Phase I of STR-F automation is done. Phase II is the one that will hurt.

On 31 December 2025 the Financial Monitoring Unit issued Circular No. 04 of 2025, setting out the phased rollout of STR-F automation through goAML. Phase I is behind us: the ten pilot banks went live on or before 30 January 2026, and every other bank from 30 March 2026.

If you filed on time, the temptation now is to move on. That would be a mistake, because the circular says plainly what comes next:

“In the second phase, all other transactions, including interbank transactions, will migrate to XML format. Timelines for implementation of phase-II will be communicated after completion of Phase-I. In the meantime, the banks are encouraged to begin developing mechanism for XML-based reporting of interbank transactions.”

No date has been announced. That is precisely why it is worth starting.

What Phase I actually asked for

Phase I covered intra-bank counterparty transactions — the ones previously entered by hand, or attached as an Excel file, on the goAML web portal. Those had to move to XML in the prescribed goAML format, uploaded rather than typed.

On paper that is a file format change. In practice it asks a bank for several things it may not have had:

• A reliable extract of counterparty transaction data, in a shape that maps cleanly onto the goAML schema.
• Schema conformance — valid XML that passes validation before submission, not after rejection.
• Consistent funds code selection. FMU enclosed a separate guidance note on uniformity of funds code selection, which tells you something about how consistently banks were choosing them.
• A tested path. The circular points non-pilot banks at the goAML test environment to validate files before going live — a step easy to skip under time pressure, and expensive to have skipped.

The enclosures are themselves a signal. A circular that ships with FAQs, sample XML files and a funds-code uniformity guide is a circular whose author expected confusion.

Why Phase II is materially harder

Intra-bank transactions have a convenient property: both sides are yours. You hold the counterparty record, you control its quality, and if a field is missing you know who to ask.

Inter-bank transactions are not like that. The counterparty sits inside another institution, and you are being asked to produce schema-valid XML describing a party whose data you received rather than created. Three problems follow.

Completeness is outside your control. If an incoming instruction carries a truncated name, a missing identifier or an ambiguous institution reference, that gap is yours to resolve at filing time — regardless of who introduced it.

Volume is higher and lumpier. Inter-bank flows concentrate around settlement windows. A process that copes at intra-bank volumes can fall over when the same logic meets a month-end peak.

The mapping is less obvious. Funds code selection was already inconsistent enough across banks to need its own guidance note for intra-bank reporting. Inter-bank transactions involve more transaction types, more intermediaries and more room for two institutions to describe the same movement differently.

None of this is insurmountable. It is, however, substantially more work than Phase I, and the circular explicitly invites banks to begin before the date lands.

What starting early actually looks like

You do not need the Phase II specification to make progress. Most of the work is the same work, and it is testable today.

Find out what your Phase I pipeline actually does. If it was built quickly to meet March, it may be a script someone runs rather than a process the bank owns. Who runs it? What happens when they are on leave? Where does it log? If the honest answer is “we are not sure”, that is the first thing to fix, because Phase II will build on it.

Measure your rejection and rework rate. How many submissions came back? How long did each take to correct? That number is your baseline, and it is the only way to show Phase II went better rather than merely feeling busier.

Profile your inter-bank data now. Pull a month of inter-bank counterparty records and check them against the goAML schema requirements — not to file anything, just to find out how many would fail. That exercise takes days and tells you the size of the problem before it has a deadline attached.

Use the test environment while it is quiet. FMU provides one, and it will be considerably busier once Phase II has a date on it.

Write down the funds code decisions. If your institution had to make judgement calls in Phase I, those calls should exist as documented rules rather than in one analyst’s memory — both for consistency and because the next person will need them.

The part worth saying plainly

Regulatory automation projects fail in a recognisable way. The deadline arrives, something is built quickly to satisfy it, it works well enough to pass, and nobody returns to it until the next circular. Then the next circular turns out to depend on the thing that was built quickly.

Phase I was the straightforward half. Treating it as a finished project, rather than as the foundation Phase II will be built on, is how a second scramble gets arranged.

We build this kind of pipeline — goAML and regulatory reporting automation — including a CTR-to-goAML conversion pipeline running inside a regulated bank today: parser, XML builder, schema validator and audit trail, behind a maker–checker step. If you are assessing what your Phase I implementation would take to extend, that is a conversation worth having before the date is announced rather than after.

This article summarises FMU Circular No. 04 of 2025 and is not legal or compliance advice. Read the circular and its enclosures in full on the FMU website.