Disaster Recovery and Business Continuity for Treasury Systems

Disaster recovery restores the treasury systems; business continuity keeps the treasury function running while they're down — and in treasury the second one is what actually matters. Most functions can absorb a day's outage as an inconvenience. Treasury can't, because it carries hard, time-bound obligations that don't wait for a system to come back. The design that keeps you safe isn't a bigger backup regime; it's two honest numbers, a manual fallback for the critical few, and a test that proves both work before the day you need them.

Why treasury is special

Most systems, if they go down for a day, cost you productivity. Treasury systems, if they go down on the wrong day, cost you a missed payment — and treasury's payments have deadlines that are external and unforgiving. Payroll runs on a date. A debt repayment or coupon is due on a date, and being late is a default event, not a late fee. A margin call has to be met within hours. None of these wait politely while IT restores a database.

That's why continuity planning for treasury is a different exercise from continuity planning for the intranet. The question isn't "how do we get the system back?" It's "what must we still be able to do while it's gone?" It sits on the same reference architecture as everything else, but asks a harder question of it: what happens when a layer disappears?

RTO and RPO, plainly

Two numbers drive the entire design.

• Recovery Time Objective (RTO) — how fast you must be back: the maximum time the treasury system can be unavailable before the outage causes real damage.
• Recovery Point Objective (RPO) — how much data you can afford to lose: the maximum gap between your last recoverable state and the moment of failure. An RPO of four hours means accepting the loss of up to four hours of captured deals and payments.

Everything else — backup frequency, replication, failover architecture, cost — falls out of these two numbers. And here is the point most plans get backwards: RTO and RPO must be set by the business obligation, not by IT convenience. If a payment run has to go out by 2pm, the RTO for the payment path is dictated by that deadline, full stop — not by whatever recovery window the infrastructure team finds comfortable to promise.

"

RTO and RPO are business decisions wearing technical clothing. If the payment is due at 2pm, no amount of "24 hours is our standard" changes what the business actually needs. Set the numbers from the obligation, then make the architecture meet them.

DR is not BC

These get used interchangeably and they shouldn't. Disaster recovery is recovering the systems and infrastructure — restore the database, fail over to the secondary site, rebuild the connectivity. Business continuity is keeping the treasury function going whatever state the systems are in, including operating in a degraded or fully manual mode. DR is a technology problem; BC is an operational one, and it's the one that pays a supplier when the TMS is dark.

Moving to SaaS changes the shape of this but not the accountability. A vendor-hosted TMS shifts much of the infrastructure DR onto the vendor — their replication, their failover, their RTO — which is genuinely useful, but it doesn't discharge your responsibility. You still own the function. Know the vendor's committed RTO and RPO (read the contract, not the sales deck), what happens when your connectivity or market-data feed fails rather than theirs, and what you do while the vendor is recovering. Outsourcing the servers doesn't outsource the obligation to make payroll.

The manual fallback

This is the uncomfortable part of the plan, and the part that earns its place. When the straight-through flows stop — the automated pipelines that normally move money from initiation to settlement without a human — someone has to release the critical payments by hand. Not everything. The critical few.

A real fallback answers three questions before the crisis, not during it:

• Which actions genuinely can't wait? Payroll, a debt repayment falling due, a margin call. Draw the line deliberately; most of what treasury does can wait a day.
• How do we do them without the system? Direct access to the relevant bank portals, the beneficiary details you'd need, and a way to approve within your control limits outside the usual workflow.
• Who is authorised, and can they actually get in? Named people with live credentials, tokens that exist and work, and approval authority that holds when the normal monitored workflow isn't there to enforce it.

The manual fallback is deliberately minimal and deliberately ugly. Its job is to get the unmissable payments out while DR does its work — nothing more.

Backups, failover, and the thing that separates real plans from paper ones

The technical building blocks are well understood: regular backups tested for restore and not just for completion, replication or failover to a secondary environment, and a defined sequence for bringing systems back in the right order. None of that is exotic.

What separates a real plan from a filed one is testing. An untested DR plan is not a plan; it's a hypothesis. Until you've restored the treasury database into a clean environment and confirmed it comes up consistent, you don't know your backups are recoverable — you know they completed, which is not the same thing. Test the restore and test the fallback, on a realistic scenario, on a schedule.

Recovering the TMS alone isn't recovery

A treasury system that's back up but can't reach the banks still can't pay. Recovery has to include the dependencies: bank connectivity (SWIFT, host-to-host, EBICS or API channels, and the certificates and tokens they rely on), market-data feeds, and the interfaces to and from the ERP. Each has its own recovery path and its own failure modes, and a plan that recovers the core application while ignoring them has recovered a box that can't do its job. Map the full dependency chain and give each link a recovery plan.

Docs-vs-reality

Continuity plans have a characteristic failure: they're written for the audit, approved, filed, and never opened again — a document that exists to answer "do you have a BCP?" with "yes." It ticks the box and has never met a real outage.

Every time I've seen a treasury continuity plan actually tested against a realistic scenario, the test found something the document couldn't. The manual fallback assumed a bank token nobody could locate. It named an authoriser who had left eighteen months earlier and whose access had been revoked. The RPO on paper was four hours; the actual backup job had been failing silently for weeks. The plan wasn't wrong when it was written — it rotted, quietly, because nothing ever exercised it.

That's the entire argument for testing, and it's why continuity for treasury can't be a document exercise. The obligations are real, dated, and external. The plan that protects you isn't the one that reads best in the audit binder — it's the one that has been run, broken, and fixed, so that on the day the system is down you already know the fallback works and the token is where the plan says it is.

Part of the Treasury Systems Architecture guide. See also straight-through processing and interface monitoring and reconciliation. The newsletter sends one finance-systems pattern every two weeks.