Transaction monitoring used to be a best-practice recommendation dressed up as a regulatory obligation. That era is over.
The Sixth Anti-Money Laundering Directive — Directive (EU) 2018/1673, effective 3 December 2020 — harmonised predicate offence categories across all EU member states for the first time. The companion AML Regulation (EU) 2024/1624 and the AMLA Regulation (EU) 2024/1620, both carrying a January 2027 transposition deadline, operationalise those obligations into specific, auditable requirements for transaction monitoring systems.
For crypto-asset service providers (CASPs) and financial institutions, this means a documented typology matrix, timestamped audit trails per transaction, and formal escalation paths to your MLRO. This post is not about the legal framework in the abstract — it is about what your monitoring system must detect, what real enforcement failures look like, and how each of Arkē's three pillars maps to the obligations.
What Is 6AMLD and Who Does It Cover
6AMLD applies to the same obligated entities as the AMLD5 framework it extended: credit institutions, payment institutions, electronic money institutions, insurance companies, investment firms, and — critically — crypto-asset service providers and virtual asset service providers.
The scope clarification that matters most in 2026: under MiCAR (Regulation (EU) 2023/1114), CASPs authorised to operate in the EU are simultaneously subject to both 6AMLD's predicate offence framework and the AML Regulation 2024/1624 that accompanies the new AMLA authority. There is no separate lighter-touch regime for crypto. The obligations stack.
The AML Regulation 2024/1624 is the instrument that makes transaction monitoring a hard-law obligation rather than a supervisory expectation. Article 7 requires obligated entities to maintain a documented risk-based transaction monitoring programme. Article 50 governs suspicious activity report (SAR) format and filing. These are not guidelines — they are directly applicable rules from January 2027, with member-state enforcement from the moment of transposition.
The 22 Predicate Offences — What They Mean for Transaction Monitoring
6AMLD's most consequential contribution was harmonising the list of predicate offences — the underlying crimes whose proceeds constitute money laundering — across all EU member states. Before 6AMLD, member states varied significantly in which offences triggered money laundering exposure. Now there is a floor of 22.
For a transaction monitoring system, each predicate offence corresponds to a detection typology. The table below maps each of the 22 offences to the monitoring signal that surfaces it:
| Predicate Offence | Primary Monitoring Typology |
|---|---|
| Terrorism financing | Transfers to flagged jurisdictions; structured small amounts below reporting thresholds |
| Cybercrime (incl. ransomware) | Rapid conversion of wallet funds; known malicious address matches; darknet-linked wallets |
| Environmental crime | Payments to non-registered waste or carbon credit entities; sanctioned jurisdictions |
| Trafficking in persons | Round-trip transactions with no apparent commercial purpose; cash-to-crypto conversion |
| Counterfeiting goods | Volume anomalies on accounts linked to physical goods without apparent inventory |
| Counterfeiting currency | Large cash-equivalent deposits followed by rapid disbursement |
| Tax crimes (incl. VAT fraud) | Layer 2 anonymisation tool usage; cross-jurisdictional round-tripping |
| Market manipulation | Transaction concentration around corporate announcement windows |
| Insider trading | Correlated asset acquisition before public M&A events; wash trading patterns |
| Extortion | Ransom-pattern payments; repetitive transfers to new wallet addresses |
| Fraud | Chargebacks followed by crypto conversion; account takeover transfer patterns |
| Forgery | Identity mismatch flags on onboarding; document anomaly signals |
| Piracy | Payments to entities with adverse media on IP infringement |
| Corruption | PEP-linked transfers; beneficial owner concentration in high-risk jurisdictions |
| Bribery | Third-country payments to individuals without commercial counterparty documentation |
| Obstruction of justice | Shell company structuring with no apparent business purpose |
| Computer crime | Wallet addresses flagged by blockchain analytics providers |
| Participation in criminal organisation | Network clustering of counterparty wallets on shared infrastructure |
| Drug trafficking | Mixing service usage; high-frequency small transfers to consumer wallets |
| Human trafficking | Geographic anomalies; remittance patterns to conflict-affected regions |
| Sexual exploitation | Consumer platform wallet clustering; flagged payment processors |
| Kidnapping and unlawful restraint | Ransom payment patterns; hostage-related adversarial media signals |
| Armed robbery | Cash conversion followed by rapid cross-border transfer |
A monitoring system that cannot articulate which typology triggered a flag — and which predicate offence that typology maps to — is not defensible to a regulator. Your typology matrix is evidence, not configuration.
Real Enforcement Cases
Enforcement history is the clearest signal of where regulators focus attention. Three cases define the landscape.
ING Bank — Netherlands, 2018, €775 million
ING Bank NV reached a €775 million deferred prosecution agreement with the Dutch Public Prosecution Service in September 2018 — at the time the largest AML settlement in Dutch legal history. The failure was structural: ING's transaction monitoring systems did not detect systematic structuring (smurfing) across its correspondent banking accounts. Clients were layering drug trafficking proceeds and tax evasion payments through business accounts, using sub-threshold transaction structuring to avoid automated reporting flags.
The specific predicate offences were drug trafficking and tax evasion. ING's monitoring system failed because its thresholds were calibrated to individual transaction amounts rather than cumulative velocity across counterparty networks. A single €9,500 transfer looks unremarkable. Twenty of them across five client accounts to three counterparties in a week is a structuring pattern.
Société Générale — France and United States, 2019, €1.34 billion
Société Générale's combined settlement with the US Department of Justice and the French Parquet National Financier totalled approximately €1.34 billion and covered two separate failures. The portion relevant to AML monitoring involved a bribery scheme connected to Libyan sovereign wealth fund investments: the bank's correspondent banking infrastructure processed payments that were the proceeds of corruption and bribery — predicate offences under both French law and, from 2020, the harmonised 6AMLD framework.
The monitoring failure was in adverse media and PEP screening at the beneficial ownership level. The payments themselves did not flag internally because the direct counterparties were clean. The beneficial owners of those counterparties — with documented adverse media exposure across French and Libyan press — were not monitored.
Binance — United States, 2023, $4.3 billion
The Binance settlement with the US Department of Justice, FinCEN, and the Office of Foreign Assets Control in November 2023 totalled $4.3 billion — the largest criminal resolution involving a crypto exchange to date. The failures were threefold: deliberate non-implementation of effective AML controls; processing transactions from users in sanctioned jurisdictions (Iran, North Korea, Cuba, Syria); and failure to file suspicious activity reports on clearly suspicious transaction patterns.
The predicate offences included sanctions evasion and drug trafficking proceeds. The monitoring failure was not a false negative edge case — it was a systematic policy decision not to implement controls. The enforcement message for CASPs operating in good faith is that the bar is high: "we did not know" is not a defence when a functioning monitoring system would have surfaced the typologies.
Harmonised Minimum Rules — What Actually Changed from 5AMLD
6AMLD's harmonisation of predicate offences resolved the inconsistency where a transaction that triggered SAR obligations in Germany might not in Bulgaria. The practical differences from the AMLD5 framework:
| Obligation | AMLD5 (2018/843) | 6AMLD / AML Reg 2024/1624 |
|---|---|---|
| Predicate offences | ~11, member-state discretion on others | 22, harmonised floor across all member states |
| Corporate criminal liability | Administrative sanction only | Criminal conviction of the legal entity, up to 5% global turnover |
| Extraterritorial jurisdiction | Limited | Extended — applies to offences committed outside EU if proceeds processed within EU |
| Correspondent banking due diligence | Enhanced CDD provisions | Strengthened, with explicit monitoring obligations for high-risk relationships |
| VASP transaction monitoring | Guidance-level | Hard obligation under AML Reg 2024/1624 Art. 7 |
The extraterritorial extension is underappreciated. If a CASP processes proceeds of ransomware originating in a non-EU jurisdiction, the EU criminal liability framework applies because the processing occurs within the EU financial system. Your monitoring system cannot assume that offshore origination removes EU exposure.
The Transaction Monitoring Obligation in Detail
Article 7 of the AML Regulation 2024/1624 operationalises 6AMLD's monitoring obligations into four concrete requirements:
**1. Risk-based approach with documented typology matrix.** You must maintain a written record of which transaction patterns your system monitors for and why each maps to a predicate offence or AML typology. A system that simply has threshold alerts without documented typology rationale is not compliant — even if it catches everything.
**2. Audit trail per transaction.** Every transaction that passes through your monitoring system must have a timestamped record of: the monitoring run date, the rules applied, the outcome (pass, flag, escalate), and — if flagged — the analyst disposition. This is not optional for high-value transactions; it applies to all transactions within scope.
**3. Escalation procedures to MLRO.** Transactions that exceed your escalation threshold must have a documented path to the Money Laundering Reporting Officer. The escalation must be logged with timestamps. If your MLRO decision is "no SAR required", that decision must also be documented with rationale.
- **Real-time monitoring** is required for high-risk counterparty transfers and correspondent banking flows. A transfer cannot be completed before monitoring is run.
- **Batch monitoring** is acceptable for lower-risk, lower-velocity transaction sets — typically daily or intra-day batch jobs across CSV exports.
- **Periodic review** covers account-level monitoring (e.g. monthly review of dormant accounts that suddenly activate).
CASPs processing on-chain transfers are expected to run real-time or near-real-time checks for wallet address sanctions screening. Batch AML typology detection across transaction sets is acceptable for internal analytics and retrospective pattern analysis, but cannot substitute for pre-transfer screening of individual high-risk counterparties.
How Arkē's Monitoring + Reporting Satisfies the Obligations
Arkē's three pillars map directly to the AML Regulation 2024/1624 monitoring and reporting obligations:
| 6AMLD / AML Reg Obligation | Arkē Feature | Notes |
|---|---|---|
| AML typology detection (Art. 7 AML Reg) | /api/monitor — batch CSV/JSON typology detection | Returns typology flags, risk indicators, and suspicious pattern summary per transaction set |
| SAR drafting in FIU format (Art. 50 AML Reg) | /api/reporting — AMLD6 FIU-format draft generation | Structured output maps to national FIU portal fields; includes predicate offence classification |
| Counterparty screening pre-transfer (Art. 15 AML Reg — customer due diligence) | /api/screen — OFAC SDN + PEP + adverse media in under 5 seconds | Evidence trail for CDD documentation requirement; timestamped risk score |
| Predicate offence indicator detection | Adverse media AI enrichment (GPT-4o-mini) | Surfaces ransomware, fraud, bribery, and corruption mentions from global news sources |
| Audit trail per transaction | screening_results table — timestamped, exportable | Risk level, flags, and recommendation stored per screen; searchable by counterparty name |
The monitoring pillar (/api/monitor) accepts batched transaction data in CSV or JSON format and returns AML typology flags — structuring, layering, round-tripping, smurfing, rapid conversion — mapped against the 22 predicate offence categories. The output is designed to feed directly into your MLRO escalation workflow: each flagged transaction includes the typology triggered, the confidence signal, and the predicate offence mapping.
The reporting pillar (/api/reporting) generates SAR drafts in AMLD6 FIU format. The structured output includes the mandatory fields required by Art. 50 of the AML Regulation: subject identity, transaction amounts, suspicion narrative, and predicate offence classification. The draft reduces the time from monitoring alert to SAR submission — the bottleneck in most compliance teams' workflows.
The screening pillar (/api/screen) closes the pre-transfer CDD loop. Before a transfer is initiated to a counterparty, a screen against 19,049 OFAC SDN entries plus AI-enriched PEP and adverse media checks produces a risk score 0–100 in under 5 seconds. The timestamped screening_results record is your documented evidence that CDD was conducted.
What Your Engineering Team Needs to Build
Arkē covers the detection and reporting layer. Your engineering team owns the infrastructure around it. A defensible 6AMLD monitoring programme requires:
**1. Typology matrix as versioned JSON.** Store your monitoring rules as a versioned configuration file with source citations (FATF typology reports, FIU guidance, AMLA technical standards). When a regulator asks "why did you flag this transaction?", your answer must reference the typology matrix version and the regulatory source.
**2. IVMS101 Travel Rule fields on all CASP-to-CASP transfers.** The AML Regulation drops the €0 threshold for crypto transfers. Every outbound transfer must carry IVMS101 originator and beneficiary data. Retrofit this now if you haven't — it is a material engineering change for platforms that assumed the old €1,000 floor.
**3. Pre-transfer screening gate.** For counterparties in high-risk jurisdictions or above your internal risk threshold, the transfer must be blocked pending a screening result. This requires an asynchronous screening call integrated into your transaction initiation flow, not a post-hoc batch job.
**4. SAR draft trigger on threshold breach.** When a transaction or account-level flag exceeds your escalation threshold, the system should auto-generate an SAR draft and route it to the MLRO queue. Manual SAR drafting at scale is not viable — and regulators increasingly expect automated escalation with documented disposition.
**5. Five-year retention of all monitoring outputs.** The AML Regulation requires a 5-year retention period for transaction monitoring records, SAR drafts, and CDD documentation. This includes the audit trail records — screening timestamps, monitoring run results, analyst dispositions. Architect your data layer for this from the start.
**6. MLRO escalation workflow with timestamps.** Your compliance system must log the timestamp at which a flagged transaction was escalated to the MLRO, the MLRO's decision, and the rationale if no SAR was filed. The absence of this audit trail is itself a compliance failure — even if the underlying monitoring caught everything correctly.
CTA
Arkē's transaction monitoring and SAR reporting pillars are built for the 6AMLD/AML Regulation era. [See how the pillars work →](/features)
*This post covers the transaction monitoring and SAR reporting engineering obligations under 6AMLD and the AML Regulation 2024/1624. For the legal framework — predicate offences, corporate liability, UBO rules, and Travel Rule changes — see our companion post [AMLD6 for Fintechs: What Actually Changes in 2026](/blog/amld6-for-fintechs-what-changes). Nothing in this post constitutes legal advice. Consult a qualified AML compliance specialist for your specific situation.*