Payments Training Hub
Payment engine cannot resolve every payment automatically PAYMENT OPERATIONS STARTED LIVE 01 Payment engine cannot resolve every payment - needs worklists: queues of ACTIVE 02 Payment of EUR 12,000 - example, a payment of EUR 12,000 QUEUED 03 True match - means the payment is blocked QUEUED 04 Payment of EUR 25,000 - returned with reason code AC04 must have QUEUED 05 Escalation rules decide when a worklist - stops waiting for a routine operator QUEUED 06 Repair operator who corrects - IBAN to the wrong account sends the payment QUEUED A payment engine cannot resolve every payment automatically, so it needs worklists: queues of payments that require a human decision. Step 1 of 6 Payment engine cannot resolve every payment automatically STARTED Payment engine cannot resolve every payment needs worklists: queues of payments ACTIVE Payment of EUR 12,000 example, a payment of EUR 12,000 QUEUED True match means the payment is blocked QUEUED Payment of EUR 25,000 returned with reason code AC04 must have QUEUED Escalation rules decide when a worklist stops waiting for a routine operator QUEUED Repair operator who corrects IBAN to the wrong account sends the QUEUED A payment engine cannot resolve every payment automatically, so it needs worklists: queues of payments that require a human decision.
Payment of EUR 12,000 PAYMENT OPERATIONS IN PROGRESS LIVE 01 Payment engine cannot resolve every payment - needs worklists: queues of DONE 02 Payment of EUR 12,000 - example, a payment of EUR 12,000 ACTIVE 03 True match - means the payment is blocked QUEUED 04 Payment of EUR 25,000 - returned with reason code AC04 must have QUEUED 05 Escalation rules decide when a worklist - stops waiting for a routine operator QUEUED 06 Repair operator who corrects - IBAN to the wrong account sends the payment QUEUED For example, a payment of EUR 12,000 to a supplier in Italy stops because the beneficiary IBAN fails the MOD 97 check. Step 2 of 6 Payment of EUR 12,000 IN PROGRESS Payment engine cannot resolve every payment needs worklists: queues of payments DONE Payment of EUR 12,000 example, a payment of EUR 12,000 ACTIVE True match means the payment is blocked QUEUED Payment of EUR 25,000 returned with reason code AC04 must have QUEUED Escalation rules decide when a worklist stops waiting for a routine operator QUEUED Repair operator who corrects IBAN to the wrong account sends the QUEUED For example, a payment of EUR 12,000 to a supplier in Italy stops because the beneficiary IBAN fails the MOD 97 check.
True match PAYMENT OPERATIONS IN PROGRESS LIVE 01 Payment engine cannot resolve every payment - needs worklists: queues of DONE 02 Payment of EUR 12,000 - example, a payment of EUR 12,000 DONE 03 True match - means the payment is blocked ACTIVE 04 Payment of EUR 25,000 - returned with reason code AC04 must have QUEUED 05 Escalation rules decide when a worklist - stops waiting for a routine operator QUEUED 06 Repair operator who corrects - IBAN to the wrong account sends the payment QUEUED A true match means the payment is blocked Step 3 of 6 True match IN PROGRESS Payment engine cannot resolve every payment needs worklists: queues of payments DONE Payment of EUR 12,000 example, a payment of EUR 12,000 DONE True match means the payment is blocked ACTIVE Payment of EUR 25,000 returned with reason code AC04 must have QUEUED Escalation rules decide when a worklist stops waiting for a routine operator QUEUED Repair operator who corrects IBAN to the wrong account sends the QUEUED A true match means the payment is blocked
Payment of EUR 25,000 PAYMENT OPERATIONS IN PROGRESS LIVE 01 Payment engine cannot resolve every payment - needs worklists: queues of DONE 02 Payment of EUR 12,000 - example, a payment of EUR 12,000 DONE 03 True match - means the payment is blocked DONE 04 Payment of EUR 25,000 - returned with reason code AC04 must have ACTIVE 05 Escalation rules decide when a worklist - stops waiting for a routine operator QUEUED 06 Repair operator who corrects - IBAN to the wrong account sends the payment QUEUED A payment of EUR 25,000 that was returned with reason code AC04 must have an audit trail showing the original instruction, the validation, the clearing message, the return, Step 4 of 6 Payment of EUR 25,000 IN PROGRESS Payment engine cannot resolve every payment needs worklists: queues of payments DONE Payment of EUR 12,000 example, a payment of EUR 12,000 DONE True match means the payment is blocked DONE Payment of EUR 25,000 returned with reason code AC04 must have ACTIVE Escalation rules decide when a worklist stops waiting for a routine operator QUEUED Repair operator who corrects IBAN to the wrong account sends the QUEUED A payment of EUR 25,000 that was returned with reason code AC04 must have an audit trail showing the original instruction, the validation, the clearing message, the return,
Escalation rules decide when a worklist item PAYMENT OPERATIONS IN PROGRESS LIVE 01 Payment engine cannot resolve every payment - needs worklists: queues of DONE 02 Payment of EUR 12,000 - example, a payment of EUR 12,000 DONE 03 True match - means the payment is blocked DONE 04 Payment of EUR 25,000 - returned with reason code AC04 must have DONE 05 Escalation rules decide when a worklist - stops waiting for a routine operator ACTIVE 06 Repair operator who corrects - IBAN to the wrong account sends the payment QUEUED Escalation rules decide when a worklist item stops waiting for a routine operator and goes to a senior operator or a manager. Step 5 of 6 Escalation rules decide when a worklist item IN PROGRESS Payment engine cannot resolve every payment needs worklists: queues of payments DONE Payment of EUR 12,000 example, a payment of EUR 12,000 DONE True match means the payment is blocked DONE Payment of EUR 25,000 returned with reason code AC04 must have DONE Escalation rules decide when a worklist stops waiting for a routine operator ACTIVE Repair operator who corrects IBAN to the wrong account sends the QUEUED Escalation rules decide when a worklist item stops waiting for a routine operator and goes to a senior operator or a manager.
Repair operator who corrects PAYMENT OPERATIONS COMPLETE LIVE 01 Payment engine cannot resolve every payment - needs worklists: queues of DONE 02 Payment of EUR 12,000 - example, a payment of EUR 12,000 DONE 03 True match - means the payment is blocked DONE 04 Payment of EUR 25,000 - returned with reason code AC04 must have DONE 05 Escalation rules decide when a worklist - stops waiting for a routine operator DONE 06 Repair operator who corrects - IBAN to the wrong account sends the payment ACTIVE A repair operator who corrects an IBAN to the wrong account sends the payment to the wrong beneficiary, and the error is only discovered when the intended beneficiary complains. Step 6 of 6 Repair operator who corrects COMPLETE Payment engine cannot resolve every payment needs worklists: queues of payments DONE Payment of EUR 12,000 example, a payment of EUR 12,000 DONE True match means the payment is blocked DONE Payment of EUR 25,000 returned with reason code AC04 must have DONE Escalation rules decide when a worklist stops waiting for a routine operator DONE Repair operator who corrects IBAN to the wrong account sends the ACTIVE A repair operator who corrects an IBAN to the wrong account sends the payment to the wrong beneficiary, and the error is only discovered when the intended beneficiary complains.

