I have seen plenty of systems that were technically up and operationally not ready.
That sounds contradictory until you have sat inside a live financial operation. The platform responds. The login page loads. The trading server is reachable. The database is accepting connections. The dashboard is green. But support cannot explain a client issue, reconciliation is behind, a third-party file is missing, the incident owner is unclear, and nobody is confident about the next safe action.
That is not readiness. It is partial availability.
Availability asks whether a component responds. Operational readiness asks whether the important business service can still be delivered safely. Operational resilience is the wider discipline of preparing for severe but plausible disruption. They overlap, but they are not interchangeable, and this article is not a compliance test.
Uptime matters, obviously. A financial platform that cannot be reached has a direct problem. But uptime is only one layer of operational readiness. The more useful question is whether the business can continue the important service, understand the dependencies, recover from disruption, communicate clearly, and leave evidence of what happened.
The operational problem
Technology teams often measure what is easiest to measure first.
CPU, memory, disk, network, API latency, error rates, queue depth, and service status are all important. They are also incomplete. They tell you something about the platform. They do not always tell you whether the business can operate.
In financial services, the operating surface is wider than the application. It includes people, permissions, third parties, support, reporting, reconciliation, communication, change control, and regulatory obligations. A platform can be online while one of those layers is failing quietly.
The FCA's current outsourcing and operational resilience material asks firms to understand the people, processes, technology, facilities, information, and third-party dependencies needed to deliver important business services. For firms and financial market infrastructures within the Bank of England or PRA's remit, the Bank's framework similarly centres on important business services, impact tolerances, mapping, scenario testing, and recovery. The exact regulatory scope differs by firm, but the operating lesson travels well: start with the service and trace what it depends on.
That is a better frame than uptime alone.
What usually goes wrong
The usual failure is that readiness is assumed from infrastructure health.
A deployment completes, but support has not seen the new failure modes. A provider integration is live, but escalation contacts are out of date. A report runs, but nobody has checked whether the downstream team can use it. A backup exists, but the restore path has not been rehearsed. A dashboard shows green, but the alert that matters is buried under noise. A client-impacting issue is technically small, but nobody knows whether it crosses an incident threshold.
These are not exotic problems. They are normal gaps between technical delivery and operational ownership.
The symptoms look technical, but the causes are usually upstream.
A readiness model that is more useful than uptime
1. Define the service, not just the system
Readiness starts by naming the service the business is trying to protect.
For a brokerage, that might be client login, pricing, order execution, deposits and withdrawals, client reporting, liquidity routing, or support handling. For an investment platform, it might be onboarding, valuation, subscription processing, reporting, or adviser support.
The service definition matters because a server can be up while the service is impaired. If clients can log in but cannot place valid orders, the platform is not operationally ready for trading. If reports generate but cannot be reconciled, the reporting service is not healthy enough.
2. Map the dependencies
Every important service has dependencies.
Those dependencies include software, infrastructure, data, people, permissions, third parties, scheduled jobs, credentials, procedures, and business decisions. A readiness review should map enough of those dependencies to answer a practical question: what would stop this service from being delivered, and how would we know?
This is where third-party dependencies deserve attention. A liquidity provider, hosting provider, payment provider, CRM, reporting vendor, or market data service may sit outside the firm, but the client impact still lands inside the business. Outsourcing the component does not remove the firm's responsibility for understanding the dependency and managing its effect on the service.
3. Test the operating path
Operational readiness needs rehearsal.
That does not mean every scenario has to become a full disaster-recovery exercise. It does mean the team should test common and plausible paths: provider unavailable, report late, deployment rollback, bridge degraded, data import failed, support spike, lost access, or key person unavailable.
The useful test is not "can the engineer fix it?" It is "can the business detect it, decide what it means, take the next safe action, and record the outcome?"
4. Separate detection from decision
Monitoring should detect. Operating ownership should decide.
A good alert tells the right person that something specific has changed. It does not always decide the business response. In financial operations, that distinction matters because some actions affect clients, money, trading, reporting, or regulatory communication.
The readiness question is whether the decision boundary is clear. Who can restart a process? Who can pause a route? Who can approve a reconciliation correction? Who decides whether clients need communication? Who decides whether an incident is material enough to report?
The FCA's material on operational incident reporting is a useful public reference point here. It discusses material disruption to financial services, customer impact, unauthorised access, significant data loss, and unavailability or loss of control of IT systems. Even where a day-to-day event is not reportable, the discipline of thinking in terms of service impact is valuable.
The current reporting process remains in place until 18 March 2027, when the FCA's standardised incident-reporting rules take effect. Firms within scope have a concrete reason to improve their evidence, ownership, and decision thresholds now rather than waiting for a reporting deadline.
5. Keep evidence close to the action
A ready operation does not rely on people remembering where the evidence lives.
If an issue affects trading, the team should be able to find order IDs, execution evidence, provider responses, timestamps, account state, and recent changes. If an issue affects reporting, the team should be able to see source files, run history, reconciliation state, and downstream consumers. If an issue affects onboarding, the team should be able to see status, missing information, permissions, and ownership.
Evidence turns a stressful conversation into an operating loop.
6. Review the gap after every pressure event
Readiness improves when the business reviews what the pressure event revealed.
Which alert mattered? Which alert was noise? Which dependency surprised people? Which action took too long? Which decision was unclear? Which manual workaround should become a controlled workflow? Which support questions could have been answered by better public or internal content?
This is the practical value of post-incident review even when the event was not dramatic. Small pressure events show the next readiness gap.
The minimum useful readiness pack
A readiness review does not need to become a huge document. For each important service, the minimum useful pack is usually small:
- A plain-language service definition and the clients or business functions affected if it degrades.
- A named owner, deputies, and the decisions each role is authorised to make.
- The critical technology, data, people, permissions, scheduled jobs, and third parties the service depends on.
- The applicable impact tolerance and practical degradation thresholds, including who decides when they have been crossed.
- The monitoring evidence, alert route, recovery steps, rollback or manual workaround, and communication path.
- The date and result of the last scenario test, plus any open remedial actions and owners.
That pack should stay close to the operation and change when the service changes. A dependency map that was correct before a provider migration, permissions redesign, or reporting change is historical evidence, not a current readiness assessment.
What good looks like
An operationally ready platform has more than uptime.
It has named services. It has mapped dependencies. It has monitoring tied to client and business impact. It has owners. It has tested recovery paths. It has a way to separate normal noise from material disruption. It keeps evidence close to the action. It leaves enough record that the next person can understand what happened.
That is the same distinction I wrote about in financial operations need operating loops, not more dashboards. A dashboard may show that the system is alive. An operating loop helps the business decide what to do.
It also connects to what actually breaks first when a brokerage gets busy, because the first failures under pressure are often coordination failures that happen through technical systems.
Uptime is necessary. It is not sufficient.
The stronger question for a financial platform is: can the business operate the service, under pressure, with evidence, ownership, recovery, and judgement?
If the answer is no, the platform may be available, but it is not ready.
This article is operational commentary only. It is not investment advice, regulatory advice, or a recommendation about any specific financial service or technology provider.
