Retail banking back office

Payments & Transfers

Every money movement in this module is an integer-cent, double-entry posting: balanced debit/credit pairs written in one transaction, with account balances derived from those postings rather than stored as a mutable field.

Available now

Internal (book) transfersMove money between two on-platform accounts. Posts a balanced debit/credit pair immediately and returns a synchronous posted-or-rejected outcome, idempotent on the client payment reference.
Payment history & statusEvery captured payment with its live lifecycle status — initiated, validated, held, posted, pending settlement, settled, returned, failed or rejected. Filter by status, date range, account, type and amount, search on reference or payee, and open a payment for its postings and full status timeline.
Batch clearing — SIMULATED schemeACH-style batch payments cleared by this module's own deterministic settlement engine — an explicit SIMULATION, never a connection to a real scheme, and labelled as such on every screen and record. Entries validate as usual and then post immediately as balanced pairs debiting the customer and crediting an internal scheme-settlement suspense account, leaving each payment pending settlement until its configured settlement lag elapses. Batches carry an identifier, created timestamp, item count, total value and status, and drill down to every entry with its own live status.
High-value wires — dual-control releaseWire-style high-value instructions captured with their full detail set: debit account, beneficiary name and address, beneficiary account and routing identifiers, correspondent and intermediary bank fields, purpose of payment, charges handling and free-text remittance information, with required fields enforced per instruction type. Capturing posts nothing — the wire waits for a SECOND, DIFFERENT staff user with release authority, who sees the whole instruction, the validation result and the sanctions screening and approves or rejects it with a mandatory note. The capturing user can never approve their own wire, and a refused attempt is recorded permanently. On approval the wire posts a balanced pair and settles through the same clearly-labelled SIMULATED adapter as the batches.
Standing orders & scheduled paymentsRecurring instructions — create, view, amend, pause, resume and cancel — with the schedule the frequency and start date actually produce shown before you commit. A standing order holds no money: a background job runs the due dates, posts a balanced pair for each, retries an insufficient-funds failure on the next cycle with a customer notification record, and is idempotent per order per due date so running the sweep twice can never double-pay.
Bulk payment files — per-item validationUpload a CSV of payment instructions for one customer and every row is validated independently: schema and required columns, positive integer-cent amounts, a source account that belongs to the customer, an existing and verified payee, sufficient aggregate funds across the whole file, and the per-payment and period limits. Each item ends accepted or rejected with a specific named reason, and the file carries a validation summary — total items, accepted count and value, rejected count and value, and the breakdown of rejection reasons — with a filterable drill-down and a downloadable CSV error report. A malformed file is refused as a whole with a clear parse error, never partially imported, and uploading moves no money: nothing posts until a second, different authorised user approves the file.
Exceptions desk — the operations queueOne queue for every payment exception: scheme returns, failed standing orders, quarantined bulk items and sanctions holds. Cases are raised automatically by the engines that produce them, carry their type, source payment or order, customer, account, amount, reason code and description, and walk open → assigned → resolved with role-gated transitions — only an authorised operations user may assign or resolve, a case can never skip assignment, and it can never be closed without a written resolution note. Filter by type, state, assignee, customer and reason, sort the queue, and read the aging derived from each case's creation date — under a day, 1–3, 3–7 and over 7 days — with the oldest work emphasised and a summary of open cases by type and bucket. Duplicate detection links a repeat exception (same source payment, or same customer, amount and reason within a short window) to the case already open rather than filing unrelated work, and every case carries its full activity trail.
Payees & confirmation of payeeAdd, verify and remove the beneficiaries saved against a customer. Adding a payee runs a confirmation-of-payee name check against the registered account holder name — exact, close-but-not-exact (which names the holder and needs an explicit confirmation) or no match (blocked without a recorded override) — and warns on duplicate account identifiers or near-identical names. Removal is a soft removal so payment history survives.
Compliance review — sanctions holdsEvery outbound payment is screened before release against a SEEDED SAMPLE watchlist (OFAC/EU-style entities, individuals, vessels, jurisdictions and name variants — clearly disclosed as sample data, not a live feed). Payee, counterparty and correspondent details are matched normalised and fuzzy, so variants and near-spellings are caught; a match records the matched entry and score and holds the payment, which then posts nothing. Only a compliance-role user other than the initiator can release it with a note or reject it with a reason, and both are recorded on the audit trail.
Background job run historyEvery run of every declared job — the standing-order sweep and the simulated batch settlement engine — with what it examined, executed, settled, returned, skipped, paused and notified, whether the platform's scheduler or an operator triggered it, and any error. A second run over the same due work shows honestly as skipped rather than having to be inferred.
Per-customer payment limitsConfigure the per-transaction maximum and the cumulative daily and monthly caps for a customer, all in integer cents, and see how much of each period has been used, what allowance remains and when the period resets. Limits are enforced at release: a breach refuses the payment before anything posts, naming the limit, its value, the amount already used and what was left.
High-value step-up authorizationAbove a configurable amount threshold a payment is held and posts nothing until the user who initiated it re-confirms it with their own personal approval code. Administrators set the threshold, the number of wrong attempts tolerated and how long a code is locked out; the threshold in force is shown on the capture form, and every confirmation attempt — right or wrong — is recorded against the payment with the user and the moment.
Simulated clearing scheme settingsThe whole behaviour of the batch-clearing SIMULATION, in two numbers: the settlement lag a posted entry waits in the suspense account, and the share of posted entries the simulation returns with an R-code style reason instead of settling. Both are administrator-only and audited, the selection of returned entries is deterministic rather than random, and the screen states in full exactly what the simulation does and what it emphatically is not.
Your personal approval codeSet and rotate the approval code the step-up gate asks for on a high-value payment. The code is never stored: only a salted scrypt hash is kept, compared with a timing-safe check, and it is never logged, shown or returned by an API. Rotating needs the current code; an administrator can reset a forgotten or locked-out code without ever learning the old one.

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.