Flow of the explanation in this lesson.

0:00 / 6:09 Step 1 of 6

Worklists and audit trails: what operators see and what auditors need

Payment engine internals and observability, Lesson 3 of 7, Narration 6:09, D09 Payment architecture and technology

ISO 20022ClearingReturn

What you will learn

Your objective. By the end of this lesson, you will be able to explain worklists and audit trails: what operators see and what auditors need and apply it to a real banking scenario.

Why it matters. For a business analyst, the requirement is precise: define which actions need four eyes, what the approver must check, and what happens if the approver rejects the action.

Chapter objective: What is inside a payment engine, and how operations sees what it is doing

Key learning points

  • Worklists for manual decisions
  • Operator worklist view
  • Audit evidence and accountability
  • Audit trail completeness
  • Ageing and escalation thresholds
  • Four-eyes approval

Key terms

ISO 20022: An international standard for financial messaging that defines XML message formats for payments, securities and trade.

Clearing: The process of exchanging payment instructions between banks and calculating what each bank owes the others.

Return: A payment that is sent back to the sender after settlement because it cannot be credited to the beneficiary.

Payment flow diagram showing Worklists and audit trails: what operators see and what auditors need.

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 worklists and audit trails: what operators see and what auditors need?

Takeaway and next step

What to remember

For a business analyst, the requirement is precise: define which actions need four eyes, what the approver must check, and what happens if the approver rejects the action.

Follow EUR 12,000 through every stage, from instruction to beneficiary credit, and note where it can stop.

Open the Payment Lifecycle Simulator →

Builds on "Booking entries per message: how a payment posts to the ledger".

Transcript and full text

Show transcript

