Article map
A payment process is resilient only if the organisation can continue its critical obligations when ordinary systems, people, premises, channels or banks are unavailable. Having a backup file or a second bank is not enough if the alternate route lacks funding, authorised users, current beneficiary data or an approval method that can be used under disruption.
Continuity design must also resist the temptation to abandon controls in an emergency. Fraud risk often increases when teams are under pressure, normal communication is unavailable and senior management demands immediate action. The contingency process should therefore be simpler than the primary process, but no less clear about authority and evidence.
This article explains how a TMS operating model can identify critical payments, map dependencies, prepare alternate routes and support controlled recovery after cyber, technology, bank or staffing disruption.
1. Define critical payment services and tolerances
Continuity planning should begin with the obligations whose non-payment would cause unacceptable harm. Materiality is not solely monetary; a small regulatory, payroll or utility payment may be operationally critical.
The operating boundary should define:
- payroll, tax, debt service, margin, regulatory and essential supplier populations
- maximum tolerable delay and latest safe decision time
- minimum data, approvals and banking capability needed for each service
- entities, currencies, accounts and geographies in scope
- conditions for activating partial, alternate or manual processing
The result should be a service map, not a generic statement that “payments are critical.” Different services have different recovery time and data requirements.
2. Map end-to-end dependencies and single points of failure
The payment chain depends on source obligations, master data, user identity, approval, TMS processing, communication, bank access, account funding and downstream reconciliation. A continuity plan that tests only one system may miss the actual constraint.
The governed data record should capture:
- ERP or payroll source and approved payment data
- beneficiary, bank-account and signing master data
- identity provider, authentication token and approval device
- TMS, file generation, API, SWIFT, SFTP or bank portal
- bank account, liquidity source, cut-off and reconciliation feed
Dependencies should include people and external providers. An alternate bank route is unusable if only one absent employee understands it or if the account has no current mandate.
3. Prepare controlled alternate operating routes
Alternate routes should be preconfigured, documented and tested. They may include a secondary bank, alternate channel, emergency portal, pre-approved manual template or controlled payment service provider, depending on the organisation’s risk and geography.
The end-to-end workflow should make visible:
- approved contingency accounts with available or transferable funding
- current user entitlements and out-of-band authentication
- minimal payment template with verified beneficiary source
- emergency approval matrix and transaction limits
- verified bank contacts, file specifications and cut-off instructions
The alternate route should not be used routinely merely because it is convenient. Restricted activation reduces exposure and preserves readiness.
4. Control activation, execution and return to normal
A continuity event needs formal activation and a clear boundary. Without it, users may process the same obligation through both primary and alternate routes or continue emergency practices after the underlying problem is resolved.
The control architecture should address:
- incident declaration, scope and authorised continuity leader
- freeze or reconciliation of the primary queue before alternate release
- duplicate detection across channels and banks
- heightened approval, limits and post-release monitoring
- controlled deactivation, backlog reconciliation and sign-off
Every contingency payment should carry an incident reference so that treasury can identify, reconcile and review the complete population later.
5. Use the TMS to preserve a minimum operating picture
Where the TMS remains available, it can coordinate critical-payment inventory, funding and evidence even if a bank channel or source system fails. Where the TMS is unavailable, a protected export or recovery environment should provide the minimum verified data needed.
The TMS configuration should support:
- critical obligation register with due date and service tolerance
- last known approved beneficiary and source references
- account balances, available facilities and transfer options
- contingency workflow, user roster and bank contacts
- recovery reconciliation of all primary, alternate and manual events
Continuity data must be protected, current and recoverable. An old offline spreadsheet with stale bank details can introduce more risk than the outage itself.
6. Measure resilience through achievable outcomes
A successful test is not one where participants complete a scripted checklist. It should demonstrate that critical payments can be prepared, approved, funded, transmitted, confirmed and reconciled within tolerance under realistic constraints.
Management reporting should measure:
- critical services with tested alternate route and current evidence
- recovery time achieved versus maximum tolerable delay
- payment volume and value executable through contingency capacity
- test exceptions involving access, data, funding, cut-off and bank response
- time to reconcile backlog and retire emergency controls
Management should see which services lack a viable route and the time required to close those gaps.
7. Exercise compound scenarios and maintain readiness
Real incidents combine failures. A cyber event may remove email and identity services while a public holiday limits bank support. Exercises should therefore include unavailable staff, stale data, compromised channels and partial bank service.
The implementation plan should sequence:
- tabletop tests for decision rights and communication
- technical tests of alternate files, APIs, portals and credentials
- live low-value tests where policy and bank permit
- supplier, payroll, tax and debt-service scenario rehearsals
- post-test remediation with owners, deadlines and retest
Readiness decays as users, banks, accounts and formats change. Continuity should be part of change management, not an annual exercise detached from production reality.
Management questions before approval
Before management approves treasury payment continuity, the discussion should test the boundary described by define critical payment services and tolerances, the reliability of ERP or payroll source and approved payment data, and whether incident declaration, scope and authorised continuity leader remains effective when an exception occurs. It should also ask how critical services with tested alternate route and current evidence will reveal whether the decision delivered its intended treasury result.
- Are critical payment services and tolerances defined?
- Are dependencies mapped beyond the TMS itself?
- Does each critical service have a funded alternate route?
- Are contingency users and bank mandates current?
- Can payment data be recovered from a protected source?
- Is emergency approval clear and independently authenticated?
The TMS record should connect those answers to prepare controlled alternate operating routes and to the action 'tabletop tests for decision rights and communication'. Where judgement changes the normal route for treasury payment continuity, the evidence, approver, effective date and next review should remain visible beside critical obligation register with due date and service tolerance.
Evidence a controlled TMS should retain
The operating record for treasury payment continuity should show how ERP or payroll source and approved payment data became an approved action under control activation, execution and return to normal. It should retain source identity, calculation or transformation, workflow status, exception treatment and approval, together with the downstream result represented by critical obligation register with due date and service tolerance.
- incident declaration, scope and authorised continuity leader
- freeze or reconciliation of the primary queue before alternate release
- duplicate detection across channels and banks
- critical obligation register with due date and service tolerance
- last known approved beneficiary and source references
- account balances, available facilities and transfer options
Version history for ERP or payroll source and approved payment data should preserve the information used when the decision was taken, even if later correction changes the current view. Comparing that history with critical services with tested alternate route and current evidence and the practical outcome in 'a ransomware event on payroll day' allows management to evaluate process discipline and decision quality without hindsight rewriting.
Practical illustration: a ransomware event on payroll day
A ransomware incident makes the ERP, corporate email and primary identity service unavailable on the morning of payroll release. The bank channel remains available, but treasury cannot rely on the newly generated file or ordinary electronic approvals.
The continuity plan provides a protected prior-day payroll extract, an independently verified delta file, named emergency approvers using out-of-band authentication and a preconfigured secondary transmission workstation. Treasury funds the account from an unaffected entity, releases the payment within the defined tolerance and records the incident reference in every instruction.
When systems recover, the TMS reconciles the contingency batch to payroll obligations and the bank statement before the primary queue is reopened. The plan succeeds because data, funding, authority and reconciliation were prepared together—not because a spare laptop existed.
Implementation checklist
A treasury team preparing to operationalise this topic should be able to answer yes to the following questions:
- Are critical payment services and tolerances defined?
- Are dependencies mapped beyond the TMS itself?
- Does each critical service have a funded alternate route?
- Are contingency users and bank mandates current?
- Can payment data be recovered from a protected source?
- Is emergency approval clear and independently authenticated?
- Can duplicates be prevented across routes?
- Are contingency payments identifiable for reconciliation?
- Is return to normal formally controlled?
- Have compound disruption scenarios been exercised?
Common design failures
Payment continuity plans are often technically focused but operationally incomplete.
- assuming a second bank is usable without funding or entitlements
- storing emergency instructions only in the unavailable network
- using stale offline beneficiary data
- removing maker-checker control because the payment is urgent
- failing to freeze or reconcile the primary queue before alternate release
- ending the incident when payment is sent rather than when backlog and accounting are reconciled
Resilience is demonstrated by controlled completion of the obligation and restoration of the operating record, not by technology recovery alone.
Closing perspective
Critical payments must remain executable during severe disruption, but emergency processing should not become uncontrolled processing. The continuity design must preserve identity, authority, funding, status and evidence in a simplified form.
A TMS can support that design through critical-service mapping, contingency tasks, protected data, alternate routes and recovery reconciliation. The real test is whether the organisation can pay what matters, on time, and still explain exactly how it did so.
Frequently asked questions
Which payments should be included in a treasury continuity plan?
Include obligations whose delay would cause unacceptable legal, financial, operational or human impact, commonly payroll, tax, debt service, margin, regulatory and essential supplier payments.
Is a second bank account sufficient for payment continuity?
No. The account must have funding, current mandates, authorised users, a working channel, beneficiary data, approvals, cut-off knowledge and a reconciliation process.
How often should payment continuity be tested?
Testing frequency should reflect risk and change, with periodic end-to-end exercises and additional testing after material changes to systems, banks, users, formats or critical services.