The Regulator Pack — a defensible case file
The Regulator Pack is a single, sealed dossier that lets an MLRO hand a supervisor or an auditor a complete, tamper-evident, reconstructable-years-later account of one onboarding decision — and prove that nothing in it was altered after the fact. Atlas can already produce a compliance report; the pack is the step that turns that report into an artifact a regulator can trust and an examiner can verify offline.
Every capability on this page is planned, not shipped. It describes the target design Atlas builds toward. Each capability links to its tracking issue under the Regulator case-pack readiness epic (8 capabilities, #735–#742).
Engineering and product documentation, not legal advice or a certification claim. Article references are to the 2024 EU AML package; the AMLR ((EU) 2024/1624) applies from 10 July 2027. Your compliance team owns the mapping to the finally-adopted requirements.
In one line
Atlas can write the report. It cannot yet seal it — bind it into one dossier, hash it so tampering is detectable, attach an immutable record of who decided what and when, and stamp it for retention. And half the gap is not a missing feature: the report must be honest enough to seal first, because sealing an unverified "clear" gives a wrong answer the authority of a tamper-proof record.
Why — the MLRO's problem
An EU MLRO is personally accountable. On a supervisor's request, or years after a decision, they must be able to reconstruct exactly what was known, what was checked, what was found, who decided, and on what basis — and to demonstrate that the file has not been edited since. Today an Atlas dossier is a set of loose PDFs with no seal, no manifest, and no immutable decision record; an examiner cannot verify offline that the file in their hands is the file that was produced.
The obligation is not abstract — it is written into the regime the platform serves:
- Reconstructability and demonstrability. AMLR Art. 21–22 require an obliged entity to demonstrate to supervisors that its measures are appropriate; Art. 77 requires CDD records and the basis of decisions to be retained for five years. The unit of that retention is a coherent case file, not scattered exports.
- Supervision. Selected obliged entities fall under direct AMLA supervision ((EU) 2024/1620); supervisory review presumes a reconstructable, tamper-evident file exists.
- Automated-decision accountability. A declined onboarding is an automated decision with legal or similarly significant effect, engaging GDPR Art. 22 (meaningful human involvement and contestability) and Art. 30 (records of processing). The decision trail and the human sign-off are that evidence.
Atlas's governing principle is that a false "clear" is worse than no answer. The pack extends it: a sealed false clear is worse still, because the seal vouches for it. Honesty is therefore a prerequisite of sealing, not a parallel task.
What — the pack
The pack is one archive that binds every artifact behind a decision, under a cryptographic manifest and an explicit retention stamp. It carries the honest gaps forward — a check that did not run is recorded as not assessed, never quietly dropped.
It rests on three guarantees:
- Tamper-evidence. Every member is sealed with a SHA-256 digest, and a single pack-level hash over those digests detects any change — add, drop, reorder, or a single flipped bit.
- Fail-closed honesty. "Not assessed", coverage gaps, and screening shortfalls are stated explicitly on the face of the dossier. A load error is never rendered as a clean, empty result.
- Accountable retention. The pack is stamped for the AMLR five-year retention class, and its export is itself recorded — who took the file, when, and its hash.
How — the mechanics
None of this is novel research; it is a set of well-established compliance-tooling patterns Atlas adopts.
- Bound dossier + manifest. Assemble the members into one archive; record each member's hash and
size in a
manifest.json, plus a Merkle-style root hash over the member digests. An examiner re-hashes the files offline and compares — integrity is genuinely verifiable, not decorative. - Immutable decision trail. Every risk-tier change, override, and onboarding decision is written to an append-only event log that even a privileged account cannot edit or delete, so the "who decided, and on what basis" is reconstructable long after the working state has aged out.
- Four-eyes on high-risk decisions. A high-risk or EDD approval requires a distinct second approver, recorded before any side effect — the strongest evidence of the human involvement GDPR Art. 22 requires.
- Source-provenance verification state. Each material claim carries its sources, collection time, and a three-state verdict — confirmed / requires re-confirmation / not verified — built from the platform's existing source-trust layer, so the file never presents an unverified claim as settled fact.
- Retention lock. The dossier is stamped
AMLR-5yr, protected from premature deletion, and its export is anchored on the immutable trail.
Honesty is sequenced first
The pack's guarantee is only as strong as the file it seals. So the report-integrity work — making sure a verdict is never synthesised, a "clear" never stands in for a check that did not run, and a persistence failure is never reported as success — is sequenced ahead of the sealing machinery. Those fixes are tracked under the platform audit epic #436; the pack builds on top of them.
The MLRO viewpoint
For the officer who signs, the pack changes the review from "do I trust this PDF?" to a short, mostly mechanical set of confirmations — so their judgement is spent where it belongs, on the file's substance rather than its plumbing.
A pre-seal review separates what the system guarantees from what the human must still judge:
| Check | Enforced by | The officer still confirms |
|---|---|---|
| One case reference across every member | System (single source) | It reflects the final investigation run, not a stale one |
| Risk verdict and recommendation agree | System (one verdict source) | The rating names the real determinative finding |
| Integrity: per-file + pack hash re-verified on assembly | System | The pack_hash matches the export record they hold |
| Tipping-off: neutral customer-facing wording | System (vocabulary gate) | The letter as a whole discloses nothing about suspicion |
| Decision attribution + four-eyes | System (immutable trail) | The approver is a real human in the MLRO role |
| Honest gaps stated, not omitted | System (fail-closed) | Any corroborated finding the system missed is added |
That division — code guarantees the mechanics, the MLRO owns the judgement — is exactly what an examiner expects to see, and it is what makes the sign-off defensible.
Regulatory basis
| Instrument | Provisions | What the pack discharges |
|---|---|---|
| AMLR (EU) 2024/1624 | Art. 20 (CDD), 22 (identify/verify + LEI), 26 (ongoing monitoring), 34 (EDD), 69 (report suspicion to the FIU), 73 (prohibition of disclosure / tipping-off), 77 (5-year retention of records and the basis of decisions) | The evidenced CDD file, the retention unit, and the tipping-off boundary on customer-facing output |
| AMLA Reg. (EU) 2024/1620 | Direct supervision of selected obliged entities | A reconstructable file a supervisor can request and verify |
| GDPR (EU) 2016/679 | Art. 5(2) accountability · 22 automated decisions · 30 records of processing · 5(1)(e) storage limitation | Human involvement in the decision, and the record of it |
| FATF Recommendations | 10 (CDD) · 11 (5-yr record-keeping) · 20 (report suspicion) · 21 (tipping-off) | The global-standard baseline the EU regime implements |
The case for the pack does not rest on the AI Act. AML and fraud-detection systems are not automatically high-risk — Recital 58 of Regulation (EU) 2024/1689 excludes them from Annex III. The obligations above (AMLR demonstrability and retention, GDPR Art. 22, AMLA supervision) compel a tamper-evident, human-attributed, reconstructable file on their own. Art. 12 (logging) and Art. 14 (human oversight) would apply only if a future deployment were classified high-risk — so building the trail now is cheap insurance, not a dependency.
Roadmap
Eight capabilities, sequenced behind the report-honesty prerequisites. Status marks whether Atlas extends an existing pattern (🟡) or builds net-new (🔴).
| Capability | Status | Tracking |
|---|---|---|
| Bound case-pack export — one archive + SHA-256 manifest + integrity self-check | 🔴 Planned — net-new | #735 |
| Immutable, case-level decision audit trail (who / when / why), DB-enforced | 🟡 Planned — extend | #736 |
| Export-accountability event — actor + pack hash on the immutable trail | 🔴 Planned — net-new | #737 |
| Four-eyes / maker-checker on high-risk onboarding decisions | 🔴 Planned — net-new | #738 |
| Source-provenance appendix with three-state verification | 🟡 Planned — extend (source-trust layer) | #739 |
| SAR-first / tipping-off gate before any customer-facing outreach | 🔴 Planned — net-new | #740 |
| Retention lifecycle — AMLR-5yr class, protected deletion, legal hold | 🔴 Planned — net-new | #741 |
| Shared case contract feeding the pack (the assembly seam) | 🟡 Planned — extend | #742 |
The gating decision is the last one: agree a single case contract the pack assembles from, so the sealed dossier has exactly one authoritative narrative per entity.
How this relates to the rest of the roadmap
The Regulator Pack is the defensible-output counterpart to the AMLA ongoing-monitoring work: ongoing monitoring keeps the file current, the pack makes the file defensible. Both sit on the EBA / AMLR foundation, and both depend on the report-integrity fixes in the platform audit (epic #436) landing first — because a current, sealed file is only worth as much as the honesty of what it records.