The ruffians on Twitter treat this as a failure of imagination, but they miss the real reason it happens.

Your typical fintech app isn’t used often enough to build a habit like Twitter or TikTok. Sure, they might not be social media apps, but when you’re optimizing for Daily Active Users (DAU) to show your investors you’re doing something, you start to look for things that drive activity.

Let’s look at Zap. It was a simple mobile wallet. You connect a payment instrument, like a card or an account, and you use it to make payments on the go. Once the novelty wore off, the PM probably looked at their DAUs taking a nose dive. Users can make transfers with their current bank app. Beyond the smooth UX of it all, Zap still relied on NIBSS like everyone else, so it’s not like there was some unique wedge there.

So the PM moves to add analytics. Oh, you can now see where your money goes. That should get you to route more of your transfers via Zap. Good idea, but it assumes the user is discerning. Sure, it might attract a couple of new users but they probably get lazy and drop off after a while.

Then the PM gets a lightbulb moment. People buy airtime every week so why not add that. If they can buy airtime, there’s something else to do on the app besides making transfers. Another reason to open Zap. Suddenly, DAUs start to pick up.

This is probably not how the PM’s thought process went but I’m sure I’d think similar.

You can say the same thing for FairMoney and credit. After borrowing, the users run away until it is time to pay. But you need them to come back earlier, so you add airtime.

That extra reason to open the app is the utility. Literally everyone buys airtime. You do it this week, and because of MTN, you’ll do it next week. If the place to buy airtime is located in a particular fintech app, that app stops being something you only remember when you need it. It just becomes the one you use.

That’s also how you get users to leave money sitting in your app.

If the app only does one job, they fund it, do the thing, and take the rest out. It becomes something Ron Shevlin calls a “Paycheck Motel”. Money comes in, does one job, leaves. It even happens to the best of us like PiggyVest. You’ll park funds there for a goal, the goal hits, and the money is gone. It’s done what it came to do.

Give people enough everyday stuff in one app (read: transfers, airtime, data, electricity) and there’s less reason to keep emptying it. Easier to just leave the money. And once it’s sitting, you can lend it or invest it.

Airtime, in itself, also contributes to the bottom line. HabariPay’s recent financial reports showed airtime-vending revenue beating switching and processing. Selling airtime is one of the highest-margin products a fintech can offer outside of credit, and the direct costs are little to none. You’re looking at an uncapped 3% to 6% per transaction. Which is why some fintechs can afford those generous airtime cashback programs. The margin is so huge that you can just throw it at user acquisition.

At this point you might say, if everyone has airtime, then what’s the value. Fair question. Every consumer fintech can sell the same MTN and Airtel airtime. There are no switching costs and if you’re all giving cashback, it’s a race to zero.

So airtime by itself will not save you. Same way push notifications (instead of SMS) and transfers and a transaction feed will not save you, but you’d still look unserious without them. Airtime right there with those guys. You just have to have it.

What you actually want to know is whether the people who buy airtime come back more, keep more money in the account, and do other things you want them to do like saving and borrowing.

With these few points of mine, I hope I have convinced you and not confused you as to why fintechs eventually sell airtime.

If bank transfers are going to become a proper merchant payment experience, the interesting question is not only how the money moves. It is what the moment of payment should feel like for the customer.

Could NPS Request to Pay be shaped into an Apple Pay-like tap experience for Nigeria, without using cards at all?

I do not mean “run Apple Pay on NPS.” Apple Pay is a card-wallet product that rides card scheme rails. NPS is account-to-account. There is no need for PANs, DPANs, card tokens, or card scheme authorization. The more interesting idea is to borrow the experience pattern:

• tap at the point of sale

• authenticate on your own device

• do not expose sensitive payment details to the merchant

• bind the approval to that exact transaction

• complete the payment over the appropriate scheme rails

For Apple Pay, those rails are card networks. For NPS, the rails would be account-to-account transfers orchestrated through NIBSS/NPS.

This note is a first attempt to think through how that could work.

What the NPS docs already suggest

The NPS deck I received describes Request to Pay as a way to modernize invoice presentment and e-commerce. The core message pair is:

• pain.013: Creditor Payment Activation Request

• pain.014: Creditor Payment Activation Request Status Report

The broad flow is simple:

1. A creditor, such as a merchant or biller, creates a payment request.

2. The creditor’s bank sends the request into NPS.

3. NPS routes the request toward the debtor’s bank.

4. The debtor approves, partially approves, or declines.

5. If approved, the actual money movement happens through a credit transfer, such as pacs.008.

6. Status updates flow back through pain.014 and pacs.002.

The deck also highlights data needed for matching the request back to the payment:

• EndToEndId, which should persist from the request into the payment

• PmtInfId, which groups transactions

• structured remittance data, such as invoice number and invoice date

• amount

• due date or expiry

• purpose codes, such as e-commerce or utility bill

That is important because a good tap-to-pay experience cannot just move money. It must reconcile cleanly. The merchant needs to know which order was paid. The bank needs to know what the customer approved. NIBSS needs to correlate the request, approval, transfer, and final status.

So the core RTP primitive is already there:

merchant creates request
NPS routes request
customer approves
account-to-account payment executes
status returns to merchant

The missing product question is: what is the best customer interaction at the point of sale?

QR has struggled in Nigeria as a checkout form factor. A more natural direction is NFC.

How Apple Pay works, at a high level

Apple Pay at a terminal is basically EMV contactless with a very secure device pretending to be a contactless card.

At the point of sale:

1. The terminal creates an NFC field.

2. The iPhone or Apple Watch behaves like a contactless EMV payment credential.

3. The terminal selects the card application, such as Visa or Mastercard.

4. The terminal sends transaction data: amount, currency, terminal country, merchant/acquirer data, unpredictable number, and other EMV fields.

5. The Secure Element returns tokenized card data plus a dynamic cryptogram for that transaction.

6. The merchant/acquirer sends the authorization through the card network.

7. The card scheme/token service and issuer validate the token, cryptogram, account status, risk, and available funds.

The important design ideas are:

• the merchant does not get the real card number

• the device credential is not generally useful outside its intended context

• the transaction includes a dynamic proof that cannot simply be replayed

• user verification happens locally through Face ID, Touch ID, passcode, or Apple Watch unlock

• the terminal and payment network receive proof that the consumer device verified the user

For Apple Pay, the underlying instrument is still a card. The device presents a card-network token, and the card schemes play the central trust and routing role.

For NPS, the underlying instrument should be a bank account. That means the NPS version should not copy the card abstraction. It should copy the pattern:

Apple Pay:
card token + device cryptogram + issuer authorization

NPS RTP:
account alias/token + signed customer consent + debtor bank authorization

What an NPS Apple Pay-like experience could mean

The account-to-account version could look like this:

Customer taps phone on POS
POS/NFC exchange identifies the RTP request
Customer's bank app shows merchant, amount, and account
Customer approves with biometrics, passcode, or bank PIN
Bank/NPS creates transaction-bound consent
NPS executes or coordinates the account-to-account payment
Merchant receives status

The goal is not to put account details into the terminal. In fact, that should be avoided.

The terminal should not receive:

• real account number

• BVN

• phone number

• stable customer identifier

• any reusable debtor credential

Instead, the terminal should receive or exchange only enough information to connect the tap to an NPS RTP request. The customer account should be selected and authorized inside the customer’s own bank app, or inside an approved NPS wallet if one exists later.

This is especially important in Nigeria because many users have multiple banks and multiple accounts. A blind tap where the phone tries to guess which bank app should pay is likely to create ambiguity. The more realistic early experience is probably app-first:

open bank app
choose "Pay with NPS Tap"
select account
tap POS
approve payment

That may be one step more than Apple Pay, but it solves the multi-bank problem and keeps the funding decision where it belongs: inside the user’s bank app.

The main design options

I see four plausible options.

Option A: App-first presentment

In this model, the user opens their bank app before tapping.

1. Merchant POS creates an NPS RTP request.
2. Customer opens bank app.
3. Customer chooses the funding account.
4. Customer taps the POS.
5. The phone sends a one-time debtor routing token to the POS.
6. POS submits or updates the RTP request with that token.
7. NIBSS routes the request to the selected bank/customer.
8. Customer confirms in-app, or the earlier app action counts as the consent ceremony.
9. Payment completes over NPS account-to-account rails.

The NFC payload from the phone should not contain the account number. It should contain something like:

{
  "scheme": "NPS_RTP_TAP",
  "debtorBankCode": "XYZ",
  "debtorRoutingToken": "short-lived-opaque-token",
  "requestId": "optional-if-known",
  "nonce": "terminal-challenge",
  "expiry": "2026-05-17T13:10:00Z",
  "signature": "bank-app-or-device-signature"
}

The token would be meaningful only to NIBSS and/or the debtor bank. The POS simply passes it along.

This handles multiple banks well because the user has already chosen the bank app. It also works with the mental model Nigerian users already have: “I want to pay from this bank account.”

