In the early 2010s, Uber disrupted global transportation by commoditizing an entirely invisible transaction. Driven by a rigid Silicon Valley philosophy, the platform demanded that users maintain an active credit card on file.

This completely divorced the physical act of transport from the cognitive friction of payment. You push a button, a car arrives, and you get out. It was frictionless, seamless, and magical.

But when Uber exported this uncompromising card-only architecture to emerging markets like India and subsequently Africa, the magic broke.

Uber’s frictionless dream crashed into the heavy reality of low credit card penetration and a deep, systemic lack of institutional trust.

To survive, a trillion-dollar tech giant had to humble its global playbook, break its own design rules, and introduce the ultimate friction. They had to introduce physical cash.

They were not alone. Netflix is a platform engineered for 4K Smart TVs and infinite broadband. But when they looked at Africa, they realized they couldn’t just translate their app into local languages. To penetrate the market, they had to fundamentally re-architect their video encoding using AV1 codecs and launch mobile-only plans to combat severe data scarcity.

I constantly see startups making this exact mistake today. When you blindly export Silicon Valley’s obsession with frictionless UI to Lagos or Nairobi, you don’t get a seamless user journey. You build a “Digital Norman Door.” You end up with a product that looks beautiful in an air-conditioned boardroom but completely fails the user in the real world.

In the Global South, falling into this aesthetic-usability trap is fatal. To build products that actually scale here, product architects must stop building for the user they want and start engineering for the human they have.

To do that, we must kill the marketing persona.

The True Barriers of the African Market

Most startups begin their product development by drafting a marketing persona. It usually reads something like this:

“Meet Sarah. She is a 24-year-old professional in Lagos who loves artisanal coffee and wants a faster, more delightful way to send money.”

Sarah is a fantastic tool for an advertising agency. However, she is completely useless to a software product development team.

Knowing Sarah’s hobbies does not help a developer design a secure API, optimize a localized escrow system, or decide whether to build on USSD or React Native.

To build resilient financial infrastructure in Africa, we must utilize Constraint-Based Personas. Instead of defining a user by their desires, we need to define them exclusively by their limitations. We must map out what they cannot do, the hardware they are forced to use, and the trust deficits they navigate daily.

When you look at the hard macroeconomic data of Nigeria, the baseline constraints become very clear.

First, we have the hardware constraint. According to 2023 mobile operating system data from StatCounter, Android controls over 85 percent of the Nigerian mobile market. However, market intelligence reports from the International Data Corporation (IDC) indicate that the average mass-market device is severely limited. These phones typically run on just 2GB to 4GB of RAM and have 32GB to 64GB of internal storage. Users are in a constant state of digital triage, regularly deleting apps just to make space.

Second, we have to account for the data constraint. Internet is not a utility in this market; it is a strictly metered commodity. Based on pricing data tracked by the Nigerian Communications Commission (NCC) and the Alliance for Affordable Internet, the average cost of 1 Gigabyte of data in 2023 was roughly 287 Naira. Against the national minimum wage of 30,000 Naira at the time, 1 Gigabyte of data consumed nearly 1 percent of a user’s monthly income.

Finally, there is the institutional trust constraint. The 2023 EFInA Access to Financial Services in Nigeria survey highlights that while formal financial inclusion hovers around 64 percent, a critical 10 percent of the adult population relies exclusively on informal, offline financial services. These individuals use traditional Ajo or Esusu collectors because they prefer physical human accountability over digital clouds.

When you map these verified constraints, the true architectural challenge reveals itself.

Paga and the Offline Reality

Long before the current era of digital banking, Paga recognized the absolute necessity of constraint-based design.

The friction in the market was obvious. The Nigerian economy was heavily cash-driven, making the act of carrying physical cash dangerous and inefficient. Yet, as EFInA data historically showed, the vast majority of the population was entirely unbanked and disconnected from the internet.

If Paga had designed for “Sarah,” they would have built a heavy, data-intensive mobile app. Instead, they built a constraint persona: a consumer who needs to transfer funds safely but does not possess a smartphone, has zero access to mobile data, and lacks formal digital identification.

This led to a very specific design question: How might we facilitate secure electronic money transfers for users without smartphones, internet, or even modern USSD banking rails?

