In the 1990s, a Nigerian bank we would later work with took the steel security grilles out of its branches. It put a piano in the middle of the banking hall and hired someone to play it. Nobody had a piano on a checklist. The decision came from understanding what it felt like to walk into a bank in that market at that time, and at the time it was close to a provocation.
Thirty years later, the same institution shipped a mobile app with a tab bar containing external social networks. You could check your balance, then scroll Instagram, without leaving your bank.
Both were unusual choices. Only one of them came from knowing the customer.
What happened in between is a problem I now see in most large banks, and banking app feature parity is where it hides. Parity has become the standard measure of digital maturity. It is a genuinely useful number. It also cannot see the thing that decides whether customers stay.
By 2025 this bank had done the work. Compared feature by feature across digital account opening, transfers, credit, savings, investments, FX, support and security, its app benchmarked at 90%. That was the highest of any retail bank measured in Nigeria, and ahead of every major Nigerian fintech in the same comparison.
Over the same period, transfers between the bank's own customers fell from 123.6 million a year to 59 million. Transfers going out to other banks grew 45%.
The value of in-network transfers fell far more slowly than the count, which means the average transaction roughly doubled in size. Small everyday payments had moved somewhere else. Large, infrequent ones stayed.
Read those facts together and the picture is uncomfortable. The bank had won on features and was losing the daily habit. A good share of that everyday money now moves through the same fintechs the bank had just out-scored on the benchmark.
This is what a parity benchmark cannot see. It counts whether a function exists. It says nothing about whether that function is the one a person reaches for at eleven in the morning.
It counts whether a function exists. It says nothing about whether that function is the one a person reaches for at eleven in the morning.
Three layers sit underneath every product decision, and most banks manage only the first.
Parity asks which functions exist, and a benchmark answers it. Usage asks which of them people actually open, how often, and in what order; your own analytics will tell you, if anyone looks. The third question is the one that decides: which of these would a customer be annoyed to lose? Nothing in your dashboard answers that. It comes from research or it does not come at all.
A bank can lead its market on the first layer while the third quietly relocates to a competitor. That is not a contradiction. It is what happens when the first layer is the only one anyone is accountable for.
Products designed around the third layer look different from the first release. monobank was structured around everyday financial behaviour rather than a list of banking functions, and that decision was made years before there was anything to benchmark it against.
The social tab was not a strange decision by one person. It was the predictable output of a system with a gap in it.
This bank had ambition, budget and a roadmap. What it did not have was anyone inside whose job was the experience rather than the function list. Product and design were not roles the institution had built, which is unremarkable for a bank whose innovation history lived in branch design and physical service.
When nobody owns experience, feature selection still has to happen. It falls to whoever is nearest, and the only method available to them is looking at what is visible elsewhere. Something is popular somewhere, so it goes in. Nobody is being careless. They are working with the only input they have.
This usually gets diagnosed as a culture problem and answered with an innovation programme. The diagnosis is wrong, and the answer is expensive. Workshops generate more ideas for a system that already cannot choose between the ideas it has.
A parity table is assembled from your competitors' outputs. It tells you what is missing from your list. It cannot tell you what to build, because it contains no information at all about your users' constraints.
We started this engagement in the field. That meant flying to Nigeria, spending time in open-air markets, and watching how people paid for things: what they held, what they waited for, where they gave up.
Two decisions came out of that which no benchmark would have produced.
The first is infrastructure the customer never sees. Identity verification during onboarding runs on a facial match, and the acceptance threshold had to come down from 75% to 70%. Ninety-two percent of this bank's app users are on Android, a large share of them on inexpensive handsets with poor cameras. A threshold tuned for good hardware quietly excludes the majority of your market. No competitor's feature list mentions a verification threshold.
The second was sequence. Once you have watched people transact, the order in which to build things stops being a matter of opinion in a room.
The most useful thing in this project has nothing to do with design.
When we started, the bank would not give us access to core banking. It was building and protecting that system itself, and its position was that the backend worked. This is a normal posture for a bank. It is also the single most common reason digital programmes stall.
There are two usual responses and both fail. You can treat access as a precondition and wait, which means waiting indefinitely, because access is a political question and political questions do not resolve on a project timeline. Or you can accept that the backend works and build the product around whatever it happens to return, which is how an app ends up shaped by an API instead of by a person.
We did neither. We went frontend-first and made the interface the contract.
The logic is plain. The front end states what it must display in order to work. The contract states what the backend owes: which data, in which format, at which moment. How the bank's internal system produces it is the bank's business, and we said as much. We would help where that was useful. What we needed was the right shape, at the right time.
That change does something people underestimate. It converts an access problem into an obligations problem, and nobody needs to grant permission for an obligation to be legible.
It converts an access problem into an obligations problem.
Contracts make gaps specific. Where a service could not arrive in the shape and on the timeline the product required, that showed up immediately, as a technical fact rather than a political argument. Investments and pensions were built on our side for exactly that reason. Nobody had to construct a case about capability, because the contract had already made it.
Institutional trust moved on the same logic. In-app account opening shipped in February 2024. The bank made the app its account-opening channel eighteen months later, in August 2025, and average monthly accounts opened rose 286%. An institution does not route core acquisition through a platform it distrusts, and it does not start trusting one because of a launch. It starts because a track record accumulated.
Three years in, the same principle is running at group scale. Every market the bank operates in has its own app, with its own core banking underneath it. The architecture that lets a new one be brought up without redesigning the interface each time was designed on our side, and the bank's own engineers are building it.
That is the part worth taking. A contract-first interface does more than get you past one blocked backend. It makes the backend interchangeable, so a different core system in each country becomes a question of configuration rather than architecture.
It also answers what every product leader eventually asks about a long partnership. We designed it. Their engineers are building it. Capability transfer, when it is real, looks like that, and not like a handover scheduled for the final sprint.
Parity gets an account opened. It does not keep it.
Of everyone who has ever used this bank's digital platform, about a third have stopped. That is the number I would put in front of any board that has just been shown a favourable feature comparison. Acquisition is rising, the app leads its market on functions, and a third of the people who once used it no longer do.
There is also a reading error here worth naming, because it is everywhere.
The bank's own review flagged that only 10% of its app users are aged 18 to 24, and read that as a youth problem. But 18 to 24 year olds are 11% of the bank's customer base. Penetration inside that cohort is 36%, against a 39% average across all ages. The app converts young customers at close to the normal rate. The bank simply does not have many of them.
That is a composition figure being read as a penetration figure, and the two point to opposite decisions. One says fix the product. The other says the product is fine and the constraint sits upstream, in who the bank acquires.
To its credit, the bank acted on the correct reading. In February 2026 it launched a free account aimed at 18 to 25 year olds, with no account charges. An acquisition answer to an acquisition problem.
Parity is a threshold, not a position. Reaching it means you have stopped being excluded, which is worth having and is not the same as being chosen. What decides is the layer a benchmark cannot see: which parts of your product a person would actually miss.
The bank in this story once knew that without needing a framework for it. It proved as much by taking the grilles out of its branches and putting a piano where they had been. Nothing about that decision appeared on anyone's feature list.
If your benchmark says you are doing well and your usage numbers say something quieter, the benchmark is not wrong. It is answering a smaller question than the one you asked.
Practical notes on fintech product design and banking UX, sent when we have something worth saying.
Further reading
