The Account Aggregator Update Nobody Wants But Everyone Has to Do
There’s a deadline coming on September 30, 2026, and if you’re running an FIP or building on Account Aggregator, you’re going to feel it. By that date, you have to support PAN and DOB for account discovery-not because it’s a nice feature, but because the current system is breaking under real-world use.
I know this because I’ve watched it happen across multiple FIPs over the past few months. Teams thought AA was working fine until they started looking at their actual discovery success rates. That’s when the conversation changes.
The Problem That Started All This
Here’s what’s really happening in the field right now: Account discovery via mobile number alone is failing way more often than anyone publicly admits.
Last month, I was talking to a payments bank running AA integrations. Their data? About 15-20% of users hit a situation where the account discovery call comes back empty. The customer knows they have a savings account at that bank. But the discovery fails because the mobile number on their bank records is a SIM they haven’t used in three years.
This happens more in India than most people want to acknowledge. Branch-opened accounts often have outdated phone numbers. Customers change SIMs without updating their banks. Someone closes a line and moves to a new carrier. Now when they try to link their bank account via an Account Aggregator, the system can’t find them.
The AA team sees a user bounce out of the account linking flow. The FIP sees a failed discovery call. The customer sees a broken product. Everyone loses.
ReBIT saw this pattern and decided: We have to fix this. Not with machine learning. Not with better UX. Just with more data.
The fix: Let account discovery work backwards. Try mobile number first (it works for 80-85% of cases). When that fails, try PAN. If that fails, try DOB. More identifying information = more successful matches = more accounts actually get linked.
It’s not elegant. It’s not innovative. It’s pragmatic infrastructure work. And it’s mandatory by September 30.
Why You Can't Skip This
Let me be direct: There is no exemption. If you’re an FIP live with AA, this is coming to your system.
ReBIT made this mandatory for a reason. Right now, the AA ecosystem is useful for maybe 70-75% of users who try to link accounts. That’s below where it needs to be for an open financial data infrastructure to actually work. PAN + DOB isn’t going to solve everything, but it’ll move the needle to 85-90%, which changes the whole value prop.
From the regulator’s perspective, account discovery is still broken. From your perspective, it’s a significant piece of work that’s going to hit your backlog in the next few months.
Risk Lending Score: Measuring Probability of Default
While identifying future credit demand is important, understanding repayment capability is equally critical.
The Risk Lending Score (RLS) assesses future repayment risk by evaluating patterns across banking activity, transaction behaviour, account balances, outstanding liabilities, BNPL utilization, insurance coverage, and lifestyle spending trends. Together, these signals provide a forward-looking view of a borrower’s financial stability and ability to meet repayment obligations.
A declining RLS can act as an early warning signal of increasing financial stress, allowing lenders to take proactive measures before risk translates into delinquency.
What This Actually Means for You (The Work Breakdown)
So you’re an FIP. You’re live with Account Aggregator. Account discovery is working-users are linking accounts, data is flowing. And now you have to rebuild a core piece of that system by September 30.
Here’s what’s actually required:
Your /Accounts/discover API endpoint needs to change. Today it probably takes a mobile number and returns matching accounts. Soon it needs to accept mobile, PAN, and DOB-and validate all three in sequence.
The logic is strict: Try mobile first. If that matches, great, return the account. If mobile doesn’t match but PAN does, return the account. If mobile doesn’t match and PAN doesn’t match but DOB does, return the account. But here’s the part that catches people: If mobile matches but PAN doesn’t, you have to fail the entire request. No account returned. This is anti-fraud. It’s saying “your mobile is right but your PAN is wrong, so something’s not adding up here.”
On the data side: You’re going to be touching PAN and DOB. These are sensitive identifiers. Every system that logs them-your application logs, your error tracking, your monitoring dashboards-has to mask them. PAN shows up as AAAPK****Z. DOB shows up as 19**-**-15. And after the discovery call completes, they’re gone. Not cached. Not kept for analytics. Deleted.
The reasoning is clean: PAN and DOB are only for account discovery. Not for building credit risk models. Not for analytics. Not for cross-selling. Only discovery. If you want to use this data for anything else, you need the customer to consent again. Purpose limitation is the guardrail here, and it’s enforced.
If you miss this timeline? October 1 rolls around, your API doesn’t support PAN/DOB, and AAs start failing when they call you. Your audit trail shows you weren’t ready. Your certification could be questioned.
The Work: What Your Team Actually Has to Build
I’ve watched this unfold at a few FIPs now, and here’s how it typically goes:
Week 1-2: Your CTO audits the current account discovery code. They find that it’s mobile-number-centric. The search logic is clean, built for speed, indexed for mobile lookups. Adding PAN? DOB? That’s new. If your PAN data is in a different table, or if it’s not indexed, or if it’s stored with the KYC data in some legacy system, this gets complicated fast.
Week 2-3: Your backend team starts refactoring. They’re building sequential search logic now-try mobile, if that fails, try PAN, if that fails, try DOB. And they have to handle the hard case: What if mobile matches but PAN doesn’t? You can’t just pick whichever identifier works. You have to fail. This is anti-fraud logic, not convenience logic.
Meanwhile, your DevOps or platform team is thinking about masking. PAN can’t show up unmasked in Datadog. DOB can’t appear in error logs. So now you’re updating your logging infrastructure-applying masks at the source, before data ever hits a log aggregator. This is more complex than it sounds because you might have three different logging systems. Masks have to be consistent everywhere.
Week 3-4: QA picks up the work. They’re testing all the edge cases:
- Mobile match succeeds (straightforward)
- Mobile fails, PAN succeeds (common case, going forward)
- Mobile matches, PAN doesn’t (the scary one-you have to fail)
- Non-PAN accounts like BSBDA (special case for basic savings accounts)
- What happens when PAN is malformed, or DOB is in the wrong format?
Week 4-5: Your infrastructure team is now worried about performance. PAN and DOB queries-are they fast enough? Mobile number queries are probably blazingly fast because they’re indexed and hit a small table. PAN queries might touch different tables or require joins. Load test time. If PAN/DOB searches are slow under load, you’ve just introduced a latency problem in your entire discovery pipeline.
This is where teams often discover their database schema wasn’t built for this. A week in August, you realize “PAN queries are 300ms slower than mobile queries.” Now you have an emergency optimization project that wasn’t in the plan.
Week 5-6: Data deletion logic. After a discovery call completes, PAN and DOB are gone. This sounds simple-“just don’t store it”-but in practice, you need to be intentional. Are you caching it temporarily? Set a 5-minute TTL, not 24 hours. Are there backups? Make sure backups don’t contain unmasked PAN/DOB. Is there an audit trail? Make sure it only logs masked values.
Week 6-7: Partner testing. You reach out to AA teams and say “we’re ready, come test with us.” Some of them won’t have prioritized testing yet. Some will be testing with five different FIPs simultaneously. Coordination takes time.
By week 7-8, you’re pushing production. Late September, you go live. For the next two weeks, someone’s watching your discovery success metrics closely. Are they improving? Staying flat? If they drop, you might have to roll back and debug.
The Real Timeline Pressure
You have 67 days from now until September 30. Sounds like enough time. It’s not.
Account for weekends (9-10 days gone), holidays (maybe 2-3 days), all-hands meetings, code review cycles, and the inevitable blockers that show up in late August. You’re really looking at 40-45 days of actual development time.
And here’s what I’ve seen happen: Teams get to August and realize their database schema doesn’t play nicely with fast PAN lookups. Or they discover that unmasked PAN is appearing in three different monitoring systems. Or their AA partners tell them in late September they’re not ready to test yet.
Start now. Not in August. Now.
Why This Actually Happened (And What It Tells You)
Here’s the thing that doesn’t get said out loud: Account discovery is failing at a rate that wasn’t acceptable to ReBIT.
I don’t have the exact numbers, but from talking to people inside multiple FIPs and AAs, the story is consistent. When AA went live, people thought “mobile number is good enough-it’s how KYC works.” But real-world data showed something different.
Mobile-number-only discovery has a silent failure rate of 15-25%, depending on the FIP and geography. That means 1 in 4 to 1 in 6 users trying to link their account hit a wall because the bank has an outdated phone number. Some users persist. Most don’t. The consent journey collapses before it starts.
From the regulator’s perspective, that’s not acceptable. AA is supposed to be infrastructure for open financial data sharing. If your infrastructure can’t reliably identify and link accounts, it’s broken infrastructure.
ReBIT looked at this and made a pragmatic call: Let’s use the data points we have. PAN is issued by the income tax department-it doesn’t change. DOB is stable. If mobile fails, try PAN. If that fails, try DOB. Three shots to identify the customer instead of one.
It’s not sexy. It doesn’t enable new business models. It just makes the plumbing work.
What this tells you about the regulatory mindset: This isn’t visionary regulation. It’s maintenance regulation. ReBIT is focused on “make what exists work reliably” rather than “enable new possibilities.” That shapes how you should think about your roadmap over the next 2-3 years. Expect more of these mandatory infrastructure fixes. Expect them to be operational burdens. Expect them because the ecosystem isn’t yet at the maturity where it can skip them.
The Timeline (Where Things Actually Go Wrong)
I’ve watched teams approach this in a few different ways. Here’s what I’ve learned:
If you start now (July), you’re probably okay. Not comfortable, but okay.
If you start in August, you’re cutting it close. You can get it done, but you’ll be testing in late September, going live two weeks before the deadline, and crossing your fingers nothing breaks.
If you start in September, you’re already late. I’m not exaggerating.
Here’s why: Most teams underestimate this work by about 3-4 weeks. They think “it’s just adding PAN and DOB to the search logic” and don’t account for the full scope.
The thing that usually derails timelines: Database performance.
Week 4-5 of development, someone runs a load test and discovers that PAN queries are slow. Really slow. Maybe your PAN data isn’t indexed the right way, or it’s in a separate table, or the lookups require joins that weren’t optimized. Now you have an emergency optimization project that’ll take 1-2 weeks.
This happens to teams who don’t do their schema audit early enough. So start there. In the next week, have someone who knows your database look at where PAN and DOB live, how they’re indexed, and whether those lookups will be fast under load. If the answer is “I’m not sure,” you have work to do before you even write code.
The second thing that usually causes headaches: Backward compatibility.
You’ll have AAs testing your old endpoint (mobile-only) at the same time you’re building the new one. You need both to work. This seems obvious, but teams often assume they can just flip a switch on September 30. In reality, you’re supporting two request formats simultaneously for weeks. Make sure your testing accounts for that.
The third issue: Late partner testing.
You’re going to need to test with AA partners. Don’t wait until September. Reach out in July. Tell them you’re building this, ask when they want to test on staging. Some teams move fast. Some teams don’t prioritize until September, and then you’re trying to coordinate testing two weeks before go-live.
Real timeline that usually works:
- Now – Early August: Audit, planning, team alignment
- Early August – Mid August: Core development (search logic, masking, deletion)
- Mid August – Late August: Testing, optimization (this is where the database performance issues surface)
- Late August – Early September: Staging deployment, partner testing, bug fixes
- Early-Mid September: Production deployment, monitoring
- Mid-Late September: Watch metrics, respond to issues
If you hit late August and still have major work to do, you’re in a risky position.
If You’re Running an FIP
You can’t skip this. I want to be clear about that. There’s no way to work around this, no exemption request that’ll get approved, no “we’ll do it in Q4” negotiation.
By October 1, your API needs to support PAN and DOB discovery. AAs are going to call your endpoint with all three identifiers, and if you’re not ready, they’ll fail. Your audit trail will show you weren’t compliant. That becomes a problem in your next certification cycle.
I’d honestly start this week. Do the schema audit. Figure out where PAN/DOB live in your systems. Rough out the development plan with your team. The goal isn’t to start coding immediately-it’s to know exactly what you’re building and when the bottlenecks will hit.
And when someone from your team says “this is just adding a few fields to the API,” politely remind them about the masking, the deletion logic, the database performance testing, and the late-stage coordination with AA partners.
If You’re an AA or Fintech Building on AA
Your life is going to depend on FIPs getting this done. Some will. Some will be late. Some might do it halfway and create weird edge cases for you to handle.
Start thinking now about what happens if an FIP hasn’t upgraded by October 1. Your account discovery flow is probably built for mobile-only requests right now. What’s your fallback? Can you gracefully degrade to mobile-only? Can you tell users “your bank doesn’t support PAN discovery yet, try again next week”?
And coordinate with your FIP partners early. Not September. Now. Tell them you’re planning to test PAN/DOB discovery and ask what their timeline looks like. Some of them might already be building this. Some might not have thought about it yet. You want to know which is which before the rush starts.
The Conversation I'd Have with Your Team
If I were sitting in your engineering standup right now, here’s what I’d say:
“We have a mandatory regulatory update coming by September 30. It’s going to touch your core account discovery logic. It’s not catastrophically complex, but it’s real work spread across backend, data, logging, and testing. We’re going to need 4-5 weeks of focused effort-probably two engineers for most of that time.
The biggest risk is database performance. We need to audit our schema this week and understand whether PAN/DOB queries will be fast enough under load. If they’re not, we have an optimization project on top of the development work.
We also need to think about backward compatibility. We’re going to be supporting both old and new request formats for a while. Let’s not pretend that’s simple.
And partner coordination. We need to test with AAs before we go live. That means staging environment work in August. Reach out now and set expectations.
This is doable. But it starts today, not in August. Questions?”
What I Actually Want You to Do
If you’re an FIP: Pull your tech lead aside this week. Ask them to audit your account discovery code and database schema. You need to know by early next week whether there are any structural problems (like PAN data being slow to query). Once you know that, you can plan the real work.
If you’re an AA: Map out which FIPs are live with you. Make a list. Start reaching out to them this month and ask about their September 30 readiness. You’ll probably get responses ranging from “we’re already building it” to “when is this due again?” Both answers are useful.
The deadline is September 30. That’s not negotiable. The work is real. Don’t assume you’ll get to it next month.
Start this week. Seriously
