Bulk payment files

A business bulk file is a CSV of payment instructions uploaded on behalf of one customer. The file is parsed and every row is validated independently — schema and required columns, a positive whole-cent amount, 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 with a verdict of accepted or rejected and a specific reason.

Uploading moves no money: an accepted item is a validated instruction. Nothing posts until a second, different authorised user reviews the validation summary and approves the file — and the uploader can never be that user.

Awaiting approval

No validated file is waiting for a checker.

Executed

Approved by a checker; accepted items executed as balanced postings.

Rejected by a checker

Terminal: nothing was posted and nothing will be.

Parse failures

Files that could not be read as CSV. Nothing was imported — not even the rows before the problem.

Upload a bulk payment file

The whole file either parses or it does not: a malformed file is refused as a file and recorded with its parse error and zero items, rather than partially imported. When it parses, a bad row never stops the rows after it — every row is assessed and gets its own named reason.

Customer the file is uploaded for

1 account and 1 verified payee. Every row must debit one of this customer's own accounts and pay one of its verified payees.

Staff user uploading the file

Recorded as the file's uploader. Under maker-checker control this user can never be the one who approves the file.

CSV file

Up to 2048 KB and 5000 instruction rows. The file is read in the browser and sent as text.

Filename recorded against the upload

Instruction rows

The header row must name "reference", "source_account", "payee", "amount", "description" in any order.

File format — the five required columns

reference: Unique payment reference for the row — 3–64 characters of letters, digits and . _ : / - . It is the item's idempotency key.
source_account: Account number to debit. Must belong to the customer the file is uploaded for.
payee: The payee to pay: its saved payee id, or the account identifier it is registered on. The payee must exist for this customer and be VERIFIED.
amount: Amount in major units with at most two decimals, e.g. 1250.00. Never zero or negative.
description: What the payment is for — carried onto the payment row.

Quoted fields, embedded commas, doubled quotes, CRLF endings and a UTF-8 byte-order mark are all handled. A file that cannot be parsed is refused as a whole — never partially imported.

reference,source_account,payee,amount,description
BULK-2024-0001,GB-1000-0001,GB-1000-0003,250.00,Invoice 4471

Not polling: nothing on screen can change status any more. Showing state as of 2026-08-19 05:51:33 UTC.

No bulk payment file matches this view. Upload one above to see it here with its filename, uploader, upload time, item count, total value and status.

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.