Designing an API gateway for Nigeria’s open banking ecosystem
Nigeria’s move toward open banking created a need for a shared layer that could help financial institutions and third-party providers connect through one standard. I designed the experience for an open-source API gateway that would sit between API Providers and API Consumers, making onboarding, API access, monitoring, and compliance easier to manage.
The product had to support a complex ecosystem without making the experience feel complex. My role was to translate regulatory, technical, and workflow requirements into a clear product experience for banks, fintechs, developers, and operational teams.
Why this needed to exist
Nigeria’s financial ecosystem has many banks, fintechs, and developers trying to build connected financial products. But without shared API standards, integration can become slow, expensive, and difficult to scale.
Each institution may expose APIs differently, which creates extra work for fintechs and technical teams. Smaller institutions can also be left behind because building and maintaining custom API infrastructure requires time, money, and technical capacity.
The API gateway was designed to reduce that fragmentation by creating a shared, standards-based layer for open banking participation.
Where the experience needed clarity
The product needed to solve three experience challenges:
1. Fragmented integrations
Fintechs and third-party providers often had to integrate with institutions one by one, increasing technical overhead and time-to-market.
2. Inconsistent standards
Different API structures and documentation patterns made it harder for teams to build scalable integrations.
3. Access barriers for smaller institutions
Not every financial institution had the resources to build a complete open banking API layer from scratch.
The design challenge was to make a highly technical, compliance-heavy system feel structured, usable, and approachable.
My role
I worked as the Product Designer, translating open banking requirements and technical workflows into a usable product experience.
My work included:
- Studying open banking API specifications and operational requirements
- Understanding the needs of API Providers and API Consumers
- Mapping workflows for onboarding, authentication, API management, reporting, audit trails, and team management
- Designing the dual-portal experience for both user types
- Creating consistent interface patterns for shared modules
- Collaborating with engineers and stakeholders to refine feasibility, permissions, and edge cases
Goals
The gateway needed to:
- Make adoption easier for institutions and third-party providers
- Lower the effort required to expose, consume, and manage open banking APIs
- Support compliance through traceability, permissions, security, and auditability
- Give technical teams enough visibility to monitor API usage and integration health
- Create a scalable foundation for the wider open banking rollout
How I designed the gateway experience
1. Designing around two user types
The product was structured around two primary users: API Providers (APs) and API Consumers (ACs).
API Providers needed control, visibility, and governance. They needed to manage API collections, configure endpoints, monitor consumer activity, review performance, and maintain auditability.
API Consumers needed speed and autonomy. They needed to discover available APIs, understand documentation, test integrations, manage credentials, and track usage.
Instead of forcing both groups into one generic experience, I designed a dual-portal structure. Each user type had its own dashboard, onboarding, and management workflows, while shared modules like reports, audit trails, team management, and security followed consistent patterns.
This made the product easier to scale because shared systems could remain consistent while still adapting to each role’s context.
2. Making API management easier to understand
I designed the API collection experience to help users understand what APIs were available, how they were grouped, and what actions could be taken on each endpoint.
For providers, the interface focused on management: configuring collections, reviewing endpoints, and controlling how APIs were exposed.
For consumers, the interface focused on exploration and integration: viewing available collections, understanding endpoint details, and accessing the information needed to build with them.
The goal was to reduce the cognitive load of working with multiple APIs by giving users a clear structure for navigating collections, endpoints, and configuration states.
3. Giving technical teams visibility into performance and activity
Because the gateway sits between institutions and third-party providers, visibility was critical.
I designed dashboards and activity views that helped users monitor API consumers, API calls, success rates, response time, and integration activity. Detailed activity pages also gave teams access to request and response information, making it easier to investigate issues and understand system behaviour.
This was especially important for developer experience. Users needed more than a clean interface; they needed transparency into what was happening inside the system.
4. Designing for trust, security, and compliance
The gateway needed to feel trustworthy because it would support sensitive financial data exchange.
I designed security and governance workflows such as two-factor authentication, team management, role-based access, audit trails, and activity monitoring. These patterns helped users manage access, track important events, and maintain accountability across the system.
The focus was to make compliance-related actions visible and usable without overwhelming the main workflows.
5. Creating consistent patterns for a complex system
To keep the product scalable, I aligned repeated modules around consistent interface patterns.
Dashboards, tables, filters, forms, modals, status indicators, and detail pages were designed to behave predictably across both portals. This consistency made the experience easier for users to learn and easier for engineers to build.
Working through all the complexity
This project required close collaboration with engineers and stakeholders because many design decisions depended on technical feasibility, permissions, data structure, and compliance expectations.
I used the existing user stories and product requirements as a design reference, then mapped flows and interface structures around what each user type needed to accomplish.
Feedback loops helped refine page hierarchy, role permissions, security flows, and the level of detail shown in technical views.
Expected impact
Once open banking rollout progresses, the gateway is expected to:
- Reduce integration timelines for fintechs by up to 60% through standardised onboarding and documentation
- Lower infrastructure costs for smaller financial institutions adopting open banking APIs
- Improve regulatory confidence through auditability and traceability
- Support a more inclusive open banking ecosystem by making participation easier for more institutions
What this project taught me
This was one of the most technically challenging products I have worked on. It pushed me to understand how APIs are structured, consumed, documented, and monitored.
The biggest lesson was that technical products still need clear product thinking. Developers and financial institutions do not only need access to features; they need structure, visibility, trust, and confidence that the system will behave predictably.
Designing the gateway showed me how design can make complex infrastructure easier to adopt, especially in ecosystems where clarity and standardisation are essential for scale.