Moving a bank onto Nigeria's next payment rail

In June 2025, NIBSS launched the National Payment Stack, the next-generation payment infrastructure designed to modernise and eventually supersede the legacy NIP ecosystem. NPS is not an upgrade. It is a full architectural shift: real-time settlement, ISO 20022 messaging, Request-to-Pay, Direct Debit, bulk and single payments on a single rail, automated reconciliation, and advanced dispute management.

For Stanbic IBTC, that meant aligning core banking, digital channels, middleware, compliance, operations, and treasury simultaneously. I was the Business Analyst and Project Manager on the program, holding the delivery together across all of those moving parts and ensuring reconciliation was built correctly from the start.

The legacy NIP infrastructure ran on SOAP-based messaging with a narrower data model. NPS runs on ISO 20022 XML, a richer, globally interoperable standard that carries significantly more information per transaction: purpose codes, structured remittance data, end-to-end identifiers, and ultimate debtor and creditor fields. Migrating to it required rethinking data models, updating core banking interfaces, rewriting reconciliation logic, and redesigning fraud and dispute workflows across the board.

Every digital channel the bank operates had to be assessed, mapped, and aligned to the new rail. A change of this scale, touching this many systems simultaneously, had the potential to create operational chaos if it was not sequenced carefully and governed tightly. And in a real-time payment environment processing millions of transactions across multiple channels, any gap in the reconciliation design creates exposure immediately.

• Real-time settlement leaves no slackWhen every transaction settles instantly, any mismatch between what the channel initiated, what the switch processed, and what NIBSS settled becomes an immediate discrepancy. In a high-volume environment those discrepancies compound fast.
• NIBSS certification gatesProduction access was gated on certification across sandbox, functional, and production environments. Internal test results had to map to the acceptance criteria NIBSS used for approval.
• Organisational surface areaCore banking has different release cycles from digital channels. Compliance has different sign-off requirements from operations. The program touched teams that do not naturally coordinate with each other.
• A richer standard than the systems it lands onISO 20022 introduces data fields and message structures that did not exist in the legacy NIP model. Internal systems, and the fraud rules that depended on the old message structure, had to grow to hold it.

Internally: core banking, digital channels, middleware, compliance, operations, treasury, and the reconciliation team, plus channel owners across mobile banking, internet banking, USSD, agent banking, ATMs, POS and NQR, and in-branch systems. Externally: NIBSS, whose sandbox access, test scenarios, and certification requirements I owned the relationship for throughout the integration.

I set up the cross-functional RACI, delivery tracker, and steering cadence that kept every team aligned on dependencies, milestones, and blockers, so that a program touching this many systems moved as one delivery rather than seven parallel ones.

The analytical core of the program was translating the NIBSS NPS technical specification into requirements each workstream could act on. ISO 20022's new fields and message structures had to be mapped to internal data structures field by field; getting that mapping right was a prerequisite for everything downstream, so it ran as its own workstream with a formal sign-off confirming every field was accounted for before testing started.

In parallel, every consuming channel got its own change impact assessment, defining what the migration meant for that channel's integration, testing requirement, and go-live readiness gate.

Two principles carried the program. First, reconciliation was treated as the critical path, not an operational afterthought. NPS has automated reconciliation built into the rail, but the bank's internal processes had to be redesigned to consume it correctly, and that design was validated during pilot testing before full cutover.

Second, nothing went live unproven. Each channel passed its own end-to-end validation before enablement, testing ran as a structured multi-phase program rather than a single UAT cycle, and operational readiness, from customer support procedures to fraud monitoring rules and business continuity plans, was a delivery requirement gated before cutover.