To answer this, Paga built their foundational MVP architecture around an ingenious SMS-to-Voice flow and a physical agent network. A user could simply send a text message to initiate a transfer. Because SMS is unencrypted and insecure, Paga’s system would instantly trigger an automated voice call back to the user, prompting them to securely enter their PIN on their phone’s keypad to authorize the transaction.

There was no graphical user interface, no 10-megabyte download, and no internet requirement. For those who couldn’t even manage an SMS, Paga deployed human agents across neighborhoods to act as physical cash-in and cash-out nodes. Paga stripped away the aesthetic entirely to solve the core mathematical constraint of the environment. They didn’t build a beautiful app; they built a financial lifeline.

PiggyVest and the Cognitive Constraint

When we move beyond physical hardware limitations, we encounter the psychological barriers of the user. In the financial sector, one of the most difficult constraints to design for is human discipline.

In late 2015, a conversation went viral on Nigerian Twitter. A woman revealed she had saved 365,000 Naira over the course of a year simply by putting 1,000 Naira every single day into a physical wooden savings box, locally known as a ‘kolo’.

This viral moment exposed a massive friction point in the market. The founders of PiggyVest recognized that traditional bank accounts were fundamentally designed for immediate transactions, not sustained saving. Young earners faced severe “spending urgency,” meaning their salaries were spent almost as soon as they hit their accounts. People desperately wanted to adopt a disciplined saving culture, but they were relying on an insecure, physical method because the digital alternatives failed to understand their psychology.

Furthermore, this demographic was operating in a low-trust environment. The market was highly skeptical of digital financial tools, especially following the recent collapse of rampant Ponzi schemes like MMM in Nigeria.

If the founders had designed for a traditional marketing persona, they would have built a standard, flexible digital wallet with a beautiful interface. Instead, they built a constraint persona: a young earner battling daily micro-expenses, who wants to save small amounts but fundamentally lacks the discipline to not spend their own money, and who is highly suspicious of digital platforms.

The resulting “How Might We” question was brilliant. How might we digitize the strict discipline of a physical wooden box, protecting a user’s money from their own spending urges while proving the system is not a scam?

Within two weeks of that viral tweet, the team built the Minimum Viable Product for Piggybank.ng. The platform digitized the wooden box concept by automating daily, weekly, or monthly savings directly into a digital wallet.

But the true genius was in how they designed the constraint. To distinguish themselves from standard bank accounts and promote true saving, they implemented a deliberate friction point. Users could only access their funds for free once every quarter. They essentially digitized the physical friction of “breaking the box.”

To solve the institutional trust constraint, they did not rely on expensive marketing billboards. They relied on raw, organic community proof. When their early users successfully withdrew their locked savings on December 31, 2016, those users took to social media to share their positive experiences. That user-generated validation proved the system worked, instantly bridging the trust gap and fueling their exponential growth the following year.

Moniepoint and the Institutional Trust Constraint

Perhaps the most difficult barrier to cross in the Global South is the lack of institutional trust.

Before founding Moniepoint, Tosin Eniolorunda and his team at TeamApt were building backend software solutions for traditional commercial banks. During this time, they noticed a glaring disconnect. The traditional banking industry was entirely obsessed with building sleek online products for urban, digitally connected areas. Meanwhile, a massive, underserved population across the country was being completely neglected.

This offline demographic faced terrible friction. Transaction failure rates were high, interoperability was poor, and physical ATMs were largely inaccessible. More importantly, a significant portion of this population lacked basic digital literacy.

If you build a state-of-the-art mobile banking app for a market trader who does not understand how to navigate nested menus, you have built a Digital Norman Door. When an unbanked individual loses money in a digital transaction, they do not want to call a toll-free customer support hotline. They want to speak to a human being.

Recognizing this, the team pivoted their business model entirely. They stopped trying to force a digital-only experience and asked a new architectural question. How might we deliver reliable banking infrastructure to offline communities by leveraging pre-existing local relationships rather than demanding digital literacy?

Their solution was the agency banking model. Instead of expecting users to trust a faceless app, Moniepoint placed human agents directly within the communities.

These agents were onboarded by people the community already knew and trusted. The human agent became a physical branch. If a transaction failed or an issue arose, the customer had a familiar, physical point of contact to hold accountable.

Moniepoint also had to engineer around severe hardware constraints at the agent level. Point-of-Sale (POS) devices in the market were highly fragmented and ran on poorly written code. To solve this, the engineering team developed a unified virtual machine environment that allowed their software to be written once and run seamlessly across various hardware manufacturers.

