Set up a standing order

A standing order is validated with exactly the same rules as a one-off payment: the payee must exist, be VERIFIED, be unremoved, belong to the paying customer and be registered on the account that will be credited; the amount must be a positive whole number of cents within the customer's per-transaction maximum. Anything that would fail on every due date refuses the set-up with its named reason code.

Two things WARN rather than refuse, because a standing order debits future dates: whether the account covers the amount today, and the customer's cumulative daily and monthly caps. Both are enforced for real — as rejections — when a due date actually raises its payment.

Setting up an order posts nothing. Each due date raises its own payment and writes its own balanced debit/credit pair, in integer cents.

Staff user setting up the order

Account to debit

Balance derived from postings: USD 4,250.00. The account must be funded on every due date, not just the first.

Payee to pay

Only live, VERIFIED payees of the paying customer are listed; the same rule the payment engine applies on every due date.

Amount for each payment

Major units with at most two decimals; stored and debited as integer cents.

Schedule

How often it repeats

First payment date

Today (2026-08-19) or later. A monthly or quarterly schedule is anchored to this day-of-month and clamped in shorter months, so the 31st falls on the last day of February rather than drifting.

End date (optional)

Number of payments (optional)

Leave both empty to run until the order is cancelled. Whichever binds first ends the run.

Description

Client reference (idempotency key)

Re-submitting the same reference returns the original order and never creates a second standing instruction.

Before you commit

Choose the account, the payee, an amount and a start date and the dates this schedule would produce appear here, together with the funding assessment and any check that would refuse the set-up.

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.