DevOps for Banking — secure multi-cloud platforms

What regulates the infrastructure

What actually goes wrong here

• Overnight batch overrun in the core banking system. Interest accrual, transaction posting, standing orders and statement generation run inside a fixed window; if the batch does not complete, the next business day opens with wrong balances and unexecuted instructions, and the error compounds into subsequent cycles rather than clearing itself.
• Missed settlement cut-offs. Large-value payment systems close at a fixed time; a payment that misses the window does not simply arrive late — it leaves an unsettled position overnight, creating liquidity and counterparty exposure and, at scale, a reportable incident.
• The vanishing maintenance window. Continuous instant-payment obligations mean the weekend change window that core banking upgrades were built around no longer exists in the euro area, so changes to shared components must be made live against a service that is contractually obliged to answer in ten seconds.
• Third-party and sector concentration. Many institutions depend on the same core banking vendor, card processor or cloud region, so one supplier failure becomes a simultaneous multi-bank event that no single bank's recovery plan can absorb — the specific risk DORA's critical ICT third-party provider oversight was created to address.
• Card switch and ATM network outages. Because these are the most publicly visible part of a bank, an interruption produces immediate reputational and, in cash-reliant markets, social consequences well out of proportion to the transaction volume affected.
• Risk-data aggregation failures at reporting deadlines. Prudential returns require assembling consistent data across legacy systems on a hard submission date; a broken feed is not a delayed report but a supervisory breach, and the reconciliation work has no slack in the calendar.
• Breach of the SWIFT secure zone boundary. Attacks on the payment-messaging path target the back-office systems feeding it rather than SWIFT itself, which is why the framework's controls concentrate on isolating and monitoring those flows.

How demand behaves

Largely calendar-driven and predictable. Retail volumes concentrate on salary payment dates, month-end and the days before public holidays; wholesale payment traffic bunches ahead of the daily RTGS cut-off each afternoon; prudential and financial reporting workloads spike at month, quarter and year end. Instant payment obligations have flattened the historical overnight trough, because the rails must run continuously even when branch and corporate activity is at zero.

Data you will be holding

Account balances, transaction histories, payment message content and AML/KYC identity records. Banking secrecy statutes in many jurisdictions restrict disclosure and cross-border transfer independently of data protection law, so a lawful GDPR-style transfer can still be a secrecy breach. AML rules generally require records be retained for years after the customer relationship ends, which puts retention obligations in direct tension with erasure rights and constrains how backups and archives can be designed.

Architecture this pushes you toward

A vendor or mainframe core with a batch cycle, fronted by channel and API layers that must stay answerable while the core is closed for cut-over. SWIFT connectivity sits in an isolated secure zone with separately administered credentials and controlled data flows from the back office. Regulatory expectations push toward documented and tested exit plans for each ICT provider, warm secondary sites, and the ability to evidence recovery to a supervisor — the burden is proving resilience, not only having it.

Availability expectation

Retail channels and payment rails are typically targeted at 99.9% or better, and euro-area instant payment obligations make continuous operation a legal requirement rather than an SLA. Supervisors increasingly express the expectation as an impact tolerance — the maximum tolerable disruption to a named critical operation — rather than as an availability percentage, so the operative number differs per operation and per institution.