Credit unions & community banks
The problem: joining an instant rail means posting every payment in real time, all day, every day — on a core that books in batches and has maintenance windows. Replacing the core is a multi-year programme.
What changes: TulaDB posts in front of the core. Every payment updates one balance the moment it posts, so the balance your channels read is never waiting on the batch. A resent message never posts twice; a hold for one rail stops the same money leaving on another; your core is updated from the ledger's history through a feed built with you.
Shipped: engine and export. Not yet: rail adapter, core connector. Read the argument → · The proof →
Sponsor banks & aggregators
The problem: giving smaller institutions access to a rail means carrying their liquidity risk. One client can consume the liquidity posted for all of them, and exposure is usually learned from a report.
What changes: each client gets its own account with a net debit cap the ledger enforces on every payment — changeable intraday in one call. The pooled account stays equal to the sum of client positions by double entry.
Recipe on shipped limits and holds; rail adapter not yet. Intraday liquidity → · FBO recipe → · The proof →
Payment providers & fintechs
The problem: payouts, collections and wallets run across several rails, each integration with its own view of the balance. Two rails approve against the same funds; finance reconciles each rail by hand.
What changes: one balance for every rail, checked in the same step as each write. Each rail keeps its own references and refusal codes, and reconciles separately — one search in the engine, one filter in the lake.
Shipped in the engine; rail adapters not yet. One balance across every rail → · The proof →
Bank treasury & payments operations
The problem: on an instant rail, by the time a report says the settlement position is low, the payments that made it low have settled. Known obligations get eaten by the stream; monitoring evidence is assembled after the fact.
What changes: the position is an account with a floor no payment can cross, known obligations are held aside with automatic expiry, and the full intraday curve comes out of the Iceberg export as one query.
Recipe on shipped limits and holds; the intraday curve is an opt-in export. Not yet: alerts, forecasts, sweeps, queueing. · The proof →
Payment-hub vendors & integrators
The problem: every hub carries a memo-posting store that has to be perfect under retries and failover, and every client asks for multi-rail balances and liquidity controls on top of it.
What changes: run a ledger under your hub whose behaviour through node kills, partitions and crashes is published with its evidence, and ship balances, holds, caps and refusals as its features rather than your code.
Shipped in the engine; the integration is yours. Not yet: per-tenant isolation inside one cluster (run a cluster per client). Embedding TulaDB in a product you sell needs an OEM agreement. The evidence → · The proof →
Switch & scheme operators
The problem: every participant's position must be exact through any failure, retry storms must settle once, and refusals belong in the settlement record.
What changes: participant positions under double entry, net debit caps per participant, reference-keyed deduplication, and refusals as durable records with the scheme's own code.
Shipped in the engine; scheme adapter not yet. Payment switch recipe → · The proof →