pacs.002 Status Reports Explained

In modern payment schemes, sending money is only half the conversation. The other half is knowing what happened to it. In the ISO 20022 world, that answer arrives as a pacs.002 message — formally the FIToFIPaymentStatusReport. Every instant payment that resolves in seconds does so because a pacs.002 travels back to confirm acceptance or rejection. If you build on modern rails, this is one of the most important messages to understand.

Where pacs.002 sits in the message family

ISO 20022 organises messages into business areas identified by a four-letter prefix. The pacs family covers payments clearing and settlement — the interbank messages that actually move money. A credit transfer is carried by pacs.008 (FIToFICustomerCreditTransfer). The response to it — confirming whether the receiving bank and scheme accepted the transfer — is the pacs.002. So the pair works as request and response: pacs.008 says "here is a payment", pacs.002 says "here is what happened to it".

The same status report is reused elsewhere. It can acknowledge a pain.001 customer payment initiation, respond to a pacs.003 direct debit, or report on a return. Because one message type reports status across many flows, learning it once pays off repeatedly.

What the message carries

A pacs.002 is built around identifiers that let both sides tie the status back to the original payment. The key elements include:

• OriginalGroupInformation — references the original message identifier and message name, so you know which batch this responds to.
• OriginalEndToEndIdentification and OriginalTransactionIdentification — pinpoint the exact payment being reported on, which is essential when a file contained many.
• TransactionStatus — the code that says accepted, rejected, or pending.
• StatusReasonInformation — when something went wrong, a reason code and optional narrative explaining why.

A single pacs.002 can report on a whole group or on individual transactions within it, which is why the original references matter so much for reconciliation.

The status codes that matter

TransactionStatus uses four-letter ISO codes. The ones you meet most often are:

• ACCP — AcceptedCustomerProfile: the payment passed initial validation.
• ACSC — AcceptedSettlementCompleted: settlement is done and funds are with the beneficiary. On instant rails this is the confirmation the payer waits for.
• ACSP — AcceptedSettlementInProcess: accepted and moving through settlement.
• RJCT — Rejected: the payment failed and will not proceed; a reason code explains why.
• PDNG — Pending: no final outcome yet, awaiting further processing.

The exact set a scheme uses is defined in its rulebook. An instant scheme typically expects a definitive ACSC or RJCT within seconds, whereas a batch scheme may send an ACCP first and settle later.

Reason codes on rejection

When the status is RJCT, the value is in the StatusReasonInformation. ISO 20022 defines a standard external code list so rejections are machine-readable rather than free text. Common reasons include AC04 (account closed), AC01 (incorrect account number), AM04 (insufficient funds), MD07 (beneficiary deceased) and RR04 (regulatory reason). A well-designed system maps these codes to concrete next steps — retry, correct the account, or notify the customer — instead of surfacing a raw code to a confused user. Keeping this mapping current matters because scheme rulebooks periodically add or retire codes, and a stale mapping silently degrades into unhelpful generic errors.

Positive and negative confirmations

It helps to remember that a pacs.002 is used for both good news and bad. A positive status report confirms acceptance and, on instant rails, is the trigger that lets the payer's app show a green tick. A negative report carries the rejection and its reason so the payer can act. Some schemes only require a status report on rejection or on request, while instant schemes mandate an unconditional response for every payment — so always check the specific rulebook to know when a pacs.002 is guaranteed to arrive and what its absence means.

Why timing is central

On instant-payment rails, the pacs.002 is on the critical path of the user experience. Schemes such as SEPA Instant impose a strict end-to-end deadline — the payer's bank must receive a definitive status within seconds, or the payment is treated as failed and unwound. This makes the pacs.002 not just a receipt but a time-boxed commitment. If a receiving bank cannot decide in time, the safe outcome is a timeout and reversal, because leaving the payer uncertain is worse than a clean failure they can retry.

Key takeaways

• pacs.002 is the ISO 20022 payment status report that answers what happened to a payment.
• It pairs with pacs.008 credit transfers and also reports on other initiation and clearing messages.
• Original references let the status be tied back to a specific transaction for reconciliation.
• Status codes like ACSC (settled) and RJCT (rejected) drive the payer's confirmation experience.
• Standard reason codes make rejections machine-readable, and instant rails demand a status within seconds.