RIYADH, 4 March 2026 — Yusr Bank today announced the completion of an eighteen-month programme to rebuild how its banking platform survives failure. The work began in September 2024, before the app opened to the public, and finished with a full rehearsal in February in which the entire customer-facing platform was moved to the bank's secondary region and back again while customers were using it.
Yusr's primary systems run in-Kingdom, in the cloud provider's Riyadh region. That has been true since day one and has not changed. What the programme added is a properly engineered second place to run from: a secondary region in Frankfurt, Germany, held for continuity and disaster recovery, kept continuously in sync with Riyadh rather than held cold and reconstructed from backups after the fact.
The distinction matters more than it sounds. A cold standby is a promise about a rebuild — someone restores last night's backup, someone else checks it, and the clock runs the whole time. A warm, continuously replicated region is a switch. Yusr's databases stream changes to Frankfurt as they are committed, the same application versions run in both places, and the configuration that ties them together is generated from one source rather than maintained twice by hand.
What the programme delivered
Continuous replication. Every committed change is streamed to the secondary region as it happens, giving a recovery point objective measured in seconds rather than hours.
A fifteen-minute objective. From the decision to fail over to the app serving customers from the secondary region, the target is under fifteen minutes. February's rehearsal came in at eleven.
Quarterly exercises. Failover is now rehearsed four times a year against the live platform, not modelled on paper. The next exercise is scheduled for June.
Independent review. The design and the rehearsal evidence were reviewed by an external assurance firm and by the bank's own internal audit function before the programme was signed off.