Sector Analysis · Financial Services & Insurance
A payment API written this year calls a core system written in 1987. Neither team can see the other’s telemetry. That seam is where your most expensive incidents live — and where your regulator’s deadline starts running.
Operational resilience stopped being an engineering preference the moment supervisors started naming it. The Federal Reserve, OCC and FFIEC treat it as a safety-and-soundness matter. The EU’s DORA attaches explicit reporting timelines to major incidents. For any institution with European exposure, an outage is now an event with a clock on it.
US financial services turns over roughly $4.5 trillion a year across banking, insurance, asset management and payments. JPMorgan alone spends around $17 billion annually on technology. The problem is not investment. It is that the investment has produced two estates that do not share a language.
The characteristic banking incident starts as a customer-facing API latency regression and ends, three hours later, in a core system nobody on the call has credentials for.
Modern services are instrumented with OpenTelemetry, traced end to end, and owned by teams who practise SRE. Core deposit, card authorization and settlement systems are instrumented with whatever the platform provides, observed through different tooling, and owned by teams with a different operational culture and an older change calendar.
A trace that starts in the modern estate simply stops at the boundary. What happens beyond it is inferred from timing, which is another way of saying guessed.
You cannot correlate across a seam you cannot see across. Most banking incidents are not hard because the fault is subtle — they are hard because half the evidence is in a system the responder cannot query.
Batch makes it worse. Mortgage servicing, settlement and regulatory reporting run long-lived jobs with hard deadlines. A process that fails at 02:00 and is noticed at 07:00 has already missed its window, and most observability is built for request-response rather than for a job that should have finished and did not.
| Surface | How it presents |
|---|---|
| Reporting deadlines | DORA and equivalent regimes require a defensible timeline within a fixed window. Reconstructing one from chat logs is a week of senior time you do not have. |
| Payment rails | Authorization and settlement downtime is directly revenue-linked and among the highest per-minute costs in any sector. |
| Peak concentration | Payday, month-end and benefit disbursement create sharp peaks where a capacity event and a reliability event look identical in early telemetry and demand opposite responses. |
| Acquisition seams | Merged estates rarely converge on one observability convention. The boundary becomes a jurisdictional argument during every incident. |
| Missed batch windows | A failed overnight job is discovered after the window closed, at which point the remediation is manual and the deadline is already gone. |
Two pressures arrive together. Attack volume is up — synthetic identity, automated application fraud, and social engineering at a quality and scale that was not economic three years ago. And model-driven decisioning is moving into credit, fraud and AML paths, which means more automated decisions to explain.
For resilience specifically, the exposure is explainability. When an automated system acts on production during an incident, “the model decided” is not an account a supervisor accepts. The decision must be reconstructable with the evidence available at the time — and most implementations discard the probes once a conclusion is reached, keeping the summary and losing the reasoning.
Managed instances provisioned per region, with dedicated tenancy where a shared database is not acceptable. For digital channels, customer-facing APIs, data platforms and the modern half of the estate generally, this is the fast path — and the one that gets a correlated problem feed running while the core-side conversation is still in progress.
For core banking, card and settlement estates, the platform deploys self-hosted inside your own boundary. Customization here is usually three things: SLO definitions that map to contractual and regulatory commitments rather than internal targets; per-entity and per-jurisdiction tenancy so each supervised entity is measured against its own obligations; and postmortem output shaped to your regulatory reporting template so the incident record is the filing input rather than a source for it.
| Engagement | What it produces |
|---|---|
| Seam Assessment 3–4 weeks |
Where traces terminate at the modern-to-core boundary, what it costs you per incident, and the minimum instrumentation that restores continuity without a core change programme. |
| Regulatory Evidence Readiness 3 weeks |
Measured against the deadlines that actually apply to you: how long it currently takes to produce a defensible timeline, and what would have to change to produce it as a by-product. |
| Batch Observability 4–6 weeks |
Throughput SLOs across settlement, servicing and reporting jobs so a missed window is an alert rather than a morning discovery. |
| Guarded Rollout 10–14 weeks |
Self-hosted deployment across a bounded domain, per-entity SLOs, guardrails mapped to your risk framework, and evidence retention configured to your examination cycle. |
Large banks already invest heavily in resilience and have sophisticated incident practice. The marginal value here is not basic monitoring, and anyone pitching it as such has not looked at your estate.
The defensible claims are narrower: correlation across seams you currently cannot cross, per-entity granularity that aggregate reporting hides, and evidence generated rather than reconstructed. If your traces already span core and your postmortems already write themselves, spend the money elsewhere.
Five hours. A common gap between an overnight batch failure and its discovery — by which point the settlement or reporting window has closed and the remediation is manual.
No latency threshold detects a job that never started. Only a throughput floor does, and almost nobody sets one.
Pick your three most critical overnight jobs. Ask: if this did not run tonight, how would we find out, and when?
If the answer is “someone notices in the morning,” you have a throughput SLO to write — and it is the cheapest reliability improvement available to you this quarter.