Consent Architecture

1. Overview

The Constitution of India ('the Constitution') recognises a fundamental right to privacy, which has been read into to influence the development of right against the invasion of privacy and the interpretation of rights embodied in laws on consumer protection, health, IT, telecom licences, and the financial sector.

It is essential to mention here the regulatory framework firmed up by the Reserve Bank of India (RBI) to support orderly growth of credit delivery through digital lending methods while mitigating the regulatory concerns. Certain highlights of the requirements to be followed by the respective data collectors in this context are as follows:

1. All loan disbursals and repayments are required to be executed only between the bank accounts of borrower and the Regulated Entity (RE) without any pass-through/pool account of the Lending Service Provider (LSP) or any third party.
2. REs should ensure that they and the LSPs engaged by them shall have a suitable nodal Gievance Redressal Officer to deal with FinTech/ digital lending related complaints, whose details shall be prominently indicated on the website of the RE, its LSPs and on DLAs, as applicable. Any complaint lodged by the borrower is required to be resolved within the stipulated period (currently 30 days).
3. Data collected for the purpose of lending should be need based, should have clear audit trails and should be only done with prior explicit consent of the borrower.
4. Option should be provided for borrowers to accept or deny consent for use of specific data, including option to revoke previously granted consent, besides option to delete the data collected.

Consent lies at the heart of almost all the data protection and privacy regulations enforced globally. Consent means providing individuals the ability to control and manage usage of their personal information by a data fiduciary or processor. Genuine consent puts individuals in charge of their data. It also helps build trust in the organization storing and processing personal information. Therefore, Consent Management Architecture has become a critical requirement for enterprises.

It is critical that core consent requirements should be considered while defining consent related processes, controls, policies and standards. Once all the basic processes are defined and established, they need to be operationalised and implemented as part of core business processes. This reduces manual effort, errors in consent validation process and cost by minimising noncompliance fines.

With the advent of paperless journey for lending in India, therefore Consent Management Architecture has become necessary to meet data privacy and data storage. The Data collection for enabling digital service delivery of both government and private services to citizens with the help of eKYC based on Aadhaar based Authentication, digital signature and OTP based authentication, have enabled the service providers to onboard customers in a seamless manner.

Systems require a mechanism for obtaining and preserving user consent to operate effectively and securely. The Information Technologies Act 2000 (as amended from time to time) and rules made thereunder or affecting its application also require that any entity sharing user data that is sensitive in nature must obtain consent from the user prior to such sharing. These rules include Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011 ('the SPDI Rules') and the Information Technology (The Indian Computer Emergency Response Team and the Manner of Performing Functions and Duties) Rules, 2013 ('CERT-In Rules'), amongst others.

The technology framework outlined in this document is designed to be in compliant with what was proposed by Government of India & Ministry for Electronics & Information Technology (MeitY) on data consent & privacy standards. Using this framework, data consumers (lenders, underwriters) can access data of users from providers (APIs, Credit & Bureau scores, KYC documents etc.) using electronic consent, rather than requiring users to share credentials like passwords or to sign paper documents.

2. Definitions

1. Data — Any electronic information that is held by a public or private service provider (like a government service department, a bank, a document repository, etc). This may include both static documents and transactional documents.
2. User — any person or entity who wishes to share data about them for availing a service.
3. Data Provider (DP) — Any entity which has data about users in their system that can either be given to the user (whose data it is) or to another entity based on the consented request of the user.
4. Data Consumer (DC) — Any entity which accesses data for providing a service to the user.
5. Consent Collector (CC) — An entity that interacts with users and obtains consent from them for any intended access to data. This role may be played by the Data Consumer (in most cases) or the Data Provider or could be another service provider.
6. Lending Service Provider (LSP) – Independent entities engaged by Regulated Entities for promoting, processing and easier accessibility of customers to digital lending ecosystem.
7. Regulated Entity (RE) – Entities regulated by the RBI and permitted to carry out lending business

3. Components

Consent Management Architecture should ideally consist of the following components/stages:

1. User interaction and Consent Collector (CC)
2. Consent Manager (CM)
3. Data Manager (DM)
4. Context Handler (CH)
5. Reconciliation Manager (RM)

4. Consent Artifact

The consent artifact is in the form of a machine-readable electronic document that specifies the parameters and scope of data share that a user consents to in any data sharing transaction and is meant to initiate consent capture. In this framework, consent must be digitally signed, accepted via OTP with authorized mobile number either by the user (using the services of a signature service provider) or by the consent collector or both.

Thus, it is essential that a digital signature or OTP authentication be included in every consent artifact that is then used to facilitate data sharing. The consent collector (in this case Aton) must ensure the scope of data sharing and purpose is clearly provided to the user. Once the user agrees to the scope of sharing, he/she may be requested to sign the consent digitally, on mobile (OTP) in which case the resulting artifact would contain the user’s OTP authorization or digital signature. The consent collector may also obtain data sharing authorization from the user differently (e.g., by having the user click a button or mobile OTP by signing a paper form). In such situations, the consent artifact that is generated would contain the consent collector’s digital signature or digital record of acceptance. Subsequently, the data provider may provide the requested data to the data consumer, after validating the consent artifact, which involves verifying the digital acceptance.

Following sections provide the high level structure of the consent artifact:

