Writing

What a Term Sheet Cannot See: A Working Framework for Technical Due Diligence on Emerging Market Fintech

Lanre Ibraheem, Founder and Principal  ·  January 2026

Over the past decade I have built core infrastructure inside emerging market fintech, taken a company through acquisition as its CTO, and sat on the operating side of engineering organisations that process billions of dollars a year. In that time I have also watched international investors evaluate emerging market technology companies using diligence frameworks written for Palo Alto. There is nothing wrong with those frameworks as far as they go. They just stop short of the questions that decide whether an emerging market fintech deal goes bad.

This is the working framework Norchester uses. It is deliberately short, because a report the partner never finishes reading might as well not exist.

1. Start with money movement, not architecture

In most software diligence, you begin with the codebase. In fintech, and in emerging market fintech especially, you begin by tracing a single naira, peso, or rupiah from the customer’s account to its destination. Which rails does it touch, and how many of them does the company actually own? Somewhere along that journey there is usually an informal workaround, built because a formal rail kept failing, that nobody mentioned in the data room.

The reason this comes first is that fintech companies in these markets routinely carry heroic engineering that compensates for infrastructure gaps. Retry queues paper over flaky switching partners, and reconciliation jobs run four times a day because a settlement partner cannot report consistently. Little of this shows up in an architecture diagram, yet it is frequently the most valuable asset in the company, and the most fragile. If the two engineers who understand the reconciliation layer leave, the company has a problem no term sheet accounted for.

2. Regulatory posture is a technical question

Ask a founder about licensing and you will get a legal answer. Ask the engineering team how a new central bank directive reaches production and you will learn what you actually need to know. In markets where the regulator can change settlement rules, KYC thresholds, or data residency requirements with short notice, the speed at which compliance changes move from circular to deployed code is a core technical capability, not a legal detail.

What I look for is boring and specific. Where do the compliance rules live in the code, and are they configuration or hardcoded across seventeen services? Who owns the change when the rule changes? A company that took three months to implement a previous directive will take three months to implement the next one, and in that window it is either non compliant or switched off.

3. Separate genuine AI from workflow wearing a costume

Nearly every fintech deck now claims AI, and diligence has not caught up. The questions that cut through have little to do with models and everything to do with consequences. What happens when the system is wrong, and who reviews it? What can the automated component actually do without a human, and what stops it from doing more than intended?

Having built and evaluated agentic systems against live financial operations, my view is that the honest companies are easy to recognise. They can tell you precisely where automation ends and deterministic code begins, and they will show you evaluation results rather than demos. Their access model for automated systems is also narrower than the one they apply to staff. Companies that cannot answer the access question have usually given their automation the keys to everything, which is less an AI capability than an incident waiting for a date.

4. Read the team like an operator, not a spreadsheet

Headcount and tenure tell you little in emerging engineering markets, where the talent pool is deep but the senior layer is thin and heavily recruited by international remote employers. The questions that matter are narrower. Who are the three people the company cannot lose, and what are they paid relative to what a US remote employer would offer them? How much of what they know is written down, and how much travels in their heads? A company whose critical knowledge sits with two underpaid principal engineers is one international offer away from a very bad quarter.

5. Technical debt is a bill, so price it

Every report ends the same way, with a number and a duration. Not a maturity score, not a red amber green grid. An estimate of what it costs, in engineer months and in money, to bring the platform to where the investment thesis assumes it already is. Occasionally that number is small and the deal is better than it looks. I have also seen it come out to eighteen months of rebuild hiding under a polished API, which is a thing the valuation should know before the wire goes out.

That is the whole framework. It fits in a partner meeting, and in the reviews where we have applied it, it has yet to miss the thing that mattered.