Payments Training Hub
One rule that decides reject PAYMENT OPERATIONS STARTED LIVE 01 One rule - versus return is timing ACTIVE 02 Reject - happens while the payment is still in flight QUEUED 03 Return - happens after the creditor agent has already QUEUED 04 Reason codes - also change with the timing QUEUED 05 Timing test - practice, the timing test also protects QUEUED The one rule that decides reject versus return is timing, and it is simple to state. Step 1 of 5 One rule that decides reject STARTED One rule versus return is timing ACTIVE Reject happens while the payment is still in flight QUEUED Return happens after the creditor agent has already QUEUED Reason codes also change with the timing QUEUED Timing test practice, the timing test also protects QUEUED The one rule that decides reject versus return is timing, and it is simple to state.
Reject: payment is still in flight PAYMENT OPERATIONS IN PROGRESS LIVE 01 One rule - versus return is timing DONE 02 Reject - happens while the payment is still in flight ACTIVE 03 Return - happens after the creditor agent has already QUEUED 04 Reason codes - also change with the timing QUEUED 05 Timing test - practice, the timing test also protects QUEUED A reject happens while the payment is still in flight between banks, before the creditor agent has posted the funds. Step 2 of 5 Reject: payment is still in flight IN PROGRESS One rule versus return is timing DONE Reject happens while the payment is still in flight ACTIVE Return happens after the creditor agent has already QUEUED Reason codes also change with the timing QUEUED Timing test practice, the timing test also protects QUEUED A reject happens while the payment is still in flight between banks, before the creditor agent has posted the funds.
Return: creditor agent has already credited PAYMENT OPERATIONS IN PROGRESS LIVE 01 One rule - versus return is timing DONE 02 Reject - happens while the payment is still in flight DONE 03 Return - happens after the creditor agent has already ACTIVE 04 Reason codes - also change with the timing QUEUED 05 Timing test - practice, the timing test also protects QUEUED A return happens after the creditor agent has already credited the beneficiary, and later discovers a problem or receives a request to send the money back. Step 3 of 5 Return: creditor agent has already credited IN PROGRESS One rule versus return is timing DONE Reject happens while the payment is still in flight DONE Return happens after the creditor agent has already ACTIVE Reason codes also change with the timing QUEUED Timing test practice, the timing test also protects QUEUED A return happens after the creditor agent has already credited the beneficiary, and later discovers a problem or receives a request to send the money back.
Reason codes PAYMENT OPERATIONS IN PROGRESS LIVE 01 One rule - versus return is timing DONE 02 Reject - happens while the payment is still in flight DONE 03 Return - happens after the creditor agent has already DONE 04 Reason codes - also change with the timing ACTIVE 05 Timing test - practice, the timing test also protects QUEUED The reason codes also change with the timing, and that is where many learners get confused. Step 4 of 5 Reason codes IN PROGRESS One rule versus return is timing DONE Reject happens while the payment is still in flight DONE Return happens after the creditor agent has already DONE Reason codes also change with the timing ACTIVE Timing test practice, the timing test also protects QUEUED The reason codes also change with the timing, and that is where many learners get confused.
Timing test PAYMENT OPERATIONS COMPLETE LIVE 01 One rule - versus return is timing DONE 02 Reject - happens while the payment is still in flight DONE 03 Return - happens after the creditor agent has already DONE 04 Reason codes - also change with the timing DONE 05 Timing test - practice, the timing test also protects ACTIVE In practice, the timing test also protects the customer and the bank from double handling. Step 5 of 5 Timing test COMPLETE One rule versus return is timing DONE Reject happens while the payment is still in flight DONE Return happens after the creditor agent has already DONE Reason codes also change with the timing DONE Timing test practice, the timing test also protects ACTIVE In practice, the timing test also protects the customer and the bank from double handling.

Key points of this lesson, in order.

0:00 / 3:30 Step 1 of 5

Reject vs Return: The One Rule That Decides

Reject and Return in CBPR+, Lesson 1 of 7, Narration 3:30, D11 Operations, exceptions and reconciliation

ReconciliationSettlementCreditor

What you will learn

Your objective. By the end of this lesson, you will be able to explain reject vs return: the one rule that decides. The one rule that decides reject versus return is timing, and it is simple to state.

Why it matters. Operations teams that learn this rule first make far fewer errors than teams that try to memorise lists of reason codes.

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

  • One rule that decides reject
  • Reject: payment is still in flight
  • Return: creditor agent has already credited
  • Reason codes
  • Timing test

Key terms

Reconciliation: The process of comparing records from two sources, such as a bank statement and an internal ledger, to confirm they agree.

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.

Creditor: The party that is owed money and receives a payment, such as a supplier, a seller or a service provider.

Exception investigation workflow showing Reject vs Return: The One Rule That Decides.

Practise this lesson

Exercise

Handle the exception described in this lesson the way the lesson prescribes.

Use the exception type, the reason code and the recovery path in this lesson.

  1. What to do. State what happened, what the correct action is, what must not be done, and what the post-incident review should capture.

Correct result. The correct action is the one the lesson prescribes for this exception type, with the right reason code and the right message. The payment must not be resent without checking whether it already settled, because that creates a duplicate.

Why. An exception handled wrongly is worse than the exception itself. A duplicate payment is a loss, and an unlearned exception will happen again.

Check your understanding

Practice question

A pacs.008 is finally rejected by the beneficiary bank after several banks tried to process it. Which status message is now mandatory, and what happens to the funds?

