← All guides

pain.001.001.03 vs pain.001.001.09: what changed and when to migrate

The practical differences between the two most common pain.001 versions — BICFI, structured addresses, dates, new elements — and a calm plan for moving from .03 to .09.

If your payment files have worked for years, they are probably pain.001.001.03. That version, published in 2009, became the workhorse of SEPA: when the euro area moved to SEPA credit transfers, the European Payments Council built its rulebook on .03, and a generation of ERP systems learned to speak it. Pain.001.001.09 arrived a decade later, in 2019, and the current SEPA rulebook is built on it. Both versions are valid ISO 20022 messages. Both are still accepted by many banks. But they are not interchangeable: a file written for one version fails the schema check of the other, and several everyday fields changed their names, their shapes, or their rules. This guide explains what actually changed, who needs to move, and how to migrate without breaking a payment run.

First, a word on version numbers, because they confuse everyone. In pain.001.001.09, the parts read like this: pain is the message family (payment initiation), 001 is the message within the family (customer credit transfer initiation), the second 001 is a variant, and 09 is the version. Versions .03 through .13 all exist and are all published with official schemas. The version is declared in the file’s namespace, so software can tell instantly which grammar a file follows. Nothing about the version number says the file is good or bad — it says which rulebook edition the file claims to follow, and the bank checks the file against exactly that edition. If version questions keep coming up in your team, start with how validation works layer by layer for the big picture.

The headline differences at a glance

BIC becomes BICFI

The change you will trip over first is a rename. In .03, a bank is identified with an element called BIC inside the financial institution identification. In .09 the same value lives in an element called BICFI. The content is identical — an 8 or 11 character bank code — but the tag name differs, so a .03 file fails the .09 schema at the very first agent block, and the error message points at a name many people have never seen. ISO renamed the element to align the payment messages with the rest of the ISO 20022 library, where financial institution identification uses BICFI everywhere. When you migrate templates, search for every BIC tag that identifies an agent and rename it; BIC values inside other contexts, such as organisation identification, follow their own paths, so a blind find-and-replace across the whole file is risky.

This rename is a good example of why migration is a testing job, not an editing job. The value did not change, the meaning did not change, but the file either passes or fails on the tag name alone. A schema check catches it in milliseconds, which is the kindest possible way to learn about it. The unkind way is a rejected payroll file on the last banking day of the month. Validate every migrated template against the .09 schema before it goes anywhere near the bank — you can run the check free on the home page — and keep the .03 template untouched until the .09 one has been accepted at least once.

Addresses grow up: from free lines to structured fields

The deepest change is the postal address. The .03 era allowed addresses as up to seven free-text lines, and most ERP systems happily dumped street, city and postcode into those lines in whatever order the address book held them. ISO 20022 always had structured address fields — street name, building number, post code, town name, country — but schemes tolerated the free lines for years. That tolerance is ending. The direction of travel in the .09 rulebooks, and in the wider ISO 20022 migration across high-value payment systems, is structured addresses: each part in its own field, with the country as a two-letter code. Hybrid addresses, with some structured fields plus limited free lines, are the stepping stone many banks now document in their guidelines.

Why does this matter for a payment file? Because screening systems read addresses. Sanctions and fraud checks match names and addresses against lists, and a free-text line that mixes street and town defeats the matching. Structured data also survives borders better: a German postcode inside a field labelled post code is unambiguous, while the same digits inside a free line can be read as a house number. For migration, the practical work is in your master data, not in the XML: check that your ERP stores addresses in parts, or at least that the export maps the parts consistently. Files that carry only AdrLine elements are the ones to fix first, because guideline after guideline now flags or rejects them.

Smaller changes that still bite

Several smaller edits cause a steady trickle of rejections. The .09 message adds a charges account element at payment level, so charges can be booked to a different account than the principal — in .03 there was no clean place to say that. Regulatory reporting details were expanded, which matters for payments that need structured tax or statistical reporting. The group header and payment blocks gained clearer rules for the initiating party and for on-behalf-of structures. Date and time fields kept their shape, but bank guidelines built on .09 are stricter about time zone offsets in the creation date-time. None of these changes is dramatic alone. Together they mean a .03 export with years of local patches will not become a good .09 file by changing the namespace and hoping.

