Operational Resilience for Fintech Software: What FCA, DORA and MAS Expect

TL;DR

If you build or buy software for a regulated financial firm in the UK, the EU or Singapore, "does it work?" is no longer the only question a supervisor cares about. The question is: what happens to your customers when it stops working, and can you prove you planned for that? The UK's operational resilience rules, the EU's Digital Operational Resilience Act (DORA) and the Monetary Authority of Singapore's Technology Risk Management (TRM) Guidelines all push in the same direction. They want mapped dependencies, tested recovery, tight control over third parties, and evidence.

This guide translates those three regimes into engineering decisions: what to design for, what to document, what to put in vendor contracts, and what to ask any software partner before you sign. It is written for founders, CTOs, heads of product and risk leads at payment firms, e-money institutions, lenders and wealth platforms. It is not legal advice. Your compliance team and counsel own the interpretation.

Why three rulebooks keep landing on the same engineering problems

The UK, EU and Singapore each built their own framework, with different legal force, scope and vocabulary. Yet when you read them as an engineer, the overlap is striking. Each one asks, in its own words:

• Do you know which services your customers cannot afford to lose?
• Do you know every system, team and supplier those services depend on?
• Have you tested a bad day, rather than assumed you would cope?
• Do you stay accountable when a supplier fails?

If your platform can answer those four questions with evidence, you are most of the way towards all three regimes. If it cannot, no certificate or policy document will paper over the gap.

A caution before we go on. Each regime has its own scope, definitions and deadlines. Whether a rule applies to your entity, and in what form, is a question for your compliance function. What follows concentrates on the parts that change how software gets designed and run.

The UK: important business services, impact tolerances and mapping

The FCA's operational resilience rules (policy statement PS21/3, in the FCA Handbook at SYSC 15A) apply to a defined list of firms. According to the FCA, that list includes banks, building societies, insurers, certain investment firms and exchanges, and entities authorised or registered under the Payment Services Regulations 2017 and the Electronic Money Regulations 2011, alongside enhanced-scope Senior Managers and Certification Regime firms (FCA, operational resilience insights and observations). Law firm Sidley summarises the in-scope set as including banks, insurers, e-money institutions and payment institutions (Sidley Data Matters, January 2025).

The transition period under the rules ended on 31 March 2025. The FCA states that firms had to be able to "remain within impact tolerance in severe but plausible scenarios for any identified important business services" by then, with plans approved by their board. It also stresses that the requirement "is not a once and done activity". So for a regulated UK firm in November 2026, this is a standing obligation, not a project that finished.

The four concepts that matter to engineers

Important business services. Firms must identify the services that, if disrupted, could cause intolerable harm to clients or threaten market stability, and keep that list under review. For a payments firm that might be sending a payment, onboarding a customer or giving access to funds. The FCA warns against excluding a service because of one factor, such as the assumption that competitors could cover it.

Impact tolerance. This is the maximum tolerable level of disruption for each important business service, usually measured as time plus other metrics where relevant. The FCA is explicit that an impact tolerance is not the same thing as a recovery time objective. Most firms set recovery targets well inside their tolerances. It also encourages firms to complement time-based measures with other metrics.

Mapping. Firms must identify and document the people, processes, technology, facilities and information needed to deliver each important business service, including third-party relationships that could affect their ability to stay within tolerance. Anyone who has tried to draw this on a whiteboard knows how many hidden dependencies surface: a shared identity provider, a single message queue, a vendor's rate limiter, a batch job nobody owns.

Scenario testing. Firms must keep testing plans up to date, using severe but plausible scenarios that vary in nature, severity and duration. The FCA's observation is that testing should move from desk-based judgement towards empirical testing: penetration tests, disaster recovery and failover tests, simulations, and lessons from real incidents.

What the FCA says about suppliers

This is the part software buyers should read twice. The FCA's wording is blunt: if a third-party provider supporting an important business service fails to remain within impact tolerance, "the failure to remain within impact tolerance is your responsibility". It adds that third-party relationships should be actively managed so that you are satisfied with their resilience, and that a third party may run its own resilience testing, provided you are satisfied that its methodology and scenarios are appropriate and sufficient for your needs.

Sidley also points to separate UK proposals on incident and material third-party reporting (the PRA's CP17/24 and the FCA's CP24/28) and notes that the UK has a critical third parties regime under the amended Financial Services and Markets Act 2000. We have not verified the current status of those proposals, so check with your regulator or counsel before relying on them.

The EU: DORA and the contract is now part of the control framework

DORA is Regulation (EU) 2022/2554. It has applied since 17 January 2025 (EIOPA, DORA overview). EIOPA describes it as applying to 20 different types of financial entity and to ICT third-party service providers, with an EU oversight framework for critical ICT third-party providers.

For a software team, the practical shape of DORA is its set of pillars: ICT risk management, reporting of major ICT-related incidents to competent authorities, digital operational resilience testing (basic and advanced), management of ICT third-party risk including key contractual provisions, and information sharing. The detailed technical standards sit in a series of regulatory and implementing technical standards, including those on incident classification and reporting, threat-led penetration testing and the register of information.

