Payments Training Hub
Operational controls PAYMENT OPERATIONS STARTED LIVE 01 Operational controls - rules and checks that prevent errors ACTIVE 02 Queues - where payments sit when they cannot go QUEUED 03 Common exceptions - most common exceptions are simple data QUEUED 04 Sanctions and fraud exceptions need more - because the analyst must judge QUEUED 05 Exception handling - measured every day QUEUED Operational controls are the rules and checks that prevent errors, detect them quickly when they happen, and limit the damage. Step 1 of 5 Operational controls STARTED Operational controls rules and checks that prevent errors ACTIVE Queues where payments sit when they cannot go QUEUED Common exceptions most common exceptions are simple data QUEUED Sanctions and fraud exceptions need more because the analyst must judge risk rather QUEUED Exception handling measured every day QUEUED Operational controls are the rules and checks that prevent errors, detect them quickly when they happen, and limit the damage.
Queues: safe waiting areas PAYMENT OPERATIONS IN PROGRESS LIVE 01 Operational controls - rules and checks that prevent errors DONE 02 Queues - where payments sit when they cannot go ACTIVE 03 Common exceptions - most common exceptions are simple data QUEUED 04 Sanctions and fraud exceptions need more - because the analyst must judge QUEUED 05 Exception handling - measured every day QUEUED Queues are the safe waiting areas where payments sit when they cannot go straight through. Step 2 of 5 Queues: safe waiting areas IN PROGRESS Operational controls rules and checks that prevent errors DONE Queues where payments sit when they cannot go ACTIVE Common exceptions most common exceptions are simple data QUEUED Sanctions and fraud exceptions need more because the analyst must judge risk rather QUEUED Exception handling measured every day QUEUED Queues are the safe waiting areas where payments sit when they cannot go straight through.
Common exceptions PAYMENT OPERATIONS IN PROGRESS LIVE 01 Operational controls - rules and checks that prevent errors DONE 02 Queues - where payments sit when they cannot go DONE 03 Common exceptions - most common exceptions are simple data ACTIVE 04 Sanctions and fraud exceptions need more - because the analyst must judge QUEUED 05 Exception handling - measured every day QUEUED The most common exceptions are simple data errors that can be fixed in minutes. Step 3 of 5 Common exceptions IN PROGRESS Operational controls rules and checks that prevent errors DONE Queues where payments sit when they cannot go DONE Common exceptions most common exceptions are simple data ACTIVE Sanctions and fraud exceptions need more because the analyst must judge risk rather QUEUED Exception handling measured every day QUEUED The most common exceptions are simple data errors that can be fixed in minutes.
Sanctions and fraud exceptions need more care PAYMENT OPERATIONS IN PROGRESS LIVE 01 Operational controls - rules and checks that prevent errors DONE 02 Queues - where payments sit when they cannot go DONE 03 Common exceptions - most common exceptions are simple data DONE 04 Sanctions and fraud exceptions need more - because the analyst must judge ACTIVE 05 Exception handling - measured every day QUEUED Sanctions and fraud exceptions need more care, because the analyst must judge risk rather than fix a typing error. Step 4 of 5 Sanctions and fraud exceptions need more care IN PROGRESS Operational controls rules and checks that prevent errors DONE Queues where payments sit when they cannot go DONE Common exceptions most common exceptions are simple data DONE Sanctions and fraud exceptions need more because the analyst must judge risk rather ACTIVE Exception handling measured every day QUEUED Sanctions and fraud exceptions need more care, because the analyst must judge risk rather than fix a typing error.
Exception handling PAYMENT OPERATIONS COMPLETE LIVE 01 Operational controls - rules and checks that prevent errors DONE 02 Queues - where payments sit when they cannot go DONE 03 Common exceptions - most common exceptions are simple data DONE 04 Sanctions and fraud exceptions need more - because the analyst must judge DONE 05 Exception handling - measured every day ACTIVE Exception handling is measured every day, because the numbers reveal whether the process is working. Step 5 of 5 Exception handling COMPLETE Operational controls rules and checks that prevent errors DONE Queues where payments sit when they cannot go DONE Common exceptions most common exceptions are simple data DONE Sanctions and fraud exceptions need more because the analyst must judge risk rather DONE Exception handling measured every day ACTIVE Exception handling is measured every day, because the numbers reveal whether the process is working.

Key points of this lesson, in order.

0:00 / 3:37 Step 1 of 5

Operational Controls, Queues and Exception Handling

Payment Operations, Lesson 5 of 7, Narration 3:37, D11 Operations, exceptions and reconciliation

ExceptionLiquidityRepair

What you will learn

Your objective. By the end of this lesson, you will be able to explain operational controls, queues and exception handling. Operational controls are the rules and checks that prevent errors, detect them quickly when they happen, and limit the damage.

Why it matters. A third control is the limit on what one analyst can release in a day, so a single compromised account cannot drain a large sum.

Chapter objective: Learner explains payment operations, including daily processing, cut-offs, monitoring, incident handling, and reporting, and builds a daily operations checklist for a payment team. Learner demonstrates this skill using realistic banking examples, explaining each step clearly and using correct terminology throughout.

Key learning points

  • Operational controls
  • Queues: safe waiting areas
  • Common exceptions
  • Sanctions and fraud exceptions need more care
  • Exception handling

Key terms

Exception: A payment that cannot be processed normally and needs manual handling, investigation or repair. Exceptions arise from missing data, failed screening, account errors or system faults.

Liquidity: Cash or assets that a bank can use immediately to meet payment obligations. Banks manage liquidity by forecasting inflows and outflows, funding nostro and settlement accounts, and using central bank...

Repair: Manual correction of a payment that failed straight through processing because of missing or invalid data.