A payment engine cannot resolve every payment automatically, so it needs worklists: queues of payments that require a human decision. A worklist is not a spreadsheet and not an email inbox; it is a structured queue inside the engine where each item carries the payment, the reason it stopped, the data the operator needs to decide, and the actions available. For a business analyst, the requirement is to define this behaviour explicitly, because the engine does what the requirement says and nothing more. The most common worklists are repairs (a field that could not be resolved), sanctions holds (a name matched a screening list), exceptions (a return, a recall or a duplicate), and investigations (a customer or another bank asking where a payment is). Each worklist has a service level: a repair must be actioned within hours, a sanctions hold within the working day, an investigation within the timeframe the scheme or the correspondent requires. Source: bank payment operations procedures; ISO 20022 investigation message usage guidelines. A repair worklist item carries the full payment instruction, the field that failed, and the reason. For example, a payment of EUR 12,000 to a supplier in Italy stops because the beneficiary IBAN fails the MOD 97 check. The operator sees the instruction, the invalid IBAN, and the suggested correction from the reference data, if one exists. The operator can correct the IBAN, return the payment to the customer for correction, or reject the payment with reason code AC01. Whatever the operator does is recorded: who acted, when, what they changed, and why. A repair that is corrected and released goes back into the engine at the point where it stopped; it does not restart from intake, because re-running intake would re-screen and re-validate a payment that has already passed those stages. A sanctions hold is the most sensitive worklist. When screening flags a payment because a party name, country or reference matches a sanctions list, the payment stops and no one outside the compliance team can see the details. The operator in the sanctions team reviews the match: is it a true match, a false positive, or a near match that needs more information? The review must be fast, because a held payment is a customer waiting. A true match means the payment is blocked and reported; a false positive means the payment is released with a record of the decision and the evidence; a near match means the team asks the customer for more information and the payment waits. The decision, the evidence and the name of the person who made it are all recorded, because a regulator can ask for them years later. A sanctions hold that is released without a recorded decision is a compliance failure, even if the payment itself was legitimate. The audit trail is the record of everything that happened to a payment, and it is not optional. Every state change, every operator action, every message sent and received, every screening result and every decision is written to the audit trail with a timestamp and an actor. The audit trail must be complete, tamper evident and retrievable: complete means no gap between intake and completion, tamper evident means no one can alter an entry after it is written, and retrievable means the bank can produce the full trail for a single payment within hours when a regulator, an auditor or a customer asks. A payment of EUR 25,000 that was returned with reason code AC04 must have an audit trail showing the original instruction, the validation, the clearing message, the return, and every operator who touched it. If any link in that chain is missing, the bank cannot explain what happened to the money. For a business analyst, the requirement is to define what is logged, who can read it, and how long it is kept, because the audit trail is the evidence. Four eyes control applies to the highest risk actions. A payment above a threshold, a manual release from a sanctions hold, or a change to a routing rule requires two people: one to propose the action and another to approve it. The second person must be independent of the first, and the system enforces this by refusing to accept an approval from the same user who proposed the action. Four eyes control is not bureaucracy; it is the control that stops a single operator, whether mistaken or malicious, from releasing a payment that should not go. For a business analyst, the requirement is precise: define which actions need four eyes, what the approver must check, and what happens if the approver rejects the action. Escalation rules decide when a worklist item stops waiting for a routine operator and goes to a senior operator or a manager. A repair that is older than four hours, a sanctions hold that is older than one working day, or an investigation that is older than the scheme deadline all escalate automatically, and the escalation is recorded. The escalation does not change the payment; it changes who is responsible for deciding, and it starts a clock that the manager can see. A worklist without escalation rules is a place where payments go to be forgotten, and a forgotten payment is a customer complaint, a missed cut off, or a regulatory breach. For a business analyst, the requirement is to define the escalation threshold for each worklist, the person it escalates to, and the notification that is sent when it escalates. The operations team must be able to see this state on a dashboard, because a payment that cannot be seen cannot be managed. A worklist item that is resolved incorrectly is worse than one that is not resolved at all, because the error is hidden. A repair operator who corrects an IBAN to the wrong account sends the payment to the wrong beneficiary, and the error is only discovered when the intended beneficiary complains. The defence is a second check for high value repairs: a payment above a threshold that is corrected in a worklist must be reviewed by a second operator before it is released. The second operator checks the correction against the original instruction and the reference data, and either approves it or sends it back. This is four eyes control applied to repairs, and it is the control that stops a typing error from becoming a misdirected payment. Further reading: bank payment operations procedures; ISO 20022 investigation message usage guidelines. Last reviewed 7 November 2026.

