Multi-accounting in iGaming: investigate repeated claims

Casino multi-accounting detection connects related activity so the operator can assess account participation under the promotion's rules. For bonus protection, investigate whether repeated claims are connected and whether that participation is eligible. A shared IP address or a device relationship can contribute evidence, but each has a different meaning.

Begin with a known claim, campaign and account. Expand to related events only after confirming how the association was created. This helps separate controlled repeated participation from genuine customers using shared networks, devices or payment arrangements permitted by the product.

Establish what the platform actually links

Ask whether the result links browser observations, devices, authenticated accounts or verified identities. A provider may return one of those relationships without returning the others. Account association often depends on a specific integration step.

Verisoul's device product uses multiple fingerprints and probabilistic account matching. Fingerprint's playground exposes hosted identification and signals. The interfaces answer related questions, but their identifiers and matching probabilities should retain their own semantics.

Write the relationship type into the case record.

That small choice makes review easier. Instead of “these accounts match,” a reviewer can say which known observations were associated, which product produced the connection and which time window applies. A later correction can then address the relevant relationship rather than invalidating an unexplained cluster.

Distinguish shared infrastructure from shared control

A casino floor, household, office or mobile network can put several genuine users behind one public address. One household computer can also serve more than one account holder. The shared resource is relevant context, but it does not establish that every connected account is controlled by one person.

Build legitimate examples into the evaluation. Use separate known devices on a shared network, a permitted shared-device case and an account moving to a replacement device. Check how the selected product represents these situations and whether the application consequence remains appropriate.

Avoid counting every connected account as confirmed abuse. If a system returns a relationship for review, preserve that status. If it returns a ready-made finding, inspect the documented meaning and conditions of that finding.

Read campaign activity with the relationship

Repeated participation is easier to interpret when account events carry campaign references and timestamps. Two accounts appearing on a device months apart may require a different investigation from a coordinated sequence of new claims during one campaign. Keep the relevant period with the evidence.

ShieldLabs combines recognition and current device/network context with ready-made multi-accounting detection. The account-linked result should still belong to the protected application event. Its usefulness depends on the collection and association present in that flow.

Sumsub's pre-KYC documentation shows another concrete association model: captured device data is connected to an applicant before a Device Intelligence check is requested. This illustrates why the integration relationship matters even when the vendor also offers identity verification.

Investigate coordinated activity without overstating identity

The term “gnoming” is used for situations where accounts in different people's names are operated together to obtain a benefit. The operational question is supported control and eligibility, rather than assuming that different names prove unrelated activity or that one device proves a single human.

SHIELD's gaming guide discusses device evidence around multi-account bonus harvesting. Darwinium's gaming material describes entity links, velocity and journey observation. Evaluate the actual returned fields and workflow for your permitted cases instead of transferring broad platform claims into a specific identity conclusion.

Keep the review focused on the evidence needed for the protected action. A large graph can be visually persuasive while leaving important edge types or observation times unspecified.

Preserve uncertainty and availability

An unavailable match is not a new player. A delayed result is not a clean signup. A matching-confidence field describes a relationship under the provider's model; it does not replace the known labels in your evaluation ledger.

Test both false splits and false merges. If a known repeated device receives different identifiers, inspect collection and supported scope. If distinct known devices are incorrectly linked, record the merge and the effect on genuine-user handling. Both errors matter when relationships influence promotional access.

Build an investigation path before expanding coverage

For the first pilot, trace one labeled repeated-account case and one legitimate shared-network case from collection to the final account record. Confirm the account, campaign, event, relationship, finding and consequence. This can reveal a wrong association even when the raw device recognition is working.

Use the evaluation checklist to expand the case set and the signals guide to inspect network and integrity evidence. The vendor reviews identify which products emphasize account findings, recognition, enrichment or journey decisions.

FAQ