pacs.002 FI to FI Payment Status Report

When pacs.002 is used

A reject is used when the payment has not been settled yet and the receiving bank cannot process it: the creditor account does not exist, the BIC is wrong, regulatory data is missing. The bank sends a pacs.002 with status RJCT and a reason code to the bank it received the payment from. Nothing has moved, so nothing has to be returned.

Once a payment has been settled, a problem further down the chain is handled with a pacs.004 return instead, because the money must flow back. The settlement method decides which applies first: with INDA the receiver has not yet debited the sender’s account and can reject; with INGA the sender has already credited the receiver, so the receiver must return.

Positive statuses (received, accepted, settled, credited) are optional and used only where banks agree on them bilaterally or a scheme requires them. Rejects are mandatory in CBPR+.

In each hop the status goes back to the immediate sender only. If bank C rejects to bank B after B has already settled with A, bank B then has to return the funds to A with a pacs.004.

Versions in common use

pacs.002 key elements

Paths are relative to Document/FIToFIPmtStsRpt. Occurrence is from the base message (pacs.002.001.10); market practice such as CBPR+ or a CSD’s rules can make an optional element mandatory or forbid it.

Rules worth knowing

• Transaction status codes: RJCT rejected; RCVD received; ACTC accepted after technical validation; ACCP customer profile check passed; ACWC accepted with change; ACSP accepted, settlement in process; ACSC settlement completed (for this leg); ACWP accepted without posting to the creditor’s account; ACCC settled on the creditor’s account; PDNG pending.
• A RJCT can only be sent before settlement. After settlement the bank must return the funds with a pacs.004.
• Reason codes often seen in rejects (ISO names; some schemes allow a code only for returns, for example SEPA uses AC04, AC06, AG01 and BE04 for returns only): AC01 Incorrect Account Number, AC04 Closed Account Number, AC06 Blocked Account, AG01 Transaction Forbidden, AG02 Invalid Bank Operation Code, AM05 Duplication, BE01 Inconsistent With End Customer, BE04 Missing Creditor Address, CNOR Creditor Bank Is Not Registered, DNOR Debtor Bank Is Not Registered, ED05 Settlement Failed, FF01 Invalid File Format, MS03 Not Specified Reason Agent Generated, RC01 Bank Identifier Incorrect, RR01 Missing Debtor Account Or Identification, RR02 Missing Debtor’s Name Or Address, RR03 Missing Creditor’s Name Or Address, RR04 Regulatory Reason, TM01 Cut Off Time.
• Some codes cannot be used in some countries for data protection reasons (for example AC04 or the RR codes in parts of SEPA), so a bank may send MS03 instead. MS03 is meant as a last resort, not a default.
• The codes come from an external code list that ISO 20022 updates outside the message versions, so a new code can appear without a new message version. Schemes and banks may restrict which codes they send.
• In CBPR+ the status report covers one transaction and refers to it by original message ID, message name, instruction ID, end-to-end ID and UETR.

pacs.002 XML example

BANKGB2LXXX in London rejects a pacs.008 of GBP 8,400.00 received from ZagTrader Test Bank (ZAGTAEADXXX) because the creditor’s account is closed. Settlement method was INDA and BANKGB2LXXX had not yet debited ZagTrader’s account, so a reject is correct. Reason AC04 Closed Account Number.

<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pacs.002.001.10">
  <FIToFIPmtStsRpt>
    <GrpHdr>
      <MsgId>BGB26102000731</MsgId>
      <CreDtTm>2026-10-20T08:42:00+01:00</CreDtTm>
    </GrpHdr>
    <TxInfAndSts>
      <OrgnlGrpInf>
        <OrgnlMsgId>ZT26102000003</OrgnlMsgId>
        <OrgnlMsgNmId>pacs.008.001.08</OrgnlMsgNmId>
        <OrgnlCreDtTm>2026-10-20T11:05:00+04:00</OrgnlCreDtTm>
      </OrgnlGrpInf>
      <OrgnlInstrId>ZT2610200003</OrgnlInstrId>
      <OrgnlEndToEndId>GT-PO-2026-0461</OrgnlEndToEndId>
      <OrgnlUETR>45c0b4c4-6cdb-4224-a582-538ad7331f68</OrgnlUETR>
      <TxSts>RJCT</TxSts>
      <StsRsnInf>
        <Orgtr>
          <Id>
            <OrgId>
              <AnyBIC>BANKGB2LXXX</AnyBIC>
            </OrgId>
          </Id>
        </Orgtr>
        <Rsn>
          <Cd>AC04</Cd>
        </Rsn>
        <AddtlInf>CREDITOR ACCOUNT CLOSED</AddtlInf>
      </StsRsnInf>
      <InstgAgt>
        <FinInstnId>
          <BICFI>BANKGB2LXXX</BICFI>
        </FinInstnId>
      </InstgAgt>
      <InstdAgt>
        <FinInstnId>
          <BICFI>ZAGTAEADXXX</BICFI>
        </FinInstnId>
      </InstdAgt>
      <OrgnlTxRef>
        <IntrBkSttlmAmt Ccy="GBP">8400.00</IntrBkSttlmAmt>
        <IntrBkSttlmDt>2026-10-22</IntrBkSttlmDt>
      </OrgnlTxRef>
    </TxInfAndSts>
  </FIToFIPmtStsRpt>
