MiCA in Practice #3: Transaction Monitoring & SAR

This is Part 3 of our "MiCA in Practice" series. In Part 2, we covered AML/KYC programme design. Here, we focus on the operational reality of transaction monitoring — the system that turns your policies into actionable alerts.

Transaction monitoring is where AML compliance either works or fails. You can have the most comprehensive policies in the industry, but if your monitoring system generates thousands of false positives, misses genuine risks, or lacks an auditable investigation workflow, regulators will find you deficient.

For CASPs, transaction monitoring must operate on two parallel planes: traditional off-chain monitoring (fiat deposits, withdrawal patterns, customer behaviour) and on-chain monitoring (blockchain-level analysis of sources, destinations, and transaction patterns). Getting both right — and integrating them — is the practical challenge.

Designing Your Monitoring Rules

Effective transaction monitoring starts with a rule set calibrated to your BWRA. Generic, out-of-the-box rules from traditional banking software will not catch crypto-specific risks. Your rules should cover at minimum:

Threshold-Based Rules

• Large transactions — single transactions or aggregate daily/weekly volume exceeding defined thresholds (calibrated by customer risk tier)
• Structuring detection — multiple transactions just below reporting thresholds within a defined period (e.g., several €900 deposits within 24 hours)
• Rapid movement — funds deposited and withdrawn within a short window ("pass-through" behaviour), particularly where the withdrawal is to an unhosted wallet

Behavioural Rules

• Deviation from profile — transaction volumes or patterns that deviate significantly from the customer's declared activity or historical baseline
• Dormant account activity — accounts with no activity for an extended period that suddenly show large or unusual transactions
• Geographic anomalies — login locations or counterparty jurisdictions inconsistent with the customer's profile

On-Chain Risk Rules

• Mixer/tumbler exposure — deposits or withdrawals with direct or indirect exposure to known mixing services
• Sanctioned address interaction — any transaction involving OFAC SDN, EU, or UN sanctioned addresses (must generate an immediate alert, not a batch review)
• Darknet/scam exposure — funds traceable to known darknet markets, ransomware wallets, or fraudulent schemes
• Cross-chain obfuscation — assets bridged through multiple chains in rapid succession, particularly through decentralised bridges with minimal controls
• High-risk protocol interaction — deposits sourced from or withdrawals sent to protocols flagged as high-risk (unlicensed DEXs, gambling dApps in restricted jurisdictions)

Alert Triage and Investigation Workflow

Generating alerts is only the first step. You need a structured workflow to triage, investigate, and resolve them:

Level 1: Automated Pre-Screening

Before a human analyst sees an alert, automated checks should enrich it with context: customer risk score, historical alert volume for this customer, on-chain risk data for the flagged transaction, and any related alerts from the same period. This pre-screening step can eliminate 30–50% of false positives before they reach the queue.

Level 2: Analyst Review

A trained compliance analyst reviews the enriched alert and decides: close as false positive (with documented rationale), escalate for enhanced review, or file a SAR/STR. The analyst should have access to:

• Full customer CDD file and risk profile
• Complete transaction history (on-chain and off-chain)
• On-chain analytics showing source/destination risk scores
• Previous alerts and investigation outcomes for the same customer
• Sanctions and PEP screening results

Level 3: MLRO Decision

Complex cases and potential SARs are escalated to the MLRO, who makes the final determination. The MLRO reviews the analyst's findings, assesses whether the activity constitutes reasonable grounds for suspicion, and either approves SAR filing or documents why no filing is warranted.

SAR/STR Filing: Practical Requirements

When monitoring identifies suspicious activity, the CASP must file a Suspicious Activity Report (SAR) — or Suspicious Transaction Report (STR), depending on the jurisdiction — with the relevant Financial Intelligence Unit (FIU). Key practical points:

• Timing — most FIUs expect reports within 24–72 hours of the decision to file (not 24 hours of the initial alert). The AMLR establishes a maximum of 5 working days from the point at which the obliged entity forms a suspicion (Art. 69)
• Content — include all relevant identification data, the nature and value of the suspicious transactions, the reason for suspicion, and any supporting on-chain evidence (transaction hashes, wallet addresses, risk scores)
• Tipping-off prohibition — do not inform the customer that a SAR has been filed or that an investigation is underway (Art. 54 AMLR). This prohibition extends to all staff, not just the compliance team
• Continued business relationship — filing a SAR does not automatically require you to exit the customer. The FIU may instruct you to continue the relationship for intelligence-gathering purposes
• Record keeping — retain a complete copy of every SAR filed, along with the underlying evidence and investigation notes, for a minimum of five years after the filing date

Ongoing Monitoring: Beyond the Initial Alert

Transaction monitoring is not a point-in-time activity. CASPs must implement ongoing monitoring that continuously reassesses customer risk based on evolving transaction patterns:

• Wallet monitoring — continuously track customer wallets for changes in risk profile (e.g., a previously clean wallet receiving funds from a newly sanctioned address)
• Sanctions list updates — re-screen all customer wallets whenever sanctions lists are updated (OFAC updates can occur multiple times per week)
• Periodic reviews — scheduled re-assessment of high-risk customers (at least annually) and standard-risk customers (every 2–3 years)
• Event-driven reviews — triggered by material changes: new jurisdictions, significant increase in transaction volumes, adverse media hits, or changes in beneficial ownership

How BlockchainAnalysis Monitoring Works

Manually monitoring customer wallets across 80+ blockchains is operationally impossible at scale. BlockchainAnalysis Monitoring provides continuous, automated surveillance of customer addresses — alerting your compliance team in real time when risk indicators change.

The platform re-screens monitored wallets against our database of 1B+ labelled addresses and 297+ data sources, generating alerts when a wallet interacts with sanctioned entities, receives funds from high-risk sources, or exhibits behavioural patterns consistent with money laundering typologies. Each alert includes full on-chain context, risk scores, and transaction flow visualisation — giving your analysts everything they need to make informed triage decisions.

Next in the series: MiCA in Practice #4 — Governance, Risk Management, and Internal Controls, where we cover board-level responsibilities, operational resilience, and the intersection with DORA.