Suspicious Transaction Reports in Crypto: When to File
A crypto business should file a suspicious transaction report when it knows, suspects, or has reasonable grounds to suspect that funds are linked to crime or terrorist financing. The report goes to your country's financial intelligence unit (FIU), and it is only useful if an analyst who has never seen your case can follow it: full addresses and hashes, a clear timeline, confirmed facts kept apart from indicators, and the customer's KYC data. This guide covers when the threshold is crossed, what to put in the report, and the mistakes that make good cases hard to use.
STR or SAR: the same obligation under different names
FATF Recommendation 20 requires financial institutions, and through Recommendation 15 virtual asset service providers (VASPs), to report suspicious transactions promptly to the FIU. Each jurisdiction names that report in its own way:
- SAR (suspicious activity report) is the term used in the United States and the United Kingdom, among others.
- STR (suspicious transaction report) is common in Asia, Africa, the Middle East and Central Asia.
- Some EU and Latin American regimes speak of "suspicious transaction notifications" or use local acronyms such as ROS.
The label matters less than the substance. In every regime, the report describes who, what, when and why you are suspicious, and it goes to a government body that can combine it with information from other reporters. Deadlines, formats and filing portals differ by country, so check your local FIU guidance for the exact rules rather than relying on a generic number.
When does a crypto case cross the reporting line?
Suspicion is a lower bar than proof. You do not need to know which crime produced the funds. You need facts that a reasonable compliance officer would find hard to explain as legitimate activity. For a crypto exchange or payment provider, that usually means one or more of the following:
- Direct or close exposure to a sanctioned address or entity.
- Funds received from, or sent to, a darknet market, ransomware wallet, mixer or scam cluster.
- Behavior that looks like structuring: repeated deposits just under internal or regulatory thresholds, evenly spaced transfers, round amounts with no business reason.
- A mismatch between the customer's KYC profile and the volume or pattern of activity.
- Rapid pass-through: funds arrive and leave within minutes, often to a newly created address.
- Information from a counterparty VASP during a Travel Rule exchange that contradicts what your customer told you.
A single indicator rarely settles the question on its own. A deposit two hops away from a mixer can be innocent. The same deposit, from a customer whose declared income does not match, followed by an immediate withdrawal to a fresh address, is a different picture. Write down why you concluded what you concluded, whichever way you decide. A documented decision not to report is as important for an examiner as a filed report.
A practical decision rule
Many teams use a three-way outcome rather than a yes/no, because it forces a second look at borderline cases:
| Outcome | Typical facts | What happens next |
|---|---|---|
| Do not report | Low risk score, no sanctions exposure, no direct darknet contact | Close with a written rationale |
| Review | Mixed signals, indirect exposure, unexplained but not clearly criminal patterns | Request information from the customer or escalate to a senior officer |
| Report | High risk score, any sanctions exposure, direct darknet or ransomware contact | Prepare and file the STR |
In Cryptic AI, the compliance advisor applies this logic to the investigation result: a score below 40 with no sanctions and no direct darknet contact leads to "don't report", 70 or more, any sanctions exposure or direct darknet or ransomware contact leads to "report", and everything in between goes to review. The recommendation lists the FATF red flags it relied on and the regulations that apply. The decision and the signature stay with the compliance officer.
What makes a crypto STR usable by the FIU
1. Full addresses and transaction hashes
Write every address and hash in full. 0x3f5c…a91e is not searchable. An analyst cannot paste a shortened hash into a block explorer, and two addresses with the same first and last characters are not rare. Name the blockchain for each one, because the same address format can exist on several EVM networks.
2. A timeline
List the relevant transactions in order: date and time in UTC, direction, asset, amount, counterparty address and hash. A table works better than prose here. Then summarize the pattern in two or three sentences, for example: "Between 3 and 9 March, the customer received 14 USDT deposits of 9,500 to 9,900 each from 11 addresses, and withdrew 98% of the total to a single address within 24 hours of each deposit."
3. Confirmed facts separated from indirect indicators
"The customer received 12,000 USDT directly from an address on the OFAC SDN list" is a fact you can prove with a hash. "The funds may originate from a scam" is an inference. Both can belong in the report, but they belong in different paragraphs, and the inference should say what it rests on (attribution source, number of hops, the pattern observed).
4. The customer's KYC data
Include the identity and contact details you hold, the onboarding date, the declared occupation or source of funds, IP or device information if your rules allow it, and any linked accounts. This is the part only you have. The FIU can trace public blockchain data on its own; it cannot see who opened the account.
5. The "why"
Close with your reasoning: which indicators, taken together, made the activity suspicious, and which typology you believe it fits. Several FIUs ask reporters to classify reports by typology code; map your internal risk categories to that list before you need it.
Common mistakes in crypto suspicious activity reports
- Shortened hashes and addresses. The single most frequent problem, and the easiest to avoid.
- Speculation stated as fact. "The customer is laundering ransomware proceeds" when the evidence is a three-hop link to a cluster. Overstated claims damage the credibility of the whole report.
- Missing the why. A list of transactions with no explanation forces the analyst to redo your investigation.
- Screenshots of tools instead of data. A risk score or a graph image without the underlying transactions cannot be verified.
- No mention of actions taken. Say whether you froze the account, rejected a withdrawal, requested documents, or kept the relationship open.
Tipping-off: what you may not tell the customer
FATF Recommendation 21 prohibits disclosing to the customer, or anyone else, that a suspicious transaction report is being prepared or has been filed. In practice this affects support scripts and account actions. If you restrict an account after filing, your message should be neutral ("your account is under review") and should never mention the FIU, the report or the specific suspicion. Train support staff on this, and keep STR status visible only to the compliance team.
Record keeping
FATF Recommendation 11 requires transaction records and CDD information to be kept for at least five years, and many countries set longer periods. For STRs, keep:
- the filed report and the filing confirmation;
- the investigation file: risk score, data sources consulted, graphs, and the transaction list;
- the decision record, including cases you decided not to report and the reason;
- internal escalation emails or approvals.
Blockchain attribution changes over time. An address that was unlabeled when you investigated may be labeled later. Save the evidence as it stood on the day of the decision, with timestamps and source names, so you can show what you knew at the time.
How a reporting workflow fits together
A typical flow at a crypto business looks like this: a monitoring alert, a Travel Rule exchange or a manual check opens a case; the investigation gathers evidence and a risk score; a recommendation and draft follow; the officer reviews, edits and submits. In Cryptic AI's KYT, the agent traces funds across hops and cross-checks several blockchain data providers, and every risk factor has to cite a transaction, a source and a timestamp or it is dropped. The STR reporting module then builds a draft from that evidence with full hashes and addresses, only confirmed facts in the narrative and indirect indicators flagged separately. A chat assistant handles edits such as "add the transfers between these two addresses" or "make the conclusion shorter", and the draft exports to DOCX, HTML or plain text.
FAQ
Is a SAR the same as an STR for crypto?
Yes, in substance. Both are reports of suspicion to the national FIU. The name, form and deadline depend on the jurisdiction.
Do I need proof of a crime before filing?
No. The standard is suspicion or reasonable grounds to suspect. You report facts and your reasoning; investigating the underlying crime is the authorities' job.
Can I keep serving a customer after filing?
Often yes, subject to local law and any instruction from the FIU. Whatever you decide, record it, and avoid any action or message that could tip the customer off.
Should I file if a transaction was rejected?
In many regimes, attempted transactions are reportable too. If you blocked a deposit or withdrawal because it looked suspicious, check whether your local rules require a report.
Good STRs come from good investigations: evidence first, then a clear narrative an FIU analyst can act on. If your team spends hours rebuilding timelines and retyping hashes for each report, see how Cryptic AI's reporting workflow turns case evidence into a draft your officer can review and sign. To test a single address first, run the free AML wallet check.