They did not demand that the Nigerian masses adapt to complex software. They adapted their software to operate through trusted human proxies.

Chowdeck and the Vendor Infrastructure Constraint

The constraints of the Global South do not only apply to the end consumer. Often, the most severe friction lies with the merchants and the physical infrastructure required to serve them.

Before Chowdeck entered the market, the primary friction was that existing food delivery services were tailored to a niche, international-style market.

These platforms focused heavily on items like pizza and burgers, which the average Nigerian did not eat on a daily basis. The real, mass-market demand was for local staple foods like Amala and Pounded Yam, but the existing infrastructure simply was not designed to handle the logistical complexities of transporting these local dishes. Furthermore, accepting food delivery in Nigeria often meant accepting a waiting period of two to three hours.

The constraint persona for their merchant side was a local food vendor, or ‘buka’ owner, operating in a highly informal commercial environment. Many of these early vendors did not have the digital literacy or high-end hardware required to manage a complex restaurant-facing tablet application.

The architectural question became clear. How might we integrate local, offline food vendors into a rapid delivery network without forcing them to adopt complex new software?

Because the founders were former software engineers at Paystack, they had the technical capacity to build anything. In fact, they built the very first version of their customer-facing mobile app in just three weeks to capture demand. However, they made a brilliant constraint-based design choice for the backend.

Instead of over-engineering a complex merchant portal that local vendors would struggle to use, they intentionally kept the backend operations heavily manual at the start. When an order came through the customer app, the Chowdeck team coordinated with roadside vendors and riders using direct, everyday communication channels like SMS, WhatsApp, and regular phone calls.

This manual approach allowed them to physically deconstruct the logistics. They mapped the bottlenecks, rider reliability, and vendor preparation times in the real world before they ever tried to automate it with code.

They stripped away the assumption that vendors needed state-of-the-art hardware, choosing instead to meet the merchant exactly where their technological capacity ended. To secure the vendors’ trust, Chowdeck broke industry norms by paying merchants as quickly as possible, ensuring these small businesses had the daily liquidity they needed to survive.

The Blueprint for the Next Billion Users

As a product architect, I constantly see teams fall into the trap of trying to design their way out of foundational infrastructure problems using pretty interfaces. We obsess over pixel-perfect layouts, seamless animations, and the “happy path” of a user journey. But in emerging markets, consumer behavior does not passively adapt to the requirements of Western software. Rather, software must forcefully deconstruct and rebuild itself to survive the physical, financial, and regulatory constraints of the market.

The history of global business expansion is replete with case studies of rigid corporate playbooks collapsing under the weight of localized socio-economic realities. When you look at the trajectory of Paga, PiggyVest, Moniepoint, and Chowdeck, a unified blueprint emerges.

None of these companies succeeded by building frictionless, data-heavy applications for an imaginary, upper-middle-class marketing persona.

They succeeded by looking brutally at the hard metrics of their environment. They accepted that mass-market devices operate on 2GB to 4GB of RAM. They respected the fact that a single gigabyte of data consumes nearly 1 percent of a minimum wage earner’s monthly income. They understood that a massive segment of the population relies exclusively on offline, informal trust networks.

You cannot achieve true scale in the Global South by building a Digital Norman Door. A beautiful application that requires a 4G connection and a modern smartphone in a market dominated by cracked screens and expensive data is a failure of product design.

If you want to build solutions that actually change lives, you have to stop designing for the user you want. Kill the marketing persona, and start architecting for the constraints of the human you have.

About the Author

Faheed Alli-Balogun is a Senior Product Designer, Architect, and active contributor to Africa’s digital ecosystem. With a background spanning product leadership at Chimoney (Techstars ’23) to advising early-stage fintechs, Faheed specializes in open payments infrastructure and the mechanics of trust in digital platforms. As a guest lecturer at institutions like Covenant University and Alabama A&M University (AAMU), he champions “Designing for Agency”, a philosophy dedicated to building resilient, constraint-aware financial products that prioritize the human over the system. He also actively mentors early-stage builders through Dreamax. 

Introduction: The Alabama Paradox

This group of high-achieving scholars from the College of Business and Public Affairs was exploring the intersection of digital banking and entrepreneurship.

From my home office in Lagos, Nigeria, I connected to their classroom in Huntsville to discuss the future of fintech.