The tradeoff is that the terminal receives an opaque debtor routing token. That is much better than an account number, but it is still something that must be carefully designed to avoid becoming a stable tracking identifier.

Option B: App-first claim

This is more private.

Here, the POS exposes the RTP request over NFC, and the bank app reads it. The bank app then talks directly to NIBSS or the debtor bank.

1. Merchant POS creates an RTP request.
2. POS exposes request ID, amount, merchant ID, terminal ID, and nonce over NFC.
3. Customer opens bank app and selects account.
4. Customer taps.
5. Bank app reads the request context.
6. Bank app sends directly to NIBSS: this customer wants to pay this request from this selected account.
7. NIBSS correlates the claim with the merchant request.
8. Payment completes and status returns to the POS/merchant.

The terminal never receives a debtor token. It only broadcasts or exposes the request.

This is attractive because the customer identity and account choice flow only between the bank app, debtor bank, and NIBSS. The merchant terminal remains blind.

The challenge is hardware and rollout. Existing terminals may be better at reading a phone than being read by a phone. If the POS estate cannot reliably expose NFC tags or peer-style request data, this becomes harder to deploy.

Option C: Default NPS wallet

This is the most elegant user experience if the ecosystem can support it.

1. Customer taps POS.
2. The default NPS wallet opens.
3. User chooses bank and account.
4. User approves.
5. NPS routes the RTP and completes the payment.

This removes the need to open a specific bank app first. It also creates a consistent national experience.

But the governance and platform questions are heavy:

• Who owns the default wallet?

• Would banks support an NPS wallet sitting above their apps?

• How would account linking work?

• How would liability be shared?

• How would this work on iPhone in Nigeria?

• Would the OS allow this app to be the default contactless payment handler?

Android gives more room here because of Host Card Emulation and default wallet behavior. iPhone is more constrained. Apple opened NFC access in the EEA because of the European Commission’s Apple Pay case, and Android has long supported HCE. But Nigeria is not automatically covered by Apple’s EU commitments, and Apple’s broader NFC & Secure Element Platform is entitlement-based and territory-limited.

So a default NPS wallet may be desirable, but it is probably not the right starting point.

Option D: NPS Tap ID / device credential

This is the ambitious long-term option.

In this model, NIBSS defines a full NPS NFC credential, similar in spirit to a network token but account-to-account rather than card-based.

Each enrolled device gets an NPS Tap ID or device-bound credential:

NPS Tap ID -> mapped by NIBSS/debtor bank to customer/account context

At the terminal:

1. POS selects the NPS NFC application.
2. POS sends transaction data and challenge.
3. Device returns Tap ID plus signed transaction proof.
4. NIBSS validates the credential and routes to the debtor bank.
5. Debtor bank validates consent and account status.
6. NPS completes the account-to-account transfer.

This is the closest to Apple Pay structurally:

Apple Pay:
device card token + EMV cryptogram + issuer authorization

NPS Tap ID:
device account credential + signed RTP consent + debtor bank authorization

It could deliver the best eventual experience:

• tap without opening a bank app first

• no account number exposed

• transaction-specific signed proof

• scheme-level credential lifecycle

• consistent terminal certification

• better fraud controls over time

But it is also the heaviest option. NIBSS would need to define credential provisioning, lifecycle management, device binding, revocation, lost-device handling, terminal certification, consent rules, risk signals, liability, and fallback behavior.

This feels like the north star, not the first rollout.

Coverage map

The way I would compare the options is by asking a few practical questions. Does it keep NFC as the primary checkout interaction? Does it work for customers with multiple banks and multiple accounts? Does it avoid exposing real account numbers or stable customer identifiers to the merchant terminal? Does it still give NIBSS enough information to route or correlate the request? Does it preserve explicit consent? Does it bind the approval to the exact transaction, amount, merchant, terminal, and expiry? And does it preserve NPS reconciliation through EndToEndId, invoice references, pain.013, pain.014, pacs.008, and status messages?

On those core payment-design questions, all four options can be made to work. App-first presentment, app-first claim, a default NPS wallet, and a long-term NPS Tap ID can all use NFC, support multi-account users, hide sensitive account details from the merchant, preserve consent, produce transaction-bound authorization, and reconcile cleanly through the NPS message flow.

The real differences show up when you ask about rollout.

App-first presentment is the most practical. It works with the multi-bank reality because the customer chooses their bank app and account before tapping. It also keeps terminal changes relatively modest: the POS needs to create or hold an RTP request, exchange a challenge or token over NFC, and pass the opaque debtor routing token into the NPS flow.

App-first claim is stronger on privacy because the terminal never receives even a debtor routing token. The phone reads the request context from the POS, and the bank app claims the request directly with NIBSS. The problem is terminal capability. It may require POS devices to expose request data in a way the phone can reliably read, and that may be unrealistic across the current Nigerian POS base.

A default NPS wallet gives the cleanest consumer story on paper: tap first, choose bank/account, approve. But it depends on a default-wallet model, OS-level support, and bank/NIBSS governance alignment. It is especially tricky on iPhone in Nigeria, where NFC presentment is not as open as it is in the EU context or on Android.

The NPS Tap ID option is the most ambitious. It could eventually give Nigeria a true account-to-account tap credential, with a device-bound NPS identity and signed transaction proof. But it has the heaviest dependencies: credential provisioning, lifecycle management, terminal certification, Apple platform access, Android wallet behavior, fraud rules, and liability. It is a north star, not the easiest first step.

Closing thought

The interesting thing about NPS Request to Pay is that it should not just be thought of as “send me money” infrastructure. With the right NFC interaction model, it could become a new physical commerce experience.

Apple Pay taught users that tapping a phone can feel safer and faster than handing over payment details. NPS has the chance to apply that same lesson to account-to-account payments in Nigeria.

For now, the most realistic path is app-first presentment: open bank app, select account, tap, approve, pay. For the long term, the more ambitious path is an NPS Tap ID: a device-bound account credential that can deliver a true tap-to-pay experience without cards.

This 2026 Guide supersedes the 2020 version and applies across a broad set of institutions including Commercial and Merchant Banks, Payment Service Banks, Non-Interest Banks, Microfinance Banks, Finance Companies, Primary Mortgage Banks, Development Finance Institutions, Credit Guarantee Companies, Mobile Money Operators, and any other institution designated by the CBN.

Schedule of Charges (selected highlights)

The formal schedule is organised into sections. Below are the consumer- and merchant-facing changes that will likely be most visible in practice.

Interest on Deposits/Borrowings (selected items)

For deposits held as collateral, the Guide introduces minimums in some cases. In particular, foreign currency deposits held as collateral are negotiable subject to a minimum of 0.18%. (Naira collateral deposits are negotiable subject to a minimum of 30% of MPR per annum.)

Lending Rates and Fees (APR and penal rates)

The Guide tightens how borrowing costs are presented. All lending rates—inclusive of applicable fees—must be quoted and communicated strictly on an Annual Percentage Rate (APR) basis. Except for penal charges, no other fee or rate associated with credit that is not included in the APR should be charged to borrowers.

Penal rates are capped at 1% flat per month on unpaid Naira loan amounts and 0.25% flat per month for foreign currency loans (where applicable), in addition to the agreed interest on outstanding debt. The Guidance Notes also clarify grace periods before penal charges apply: 7 days for banks/PMBs/DFIs and 3 days for MFBs (with the important caveat that the grace period does not waive penal charge; it governs timing).

Account Service Charges (CAMF and statements)

For current accounts, the Current Account Maintenance Fee (CAMF) remains negotiable subject to a maximum of ₦1 per mille, but now has a clear phase-out: 2026: ₦0.5 per mille; 2027: ₦0.

On statements, the Guide makes monthly issuance (printed or electronic) free, and keeps special printed statements capped at ₦20 per page. It also introduces a fee for special electronic statements delivered to third parties: ₦200 (while special electronic statements for personal use remain free).

Electronic Banking (EFT and tokens)

The schedule explicitly reorients small transfers toward lower fees. For inter-bank/scheme electronic transfers, amounts >₦0 to ₦5,000 are free, transfers >₦5,000 to ₦50,000 are capped at ₦10, and transfers >₦50,000 are ₦50.

On authentication tools, hardware tokens are on cost recovery, while software tokens are ₦500 per annum. One-time passwords via email are free, while SMS OTP is cost recovery.

Cards (issuance and maintenance)

Standard regular/basic Naira debit/credit card issuance is set at ₦1,500, while virtual cards are free. Naira debit/credit card maintenance is free, while foreign-currency denominated card maintenance remains $10 per annum (or its equivalent).

ATM Transaction Fees (Not-On-Us withdrawals)

On-us withdrawals are free. For Not-On-Us withdrawals (using another institution’s ATM in Nigeria), the Guide adopts a per-withdrawal structure: ₦100 per ₦20,000 at on-site ATMs, and ₦100 plus a surcharge of up to ₦500 per ₦20,000at off-site ATMs. The surcharge (income of the deployer/acquirer) must be disclosed at the point of withdrawal.