The contract requirements are concrete

McCann FitzGerald's summary of Article 30 is a useful checklist for what your software supplier contract now has to contain (McCann FitzGerald, Delving into DORA: ICT contractual arrangements). All contracts for ICT services must address minimum elements, and DORA adds further elements where the service supports a critical or important function. The minimum list includes:

• a clear and complete description of the ICT service;
• the locations from which the service is provided and where data is processed;
• provisions on protection of data, including personal data;
• access, return and recovery of data on insolvency or discontinuation of the provider's business;
• co-operation with the financial entity's competent and resolution authorities;
• termination rights and minimum notice periods;
• service levels;
• incident support, at no additional cost or at a cost fixed in advance;
• conditions for the provider's participation in the entity's security awareness and resilience training.

Firms also have to maintain a register of information on all contractual arrangements for ICT services from third-party providers, and may have to make it available to their competent authority. The European supervisory authorities published final templates for the register in January 2024.

Notice what that list does to an ordinary software engagement. "Where will the data be processed?" becomes a contractual statement. "What happens if you disappear?" becomes a data-return and recovery clause. "Who helps us at 2 a.m. on a Sunday?" becomes incident support with a known cost. These are good questions to be asking in any project, regulated or not.

Singapore: MAS TRM Guidelines

The MAS Technology Risk Management Guidelines were updated on 18 January 2021 and, according to Linklaters, apply broadly to all financial institutions regulated by MAS (Linklaters, MAS issues updated Technology Risk Management Guidelines). Bird & Bird says they are to be "observed and followed" by regulated institutions (Bird & Bird, revised TRM Guidelines). Check the MAS site itself for the current text and its legal status for your licence type, because we have relied here on law-firm summaries.

Points from those summaries that matter to anyone building software:

• Third parties. The guidelines extend to third-party services that may not count as outsourcing under MAS's separate outsourcing guidelines. Institutions should assess technology risk exposure before contracting, expect high standards of care from providers on confidentiality, integrity and system resilience, and make sure use of a third party does not weaken controls.
• Secure development. Bird & Bird describes best practice for developing software with a focus on security and reliability, with comprehensive testing and vetting of third-party components, especially where customer data is transferred.
• Cyber exercises. Institutions should stress test their cyber defences regularly, through exercises such as social engineering, table-top and cyber range scenarios, and take part in cyber threat information-sharing arrangements.
• Accountability. A Chief Information Officer and a Chief Information Security Officer, or equivalents, should be appointed and accountable for technology and cyber risk.

Side by side: what each regime asks of your platform

This table is a map of themes, not a compliance matrix. Confirm timelines, thresholds and obligations that apply to your entity with your regulator or counsel. In particular, we have not set out incident reporting deadlines, because the sources we reviewed for this article do not state them.

Turning the regimes into design decisions

Compliance teams talk in services and tolerances. Engineers talk in services, queues and databases. The work is connecting the two.

1. Start with a service map, not an architecture diagram

For each customer-facing service that matters, such as "pay a beneficiary" or "see my balance", list every component it touches: front end, API gateway, identity, ledger, payment rails, fraud checks, notifications, data stores, cloud regions and the people who run them. Then mark which are yours and which belong to suppliers. That one diagram answers the FCA's mapping expectation and feeds the DORA register and MAS vendor reviews.

Keep it in version control next to the code. A service map in a slide deck goes stale in a quarter.

2. Decide the tolerance before you decide the architecture

If the business says a payment initiation service can be down for no more than a given time, that number drives your choices: single or multi-region, active-active or warm standby, synchronous or queued processing, how much you can degrade gracefully. Ask for the tolerance up front. Ask what customers see during degraded mode. A read-only balance screen with a clear message is a very different resilience posture from a spinning loader.

3. Design for graceful degradation

Resilience is rarely about preventing every failure. It is about choosing what still works. Patterns that tend to help in regulated financial software include:

• queue-backed payment submission so customers can be told "received" even when a downstream rail is slow;
• idempotent operations so retries after an outage do not duplicate money movements;
• feature flags and kill switches for risky journeys;
• read replicas or cached views so account information survives a write-path incident;
• clear separation between your ledger of record and customer-facing views.

None of these is exotic. They become important when you have to demonstrate the behaviour in a test.

4. Test the bad day, then keep the evidence

Both the FCA and MAS lean towards empirical testing over assumptions. Schedule failover drills, restore-from-backup exercises, dependency-outage simulations and security testing. Record what you ran, what failed, what you fixed and when you retested. Evidence of remediation is often more persuasive than a clean first run.

5. Treat observability as a compliance asset

You cannot report an incident you cannot see, classify an incident you cannot size, or prove recovery time without timestamps. Structured logs, traces, service-level indicators tied to your important services, and an audit trail of administrative actions all earn their keep in regulated settings. They also make your engineers' lives better.

6. Own your exit

DORA's data return and recovery language, and the FCA's insistence that responsibility stays with you, point to the same practical question: could you move? You do not need to be able to migrate overnight, but you should know what data you would need, in what format, and how long a transition would take. Avoid designs where a single supplier holds data you cannot export.

