Forty New Agents, Thirty Wrong Locations: Planning a Network With Real Geography
A bank picked 40 agent locations from a ward spreadsheet and eleven underperformed. Geocoding and travel-time catchments showed why, and fixed the next round.
Composite scenario drawn from typical East African deployments. Institution details are anonymised and figures are representative rather than attributable to a single client.
An expansion that half worked
A bank expanding its agent banking network approved 40 new agent locations across six counties. Eighteen months later, the performance spread was extreme: the top ten agents were processing more than eight times the transaction volume of the bottom fifteen, and eleven agents were below the threshold at which the arrangement made sense for either party.
The bank's post-mortem initially focused on agent selection — commitment, capital, training. Those factors mattered. They did not explain the pattern, because the underperformance was geographically clustered in a way that agent quality would not produce.
How the locations had been chosen
The planning process was a spreadsheet. It listed wards, their population from census data, the count of existing bank branches and agents in each, and a calculated ratio. Wards with a poor ratio were flagged as underserved, and agents were recruited in the main trading centre of each.
Every step of that reasoning is defensible and every step loses information.
Administrative boundaries do not describe how people move. A ward with a poor agent ratio may be five minutes from a well-served trading centre in the neighbouring ward, along a road people already travel for other reasons. On a boundary map it is underserved. On the ground it is covered.
"The main trading centre" is not a coordinate. Locations were recorded as place names. Two of the 40 were placed in the wrong settlement entirely, because two villages in different counties share a name.
Existing coverage was counted, not located. The competitor and own-network agents in the ratio were tallied per ward. Where they actually sat — clustered on one road, or spread evenly — was not part of the calculation. Several new agents were placed within 400 metres of an existing competitor agent on the same street.
Physical geography was absent. Two locations served populations separated from them by a river with no nearby crossing. The catchment on paper was several thousand people. The catchment in practice was the near bank only.
The rework
The bank engaged Creodata's geospatial data services, built on OpenStreetMap data and delivered as Azure-hosted APIs.
Everything was geocoded. Every existing own-network agent, every branch, and every known competitor location was resolved to coordinates using geocoding tuned for East African addresses — which matters, because address quality in the region defeats geocoders trained on Western formats. The name-collision errors surfaced immediately.
Catchments were computed, not assumed. Rather than ward population, the bank modelled realistic catchments using routing and travel distance along actual roads. This is where the river cases appeared, and where several "underserved" wards turned out to be comfortably served from across a boundary.
Overlap was measured. Proximity analysis identified where new agents had been placed inside the effective catchment of an existing one. Nine of the eleven underperforming agents fell into this category — they were not badly chosen, they were placed into demand that was already being met.
Gaps were identified positively. The same analysis, run in reverse, produced locations with meaningful population inside a realistic travel radius and no agent or branch within it. Several were in wards the original spreadsheet had marked as adequately served.
The outcome
The bank relocated six agents and did not renew five. The next expansion round of 25 locations was planned from catchment analysis rather than ward ratios; after twelve months, three were below threshold rather than the eleven-in-forty of the previous round.
The APIs found uses beyond network planning. Field verification during customer onboarding now geo-verifies a business address rather than accepting a typed one. Risk models incorporate a geography component. The field team's visit routing is planned on real road distance, which cut travel time on rural verification rounds noticeably.
A note on data quality
One question comes up in every geospatial conversation in this region: is OpenStreetMap data good enough for commercial decisions?
The honest answer is that it varies by geography and by feature type. Road networks in and around major East African towns are well mapped and improve continuously. Building footprints and points of interest are patchier outside urban centres. Formal addressing is thin almost everywhere, which is exactly why geocoding tuned for local address conventions matters more here than it does in markets with reliable postcodes.
For network planning, that variance is tolerable, because the decision turns on roads and travel time rather than on individual building records. For field verification, the bank pairs the geocoded result with a captured GPS point at the visit, which resolves ambiguity at the moment it matters. Knowing which decisions the data supports well is part of using it properly.
The general point
Coverage expressed in administrative units answers a question about administration, not about customers. People cross boundaries; they do not cross rivers without bridges.
Two checks are worth running against any network plan:
Are your locations coordinates or names? Names collide, drift and mislead. Every location in a network plan should be a point on a map.
Is your catchment a radius or a route? Straight-line distance ignores rivers, escarpments, unpaved roads and the direction people already travel. Travel-time catchments consistently produce a different and better answer.
Planning branch or agent coverage? Book a consultation or explore Geospatial Data Services to see how geocoding and catchment analysis fit into network planning.