ISO 20022 example files — pain.001 and pain.008 samples per country and rail

If you are connecting a system to a bank, writing a parser, or testing a mapping, you need sample ISO 20022 files that are correct for your country and your rail. The ones passed around are usually old, hand-edited, or from somewhere else. This page gives you files built from the public rulebooks, with a record of where each one comes from.

What you get

• 42 realistic payments across 17 countries: a UK CHAPS property purchase, a Swiss QR-bill, a Swedish Bankgiro run, a US ACH payroll, a SEPA direct debit, and more, each rendered in the message editions you are likely to meet.
• 131 schema coverage files across 13 editions: deliberately exhaustive files that exercise the elements and choices of one schema edition, for testing a parser or a mapping against the whole schema rather than the usual happy path.
• A provenance record beside every payment file saying where its content comes from, how far to trust it, and how the library checked it.

How to use it

1. Download the complete bundle below, or pick single files from the tables.
2. Open the .xml next to your own file and diff them; open the .provenance.yaml to see what the differences mean.
3. Get your bank's usage guideline (see below) and apply it on top: these files follow the public scheme rules, not any one bank's profile.

Identifiers are synthetic: IBANs, BICs, LEIs and account numbers pass their check digits but belong to nobody, and names and addresses are invented. Do not send these files to a bank.

Download#

Everything here is generated from pain001 0.0.70's own corpus, which also ships inside the Python package (pain001.corpus) and in the repository.

One scenario, end to end#

Take gb.chaps.property-purchase: CHAPS same-day property completion with the BoE HLST purpose code.

It ships as these files:

• gb.chaps.property-purchase.pain.001.001.03.xml: the payment in pain.001.001.03, and beside it gb.chaps.property-purchase.pain.001.001.03.provenance.yaml, its provenance record.
• gb.chaps.property-purchase.pain.001.001.09.xml: the payment in pain.001.001.09, and beside it gb.chaps.property-purchase.pain.001.001.09.provenance.yaml, its provenance record.

The provenance record answers the questions you would otherwise have to ask us:

• Where does the content come from? Bank of England: ISO 20022 purpose codes for CHAPS property transactions.
• How much can I trust it? Confidence derived: built from the public rulebook or implementation guide; no published sample was available to compare.
• How was it checked? By the library, against the schema, the ISO rules and the uk-chaps, purpose-mandate-gb profiles; the record lists every finding, including warnings.
• Is it exactly this file? Its SHA-256 is in the record.

What the record does not tell you is what your bank requires. That is the subject of the next section.

Your bank's guideline#

Every bank and clearing house publishes its own message usage guideline: which ISO 20022 elements it requires, which it ignores, and the values it accepts. Two banks on the same scheme can differ. Those guidelines are the bank's documentation, so they are not reproduced here: download them from your bank or financial organisation, typically from its client portal or from its collection on Swift MyStandards, and treat them as the final word.

The library is built for that step. Its overlay grammar expresses a guideline as a short list of rules (an element that must be present, one that must be absent, a value that must be one of a set), scripts/derive_overlay.py reads a guideline's schema and drafts those rules for you, and the corpus builder can then render any scenario on this page the way your bank wants it, privately, in your own environment. The corpus guide walks through it.

How the library checked these files#

These checks are the library's own; they are not a certification, and passing them does not mean a bank will accept the file. Channel rules, onboarding profiles, cut-off times and the bank's guideline sit on top.

Reading the evidence column. verified means checked against a sample the scheme itself published. derived means built from the public rulebook or implementation guide; no published sample was available to compare. assumed means one detail rests on an assumption the record names; treat that detail with care.

Payment files by country#

AE (AE)

Belgium (BE)

Switzerland (CH)

CZ (CZ)

Germany (DE)

Spain (ES)

France (FR)

United Kingdom (GB)

HK (HK)

Italy (IT)

Luxembourg (LU)

MY (MY)

Netherlands (NL)

QA (QA)

Sweden (SE)

SG (SG)

United States (US)

Schema coverage files#

Each edition has a small set of files built so that the elements and choice branches its schema declares each appear in at least one file. The first file is the baseline that carries every element once; each later file is named after the blocks it adds, so you can pick the one that exercises what you are testing. The coverage page lists every file with what it adds and a zip per edition.

Notes#

• The site publishes the generic files and their public sources. Bank-specific material stays with the banks.
• The corpus is English only and grows with every release; it is generated data, not a translated page.
• The corpus guide explains the scenario format, the overlay grammar and how to add a country or a rail. Corrections and new scenarios are welcome there.
• Regenerate this page and its downloads with poetry run python3 scripts/generate_corpus_page.py from the pain001 checkout after a corpus change.