Build, buy or hybrid: the resilience lens

Most fintechs end up with a mix of bought components and custom software. The resilience view adds some sharper questions to the usual cost debate.

Buying a platform gets you speed and a vendor that has probably solved common problems. It also adds a third party whose failure is your responsibility, and whose contract must meet the standards above. Ask how the vendor supports your testing, what its sub-contracting chain looks like and what you get on exit.

Building custom gives you control over architecture, data location and degradation behaviour. It also makes you responsible for running, patching and testing what you built, so budget for operations and not just for delivery.

Hybrid is common: a bought core for commodity capabilities, custom software where your product differs, and an integration layer between them. In that model the integration layer is often where resilience is won or lost, because it is where timeouts, retries and fallbacks live. Our related guide on API-first architecture for fintech startups covers how to structure that layer as you scale beyond an MVP.

Questions to put to any software partner

Whether you are hiring an agency, a consultancy or a product vendor, these questions separate teams who have worked in regulated environments from those who have not:

1. How do you document dependencies for the systems you deliver, and in what format do you hand that over?
2. Where will our data be stored and processed, and can you commit to that in the contract?
3. What does your incident support look like out of hours, and how is it priced?
4. How do you test failover and restore, and will you share the results with us?
5. What third-party libraries and services do you use, and how do you vet them?
6. If we needed to bring the system in-house or move to another supplier, what would you hand over and how quickly?
7. Which of your engineers have worked under FCA, MAS or EU supervision, and on what kind of systems?

A partner who answers these concretely, and does not flinch, is worth more than one with a polished deck.

A short readiness checklist

Use this as a starting conversation with your team rather than a certification:

• [ ] Important services listed, each with a named business owner.
• [ ] A tolerance defined per service, agreed with the business and approved at the right level.
• [ ] Service maps current, version-controlled and covering suppliers.
• [ ] A register of third-party ICT arrangements, with contract terms reviewed against DORA Article 30 where it applies to you.
• [ ] Documented, scheduled testing including failover, restore and security testing, with remediation tracked.
• [ ] Incident detection and classification process tested at least in a table-top exercise.
• [ ] Exit plans for critical suppliers.
• [ ] Board or senior management reporting that uses real test results.

What about PSD3 and the Payment Services Regulation?

If you operate in the EU payments market, you will also be tracking the replacement of PSD2. According to law firm summaries published in March and April 2026, a provisional political agreement on PSD3 and a new directly applicable Payment Services Regulation was announced on 27 November 2025, with formal adoption expected in 2026 and entry into force anticipated in 2027 (DLA Piper; Morrison & Foerster). Those summaries describe requirements such as payee name checks for credit transfers, reimbursement obligations for certain impersonation fraud, adaptive authentication, and more prescriptive expectations for open banking interface performance and availability.

We have not verified the position after April 2026, so check the official texts before planning. The engineering point stands either way: payee verification, fraud controls and API availability all depend on the same resilient, well-instrumented platform that the operational resilience regimes require.

Conclusion

The UK, EU and Singapore have written their expectations in different documents, but the engineering message is consistent: know what matters, know what it depends on, test failure, and stay accountable for your suppliers. Teams that build this discipline into their delivery, rather than bolting it on before an audit, spend less time in remediation and more time shipping product.

Syslabs builds custom software for fintech and other regulated sectors, including reconciliation engines, fraud and risk analytics and lending origination, with delivery for international clients. If you are scoping a platform and want a second opinion on resilience, architecture or vendor boundaries, we are happy to talk it through. Scope and pricing are agreed on a consultation, and the conversation costs nothing.

Book a consultation with Syslabs - the booking page shows times in your own time zone.

References

• European Insurance and Occupational Pensions Authority. Digital Operational Resilience Act (DORA). https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en
• McCann FitzGerald (20 May 2024). Delving into DORA: ICT contractual arrangements. https://www.mccannfitzgerald.com/knowledge/data-privacy-and-cyber-risk/delving-into-dora-ict-contractual-arrangements
• Financial Conduct Authority. Operational resilience: insights and observations for firms. https://www.fca.org.uk/firms/operational-resilience/insights-observations
• Sidley Austin (7 January 2025). UK Operational Resilience Rules: Are You Ready for 31 March 2025? https://datamatters.sidley.com/2025/01/07/uk-operational-resilience-rules-are-you-ready-for-31-march-2025/
• Linklaters (March 2021). Singapore: MAS issues updated Technology Risk Management Guidelines. https://www.linklaters.com/knowledge/publications/alerts-newsletters-and-guides/2021/march/05/singapore---mas-issues-updated-technology-risk-management-guidelines
• Bird & Bird (2021). Revised Technology Risk Management Guidelines. https://twobirds.com/en/insights/2021/singapore/revised-technology-risk-management-guidelines
• DLA Piper (March 2026). PSD3 and PSR. https://www.dlapiper.com/en-sk/insights/publications/2026/03/psd3-and-psr
• Morrison & Foerster (30 April 2026). PSD3 and the Payment Services Regulation: key developments. https://www.mofo.com/resources/insights/260430-psd3-and-the-payment-services-regulation-key-developments