Key points of this lesson, in order.
Unknown Payment Status, Failed Beneficiary Credit and Clearing System Outage
What you will learn
Your objective. By the end of this lesson, you will be able to explain unknown payment status, failed beneficiary credit and clearing system outage. Unknown payment status means the bank has sent a payment but has received no acknowledgement, no rejection, no return, and no settlement confirmation, so it cannot state with confidence whether the money moved.
Why it matters. The bank must not assume the payment failed, and it must not assume it succeeded, because either assumption can cause a duplicate or a missing payment.
Chapter objective: Learner investigates payment exceptions, including non-receipt, wrong amount, duplicate, and delayed payments, and runs a structured investigation from first report to resolution. Learner demonstrates this skill using realistic banking examples, explaining each step clearly and using correct terminology throughout.
Key learning points
- Unknown payment status
- Failed beneficiary credit: payment reaches beneficiary bank
- Clearing system outage
- Most important task: protect payment queue
- Post-incident review after three events
Key terms
Suspense account: A temporary account used to hold funds or entries that cannot yet be posted to their final account. Banks use suspense accounts for unidentified receipts, pending investigations and items awaiting...
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.
Exception investigation workflow showing Unknown Payment Status, Failed Beneficiary Credit and Clearing System Outage.
Insights and practice scenarios
Worked insights and practice scenarios for this lesson. Each one is a reusable PaymentForge case, so the same case may appear in more than one lesson.
Practise this lesson
Exercise
Work out the net settlement position for the clearing cycle described in this lesson.
Use the clearing rules and the netting logic in this lesson.
- What to do. List the payments in the cycle, calculate the net position for each bank, and state what settles.
Correct result. Clearing validates, sorts, matches and nets the instructions, then produces a net position per bank. Only the net position settles, which needs far less liquidity than settling every payment individually.
Why. Netting is what makes high volume payments possible. Without it, every payment would need full liquidity at the moment it is sent.
Check your understanding
Practice question
Which of the following best describes unknown payment status, failed beneficiary credit and clearing system outage?
Takeaway and next step
What to remember
The key point is that an outage is a known event with a known response, not a reason for each payment to be investigated individually.
Reconcile the payment in this lesson against its statement and find the break.
Open the Accounting and Reconciliation Lab →
Builds on "Investigations, Duplicate Payments, Timeouts and Pending Payments".
Transcript and full text
Show transcript
Unknown payment status means the bank has sent a payment but has received no acknowledgement, no rejection, no return, and no settlement confirmation, so it cannot state with confidence whether the money moved. This can happen when a message is lost in transit, when a correspondent bank's system fails to send an acknowledgement, or when a clearing system report is delayed. The bank must not assume the payment failed, and it must not assume it succeeded, because either assumption can cause a duplicate or a missing payment. The correct action is to raise a status investigation with the next bank in the chain, asking for confirmation of receipt and processing, and to keep the payment in an open state until that confirmation arrives. A failed beneficiary credit happens when the payment reaches the beneficiary bank but the beneficiary bank cannot credit the intended account, often because the account is closed, the name does not match, or the account is blocked. The beneficiary bank will usually return the payment with a pacs.004 message and a reason code such as AC04 for a closed account or AC06 for a blocked account. That return is the standard process. In some cases a beneficiary bank holds funds in its own suspense account while it tries to identify the correct account, but that is an exception, not the standard flow, and it is not a substitute for the pacs.004 return. A learner should not treat holding funds in suspense as the normal way a failed credit is handled. The sending bank must then work with the beneficiary bank to establish whether the credit can be repaired, for example by correcting the account number, or whether the funds must be returned to the customer. Each day of delay increases the risk that the customer will suffer a commercial loss. A clearing system outage is an event where the system that settles payments between banks stops working, and it affects thousands of payments at once rather than one payment at a time. For example, if a real-time gross settlement system is unavailable for two hours, every payment due to settle in that window will be delayed, and banks must decide whether to hold the payments, queue them for the next settlement window, or use an alternative route. The outage is usually announced by the system operator, and banks activate their business continuity plans, which include manual workarounds, extended cut-off times, and proactive customer communication. The key point is that an outage is a known event with a known response, not a reason for each payment to be investigated individually. During an outage, the most important task is to protect the integrity of the payment queue, so that no payment is lost, duplicated, or settled twice when the system recovers. Banks freeze new submissions to the affected system, record every payment that was in flight when the outage began, and reconcile that list against the settlement report once the system returns. A payment of EUR 500,000 that was submitted just before the outage must be checked against the post-outage report before it is resent, because it may have settled in the final moments before the system stopped. That reconciliation is the difference between a smooth recovery and a day of duplicate payments. After any of these three events, the bank must complete a post-incident review that records what happened, how many payments were affected, how long the impact lasted, and what will change to prevent a recurrence. The review for an unknown status event may recommend better acknowledgement monitoring, the review for a failed credit may recommend stricter beneficiary validation, and the review for an outage may recommend a faster switch to an alternative settlement route. Regulators expect to see those reviews for significant incidents, and customers expect to be told what happened in plain language. An exception that is resolved but not learned from is an exception that will happen again.
Unknown payment status means the bank has sent a payment but has received no acknowledgement, no rejection, no return, and no settlement confirmation, so it cannot state with confidence whether the money moved. This can happen when a message is lost in transit, when a correspondent bank's system fails to send an acknowledgement, or when a clearing system report is delayed. The bank must not assume the payment failed, and it must not assume it succeeded, because either assumption can cause a duplicate or a missing payment. The correct action is to raise a status investigation with the next bank in the chain, asking for confirmation of receipt and processing, and to keep the payment in an open state until that confirmation arrives.
A failed beneficiary credit happens when the payment reaches the beneficiary bank but the beneficiary bank cannot credit the intended account, often because the account is closed, the name does not match, or the account is blocked. The beneficiary bank will usually return the payment with a pacs.004 message and a reason code such as AC04 for a closed account or AC06 for a blocked account. That return is the standard process. In some cases a beneficiary bank holds funds in its own suspense account while it tries to identify the correct account, but that is an exception, not the standard flow, and it is not a substitute for the pacs.004 return. A learner should not treat holding funds in suspense as the normal way a failed credit is handled. The sending bank must then work with the beneficiary bank to establish whether the credit can be repaired, for example by correcting the account number, or whether the funds must be returned to the customer. Each day of delay increases the risk that the customer will suffer a commercial loss.
A clearing system outage is an event where the system that settles payments between banks stops working, and it affects thousands of payments at once rather than one payment at a time. For example, if a real-time gross settlement system is unavailable for two hours, every payment due to settle in that window will be delayed, and banks must decide whether to hold the payments, queue them for the next settlement window, or use an alternative route. The outage is usually announced by the system operator, and banks activate their business continuity plans, which include manual workarounds, extended cut-off times, and proactive customer communication. The key point is that an outage is a known event with a known response, not a reason for each payment to be investigated individually.
During an outage, the most important task is to protect the integrity of the payment queue, so that no payment is lost, duplicated, or settled twice when the system recovers. Banks freeze new submissions to the affected system, record every payment that was in flight when the outage began, and reconcile that list against the settlement report once the system returns. A payment of EUR 500,000 that was submitted just before the outage must be checked against the post-outage report before it is resent, because it may have settled in the final moments before the system stopped. That reconciliation is the difference between a smooth recovery and a day of duplicate payments.
After any of these three events, the bank must complete a post-incident review that records what happened, how many payments were affected, how long the impact lasted, and what will change to prevent a recurrence. The review for an unknown status event may recommend better acknowledgement monitoring, the review for a failed credit may recommend stricter beneficiary validation, and the review for an outage may recommend a faster switch to an alternative settlement route. Regulators expect to see those reviews for significant incidents, and customers expect to be told what happened in plain language. An exception that is resolved but not learned from is an exception that will happen again.
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.