OnLink
ConceptsRails

Cut-off times

Which Kenyan rails observe a banking day and which never close, why we do not publish a clock time, and how to find the one that applies to your account.

Three of the rails in this corridor run continuously. The rest observe a banking day, and an instruction that arrives after the day's last session is carried to the next one.

A cut-off belongs to the rail, not to us

Every row below describes when the rail stops accepting instructions for the day. None of it is a commitment about how long anything takes once it has been accepted, and none of it should be read as one. Build your product around the event that tells you a movement finished, not around a clock.

The table

Currency follows the rail, so it is named in the first column rather than given one of its own.

RailCloses?What that means for an instruction
M-PESA (KES)Never — runs continuouslyNo weekend or public-holiday pause.
PesaLink (KES)Never — runs continuouslyReal-time between participating Kenyan banks.
USDT (Tron)Never — a public networkNetwork conditions apply instead of a calendar.
RTGS (KES)Yes, each banking dayCarried to the next banking day. Settles gross, one by one, and closes at weekends and on Kenyan public holidays.
EFT (KES)Yes, at each batch sessionCarried to the next session. Settles in batches, so the session matters more than the minute.

The three rails that never close are listed first on purpose: for most Kenyan corridors the cut-off question has no answer, and that is the answer.

SWIFT and on-us transfers are not reachable on this API in either direction, so nothing about their sessions is published here — see Rails for what each one is.

Why there is no clock time in that table

Because the true one is per account, and a wrong precise number is worse than an honest absence.

The session times on the banking-day rails are set by the rail and by the bank holding the account, not by us, and they differ between banks and move with the Central Bank's own calendar. A single time published here would be right for some readers and quietly wrong for the rest — and a reader who builds a scheduler around a wrong time finds out on the one day it matters.

Ask us for the times that apply to your account, and we will give you the current ones for your rails rather than a number from a page. Email info@onlink.africa.

What to build instead of a schedule

  • Take the outcome from a webhook. It reaches you when the transition happens, whatever the calendar was doing.
  • Treat "sent late on a Friday" as a normal case, not an incident. On a banking-day rail it is the next session, and nothing about the instruction is wrong.
  • Do not derive a deadline from a cut-off. The deadline your integration has to respect is the one on your order — expiresAt for funding, and sendBefore on a sell order. Both are on the response. See Asynchronous settlement.
  • Watch Kenyan public holidays if you run a payment schedule. They close the banking-day rails and leave the continuous ones untouched.

On this page