The connection was seamless. I was streaming 4K video and high-fidelity audio across the Atlantic Ocean with a latency of approximately 50 milliseconds.

The data packets carrying my voice traversed multiple distinct networks. They moved from my high-speed fiber and satellite ISP connection to a ground station, across subsea fiber optic cables, and through US domestic ISPs without a single human administrator needing to approve the route. The internet’s “best effort” packet-switching architecture worked exactly as designed.

However, the session concluded with a stark realization of the “Bug” I had spent the hour describing. When the University attempted to process my speaker stipend, the process deadlocked. The failure was not technical.

The global banking system certainly possesses the ability to wire funds to Nigeria. The failure was bureaucratic and architectural.

The University’s finance department operates within a rigid compliance framework designed for a high-trust physical world.

They found the process of verifying a foreign vendor and authorizing an international wire so administratively burdensome that they defaulted to the only protocol they knew would not fail: Cutting a physical paper check and mailing it.

This creates a startling paradox in the modern economy:

• Information Velocity: 0.05 seconds (Lagos to Huntsville).
• Value Velocity: 1,209,600 seconds (14 Days via Courier).

We have built a Ferrari for information, but we are utilizing a stagecoach for money.

The Agency Gap: Timothy vs. Femi

This anecdote is not unique to me. It serves as a microcosm for the daily reality of millions of professionals.

To understand the difference between Access and Agency, we must juxtapose two personas: one of the scholars from the class, whom we will call Timothy, and a freelance designer in Lagos named Femi.

Timothy lives in the United States. If he needs to send $500 to a classmate, he uses a domestic P2P rail like Zelle. The cost is $0. The settlement is instant. However, Timothy is also trapped in a “Walled Garden.” If he tries to send that same $500 to Femi in Lagos, his Zelle app fails. He cannot communicate with the Nigerian banking system. His agency is limited to his domestic borders.

Now consider Femi. Femi is a talented 23-year-old designer in Yaba, Lagos. He can collaborate in real-time on Figma with a client in San Francisco. Unlike the unbanked populations of the past, Femi technically has “Access.” He can sign up for third-party fintech applications that issue him a virtual USD checking account.

But this access is a mirage of utility. To receive that same $500, Femi enters a labyrinth of friction:

1. The Inbound Fee: The third-party provider charges a deposit fee (often 1% or flat fee) just to receive the ACH/Wire.
2. The FX Spread: When Femi needs to spend that money in Lagos, he cannot withdraw USD. He must convert it to Naira. The provider often applies a spread of 3% to 5% against the mid-market rate. On $500, that is a loss of roughly $20 in value compared to the true market rate.
3. The Withdrawal Fee: Finally, moving the funds to his local bank incurs another fee.

By the time the money hits Femi’s usable account, $500 has become roughly $470. He has paid a 6% tax on his labor and waited 1 to 3 business days for the funds to settle.

For Femi, and for the 1.4 billion people excluded from the core financial grid, “Access” is having a bank account that bleeds value at every turn. Agency is the utility derived from the system. It is the ability to move value globally, instantly, and permissionlessly.

To achieve Agency for Femi, we cannot simply digitize the current bureaucracy. We must re-architect the ‘physics’ of money movement from the ground up.

The Taxonomy of Friction: Why the Old Rails are Failing

To understand why the check was mailed, we must first perform a root-cause analysis of the current system’s failure modes. The global financial network is not a single grid. It is a fragmented archipelago of “Walled Gardens” connected by a legacy system of “Message Switching.”

The Message-Switching Paradigm (Serial Settlement)

The current Cross-Border Payments (CBP) model is dominated by the correspondent banking network. This network utilizes a “Store-and-Forward” message-switching architecture, exemplified by SWIFT.

In this model, a payment is treated as a single, atomic instruction. If Bank A in Nigeria wants to send funds to Bank B in the United States, they rarely have a direct relationship. They must rely on a chain of intermediaries. While the user may not see these intermediaries when filling out a form, the instruction hops through them in the background. A typical flow looks like this:

1. Bank A (Lagos) sends an MT103/ISO 20022 instruction to Bank C (London).
2. Bank C receives the message, decrypts it, and validates the compliance data.
3. Bank C checks its internal ledger to ensure Bank A has enough pre-funded liquidity.
4. Bank C debits Bank A’s account and credits Bank D (New York).
5. Bank D repeats the entire process before crediting Bank B (Alabama).

