What the EU AML Package and eIDAS 2.0 mean for companies expanding beyond Europe

A harmonized European credential tells you nothing about whether your customers in emerging markets will verify.

I’ve spent most of my career on the inside of compliance work, building controls, debating interpretations, and writing the policies nobody reads until something goes wrong.

So I’ll start with a hard truth. Most regulatory commentary comes from one of two places. Either lawyers write it, and they’re thorough on what the text says and necessarily cautious on what to do with it. Or vendors write it, and every rule becomes a reason to buy something. What’s missing is the practitioner’s view: here’s what the rule says, here’s what it will cost you operationally, and here’s where it doesn’t apply to you. That last part matters most. Credibility in this field comes as much from telling people what they can safely ignore as from telling them what to worry about.

That brings me to the EU AML Package and eIDAS 2.0, two of the largest regulatory shifts in identity verification landing in the same window. If your company is headquartered outside Europe, you’ve likely been told that they don’t concern you and, in the same breath, that they change everything.

Both readings are wrong, and they’re wrong in the same way. Each treats this as a question about jurisdiction, when it’s really a question about corporate structure. Below, I break down what it all means.

Two things are happening at once

These two reforms are routinely treated as a single European move on digital identity. They’re worth separating and addressing individually, because the differences between them determine what you actually have to build.

The EU AML Package

Until now, these rules have lived in the Fourth and Fifth Anti-Money Laundering Directives, which every member state has transposed into its own national law and read in its own way. The EU AML Package replaces that patchwork approach with a single, directly applicable rulebook. Its centerpiece is the AML Regulation — AMLR, Regulation (EU) 2024/1624 — which applies from July 10, 2027.

Because it’s a regulation rather than a directive, there’s no national transposition and far less member-state discretion. The same customer due diligence rules bind a payments firm in Tallinn and a bank in Dublin in substantially the same way. Two other pieces sit alongside it: AMLD6, which member states do still transpose, and the new EU Anti-Money Laundering Authority (AMLA). AMLA has been operational in Frankfurt since 2025 and will begin directly supervising a first cohort of the highest-risk cross-border entities in 2028.

Here’s the part most coverage overlooks. AMLR itself is written at a level of generality that does not tell you what to build. The detail lives in AMLA’s technical standards. The draft standards on customer due diligence, made under AMLR Article 28(1), went out for consultation in February 2026 and closed in May 2026, with the final standards due to the European Commission by mid-July 2026. The group-wide and third-country standards, under Articles 16(4) and 17(3), follow by the end of September 2026. Those documents are where a general instruction to verify the customer’s identity turns into a specific list of acceptable sources, a defined minimum data set, and an explicit retention and audit expectation.

That means the event everyone is counting down to is not really the event at all. By the time July 2027 arrives, the decisions that determine what you have to build will already have been made.

eIDAS 2.0

eIDAS 2.0, or Regulation (EU) 2024/1183, is the other half, and it creates the EU Digital Identity Wallet. Every member state must make at least one certified wallet available by December 24, 2026, and regulated sectors — including banks, payment institutions, and e-money firms — must accept it for authentication a year after that.

The design principles are the interesting part: selective disclosure, no central database, and user-controlled release of attributes. In practice, a customer can prove they are over 18, or resident in a given country, without handing you a document image and a full identity record. That’s a sharp break from how verification has worked for the last decade, as you’re no longer building a file on someone but accepting a signed claim about them.

What’s actually changing for identity verification

Put the two together, and the shift becomes clear. Inside Europe, verification will move from inferring identity out of evidence you collect and store to receiving a cryptographically assured assertion you mostly don’t store.

Outside Europe, nothing changes. You’re still collecting documents, matching against authoritative sources, and holding the data.

The same organization will end up running two structurally different identity models built on two opposed data philosophies and will need to be able to explain both to a supervisor. That’s the real consequence of this package for anyone operating across borders, and it’s all but absent from the current commentary.