Domestic Transaction Fees (stopped cheques, MSC, WAC)

Two sharp changes show up here. First, stopped cheques are ₦5,000 per cheque.

Second, the Guide is explicit about merchant charges and cardholder protection:

• Merchant Service Charge (MSC): 0.5% capped at ₦10,000, to be borne by the merchant. Cardholder transactions at a merchant location must be free to the cardholder, and the MSC must be the same irrespective of payment method (cards, cardless, transfer, pay-with-phone-number, etc.). Where MSC applies, a convenience fee must not be charged.

• Web Acquiring Charge (WAC): negotiable, also borne by the merchant, with the same “no charge to cardholder” and “no convenience fee where this applies” rules.

At a high level, the 2026 Guide does two things in parallel: it codifies responsibility and enforcement (system configuration, compliance accountability, and monthly failed-transaction reporting), and it clarifies pricing and disclosure (particularly around APR-based lending disclosure and explicit “no cardholder charge” rules for merchant/web acquiring fees). For consumers and merchants, the most immediate effects are likely to show up in small transfer pricing, the CAMF phase-out, the revised Not-On-Us ATM withdrawal structure, and the stricter framing of MSC/WAC as merchant-borne charges with clear disclosure requirements.

Circular on Additional Functionalities for Instant Payment (IP)

Effective Date: July 1, 2026

This circular mandates Financial Institutions to introduce new security and control features for Instant Payments to enhance stability and combat fraud:

• Opt-In/Opt-Out Feature: Customers can voluntarily disable (opt-out) or enable (opt-in) instant payment services for their accounts at any time using Multi-Factor Authentication (MFA). When opted out, online instant transfers are blocked, but in-person branch transfers remain possible.

• Customizable Transaction Limits: Customers can adjust their personal transaction limits (up to the existing maximums of ₦25 million for individuals and ₦250 million for corporates). Changes require MFA and enhanced due diligence.

• Enterprise Fraud Monitoring: Institutions must actively monitor both inflows and outflows for fraudulent activities.

• Liveliness & Identity Checks:

  • Online account openings and reactivations require liveliness checks and real-time validation against the BVN/NIN database.

  • Online reactivations require enhanced authentication (like biometrics or hardware tokens).

• Mobile App & Internet Banking Security:

  • Device Binding: Mobile apps can only be active on one device at a time.

  • 24-Hour Limits: A maximum withdrawal limit of ₦20,000 applies for the first 24 hours on newly opened accounts or newly activated mobile apps on existing accounts.

• New Device Logins: Logging into internet banking from a new device for the first time requires additional MFA.

Addendum to the BVN Operations and Watch-List Framework

Effective Date: May 1, 2026

This circular introduces amendments strictly regulating Bank Verification Number (BVN) operations:

• Temporary Fraud Watchlist: Financial institutions must create a temporary watchlist for BVNs flagged in suspected fraud. A BVN can remain on this list for a maximum of 24 hours, during which the customer will be contacted to clarify the transaction.

• Age Restriction: BVN enrollment is now strictly limited to individuals aged 18 years and above.

• Phone Number Updates: Customers are now restricted to amending the phone number linked to their BVN only once.

• Data Access: Access to the BVN database is exclusively restricted to CBN-licensed financial institutions. The CBN retains the sole right to grant access exceptions in special circumstances.

In this essay (can I call it that?), I’m going to imagine what every product manager for fraud and compliance at a digital bank is thinking.

First, you’re a digital bank so you don’t do in-person onboarding like GTB and co. That already puts you in a higher risk bucket in the CBN’s eyes. They’ve made it clear that any monitoring you do can’t be “transaction data only.” All the lies your fraud team has been telling them won’t fly anymore. Those transaction rules you built that trigger PNDs or liens when there’s an abnormally large transaction don’t cut again. You built that, but bank glitch recovery hasn’t materially improved. Perpetrators are still getting away, and all you’ve done is give the consumer protection department at CBN more disputes to resolve. According to the CBN, you now have to look at your alerts full context of who the customer is. Think full KYC/KYB, risk rating, behaviour. Your fraud team has never done this type before. You also need real-time or near real-time screening at onboarding and when any payment is made. Don’t forget sanctions and PEP screening, fraud monitoring (with a clear split from AML if it’s the same platform), case management, and reporting in the formats CBN and NFIU want. Oh, and audit trails, security, and data protection that stand up to NDPA and the CBN’s cybersecurity expectations.

So the real question you’re trying to answer: What do you actually build or buy, and how do the pieces fit together?

The CBN’s timeline isn’t most flexible: roadmap in 3 months, fully compliant in 18 or 24. Whatever you build has to include the full stack:

• sanctions/PEP screening

• transaction monitoring with KYC context

• fraud monitoring

• case management

• NFIU reporting — plus everything Nigeria-specific: local lists, BVN/NIN, NFIU formats.

You have three options: A = build everything in-house, B = buy one suite from one vendor, C = orchestrate best-of-breed with a central layer you build and own.

Exploring the options

Option A: Build it all.

In this option, you build screening, transaction monitoring, fraud, case management, reporting, and the glue to core and KYC. Note that each of these is a startup on its own. People are going to YC just solving one of these problems.

Screening means a real-time API with fuzzy name matching across OFAC, UN, EU, and local NFIU lists, plus a pipeline to keep those lists current. The lists in Nigeria are usually in excel sheets btw. Transaction monitoring means a configurable scenario engine, look-back windows for pattern detection (you can’t detect structuring on a single transaction), peer group analysis, and enough explainability that a compliance analyst can defend the output to a regulator. Fraud monitoring means a real-time ML model, a feature engineering pipeline, and retraining infrastructure. Case management means alert queues, assignment, escalation, audit trails, and an analyst UI. NFIU reporting means building to exact format specs for STR, SAR, CTR, and FTR submissions. Laolu says I should define these attributes, but if you don’t know what they mean then I don’t know how they hired you as a fraud product manager.

Anyway, in theory, you could satisfy every product requirement but you’d have to deliver all of it within 18 or 24 months. For most digital banks that’s not realistic. (Unless you’re Moniepoint or Opay or PalmPay and you have infinity dollars and a pool of underemployed engineers). Option A breaks in practice: 18 months is too tight for this scope.

Option B: One vendor, one suite.

You pick one vendor that does screening, transaction monitoring, case management, and reporting. You plug your core and KYC into them. Product-wise they can tick most boxes. The gap is Nigeria: do they have Nigerian lists, NFIU reporting, and the right data residency? Those are very rare. There are not many best-of-breed providers that are local. Sorry to all of you with your shiny websites. Also, you’re locked in one contract, one vendor. If you find a suite that’s proven in Nigeria and you’re okay with lock-in, B is the simple path.

Option C: Best-of-breed orchestration.

You keep your existing KYC (Smile Identity, Mono, whatever you have) and add a central layer. Think of this as the thing that ties everything together. That layer holds the unified customer risk view, gets events from core and KYC, and calls out to:

• A screening provider (e.g. Youverify for Nigeria/NFIU, or a global name with local lists).

• A transaction monitoring provider (e.g. ThetaRay, Sardine, or another with scenario config and explainability).

• A fraud provider (maybe the same as transaction monitoring, maybe not). If it’s the same vendor, the central layer enforces segregation at the workflow level: separate alert queues, separate case types, separate analyst access.

• Case management and reporting — either from one of those vendors or a dedicated tool that can do STR/SAR/CTR/FTR/NFIU.

You build the central layer so that every alert is evaluated with full KYC/KYB context. No standalone transaction feed. That gives you the unified view. You choose providers that already support Nigeria lists and NFIU formats, so you’re compliant on Nigeria. And you’re not stuck with one vendor for everything so you can swap a piece if you need to. The cost is integration and vendor management. I’m sure you can tell by how much detail I’ve gone into for this option that this is the direction I’m leaning towards.

What your solution can look like: a first pass

So assume you go C. What does that look like? I sketched it out to make the idea concrete.

The different contexts

The AML Ops Console is the UI your compliance and fraud teams use: alerts, customer risk, cases.

The central layer (the thing that ties everything together) is the backend that receives events, enriches them with KYC and risk data, calls screening, transaction monitoring, and fraud, then aggregates results and decides allow, hold, reject, or escalate.

KYC / Customer Profile is what you already have or extend. You can use your Smile Identity or Mono integration here. Plus your own store of customer and risk attributes.

The Screening Service is a specialist for sanctions, PEP, and watchlists e.g. Youverify plus global lists, with a real-time API. (Does Smile Identity have Nigerian watchlists? Maybe kill 2 birds with one provider.)

The Transaction Monitoring Service is a specialist for AML scenarios. Stuff like transaction thresholds, peer grouping, optional AI/ML, explainability. You should probably go international with this one.

The Fraud Monitoring Service is a real-time fraud engine. Maybe the same vendor as transaction monitoring, maybe not; either way its signals feed back into the central layer.