A payment engine cannot resolve every payment automatically, so it needs worklists: queues of payments that require a human decision. A worklist is not a spreadsheet and not an email inbox; it is a structured queue inside the engine where each item carries the payment, the reason it stopped, the data the operator needs to decide, and the actions available. For a business analyst, the requirement is to define this behaviour explicitly, because the engine does what the requirement says and nothing more.

The most common worklists are repairs (a field that could not be resolved), sanctions holds (a name matched a screening list), exceptions (a return, a recall or a duplicate), and investigations (a customer or another bank asking where a payment is). Each worklist has a service level: a repair must be actioned within hours, a sanctions hold within the working day, an investigation within the timeframe the scheme or the correspondent requires. Source: bank payment operations procedures; ISO 20022 investigation message usage guidelines.

A repair worklist item carries the full payment instruction, the field that failed, and the reason. For example, a payment of EUR 12,000 to a supplier in Italy stops because the beneficiary IBAN fails the MOD 97 check. The operator sees the instruction, the invalid IBAN, and the suggested correction from the reference data, if one exists. The operator can correct the IBAN, return the payment to the customer for correction, or reject the payment with reason code AC01. Whatever the operator does is recorded: who acted, when, what they changed, and why. A repair that is corrected and released goes back into the engine at the point where it stopped; it does not restart from intake, because re-running intake would re-screen and re-validate a payment that has already passed those stages.

A sanctions hold is the most sensitive worklist. When screening flags a payment because a party name, country or reference matches a sanctions list, the payment stops and no one outside the compliance team can see the details. The operator in the sanctions team reviews the match: is it a true match, a false positive, or a near match that needs more information? The review must be fast, because a held payment is a customer waiting.

A true match means the payment is blocked and reported; a false positive means the payment is released with a record of the decision and the evidence; a near match means the team asks the customer for more information and the payment waits. The decision, the evidence and the name of the person who made it are all recorded, because a regulator can ask for them years later. A sanctions hold that is released without a recorded decision is a compliance failure, even if the payment itself was legitimate.

The audit trail is the record of everything that happened to a payment, and it is not optional. Every state change, every operator action, every message sent and received, every screening result and every decision is written to the audit trail with a timestamp and an actor. The audit trail must be complete, tamper evident and retrievable: complete means no gap between intake and completion, tamper evident means no one can alter an entry after it is written, and retrievable means the bank can produce the full trail for a single payment within hours when a regulator, an auditor or a customer asks.

A payment of EUR 25,000 that was returned with reason code AC04 must have an audit trail showing the original instruction, the validation, the clearing message, the return, and every operator who touched it. If any link in that chain is missing, the bank cannot explain what happened to the money. For a business analyst, the requirement is to define what is logged, who can read it, and how long it is kept, because the audit trail is the evidence.

Four eyes control applies to the highest risk actions. A payment above a threshold, a manual release from a sanctions hold, or a change to a routing rule requires two people: one to propose the action and another to approve it. The second person must be independent of the first, and the system enforces this by refusing to accept an approval from the same user who proposed the action. Four eyes control is not bureaucracy; it is the control that stops a single operator, whether mistaken or malicious, from releasing a payment that should not go. For a business analyst, the requirement is precise: define which actions need four eyes, what the approver must check, and what happens if the approver rejects the action.

Escalation rules decide when a worklist item stops waiting for a routine operator and goes to a senior operator or a manager. A repair that is older than four hours, a sanctions hold that is older than one working day, or an investigation that is older than the scheme deadline all escalate automatically, and the escalation is recorded. The escalation does not change the payment; it changes who is responsible for deciding, and it starts a clock that the manager can see.

A worklist without escalation rules is a place where payments go to be forgotten, and a forgotten payment is a customer complaint, a missed cut off, or a regulatory breach. For a business analyst, the requirement is to define the escalation threshold for each worklist, the person it escalates to, and the notification that is sent when it escalates. The operations team must be able to see this state on a dashboard, because a payment that cannot be seen cannot be managed.

A worklist item that is resolved incorrectly is worse than one that is not resolved at all, because the error is hidden. A repair operator who corrects an IBAN to the wrong account sends the payment to the wrong beneficiary, and the error is only discovered when the intended beneficiary complains. The defence is a second check for high value repairs: a payment above a threshold that is corrected in a worklist must be reviewed by a second operator before it is released.

The second operator checks the correction against the original instruction and the reference data, and either approves it or sends it back. This is four eyes control applied to repairs, and it is the control that stops a typing error from becoming a misdirected payment. Further reading: bank payment operations procedures; ISO 20022 investigation message usage guidelines. Last reviewed 7 November 2026.

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.