When a mobile financial services offering is described as a "wallet launch," it's usually the wrong framing before a single line of code matters. A wallet is a container. What determines whether it succeeds or fails is everything around it, and most organizations under-invest in that part. I learned this directly while helping build out mobile financial services in Jamaica, at the point the offering was just being introduced to the market. The instinct in most organizations at that stage is to treat it as a product rollout: ship the app, market it, measure downloads. That instinct is almost always wrong, and it's expensive to unwind once you've built momentum around it.

Start with who is actually underserved, not who is easiest to reach

Before anything else, we profiled the existing customer base: device type, ARPU, data usage. Not to find early adopters, but to separate the served from the underserved. That distinction became the actual targeting logic for the product. Financial services in a market like this aren't a convenience feature for people who already have banking access. They're infrastructure for people who don't.

The access layer matters more than the app

A wallet is useless if there's no way to convert cash into digital value and back again. That meant building an agent network from the ground up: identifying and assessing who could operate as a cash-in/cash-out point, sourcing the devices merchants would need, and designing incentive economics that would keep that network commercially sustainable rather than dependent on subsidy.

Extend trust that already exists. Don't manufacture new trust.

Rather than build a merchant ecosystem cold, we mapped it onto relationships that already existed inside our own distribution and sub-distribution network: grocers, vendors, and small retailers who already had a functioning commercial relationship with the business. The financial ecosystem grew on rails people already trusted, instead of asking an underserved population to trust something entirely new, from an entirely new counterparty, at the same time.

Compliance is part of the product, not a gate at the end of it

We built the KYC framework as part of the ecosystem design, not as a checkpoint bolted on before launch. In markets where a large share of the target population operates outside formal financial documentation, how you design onboarding is the product decision that determines who can actually use it.

The pattern this points to

None of this is specific to financial services. It's the same operating discipline that applies to any ecosystem-dependent launch: a new sales channel, a new digital product, a new market entry. The product is rarely the constraint. The constraint is almost always the infrastructure around it: who has access, who is trusted, who bears the incentive to participate, and whether the compliance model matches the reality of the population you're trying to serve. Organizations that treat these as sequential (build the product, then figure out access, then bolt on compliance) end up with technically complete products that never achieve real adoption. Organizations that design the ecosystem and the product together get something closer to what actually works. That's the harder job. It's also the one that determines whether the launch becomes a business or stays a pilot.