BCBS 239 + DORA + AMLA: one evidence pack, three regulators.

Most banks treat BCBS 239 (risk-data aggregation), DORA (operational resilience) and AMLA (AML supervision) as three separate compliance programmes. They share roughly 70% of the artefact base. Here's the mapping table — and why running them as one programme cuts evidence-pack labour 60%.

Three regulators, one bank, one bill

A tier-1 EU bank in 2026 is preparing for three overlapping regulatory regimes that demand essentially the same artefact set, presented in three slightly different formats, to three different authorities, on three different cadences.

The three regimes:

1. BCBS 239 — the Basel Committee's Principles for effective risk data aggregation and risk reporting. In force since 2016 for G-SIBs, gradually extended to D-SIBs across EU member states. Supervised by the bank's national competent authority (BaFin, ACPR, ČNB etc.) and by the ECB SSM for significant institutions.

2. DORA — Digital Operational Resilience Act (Regulation (EU) 2022/2554). Enforced from 17 January 2025. Supervised by the same national competent authorities plus the European Banking Authority for cross-border concentration risk.

3. AMLA — the Anti-Money Laundering Authority established by Regulation (EU) 2024/1620, with direct supervision powers over selected obliged entities from 2025 and the full operational regime from 2028. The bank's existing FIU relationships continue but with AMLA on top for high-risk entities.

Most banks treat these as three separate compliance programmes, with three separate teams, three separate evidence pipelines and three separate audit cycles. After spending 18 months mapping the actual artefacts each regulator wants, we have concluded that this is needlessly expensive. The three regimes overlap on roughly 70% of the underlying artefact base. Treating them as one programme — same data lineage, same decision journal, same incident taxonomy, different formatting layers for output — cuts the bank's evidence-pack labour by approximately 60% per cycle.

This essay is the mapping table, why the overlap exists, and what the bank's compliance org chart should look like to capture it.

What each regime actually demands

BCBS 239 — the risk data aggregation regime

BCBS 239 has 14 principles across four pillars. The compliance burden on the bank is concentrated in pillars 2 (data aggregation capabilities) and 3 (risk reporting practices).

The artefacts a BCBS 239 audit consumes:

• Data lineage for every risk metric the bank reports. Where did the number come from? What systems contributed? What transformations happened between source and report?
• Data quality controls at each transformation step. Validation rules, reconciliation procedures, error-correction paths.
• Aggregation capability test — can the bank produce risk reports under stress conditions and unusual scenarios (off-cycle, complete-portfolio, hypothetical-portfolio)?
• Frequency and accuracy of risk reports.
• Distribution and ownership of risk reports.

In practice, BCBS 239 audits focus on the lineage. The auditor asks "where did this number on this report come from?" and the bank has to trace it through every system, every transformation, every aggregation step, with timestamps, owner names and validation evidence.

DORA — the operational resilience regime

DORA has eight Title chapters but the operational burden concentrates in Title II (ICT risk management framework), Title III (ICT-related incident management), and Title V (managing third-party risk).

The artefacts a DORA review consumes:

• ICT risk register — every ICT system the bank operates, with criticality classification, risk score, owner.
• Incident register and reporting — taxonomy of ICT incidents, classification of each, root-cause analysis, timeline of detection-containment-restoration, regulator-notification record.
• Decision journal — for material ICT decisions, who decided what, when, with what input, replayable.
• Third-party register — every ICT third party, with concentration analysis, exit plan, contractual evidence (see DORA Art. 28 evidence pack).
• TLPT — threat-led penetration testing, scope document, results.
• Business continuity — RTO/RPO per critical service, dry-run results.

DORA audits focus on the incident-and-decision trail. The auditor asks "show me the chain of decisions and incidents over the last quarter, and how each one was classified, owned and reported."

AMLA — the anti-money laundering supervision regime

AMLA, when fully operational from 2028, will directly supervise selected high-risk obliged entities. In the interim, AMLA defines harmonised standards that national FIUs are expected to apply.

The artefacts AMLA reviews consume:

• Customer due diligence files — per customer, with risk classification, periodic review evidence.
• Transaction-monitoring rule library — rules, hit rates, tuning history.
• Suspicious activity reports (SARs) — submissions, supporting evidence, FIU correspondence.
• Beneficial-ownership data — UBO chains for corporate customers, source documents.
• Sanctions screening records — every screen, hit, disposition.
• AML programme governance — policy, ownership, training records, internal audit findings.

AMLA reviews focus on the customer- and transaction-level evidence trail. The auditor asks "show me your AML decisions on these 50 randomly chosen customers, and the case files behind every SAR you filed in the last year."

Where they overlap — the 70%

Three observations from working through real audit asks across all three regimes.

Observation 1: Data lineage is required by all three.

BCBS 239 demands lineage on risk metrics. DORA demands lineage on incident-related and decision-related data. AMLA demands lineage on customer due diligence and transaction monitoring inputs.

If the bank's lineage infrastructure can answer "where did this number come from", it answers the question for all three regimes. The bank does not need three separate lineage systems. It needs one good one.

Observation 2: Decision journal is required by two of three (and useful for the third).

DORA Art. 5 requires a decision journal for material ICT decisions. AMLA reviews look for the bank's decision trail on SAR filings and risk-rating changes. BCBS 239 does not explicitly require a journal, but auditors increasingly ask for the rationale behind material risk-metric changes (e.g., changing the methodology on operational-risk capital).

