Nobody designs a fragmented banking setup. It accumulates.

No finance director ever decided to work with five banks, thirty accounts and as many sets of credentials. Every one of those accounts was a reasonable decision at the time. A local regulator required an account in-country. An acquisition arrived with its own banking relationship. A provider solved one specific problem quickly, when the incumbent bank could not.

Each decision was locally rational. The result, taken together, is not a structure. It is an accumulation.

How it happens

Fragmentation almost never announces itself. It arrives one entity at a time, over several years, usually during periods when the company had more urgent things to attend to than the shape of its banking.

A group expands into a second country and opens a local account because a supplier will not be paid otherwise. It sets up a holding company in a third jurisdiction for a specific transaction. It acquires a competitor and inherits two banking relationships it did not choose. It adds a payment provider because card collections in a fourth currency were being converted automatically at a rate nobody had agreed.

Five years later the finance team is reconciling across five interfaces, with five pricing grids, five sets of security tokens and no single view of where the group’s cash actually sits.

What it costs, beyond the fees

The direct costs are visible enough: duplicated account maintenance, intercompany transfer charges between entities of the same group, conversion spreads paid separately by each subsidiary rather than negotiated once at group level.

The indirect costs are larger and rarely measured.

• No consolidated cash position. A group that cannot see its own liquidity in one place will hold buffers in several currencies at once, and borrow in one country while sitting on cash in another.

• Manual reconciliation. When bank data does not flow into the accounting system automatically, month-end closing depends on people re-keying it, and every reporting cycle inherits the delay.

• People. It is not unusual to find several full-time roles absorbed by banking monitoring and payment execution in a group whose transaction volume would be entirely manageable with the right connections in place.

• Key-person risk. Access rights, tokens and signature mandates accumulated over years are rarely mapped. Nobody discovers the gaps until someone leaves.

• Resilience. A concentration on one provider in a market, with no documented alternative, is a single point of failure that only becomes visible when the provider withdraws.

The cost of fragmentation is not what the banks charge. It is what the group cannot see, and what its finance team cannot stop doing.

Four questions before the next account

The moment to intervene is not the audit. It is the next account opening, because that is where the accumulation continues. Four questions are usually enough to establish whether an account is a design decision or another layer.

• Does this entity need its own account, or does the group need an account in this currency? These are different requirements, and only the first genuinely requires a local relationship.

• Who initiates, who signs, who can view? Deciding this at opening is straightforward. Reconstructing it across thirty accounts, years later, is not.

• Does this provider connect to our accounting or treasury system? A relationship that cannot deliver structured data will be paid for twice: once in fees, once in manual work every month for as long as it lasts.

• What is the fallback if this provider exits this market? Every group operating in constrained corridors should be able to answer this for each of them.

Design, not accumulation

Structuring a banking architecture properly means reversing the order in which most setups are built. The usual sequence is: a need appears, a provider is found, an account is opened, and the structure is whatever emerges. The order that works is the opposite.

Start with the entity map: which legal entities exist, where, why, and which of them will still exist in three years. Then the flows: what moves between them, in which currencies, at what frequency, with which external counterparties. Then the constraints: local requirements, exchange controls, mandates, reporting obligations, the systems the data has to reach. Providers come last, selected against criteria that already exist — not chosen first and worked around afterwards.

This is unglamorous work. It also tends to be the point at which a group discovers that half of what it does every month exists only because of a decision taken years earlier, for reasons that no longer apply.