Stanbic IBTC: NIBSS National Payment Stack Integration
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, this meant aligning core banking, digital channels, middleware, compliance, operations, and treasury simultaneously. I was the Business Analyst and Project Manager on this programme, holding the delivery together across all of those moving parts and ensuring reconciliation was built correctly from the start.
NPS Rail
NIBSS National Payment Stack (ISO 20022): full migration from legacy NIP infrastructure
7+ Channels
Digital channels enabled: mobile, internet, USSD, ATM, agent banking, POS/NQR, in-branch
Certified
NIBSS certification achieved across sandbox, functional, and production environments
Day One
Automated reconciliation and dispute management operational from go-live, not retrofitted after
The Problem
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.
What I Did
1. Requirements elicitation across all programme workstreams
Working with core banking, digital channels, middleware, and compliance teams, translated the NIBSS NPS technical specification into requirements each team could act on. ISO 20022 introduces data fields and message structures that did not exist in the legacy NIP model. Mapping those fields to internal data structures was its own workstream, and getting the mapping right was a prerequisite for everything downstream.
2. Programme governance structure
NPS integration at a bank the size of Stanbic IBTC involves teams that do not naturally coordinate with each other. Core banking has different release cycles from digital channels. Compliance has different sign-off requirements from operations. Set up the cross-functional RACI, delivery tracker, and steering cadence that kept every team aligned on dependencies, milestones, and blockers throughout the delivery.
3. Stakeholder coordination with NIBSS
Owned the relationship with NIBSS throughout the integration. This included managing access to the NIBSS sandbox environment, coordinating test scenarios with the NIBSS technical team, tracking certification requirements, and ensuring that internal test results mapped to the acceptance criteria NIBSS used for production approval.
4. ISO 20022 data migration workstream
The shift from legacy message formats to ISO 20022 required the data and middleware teams to expand the bank's internal data model, validate richer transaction attributes, and update fraud detection rules that relied on the old message structure. Facilitated the sessions that produced the data mapping documentation and owned the sign-off process that confirmed every field was accounted for before testing started.
5. Testing programme management
Testing for an NPS integration is not a single UAT cycle. It covers sandbox testing, functional testing, negative scenario testing, performance and load testing, security testing, settlement validation, dispute simulations, and production certification. Structured the testing phases, coordinated the teams responsible for each, tracked defect resolution, and managed the readiness gates that determined when the programme was clear to move forward.
6. Reconciliation requirements design
Designed and owned reconciliation requirements alongside the reconciliation team. Defined the reconciliation rule matrix, the exception taxonomy, the SLAs for failed transaction resolution, and the workflows for dispute management under the new rail. Validated during pilot testing before full cutover, ensuring the operations team was working from clean data rather than chasing individual transactions manually.
7. Digital channel readiness across all consuming channels
Coordinated channel owners across mobile banking, internet banking, USSD, agent banking, ATMs, POS and NQR, and in-branch systems. Each channel had its own change impact assessment, testing requirement, and go-live readiness gate. No channel went live before its integration had been validated end to end.
8. Cutover planning and operational readiness
Technology go-live was only part of the picture. Led cutover planning and ensured that customer support procedures, incident management workflows, fraud and security monitoring rules, and business continuity plans were all updated and signed off before the cutover date. Operational readiness was treated as a delivery requirement, not a post-go-live activity.
Why Reconciliation Was the Critical Path
Real-time payments create an operational challenge that batch-settlement systems do not have. When every transaction settles instantly, any mismatch between what the channel initiated, what the switch processed, and what NIBSS settled creates an immediate discrepancy. In a high-volume environment, those discrepancies compound fast.
NPS has automated reconciliation built into the rail. But the bank's internal reconciliation processes had to be redesigned to consume it correctly. That meant defining the match keys for ISO 20022 transactions, the end-to-end identifiers that replace legacy session IDs, specifying how the bank's core banking postings would be reconciled against the NIBSS settlement file, and designing the exception handling workflow for transactions that could not be auto-matched.
The reconciliation rule matrix covered every transaction state: completed, failed, reversed, pending, and disputed. The exception taxonomy defined how each type of mismatch would be routed, who was responsible for resolution, and what the SLA was. The dispute management integration tied the bank's internal chargeback process to the NIBSS dispute portal, including both single and bulk dispute filing.
Technical Stack
Payment Rail
NIBSS National Payment Stack (NPS)
Messaging Standard
ISO 20022 XML
Core Banking
Finacle
Dispute Management
NIBSS Dispute Portal (single and bulk filing)
Monitoring
Prometheus, Dynatrace
Project Tracking
Jira + Confluence
Collaboration
Microsoft Teams + SharePoint
Artefacts Delivered
The Outcome
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 delivered 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.