Internal (book) transfer
Moves money between two on-platform accounts by posting a balanced debit/credit pair to the ledger. Amounts are integer cents; balances are derived from postings and never stored as a mutable field. The payment reference is the idempotency key — submitting it twice returns the original result. An instruction may be released against a saved payee, in which case the payee must exist, be verified, not be removed, belong to the paying customer and be registered on the credited account.
Every submission runs the same pre-release validation gate before anything posts: payee exists and is verified, the amount is a positive whole number of cents, the source account has sufficient available funds, the payment is within the paying customer's configured per-transaction maximum and cumulative daily and monthly caps, and the fields this payment type requires are present. Each failed check is returned with its own named reason code — all of them, not just the first — and either refuses the payment outright or holds it for a decision. A held payment never posts while it is held.
The same gate applies the HIGH-VALUE STEP-UP rule — at USD 50,000.00 or more: the payment is captured and held, and only the initiating user can release it, by re-confirming it with their own personal approval code. The threshold is shown on the form below and is configurable by an administrator.
The gate also SCREENS the payee name, the counterparty (registered account holder) details and the correspondent bank details against the watchlist — normalised and fuzzy, so name variants and near-spellings are caught. A match records the matched entry, the matched name and the score and holds the payment for a compliance decision; nothing posts while it is held.
Seeded sample dataset — not a live sanctions feed
Sanctions screening in this module runs against a SEEDED SAMPLE DATASET created for demonstration. It is shaped like an OFAC SDN / EU consolidated list — individuals, entities, vessels and jurisdictions with alias name variants — but it is not a live sanctions feed, is never refreshed from an authority, and has no regulatory meaning. Named individuals, entities and vessels are fictional.
A production deployment would replace this table with an ingested feed from the relevant authority. Nothing shown here should be relied on as a sanctions determination.
Sample datasetScreening compares each instruction with 20 watchlist records, 41 name variants across 12 sample programmes.
Synchronous outcome
No payment submitted yet. Every submission runs the pre-release validation gate — payee, amount, funds, limits, sanctions screening, the high-value step-up threshold and the fields this payment type requires — and returns either a posted confirmation with its postings and both new balances, or every failed check with its reason code.
Recent payments on this book
Full payment history →No payments have been submitted yet.
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.