Payments Academy
Hub operations overview 1 Hub operations overview NOW 2 Monitoring and alerts 3 Queues and exception handling 4 Change management 5 Capacity and peak volumes 6 Worked A payment hub is not finished when it is built; it must be operated every day, and the operational model is as much a design decision as the component catalogue. Step 1 of 6 Hub operations overview 1 NOW Hub operations overview 2 Monitoring and alerts 3 Queues and exception handling 4 Change management 5 Capacity and peak volumes 6 Worked A payment hub is not finished when it is built; it must be operated every day, and the operational model is as much a design decision as the component catalogue. Step 1 of 6
Monitoring and alerts 1 Hub operations overview 2 Monitoring and alerts NOW 3 Queues and exception handling 4 Change management 5 Capacity and peak volumes 6 Worked A growing worklist warns of bad instructions upstream. Step 2 of 6 Monitoring and alerts 1 Hub operations overview 2 NOW Monitoring and alerts 3 Queues and exception handling 4 Change management 5 Capacity and peak volumes 6 Worked A growing worklist warns of bad instructions upstream. Step 2 of 6
Queues and exception handling 1 Hub operations overview 2 Monitoring and alerts 3 Queues and exception handling NOW 4 Change management 5 Capacity and peak volumes 6 Worked The operator must release it, repair it, return it or escalate it, and every decision must be recorded with who made it and why. Step 3 of 6 Queues and exception handling 1 Hub operations overview 2 Monitoring and alerts 3 NOW Queues and exception handling 4 Change management 5 Capacity and peak volumes 6 Worked The operator must release it, repair it, return it or escalate it, and every decision must be recorded with who made it and why. Step 3 of 6
Change management 1 Hub operations overview 2 Monitoring and alerts 3 Queues and exception handling 4 Change management NOW 5 Capacity and peak volumes 6 Worked Every change to a routing rule, a validation rule, a screening list, or engine code goes through a defined process: proposed, reviewed, tested outside production, approved, deployed in a Step 4 of 6 Change management 1 Hub operations overview 2 Monitoring and alerts 3 Queues and exception handling 4 NOW Change management 5 Capacity and peak volumes 6 Worked Every change to a routing rule, a validation rule, a screening list, or engine code goes through a defined process: proposed, reviewed, tested outside production, approved, deployed in a Step 4 of 6
Capacity and peak volumes 1 Hub operations overview 2 Monitoring and alerts 3 Queues and exception handling 4 Change management 5 Capacity and peak volumes NOW 6 Worked If volume is growing 15 percent a year, the team must plan the increase before the hub reaches its limit, not after. Step 5 of 6 Capacity and peak volumes 1 Hub operations overview 2 Monitoring and alerts 3 Queues and exception handling 4 Change management 5 NOW Capacity and peak volumes 6 Worked If volume is growing 15 percent a year, the team must plan the increase before the hub reaches its limit, not after. Step 5 of 6
Worked example and BA test 1 Hub operations overview 2 Monitoring and alerts 3 Queues and exception handling 4 Change management 5 Capacity and peak volumes 6 Worked NOW For a business analyst, product owner or subject matter expert, the test is to state, for the hub you own, what is monitored, what the alert thresholds are, how queues are ordered, how Step 6 of 6 Worked example and BA test 1 Hub operations overview 2 Monitoring and alerts 3 Queues and exception handling 4 Change management 5 Capacity and peak volumes 6 NOW Worked For a business analyst, product owner or subject matter expert, the test is to state, for the hub you own, what is monitored, what the alert thresholds are, how queues are ordered, how Step 6 of 6

Steps of this lesson, in order.

0:00 / 7:04 Step 1 of 6

Hub operations: running a payment hub day to day

Payment Hub: Enterprise Architecture, Lesson 9 of 10, Narration 7:04, D09 Payment architecture and technology

Sanctions screeningPayment hubValue date

What you will learn

Your objective. By the end of this lesson, you will be able to explain hub operations: running a payment hub day to day. A payment hub is not finished when it is built; it must be operated every day, and the operational model is as much a design decision as the component catalogue.

