4) WRIT / Fintech / 2026-09-06

FinTech Engineering Resources: A Practitioner's Reading List

A working engineer's map to learning fintech properly: ledgers, invariants, rails, settlement, and reconciliation — plus the GitHub-native courses and curated lists worth bookmarking.

#fintech#payments#systems#career#reading-list

I keep getting asked some version of "how do I actually learn fintech engineering" — not the pitch-deck version, the version where you have to reason about ledgers, settlement, and money that must never silently disappear or duplicate. So I collected what I consider the best material into one list, split into two parts:

  1. The deep end — books, handbooks, and production-system writeups for engineers who need to understand ledgers, rails, and invariants well enough to design around them.
  2. The on-ramp — GitHub-native curricula and free courses for getting oriented quickly, especially if you're coming from general software engineering or quant curiosity.

Nothing here is filler. If a resource made this list, it's because it teaches something you can't get by just reading API docs for Stripe or Plaid.

Part 1: The deep end

For a working fintech engineer, the useful stuff is not "what is a bank" — it is ledgers, invariants, rails, settlement, idempotency, reconciliation, and how real cores are actually decomposed.

X (Twitter) does surface a lot of this, but the densest material is still books, a few free handbooks, vendor-independent papers, and engineering writeups from people who have run money systems in production.

Start here

1. Fintech Engineering Handbook — Voytek Pitula Free, and the best engineer-first map I know right now. Three rules: no invented data, no lost data, no trust. Then it goes into money representation, double-entry ledgers, value/booking/settlement time, funds reservation, idempotency, outbox/CDC, webhooks, reconciliation, four-eyes, and testing strategies that actually matter for money. It also has its own reading list.

This is the resource that has been circulating on X recently.

2. Payments Systems in the U.S. — Carol Coye Benson, Scott Loftesness, Russ Jones (Glenbrook) Still the standard "how money actually moves" book for cards, ACH, wires, checks, and cash. Read this before designing a payment hub. Modern Treasury calls it the payments bible.

3. Designing Data-Intensive Applications — Martin Kleppmann Not a banking book. Still mandatory. Logs, replication, consistency, exactly-once illusions, and why "just use Kafka + microservices" is not a ledger. Pair it with Kleppmann's short essay Accounting for Computer Scientists.

Core banking architecture

  • Designing the Core Banking Ecosystem — Krishna Jha. Surrounding systems around the core: payment hubs, ACH/RTGS, AML, onboarding, CRM, batch, reconciliation, integration patterns, failure modes. Useful if you already know the ledger and now have to live in a real bank landscape. (No stable canonical link found at time of writing — search by title/author.)
  • Modernizing Core Banking Systems — Alexander Gruber. Academic but practical: what a CBS is, why monoliths calcify, and a module-by-module modernization process using BIAN as a target. The thesis PDF is also available.
  • Rip Out the Core — Pål Krogdahl. Transformation book: shrink the core, capability-based waves, build/buy/consume, avoid another big-bang replacement.
  • SaaScada, "Building from scratch." Short and concrete: MACH, real-time, event-driven, CQRS, event-sourced ledger instead of mutable balance rows. Good thinking piece if you are greenfield.
  • AWS Guidance for Building a Core Banking System. Cloud reference architecture, not gospel, but a useful diagram of event-driven microservices around a ledger.
  • Journal paper: "Building a Performance Efficient Core Banking System Based on the Microservices Architecture." Case study migrating a large monolith and measuring throughput/latency. Useful as a cautionary "MSA is not free" paper.

Also learn BIAN (Banking Industry Architecture Network): service domains, APIs, and a shared language for decomposing a bank. Do not implement all 300+ domains. Use it as a bounded-context catalog so deposits, payments, lending, and GL do not collapse into one service.

Modern cores worth studying as architectures, not as shopping lists: Thought Machine Vault (product logic as versioned contracts on a universal ledger), Mambu-style configurable cores, and the Nubank/Monzo/Starling writeups below.

Payments and market infrastructure

