← All guides

How to validate a pain.001 file before your bank rejects it

A step-by-step pre-flight check for ISO 20022 pain.001 credit transfer files: schema, control totals, IBANs, SEPA rules and bank guidelines — in the same order banks check them.

Every month, finance teams export a payment file from their ERP system, upload it to the bank portal, and wait. Most of the time the file goes through. But when it does not, the message is usually short and unhelpful: file rejected. Salaries sit unpaid, suppliers chase late fees, and somebody has to find one bad line inside a file that may hold thousands of payments. The painful part is that almost every rejection is caused by a small, boring, checkable mistake — a total that is one cent off, one IBAN with a mistyped digit, a date that fell on a Sunday. This guide walks through how to validate a pain.001 file before you send it, in the same order a bank will check it, so you can fix problems while they are still cheap.

Pain.001 is the ISO 20022 message for customer credit transfer initiation. In plain words, it is the XML file that tells your bank: take this money from our account and pay these people. The bank does not read it like a human reads a letter. It runs the file through layers of automated checks, and each layer can stop the whole file. Validation means running those same layers yourself, first. If you want the short version, you can validate your file with our free tool right now and read the results alongside this guide. The free plan checks five files a month, which is enough for most monthly payment runs.

Step 1: Confirm the file is well-formed XML and the right version

The first check is the dumbest and the most common failure after a system change: is the file even valid XML, and does its namespace match the version your bank expects? A pain.001 file declares its version in the root element, for example pain.001.001.09 or pain.001.001.03. If your ERP was updated and quietly switched versions, or a template edit broke a closing tag, the bank stops at the door. Open the file in any text editor and look at the first lines. The namespace should name one version, the tags should be balanced, and the encoding should be UTF-8. Version mix-ups are so common that we wrote a separate guide on the differences between pain.001.001.03 and pain.001.001.09 and when to migrate.

Also check the file size and the batch shape at this stage. A file that is empty, truncated, or suddenly ten times larger than last month is telling you something went wrong upstream, long before any rule about money applies. Compare this file with the last one that was accepted: similar size, similar number of payment groups, similar total. This two-minute sanity check catches export jobs that ran twice, exports that stopped halfway, and test files that were uploaded by mistake. Banks will not tell you any of this; they will just reject the file, and the clock on your payment deadlines keeps ticking while you guess.

Step 2: Run the official XSD schema check

The second layer is the schema. ISO 20022 publishes an XML Schema Definition, called an XSD, for every pain.001 version. The XSD is a strict grammar: it lists every allowed element, the order elements must appear in, which ones are required, and the shape of each value, such as a date, a decimal amount, or a code from a fixed list. If an element is misspelled, out of order, or holds a value of the wrong shape, the schema check fails with the element name and a line number. This is the layer most free online XML validators can run, and it is necessary — but it is not sufficient, as our guide on schema-valid files that still get rejected explains.

There are eleven pain.001 versions in live use, from pain.001.001.03 to pain.001.001.13, and the details differ between them: element names changed, some fields were added, others were tightened. Validating a .09 file against the .03 schema produces nonsense errors, so the tool you use must pick the schema that matches the namespace in the file. Our validator ships the official XSD for all eleven versions and selects the right one automatically. When you read a schema error, fix the first one first: XML parsers often report a cascade of follow-on errors that all disappear once the real, first problem is corrected. Then validate again, because a file can hold more than one structural problem.

Step 3: Recompute the control totals and counts

The third layer is arithmetic. A pain.001 file carries its own summary numbers: NbOfTxs, the number of transactions, and CtrlSum, the sum of all amounts. They appear in the group header for the whole file and again inside each payment information block. The bank recomputes them from the actual transactions and compares. If your file says the total is 20,630.00 but the payments add up to 20,630.75, the file is rejected — even if every single payment is perfect. This is the single most common reason ERP exports fail, because the header is often written by a different code path than the transactions, and rounding or a late manual edit makes them drift apart.

You can check this by hand for a small file: count the CdtTrfTxInf elements, add up every InstdAmt with a calculator, and compare with both levels of NbOfTxs and CtrlSum. Use exact decimal arithmetic — a spreadsheet that stores money as floating point can hide a one-cent error or invent one. For anything beyond a handful of payments, let software do it; the counting is easy for a machine and miserable for a person. Our deep dive on how CtrlSum and NbOfTxs are calculated shows the two-level structure with worked examples. On Pro plans, when the only errors are wrong counts or totals, you can even download a corrected file with the header values recomputed for you.

Step 4: Check every IBAN and BIC