Case Management & Reporting handles cases plus STR/SAR/CTR/FTR/NFIU generation and submission. SoftAML might be able to do a job here.

Core Banking / Channels is your ledger and channels. This sends out transaction and onboarding events.

One flow in practice

A transaction happens in your core. It could be a transfer, card, bill, whatever. Core sends out a transaction event.

The central layer receives it. Before it does anything else, it fetches the customer profile from KYC. Who is this customer, what’s their risk rating, what do we know about them? It builds a single picture that combines the transaction, the customer, and behaviour. That’s the unified risk context.

Then the central layer calls three things (in parallel or in a defined order): screening (sanctions/PEP/watchlist), transaction monitoring (AML scenarios), and fraud (real-time patterns). Each returns a result. The matches, alerts, scores. This is what satisfies the CBN’s requirement: your transaction monitoring is not standalone. It always gets the full enriched customer context, not a raw transaction feed.

The central layer combines those results into one decision: allow, hold, reject, or escalate. If hold or reject, it tells core to block or decline. If anything crosses an alert threshold, it creates or updates a case in case management with the full context and provider results.

In the AML Ops Console, analysts see the alert list, open a case, see customer plus transactions plus screening hits plus transaction monitoring scenarios plus fraud scores, and treat: close, escalate, or mark for STR/SAR. Case management generates and submits reports to NFIU/CBN in the right formats.

Onboarding works the same way: an onboarding event hits the central layer, you enrich with KYC, you screen (and maybe transaction monitoring and fraud depending on design). If there’s a sanctions match you block and you may even open a KYC case. As you can tell already: every decision uses the full customer picture, not just the single transaction or form.

The latency problem

The flow described above, i.e. central layer calls three things, waits for results, makes a decision, is clean on a whiteboard. In production, it has a problem: you’ve just added three external API calls to your payment processing path. If screening, transaction monitoring, and fraud each take 200ms on a good day, that’s a second of added latency on every transaction, even running them in parallel. And that’s a good day.

Not all three calls need to be synchronous. That’s actually the key design decision inside Option C, and the one the architecture sketch glosses over.

Sanctions and PEP screening has to be synchronous. You cannot let a sanctioned party complete a transaction and catch it afterwards. So screening blocks the payment, which means your screening vendor’s SLA is now part of your payment SLA. If Youverify has a slow response or an outage, your transactions start hanging. You need a circuit breaker: a timeout threshold at which you decide to allow-and-flag or hold the transaction, log the vendor failure, and retroactively screen when they recover.

Fraud scoring can be synchronous if the model is fast. Modern ML fraud models can return a score in under 100ms. If your vendor hits that SLA, you run it inline. If not, you run it async and the transaction goes through, score comes back, and if it crosses a threshold you trigger a post-transaction action: freeze, alert, review. You’ll end up letting in some fraud through. But that’s the choice between real-time blocking and payment experience.

Transaction monitoring is almost always near-real-time or batch. Most AML scenarios (like velocity patterns, structuring detection) need a window of transactions, not just the current one. You can’t detect structuring on a single transaction. So TM runs asynchronously: events go into a queue, scenarios run on a look-back window, alerts land in the ops console for analyst review.

What you’re actually building in the central layer is an orchestration layer with three execution modes: synchronous screening that blocks, optional synchronous fraud scoring, and an event pipeline that feeds async transaction monitoring. Deciding which paths are synchronous, how to handle vendor failures, and how to replay missed events is where your engineers will earn their salary if Claude hasn’t rotted their brains already.

I’m not pretending this sketch is complete. You will still need to nail event formats and which systems send what. But it gives you a picture: one brain (the central layer), many specialists (screening, transaction monitoring, fraud, case/reporting), and one place for the human (ops console) to see and act on everything.

If you’re reading this and you’re in a similar seat, I hope it gives you a place to start: get clear on the problem first, then narrow down what the product must do, then sketch how the pieces fit. Unfortunately, I’m not in the trenches anymore so this is not a problem I have to solve. All I do is send “how far?” on Slack to the guy who has to build this.

(If you’re a provider of any of these tools, you could’ve bought this a sponsored post but your marketing team doesn’t want to give us money smh)

Bank transfers were not originally designed to be a consumer payment experience. They were designed as bank infrastructure: reliable, interoperable, and legible to institutions. For a long time, that was fine. Transfers were mostly B2B, payroll, or the occasional P2P payment. But in Nigeria, that world is gone. Bank transfers have become the default way people pay each other and, increasingly, the default way they pay merchants too. In practice, the rail has already won. The interface has not.

That is what makes the current state of affairs so interesting. Nigeria solved the hard part early. NIBSS launched NIP in 2011, and within a short period it had spread across the banking system. It gave the market what it badly needed: instant settlement, always-on availability, name enquiry, and transaction status checks. In other words, Nigeria spent the last decade making bank transfers fast and trustworthy. But fast and trustworthy is not the same thing as elegant. The rail matured much earlier than the interface built on top of it. One reason card payments still feel more convenient, even when transfers are faster and cheaper, is that card payments usually begin with intent. You are already at checkout. The merchant is already known. The amount is already known. In the best cases, all that is left is authorization. Bank transfers, by contrast, often begin with reconstruction. The user has to assemble the destination before the system can help. Today, a typical transfer flow still asks the user to do something fundamentally unnatural: pick a bank from a huge list, type an account number, wait for a name resolution, verify it, then proceed. We have accepted this because NIP works, because settlement is fast, and because users have built muscle memory around it. But “people can do it” is not the same as “this is good UX.” If a payment method is now mainstream consumer behavior, it should not still feel like operating a piece of financial plumbing.

The core problem here is addressing. When someone wants to send money, what they actually know is rarely “the recipient’s institution plus their 10-digit account number.” What they know is a phone number, a username, a business name, a message thread, an invoice, or just the fact that they are standing in front of the person or merchant they want to pay. The current transfer experience forces the user to translate a human intention into bank-native coordinates before the system can help them. That translation step is where a lot of friction lives.

There have been attempts to fix this, and they point in the right direction. One old but interesting idea was trying to reverse engineer the NUBAN algorithm so the bank could be inferred from the account number. That mattered because it attacked the ugliest part of the flow: the bank picker. If the system can infer the destination bank, the user only needs to supply the number. That was a meaningful improvement, especially in the USSD era, when every extra step had real cost. But it was always a partial fix, and it has become less durable over time. Newer neobanks and wallets do not always map neatly onto the assumptions behind classic NUBAN inference. Some have leaned into phone-number-based accounts or other abstractions, which improves usability locally while making the broader system feel less consistent. More recent approaches also attack the same surface from different angles. Zap by Paystack uses OCR to scan the account number so the user has less to type. That is directionally correct. If the interface is forcing manual transcription, scanning will always feel better than typing. But it is still a workaround for the same underlying issue. The user is still being asked to operate on raw bank coordinates. We have just made the data entry slightly less painful.

That is why I keep coming back to QR. NQR has always felt like the most promising path, not because QR codes are magically better, but because they let the payment start from intent instead of bank details. When a user scans a QR code, they are saying “I want to pay this person or this merchant right now.” That is a much better starting point. The frustrating part is that Nigeria already has many of the ingredients. NIP is real-time. Bank transfers are already culturally normal. Merchants and customers are used to QR scanning patterns from other ecosystems (I have a side theory that Blackberry dying changed Nigeria’s payments trajectory but that’s for another day). The missing piece is the wrapper. Other markets have shown what a better wrapper can look like. Brazil’s Pix made aliases and QR codes feel native to everyday payments. Australia’s PayID turned bank transfers into something closer to messaging by letting users send to phone numbers and emails. Poland’s BLIK built a bank-centric payment experience that feels like a consumer product rather than a bank form. Even PayPal and Venmo eventually realized that interoperability gets much better when users can pay to a shared identity surface, like a phone number, rather than moving money through a bank account as an awkward middle layer. The common pattern across all these systems is simple: the best bank-transfer experiences hide bank-transfer primitives. They do not force users to start with the routing layer. They start with something human-readable, contextual, and already present in the user’s flow. Sometimes that is an alias. Sometimes it is a QR code. Sometimes it is a merchant handoff. But the design principle is the same: reduce the amount of banking syntax the user has to manually produce. That is why I do not think the future of transfer UX in Nigeria is “a slightly better bank picker.” I think it is a move away from the bank picker as the center of the experience.

What follows are some concrete approaches that could change this. None of them require a new payment rail. They all settle on NIP. The question is what sits on top.

A national alias directory

The most straightforward fix is to replace “bank + account number” with something the user already knows. A central directory, probably operated by NIBSS, that maps aliases to bank accounts. The aliases could be phone numbers, emails, usernames, business handles, or national IDs. The user registers an alias through their bank app. From then on, anyone who wants to pay them just types the alias. The system resolves it to a NUBAN behind the scenes, shows the recipient’s name for confirmation, and proceeds. This is essentially what Australia did with PayID, what India did with UPI IDs, and what Brazil did with Pix keys. It works. It is proven. And it would immediately eliminate the bank picker and the 10-digit account number for most everyday transfers. But it has a limitation. Aliases carry identity, not transaction context. If you are paying a merchant, you still have to enter the amount yourself. The merchant’s alias tells the system where the money should go, but not how much or for what. For P2P, that is fine. For merchant payments, it means the user is still doing some of the reconstruction work. The payment does not yet start from intent.

