We work with UK fintechs at various stages of the regulatory journey. One client is pursuing a UK banking licence and passed a major bank’s due diligence review. Another operates a payment processing platform in Edinburgh handling real-time micropayments during live events. This post distils what we have learned about making cloud infrastructure FCA-ready.
What the FCA actually cares about
The FCA does not prescribe specific technologies. They do not mandate AWS over Azure, Kubernetes over ECS, or any particular architecture. What they care about is whether you can:
- Continue operating when things go wrong (operational resilience)
- Explain and control your reliance on third parties (outsourcing and concentration risk)
- Produce records when asked (data retention and auditability)
- Protect customer data (security and access controls)
- Recover quickly when incidents occur (incident management and disaster recovery)
The relevant regulatory frameworks are:
- PS21/3 - Operational Resilience (in force since March 2022, full compliance required since March 2025)
- SS2/21 - Outsourcing and Third-Party Risk Management
- SYSC 13 - Operational Risk
- FCA Handbook SYSC 3.2 - Systems and Controls
- Senior Managers and Certification Regime (SM&CR) - personal accountability for operational failures
Operational resilience: what it means for infrastructure
Since March 2025, FCA-regulated firms must have identified their “important business services,” set impact tolerances for disruption, and demonstrated they can stay within those tolerances.
For a fintech running on AWS, this translates to concrete architectural requirements:
Defined RTO and RPO for every important service
You need documented, tested recovery targets. Not aspirational ones - tested ones. The FCA expects you to run scenario tests (“what happens if eu-west-2 goes down?”) and prove you can recover within your stated tolerances.
What this means for AWS:
- Multi-AZ deployment at minimum for production workloads
- Documented disaster recovery procedures for every important business service
- Cross-region backups for critical data (even if you run single-region by choice)
- Annual DR testing with evidence - not just “we have a runbook” but “we ran it on this date and recovered in X minutes”
Self-assessment and mapping
You must map which technology components support each important business service. If your payment processing service depends on ECS → ALB → RDS → Redis, that dependency chain needs to be documented. If any component has a single point of failure, you need to acknowledge it and explain your risk acceptance.
What this means for AWS:
- Architecture diagrams that map business services to infrastructure components
- Dependency documentation including AWS service dependencies
- Risk assessment for each AWS service (what happens if S3 is unavailable? What happens if a specific AZ fails?)
Third-party risk: AWS as a material outsourcing arrangement
The FCA treats cloud providers as material outsourcing arrangements. Under SS2/21, you must:
Maintain a register of outsourcing arrangements
AWS is on it. So is any managed service provider (including us, when acting as a CloudOps partner). The register must include:
- What service is outsourced
- Who provides it
- Where data is processed
- What controls exist
- What the exit strategy is
Demonstrate you can exit
The FCA wants to know: if AWS becomes unavailable (sanctions, commercial dispute, service failure), what is your plan? This does not mean you need to be multi-cloud. It means you need a documented, realistic exit strategy - even if it is “we rebuild on Azure within 6 months.”
For most fintechs, the pragmatic answer is:
- Infrastructure defined in Terraform (cloud-agnostic in principle)
- Data exportable in standard formats
- No proprietary AWS lock-in on core business logic (avoid building critical paths on Step Functions or proprietary ML services)
- Documented exit plan with time and cost estimates
Monitor concentration risk
If your entire platform runs in a single AWS region and you also use AWS for backups, logging, and DNS - you have concentration risk. The FCA does not say you cannot do this, but they want you to acknowledge it and explain your mitigations.
Common mitigations:
- Cross-region backups (production in eu-west-2, backups replicated to eu-west-1)
- External DNS failover (Route 53 plus a secondary provider)
- Monitoring that does not depend on the monitored platform (external uptime checks)
Data retention: 5-7 years is the floor
FCA-regulated firms must retain records for a minimum of 5 years (MiFID firms: 7 years). For a cloud-native platform processing transactions, this means:
What you must retain
- All transaction records
- Client communications
- Order records and execution data
- Complaints and dispute records
- Compliance monitoring records
- System access logs (who did what, when)
How to implement on AWS
The naïve approach is “keep everything in RDS forever.” This is expensive and operationally fragile. A better architecture:
- Hot data (0-12 months): RDS/Aurora for active queries
- Warm data (1-3 years): Archived to S3 Standard-IA, queryable via Athena if needed
- Cold data (3-7 years): S3 Glacier Deep Archive with lifecycle policies
- Immutability: S3 Object Lock in compliance mode - data cannot be deleted, even by administrators, until the retention period expires
- CloudTrail: All API activity logged to an immutable S3 bucket with 7-year retention. This provides the “who accessed what” audit trail regulators request.
For our fintech client pursuing a UK banking licence, we implemented exactly this pattern - 7-year retention with S3 Object Lock, cross-region replication, and automated lifecycle transitions. The cost of long-term storage on Glacier Deep Archive is negligible compared to the regulatory risk of not having it.
Security: what the FCA expects beyond Cyber Essentials
Cyber Essentials Plus is the baseline. For FCA-regulated firms, the expectation goes further:
Continuous vulnerability management
Not just “patch within 14 days” (Cyber Essentials) but continuous scanning with evidence of active management. Amazon Inspector scanning containers, Security Hub aggregating findings, and a documented workflow for triaging and remediating vulnerabilities under SLA.
Privileged access management
The FCA expects you to know exactly who has access to what, and to be able to revoke it immediately. For AWS this means:
- IAM Identity Center with SSO (no long-lived access keys)
- Just-in-time access for production systems (request, approve, time-limited)
- Full CloudTrail audit of all privileged actions
- Regular access reviews (quarterly minimum)
Incident response
A documented, tested incident response plan. Not just “call the CTO” - a structured process with:
- Defined severity levels mapped to response times
- Communication templates for regulators (FCA expects notification within specific timeframes for material incidents)
- Post-incident review process
- Evidence preservation procedures
Penetration testing
Annual penetration testing is expected (not just CE+ vulnerability scanning). The FCA wants to see that you proactively test your defences, not just reactively fix what scanners find.
What we typically deliver for FCA-regulated fintechs
Based on our experience with UK fintech clients:
| Deliverable | Purpose |
|---|---|
| Multi-account AWS architecture | Blast radius containment between environments |
| Security Hub + GuardDuty + Inspector | Continuous security monitoring under SLA |
| IAM Identity Center | Centralised access, MFA, session expiry, audit trail |
| Immutable audit logging | CloudTrail + S3 Object Lock for 7-year retention |
| Automated backup with cross-region replication | DR capability within defined RTO/RPO |
| IaC (Terraform) for all infrastructure | Auditability, reproducibility, exit strategy evidence |
| Documented DR procedures | Tested annually, evidence for regulatory review |
| CI/CD with security gates | Inspector blocks vulnerable images from production |
| Operational runbooks | Incident response, DR activation, escalation paths |
The timeline reality
Getting from “we have a working product on AWS” to “we can satisfy FCA infrastructure expectations” typically takes:
| Starting point | Timeline to FCA-ready |
|---|---|
| Well-managed IaC, basic security | 4-8 weeks |
| Running on AWS but limited automation | 8-16 weeks |
| Legacy/manual infrastructure | 16-24 weeks |
The earlier you build with regulation in mind, the less retrofit is needed. If you are pre-revenue and planning to seek FCA authorisation in 12-18 months, now is the time to get the architecture right.
Getting started
If you are a UK fintech building towards FCA authorisation - or already regulated and facing an infrastructure gap - we can help you get your AWS environment to the point where regulatory scrutiny is a non-event.
We have done this for fintechs handling traditional finance and digital assets, real-time payment processing, and companies across the regulated spectrum.
Book a free consultation - we will review your current state and give you an honest assessment of what the FCA will expect from your infrastructure.