Takeaway and next step

What to remember

It sends a pacs.002 with a rejection status back to JPMorgan Chase, and the funds never reach the intended beneficiary.

Reconcile the payment in this lesson against its statement and find the break.

Open the Accounting and Reconciliation Lab →

The CBPR+ technical deep dive, building on ch41, Payment Exceptions and Investigations. This chapter covers the pacs.002 and pacs.004 messages, the INDA and INGA settlement methods, and the reject versus return rule with worked examples.

Transcript and full text

Show transcript

The one rule that decides reject versus return is timing, and it is simple to state. If a payment has not yet been credited to the creditor account, the problem is handled as a reject. If the payment has already been credited to the creditor account, the problem is handled as a return. That distinction sounds small, but it drives the whole CBPR+ flow, because a reject stops a payment before value reaches the beneficiary, while a return takes value back after the beneficiary bank has already received it. Operations teams that learn this rule first make far fewer errors than teams that try to memorise lists of reason codes. A reject happens while the payment is still in flight between banks, before the creditor agent has posted the funds. For example, Deutsche Bank in Frankfurt receives a pacs.008 for USD 100,000 from JPMorgan Chase in New York, and its validation finds that the creditor account number is closed. Deutsche Bank has not credited any customer account, so it rejects the payment. It sends a pacs.002 with a rejection status back to JPMorgan Chase, and the funds never reach the intended beneficiary. The original payment instruction is dead, and no new settlement instruction is needed to move the money back. A return happens after the creditor agent has already credited the beneficiary, and later discovers a problem or receives a request to send the money back. For example, BNP Paribas in Paris credits EUR 50,000 to a corporate customer, and the customer then reports that the payment was sent in error and asks for the funds to be returned. BNP Paribas cannot simply send a status report, because the money is already in the customer account. It must create a new payment instruction, a pacs.004, to move the funds back through the chain. The original pacs.008 remains a settled payment in the records, and the pacs.004 is a separate transaction. The reason codes also change with the timing, and that is where many learners get confused. A reject uses status reason codes in pacs.002, such as AC01 for an incorrect account number, AM05 for a duplicated payment, or BE04 for a missing creditor address. A return uses return reason codes in pacs.004, such as AC03 for an invalid account number discovered after credit, DUPL for a duplicate payment, or FRAD for a fraudulent payment. The code families overlap in meaning, but they live in different messages, and sending the wrong code in the wrong message will fail validation at the next bank. Always check the timing first, then choose the message, then choose the code. In practice, the timing test also protects the customer and the bank from double handling. If a bank tried to return a payment that was never credited, the return would move money that was never received, and the nostro account would go out of balance. If a bank tried to reject a payment that was already credited, the status report would claim the funds were never delivered, while the beneficiary still held them, and the reconciliation would break. A simple question at the start of every case prevents both failures. Has the creditor account been credited yet. If the answer is no, reject with pacs.002. If the answer is yes, return with pacs.004. That discipline keeps every case clean.

The one rule that decides reject versus return is timing, and it is simple to state. If a payment has not yet been credited to the creditor account, the problem is handled as a reject. If the payment has already been credited to the creditor account, the problem is handled as a return. That distinction sounds small, but it drives the whole CBPR+ flow, because a reject stops a payment before value reaches the beneficiary, while a return takes value back after the beneficiary bank has already received it. Operations teams that learn this rule first make far fewer errors than teams that try to memorise lists of reason codes.

A reject happens while the payment is still in flight between banks, before the creditor agent has posted the funds. For example, Deutsche Bank in Frankfurt receives a pacs.008 for USD 100,000 from JPMorgan Chase in New York, and its validation finds that the creditor account number is closed. Deutsche Bank has not credited any customer account, so it rejects the payment. It sends a pacs.002 with a rejection status back to JPMorgan Chase, and the funds never reach the intended beneficiary. The original payment instruction is dead, and no new settlement instruction is needed to move the money back.

A return happens after the creditor agent has already credited the beneficiary, and later discovers a problem or receives a request to send the money back. For example, BNP Paribas in Paris credits EUR 50,000 to a corporate customer, and the customer then reports that the payment was sent in error and asks for the funds to be returned. BNP Paribas cannot simply send a status report, because the money is already in the customer account. It must create a new payment instruction, a pacs.004, to move the funds back through the chain. The original pacs.008 remains a settled payment in the records, and the pacs.004 is a separate transaction.

The reason codes also change with the timing, and that is where many learners get confused. A reject uses status reason codes in pacs.002, such as AC01 for an incorrect account number, AM05 for a duplicated payment, or BE04 for a missing creditor address. A return uses return reason codes in pacs.004, such as AC03 for an invalid account number discovered after credit, DUPL for a duplicate payment, or FRAD for a fraudulent payment. The code families overlap in meaning, but they live in different messages, and sending the wrong code in the wrong message will fail validation at the next bank. Always check the timing first, then choose the message, then choose the code.

In practice, the timing test also protects the customer and the bank from double handling. If a bank tried to return a payment that was never credited, the return would move money that was never received, and the nostro account would go out of balance. If a bank tried to reject a payment that was already credited, the status report would claim the funds were never delivered, while the beneficiary still held them, and the reconciliation would break. A simple question at the start of every case prevents both failures. Has the creditor account been credited yet. If the answer is no, reject with pacs.002. If the answer is yes, return with pacs.004. That discipline keeps every case clean.

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.