AMLR deadline 2027: the data infrastructure problem institutions aren't ready for

My guess is that most institutions treating the July 2027 deadline as a compliance project will discover, too late, that it is actually a data infrastructure crisis. The Anti-Money Laundering Regulation ("'AMLR") does not just raise the bar for what you must do. It changes the underlying standard for what you must know – and know consistently, traceably, and in real time. Institutions that have spent years masking customer data gaps through manual review and analyst judgment will find that the AMLR leaves no room for those workarounds. Achieving better processes is the goal – but getting there requires finally addressing the legacy data problem that has been deferred for a decade.

Key takeaways

• Only one-third of EU obliged entities expect to be ready by 10 July 2027. According to PwC’s 2026 EMEA AML Survey, between 14% and 29% of respondents had even completed a detailed impact assessment (PwC, 2026).
• Data quality is the primary barrier to AMLR compliance, not process design. PwC found that data quality was cited as the leading obstacle to scaling technology and AI adoption by 52% to 89% of respondents, depending on sector (PwC, 2026).
• The AMLR is a regulation with no national transposition buffer – and its UBO requirements are the sharpest test of data quality. The same text binds all 27 Member States from 10 July 2027. Ultimate Beneficial Owners (UBOs) must be identified and verified at a 25% or lower ownership threshold, central registers consulted, and discrepancies flagged proactively. That chain of verification breaks instantly when underlying entity data is fragmented or stale.
• Know Your Customer (KYC) remediation is already expensive. Post-AMLR, it gets more so. Large EU banks already spend an average of €5.7 million per year on KYC, with 74% of that on labor (Ondato, 2025). The AMLR’s richer data requirements will expand that cost for every institution that has not structurally addressed its data foundations.
• Clean data is a prerequisite for productivity gains, not a consequence of them. Every automation investment – screening tools, AI-assisted review, risk scoring models – assumes structured, reliable data as input. Institutions that deploy those tools on fragmented data do not gain productivity. They automate their existing errors at scale, and analysts continue spending most of their time chasing information rather than making decisions.
• ACPR enforcement foreshadows AMLA’s approach. 48% of ACPR sanctions issued in 2023 included grievances related to inadequate or outdated customer knowledge – before the new regime even applies (Welance Conseil, 2023).

What is actually changing on 10 July 2027?

The EU AML Package of 2024 introduced three interlocking instruments. They are not interchangeable, and conflating them is one of the most common errors in how institutions plan their response.

The structural shift is the AMLR’s nature as a regulation. For two decades, AML obligations were set by directives, which Member States transposed into national law – introducing interpretive variation that institutions could navigate and, where needed, exploit. The AMLR removes that buffer. From 10 July 2027, a payments institution in Dublin and a bank in Warsaw read the same text and are bound by the same standard.

That standardization has a direct consequence: it eliminates the room to compensate for weak data with local procedural interpretation.

Why is data the real compliance gap?

Compliance teams have been running gap analyses for two years. Most know what the AMLR requires. Far fewer have honestly answered the harder questions: where is the required customer and ownership data actually held? Who owns it internally? Can it be traced, verified, and kept current consistently across entities and jurisdictions?

When those questions are asked, the answer is usually uncomfortable. Customer information is typically spread across multiple systems – Customer Relationship Management (CRM) tools, core banking systems, onboarding forms, and operational spreadsheets.

The deepest part of that failure is often the CRM. Most institutions store their compliance-relevant customer data in a system - Salesforce or a proprietary equivalent – that was designed for commercial interactions, not risk. A CRM organises data around deals, contacts, and revenue stages. We’ve written the full argument in this article: Your CRM is a revenue tool. It is the wrong KYC system.

Compliance requires data organised around risk profiles: ownership chains, verification history, document provenance, event-driven refresh triggers. Presenting a CRM record to a regulator during an inspection is not evidence of due diligence. It is evidence of a system that was never fit for the purpose. Yet for most institutions, the CRM remains the de facto system of record for customer data, including compliance data.

That design choice has a compounding effect. Over the past decade, institutions have responded to each new regulatory requirement by buying a specialist point solution: one tool for PEP identification, one for identity document verification, one for sanctions screening, one for transaction monitoring. Each tool works in isolation. None of them feed a central, coherent picture of the client. Regulators are increasingly sanctioning not just the absence of checks, but the absence of a system capable of connecting those checks into a coherent client view. The fragmentation is structural, and buying another point solution does not fix it.

Specifically, the AMLR requires:

• Identification and verification of UBOs at the 25% threshold (or lower in high-risk sectors), supported by documentary evidence
• Mandatory consultation of central UBO registers maintained under AMLD6, with documented discrepancy reporting where records conflict with internal data
• Ongoing monitoring, periodic refresh, and event-driven reviews – not point-in-time collection
• Records that trace where data came from, when it was verified, and how it informed a compliance decision
• Consistency sufficient for cross-border groups to apply controls and provide evidence to supervisors across multiple jurisdictions

None of that is achievable when customer data lives in disconnected silos.

Why can't KYC be fixed without fixing data first?

KYC is a downstream function. It depends entirely on the quality, completeness, and consistency of the customer data that feeds it. When that data is broken - i.e. contradictory or fragmented across systems, collected once and never refreshed, stored in formats no screening tool can parse - no KYC process, however well-designed, can produce a reliable output. This is a structural problem that institutions have managed around for years through manual effort and recurring remediation campaigns.

If anything, the AMLR is the regulatory pretext that compliance teams have been waiting for. Regulation is one of the few forcing functions capable of getting ExCo approval for infrastructure investments that have been deprioritised for years. And compliance is one of the only functions in the business that carries a regulatory mandate to force convergence on a single, authoritative view of who a client is -- a problem every other function has been unable to solve on its own.

