1. Introduction
The Reserve Bank of India (RBI) Account Aggregator (AA) framework is a consent-driven, interoperable financial data-sharing ecosystem that lets individuals and businesses securely share their financial information across regulated institutions. Introduced through the RBI Master Direction - Non-Banking Financial Company - Account Aggregator (Reserve Bank) Directions, 2016 (as amended from time to time), the framework created a new class of Non-Banking Financial Company (NBFC-AA) that acts purely as a consent manager and data conduit. Crucially, an AA neither stores customer financial data nor uses it for any purpose other than transmitting it, on the basis of explicit, revocable, granular customer consent, from a Financial Information Provider (FIP) to a Financial Information User (FIU).
This deep-dive is written for compliance leaders, information security officers, data-protection officers, product teams and internal auditors at entities operating in, or seeking to enter, the AA ecosystem - whether as an NBFC-AA licensee, an FIP (bank, NBFC, insurer, depository, mutual fund, pension fund, GST network) or an FIU (lender, wealth manager, personal finance manager, insurer). It provides an auditor-grade, control-by-control assessment methodology that fuses the RBI Master Direction, the ReBIT technical specifications, the DigiSahamati Foundation (Sahamati) Self-Regulatory Organisation (SRO) baselines, and the overlapping obligations under the Digital Personal Data Protection Act, 2023 (DPDP Act) and RBI/CERT-In cyber-security directions.
Copyright and source note
The RBI Master Direction on NBFC-Account Aggregators, the ReBIT AA technical specifications and Sahamati participation baselines are the intellectual property of the Reserve Bank of India, ReBIT and the DigiSahamati Foundation respectively. This guide is an original interpretation authored by CyberSigma for assessment purposes. It paraphrases requirements and does not reproduce any copyrighted text. Always validate against the current, official versions of the Master Direction (DNBR.PD.009/03.10.119/2016-17 and subsequent amendments), the latest ReBIT specification and Sahamati technical standards, as these are periodically revised.
2. What is the Account Aggregator framework
The Account Aggregator framework is an RBI-regulated data-sharing architecture built on the principle of user consent and data minimisation. It operationalises the concept of a 'consent manager' - an entity that empowers a person to control how their financial data flows between institutions, without the aggregator ever seeing the data in plaintext or retaining it. AA is a foundational pillar of India's Digital Public Infrastructure alongside Aadhaar, UPI and the DigiLocker/OCEN stack, and is designed to reduce friction, fraud and cost in credit underwriting, wealth management, insurance and personal financial management.
The ecosystem has four core actors. The Account Aggregator (NBFC-AA) is a licensed intermediary that provides the consent and data-sharing infrastructure. The Financial Information Provider (FIP) holds the customer's financial data (for example, a bank holding deposit and loan data). The Financial Information User (FIU) is the regulated entity that consumes the data to provide a service (for example, a lender underwriting a loan). The Customer (also called the individual or account holder) is the data principal who grants, monitors and revokes consent. Central to the design are two RBI-approved artefacts: the electronic Consent Artefact, a machine-readable, digitally signed record defining exactly what data may flow, to whom, for what purpose, over what period; and the Financial Information (FI) data, transmitted end-to-end encrypted so that only the intended FIU can decrypt it.
Data types exchanged include deposit accounts, recurring and term deposits, loan and credit facilities, credit card statements, mutual fund and equity holdings, insurance policies, National Pension System balances, and GST returns for MSME lending. The framework enforces 'data blind' operation: the AA cannot read, analyse or resell the data it moves.
| Concept | Description |
|---|---|
| NBFC-AA | RBI-licensed Non-Banking Financial Company acting as a consent manager and data conduit; earns fee for consent/data services, never stores or reads FI data. |
| FIP | Financial Information Provider - regulated entity holding customer financial data (bank, NBFC, AMC/RTA, depository, insurer, pension fund, GSTN). |
| FIU | Financial Information User - regulated entity consuming FI data to deliver a service (lending, wealth, insurance, PFM). |
| Consent Artefact | Digitally signed, machine-readable record specifying data type, purpose, consumer, fetch type, frequency and validity. |
| FI Data flow | End-to-end encrypted financial information passing FIP to FIU via the AA, which cannot decrypt it. |
| Sahamati | Industry alliance / collective for the AA ecosystem, publishing technical standards, the Central Registry and SRO-style baselines. |
3. Who must comply
Compliance obligations differ by role, but every participant in the AA ecosystem inherits a defined slice of regulatory, technical and security responsibilities. RBI licenses the NBFC-AA; FIPs and FIUs are regulated by their respective sectoral regulators (RBI, SEBI, IRDAI, PFRDA) but must adhere to AA ecosystem technical and security standards to participate.
| Entity type | Applicability and core obligation |
|---|---|
| NBFC-Account Aggregator | Must hold a Certificate of Registration from RBI (minimum net owned funds of Rs 2 crore, or as revised); operates the consent architecture; subject to the full Master Direction, fit-and-proper, IT governance and audit obligations. |
| Financial Information Provider (FIP) | Banks, NBFCs, AMCs/RTAs, depositories, insurers, pension funds and GSTN that hold customer data; must expose ReBIT-compliant APIs, honour consent artefacts and share data securely. |
| Financial Information User (FIU) | Regulated lenders, wealth managers, insurers and PFM providers that consume data; must obtain valid consent, use data only for the stated purpose, and meet data-protection obligations. |
| Regulated entities acting in dual role | Many banks/NBFCs are both FIP and FIU; must maintain segregation and separate control sets for each role. |
| Technology Service Providers (TSPs) | Vendors providing AA/FIP/FIU technical modules; contractually bound to ecosystem security and ReBIT specifications; subject to outsourcing controls. |
| Data principals (customers) | Not regulated, but are the source of consent; their rights (grant, view, pause, revoke) must be operationally supported. |
4. Structure of the Account Aggregator framework
The AA framework is not a single monolithic control catalogue; it is layered across a regulatory tier (RBI Master Direction), a technical tier (ReBIT specification and Sahamati standards), and a data-protection tier (DPDP Act and RBI/CERT-In cyber directions). For assessment purposes CyberSigma organises the obligations into control domains that map cleanly onto an auditable structure. Each domain aggregates several families of specific controls.
| Domain | Focus area | Illustrative control families |
|---|---|---|
| D1 - Licensing and Governance | RBI registration, ownership, board oversight | CoR maintenance, fit-and-proper, net owned funds, board-approved policies |
| D2 - Consent Architecture | Consent artefact lifecycle | Consent capture, granularity, validity, revocation, logging, notification |
| D3 - Data Flow and Encryption | Secure movement of FI data | End-to-end encryption, key management, no-storage, data-blind operation |
| D4 - Technical Interoperability | ReBIT/Sahamati API conformance | API schemas, digital signatures, mutual TLS, certificate management |
| D5 - Information Security | Cyber-security controls | IS policy, access control, VAPT, SOC, patching, secure SDLC |
| D6 - Privacy and Data Protection | DPDP Act alignment | Purpose limitation, data minimisation, principal rights, grievance |
| D7 - Operational Resilience | Availability and continuity | BCP/DR, uptime SLAs, incident response, capacity |
| D8 - Customer Protection and Grievance | Fair treatment and redress | Grievance officer, TAT, ombudsman, disclosure, transparency |
| D9 - Audit, Reporting and Oversight | Assurance and regulatory reporting | System audit, statutory returns, SRO reporting, third-party oversight |
| D10 - Outsourcing and Third-Party Risk | Vendor and TSP governance | Due diligence, contracts, monitoring, exit, sub-outsourcing |
5. Master assessment checklist
This is the core of the guide. Each control domain below is expanded into an auditable checklist stating what an assessor must verify and the typical evidence that demonstrates conformance. Assessors should test design and operating effectiveness for each item, sampling transactions and artefacts over the audit period. No domain should be skipped; where an entity operates in only one role (FIP or FIU), mark role-specific controls as not applicable with justification rather than omitting them.
D1 - Licensing and Governance
| What to verify | Typical evidence |
|---|---|
| Valid RBI Certificate of Registration as NBFC-AA is held and current | CoR copy, RBI correspondence, licence conditions register |
| Net Owned Funds meet the RBI minimum threshold on an ongoing basis | Audited financials, NOF computation, statutory auditor certificate |
| Directors and promoters meet fit-and-proper criteria | Fit-and-proper declarations, board minutes, deed of covenant |
| Board-approved policies exist for consent, IS, outsourcing, grievance and privacy | Signed policy documents with board approval dates and review cycle |
| Board / IT Strategy Committee provides documented oversight of AA operations | Committee charters, meeting minutes, MIS packs |
| The entity does not undertake activities beyond those permitted for an AA | Business activity register, product catalogue, RBI scope confirmation |
| Changes in control/ownership are reported to RBI as required | Prior-approval records, shareholding pattern, RBI approvals |
D2 - Consent Architecture
| What to verify | Typical evidence |
|---|---|
| Consent artefact captures all mandated attributes (data type, purpose, consumer, fetch type, frequency, validity, data-life) | Sample consent artefacts, JSON schema, ReBIT mapping |
| Consent is granular - customer can select specific accounts/data types | UI walkthrough, screen recordings, consent options config |
| Consent is digitally signed and tamper-evident | Signature verification logs, certificate chain, hashing evidence |
| Customers can view, pause and revoke consent at any time | Consent dashboard, revocation logs, audit trail of state changes |
| Purpose codes conform to the approved ecosystem purpose taxonomy | Purpose code mapping, Sahamati purpose list reference |
| Consent validity and data-fetch frequency are enforced technically | Policy engine config, blocked-request logs on expiry |
| Every consent grant, use and revocation is logged immutably | Immutable log store, WORM/append-only evidence, retention policy |
| Customers are notified of consent events (grant, data pull, expiry) | Notification templates, delivery logs, SMS/email/app records |
D3 - Data Flow and Encryption
| What to verify | Typical evidence |
|---|---|
| FI data is end-to-end encrypted so the AA cannot decrypt it | Encryption architecture diagram, key-ownership matrix, code review |
| The AA does not store, cache or log FI data in plaintext | Data-flow audit, storage inspection, log-redaction proof, DLP scan |
| Public/private key exchange between FIU and FIP is secure and rotated | Key management policy, HSM/KMS logs, rotation schedule |
| Encryption algorithms and key lengths meet current cryptographic standards | Crypto standard doc, cipher configuration, TLS scan report |
| Data is transmitted only to the FIU named in the consent artefact | Routing logs, consent-to-recipient reconciliation |
| Data-blind principle is enforced - no analytics/monetisation of FI data | Product terms, code audit, contractual attestations |
| FI data is purged after delivery in line with data-life parameters | Purge job logs, retention config, deletion certificates |
D4 - Technical Interoperability (ReBIT / Sahamati)
| What to verify | Typical evidence |
|---|---|
| APIs conform to the current ReBIT AA technical specification version | API conformance test results, version register, Sahamati certification |
| All inter-party API calls use mutual TLS and message-level signatures | mTLS config, certificate inventory, signed payload samples |
| Entity is registered on the Sahamati Central Registry and discoverable | Central Registry entry, registration confirmation |
| Digital certificates are valid, from approved CAs, and monitored for expiry | Certificate inventory, expiry alerts, CA trust list |
| Error handling and retry semantics follow the specification | API error logs, retry config, specification mapping |
| Interoperability tested against multiple ecosystem participants | UAT/integration test evidence, partner sign-off |
| Schema validation rejects malformed or non-conformant requests | Validation logs, rejected-request samples, schema files |
D5 - Information Security
| What to verify | Typical evidence |
|---|---|
| A board-approved Information Security policy aligned to RBI IT directions exists | IS policy, approval record, RBI IT framework mapping |
| Role-based access control and least privilege are enforced | IAM config, access review reports, privileged-access logs |
| Multi-factor authentication protects administrative and privileged access | MFA configuration, authentication logs, exception register |
| Vulnerability assessment and penetration testing are conducted periodically | VAPT reports, remediation tracker, re-test evidence |
| A Security Operations Centre / SIEM monitors for threats 24x7 | SOC runbooks, SIEM dashboards, alert-to-incident records |
| Patch and vulnerability management processes are documented and timely | Patch SLA, patch logs, vulnerability aging report |
| Secure SDLC with code review and application security testing is applied | SDLC policy, SAST/DAST reports, change tickets |
| Network segmentation and firewall rules protect the data path | Network diagram, firewall ruleset, review evidence |
| Cyber incidents are reported to CERT-In within mandated timelines | Incident register, CERT-In reporting proof, six-hour SLA evidence |
D6 - Privacy and Data Protection (DPDP alignment)
| What to verify | Typical evidence |
|---|---|
| Processing is limited strictly to the consented purpose | Purpose-limitation controls, use-case mapping, code audit |
| Data minimisation - only necessary data types/accounts are requested | Consent scoping rules, minimisation review, data-need justification |
| Data principal rights (access, correction, erasure, grievance) are operational | Rights-request workflow, SLA logs, fulfilment records |
| Consent notices are clear, plain-language and available in required languages | Notice templates, language versions, readability review |
| A Data Protection Officer / grievance officer is designated and published | Appointment letter, website disclosure, contact channel |
| Cross-border and third-party sharing constraints are respected | Data-residency config, transfer register, contractual clauses |
| Personal data breach notification procedures meet DPDP requirements | Breach response plan, notification templates, Board reporting |
D7 - Operational Resilience
| What to verify | Typical evidence |
|---|---|
| Business continuity and disaster recovery plans exist and are tested | BCP/DR plan, DR drill reports, RTO/RPO evidence |
| Uptime and API availability meet ecosystem SLAs | Availability dashboards, SLA reports, downtime register |
| Capacity and performance are monitored to handle peak consent/data volumes | Capacity plan, load-test results, monitoring alerts |
| Backups are taken, encrypted and restoration-tested (excluding prohibited FI data) | Backup logs, restore-test evidence, encryption proof |
| Redundancy and failover exist for critical components | Architecture HA design, failover test records |
| Incident and problem management processes are documented and followed | ITSM tickets, RCA documents, MTTR reports |
D8 - Customer Protection and Grievance
| What to verify | Typical evidence |
|---|---|
| A grievance redressal mechanism with defined TAT is published | Grievance policy, TAT matrix, website disclosure |
| A nodal/grievance officer is appointed and reachable | Appointment record, contact details, escalation matrix |
| Complaints are logged, tracked and resolved within SLA | Complaint register, ageing report, resolution evidence |
| Escalation to the RBI Ombudsman / Integrated Ombudsman Scheme is disclosed | Customer disclosures, escalation instructions |
| Fees and terms of service are transparently disclosed to customers | Fee schedule, terms of use, consent-screen disclosures |
| Customers can access a complete history of their consents | Consent history dashboard, export function evidence |
D9 - Audit, Reporting and Oversight
| What to verify | Typical evidence |
|---|---|
| Independent system/IS audit is conducted at mandated frequency | System audit report, auditor engagement letter, findings closure |
| Statutory returns and disclosures are filed with RBI on time | Return submission acknowledgements, filing calendar |
| Internal audit covers AA-specific risks and controls | Internal audit plan, workpapers, audit committee minutes |
| SRO / Sahamati reporting obligations are met | Reporting records, Central Registry updates |
| Audit findings are tracked to closure with accountable owners | Remediation tracker, management responses, closure evidence |
| Concurrent/technology audit of consent and data-flow integrity is performed | Concurrent audit reports, sampling methodology |
D10 - Outsourcing and Third-Party Risk
| What to verify | Typical evidence |
|---|---|
| Due diligence is performed before onboarding TSPs and material vendors | Due-diligence reports, risk ratings, approval records |
| Outsourcing contracts include RBI-mandated clauses (audit, access, confidentiality) | Executed contracts, clause checklist, RBI outsourcing mapping |
| Vendor performance and security posture are monitored continuously | Vendor scorecards, SLA reports, security attestations |
| Sub-outsourcing is controlled and disclosed | Sub-contractor register, prior-consent records |
| Exit and data-return/destruction plans exist for each critical vendor | Exit plans, data-destruction certificates |
| RBI retains right to audit outsourced arrangements | Contract clause evidence, regulator access provisions |
6. Scoping
Accurate scoping determines the boundary of the assessment and prevents both under- and over-auditing. For an AA engagement, scope is defined by role, by the technical estate carrying consent and data flows, and by the supporting organisational functions.
- Role determination: confirm whether the entity is an NBFC-AA, an FIP, an FIU, or a dual-role participant, as this dictates the applicable control subset.
- In-scope systems: the consent management platform, API gateways, ReBIT/Sahamati integration modules, encryption/key-management systems, logging and notification services.
- In-scope data flows: consent artefact lifecycle, FI data transit path (FIP to AA to FIU), and all logging/audit trails - noting that the AA must not persist FI data.
- In-scope processes: onboarding, consent capture and revocation, grievance handling, incident response, outsourcing governance and regulatory reporting.
- Supporting functions: information security, DPO/privacy, internal audit, compliance and vendor management.
- Out-of-scope (with justification): unrelated business lines, systems that never touch consent or FI data, and role-specific controls not applicable to the entity's role.
- Boundary interfaces: FIP/FIU counterparties, TSPs, cloud providers and the Sahamati Central Registry are assessed at the interface/contract level.
7. Implementation approach
A pragmatic, phased implementation reduces risk and creates auditable milestones. CyberSigma recommends five phases from discovery to sustained operation.
Phase 1 - Discovery and gap assessment
- Activities: confirm role, map current architecture, benchmark against Master Direction / ReBIT / DPDP, run a control gap analysis.
- Deliverables: current-state assessment report, applicability matrix, prioritised gap register, high-level roadmap.
Phase 2 - Governance and policy design
- Activities: draft/refresh consent, IS, privacy, outsourcing and grievance policies; establish board/committee oversight; define roles.
- Deliverables: board-approved policy suite, RACI matrix, governance charter, risk-and-control matrix.
Phase 3 - Technical build and integration
- Activities: implement consent engine, ReBIT-conformant APIs, end-to-end encryption, key management, logging and notifications; integrate with the Central Registry.
- Deliverables: conformance-tested APIs, encryption design, key-management SOPs, integration test evidence, Central Registry registration.
Phase 4 - Security hardening and assurance
- Activities: run VAPT, secure SDLC review, SOC/SIEM onboarding, DR testing, system audit and pre-go-live independent review.
- Deliverables: VAPT and remediation reports, system audit report, DR drill results, go-live readiness sign-off.
Phase 5 - Go-live and continuous operation
- Activities: production launch, ongoing monitoring, periodic audits, regulatory reporting, continuous improvement of controls.
- Deliverables: operational runbooks, monitoring dashboards, regulatory filing calendar, continuous-improvement backlog.
8. Maturity and capability model
CyberSigma applies a five-level capability model to benchmark an entity's AA control maturity, enabling year-on-year tracking and board reporting. Levels progress from ad hoc to optimised.
| Level | Maturity stage | Characteristics |
|---|---|---|
| Level 1 | Initial / Ad hoc | Controls undocumented; consent and security handled reactively; high regulatory exposure. |
| Level 2 | Developing | Basic policies exist; some ReBIT conformance; inconsistent logging and monitoring. |
| Level 3 | Defined | Documented, board-approved controls across all domains; consent lifecycle fully implemented; periodic audits. |
| Level 4 | Managed | Metrics-driven controls; automated monitoring, SIEM alerting and SLA tracking; proactive risk management. |
| Level 5 | Optimised | Continuous improvement; threat-led testing; full automation of consent, encryption and reporting; ecosystem-leading resilience. |
9. Assessment and audit approach
A structured audit lifecycle ensures repeatable, defensible conclusions.
- Planning and scoping: confirm role, systems and period; agree objectives, criteria and sampling with stakeholders.
- Documentation review: examine policies, procedures, architecture, consent schemas and prior audit/VAPT reports.
- Control walkthroughs: trace the consent and data-flow lifecycle end to end with process owners.
- Design effectiveness testing: assess whether each control is designed to meet the applicable requirement.
- Operating effectiveness testing: sample consent artefacts, data transactions, logs, revocations and incidents across the period.
- Technical testing: validate encryption, key management, mTLS, API conformance and no-storage of FI data.
- Gap analysis and risk rating: document deficiencies with severity, root cause and regulatory reference.
- Reporting: issue findings, management responses and a prioritised remediation plan.
- Remediation and re-test: verify closure of high-risk findings and update the control status.
- Continuous assurance: define ongoing monitoring, metrics and the next audit cycle.
10. Evidence request list
Assessors should request the following, organised by category, ahead of fieldwork.
- Governance: RBI CoR, NOF computation, board minutes, committee charters, fit-and-proper records, board-approved policies.
- Consent: consent artefact schemas and samples, purpose-code mapping, revocation and notification logs, consent dashboard walkthrough.
- Data flow and encryption: architecture diagrams, encryption/key-management policy, HSM/KMS logs, data-flow and no-storage evidence.
- Technical: ReBIT conformance results, mTLS/certificate inventory, Central Registry registration, API error/validation logs.
- Information security: IS policy, IAM and access-review reports, VAPT reports, SOC/SIEM evidence, patch logs, CERT-In reporting proof.
- Privacy: consent notices, DPO appointment, data-principal rights workflow and fulfilment records, breach response plan.
- Resilience: BCP/DR plans, DR drill reports, availability dashboards, backup/restore evidence.
- Grievance: grievance policy, complaint register, TAT/ageing reports, ombudsman disclosures.
- Audit and reporting: system audit report, internal audit workpapers, statutory return acknowledgements, remediation trackers.
- Outsourcing: vendor due-diligence, executed contracts, vendor scorecards, exit and data-destruction plans.
11. Roles and responsibilities
| Role | Key responsibilities |
|---|---|
| Board of Directors | Approve policies, oversee AA operations and risk appetite, ensure regulatory compliance. |
| IT Strategy / Risk Committee | Oversee IT governance, security posture, audit findings and technology risk. |
| Chief Compliance Officer | Ensure adherence to Master Direction, manage regulatory filings and liaison with RBI. |
| Chief Information Security Officer | Own IS policy, VAPT, SOC/SIEM, incident response and CERT-In reporting. |
| Data Protection / Grievance Officer | Uphold DPDP obligations, handle data-principal rights and grievance redressal. |
| Consent / Product Owner | Own consent artefact design, granularity, notifications and lifecycle. |
| Head of Technology / Integration | Deliver ReBIT-conformant APIs, encryption, key management and Central Registry integration. |
| Internal Audit | Provide independent assurance over AA-specific controls and track remediation. |
| Vendor / Outsourcing Manager | Govern TSP due diligence, contracts, monitoring and exit. |
12. KPIs to track
- Percentage of consent artefacts fully conformant to the ReBIT schema.
- Consent revocation processing time (mean and 95th percentile).
- API availability and success rate against ecosystem SLAs.
- Number and severity of open VAPT findings and mean time to remediate.
- Cyber incidents detected and time to CERT-In notification (six-hour SLA adherence).
- Grievance resolution TAT and percentage resolved within SLA.
- Percentage of FI data flows confirmed end-to-end encrypted with zero AA-side storage.
- Certificate expiry incidents and key-rotation adherence.
- Data-principal rights requests fulfilled within statutory timelines.
- System audit and internal audit findings closed on schedule.
13. Readiness checklist
- Valid RBI Certificate of Registration held and NOF maintained.
- Board-approved consent, IS, privacy, outsourcing and grievance policies in place.
- Consent artefacts implemented with full granularity, validity enforcement and revocation.
- End-to-end encryption implemented; AA stores/reads no FI data.
- ReBIT-conformant APIs certified and registered on the Sahamati Central Registry.
- mTLS and message signing enforced with a monitored certificate inventory.
- VAPT completed with high-risk findings remediated.
- SOC/SIEM monitoring and CERT-In reporting process operational.
- DPO/grievance officer appointed and data-principal rights workflow live.
- BCP/DR tested with documented RTO/RPO.
- Independent system audit completed and findings closed.
- Outsourcing contracts include RBI-mandated clauses with exit plans.
14. Common gaps
- Consent artefacts lacking full granularity or missing mandated attributes (purpose, data-life, frequency).
- Weak or unenforced consent expiry and revocation, allowing data pulls beyond validity.
- Inadequate proof that the AA truly stores no FI data - plaintext appearing in logs or caches.
- Certificate and key-rotation lapses causing integration failures or weakened cryptography.
- Delayed or missing CERT-In incident reporting within the six-hour window.
- Grievance TAT breaches and undisclosed ombudsman escalation paths.
- Outsourcing contracts missing RBI audit-access and data-destruction clauses.
- Insufficient DPDP alignment - unclear notices, unmet data-principal rights, no breach playbook.
- Purpose codes not mapped to the approved ecosystem taxonomy.
- System/VAPT audits performed but findings left unremediated past due dates.
15. Account Aggregator mapped to other frameworks
| AA control area | Related framework / requirement |
|---|---|
| Consent and purpose limitation | DPDP Act 2023 - consent, notice, purpose limitation and data-principal rights |
| Information security controls | RBI Master Direction on IT Governance / ISO 27001 Annex A / NIST CSF |
| Encryption and key management | ISO 27001 A.8 cryptography / PCI DSS Requirement 3 and 4 (analogous) |
| Incident reporting | CERT-In Directions (six-hour reporting) / ISO 27035 |
| Access control and MFA | ISO 27001 A.5-A.8 / RBI cyber-security framework / NIST 800-53 AC family |
| Outsourcing and third-party risk | RBI Outsourcing Directions / ISO 27036 / SOC 2 vendor management |
| Business continuity | ISO 22301 / RBI BCP guidelines / NIST CP family |
| Audit and assurance | ISAE 3402 / SOC 2 / RBI system audit requirements |
16. How CyberSigma helps
Partner with CyberSigma for Account Aggregator assurance
CyberSigma's CERT-In empanelled auditors and QSAs deliver end-to-end Account Aggregator readiness and assurance - from role determination, gap assessment and policy design, through ReBIT/Sahamati conformance validation, VAPT, encryption and key-management review, DPDP alignment and independent system audit. We help NBFC-AAs, FIPs and FIUs achieve and sustain RBI compliance with defensible, auditor-grade evidence, remediation support and continuous monitoring. Talk to CyberSigma to build a resilient, consent-first data-sharing ecosystem that regulators, partners and customers can trust.
Frequently asked questions
Can an Account Aggregator see my data?
No — AAs are "data-blind" by design: they move encrypted financial information based on your consent but cannot read or store it in readable form.
Official documents
CyberSigma resources
Need help with Account Aggregator?
CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.