| Field | Meaning | Required |
|---|---|---|
GrpHdr | The header with message identification, creation date and time and instructing agent. It identifies the status report for tracking and duplicate detection. The | M |
OrgnlGrpInfAndSts | Reference to the original message group plus its status and reason. It tells the sender whether the whole group was accepted, rejected or partially accepted. Th | O |
TxInfAndSts | Status information for a single transaction, with its identification, status and reason. It is the core of the message for exception handling. The sender uses i | O |
OrgnlInstrId | The instruction identification from the original payment message, copied into the status report. It links the status to the sender instruction. The sender syste | M |
OrgnlEndToEndId | The end to end identification from the original payment, copied into the status report. It stays unchanged through the chain and lets all banks and the customer | O |
OrgnlTxId | The transaction identification from the original payment, assigned by the instructing agent. It provides a third matching key alongside instruction and end to e | O |
TxSts | The status of the transaction, using codes such as ACCP for accepted, RJCT for rejected, PDNG for pending, ACSC for accepted settlement completed and ACCC for a | M |
StsRsnInf | The reason for the status, with a coded reason and additional text. Codes include AC01 for wrong account number, AM05 for duplicate payment and NARR for a narra | O |
OrgnlIntrBkSttlmAmt | The interbank settlement amount from the original payment, copied into the status report. It confirms which payment the status refers to when several payments h | O |
OrgnlIntrBkSttlmDt | The interbank settlement date from the original payment, copied into the status report. It confirms the value date of the payment being reported on. The sender | O |
ChrgsInf | Charges applied by the reporting agent, with amount, currency and bearer. It lets the sender see any fee deducted by an intermediary or the creditor agent. Tran | O |
AccptncDtTm | The date and time when the reporting agent accepted the payment for processing. It is a key timestamp for gpi tracking and for measuring processing speed. The s | O |
Harbour Bank Singapore sends a pacs.002 to Meridian Bank London for the pacs.008 with end to end identification MER-20261105-1187: transaction status ACCP, accepted for processing. Meridian Bank updates its tracker and tells Bright Logistics the payment is on its way.
Valid example from the message catalogue. Scheme rules: pacs.002 is a base ISO 20022 message: the structure and fields below are the base definition, and each scheme adds its own rules for its rail. Under CBPR+ a pacs.002 must be sent for a rejected paymen
pacs.002 Payment Status Report in Depth
What you will learn
Your objective. By the end of this lesson, you will be able to explain pacs.002 payment status report. A pacs.002 is a status report that an agent sends to the previous agent in the payment chain to report the outcome of a payment instruction.
Why it matters. These optional reports help corporate treasurers who need to know where a USD 250,000 supplier payment stands, and they help operations teams to spot a stuck payment before the customer calls.
Chapter objective: Learner explains reject and return in CBPR+, describes when pacs.002 is mandatory for a final negative status, and shows how pacs.004 works as a separate settlement instruction. Learner uses real amounts, banks and message names to show how reject and return work in practice.
Key learning points
- Pacs.002: status report
- Pacs.002 becomes mandatory only
- Structure of a pacs.002
- Previous agent uses those references
- When a pacs.002 helps even when it is not mandatory
Key terms
Settlement: The final movement of funds between banks to discharge obligations created by cleared payments. Settlement is usually made in central bank money or through correspondent accounts.
pacs.002: An ISO 20022 message one financial institution sends to another to report the status of a payment instruction.
pacs.004: An ISO 20022 message used to return a payment that was already settled but cannot be credited to the beneficiary.
ISO 20022 XML explorer showing pacs.002 Payment Status Report in Depth.
Practise this lesson
Exercise
Read the pacs.002 message described in this lesson and identify its key parts.
Use the message structure, fields and example in this lesson.
- What to do. List the three levels of the message and name the field that carries the amount and the field that carries the end-to-end reference.
Correct result. The amount is carried in the instructed amount element and the reference in the end-to-end identification. The three levels are the group header, the payment information, and the credit transfer transaction information.
Why. A message is only useful if you can read it. The group header identifies the message, the payment information identifies the batch, and the transaction information carries the single payment.
Check your understanding
Practice question
Which of the following best describes pacs.002 payment status report?
Takeaway and next step
What to remember
The mandatory obligation is triggered by one event only, a final rejection, and that is the point to remember for examinations and for live work.
Open the message type from this lesson and inspect its fields, then find the field that carries the amount.
Open the ISO 20022 Message Explorer →
Builds on "Reject vs Return: The One Rule That Decides".
Transcript and full text
Show transcript
A pacs.002 is a status report that an agent sends to the previous agent in the payment chain to report the outcome of a payment instruction. It carries the original instruction reference, the transaction status, and, where the payment has failed, the status reason code and additional information that explains the failure. It does not move money, and it does not create a new settlement instruction. Its job is information only, and that limitation is important, because a bank that needs to move funds back must use a pacs.004 instead. The pacs.002 is the reporting tool, not the settlement tool, and confusing the two is a common operational error. In CBPR+, a pacs.002 becomes mandatory only in the scenario of a final negative status. That means when a payment is rejected, a pacs.002 must be sent to inform the previous agent that the payment will not proceed. The rule is deliberately narrow, because CBPR+ does not want every bank in a long chain to flood the network with status reports for every successful payment. A successful payment needs no mandatory pacs.002, and an interim status such as a payment received for processing needs no mandatory report either. The mandatory obligation is triggered by one event only, a final rejection, and that is the point to remember for examinations and for live work. The structure of a pacs.002 follows the original instruction closely, so that the previous agent can match it without manual work. It repeats the message identification of the original pacs.008, the original end to end identification, and the original instruction identification. It then states the transaction status, which for a rejection is RJCT, and it gives the status reason information, including the reason code and a short text explanation. For example, a pacs.002 from Barclays in London to Citibank in New York might report RJCT with reason AC01, incorrect account number, for a USD 75,000 payment. The previous agent uses those references to find the original payment in its own system and to inform its customer. A rejected pacs.002 also carries practical consequences that go beyond the message itself. When the debtor agent receives the RJCT report, it must release any funds it had reserved, reverse any nostro debit it had posted in anticipation, and inform the debtor customer that the payment failed. If the debtor agent had already debited its customer USD 100,000, it must now credit that amount back, or at least explain the delay while it checks the reason. The pacs.002 therefore starts a chain of customer communication and account corrections, and a missing or late pacs.002 leaves the debtor agent guessing, with funds held and a customer waiting for an answer that never arrives. There are also cases where a pacs.002 is useful even though it is not mandatory, and good banks use it wisely. A bank may send a pacs.002 with status ACCP to confirm that a payment has been accepted for execution, or with status ACSP to confirm that settlement is in progress, when the customer or the previous agent has asked for tracking. These optional reports help corporate treasurers who need to know where a USD 250,000 supplier payment stands, and they help operations teams to spot a stuck payment before the customer calls. The rule to carry forward is simple. A final rejection always requires a pacs.002, while other statuses are sent when they add value, never as a substitute for moving money.
A pacs.002 is a status report that an agent sends to the previous agent in the payment chain to report the outcome of a payment instruction. It carries the original instruction reference, the transaction status, and, where the payment has failed, the status reason code and additional information that explains the failure. It does not move money, and it does not create a new settlement instruction. Its job is information only, and that limitation is important, because a bank that needs to move funds back must use a pacs.004 instead. The pacs.002 is the reporting tool, not the settlement tool, and confusing the two is a common operational error.
In CBPR+, a pacs.002 becomes mandatory only in the scenario of a final negative status. That means when a payment is rejected, a pacs.002 must be sent to inform the previous agent that the payment will not proceed. The rule is deliberately narrow, because CBPR+ does not want every bank in a long chain to flood the network with status reports for every successful payment. A successful payment needs no mandatory pacs.002, and an interim status such as a payment received for processing needs no mandatory report either. The mandatory obligation is triggered by one event only, a final rejection, and that is the point to remember for examinations and for live work.
The structure of a pacs.002 follows the original instruction closely, so that the previous agent can match it without manual work. It repeats the message identification of the original pacs.008, the original end to end identification, and the original instruction identification. It then states the transaction status, which for a rejection is RJCT, and it gives the status reason information, including the reason code and a short text explanation. For example, a pacs.002 from Barclays in London to Citibank in New York might report RJCT with reason AC01, incorrect account number, for a USD 75,000 payment. The previous agent uses those references to find the original payment in its own system and to inform its customer.
A rejected pacs.002 also carries practical consequences that go beyond the message itself. When the debtor agent receives the RJCT report, it must release any funds it had reserved, reverse any nostro debit it had posted in anticipation, and inform the debtor customer that the payment failed. If the debtor agent had already debited its customer USD 100,000, it must now credit that amount back, or at least explain the delay while it checks the reason. The pacs.002 therefore starts a chain of customer communication and account corrections, and a missing or late pacs.002 leaves the debtor agent guessing, with funds held and a customer waiting for an answer that never arrives.
There are also cases where a pacs.002 is useful even though it is not mandatory, and good banks use it wisely. A bank may send a pacs.002 with status ACCP to confirm that a payment has been accepted for execution, or with status ACSP to confirm that settlement is in progress, when the customer or the previous agent has asked for tracking. These optional reports help corporate treasurers who need to know where a USD 250,000 supplier payment stands, and they help operations teams to spot a stuck payment before the customer calls. The rule to carry forward is simple. A final rejection always requires a pacs.002, while other statuses are sent when they add value, never as a substitute for moving money.
Full lesson text (all scenes)
Completing a lesson updates your progress dashboard on the homepage.
Scene timestamps are estimated by allocating the narration text proportionally across the real audio length. The audio playback position is the source of truth: pause freezes the visual, seeking restores the correct scene, replay restarts the scene animation.