A single replayable decision journal — capturing who decided what, when, with what input — satisfies the DORA requirement, supports the AMLA review, and answers the BCBS 239 auditor's increasing methodological questions.

Observation 3: Incident taxonomy is shared by all three.

DORA's incident classification (Art. 19) is the most explicit, with a defined taxonomy: severity, root cause, impact category, etc. BCBS 239 incidents (data quality breakages, reporting failures) overlap with the DORA "data integrity" category. AMLA-relevant incidents (sanctions screening failure, missed SAR filing, KYC tier escalation gone wrong) overlap with the DORA "compliance failure" category.

A bank running a single incident-classification taxonomy across all three regimes will produce slightly more detailed DORA reports (because the categorisation is more granular than DORA strictly requires) but will fully cover AMLA-side and BCBS 239-side incident review.

The 30% that does NOT overlap

Three things stay distinctive per regime:

BCBS 239-specific: aggregation-capability testing. The on-demand-stress-test ability to produce hypothetical-portfolio risk reports is unique to BCBS 239. The bank still needs the aggregation engine and the testing protocol.

DORA-specific: third-party concentration analysis (DORA Art. 29). The portfolio-level concentration on ICT vendors is unique. The bank still needs the per-vendor analysis and the concentration metric.

AMLA-specific: SAR filings and FIU correspondence. The submission-and-response trail with the national FIU (and AMLA from 2028) is unique. The bank still needs the SAR workflow and the historical filings archive.

Even within the 30%, two of the three (DORA-third-party and AMLA-SAR) can be partially decomposed onto the shared data lineage and decision journal infrastructure. So the operational overlap is closer to 80% if the bank invests well.

The mapping table

Below is the working mapping we use with banks during a Wave-1 or Wave-2 engagement. The format: artefact, BCBS 239 reference, DORA reference, AMLA reference, where Coreal generates it.

The "Coreal source" column matters because it tells the bank's compliance team where to look. If Coreal generates the lineage automatically as a byproduct of operation, the bank does not have to maintain a parallel lineage tool. The decision journal is single-source-of-truth across all three regimes.

The bank's compliance org, simplified

Most tier-1 banks today have three separate teams: a BCBS 239 / risk-data team (often inside Finance or Risk), a DORA / operational-resilience team (often inside IT-Risk or Operational Risk), and an AML team (inside Compliance). Each team has its own director, its own evidence-pipeline team, its own audit interaction cadence.

The unified-evidence-pack pattern lets the bank restructure:

Unified Layer 1: shared evidence infrastructure. A single team (4–6 people) owns the decision journal, lineage engine, incident classification taxonomy, and the audit-export tooling. This team serves all three regimes.

Specialised Layer 2: regime-specific judgement. A small team per regime (3–5 people each) owns the regime-specific interpretation, the regulator relationships, and the unique 20–30% of artefacts.

Bank Layer 3: senior governance. The CCO, CRO, and Head of Internal Audit oversee all three layers.

The headcount saving relative to fully siloed teams is approximately 8–12 FTE for a tier-1 bank with all three regimes in scope. Some of that headcount becomes specialised expertise rather than reduction — but the duplicate-work elimination is real.

What this looks like in a Coreal engagement

For a bank we work with, the unified evidence pack starts in Wave-1.

Wave-1 (90 days): the decision journal is live for KYC orchestration. The bank's compliance team is given the journal schema and the audit-export tooling. By end of Wave-1, the bank can produce DORA-style ICT decision evidence for its KYC pipeline (covering customer-onboarding decisions, sanctions-screening dispositions, manual-review case decisions). The AMLA-side coverage starts immediately because the customer due diligence and sanctions screening are journaled in the same place.

Wave-2 (months 4–12): as new products ship on Coreal ledger (card-to-card field note), the lineage automatically extends to those products. The bank's BCBS 239 risk-data aggregation team now has lineage on the new transactional volume too. The same incident taxonomy applies.

Wave-3 (months 12–36): as Coreal-handled volume grows to majority, the bank's unified evidence pack is generating roughly 70% of the regulator-facing artefacts for all three regimes. The remaining 30% (legacy core-side data, on-prem operational risk, paper-based historical records) still exists and still requires manual work, but on a shrinking footprint.

By month 24, banks we have worked with report that their internal audit cycle for the three regimes takes 40–50% less elapsed time than the prior year, with smaller specialised teams plus a shared infrastructure team.

The strategic point

The compliance org of a tier-1 EU bank in 2026 was structured around regimes that arrived sequentially over a decade. BCBS 239 came first (2013–2016). Then GDPR (2018). Then DORA (2022, enforced 2025). Then AMLA (2024, fully operational 2028). Each one was framed at the time as a separate problem with a separate solution.

In retrospect, they are not separate. They are all asking the same underlying questions in slightly different framings: where did this number come from, what decisions led to it, what incidents affected it, who is accountable.

A bank that runs a unified-evidence-pack infrastructure — decision journal, lineage engine, incident taxonomy, shared audit-export tooling — answers all those questions for all three regimes from one source. The bank that runs separate infrastructure per regime is paying three times for what is structurally one job.

We help banks consolidate this in Wave-1 and Wave-2. The unified pack is one of the byproducts of the Coreal architecture, not a separately purchased tool. It comes with the engagement.

Engagement-side note: BCBS 239 supervisory expectations vary by member state. AMLA RTS and ITS are still being finalised as of 2026. Treat the mapping above as our practical baseline; check it against your competent authority's published guidance. For a unified-evidence-pack design scoped to your specific bank, book a working session →. For the architectural foundation, see solutions for banks.