Introduction | The Alabama Paradox
Last week, I had the privilege of delivering a guest lecture to the Dollarcraft Program cohort at Alabama A&M University.
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:
- The Inbound Fee: The third-party provider charges a deposit fee (often 1% or flat fee) just to receive the ACH/Wire.
- 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.
- 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:
- Bank A (Lagos) sends an MT103/ISO 20022 instruction to Bank C (London).
- Bank C receives the message, decrypts it, and validates the compliance data.
- Bank C checks its internal ledger to ensure Bank A has enough pre-funded liquidity.
- Bank C debits Bank A’s account and credits Bank D (New York).
- 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.
- The Handshake: Before a single cent moves, the Sender’s Wallet and the Receiver’s Wallet perform an encrypted handshake.
- The Exchange: They exchange identity data (utilizing standards like IVMS 101) required for the Travel Rule (FATF Recommendation 16).
- 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.
