Overview pacs messages

Published on

08/09/2026

Updated on

08/09/2026

Reading time

3 min

In ISO 20022 the abbreviation pacs stands for Payments Clearing and Settlement. This family carries the actual movement of money between institutions: credit transfers, direct debits, their status reports and their unwinding. Where pain messages cover the customer-to-bank leg and camt messages carry account information and exception handling, pacs is the family of the interbank leg.

The life cycle of a payment

The family is manageable because it follows a single logic – the path of a payment from being passed on to a possible unwinding:

  • Payment instruction – the payment is passed to the next institution or to a clearing system. Depending on the payment type: pacs.008, pacs.003, pacs.009 or pacs.010.
  • Status report – pacs.002 rejects a payment. A positive confirmation exists only where the scheme provides for one, above all in instant payments.
  • Status request – if that report does not arrive, pacs.028 asks for the status explicitly.
  • Unwinding – a settled payment is returned with pacs.004, or a direct debit is reversed with pacs.007.

payment instructionpacs.008 · pacs.003 · pacs.009 · pacs.010status reportpacs.002 – rejection; confirmation only in instant paymentsstatus requestpacs.028 – when the status report does not arriveunwindingpacs.004 return · pacs.007 reversal

Overview of usage

The table below shows where each message actually occurs. What governs is always the rulebook of the environment concerned. Use the buttons to select an environment; the table then shows only the corresponding column. Switzerland and the handling in EBICS are topics of their own and follow below.

Select environment:
MessagePurposeSEPATARGET (T2)Swift CBPR+
Payment instructions between institutions
pacs.008customer credit transfer, interbankSCT and SCT InstRTGSyes
pacs.003customer direct debit, interbankSDD Core and B2Byes
pacs.009financial institution credit transfer (CORE and COV)RTGSyes
pacs.010financial institution direct debitRTGSyes
Status and status request
pacs.002payment status reportreject; confirmation only in SCT InstRTGSyes
pacs.028request for the statusSCT and SCT Inst
Unwinding
pacs.004return of a settled paymentall schemesRTGSyes
pacs.007reversal of a direct debitSDD

The environments in detail

SEPA

In the SEPA area pacs is the load-bearing family. The European Payments Council's Inter-PSP implementation guidelines rely on pacs.008, pacs.002, pacs.004 and pacs.028 for the credit transfer schemes SCT and SCT Inst, and on pacs.003, pacs.002, pacs.004 and pacs.007 for the direct debit schemes SDD Core and B2B.

One point is regularly misunderstood: in the bulk scheme SCT, pacs.002 is not an execution confirmation. The Inter-PSP implementation guidelines provide for it there only for dataset DS-03, that is for rejection. An institution submitting a credit transfer through a bulk clearing system receives no positive pacs.002 as a receipt – no response means acceptance. Instant payments are different: in SCT Inst the pacs.002 is the binding response and carries both the confirmation and the rejection.

Two further points are regularly confused. pacs.028 is confined to the credit transfer schemes and is not foreseen in SDD. And pacs.007 is not a general cancellation: the EPC core rulebook provides no reversal process for SCT, where unwinding after settlement runs on pacs.004. The reasons for returns travel in the SEPA reason codes and together form the R-transactions.

TARGET (T2)

In TARGET – T2 the RTGS component uses five pacs messages: pacs.008 and pacs.009 for credit transfers, pacs.010 for the financial institution direct debit, pacs.002 for status and pacs.004 for returns. pacs.009 appears in both variants, CORE and COV for cover payments. Customer direct debits under pacs.003 do not exist in RTGS.

Instant payments follow a different set: TIPS aligns with the SCT Inst scheme and therefore works with pacs.008, pacs.002, pacs.004 and pacs.028.

Swift CBPR+

In cross-border payments under Swift CBPR+, pacs.008 and pacs.009 in its CORE and COV variants carry the credit transfers, pacs.003 and pacs.010 the direct debits, pacs.002 the status and pacs.004 the return. These messages have replaced the former MT category 1 and category 2 formats. The status request pacs.028 is not part of this: tracking a payment here runs on the UETR and the Swift gpi tracker.

Switzerland

In Swiss payments the Swiss Payment Standards cover the customer-to-bank leg through pain and camt messages, while the interbank leg in the SIC system works with pacs messages. The cash management implementation guidelines published by SIX explicitly do not cover the pacs family; it is the subject of the interbank documentation.

Handling in EBICS

EBICS is the transport route, not the rulebook. One distinction matters for the pacs family: corporate customers submit their instructions as pain messages and receive account information as camt messages – they normally never see a pacs message. The conversion into a pacs.008 or pacs.003 happens inside the bank.

The interbank space is different: in Germany the connection to the Deutsche Bundesbank's SEPA Clearer runs over EBICS, and pacs messages are exchanged as files on that leg. The admissible format versions are set out in Appendix 3 of the DFÜ agreement. The pacs messages of the TARGET environment, by contrast, do not run over EBICS but over the channels of the TARGET Services.

Sources for specifications