ISO 20022 and scheme docs (FedNow, TCH RTP, SEPA Instant, NIP, UPI) are dry and worth reading once you know which rail you own.

Production systems worth studying

These are better than most textbooks because they show tradeoffs under load:

  • Nubank / Building Nubank + InfoQ "Architecting Software for Leverage." Clojure, Datomic as an immutable fact log, hexagonal services, Kafka, real-time double-entry, history as a first-class feature. Their stack is unusual; the ideas (immutability, auditability, replay) are not.
  • Monzo. "Modern Banking in 1500 Microservices," AWS architecture talks, stand-in/failover across clouds, fraud control pipeline. Study how they isolate the payment hot path.
  • Starling. "Microliths" (couldn't find a stable link), correlation IDs, at-least-once / at-most-once as explicit product rules, card processor.
  • Crassula and similar vendor blogs on CBS components and database design are uneven, but useful for a component checklist: CIF, CASA, GL, lending, card switch, statements, EOD.

How I would read this as a practicing engineer

  1. Pitula handbook + Kleppmann + Glenbrook. That trio covers invariants, distributed systems, and rails.
  2. Then a ledger series (Modern Treasury or SaaScada) and implement a tiny double-entry journal yourself: immutable entries, derived balances, idempotency keys, reversals not updates, recon against an external file.
  3. Then BIAN + one modernization book so you can talk to bank architects without drowning in vendor language.
  4. Then one real-system talk (Nubank or Monzo or Starling) and one payments-system-design chapter.

The architectural invariants that show up in almost every good source

  • Money is integers in minor units, never floats.
  • The journal is the source of truth; balances are projections.
  • Double-entry is an invariant, not a reporting style.
  • Distinguish authorization, booking, and settlement time.
  • Idempotency and exactly-once effects beat "exactly-once delivery."
  • External rails lie; reconcile continuously.
  • Saga/outbox over distributed 2PC for multi-service money movement.
  • Audit trail and reversals, never silent mutation.

A natural extension of this list is a 4-week reading + build plan (ledger + payment orchestrator + recon) tailored to whether you work closer to core/ledger, cards, or A2A rails — that's a good follow-up project once the reading above is done.

Part 2: GitHub-native learning resources

If Part 1 is the deep end, this is the on-ramp: curated lists and free courses that are useful for discovery and structured self-study, especially if you're building hands-on rather than reading cover to cover.

GitHub curated lists (the "awesome" learning route)

  • wilsonfreitas/awesome-quant — the big one (29k+ stars). Libraries, packages, and resources for quantitative finance across Python, R, Julia, Java, and more. Best for hands-on, code-first learning. See also github.com/topics/quant.

  • hendrirach/financemasters — an open-source curriculum for learning finance, maintained by a finance-authority professional and LBS alum. Pulls together free university courses (Yale's Shiller on financial markets, Damodaran's NYU corporate finance/valuation), a math track, and a fintech section. This is the closest thing to a structured self-study path.

  • awesomelistsio/awesome-fintech and its sibling awesomelistsio/awesome-finance — both have dedicated "Learning Resources" sections (tutorials, guides, courses) alongside platforms and APIs. Good for discovery of tools and where to go next.

Free courses & masterclasses (structured, beginner → intermediate)

If your goal is discovery / staying current

Quick recommendation depending on where you're starting

  • financemasters if you want a full self-study path.
  • awesome-quant if you want to learn by building.
  • CFTE's free masterclasses if you want the fintech-industry framing.

Putting the two parts together

The GitHub lists and free courses in Part 2 are the fastest way to get oriented and to find code you can run today. The books and production writeups in Part 1 are what actually change how you design systems — they're where the invariants come from. My own sequencing: skim Part 2 for a week to get vocabulary and working code, then commit to the Part 1 trio (Pitula, Kleppmann, Glenbrook) and build the tiny double-entry ledger. Everything else on this page is reference material to pull from as the specific problem in front of you demands it — cards, ACH, RTGS, core modernization, or a production incident that forces you to finally read the ISO 20022 spec.