The investigation lifecycle

A crypto investigation is a project with legal consequences, and it fails in predictable ways: preservation windows are missed, scope drifts, findings go unreviewed and nobody can later explain why a lead was dropped. A defined lifecycle gives each stage a purpose, an output and a record in the case file. This lesson walks through the stages, the case file that ties them together and a worked intake.

The stages at a glance

ISO/IEC 27043 describes investigations in a similar way, grouping the work into readiness, initialization, acquisitive and investigative processes, with concurrent processes such as obtaining authorization, documentation and preserving the chain of custody running throughout. The point carries over directly: some activities are not stages but threads that run from intake to closure.

The stages are also not strictly linear. Analysis routinely reveals new seeds, such as a second victim or a bridge to another chain. That sends the case back to scoping and collection, and every such loop should leave a dated entry explaining the change.

Intake and triage

Intake captures the report as received: who reported, what is alleged, every identifier supplied (txids, addresses, account IDs, screenshots, chat exports), when events happened in UTC, the claimed loss, and what the reporter has already done. The last item matters. A victim who has posted the scammer's address on social media, or contacted the exchange directly, may already have alerted the subject.

Triage decides priority. In crypto cases speed often decides the outcome, so the main factors are about whether action now can still change things.

A case with funds laundered through a mixer two years ago is still recorded, but it is not worked first. Record the triage decision and its reasons; a decision not to act is also a decision that may need explaining later.

Scoping

A scope statement has four elements.

• Seeds: the identifiers the case starts from. Verify each one on the chain before relying on it. Victims misread screenshots, copy truncated addresses and confuse networks; a txid that does not exist or sits on another chain is common.
• Chains and assets: which networks and tokens are in scope. The same EVM address format is valid on many chains, so state which ones were checked.
• Period: start and end times in UTC, with a margin before the first known event.
• Questions: specific and answerable. "Where are the victim's funds now, and which service accounts received them?" can be answered; "Find the scammers" cannot, at least not by an examiner.

Scope creep is not wrong in itself, but unrecorded scope creep is. When the scope changes, record what changed, why, who approved it and on what date.

Planning and hypotheses

The investigation plan lists tasks, the data sources each task needs, the legal authority each source requires (see the lesson Legal authority and international cooperation), who owns each task, deadlines and dependencies. Requests to providers abroad can take months, so they are started early and in parallel with on-chain work.

Hypotheses keep the investigation honest. Write down at least two explanations that fit the facts at intake and identify the evidence that would tell them apart. For a reported investment scam, they might be: the platform operators took the funds; the victim's own wallet was compromised by a third party; or the platform was a real, if failing, business. The IDFE-BA lesson From question to hypothesis covers analysis of competing hypotheses; the forensic addition is that the case file must show which hypotheses were tested and what evidence eliminated them.

Collection, analysis and review

Collection means acquiring data under the right authority and preserving it so that it can be verified later: on-chain data with block references, provider returns, device images, web captures. The lesson Preserving on-chain evidence covers the techniques.

Analysis turns preserved data into findings, each with its method, basis and confidence, as taught in Module 2.

Review is a separate stage, not a courtesy. A reviewer who did not do the work checks the method, re-performs the key hops from raw data and challenges every inference. Disagreements and how they were resolved go into the file. A review that finds a gap sends the work back to planning: more data, a different method or a narrower claim. The lesson Quality management in the forensic unit describes peer review and validation in more depth.

Reporting, disclosure and closure

Reporting produces the statement or expert report and its appendices (see the lesson Writing the forensic report). Disclosure makes material available to the other side as the proceedings require, including unused material and tool and label provenance (see the lesson Disclosure and defense scrutiny).

Closure is easy to neglect. A closure memo records the outcome, any open leads, assets still held and who controls them, retention periods for evidence and personal data, and lessons learned. Crypto cases often reopen when dormant funds move years later, so the file must let a different examiner pick up where the last one stopped.

Case management and a worked intake

The case file is the single place where the case lives: intake, scope and changes, plan, copies of legal authority, requests and returns, the evidence log, contemporaneous notes, findings, review records, reports, disclosure and closure. Access is restricted and logged.

A victim reports losing 48,500 USDT on the Tron network in five payments over three weeks to a trading platform that has stopped responding. The examiner works through intake:

1. Verify the seeds. Four txids are confirmed on Tron. The fifth, taken from a screenshot, does not exist on Tron; it is found on Ethereum, where the victim had sent a test payment. Both are recorded, with the discrepancy noted.
2. Quick look forward. The last payment, 9,800 USDT, reached an address that swept to a hot wallet labeled as Exchange K two hours ago.
3. Triage. Funds at a custodial service, moved recently: priority high.
4. Immediate actions. A preservation request and a voluntary freeze request go to Exchange K the same morning (see the lesson Working with service providers). Whether the stablecoin issuer could freeze the receiving address is noted for the plan.
5. Scope and hypotheses. Seeds, two chains, a period starting a week before the first payment, three questions and two competing hypotheses are written down.

The intake record at the end of the morning:

{
  "case_id": "CF-2026-0147",
  "received_utc": "2026-03-04T09:15:00Z",
  "allegation": "investment scam; funds sent to an unresponsive trading platform",
  "seeds": [
    {"chain": "tron", "type": "txid", "value": "7b2f…d9e0", "verified": true},
    {"chain": "ethereum", "type": "txid", "value": "0x3a8c…f71b", "verified": true,
     "note": "screenshot labeled Tron; found on Ethereum"}
  ],
  "reported_loss": {"asset": "USDT", "amount": "48500.00"},
  "priority": "high",
  "priority_reason": "9,800 USDT reached an Exchange K deposit address 2 hours before intake",
  "immediate_actions": ["preservation request P-01", "voluntary freeze request F-01"],
  "assigned_to": "examiner-07",
  "authority_status": "production order requested"
}

The record shows the verified seeds, the discrepancy and its resolution, the reason for the priority and the actions taken, each with a reference that points to the request in the case file. Only two of the five seeds are shown here; the full list goes in the scope statement. Amounts are stored as strings to avoid rounding when the record is processed.

Exam focus: the nine lifecycle stages and the output each leaves in the case file; ISO/IEC 27043 and the idea of concurrent processes such as authorization, documentation and chain of custody; triage factors that raise priority in crypto cases; the four elements of a scope statement and why seeds must be verified on-chain; recording scope changes; writing competing hypotheses and the evidence that separates them; review as independent re-performance; what a closure memo must record; what a sound intake record contains.