Banking & Fintech Systems

Double-Entry Core Ledger

Append-only double-entry ledger that guarantees financial data integrity and handles contention on hot accounts with pessimistic locking.

Interbank Payment Gateway

Interbank transfers using ISO 20022 (pain.001, pacs.008), distributed transactions coordinated by a Saga Orchestrator, end-of-day settlement with Spring Batch.

Architecture Decision Records

Architecture decisions written as Problem - Choice - Rationale - Trade-offs, including the real issues met during implementation — 13 ADRs, 9 of them already applied in Core Banking.

Roadmap & Devlog

A 3–6 month build roadmap and a phase-by-phase development log — updated honestly as work happens, not before.

Overview

These are two simulated core banking systems built with Java/Spring Boot, following a 3–6 month roadmap. Each one focuses on a different class of engineering problems:

Financial data integrity: an immutable double-entry ledger (append-only) that guarantees Debit = Credit for every transaction and controls contention on hot accounts.

Distributed transactions: interbank transfers coordinated with Saga Orchestration instead of 2PC, with idempotency and compensating transactions when a step fails.

Financial message standards: parsing and validating ISO 20022 messages (pain.001, pacs.008) and batch end-of-day settlement.

Core Banking System has completed Phase 1 (45/45 tests passing on both PostgreSQL and Oracle, overdraft protection verified across 3 Kubernetes Pods). Payment Gateway is the next phase. Detailed progress: Project status and Devlog.

The two sub-projects

Sub-project A: Interbank Payment Gateway

Message parsing & validation for pain.001 / pacs.008

Saga Orchestrator — coordinates and compensates distributed transactions

EOD Batch Settlement — Spring Batch, chunk-oriented

Exception/ops handling — retry, dead-letter

Calls Core Banking over internal REST with an Idempotency-Key header:

Sub-project B: Core Banking System

Account Service — account management, balance derived from the ledger

Ledger Service + Transaction aggregate root — append-only double-entry ledger, guarantees Debit = Credit

Concurrency Guard — pessimistic lock (SELECT ... FOR UPDATE), verified across 3 K8s Pods

Outbox Pattern + Kafka, Redis cache, runs on both PostgreSQL and Oracle

The Payment Gateway calls into Core Banking to update real balances (integration happens in Phase 3).

Quick comparison

Criterion	Sub-project B: Core Banking System	Sub-project A: Payment Gateway
Core business	Account management, double-entry bookkeeping	Interbank transfers, ISO 20022 messages
Hardest problem	Race conditions & data integrity	Distributed state & failure handling (Saga)
Consistency model	Strong consistency (ACID + DB locks)	Eventual consistency (Saga Orchestration)
Batch processing	—	EOD settlement with Spring Batch (chunk-oriented)
Security	Spring Security (Phase 3)	Spring Security (Phase 3)

Criterion

Sub-project B: Core Banking System

Sub-project A: Payment Gateway

Core business

Account management, double-entry bookkeeping

Interbank transfers, ISO 20022 messages

Hardest problem

Race conditions & data integrity

Distributed state & failure handling (Saga)

Consistency model

Strong consistency (ACID + DB locks)

Eventual consistency (Saga Orchestration)

Batch processing

—

EOD settlement with Spring Batch (chunk-oriented)

Security

Spring Security (Phase 3)

Banking & Fintech SystemsCore Banking & Interbank Payment Gateway