Why it matters. Hub operations is where most payment failures happen, so a BA must be able to specify monitoring, queue priority, exception handling, incident response, change control and capacity, not just the happy path.

Chapter objective: Learner designs enterprise payment hub architecture for a large bank, integrating channels, rails, screening, liquidity, and operations into one governed, scalable platform. Learner practises this skill on realistic banking cases, explaining the reasoning clearly and using correct terminology throughout the work.

Key learning points

  • Hub operations overview
  • Monitoring and alerts
  • Queues and exception handling
  • Change management
  • Capacity and peak volumes
  • Worked example and BA test

Key terms

Sanctions screening: Checking payment parties, countries and references against sanctions lists published by governments and international bodies.

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.

Value date: The date on which funds become available to the beneficiary and on which interest starts to accrue. It is the date used for settlement and for nostro posting.

Banking architecture diagram showing Hub operations: running a payment hub day to day.

Practise this lesson

Exercise

The connection to the clearing system has been down for 90 seconds. State the severity, who is paged, the required response time, and what the operations team must communicate, and then state what happens after the incident is fixed.

A connection down for more than 60 seconds raises a severity one alert and pages the on call engineer. A severity one incident requires a response within 15 minutes. The team must tell the channels, the customer service team and the affected customers what is happening and when it will be fixed.

  1. What to do. Name the severity, the paging action, the response deadline, and the three audiences for communication. Then name the four questions the blameless post mortem must answer.

Correct result. Severity one, because the connection has been down for more than 60 seconds. The on call engineer is paged immediately and must respond within 15 minutes. The team tells the channels, the customer service team and the affected customers what is happening and when it will be fixed. After the incident, the team holds a blameless post mortem answering what happened, why, what will prevent it happening again, and who owns each action.

Why. An incident that is fixed but not communicated is a customer complaint waiting to happen. Severity is not a technical label, it is a promise about how fast someone responds and who is told.

Check your understanding

Practice question

The connection to a clearing system has been down for 90 seconds. What should the operations team do?

Takeaway and next step

What to remember

For a business analyst, product owner or subject matter expert, the test is to state, for the hub you own, what is monitored, what the alert thresholds are, how queues are ordered, how exceptions are decided and recorded, what the incident runbook says, how changes are released and rolled back, and what the peak capacity is.

Send a payment through the hub and watch it pass each component named in this lesson.

Open the Payment Hub Architecture Simulator →

Builds on "Cloud and deployment architecture for payment platforms".

Transcript and full text

Show transcript

