pain.001.001.09 versus .03: what actually changes

ARLing s. r. o. · 6 September 2026

pain.001.001.09 and pain.001.001.03 are both "Customer Credit Transfer Initiation" messages under ISO 20022. The number after the second dot is the schema version. If your accounting software or your bank's portal has started mentioning ".09" and you are still sending ".03", here is what is actually different in the file, and what is not.

Four concrete differences in the XML

The namespace on the root element

The root <Document> element declares a different namespace in each version. The bank's parser reads this value to know which schema to validate the rest of the file against.

.03  xmlns="urn:iso:std:iso:20022:tech:xsd:pain.001.001.03"
.09  xmlns="urn:iso:std:iso:20022:tech:xsd:pain.001.001.09"

The bank code element is renamed to BICFI

The BIC of the debtor's or creditor's bank sits inside <FinInstnId>. In .03 that value goes into <BIC>. In .09 the same value goes into <BICFI>. The value and its format do not change, only the element name does.

.03  <FinInstnId><BIC>TATRSKBX</BIC></FinInstnId>
.09  <FinInstnId><BICFI>TATRSKBX</BICFI></FinInstnId>

The execution date is wrapped in a choice element

In .03, ReqdExctnDt is a plain date string. In .09 it is typed as DateAndDateTime2Choice, so the value has to be wrapped one level deeper, inside <Dt>, or inside <DtTm> if the bank asks for an exact time rather than just a date. A file that keeps the .03 shape of this element but declares the .09 namespace is a common cause of a rejected import.

.03  <ReqdExctnDt>2026-11-20</ReqdExctnDt>
.09  <ReqdExctnDt><Dt>2026-11-20</Dt></ReqdExctnDt>

The address type changes name, not shape

The postal address of the debtor or the creditor is PostalAddress6 in .03 and PostalAddress24 in .09. The order of the fields that matter for a normal business address, StrtNm, BldgNb, PstCd, TwnNm, Ctry, is the same in both types. PostalAddress24 only adds extra, optional fields such as BldgNm, Flr, Room, or TwnLctnNm, and it limits free-text AdrLine to two lines instead of leaving it open.

The 15 November 2026 deadline is about the address, not the message version

This is where most of the confusion online comes from. The 15 November 2026 date comes from the SEPA Credit Transfer rulebook published by the European Payments Council, version 1.1. It applies to every SEPA scheme that carries an address: credit transfers, instant credit transfers, and direct debits, both Core and B2B. From that date, whenever a message contains a postal address, that address can no longer be pure free text. It has to carry at least the town and a two-letter country code in their own fields, either fully structured or in the so-called hybrid form (up to two lines of free text plus a separate town and country).

An address is optional in a SEPA credit transfer, so a file with no address at all is unaffected even after the deadline. The rule only bites when an address is present and written as one unstructured block.

The part that matters for this article: nothing in the rulebook ties that requirement to a message version. pain.001.001.03 can carry a fully structured address through PostalAddress6, described above, which already has a separate town and country field. Moving to .09 is not a condition for meeting the 15 November 2026 deadline. If your accounting export already writes the town and country into their own fields, a .03 file meets the address rule as it stands today.

One more point worth being explicit about, because it is a common mix-up: an earlier version of the same rulebook (version 1.0, from 2025) set the end of unstructured addresses at 22 November 2026. Version 1.1 corrected that to 15 November 2026. Some bank pages online still cite the older 22 November date; 15 November 2026 is the one in the current rulebook.

Each bank sets its own migration date, separately

Which pain.001 version a bank still accepts for a batch import is that bank's own decision, separate from the address rule above. There is no single answer across countries. Two concrete, dated examples:

Germany. The Atruvia network of cooperative banks, which includes GLS Bank, has published an exact date for batch payments: it stops accepting pain.001.001.03 from 14 November 2026. The German savings banks (Sparkassen) have said the same switch happens in November 2026, but without naming an exact day.

Czechia. This is a Czech bank's own published page, not a general rule: Komerční banka's support page describes a change in how address data is submitted from 20 June 2026, and a future version of its MultiCash client (5.0) with full pain.001.001.09 compatibility. The page does not state an explicit date for when .03 stops being accepted, even though some secondary summaries online imply one.

For reference, and again only as one national example and not a general SEPA rule: Slovak banks such as Tatra banka currently document their batch payment import against the pain.001.001.03 namespace. As of the date this article was checked, we found no publicly announced date for Slovak banks to stop accepting .03 or to require .09.

The pattern is the same across all three: the address rule comes from the European rulebook and applies everywhere on a fixed date. The message version a bank accepts is its own decision on its own timeline. The only reliable way to know it is to ask that bank directly or check its own technical documentation for batch payments.

What to actually check

1. Solve the address requirement by looking at the address, not the version. If your file's PstlAdr blocks already have a town and a two-letter country code in their own fields, you meet the 15 November 2026 rule in .03 as well as in .09.
2. Do not switch your accounting software's export to .09 only because you read about the November deadline. Ask your bank which version it expects for a batch import, ideally through its online banking help pages or its business support line.
3. If a file is offered to you in .09, or your software starts producing it, open it and check three things: the namespace on <Document>, whether the bank code sits in <BICFI> rather than <BIC>, and whether ReqdExctnDt has the date wrapped in <Dt> or <DtTm>.
4. If your bank still accepts .03 after November 2026, get that confirmed in writing, or check again after a few months. Banks can, and some already have, changed their own migration plans during 2026.

A free, purely format-level check of a pain.001 file, including which version it declares and whether its addresses have a town and country, is available at SEPA pain.001 Doctor. It runs in the browser and does not send the file anywhere. It is not a bank, it checks nothing against your actual account, and a clean result there is no guarantee that any bank will accept the payment: banks can change their own requirements at any time.