Here is what that looks like in practice:

• No single source of truth means KYC is always an approximation. When customer data lives across a CRM, a core banking system, an onboarding form, and a set of analyst spreadsheets, no one has a complete picture of any client. Reconciliation is manual and slow.
• Remediation campaigns are a confession, not a solution. Every large-scale KYC remediation project is an institution admitting that its data architecture produced records that were never fit for compliance purposes. Cleaning those records fixes a snapshot. It does not fix the system that generated them.
• Automation deployed on bad data makes the problem invisible, not smaller. Alert queues grow, analysts stay busy, dashboards show activity. But the underlying client picture remains incoherent. The productivity gains never arrive because the data precondition for them was never met.

Why does bad data make automation worthless?

This is the argument that matters most for operations and technology leaders.

The assumption built into every automation investment – AI-assisted document review, automated UBO mapping, continuous transaction monitoring, risk-based scoring – is that the underlying customer data is clean, structured, and consistent. Strip that assumption away and the productivity math collapses entirely.

This is not a hypothetical. PwC’s 2026 EMEA AML Survey found data quality cited as the leading barrier to scaling technology and AI adoption by 52% to 89% of respondents depending on sector (PwC, 2026). Those institutions are not failing to adopt technology. They are adopting technology and discovering that it cannot deliver without the data foundation to support it.

The productivity case for fixing data infrastructure is, in many ways, stronger than the compliance case. A compliance gap creates regulatory risk. A data gap creates regulatory risk and permanently caps how much efficiency any technology investment can deliver. Institutions that treat data quality as a compliance hygiene task and not as a strategic infrastructure decision will keep buying tools and keep being disappointed by the results.

Clean data does not follow from better tooling. Better tooling follows from clean data. The sequencing matters, and too many institutions have it backwards.

What does “ready by 2027” actually mean?

A completed gap analysis is not readiness. Neither is a signed contract with a new vendor. Readiness means that your institution can demonstrate, to a supervisor, a coherent and traceable picture of every client’s risk profile – sourced from a single authoritative system, kept current by continuous refresh, and supported by a full audit trail of how every data point was collected and verified.

Most institutions are not there. Only approximately one-third of EU respondents to PwC’s 2026 EMEA AML Survey expected to be compliant by 10 July 2027 – and between 14% and 29% had completed even a detailed impact assessment (PwC, 2026).

The problem is most acute for cross-border groups, where the same customer may be represented differently across multiple national systems, UBO structures documented to varying local standards, and no shared data layer connecting entities. The AMLR’s push toward harmonization assumes a level of internal data consistency that most large institutions have not yet achieved. For those groups, July 2027 is not a compliance deadline, it is a data infrastructure deadline.

What does fixing the data foundation actually require?

The institutions that will be ready in July 2027 share a common characteristic: they have treated customer data as infrastructure, not as a byproduct of compliance workflows.

Practically, this means four things:

1. A unified customer data model – a system of record, not a repository. Customer identity, ownership structures, and associated documents must live in a single authoritative system that all downstream processes – screening, monitoring, reporting – draw from. Not copies, not exports, not a data lake: one source that organises data around risk, not commercial interactions.

2. Structured, machine-readable data from the point of collection. UBO data collected as a PDF attachment saved in a SharePoint is not usable in itself. Data must be structured at ingestion – not retrospectively cleaned in remediation campaigns.

3. Continuous refresh, not periodic review. The AMLR’s event-driven review requirements mean that changes in beneficial ownership, PEP status, or risk profile must trigger automatic updates. That requires synchronizing alert mechanisms, periodic reviews and live connections to external registers to automate workflows.

4. A full audit trail by design. Every data point must carry provenance: where it came from, when it was verified, by what means, and how it informed a compliance decision. This is not a reporting feature to be added later. It must be baked into how data is stored from the start.

How does Ondorse approach this?

The institutions Ondorse works with often arrive with a version of the same problem: they have run a remediation program, bought a screening tool, and improved their Know Your Customer ("KYC") workflows – and they are still drowning into manual work.

Ondorse’s approach starts with the data layer, not the workflow. Rather than becoming another point solution stacked on top of a fragmented architecture, Ondorse acts as the system of record for KYC compliance : the central hub that replaces the CRM as the authoritative source of compliance data. The distinction is not semantic. A system of record organises data around risk: every client has reviews (onboarding, periodic review, event-driven reviews) and a dynamic risk profile built from the coherent combination of signals. It also connects to and consolidates the point solutions an institution has already deployed, so PEP, sanctions and negative checks, ID. verification feed a single, unified client record instead of living in separate silos.

Once that system of record is in place, a second shift becomes possible: AI automation that actually delivers. The institutions currently deploying AI-assisted document review, automated risk scoring, or agentic onboarding workflows – and being disappointed by the results – are not suffering from poor AI. They are suffering from poor data and missing underlying infrastructure. AI models need context to act reliably: a coherent, structured, up-to-date client profile that connects documents, ownership data, screening results, and transaction history into a single view. That context is exactly what a compliance system of record provides. Fix the data foundation, and the automation investments already made start to work. The productivity gains that were promised – faster onboarding, less manual work, lower analyst cost per file – become achievable, because the precondition for them has finally been met.

For institutions beginning to map their AMLR gap, the first question to answer is not which workflow tool to buy. It is whether your customer data architecture can support the standard the AMLR demands. The answer to that question determines everything else – including how much value you will ever extract from the tools you have already bought.

Explore how Ondorse helps obliged entities build the data foundation that AMLR compliance requires: ondorse.co/contact.