The STR Is the Entry Point, Not the Exit: What AMLA's FIU Cooperation Standards Reveal About Your Compliance Data

On 13 May 2026, the Authority for Anti-Money Laundering and Countering the Financing of Terrorism published three draft Implementing Technical Standards for FIU cooperation. Public hearings follow on 27 May, with morning and afternoon sessions covering EPPO reporting and FIU.net exchanges respectively. Most compliance teams at management companies and TCSPs are not monitoring this file. It sits in the interoperability section of AMLA's rulemaking programme, which looks like a technical matter for Financial Intelligence Units, not for the firms that feed them.

That reading is wrong. The three instruments AMLA published on 13 May are not plumbing for regulators. They are a specification of what structured AML compliance data looks like when it travels through a law enforcement chain. And that specification has a direct read-across into the compliance files that management companies, TCSPs, and fund administrators are building right now.

What the Three Instruments Actually Contain

Two of the three ITS govern how findings are reported to the European Public Prosecutor's Office when FIU analysis reveals reasonable grounds to suspect offences against the EU's financial interests. One covers FIU reporting format; the other covers AMLA's own reporting format when it conducts joint analyses. Both require a common reporting template and machine-readable submissions through a secure channel, enabling automatic processing by the EPPO.

The third instrument governs FIU-to-FIU cooperation. It introduces six standard templates for information exchange on FIU.net, the secure platform through which national FIUs share intelligence across the EU. The goal, as AMLA stated, is to ensure information sent through FIU.net is "more complete and consistent, reducing operational gaps and potential delays."

The practical effect of these three instruments is that by the time a compliance matter reaches the FIU layer of the EU enforcement system, the data describing that matter must be structured, templateable, and machine-processable. It cannot be a narrative PDF. It cannot be a case note that makes sense only to the analyst who wrote it. It must conform to a format the system can parse, compare, and route automatically.

The Chain These Standards Assume

The EU's AML enforcement architecture runs in a sequence. A financial institution conducts customer due diligence and transaction monitoring. It identifies an activity that meets the reporting threshold. It files a Suspicious Transaction Report with the relevant FIU, in Luxembourg the Cellule de Renseignement Financier, in Mauritius the Financial Intelligence Unit. The FIU analyses the report, possibly in coordination with other EU FIUs via FIU.net. Where analysis reveals grounds to suspect crimes against EU financial interests, the FIU or AMLA reports to the EPPO.

The ITS published on 13 May standardise the back end of this chain. They define what the data looks like when it travels from FIU to FIU, and from FIU to prosecutor.

What they assume, without stating it, is that the front end of the chain, the compliance file the institution built before it filed the STR, can support the structured output the back end requires. Machine-readable reports to the EPPO cannot be reliably generated from case files that consist of unstructured narrative, PDF documents, and manually maintained spreadsheets. The structured output has to come from somewhere. The ITS specify where it ends up. They do not specify where it starts. That is the gap these standards expose.

The STR as Data Entry Point, Not Exit

Most compliance teams at management companies and TCSPs treat the STR as a terminal event. The suspicious activity was identified. The required analysis was done. The report was filed. The file is closed, or at least the active monitoring phase ends and the matter moves to an ongoing watch list.

This framing is operationally wrong in a system where FIU.net exchanges now run on six standardised templates and EPPO reports require machine-readable submissions. From the perspective of the enforcement chain, the STR is not the end of the file. It is the entry point. The data the institution submits in the STR is the raw material the FIU uses to populate the structured exchange templates that AMLA has just defined.

If the STR is thin, narrative, or poorly evidenced, the FIU's ability to use it in a structured intelligence exchange is compromised. If the underlying case file supporting the STR cannot be reproduced with the documents and reasoning that existed at the time the decision was made, the STR is an assertion without a foundation. It enters a pipeline that is now designed to be machine-processed, and it degrades that pipeline.

