Operational Dashboards, KPIs, Resilience and Disaster Recovery

An operational dashboard shows volumes, straight through processing rate, exception ageing, settlement positions and queue depths in one view, so the duty manager can see the health of the payment service at a glance. Volumes show how many payments arrived, settled, and are still in flight, while the straight through processing rate shows the share needing no manual touch, and a falling rate usually means a data or rule problem upstream. Exception ageing shows how long breaks and held payments have waited, settlement positions show the cash available at each correspondent, and queue depths show how many messages wait in each queue. In the worked example, the morning dashboard shows the USD 120,000 payment settled and reconciled, one held cover released, and no exception older than four hours. Testing the dashboard means checking each figure against its source system and confirming a stuck queue changes the dashboard within a minute. Key performance indicators turn the dashboard into action, because each KPI carries a target and an alert threshold that tells operations when to act. Common KPIs are the straight through processing rate, the percentage of payments settled by cut off, the average exception age, the reconciliation match rate, and the number of payments in suspense. When the straight through processing rate falls below 95 percent, or when an exception ages past four hours, an alert fires and the duty manager assigns the work. In the worked example, Meridian Bank targets 98 percent straight through processing and a reconciliation match rate above 99 percent, and the USD 120,000 payment met both because it settled on time and matched the next morning. Testing KPIs means forcing a rate below its threshold, confirming the alert fires, and confirming the alert reaches the right team with the right detail. Recovery time objective and recovery point objective define how fast the service must return and how much data it may lose, and both are agreed with the business before a disaster. The recovery time objective is the maximum time the service may be down, for example two hours, and the recovery point objective is the maximum data loss, for example five minutes of transactions. A short recovery time objective needs standby systems already running, while a short recovery point objective needs continuous data replication between sites. In the worked example, Meridian Bank sets a two hour recovery time objective and a five minute recovery point objective, so a failure at ten in the morning must be recovered by 12 noon with no payment older than five minutes to ten in the morning lost. Testing these objectives means failing over in a rehearsal and measuring the real recovery time and data loss against the targets. Active active resilience runs the payment service in two data centres at once, sharing traffic between them, so if one centre fails the other keeps working. Active passive resilience runs the service in one centre and keeps a standby in a second, which takes over only when the first fails, and cut over takes longer because the standby must start and catch up. Disaster recovery testing proves the plan works, by failing over to the standby in a rehearsal, processing payments there, and failing back, with results recorded and gaps fixed. In the worked example, Meridian Bank runs active active across two centres, and its twice yearly rehearsal cuts over the payment flow, confirms no payment is lost or duplicated, and returns traffic. Testing resilience means killing one centre in a rehearsal and confirming payments keep flowing, the dashboard stays live, and the cut over procedure is followed.