Your Financial Data, Your Choice: What ReBIT’s New AA Standards Change

By Prithviraj Singh Chauhan | Finanjo | Updated 19 October 2026

Imagine connecting your bank account to a money-management app. You want to understand where your salary went this month. A screen asks for permission, an OTP arrives, and a few taps later your transactions appear.

But could you explain what you just agreed to? Which company will receive the information? How often can it ask for fresh data? When does that permission end? Where would you go to stop it?

Those questions are central to the latest Account Aggregator changes. They matter to someone reviewing household spending just as much as they matter to a fintech building a lending or investment journey.

ReBIT’s AA client standards are moving into implementation ahead of the 31 October 2026 adoption deadline cited in Sahamati’s July circular. The practical question for fintechs is how to make the permission a customer gives understandable, deliberate and manageable throughout the relationship. Sahamati’s adoption circular

What is changing, and who is changing it?

It is easy to describe this as “Sahamati changing the ReBIT guidelines.” More precisely, ReBIT published version 1.0.0 of its AA client standards on 30 April 2026, covering customer protection and user experience. Sahamati subsequently circulated implementation and reporting guidance to participants. Sahamati’s May announcement

The roles are different:

• An Account Aggregator (AA) manages consent for sharing financial information.
• A Financial Information Provider (FIP) holds the information, such as a participating bank.
• A Financial Information User (FIU) requests it for a stated financial service or purpose.
• A Technology Service Provider (TSP) helps participants implement the technology.

“Fintech” is a business description, not a single role in this framework. Sahamati’s FAQ makes clear that an unregulated startup cannot simply act as an FIU or FIP. Companies need to establish which regulated entity, AA and technology arrangement their customer journey actually uses. Sahamati FAQ

That distinction matters when an account-connection screen appears inside an app. The user should still be able to understand which organisation is asking, which organisation is managing permission, and where to get help.

October 31 is one deadline among several

Different AA initiatives are progressing at the same time. Their dates should not be mixed together.

Date	What it relates to
5 October 2026	The earlier final-report submission date to Sahamati for SEBI-regulated FIUs, to support its consolidated reporting.
31 October 2026	AA client standards adoption, as stated in Sahamati’s July circular.
30 November 2026	Adoption of Sahamati’s Fair Use Implementation Guidelines v2.0 by AAs and FIUs.
1 December 2026	ReBIT’s revised interoperability adoption deadline, announced on 16 October, replacing 31 December.

Sources: July adoption circular, September fair-use circular, ReBIT announcements.

For a fintech team, this calls for separate workstreams. A consent-screen release does not establish that the fair-use implementation is ready. An interoperability integration does not establish that users can understand the consent screen. Each needs its own scope, owner and evidence.

What users should notice in the consent journey

The most useful way to understand the changes is to follow the decisions a person makes.

Customer question	What the updated journey needs to make clear
Who receives my information?	The FIU requesting the data and the AA managing the consent.
What am I agreeing to?	The purpose, financial-information types, historical data period, permission dates and fetch frequency.
Can I choose which accounts to share?	Account selection must be an active choice, without preselected accounts.
Can I say no?	Approve and Reject must have equal size and visibility; approval must not be the default.
Are several permissions bundled together?	Multiple consents need separate approval and rejection controls.
Can I review what happened later?	A consent dashboard should show active permissions and data-fetch history.

These are reflected in ReBIT’s published adoption checklist. Adoption Progress Report template

Consider the opening example. A spending analysis request and a later credit application are different decisions for the customer. A good product should explain the value of each request at the moment it is made. It should not rely on the customer remembering a vague permission from weeks earlier.

Our view is that this changes how teams should evaluate onboarding. Completion rate remains useful, but it cannot tell us whether the person understood the decision. A short usability interview can reveal something a conversion chart misses: whether a customer can explain who receives their information and why.

Stronger authentication will be visible

ReBIT specifies two-factor authentication for AA registration and each login, with security controls suited to the client type. Its examples include a credential combined with an OTP or TOTP. The standard does not establish one universal four-digit MPIN journey for every implementation. ReBIT client standards, section 5.1

Users may therefore encounter an additional authentication step. The product challenge is to explain what that step protects and to make recovery understandable when a person forgets a credential or changes devices.

For implementation teams, a successful first login is only the beginning of testing. Try an expired OTP, an interrupted session, a forgotten PIN and a return visit. Support teams should be able to describe the next safe step without asking customers to disclose their credentials.

Language and error messages affect real decisions

The adoption checklist includes multilingual support, accessibility and usability testing. ReBIT confirmation checklist

A language selector is useful only if the important parts of the journey remain understandable after the user selects a language. A Hindi heading followed by an unexplained English permission is a poor experience. So is a translated approval screen followed by an error the customer cannot interpret.

