Payments DR, exit plan and an untested runbook

Active-active across two providers would give strong recovery characteristics, but it exceeds the approved funding because it requires a permanent duplicate active environment, and it exceeds the team's proven capability because dual-provider networking has never been operated. The proprietary queuing service also creates a portability gap that active-active does not solve by itself. Recommend a warm-standby or pilot-light design for the critical payment path in the second provider, with continuous data replication or log shipping sufficient to meet a 2-minute recovery point objective, and automated failover designed for a 15-minute recovery time objective. Keep the primary active-passive across availability zones, but replace nightly backup-only replication with a mechanism that meets the RPO. Abstract or replace the proprietary queue where feasible, and document the exit sequence. This direction respects the funding ceiling, matches operational maturity, and gives the regulator evidence of portability. It also follows start where you are and progress iteratively: prove failover and runbooks before considering full active-active. Active-active remains a future option only after dual-provider operations are demonstrated.

The six-hour restore against a 15-minute RTO is a governance problem because the service is advertised at 99.99% while recovery capability is unproven and far outside the objective; customers and the regulator are relying on a claim that testing contradicts. Build an annual and change-triggered test programme: test failover to the second provider, restore from replicated data, validate data integrity, exercise runbooks with named roles, measure actual RTO and RPO, and record evidence. Start with a non-production rehearsal, then a controlled production failover in a low-traffic window, then a full exercise with customer communication. Include dependencies such as identity, DNS, payment networks and the proprietary queue. After each test, update the service continuity management plan, runbooks and the risk register. The reasoning is that continuity is a management system, not a backup job. The absence of runbooks and the six-hour result show that recovery depends on improvisation; the regulator's annual proof requirement makes tested evidence part of the licence to operate. Report results to the board, including gaps and remediation dates, rather than reporting only that a backup exists.

Replace the single "payments processing" entry with service offerings that distinguish the core authorization service, settlement reporting and support. For each, state service hours, availability objective, recovery time and recovery point objectives, maintenance windows, support and escalation paths, price model, data residency, and the shared-responsibility matrix. Customers must be told what the processor controls and what they control: the processor owns the platform, replication, failover and transaction processing; the customer owns its credentials, payment instructions, reconciliation and downstream systems. State exclusions and dependencies, including payment-network outages and customer-side integration failures. Avoid advertising 99.99% without qualifying whether it applies during a declared disaster and how it is measured. The catalogue should also explain how to invoke disaster recovery and what communication to expect. The reasoning is that customers make operational and regulatory decisions from the catalogue; an incomplete entry shifts risk to them silently. Service catalogue management and service level management should keep the entry aligned with tested capability, not aspiration.