Pitula consolidates years of staff-level fintech experience into a single opinionated reference covering ledgers, idempotency, reconciliation, payment rails, KYC/AML, and operational rituals. His thesis is that the canonical knowledge of money systems has never been written down in one place, and engineers building payment backends deserve a practitioner-grade guide rather than scattered blog posts and tribal knowledge.
By submitting the handbook to HN, signa11 implicitly endorses it as worth the community's attention. The 231-point response within a day signals broad agreement that this kind of consolidated, vendor-neutral fintech reference has been conspicuously missing.
The editorial argues that Stripe's engineering blog, while excellent, is inherently self-promotional, and that the real tacit knowledge lives in the heads of ~4,000 engineers worldwide. Pitula's direct, slightly tired, jargon-allergic tone is praised precisely because it reads like a senior engineer in a 1:1 rather than marketing-adjacent thought leadership.
Pitula's handbook organizes its architectural advice around the assertion that 'your ledger is the source of truth; everything else is a cache,' and backs it with concrete schemas that hold under load. This reframes common fintech mistakes — deleting transactions, treating balance rows as authoritative, bolting reconciliation on after the fact — as violations of a single underlying invariant.
Wojtek Pitula — a staff-level fintech engineer who's spent years inside payments and banking platforms — quietly published the Fintech Engineering Handbook at `w.pitula.me/fintech-engineering-handbook/`. Hacker News surfaced it to 231 points within a day, which is the HN equivalent of a standing ovation for a piece of long-form technical writing with no logo, no startup attached, and no Substack paywall.
The handbook is the thing the industry has refused to write for fifteen years: a single, opinionated, end-to-end reference for engineers who are about to build systems that move other people's money. It covers ledgers, idempotency, reconciliation, payment rails (cards, ACH, SEPA, faster payments), KYC/AML, fraud, PCI scope, chargebacks, regulatory reporting, and the operational rituals — close-of-day, settlement windows, dispute timers — that nobody in a CS program ever mentions.
The tone is unmistakably practitioner. There are no diagrams of Visa's logo trying to look profound. Instead you get sentences like "your ledger is the source of truth; everything else is a cache," followed by the schema that makes that statement actually hold under load. Pitula writes the way senior fintech engineers talk in 1:1s — direct, slightly tired, allergic to the word "seamless."
Fintech has a documentation problem that's hard to overstate. The canonical knowledge — how to design an immutable ledger, when to use pessimistic vs. optimistic locking on a balance row, why you never, ever delete a transaction — lives in three places: Stripe's engineering blog (excellent but self-promotional), a handful of conference talks that are eight years old, and the heads of about 4,000 people worldwide who've shipped a real payments backend. Pitula's handbook is the first attempt I've seen to consolidate that tacit knowledge into something a mid-level backend engineer can read on a weekend and stop making the obvious mistakes.
The obvious mistakes are remarkably consistent. Floating-point money. A `balance` column that gets `UPDATE`d in place. Idempotency keys that are scoped to the request but not the operation. Reconciliation jobs that compare two systems and "fix" the difference by overwriting one of them. Webhook handlers that aren't idempotent because "Stripe says they only send once" (Stripe does not say that, and they do not only send once). A KYC pipeline glued together with cron and hope. Every one of these is a six-figure incident waiting to happen, and every one of them is in the handbook with a worked example of why it bites and what the boring correct version looks like.
The comparison most readers will reach for is Gergely Orosz's *Building Mobile Apps at Scale* or Alex Xu's *System Design Interview* series. The closer analogue is actually Martin Kleppmann's *Designing Data-Intensive Applications* — a domain-specific reference that respects the reader's time and assumes they already know what a B-tree is. DDIA taught a generation of engineers to stop confusing replication with backup; this handbook will, if it gets the readership it deserves, teach the next generation to stop confusing a database row with a ledger entry.
The HN thread is also worth reading. The top comments aren't "this is great," they're senior fintech engineers arguing about specific chapters — whether the double-entry section should mention triple-entry accounting, whether the chargeback flow oversimplifies dispute representment, whether the PCI scoping advice is too conservative for non-US issuers. That's the signature of a real reference: practitioners fighting over the details rather than thanking the author for the inspiration.
If you're on a team that's about to touch money — and in 2026 that includes a depressing number of teams who think they aren't, because their B2B SaaS is adding "usage-based billing" or their marketplace is finally moving payouts in-house — read it before your next design doc. Specifically:
Before you write the schema. The handbook's ledger chapter alone will save you the migration you're going to do in eighteen months when finance asks why the numbers in your dashboard don't match the numbers in Stripe. Append-only ledger, computed balances, no `UPDATE` on financial rows. If your current design doesn't do this, fix it now while the table has thousands of rows instead of millions.
Before you integrate the processor. Idempotency is not a feature you bolt on after the first duplicate charge. The handbook's treatment of idempotency keys — scope, TTL, what to return on replay, how to handle the case where the original request succeeded but the response was lost — is the kind of thing you cannot afford to get wrong and cannot easily retrofit.
Before you scope PCI. The handbook is refreshingly direct: tokenize everything, never store a PAN, route card data straight from the browser to the processor via their hosted fields, and your audit shrinks from a quarter-long ordeal to a questionnaire. Engineers consistently underestimate how much money and time bad PCI scoping costs, and how cheap good scoping is if you decide it on day one.
There's a secondary use case worth flagging: hiring. Print the table of contents, hand it to a senior backend candidate, and ask which three chapters they'd want to skip because they've already shipped the systems described. You'll learn more in five minutes than from any system-design interview.
The interesting question is whether this becomes the de facto reference the way DDIA did, or whether it stays a beloved HN artifact that 8,000 people bookmark and 800 actually read. The signal is encouraging — Pitula is iterating in public, the HN comments are already feeding back into revisions, and the handbook is structured for incremental updates rather than a static v1. Stripe, Adyen, Wise, and the dozen serious neobank platforms have every incentive to point new hires at it instead of writing their own onboarding docs. If you build anything that ends in a customer balance, bookmark it, send it to your team, and treat the next design review as an open-book exam.
Word of advice to anyone considering the "minor-units precision" strategy for representing monetary amounts: Don't (or at least, don't use it as an interchange/API data format).It seems like a clever idea (fast integer math, no rounding problems for addition and subtraction)
> Money can’t be created out of nowhereWell, in case of a bank it can. And it happens on a daily basis. In fact thats how most private bank money enters the system in the first place either when a bank makes a loan or when it buys any other asset like e.g. a corporate bond (you can conceptualize
As a programmer, what I feel when I see fintech programmers each speaking from their own different experiences and perspectives is that it makes me wonder what it really means to be good at programming.What user xlii said about not storing monetary amounts as floats is a common IEEE 754 issue. And w
Nice. The book contains a bunch of good information that could already be found elsewhere but collecting it is quite practical. I highly suggest to read Kleppmann's Designing Data-Intensive Applications. The first edition was very good, a second one came out recently.I was CTO of a FinTech wher
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
I glanced, and I found this handbook shallow and - in some areas - even bad advice.E.g. If I ever see a monetary value stored in something else than integers I'm going to run away screaming (thank you Rust decimals represented as JSON floats). It's always integers unless you have a VERY go