A payment hub is not finished when it is built; it must be operated every day, and the operational model is as much a design decision as the component catalogue. Hub operations covers the daily running of the hub: monitoring, queues and exception handling, incident response, change management, capacity management, and the handover between the team that builds the hub and the team that runs it. A hub that is well built but poorly operated will fail in production, and a hub that is well operated but poorly built will fail in a different way, by being impossible to change. This lesson teaches the operational model that a payments SME must be able to specify, test and audit. Source: bank payment operations procedures; Site Reliability Engineering, Google. Monitoring is the first operational duty. The team watches throughput, latency, success rate and queue depth across engines, live. A straight through processing rate falling from 97 percent to 90 percent in an hour is a signal, not a statistic: something changed, and the team must find it before the queue grows. The team also watches worklists: payments waiting in repairs, sanctions holds, and exceptions, and the oldest item's age. A growing worklist warns of bad instructions upstream. External connections are watched too: a connection down for more than 60 seconds raises a severity one alert that pages the on call engineer, while one answering in 5 seconds instead of 200 milliseconds raises a lower alert. Thresholds come from real volumes, not guesses, or false alarms drown the team. Queues are where payments wait, and managing them is a core operational skill. A payment can queue because it is waiting for a cut-off, because it is waiting for liquidity, because a downstream system is slow, or because it is held for manual review. The operations team must know how many payments are in each queue, how long the oldest one has waited, and which queue to release first when capacity returns. Releasing a low value bulk file before a high value property payment is a real error with real consequences, so the release order is a business rule, not a technical default. Exception queues hold the payments that automation could not handle, and they are where operational skill shows most clearly. A payment held for a sanctions alert, a payment with a missing beneficiary detail, or a payment that failed validation all land in an exception queue for a human to decide. The operator must release it, repair it, return it or escalate it, and every decision must be recorded with who made it and why. An exception queue that grows faster than the team can clear it is a capacity problem, and the fix is more people, better rules, or both, not longer hours alone. Incident response is the procedure for when something goes wrong. Every incident has a severity, an owner, and a runbook: a written procedure that tells the on call engineer exactly what to check and what to do. A severity one incident, such as a clearing connection failure, pages the on call engineer immediately, response required within 15 minutes. The team confirms the impact, tells affected customers and stakeholders, switches to the fallback if one exists, and records a timeline. Communication matters as much as the fix, because a treasurer who does not know whether a salary file was sent cannot plan. After the incident, the team holds a blameless post mortem, and the incident closes only when the backlog is cleared and the root cause is recorded, not when the system comes back up. Change management is how the hub is changed without breaking it. Every change to a routing rule, a validation rule, a screening list, or engine code goes through a defined process: proposed, reviewed, tested outside production, approved, deployed in a change window, and verified after deployment. A routing rule change that sends payments to the wrong clearing system is a business incident, not a technical one, so the product owner approves it as well as the technical lead. Changes deploy outside peak hours and must be reversible: if a change causes a problem, the team rolls back within minutes. An irreversible change is a risk not worth taking. For a business analyst, the requirement is to define the change process, approval roles, change window, and rollback procedure. Capacity management is the ongoing work of ensuring the hub can handle the volume it receives. The team reviews actual volume against the capacity model every week, and peak scenarios quarterly. A hub that handles 1.2 million payments on a normal day may face 2 million on a salary Friday, and the team must know the headroom. Capacity is planned from measured peaks, not from averages, and the team tests it with load tests that replay a peak day. If volume is growing 15 percent a year, the team must plan the increase before the hub reaches its limit, not after. If the hub is down for 30 minutes at peak, it must clear the backlog within the next hour, which means it needs spare capacity above the peak rate. A disaster recovery test that has never been run is an assumption, not a control. Worked example. A bank processes 1.2 million payments a day. At 10:00 the sanctions screening service stops responding, and 40,000 payments queue in an hour. The operations team sees the queue depth alert, confirms the screening service is down, and tells the affected corporate customers that their payments are queued, not lost. At 11:00 the service returns, and the team releases the queue oldest first, prioritising 200 high value property payments worth 90 million pounds before the bulk salary files. By 13:00 the queue is clear, and the incident record shows the outage lasted 60 minutes, no payment was duplicated, and three payments missed their value date and were returned with reason code BE01. That record is what the auditor asks for. For a business analyst, product owner or subject matter expert, the test is to state, for the hub you own, what is monitored, what the alert thresholds are, how queues are ordered, how exceptions are decided and recorded, what the incident runbook says, how changes are released and rolled back, and what the peak capacity is. The requirement must name the dashboard, the thresholds, the release order, the decision record and the rollback step. A hub design that says nothing about operations is incomplete, because the hub will be operated every day for years and built only once. Last reviewed 7 November 2026. Further reading: bank payment operations procedures; Site Reliability Engineering, Google.

A payment hub is not finished when it is built; it must be operated every day, and the operational model is as much a design decision as the component catalogue. Hub operations covers the daily running of the hub: monitoring, queues and exception handling, incident response, change management, capacity management, and the handover between the team that builds the hub and the team that runs it. A hub that is well built but poorly operated will fail in production, and a hub that is well operated but poorly built will fail in a different way, by being impossible to change. This lesson teaches the operational model that a payments SME must be able to specify, test and audit. Source: bank payment operations procedures; Site Reliability Engineering, Google.