• option 01Minimum-compliance adapter over the legacy data modelTranslate ISO 20022 messages down into the existing internal structures and discard what does not fit. Fastest to build, but it would throw away the richer transaction data the new standard exists to carry and leave fraud and reconciliation logic blind to it.
• option 02Big-bang enablement of every channel at onceOne cutover date for all seven-plus channels. Operationally simplest to schedule and operationally riskiest to live through: a defect in any channel becomes an incident across all of them simultaneously.
• option 03Full data model migration with per-channel readiness gatesThe chosen path. Expand the internal data model to carry ISO 20022 properly, update the interfaces and fraud rules that depend on it, and enable each channel only when its own end-to-end validation passed.

• Data model depth over adapter speedExpanding the internal data model meant more work for the data and middleware teams and a rewrite of fraud rules tied to the old message structure. The payoff is a bank that actually uses what ISO 20022 carries instead of merely surviving it.
• Gated channel readiness over a single cutover datePer-channel validation and readiness gates made the program schedule longer and the tracking heavier. In exchange, no channel could take the rail down for the others, and no channel went live on hope.
• Operational readiness as a delivery gate over a faster go-liveHolding cutover until support procedures, incident workflows, fraud monitoring, and BCP were signed off delayed nothing that mattered and prevented the classic failure mode: a technically successful migration that operations cannot run.

1. 01. Requirements elicitation across workstreamsTranslated the NPS technical specification into actionable requirements with core banking, digital channels, middleware, and compliance teams.
2. 02. Program governanceEstablished the cross-functional RACI, delivery tracker, and steering cadence across teams with different release cycles and sign-off requirements.
3. 03. ISO 20022 data migrationFacilitated the data mapping sessions, owned the field-level sign-off, and coordinated the internal data model expansion and fraud rule updates.
4. 04. NIBSS coordinationManaged sandbox access, coordinated test scenarios with the NIBSS technical team, and tracked certification requirements through to production approval.
5. 05. Testing programStructured and ran the phases: sandbox, functional, negative scenario, performance and load, security, settlement validation, dispute simulations, and production certification, with readiness gates between them.
6. 06. Reconciliation designDefined the reconciliation rule matrix, exception taxonomy, resolution SLAs, and dispute workflows with the reconciliation team, validated during pilot testing before cutover.
7. 07. Channel readiness and cutoverRan change impact assessments and readiness gates per channel, then led cutover planning with customer support, incident management, fraud monitoring, and BCP signed off before the date.

The integration connects the bank's core banking platform and every consuming digital channel to the NPS rail over ISO 20022 XML, with the NIBSS dispute portal integrated for single and bulk filing and observability tooling watching the flow in production.

The reconciliation layer is where the architecture earns its keep. Match keys were defined for ISO 20022 transactions using the end-to-end identifiers that replace legacy session IDs; core banking postings reconcile against the NIBSS settlement file; and an exception handling workflow catches transactions that cannot be auto-matched. The reconciliation rule matrix covers every transaction state, completed, failed, reversed, pending, and disputed, and the exception taxonomy defines how each mismatch is routed, who resolves it, and on what SLA.

NIBSS certification achieved across sandbox, functional testing, and production environments. All digital channels enabled on the NPS rail: mobile banking, internet banking, USSD, ATM, agent banking, POS and NQR, and in-branch. Automated reconciliation and dispute management operational from Day 1 of go-live, not retrofitted after the fact.

Operational readiness landed alongside the technical integration, with customer support procedures, fraud monitoring rules, and business continuity plans signed off before cutover. The bank moved to the next generation of Nigeria's payment infrastructure with every system aligned, every channel validated, and every operational process in place.

• ›In real-time payments, reconciliation is the product. Building the rule matrix, exception taxonomy, and SLAs before cutover is the difference between an operations team working from clean data and one chasing individual transactions manually.
• ›Field-level sign-off is cheap insurance. Confirming every ISO 20022 field was accounted for before testing started meant defects found later were behavioural, not structural.
• ›A migration is done when operations can run it, not when the integration passes. Treating support procedures, fraud rules, and BCP as delivery requirements is what made go-live uneventful.