ISO-style references
35-character financial references for ISO 20022-oriented systems, derived compactly with SHA3-256 and Base62 encoding.
The platform
The financial-state runtime, part by part.
TulaDB brings ledger semantics close to the write path. Balanced mutations, idempotency, the reservation lifecycle, rejected outcomes, deterministic ordering, and replayable recovery are treated as core system concerns — not conventions your services have to remember.
- Integer amounts
- Deterministic ledger mutation by default
- Two reference modes
- ISO-style or full SHA3-256 digest
- 2-phase value
- Reserve, commit, rollback, reject
- WAL-backed
- Restart and replay review
Double-entry core
Value moves in balanced pairs, or it doesn't move.
Every mutation is an atomic pair: a debit and its matching credit, applied under account-level sequencing. Posted and pending balances are tracked distinctly, account limits are enforced in the core, and duplicate operations resolve deterministically rather than double-applying.
Invariant: across any consistent read, the sum of debits equals the sum of credits. The balance isn't reconciled after the fact — it's a property of the write.
Atomic debit & credit
Both legs post together or not at all — no half-applied transfers.
Posted vs. pending balances
Available balance reflects holds; posted balance reflects settled value.
Account-level sequencing
Deterministic ordering per account keeps concurrent activity explainable.
Enforced account limits
Limit checks live in the core, not in whichever service happened to write.
Reservation lifecycle
Holds are a state, not a flag.
A reserve holds the debit side without posting the credit. A commit releases the hold and posts the credit. A rollback releases the hold and posts nothing. Each transition is a durable, ordered outcome — so a hold can never quietly leak into an unbalanced state.
TransitionDebit sideCredit sideOutcomeGuarantee
reservehold placednot postedPENDINGAvailable balance drops; posted balance unchanged
commithold releasedpostedPOSTEDExactly one settlement, idempotent under retry
rollbackhold releasednoneVOIDEDFunds return to available; trail preserved
rejectunchangedunchangedREJECTEDDurable record of the declined decision
RequestEffect
transfer · op-id 7f3a…
First delivery
transfer · op-id 7f3a…
Retry after timeout
transfer · op-id 7f3a…
Duplicate from queue
One operation identity → one financial effect, however many times it arrives.
Idempotency
A retry is not a second transaction.
Durable operation identity makes retries safe. The same stable caller identity returns the same outcome instead of creating duplicate effects — so timeouts, at-least-once queues, and client retries don't turn into double charges or phantom credits.
Deterministic duplicate checks can derive financial identity from source reference, currency, and source identifier — using SHA3-256 with Base62 encoding for compact references, or the full digest when that mode is selected.
Reference & amount modes
Identity and value follow explicit ledger policy.
TulaDB supports two reference-identity modes and deterministic amount handling. Payment-message standards stay at the integration edge; the resulting financial state stays deterministic, balanced, and recoverable in the core.
Full SHA3-256 digest
Digest-native reference identity when a deployment prefers the full SHA3-256 digest as the reference form.
Integer amounts
Amounts are stored as integers by default for deterministic ledger mutation and exact arithmetic.
Currency-scaled amounts
With ISO 20022 mode enabled, decimal interpretation follows currency-based scale policy, including 18,5 scale support where required.
Multi-tier value movement
Position and settlement movement can be applied atomically inside one ledger transaction.
Control-account funding
Funding and defunding seed or remove value while preserving double-entry correctness.
Positioning note: TulaDB can start with ISO 20022-compatible ledger semantics by default. It does not claim ISO 20022 certification, parse ISO messages in the core, or replace payment-network message validation.
Write path
Narrow to write, wide to read.
The mutation surface stays small and ordered. The read surface is broad and safe: balances, history, pending reservations, rejected records, and account search all come through a read-only path that never opens the ledger to mutation.
Validate
Request shaping and idempotency on a stable operation identity.
Order
Deterministic, account-level sequencing of the balanced mutation.
Persist
Durable, append-only outcome written ahead of acknowledgement.
Project
History, holds, and rejected records surfaced to the read path.
Accounting kernel vs. ledger system
How much of the ledger do you want to build yourself?
If you need the fastest possible double-entry atom and your team will build the reservation lifecycle, deduplication, rejected-record visibility, and settlement coordination above it, a minimal accounting kernel can be the right choice.
TulaDB is for teams that want those responsibilities built, tested, and owned below the application — closer to the financial state itself.
Minimal kernel
You own the lifecycle
A small accounting primitive; your services own lifecycle state, retries, reconciliation visibility, settlement choreography, and operational tooling.
TulaDB
The runtime owns the lifecycle
Holds, commits, rollbacks, rejected outcomes, deterministic duplicate checks, and atomic position-plus-settlement updates are part of the runtime contract.
Scope boundary
What TulaDB owns — and what stays above it.
TulaDB is not a payment switch, ISO 20022 parser, fraud engine, compliance workflow, or customer orchestration system. Those stay above the ledger. TulaDB owns deterministic financial state: balances, holds, postings, rejected outcomes, idempotency, and recovery.
Not a message parser
Payment and ISO message handling stay at the integration edge; the ledger receives validated financial intent.
Not workflow orchestration
Customer journeys, compliance flows, routing, and approvals stay in application services above the core.
A financial-state runtime
Durable balances, holds, postings, rejected records, deterministic retries, and recovery evidence.
Private preview
Evaluate the engine against your workload.
Review the write path, reservation lifecycle, idempotency, and recovery behavior with a controlled integration pilot.