QR with app-to-app handoff

A different approach starts from the merchant context instead of the bank app. The merchant displays a QR code, either printed or on a screen, that encodes their identity, the amount, and a reference. The user scans it with their phone camera. The device surfaces a list of compatible bank apps. The user picks one. The app opens with everything prefilled. The user authorizes and the payment settles. The key difference from the alias approach is that the payment object itself carries the full intent. The user does not type a destination. They do not type an amount. They just confirm and authorize. The bank app becomes the place of authentication, not the place where all the payment details have to be assembled by hand. This is close to how iDEAL 2.0 works in the Netherlands, how BLIK handles QR payments in Poland, and how WalletConnect works in crypto. The pattern is: scan, choose your app, approve. For online payments, the same handoff can work through deep links instead of QR codes. The checkout page triggers a link that opens the user’s bank app with the payment prefilled. The limitation here is P2P. When you are splitting dinner or sending money to a friend, there is no QR code. There is no merchant context. You are back to needing some form of addressing.

Payment links and virtual accounts

A third approach leans on payment links and per-transaction virtual accounts. Every payment request becomes a shareable link or a unique virtual NUBAN. The merchant or recipient generates it through a PSP. The link contains the recipient, amount, reference, and expiry. The user clicks it, sees a prefilled payment page, and either transfers to the virtual account from their bank app or gets handed off via a deep link. This is already happening in Nigeria through Paystack, Flutterwave, Monnify, and others. It works well for online and invoice payments. The user never has to assemble the destination. The payment object carries everything. The problem is fragmentation. These links are PSP-specific today. A Paystack link and a Flutterwave link are not interoperable. There is no shared national standard. And many of these flows land on a hosted checkout page rather than handing off directly to the user’s bank app, which introduces an intermediary layer that the other approaches avoid.

The hybrid

Each of these approaches solves a different part of the problem. Aliases are best for P2P. QR handoff is best for in-person merchant payments. Payment links are best for online and invoice payments. None of them, alone, covers the full surface. The most interesting path is probably a hybrid: a national alias directory for P2P and ad-hoc payments, QR with app-to-app handoff for merchant POS, and standardized payment links for online checkout. All three front-ends, one shared standard, all settling on NIP. This is roughly what Brazil built with Pix. Aliases, QR codes, and copy-paste keys all coexist within a single system. India’s UPI does something similar with UPI IDs, QR, and intent-based deep links. The insight in both cases is that different payment contexts need different entry points, but they should all resolve to the same settlement layer.

Again, for Nigeria, the building blocks already exist. NIP is the settlement layer. NQR is an early version of the QR piece. Bank apps already handle authorization. What is missing is the connective tissue: an open alias registry, a QR encoding standard that triggers OS-level app handoff instead of requiring users to open a specific bank app first, and a shared deep link format that payment links can use across PSPs. Who would operate this? NIBSS is the obvious candidate, given that they already run NIP and NQR. But the governance question matters. The alias directory, the QR standard, and the deep link format all need to be open enough that any bank or fintech can participate without gatekeeping.

Ayo’s card essay made the point that there was still a lot of room to innovate around a payment method people assumed was already mature. I think bank transfers are now in the same place. The rail is established. Consumer behavior is established. Merchant behavior is established. What remains underexplored is the software layer that sits on top: the addressing models, handoff patterns, and interface conventions that would make transfer payments feel as natural as the intent that triggers them.

Thank you for loving the podcast all year long!

_

We love hearing your thoughts! Find us on X (@TheOAPod) and Instagram (@openafricapod) and tag us in your conversations.

We love hearing your thoughts! Find us on X (@TheOAPod) and Instagram (@openafricapod) and tag us in your conversations.

Hosted on Acast. See acast.com/privacy for more information.

We explore LemFi’s FSCS-protected savings launch in the UK and what it means for retention beyond remittances. We also discuss Nomba’s remittance-first expansion into the DRC and Nigeria’s new National Payment Stack, built to modernise instant transfers and onboarding. 

Finally, we unpack South Africa’s Discovery Bank adding crypto integration via Luno, Chowdeck’s new airtime feature, and Wave’s evolving journey from mobile money to full bank ambitions.

_

P.s: you’ll find a suprise if you listen to the end!

_

We love hearing your thoughts! Find us on X (@TheOAPod) and Instagram (@openafricapod) and tag us in your conversations.

We love hearing your thoughts! Find us on X (@TheOAPod) and Instagram (@openafricapod) and tag us in your conversations.

Hosted on Acast. See acast.com/privacy for more information.

What Problem is the CBN Trying to Solve?

Traditional fraud typically involves someone gaining unauthorized access to your account and moving money without your knowledge. APP fraud works differently. Here, victims are tricked, manipulated, or deceived into initiating transfers themselves. The transaction appears legitimate from the bank’s perspective because all the usual authentication steps are completed by the actual account holder.

The most common scenarios involve fraudsters posing as customer support agents—often from banks or fintechs—who contact victims under the guise of resolving issues with their accounts or transactions. They trick victims into sharing sensitive information or authorizing transfers, sometimes by claiming to verify suspicious activity or refund failed payments. Because victims carry out these transactions themselves, albeit under false pretenses, recovery has historically been difficult, and banks have often disclaimed responsibility.

The CBN’s draft guidelines attempt to create a structured framework for preventing these scams, investigating them when they occur, and ensuring victims have a clear path to potential reimbursement.

How the Framework is Structured

The regulation places significant governance responsibilities at the board level of financial institutions. Boards must approve risk management policies specifically addressing APP fraud, assign oversight to the Board Risk Management Committee, and ensure the Board Audit Committee supervises investigations. The Head of Compliance becomes responsible for implementing the guidelines day to day.

This governance structure signals that the CBN views APP fraud as a systemic risk requiring senior leadership attention rather than a routine operational matter to be handled solely by fraud departments.

Financial institutions must develop comprehensive APP fraud policies covering prevention, detection, investigation, recovery, and reimbursement. These policies require board approval and must be reviewed at least every two years.

Prevention Through Early Warning Systems

A significant portion of the guidelines focuses on proactive fraud prevention through Early Warning Systems. Banks must implement monitoring capabilities that can identify accounts exhibiting suspicious characteristics before they are used to receive fraudulent funds.

The regulation contemplates both quantitative indicators like unusual transaction patterns and qualitative factors derived from market intelligence and customer conduct. Accounts identified through these systems must be flagged for enhanced monitoring or restriction pending investigation.

Banks must also establish dedicated fraud data analytics units with resources appropriate to their size and complexity. The effectiveness of these early warning systems must be tested at least twice yearly.

What Happens When Fraud Occurs

The guidelines establish clear timelines for the complaint and investigation process. Customers who fall victim to APP fraud are expected to report the incident within 24 hours, though they have up to 72 hours total to make a report. This window matters because delayed reporting can affect reimbursement eligibility.

Banks must maintain multiple reporting channels available around the clock, including hotlines, email, mobile applications, in-person options, and social media. These channels must support multiple languages and include toll-free options.

Once a complaint is received, the bank must acknowledge it within 24 hours and provide the customer with a unique case reference number along with a summary of the review process and expected timelines. The full investigation must conclude within 14 working days.

When fraud involves multiple institutions, which is almost always the case since APP fraud requires money to move from the victim’s account to a fraudster’s account at a receiving bank, the originating institution must notify other involved institutions within 30 minutes of receiving the complaint. This rapid notification requirement aims to enable faster freezing of funds before they can be withdrawn or moved further along the transaction chain.

The Reimbursement Framework

Perhaps the most significant aspect of the guidelines is the reimbursement framework. Customers who meet eligibility criteria must be reimbursed within 48 hours of a completed investigation, or within 16 working days when multiple institutions are involved.

Eligibility for reimbursement requires that all four of the following conditions are met:

• The customer authorized the transaction under false pretenses and had no reasonable cause to suspect fraud.

• The customer reported the fraud within 72 hours and fully cooperated with the investigation.

• There is no evidence of negligence, collusion, or criminal intent by the customer.

• The financial institution failed to implement appropriate fraud detection, warning, or verification protocols that could have prevented the transaction.

The regulation explicitly excludes reimbursement in certain situations. Customers who acted fraudulently or negligently are not eligible. Those who delayed reporting beyond 72 hours without reasonable justification lose eligibility, though the guidelines recognize exceptions for circumstances like illness, force majeure events, or unavailability of reporting channels. Transactions occurring before the guidelines take effect are also excluded unless banks voluntarily apply them retroactively.

Sharing the Cost

