Money Movement and Ledger Simulator
A reference implementation for holds, releases, settlements, reversals, and double-entry balance logic.
A portfolio system focused on the difficult parts of financial correctness: holds, releases, reversals, settlements, pending balances, traceability, and failure recovery across distributed services.
Project context
This is a portfolio reference implementation built to demonstrate financial-systems rigor, not a description of employer production work. It is intentionally not blockchain-flavored; it is a backend ledger and transaction state engine designed to mirror the kinds of internal financial primitives that power wallet balances, account movements, reserve holds, and settlement reconciliation in real products.
Ledger guarantees
Double-entry
Balance views
Available plus pending
Event integrity
Outbox pattern
Role and positioning
Domain modeling, architecture, integrity controls, operator workflows
Useful proof for fintech, core banking, treasury platform, and distributed systems roles where correctness matters as much as scale.
Money movement systems need more than a balance column and a transfer endpoint. They need traceable postings, pending states, reversals, settlement windows, and the ability to reconstruct how a balance was derived even after asynchronous workflows and service failures.
The challenge here was to model a distributed system that preserves financial integrity while still allowing independent services to react to ledger events, update read models, and drive operational workflows.
I designed the system around a posting engine that writes immutable ledger entries and enforces double-entry rules before emitting events. Account balance projections are derived rather than directly mutated, which keeps auditability strong and failure recovery tractable.
Pending and available balances are treated separately so the system can represent authorization holds, settlement completion, release flows, and reversals without losing the underlying accounting trail.
The eventing model uses an outbox pattern so downstream consumers receive balance-affecting events reliably without creating hidden coupling between the ledger core and administrative or reporting surfaces.
Structured to separate core domain responsibility from provider or workflow-specific complexity.
The system keeps financial correctness in the ledger core while allowing read models, reporting, and operator experiences to evolve from event streams instead of fragile synchronous coupling.
Illustrative wallet position
double-entrySample available
$ 124,880.43
Sample pending
$ 18,430.12
Hold
Card authorization reserved funds
Settlement
Posting confirmed to clearing account
Projection
Balance view caught up after replay
Illustrative event lineage
movement.created
sample-transfer-91eea2ledger.posted
sample-journal-2041projection.updated
sample-wallet-e4a8settlement.completed
sample-batch-2026-03-21Wallet and Movement API
Accepts transfer commands, hold requests, settlement events, and reversal actions through a deliberately narrow command model.
Ledger Posting Engine
Validates journal rules, writes immutable postings, enforces referential traceability, and triggers outbox events inside the same transaction boundary.
Balance Projection Service
Builds available and pending balance views from the event stream so reads stay fast without weakening the source of truth.
Settlement and Recovery Workers
Process asynchronous settlement steps, detect stalled commands, and keep failure handling visible to operators.
Admin and Observability Surface
Provides role-based investigation tools, event lineage, projection lag visibility, and operational metrics.
Immutable postings over mutable balances
Mutable balance updates are tempting, but immutable journals provide better auditability and make recovery and replay possible.
Derived read models for performance
Fast balance reads come from projections, not shortcuts in the core ledger, which keeps integrity and operational performance aligned.
Explicit state engine for money movement
Transfers move through commanded states such as held, settled, released, or reversed so downstream services can reason about intent as well as postings.
Features and operational views that make the reference implementation feel credible beyond the API layer.
The point is to show backend depth alongside the operator-facing surfaces real teams need in order to diagnose and run a system well.
Double-entry ledger core
Every balance-affecting movement is recorded as immutable debit and credit postings with referenceable journal metadata.
Pending versus available balances
Supports authorization holds, settlement capture, release flows, and reversal scenarios without compromising traceability.
Event-driven consistency
Publishes posting events for downstream consumers while keeping the ledger write path transactionally safe through an outbox design.
Operational controls
Includes role-aware admin screens for investigating transfers, reviewing holds, and understanding failed settlement flows.
Observability and failure testing
Exposes metrics for posting throughput, lagging consumers, stale projections, and recovery scenarios under downstream failure.
Wallet operations board
Live account positions with available versus pending balance breakdown and alerts for stale projections.
Transfer investigation panel
A detailed journal and state lineage view for a single transfer including holds, releases, and settlement events.
Failure simulation monitor
Operational tooling for lagging consumers, replay actions, and outbox backlog visibility.
- A strict ledger model is more verbose than direct balance mutation, but it is substantially safer for correctness-sensitive systems.
- Derived projections create eventual consistency for reads, which is a deliberate compromise in exchange for stronger source-of-truth guarantees and decoupled downstream processing.
- The system exposes more domain concepts up front, but that clarity is useful in financial products where ambiguity becomes risk very quickly.
- Demonstrates mature understanding of financial consistency without leaning on blockchain tropes or unnecessary complexity.
- Shows how event-driven design can coexist with transactional integrity when the write path is modeled carefully.
- Signals strong fit for roles involving wallets, balances, settlements, treasury workflows, or reliability-critical backend platforms.
- Add configurable account hierarchies for internal reserve and fee accounts.
- Introduce scenario-based load testing for high-volume posting bursts and delayed projection recovery.
- Add compliance-oriented export formats for finance and audit stakeholders.
- services/ledger-core for posting rules and journal persistence
- services/balance-projections for read-model updates and balance queries
- services/movement-api for transfer command intake and state transitions
- apps/admin-console for role-based operational workflows
- platform/observability for dashboards, alerts, and local telemetry wiring