From July 10, 2027, the EU Anti-Money Laundering Regulation applies directly across all 27 member states. Unlike the directives before it, the AMLR leaves no room for national interpretation. The same rules, the same Regulatory Technical Standards, and the same enforcement expectations apply everywhere from the same date.
For RegTech vendors, going from directive to regulation has a specific architectural consequence. Directives gave national regulators the possibility to interpret, which meant your product could handle different implementations across jurisdictions by accommodating local variation. A single regulation removes that possibility. Compliance logic that was built around national flexibility may need to be reconsidered.
Most product teams we talk to are not starting from scratch. They have something built and running already. The question is whether that product meets the new technical standards without significant rework. Below are ten questions worth asking now, before a customer or a supervisor asks them first.
Ten questions about your AML stack
1. Can your product produce a complete audit trail for a single customer decision?
The requirement is a single retrievable record showing every step, every data source consulted, and every decision made, from initial onboarding through ongoing monitoring, connected and traceable in sequence. If your screening output and your monitoring output sit in separate systems that do not talk to each other cleanly, that is a gap supervisors will notice.
2. Does your KYC and CDD logic reflect one consistent standard, or has it picked up country-specific variations over the years?
Most AML products built under the directive regime have jurisdiction-specific flows stitched in over time because that is what national implementations required. The AMLR replaces all of that with one standard. If your onboarding logic branches by country in ways that produce different evidence trails for the same type of customer, that inconsistency will be visible under a harmonised framework.
3. Does your product support perpetual KYC, or does it treat onboarding as the main compliance event?
The AMLR requires ongoing monitoring that refreshes customer risk on a schedule and reacts when something changes. If your product was built around onboarding as the primary compliance moment, adding perpetual KYC is not a feature addition. It affects your data model, your processing infrastructure, and how cleanly customer records connect across your platform.
4. Can your transaction monitoring explain why a specific transaction was flagged?
Static, rule-only monitoring is increasingly treated by supervisors as too weak. The AMLR points toward risk-based scoring and AI-assisted detection, with the requirement that outputs are explainable and auditable. A monitoring system that flags transactions without a traceable rationale will face scrutiny, and so will the product behind it.
5. Is your sanctions and PEP screening connected to your onboarding and monitoring, or does it run separately?
The AMLR ties due diligence and sanctions obligations together. Screening that sits in its own silo, disconnected from onboarding and ongoing monitoring, produces the kind of fragmented audit trail that supervisors find difficult to follow. Under the new standard, that disconnection is not a minor gap.
6. Does your data model reflect the AMLR's updated beneficial ownership threshold of 25%?
Under the AMLR, UBO identification moves to 25% or more under the AMLR, with tighter verification requirements attached to it. Your data model and screening logic need to reflect that threshold cleanly. In products built with this flexibility in mind, it is a straightforward update. In products that are not, it is a more significant rework than it appears on paper.
7. Can your product retrieve the data behind a compliance decision five years after it was made?
Five-year retention is an AMLR requirement. Retention is the straightforward part, while retrieval is harder. The question is whether your data architecture makes it possible to pull a complete decision record quickly when a supervisor asks, without manual reconstruction across systems.
8. Does your product generate documentation that supports a defensible risk-based approach, not just the compliance outputs themselves?
The AMLR requires firms to demonstrate a documented risk-based approach to AML, alongside the implementation itself. A product that generates compliant outputs but leaves its customers to document their own methodology separately creates a gap that becomes visible during supervision. The documentation that supports a defensible risk-based approach should come out of the system, not be assembled manually around it.
9. Can your product serve newly obliged entities, or was it built exclusively for traditional financial institutions?
The AMLR expands the scope of obliged entities to include crypto-asset service providers, crowdfunding intermediaries, and traders in high-value goods such as precious metals. If any of your customers fall into these newly obliged categories, your product may need to handle compliance workflows it was never designed for. That is worth knowing before those customers ask.
10. If one of your customers received a supervisory visit tomorrow, could your product produce everything needed without your engineering team getting involved?
This is what all the other questions come down to in practice. AMLR compliance is about having data organised, connected, and retrievable in the way supervisors expect. Without that, every regulatory request becomes an internal engineering project.
Where to start
Before you jump into building anything, make sure you understand where your current stack actually stands:
1. Map your gaps. Work through the ten questions above against your real architecture. Where does the audit trail break between modules? Does your data model reflect the updated UBO threshold? Does your KYC logic still carry jurisdiction-specific variations from the directive era? Product teams usually find gaps they did not expect at this stage.
2. Prioritise by regulatory exposure. Not every gap carries the same weight. Audit trail completeness and data lineage are what supervisors will look at first. Sequence the work by regulatory priority, not engineering convenience.
3. Start the mapping now. Given the 12 to 18-month realistic timeline, the window is critically narrow. With July 2027 less than a year away, teams that begin the diagnostic immediately still have a viable path to compliance.
How much time you actually have
July 10, 2027 is closer than it looks.
AMLA became operational on July 1, 2025 and begins direct supervision of the highest-risk cross-border institutions from 2028. The EU AI Act deadline for high-risk AI systems including AML and fraud detection lands in December 2027, five months after the AMLR. If your product is in scope for both, the engineering work overlaps significantly. Starting now means addressing both in one coherent programme rather than two sequential ones under increasing time pressure.
Dreamix builds and integrates AML systems for RegTech vendors and financial institutions — KYC, screening, monitoring, and FIU reporting — without disrupting what's already live. Want an engineering-led review of your AML stack against AMLR requirements?
