DigiSahamati Foundation (Sahamati) is a Collective of Account Aggregator ecosystem being set up as a non-Government, private limited company. The RBI approved a new class of NBFCs in 2016 to act as Account Aggregators, whose primary responsibility is to facilitate the transfer of user’s financial data with their explicit consent. This primarily includes transfer, but not storing, of a client’s data.
Account Aggregator (AA) is the construct/framework that addresses the above pain points and provides a digital platform for easy sharing and consumption of data from various entities with user consent. The architecture of AA is based on the Data Empowerment and Protection Architecture (DEPA) framework.
An Account Aggregator (AA) provides data to a Customer or Financial Information User (FIU) from a Financial Information Provider (FIP) based on the user’s explicit Electronic/Digital Consent. No financial information of the user is retrieved, shared or transferred by the Account Aggregator without the explicit consent of the user.
An AA merely acts as a conduit between FIUs and FIPs and does not process the data. An AA is ‘data-blind’ as the data that flows through an AA is encrypted and can be processed only by the FIU for whom the data is intended.
Financial Information Providers (FIP’s) are the institutions which hold user data, for example, user’s Bank, NBFC, Mutual Fund Depository, Insurance Repository, Pension Fund Repository, etc.
Financial Information User (FIU) consumes the data from an FIP to provide various services to the end consumer. For e.g. a lending Bank wants access to the borrower’s data to determine if a borrower qualifies for a loan. The lending Bank is the FIU. Banks play a dual role – both as an FIP and an FIU.
This document defines the certification requirements for each of the AA ecosystem members.
2. Certification Requirement and Scope
To become a part of the Account Aggregator Ecosystem, the entities- FIPs, AAs and FIUs need to adhere to ReBIT guidelines for API & functional flow, and must adopt right policy controls.
Only certified modules of FIP/AA/FIU shall be included in the Central Registry and able to seamlessly connect with a network of AAs. The certification shall help organisation demonstrate that they have fulfilled minimum required AA ecosystem security controls, and under regular effectiveness assessment by Certified Auditors.
Hence to ensure the security of AA environment, Sahamati has empanelled Aujas Network as an authorised body to conduct the mandatory certification audits for all the AA ecosystem partners. Entities are required to get in touch with Aujas for the audit and certification requirements.
This document provides the certification framework for:
- Financial Information Provider (FIP),
- Account Aggregator (AA) and
- Financial Information User (FIU) in India to be part of the AA ecosystem
The scope of assessment and certification is limited to the FIP/AA/FIU Infrastructure/environment only.
|FIP||Financial Information Provider|
|FIU||Financial Information User|
|NBFC||Non-Banking Financial Company|
|DEPA||Data Empowerment and Protection Architecture|
|MeitY||Ministry of Electronics and Information Technology|
|E2E||End to End|
|GST||Good and Service Tax|
|RBI||Reserve Bank of India|
|SEBI||Securities and Exchange Board of India|
|IRDA||Insurance Regulatory and Development Authority|
|PFRDA||Pension Fund Regulatory and Development Authority|
|ISO||International Organization for Standardization|
|NIST CSF||National Institute of Standards and Technology Cyber Security Framework|
|ReBIT||Reserve Bank Information Technology Private Limited|
|API||Application programming interface|
|CIA||Confidentiality, Integrity, Availability|
|HTTP||Hypertext Transfer Protocol|
|PII||Personal Identifiable Information|
|SPI||Sensitive Personal Information|
|AES||Advanced Encryption Standard|
|UAT||User Acceptance Testing|
|USB||Universal Serial Bus|
|NTP||Network Time Protocol|
|IDS||Intrusion detection system|
|IPS||Intrusion prevention system|
|SIEM||Security information and event management|
|BCP||Business Continuity Planning|
|Network Penetration Testing||To identify exploitable vulnerabilities in networks, systems, hosts and network devices (i.e. routers, switches) before hackers are able to discover and exploit them.|
|Secure Configuration Assessment||A detailed review and verification of configuration settings of IT infrastructure components including systems, network devices & applications to measure their security effectiveness|
4. Eligibility Criteria
Currently, only players who are registered or regulated by either of the four regulators – RBI, SEBI, IRDA, PFRDA, are allowed to be FIPs and FIUs.
- No entity other than a company shall undertake the business of an Account Aggregator.
- No company shall commence or carry on the business of an Account Aggregator without obtaining a certificate of registration from the RBI.
Provided that, entities being regulated by other financial sector regulators and aggregating only those accounts relating to the financial information pertaining to customers of that particular sector will be excluded from the above registration requirement.
5. Certification Methodology
The certification framework is based on the industry best practices, as recommended by ISO 27001:2013, NIST Cybersecurity Framework (CSF). However, it does not replace them rather it is bringing a focus on the areas of importance.
The certification framework also recommends that AA ecosystem partners follow a lifecycle model for implementing these focus areas using models like ISO27001’s PDCA and NIST Cybersecurity Framework.
- PLAN: Establish policies and procedures to manage risks and protect data in the scoped environment
- DO: Implement policies, procedures, conduct a risk assessment, identify, and implement security controls for data protection
- CHECK: Conduct audits and assessment (secure code reviews, vulnerability assessment/penetration testing for application and network, security configuration assessment) to identify gaps/vulnerabilities in the implemented security controls
- ACT: Take necessary actions to mitigate gaps/vulnerabilities identified as part of audits and assessment for continual improvement.
The NIST Cybersecurity Framework provides a policy framework for how organizations can assess and improve their ability to prevent, detect, and respond to cyber-attacks. Sahamati categorizes controls based on the five high-level functions:
- Recover of the Core areas of NIST Cybersecurity Framework
These five functions are not only applicable to cybersecurity risk management but also to risk management at large.
6. Certification Path
The following section describes the certification path for AA ecosystem partners.
6.1 Certification Planning & Pre-requisites
Entities interested to be part of the AA ecosystem must:
- Qualify as per the “Eligibility Criteria” section of this document (Section Eligibility Criteria)
- Comply with the latest ReBIT requirements for FIP/AA/FIU
- Comply with the ISO27001 standard controls and the security control as defined under Annexure (Security Controls Checklist) of this document
- Conduct Risk Assessment of in-scope infrastructure
- Conduct Source code review of in-scope modules and applications
- Conduct Vulnerability assessment of in-scope infrastructure
- Conduct Configuration assessment of in-scope infrastructure
Pre-requisites for the Self-assessment kit:
- Windows/Linux VM with a minimum of below configuration and accessible from UAT environment of the test application
- Docker to be pre-installed in the VM
- 4 core CPU
- 8 GB of RAM
- 50 GB HDD
6.2 Risk Assessment
All AA ecosystem partners, existing or new, must conduct a Risk assessment of the in-scope systems, applications, modules, API’s etc. periodically to identify risks that may impact the confidentiality, integrity, availability, security and privacy of the sensitive data being processed.
All the identified risks must have a defined risk owner along with risk mitigation and treatment plan. Controls identified as part of the risk mitigation and treatment must be implemented within the defined timeline.
A risk that cannot be mitigated due to technical limitation must have secondary controls in place along with an exception approved by the management.
6.3 Automated Self-Assessment
The self-assessment is a mandatory and automated assessment performed by the AA ecosystem partners (both existing and new) via a self-assessment kit.
The self-assessment kit comprises of checks for:
- Technical controls: API specification adherence and Function flow specification adherence are tested in line with the controls/specifications as defined by ReBIT for FIP/AA/FIU module, respectively.
The output of the self-assessment check is a PASS/FAIL based on the evaluation of technical controls.
The entity shall not be eligible for the Onsite Audit & Certification unless the result of this self-assessment is a PASS. The technical controls must be evaluated quarterly to ensure compliance with ReBIT specification.
- The self-assessment report must be shared with Sahamati every quarter
- Security Controls: Security controls as defined under Annexure of this document must be implemented before the self-assessment and all relevant evidence need to be uploaded during the self-assessment activity.
The controls shall also be evaluated once at the time of certification and annually thereafter at the time of Surveillance Audit and Re-certification audit.
Any non- compliance identified at this stage need to be mitigated/closed before scheduling the certification audit.
6.4 Onsite Audit & Certification
To review the effectiveness of the processes and controls deployed by the AA ecosystem partners, the external audit agency, empanelled by Sahamati, shall carry out a detailed and formal onsite audit to review compliance to information security policies, regulatory compliances, confirmation to various guidelines issued by the regulator and to test the effectiveness of the information security controls deployed.
The onsite auditors shall seek evidence to confirm and validate the responses submitted during the applicable self-assessment kit. Passing this stage shall result in the entity being certified as FIP/AA/FIU.
- The certification issued at this stage shall be valid for a period of 2 years and have to be renewed.
- An intermittent audit shall be required only when MAJOR regulation or schema changes from ReBIT have a MAJOR impact on scoped ecosystem/infrastructure.
The auditors shall formulate the audit report and document the audit findings and observations along with actionable recommendations so as to ensure data governance, confidentiality, integrity, reliability and availability of information and resources. The report shall also be shared with Sahamati.
The findings and observations from the onsite audit have been broadly categorized and defined in the following table:
|Finding Type||Description||Certification Requirement|
|- Non-compliance has a direct effect on the preservation of confidentiality, integrity and availability (CIA) of the organizational asset (under scope). |
- A Non-compliance occurs when the organization has not addressed all of the requirements of a specific control as specified in the organizational policies, standards and procedures.
- A Non-compliance can also occur if a significant number of “observations” in a given activity or against a given element point to a systemic failure.
0 “Zero” Non-compliance’s
|OBSERVATION||- One or more elements as specified in the organizational policies, standards and procedures is/are only partially complied. |
- An observation has an indirect effect on the CIA of the scoped asset.
|RECOMMENDATION||- These are the validations against the laid down policies, procedures, standards or guidelines. |
- It is also suggested to ensure that a Non-Compliance is not created in the future for any critical activity.
6.5 Surveillance Audits
Certification maintenance requires periodic re-assessment audits to confirm that the AA ecosystem partners continue to operate as specified and intended, thus surveillance audits shall be conducted annually to:
- Ensure the scoped systems/ecosystem maintain the required compliance measures
- Ensure changes implemented in the scoped systems meet the requirement of the standard/ specification and implemented effectively.
- Ensure that the management system continues to be appropriate to the product/ process/ service offered by the entity.
- Ensure and verify actions taken on the findings reported during the previous audit.
7. Audit Type & Frequency
The following table lists the type audits and their frequency throughout the lifecycle of the certification.
|Sl No||Assessment Type||Frequency|
|1||Self-Assessment||- Once at the time of onboarding|
- Quarterly (Technical control assessment only)
- Annually (Security Controls Assessment)
|2||Certification Audit||Once at the time of onboarding|
|3||Surveillance Audit||Annual re-assessment audit|
|4||Re-certification Audit||Once every 2 years|
|5||Intermittent Audit||Done only when MAJOR regulation or schema changes from ReBIT have a MAJOR impact on the scoped ecosystem/infrastructure|
8.1 Security Controls Checklist
|Sr. No.||Domain||Function||Control Description|
|1||Security Policy & Administration|
|1.1||Identify||There must be documented and approved Information Security Policy to cover the AA ecosystem.|
|1.2||Identify||All policies and procedures must be communicated to all relevant stakeholders of AA ecosystem as per responsibilities and requirements.|
|1.3||Identify||Information security roles and responsibilities must be clearly defined for all relevant AA ecosystem stakeholders|
|1.4||Identify||Risk associated with AA Ecosystem must be identified, analysed, and evaluated as per established risk assessment criteria.|
|1.5||Protect||All identified risk of AA Ecosystem must be treated as per Risk treatment plan|
|1.6||Protect||Information security training must be provided annually to all employees/vendors pertaining to the AA ecosystem.|
|1.7||Identify||There must be documented and approved Information Classification, Labelling and Handling Policy.|
|1.8||Identify||There must be documented and approved Acceptable Use Policy.|
|1.9||Identify||All policies and procedures must be reviewed/updated in accordance with organization defined frequency|
|2.1||Identify||There must be documented and approved Cyber Security Policy.|
|2.2||Protect||Cyber Crisis Management Plan must be maintained and communicated to all relevant stakeholders of the AA ecosystem.|
|2.3||Respond||The organization must take necessary measures in addressing various types of cyber-attacks.|
|3.2||Identify||List of scoped personal data types stored/processed must be maintained.|
|3.3||Protect||The organization must have a formal process for reporting and responding to privacy complaints or privacy incidents for scoped data.|
|3.4||Protect||Organization must have capability to restrict the processing/removal of customer data upon consent withdrawal|
|4.1||Protect||Organization must have the ability to logically segment or encrypt customer data such that data may be produced for a single tenant only, without inadvertently accessing another tenant's data?|
|4.2||Protect||Physical location/geography of storage of an AA ecosystem data must be available?|
|4.3||Protect||Organization must ensure that AA ecosystem data does not migrate beyond a defined geographical residency?|
|4.4||Protect||All data in transit must occur over a secure transmission channel such as HTTPS or an equivalent mechanism.|
|5.1||Protect||There must be documented and approved Cryptography Policy to cover the AA ecosystem.|
|5.2||Protect||PII and SPI data on scoped systems must be encrypted with AES 256 Bit encryption, or anonymised, as applicable|
|5.2||Protect||There must be documented and approved policy for governing the whole lifecycle of cryptographic keys? (Key generation, distribution, installation, renewal, rotation, revocation, and expiry are established). The policy must be in line with the procedural guidelines|
|5.4||Protect||User authentication data must always be encrypted at rest.|
|6||Asset Classification and Control|
|6.1||Protect||There must be documented and approved Asset Management Policy to cover the AA ecosystem.|
|6.2||Identify||The organization must have an updated Asset Register for scoped environment along with asset classification and risk owner details.|
|6.3||Protect||There must be documented and approved Information handling and classification policy.|
|6.4||Protect||The organisation must have defined and implemented processes for management of removable media ?|
|6.5||Protect||There must be documented and approved media disposal policy or process.|
|6.6||Protect||If back-up media is stored off site containing scoped system data, then the organisation must have a documented process detailing how physical media should be transported.|
|6.7||Protect||If back-up media is stored off site containing scoped system data, then Media must be protected during the transport against unauthorized access, misuse, or corruption.|
|7||Logical Access Control|
|7.1||Protect||There must be documented and approved User Access Management Policy.|
|7.2||Protect||User access registration and de-registration processes must be defined and implemented for the AA ecosystem.|
|7.3||Protect||The privileged access accounts must be managed and controlled?|
|7.4||Protect||The asset (Application, Servers, DB and Network devices) owners must review access rights of assets on a regular basis relevant to the AA ecosystem.|
|7.5||Protect||User access rights must be removed on termination of employment or contract or adjusted upon change of role.|
|7.6||Identify||There must be documented and approved Password Management Policy.|
|7.7||Protect||Management approved password policy/complexity must be configured in AA ecosystems.|
|7.8||Protect||There must be documented and approved Remote Access Policy to cover the AA ecosystem.|
|7.9||Identify||List of approved staff (supporting scoped system activities) having remote access rights for AA ecosystem must be maintained.|
|8.1||Protect||There must be documented and approved Background Verification policy for new Employees/Vendors.|
|8.2||Protect||Background Verification checks for employees/Vendors must include the following checks (1) Address (2) criminal (3) Education (4) Previous Employment|
|8.3||Protect||The organisation must conduct background verification for staff including contractors/third-party vendors supporting and managing AA ecosystem.|
|8.4||Protect||Signed Non-disclosure agreements must be obtained by organization for all employees including contractors/third-party vendors before granting access to AA ecosystem.|
|8.5||Protect||There must be a documented and approved Disciplinary action process.|
|8.6||Protect||There must be documented and approved employee Exit/Termination/Transfer process for employees/Vendors.|
|9.1||Protect||There must be documented and approved Incident Management Policy to cover the AA ecosystem.|
|9.2||Respond||The organisation must have defined and implemented a documented process for timely reporting of information security events, in line with the requirements as defined in the procedural guidelines, for AA ecosystem.|
|9.3||Respond||There must be a documented process of security event review and response for AA ecosystem.|
|9.4||Respond||Information security events must be properly assessed and classified for the AA ecosystem.|
|9.5||Respond||There must be a documented and approved Incident Response Plan to cover the AA ecosystem.|
|9.6||Respond||There must be documented and approved Incident Escalation Matrix to cover AA ecosystem.|
|10.1||Protect||There must be documented and approved Change Management Policy.|
|10.2||Protect||All changes to the production environment must be approved by personnel delegated with the authority to approve change requests.|
|10.3||Protect||Test result sign-offs must be obtained from the user prior to the AA ecosystem migration.|
|10.4||Protect||To minimise risks associated with changes, all deployments should be accompanied with a rollback plan. Should there be any changes to data / data schema, then appropriate rollback plans shall be defined for those too.|
|10.5||Protect||There must be a documented rollback plan for the AA ecosystem prior to the change.|
|10.6||Identify||Prior to deploying changes to the production environment, a risk and impact analysis of the change must be performed.|
|11||Communications and Operations Management|
|11.1||Protect||Inactivity timeout period/automatic lockout of 3 minutes specified for applications pertaining to AA ecosystem.|
|11.2||Detect||Vulnerability assessment and penetration tests (internal/external) must be performed on all AA ecosystems (Applications, Servers, DB & Network devices) at least annually? As industry best practices for vulnerability management are updated (for example, the OWASP Top 10, SANS CWE Top 25, CERT Secure Coding, etc.), the current best practices must be used for these requirements.|
|11.3||Protect||There must be a documented and approved Capacity Management Policy?|
|11.4||Identify||Organisation must restrict its user’s from installing any unnecessary software onto operational systems.|
|11.5||Protect||There must be documented and approved Patch Management Process relevant to the AA ecosystem.|
|11.6||Protect||Patches must be tested in an UAT instance before deployment on the production server.|
|11.7||Protect||Hardening document/technical specification document must be maintained for all AA ecosystems.|
|11.8||Protect||USB/CD, internet, shared folders, and admin privileges must be restricted in all AA ecosystems.|
|11.9||Protect||Audit logs with security-relevant activities must be stored/maintained for operating systems and applications pertaining to the AA ecosystem.|
|11.1||Protect||Logs must be analysed periodically for all AA ecosystems.|
|11.11||Protect||The organization must continuously monitor and report the compliance of infrastructure against defined information security baselines.|
|12.1||Protect||There must be a documented and approved Network Security Policy?|
|12.2||Protect||Organization must have a comprehensive network architecture diagram for the AA ecosystem?|
|12.3||Protect||Scoped systems must be synced with NTP service?|
|12.4||Detect||Firewall logs review must be performed periodically for AA ecosystem?|
|12.5||Detect||Firewall rule base review must be performed periodically for AA ecosystem?|
|12.6||Detect||Organization must have configured IDS/IPS to detect/prevent network intrusion for the scoped ecosystem ?|
|12.7||Detect||IDS/IPS logs review must be performed periodically for the AA ecosystem?|
|12.8||Detect||NIDS/IPS signature must be updated regularly?|
|12.9||Detect||Organization must have network events monitored for the AA ecosystem?|
|12.1||Detect||There must be centralized log monitoring system e.g. SIEM|
|12.11||Detect||Network penetration tests must be conducted for AA ecosystem service infrastructure (on prem/cloud) at least annually.|
|13||Antivirus & Malware Protection|
|13.1||Detect||Organizations must have Anti-Malware/Anti-Virus Policy?|
|13.2||Detect||Organization must have Antivirus Signature Management System in place for systems related to AA ecosystem|
|-AV signatures must be up to date|
|-Records must same maintained for the same|
|-Specify the frequency defined for signature update.|
|13.3||Detect||There must be an antivirus software deployed, updated and maintained for scoped systems|
|13.4||Protect||There must be controls in place to prevent end users from overriding or disabling the antivirus software|
|14||BCP & IT DR|
|14.1||Protect||Organization must have a Business Continuity Plan for scoped system|
|14.2||Protect||Business Continuity Plan must be tested for AA ecosystem on regular basis|
|14.3||Protect||Organization must have a Disaster Recovery Plan for scoped system|
|14.4||Protect||Disaster Recovery Plan must be tested for AA ecosystem on regular basis|
|15||Data Backup and Restoration|
|15.1||Protect||There must be a documented and approved Backup and restoration policy|
|15.2||Protect||Back-up schedule for AA ecosystem must be documented|
|15.3||Protect||Organization must have Backups for critical data and programs are available in the event of an emergency.|
|15.4||Protect||Backup data must be encrypted|
|15.5||Protect||There must be a defined retention period of backup to ensure backup data is retained for the period necessary to satisfy business, regulatory and legal requirements|
|15.6||Protect||Organization must conduct Backup restoration for scoped systems|
|16||Third Party/Vendor/Partner Management|
|16.1||Identify||Organization must have documented Vendor Management policy|
|16.2||Identify||Organization must have a documented list of third party/vendor/partner involved for the scoped ecosystem along with services provided.|
|16.3||Identify||Organization must have a valid contract and Non-disclosure agreement with third party service provides|
|16.4||Identify||Organization must conduct audit for third party /vendors handling scoped ecosystem data|
|17||Physical & Environmental Security|
|17.1||Protect||Organization sensitive or critical information areas must be segregated and appropriately controlled|
|17.2||Protect||Secure areas must have suitable entry control systems to ensure only authorized personnel have access|
|17.3||Detect||There must be continuous monitoring systems (viz. CCTV’s) installed to monitor critical facilities on a 24 x 7 basis|
|17.4||Protect||Organization must maintain visitor management policy|
|17.5||Protect||Organization must ensure asset movement are controlled and managed|
|17.6||Detect||Visitor entry and exist, must be recorded, and maintained for access to scoped AA ecosystem|
|17.7||Protect||Organization must have appropriate physical protection measures to prevent natural disasters, malicious attacks, or accidents.|
|17.8||Protect||There must be a physical security personnel trained in use of fire extinguishers and basic first aid|
|17.9||Protect||Organization must have conducted the Mock Fire Evacuation Drills/Emergency Evacuation Drills|
|18.1||Identify||Organization must comply with applicable legal and regulatory requirements.|
|18.2||Identify||Organization must maintain and track previous audit findings till closure|
|Sl No||Domain||Function||Control Description|
We welcome technical feedback from developers and security researchers. Please contact us with your feedback.