There is also a difference in what the surrounding ecosystem expects. The current SEPA Credit Transfer rulebook is written against .09, and its examples, error codes and clarifications all assume the newer message. When your bank’s support team answers a question, they answer it in .09 terms. Staying on .03 means translating every answer — and every new guideline — back into the older grammar, forever, while the pool of people who remember .03 quirks shrinks. That translation cost, more than any single field change, is the real argument for migrating on your own schedule instead of the bank’s deadline.

Who must migrate, and who can wait

You must migrate when your bank tells you to — banks retire old versions on their own calendars, and the notice usually arrives as a guideline update with a date. You should migrate soon if you are changing ERP systems, onboarding with a new bank, or adding a new payment type, because doing the version change inside a bigger project is far cheaper than doing it alone later. You can wait if your bank still documents and accepts .03, your files pass cleanly, and nothing in your setup is changing. Waiting is a legitimate choice; drifting is not. The teams that get hurt are the ones who never decided anything and discover the deadline from a rejection message. Put a date in the calendar to review the question once a year, and the decision stays yours.

One more group should move early: anyone whose files travel to more than one bank. Multi-bank setups age badly on old versions, because each bank retires .03 on a different date and documents the change in a different place. Running the newest common version everywhere removes a whole category of which-bank-wants-what confusion. The same logic applies to software vendors and integrators: if your product generates pain.001 for customers at many banks, .09 is the dialect your support team will be asked about, and the one the current scheme rulebook describes. Our own validator treats both versions as first-class citizens — full business rules run on .03 and .09 files on every plan — precisely because mixed estates are the normal case during a migration.

A migration plan that does not break payday

• Inventory first: list every system, template and bank connection that produces or consumes pain.001, and note the version each one uses today.
• Get the target in writing: ask each bank which versions it accepts now, which it plans to retire, and for its current implementation guidelines for .09.
• Convert a copy of the templates, never the live ones: rename BIC to BICFI in agent blocks, map addresses to structured fields, and add the time zone offset to creation timestamps.
• Validate the converted templates against the .09 schema and the SEPA rules; fix structure first, then business rules, in that order.
• Run one full payment cycle in parallel: produce both files, validate both, send the one your bank expects today, and compare the .09 report until it is clean.
• Switch the default on a quiet cycle — not month-end, not the December run — and keep the .03 template ready as a fallback for one more cycle.

The step teams skip is the difference report: a list, for one real file, of everything that would change between the .03 export and the .09 export. Reading it turns an abstract migration into a short, concrete work list — these fields rename, these addresses need restructuring, this timestamp needs an offset. Our Starter and Pro plans generate exactly that report for your file: upload the .03 original and get the concrete differences itemised, which is the fastest way we know to scope the work. See the pricing page for which plans include the migration report, and compare it with our guide on why files that pass the schema still get rejected — most migration surprises live in that gap.

What about the other versions — .04 to .08 and .10 to .13?

The version line did not jump straight from .03 to .09. Versions .04 through .08 filled the decade between them, each a modest revision published as the standard absorbed lessons from live use, and .10 through .13 followed .09 on the same steady rhythm. In practice, production estates are lopsided: .03 dominates the legacy world because the original SEPA migration was built on it, .09 dominates new work because the current rulebook is, and the in-between versions appear mainly inside specific banking communities and vendor products that adopted them at the time. The newest versions refine details again — further address structuring, small datatype corrections, clarified code lists — without changing the story of this guide: every version is its own grammar, a file is valid only against its own schema, and banks choose which grammars they accept. If your estate contains one of the middle versions, nothing about the migration logic changes; you inventory it, get the bank’s target version in writing, convert templates, and test, exactly as described above. Our validator carries the official schemas for all eleven versions, .03 through .13, for exactly this reason: mixed estates are normal, and “we only meet this version at one bank” is a routine finding, not an exception.

Finally, do not throw away the old knowledge when you switch. Keep the last accepted .03 file and its validation report with the run documentation, and note the date each bank accepted your first .09 file. If a question comes up months later — why does this report look different, when did the address format change — the paper trail answers it in minutes. Migration done this way is boring, and boring is the highest praise a payment process can earn. The version number in the namespace is a small thing. The calm around payday is the real deliverable.