Fraud teams should build a single case file that links wallets, domains, payment processors, and company records. The point is to identify the operational chain behind the scam, not just the victim transactions. That approach helps distinguish isolated activity from an organised fraud infrastructure and supports stronger attribution decisions.
Why This Matters for Security Teams
Crypto scams that use multiple companies are harder to investigate because the corporate layer is often part of the concealment, not just the fraud itself. A single victim payment may pass through shell entities, payment processors, exchange accounts, and vendor relationships before it reaches a wallet. That means investigators need to correlate company registrations, infrastructure, and money movement together, rather than treating each transaction as an isolated event. NHI Mgmt Group’s Ultimate Guide to NHIs is relevant here because scam operations often rely on compromised or disposable non-human identities such as API keys and platform accounts to sustain the flow of funds and data. A useful control baseline is NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where evidence handling, access control, and auditability matter. Current guidance suggests the best fraud outcomes come from joining financial, technical, and corporate evidence into one case narrative. In practice, many fraud teams only see the pattern after the scam network has already rotated domains, accounts, and company names several times.
How It Works in Practice
The investigation should start by building an entity map, not a payment ledger. Each case should link wallets, domains, hosting providers, incorporated entities, email accounts, social profiles, and payment rails so the team can identify repeat infrastructure across supposedly separate companies. That is especially important when one operator uses multiple legal entities to split risk, confuse attribution, or pass due diligence checks.
A practical workflow usually includes:
- Collecting on-chain records, exchange withdrawal data, and payment processor logs into a single timeline.
- Matching company directors, addresses, formation dates, and registrars for overlap or recycled patterns.
- Preserving metadata from domains, certificates, hosting, and contact records for clustering.
- Tagging shared infrastructure such as wallets, API keys, support emails, and merchant accounts.
- Escalating to legal and compliance teams once the same operational controls appear across multiple brands.
This is where identity security thinking helps. Scams that span several companies often depend on weak control over machine identities, outsourced access, and third-party integrations. The NHIMG research on the Ultimate Guide to NHIs is useful because it shows how unmanaged service accounts, keys, and third-party exposure become persistence mechanisms. For control design, NIST SP 800-53 Rev 5 Security and Privacy Controls supports evidence integrity, access restriction, and log retention practices that make chain analysis defensible. Fraud teams should also maintain chain-of-custody on extracted data so attribution can survive legal review, SAR filing, or law enforcement referral. These controls tend to break down when payment data sits in one system, corporate records in another, and the case owner lacks permission to correlate them across jurisdictions.
Common Variations and Edge Cases
Tighter attribution often increases investigation time, so teams have to balance speed against the need to avoid false linkage. That tradeoff becomes sharper when several companies are legitimate on paper but share a small number of operational touchpoints that may or may not be intentional.
A few edge cases matter:
- Some scams use real incorporated companies as front-end contractors, so the presence of a valid business record does not prove legitimacy.
- Shared payment processors can create weak signals; current guidance suggests treating them as correlation points, not proof on their own.
- Cross-border structures can obscure beneficial ownership, which means public registry data may be incomplete or stale.
- Where a scam touches NHI or agentic tooling, investigators should ask whether API keys, automation accounts, or vendor integrations were abused to move funds or suppress alerts.
The main operational risk is overconfidence from a single indicator. One wallet, one domain, or one company name rarely tells the full story. Better cases combine technical indicators, corporate control evidence, and access patterns to show the operating model behind the fraud. The NHIMG view of Ultimate Guide to NHIs reinforces that unmanaged non-human access often extends fraud lifecycles across multiple services and brands. Where organisations rely on loosely governed third-party access or shared admin tooling, the investigative model can break down because the same actor leaves too few stable identifiers to prove continuity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 | Fraud investigations need clear business context and risk ownership across linked entities. |
| MITRE ATT&CK | T1583 | Scams using multiple companies often reuse infrastructure acquisition patterns. |
| OWASP Non-Human Identity Top 10 | NHI-07 | Compromised or overexposed non-human access can sustain multi-company fraud operations. |
Define case ownership, scope, and decision criteria before correlating companies, wallets, and infrastructure.
Related resources from NHI Mgmt Group
- How should AML teams investigate crypto transactions that use mixers and bridges?
- How should security teams investigate sensitive file exposure when data is copied across multiple systems?
- How should security teams govern AI agents that use multiple identity layers?
- Should customer identity teams use fraud trends to prioritise controls?
