pain.007.001.13 CustomerPaymentReversalV13
ISO 20022 pain Messages
Request reversal of a previously executed payment; the specified usage covers a settled customer direct debit.
After the fictional January direct-debit collection is assumed settled, Example Services Ltd asks to reverse its EUR 125.00 collection because the service was not supplied. The request is created on 12 January 2026 and names the earlier pain.008.001.12 message DEMO-M008-001, batch DEMO-DD-BATCH-001 and its instruction/end-to-end references. It carries its own reversal identity and fictional proprietary reason. The original and requested reversed amounts are both 125.00 EUR. These facts describe the requested correction; they do not show a completed reimbursement, a confirmed debtor credit or cancellation of the underlying mandate.
This lesson’s customer usage is reversal of a settled CustomerDirectDebitInitiation. Preserve that scope rather than present pain.007 as a generic pre-settlement cancellation of pain.001. The original collection, requested correction and applicable service agreement determine the relevant business process; the message family name alone is not authority to reverse any payment.
Required children do not make optional parent structures mandatory. OrgnlGrpInf is required at the business root; OrgnlMsgId and OrgnlMsgNmId are required inside it. An included OrgnlPmtInfAndRvsl requires OrgnlPmtInfId, while its TxInf repetitions and the selected transaction’s amounts/reasons are optional locally. The receiving service can require more complete references and reasons. The detailed reference exposes the exact ancestor/choice context.
Reversal identification is not mandate identification, and reversal completion is not mandate cancellation. The original direct-debit instruction, the requested correction and any mandate-state action have separate identities and evidence. Their relationship should remain visible in investigations and reconciliation even when a bank stores them in different internal systems.
Catalogue availability is not scheme activation. The inspected 2025 EPC SDD Core customer-to-PSP guideline uses pain.007.001.09, pain.008.001.08 and pain.002.001.10, which differ from the mounted examples. Do not import its local constraints or service windows as pain.007.001.13 base-schema requirements. No legal refund right, universal deadline or certified SEPA processing is taught by this XML.
Current-date caveat checked 11 October 2026: September 2026 EPC notices postponed the earlier address-removal deadlines with replacement timing undetermined; Swift’s September 2026 roadmap warns that SR2026 postponement can invalidate displayed dates. These notices do not change the frozen example dates or establish this reversal’s eligibility. Consult the applicable current service and customer agreement before operational decisions.
The XML expresses a request; a valid request does not guarantee acceptance, a downstream reversal, movement of funds or successful reimbursement. Namespaces/XPath establish precise technical selection, while bank controls and account processing establish different facts. Illustrative case stores, APIs, queues and ledger joins are implementation choices, not architectures mandated by pain.007.
Explore the complete Payment Life Cycle