Overview pain messages

Last updated: 9 September 2026

In ISO 20022 the abbreviation pain stands for Payments Initiation. This family covers the leg between customer and bank: the customer instructs a payment, the bank reports the status back. That is where its scope ends – passing the payment between institutions is the job of the pacs family, and account information comes from camt messages.

Where pain stops

This boundary is the key to understanding the family and at the same time the most common confusion: a corporate customer submits a pain.001 and receives a pain.002. What the bank makes of it – a pacs.008 to the clearing system – the customer never sees. Conversely, there is no pain message for the interbank leg.

Overview of usage

The table below shows where each message actually occurs. Use the buttons to select an environment; the table then shows only the corresponding column. The handling in EBICS is a topic of its own and follows below.

The environments in detail

SEPA

For the SEPA area the European Payments Council publishes separate Customer-to-PSP implementation guidelines per scheme. They rely on pain.001 for SCT and SCT Inst, on pain.008 for SDD Core and B2B, and throughout on pain.002 for the status report. pain.007 is the reversal by the originator and belongs to the direct debit space.

One detail that regularly surfaces in projects: the ISO catalogue now lists considerably higher versions than those used in SEPA – pain.001 stands at V13 there, pain.002 at V15. What governs is not the newest ISO version but the one fixed in the relevant rulebook. Working from the ISO catalogue instead of the guidelines means building past the scheme.

Mandates and payment requests

Two groups are not payment instructions in the narrow sense. The mandate messages pain.009 to pain.012 belong to the e-mandate service of the SDD scheme: requesting, amending and cancelling a mandate, plus the report on its acceptance. pain.013 and pain.014 carry the payment request in SEPA Request-to-Pay – the creditor asks to be paid, the debtor decides.

Switzerland

In Switzerland pain is the load-bearing family of the customer-to-bank leg. The Swiss Payment Standards issued by SIX cover pain.001 for credit transfer instructions, pain.002 for the status report and pain.008 for the direct debit schemes LSV+ and BDD. The current version of the business rules applies from 14 November 2026. Mandate messages and payment requests are not part of those guidelines.

Swift

Here the absence is the point: Swift CBPR+ covers the interbank leg, and pain messages are not part of its scope. Corporates using SCORE are under no obligation to migrate to ISO 20022; the exchange of pain.001 and pain.002 is agreed bilaterally between bank and customer. pain messages likewise do not appear in the TARGET – T2 message catalogue: the TARGET Services begin behind the customer interface.

Handling in EBICS

EBICS is the transport route that matters for exactly this family in Germany. The customer submits instructions as a file, and the order type determines which message type is expected: an order type for the SEPA credit transfer carries a pain.001, one for the direct debit a pain.008. The response is collected as a pain.002, account information separately through the camt order types.

Which format versions are admissible is governed neither by ISO nor by the EPC rulebook alone, but by Appendix 3 of the DFÜ agreement. For German corporates it is the binding reference and is updated annually – version 26.11 applies from 15 November 2026.

Sources for specifications

• ISO 20022 – Message Definitions
• EPC – SCT Customer-to-PSP Implementation Guidelines
• EPC – SDD Core Customer-to-PSP Implementation Guidelines (PDF)
• EPC – SDD Core e-Mandate Service Implementation Guidelines (PDF)
• SIX – Swiss Payment Standards, Business Rules (PDF)
• Swift – ISO 20022 FAQ: Corporates
• Die Deutsche Kreditwirtschaft – data format specification (Appendix 3 of the DFÜ agreement)