Two rules land in November 2026, ten days apart. AIB stops processing its older bulk payment formats after 12 November. From 22 November, every SEPA credit transfer needs a town and a country in each postal address, each in its own field. Most accounting systems still export files that break both rules.
We have spent the last few weeks fixing exactly this for a client in Ireland. Here is what changes, how to check your own files, and what to do if your accounting system cannot export the new format in time.
What is a pain.001 file?
pain.001 is the ISO 20022 XML message a company sends its bank to start credit transfers. One file carries a batch of payments: who pays, who is paid, the IBANs, the amounts and the execution date. Accounting systems such as Twinfield and Xledger export it, and the finance team uploads it to the bank or sends it over SFTP.
The bank checks the file against the ISO schema (the XSD) and against its own rules before it pays. A file that fails either check is rejected, as a whole or payment by payment.
What changes at AIB on 12 November 2026?
AIB stops processing its older bulk payment file formats after 12 November 2026. Files have to follow AIB's pain.001.001.09 specification. AIB sets this out on its ISO 20022 page.
What changes for SEPA payments on 22 November 2026?
From 22 November 2026, SEPA payments only accept structured and hybrid postal addresses. The town (TwnNm) and the country (Ctry) are mandatory in every address. One free-text line holding the whole address is rejected. Bank of Ireland describes it in its pain.001.001.09 file structure.
The rule comes from the European Payments Council, so it is not only an Irish rule. Every bank that processes SEPA credit transfers applies it.
What is the difference between pain.001.001.03 and pain.001.001.09?
pain.001.001.03 is the 2009 version of the message, and it is still what most accounting systems export. pain.001.001.09 is the 2019 version, which the European Payments Council adopted for SEPA in November 2023. It adds structured address elements, the LEI and a few other fields, and some elements move or change name.
Converting is not a find and replace on the namespace. The group header, the execution date, the address and the bank-specific identifiers all change, and every bank publishes its own rules on top of the standard.
What does a rejected address look like?
This is the unstructured address most exports still write. From 22 November it fails, because there is no town element:
<PstlAdr>
<Ctry>IE</Ctry>
<AdrLine>Unit 4, Quay Road, Dublin 2</AdrLine>
</PstlAdr>
This hybrid address passes. The street stays as it was typed, and the town and the country sit in their own elements:
<PstlAdr>
<TwnNm>Dublin</TwnNm>
<Ctry>IE</Ctry>
<AdrLine>Unit 4, Quay Road</AdrLine>
</PstlAdr>
A structured address goes further and splits everything: street (StrtNm), building number, post code, town and country. For files coming out of an accounting system, hybrid is usually the practical route, because nobody has to re-type the street.
How do I check whether my files will be rejected?
- Open the last file you sent and look at the namespace on the
Documentelement. If it ends inpain.001.001.03, the file is the old version. - Search for
PstlAdr. Any address with anAdrLineand noTwnNmfails from 22 November. - Look at the requested execution date. In version 09,
ReqdExctnDtwraps the date in aDtelement. - Validate the file against the XSD and against your bank's own guidelines. Passing the ISO schema is not enough on its own.
What if the accounting system cannot export pain.001.001.09 in time?
That was our client's situation. The Twinfield exports were still pain.001.001.03, with supplier addresses typed as one line. Nobody re-types hundreds of addresses in a week.
So we put agents between the export and the bank. They read the file, complete each address with its town and country, flag what the bank would reject (no town, the whole address in one line, a date already past) and write a pain.001.001.09 file. Before it goes to the bank, the file is checked against the ISO 20022 schema, Bank of Ireland's rules and the control totals in the header.
The full case is on Twinfield files that AIB and Bank of Ireland accept.
Where Alongside fits
We automate the work between accounting systems and banks: exports from Twinfield, Xledger, Exact, Sage and others, converted, checked and delivered to the bank. You can see how on the finance automation page. If your payment files have to change this month, write to hi@alongside.team.



