pacs.002

pacs.002 is the ISO 20022 message called the FI To FI Payment Status Report. Financial institutions and payment system operators send it to report the status of a payment message they have received, such as a pacs.008 customer credit transfer or a pacs.009 bank-to-bank transfer. A pacs.002 can say that a payment has been accepted, rejected or is still being processed, and it can give a coded reason for a rejection. It is one of the most frequently exchanged messages in modern payment systems.

The message belongs to the "pacs" business area of ISO 20022, which covers payments clearing and settlement between institutions. It is the interbank counterpart of pain.002, which a bank uses to report the status of a customer's payment instruction back to the customer. In the SWIFT environment it is one of the MX messages used under the cross-border payments guidelines.

A pacs.002 has three main parts:

• Group header. A unique message identifier and the date and time the report was created.
• Original group information and status. A reference to the original message being reported on, including its identifier and type, and optionally a status for the whole group of transactions it contained.
• Transaction information and status. For each payment, references such as the original instruction identification, the end-to-end identification and, where used, the unique end-to-end transaction reference (UETR), together with the transaction status, any status reason and, optionally, key details of the original payment.

Because each status is tied to the original references, the sender can match the report automatically to the payment it sent.

Status values come from an external ISO 20022 code list. Commonly used codes include ACTC (accepted after technical validation), ACCP (accepted after customer profile checks), ACSP (accepted, settlement in process), ACSC (accepted, settlement completed), PDNG (pending) and RJCT (rejected). Not every system uses every code, and each scheme's rules say which ones apply.

When a payment is rejected, a reason code explains why. Examples from the external status reason code list include AC01 for an incorrect account number, AC04 for a closed account, AM04 for insufficient funds, BE01 when the account holder's details do not match the account, AG01 when the transaction is forbidden on that account, FF01 for an invalid file format and MS03 when the reason is not specified. Codes in the RR range indicate regulatory reasons, such as missing information required for screening. Free-text additional information can supplement the code.

Use varies by payment system:

• Instant payments. In schemes such as SEPA Instant Credit Transfer, the beneficiary's bank must accept or reject a payment within seconds. Its answer is sent as a pacs.002, which the scheme's clearing system forwards to the payer's bank. A positive pacs.002 confirms that the funds have been credited or made available, while a negative one rejects the payment and the payer's funds are released.
• RTGS and high-value systems. Central bank systems may send a pacs.002 to notify a participant that a payment has been rejected by validation or, depending on configuration, that it has settled.
• Cross-border payments. In correspondent banking, a bank that cannot process a payment it has received uses a pacs.002 to reject it back to the previous bank in the chain, rather than relying on free-format messages.
• Batch systems. Clearing houses use pacs.002 to report rejected transactions within a bulk file.

A pacs.002 rejection is different from a return. A rejection stops a payment before settlement, while money that has already settled is sent back using a separate return message, pacs.004, as described under returned payment.

Structured status reports allow banks to show customers the real transaction status of their payments, to trigger automatic actions such as releasing reserved funds, and to identify recurring problems with particular account formats or counterparties. Coded reasons are easier to analyse than free text, which helps banks reduce repeat errors and improves payment message validation upstream.

The value of a pacs.002 depends on how consistently it is used. Some systems send it only for rejections and not for acceptances, so the absence of a message may itself carry meaning. Reason codes are sometimes chosen loosely, especially the generic "not specified" code, which limits their usefulness. When payments pass through several banks and formats, status information may be lost or delayed if any party in the chain does not support the message, which is why tracking services and scheme rules increasingly make status reporting mandatory.