FinTechConsent Management and Data Protection in the Account Aggregator Ecosystem

INTRODUCTION

Account Aggregators (AAs) is a novel structure of technology infrastructure, which aims to enable ease of access to the financial data of individuals and Business Customers. It enables sensitive financial information from one financial institution, where the individual has an account, with other regulated financial institutions within the AA network.

As discussed in the previous blog on AAs, such platforms are subject to regulation by the Reserve Bank of India (RBI) which issues an NBFC-AA license to the approved AAs.

In this blog, we shall discuss the concept of AAs as Consent Managers and the role of Data Empowerment and Protection Architecture (DEPA), in continuance of the previous blogs on AAs.

AA AS CONSENT MANAGERS

Consent bears an extremely pivotal role in the ecosystem of AAs, as without the explicit consent of the Customer, AAs are prohibited to share, retrieve or transfer financial data of a Customer. Under this ecosystem, Customers who are registered with the AA Platform have the sole authority to grant or refuse consent for sharing of their financial data, stored with different Financial Information Providers (FIPs).

CONSENT ARTEFACT 

AA deals with the sensitive financial data of its Customers and hence it is essential for them to take the permission of its Customer, provided, while collecting financial data of Customers, their consent must be explicit, informed, and voluntary. The Customer’s consent is to be obtained, submitted and managed in compliance with the Non-Banking Financial Company – Account Aggregator (Reserve Bank) Directions, 2016 issued vide Master Direction DNBR.PD.009/03.10.119/2016-17 (here-in-after referred to as “the Master Directions”).

Clause 6.3 of the Master Directions stipulate that the AAs Platform must obtain consent of its Customers and formulate a standardised consent artefact, mandatorily containing the following details:

• Identity of the Customer and optional contact information,
• Nature of the financial information requested,
• Purpose of collecting such information,
• Identity of the recipients of the information,
• URL or other address to which notification needs to be sent every time the consent artefact is used to access information,
• Consent creation date, expiry date, identity and signature/digital signature of the AA,
• Other attributes as may be prescribed by the Bank (if any).

For the Customers, providing data with consent to the AA is a completely voluntary process. A person may choose to register on an AA if the bank in which they have an account has joined the AA network. AAs can share data with other financial institutions only after the person consents to the sharing of data between financial institutions. Further, the Customer is entitled to reject the consent request for sharing of data at any given time. In the cases where consent to share data is granted for a recurring access, such as during a loan period, the Customer is empowered to revoke such consent at any time later.

ELECTRONIC CONSENT FRAMEWORK

The RBI, keeping in mind the ‘Digital India’ initiative, has allowed AAs to collect consent through electronic mode. To facilitate this, the Department of Science and Technology has issued the Electronic Consent Framework which defines consent artefact as:

“a machine-readable electronic document that specifies the parameters and scope of data shared that a user consents to in any data sharing transaction”.

This framework provides for an electronic consent dashboard for the effective collection and tracking of individual consents. Electronic Consent allows its user to share data, after obtaining free, informed, specific, clear and revocable consent of Customers, with several service providers electronically and securely, while maintaining traceability to ensure that the data trails can be audited even in the future.

Consent Artefact, as specified by the RBI, is an electronic document which discloses the scope of data sharing and its purpose with the Customer. Clause 5.1 of the Electronic Consent Framework prescribes the following specifications applicable on a Consent Artefact:

1. Identifier Section

This section must specify all the parties involved in the transaction, such as the data provider holding such data; the data consumer accessing such data; the consent collector; and the user. Under this mechanism, account IDs are assigned by the entities to the users to distinguish multiple accounts of the same user with the same service provider.

2. Data Section

It contains the type of data that is being accessed along with the consent associated with such data access. Further, it should contain detailed specifications of the accessed data including the time period for which data is requested, duration of storage by data consumer, frequency of access of such data along with set of few attribute filters that can be used to further subset data, in accordance with the permission associated with it. Provided, all the data must be exchanged securely, using encryption.

 Under this, Data Access can be of three types – 

i. View Access – AAs are only allowed to view the data of the Customer and not to store it or reuse it later.

ii. Copy Access –AAs are allowed to copy data of the Customer, which they can store and reuse. However, such data should be used within the period defined in data life.

iii. Advanced Access – AAs will get a data packet of the entire financial data of the Customer through a secure container. However, they will not be able to read data as it is but will only be allowed to verify the authenticity of such data

3. Purpose of data access

It should specify the domain in which application is filed i.e., finance and the use within that domain that is enabled through the data access (e.g., loan offer computation), and a textual description of the data access.

4. Logging of consent and data flows

It must contain details about the identifiers that collect and store logs. Logging can be done by AAs or by other entities, if the Customer permits the same. Further, data providers and data customers can also maintain logs of the data independently for the purpose of conducting audits and analysis.

5. Signature

Finally, each Consent Artefact should contain a digital signature in the signature block along with the signature service provider’s ID, signature creation timestamp, and the user certificate required to verify the signature.

DATA EMPOWERMENT AND PROTECTION ARCHITECTURE (DEPA)

 Under the ecosystem of AAs, there are various modus operandi for collection of financial data of the Customer. The most dominant one among them is the method of Screen Scraping. Under this method, AAs possess the Customer’s authentication credentials i.e. username and password of their financial accounts, collect financial information of their Customers by using a software, which reads text data from a computer display terminal’s screen.

Though this method is the most prominent one, it provides incomplete financial information of its Customers, as the frequency and regularity of updating financial information on their website varies a lot.

