Payments & transfers

This is the money path: moving funds between accounts, out to other banks, and in from them. Two screens matter, and the difference between them is worth understanding.

Where: the Payments & Clearing group.

• Transfers, the standard customer flows: own-account, internal (this bank), a saved beneficiary, or outbound to another bank.
• Payments (hub), the operational money path: dispatch, settle, return, and ingest inbound files. This is where operators run and recover payments.

Transfers

Payments & Clearing → Transfers handles everyday movements. Alongside it, Beneficiaries holds saved payees and Standing orders holds scheduled recurring instructions (which run at the start of their due day).

The payments hub

Payments & Clearing → Payments lists payments with their reference, type, rail, beneficiary, amount and status. Open a row to see the instruction, its ISO 20022 references (end-to-end ID, UETR, instruction and clearing-system IDs) and the ledger entries it posted: each leg as a debit or credit with its business, value and posted dates.

Actions are gated by the payment's status and your permissions:

Action	When	Permission
Run dispatch	Send queued payments to their rail	payment:dispatch
Receive inbound	Credit a beneficiary from an inbound file	payment:inbound
Settle	Mark an executed/dispatched payment settled	payment:settle
Return	Reverse the debit (reason required)	payment:return
Recover	Resolve a held payment: retry, return or mark settled	payment:recover
Manual payment	An exception path (see below)	payment:exception-initiate

Recovery is always four eyes

Recovering a held payment does not act immediately. It parks a PAYMENT_RECOVERY approval, and a checker authorises the retry, return or settle in Approvals.

Manual (exception) payment

The hub's manual payment is a deliberate exception path, used when the normal flow cannot be. It is a short wizard: type (internal or outbound), rail, accounts, then amount. It requires an audited reason, which is stamped onto the payment's narrative. Reach for it only when you must.

Limits and step-up

Whether a payment settles straight through or needs authorisation depends on limits.

• Staff operations over an auto-limit route to Approvals (four eyes). You will see "Payment exceeds the auto-limit. A checker must authorize it."
• Customer channels (the portal, mobile, USSD) apply per-channel ceilings and step-up (a one-time code / SCA) on sensitive actions. These are configured under Digital Identity → Channel policies and Channel limits, not in the payments hub.

Not yet built: unified limits engine

A single preventive limits engine (with ALLOW / STEP-UP / REVIEW / BLOCK outcomes and "most restrictive wins" precedence) is designed but not yet built. Today limits are enforced per module: channel, product, lending, cards, agent float, treasury and teller each apply their own.

Rails, clearing and messaging

• Payment schemes configures the rails and how payments route across them (editing needs the reference-manage permission, so read-only payment roles do not see it).
• Bill pay holds the biller, merchant, tax and government payee catalogue.
• ISO 20022 is the message inbox/outbox: pacs.008 instructions in, pacs.002 acknowledgements out.
• Clearing → Items / Settlements shows clearing items and the net settlement batches that square them.
• Agents manages banking agents (cash-in/out and bill-pay outlets) with their float and commission.

Key terms

Rail / scheme

The network a payment travels on (a domestic switch, a cross-border scheme, mobile money).

UETR / end-to-end ID

Unique references that follow a payment across systems, so both sides can trace it.

pacs.008 / pacs.002

ISO 20022 messages: a customer-credit-transfer instruction, and its acknowledgement.

Stand-in

Transfers accepted into a durable queue while end-of-day runs, then released on the date roll, within per-currency caps.

Roles that do this work

Task	Permission	Typical role
Read payments	payment:read	Payments Officer
Dispatch / receive	payment:dispatch, payment:inbound	Payments Officer
Settle / return	payment:settle, payment:return	Payments Officer
Approve over-limit (tier)	payment:approve	Payments Supervisor
Configure schemes	reference:manage	System Administrator