FCA-Compliant Payment Platform — 10M+ Daily Transactions

A UK fintech startup had built something genuinely impressive: a B2B payment platform connecting 400+ SMEs to their banking rails, processing a rapidly growing volume of transactions. The technical problem was that they'd built it like a startup — a single Node.js application on a £180/month VPS, with payment state stored in a SQLite database, deployed by SSHing into the server and running git pull. For 18 months it had worked well enough. Then they landed their first enterprise client — a facilities management company routing £1.2M/month through the platform — and the architecture began to visibly strain. Three outages in six weeks, each costing hours of failed transactions that had to be manually reconciled. Their FCA Electronic Money Institution licence application was already in progress, and the regulator's technical questionnaire was asking questions their current architecture couldn't honestly answer: How do you ensure idempotency in payment processing? Describe your disaster recovery procedures. What is your data segregation model for client funds? They came to us nine months before their EMI licence renewal deadline with two parallel mandates: make the platform reliable enough to retain the enterprise client, and make it auditable enough to satisfy the FCA.

• SQLite database on a single VPS processing live payment state — no replication, no backups, no recovery procedure beyond hoping the disk didn't fail
• Zero idempotency in payment processing — network timeout during a transaction meant manual investigation to determine whether money had actually moved
• FCA EMI licence renewal in 9 months requiring demonstrable technical controls around client fund segregation, audit logging, and disaster recovery
• Three outages in six weeks had damaged confidence with the enterprise client accounting for 40% of transaction volume
• No monitoring, no alerting, no audit trail — the team was discovering incidents when clients emailed to ask why their payments had failed

We designed and built a microservices payment architecture from scratch alongside the existing platform, migrated transaction processing with zero data loss, and produced the FCA technical documentation as a first-class deliverable alongside the code. The architecture was designed to answer the regulator's questions before they were asked.

• Event-sourced payment ledger on PostgreSQL with full idempotency — every payment has a deterministic state machine; double-processing is architecturally impossible
• Three core microservices: Payment Orchestrator (transaction lifecycle), Settlement Service (fund movement), and Compliance Engine (AML screening, audit log, suspicious transaction flagging)
• Client fund segregation at the database level with row-level security — the architecture makes it technically impossible for client A's funds to appear in client B's balance, satisfying the FCA's client money rules
• AWS multi-AZ deployment with RDS read replicas, automated failover tested monthly, and a 4-hour RTO documented and demonstrated to the regulator
• Real-time Datadog dashboards tracking payment success rate, settlement latency, and AML flag rate — the operations team went from discovering incidents via email to resolving them before clients noticed
• Strangler Fig migration: new architecture ran in parallel for 8 weeks, processing a growing percentage of transactions, until the legacy system was safely decommissioned