Designing an intermediary layer between financial institutions and TPPs in Nigeria.

Open Banking Nigeria ・ 2024

Nigeria’s move toward open banking created a need for a shared layer that could bring banks, fintechs, and developers together on one standard. I designed the experience for an open-source API gateway that would make onboarding, API access, and compliance straightforward for financial institutions and third-party providers (TTPs). The work laid a clear foundation for adoption once nationwide rollout begins.

Dashboard interface showing API consumers metrics with total, active, rejected, and inactive counts, and API calls statistics including total processed, success rate, and average response time.

Background

As Nigeria’s financial ecosystem expands, collaboration between banks, fintechs, and developers remains limited by fragmented systems and inconsistent API standards. Open Banking Nigeria set out to change this by building a unified framework that enables secure, standardized data sharing across the ecosystem.

A key milestone in this mission was designing an open-source API gateway, an intermediary layer that bridges financial institutions and third-party providers (TPPs). This gateway would make integration faster, cheaper, and more accessible, especially for smaller institutions.

The problem

The rapid growth of fintechs and banks in Nigeria introduced a complex web of APIs with no shared standards.

Integration friction: Each bank required custom integrations, increasing time-to-market and technical overhead for fintechs.
Inconsistent standards: APIs differed in structure and documentation, limiting scalability.
Barrier for smaller institutions: Without resources to build their own APIs, smaller financial institutions risked exclusion from the open banking ecosystem.

These issues made interoperability the single biggest barrier to realizing Nigeria’s open banking potential.

Account setup form asking for first and last name, password, and confirm password with password requirements and a submit button, alongside a geometric colorful pattern.

Complete account setup screen

My Role

As the Product Designer, I translated complex regulatory and technical requirements into intuitive design solutions. Working closely with developers and key stakeholders, I ensured the gateway balanced compliance, scalability, and usability.My key contributions included:

Research & comprehension: Conducted deep dives into the open banking API specifications to understand data flows, permissions, and integration requirements.
Design system alignment: Created consistent UI patterns and visual hierarchies that supported modular scalability.
User-centered workflows: Designed and tested onboarding and integration flows to reduce setup complexity for developers.
Iteration & feedback: Partnered with stakeholders to refine the experience through multiple review cycles, ensuring both clarity and performance.

Goals

The gateway was designed with the following objectives:

Simplify adoption: Create a plug-and-play interface and setup process for institutions with minimal technical debt.
Empower smaller players: Lower the cost of entry by providing ready-to-use, customizable API components.
Ensure compliance and trust: Embed regulatory standards and security patterns into every workflow.
Foster collaboration: Enable banks and fintechs to build new products faster by standardizing how data is exchanged.

Research and discovery

I studied Open Banking Nigeria’s standards and CBN’s operational guidelines to understand the regulatory context and compliance requirements. To translate these into practical design decisions, I reviewed existing developer platforms like Paystack, Mono, and TrueLayer, learning how they structure onboarding, authentication, and API documentation.

‍

The product and engineering teams had already defined detailed user stories and high-level features, which outlined what each user type (API Provider and API Consumer) needed to accomplish. I used these stories as design references, helping me identify feature dependencies, workflow priorities, and edge cases early in the process.

My process

Structuring the experience

I began by mapping out the two user types; API Providers (AP) and API Consumers (AC). Both groups shared similar foundational needs like authentication, reporting, and user management, but each had distinct goals. Providers focused on control and visibility, while Consumers prioritized integration speed and autonomy.

Managing consumer collections (API Provider)

API Management dashboard showing Transactions collection with six API endpoints including Get Transactions, Transfer Funds, Get Transaction Status, Get Holds, Hold Funds, and Release Funds, with their request methods, configuration status, endpoint URLs, and tiers.

Collection details (API Provider)

API management dashboard showing Transactions section with a list of APIs for transfer funds, get transactions, get holds, and hold funds along with request methods, endpoint URLs, tiers, and parameters.

Collection details (API Consumer)

Designing the dual-portal experience

Since both API Providers and API Consumers use the gateway differently, I created a dual-portal structure:

Each user type had its own authentication, dashboard, and management modules.
Shared components (such as Audit Trail, Reports, and Manage Users) were designed with consistent UI patterns but customized metadata and actions per role.

This approach ensured that updates to shared systems would propagate across both portals without duplicating effort.

Collection details (API Consumer)

Dashboard (API Provider)

API dashboard showing user stats, API collections, reporting filters, and process summary with a sidebar menu including dashboard, collections, activity, reports, consents, members, and roles.

Dashboard (API Consumer)

Audit Trail screen showing a list of members with columns for name, email, event type, and description, with navigation sidebar on the left.

Audit trail (API Provider)

Designing for developer experience

Given that the primary users were developers or technical teams, usability meant:

Clarity over decoration: A clean layout with code-first readability, prioritizing JSON samples, response previews, and API testing options.
System transparency: Performance dashboards and audit trails that give developers insight into integration health and activity logs.

API dashboard showing user John Ajayi with metrics for API Consumers and API Calls, including totals, active, rejected, inactive consumers, and total processed calls, success rate, and average response time.

Switching to Test Mode (API Provider)

API Configuration screen showing Upstream Service settings with endpoint URL, hosts, headers, and request body code snippet in a web app dashboard for user John Ajayi.

API configuration (API Provider)

API management dashboard showing activity details for user John Ajayi with a successful Get Balance API call including request headers and payload in JSON format.

API activity details (API Provider)

Collaboration and iteration

I worked closely with engineers to align design decisions with technical feasibility, particularly around:

Security components (2FA, API key generation).
Performance data visualization.
Consent and notification flows.

Feedback loops with stakeholders helped refine page hierarchies, role permissions, and layout clarity.

Enable 2FA (API Consumer)

Dashboard interface showing a list of active team members with names, emails, roles, status set to active, and two-factor authentication status indicated by green check marks or red crosses.

Manage team members (API Provider)

Expected outcomes

Once Open Banking is approved by the CBN and goes live, the gateway is expected to:

Reduce integration timelines for fintechs by up to 60% through standardized onboarding and documentation.
Lower infrastructure costs for smaller financial institutions adopting open banking APIs.
Increase regulatory confidence by ensuring full auditability and traceability across financial institutions.
Foster a more inclusive, innovation-driven ecosystem for Nigeria’s financial sector.

Reflection and key takeaways

Working on this project expanded my understanding of technical systems and how design can bridge complexity and accessibility. When I began, my knowledge of APIs and backend integrations was limited. Over time, I learned how APIs are structured, consumed, and documented, and how developers interpret those interactions.

‍

The Open Banking Gateway remains one of the most technically challenging and rewarding projects I’ve worked on, a reminder that even in deeply complex domains, thoughtful design can make systems feel human, transparent, and usable.

Next project