Crypto crime cases can fail even when the technology is available. The problem is often an inconsistent investigation process: alerts are handled differently by each analyst, evidence is not preserved, attribution is overstated, and the final decision does not explain how the facts meet the firm's legal or policy threshold.
A clear workflow helps compliance teams investigate ransomware, darknet markets, fraud, theft, sanctions exposure, and laundering activity with the same core standards. It also supports efficient quality assurance and makes urgent cases easier to escalate.
This guide provides a practical end-to-end workflow from alert triage to case closure, monitoring, or SAR and STR escalation.
This workflow is the operating layer behind ransomware payment investigations and darknet market exposure reviews. It also supports the broader Ransomware, Darknet Markets and Crypto Crime Investigation guide by giving analysts a repeatable route from alert context to documented outcome.
What makes a crypto crime case defensible?
A defensible case does not need perfect visibility. It needs a clear scope, reliable evidence, proportionate reasoning, and an audit trail that another reviewer can reproduce.
Step 1: Define the alert and investigation scope
Start with the exact trigger. Record the customer, product, wallet, transaction hash, asset, network, value, date, risk category, exposure depth, and analytics source.
Decide what the case needs to answer. Examples include:
• Did the customer directly send funds to a ransomware or darknet market address?
• Is the customer a victim, buyer, vendor, broker, criminal recipient or unrelated third party?
• Are the funds linked to a theft, fraud or exploit?
• Does the transaction create sanctions or suspicious activity reporting concerns?
• Is immediate restriction or external coordination required?
A defined question prevents the analyst from collecting large amounts of irrelevant data.
Step 2: Preserve the evidence
Save the original alert and all key identifiers before labels or web content change. Preserve transaction hashes, wallet addresses, screenshots or exports, customer messages, support tickets, KYC records and relevant documents.
For ransomware, preserve the ransom note, payment instructions and negotiation evidence. For darknet markets, preserve official attribution or takedown material rather than attempting unsafe access to criminal sites.
Evidence should be stored according to the firm's security, privacy and legal procedures. The case file should contain enough information to reproduce the analysis without relying only on screenshots.
Step 3: Establish customer and wallet ownership
Review the customer's identity, occupation or business, account age, expected activity, source of funds, previous transactions, devices, IP information, linked accounts and prior alerts.
Determine which wallets the customer controls. Exchange withdrawal records, signed messages, Travel Rule data, deposit ownership, device evidence and customer explanations can help. Do not assume ownership simply because a wallet is adjacent to a customer transaction.
The customer's role is central. An organisation acquiring crypto after a ransomware incident is different from an account repeatedly receiving payments from victim wallets.
Step 4: Trace the source and destination
Trace backward to identify the origin of funds and forward to find their destination. Record key values, timestamps, swaps, internal transactions, bridge messages, mixer exposure and exchange deposits.
The analyst should maintain a clear transaction map rather than a collection of disconnected screenshots. Where several paths exist, prioritize the branch carrying the largest value or the one linked to the highest-risk service.
The investigation should stop only when a meaningful endpoint is reached, the value becomes immaterial or the confidence is too weak to continue responsibly.
Step 5: Combine on-chain and off-chain evidence
On-chain evidence shows what happened between addresses. Off-chain evidence helps explain who controlled them and why the transaction occurred.
Useful off-chain sources include customer records, source-of-funds documents, incident reports, exchange responses, Travel Rule data, contracts, invoices, support messages, sanctions information, public enforcement releases and lawful law-enforcement requests.
A strong case tests whether these sources agree. A customer explanation may fit the transaction timing but conflict with wallet ownership. An analytics label may indicate a market, while the value and activity period suggest that the address was no longer used by the service.
Step 6: Assess attribution confidence
Attribution should be expressed at the level the evidence supports.
Tentative or low confidence
A single vendor label, distant indirect exposure or timing similarity with several plausible alternatives. The case should not use definitive ownership language.
Moderate confidence
Reliable analytics attribution supported by direct interaction, relevant timing, value patterns or known service behaviour, but without independent identity confirmation.
High confidence
Several independent sources support the same conclusion, such as analytics, official attribution, customer records and counterparty information.
Confirmed
A legal identity or control relationship is established through verified account records, official evidence, direct admission or equivalent reliable material.
The analyst should record what evidence could increase or reduce the confidence level.
Step 7: Analyse typology and behaviour
Classify the pattern using the underlying behaviour rather than a generic “high-risk crypto” label.
Relevant patterns include:
• Victim payment followed by affiliate and operator splits.
• Repeated market deposits or vendor payouts.
• Stolen funds moving rapidly through decentralized exchanges and bridges.
• Fraud proceeds consolidated from many victims.
• Use of fresh wallets, peel chains, mixers or nested services.
• Multiple customer accounts sharing funding or destination infrastructure.
• Conversion into stablecoins or privacy assets before off-ramping.
• Delayed movement designed to avoid immediate post-incident monitoring.
Explain why the pattern matters in the specific case. A bridge transfer alone is ordinary technology; a bridge used immediately after receipt of exploit proceeds may support a laundering assessment.
Step 8: Apply sanctions, legal and policy review
Screen relevant entities, addresses, counterparties and service providers using current information. Consider ownership and control, not only exact address matches. Escalate possible sanctions issues to specialists before releasing funds or advising the customer.
Review the applicable SAR or STR threshold, transaction restrictions, reporting duties, information-sharing permissions, preservation requirements and customer communication rules.
The legal review should be documented. Statements such as “no sanctions issue” should identify which parties were screened, when and against which source.
Step 9: Reach the case decision
Possible outcomes include:
• Close the alert as explained or unsupported.
• Release or process the transaction under approved controls.
• Request additional information.
• Apply enhanced monitoring or lower limits.
• Restrict withdrawals or freeze assets where legally permitted.
• Reject the transaction or exit the relationship.
• Escalate to sanctions, fraud, cyber security or legal specialists.
• File a SAR or STR and support lawful external requests.
The decision should reflect the severity and directness of exposure, customer role, explanation, evidence quality, legal obligations and residual risk.
Step 10: Write the case note
A strong case note should include:
Alert and scope
State what triggered the review and the question the investigation was designed to answer.
Confirmed facts
List customer records and on-chain events that can be independently verified.
Analysis and attribution
Explain the transaction path, risk typology, wallet roles, confidence level and competing explanations.
Legal and policy review
Record sanctions screening, reporting analysis, restrictions, consultations and required approvals.
Decision and rationale
State the outcome and why it is proportionate to the evidence and risk.
Gaps and follow-up
Identify missing information, ongoing monitoring, retrospective checks or external responses still required.
SAR or STR escalation
A SAR or STR should provide useful financial intelligence rather than repeating a generic alert. Include the customer, suspected offence, relevant wallets, hashes, values, dates, services, transaction flow and reason for suspicion.
For a ransomware case, identify the victim payment, demand wallet, affiliate splits and later exchange or laundering destinations where known. For a darknet market case, state whether the customer made deposits, received vendor payouts or handled market fees.
Avoid unsupported legal conclusions. The report can describe behaviour consistent with laundering or criminal proceeds without claiming a specific offence has been proven.
Quality assurance and governance
Quality assurance should test both technical tracing and decision logic. Reviewers should check:
• Was the alert and customer role correctly defined?
• Are transaction identifiers complete and reproducible?
• Was the analytics attribution current and appropriately qualified?
• Were customer and counterparty records considered?
• Were sanctions and legal issues escalated correctly?
• Does the outcome match the firm's policy and similar cases?
• Are facts, inferences and gaps separated?
• Is ongoing monitoring assigned and dated?
Management information should track alert volumes, case outcomes, direct versus indirect exposure, false positives, time to escalation, SAR quality and emerging services or typologies.
Common workflow failures
Failure 1: Starting with the conclusion
An analyst who begins with “the customer is laundering money” may select only evidence that supports that view. Start with a neutral investigation question.
Failure 2: Using screenshots without transaction identifiers
Screenshots help explain a case but may not allow another reviewer to reproduce it.
Failure 3: Confusing interaction with ownership
Sending funds to an address does not prove ownership of the recipient. Cluster association does not automatically prove legal control.
Failure 4: Failing to record confidence
A tentative analytics link should not be written in the same language as confirmed exchange records.
Failure 5: Applying policy inconsistently
Similar cases should receive similar treatment unless there is a documented reason for a different outcome.
Failure 6: Closing without a monitoring plan
Some cases are not suspicious enough for immediate escalation but still require enhanced monitoring or retrospective review.
Conclusion
A consistent crypto crime investigation workflow turns blockchain data into a defensible compliance decision. The process begins with a clear question, preserves evidence, establishes customer and wallet roles, traces the flow, qualifies attribution and applies the correct legal and policy review.
The best case notes do not hide uncertainty. They show what is confirmed, what is inferred, what remains unknown and why the final response is proportionate.
This workflow becomes stronger when it is connected to the broader Ransomware, Darknet Markets and Crypto Crime Investigation framework, because typology knowledge, wallet-role analysis and evidential confidence all shape the final decision. For structured analyst training, explore the Ransomware, Darknet Markets and Crypto Crime Investigation Basics course.
FAQs
How long should a crypto crime investigation take?
The timeline depends on urgency, complexity and legal risk. Sanctions or live ransomware cases may need immediate escalation, while historical indirect exposure can follow a standard queue.
What is the difference between a fact and an inference?
A fact can be independently verified, such as a transaction hash or customer record. An inference is an analytical conclusion drawn from facts, such as likely common control.
How many transaction hops should an analyst trace?
There is no universal number. Trace until a meaningful endpoint is reached, the link becomes too weak or the remaining value is not material to the case.
Should analysts rely on one blockchain analytics provider?
A provider can be central to the process, but high-impact conclusions should be corroborated with transaction data, official sources, customer evidence or counterparty information where possible.
What should be included in a SAR or STR narrative?
Include the customer, suspected activity, wallets, hashes, dates, values, services, tracing summary and reason for suspicion, while separating fact from inference.
When is retrospective review needed?
Review may be needed after a new sanctions designation, market takedown, ransomware attribution, exchange response or material update to service intelligence.
How should case confidence be recorded?
Use defined levels such as tentative, moderate, high confidence and confirmed, and explain the evidence supporting the level.
What happens when evidence is incomplete?
The firm can request information, apply enhanced monitoring, restrict activity where appropriate or close the case with documented residual risk. Missing evidence should never be hi