The 2026 FATF Mutual Evaluation of Singapore noted that despite a strong overall framework, the number of enforcement actions relative to STR volume remains relatively low. This pattern repeats across jurisdictions because FIUs receive high volumes of reports, and the reports that produce actionable intelligence are those with structured, evidence-linked detail. The reports that produce nothing meet the form requirements without meeting the substance requirements. AMLA's ITS are, among other things, an attempt to make the substance requirements legible throughout the chain.

Why Narrative Case Files Break the Chain

The most common compliance file structure at Luxembourg management companies and Mauritius fund administrators is still a hybrid. The customer risk profile exists in the CDD platform. The supporting documents are in a document store, linked loosely or not at all. The risk rationale is in a case note, often a narrative field. The transaction monitoring output that triggered the review is in a separate system.

None of this data is wrong in isolation. The problem is that it cannot be exported as structured, template-compatible data without a manual assembly step. When the STR needs to be filed, the analyst assembles the narrative from these sources. The narrative is useful to a human reader. It is not useful to a system that needs to populate an AMLA-specified FIU.net template.

The ITS published on 13 May describe six standard template types for FIU.net exchanges. The stated purpose, to ensure information is "more complete and consistent," describes the problem with current practice accurately. Completeness is a data architecture problem before it is a compliance problem. Consistency is a schema problem before it is a procedural problem.

The firms whose compliance platforms store customer data in structured, queryable fields linked to their source documents will be able to support the full chain. The firms whose platforms store compliance rationale as narrative text in free-form fields will not. The difference is not which platform was purchased. The difference is how the platform was configured and what data model it uses.

What This Means for Management Companies, TCSPs, and Fund Administrators

For CSSF-supervised firms in Luxembourg, the operational question is whether the CRF can use the STRs your firm files in an AMLA-era structured intelligence context. The CRF has historically been active in FIU.net coordination, and the quality bar for FIU.net exchanges is about to be formalised through AMLA's ITS.

For FSC-regulated firms in Mauritius, the Mauritius FIU is part of the Egmont Group and has its own information-sharing obligations. The FATF mutual evaluation process increasingly measures not just whether STRs are filed but whether they produce actionable intelligence. Firms whose reports support structured FIU analysis will score better on the effectiveness dimension than firms whose reports meet form without substance.

For fund administrators across both jurisdictions, the read-across is concrete. A fund administrator handling beneficial ownership records and transaction monitoring for complex fund structures is a high-volume STR originator relative to its size. The quality of those reports is a function of how the underlying CDD data is structured. An administrator whose beneficial ownership records are stored as version-controlled, field-structured data can support a complete and consistent FIU submission. An administrator whose beneficial ownership narrative lives in a case note attached to a PDF cannot.

Three practical questions worth addressing before AMLA's public hearings on 27 May. First, can your compliance platform export the data behind any given STR in a structured format, field by field, linked to the source documents? Second, is the risk rationale in your case files stored as structured reasoning, or as narrative text that requires a human to interpret before it can be transmitted? Third, when a transaction monitoring alert produces an STR, does the system create a traceable link between the alert, the CDD file, and the report filed, so the entire chain can be reproduced and verified?

The Specification Has Already Been Written

The AMLA FIU cooperation ITS are not a future concern. They are a specification being consulted on now, with public hearings in six days. The formats they define will flow backwards through the supervision chain. The supervisor's assessment of a firm's AML/CFT framework depends on the quality of the intelligence that firm contributes to the system. That quality is now being formally defined, from the EPPO back to the FIU, and from the FIU back to the originating institution.

The firms that treat compliance as a data infrastructure problem will already be building case files in formats that can support structured FIU submissions. They are not waiting for the finalised ITS. They are building the infrastructure because the direction of travel has been clear since AMLA published its supervisory risk assessment methodology in December 2025. The firms that are waiting for the regulation to be finalised before addressing their data architecture will spend the next two years retrofitting.

The STR is not the end of the compliance file. It is the point at which your compliance data enters a chain that now ends at the European Public Prosecutor. The chain is only as strong as what you put into it.

If your firm is assessing whether its STR data quality and underlying case file structure are ready for AMLA's compliance chain, we can help you close the gap.