Exception investigation workflow showing Operational Controls, Queues and Exception Handling.

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

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

Which of the following best describes operational controls, queues and exception handling?

Takeaway and next step

What to remember

When the exception rate rises from two percent to four percent, the team leader investigates the cause, which is often a bad file from one corporate customer or a change in a screening rule.

Run the exception from this lesson and follow the investigation to its resolution.

Open the Exception Investigation Simulator →

Builds on "Intraday Liquidity Operations and Monitoring".

Transcript and full text

Show transcript

Operational controls are the rules and checks that prevent errors, detect them quickly when they happen, and limit the damage. The most important control is the four eyes principle, which means a second person checks any payment above a defined threshold before it is released. In many banks that threshold is 100,000 pounds, so a payment of 250,000 euros to a supplier in France needs a maker and a checker. Another control is the segregation of duties, which means the person who sets up a new beneficiary cannot also approve the first payment to that beneficiary. A third control is the limit on what one analyst can release in a day, so a single compromised account cannot drain a large sum. Queues are the safe waiting areas where payments sit when they cannot go straight through. The main queues are the validation queue for payments with missing or incorrect fields, the sanctions queue for payments that match a name on a screening list, the fraud queue for payments that look unusual, the liquidity queue for payments waiting for funds, and the repair queue for payments that failed in a downstream system. Each queue has an owner, a target age and a priority order. A payment of 2 million dollars in the sanctions queue takes priority over a payment of 150 pounds in the validation queue, because the value at risk and the customer impact are far greater. The most common exceptions are simple data errors that can be fixed in minutes. A payment may fail because the beneficiary account number is one digit short, the SWIFT code is out of date, the currency does not match the beneficiary account, or the amount exceeds the customer daily limit of 50,000 pounds. A payment of 75,000 euros to a company in Italy may be held because the IBAN is missing two characters. The analyst opens the payment, compares the instruction with the customer record or the previous payment to the same beneficiary, corrects the field and resubmits the payment for validation. Every correction is logged with the old value, the new value, the analyst name and the time, so an auditor can reconstruct the change. Sanctions and fraud exceptions need more care, because the analyst must judge risk rather than fix a typing error. A payment of 120,000 dollars to a company whose name is similar to a name on the United States OFAC sanctions list is held until compliance confirms whether the match is a true hit or a false positive. The analyst checks the full name, the address, the country and the date of birth of the individual where available, and passes the evidence to compliance. A fraud exception may involve a customer who normally pays 2,000 pounds a month suddenly sending 48,000 pounds to a new beneficiary in another country. The analyst calls the customer to confirm the payment is genuine before releasing it, and the call is recorded. Exception handling is measured every day, because the numbers reveal whether the process is working. The team tracks the straight through processing rate, which is the share of payments that need no manual touch, the average age of items in each queue, the number of payments repaired per analyst per hour, and the number of payments returned to customers. A retail bank processing two million payments a day at 98 percent straight through processing still has 40,000 exceptions to handle, which is why staffing is planned around the exception rate rather than the total volume. When the exception rate rises from two percent to four percent, the team leader investigates the cause, which is often a bad file from one corporate customer or a change in a screening rule.

Operational controls are the rules and checks that prevent errors, detect them quickly when they happen, and limit the damage. The most important control is the four eyes principle, which means a second person checks any payment above a defined threshold before it is released. In many banks that threshold is 100,000 pounds, so a payment of 250,000 euros to a supplier in France needs a maker and a checker. Another control is the segregation of duties, which means the person who sets up a new beneficiary cannot also approve the first payment to that beneficiary. A third control is the limit on what one analyst can release in a day, so a single compromised account cannot drain a large sum.

Queues are the safe waiting areas where payments sit when they cannot go straight through. The main queues are the validation queue for payments with missing or incorrect fields, the sanctions queue for payments that match a name on a screening list, the fraud queue for payments that look unusual, the liquidity queue for payments waiting for funds, and the repair queue for payments that failed in a downstream system. Each queue has an owner, a target age and a priority order. A payment of 2 million dollars in the sanctions queue takes priority over a payment of 150 pounds in the validation queue, because the value at risk and the customer impact are far greater.

The most common exceptions are simple data errors that can be fixed in minutes. A payment may fail because the beneficiary account number is one digit short, the SWIFT code is out of date, the currency does not match the beneficiary account, or the amount exceeds the customer daily limit of 50,000 pounds. A payment of 75,000 euros to a company in Italy may be held because the IBAN is missing two characters. The analyst opens the payment, compares the instruction with the customer record or the previous payment to the same beneficiary, corrects the field and resubmits the payment for validation. Every correction is logged with the old value, the new value, the analyst name and the time, so an auditor can reconstruct the change.

Sanctions and fraud exceptions need more care, because the analyst must judge risk rather than fix a typing error. A payment of 120,000 dollars to a company whose name is similar to a name on the United States OFAC sanctions list is held until compliance confirms whether the match is a true hit or a false positive. The analyst checks the full name, the address, the country and the date of birth of the individual where available, and passes the evidence to compliance. A fraud exception may involve a customer who normally pays 2,000 pounds a month suddenly sending 48,000 pounds to a new beneficiary in another country. The analyst calls the customer to confirm the payment is genuine before releasing it, and the call is recorded.

Exception handling is measured every day, because the numbers reveal whether the process is working. The team tracks the straight through processing rate, which is the share of payments that need no manual touch, the average age of items in each queue, the number of payments repaired per analyst per hour, and the number of payments returned to customers. A retail bank processing two million payments a day at 98 percent straight through processing still has 40,000 exceptions to handle, which is why staffing is planned around the exception rate rather than the total volume. When the exception rate rises from two percent to four percent, the team leader investigates the cause, which is often a bad file from one corporate customer or a change in a screening rule.

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.