Most software fails by dropping a request. Money software fails by losing money, or inventing it. That is why a fintech engineer and a normal backend engineer can ship the same CRUD endpoint and be held to different standards. One is judged on whether the feature works. The other is judged eighteen months later, when an auditor pulls the database and asks who changed this row, when, and who approved it.
The Fintech Engineering Handbook by Voytek Pitula distills money software into three principles: no invented data, no lost data, no trust. Read it with a DBA's eyes and all three bottom out at the database. In a money system the database is not where state happens to live. It is the ledger, and the ledger is the product. Everything above it is a teller standing in front of the vault. Governance is the controls on the vault: who can open it, who has to be watching, and the camera that never stops recording.
The client surfaces (API, app, dashboard) are the teller, all reaching the database behind them. The database is the vault and the ledger, the database of record. Governance is the set of controls on the vault: who can open it, who has to be watching, and the recording that never stops.
No invented data
The fastest way to invent money is an ad hoc UPDATE on a balances table: forget the WHERE, and a few thousand users are millionaires. So changes to production data go through a workflow, never a raw connection. "I'll just run this quickly" is structurally the same action as fraud, and the database cannot tell them apart.
Constraints carry the rest (Invariants): unique indexes for idempotency, foreign keys that tie a posting to a real account. But not every invariant belongs in the schema. CHECK (balance >= 0) looks obvious until a settlement legitimately pushes an account negative and the system crashes instead of booking the overdraft. Deciding which invariants to weld in is itself a call that wants a second reviewer, not a lone engineer at 2am.
No lost data
A ledger is append-only. You never edit a posted entry, you post a compensating one that offsets it. So revoke UPDATE and DELETE on the ledger tables outright: a trail that can be quietly edited proves nothing.
Governance needs the same trail. An auditor asks who deployed this migration and who granted Alice production access, and when, so audit logging has to cover both the engine's log and every change request, approval and grant. Most teams only have the first.
Retention looks like a contradiction: AML makes you keep records for five to ten years, GDPR says forget the user. Resolve it at the database layer. Keep the financial records, but hold PII in a separate store behind masking, referenced from the ledger only by an opaque id. Where PII must sit inside an immutable record, encrypt it per user and erase by deleting the key.
No trust
The principle turns inward: your own engineers are a trust boundary too. The developer wants to ship the migration now, the DBA wants to not get paged at 3am, the security engineer wants no breach, and the auditor shows up last wanting proof the first three could not quietly do whatever they wanted. Not because anyone is malicious, but because a control that relies on everyone being careful is a hope, and hope does not survive an audit.
Four roles each pull a different way: the developer wants to ship now, the DBA wants no 3am pages, security wants no breach, the auditor wants proof. Governance reconciles all four so nobody is simply trusted, through least privilege, four-eyes approval and just-in-time access.
Three controls let all four coexist:
- Least privilege through roles, enforced at the statement and not just the connection (access control): read this table masked, but not write it.
- Four-eyes on sensitive moves (a ledger correction, a treasury transfer, a production migration), with the record showing requester and approver were different people. Otherwise the control is unprovable, which to an auditor means it does not exist.
- Just-in-time access, granted scoped and time-boxed, with an audited break-glass door for real emergencies so nobody builds their own backdoor.
What the auditor pulls
Build those and the frameworks fall out as a byproduct. Same handful of database controls underneath, different acronyms on top:
| Principle | Database control | Satisfies |
|---|---|---|
| No invented data | Change workflow, schema constraints | SOX 404 |
| No lost data | Append-only ledger, audit log, retention with masking | GDPR, AML, DORA / MiCA |
| No trust | Least privilege, four-eyes, just-in-time access | PCI DSS, SOX 404 |
PCI DSS wants restricted, logged access to cardholder data. SOX 404 wants proof a developer cannot push an unreviewed change (SOX). GDPR wants erasure, AML wants retention. DORA and MiCA want traceability of who touched the systems holding the money. The auditor is really asking one thing: can the ledger prove its own history.
The oldest technology in fintech
Double-entry bookkeeping was formalized by Luca Pacioli in 1494, five centuries before Postgres, and it already had the whole idea: every movement has a source and a destination, you never erase an entry, you correct it with another. The ledger was the first trust technology. The database is just its current form. Keeping it honest is the database's actual job, and always has been.
Related reading
- Fintech Engineering Handbook by Voytek Pitula
- What is Database Access Control (DAC)?
- Database Change Management for SOX Compliance
- Dynamic Data Masking Best Practices
- Database Audit Logging: Two Layers, One Trail