Simulated clearing scheme settings
Simulated schemeThese two values are the whole behaviour of the batch-clearing simulation: how long a posted entry sits pending settlement in the suspense account, and what share of posted entries the simulation returns instead of settling. Changing them is restricted to administrators and written to the audit trail with the old and new values.
A change applies to the NEXT batch built. An entry already pending settlement keeps the lag that was stamped on it when its batch was built, so the rule that decided an entry and the rule recorded on it can never disagree. With no configured row the module defaults apply (1 h lag, 0‰ returns), so a lag is always in force.
SIMULATED clearing scheme — this module's own settlement engine, not a real scheme connection
Batch (ACH-style) payments in this module clear through an INTERNAL SIMULATION of a clearing scheme, not through a real one. There is no connection to ACH, Bacs, SEPA, FedACH or any other scheme, no file is exchanged with any counterparty, and nothing recorded here has any effect outside this database. The adapter is this module's own deterministic settlement engine: an outbound entry is validated and immediately posted as a balanced pair — debiting the customer account and crediting an internal scheme-settlement suspense account — and is then marked pending settlement until the configured settlement lag elapses, at which point the scheduled settlement job settles it or, at the configured simulated return rate, returns it with an R-code style reason. Every batch record stores the adapter identifier and a simulated flag so a stored record can never be mistaken for real scheme traffic.
Exactly what the simulation does
- An outbound entry passes exactly the same pre-release validation gate as any other payment: required fields, positive whole-cent amount, available funds, per-customer limits, payee state, sanctions screening and high-value step-up.
- On passing, it posts IMMEDIATELY as a balanced pair — DEBIT the customer account, CREDIT the internal scheme-settlement suspense account — and the payment moves to pending settlement.
- Each entry carries the settlement lag configured at the moment its batch was built, and the exact instant its simulated settlement becomes due.
- When that instant passes, the scheduled settlement job settles the entry by moving the suspense balance to the internal scheme-clearing position with a balanced pair; at the configured simulated return rate it is instead returned with an R-code style reason and reversed by an equal-and-opposite compensating posting, which also opens a case in the exceptions queue.
- No file, message or instruction is sent anywhere. Nothing outside this database is affected at any point.
adapter: internal-simulated-clearing.v1 · simulated: true · no real scheme connection exists
Settings in force
Module default- Settlement lag
- 1 h
- 60 minutes
- Simulated return rate
- 0‰
- 0‰ — no entry is ever returned by the simulation
- Settlement suspense account
- CTRL-SCHEME-001
- USD 0.00 held
- Pending settlement
- 0
- USD 0.00 of value, 0 already due
Never configured — the module defaults are in force.
adapter internal-simulated-clearing.v1 · simulated: true
Change the settings
The lag is whole minutes; the return rate is whole per-mille. Neither value is a guess at real scheme timings — they are the parameters of a demonstration engine, and the simulation says so wherever it appears.
R-code style reasons the simulation can produce
When the simulation returns an entry it picks one of these reasons deterministically from the entry's own payment reference — so the same entry always gets the same reason, and a returned entry is reversed by an equal-and-opposite compensating posting rather than by deleting history. These codes imitate the vocabulary of ACH return reasons; they are not issued by any scheme.
- R01Insufficient funds (beneficiary side)
The simulated receiving institution reports that the account could not be credited for want of funds on its side.
- R02Account closed
The simulated receiving institution reports the beneficiary account as closed.
- R03No account / unable to locate account
The simulated receiving institution cannot match the beneficiary account identifier.
- R04Invalid account number structure
The beneficiary account identifier fails the simulated scheme's structural check.
- R05Unauthorised debit — no valid authorisation held
The simulated receiving institution reports that no valid authorisation is held for this debit, so the item is returned as unauthorised.
- R08Payment stopped
A stop instruction is recorded against the item at the simulated receiver.
- R16Account frozen
The simulated receiving institution reports the beneficiary account as frozen.
Sample book disclosure: the customer accounts, staff users and sanctions watchlist in this environment are seeded demonstration data created by this module — there is no connection to a real core banking system, payment scheme or sanctions feed. Batch (ACH-style) clearing and high-value wire settlement both run through this module's own SIMULATED settlement engine, never a real scheme or wire network.