Building secure fintech infrastructure
A field guide to the primitives, tokens, KMS, isolation, that keep money movement trustworthy.
Every fintech incident report reads the same way. The vulnerability was known. The primitive was mis-used. The blast radius was larger than anyone had drawn on the whiteboard. The fix, in retrospect, was straightforward.
The lesson we keep coming back to is that security in money movement is a primitives problem, not a controls problem. Get the primitives right and most of the controls draw themselves.
Four primitives that matter
- Tokenisation of every PAN, account number and identifier at the edge. If the data never enters your application tier, most of your PCI scope disappears with it.
- A hardware-backed KMS with a strict key hierarchy. Application code never sees a master key; it sees a wrapped data key for one purpose, valid for one operation.
- Isolation at the tenant boundary, not at the application boundary. A well-designed multi-tenant fintech treats every tenant as a full network partition, not a database row.
- Immutable, tamper-evident audit. Not a log file. An append-only ledger of every state transition, verifiable end-to-end.
The two failure modes to avoid
The first is over-rotation on compliance certifications and under-rotation on the underlying primitives. A SOC 2 report will not save you from a mis-scoped IAM policy.
The second is treating security engineering as a phase, not a practice. The teams that never have an incident are the teams where the security review happens in the same PR as the feature, not two weeks after it shipped.
“The right question is not 'is it secure.' The right question is 'what happens on the day it isn't.'”
Where we start
On every fintech engagement, we start with three things: draw the actual data flow (not the one on the architecture slide), name the primitives, and run a tabletop against a compromise scenario. Half the work of the first month is undoing assumptions that were never true.
The good news: the primitives themselves are more accessible than they have ever been. AWS KMS, cloud-native tokenisation, per-tenant VPCs, verifiable data structures. The gap now is not the technology. It is the discipline to use it consistently.
Frequently asked
01What does secure actually mean for a financial platform?
That you can explain any balance, prove who changed what, and lose a component without losing correctness. Encryption and access control are necessary and rarely the thing that fails. What fails is a system that cannot reconstruct how it arrived at a number, which is both a security problem and an audit one.
02How much does regulation shape the architecture?
More than most teams plan for, and earlier. Data residency, retention and auditability are architectural constraints, not configuration, and retrofitting them is where fintech programmes lose quarters. We bring the compliance owner into design rather than presenting to them at the end.
03Build on a core banking platform or build your own?
Buy the parts that are commodity and regulated, build the parts that are your product. Ledgers, payments rails and KYC are rarely where a fintech differentiates, and building them means owning their compliance surface forever. The decision is about which obligations you want to carry, not which is more interesting to build.
04How do you test something that moves money?
With reconciliation as a first-class feature rather than a reporting job. If the system cannot continuously prove its own balances against an independent source, no amount of unit testing will tell you it is right. That harness gets built before the migration code, not after it.
