The incident

Two months ago, my younger sister sent money to the wrong account. A valid, active account — not a typo that bounced, not a dormant account that triggered an auto-reversal. Just the wrong real person. We did what you're supposed to do: reported it to both banks with the transaction reference, escalated to the Central Bank of Nigeria's Consumer Protection Department when the banks sat on it, and eventually got a court order compelling the receiving bank to reverse the transfer.

The bank still hasn't complied.

I'm a backend engineer, so my instinct wasn't just "this is unjust" — it was "why does the system allow this state to persist at all?" The answer turned out to be more interesting than "Nigerian banks are slow." It's an architectural choice, made decades ago in payment rail design everywhere, that Nigeria's infrastructure has never fully addressed: instant payment systems were built to be fast and final. They were never built to be reversible.

The happy path: how NIP actually moves money

Nigeria's real-time transfers run on NIBSS Instant Payment (NIP), the country's interbank settlement backbone. The flow, mechanically:

  1. Sender's bank performs a Name Enquiry against the destination account — validated against BVN records — to confirm the account exists and belongs to who it claims to.
  2. The sender's bank pushes the transfer instruction through NIBSS to the receiving bank.
  3. The receiving bank posts the credit and confirms back through NIBSS.
  4. The sender gets a success notification.

All of this happens in under 30 seconds. It's a genuinely well-engineered rail for the thing it was built to do: move money fast, with high reliability, at massive scale (NIBSS-cleared electronic payment volume has been in the hundreds of trillions of naira annually).

Note what's absent from that flow: there's no step where the protocol itself asks "are you sure this is reversible if wrong?" A NIP transfer is a one-way push. Once step 3 completes, there is no native "undo" instruction in the protocol — only two possible paths back.

The unhappy path: where the architecture runs out

Path one — automated reversal. This covers system-level failures: a transaction timeout before the receiving bank confirms, a stale cached Name Enquiry result pointing at a since-changed account, a sync error where a debit posts without a matching credit. These are treated as protocol-level errors, and the system (or the sending bank) reverses them automatically, typically within 24–72 hours.

Path two — cooperative manual reversal. This is what applies when the transfer was technically successful but substantively wrong — a valid account, just not the one the sender meant to pay. CBN's 2018 Regulation on Instant Electronic Funds Transfer Services actually addresses this directly: it requires the receiving bank to debit and reverse the transaction as soon as the beneficiary's account is credited, and states plainly that the receiving institution should not treat mistakenly-credited funds as the beneficiary's property.

The rule exists. What doesn't exist is a mechanism to enforce it without the receiving institution's cooperation.

Here's the part that matters at the engineering level: once a transfer is authorized by the sender (PIN, OTP, biometric), Nigerian banking practice treats it as final. A bank cannot unilaterally debit a customer's account without that customer's authorization — doing so exposes the bank to its own liability for an unauthorized debit. So the "recall" is not a system call. It's a negotiation, backstopped by a Post-No-Debit lien that banks are frequently reluctant to apply without a court order, and — as I've now personally confirmed — reluctant to act on even with one.

There is no shared, real-time state machine between the two banks and NIBSS tracking "disputed transfer, status: pending court compliance." There's a paper trail of letters and emails. That gap between "the rail moved the money in 30 seconds" and "the dispute has no equivalent time-bound tracking layer" is the actual architectural failure.

This isn't just my case

NIBSS' own infrastructure has had failures that make the same point at scale. A fault in the NIP platform in September 2024 caused "dry posting" — funds credited to beneficiary accounts with no corresponding debit from the originating account — affecting 176 accounts across 19 institutions, with NIBSS' total exposure reaching ₦13.66 billion. NIBSS is still in court years later trying to recover a fraction of it, pursuing account freezes and Post-No-Debit orders against the same accounts that received the erroneous credits.

That's the same failure mode as my sister's case, just triggered by a system bug instead of human error, and at a scale that made it newsworthy. The underlying gap is identical: money moved by the fast rail, and clawing it back required litigation because there's no protocol-level recall.

What other rails do differently

UPI (India). NPCI sits above the individual banks as a centralized dispute layer. A disputed or misdirected transaction enters a shared grievance-redress system with defined turnaround times that both banks are contractually bound to, rather than each bank running its own internal, unaccountable-from-outside process.

Faster Payments (UK). Two structural additions matter here. Confirmation of Payee checks the name against the account before the transfer completes, catching mismatches earlier than NIP's Name Enquiry model typically does in practice. And the Contingent Reimbursement Model code pre-assigns liability for authorized-push-payment fraud/error cases, so who eats the loss is a designed rule rather than something litigated case by case.

ISO 20022 messaging (used across several modern real-time rails). Recall is a first-class message type (pacs.007), not an out-of-band process. The receiving institution's system is required to acknowledge or reject the recall within a defined SLA at the messaging layer — enforceable by the rail itself, not solely by courts.

Nigeria has the equivalent of the fast rail. It doesn't have the equivalent of the recall message type, the centralized grievance clock, or the pre-assigned liability rule.

What this means if you're building on top of NIP

If you're integrating with Nigerian payment rails — Paystack, Flutterwave, Nomba, or NIBSS directly — a few things follow from all this that are worth designing for rather than assuming away:

  • Never assume the underlying rail will handle your reversal case for you. Build your own dispute/reconciliation state machine at the application layer, because the rail's default behavior for "wrong but valid destination" is "your problem now."
  • Log the NIP session ID / reference for every transaction, obsessively. It's the only universally recognized trace artifact once a dispute escalates to CBN or court.
  • Design confirmation UX to catch mistakes before they're irreversible. A Confirmation-of-Payee-style name match, shown clearly before final send, is cheap to build and addresses the single highest-leverage point in the whole flow — the moment before the push happens, which is the only moment reversal is actually free.
  • Assume the unhappy path will be used. At the volumes NIBSS processes, "wrong account, right rail" isn't an edge case — it's a predictable, recurring category of failure that deserves first-class handling, not an apology letter and a support ticket.

Where I've landed

The honest takeaway, two months and a court order into this: Nigeria's payment rails solved the fast half of the problem extremely well. The reversible half was never treated as an engineering problem at all — it was handed to law and goodwill instead. That's a solvable distributed-systems problem. It just hasn't been treated as one yet.

If you've dealt with NIP recalls from the infrastructure side, or you think the ISO 20022 / UPI comparison doesn't hold up to closer scrutiny, I'd like to hear where I've got this wrong.