pain.002 Reader Status Report
Open the status report your bank sent back, see accepted vs rejected transactions, and get each reason code explained — entirely in your browser, nothing uploaded.
What is a pain.002 file and why did my bank send one?
A pain.002 is the ISO 20022 "Customer Payment Status Report" your bank returns after you submit a pain.001 (credit transfer) or pain.008 (direct debit) file. It tells you, per transaction, whether the bank accepted it (status ACCP, ACSC…) or rejected it (status RJCT) — and for each rejection it carries a reason code such as AC04 (closed account) or AM04 (insufficient funds). This free tool reads the report locally, counts accepted vs rejected transactions, and translates every reason code into a plain-language explanation with a concrete next step — no data ever leaves your browser.
About the pain.002 status report reader
When you send a SEPA payment file (pain.001 for credit transfers, pain.008 for direct debits), the bank does not just process it silently — it sends back a pain.002 Customer Payment Status Report. This report mirrors the structure of the original file: a group-level status (OrgnlGrpInfAndSts/GrpSts), optional per-batch blocks (OrgnlPmtInfAndSts), and a status for every transaction (TxInfAndSts/TxSts) keyed by the original EndToEndId. A group can be fully accepted, fully rejected, or PART — partially accepted, meaning some transactions went through and others did not.
The value of a pain.002 is in its rejection reasons. Each rejected transaction carries a StsRsnInf block with an ISO reason code (Rsn/Cd) — AC04, AM04, MD01, RR04 and dozens more — and sometimes a bank-specific proprietary code (Rsn/Prtry) or free-text note (AddtlInf). These codes are cryptic on their own. ValidateFin translates each one into a short title and an actionable sentence in your language, and flags whether the rejection is retryable (fix and resend, e.g. insufficient funds) or final (resubmitting will not help, e.g. a closed account). The whole report is parsed in your browser: account numbers, counterparties and amounts never touch a server.
Why reading your pain.002 matters
- A pain.002 is your bank's answer to a payment file — ignoring it means missing which payments actually failed.
- Reason codes like AC04, AM04 or MD01 are cryptic; knowing what each means turns a rejection into a fixable action.
- Retryable vs final matters: resending an AM04 (insufficient funds) can work, but resending an AC04 (closed account) never will.
- A partially-accepted (PART) batch is the dangerous case — some payments went through, some did not, and only the transaction-level status tells you which.
- Because a status report contains account numbers and counterparties, reading it locally in the browser avoids exposing sensitive payment data.
Frequently asked questions
What is a pain.002 file?
pain.002 is the ISO 20022 Customer Payment Status Report a bank returns after receiving a pain.001 or pain.008 payment file. It reports, per transaction, whether the payment was accepted or rejected and, for rejections, a reason code explaining why.
What do the status codes mean?
ACCP, ACSC, ACSP and ACTC are accepted states (the payment is progressing or settled). RJCT means rejected. PART at group level means the batch was partially accepted — check each transaction status. PDNG means pending.
What are reason codes like AC04 or AM04?
They are ISO 20022 reason codes explaining a rejection. AC04 means the account is closed, AM04 means insufficient funds, MD01 means no valid mandate, and so on. This tool translates each code into a plain-language title and advice.
Can I fix a rejected payment and resend it?
It depends on the reason. Retryable reasons (insufficient funds, a wrong amount, a malformed IBAN) can be corrected and resent. Final reasons (closed account, deceased holder, duplicate) mean resubmitting will not help — the tool marks which is which.
Is my status report uploaded anywhere?
No. The pain.002 file is read and parsed entirely in your browser with JavaScript. No account numbers, counterparties or amounts are ever sent to a server.
Which pain.002 versions are supported?
The reader supports the common SEPA versions pain.002.001.03 and pain.002.001.10, including both the flat (transactions under the group) and nested (transactions under payment-info blocks) layouts.