--- title: "Multi-accounting detection tools: review account links" description: "Evaluate multi-accounting detection tools by link evidence, review workflow and shared-device handling. Test links without assuming one device is a person." status: published author: Michael Delgado datePublished: 2026-10-21 dateModified: 2026-10-21 --- # Multi-accounting detection tools: review account links *By Michael Delgado · Published 2026-10-21 · Last updated October 21, 2026.* Multi-accounting detection tools help a business examine relationships among apparently separate accounts. Their value depends on the evidence behind a link, the policy that makes related activity ineligible and the ability to correct an incorrect restriction. A shared device or network can describe a genuine relationship without establishing abusive behavior. ## Decide what “the same customer” means A promotion might apply once per account, person, household or business. A subscription may permit several seats within one organization. Those are different account models. Define the eligible entity before asking a vendor to connect accounts. Keep the policy separate from the relationship. The same link can be expected for invited teammates and relevant to an ineligible repeated trial. If a policy simply says “linked accounts are blocked,” the business has hidden an important eligibility decision inside a technical label. For communities or reward systems concerned with one operator gaining influence through many identities, the [Sybil-resistance guide](/blog/sybil-attack-prevention/) compares identity, reputation and resource boundaries. An account-linking result is one input to that broader design. Read the [fake-account guide](/blog/fake-account-prevention/) for signup claims and the [referral-fraud guide](/blog/referral-fraud-detection/) when the relationship concerns an incentive. ## Inspect how a link is formed | Relationship evidence | Question for the vendor | Legitimate case to test | | --- | --- | --- | | Shared device context | What does the device identifier represent? | Family or shared workstation | | Shared session or storage context | How is the event associated and refreshed? | Account switching on an authorized device | | Shared network | What uncertainty or network sharing exists? | Office, school or carrier network | | Repeated business artifact | Is the artifact controlled by the same claimant? | A business using one approved payout destination | | Combined event history | Can a reviewer inspect the underlying sequence? | An invited user joining an existing organization | Ask whether a relationship has an explanation, confidence or supporting event references. An unexplained cluster is difficult to review. Confirm how the product handles late events, changing identifiers and corrected account associations. ## Compare packaged detection with an identity input Some products provide an identifier or environmental observation that the business joins to account data. Others provide packaged account-linking or abuse detections. The first can fit a team with an existing decision system; the second can reduce some operating work if its event model matches the application. [ShieldLabs](/reviews/shieldlabs/) and [Verisoul](/reviews/verisoul/) are relevant account-abuse candidates in the existing review index. [Fingerprint](/reviews/fingerprint/) is useful to inspect when evaluating an identity layer. Their reviews preserve scope and commercial differences; do not assume that every allowance buys the same account investigation workflow. For web and native applications, test coverage separately. A device relationship established in one surface does not establish universal cross-device or cross-platform person recognition. ## Use a controlled account matrix Prepare expected cases before the demonstration: one customer with several devices, several legitimate people sharing a device, a team using a common network and controlled ineligible repeat claims. Record the business outcome expected for each. A hypothetical SaaS product might allow several staff accounts under one paid organization while restricting repeated introductory credits. The evaluation should show both permitted team membership and a disputed credit claim. A detector that links the accounts has only supplied one part of that decision. Keep the test in an authorized environment. The goal is to inspect evidence and policy behavior, not to develop instructions for evading a public service’s controls. ## Plan the review and correction model Define whether an exception applies to an account, relationship, organization or benefit. A broad allowlist can unintentionally remove protections from unrelated actions. Keep a reason and decision reference for each exception. Support needs a safe way to ask for relevant business information and resolve an incorrect restriction. Avoid requiring a customer to explain raw technical observations they cannot inspect. Use plain language about eligibility and the next step. The [ban-evasion article](/blog/ban-evasion-detection/) covers the additional policy and appeal questions when an earlier restriction is part of the relationship. ## Measure useful links rather than cluster size Track reviewed link accuracy for the specific policy, confirmed ineligible claims, legitimate customer completion and correction work. A larger account graph is not automatically a better business outcome. Preserve the number of unknown or unreviewed cases. Budget for the events the product actually bills. Account checks, identifications, historical searches and optional verification can be separate items. Use the [pricing worksheet](/blog/fraud-detection-pricing-units/) to connect the expected account journey to the contract. Choose a narrow first action and a named owner. The pilot should end with a decision about coverage, operating effort and customer recovery rather than a screenshot of an impressive cluster. ## Compare account-network evidence in a demo [Verisoul](https://www.verisoul.ai/) and [Castle](https://castle.io/) are examples to investigate from their current public account-abuse scope. This is a pilot starting list, not a finding that either identifies every shared operator. Bring the same three cases to a demonstration: 1. Two allowed users sharing a device. 2. One customer legitimately replacing a device. 3. Accounts confirmed by your own records to be part of an ineligible repeated claim. Ask the supplier to show the link type, event timeline, unknown fields and reviewer action for each case. Do not accept a cluster picture as proof that the accounts belong to one person. ## FAQ ### Can linked accounts always be treated as the same person? No. The evidence may describe a shared environment or business artifact. Interpret the relationship within the account model and policy. ### Do tools still work after cookies are cleared? Capabilities depend on the product and supported environment. Test the documented behavior without assuming guaranteed persistence or person identity. ### Should I buy a dedicated tool or a fraud suite? Choose the missing workflow. Compare the required evidence, packaged decisions, investigation features, integration work and billing scope on the same use case. ## Sources - [Verisoul: product scope](https://www.verisoul.ai/). - [Castle: product scope](https://castle.io/). - [W3C: mitigating browser fingerprinting](https://www.w3.org/TR/fingerprinting-guidance/). - [OWASP: transaction authorization](https://cheatsheetseries.owasp.org/cheatsheets/Transaction_Authorization_Cheat_Sheet.html). - [OWASP: automated threats](https://owasp.org/projects/automated-threats-to-web-applications).