Software Development for Financial Services: Compliance & Innovation
The compliance-innovation tension
Financial services software occupies an unusual position. It must be reliable to a standard that most software is not held to — the consequences of failures can include regulatory sanction, financial harm to customers, and reputational damage that takes years to repair. At the same time, competitive pressure from fintech challengers means that financial services firms cannot use compliance requirements as an excuse for slow innovation.
The firms that manage this well treat compliance as an architectural constraint — something to design around intelligently — rather than as an impediment to be navigated around wherever possible. This post covers what that looks like in practice.
The regulatory landscape
Financial services software in the UK operates under regulatory frameworks including:
- FCA regulations: The Financial Conduct Authority regulates financial services firms in the UK, with requirements covering conduct of business, systems and controls, and operational resilience.
- PSD2 / Open Banking: Requirements for payment service providers around strong customer authentication, API access, and data sharing with authorised third parties.
- GDPR: Data protection obligations for any processing of EU/UK personal data, with specific considerations for financial data which is often particularly sensitive.
- Senior Managers and Certification Regime (SMCR): Individual accountability requirements that have implications for how audit trails and approval workflows are designed.
- Operational resilience requirements: FCA requirements for important business services to remain within defined impact tolerances during severe but plausible disruptions.
The specific regulations that apply depend on the nature of your business and the services you provide. Regulatory advice from a qualified consultant is essential before committing to an architecture.
Designing for compliance from the architecture
Audit trails
Financial services software typically needs comprehensive audit trails — records of who did what, when, and with what authority. This is not just a logging requirement; it is an architectural one. Data models that allow records to be updated without trace are fundamentally incompatible with most financial regulatory requirements. Immutable audit logs, event sourcing, and append-only data structures are design patterns that make audit trail compliance a property of the system rather than a feature bolted on.
Separation of duties
Many financial processes require two-person or multi-party approval — maker-checker controls where one person initiates an action and another must approve it before it takes effect. Building this into the application requires careful data modelling and workflow design from the start. Adding it to an application designed without it is usually expensive and error-prone.
Encryption and data security
Financial data requires robust encryption at rest and in transit. Beyond TLS for transport and full-disk encryption for storage, sensitive financial data — account numbers, transaction details, personal financial information — should be encrypted at the field level in the database so that a compromised database does not immediately expose readable financial data.
Business continuity and disaster recovery
FCA operational resilience requirements mandate that important business services remain available within defined impact tolerances during severe disruptions. This has direct implications for infrastructure design: redundant systems, defined recovery time objectives, tested recovery procedures, and regular resilience testing. These are not afterthoughts — they need to be part of the infrastructure architecture from the start.
Innovation within constraints
Compliance constraints can actually focus innovation productively. When you cannot cut corners on security or auditability, you are forced to find innovative approaches to user experience, process efficiency, and product differentiation that work within those constraints. This discipline often produces better products than unconstrained development.
Some of the most interesting innovation in financial services software has come from finding ways to make compliance obligations better experiences rather than friction — making authentication flows faster and more intuitive, making audit trails genuinely useful for users rather than just regulators, and making disclosure requirements into genuinely informative content.
Working with regulators, not against them
The FCA operates a fintech sandbox and innovation pathways for firms building novel financial services software. These programmes allow firms to test new services with real customers under a modified regulatory framework before seeking full authorisation. For genuinely novel financial services software, engaging with the regulatory pathway early — rather than treating it as a final obstacle — is consistently good advice.
Choosing a development partner for financial services software
Development agencies working on financial services software need to understand both the technical requirements and the regulatory context. When evaluating agencies for financial services work, ask specifically:
- Have you built software for FCA-regulated firms before?
- How do you approach audit trail design?
- What is your approach to penetration testing for financial applications?
- Have you worked with the PSD2/Open Banking APIs?
- Can you provide documentation of your own security practices for due diligence purposes?
An agency that cannot engage substantively with these questions is probably not the right partner for financial services software, regardless of their general capability.