When neither the sending nor receiving institution is at fault and the customer qualifies for reimbursement, the cost is shared equally between both institutions. This creates a collective industry stake in fraud prevention since every bank potentially bears costs from fraud received at other institutions.

Institutions with inadequate fraud detection systems that fail to flag or freeze fraudulent proceeds face greater exposure and may be debited for the total amount lost. This provision incentivizes investment in detection capabilities.

The CBN has reserved authority to direct NIBSS or other settlement entities to withhold settlement for transactions identified as fraudulent. This power extends to second-level and subsequent beneficiary institutions along the transaction chain, enabling intervention even when fraudsters attempt to move funds through multiple accounts quickly.

Disputes and Escalation

Where customers are dissatisfied with investigation outcomes, they may escalate to the CBN’s Consumer Protection and Financial Inclusion Department. Similarly, when institutions cannot agree on resolution within the stipulated timelines, the matter goes to the same CBN department for decision.

This creates a regulatory backstop that should encourage good faith resolution at the institutional level while providing consumers with recourse when they believe they have been treated unfairly.

Consumer Education Requirements

The guidelines recognize that prevention requires informed consumers. Financial institutions must conduct quarterly APP fraud awareness campaigns across multiple media and languages. They must ensure customers know about available reporting channels and understand fraud risks.

Banks must also submit quarterly evidence of their financial literacy outreach to the CBN, including the number of consumers reached and languages used. This reporting requirement ensures consumer education does not become a box-ticking exercise.

Enforcement

Non-compliance with any requirement under the guidelines constitutes a regulatory breach subject to penalties prescribed by the CBN. Submitting false, misleading, or incomplete information attracts sanctions including monetary penalties and administrative actions against both the institution and responsible individuals.

What This Means in Practice

If implemented as drafted, the guidelines would create meaningful new protections for Nigerian consumers who fall victim to APP fraud. A customer deceived into paying for goods that never arrive or manipulated by a romance scammer would have a structured path to report the fraud, have it investigated within two weeks, and potentially receive reimbursement within days of the investigation concluding.

For banks, the guidelines create new operational requirements around governance, monitoring, investigation timelines, and reimbursement. Institutions will need to ensure their fraud detection capabilities are robust enough to avoid bearing disproportionate costs when fraud occurs. They will also need 24/7 reporting capabilities, rapid inter-institutional communication protocols, and dedicated fraud analytics resources.

The framework attempts to balance consumer protection with appropriate incentives. Customers retain some responsibility through the reporting timeline requirements and exclusions for negligence. Banks share collective responsibility for the fraud ecosystem regardless of where the victim account is held. And the CBN maintains oversight through reporting requirements, dispute resolution authority, and enforcement powers.

The draft is open for comment through three weeks from the circular date of November 26, 2025. Banks, other financial institutions, public interest organizations, and the general public can submit feedback to the CBN’s Financial Policy and Regulation Department.

But then Asemota and some other contrarians started posting these long-winded takes, and I realized how this could low-key confuse people who aren’t terminally fintech. So today, I’m writing this to explain what NPS is and how it’s different from NIP—so you don’t look lost when your fintech friends start talking about it.

Quick reference:

(Also, no, the CBN didn’t sell your data to China and the Soviet Union isn’t about to turn us into a Pluribus hive mind. I wish. That would be wild, but no.)

Background: Why ISO 20022?

So NIBSS is moving from NIP to NPS. It’s a shift from their own proprietary electronic funds transfer system to an ISO 20022-based international standard platform.

NIP did its job admirably. NIBSS actually shipped something useful for once, and we should give them credit for that. But at a certain point, you hit the limits of what you can do with a proprietary system. Instead of trying to patch it up, NIBSS decided to start fresh and adopt what everyone else is using: ISO 20022 messaging standard.

And yeah, this is happening everywhere. SWIFT’s been migrating to ISO 20022 for a minute now, and pretty much everyone’s hopping on this train.

SWIFT’s ISO 20022 Timeline:

- November 2022: SWIFT began supporting ISO 20022 for cross-border payments and cash reporting

- March 2023: Coexistence period started—both old (MT) and new (MX/ISO 20022) formats supported

- November 2025: All SWIFT payments must be ISO 20022 compliant

Why does any of this matter? By adopting ISO 20022 now, NIBSS is future-proofing Nigerian financial institutions. When they eventually need to integrate with SWIFT or other global systems, they’re already speaking the same language.

It’s also good for Africa’s regional trade. As AfCFTA pushes for more intra-continental commerce, having ISO 20022 makes everything smoother if all the different local payment systems have to work together.

It’s not just Nigeria doing this:

- US: Fedwire moving to ISO 20022 (2025)

- Europe: TARGET2 already migrated (2022)

- UK: CHAPS migrated (2023)

- Australia: NPP uses ISO 20022

- Singapore: FAST uses ISO 20022

So, What’s the Actual Difference?

Okay, so the transaction lifecycle is basically the same between NIP and NPS.

Civilians will probably not notice any changes, in fact.

So let me walk you through what happens when you try to transfer money in both systems:

Phase 1: Confirmation of Payee (Name Enquiry)

What goes down:

1. Customer: “I want to send ₦10,000 to account 1234567890 at Bank B”

2. Bank A asks NIBSS: “Yo, who owns this account?”

3. NIBSS routes it to Bank B

4. Bank B responds: “That’s John Doe’s account”

5. Bank A shows customer: “You’re sending to John Doe—that right?”

This first step prevents you from sending money to the wrong person. Can’t be overstating how useful this is, but some people **cough…OPay** don’t run this step every time.

Where they differ:

- NIP: Uses Name Enquiry (10 second timeout)

- NPS: Uses acmt.023/024 message format (20 second timeout)

Same vibe, different message format. That’s really it.

Phase 2: The Payment Processing

Step 1 — Bank A Initiates

- Customer: “Okay, go ahead”

- Bank A debits the account immediately (₦10,000 + fees)

- Bank A sends payment instruction to NIBSS

- Bank A’s settlement account gets marked for debit

Step 2 — NIBSS Does Its Thing

- Validates the message format is legit

- Checks that Bank A is actually authorized to do this

- Very Important Step: Makes sure Bank A has enough funds in their settlement account.

- Routes the payment to Bank B

When MoMo PSB launched, NIBSS actually skipped the very important step in their early days because “…it’s MTN. Surely, they’re good for the money.” Well, MTN cooked one beans that led to massive fraud and NIBSS was fulfilling payments that weren’t backed by what MoMo had in the bank. 

Step 3 — Bank B Receives It

- Gets the payment instruction

- Validates that John Doe’s account exists and can receive funds

- Has to respond within the timeout window or the transaction fails

Step 4 — What Happens Next (Two Scenarios)

Everything works:

- Bank B responds positively

- NIBSS tells both banks it’s good

- John Doe’s account gets credited

- Settlement positions get updated

Something goes wrong:

- Bank B rejects it (or just times out)

- NIBSS tells both banks it didn’t work

- Bank A reverses the customer’s debit right away

- Nothing settles

Phase 3: End-of-Day Settlement

Throughout the day, transactions flow in both directions. When it’s time to settle, here’s what happens:

Quick example:

- Bank A sent ₦1M to Bank B

- Bank B sent ₦800K back to Bank A

- Net: Bank A owes Bank B ₦200K

Real money moves between banks’ accounts at the CBN, and you get reconciliation reports.

What’s true for both NIP and NPS:

- Your bank debits you immediately when they send the payment

- The beneficiary only gets credited after their bank confirms it’s legit

- Timeout = transaction fails. You get your money back

- Settlement happens later, but it’s net—so if banks exchange money both ways, only the difference settles

- Once both banks confirm, that’s it. No take-backs. Payment’s final

- NIBSS doesn’t actually hold any money. It just routes messages and keeps score of who owes whom

Where NPS Actually Changes Things

Okay, so the response choreography is where NPS actually does something different.

Response Choreography

NIP: One-step process

Bank B gets payment → Responds yes/no → Done

NPS: Two-step process

Bank B gets payment → Sends “AUTH” (I authorize this) → Switch confirms “ACSP” (okay, finalize it) → Customer gets credited

It seems long so why change? Better coordination between banks, easier error handling, and it aligns with what everyone else is doing internationally etc

But the end result is the same.

Payment either succeeds (everyone agrees) or fails (someone rejects or times out).

Payment Finality & Uncertainty Handling

The Problem (Same for Both)

Network timeouts are annoying: “Did the beneficiary bank actually process this or nah?”

NIP’s Way: Manual & Reactive

- Bank has to send a TSQ (Transaction Status Query)

- Might need to retry multiple times

- Bank figures out what to do based on the response

- Result: More ambiguity, more manual work

NPS’s Way: Automated & Proactive

- The switch itself times out after 10 seconds

- Switch automatically sends RJCT (rejection) to both banks

- Clearer decision tree (AUTH → ACSP)

- Result: Less confusion, less manual intervention

NPS makes life easier by having the central switch handle timeouts instead of leaving banks to sort it out themselves.