</Document>

The instructing and instructed agents are reversed compared with the original pacs.008: the status flows back to the sender.

The original is identified four ways (message ID, instruction ID, end-to-end ID, UETR). Match on the UETR first.

ZagTrader must now tell its customer and ask for correct account details; a new payment needs a new UETR.

All identifiers are made up.

pacs.002 and its MT equivalent

There is no dedicated MT equivalent. On FIN a bank rejected an MT103 or MT202 by sending a payment message back to the sender with the code /REJT/ and a reason in field 72; the network then required the reject and return guidelines to be followed.

Swift gpi status updates were sent to the gpi Tracker as an MT199 (customer payments) or MT299 (cover payments), with the status and reason, such as ACSP/G000 or RJCT, in field 79. Status codes such as ACSP and RJCT are the same codes a pacs.002 carries in TxSts.

A pacs.002 is a reply to an ISO 20022 payment instruction, so since the end of MT/MX coexistence for cross-border payment instructions on 22 November 2025 it is the normal way to reject a payment on Swift. The MT-to-ISO change also turns a rejection that used to look like a new payment into a clear status on the original one.

Common errors and rejects

1. Reject received but no one acts on it

   A pacs.002 RJCT is a business message, not a network NAK. If your system only watches for NAKs, the reject sits unread while the customer waits. Route incoming pacs.002 to the payments exception queue and match them to the original by UETR.

   How to fix it

2. Reject sent after settlement

   If you have already debited the sender’s account (INDA) or been credited (INGA), the money has moved and a reject is wrong: send a pacs.004 return so the funds go back.

3. AC01 or RC01: wrong account or bank identifier

   Check the IBAN length and check digits, and that the BIC is a live BIC11 or BIC8 of the creditor’s bank. Get corrected details from the customer before you resend.

   How to fix it

4. RR01 to RR04: regulatory data missing

   The receiving bank could not accept the payment for regulatory reasons, for example missing debtor or creditor name and address. Complete the party data in the new payment; for RR04 contact the bank, as screening may be involved.

5. Status cannot be matched

   A pacs.002 that quotes a UETR or original message ID your system does not know usually means the original was changed in translation or by a middleware. Search by end-to-end ID and amount, then fix the reference mapping.

   How to fix it

Related messages

• pacs.008FI to FI Customer Credit Transfer
• pacs.009Financial Institution Credit Transfer
• pacs.004Payment Return
• camt.056FI to FI Payment Cancellation Request
• camt.029Resolution of Investigation
• MT199Free Format Message
• MT103Single Customer Credit Transfer
• MT202General Financial Institution Transfer

• pacs.002 reason codes
• Serial MT103 chains vs MT103 plus MT202COV cover, and the same flows in pacs.008 and pacs.009 COV.

pacs.002 questions

What is a pacs.002 message?

The ISO 20022 FI to FI Payment Status Report: the reply a bank sends to the previous bank to report the status of a payment instruction, most often a reject (RJCT) with a reason code.

What is the difference between pacs.002 and pacs.004?

A pacs.002 reject is sent before settlement, so no money moves back. A pacs.004 return is sent after settlement and itself moves the funds back to the previous bank.

What do ACSP, ACSC and ACCC mean?

ACSP: accepted, settlement in process. ACSC: settlement completed for this leg. ACCC: the creditor’s account has been credited. These positive statuses are used where banks or schemes agree to them.

What does reason code AC04 mean in pacs.002?

Closed Account Number: the creditor’s account is closed at the creditor’s bank. Ask the debtor to get new account details from the creditor before paying again.

What was the MT equivalent of pacs.002?

There was none dedicated. Rejects were sent as a copy of the MT103 or MT202 with /REJT/ in field 72, and gpi statuses went to the Tracker in an MT199 or MT299.

Which pacs.002 version does CBPR+ use?

pacs.002.001.10, the same version used for rejects in the SEPA Credit Transfer inter-PSP guidelines.