Fintech Engineering

I design and build financial systems for companies that move money: double-entry ledgers, payment integrations, reconciliation engines, and settlement workflows. I work as an independent systems architect with clients in India, the UAE and the UK — one engagement at a time, from first schema to production.

Why do your numbers stop matching?

Every finance team I’ve met has the same 4 PM ritual: two totals, one screen, and the question “yeh difference kahan se aaya?” The gateway says one number, the bank statement says another, your database says a third. Someone opens Excel. Someone stays late.

Here’s the thing — this isn’t a discipline problem. Your team is not careless. It’s an architecture problem, and it compounds quietly:

• Payments recorded as row updates instead of immutable entries, so history is whatever the last UPDATE says it is. When the number is wrong, there is no trail of how it got wrong.
• Refunds and reversals bolted on later, written straight to the tables, skipping whatever rules the original flow had. Every “quick manual fix” is a future discrepancy with a delay timer.
• Retries creating duplicates because nothing enforces idempotency. The same webhook lands twice — and now you’ve paid a vendor twice, or credited a wallet twice, and you’ll find out at month-end. Maybe.
• Reconciliation treated as a monthly cleanup instead of a daily automated discipline — so every error gets thirty days to breed dependents: reports, payouts and decisions built on numbers that were already wrong.

Watch how it plays out with real numbers. Your dashboard says the settlement account holds ₹4,20,000. The bank says ₹4,17,300. The difference — ₹2,700 — could be one duplicated webhook, three unrecorded gateway fees, or a refund that succeeded at the gateway and failed in your database. With a balance-column architecture you cannot tell which, because the column has no memory. So someone reconstructs a month of history in Excel, finds a plausible story, posts an “adjustment”, and the books agree again — until next month, when the same class of error produces a new difference, and the adjustment entries pile up into a number nobody can defend.

Left alone, this becomes audit friction, then regulatory friction, then a funding-diligence problem. In India, RBI’s 2022 Digital Lending Guidelines and the payment-aggregator licensing regime mean your books get looked at properly (source: rbi.org.in). In the UAE, DFSA and FSRA expect the same standard in the free zones. The UK’s FCA has expected it for years. The jugaad ledger stops being charming the day a regulator asks for it.

What does fintech engineering include?

These are sections of one service, not separate SKUs — most engagements combine three or four of them.

• Ledger design and build. Double-entry, append-only, every paisa traceable from event to balance. The khata your CA dreams about, implemented in PostgreSQL with the invariants enforced at the schema level — not in application code that the next hire can bypass.
• Payment integrations. UPI, cards, netbanking, wallets, payouts — built against the aggregator’s sandbox and then hardened against their production quirks, which are never the same thing. Webhook handling that treats every delivery as a rumour until confirmed; status state machines that admit payments have more than two moods.
• Reconciliation engines. Automated three-way matching between your ledger, the gateway’s settlement files and the bank statement — exceptions surfaced daily with reason codes, khalas — not discovered at month-end by an exhausted analyst.
• Settlement and payout workflows. T+1, T+2, split settlements, marketplace commissions, partner shares — encoded as rules with effective dates, not tribal knowledge that leaves when your ops lead does. India’s equity markets completed the move to T+1 in January 2023 (SEBI), and the compression pressure on operational timelines is only going one direction — the systems have to keep up.
• Migration off the old system. The scariest one, and the one with the most established method: moving live money data with dual-writes, verified backfills, parallel runs until the difference is zero, and a cutover that is deliberately boring. The full method is written up in the migration case study and the zero-downtime migration article.

How do you actually build a ledger — and why is the obvious way wrong?

The obvious way: a balance column, updated on every transaction. Fast to build, feels fine for months. It fails for one reason that no amount of care fixes — a balance is a claim, not a fact. When the balance column says ₹4,20,000 and the bank says ₹4,17,300, the column has no memory of how it got there. You cannot audit an assertion.

So I build the other way — the way every serious money company builds. I’ve published architecture teardowns of fourteen of them, from Stripe to Nubank to PhonePe, and this exact pattern appears in production in every single one:

