· ReadyStack
Worked example
Real numbers from this tool, line by line.
Eight lines out of 23 findings in one four-transaction SEPA batch are enough to have a bank return the whole file, and every one of them passes XSD validation. If you are the developer at an EU ERP integrator, or the engineer who owns the payment run inside a treasury team, those eight lines are your Monday morning.
A SEPA credit transfer file is judged before a human reads it. The gateway parses the XML, applies the scheme rules, and if one transaction breaks one of them the batch comes back whole. Not the bad transaction: the batch. Every invoice inside it stays unpaid, including the ones due that day.
The sample batch shipped with SEPA pain.001 Reject Lint has four transactions. The engine returns 23 findings: 21 errors and 2 warnings. Here is what is actually in there.
The document declares pain.001.001.03. That is the 2009 ISO 20022 version. The SEPA schemes carry the 2019 version, pain.001.001.09. It shows up in files built from an old template and in files generated by a model that learned from old examples, and a schema check run against the old schema will not see it.
One IBAN reads DE89370400440532013001. It looks right. It fails the ISO 7064 mod-97 check by one digit. The money never leaves.
CtrlSum declares 101430.51. The instructed amounts in the file add up to 100180.50. NbOfTxs declares 2. The file holds 4 transactions. Both of those are arithmetic the gateway redoes, and both are what a last-minute edit breaks.
ChrgBr is SHAR. The SEPA credit transfer scheme takes SLEV and nothing else.
One remittance line runs to 182 characters where 140 survive. The creditor sees 140 and guesses the rest.
One creditor name carries an umlaut. The SEPA Latin set is a-z A-Z 0-9 / - ? : ( ) . , ' + and space. A supplier name pasted from a PDF invoice is enough.
And EndToEndId INV-1 appears on two different transactions, which is exactly what makes a bank flag the batch as a double submission.
None of that is a schema problem. An XSD says whether the shape is legal. It has no opinion about whether the amounts add up, whether the check digits hold, or whether the message is the version the scheme is carrying this year. That is the gap this sits in.
The extension reads an open pain.001 file and marks each of those lines in the Problems panel with the rule and the line number. There are 25 rules, all checkable from the file alone: message version, UTF-8, CreDtTm shape, the 35-character identifier limits, SvcLvl, ChrgBr, ReqdExctnDt/Dt, stale execution dates, IBAN check digits and country, BIC shape, EUR and two decimals, CtrlSum, NbOfTxs, the 70-character name limit, the 140-character remittance limit, RF references under ISO 11649, duplicate and missing EndToEndId, and the character set.
One rule runs the other way. An instant transfer parked just under 100000 EUR gets flagged, because the old SCT Inst amount cap was lifted by the Instant Payments Regulation. Splitting a payment to stay under it is work nobody has to do any more.
By hand, this is 25 rule checks per transaction, read against the rulebook, repeated in full every time the file changes, because a single edit can break CtrlSum, NbOfTxs and a check digit at once. For a four-transaction batch that is 100 checks.
The free version does one open file against all 25 rules, in the editor or on the web page, with no key. That is the whole job for one file. The paid version cuts on a different axis: every payment file in the workspace in one pass, exported as JSON, CSV or Markdown you keep for the bank or the auditor.
15 seconds — what it actually does
Questions people ask
What does SEPA pain.001 Reject Lint actually do?
It reads a SEPA credit transfer XML file and marks every line a bank gateway will refuse, with the rule and the line number. It covers 25 rules: the pain.001.001.09 message version, IBAN mod-97 check digits, BIC shape, CtrlSum and NbOfTxs arithmetic, ChrgBr, the 140 character remittance limit, duplicate EndToEndId values and the SEPA Latin character set.
Who is this for?
Developers and payment operations engineers at EU companies who generate pain.001 files: ERP and accounting integrators, treasury teams building their own payment runs, and fintech engineers shipping a SEPA credit transfer feature. If a returned batch lands on your desk on a Monday morning, this is aimed at you.
Why is a free XSD validator not enough?
An XSD says whether the shape is legal, not whether the batch will clear. A file can validate perfectly against the schema while CtrlSum disagrees with the amounts, an IBAN fails its mod-97 check digits, a supplier name carries an umlaut, or the whole document still declares the retired pain.001.001.03 version. The schema has no opinion about any of those.
What is free and what does the paid version add?
Free checks one open file against all 25 rules and shows every finding with its line, in the editor or on the web page, with no key. The paid version adds a different axis: it scans every payment file in the workspace in one pass and exports the findings as JSON, CSV or Markdown that you keep and hand to the bank or the auditor.
What would this cost done by hand?
Reading a batch against the rulebook is 25 rule checks per transaction, repeated in full every time the file changes, because a single edit can break CtrlSum, NbOfTxs and a check digit at once. A four transaction batch is 100 checks. The licence is 29 dollars once,.
Why not just ask ChatGPT or another AI chat?
A general AI chat answers from training data with a cutoff date, cannot read your repository and names no rule version. SEPA pain.001 Reject Lint checks the file you open against 25 rules from a rule set dated 2026-09-20, and points at the exact line. For a filing, an audit or a client you need that dated result on your own files.
Ask about this tool
One question, answered by the person who built it. Your email only if you want the answer sent.