Capture a high-value wire
Simulated wireCapture the full instruction — debit account, beneficiary name and address, beneficiary account and routing identifiers, correspondent and intermediary bank fields, purpose of payment, charges handling and remittance information. Required fields differ by instruction type and are named individually below. Capturing posts nothing: the wire waits for a second, different staff user with release authority.
SIMULATED high-value settlement — this module's own settlement engine, not a real wire network
High-value wire instructions in this module settle through an INTERNAL SIMULATION, not through a real wire network. There is no SWIFT, Fedwire, CHAPS or TARGET2 connection, no correspondent or intermediary bank is contacted, no MT103 or pacs.008 message is produced or transmitted, and nothing recorded here has any effect outside this database. The correspondent, intermediary and routing fields captured on a wire are held as instruction data and screened against the seeded sample sanctions watchlist; they are never used to address anybody. On approval the wire posts as a balanced pair — debiting the ordering customer and crediting an internal scheme-settlement suspense account — and is marked pending settlement until the configured settlement lag elapses, at which point the same deterministic settlement job moves the suspense balance to the internal scheme-clearing position and the payment becomes settled. Every wire record stores the adapter identifier and a simulated flag so a stored record can never be mistaken for real wire traffic.
What dual control enforces here
- The MAKER captures the wire with its full detail set — debit account, beneficiary name and address, beneficiary account and routing identifiers, correspondent/intermediary bank fields, purpose of payment, charges handling and free-text remittance information. Required fields are enforced per instruction type.
- The captured wire is put through exactly the same pre-release validation gate as every other payment (positive whole-cent amount, account state, available funds, per-customer limits, payee state) and screened against the seeded sample sanctions watchlist. Nothing posts at capture: the wire is recorded as awaiting approval.
- A SECOND, DIFFERENT staff user with release authority reviews the full instruction, the validation result and the screening result, and either approves or rejects it. Both decisions need a mandatory note and are recorded with the acting user and the moment.
- The capturing user can never approve their own wire. An attempt is refused with a clear message and the refused attempt is itself recorded on the wire's decision trail.
- On approval the wire posts a balanced debit/credit pair and moves to pending settlement; the scheduled settlement job settles it after the configured lag, through the same SIMULATED adapter and disclosed the same way. A rejected wire is terminal and posts nothing, ever.
adapter: internal-simulated-wire.v1 · simulated: true · no wire-network connection exists
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.