pacs.002 ISO 20022 message

Published on

10/01/2024

Updated on

22/09/2026

Reading time

3 min

Last updated: 22 September 2026

The pacs.002 is the ISO 20022 message FIToFIPaymentStatusReport. A clearing system or an institution uses it to report back the status of a credit transfer or direct debit sent earlier. A common misconception: that it is the receipt confirmation everywhere. It is not. In the SEPA bulk schemes it reports rejections only (no feedback means the payment was accepted). Only in instant credit transfers does it become a genuine confirmation.

How it differs from neighbouring messages

The line between it and the pacs.004 is settlement: before settlement a payment is rejected with the pacs.002 (reject), after settlement it is sent back with the pacs.004 (return). In the SEPA schemes both belong to the same data set, but they are not interchangeable.

The pacs.028 runs the other way: it asks for a status, it does not report one. And in the customer-to-bank relationship the counterpart of the pacs.002 is the pain.002 – same task, different layer. The whole family is set out in the entry Overview pacs messages.

Structure and status codes

The message is lean. The group header is followed by the reference to the original message (OrgnlGrpInfAndSts) and, per individual payment, a status block (TxInfAndSts) carrying the original references and the status code TxSts. Where a payment is rejected, the reason is added in StsRsnInf.

Two status codes are in use across the SEPA schemes: ACCP for acceptance and RJCT for rejection. Cross-border payments add further ones – ACSP once the checks have been passed, and ACSC once settlement is complete. In SEPA, the reason codes for rejections are set out per scheme in the EPC Guidance on Reason Codes.

When does a pacs.002 come back – and what does it say?Institutionsends the paymentSEPA SCT and SDD – the bulk schemesSEPA-Clearerclearing and settlementpacs.008 or pacs.003 in a bulk filepacs.002 only on rejection (reject)No feedback means the payment was accepted.In the bulk schemes there is no positive pacs.002.It reports rejections before settlement, nothing else.SEPA SCT Inst – the instant credit transferTIPS or RT1clearing in secondspacs.008 as a single paymentpacs.002 always – ACCP or RJCTTarget five seconds, time-out after seven.Here the pacs.002 is the confirmation: only with it is it settledwhether the funds are available to the payee.T2 – individual paymentsT2 / RTGSsettlement in central bank moneypacs.008, pacs.009 or pacs.004pacs.002 on the payment orderLiquidity transfers are acknowledged by the camt.025 instead.In T2 the pacs.002 accompanies the payment orders.A different message acknowledges the liquidity transfer.Swift CBPR+ – cross-border paymentsnext institutionin the payment chainpacs.008 or pacs.009pacs.002 – RJCT is mandatoryPositive statuses are agreed bilaterally.The rejection is the binding part; whether positive statusesare exchanged as well is for the institutions to agree.

Usage

SEPA SCT

In SCT the pacs.002 carries data set DS-03 as a reject. The EPC inter-PSP implementation guidelines know exactly two forms for that data set: the reject as a pacs.002 and the return as a pacs.004. No positive feedback is provided for. The SEPA-Clearer of the Deutsche Bundesbank reports rejections back to the payer’s institution either bundled in a file or as an individual message.

SEPA SDD

For direct debits the logic is the same under a different number: data set DS-05 covers reject, return and refund; within it the pacs.002 covers the reject alone, while return and refund run over the pacs.004. Here, too, there is no positive feedback.

SEPA SCT Inst

In instant credit transfers the message changes character. Data set DS-03 is called confirmation message here and is used in both directions: positive confirmation with ACCP, negative with RJCT, both as a pacs.002. That makes it booking-relevant – only with it is it settled whether the amount is available to the payee. Deadlines apply: counted from the time stamp of the payer’s institution, the confirmation should be available after five seconds, and at the latest after seven seconds it must have reached the clearing and settlement mechanism of the payee’s institution. It is carried over TIPS or RT1.

T2

In T2 the pacs.002 reports the status of payment orders – customer payments, banks’ own payments and returns. It does not apply to liquidity transfers; their status is acknowledged by the camt.025.

Swift CBPR+

In cross-border payments under CBPR+ the rejection is the binding part: a pacs.002 with RJCT is the prescribed way of informing the sender that a payment has been rejected. Positive statuses may be sent by any institution in the chain – whether and in what depth is agreed bilaterally between the parties. These status messages are also what tracking through Swift gpi builds on.

Versions

The EPC inter-PSP implementation guidelines 2025 specify the same version for all three schemes – SCT, SDD Core and SCT Inst: pacs.002.001.10. It is based on the 2019 version of ISO 20022. A change of version is due with the next development cycle of the EPC schemes; the version currently in force is stated in the implementation guidelines of the scheme concerned.

Sources for specifications