Protect Product / Research deskFraud prevention software field guide · October 2026
Protect Product

Protect Product / Field guide

Multi-accounting detection tools: review account links

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.

Published 5 min read
Protect Product editorial guide: Multi-accounting detection tools: review account links

Read this article with AI

Copy the article text into your chosen tool to inspect its sources and trade-offs.

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 compares identity, reputation and resource boundaries. An account-linking result is one input to that broader design.

Read the fake-account guide for signup claims and the referral-fraud guide when the relationship concerns an incentive.

Retain the link type instead of merging accounts into people.
Editorial model. Retain the link type instead of merging accounts into people. Original illustration; no vendor performance is measured.
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 and Verisoul are relevant account-abuse candidates in the existing review index. 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 covers the additional policy and appeal questions when an earlier restriction is part of the relationship.

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 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 and Castle 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

Editorial basis: primary-source documentation and a practical evaluation framework. Examples are hypothetical unless explicitly identified otherwise. This article does not report an independent vendor benchmark.

For evaluation standards and corrections, see our methodology and contact page.