pain.001 Payment File Checker (Technical Pre-Check)

What is checked. The version and variant (from the namespace, for example pain.001.001.03 or the Swiss .ch variants), the group header (message ID, creation time, initiating party), the number of transactions and the control sum at message and at payment-block level (compared exactly, with no rounding drift), the execution date, debtor and creditor names against the length limit of the version (70 characters up to version .08, 140 from .09), IBAN format and mod-97 checksum, BIC format, amounts (positive, number of decimals for the currency), currencies, SEPA basics (EUR, charge bearer SLEV), duplicate end-to-end, instruction and payment-information IDs, the structured creditor reference (RF check digits) and the rule that unstructured and structured remittance information are not mixed.

Schema check. For versions .03 and .09 the file is also checked against the ISO 20022 base schema in your browser. The schema describes structure only; country and bank variants (for example the Swiss .ch versions or German DK rules) are stricter subsets of it, so a file can pass the schema and still be rejected by a bank.

Addresses. Every debtor and creditor address is classified. A structured address uses separate elements and needs at least a town name (TwnNm) and a country (Ctry); street, building number and postal code are recommended. A hybrid address has that minimum plus up to two AdrLine elements of 70 characters. An unstructured address consists only of AdrLine elements. Swiss banks and the SWIFT cross-border (CBPR+) messages are ending support for fully unstructured addresses around November 2026, and the exact dates differ per bank (UBS and PostFinance, for example, name different dates), so unstructured addresses are flagged, as is a building number written inside the street name.

Report. Findings are sorted by severity and name the payment block and transaction they refer to. You can download the report as Excel (findings and a payment list), as CSV or as JSON.

pain.001 XML files up to 40 MB. Versions .02 to .12 are read; the checks for name length, addresses and structure use the version in the namespace, and the schema check is available for .03 and .09. Direct debit files (pain.008) and status reports (pain.002) are recognised and refused with an explanation.

1. Drop the pain.001 XML file onto the box.
2. Read the summary: version, number of payments, totals per currency and how many addresses are structured, hybrid or unstructured.
3. Go through the findings from the top. Errors are things a bank would probably reject; "check" items are rules that differ between banks.
4. Fix the file in your accounting or banking software, export it again and re-check it. Download the report if you need to send it to someone.

• Checking a payment file generated by accounting software before uploading it to e-banking
• Finding out why a bank rejected a pain.001 upload
• Preparing for the end of unstructured addresses by seeing which payments still use them
• Testing the export of a new ERP or payroll system
• Comparing the totals in a file with the control sum the software wrote

This is not an official or bank validator. It cannot know your bank's implementation guide (character sets, accepted payment types, limits, cut-off times, which address forms are accepted), and it does not confirm that an account exists or that funds are available. Some banks accept what this check flags, and some reject what it passes.

The dates and rules for structured addresses are announced by banks and payment bodies and change; the warning text names the direction, not a date you can rely on. The ISO schema used here was taken from a package that redistributes the published ISO files (see the provenance note in the site's schema folder), so compare it with the files on iso20022.org if exactness matters.