Streamlining a critical lending workflow to help new users book loans faster and experience the value of the admin console sooner.
Designing an API gateway for Nigeria’s Open Banking ecosystem
Open Banking Nigeria · 2024
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.
Background
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.
Problem
The product needed to solve three experience challenges:
Fragmented integrations: Fintechs and third-party providers often had to integrate with institutions one by one, increasing technical overhead and time-to-market.
Inconsistent standards: Different API structures and documentation patterns made it harder for teams to build scalable integrations.
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
Solution
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.
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.
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.
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.
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.
Working on this project showed me how design can make complex infrastructure easier to adopt, especially in ecosystems where clarity and standardisation are essential for scale.
Kuda
