What changes on 10 July 2027

Most compliance teams know the EU rewrote its anti-money laundering framework in 2024. Rather fewer have worked through what it means for the identity data they actually hold, and that is where the work sits. Regulation (EU) 2024/1624 — the Anti-Money Laundering Regulation, or AMLR — applies from 10 July 2027. Just under a year out, it is worth being precise about what changes and what does not.

Why a regulation is different

For three decades, EU anti-money laundering obligations arrived as directives. Each Member State transposed them into national law — the Netherlands into the Wwft, Germany into the Geldwäschegesetz, and so on for all twenty-seven. That produced twenty-seven interpretations with genuine differences in scope and rigour, which is precisely the gap the new package closes.

AMLR sits alongside two other instruments. AMLD6 (Directive (EU) 2024/1640) keeps the things that genuinely belong at national level: beneficial ownership registers, the powers of Financial Intelligence Units, how national supervisors operate. Member States must transpose it by the same date, with certain register-access provisions phased later. And the AMLA Regulation (EU) 2024/1620 created the Anti-Money Laundering Authority in Frankfurt, which has been operational since 1 July 2025 and is expected to begin direct supervision of the highest-risk cross-border entities from 2028.

The practical consequence for anyone building or buying verification infrastructure: a process that satisfies a supervisor in Amsterdam should satisfy one in Lisbon. That is a real simplification. It also means the floor rises everywhere at once, including in jurisdictions where the previous implementation was lenient.

Who is newly in scope

AMLR widens the population of obliged entities. If your organisation was outside the perimeter under the old directives, it is worth re-checking rather than assuming.

Article 22: the identity provisions that matter

For any business that onboards people remotely, Article 22 is the operationally significant text. It sets out what must be collected and, critically, the standard to which it must be verified.

For natural persons, that means name, nationality and address — verified against reliable, independent sources rather than accepted as self-declared. For legal entities, AMLR names the Legal Entity Identifier explicitly: where a customer has an LEI, obliged entities are required to collect it. If your customer records currently hold a free-text company name and a registration number scraped from an onboarding form, that is the gap to close first.

The eIDAS hierarchy for remote verification

Article 22(6)(b) is where AMLR reaches into the EU's digital identity infrastructure. It points to electronic identification means meeting eIDAS requirements at the substantial or high assurance levels, together with relevant qualified trust services. In effect this establishes a preference order:

• Notified eIDs and the EU Digital Identity Wallet at substantial or high assurance — the strongest position, treated as equivalent to face-to-face verification.
• Qualified electronic signatures and qualified attestations of attributes — a legally robust alternative where a national eID is unavailable or poorly adopted.
• Document-based remote onboarding — still permitted, but expected to carry real-time liveness detection, high-quality capture, and a securely retained, time-stamped record of the verification session that a supervisor can inspect after the fact.

Deepfake-assisted document forgery and synthetic identities are exactly the pressure this provision was drafted against, so the liveness and capture-quality expectations are unsurprising. The clause that gets underestimated is the one after them.

Worth tracking separately: the Regulatory Technical Standards on customer due diligence, developed via the European Banking Authority, add granular detail on onboarding controls and identity assurance. Confirm the final adopted text before freezing any implementation decisions, since the detail here is still settling.

The obligation nobody prices in: proving it later

Read that third bullet again, because a second obligation is hiding inside the first. A securely retained, time-stamped record that a supervisor can inspect after the fact is not a description of verification. It is a description of evidence.

A supervisor does not watch your onboarding flow in real time. They arrive afterwards — sometimes years afterwards, often once something has already gone wrong — and ask you to reconstruct one specific decision about one specific customer on one specific date. The question is never is this person verified? It is: what did you check on 4 March 2028, against which source, to what assurance level, and how do you know that is true?

That reconstruction burden sits with you as the obliged entity. It does not transfer to your verification vendor, and it does not end when the customer relationship does — AMLR continues the established requirement to retain customer due diligence records for a defined period running from the end of the relationship, measured in years. Your evidence has to outlive the customer. In practice it often has to outlive the vendor contract too.

Three ways a stored verification result falls short

Most identity platforms retain a verification outcome: a status, a confidence score, perhaps the captured images, sitting in the vendor's own database. That is useful operationally. As evidence it has three specific weaknesses, and each maps onto a question a supervisor is likely to ask.

• It proves the present, not the past. A record showing a customer is verified today says nothing about what was true at the moment you made the decision. Circumstances move: a customer becomes a politically exposed person, a document expires, a sanctions listing lands, an attribute is corrected. The supervisor's question is always about status at decision time, and a current-state lookup cannot answer it.
• It is mutable, and by the wrong party. If a record can be edited — by your staff, by the vendor, by anyone — its evidential weight rests on trusting whoever holds the database. That is precisely the assumption an adversarial process is designed to test.
• It is not portable. If your verification evidence lives inside a vendor dashboard, changing providers puts a live retention obligation at risk. You end up locked in for reasons that have nothing to do with product quality.

None of this is a criticism of verification vendors, who largely sell what they were asked to sell. It is an observation that the market has optimised heavily for performing the check and barely at all for defending it.

