If your company is present in multiple countries, you must report suspicious activity to multiple financial intelligence units (FIUs). This means that you have to maintain one report format for each FIU – even if the FIUs use similar reporting systems, such as the UN’s goAML.
Many compliance officers are silently waiting for harmonization to happen at some point. “Perhaps FATF will take it up at some point.” Or in the EU, they look at the EU Anti-Money Laundering Authority (AMLA) to sort it out. But until then, they keep a spreadsheet of national “quirks”.
That is the wrong bet. No regulator is coming to merge different expectations. Even the EU is far off from achieving this.
Actually, we should not regard national divergence in suspicious activity reporting as a “defect” waiting for a fix. Every difference between two FIUs encodes legal choices: what a country treats as suspicious, what its FIU can do about it, and what evidence it wants in hand. Different economies have different risk profiles. Harmonization may narrow those differences, but will not erase them.
So the teams that report well across borders have stopped waiting. They build with the differences in mind.
One record of the case, every national report generated from it. A new FIU, a new field. (Even AMLA's final format will become a configuration change, not a rebuild.)
This way, your analysts spend their time on investigating the suspicion, and not filling out an unfamiliar form again.
This blog post reviews some of the larger markets’ divergences in terms of suspicious activity reporting formats. It considers what AMLA will (not) change in the European Union. And ultimately, it will address the practical question: how to stop rebuilding the same report for each and every FIU?
Do suspicious activity report requirements differ by country?
Yes. Even among the 75 FIUs that use the UN's goAML platform, each sets its own report types, narrative rules, indicator codes, data requirements, and validation checks. Outside goAML, national formats differ entirely from FinCEN's batch XML in the US to the glossary codes UK reporters type into free text.
Why one standard never meant one report
Seventy-five (!) FIUs belong to the user group of goAML, the reporting platform built by the UN Office on Drugs and Crime (UNODC). That number suggests a global standard.
But it isn’t, really.
goAML standardized the software and the reporting file format’s (XML) “skeleton”. But it never standardized the content of the reports. Hence each FIU configures its own instance: its report types, its codes, its mandatory fields, and its validation rules. The result is one grammar, spoken in 75 “dialects”.
In 2019, the European Commission found that few FIUs used standardized templates at all. Those that did were "bank"-focused, "not fit for use by other obliged entities". In 2025, a Council of Europe mapping across 28 EU and EEA FIUs counted "over 6500 different possible data points". AMLA describes data points spread "across hundreds of documents in multiple formats".
Why so much variety?
Because a report is a legal instrument first. It is only a data file second. So each difference is a policy decision. They may stem from many different reasons like historic circumstances or specific socio-economic characteristics. No two countries are the same.
Where the dialects split: five differences that decide whether a report lands
We reviewed the openly available FIU specifications from a handful of major economies like the UK, US, Germany, France, Italy, Switzerland, Denmark, Luxembourg, and even a few east African economies etc. They use different systems and provide different level of detail.
We found that differences can be grouped into five categories. Practically speaking, each of these groups represent a mapping problem for your team. They are usually solved by hand, again and again. Unless your reporting is built for it (which is rarely the case in today’s market). Let’s review these five categories below.
1. The name: what a suspicious activity report is called
The term itself is not unanimous.
In the US, a Suspicious Activity Report is how a bank reports any suspicious transaction to FinCEN. In the UK, SARs are the umbrella for every report to the National Crime Agency. In goAML, a SAR is something narrower: a suspicion with no transactions attached, the counterpart of the suspicious transaction report (STR).
Then the national vocabularies take over due to national languages other than English:
- Germany works with three report types: VMT (with transactions), VMA (without), and EIT (additional transactions for an earlier report).
- Luxembourg uses six, with terrorist financing split into its own types (TFTR, TFAR).
- Switzerland adds two report types found nowhere else in our review (CANCT and CANCL) to notify the termination of a business relationship. And in Switzerland, your sector decides the type: banks, money transmitters, and virtual asset service providers must file STRs, while card providers, fiduciaries, and insurers file SARs.
The report type hence is a mapping exercise. It belongs in your system, not in an one of your analyst's memory.
2. The narrative: what the report must tell
Every FIU wants the narrative, but few agree on what it should really look like and contain.
- Denmark's 2020 goAML schema left the
reasonfield optional, at up to 4,000 characters. - Luxembourg allows 8,000.
- Switzerland asks for two fields of 8,000 each: the description of facts, then the reason for suspicion and the steps taken.
- Malta made its
reasonelement mandatory on 12 January 2026. Germany made its fact description mandatory on 1 March 2026. - Italy's draft instructions go further: two free texts, one for the transactions and one for the reasons, which may not repeat each other.
- And AMLA's draft standards ask every narrative to answer "who, when, where, how, how much and why".
The same facts need to be told in different ways, with different specifications each time. So reporting teams lose many valuable hours. Hence drafting from a complete case file pays back fast here.
3. The labels: how suspicion reports get their regulatory codes
On top of these differences, classification becomes completely disparate. Here, the “dialects” are rendered mutually unintelligible.
For example:
- Germany's FIU uses alphanumeric reasons: A1001 for a pending money-laundering transaction that needs FIU consent, A3004 when you also intend to report to BaFin, A4000 for an urgent matter.
- Denmark's 2020 catalog uses letter-number pairs: B09 for transfers to many receivers, D05 for cash deposits across several branches, F01 for a sanctions hit.
- Switzerland added indicator 1211V (crimes against the environment) in August 2026.
- The UK asks reporters to type glossary codes such as XXS99XX at the start of the free text.
Naturally, none of these correspond to one another. AMLA leaves indicator lists largely to FIUs. So what you can do here, is to map your alerts and rules to each FIU's codes once, at the source. Otherwise, you risk re-coding every report by hand over and over again.
4. The scope: who and what goes into the report
The scope of a report is a data-selection question. FIUs answer it differently.
- In Switzerland, the whole business relationship must be reported: every active account, "even if the suspected transactions were executed on one specific (sub-)account". An STR holds at most 100 transactions, chosen for relevance: "all transactions between Date X and Date Y" is refused.
- Luxembourg sets no cap. But, above 500 transactions, a special procedure is triggered. And the FIU excludes bank fees, interest, and currency-exchange commissions from the reporting.
Even the word "account" changes: in Switzerland, it can be an IBAN, a crypto address, an email address, or a phone number used for TWINT payments. Perhaps most curiously, the way individuals are identified varies, too. AMLA's interpretative note lists each Member State's national identifier as of today: the CPR in Denmark, the BSN in the Netherlands, PESEL in Poland, the codice fiscale in Italy... And none at all in Germany or France.
Scope is decided by the regulator, and your team must conform. So these requirements belong in your data model, not just a filing checklist in a file somewhere.
5. The gate: what the FIU will accept
A valid file is not an accepted report.
- Switzerland's schema 5 rejects reports automatically when structural information is missing or wrong. MROS intends to extend those checks.
- Malta applies rejection rules as "an additional automated filter prior to the acceptance stage".
- Luxembourg runs semantic business rules after the XSD check. So a report can be rejected "even if it is syntactically correct".
- Liechtenstein goes furthest: before you can submit XML at all, its FIU audits the content of at least three test reports, each an STR with 10 to 15 transactions paired with a SAR.
The small print diverges too. Germany accepts eight attachment file types, 20 MB each, with no embedded files. Switzerland caps a report at 300 MB and refuses password-protected attachments. In mandatory fields with no data, it accepts "n/a" – "but never 'NA', 'n.a.', 'unknown', 'null'".
The cheapest rejection is the one that never reaches the FIU. Check every report against each FIU's rules before you submit.
Beyond goAML: four more ways to report a suspicion
FIUs that use goAML at least share a skeleton. But countries’ reporting formats beyond goAML naturally vary even more widely.
Four countries, four philosophies. A group that reports in all four countries has to maintain four mental models.
What AMLA will harmonize (and what it will not)
The EU has heard the complaints.
Article 69(3) of the Anti-Money Laundering Regulation (AMLR) tasks AMLA with specifying "the format to be used for the reporting of suspicions and for the provision of transaction records". AMLA's draft standards, published on 2 July 2026, propose a common core of data points with one EU-wide definition each, templates adapted to each type of obliged entity, and common templates for transaction records from banks, money remitters, crypto-asset service providers, and correspondent services.
This is real progress. But it is also incomplete. Deliberately so.
The draft "does not specify the technical language to be used nor the file format". This way, Member States’ FIUs keep their platforms. And the draft keeps national room by design: data points can be "FIU-required", used only where national law needs them.
Then, there is the calendar. AMLA submits its draft to the European Commission by 30 November 2026. After publication, FIUs get two years to test the data points and run a gap analysis. Implementation follows. Altogether, AMLA envisages about five years: three for FIUs, two for reporting entities, with some overlap. Only from July 2032 will the Commission assess whether a single EU reporting system makes sense.
Thus waiting for convergence would mean waiting into the 2030s, for an answer that still leaves three of five differences partly or fully national. And it covers only the EU.
Build for divergence, not convergence
If divergence is permanent, the question changes. It’s not "when will the formats align?", but "how do we make each new format cheap?"
The answer: stop treating a report as a document. Start treating it as an output.
Keep one complete record of the case: alerts, transactions, parties, accounts, investigation notes, and the decision all in one place. And then, generate each FIU's report from this single source of truth. The facts are established once. The “dialect” is applied at the end.
We built Marble with this exact logic in mind. So that is exactly how Marble handles reporting:
- Naming: each FIU's report types are mapped once. When a case is marked for reporting in a given jurisdiction, Marble selects the right type: a VMT in Germany, a TFTR in Luxembourg, an STR in Switzerland
- Narrative summaries: Marble's AI drafts the narrative from the full case file, compatible with any FIU's specification (whether it is one field or two, the facts separate from the reasoning, within each character limit). Your analysts review the pre-written narrative. They can edit and amend the narrative, add more related transactions and accounts, attach files with context or proofs, and finally, sign off. So humans stay in full control of the entire reporting process, nothing is left to AI only
- Submission: reports are generated in each FIU's format and checked against its schema before submission
Every decision stays on an unalterable audit trail from the first alert to the filed report.
And when the dialect shifts, it is a configuration change in Marble, not a project for your engineers. Because it is your framework. Your data. So every report falls into place.
See how Marble automates multi-jurisdiction SAR and STR filings through a single unified case record.
Frequently asked questions
Do suspicious activity report requirements differ by country?
Yes. Even among the 75 FIUs that use goAML, each sets its own report types, narrative rules, indicator codes, data requirements, and validation checks. Outside goAML, formats differ entirely.
What is the difference between a SAR and an STR?
It depends on where you report. In the US and the UK, a suspicious activity report (SAR) is the general term for any suspicion report. In goAML, a SAR is a report with no transactions attached, while a suspicious transaction report (STR) carries structured transaction data.
Why are goAML reports different in every country?
goAML standardizes the software and the XML skeleton, not the content. Each FIU configures its own report types, codes, mandatory fields, and validation rules to reflect national law.
Will AMLA create a single EU format for suspicious activity reports?
Partly. AMLA's draft standards define common data points and templates, but no file format. FIUs keep their platforms, indicator lists, and validation rules, and some data points stay national.
When will AMLA's common reporting format apply?
Not before the end of the decade. AMLA submits its draft to the European Commission by 30 November 2026. FIUs then get two years for a gap analysis, followed by about five years of implementation.
Can suspicious activity reporting be automated across several countries?
Yes. The reliable approach is to keep one complete record of each case and generate each FIU's report from it, mapping report types, indicator codes, and data requirements per jurisdiction and checking each report against the FIU's rules before submission.
