Building Teddoh across five markets, I kept watching the same thing happen.
A product would launch. The design was clean. The fees were lower than anything incumbents were offering. Onboarding took three minutes. And then the retention data would come in around month eighteen, and it would tell a story nobody wanted to read: activation dropping for users without formal employment, NPS lower in markets with more rail friction, a quiet performance cliff for anyone below a certain income bracket.
Every team I watched go through this attributed it to product. It wasn't product. It was infrastructure – and it had been locked in before the first wireframe was drawn.
Financial inclusion is not a product problem. It is an infrastructure problem. And until the industry builds the right rails, the apps are irrelevant.
Why Builders Keep Getting This Wrong
Every year, fintech ships thousands of new products promising financial inclusion. Mobile wallets. Micro-lending platforms. Digital savings tools. The pitch is always the same: better design, lower fees, simpler onboarding.
Yet the number of unbanked adults globally has barely moved relative to population growth. The people most excluded from formal finance remain excluded – not because the apps aren't good enough, but because the rails those apps sit on don't reach them.
The reason builders keep making this mistake is structural. Apps are faster to ship. They're easier to fundraise on. A beautiful UI can be demoed in a pitch meeting; a settlement architecture cannot. VC incentive structures reward eighteen-month product cycles, not the multi-year infrastructure work that actually changes who gets served. So teams default to app-first – and then discover, eighteen months in, that they've built something beautiful for the 40% of their users who have a bank account, and nothing for the 60% who don't.
That is not a design failure. It is an infrastructure failure that got made by accident, by people who thought they were making a product decision.
The Three Gaps That Actually Determine Addressable Market
The distance between "I have built a financial product" and "I have built a financial product that works for the unbanked" is not a design gap. It is an infrastructure gap, and it has three specific dimensions.
Settlement reach. A payment that processes and fails at settlement is not a payment. In markets where formal banking penetration is low, settlement reach determines your addressable market before any other variable. This is why mobile money infrastructure – systems that settle to a SIM card rather than a bank account – transformed commerce across African, Southeast Asian, and Latin American markets in ways that bank-first products never did. The technology wasn't remarkable. The reach was.
Identity infrastructure. In Canada, the US, and most of Western Europe, identity verification is a solved problem. In most of the rest of the world, the infrastructure for identity is fragmented, unreliable, or simply absent for large portions of the population. KYC without accessible identity infrastructure is not compliance. It is exclusion with paperwork.
Credit data infrastructure. A user who has been sending mobile money for three years, paying utility bills on time, and running a small retail operation has a meaningful financial history. None of it shows up in a traditional credit bureau. Building for inclusion means building the infrastructure to capture and act on that data – not waiting for the bureau to catch up with your users.
These gaps don't only describe emerging markets. They describe the underbanked immigrant in Toronto, the gig worker with no W-2 in Chicago, and the informal market vendor in Lagos with equal accuracy. The infrastructure problem is global. The severity varies. The solution architecture is the same.
Rails-First Design: Three Questions Before Any Product Decision
I call this rails-first design. It starts with three questions that have to be answered before anything else.
Before you design a checkout flow or a lending decision, ask: through what mechanism does money actually reach this user? If the answer is a bank account, your addressable market is everyone with a bank account. Each aggregator layer you add is a failure point, a fee, and a settlement delay. For users without a fallback mechanism, that delay isn't an inconvenience. It's a broken product.
Alternative data – transaction history, airtime top-ups, bill payments, behavioral signals from the product itself – can substitute for bureau data if the system is built to collect and process it. In thin-file markets, this data is often more predictive than bureau scores because it captures recent, high-frequency financial behavior rather than years-old credit history. The infrastructure investment is in building the data pipeline, not waiting for the bureau to catch up.
For a user with a bank account and multiple payment options, a rail failure is an inconvenience. For a user whose only payment mechanism is a single mobile money operator, it is a locked account, a missed payroll, a business that cannot transact for twenty-four hours. Rail redundancy is not a performance optimization. It is a baseline requirement for any product targeting inclusion.
What This Actually Looks Like to Build
Rails-first design sounds clean as a framework. Building it is harder – and the decisions are more consequential than they appear.
At Teddoh, integrating directly with mobile money operators rather than routing through aggregators was one of the most important architectural choices we made. Aggregators are faster to integrate and easier to manage initially. But they add a settlement layer, a fee layer, and a failure point you don't control. For users with no fallback rail, someone else's infrastructure failure becomes your user's exclusion event. We took the slower path – dedicated integration work per market, regulatory engagement that an aggregator would have abstracted away. What we got in return was settlement visibility down to the individual transaction, fee transparency across the full stack, and the ability to route around failure in real time.
We made the same call on credit infrastructure. We didn't wait for bureau data. We built our own credit scoring model from day one – trained on transaction behavior, payment history, and behavioral signals from within the product. Bureau data is better where it exists. It exists for 20–30% of our target users in the markets where we operate. Our model works for 100% of them. That coverage gap is not acceptable to defer.
Both decisions were harder than the alternatives. Both decisions defined the product's addressable market. That is the point.
The Stakes If We Don't Get This Right
Getting this wrong is expensive – not just commercially, but at a civilizational scale.
A merchant who can't accept digital payments can't access working capital. A worker who can't receive remittances efficiently loses 7–12% in fees. A borrower without a credit history can't access a loan, which means they can't build a credit history. The loop is closed from the outside – and every app built on the wrong rail makes it harder to see that the loop exists at all.
The builders who understand this don't start with the app. They start with the rail – and then build the app on top of infrastructure that actually reaches everyone it's supposed to reach.
If you're building a fintech product and you started with the app, you've probably already constrained your addressable market in ways you don't fully understand yet. The evidence will show up around month eighteen. You'll attribute it to product. It will be infrastructure.
Start with the rail. Ask whether it reaches your user. Ask whether trust can be established without credentials your user is unlikely to have. Ask what happens when it fails.
Then build the product.
Financial inclusion isn't a design problem waiting for a better UI. It's an infrastructure problem waiting for builders willing to do the harder work – because that work is what determines who commerce is actually possible for.
The apps will follow. They always do. But only once the rails are there, and only if those rails were built to reach everyone from the start.
This is the Foundational Essay for TechRoadmap – the piece everything else links back to. It spans Pillar 01 · Building the Rails and Pillar 03 · Financial Inclusion by Design.