Every KSA bank has a disaster recovery document. Most of them describe a warm standby that was last tested two quarters ago, a failover RTO measured in hours, and a replication lag that nobody monitors in production. When SAMA asks for the business continuity assessment, the document passes. When the WAN link fails for six hours, the document is irrelevant.
The question of where to put a second copy of financial data — and how to keep it in sync — is not primarily a technology question. It is a question about what the organisation is actually prepared to operate. Active/active multi-region replication is not a higher ambition than active/passive. It is a different risk profile, a different operational burden, and a fundamentally different set of design constraints on every system that writes to the database. Whether it is the right choice depends on questions that the VP of Enterprise Integration or Chief Architect has to answer before the engineering team starts configuring anything.
What the regulator actually requires
SAMA’s Technology Risk Management framework specifies that critical financial systems must have documented and tested business continuity plans with explicit RPO and RTO targets. For payment systems, the typical expectation is RPO measured in seconds, not minutes, and RTO measured in minutes, not hours. The framework does not mandate a specific topology — it mandates a tested outcome. An active/passive deployment with a fifteen-minute manual failover procedure can satisfy SAMA’s requirements if the fifteen minutes is within the approved RTO and the procedure is tested and documented.
The practical constraint is data residency. Both the primary site and any replication target must sit within KSA’s geographic and regulatory boundary. A cross-region DR site in a European AWS region is not compliant, regardless of encryption. SAMA maintains a list of approved cloud regions and an approval process for cloud-hosted DR; staying current with that list is an operational discipline, not a one-time procurement decision.
The SAMA audit question is not “which topology do you use?” It is: “Show me the last tested failover, the actual RTO achieved, and the replication lag at the moment of the test.” A live dashboard and a DR drill log are worth more than any architecture diagram.
What the topology choice looks like to the business
Three topologies appear in KSA bank multi-region deployments, with very different cost and capability profiles.
Active/passive (warm standby) is the minimum. The secondary site holds a copy of the data, receives replication, but serves no live traffic. Failover is manual or semi-automated and takes minutes to hours. The cost is low — the standby infrastructure is idle under normal conditions — but so is the availability benefit. An active/passive deployment protects against total loss of the primary site. It does not protect against anything that takes less than the failover time to cause business impact.
Active/hot-standby is where most mature KSA banks land after their first real DR incident. The standby receives continuous replication, serves read traffic under normal operation, and can be promoted in seconds using automated tools like Patroni for PostgreSQL or a configured Db2 HADR takeover. The read traffic served from the standby is slightly stale — by seconds under normal WAN conditions — which is acceptable for reference data lookups but not for balance reads that precede an authorisation decision. The operational cost is moderate: the standby infrastructure is active and must be monitored, and the promotion procedure must be rehearsed. The availability benefit is substantial: an automated failover of ten to thirty seconds is materially different from a manual process of fifteen minutes.
Active/active is the aspirational topology and the one most frequently oversold by platform vendors. Both regions accept write traffic simultaneously and replicate changes to each other. The latency benefit is real in specific scenarios — a customer in Jeddah whose writes go to a Jeddah replica instead of traversing the WAN to Riyadh. But the fundamental problem is write conflicts: when two regions receive writes to the same data before either replication stream catches up, you have a conflict, and no replication technology resolves financial conflicts correctly without application-layer business logic. The team that ships active/active successfully is the team that has already defined, tested, and operationalised its write ownership model — knowing which region owns which entity for writes, and routing accordingly — before changing the topology.
The decision the architecture team needs from leadership
The topology choice cannot be delegated to the engineering team, because it implies an organisational commitment that the engineering team cannot make unilaterally. Active/hot-standby requires an on-call rota that can respond to a failover alert at 3am, a tested promotion procedure, and a monitoring setup that pages before the lag becomes a problem. Active/active requires all of that, plus a write-routing service, a conflict resolution strategy reviewed by the risk team, and a set of integration tests that verify the conflict-free path for every entity type the system manages. Both require budget, headcount, and a testing cadence that most delivery programmes do not plan for.
The leadership decision is: which of these commitments are we prepared to make and sustain? Not which topology is most technically elegant, and not which topology the vendor recommended. The question is operational maturity.
A workable sequencing principle: start with active/hot-standby and an automated promotion tool. Instrument the replication lag. Perform a live DR test within the first three months — not a table-top exercise, a real promotion of the standby to primary with live traffic. Measure the actual RTO. If the actual RTO satisfies SAMA and the business, hold the topology there and invest the saved complexity budget in monitoring and testing discipline. Consider active/active only when a specific latency or availability requirement cannot be met by hot-standby with automated failover, and only after the write ownership model for every affected entity has been formally documented and approved.
What the team needs from leadership to ship it
The most common failure mode in cross-region replication projects is that the replication infrastructure is built and declared done, and the DR testing is planned for “after stabilisation.” Stabilisation arrives; the DR test is deferred to avoid risk; the team rotates; the DR test never happens. The standby drifts. The SAMA audit finds a gap. A real incident reveals that the tested-on-paper DR capability does not exist in practice.
Leadership needs to treat the first successful DR test as a delivery milestone with the same status as a production go-live. It should be date-committed, it should have a defined success criterion (actual RTO under X minutes, zero data loss, application reconnects without restart), and it should be signed off by the same governance process that signs off production deployments.
The other ask: fund the monitoring. Replication lag alerts, data-age dashboards, and heartbeat checks on the replication connectors are not optional instrumentation that the team adds later. They are the foundation of the operational capability that SAMA is reviewing. A multi-region deployment with no replication observability is not a DR capability — it is a DR document with infrastructure underneath it. The gap between those two things is where production incidents occur.
For the engineering depth behind this pattern — MirrorMaker 2 configuration, Postgres synchronous_commit modes, Db2 HADR NEARSYNC vs SUPERASYNC, Patroni cross-region etcd setup, and the Prometheus alert rules for replication lag — see the companion Lab article: Cross-Region Replication Patterns.