Fintech Architecture Patterns That Actually Survive Regulators
Five years building inside two of the largest banks. Here's what actually matters.
Fintech architecture content online is mostly written by people who've never been audited. Here's what regulators actually ask about and how I architect to pass.
Fintech architecture is full of folklore. Most of what you read online is written by people who've never sat through an audit. Here's what actually happens when regulators look at your system.
What auditors actually ask
In ~80% of audits I've been in, the questions cluster around five things:
- Audit trail completeness. Can you reconstruct what happened to a transaction at 2am six months ago? Down to the user/service that made each change?
- Access controls. Who can do what, who approved that access, when does it expire?
- Separation of duties. Can a single person initiate AND approve a transaction?
- Data residency. Where physically does customer data live? Including backups, analytics, log storage?
- Recovery testing. When was your last DR drill? What was the RTO/RPO actual vs. target?
Notice what's NOT on this list: what database you use, whether you do microservices, whether you're in the cloud. That stuff matters operationally; auditors mostly don't care.
Patterns that pass
Append-only audit log. Every state-changing action writes to a log table that nobody can delete from (revoke DELETE permission at the database level). Use this as your source of truth for "what happened." Don't try to derive audit history from your operational tables - they get rewritten.
Idempotency keys everywhere. Every external interface accepts a client-supplied idempotency key. Replays are safe. This is non-negotiable for payments, but I add it everywhere - it makes incident response 10x easier.
Outbox pattern for events. Don't write to your DB and publish to Kafka in the same atomic block. Write the event to an outbox table inside the transaction, then have a separate process publish from the outbox. Solves the "DB committed but Kafka didn't" failure mode.
Saga for cross-service transactions. When a flow spans services and you can't use a 2PC, write explicit compensating actions. Every step has an undo step. Test the undo paths.
Patterns that fail
- "We'll add audit logging later." You won't. Or you will, and the gap will hurt you.
- Soft deletes without rigour. A "deleted_at" column without strict access controls becomes a way to hide data from auditors. Don't.
- PII in logs. It's there. Find it. Remove it. Add tests that fail if it ever appears.
- Implicit trust between services. Service A calling service B should authenticate. Even within your own VPC.
What I do on every fintech project
- Outbox + audit log on day 1
- Idempotency keys on all write APIs
- Per-service IAM identities (not shared secrets)
- End-to-end DR drill quarterly
- Penetration test annually
- Data classification doc (what PII lives where)
The hidden cost
The architectural patterns above are 1.5-2x more code than the "happy path" version. That's the tax. It's not optional in fintech. Bake it into your estimates from day 1, or you'll under-quote and over-deliver and burn out.