The Key Operational Differences

1. Timeout Architecture

NIP: Pretty straightforward

- Single timeout: 20 seconds, end-to-end

- Name Enquiry: 10 seconds

NPS: More layered

- Customer → Bank A → NPS: 20 seconds

- NPS → Bank B: 10 seconds

- Name Enquiry: 20 seconds

Bank B basically has half the time to respond now. NPS has introduced a tighter SLA.

2. Payment Authorization Model

NIP: One-shot deal

- Send payment → Get yes/no → Done

NPS: Needs both banks on the same page

- Step 1: Bank B sends AUTH (authorization) within 10 seconds

- Step 2: Switch confirms ACSP (acceptance) to finalize

- Both banks wait for ACSP before they finalize anything

There’s more back-and-forth between banks, but what’s happening is clearer and there’s less room for confusion.

4. Response Codes

NIP: Custom NIBSS codes

- Example: Code 25 = transaction not found

- Made-up numbering system

NPS: Uses global ISO 20022 codes

- AUTH (Authorized)

- ACSP (Accepted)

- RJCT (Rejected)

- NAUT (Not Authorized)

5. Transaction Types

NIP has a bunch:

- Direct Credit ✓

- Direct Debit ✓

- Mandate Advice ✓

- Amount Block/Unblock ✓

- Account Block/Unblock ✓

- Financial Institution List ✓

NPS (v1.0) is scaled back:

- Identification Verification ✓

- Payment Request ✓

- Payment Status Request ✓

NPS is launching with just core payment stuff. Everything else is coming later. Things like direct debit will run on NIP until they’re migrated to NPS

6. Platform Scope

NIP: Just payments

- That’s all it does

NPS: Way more ambitious

- “Payment AND non-payment capabilities”

- Built to scale

- Account verification, KYC checks, etc. can be added without building a new platform

7. Account Designation

NPS adds a new field: Account Designation (customer type):

- Corporate

- Individual

- Joint

- Others

- Juvenile

- Sole Proprietorship

When the new tax regime kicks in, this is going to be very very important. Sorry to you tax dodgers.

So What Does It All Mean?

NPS is just NIP rebuilt in line with global best practice.

What’s actually changing: Message formats, how banks coordinate, timeout logic, and operational stuff.

What’s the same: The core flow still goes debit → validate → route → credit → settle. That’s not changing.

For now, it focuses on bank transfers. But expect card payments and other payment methods to align with ISO 20022 in the coming months too.

_

We love hearing your thoughts! Find us on X (@TheOAPod) and Instagram (@openafricapod) and tag us in your conversations.

We love hearing your thoughts! Find us on X (@TheOAPod) and Instagram (@openafricapod) and tag us in your conversations.

Hosted on Acast. See acast.com/privacy for more information.

The review became necessary due to the expansive nature of the Agent banking ecosystem and the increasing “sophistication of Agent banking operations due to technological advancement”. Issued pursuant to the CBN Act 2007 and the Banks and Other Financial Institutions Act (BOFIA) 2020, the 2025 Guidelines seek to consolidate all extant policies into a single document to comprehensively address emerging issues.

The objectives of the new Guidelines are to provide minimum standards, enhance Agent banking as a delivery channel for offering financial services to drive financial inclusion, and encourage responsible market conduct and improve service quality.

Here are the most significant regulatory and operational changes introduced by the 2025 Guidelines:

1. Mandatory Exclusivity for Agents

The structure of the Agent-Principal relationship has undergone a fundamental change.

• 2013 Policy: The older guidelines stipulated that there shall be “no exclusivity of agent banking contracts”. An Agent was permitted to “provide agent-banking services to as many FIs as it can accommodate at any given time”.

• 2025 Policy: The new guidelines strictly mandate that Agents shall be exclusive to one Principal only. An Agent is not allowed to be appointed by another Principal until the expiration of any existing Agent Banking Agreement.

However, Super Agents retain flexibility, as they may still be contracted by more than one Principal.

2. Strict New Identification and Due Diligence Requirements (KYA)

The 2025 Guidelines impose rigorous steps for Principals (or Super Agents) to vet Agents, known as Know Your Agent (KYA).

• Mandatory IDs: Onboarding requires furnishing extensive personal identification data. This includes the Bank Verification Number (BVN) and National Identity Number (NIN) for prospective individual Agents and designated employees of non-individual Agents. Non-individual Agents must also provide a Tax Identification Number (TIN) and a 3-year Tax Clearance Certificate.

• Biometric Data and GPS: The KYA registration process involves profiling the appointed Agent’s information, including biometric data collection and GPS locations, on the database of the Agent network.

• Non-Performing Loans (NPLs): An individual or entity is now disqualified from appointment or renewal if they have a non-performing loan with any Financial Institution (FI) in the last 12 months preceding the appointment date. (The 2013 rules also disqualified Agents if they were classified as a non-performing borrower in the 12 months preceding the contract signing).

• Device Linking: The BVN of designated employees and the TIN of non-individual Agents shall be linked to any electronic device deployed for Agent banking operations.

3. Fixed Maximum Transactional Limits Imposed

While the 2013 Guidelines required FIs to set limits that were “prudent” and based on risk associated with the agent’s locality, the 2025 Guidelines introduce specific transaction limits:

• Daily Cash-in (deposit): ₦100,000

• Weekly Cash-in (deposit): ₦500,000

• Daily Cash-out (withdrawal): ₦100,000

• Weekly Cash-out (deposit):₦500,000

• Daily Bill Payments: ₦100,000

Additionally, the Principal must ensure that each Agent’s daily cumulative cash-out limit does not exceed ₦1,200,000.00.

4. New Operational Security and Accountability Mandates

The 2025 guidelines introduce specific technical and procedural controls:

• Dedicated Agent Accounts: Agent banking transactions must be conducted through a dedicated account/walletwith the Principal. Operating outside this account is a violation, and the Agent shall be personally liable for any misconduct, fraud, or related offences arising from such unauthorized activity.

• Geo-Fencing: Any device deployed to an Agent shall be geo-fenced or tagged to operate strictly within the agreed registered Agent premises or location. Payment Terminal Service Aggregators (PTSAs) are responsible for facilitating this geo-fencing.

• Two-Factor Authentication (2FA): Agent banking IT systems must ensure a minimum of Two-Factor Authentication (2FA) per customer, per transaction.

• Faster Complaint Resolution: The Principal must ensure all customer complaints are resolved within a reasonable time, not later than seven (7) working days from the date of reporting. (The 2013 Guideline allowed up to fourteen (14) days).

• Card Neutrality and Agent Code: Principals must ensure all PoS terminals deployed are configured to accept transactions from all cards issued by Nigerian banks, meaning Principals must be card-neutral entities. Furthermore, Agents must apply the approved Agent Code 6010 for Agent banking activities to clearly demarcate them from merchant activities.

5. Increased CBN Oversight and Regulatory Scope

The CBN has strengthened its reporting requirements and regulatory definitions.

• Expanded Stakeholders: The guidelines formally recognize Payment Terminal Service Aggregators (PTSAs) as key stakeholders. PTSAs are required to register PoS terminals, facilitate geo-fencing, and integrate their systems with the CBN Automated Regulatory Data Solutions (CARDS).

• AML/CFT/CPF Compliance: The anti-financial crime requirements have expanded from Anti-Money Laundering and Combating the Financing of Terrorism (AML/CFT) to include Countering Proliferation Financing (CPF), referred to as AML/CFT/CPF.

• Real-Time Transaction Reporting: Principals must ensure that all daily transactions per agent, including withdrawals, limits, and balances in dedicated agent accounts, are sent electronically to NIBSS for forwarding to the CBN.

6. Non-Permissible Activities

The Guidelines specify actions that Agents and Super Agents are explicitly forbidden from undertaking.

In addition to general prohibitions like opening accounts, carrying out loan underwriting, or engaging in foreign currency transactions, the 2025 Guidelines explicitly state that the “Use of non-human/automated machines as Agents” is a non-permissible activity. This ensures that Agent banking services must be provided by either an Individual Agent (a natural person) or a Non-Individual Agent (an incorporated entity with designated human employees).

This specific prohibition appears to pre-emptively shut down the possibility of using automated or remotely operated financial kiosks, smart ATMs, or decentralized autonomous agents as part of the formal Agent network, regardless of the security or accessibility benefits they might offer.

Read the full circular HERE.

_

We love hearing your thoughts! Find us on X (@TheOAPod) and Instagram (@openafricapod) and tag us in your conversations.

We love hearing your thoughts! Find us on X (@TheOAPod) and Instagram (@openafricapod) and tag us in your conversations.

Hosted on Acast. See acast.com/privacy for more information.

_

We love hearing your thoughts! Find us on X (@TheOAPod) and Instagram (@openafricapod) and tag us in your conversations.

We love hearing your thoughts! Find us on X (@TheOAPod) and Instagram (@openafricapod) and tag us in your conversations.

Hosted on Acast. See acast.com/privacy for more information.

