[{"data":1,"prerenderedAt":297},["ShallowReactive",2],{"blog-\u002Fblog\u002Fdisaster-recovery-business-continuity-treasury":3,"blog-surround-\u002Fblog\u002Fdisaster-recovery-business-continuity-treasury":275,"blog-related-\u002Fblog\u002Fdisaster-recovery-business-continuity-treasury":284},{"id":4,"title":5,"audience":6,"body":10,"cluster":242,"date":243,"description":244,"draft":245,"extension":246,"faq":247,"featured":245,"language":257,"meta":258,"navigation":259,"order":260,"path":261,"pillar":262,"primaryKeyword":263,"relatedProject":257,"reviewCycle":264,"searchIntent":265,"seo":266,"stem":267,"tags":268,"type":273,"updated":243,"__hash__":274},"blog\u002Fblog\u002Fdisaster-recovery-business-continuity-treasury.md","Disaster Recovery and Business Continuity for Treasury Systems",[7,8,9],"treasury-system-lead","solution-architect","group-treasurer",{"type":11,"value":12,"toc":231},"minimark",[13,26,31,34,43,47,50,66,73,79,83,97,107,111,123,126,155,158,162,169,180,184,192,196,199,202,205,208],[14,15,16,25],"p",{},[17,18,19,20,24],"strong",{},"Disaster recovery restores the treasury systems; business continuity keeps the treasury ",[21,22,23],"em",{},"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.",[27,28,30],"h2",{"id":29},"why-treasury-is-special","Why treasury is special",[14,32,33],{},"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.",[14,35,36,37,42],{},"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 ",[38,39,41],"a",{"href":40},"\u002Fblog\u002Freference-architecture-for-corporate-treasury","reference architecture"," as everything else, but asks a harder question of it: what happens when a layer disappears?",[27,44,46],{"id":45},"rto-and-rpo-plainly","RTO and RPO, plainly",[14,48,49],{},"Two numbers drive the entire design.",[51,52,53,60],"ul",{},[54,55,56,59],"li",{},[17,57,58],{},"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.",[54,61,62,65],{},[17,63,64],{},"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.",[14,67,68,69,72],{},"Everything else — backup frequency, replication, failover architecture, cost — falls out of these two numbers. And here is the point most plans get backwards: ",[17,70,71],{},"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.",[74,75,76],"pull-quote",{},[14,77,78],{},"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.",[27,80,82],{"id":81},"dr-is-not-bc","DR is not BC",[14,84,85,86,89,90,93,94,96],{},"These get used interchangeably and they shouldn't. ",[17,87,88],{},"Disaster recovery"," is recovering the systems and infrastructure — restore the database, fail over to the secondary site, rebuild the connectivity. ",[17,91,92],{},"Business continuity"," is keeping the treasury ",[21,95,23],{}," 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.",[14,98,99,100,102,103,106],{},"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 ",[21,101,23],{},". Know the vendor's committed RTO and RPO (read the contract, not the sales deck), what happens when ",[21,104,105],{},"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.",[27,108,110],{"id":109},"the-manual-fallback","The manual fallback",[14,112,113,114,118,119,122],{},"This is the uncomfortable part of the plan, and the part that earns its place. When the ",[38,115,117],{"href":116},"\u002Fblog\u002Fstraight-through-processing-in-treasury","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 ",[21,120,121],{},"critical few",".",[14,124,125],{},"A real fallback answers three questions before the crisis, not during it:",[51,127,128,138,144],{},[54,129,130,133,134,137],{},[17,131,132],{},"Which actions genuinely can't wait?"," Payroll, a debt repayment falling due, a margin call. Draw the line deliberately; most of what treasury does ",[21,135,136],{},"can"," wait a day.",[54,139,140,143],{},[17,141,142],{},"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.",[54,145,146,149,150,154],{},[17,147,148],{},"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 ",[38,151,153],{"href":152},"\u002Fblog\u002Finterface-monitoring-and-reconciliation","monitored workflow"," isn't there to enforce it.",[14,156,157],{},"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.",[27,159,161],{"id":160},"backups-failover-and-the-thing-that-separates-real-plans-from-paper-ones","Backups, failover, and the thing that separates real plans from paper ones",[14,163,164,165,168],{},"The technical building blocks are well understood: regular backups tested for ",[21,166,167],{},"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.",[14,170,171,172,175,176,179],{},"What separates a real plan from a filed one is ",[17,173,174],{},"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 ",[21,177,178],{},"completed",", which is not the same thing. Test the restore and test the fallback, on a realistic scenario, on a schedule.",[27,181,183],{"id":182},"recovering-the-tms-alone-isnt-recovery","Recovering the TMS alone isn't recovery",[14,185,186,187,191],{},"A treasury system that's back up but can't reach the banks still can't pay. Recovery has to include the ",[38,188,190],{"href":189},"\u002Fblog\u002Ftreasury-system-of-record","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.",[27,193,195],{"id":194},"docs-vs-reality","Docs-vs-reality",[14,197,198],{},"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.",[14,200,201],{},"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.",[14,203,204],{},"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.",[206,207],"hr",{},[14,209,210],{},[21,211,212,213,217,218,221,222,225,226,230],{},"Part of the ",[38,214,216],{"href":215},"\u002Ftopics\u002Ftreasury-systems-architecture","Treasury Systems Architecture guide",". See also ",[38,219,220],{"href":116},"straight-through processing"," and ",[38,223,224],{"href":152},"interface monitoring and reconciliation",". The ",[38,227,229],{"href":228},"\u002Fnewsletter","newsletter"," sends one finance-systems pattern every two weeks.",{"title":232,"searchDepth":233,"depth":233,"links":234},"",2,[235,236,237,238,239,240,241],{"id":29,"depth":233,"text":30},{"id":45,"depth":233,"text":46},{"id":81,"depth":233,"text":82},{"id":109,"depth":233,"text":110},{"id":160,"depth":233,"text":161},{"id":182,"depth":233,"text":183},{"id":194,"depth":233,"text":195},"controls","2026-07-24","Keeping treasury running through an outage: how RTO and RPO drive the design, and why the manual fallback is the plan that actually saves the payment.",false,"md",[248,251,254],{"question":249,"answer":250},"What is disaster recovery for a treasury system?","Disaster recovery is the plan and capability to restore the treasury systems and infrastructure after a serious outage — a data-centre failure, a corrupted database, a ransomware event, a failed upgrade. In treasury it's inseparable from business continuity, because the system exists to meet hard, time-bound obligations: payroll, debt repayments, margin calls, settlement. Recovery means being able to make those payments again, not just bringing a server back online.",{"question":252,"answer":253},"What are RTO and RPO?","RTO, the Recovery Time Objective, is how fast you must be back — the maximum tolerable time the treasury system can be down. RPO, the Recovery Point Objective, is how much data you can afford to lose — the maximum gap between your last good backup and the moment of failure. Together they drive the whole design and its cost. Crucially, they should be set by the business obligation the system serves, not by what IT finds convenient to deliver.",{"question":255,"answer":256},"How do you keep paying suppliers if the TMS is down?","Through a manual or degraded fallback: a documented, tested way to release the critical few payments directly through the bank portals, using named authorised people and pre-agreed approval limits, without the treasury system. It won't be pretty or complete — the point is to cover the payments that genuinely cannot wait for recovery. A fallback only works if it's been tested; an untested one usually assumes a token nobody can find or a person who has left.",null,{},true,8.9,"\u002Fblog\u002Fdisaster-recovery-business-continuity-treasury","treasury-systems-architecture","treasury disaster recovery","annual","informational",{"title":5,"description":244},"blog\u002Fdisaster-recovery-business-continuity-treasury",[269,270,242,271,272],"treasury","architecture","business-continuity","disaster-recovery","text","HJq49ZhjfH93tsag3DIDfb1_hsk1kdf8VmYfkupVS8I",[276,280],{"title":277,"path":278,"stem":279,"type":273,"language":257,"draft":245,"children":-1},"Direct vs Indirect Cash Flow Forecasting for Treasury","\u002Fblog\u002Fdirect-vs-indirect-cash-flow-forecasting","blog\u002Fdirect-vs-indirect-cash-flow-forecasting",{"title":281,"path":282,"stem":283,"type":273,"language":257,"draft":245,"children":-1},"EBICS Explained: European Bank Connectivity","\u002Fblog\u002Febics-european-bank-connectivity","blog\u002Febics-european-bank-connectivity",[285,289,293],{"path":286,"title":287,"description":288},"\u002Fblog\u002Fsegregation-of-duties-in-treasury-systems","Segregation of Duties in Treasury Systems","Treasury moves money, so it's a prime fraud target. Segregation of duties means no one person can initiate, approve and release a payment or trade alone.",{"path":290,"title":291,"description":292},"\u002Fblog\u002Fpayment-fraud-prevention-in-treasury","Payment Fraud Prevention and Controls in Treasury","Payment fraud prevention in treasury: the main threats are BEC, invoice redirection, insider diversion and standing-data tampering — and how to stop them.",{"path":294,"title":295,"description":296},"\u002Fblog\u002Faccess-management-and-user-provisioning-treasury","Access Management and User Provisioning in Treasury Systems","A treasury system can move money, so who can do what inside it is a first-order control. Access management is the foundation segregation of duties stands on.",1784914209091]