Payments Training Hub
Incident: any event PAYMENT OPERATIONS STARTED LIVE 01 Incident - stops or degrades payment processing ACTIVE 02 Incident first hour - follows a fixed sequence. QUEUED 03 Incident communication - during an incident is as important QUEUED 04 Silence during an incident damages trust - more than the incident itself. QUEUED 05 Testing the continuity plan - what makes it real QUEUED An incident is any event that stops or degrades payment processing, from a single system failure to a full site outage. Step 1 of 5 Incident: any event STARTED Incident stops or degrades payment processing ACTIVE Incident first hour follows a fixed sequence. QUEUED Incident communication during an incident is as important QUEUED Silence during an incident damages trust more than the incident itself. QUEUED Testing the continuity plan what makes it real QUEUED An incident is any event that stops or degrades payment processing, from a single system failure to a full site outage.
Incident first hour PAYMENT OPERATIONS IN PROGRESS LIVE 01 Incident - stops or degrades payment processing DONE 02 Incident first hour - follows a fixed sequence. ACTIVE 03 Incident communication - during an incident is as important QUEUED 04 Silence during an incident damages trust - more than the incident itself. QUEUED 05 Testing the continuity plan - what makes it real QUEUED The first hour of an incident follows a fixed sequence. Step 2 of 5 Incident first hour IN PROGRESS Incident stops or degrades payment processing DONE Incident first hour follows a fixed sequence. ACTIVE Incident communication during an incident is as important QUEUED Silence during an incident damages trust more than the incident itself. QUEUED Testing the continuity plan what makes it real QUEUED The first hour of an incident follows a fixed sequence.
Incident communication PAYMENT OPERATIONS IN PROGRESS LIVE 01 Incident - stops or degrades payment processing DONE 02 Incident first hour - follows a fixed sequence. DONE 03 Incident communication - during an incident is as important ACTIVE 04 Silence during an incident damages trust - more than the incident itself. QUEUED 05 Testing the continuity plan - what makes it real QUEUED Communication during an incident is as important as the technical fix. Step 3 of 5 Incident communication IN PROGRESS Incident stops or degrades payment processing DONE Incident first hour follows a fixed sequence. DONE Incident communication during an incident is as important ACTIVE Silence during an incident damages trust more than the incident itself. QUEUED Testing the continuity plan what makes it real QUEUED Communication during an incident is as important as the technical fix.
Silence during an incident damages trust PAYMENT OPERATIONS IN PROGRESS LIVE 01 Incident - stops or degrades payment processing DONE 02 Incident first hour - follows a fixed sequence. DONE 03 Incident communication - during an incident is as important DONE 04 Silence during an incident damages trust - more than the incident itself. ACTIVE 05 Testing the continuity plan - what makes it real QUEUED Silence during an incident damages trust more than the incident itself. Step 4 of 5 Silence during an incident damages trust IN PROGRESS Incident stops or degrades payment processing DONE Incident first hour follows a fixed sequence. DONE Incident communication during an incident is as important DONE Silence during an incident damages trust more than the incident itself. ACTIVE Testing the continuity plan what makes it real QUEUED Silence during an incident damages trust more than the incident itself.
Testing the continuity plan PAYMENT OPERATIONS COMPLETE LIVE 01 Incident - stops or degrades payment processing DONE 02 Incident first hour - follows a fixed sequence. DONE 03 Incident communication - during an incident is as important DONE 04 Silence during an incident damages trust - more than the incident itself. DONE 05 Testing the continuity plan - what makes it real ACTIVE Testing the continuity plan is what makes it real, because an untested plan is only a document. Step 5 of 5 Testing the continuity plan COMPLETE Incident stops or degrades payment processing DONE Incident first hour follows a fixed sequence. DONE Incident communication during an incident is as important DONE Silence during an incident damages trust more than the incident itself. DONE Testing the continuity plan what makes it real ACTIVE Testing the continuity plan is what makes it real, because an untested plan is only a document.

Key points of this lesson, in order.

0:00 / 3:34 Step 1 of 5

Incident Management, Outages and Business Continuity

Payment Operations, Lesson 6 of 7, Narration 3:34, D11 Operations, exceptions and reconciliation

Payment hubGatewaySWIFT

What you will learn

Your objective. By the end of this lesson, you will be able to explain incident management, outages and business continuity. An incident is any event that stops or degrades payment processing, from a single system failure to a full site outage.

Why it matters. The analyst who notices the problem logs it, states the impact in plain language and calls the incident manager.

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

  • Incident: any event
  • Incident first hour
  • Incident communication
  • Silence during an incident damages trust
  • Testing the continuity plan

Key terms

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.

Gateway: A service that connects a merchant website or app to payment networks and acquirers. It encrypts card data, routes authorisation requests, and returns the result to the merchant.

SWIFT: The Society for Worldwide Interbank Financial Telecommunication, a member owned cooperative that provides secure messaging services for financial institutions.

Payment flow diagram showing Incident Management, Outages and Business Continuity.

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

Investigate the reconciliation break described in this lesson and find its root cause.

Use the three-way matching rule and the break categories in this lesson.

  1. What to do. Compare the instruction, the settlement record and the statement, name the break type, and state the corrective action.

Correct result. A break is found by matching amount, currency, date and reference across the three sources. The root cause is a timing difference, an amount difference, a missing entry, or a duplicate, and the corrective action follows the cause.

Why. Reconciliation is the last line of defence. A break that is not investigated is money that cannot be proved.

