Hierarchical accounts: the data model under a wallet.
Customer subaccounts, blocked amounts, treasury depth.
Why a wallet is not a bank account
The user sees a balance. Behind that balance is a structure that most wallet engineers discover they should have designed differently at the worst possible moment — usually when they are trying to explain to an auditor why two ledgers don't agree.
A wallet balance in Coreal is the sum of a hierarchy of subaccounts, each with its own currency, blocked-amount set, and posting rules. The hierarchy lets you model the real structure of a financial product: a customer has an available balance, a blocked-for-card-auth amount, a savings pocket, and a pending-withdrawal amount. Each is a subaccount. Each has its own balance history. The sum is what the customer sees.
The blocking problem
Card authorisations block funds before they settle. A customer with €100 who authorises a €30 card payment has €70 available and €30 blocked. If they try to withdraw €80, the system should decline. If the authorisation expires (most do, after 7–30 days depending on scheme), the €30 should unblock.
This sounds simple. It becomes complex when you have multiple concurrent authorisations, partial captures, reversals, and chargebacks. The naive approach — a single balance field in a database — breaks immediately when two authorisations arrive simultaneously. The correct approach is a ledger with posting semantics: each authorisation creates a blocking entry, each capture creates a settlement entry, each reversal creates a reversal entry. The balance is always the sum of posted entries.
Treasury depth
The hierarchy extends upward, not just downward. Customer subaccounts roll up to pool accounts (e.g., all EUR balances for a market), which roll up to treasury accounts (the funds held at the partner bank), which roll up to the safeguarding account (the ring-fenced EU EMI requirement). The same posting model that governs customer transactions governs treasury movement.
This means reconciliation is not a separate process. It is the natural output of the ledger: the sum of all customer subaccounts must equal the treasury account balance, which must equal the safeguarding balance. If it doesn't, something is wrong — and the ledger's audit trail tells you exactly where.