| “Simplification is a core component of AMLA’s mandate.”
AMLA, on the draft ITS under Article 69(3) AMLR |
This is how AMLA frames one of the most ambitious technical projects under the new EU anti-money laundering framework: the draft Implementing Technical Standards under Article 69(3) AMLR on the format for reporting suspicions and for providing transaction records to Financial Intelligence Units. AMLYZE is contributing to this public consultation through the Lithuanian Fintech Association.
The objective deserves support. Suspicious transaction and activity reporting across the EU remains fragmented: different FIUs use different structures, terminology, technical formats and levels of detail. Harmonisation can reduce that fragmentation and, in the longer term, make both reporting and cross-border FIU analysis more efficient. But there is a tension hidden in AMLA’s own language.
Harmonisation is not necessarily simplification
AMLA’s chosen starting point is an exhaustive universe of datapoints currently used by EU FIUs. That is an understandable harmonisation technique. But if different national requirements are collected into one European superset, the immediate result may be a larger and more complex reporting model – particularly for obliged entities currently operating under considerably leaner national templates. The draft therefore raises a fundamental question: simplification for whom?
For FIUs, a common vocabulary and structured dataset may indeed simplify analysis. Yet for cross-border obliged entities it will not: the framework retains datapoints dedicated specifically to individual national FIUs, so an institution reporting in several Member States still has to know which fields apply where – national variation is carried into the European model rather than removed from it. And for an individual institution asked to collect, map and technically transmit a materially larger universe of information, the road to simplification may itself be rather complex. Simplification for obliged entities, then, is obviously not the target.
After reviewing the draft datapoint by datapoint, our concern is not with AMLA’s objective. It is with whether the present data model is mature enough to deliver it.
Creating the language before agreeing the vocabulary
AMLA is effectively trying to make very different FIUs and obliged entities speak one reporting language. That is exceptionally difficult.
The problem becomes visible once apparently simple datapoints are tested against real business models. Our review suggests that the draft has a sensible underlying architecture – common entities, attributes, links and structured information – but still needs a significant horizontal data-modelling and implementation-consistency review.
In several places, two sophisticated institutions could adopt perfectly reasonable interpretations of the ITS and arrive at materially different reporting outcomes. For a harmonisation standard, that is not a minor problem.
Written against the clock
Public consultation naturally takes place on draft legislation. Nobody expects the text to be final. There is nevertheless a difference between consulting on regulatory choices and publishing technical material in which parts of the architecture are explicitly still being designed.
Signals of a draft still being drafted
N.B: This category is still under discussion and some of the data points may be relocated to another category.
Interpretative NoteThis corresponds to the information provided by the customer when…
Guidance for DP0612 on unstructured remittance information – the explanation simply stopsNOTE: might need a definition or clarification regarding account servicing Institution.
Crypto transaction-record section – reading rather like an internal drafting note
Any one of these would be an ordinary drafting issue. Taken together, they give a different impression: the market is being asked not only to comment on the proposed architecture, but in places to help finish it. There may be a rather straightforward explanation: AMLA is in a hurry.
It is not only an STR standard
The ITS has two distinct functions. Annex I standardises reports of suspicions submitted by obliged entities on their own initiative under Article 69(1)(a), while Annex II standardises the transaction records provided by credit and financial institutions at the request of an FIU under Article 69(1)(b).
But Annex I itself contains another important harmonisation step that is easy to overlook. AMLA proposes three possible report types: Suspicious Transaction Report (STR), Suspicious Activity Report (SAR), or both. This distinction may itself require adaptation in some Member States, because STR and SAR are not currently separate reporting concepts across all national frameworks. Lithuania is one example: the Lithuanian framework requires reports on suspicious transactions and it does not currently operate a separately designated SAR reporting category.
This raises a more substantive question than terminology. Article 69(1)(a) establishes a common obligation to report suspicions, but the ITS is now proposing a particular operational taxonomy for how that suspicion should be packaged. For institutions accustomed to an STR-centric national system, implementation may therefore mean more than mapping existing fields into a new EU template. They may need to introduce a new classification decision into the reporting process including the boundaries between a suspicious transaction and suspicious non-transactional activity with dedicated case-management systems supporting the distinction.
Annex II does something different altogether. It establishes the format through which credit and financial institutions provide transaction records requested by an FIU, with separate templates envisaged for banking and payment activities, money remittance, crypto-assets and correspondent services. These records may cover hundreds or thousands of transactions over a requested period, of which there will be few or most of them not themselves suspicious.
The reporting requirements for obliged entities do not end with the reporting architecture harmonised by this ITS. What is equally important is what remains outside it. Threshold-based reporting is not covered: neither cash transaction reports, nor reports concerning transactions involving certain high-value goods under Article 74 AMLR fall within this standard, as Article 69(3) does not mandate AMLA to harmonise those reporting formats.
The result is therefore somewhat paradoxical: the ITS takes a major step towards a common EU language for communicating with FIUs, but that language will not yet cover the entire conversation. Even once the AMLR Article 69 formats are harmonised, obliged entities will continue to navigate national or separate reporting arrangements for information flows falling outside this mandate. Harmonisation is progressing, but fragmentation will remain in parts of the FIU reporting landscape.
Five years to implement – including time to decide what the dataset should contain
The proposed implementation sequence is equally interesting. The consultation envisages approximately five years for implementation: around three years for FIUs and two years for obliged entities (NOTE: this is to be clarified in the final version of ITS after the public consultation, it is also not clear if those phases will overlap or be calculated seperately).
The first two years following publication are themselves envisaged as a period during which FIUs assess the completeness and accuracy of the Annexes, perform gap analyses against their existing requirements and assess implementation impact. AMLA and the FIUs may then review the Annexes, including adding, removing, merging or amending datapoints. Only after that does the full technical implementation phase follow.
This creates an unusual regulatory sequence: the market is consulting on a standard that FIUs themselves are expected to test for another two years before its dataset is fully stabilised. In practice, however, the first stress test may already be happening. The public consultation is effectively the first market shock wave: obliged entities are being confronted with the scale of the proposed common dataset.
And the scale is significant. Annex I alone contains roughly 160 distinct datapoints for suspicion reporting, before turning to the separate transaction-record requirements under Annex II. Not every datapoint will apply to every report – sectoral applicability, dependencies and availability rules matter – but the overall reporting vocabulary is extensive. For institutions operating today under comparatively lean national STR/SAR formats, the potential dataset could represent a very substantial increase and, depending on the jurisdiction and existing FIU requirements, could conceivably approach twice the information currently structured for reporting.
This also changes how the Annexes should be read. They are not simply a final reporting template awaiting technical implementation. They are, to some extent, a common EU dataset being tested for the first time: first against the market through this public consultation, and subsequently against the existing requirements, practices and systems of national FIUs.
The important question therefore becomes not only how long will implementation take?, but also how much of the proposed dataset will survive this testing process in its current form? If public consultation is the first reality check, our datapoint review suggests that the discussion should go considerably further.
What the datapoint review tells us
Our review suggests that the concerns are not primarily about individual datapoints. The same structural patterns recur throughout the draft. They raise broader questions about where an STR reporting standard ends and additional CDD or data-retention requirements begin; whether the same concepts have the same meaning across sectors; whether dependencies reflect non-banking business models; and whether obliged entities are being asked to report information they hold or, in some cases, to infer or reconstruct information specifically for reporting.
In other words, the real test is not whether a few hundred datapoints can be placed into a common EU schema. It is whether each of them has a sufficiently clear purpose, source, definition and dependency to produce the same reporting outcome across 27 Member States and very different business models.
The consultation took more than 40 datapoints to comment solely for Annex I, for your convenience we summarize those below in several recurring findings.
01 · Reporting risk is drifting into data-collection and retention obligations
The ITS sometimes moves beyond standardising how existing information is reported and starts to resemble an indirect CDD or record-retention standard. This is visible where fields expect information that AMLR or the emerging CDD framework does not clearly require institutions to hold as structured data (identification-document details, the infamous city of birth, residency status, historical addresses, occupation classifications, onboarding IP or device information).
The concern is not whether such information can be useful to an FIU. It can. The question is whether an STR format should cause institutions to collect, structure or retain information solely because it may later become reportable.
02 · Common fields do not always have a common meaning
Several concepts remain too open to interpretation for a machine-readable EU standard. “Residency” may mean habitual, legal or tax residence; “sanctions status” may refer to an alert or a confirmed designation; PEP status is unclear when attached to a legal entity; and a “transaction address” could refer to a branch, ATM, POS terminal or merchant location etc.
If institutions populate the same European field from materially different underlying facts, harmonisation exists in form but not necessarily in substance.
03 · Applicability rules sometimes require information that does not exist
A recurring problem is not missing information but non-applicability. Occasional customers are sometimes treated as if they had a business relationship, onboarding date, relationship status or account with the reporting institution. Similar problems arise where fields are mandatory for rejected transactions or where “mandatory”, “mandatory if available” and “optional” treatments are combined without explaining the trigger.
This can force institutions either to invent a value or populate the same field with facts having different meanings.
04 · The defining vocabulary needs to remain clear
The template occasionally risks conflating different concepts. A sanctions-screening alert is not automatically a reportable suspicion or sanctioned status; threshold-based reporting of high-value transactions is not the same as an STR.
07 · Harmonisation depends on finishing the taxonomy before implementation
Finally, several classifications, dependencies and even parts of the guidance remain unsettled or inconsistent. National additions, institution-specific classifications and unfinished enumerations would require extensive mapping while recreating national or institutional variation inside an ostensibly common EU format..
Harmonisation is not simplification – the trade-off between the two must be made explicit
Seen from that perspective, many of the issues identified in the datapoint review become easier to explain. The breadth of the dataset, overlapping concepts, sector-specific mismatches and fields that appear to go beyond existing CDD or transaction-record requirements may partly be the consequence of trying to preserve as much existing FIU practice as possible before deciding what can ultimately be removed, narrowed or standardised differently.
That is not necessarily the wrong way to begin. It is, however, a very different starting point from asking first what the minimum common dataset should be. The first approach maximises inclusion and then filters; the second minimises first and expands only where necessary.
This distinction matters because it shapes what the first European reporting standard will feel like for obliged entities. Under an aggregation model, simplification may come only after consultation, FIU testing and subsequent refinement. Under a minimum-dataset model, simplification is built into the architecture from the outset.
That may be a perfectly reasonable way to build the first European reporting language. Whether the first version of that language should already be called simplification is another question. Perhaps, for now, simplification is most visible from the regulator’s side of the process: instead of resolving every technical question before consultation, AMLA has effectively invited the market into the drafting room.
And that is precisely why industry should be an active participant rather than a reactive observer in these consultations.
This is not our first reading of AMLA
The draft ITS is one of several AMLA consultations reshaping what obliged entities will be expected to do from 2027. We have reviewed two others in the same way – line by line, against how the requirements would actually land in a live compliance system:
- AMLA’s draft guidelines on transaction monitoring – what continuous monitoring is expected to look like in practice
- AMLA’s draft RTS on transaction monitoring – the technical standard on monitoring business relationships and occasional transactions
About this analysis. AMLYZE is contributing to AMLA’s public consultation on the draft ITS under Article 69(3) of Regulation (EU) 2024/1624 (AMLR) through the Lithuanian Fintech Association. The observations above follow a datapoint-by-datapoint review of the consultation material and reflect our reading of a draft that is expressly still under development. This article is regulatory analysis and commentary; it is not legal advice.
