Rebuilding a Fintech Ledger While Live Money Kept Moving

The Challenge

The client is a B2B cross-border payments company. Freelancers, e-commerce sellers and agencies receive payouts from 13+ international platforms through virtual accounts, convert the funds and withdraw to local banks. Four legal entities run the business, and five licensed institutions hold the actual money. After years of growth, the in-house ledger could no longer be trusted as the source of truth, and finance could not certify balances by entity.

• 43,236 wash journals from a flawed 48-hour hold mechanism, posting offsetting entries that netted to zero and destroyed hold tracking
• 18,825 orphan entries with no valid journal or chart-of-accounts reference
• One institution’s withdrawal flow producing journals that did not match the real movement of money
• Debit-equals-credit checked only in application code
• 148 days of end-of-day snapshots missing or never locked, with a race-prone period close
• Institution statements matched by hand in spreadsheets

Stop, Clean, Guard

Nexora engineers have run the rebuild since March 2026 as 19 feature workstreams in a milestone-gated program. The client reviews and signs off each milestone before the next phase starts. The order of work matters: stop new damage first, repair the history second, and only then make the same failures impossible.

• Stop: root-caused and fixed the three recognition bugs creating bad postings, then deployed behind a 48 to 72 hour verification gate. The exit criterion was zero new orphan or wash entries.
• Clean: remediated all 18,825 orphan entries and 43,236 wash journals, backfilled and locked 148 days of snapshots, and rebuilt the snapshot engine with T+1 period locking.
• Guard: enforced double-entry and balance invariants as database constraints, added a CI invariant test suite, alerting on any rejected posting and chart-of-accounts governance.

The Rebuilt Core

The new platform is hub and spoke. The ledger sits at the center and each external institution connects as a spoke. Journals are immutable and multi-leg, and corrections happen only through linked reversal entries. A new legal entity or institution is onboarded by configuration, not by a schema change.

• Posting-rule engine that resolves transaction type to accounting treatment through rules instead of code
• Real-time webhook plus T+1 statement ingestion from all five institutions, each statement format normalized into one canonical feed, with idempotency so a retry cannot double-count
• Disbursements with instant wallet debit, maker-checker enforced at the posting layer and automatic splitting of large orders to meet regulatory limits
• Intercompany float transfers gated on CFO or CEO approval
• Native USD and VND ledger branches running in parallel with no implicit conversion
• Query and export APIs, manual journals with enforced approval, a full audit trail and dashboards for reconciliation and cash position

Engineering Details

Reconciliation compares the ledger against each institution’s statement and applies a three-tier variance gate: under 0.1% passes, 0.1% to 1% raises a warning, and above 1% blocks. Delivery was built for risk-averse finance stakeholders. All remediation counts were quantified up front and countersigned on day one, so every before-and-after claim can be audited. Every production-mutating change gets a client reviewer and an independent engineering reviewer, a database backup beforehand and a documented rollback.

• Maker is never checker, enforced at the posting layer with actor-level audit logging on every production mutation
• Interim and final audit reports measured against the signed baseline
• Runbooks and structured handover included in the scope

Results

Each result below is measured against the baseline the client signed at the start. The original failure modes cannot recur silently, because correctness now lives in the database and CI instead of in application code.

• Ledger correctness: from app-code checks to database constraints plus CI
• Hold tracking: from wash journals netting to zero to true hold and escrow accounting
• Reconciliation: from manual spreadsheets to statement-driven, variance-gated and monitored
• Period close: from race-prone with 148 days unlocked to an end-of-day snapshot engine with T+1 lock
• Group cash visibility: from fragmented per institution to a single trusted book by entity and institution

Tech Stack

The ledger stays on the client’s existing Go, PostgreSQL and Kafka stack. The team did not replatform. It tightened the data layer, replaced the posting logic and added the integration and monitoring that a book of record needs.

Why It Matters

The same problems show up wherever one platform holds customer funds at outside institutions: payment factories, shared-service payment hubs, marketplaces and wallet platforms. A four-engineer, senior-led team with AI assistance and strict review is delivering this work. Detailed architecture and audit evidence are available on request under NDA.