This is Serial Settlement. It is inherently fragile because trust is not transitive. Bank A trusts Bank C, but Bank A has no relationship with Bank D. Therefore, every single link in the chain acts as a potential brake.

If one bank in the chain pauses the transaction for a manual compliance review (a “hit” on a sanctions list, even a false positive), the entire payment stops. The money does not bounce back immediately. It gets stuck in limbo, sometimes for weeks.

The High Cost of Bad Data

Critically, this serial architecture is highly sensitive to data errors. Because the routing instructions are complex and prone to human error, the failure rate is staggering.

According to data from LexisNexis Risk Solutions and Accuity, the global economy loses billions annually to the costs of failed payments.

This figure includes the direct fees of repair, the labor cost of investigation, and the opportunity cost of trapped working capital.

What causes these failures?

• 21% of all payment failures are caused by incorrect Beneficiary Name and Address details.
• 15% are caused by incorrect Account Numbers (often due to confusion between proprietary formats and IBANs).

In the current architecture, a typo in an address field doesn’t just result in a “Message Undeliverable” notification. It results in funds being frozen at an intermediary bank while manual investigations are launched.

This is the “fragility of the string.” We are trying to route value using coordinates that were designed for human postmen rather than digital routers.

The Bureaucracy as a Feature, Not a Bug

This explains the University’s behavior. The finance department likely faced a choice between two paths.

Option A (The Wire): Navigate a complex onboarding form. They would have to verify international beneficiary addresses to avoid that 21% failure rate. Then they would risk the funds getting stuck in a compliance filter at an intermediary bank.

Option B (The Check): Print a piece of paper.

They chose Option B not because they are averse to technology, but because the UX of the current financial architecture is broken. The bureaucracy is the scar tissue that forms around bad architecture. To fix the user experience, we have to fix the rails.

The Liquidity Trap: The $27 Trillion Cost of Trust

While data errors cause failures, the hidden cost of the successful transactions is Trapped Liquidity. Because settlement is sequential in the legacy model, banks cannot send money they do not have. Bank A cannot send US Dollars to Bank B unless Bank A already holds US Dollars in a “Nostro” account at Bank B.

To facilitate global trade, banks essentially have to park massive piles of cash in foreign vaults “just in case” a customer needs to send a payment.

According to global financial research from a 2015 McKinsey Global Payments Report, trillions in global liquidity sits idle in these pre-funded Nostro/Vostro accounts. This is “lazy capital.” It is money that cannot be used for lending. It cannot be used for infrastructure projects. It cannot be used to fund small businesses in emerging markets. It is simply frozen as collateral to lubricate the rusted gears of the correspondent banking machine.

For the Global South, this liquidity requirement acts as a Poverty Premium. Developing nations are often perceived as “high risk.” When global banks optimize their balance sheets, these nations are the first to be cut off. When a country loses its Correspondent Banking Relationships (CBRs), a trend known as “de-risking”, it effectively disconnects from the global economy.

The Architecture of Inclusion: Packet-Switching for Money

If “Message Switching” is the problem, the solution is to adopt the architecture that scaled the internet: Packet Switching.

This is the foundational thesis of the Interledger Protocol (ILP). The core insight here is that we do not need a single global bank. We need a standard for connecting all banks. Just as the Internet Protocol (IP) packetizes data to route it across disparate networks (Wi-Fi, Fiber, 5G) without those networks needing to understand the content, the protocol packetizes value to route it across disparate ledgers (Banks, Blockchains, Mobile Money).

The Concept: “Streaming” Value

In a packet-switched financial network, we do not send a $1,000 transaction as a single, atomic “Big Rock” that can get stuck. Instead, the protocol breaks that $1,000 into millions of tiny packets of value (e.g., $0.0001 per packet).

These packets are streamed from sender to receiver using a transport protocol. This fundamentally changes the risk profile of the transaction.

• Resilience: If a specific route fails or runs out of liquidity mid-stream, the protocol automatically re-routes the remaining packets through a different path.
• Efficiency: Because each packet is tiny, the liquidity requirements for intermediaries are drastically reduced. A connector does not need $1 million in the bank to process a $1 million payment. It only needs enough liquidity to process a few cents at a time, recycled thousands of times per second.

The Technical Stack: Anatomy of an Open Payment:

To understand how this delivers “Agency” to someone like Femi, we must look at the technical stack. The ecosystem is not a single app. It is a layered suite of open protocols designed to be modular.

