How a payment picks its rail

A rail is a clearing scheme your organisation can send money on. Most markets offer more than one, and they differ in speed, cost, and how much they will carry.

You do not choose the scheme. You say how fast the payment needs to be, and the system picks the first rail that can carry it.

The ladder

Your organisation configures its rails in order, fastest first. A payment tries each one in turn and takes the first that fits.

flowchart TD
    A["Payment raised"] --> B{"Instant rail fits?"}
    B -- "Yes" --> C["Sent in seconds"]
    B -- "No: too large, or<br/>not fast enough to need it" --> D{"Same-day rail fits?"}
    D -- "Yes" --> E["Cleared today"]
    D -- "No" --> F["Next-day batch"]

Four things decide whether a rail fits.

The first three decide which rail carries the payment. The fourth decides when it settles — see Cut-off times below.

Service levels

A payment declares what it needs of the clearing system. There are three.

These are the standard ISO 20022 service levels, so a service level means the same thing here as it does on the wire. See the standards register row for ISO 20022 — ExternalServiceLevel1Code.

A payment that says nothing is non-urgent. That matters: a rail that serves only urgent payments charges an urgent fee, and a payment nobody marked urgent should never quietly pay it.

Why a fast rail does not take everything

A rail declares which service levels it serves. A rail that names none serves them all.

Suppose your organisation adds a same-day rail above its next-day batch. If the new rail named no service levels, every ordinary payment would take it, because it is higher in the order and always fits. Every interest payout, every account closure, on a paid rail nobody asked for.

Naming the levels a rail serves is what prevents that.

An urgent payment over the fast rail’s limit still falls through to the batch. A limit is a test of fit, not a refusal — the payment goes out, more slowly.

Cut-off times

A rail closes at a time each day. A payment approved after it stays on the same rail and settles one business day later. It is not moved to another scheme.

That is what a cut-off means in banking, and it is why the date you are quoted can move when the payment is approved.

Take a rail that closes at 16:00 and normally settles the next business day:

The cut-off is read in the rail’s own market. A rail that closes at 16:00 in Johannesburg closes at 16:00 there, whatever time it is where you are sitting.

When the date changes

The date you see when a payment is captured is provisional. It becomes firm at approval, because approval is when the rail is really chosen.

A revised date is always later than the one first quoted, never earlier. Someone told the money arrives tomorrow, who is paid in seconds, is pleasantly surprised. Someone told it arrives today, who waits a day, has been misled.

Every revision is recorded with who approved the payment and when, so you can always see why a date moved.

Which speed a payment asks for

The speed comes from what the payment is for, not from who raises it.

Your organisation sets a service level against each purpose it pays for — an interest payout, a maturity, a disbursement. Every payment for that purpose asks for that speed, without anyone deciding it payment by payment.

A purpose can also be marked so that its speed cannot be overridden. That is a policy your organisation sets, and the system enforces it when the payment is raised — not by hiding a control.

Real-time clearing

Some markets offer a real-time credit scheme that clears against an ordinary account number, settling in seconds rather than overnight.

This sits between an instant proxy payment, which is capped and needs the beneficiary’s proxy, and the next-day batch, which carries anything. It gives you a third tier: fast, addressed the ordinary way, and available for any amount your organisation permits.

Two things are worth knowing about it.

• It only ever pushes money out. There is no real-time way to collect. A collection is disputable by design, and money that settles irrevocably on receipt would remove the payer’s protection. So a collection screen offers no service level, because no scheme could honour one.
• It is irrevocable on settlement. Once it clears, it cannot be recalled. Money received on it is available immediately, with no uncleared-funds hold.

South Africa’s scheme is Real Time Clearing. See the standards register row for BankservAfrica Real Time Clearing (RTC), South Africa.

What your organisation configures

• Which rails exist, and in what order. Adding a tier is a settings row, not a code change.
• What each rail is called. A rail can carry a name your people recognise. Left blank, it shows the name of the scheme it clears on.
• Each rail’s limit, service levels, and cut-off — including the market the cut-off is stated in.
• Which speed each payment purpose asks for, and whether that speed can be overridden.

Rail settings are edited as a draft and take effect when the draft is published, so a change is reviewed before it moves any money. The change is recorded, with who published it.