DORA Compliance for Fintech & Neobanks: Digital-First Resilience

Cloud-Native Architecture

• Single cloud dependency: Most fintechs run entirely on one cloud provider (AWS, GCP, or Azure). This is a concentration risk under DORA Article 29.
• Serverless and managed services: Lambda, Cloud Run, managed databases — you don't control the underlying infrastructure. How do you demonstrate resilience of services you don't manage?
• Multi-region strategy: DORA requires resilience testing and BCP. Fintechs need to demonstrate they can survive a regional cloud outage.
• Shared responsibility: Cloud shared responsibility model meets DORA — you must clearly document which resilience obligations are yours vs your cloud provider's.

API-Dependent Ecosystems

• Banking-as-a-service: Fintechs relying on BaaS providers (Solaris, Railsbank, Swan) for core banking — the BaaS provider's DORA compliance directly affects you
• Payment processors: Stripe, Adyen, Mollie — critical third parties that must be in your DORA register
• Identity verification: Onfido, Jumio, Sumsub — KYC providers are ICT third-party service providers under DORA
• Open Banking APIs: PSD2 APIs from banks — what happens when a bank's API goes down? Fallback strategy required.

DORA includes a proportionality principle — requirements scale with size, complexity, and risk profile:

• Microenterprises (<10 employees, <€2M turnover): Simplified ICT risk management framework. No mandatory TLPT (threat-led penetration testing).
• Small fintechs (10-250 employees): Full DORA requirements but proportionate implementation. Board can delegate ICT risk management to senior management.
• Key principle: Proportionality doesn't mean exemption. Even small fintechs must have incident reporting, third-party registers, and basic resilience testing.

1. Third-party register: Map all ICT dependencies — cloud, BaaS, payments, KYC, monitoring. Classify criticality.
2. Incident response: Define incident classification, reporting chain (NCA within 4 hours for major incidents), and communication plan.
3. Cloud resilience: Document multi-region/multi-AZ strategy. Test cloud failover scenarios.
4. Exit strategy: For each critical third party — can you switch providers? What's the timeline? What data needs to be migrated?
5. Board awareness: Ensure management body understands ICT risk. Regular reporting on incidents, testing results, and third-party risk.