Layer 1: Addressing (Payment Pointers)

We established that 21% of payment failures are due to bad address data. The legacy system relies on complex routing details.

For example, to receive a wire transfer via a third-party app today, I must provide the following:

Account Name: FAHEED ALLI-BALOGUN
Bank: Named US Bank
Account Number: 123456789012
Routing Number: 123456789
Account Type: Personal Checking
Address: 1234 Southwest Gemini Drive, Beaverton, OR, 12345, USA

This is 350+ characters of sensitive data. One typo in the Routing Number sends the money to the wrong state. One typo in the Address triggers an AML freeze.

In the open architecture, identity is abstracted into a Payment Pointer. It looks like this: $ilp.chimoney.com/faheed

This pointer resolves to a secure HTTPS endpoint (SPSP Endpoint). When a sender queries this endpoint, the receiver returns a unique destination address and a shared cryptographic secret.

This creates a “Human-Readable” address layer for finance. Femi can share his Payment Pointer as easily as he shares his email address. Crucially, the validation happens at the moment of query, before any money moves. This eliminates the “post-transaction failure” that costs the industry billions.

Layer 2: Transport (STREAM Protocol)

Once the address is resolved, the actual movement of funds is handled by the STREAM (Streaming Transport for the Real-time Exchange of Assets and Messages) protocol.

• Packetization: STREAM chops the total amount into micro-packets.
• Flow Control: It manages the speed of the transfer based on network congestion. This is similar to how Netflix buffers video quality based on bandwidth.
• Encryption: The shared secret ensures that only the sender and receiver can decrypt the packet data. The intermediaries (Connectors) can see where the money is going (the routing address), but not why or what the payload data contains. This provides a level of privacy that ISO 20022 messages cannot match.

Layer 3: Interoperability (The Connector)

The glue holding the system together is the Connector. Connectors are nodes that hold accounts on multiple ledgers. They act as automated market makers for liquidity.

A Connector might hold a USD account at Chase Bank and a NGN account at GTBank. When a packet arrives in USD, the Connector locks the USD and instantly releases the equivalent NGN to the next hop. This enables Just-In-Time (JIT) Liquidity.

Instead of holding $27 trillion in idle cash, the global economy could operate on a fraction of that capital. We can utilize velocity rather than volume to settle trade.

The Data Integrity Layer: Why Standard Databases Fail

One of the most overlooked challenges in building a high-velocity financial network is the database physics. It is easy to draw a diagram of “Streaming Money.” Building a database that can handle it is a significant engineering challenge.

When we move from “one transaction per day” (Legacy) to “thousands of packets per second” (Interledger), standard SQL databases begin to fail. The issue is Row Locking.

If a thousand packets try to update a single user’s balance simultaneously, the database locks the row to prevent errors. This creates a bottleneck that introduces latency. It destroys the user experience of “instant” settlement.

TigerBeetle: Accounting at the Rudimentary Level

To solve this, the ecosystem has begun adopting TigerBeetle. This is a distributed financial accounting database designed specifically for mission-critical safety and performance.

Unlike a general-purpose database, TigerBeetle is purpose-built for Double-Entry Accounting.

• Double-Entry Native: It enforces the rule that every debit must have a matching credit at the database engine level. It is mathematically impossible to “create” or “destroy” money due to a software bug.
• Strict Serializability: Using Viewstamped Replication (VSR), it ensures that the history of transactions is immutable and correct, even if hardware fails or power is lost.

For a product leader, this is the difference between “Move fast and break things” and “Move fast and break nothing.”

In finance, correctness is not a feature. It is the product. The integration of TigerBeetle into the protocol stack provides the robust foundation necessary to convince institutional players that open rails are safe rails.

The Compliance Layer: Decentralized Identity & The Travel Rule

The primary counter-argument from institutional finance regarding open protocols is always compliance. “How do you handle AML? If money moves like data, how do we stop illicit finance?”

This objection often stems from a misunderstanding of the architecture. The architectural intent of the protocol is not to bypass compliance, but to decouple it.

In the legacy SWIFT model, the identity data travels inside the payment message (ISO 20022). This is a privacy nightmare. Every bank in the chain sees the full personal details of the sender and receiver. This happens even if the intermediary is in a jurisdiction with weak data protection laws.

Compliance at the Edge

The architecture advocates for Compliance at the Edge.