What you can safely ignore

There are two misconceptions that can do real damage.

The first is the idea that being compliant today means being ready tomorrow. Being compliant with an existing framework tells you nothing about whether you can satisfy a new one, because the new one asks for evidence you may never have had a reason to keep. AMLR raises the standard for how you identify customers and verify beneficial owners and, crucially, how you demonstrate that you did. If you have a fragmented stack, multiple vendors, separate audit logs, and inconsistent data formats, you’ll find the demonstrating harder than the doing.

The second is retro-fix panic, or the belief that every existing customer file has to be re-papered to the new standard by July 10, 2027. That is not the expectation as I read it. Existing files are updated on a risk-based basis in line with your own review cycles — high-risk first, then the rest within applicable timeframes. New customers onboarded after the application date must meet the new standard.

The deadline that matters to you is not 2027. It’s the change cycle you need to start now, while there’s still calibration room with your vendors and your release schedule, rather than under inspection pressure later.

If you’re just getting started, don’t start with the regulation. Start with an honest inventory of where your customer data comes from, who owns each source, and whether you could evidence its provenance to an inspector tomorrow. You can rewrite a policy in two weeks. You can’t rebuild data lineage in two weeks. Misreading the rule is rarely the problem. The firms that struggle in 2027 will be the ones that couldn’t tell you which of their four customer data lists was the correct one.

Three ways these rules reach companies outside Europe

For most companies outside Europe, the honest answer is that EU law mostly doesn’t apply to them directly. But it reaches them anyway. The mechanism is corporate structure (how a group is assembled, and which entity answers for its policies), and it travels through three specific channels.

Group structures

If you’re a branch or subsidiary of an EU-headquartered group, group-wide AML policies must be implemented at your level. AMLA’s draft standards on group-wide requirements are explicit about this, and they even go one step further. Where local law prevents you from applying the group’s policy (because of data protection rules, bank secrecy, or data localization requirements), you do not get an exemption. You get a prescribed set of additional measures to apply and an obligation to notify your home supervisor. If those measures are judged insufficient to manage the risk, the draft standards require you to terminate affected business relationships, cease transactions, or close down operations in that market, and your supervisor can compel a risk mitigation plan.

Contracts that move faster than the law

Long before any regulator looks at a Brazilian or Singaporean firm, its EU bank, EU acquirer, or EU licensing partner will push the AMLR standard down the chain contractually. I watched this same pattern unfold with GDPR and with DORA, and the commercial deadline always lands months before the legal one.

A shifting benchmark for “good” verification

This is the channel I care most about. Once a European flow is a wallet presentation with cryptographic assurance and near-zero friction, that becomes the internal reference point for what “good” identity verification looks like. At that point, a perfectly sound Mexican or Indonesian verification, done properly against authoritative government sources, starts to look deficient by comparison. It’s not. It’s just differently evidenced. That said, I fully expect risk committees to start treating non-wallet markets as higher-risk simply because the assurance is expressed differently, and that’s a failure of the risk-based approach dressed up as rigor.

How a routine licensing decision puts you in scope

A business headquartered outside Europe, with growth markets across Asia and Latin America, expands into Europe the way most firms actually do: by standing up two separately licensed entities in two member states rather than one European holding company. Nobody involved thinks of that as a compliance decision. It is a licensing and speed decision.

Under the draft group-wide standards, that structure is the trigger. Two EU obliged entities and no EU parent means one of them is designated the parent undertaking in the Union and becomes responsible for the group’s AML framework. So, a head office on the other side of the world now has a European subsidiary accountable for how identity verification is done in every market the group operates in.

The obligations stack up from there. The group policy has to be genuinely implemented in markets where local law restricts moving customer data back to the group, which triggers the additional measures regime. The European flow has to become wallet-capable. And a market with excellent authoritative registries but no wallet scheme suddenly looks heavy next to a European flow that returns a signed assertion instantly, even though the verification is sound and arguably harder to defeat.