1. • Identifier Section: Specifies all the entities that are involved in the transaction: the data provider holding the data, the data consumer accessing the data, the consent collector, and the user. To identify the user, a User element provided by an identity service provider is used. Additionally, account IDs assigned by the players within the ecosystem can be used. Account IDs enable distinguishing multiple accounts of the same user with the same service provider; these may not be included in case the user ID is sufficient for account disambiguation.
   • Data Section: Second section is comprised of fields describing the type of data that is being accessed and the access permissions associated with each of them. This section also describes the specific data that is shared, date range for which data is requested, duration of storage by data consumer, frequency of access, along with a set of attribute filters that can be used to further subset data. Data access permissions can be of three types: the data consumer can either get VIEW access to the data, which implies that the consumer is not allowed to store the data or reuse it later. Or they could get a COPY of the data which they can store and use within the period defined in datalife. In advanced mode, using a secure container, data consumer could get a data packet that cannot be read as-is, but, only be queried. All data must be exchanged between the provider and the consumer in a secure fashion using either data and/or channel encryption.
   • Purpose of data access: This may include information about the application domain (e.g., loan) and the application within that domain that is enabled through the data access (e.g., loan offer computation) and a free-form textual description. A more detailed ontology for purpose descriptions may be created for various domains that can be included in future versions of this document.
   • Logging of consent and data flows: The consent artifact includes identifiers for entities which collect and store logs. Logging could be done by the consent collector or by other entities e.g., logs could be sent to the users’ own email addresses, if the user desires so. Data providers and data consumers could also independently maintain logs (without explicit mention in the consent artifact) for auditing and analytics purposes
   • Data Protection: The consent artifact shall include Data Protection in to prevent any form of unlawful interception or misuse of User Information, the respective parties shall use appropriate reasonable physical, electronic, and managerial procedures to safeguard and secure the collected User Information in compliance with the Information Technology Act, 2000 (as amended from time to time) and the rules related thereto to protect the user information against any misuse. The User shall ensure that it will not share user name, password, or other security information relating to Your account with anyone. The user shall confirm that he has been made aware of the security measures undertaken by Us and he expressly consent to Us storing, handling, using Your User Information.
   • Disclaimer: The Consent Artifact shall contain a disclaimer that we make no warranties or representations about the accuracy or completeness of this Platform and contents hereof. We nor any of Our contractors, partners or employees shall be liable for any direct, incidental, consequential, indirect or punitive damages arising out of access to or use of any content of this Platform, etc.
   • Acknowledgment and consent: Before providing the signature, the user shall acknowledge that by visiting the Platform he/she agrees to be bound by the terms and conditions of the Privacy Policy and by use of the Platform, he/she has expressly and unconditionally agreed to the terms and conditions of Privacy Policy and consented to the usage, storage and handling of the personal information/ sensitive personal data submitted by user in accordance with the terms contained therein.
   • Signature: Finally, each consent artifact contains a digital signature, OTP authorization or Acceptance button on the App / web App . The signature is included in a signature block which also includes information like the signature service provider’s ID, the signature creation timestamp and the user certificate or digital acceptance or OTP authorization with registered mobile verifying the signature.

5. Consent & Data Flow

Consent capture and use process is comprised of two flows: consent flow wherein consent is created and the consent parameters are shared with the relevant entities; and a data flow, where the actual data access, based on user consent, happens. In the data flow, the consent artifact is utilized to enable the data consumer to access the data held by the data provider. In consent flow, where the user grants permission for a certain kind of data access between a data consumer and a data provider. The consent flow must necessarily involve an interaction between the consent collector, and the user, at the end of which a consent artifact — an electronic representation of the consent given by the user — is generated and shared by the consent collector with either the data consumer or the data provider, depending upon who initiates the data share.

The consent artifact is used in the second flow, the data flow, for the actual data share to happen, sometimes repeatedly. In the case of data shares initiated by the data consumer, the data provider must verify the signature in the consent artifact before granting access to data. In the case of data shares initiated by the data provider, the data consumer must verify the signature before accepting data. The consent and data flows operate asynchronously in an API-driven manner, which ensures efficiency and resilience. Events at various stages of the consent and data flows are logged and digital signatures are used to ensure security in each of the flows.

The separation of the consent and data flows is a key feature of the consent framework. It is important for data flows to be executable asynchronously without the engagement of the user. This framework specifically enables this separation.

6. Consent Revocation

If the consent is marked as "revocable", then users have the ability to revoke that consent at a later date, by requesting the data provider, the data consumer or other entities. The consent artifact has provision for defining Revoker for revoking the consent and options for Data Consumer and Data Provider to get notified on various events such as this. In most situations, Revoker would be a URI owned by the Data Provider. Revocation requests sent to the revoker must follow a standard format which is specified below. Requests must be digitally signed, just like the original artifact being revoked.

While verifying signatures in consent artifacts (in the data flow), the data provider/ consumer must also check that the consent artifact has not been revoked by the user, and only when this is true should the data share be allowed to occur.

7. Logging and Notification

All events in the consent flow and data flow must be logged and notified as necessary using Consent Log artifact. A log artifact contains the consent artifact along with information about when and by whom the log was created. Two types of consent flow events must be logged - CONSENT-CREATED and CONSENT-REVOKED. For data flow events, logs must be created for DATA-REQUESTED (when a new data request is received by the data provider), DATA-SENT (when data is sent by data provider to data consumer) and DATA-DENIED (when data request is denied by data provider). Additionally, for DATA-SENT event, the list of data items shared by the data provider / received by the data consumer must also be logged.