AMLD6 — what compliance officers need from their tech stack

AMLD6 (the Sixth EU Anti-Money Laundering Directive) is the EU's most comprehensive AML framework to date. It harmonizes the definition of money-laundering offenses across all 27 EU member states, expands predicate offenses to 22 categories, introduces corporate liability for AML failures, and — most significantly for compliance officers — creates personal criminal liability in certain scenarios.

This page covers what AMLD6 requires, who it applies to, the personal liability provisions that compliance officers most commonly ask about, and how orchestration-layer evidence infrastructure supports AMLD6 compliance.

What AMLD6 changes

Key shifts compared to AMLD5:

• Harmonized offense definitions — the same conduct is a money-laundering offense across every EU member state, ending jurisdictional arbitrage.
• Expanded predicate offenses — 22 categories now, including cybercrime, environmental crime, and tax offenses.
• Corporate criminal liability — legal entities (not just individuals) can be held criminally liable for AML failures.
• Extended "aiding and abetting" — broader personal liability for individuals who facilitate money laundering, including through omission or failure of controls.
• Stronger sanctions — minimum four-year maximum prison term for money-laundering offenses across all member states.

Personal liability for compliance officers

The provision that generates the most concern: under AMLD6's expanded aiding-and-abetting framework, compliance officers and other responsible individuals can face personal criminal liability when AML controls fail in ways that facilitate money laundering — particularly where the failure stems from knowing omission, reckless disregard, or documented gaps in the control environment.

This is not a theoretical risk. Multiple EU member states have begun prosecutions under the implementing national legislation. The practical implication for Chief Compliance Officers and MLROs: the quality of your audit trail and control evidence is now personally relevant, not just organizationally relevant.

Two capabilities in particular become load-bearing:

• Demonstrable real-time decisioning — evidence that compliance decisions were made at the time of the transaction, not retrospectively.
• Tamper-evident audit trails — cryptographic assurance that decision records have not been altered after the fact.

Who AMLD6 applies to

AMLD6 applies to "obliged entities" across the EU financial services sector: banks, payment institutions, e-money institutions, investment firms, crypto-asset service providers (CASPs), insurance intermediaries, and designated non-financial businesses. It also reaches entities outside the EU when they provide services to EU customers.

For fintechs and BaaS platforms operating in or into the EU, AMLD6 typically flows through your banking partners — whose obligations cascade to you contractually.

Effective dates

AMLD6 (Directive 2018/1673) had to be transposed into national law by all EU member states by June 2021. Most member states have done so; enforcement activity has ramped up since 2023. The parallel EU AML package — including the AMLR regulation and the AMLA (EU AML Authority) — further tightens the framework with direct-effect obligations and a central EU supervisor.

What an AMLD6-ready evidence posture looks like

To defend a control environment under AMLD6, you need to demonstrate — on demand — that every AML-relevant decision was:

• Made at the appropriate time (real-time or near-real-time for onboarding and transaction decisions)
• Based on the rules in force at that time (versioned rule state, not current rule state)
• Logged with the specific data that informed the decision
• Stored in a form that cannot be retrospectively altered
• Queryable by entity, date range, and regulatory framework

This is exactly the capability a fintech orchestration platform produces as a byproduct of execution. Every KYC decision, every KYB verification, every sanctions screening, every transaction monitoring alert — logged to a hash-chained, tamper-evident audit record, tagged with the applicable AML framework metadata, exportable by entity, jurisdiction, and date range.

How FinQub supports AMLD6 compliance

FinQub provides evidence infrastructure — not compliance determination. Specifically:

• Hash-chained audit trails — every vendor call, decision, and data transformation is logged to an append-only record with cryptographic integrity.
• Regulatory framework tagging — each record is tagged with the applicable framework (AMLD5, AMLD6, FinCEN, FINTRAC, etc.) so evidence can be queried by framework at exam time.
• Real-time decisioning — compliance rules evaluated during workflow execution in under 5ms, not in batch review.
• Rule version preservation — the rule state in force at decision time is preserved alongside the decision, supporting "rules in force at that time" evidence requirements.
• Examiner-ready export — complete files for a given entity / date range / framework as a single document.

FinQub does not make compliance determinations. Whether a specific control environment meets AMLD6 requirements remains the responsibility of the obliged entity, its compliance officers, and its regulators. What FinQub provides is the evidence infrastructure required to demonstrate compliance.

Practical next steps for CCOs and MLROs

1. Map every AML-relevant decision your organization makes (onboarding, ongoing monitoring, transaction monitoring, alerts, escalations).
2. For each decision type, identify where the evidence currently lives (vendor dashboards, internal systems, spreadsheets, email).
3. Assess the tamper-evidence posture — can any part of that evidence be retrospectively altered? How would you prove otherwise?
4. Assess the real-time-decisioning posture — is the decision logged at decision time, or reconstructed after?
5. Identify the gap between current state and an AMLD6-ready posture. Typically the highest-leverage change is consolidating decisions onto a platform with built-in evidence infrastructure rather than building audit logging across N separate systems.