Check your understanding

Practice question

Which of the following best describes incident management, outages and business continuity?

Takeaway and next step

What to remember

Any failure in the test is logged, fixed and retested, because the bank would rather find the gap on a planned test day than on the day of a real outage.

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

Open the Accounting and Reconciliation Lab →

Builds on "Operational Controls, Queues and Exception Handling".

Transcript and full text

Show transcript

An incident is any event that stops or degrades payment processing, from a single system failure to a full site outage. Incidents are classified by severity, usually from one to four, with severity one meaning customer payments cannot be made at all. A SWIFT gateway failure that stops all cross border payments is severity one, while a slow dashboard that still allows payments to flow is severity three. The classification decides who is called, how fast they must respond and how often senior management is updated. A severity one incident requires the incident manager, the technology lead, the operations manager and the communications team to join a bridge call within fifteen minutes, day or night. The first hour of an incident follows a fixed sequence. The analyst who notices the problem logs it, states the impact in plain language and calls the incident manager. The incident manager opens a bridge call, confirms the scope, and asks technology to diagnose the cause while operations counts the affected payments. If the payment hub is down, operations stops releasing new payments and holds them in a queue so none is lost or duplicated. If the CHAPS system is down, the team checks whether Faster Payments or a correspondent bank can carry the most urgent payments. Customer service is given a short statement to use with callers, so every customer hears the same facts rather than a different guess from each agent. Communication during an incident is as important as the technical fix. Customers need to know what is affected, when it is expected to be fixed and what they should do in the meantime. A bank that cannot process Faster Payments for two hours will tell customers on its website, on its mobile app and through its call centre, and will update the message every thirty minutes even if the news is that there is no change. Corporate customers with a payment of five million pounds due that day receive a direct call from their relationship manager. Regulators are informed within the required time, usually within hours for a major incident, with a factual report that states the cause, the impact and the recovery plan. Silence during an incident damages trust more than the incident itself. Business continuity is the plan for continuing to pay customers when the normal site or system is unavailable. Large banks have a second operations site, often in another city, that can take over within two hours. The plan covers who moves to the second site, which systems are switched over, and how the queues are transferred without losing a payment. The plan also covers a manual fallback, where the most urgent payments are processed by phone and fax with the central bank if the electronic systems are down. A bank in London may have its second site in Manchester, with a duplicate payment hub and a duplicate SWIFT connection, so a fire or a power failure in London does not stop payments for the whole country. Testing the continuity plan is what makes it real, because an untested plan is only a document. Banks test their plans at least once a year, and often twice, by switching operations to the second site for a full working day. During the test, the team processes real payments from the second site, including a CHAPS payment of one million pounds and a Faster Payments batch of 20,000 payments, and confirms that every payment settles correctly. The test also checks that staff can log in, that the telephone system works and that the queues transfer cleanly. Any failure in the test is logged, fixed and retested, because the bank would rather find the gap on a planned test day than on the day of a real outage.

An incident is any event that stops or degrades payment processing, from a single system failure to a full site outage. Incidents are classified by severity, usually from one to four, with severity one meaning customer payments cannot be made at all. A SWIFT gateway failure that stops all cross border payments is severity one, while a slow dashboard that still allows payments to flow is severity three. The classification decides who is called, how fast they must respond and how often senior management is updated. A severity one incident requires the incident manager, the technology lead, the operations manager and the communications team to join a bridge call within fifteen minutes, day or night.

The first hour of an incident follows a fixed sequence. The analyst who notices the problem logs it, states the impact in plain language and calls the incident manager. The incident manager opens a bridge call, confirms the scope, and asks technology to diagnose the cause while operations counts the affected payments. If the payment hub is down, operations stops releasing new payments and holds them in a queue so none is lost or duplicated. If the CHAPS system is down, the team checks whether Faster Payments or a correspondent bank can carry the most urgent payments. Customer service is given a short statement to use with callers, so every customer hears the same facts rather than a different guess from each agent.

Communication during an incident is as important as the technical fix. Customers need to know what is affected, when it is expected to be fixed and what they should do in the meantime. A bank that cannot process Faster Payments for two hours will tell customers on its website, on its mobile app and through its call centre, and will update the message every thirty minutes even if the news is that there is no change. Corporate customers with a payment of five million pounds due that day receive a direct call from their relationship manager. Regulators are informed within the required time, usually within hours for a major incident, with a factual report that states the cause, the impact and the recovery plan. Silence during an incident damages trust more than the incident itself.

Business continuity is the plan for continuing to pay customers when the normal site or system is unavailable. Large banks have a second operations site, often in another city, that can take over within two hours. The plan covers who moves to the second site, which systems are switched over, and how the queues are transferred without losing a payment. The plan also covers a manual fallback, where the most urgent payments are processed by phone and fax with the central bank if the electronic systems are down. A bank in London may have its second site in Manchester, with a duplicate payment hub and a duplicate SWIFT connection, so a fire or a power failure in London does not stop payments for the whole country.

Testing the continuity plan is what makes it real, because an untested plan is only a document. Banks test their plans at least once a year, and often twice, by switching operations to the second site for a full working day. During the test, the team processes real payments from the second site, including a CHAPS payment of one million pounds and a Faster Payments batch of 20,000 payments, and confirms that every payment settles correctly. The test also checks that staff can log in, that the telephone system works and that the queues transfer cleanly. Any failure in the test is logged, fixed and retested, because the bank would rather find the gap on a planned test day than on the day of a real outage.

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.