Your Fintech’s Cloud Provider Goes Down. What Happens Next?

Your balance can look perfectly normal while the service behind it is unavailable. The app opens, a spinner appears, and the transfer that usually takes seconds never gets beyond “processing”. A cloud outage is one possible explanation. It is not proof that money has disappeared, that a bank has failed, or that a payment has definitely been sent. Those are different questions, and treating them as one makes an already stressful situation harder to understand.

For covered European financial firms, operational resilience is now a regulatory responsibility rather than just a reassuring line on a product page. The Digital Operational Resilience Act, Regulation (EU) 2022/2554, known as DORA, applies from 17 January 2025. That is its application date, not its entry-into-force date. It is an enacted EU regulation, not a proposal waiting for national adoption. Its purpose is to improve how covered financial entities manage technology risks, including dependencies on outside suppliers.

The app is only the front door

Imagine a hypothetical payment firm that runs customer authentication, transaction records and support tooling through several technology suppliers. One supplier becomes unavailable. The firm may still have money securely held and accurate records, while customers cannot authenticate or submit instructions. Alternatively, authentication might work while the transfer service is interrupted. The visible symptom does not identify the broken dependency.

This is OLECH analysis of an operational scenario, not a report of an outage at a named business. The distinction matters because a phone screen reveals very little about settlement. A failed request, a queued request and a completed payment whose confirmation is delayed can look surprisingly similar. Sending the same instruction repeatedly can complicate reconciliation if some requests eventually succeed. Reliable incident communication needs to distinguish what the firm knows from what it is still investigating.

DORA addresses that wider system. Its requirements cover ICT risk management, incident handling and reporting, resilience testing and ICT third-party risk. The EBA's DORA rulebook overview describes the framework across those areas. The underlying question is not simply whether a firm bought cloud capacity. It is whether the firm understands the operational consequences of losing it.

Outsourcing does not outsource responsibility

DORA applies to specified categories of financial entities, with scope provisions and exemptions in the regulation. “Fintech” is a commercial description, not a legal category that automatically settles coverage. Before applying the rule to a particular app, identify the regulated entity providing the service and its status. A software company selling tools to banks is not necessarily subject to the same duties as the bank using those tools.

For covered entities, using an outside supplier does not erase the firm's responsibilities. The EBA material on contractual policies for ICT services supporting critical or important functions explains that firms must remain in control of operational risks, information security and business continuity throughout the contract lifecycle. A supplier contract therefore belongs in the resilience plan, not outside it.

The consumer-facing implication is limited but important. “Our cloud provider is down” can be a factual explanation of a dependency failure; it is not a complete account of the firm's response. Customers still need to know which services are affected, whether instructions can be relied on, and where updates will appear. The regulation does not promise that every customer receives an instant technical diagnosis or automatic compensation for every interruption.

Recovery is a process, not a button

DORA's risk-management provisions address protection, detection, response and recovery. Continuity and recovery arrangements should reflect the actual systems and dependencies used. That does not make moving to another cloud a simple emergency switch. Data consistency, access controls, software configuration and supplier connections can all affect whether a restored service works safely.

Consider a second hypothetical example: the app can be restarted elsewhere, but its transaction history is not yet synchronised. Restoring the interface before checking the records could create a different problem from the original outage. A recovery plan needs to establish which records are authoritative, which instructions remain pending and how duplicate or incomplete operations will be handled. This is an operational explanation, not a claim that DORA prescribes one universal recovery sequence.

Testing is valuable precisely because a plan on paper can conceal these problems. DORA sets testing requirements, with additional arrangements for specified entities. That does not mean every small firm must perform the same exercise or that every test proves all future failures are covered. Scope, proportionality and the applicable requirements matter. Resilience is evidence of preparation, not a guarantee against every possible incident.

Not every incident is a major incident

The regulation distinguishes ICT-related incidents and the classification of major incidents. Reporting consequences depend on the applicable criteria and the facts. A customer who cannot log in for a few minutes cannot determine the regulatory classification from that observation alone. Duration, service impact and other relevant factors need assessment by the entity.

Equally, a firm should not describe an unverified supplier problem as harmless merely because the interface remains online. Some incidents involve records, confidentiality or integrity rather than a completely blank screen. DORA's framework is broader than availability. That is why the response may involve investigation and controls as well as restoring service.

For readers, the useful distinction is between the firm's public status message and its regulatory obligations. A short message may not contain every incident-reporting detail. Its incompleteness does not prove the firm is breaching DORA, but vague reassurance is not evidence that customers' specific instructions have settled either. The right factual question is what is known about the affected service and the particular transaction.

“Critical cloud provider” has a formal meaning

DORA also establishes oversight for ICT third-party providers formally designated critical under its framework. That is not a label automatically attached to every cloud supplier. Nor does one supplier's designation transfer all of a financial entity's obligations to the supplier. Entity-level responsibilities, contractual commitments and the oversight framework are related but separate layers.

The EBA's description of DORA oversight includes information requests, inspections and recommendations within the framework. This changes the regulatory treatment of specified dependencies; it does not certify that a designated provider can never fail. Concentration risk remains a practical issue when many financial firms depend on similar services. Diversity of brand names on customers' phones may hide shared infrastructure underneath.

What the customer actually needs next

A useful outage update should make the operational position intelligible: which functions are affected, whether existing instructions are pending, whether an alternative channel is available, and when another update is expected. Those are editorial criteria for evaluating communication, not a promise that every outage triggers identical legal rights. Keep transaction references and follow the provider's documented support process rather than relying on screenshots from unrelated users.

The wider story is that modern finance depends on services customers do not choose directly. DORA recognises those dependencies and requires covered firms to manage them. It cannot eliminate every interruption. Its more realistic test is whether the firm can explain the failure, protect reliable records, recover critical operations and learn from what happened. The cloud may belong to somebody else; the financial service's responsibility to prepare does not simply vanish with it.

Sources - DORA: Regulation (EU) 2022/2554, official text - EBA interactive DORA rulebook - EBA contractual policy for critical or important ICT functions - EBA application update, 11 February 2025