In August 2020, the National Institution for Transforming India (“NITI Aayog”) presented a draft framework on Data Empowerment and Protection Architecture (DEPA), stating that India requires a paradigm shift in personal data management to enable greater user control over data sharing.

India Stack while keeping in mind the authenticity and security of data introduced the DEPA mechanism which is now also known as the ‘Consent Layer of India Stack’. This mechanism is a positive step towards ensuring data privacy as it provides Customers the absolute control over their data.

Customers can avail this facility, once they register themselves with the AAs, through a mobile application or desktop. DEPA has the potential to bring a paradigm shift in the mechanism of managing and processing financial data as it has the power to transform this organization-based system to a human-based system, by empowering its Customer to decide how their data can be utilized under this mechanism, such as –

• AAs are not allowed to see, sell or store financial data of their Customer, they can only collect and share such financial data.
• Customers are allowed to decide the time-period for which AAs can store their data.
• Customers are allowed to retract their consent at any time for sharing their financial data. Further, this mechanism allows Customers to be actively informed of the details of all the consent granted by them.
• Customers are allowed to control the extent to which data can be shared, for example; if a Customer has three bank accounts then he has the option to allow AAs to access data only from one or two of the accounts.

Hence, DEPA provides for a mechanism to control and regulate Customer data in a manner which is more preferable to the Customers in comparison to the current mechanism of Consent Artefacts. DEPA possesses huge potential to stimulate the profitable growth of an AA, along with enabling Customers to avail financial services through minimal effort.

DRAFT FRAMEWORK ON DEPA BY NITI AAYOG

As per the draft framework on DEPA, individuals or Customers should have absolute control over their data such as, how their data is accessed, stored, used and shared. It enables Customers to access and exchange their data with third-party institutions in a smooth and secure manner.

This framework introduces an intermediary in this transaction called the ‘Consent Managers’ who act as facilitators for the process of exchange of data. The consent manager will be in charge of keeping consent logs, which will decide how data can flow from data sources to approved system users, provided, they are not be allowed to read or save data while facilitating the transaction and shall remain data blind.

Under this framework users will be able to change their Consent Manager Operation service and opt for Consent Manager Portability.

Under the draft, consent from the user or data principal is more than a plain yes or no. DEPA uses the ORGANS framework to develop the concept of a good technology framework to enable informed consent:

• Open Standards: The consent architecture must adhere to open standards principles.
• Revocable: The user should be able to revoke their consent at any time.
• Granular: The consent must be offered at a granular level, with the data divided down into distinct characteristics, each with its own time and sharing privileges.
• Auditable: Using the MeitY Consent Log artefact, all events in the consent and data flow must be digitally signed and logged.
• Notification: When consent is granted or revoked, when data is requested, sent, or rejected, the user must be notified by email, SMS, in-app notice, and other notification mechanisms.
• Security by Design: Internal and external software and systems must be built with security in mind from the start. End-to-end data security (PKI, DSC, tamper detection) is required, as well as network agnostic and data-centric security.

This new framework aims to work through a process of exchange between FIUs and FIPs. The users known as Data Principals, in order to avail a service will have to provide their existing details to the FIUs and in such case, the other institutions such as banks, mutual fund platforms, insurance providers, etc., become the FIPs.

For this exchange, the Data Principal will provide his consent to the Consent Manager and he will generate a Consent Artefact. Thereafter, the Consent Artefact is transferred to the FIPs with the required instruction. Upon verification of this request, the FIPs will furnish the required information to the Consent Manager or the user directly which will then be transferred to the FIUs; thus, completing the transaction.

The draft mandates use of standard Application Programming Interfaces (‘APIs’) to allow for a continuous flow of encrypted data in response to data requests and to ensure seamless exchanges. Using the Draft’s APIs, institutions (such as banks) can send data in a machine-readable format to all licensed consent managers, who will then provide the data to the information requester after receiving sufficient consent.

AMLEGALS REMARKS

Consent plays a crucial role in accessing, storing and exchange of Customers’ data between FIUs and FIPs. The RBI Master Directions, emphasis on the importance of obtaining consent and the need for adequate consent management have mandated AAs platforms to inculcate a standardized Consent Artefact in accordance with the provisions of the Master Directions.

The Customer’s right to privacy over its financial information is of utmost priority in an AA ecosystem, as the entire working of the platform depends upon sharing and access of sensitive, personal information of an individual’s or Customer financial activities. Hence, the Master Directions take a leap forward in the right direction by enforcing the need for consent management by AAs and defining norms to be followed by such platforms for obtaining consent of the Customers.

The recently introduced DEPA Framework may further prove to be a revolutionizing move in the arena of data protection, provided, they are executed in the expected manner since it intends to grant its Customer with absolute control over how, when, where, with whom and for how much time they want to share their data, if any.

Since the recognition of Right to Privacy as an undisputable and crucial element of Article 21 of the Constitution of India, as pronounced in the judgment of K S Puttaswamy v. Union of India AIR 2017 SC 4161; and the recognition granted to it under Section 72 of the Information Technology Act, 2000 i.e., breach of privacy; and the introduction of the Personal Data Protection Bill, 2019; the need to implement safeguards to the fundamental right to privacy have become extremely crucial.

Implementation of DEPA is likely to compel the existing market players to comply with the framework; enabling the Customer to have absolute control over their data. Non-compliance with the DEPA framework may even lead to heavy penalties. Therefore, implementation of the DEPA framework in its full vigour is much awaited.

For any query or feedback, please feel free to connect with arushi.vyas@amlegals.com or tanmay.banthia@amlegals.com