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.

Naming

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, Cancel, queue listing	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.

Account state quick reference

Account state is a core part of SIL behavior, not a side topic. SIL mirrors the account status from core banking and enforces that status before any balance is touched.

Account state	What it means in practice
Active	Debit and credit operations are allowed, subject to balance and approval rules.
Dormant	No posting is allowed until the account is reactivated from core banking.
PostNoDebit	Credits are allowed, but withdrawals and source-leg transfers are blocked.
PostNoCredit	Debits are allowed, but deposits and receiving-leg transfers are blocked.
Frozen	All posting is blocked.
Closed	All posting is blocked.

Two rules matter for operators reading SIL responses:

1. Account state is checked before posting, so many 409 responses are state-rule failures rather than transport or validation errors.
2. Only SITBlockAccountCommand and SITUnblockAccountCommand change state locally in SIL; other state changes are mirrored from CBS through sync.

Use these pages together:

Need	Page
Full state machine and posting matrix	Account States and Rules
Enum values returned by the APIs	Enums Reference
How transaction statuses relate to account state during investigations	Transaction List

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.