When a digital banking app has a high drop-off rate, the instinct is to call a UX review. You might do things like reducing steps, making your copy clearer, or hiring a conversion specialist.
These things sometimes help, but running UX reviews that don’t seem to move activation numbers usually means the problem isn’t in the design, it’s in the infrastructure underneath the design.
This article is about reading drop-off data properly; understanding what it is and isn’t telling you, where the problem actually lives, and what it takes to fix it in a way that holds at scale.
The numbers are worse than most institutions admit
68% of consumers abandon digital banking applications mid-onboarding because the process is too long or complex. That number has been climbing, up from 63% in 2020, despite significant industry investment in digital transformation. More than half of all mobile banking applications end in user abandonment, and every second financial institution admits to experiencing drop-offs in its digital channels.
The drop-off funnel for a typical digital banking app looks like this: up to 35% of users drop off after installing but not completing sign-up, 40–50% abandon during KYC, and over 20% leave even after completing KYC, while waiting for delayed account activation.
That last number is the one worth dwelling on.
A user who completes KYC has already done the hardest work. They’ve submitted their documents, passed the identity check, and invested real time and intention into the process.
Losing one in five of them, not to friction, but to waiting, is not a UX problem.
It is an infrastructure problem.
The business cost is significant. 70% of banks lose clients due to slow onboarding. Every abandoned application represents the full cost of acquiring that user as written off before the customer relationship has generated a single transaction.
What drop-off data is actually measuring
Drop-off analytics typically show you where users leave. Step 1: install. Step 2: account creation. Step 3: KYC initiation. Step 4: verification. Step 5: activation. The report tells you what percentage of users make it from each step to the next.
What it does not directly tell you is why they left. And the why almost always lives in one of three places that standard UX analysis misses.
Processing latency that isn’t visible in your analytics
A user who abandons three minutes into a KYC flow looks identical in your data to a user who abandons because the step was confusing. But if those three minutes included two minutes of loading time, for example, a KYC integration that is running a slow API call, an identity verification provider that is timing out intermittently, or a document upload that is re-uploading because the connection dropped, the fix is not a copy change, it is a latency fix in the integration layer.
Onboarding drop-off rates using micro-deposit verification can reach 49%, while the same metric for instant account verification drops to 1%. That is not a user behaviour difference. It is the same user, with the same intent, experiencing a different infrastructure response time. The 48-point gap is entirely explained by how fast the verification layer responds.
Session failures that look like voluntary abandonment
In markets with variable connectivity, which can include meaningful portions of Nigeria, Indonesia, and the Philippines, a user who loses connectivity mid-flow and cannot resume without starting again appears in your data as a drop-off. They made a deliberate decision to stop. In reality, they hit a wall. Starting again means re-uploading the same documents, re-entering the same information, and confronting the same uncertain wait time.
If your onboarding flow doesn’t support partial progress and session resumption, you are misattributing connectivity-related failures as user decisions. And because you can’t see the connectivity event in your standard analytics, the fix looks like better UX when the fix is actually session state management in the core.
Backend delays that surface as front-end abandonment
The most commonly misdiagnosed drop-off point is the activation wait. A user completes the KYC flow, reaches a notification of application review screen, and does not come back. Every day they wait before their account is confirmed, the probability of re-engagement falls. More than 20% of users who complete verification never activate because of delayed activation.
The wait is almost never a compliance necessity. Most KYC verification, for the straightforward majority of applicants, can be completed in seconds if the verification provider returns a result in real time and the core banking system is ready to receive it and open the account immediately. The delay exists because one or both of those things is not in place; the KYC API is running asynchronously with no real-time webhook, or the core processes account creation in a batch run rather than in response to a verification event.
The front-end tells the user to wait.
But the back-end is what is making them wait.
The three infrastructure gaps that drive most drop-off
Gap 1: Synchronous KYC that isn’t actually synchronous
The best-in-class onboarding experience for a digital banking app completes identity verification in under 30 seconds as a single unbroken flow the user experiences as instant.
This requires: a KYC provider whose API returns a result synchronously within that window, an integration between your onboarding flow and your KYC provider that does not introduce additional latency, and a core banking system that can create the account and return a confirmation in the same session, not in a subsequent batch process.
Most institutions have one or two of these. Very few have all three operating below the latency threshold that keeps users in the flow. The ones that are missing the third where the core processes account creation asynchronously, even when the KYC result arrived in real time are losing the post-verification cohort. These are the users who completed KYC and did not receive an immediate confirmation that their account was open.
The fix requires the core to process account creation events in real time, triggered by the KYC result, not by a scheduled batch. This is an architectural property of the core, not a configuration change.
Gap 2: No session persistence across connectivity drops
More than half of mobile applications end in user abandonment in financial services. In emerging markets, a meaningful proportion of that abandonment is connectivity-driven. But the drop-off data almost never separates connectivity abandonment from voluntary abandonment, because standard analytics don’t capture the connectivity event.
The operational implication is that institutions are investing in UX improvements, such as shorter flows, better copy, or clearer instructions, for a cohort of users whose decision to abandon was driven by their network, not their experience of the interface. The UX investment has no effect on this cohort because the interface is not the problem.
What this cohort needs is session state persistence: the ability to close the app, reconnect, and resume exactly where they left off, with their documents still attached, their data still entered, their verification still in progress. This requires the application to store partial progress against the user’s session in the core, not just in the local device state that clears when the app closes.
Institutions whose core doesn’t support partial onboarding records cannot build session resumption without significant workarounds. The onboarding flow starts from a clean application form because the core has no concept of an in-progress application.
Gap 3: KYC integrations built for compliance, not for user experience
The third infrastructure gap is the most common and the most underappreciated. Many institutions have integrated their KYC verification layer in a way that satisfies compliance requirements but does not optimise for conversion.
The clearest example is document upload failure handling. A user uploads a photograph of their ID. The document is rejected and the application returns an error message, so the user tries again, and the document is rejected again. A single failed document upload can trigger complete abandonment.
The compliance integration is working correctly; it is returning an accurate result. But the user experience of that accurate result is a barrier, not a guide. An integration built for conversion would return the specific reason for rejection and a guided retry prompt, detect common failure conditions (lighting, angle, resolution) in real time before submission, and offer an alternative capture method when the standard method is failing.
None of this requires changing the compliance outcome. It requires the integration to surface more specific information from the KYC provider’s response, and the front-end to use that information to help the user succeed rather than presenting a generic error.
This is a product engineering problem, but it sits at the integration layer, not the UI layer. The fix is in how the onboarding flow reads and handles the KYC API response, which means it is a backend change, not a design change.
What accurate drop-off analysis looks like
Before investing in UX fixes, the diagnostic question is: which part of your drop-off is interface-driven and which is infrastructure-driven?
A basic way to separate these includes the following.
Instrument your integration latency, not just your user flow
Log the response time of every external API call in your onboarding flow; KYC verification, document processing, account creation confirmation. Compare latency against step-level drop-off rates. If drop-off at the KYC step correlates with higher-than-average verification response times, the fix is latency, not UX.
Separate connectivity abandonment from voluntary abandonment
Log network connectivity events during onboarding sessions. If a meaningful percentage of your drop-offs occurred during or immediately after a connectivity interruption, you have a session persistence problem, not a design problem.
Measure time-to-activation for completed KYC users
For users who completed verification but did not activate, plot the abandonment rate against time since completion. If abandonment is heavily concentrated in the first two to four hours, you have a batch processing problem in your core, not a re-engagement problem.
Track document upload failure rates and retry behaviour
If your drop-off at the document upload step has high retry rates before abandonment, the issue is guidance, not intent. These users wanted to complete the process and could not. That is solvable with better error handling in the integration layer.
The infrastructure properties that make high activation rates possible
The institutions achieving activation rates consistently above 60% in markets with the same demographic, the same regulatory requirements, and the same connectivity conditions as those achieving 30–40%, share a specific set of infrastructure properties.
Real-time account creation triggered by events
When a KYC result arrives, the account opens. Not in the next scheduled run. The user receives a confirmation in the same session. The integration between the KYC provider and the core is event-driven.
Partial application state persisted in the core
An in-progress onboarding application is a record in the system; with the data entered so far, the documents already uploaded, and the verification steps already completed. If the session drops, the user resumes from that record, not from a blank form.
KYC integrations that surface specific rejection reasons and retry guidance
The onboarding flow reads the full API response from the KYC provider, not just the pass/fail result. Rejections include the reason. The user is guided to a successful retry rather than presented with a generic error.
Onboarding flows that maintain state through connectivity interruptions
The application saves progress to the server, not only to the device. A user on a variable network can close and reopen the app and find themselves at the same step, with their data intact.
None of these are front-end properties. They are properties of the core banking system and the integration architecture connecting the core to the onboarding flow.
The right conversation to have after reading your drop-off report
Most drop-off report reviews end with decisions about redesigning the onboarding flow, rewriting microcopy, or adding a progress indicator. These changes have their place, some of them do improve conversion. But if the core infrastructure properties above are not in place, the conversion improvements from UI changes will be modest and will not compound.
The right questions to ask after reading your drop-off report:
- What is the average response time of our KYC integration, and how does it correlate with drop-off at the verification step?
- What percentage of our drop-offs occurred during or immediately after a connectivity interruption?
- For users who complete KYC verification, what is the time between completion and account confirmation and how does abandonment in that window relate to our batch processing schedule?
- What specific rejection reason does our application surface to a user when a document upload fails and does that reason come from the KYC API response or from a generic error handler?
The answers will tell you whether your drop-off problem is a UX problem, an integration problem, or a core infrastructure problem. In most cases, it is some combination of all three, but the infrastructure problem is the one that limits how far the UX improvements can go.
Your app’s drop-off rate is not primarily telling you that your design is wrong. It is telling you where your infrastructure is slower than the user’s willingness to wait.
Is your drop-off rate a UX problem or an infrastructure problem?
Most institutions find out the hard way. Talk to our team by emailing vanda.jirasek@oradian.com to discuss what your onboarding data is really telling you and what it would take to fix it at the source.
For more on the infrastructure requirements behind high-performing digital onboarding, read the Oradian Growth Playbook for Banks.
