Flow of the explanation in this lesson.
Incident management and reporting: the first 72 hours of a payment outage
What you will learn
Your objective. By the end of this lesson, you will be able to explain incident management and reporting: the first 72 hours of a payment outage and apply it to a real banking scenario.
Why it matters. For a business analyst, incident management is a set of requirements and a set of test scenarios.
Chapter objective: Data protection, US anti-money-laundering law, and keeping payments running under stress
Key learning points
- Customer impact assessment
- Regulator notification
- Manual processing
- DORA final incident report
- Duplicate payment root cause
- Further reading and sources
Key terms
Reconciliation: The process of comparing records from two sources, such as a bank statement and an internal ledger, to confirm they agree.
Payment hub: A central system in a bank that receives payment instructions from all channels, validates them, applies screening and routing rules, and sends them to the correct clearing system or correspondent.
Idempotency: The property that repeating the same request has the same effect as sending it once. In payments, an idempotency key lets a client safely retry a request after a timeout without creating a duplicate...
Payment flow diagram showing Incident management and reporting: the first 72 hours of a payment outage.
Practise this lesson
Exercise
Work out what the beneficiary receives for a $10,000 payment under OUR, SHA and BEN.
Use the charge arrangement rules in this lesson and the correspondent and beneficiary bank fees named in the lesson.
- What to do. Calculate the amount credited under each of the three arrangements and state who pays each fee.
Correct result. Under OUR the sender pays all charges and the beneficiary receives the full amount. Under SHA the sender pays the sending charges and the beneficiary pays the receiving charges. Under BEN the beneficiary pays all charges and receives the amount less all fees.
Why. The charge arrangement decides who pays and how much arrives. A customer who was promised the full amount and receives less will complain, and the complaint lands on the analyst.
Check your understanding
Practice question
Which of the following best describes incident management and reporting: the first 72 hours of a payment outage?
Takeaway and next step
What to remember
The messages must be consistent, and the customer message must never promise a time the firm cannot meet.
Follow a payment through every stage, from instruction to beneficiary credit, and note where it can stop.
Open the Payment Lifecycle Simulator →
Builds on "Operational resilience and DORA: staying open when things break".
Transcript and full text
Show transcript
When a payment service fails, the first question is not what broke, it is how many customers are affected and how long they will wait. The incident manager's first job is to declare the incident, to classify it, and to start the clock. Classification uses the criteria written in advance: the number of payments delayed, the value at risk, whether an important business service is affected, and whether customer money is at risk. A payment hub that stops processing for 30 minutes is a major incident if it holds 50,000 payments; the same 30 minutes is minor if it holds 50. Communication during a payment incident has three audiences, and each needs a different message. Customers need to know their payment is delayed, when it will be made, and what to do if it is urgent. The regulator needs the facts: what happened, how many payments are affected, what the firm is doing, and when the next update will come. Internal teams need the technical detail: which component failed, what the workaround is, and who is working on it. The messages must be consistent, and the customer message must never promise a time the firm cannot meet. The workaround is the most important decision in the first hour. When the payment hub fails, the options are to queue the payments and wait, to route them through a backup hub, or to process them manually. Queuing is safe but slow, and the queue grows by thousands of payments an hour. A backup hub is fast but must have the same screening, the same limits, and the same ledger, or the payments it processes will be wrong. Manual processing is the last resort, and it needs a pre-written procedure, a list of who can authorise it, and a reconciliation plan for afterwards. Recovery is not the same as restoration. Restoration means the system is running again. Recovery means every payment that was delayed has been made, every ledger entry is correct, and every customer who was affected has been told. The recovery plan must include a reconciliation of the payment queue against the ledger, a check that no payment was made twice, and a check that no payment was lost. The most dangerous moment in a payment incident is the restart, because a queue that is released without a duplicate check will double-pay. The incident report is a legal and a learning document. Under DORA the final report is due within one month, and it must describe the root cause, the impact, the actions taken, and the measures that will prevent a recurrence. Under the UK rules the Bank of England expects the same. The report must be honest about what went wrong, including human error and process failure, because a report that blames only the technology will not prevent the next incident. The report goes to the board, and the board must track the remediation actions to completion. Root cause analysis in payments usually finds a process failure behind the technical failure. A payment hub that ran out of disk space failed because nobody monitored the disk. A screening rule that blocked 10,000 legitimate payments failed because the rule change was not tested. A duplicate payment happened because the idempotency key was not carried through a retry. The analysis must therefore cover the change that introduced the fault, the monitoring that missed it, and the control that should have caught it, not just the component that broke. For a business analyst, incident management is a set of requirements and a set of test scenarios. The requirements must state the classification criteria, the communication templates, the workaround procedures, and the recovery checklist. The test scenarios must include a hub failure, a screening outage, a ledger mismatch, and a duplicate payment on restart. The acceptance criteria must include a test where the incident is declared, the workaround is invoked, and the recovery reconciliation balances to zero. Last reviewed 7 November 2026. Further reading: Regulation (EU) 2022/2554, Article 19; Bank of England operational resilience policy on incident reporting; Payment Systems Regulator guidance on payment system incidents; ISO 22301 on business continuity management.
When a payment service fails, the first question is not what broke, it is how many customers are affected and how long they will wait. The incident manager's first job is to declare the incident, to classify it, and to start the clock. Classification uses the criteria written in advance: the number of payments delayed, the value at risk, whether an important business service is affected, and whether customer money is at risk. A payment hub that stops processing for 30 minutes is a major incident if it holds 50,000 payments; the same 30 minutes is minor if it holds 50.
Communication during a payment incident has three audiences, and each needs a different message. Customers need to know their payment is delayed, when it will be made, and what to do if it is urgent. The regulator needs the facts: what happened, how many payments are affected, what the firm is doing, and when the next update will come. Internal teams need the technical detail: which component failed, what the workaround is, and who is working on it. The messages must be consistent, and the customer message must never promise a time the firm cannot meet.
The workaround is the most important decision in the first hour. When the payment hub fails, the options are to queue the payments and wait, to route them through a backup hub, or to process them manually. Queuing is safe but slow, and the queue grows by thousands of payments an hour. A backup hub is fast but must have the same screening, the same limits, and the same ledger, or the payments it processes will be wrong. Manual processing is the last resort, and it needs a pre-written procedure, a list of who can authorise it, and a reconciliation plan for afterwards.
Recovery is not the same as restoration. Restoration means the system is running again. Recovery means every payment that was delayed has been made, every ledger entry is correct, and every customer who was affected has been told. The recovery plan must include a reconciliation of the payment queue against the ledger, a check that no payment was made twice, and a check that no payment was lost. The most dangerous moment in a payment incident is the restart, because a queue that is released without a duplicate check will double-pay.
The incident report is a legal and a learning document. Under DORA the final report is due within one month, and it must describe the root cause, the impact, the actions taken, and the measures that will prevent a recurrence. Under the UK rules the Bank of England expects the same. The report must be honest about what went wrong, including human error and process failure, because a report that blames only the technology will not prevent the next incident. The report goes to the board, and the board must track the remediation actions to completion.
Root cause analysis in payments usually finds a process failure behind the technical failure. A payment hub that ran out of disk space failed because nobody monitored the disk. A screening rule that blocked 10,000 legitimate payments failed because the rule change was not tested. A duplicate payment happened because the idempotency key was not carried through a retry. The analysis must therefore cover the change that introduced the fault, the monitoring that missed it, and the control that should have caught it, not just the component that broke.
For a business analyst, incident management is a set of requirements and a set of test scenarios. The requirements must state the classification criteria, the communication templates, the workaround procedures, and the recovery checklist. The test scenarios must include a hub failure, a screening outage, a ledger mismatch, and a duplicate payment on restart. The acceptance criteria must include a test where the incident is declared, the workaround is invoked, and the recovery reconciliation balances to zero. Last reviewed 7 November 2026. Further reading: Regulation (EU) 2022/2554, Article 19; Bank of England operational resilience policy on incident reporting; Payment Systems Regulator guidance on payment system incidents; ISO 22301 on business continuity management.
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.