Monitoring is the first operational duty. The team watches throughput, latency, success rate and queue depth across engines, live. A straight through processing rate falling from 97 percent to 90 percent in an hour is a signal, not a statistic: something changed, and the team must find it before the queue grows. The team also watches worklists: payments waiting in repairs, sanctions holds, and exceptions, and the oldest item's age. A growing worklist warns of bad instructions upstream. External connections are watched too: a connection down for more than 60 seconds raises a severity one alert that pages the on call engineer, while one answering in 5 seconds instead of 200 milliseconds raises a lower alert. Thresholds come from real volumes, not guesses, or false alarms drown the team.

Queues are where payments wait, and managing them is a core operational skill. A payment can queue because it is waiting for a cut-off, because it is waiting for liquidity, because a downstream system is slow, or because it is held for manual review. The operations team must know how many payments are in each queue, how long the oldest one has waited, and which queue to release first when capacity returns. Releasing a low value bulk file before a high value property payment is a real error with real consequences, so the release order is a business rule, not a technical default.

Exception queues hold the payments that automation could not handle, and they are where operational skill shows most clearly. A payment held for a sanctions alert, a payment with a missing beneficiary detail, or a payment that failed validation all land in an exception queue for a human to decide. The operator must release it, repair it, return it or escalate it, and every decision must be recorded with who made it and why. An exception queue that grows faster than the team can clear it is a capacity problem, and the fix is more people, better rules, or both, not longer hours alone.

Incident response is the procedure for when something goes wrong. Every incident has a severity, an owner, and a runbook: a written procedure that tells the on call engineer exactly what to check and what to do. A severity one incident, such as a clearing connection failure, pages the on call engineer immediately, response required within 15 minutes. The team confirms the impact, tells affected customers and stakeholders, switches to the fallback if one exists, and records a timeline. Communication matters as much as the fix, because a treasurer who does not know whether a salary file was sent cannot plan. After the incident, the team holds a blameless post mortem, and the incident closes only when the backlog is cleared and the root cause is recorded, not when the system comes back up.

Change management is how the hub is changed without breaking it. Every change to a routing rule, a validation rule, a screening list, or engine code goes through a defined process: proposed, reviewed, tested outside production, approved, deployed in a change window, and verified after deployment. A routing rule change that sends payments to the wrong clearing system is a business incident, not a technical one, so the product owner approves it as well as the technical lead. Changes deploy outside peak hours and must be reversible: if a change causes a problem, the team rolls back within minutes. An irreversible change is a risk not worth taking. For a business analyst, the requirement is to define the change process, approval roles, change window, and rollback procedure.

Capacity management is the ongoing work of ensuring the hub can handle the volume it receives. The team reviews actual volume against the capacity model every week, and peak scenarios quarterly. A hub that handles 1.2 million payments on a normal day may face 2 million on a salary Friday, and the team must know the headroom. Capacity is planned from measured peaks, not from averages, and the team tests it with load tests that replay a peak day. If volume is growing 15 percent a year, the team must plan the increase before the hub reaches its limit, not after. If the hub is down for 30 minutes at peak, it must clear the backlog within the next hour, which means it needs spare capacity above the peak rate. A disaster recovery test that has never been run is an assumption, not a control.

Worked example. A bank processes 1.2 million payments a day. At 10:00 the sanctions screening service stops responding, and 40,000 payments queue in an hour. The operations team sees the queue depth alert, confirms the screening service is down, and tells the affected corporate customers that their payments are queued, not lost. At 11:00 the service returns, and the team releases the queue oldest first, prioritising 200 high value property payments worth 90 million pounds before the bulk salary files. By 13:00 the queue is clear, and the incident record shows the outage lasted 60 minutes, no payment was duplicated, and three payments missed their value date and were returned with reason code BE01. That record is what the auditor asks for.

For a business analyst, product owner or subject matter expert, the test is to state, for the hub you own, what is monitored, what the alert thresholds are, how queues are ordered, how exceptions are decided and recorded, what the incident runbook says, how changes are released and rolled back, and what the peak capacity is. The requirement must name the dashboard, the thresholds, the release order, the decision record and the rollback step. A hub design that says nothing about operations is incomplete, because the hub will be operated every day for years and built only once. Last reviewed 7 November 2026. Further reading: bank payment operations procedures; Site Reliability Engineering, Google.

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.