That’s what makes the exposure concrete. The regulation did not reach across the world to find this company. The company’s own corporate structure pulled the regulation in, and the cost landed on a platform that was never designed for two assurance models at once.

The four design decisions that matter most

I’d treat this whole package as a platform design question, because that’s where the work actually lands. A compliance leader can absorb AMLR by rewriting procedures. A product leader cannot, because AMLR and eIDAS 2.0 together change the shape of the data you hold and how you’re expected to evidence it.

1. Make assurance the contract, not the method.

AMLR Article 22(6)(b) points at eIDAS assurance levels as a basis for remote due diligence, so the regulation has effectively handed you a vocabulary. Use it as your internal model, then map every method onto it: a wallet presentation, a document and biometric check, and an authoritative source match. Your decisioning logic should consume an assurance outcome, never a method name. Otherwise, every new national scheme becomes a re-engineering project instead of a configuration change.

There is a live question about how far this goes. AMLR itself does not rank eIDAS methods above others, which is what most commentary notes and then leaves alone. The draft due diligence standards go further, treating an eIDAS-compliant method as the first resort and video identification as a fallback available only where the eIDAS route is unavailable, unreasonable, or disproportionate. AMLA has held that line through consultation. The operational rule is being set a layer beneath the legislation most people are reading. If you operate in a market with no notified eID scheme, that’s the sentence to watch, because the fallback you rely on today is being narrowed.

So, build the mapping, but don’t assume the routes stay interchangeable. Inside Europe, the eIDAS route is becoming the default, and the others are becoming fallbacks. Outside Europe, where no notified scheme exists, the mapping is the whole exercise.

2. Move from a document-centric model to an attribute-centric one.

Most platforms are built around a document: capture the image, extract the fields, then store the artifact. Selective disclosure breaks that, because a wallet gives you discrete attested attributes with no document behind them. The customer record needs to become a set of attributes, each carrying its own source, assurance level, consent basis, and retention clock. This is the biggest and most underestimated schema change in the package.

3. Treat provenance and retention as fields rather than policy documents.

Supervisors are moving toward asking which source you verified against, not just whether you verified. A match on an aggregated commercial database is not a match against a government record, and many global coverage claims in this market are worth testing against that question. As a result, provenance must be attached to each attribute rather than placed in a log. And retention has to be configurable per attribute and per market, because Europe will push you toward holding an assertion rather than the underlying evidence, while most other markets will still expect the evidence to be retained.

4. Share the conclusion, not the evidence behind it.

Group policy will require information sharing while local law in a number of markets still restricts moving personal data across borders. The way through is local processing, with only derived signals crossing the boundary, including the assurance level, the match outcome, and the fact that a check met a given standard. Retrofitting that into a platform built around a central store is close to impossible, so it needs to be decided now.

Three dates to work back from

Harmonized rules, local realities

Harmonization is not portability. AMLR harmonizes the rulebook, not the data. eIDAS 2.0 harmonizes the credential, not the world.

Europe is about to demonstrate that you can standardize a method beautifully — one CDD rulebook, one wallet standard, and one assurance vocabulary — and still not be able to verify a customer in Jakarta or Bogotá by the same route. A shared global method does not produce a shared global verification, and satisfying your European obligations tells you next to nothing about whether your customers will verify in your next market.

That brings me to the most important takeaway: compliance is a data problem wearing a legal costume.

AMLR tells you what to prove, and AMLA’s standards will tell you what counts as proof. Whether you can prove it depends entirely on what authoritative data exists where your customer lives and who owns it.

That’s not a question you can answer from the regulation. You answer it market by market, source by source.

Learn more

For more on how Data Zoo approaches source vetting, data sovereignty, and audit-ready verification, see Compliance at Data Zoo.

Expanding into a new market and need to know what authoritative data exists there? Talk to our team.