On this episode of the podcast, we had a guest join us. Osarumen stopped by to chat about his latest work, foodpod, a limited series about technology eating food in Africa.

Read the first post below:

They talk about the recent collapses of Vendease and Okra in the ecosystem, then take a closer look at Magic Beans, the first chapter of Foodpod – a limited series about Technology eating food in Africa – by Osarumen.

_

We love hearing your thoughts! Find us on X (@TheOAPod) and Instagram (@openafricapod) and tag us in your conversations. 

We love hearing your thoughts! Find us on X (@TheOAPod) and Instagram (@openafricapod) and tag us in your conversations.

Hosted on Acast. See acast.com/privacy for more information.

_

We love hearing your thoughts! Find us on X (@TheOAPod) and Instagram (@openafricapod) and tag us in your conversations.

Hosted on Acast. See acast.com/privacy for more information.

In our previous post, we clarified how Nigerian banks generate most of their revenue, not from transfer charges but primarily from lending and investments. Naturally, this leads us to another critical question:

Why do so many Nigerian Businesses find it difficult or even frightening to borrow from banks?

If you've ever considered taking a business loan from a traditional Nigerian bank, chances are you've either heard stories or personally experienced how intimidating the process can be. High interest rates, stringent conditions, collateral requirements, and mountains of paperwork often discourage potential borrowers. Today, we unpack these scary terms and conditions and explain why borrowing from Nigerian banks feels like an obstacle course.

Interest Rates: The Big, Scary Numbers

Most banks price loans around the Central Bank of Nigeria’s Monetary Policy Rate (MPR) which is currently at 27.5% as of February 2025. Banks add their margin on top MPR. Depending on the bank and how well your business negotiates, interest rates can range between 25% to 33% per annum.

Let’s take 29% as an example and show how it translates practically for borrowers:

Imagine borrowing ₦10 million from a Nigerian bank at the current prevailing interest rate of 29% per annum. Here’s what your repayment obligations would look like for different tenors:

Now imagine ₦500 million

Are you starting to see how banks make really good interest income? With longer tenors, monthly repayments are smaller and more manageable, but the total amount repaid increases significantly due to accumulating interest. Longer-term loans make it more manageable for the borrower to service the loan. On the flip side, longer tenor loans mean more risk but also more interest income for the banks.

Conditions Precedent: Everything You Need to Provide Before You See a Kobo

Before accessing the funds, borrowers must meet conditions, including:

• Board Resolutions: Yes, even if your “board” is just you and your cousin. The bank needs it signed, sealed, and officially approved acceptance of the loan.

• Exclusive Banking Arrangement: Commitment to domicile all revenue exclusively with the bank.

• Legal Documentation:

  • Letter of Set-Off: Giving the bank the power to deduct loan repayments directly from your other accounts with them if you’re behind schedule.

  • Personal Guarantees: Basically, the bank asks directors or major shareholders to back the loan personally. If your business can’t repay, you and other guarantors will become personally liable.

• Collateral: Banks usually require assets such as property, vehicles, stocks, or bonds that the bank can sell off if you default on your payments. Collateral value must often exceed the loan amount, sometimes significantly, just in case asset values drop.

• Legal and Credit Checks: Expect thorough credit checks on your company and its directors. This process includes verifying your credit history, reviewing existing obligations, and examining potential legal disputes.

These conditions often take weeks to fulfil, they are not all free to get done and they can cause delays.

Fees, Fees, and More Fees

Banks don’t just charge interest; there are additional non-refundable fees. These fees vary by bank:

• Management Fee: Typically 0.5% - 2% of the loan amount, payable upfront as soon as you accept the loan.

• Commitment Fee: 1% on any amount not drawn during the loan’s availability period.

• Late Payment Penalties: An additional 1% monthly charge on overdue repayments, compounded by regular interest rates.

Why All These Measures?

Banks aren't just being difficult for fun. Lending is inherently risky, and Nigerian banks are particularly cautious because they lend depositors' funds. Yes, your and my deposits. As custodians of depositors' funds, banks have the responsibility to evaluate potential borrowers to safeguard against default. The reality is that banks have little incentive to loosen these measures in an uncertain economic environment, and we are all very aware of just how volatile the Nigerian economic environment can be.

Given these conditions, it's clear why many Nigerians shy away from traditional bank loans. The difficult terms, high interest rates, collateral requirements, and intense scrutiny can discourage businesses, particularly SMEs, from accessing formal credit.

The Bottom Line

Borrowing from Nigerian banks isn't impossible, but it's definitely not for the faint-hearted. Know what you're getting into. If you’re going to make an attempt you have to be armed with patience, paperwork, and a clear repayment plan.

Read our substack about Bank Charges here

_

We love hearing your thoughts! Find us on X (@TheOAPod) and Instagram (@openafricapod) and tag us in your conversations. 

Hosted on Acast. See acast.com/privacy for more information.

Let’s use Zenith Bank as an example, as they are one of the banks that have declared over a trillion naira in PBT. If you’re not a finance buff, try to stay with us. We promise it’ll all make sense.

Let’s start by summarizing their financial performance for the last two years.

Finance buffs can skip this next part. Here’s a simple explanation for each of these metrics.

• Gross Earnings: The total revenue from all banking activities, both interest and non-interest income.

• Interest & Similar Income: The income earned primarily from loans and investments in fixed income securities (e.g., treasury bills, government bonds, etc.)

• Interest Expense: The money paid to customers for their savings and fixed deposits, and the cost of borrowing other funds.

• Net Interest Income: The difference between interest earned and interest paid. It shows the profitability of core lending activities. This is important.

• Impairment Charge: The money used to cover potential loan losses due to credit risks or defaults (customers not paying back).

• Non-interest Income: Revenue from fees, commissions, FX trading, and other non-lending services. This is what people think Banks make the bulk of their money from.

• Operating Expenses: Costs incurred in running the bank’s operations, excluding interest and impairments.

• Profit Before Tax (PBT): Earnings before tax obligations, reflecting operational and investment performance.

• Profit After Tax (PAT): Net income available to shareholders after deducting taxes.

• Earnings Per Share (EPS): Portion of profit allocated to each outstanding share, indicating shareholder value.

Zenith Bank made a ridiculous amount of money for a bank, by Nigerian standards. In an economy where many people are struggling and businesses are closing down, their trillion-naira profits almost seem immoral. But when you take a look at how this revenue was generated, it paints a different picture.

With over 30 million accounts, Zenith Bank made NGN1.1 trillion in non-interest income. Account maintenance charges brought in about NGN73 billion, while transfers generated around NGN80 billion. Together, these fees only made up about 4.64% of their total NGN3.9 trillion earnings in 2024.

Where did the bulk of the N3.9 trillion then come from? Let’s have a look at the earnings from lending and investments.

Interest and similar income amount to NGN 2.72 trillion, representing about 68.5% of the total gross earnings.. This is way more significant than the 4.64% from bank charges and transfers. Also important to note is that the bank saw a 135% increase in Net Interest Income from the previous year, and this increase happened because interest rates went up significantly.

The explanation for why interest rates went up will require us to delve (no GPT) into the work of the Central Bank of Nigeria (CBN), but for this article, just know that the CBN increased their interest rates significantly and this made the interest rate of both savings and loans to rise across banks and other financial institutions in the country. Zenith Bank also made NGN331 billion from treasury bills and NGN558 billion from Bonds, amounting to about 22.4% of gross earnings.

Simply put: Most of Zenith Bank's money came from lending activities and investments, not from your transfer fees.

Most commercial banks in Nigeria will have an income structure similar to this; the bulk of their revenue will come from lending and investments, and some change from transfers and account maintenance charges. Stanbic IBTC’s interest income accounts for about 68.8% of gross earnings, and in FCMB, it is even higher at 78.3%, with gross earnings being NGN823.31 billion and NGN794.4 billion, respectively.

This also debunks the notion that banks don’t lend money. It’s an inaccurate idea that, unfortunately, has gained traction in public opinion. Our theory suggests that individuals who make unsuccessful loan requests are the most vocal, while those who have access to loans from banks remain silent. This creates a cycle where the most negative voices are reinforced and amplified by people with similar experiences.

The reality is that banks are very careful about who they lend money to. A large chunk of the money they lend comes from customers’ deposits, and they have a responsibility to customers to ensure that the money does not get lost to borrowers who don’t pay back.

Imagine if your bank told you that they were taking money out of your account to give to some tech bro in Yaba who wants to buy a PS5, and works for a company that hasn’t paid his salary in the last 2 months.

Would you be excited about it?

In a sense, in lending with customers’ deposits, banks must have that same ick, and only choose to lend to people and businesses that they can see a straight line to repayment. This means even if you're financially responsible with a good job, banks might still refuse you a loan if they can't verify your finances, don't know enough about your employer, or don't have collateral to secure the loan.

This explains why many people don't qualify.

How to position yourself for bank financing deserves its own discussion, but I hope this clarifies how banks really make their money and why the money was moneying this year.