EBA / AMLR compatibility
TrustRelay Atlas is built around the EU Anti-Money-Laundering Regulation (AMLR — Regulation (EU) 2024/1624) and the EBA/AMLA technical standards that sit beneath it. This page explains, pillar by pillar, how the Atlas data model and engines satisfy the AMLR Know-Your-Business (KYB) obligations: customer identification, beneficial-ownership transparency, source verification, sanctions/PEP screening, risk-based customer due diligence, ongoing monitoring, and defensible record-keeping.
This page describes the target AMLR-aligned architecture — the design we build to and verify against. Implementation is tracked under the AMLR Compliance milestone (issues #271–#283). The traceability matrix at the foot of this page maps each capability described here to its tracking issue.
This is engineering and product documentation, not legal advice, and does not assert certification against any regulation. The AMLR applies from 10 July 2027. The detailed Article 28(1) CDD RTS is still in draft (AMLA consultation 2026; final draft to the European Commission expected ~10 July 2026). The structural requirements below are fixed Level-1 law; field-level mandates are intentionally kept in configuration so the final RTS can be absorbed without schema rebuilds. Your compliance team owns the mapping to your jurisdiction's adopted requirements.
Design principles
Five principles, taken straight from the AMLR's intent, shape the whole platform:
- Ownership and control are a directed, weighted graph — not a flat shareholder table. UBOs are computed by traversing the graph, never typed in by hand.
- An asserted value is separated from its verification. One claimed fact (a name, a percentage, a date
of birth) carries many verification records — never a single
verified: trueboolean. - Every node carries provenance and an immutable audit trail. Who said it, which source, when, and what changed.
- Risk classification is derived, never silently overwritten. Overrides are logged exceptions with a mandatory justification, not the norm.
- Field-level mandates live in configuration. The structural backbone is code; the "which fields are required / need verification / qualify for SDD" rules are data, ready for the final RTS.
AMLR obligation → Atlas capability map
| AMLR obligation | Atlas capability | Reference |
|---|---|---|
| Customer identification (Art. 22) | Typed SubjectEntity / NaturalPerson model with the full AMLR attribute set | Identification |
| Beneficial ownership (Art. 51–55) | Directed ownership and control graph; multi-path UBO computation; SMO fallback | Beneficial ownership |
| Verification (Art. 24–28) | 1-to-many VerificationRecord layer; multi-source rules; eIDAS levels | Verification |
| Sanctions / PEP / adverse media (Art. 17) | Screening of every natural person resolved in the graph; protected fields | Screening |
| Risk-based CDD (Art. 20, 33–34) | Derived risk matrix → SDD / standard / EDD pathway with logged overrides | Risk & CDD pathway |
| Ongoing monitoring (Art. 26) | Recurring, timestamped screening; reconciliation raises discrepancies | Monitoring |
| Record-keeping (Art. 56–58) | Append-only AuditEvent log with before/after diffs; reproducible reports | Record-keeping |
1. Customer identification
Atlas models the two AMLR subjects as first-class typed entities, capturing the expanded attribute set the AMLR mandates — not just name and number.
SubjectEntity (the business)
| Attribute | Notes |
|---|---|
legal_name, other_names | Registered name + trading/DBA names |
registration_number + register_name | The number and which register issued it |
incorporation_country, operating_countries | Country of incorporation plus where it operates |
legal_form, incorporation_date, status | active / dissolved / in_liquidation / struck_off / unknown |
registered_address + principal_place_of_business | Captured separately — divergence is a risk signal |
lei, vat_number | LEI used as a graph resolution/dedup key |
nace_codes | First-class industry classification, feeds risk scoring |
is_regulated_entity, listed_on_regulated_market | Drive SDD eligibility / UBO-exemption logic |
NaturalPerson (UBOs, controllers, representatives)
Every AMLR-mandatory attribute is modelled, including the attributes added by the AMLR:
| Attribute | Notes |
|---|---|
full_name, date_of_birth | Verified attributes (see §3) |
place_of_birth | AMLR-new mandatory field |
residential_address, country_of_residence | Verified |
nationalities | Plural — multiple nationalities are common and risk-relevant |
national_id_refs | Array of structured identity documents |
roles | ubo_ownership, ubo_control, smo_fallback, legal_representative, settlor, trustee, protector, beneficiary, founder, governing_body |
pep_status | Tri-state: not_pep / pep / rca (relative or close associate, Art. 17) |
Which of these fields are required and which need verification is resolved from configuration (reference data), per entity type, jurisdiction and risk tier — so the final Art. 28(1) RTS is a config change, not a migration. See Reference data.
2. Beneficial ownership
This is the hardest and most load-bearing engine in the platform. The AMLR defines beneficial ownership through ownership and control, and requires that indirect holdings be aggregated. Atlas treats the entire structure as a directed, weighted graph and computes the UBO set.
Ownership: multiplicative across all paths
For each natural person the engine enumerates every directed path to the subject, multiplies the ownership percentages along each path, and sums the products across all distinct paths. If the aggregate is ≥ the threshold (25% baseline), the person is a UBO via ownership.
Worked example (regression test). In the diagram above, P reaches the subject through two chains, each yielding 15% effective ownership. No single path reaches 25% — but the aggregate is 30%, so P is a UBO. Atlas aggregates across paths, so P is correctly identified. (A naïve "max single path" engine would miss P entirely — this is precisely the failure mode the AMLR aggregation rule exists to prevent.)
Control: a separate dimension
Control is modelled independently of ownership. A person can be a UBO through control with 0% ownership. Typed control edges capture the AMLR control mechanisms:
majority_voting_gt50, appoint_remove_board_majority, veto_rights, control_profit_distribution,
other_dominant_influence — including control exercised through controlled intermediates.
Cycles, fallback, and explainability
- Cross-holdings / cycles are detected during traversal and flagged; the engine never loops infinitely.
- SMO fallback — when no natural person qualifies via ownership or control, the senior managing
official(s) are identified as UBO, recorded with
reason_code = "no_bo_identified". - Explainability — each result stores the contributing paths and the arithmetic, so an analyst (or auditor) can see why a person is a UBO, not just that they are.
- Configurable threshold — 25% baseline, 10% for enhanced scrutiny, resolved per jurisdiction
from reference data. Compliance teams manage these thresholds without code through the Studio
UBO-threshold editor (Studio → Risk Categories → UBO thresholds): a per-country table
(
{default, jurisdictions}) with version management, provenance, and a full audit-log sidebar, so every change to "what level of equity makes someone a UBO here" is governed and traceable.
See Entity resolution → Ownership & UBOs.
3. Verification
The AMLR requires firms to verify CDD information against reliable, independent sources — and to keep the evidence. Atlas separates what was asserted from how it was verified, as a one-to-many relationship.
A VerificationRecord carries the method (public_register_noncentral,
central_register_crosscheck_only, eidas_eid, identity_document, third_party_data, utility_bill,
certified_professional_attestation, credit_institution_info), an eIDAS assurance level
(low / substantial / high) where relevant, the source, the verified value, and who verified it and when.
Two AMLR rules are enforced as configurable gates:
- Central registers are cross-check only. A central Beneficial-Ownership / Transparency Register can corroborate a value but can never be its sole source — at least one non-central source is required.
- Verify-required attributes need ≥ 2 independent verification records before they reach "verified" status.
When records for the same attribute disagree, a Discrepancy is raised with an
open → resolved → escalated → reported lifecycle. An unresolved discrepancy on UBO data blocks
"verified" status and may be reportable. This builds on the platform's existing
claims & survivorship and mutation queue
machinery.
4. Screening & ongoing monitoring
Atlas screens the subject and every natural person resolved in the ownership/control graph — not only the direct UBOs — against sanctions, PEP and adverse-media sources.
Each screen produces a timestamped ScreeningResult (list_type, hit, match_score, screened_at,
target reference). Because screening is recurring and timestamped, the screening history is the
ongoing-monitoring evidence trail required by Art. 26. Sanctions and PEP outcomes are written to
protected fields that incoming provider data cannot
overwrite. New provider data flows through reconciliation; material
changes raise discrepancies and re-trigger risk evaluation.
5. Risk classification & the CDD pathway
Risk is derived by a configurable risk-matrix engine across the EBA risk dimensions (geography, sector, ownership opacity, PEP exposure, product/channel). Evaluations are content-hashed, idempotent and immutable; overrides require a justification and are logged as exceptions.
The derived residual risk drives the CDD pathway:
- SDD — low risk + an eligible category (e.g. a regulated or listed entity): reduced measures.
- Standard — the default.
- EDD — high-risk geography, complex/opaque ownership, or PEP exposure: requires source of funds and source of wealth plus a documented justification.
Validation gates implement the AMLR's hard rules: an incorporation_country on the high-risk third
country list forces the EDD pathway, and a dissolved / struck_off status blocks onboarding
unless an override with a logged justification is recorded. The country and FATF lists are sourced from
reference data, not hard-coded.
6. Record-keeping & audit trail
Every CDD action is written to an append-only, immutable AuditEvent log — created, updated, verified,
screened, risk-recomputed, discrepancy-raised, overridden, reported — each with the actor, timestamp and a
before/after diff for any value change. The log is immutable at the database layer (no UPDATE / DELETE
grants) and tenant-isolated via Row-Level Security.
Combined with the verification and mutation history, this satisfies the Art. 56–58 record-keeping obligation: an audit request becomes a lookup, not an archaeology project. Reports are stored and reproducible from the same provenance.
7. Legal arrangements & relationship purpose
Two AMLR areas extend the model beyond company structures and are delivered on the AMLR roadmap:
- Legal arrangements (trusts & foundations) — modelled role-based rather than percentage-based:
express trusts (
settlor,trustee,protector,beneficiaries, other control) and foundations (founders, governing-body members, other controlling persons). Each role is a fully-attributed, verifiedNaturalPerson. - Purpose & intended nature of the relationship (Art. 15–16) — a structured
PurposeProfile: stated purpose (structured taxonomy, the monitoring baseline), expected activity (volumes, values, geographies, counterparties), and source of funds / source of wealth (verified for standard/high risk and EDD respectively).
See the scope decision for sequencing.
Implementation traceability
Each capability above maps to a tracking issue under the AMLR Compliance milestone:
| Capability | Issue |
|---|---|
| Multi-path UBO aggregation (the worked example) | #271 |
| Control as a separate UBO dimension | #272 |
SMO fallback (no_bo_identified) | #273 |
| VerificationRecord layer + multi-source rules | #274 |
| Discrepancy lifecycle + verified-blocking | #275 |
| CDD pathway (SDD / standard / EDD) | #276 |
| Screening coverage + recurring monitoring | #277 |
| Append-only AuditEvent log | #278 |
| NaturalPerson mandatory attributes | #279 |
| PEP tri-state (RCA) | #280 |
| SubjectEntity attributes | #281 |
| Validation gates (force EDD / dissolved block) | #282 |
| Trusts / foundations + PurposeProfile | #283 |
For the obligation-level summary aimed at compliance teams, see Compliance coverage. For registry and list coverage in TrustRelay's operating markets, see Benelux & Romania.