Your Account Aggregator License Meets DPDP for Financial Data Consent. It Was Never Built for KYC Consent.

An NBFC that already holds an Account Aggregator license, or routes borrower bank-statement, GST, and mutual-fund data through one of the RBI-licensed NBFC-AAs live today (Sahamati, the industry alliance that runs the ecosystem's central registry, counts well over a dozen operating under a full RBI license), has already cleared a harder compliance bar than most fintechs ever attempt: a minimum Net Owned Funds threshold, an IT-systems audit, and the Reserve Bank of India (Non-Banking Financial Company – Account Aggregator) Directions on exactly how consent-based data sharing has to work end to end. That's real, hard-won infrastructure. It's also, specifically, financial-data infrastructure, and RBI built it that way on purpose.

Which is why a founder can look at a consent-and-privacy pitch and say something reasonable-sounding: "the government already owns this, why would we pay a vendor for it." He's not wrong that a regulator-run consent framework exists. He's collapsing two frameworks that don't overlap: the RBI-regulated flow that moves a borrower's bank and tax data, and the separate, still mostly unaddressed problem of getting purpose-based, DPDP-compliant consent for the PAN, Aadhaar, and biometric data an NBFC collects at the exact same onboarding step.

What an Account Aggregator License Actually Covers

The RBI (Non-Banking Financial Company – Account Aggregator) Directions are specific about scope. Paragraph 6 restricts a registered NBFC-AA from undertaking "any business other than the business of account aggregator," and the Directions separately set a minimum Net Owned Funds threshold of ₹2 crore as a condition of registration. The "financial information" an AA is licensed to move is a defined list, bank deposits, mutual fund and pension holdings, insurance policies, GST and tax data via the account aggregator ecosystem's registered FIPs. An AA is deliberately built "data-blind": it holds a consent artifact, moves encrypted financial information from a Financial Information Provider to a Financial Information User, and is architecturally unable to read the content passing through it. That's a genuinely strong design, and it's the reason an AA integration satisfies a real slice of DPDP's consent requirements for the data it touches.

It's also a narrow slice. Nothing in that scope covers identity documents.

That paragraph 6 restriction is exactly what keeps the AA framework clean, and it's exactly why it was never going to absorb identity verification consent. That gap doesn't close on its own, and no announced extension of Aadhaar's own APIs closes it either, because UIDAI's mandate, set out in the Aadhaar (Authentication and Offline Verification) Regulations, 2021, is authenticating one document, not orchestrating consent across PAN, biometrics, and video KYC as one flow.

The Part of Onboarding an AA License Was Never Meant to Cover

Walk through what actually happens when an NBFC underwrites a loan today. The Account Aggregator flow, if it's wired in, handles bank statement and GST pulls with clean, revocable, RBI-grade consent. Then, in the same onboarding session, the applicant hands over a PAN, completes Aadhaar-based eKYC, sits through a liveness check, and possibly a video KYC call, all routed through whichever KYC vendor the NBFC plugged in years ago, most of them built to verify a document and store it, not to carry a granular, purpose-based consent record for what happens to that document afterward. Two onboarding steps, one governed by one of India's most mature consent frameworks, the other governed by whatever the KYC vendor's own privacy policy happens to say.

That's the actual gap, and it's a structural one, not a feature gap a vendor patches next quarter. A KYC platform built around ingesting and storing raw documents has to change what it stores and how it moves data to close it, not just add a consent-notice modal on top of the same document database.

Mapping the Gap to What DPDP Actually Requires

DPDP doesn't care that the AA framework already solved consent for the financial-data half of onboarding. It applies to the identity-data half just as fully, and it names obligations that fall partly on the NBFC as Data Fiduciary and partly on whichever processor is handling the PAN, Aadhaar, and biometric checks on the NBFC's behalf. Here's that mapped point-to-point, not against a general fintech checklist, but against the specific step an Account Aggregator license doesn't reach.

What This Looks Like as a Check, Not a Document Upload

The mechanism behind that data-minimization row is worth showing, not just naming. Selective disclosure means the specific claim a lending decision needs, not the document it was derived from, is what actually reaches your systems:

The same 1:1 biometric match used at the gate for an event or a marketplace onboarding applies here: a live selfie checked against the document photo at the moment of the check, not stored into a growing population database the NBFC would otherwise have to secure and justify retaining.

Where This Doesn't Try to Be Your Account Aggregator, or a Consent Manager

Worth being precise about what this is not. Hypersign isn't applying to be a Financial Information User integration point, doesn't touch bank or GST data, and isn't positioned as a DPDP-registered Consent Manager, the role Section 6(7)–(9) of the DPDP Act defines and Rule 4 and the First Schedule of the DPDP Rules, 2025 puts a registration and eligibility bar on, a minimum net worth threshold, incorporation as an Indian company, society, or trust, and Data Protection Board registration. This is identity verification infrastructure: an ID verification API, architected so that the consent, minimization, and retention properties DPDP asks for are structural to how PAN, Aadhaar, and biometric checks run, rather than a policy layer bolted on afterward. Your AA integration keeps doing exactly what it does today. This closes the adjacent gap it was never scoped to touch.

What Most KYC Vendors Store vs. What Hypersign's Architecture Ever Receives

This is the part a vertically-integrated KYC vendor can't retrofit in a sprint. Storing and later redacting is a different architecture from never receiving the raw document in the first place.

None of this is a claim that Signzy or HyperVerge can't eventually add pieces of this. It's that "eventually add" means restructuring what their platform stores by default, for every existing customer, not shipping a new API field.

Q&A: Is Hypersign the Right Fit for Your NBFC?

We already run bank-statement and GST pulls through an AA partner. Does Hypersign replace that?

No. Keep your AA integration exactly as it is, whether that's Setu, Perfios, Anumati, CAMS Finserv, or another licensed NBFC-AA. Hypersign sits at the separate onboarding step where PAN, Aadhaar, and biometric KYC happen, a step no AA license was ever scoped to cover.

Are you registering as a DPDP Consent Manager?

No. Hypersign is an ID verification API. The consent, minimization, and audit properties described here are built into how that API handles identity data, not a claim to the separately-licensed Consent Manager role DPDP defines.

What kind of NBFC is this actually a good fit for?

Digital-first lenders doing PAN, Aadhaar, and biometric KYC at onboarding today through a document-storing vendor, who want the compliance posture DPDP requires to be architectural rather than a policy document their legal team maintains separately from what engineering actually built.

When is this not the right fit yet?

If your NBFC relies heavily on RBI's regulatory-sandbox video-KYC workflows or deep CKYCR search-and-upload tooling that a decade-old India-specific vendor like Signzy has built out, that specific depth isn't something a newer platform replicates overnight either. The honest answer is to evaluate both on the specific workflow you run most, not on a single feature list.

Do we still need separate AML and sanctions screening?

Yes, PMLA obligations don't move. What changes is that the identity check feeding into that screening arrives as a verified, minimized claim rather than a raw document your AML pipeline then has to store as well.

Can this reduce repeat KYC across our own products or a lending consortium?

Within your own stack, yes, a borrower verified once can present a reusable credential for a second product line instead of re-uploading documents. Across an external consortium, that depends on the other parties accepting the same credential format, Hypersign doesn't claim to be the interoperability layer across every bank and NBFC in India, that's a much larger, separately-regulated proposition.

Does this cover business borrowers, not just individuals?

Yes, for MSME and business-loan onboarding, the same minimization principle applies through business verification (KYB), GSTIN and director-identity checks return verified claims rather than a folder of uploaded incorporation documents.

References

Primary sources for every citation above, for compliance and legal teams who want to verify this directly rather than take a vendor's word for it:

• Digital Personal Data Protection Act, 2023 (full text, Ministry of Electronics and IT)
  Sections 5, 6, 8, 11, 12, and 13 cited above are all within this Act.
• DPDP Act, Section 5 — Notice (India Code)
• DPDP Act, Section 6 — Consent, incl. 6(7)–(9) on Consent Managers (Indian Kanoon)
• DPDP Act, Section 8 — General obligations of Data Fiduciary (India Code)
• DPDP Act, Section 11 — Right to access information (Indian Kanoon)
• DPDP Act, Section 12 — Right to correction and erasure (Indian Kanoon)
• Digital Personal Data Protection Rules, 2025 (Gazette notification, MeitY)
  Rule 4 and the First Schedule govern Consent Manager registration and eligibility.
• RBI (Non-Banking Financial Company – Account Aggregator) Directions (official RBI master direction page)
  Paragraph 6 restricts an NBFC-AA to the business of account aggregation; a separate provision sets the ₹2 crore Net Owned Funds threshold.
• The Aadhaar (Authentication and Offline Verification) Regulations, 2021 (India Code)
• UIDAI — Aadhaar Paperless Offline e-KYC (official UIDAI page)

Regulations change. This mapping reflects the DPDP Act 2023, the DPDP Rules 2025 (notified November 13, 2025, with staggered commencement dates by provision), and the RBI Account Aggregator Directions as of this post's publication date, not legal advice, confirm current text against the primary sources above before relying on it for a compliance filing.

About Hypersign

Hypersign is an identity verification API for PAN, Aadhaar, biometric, and business KYC, built so that purpose-based consent, selective disclosure, and enforced retention are structural properties of the check itself, not a policy layer added after the document is already sitting in a database. It doesn't touch financial-data consent, that's what an Account Aggregator license already does well, it closes the identity-data gap sitting right next to it. See how the DPDP obligations above map against a general fintech KYC stack in DPDP Act Compliance for Fintech KYC, or against India's cKYC re-verification problem in cKYC Doesn't Mean "Verify Once" Anymore.