1. The Handshake: Before a single cent moves, the Sender’s Wallet and the Receiver’s Wallet perform an encrypted handshake.
2. The Exchange: They exchange identity data (utilizing standards like IVMS 101) required for the Travel Rule (FATF Recommendation 16).
3. The Stream: Once compliance is satisfied between the endpoints, the money begins to stream through the Connectors.

The Connectors (the routers) do not need to know who is sending the money. They only need to know that the endpoints are verified entities.

This preserves privacy while satisfying the strictest global AML/CFT regulations. It allows us to have a network that is permissionless in routing but compliant in settlement.

Case Study: Integrating the Protocol (A Practical Reference)

Theory is useful, but execution is validation. During my tenure as Head of Product at Chimoney, we undertook the engineering challenge of integrating this stack into a production environment.

The objective was clear. We wanted to bridge the gap between “Closed Loop” mobile money systems (like Airtime and Bank Accounts in Africa) and the “Open Network” of Interledger.

We aimed to serve as a gateway. We wanted to allow value from the open internet to settle into legacy fiat rails, giving users like Femi the agency they lacked.

The Implementation Strategy

We utilized Rafiki (v1.1.2-beta), the reference implementation of the Interledger stack. This acted as the middleware between our core ledger and the open network.

This was not a simple API integration. It required significant architectural lifting:

• Security Hardening: We implemented HMAC (Hash-Based Message Authentication Code) signature validation to secure the webhooks between the protocol and our internal ledger.
• Regulatory Alignment: Crucially, we aligned the open protocol flow with Canada’s Retail Payment Activities Act (RPAA). This proved that “Open” does not mean “Unregulated.” By embedding compliance checks at the wallet level (the Edge), we maintained our standing as a Money Services Business (MSB) while leveraging permissionless rails.

The Outcome: Programmable Payouts

The integration allowed us to issue Payment Pointers to users who consented to the feature. A developer in Nigeria could now receive a “stream” of micropayments for their code contributions. The system would instantly convert and settle these streams into their local bank account or mobile wallet.

This validated the core thesis. We do not need to replace the local banks (Access). We need to connect them (Agency). The local bank provides the store of value. The Interledger provides the velocity of value.

The Future State: Streaming Wages and Data Dignity

Once this architecture is adopted at scale, the implications go far beyond simply making wire transfers faster. It changes the fundamental business models of the web.

If money is packetized, there is no technical reason to hold wages for two weeks. We can move to a model of Streaming Wages. A worker like Femi could be paid second-by-second for his time. The concept of “payday” becomes obsolete. It is replaced by a continuous flow of liquidity that reduces reliance on predatory payday loans.

Furthermore, this architecture enables Web Monetization. Instead of relying on subscription paywalls or invasive ad-tracking, browsers can stream tiny fractions of a cent to content creators in real-time as users consume content. This restores Data Dignity. It allows users to pay for value with value, rather than paying with their privacy.

Conclusion: Building Bridges, Not Walled Gardens

The check I received from Alabama is a relic. It is a physical artifact of a dying architecture.

We are entering the era of Agency.

• Access is having a bank account that cannot receive a wire from Nigeria without losing 6% of the value.
• Agency is a wallet that speaks the universal language of value, connected to a grid that never sleeps.

The architecture is ready. The protocols (ILP, STREAM) are defined. The databases (TigerBeetle) are performant. The regulatory frameworks (Travel Rule) are adapting.

For the builders, product leaders, and policymakers in the Global South, the mandate is clear. We must stop trying to polish the stagecoach. It is time to build the Ferrari.

About the Author

Faheed Alli-Balogun is a Product Leader and Design Strategist with a core focus on User Experience (UX) and Brand Architecture. Currently leading Product at Chimoney, he specializes in translating complex technical infrastructures like open payment protocols into intuitive, human-centric products that foster trust and adoption.

Faheed champions the philosophy of “Designing for Agency.” He believes that true financial inclusion is a design challenge as much as a technical one. He advocates for interfaces that prioritize user dignity over bureaucratic friction. His work sits at the intersection of visual storytelling, system architecture, and financial utility.

Beyond his operational leadership, Faheed is a vocal advocate for the African design ecosystem. He actively mentors early-stage creatives through Dreamax and speaks frequently on Inclusive Design, Product Strategy, and the mechanics of trust in digital platforms.

He is committed to building a future where global financial rails are as seamless and accessible as good design should be.