The Immutable State Engine
Financial truth demands double-entry invariants. We enforce strict serializability across high-volume transaction loads. No UPDATE statements. No DELETE statements. Every ledger transition is append-only.
Your product domain layer should not calculate account balances. The ledger exposes deterministic primitives: Accounts, Transfers, and Balances.
General-purpose databases fail under financial load. They suffer from lock contention and mutable balances that drift between reconciliation cycles.
Fernel provides a purpose-built OLTP engine. Double-entry invariants execute at the engine level. It rejects malformed states synchronously.
What the Ledger Does
Double-Entry Invariants
Every transfer debits one account and credits another. Balance integrity enforced by the engine. Overdrafts and double-spends are structurally impossible.
Real-Time Balances
Account balances are always current. No batch recalculation, no stale reads. Query any account at any time and get the authoritative balance.
Multi-Currency Native
Each account operates in a single currency (ISO 4217). FX operations are explicit transfers between currency ledgers with full rate audit trail.
Immutable Append-Only
No UPDATE, no DELETE. Every entry is permanent. Corrections are recorded as new entries (Stornobuchung), preserving the complete history.
Multi-Tenant Isolation
Tenant context is embedded in every ledger operation. Data segregation enforced at the infrastructure level, not in application logic.
Predictable Performance
Static memory allocation, zero garbage collection, zero deserialization overhead. Throughput scales with batch size, not inversely with contention.
Where the Ledger Sits
The ledger engine sits at the foundation. All writes are mediated through the finance service and the workflow engine. The ledger is never accessed directly by external clients.
Try It
# Create a multi-currency wallet
curl -X POST https://connect.fernel.io/v1/wallets \
-H "Authorization: Bearer <token>" \
-H "Content-Type: application/json" \
-d '{
"customer_id": "cust_8f3a2b",
"currencies": ["EUR", "USD", "GBP"],
"type": "customer_emoney"
}'
# Response
{
"id": "w_a1b2c3d4",
"accounts": [
{ "currency": "EUR", "iban": "DE89...", "balance": "0.00" },
{ "currency": "USD", "account_number": "...", "balance": "0.00" },
{ "currency": "GBP", "sort_code": "...", "balance": "0.00" }
],
"status": "active",
"created_at": "2026-02-21T09:00:00Z"
}Technical Specifications
| Accounting model | Double-entry, strict serializability |
| Currencies | Any ISO 4217 code (EUR, USD, GBP, BRL, etc.) |
| Account types | Customer e-money, safeguarding, fee, revenue, suspense, write-off |
| Balance model | Debits posted, credits posted, debits pending, credits pending |
| Immutability | Append-only. No UPDATE or DELETE on ledger entries. |
| Idempotency | Protocol-level deduplication (128-bit transfer ID) |
| Durability | Replicated write-ahead log, 128-bit end-to-end checksums |
| Batch processing | Thousands of transfers per batch, zero lock contention |
Build on a Ledger That Never Drifts.
Talk to our team about your ledger requirements. No sales pitch, real architecture conversation.