From Free-Text to Structured Intelligence: What AMLA's Article 69(3) ITS Actually Changes

For thirty years, European compliance teams have operated in a reporting landscape that resembles Europe before 1999. Every Financial Intelligence Unit has built its own format for receiving suspicious activity reports. Different templates, different mandatory fields, different XML schemas, different validation rules, different interpretations of what "suspicion" even means. A transaction crossing five Member States gets translated five different ways before it reaches five different FIUs.

The draft Implementing Technical Standards under Article 69(3) of the Anti-Money Laundering Regulation (AMLR) are designed to end that fragmentation. But the scope of what is changing is significantly larger than most compliance commentary has recognized.Sources: AMLR (Regulation (EU) 2024/1624)

This is not a new reporting template. It is the first European AML reporting data model.

What the ITS actually harmonizes

Previous EU AML directives harmonized obligations. What to report, when to report it, who is covered. The ITS harmonizes the intelligence itself: the data definitions, the reporting logic, the validation rules, the conditional fields, the technical attributes, and the semantic relationships between reported entities.

The goal is semantic interoperability. A SAR submitted in Lisbon is designed to be understood, processed, and cross-referenced in Warsaw, Vienna, or Stockholm without being translated into a different national reporting language.

This distinction matters enormously for what comes next. When you harmonize forms, you simplify paperwork. When you harmonize intelligence, you make cross-border patterns detectable.

Five natures of data, not one

One of the least discussed innovations in the ITS is how it classifies every data point. Under Article 3, each field carries one of five natures — mandatory, mandatory if available, optional, dependent, and FIU-required — and the standard is careful about how they combine.

Three of these are base treatments. Mandatory fields must always be reported. Mandatory if available fields are required only where the institution already holds the information, with no obligation to gather data solely for reporting purposes. Optional fields can be added when they help the FIU understand the reported suspicion.

Two more are layered on top. Dependent fields become mandatory, available, or optional only when a specific parent field or circumstance is present — the mechanism behind the conditional reporting described below. FIU-required fields can be added by individual national FIUs where national legislation or specific circumstances demand it.

Within the mandatory set sits a stricter sub-type the ITS calls technically required: if a technically required field is missing, system-level validation fails and the report cannot be submitted at all. It is not a separate category — it is the hard floor of the mandatory ones.

This architecture is more sophisticated than it first appears. The "mandatory if available" nature acknowledges that institutions cannot always obtain perfect data before reporting. The "dependent" nature makes the form adapt to the facts of the case. And the "FIU-required" nature preserves national flexibility without undermining European harmonization. The result is a reporting model that is uniform in its core but adaptive at the edges.

Dependent data points: the most technically novel element

Perhaps the most innovative aspect of the ITS is the introduction of dependent data points. Certain fields only become mandatory when predefined conditions are met.

The ITS does this in two distinct ways. Some fields are dependent: a parent value switches child fields on. Flagging a counterparty as a Politically Exposed Person opens additional PEP disclosure fields; a sanctions match opens the sanctions-reference fields; reporting a legal entity rather than a natural person opens its own dependent fields. Separately, certain activities select a different template altogether — crypto-asset services and correspondent banking each have their own activity-specific reporting template, rather than a conditional field inside a shared one. Either way the effect on the compliance team is the same: the report reconfigures itself around the nature of the suspicion and the entities involved.

This means the SAR of the future is not a static form. It is a dynamic template that reconfigures itself based on the nature of the reported suspicion and the entities involved.

For compliance teams, this requires a fundamental rethink of how SAR workflows are designed. The question is no longer "which fields on the form are relevant to this case." The question is "which conditions are present in this case, and what does each condition require."

Article 9: the part nobody is talking about

The ITS contains a provision that has received almost no attention in the public commentary but may be its most consequential operational requirement.

Article 9 establishes that reported data must be complete, technically accurate, internally consistent, plausible, and compliant with FIU validation rules. Data quality itself becomes an AML compliance obligation.

This is a structural shift. Until now, supervisory scrutiny in AML has focused predominantly on whether an institution filed a report and whether the identified suspicion was reasonable. Article 9 adds a third dimension: whether the underlying data supporting that report meets a defined quality standard.

The downstream implications are significant. Institutions with fragmented customer master data, inconsistent entity resolution across systems, or poor transaction tagging now face a compliance risk that goes beyond the content of any individual report. If your systems cannot reliably determine that "ACME Ltd" in one database and "ACME Limited" in another are the same beneficial owner, the SAR that emerges from that data may fail the validation rules even if the identified suspicion is entirely legitimate.

The data governance program required to meet Article 9 is not an IT project. It is a compliance architecture project.

What this means for AI in AML compliance

The shift from free-text narrative reporting to structured data points has a specific and underappreciated implication for AI-assisted compliance systems.

Most discussions of AI in AML compliance focus on the narrative layer: AI that generates a coherent SAR description, AI that summarizes case findings, AI that writes the "grounds for suspicion" section. These capabilities are useful, but they sit on top of the fundamental problem.

The AMLA ITS reframes the core task. Producing a SAR is no longer primarily a writing problem. It is a data mapping problem: identify the relevant entities, transactions, relationships, and suspicion indicators; classify them against the ITS data model; activate the appropriate conditional fields; verify that the output meets Article 9 quality standards.

AI systems operating in this structured environment can do something more reliable and more auditable than generating prose. They can trace each populated field to its source data, flag where "mandatory if available" fields are missing and document why, and identify which dependent data point conditions are triggered by the case facts. The output is not a narrative. It is a structured evidence map.

This is a better use of AI in compliance precisely because it is more constrained. Structured fields with defined validation rules create natural checkpoints. A human compliance officer reviewing an AI-populated SAR against the AMLA data model is in a fundamentally stronger position than one reviewing an AI-generated narrative: the structure makes the reasoning visible, the gaps auditable, and the errors detectable before submission.

The implementation window is now

The ITS entered public consultation on 2 July 2026, with comments due by 20 September and the standard due to be submitted to the European Commission by 30 November 2026. Formal adoption and mandatory-compliance timelines will follow. Institutions that begin mapping their existing data architectures to the AMLA data model now, well before those dates, will be better positioned both operationally and supervisorily.Sources: AMLA public consultation on the reporting format

The institutions most exposed are not necessarily the smallest. They are the ones that have allowed AML data governance to lag behind transaction monitoring analytics. Good detection logic operating on poor underlying data produces SARs that may be substantively correct but structurally deficient under Article 9.

The Euro did not simply replace national currencies. It forced Europe to rethink payments infrastructure. The AMLA ITS will not simply replace national SAR templates. It will force European financial institutions to rethink how financial intelligence is created, structured, and made defensible at scale.