Our recommendation is to review the complete journey in each supported language: entry, account discovery, authentication, permission, refusal, recovery and support. Ask native speakers to test meaning, not just spelling. Small wording choices can change whether “monthly access” sounds like a single event or continuing access.

Three different clocks govern the request

Consent expiry, the historical data period and data life mean different things. Consent validity governs the permission to fetch; data range describes the period requested; data life concerns the period of processing for the consented purpose. ReBIT also recognises retention under applicable law. Revocation should not be described as automatic deletion of every previously received record. ReBIT client standards, consent-field definitions

A useful product explanation would answer three separate questions: “Which months of transactions?”, “How long can new information be requested?” and “What happens to information already received?” Combining those into one reassuring sentence can hide the distinctions a customer needs.

What fintech teams need to do differently

The difficult work sits at the boundary between organisations. The fintech may control the surrounding app, the AA may control authentication and consent, and a TSP may supply an SDK or other integration components.

Sahamati’s May reporting circular recognises that dependency. FIUs report the items applicable to them; AAs report their own items. Where the AA’s submission depends on FIU implementation, it may seek confirmation from the FIU. The circular also explains how to mark non-applicable items in the progress report. Sahamati’s FIU reporting clarification

For a team approaching release, we recommend an evidence table with five columns: requirement, implementation owner, affected journey, test evidence and unresolved dependency. This makes statements such as “the SDK handles it” testable. Which SDK version? In which app build? Does it also cover the custom interface?

A practical release review

The following is our suggested working checklist, not a substitute for the complete standard:

1. Map every live journey. Include returning users, additional accounts and each AA connection. Record which paths use native screens, a web flow or an SDK.
2. Test the decision itself. Ask someone unfamiliar with the product to explain the request before proceeding. Observe where they hesitate or misinterpret a label.
3. Test refusal as carefully as approval. Check that rejecting a request produces an accurate result and a sensible next step. Avoid success messages for actions that did not complete.
4. Exercise recovery paths. Simulate timeouts, missing accounts and interrupted authentication. Record what happens when the customer retries.
5. Check translations on small screens. Review long labels, line breaks, help content and error messages on actual devices.
6. Agree responsibilities in writing. Give each dependency a named owner and an acceptance criterion. Resolve disagreement before the production release.
7. Connect the report to the build. Keep the tested version, screenshots, outstanding issues and reviewer decisions together. A design file and a production build are different forms of evidence.

Security review also extends beyond the visible screens. ReBIT’s confirmation checklist covers SDK due diligence, integration security, testing and assessment obligations, with applicability to be evaluated for the participant and implementation. A visual review alone cannot establish compliance with those controls. ReBIT confirmation checklist

Reporting is part of completion

ReBIT’s instructions specify monthly progress reports on the 25th through October 2026, using the prescribed form, validation and an authorised official’s e-signature. Sahamati’s FAQ says to submit before the 25th, so planning ahead of that date avoids relying on the last day. A separate confirmation report applies once adoption is complete. ReBIT reporting instructions, Sahamati FAQ, confirmation form.

For SEBI-regulated FIUs, sharing reports with Sahamati does not replace submission to ReBIT. Teams should check their own reporting history and designated contact instructions, especially because the October 5 date has already passed. Sahamati FAQ

The next change: making fair use easier to validate

Sahamati’s September circular introduces Fair Use Implementation Guidelines v2.0. It adds a machine-readable registry and explicit template identification through the consent purpose’s refUri. It says the existing templates remain unchanged and sets 30 November 2026 for AAs and FIUs to implement the update. Fair-use v2.0 circular

For users, the underlying question is proportionality: does this service need this much information, this often? For product teams, our recommendation is to maintain an inventory connecting each customer use case to its consent configuration and review evidence. That gives engineering and compliance a shared starting point when a product changes.

ReBIT’s interoperability initiative addresses a different problem: connectivity across participants. Its October announcement describes reducing the need for separate integrations with every AA. That is a separate engineering programme with the revised December 1 deadline. ReBIT announcements

What this means for Finanjo and personal finance products

For a personal finance product such as Finanjo, the useful ambition is straightforward: help people make sense of their money while keeping them able to understand and control the permissions involved.

The same principle should shape how we build Jo. If someone asks about spending, the explanation of data access should make sense in that context. If the task later changes, the product should explain the new request. A conversational interface should make the reasoning easier to follow.

These are product principles, not a statement that every feature is already implemented or that Finanjo has completed a compliance review. We will judge the work by the actual customer journey and its verified behaviour.

The October deadline gives the industry a concrete delivery date. The longer-term test comes after release: can a person understand the request, make an informed decision, and return later to manage it without needing an expert beside them?

Before your next account connection, pause long enough to identify the recipient, purpose and duration. If any of those are unclear, ask the provider to explain. That question is a useful test of the product itself.

This article explains published standards and practical product implications as of 19 October 2026. Applicability depends on the entity’s role and integration model; it is not a compliance certification or legal opinion.