1. Events first. Every money movement is an immutable event — payment_received, fee_charged, refund_issued. Nothing is ever edited; corrections are new entries that reference what they correct. Your history becomes append-only, which is the only kind of history an auditor believes and the only kind a replay can rebuild from.
2. Double-entry on top. Every event posts equal debits and credits across accounts — customer wallets, gateway receivables, fee income, the bank. The books cannot fail to balance, because imbalance is structurally unrepresentable: the per-event zero-sum is a database constraint, not a code review comment. Double-entry has survived five hundred years of commerce for the same reason Postgres survives production — it assumes people make mistakes and catches them at write time.
3. Balances as projections. Computed from entries, cached for speed, rebuildable from scratch at any moment. When cache and truth disagree, truth wins and the cache is regenerated — never the other way around. This inversion is the whole game: the balance stops being a thing you maintain and becomes a thing you derive.
4. Idempotency at every write. Every mutation carries a client-generated key; replays become no-ops that return the original result. The double-webhook problem disappears at the schema level — a unique constraint, not a try-catch — and infrastructure noise stops becoming financial fact. The details matter enough that I wrote them up separately: Idempotency, done right.
5. Reconciliation as a first-class citizen. A daily job that matches internal entries against gateway files and bank statements, auto-clears the matches — which should be well above ninety-five percent, or your upstream references are broken and we fix that first — and queues the exceptions with a reason code: amount mismatch, timing, missing counterpart, duplicate. Hisaab barabar, every morning, without the 4 PM ritual. Write-offs need a maker, a checker and a named reason; “adjustment” as a category is where drift goes to hide.

The stack underneath is deliberately boring: PostgreSQL with the invariants in the schema, typed services, queues for the async parts, integer minor units everywhere — paise, fils, pence — because floating point near money is how you get balances that are wrong by one paisa in ways that take a week to find. Boring is a feature. Postgres specifically, because constraints, transactions and twenty-five years of production scar tissue are exactly the qualities you want underneath other people’s money — and because every engineer you hire next year will already know it. In money systems, excitement is a defect and novelty is a hiring problem.

What does the engagement actually look like?

Week zero is a working session on your real system — schema, flows, the last three reconciliation incidents. You get a written verdict: what is structurally sound, what is bleeding, what order to fix it in. If the honest answer is that you need two weeks of reconciliation tooling and not a rebuild, that is what the verdict says — I price the diagnosis so it is worth doing even if you take the plan elsewhere.

The build runs in shippable slices: reconciliation first when the bleeding is active, the ledger core next, integrations migrating onto it one flow at a time. Live money flows are never big-banged — every cutover has a parallel run behind it, and every parallel run ends with a diff of zero or it does not end. Your engineers work alongside me throughout; the design intent lands in their heads and in written decision logs, not just in the code.

After go-live, the system’s own reconciliation reports are the handover document — when the daily exception queue stays boring for a month, the engagement is done. You own everything: code, schema, docs, and the phone number of the person who designed it.

Who is this for?

The pattern fits any business where money’s correctness is existential, but four profiles account for most of the work:

• NBFCs and lenders — loan books are ledgers wearing costumes: disbursals, accruals, receipts, waivers and restructures all demand the append-only discipline, and RBI’s scale-based supervision assumes you can prove any number on demand. The specialised version lives at /industries/lending and /industries/nbfc-operations.
• Marketplaces and platforms — one order fans out into commissions, promos, delivery fees, returns and seller settlements on different cycles. Seller trust dies on wrong payouts faster than on anything else in the product; the split-and-settle architecture is at /industries/marketplaces.
• SaaS with wallets or subscriptions — the moment you hold customer value or bill on cycles, MRR stops being a dashboard number and becomes an auditable fact, or it becomes a liability. /industries/subscriptions covers the billing-specific version.
• D2C and retail at volume — COD reconciliation, gateway settlements, marketplace payouts and refunds across lakhs of orders: the same three-way matching problem, retail costume. The operational side is at /industries/retail.

If your vertical isn’t listed, the test is one question: does anyone else’s money pass through your systems? If yes, this page is about you — describe how the money moves at /contact and I’ll route you honestly.

What’s the proof?

• The fourteen-company deep-dive series — architecture teardowns of Stripe, Revolut, Monzo, Nubank, Mercado Pago, Kaspi, PhonePe, OPay, TymeBank, Airwallex, Afterpay, Visa, Mastercard and LemFi. Read how the best in the world run ledgers, risk and settlement — then hold me to the same standard: the series lives on the blog.
• The ledger rebuild — drifted books to a daily-balancing double-entry core, with the migration method that made it safe.
• The zero-downtime migration — live financial history moved with parallel runs and a Sunday-morning cutover nobody’s customers noticed.
• The reconciliation engine — month-end Excel archaeology replaced by a daily matching discipline.

Related reading

Why your ledger drifts · Ledger design · Double-entry for engineers · Idempotency, done right · Reconciliation at scale · The T+1 problem

Ready when the difference stops being funny

If your month-end involves the phrase “difference aa raha hai” — that’s my cue. Book a call, tell me your stack and your last bad reconciliation story, and I’ll tell you in thirty minutes whether this is a two-week fix or a real rebuild. Chai virtual hi sahi.