Guides · Updated 2026-10-18
How to validate a pain.001 payment file
A pain.001 file is checked in layers: it must be well-formed XML, be a recognised message version, validate against the ISO 20022 schema (XSD) for that version, and for SEPA credit transfers also follow the EPC customer-to-PSP implementation guidelines. A file passes only if every layer passes.
What a pain.001 file is
pain.001 (CustomerCreditTransferInitiation) is the ISO 20022 XML message a company sends to its bank to initiate credit transfers. ERP and treasury systems such as SAP generate it from a payment run. The two versions in common use are pain.001.001.03 (2009) and pain.001.001.09 (2019); the 2025 SEPA implementation guidelines are written for pain.001.001.09.
The checks, in order
| Layer | What is checked | Typical cause of a failure |
|---|---|---|
| XML well-formedness | The file parses as XML (tags closed, valid encoding, not empty). | Truncated export, wrong encoding, manual edits. |
| Message detection | Root element and namespace identify a supported pain.001 version. | Wrong namespace, a different message type, or an unexpected version. |
| ISO 20022 schema (XSD) | Element order, mandatory elements, lengths, formats and code values from the official schema. | Missing mandatory element, value too long, wrong format (for example a currency code). |
| SEPA scheme rules | The EPC customer-to-PSP subset: TRF, SEPA service level, SLEV charge bearer, EUR, two decimals, IBAN/BIC usage, name lengths, character set and identifier rules. | Payment-method or bank master-data configuration in the source system. |
Schema validity is necessary but not sufficient: a file can be valid against the ISO 20022 XSD and still break SEPA rules, because SEPA is a stricter subset (for example names are limited to 70 characters, while the schema allows 140). See the full list in the rule reference.
PASS, REVIEW and FAIL
BankLint decides the verdict with deterministic rules; every finding names its rule, the element location and the source section it is based on.
- FAIL: at least one blocker. The bank is likely to reject the file or the payment.
- REVIEW: no blockers, but warnings that depend on your agreement with the bank (for example control sums that do not match) or, in a Flow, a configuration change compared with the bank-accepted baseline.
- PASS: no blockers and no warnings. Info findings are recommendations only.
What validation cannot tell you
For changes in your own setup, compare each new file with a file your bank already accepted. That is what payment-file regression testing does.
- Bank-specific requirements that are not in the ISO schema or the SEPA guidelines.
- Whether the payee data itself is correct (a well-formed IBAN can still be the wrong account).
- IBAN check digits: BankLint does not check them yet.
Questions
Is an XSD-valid pain.001 file always accepted by the bank?
No. The XSD only checks the ISO 20022 structure. SEPA credit transfers must also follow the EPC implementation guidelines, which are stricter, and banks can add their own requirements.
Which pain.001 versions does BankLint validate?
pain.001.001.09 and pain.001.001.03 against their ISO 20022 schemas. SEPA scheme rules are checked for pain.001.001.09, the version the 2025 EPC guidelines cover.
Is my file stored when I validate it?
No. Files are processed in memory and not stored. Signed-in Flows keep sanitized evidence (findings and non-sensitive facts), never the file.
Validate a pain.001 fileFree, no account needed, files are not stored.