Enhanced due diligence becomes a defined trigger, not a judgement call

Under the old regime, when to escalate to enhanced due diligence was substantially a matter of organisational judgement. AMLR tightens this into defined circumstances, including relationships or transactions involving high-risk third countries, politically exposed persons and their close associates, correspondent banking relationships, complex or unusually large transactions without apparent economic purpose, and non-face-to-face relationships that do not meet the eIDAS equivalence standard.

Read that final trigger carefully alongside Article 22. A remote onboarding flow that falls short of the eIDAS standard does not simply fail — it pushes that relationship into enhanced due diligence, with the deeper source-of-funds and source-of-wealth investigation and heightened ongoing monitoring that follows. Weak verification is not just a compliance risk; it is an ongoing operational cost.

Note where the burden lands. Claiming eIDAS equivalence is not the same as demonstrating it. If you cannot produce a record showing which method was used, at which assurance level, on which date, the safe assumption a supervisor makes is the unfavourable one — and a segment you treated as standard due diligence turns out, retrospectively, to have been enhanced due diligence all along.

Beneficial ownership, tightened

AMLR establishes a fully harmonised framework for identifying and disclosing ultimate beneficial owners, replacing the patchwork of national transparency register obligations. The identification framework is more rigorous and the reporting and record-keeping expectations are heavier. Entities with layered or cross-border ownership structures — and non-EU entities operating into the Union — should be reassessing those structures now rather than in 2027.

Two further changes are worth noting in passing. AMLR introduces a Union-wide EUR 10,000 limit on cash payments in commercial transactions. And AMLA is due to issue guidelines, by the application date, on how firms should establish whether a customer holds at least EUR 50 million in financial, investable or real estate assets — the threshold that pulls wealth management relationships into a distinct treatment.

The dates that matter

What to do in the next twelve months

The useful framing is that AMLR does not introduce a new form to file. It raises the standard for the data you already hold and the process you already run. So the preparation is mostly an audit exercise:

• Confirm your perimeter. Check whether any part of the group falls into a newly obliged category — particularly if you touch crypto-assets, crowdfunding or high-value goods.
• Audit your identity data, field by field. Which attributes are verified against an independent source, and which are self-declared? Do you collect LEIs for legal-entity customers that have one?
• Map your verification methods against the eIDAS hierarchy. Identify which customer segments and which countries you can serve via notified eID or the EUDI Wallet, and where you will need a document-based fallback.
• Run a reconstruction drill. Pick a customer onboarded eighteen months ago and try to produce, from your own systems, the full record of what was checked, against what, when, by whom and to what assurance level. Whatever you cannot produce in that exercise is what you will not be able to produce for a supervisor.
• Ask where your evidence physically lives — and what happens to it if you change verification providers before the retention period ends.
• Re-examine your EDD triggers against the now-defined list, and cost the operational load of any segment that will fall into EDD because of a verification shortfall.
• Plan for EUDI Wallet acceptance as an integration project with its own timeline, not as a switch to be flipped in mid-2027.

Where ProntoID fits

ProntoID was built on a principle that AMLR now writes into law across the Union: identity should be verified once, to a high standard, against authoritative documents, and then be re-usable as a signed assertion rather than re-collected in raw form at every touchpoint.

Our architecture holds identity and verification evidence in a layer that is deliberately separate from the platforms and ledgers that consume it. Relying services receive signed tokens carrying specific assertions — that a person is verified, that a name matches, that an age threshold is met — without the underlying document images and personal data spreading across every system that needs an answer. That separation is what makes the evidence trail auditable in one place, and it is the same design that data minimisation obligations reward.

The component built specifically for the problem described earlier is the attestation receipt. Every check produces a sealed artifact designed to answer a supervisor's questions years later, without requiring anyone to take our word for anything.

Each of the three weaknesses above is addressed directly:

• Point-in-time proof rather than current state. Credential status changes are recorded as append-only events, and a cryptographic root is computed across the full status set at fixed intervals and timestamped. Every receipt embeds the status as it stood at the moment of the check, with a proof that can be verified independently. When a customer becomes a PEP in 2029, you can still demonstrate exactly what was true — and what was knowable — in 2028.
• Immutable to every party, including us. Receipts are written under a compliance-mode retention lock, so neither your staff nor ProntoID can alter or delete one before the retention period expires. The evidential weight does not rest on trusting whoever holds the database, which is the entire point.
• Portable by design. A receipt is a self-contained artifact you hold and can export. Your retention obligation is not hostage to a vendor relationship.

Two further properties matter specifically here. Receipts can carry qualified electronic timestamps issued under eIDAS, which carry a legal presumption of accuracy in EU proceedings — addressing the time-stamped record language in Article 22 directly. And because status changes propagate to the parties who relied on a credential, ongoing monitoring stops being a periodic re-screening job and becomes an event you receive, with a delivery record attached.

The distinction worth leaving you with is a simple one. Nearly every vendor in this market sells you the verification. Rather fewer sell you the thing you will actually be asked for in 2031. Get in touch if you are working through a readiness assessment, or read the attestation layer architecture in full.