Transfer

Transfer is the core capability for domestic, cross-border and stablecoin movement. Transfers is the optional add-on that reaches rails and providers. Institutions can instead use their own qualified integrations. Each connection has a stable identity and an institution-selected display name.

Choose your contract and environment

The current source includes internal account transfer routes, legacy transfer routes and a separate /payment-transfers family. The local banking profile describes selected zero-fee NGN/NPS loopback flows and consented reads. The legacy /transfers/send endpoint remains structurally blocked while its required financial controls are incomplete.

Browse the Local banking profile in the API reference. Bind the selected operation to the institution, exact build and local fixture evidence. Cross-border, stablecoin, live provider connectivity and any add-on deployment need their own approved contracts and acceptance.

Prepare the connection

The institution’s technology owner selects the adapter, environment, destination coverage, currencies and credentials. Finance and operations establish funding, settlement accounts, status enquiry, reconciliation and incident ownership. Validate the connection before independent enablement.

NIP and NPS describe different Nigerian rail contracts. Select the adapter that matches the actual provider agreement and messages. A display name or endpoint address supplies no compatibility evidence.

Follow the instruction

1. Verify debtor account, beneficiary, amount, currency, fees and eligibility under the current grant.
2. Prepare the exact instruction and retain its durable identity.
3. Obtain independent approval where required. Material edits invalidate the bound decision.
4. Commit the core funding or reservation and durable dispatch state before external release.
5. Track provider acceptance, financial posting, settlement and reconciliation separately.
6. Issue the receipt from authoritative state and retain the original connection and policy versions.

A customer agent or partner acts only within a current principal grant. The core owns the instruction and accounting for its accounts. The connection owner supplies authoritative external evidence.

Recover an uncertain result

A lost response leaves the instruction pending or unknown. Enquire through the original connection and reconcile the external evidence. Use the original idempotency and business identity. Switching to another route before resolution can duplicate the financial effect.

Incoming messages require adapter authentication and replay handling. Resolve a virtual account against the owning service, credit its linked account once in the owning core, then track notification delivery separately. Unallocated received value enters an owned exception process with its accounting retained.

Retain acceptance evidence

The institution owner needs the exact configuration and build, actor scopes, instruction and approval identity, funding and journal references, dispatch/inbox identities, external result, settlement and reconciliation proof. Exercise duplicates, concurrent release, altered approval, timeout, revocation and interrupted recovery as part of the qualified scope.