Stand-In Ledger (SIL)
What it is​
The Stand-In Ledger is a local, offline-safe ledger that lets the bank keep transacting while the Core Banking System (CBS) is unavailable (scheduled maintenance, network outage, vendor downtime, etc.).
Every transaction posted to SIL is recorded as a double-entry with full audit, idempotency and retry semantics. When the CBS is back online, a background worker automatically replays the pending transactions to core in the order they were posted.
The feature is known to the business as SIL (Stand-In Ledger). In code
and APIs the prefix SIT is used (Stand-In Transactions). The two names
refer to the same module.
Why it exists​
| Without SIL | With SIL |
|---|---|
| Tellers must turn customers away when CBS is down | Tellers continue serving customers |
| Reconciliation is manual after every outage | Replay is automatic and idempotent |
| No audit trail for offline activity | Every leg, idempotency key and retry attempt is persisted |
| Risk of double-postings on retry | Idempotency keys + transaction references prevent duplicates |
| Balance drift between branch and core | LastCoreSyncBalance + LastCoreSyncAt make drift visible |
Module surface​
The SIL module exposes commands grouped into five areas:
| Area | Commands | Doc |
|---|---|---|
| Account & customer lookup | Search account, get balance, list accounts, list customers, mandate search | Account Management |
| Account state | Block, Unblock, Sync from core | Account Management |
| Financial transactions | Deposit, Withdrawal, Transfer, Loan Repayment, Reverse | Transactions |
| Approval workflow | Approve, Reject | Approval Workflow |
| Sync & replay | Sync transaction, Sync account, Hosted worker | Sync and Replay |
| Test data | Seed customers + accounts | Seed Test Data |
For the underlying state machine and the rules every command must obey, read Account States and Rules first.
Command dispatch​
All SIL commands are dispatched through the standard BankLingo command endpoint:
POST /api/cmd
Content-Type: application/json
Authorization: Bearer <token>
{
"cmd": "SITDepositToTillCommand",
"data": { ... }
}
The response shape is the BankLingo standard CommandExecutionResponse:
{
"isSuccessful": true,
"statusCode": "00",
"message": "Posted to SIT.",
"data": { ... }
}
Status codes follow the platform convention: 00 = success, 400 = bad
request, 404 = not found, 409 = state conflict (e.g. account frozen),
503 = core banking unreachable.