The fourth layer is account numbers. Every debtor and creditor account in a SEPA file is an IBAN, and every IBAN carries two check digits that are computed from the rest of the number with the mod-97 algorithm. A single mistyped digit breaks the check digits, which means the bank can detect a typo with certainty — and will reject the payment. IBANs also have a fixed length per country: 22 characters for Germany, 27 for France, 18 for the Netherlands. A German IBAN with 21 characters is wrong before anyone even runs the maths. If an IBAN fails, do not try to fix the check digits; go back to the source document, because the account number itself was copied wrong.

BICs, the bank identifier codes, are simpler: they follow the ISO 9362 format of 8 or 11 characters, with a two-letter country code in positions five and six. The format check catches typos, but it cannot tell you whether the BIC belongs to the same bank as the IBAN — for SEPA payments inside the EEA the BIC is often derived from the IBAN or not required at all, which is why a wrong BIC survives in master data for years and then breaks a cross-border payment. If IBAN check digits are new to you, our plain-English explainer on IBAN mod-97 works through a real example digit by digit. Checking every IBAN in the file, every time, takes a script seconds and saves the worst kind of rejection: the one found after the payment deadline.

Step 5: Apply the SEPA scheme rules

The fifth layer is the rulebook of the scheme your payment travels on. For euro payments in Europe that is the SEPA Credit Transfer scheme, run by the European Payments Council. Its rules sit on top of the ISO standard and are stricter in specific places: amounts must be in euro, the charge bearer must be SLEV, names and references may only use the SEPA character set, and structured creditor references must pass their own check digit test. None of these rules appears in the XSD, so a file can pass the schema check with flying colours and still break three scheme rules. That gap between valid and acceptable is exactly where most real-world rejections live.

Work through the scheme rules as a checklist. Is every amount EUR? Does every payment block carry ChrgBr with the value SLEV? Do names contain characters outside the SEPA set — an ampersand typed by a supplier, an accented letter pasted from a spreadsheet? Are execution dates real banking days, not weekends or holidays in the debtor country? Are EndToEndId values unique inside the file, so the bank and your own reconciliation can tell payments apart? Each of these has its own guide in this series, because each one has its own traps: the SEPA character set, the SLEV charge bearer rule, and the uniqueness rules for MsgId and EndToEndId are the three we see most often.

Step 6: Think about your bank’s own guidelines

The last layer is the one nobody outside banking talks about: your bank’s implementation guidelines, known as MIGs. On top of the ISO standard and the scheme rulebook, each bank publishes its own tighter profile — this field is mandatory for us, that optional field is ignored, files must arrive before this cut-off time, one file may hold at most this many payments. A file that passes layers one to five can still fail layer six at one specific bank while a different bank accepts the same file without complaint. You cannot fully test for a MIG you do not have, but you can remove surprises: ask your bank for its current pain.001 guidelines, note the version it accepts, its batch size limits and its cut-off times, and keep that note with your payment run checklist.

Keep a copy of the last file your bank accepted. When a new file is rejected and the error message is vague, diffing the new file against the last known-good one is often the fastest detective work there is: a new element appears, a familiar one moves, a code changes spelling. Banks upgrade their checks on their own schedule, usually announced in the guidelines and easy to miss. When the same file passes your validator but fails at the bank, the difference is almost always in this layer, and the accepted-file comparison tells you where to look first. Treat every unexplained rejection as a prompt to update your checklist, so the same surprise never costs you twice.

A pre-flight checklist you can reuse

None of these steps needs to be slow. A validator runs all six automated layers in well under a second for a normal payment file — our own engine averages a few milliseconds per file — so there is no excuse for the check to be a monthly event done under time pressure. Build it into the payment run: export, validate, fix, then upload. If you validate batches for a whole finance team, or you need the report as a file your auditor can keep, the paid plans add batch validation for up to 10 or 50 files at once and JSON or CSV exports; see the pricing page for the exact limits of each plan. The point of the checklist is not the tool, though. It is the habit: never let the bank be the first system to read your file carefully.

One last habit separates teams that get rejected once from teams that get rejected every quarter: keep the validation report. When a file passes, save the summary next to the payment run. When something later goes wrong — a supplier claims non-payment, an auditor asks why a batch was late — you can show exactly what was checked and when. And when a rejection does happen, save that report too, next to the bank’s message. Patterns jump out over a few months: the same supplier whose name always contains a forbidden character, the same ERP export that drops a cent when a credit note is included. Fix the pattern, not just the file, and the rejections quietly stop.