Cloud Infrastructure for FCA-Regulated Fintech

Running regulated financial services in the cloud requires careful attention to compliance, data residency, and operational resilience. We share our approach to cloud architecture for fintech.

Why Cloud for Fintech?

Cloud infrastructure offers compelling advantages for fintech companies:

• Scalability: Handle growth without hardware procurement delays
• Security: Leverage cloud providers' security investments
• Speed: Deploy new services in minutes, not months
• Cost: Pay for what you use; avoid capital expenditure

However, operating regulated financial services in the cloud requires navigating FCA expectations and building architectures that maintain compliance.

FCA Expectations for Cloud Outsourcing

The FCA treats cloud as outsourcing, subject to SYSC 8 requirements. Key obligations:

Risk Assessment

Before migrating to cloud:

• Assess operational risks of cloud dependency
• Evaluate provider security and resilience
• Consider concentration risk (over-reliance on single provider)
• Document the assessment and approval process

Contractual Requirements

Cloud contracts must include:

• Audit rights (ability to examine provider's controls)
• Data location requirements
• Security obligations
• Exit provisions (avoiding lock-in)

Operational Resilience

Under the FCA's operational resilience requirements, firms must:

• Identify important business services
• Set impact tolerances
• Test ability to remain within tolerances

Architecture for Compliance

Data Residency

For most UK fintech use cases, data should remain in UK or EU regions:

• AWS: eu-west-2 (London)
• Azure: UK South, UK West
• GCP: europe-west2 (London)

Configure service policies to prevent data leaving approved regions.

Network Architecture

┌─────────────────────────────────────────────────────────────┐
│                     VPC Architecture                         │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐         │
│  │ Public      │  │ Private     │  │ Data        │         │
│  │ Subnet      │  │ Subnet      │  │ Subnet      │         │
│  │             │  │             │  │             │         │
│  │ Load        │  │ Application │  │ Database    │         │
│  │ Balancers   │──▶ Servers    │──▶ Clusters    │         │
│  │             │  │             │  │             │         │
│  └─────────────┘  └─────────────┘  └─────────────┘         │
│        │                                                     │
│        │ WAF, DDoS Protection                               │
│        ▼                                                     │
│  ┌─────────────┐                                            │
│  │ Internet    │                                            │
│  │ Gateway     │                                            │
│  └─────────────┘                                            │
└─────────────────────────────────────────────────────────────┘

Security Controls

Essential security measures:

• Encryption at rest: All data encrypted using KMS-managed keys
• Encryption in transit: TLS everywhere, including internal traffic
• Identity management: Centralised IAM with MFA enforcement
• Network segmentation: Security groups and NACLs limiting traffic
• Secrets management: Never hardcode credentials; use secrets managers

High Availability and Disaster Recovery

Multi-AZ Deployment

Minimum availability requirements:

• Application servers across multiple availability zones
• Database clusters with synchronous replication
• Load balancers distributing traffic

Backup and Recovery

• Automated daily backups with retention policies
• Point-in-time recovery for databases
• Cross-region backup replication for critical data
• Regular recovery testing (not just backup verification)

Disaster Recovery

Define and test DR scenarios:

• Single AZ failure: automatic failover
• Region failure: failover to DR region (for critical services)
• Provider failure: multi-cloud strategy (complex, usually unnecessary)

Monitoring and Audit

Comprehensive observability:

• Infrastructure metrics: CPU, memory, disk, network
• Application metrics: Request rates, latency, errors
• Security events: IAM changes, network flow logs, access patterns
• Audit logs: All API calls to cloud services

Centralise logs with appropriate retention for regulatory requirements (typically 5-7 years for financial records).

Infrastructure as Code

Manage infrastructure through code:

• Version-controlled Terraform or CloudFormation
• Automated deployment pipelines
• Drift detection and remediation
• Environment parity (dev matches production)

Conclusion

Cloud infrastructure enables fintech companies to build scalable, secure services without massive upfront investment. Meeting FCA expectations requires intentional architecture decisions around data residency, operational resilience, and audit capabilities. The investment in getting this right creates a foundation for compliant growth.