App Drop-Off That Ignores Redesigns Is Reading the Core

Most banks read their app drop-off rate as a verdict on the app. The rate is high, so the screens must be wrong, so the screens are redesigned. When the rate barely moves, the conclusion is that the friction is subtler than expected, and another round of testing begins. The rate is treated as a property of the interface because the interface is what the digital team owns. What the same rate might say about the core banking system underneath is rarely asked, because the core belongs to someone else.

The evening problem

A retail bank we worked with had been round that loop for a year. Its account-opening funnel showed the steepest fall at a confirmation step near the end, a screen with almost nothing on it. The team had shortened it, reworded it and moved it, and the fall stayed where it was. Only when the rate was split by hour did a pattern appear: applicants who reached the step late in the evening abandoned it at roughly twice the daytime rate. The screen was identical at nine in the evening and at nine in the morning. The system behind it was not.

That confirmation step was the first point at which the app asked the core to create a customer record. In the evening the core was running its end-of-day processing, and requests from the app waited in a middleware queue until it finished. The applicant saw a spinner, then a polite message asking them to try again later. The bank had spent a year redesigning a screen whose only real fault was that it waited on a system the digital team had never been asked about.

Four seams worth splitting

A core banking system built around branch processing imposes constraints the app inherits without displaying them. Each tends to surface along a particular seam of the drop-off rate, and the seams are visible to anyone who splits the rate along them instead of reading it as one number:

• by hour and day, where abandonment that rises during batch windows, month-end runs or maintenance slots points at a core that is slow or unavailable at those times
• by step, where the steepest fall sits at the first synchronous call to the core, for customer creation, account number allocation or an eligibility check, rather than at the longest form
• by product, where some accounts open straight through and others, a joint account, a second currency, a product configured years ago, are quietly routed to manual handling because the core cannot open them in one pass
• by applicant history, where former customers fall away more often, because the core finds an old record and its matching rules stop the application rather than resolve it

None of these seams appears in a funnel organised by screen. A funnel counts sessions reaching steps, and its view of the applicant ends at submit, the blind spot traced in why banks lose applicants where the funnel stops looking. A step that waits on the core looks, in a funnel, exactly like a step that confuses the applicant.

What the form inherits

There is a fifth mark, and it sits in plain sight. Many application forms ask questions whose purpose the applicant cannot see, because the core's customer record makes those fields mandatory, a legacy of the branch form it was designed around. The digital team receives them as requirements handed down. Session limits often belong here too: in several banks we have looked at, an application could not be held open longer than the core would reserve a pending record, which is why interrupted applicants so often returned to an empty form. Some of what looks like friction in the app is the core's data model, rendered as questions and timeouts. Which of those constraints regulation requires and which the platform merely insists on is rarely written down in one place.

Joining two logs

The method needs two sources that seldom meet: the app's event log and the integration log of the middleware that carries calls to the core. Each application carries a reference in both. Joined per application, they show for every applicant who left what the app was waiting for at the moment they left, how long it had been waiting, and whether the core answered at all. The join is usually a few days of work for one engineer who knows both systems.

We then split the drop-off rate along the four seams and set each slice against its counterpart: evening against daytime, steps that call the core against steps that do not, straight-through products against routed ones, new applicants against returning ones. Where the slice that touches the core loses applicants markedly faster, the core belongs in the diagnosis. Where the slices look alike, it probably does not, and the screens keep their place.

A step that waits on the core looks, in a funnel, exactly like a step that confuses the applicant.

The test that settles it

The cleanest evidence comes from the rate's own history. We plot it against the dates of front-end releases and against the dates of changes to the core or its middleware. A rate that ignored three redesigns and then moved the week a timeout was changed in integration has answered the question by itself. What the drop-off rate has actually responded to is a more honest diagnosis than any opinion about what it should have responded to.

The replacement reflex

Once the core appears in a drop-off diagnosis, the conversation tends to jump to the largest available answer. Core replacement is a multi-year programme with its own vendors, sponsors and momentum, and a drop-off finding can be pressed into its business case within a week. That is usually premature. Most of the constraints the seams reveal can be worked around by changing what the app asks of the core, and when it asks.

Taking the batch out of the applicant's path

At the retail bank, the repair did not touch the core. The app stopped creating the customer record at the confirmation step. It accepted the application, told the applicant it had been received, and passed the request to the core once the batch window closed. The mandatory fields were reviewed with compliance, and those that served only the platform were filled with defaults the core accepted. Returning customers were matched by operations the next morning instead of being stopped on screen. Each change moved a core constraint out of the applicant's path without asking the core to behave any differently.

Some constraints do not yield to sequencing. A product the core cannot open in one pass stays that way until it is reconfigured or rebuilt. That is where the drop-off diagnosis earns a place in a core business case, priced group by group as in the four bills of onboarding drop-off, rather than serving as the opening slide of a programme that was going to be proposed anyway.

Our work on app drop-off starts by splitting the rate along the core's seams before anyone redesigns a screen. Joining the app's events to the integration log usually shows within a fortnight whether the constraint sits in the interface, in the core, or in the way the two were wired together.

From there our consulting engagements inside the diagnosis before solution pillar sequence the workarounds and price what remains, and our training programmes teach digital, technology and operations teams to read one drop-off rate together rather than hold three explanations of it. What an app drop-off rate tells a bank about its core is worth hearing before the next redesign is commissioned, and before the next replacement programme is.