Account Aggregator drop-offs happen before the OTP

When a product team integrates India’s Account Aggregator framework, launch metrics usually follow a disappointing curve. Technical integration tests pass with 100% reliability in sandbox environments, but the moment real users hit the production funnel, drop-off rates spike above 40% before a single byte of financial data is fetched.

The engineering post-mortem often points to bank downtime or third-party SDK latency. But session replays show that drop-offs rarely happen because of an API failure. They happen because product teams treat Account Aggregator (AA) as a background data pipeline rather than a high-friction consent interaction.

In India’s financial ecosystem, regulated under the Reserve Bank of India Master Directions for Account Aggregators, the AA network acts as a consent broker between Financial Information Providers (banks) and Financial Information Users (lenders or personal finance apps). The framework is architected for privacy, but privacy requires explicit user comprehension. When an interface fails to explain what is happening, who is asking, and why a second SMS just arrived, users close the app.

The dual-SIM reality breaks account discovery#

The single largest drop-off in the Account Aggregator journey occurs in the first five seconds, during account discovery. An applicant signs up for your product using their primary data SIM. But their legacy salary or savings account at a bank is tied to a secondary mobile number they have used for years.

When your client initiates discovery against the AA registry using the signup mobile number, the API returns zero discovered accounts.

Most default SDK implementations handle this scenario with a dead-end message: “No accounts found for this mobile number.” The user assumes the service is broken or their bank is unsupported, and leaves. In unoptimized funnels, this single failure mode accounts for 18% to 24% of all initiated sessions.

[ App Signup: Number A ] ──> [ AA Discovery: Number A ] ──> [ FIP Bank: 0 Accounts ] ──> Abandon

To fix this, decouple your application’s identity phone number from the bank discovery phone number. Before calling the discovery API, present an explicit confirmation prompt:

“We will look for your accounts linked to +91 98XXX XXXXX. Is your bank account registered with this number or a different SIM?”

Providing a simple “Use a different bank-linked number” input with inline SMS verification recovers more than half of these stranded sessions. It treats dual-SIM usage not as an edge case, but as the default operating reality of the Indian smartphone market.

Consent scope paranoia kills conversion#

Once accounts are discovered, the user faces the consent approval screen. This screen is governed by regulatory requirements specified by Sahamati’s operational framework, detailing the Financial Information User, data life, fetch frequency, and date range.

Too many product managers accept the default SDK consent template, which often requests recurring access for three years with daily fetch frequencies. When an applicant applying for a one-time credit check sees a legal screen stating that an external app will monitor their bank account daily until 2029, trust evaporates.

Every additional month of requested transaction history and every recurring fetch permission decreases consent completion. If your underwriting policy only scores based on the last 180 days of cash flows, request exactly 180 days.

Consent conversion is inversely proportional to the blast radius of the requested permission.

Pair this minimal scope with plain-language assurances directly above the consent trigger: confirm that consent does not permit moving money, and that consent can be revoked at any time from their Account Aggregator profile.

The two-step OTP journey needs a visual contract#

In payment workflows, Indian consumers expect a single Two-Factor Authentication (2FA) prompt. In the Account Aggregator flow, users encounter two distinct OTP steps:

1. AA Registration / Login OTP: Validates the user’s mobile number with the regulated Account Aggregator entity (such as Setu, Finvu, or Anumati).
2. Bank FIP Linking OTP: Sent directly by the user’s bank to authorize linking and data sharing for the selected account.

When users receive the first OTP, they enter it and expect immediate completion. When a second OTP prompt instantly appears on screen from a completely different SMS header (such as VK-HDFCBK instead of the AA provider), confusion sets in. Users assume the system looped or that a duplicate action is being authorized.

Include the bank’s brand mark alongside the second OTP input field. Seeing their bank’s familiar logo grounds the interaction and reassures the applicant that the incoming bank SMS is legitimate.

Set a hard latency budget and preserve state on fallback#

Financial Information Provider (FIP) APIs operate on heterogeneous banking infrastructure. While leading private banks respond to discovery and consent requests within two to three seconds, public sector banks and regional cooperative institutions can experience latency spikes exceeding 15 seconds, or suffer temporary timeouts during peak hours.

If your onboarding screen displays an indefinite spinning loader, the user will abandon the session within 10 to 12 seconds. Worse, if your frontend handles a timeout by throwing a generic error alert that resets the application form, you force the user to re-enter personal details from scratch.

Implement a strict client-side latency budget of 12 seconds for the entire AA exchange:

AA Request Initiated (0s)
   │
   ├─► Success within 12s ──► Ingestion & Parsing ──► Complete
   │
   └─► Timeout at 12s ─────► Graceful Degradation
                                │
                                ├─► Net Banking Login (Alternative)
                                └─► Direct PDF Statement Upload (Prefilled)

If the 12-second window lapses without a successful consent callback, transition the screen immediately to your secondary ingestion rail: Net Banking login or encrypted PDF statement upload. Pass forward the user’s verified mobile number, selected bank name, and application ID so the fallback screen is already pre-configured. The user experiences the fallback as an intentional, helpful alternative rather than a broken journey.

The four funnel metrics that diagnose drop-off#

Measuring Account Aggregator performance using a single top-level metric like “AA Success Rate” conceals the exact point of friction. To maintain a healthy ingestion pipeline, track four isolated ratios across your analytics pipeline:

1. Discovery Rate (Discovered Accounts / Initiated Flows): Diagnoses phone number mismatches and FIP lookup downtime. If this drops below 75%, audit your phone-number matching logic and prompt copy.
2. Account Selection Rate (Selected Accounts / Discovered Accounts): Diagnoses confusion when a user holds multiple accounts at the same institution (such as dormant joint accounts versus active salary accounts).
3. Consent Completion Rate (Verified Bank OTPs / Rendered Consent Screens): Measures user trust and OTP delivery reliability. If this drops, review consent scope duration, recurring fetch permissions, and two-step progress messaging.
4. Data Delivery Rate (Parsed Statements / Verified Consents): Measures technical reliability of the FIP data payload transfer. A drop here indicates downstream bank server latency or schema deserialization bugs.

At your next product review, look at your drop-offs through this four-part lens. If your discovery rate or consent completion rate lags behind technical uptime, stop debugging the API client. Fix the consent messaging, give users control over their bank-linked mobile numbers, and set up state-preserving fallbacks before writing another line of backend code.