The post is the second part of a two-part series that undertakes an analysis of the technical standards and specifications present across publicly available documents on Account Aggregators. In the previous post, the authors look at the motivations for building AAs and some consumer protection concerns that emerge in the Indian context. These pieces were written as part of the blog series on Account Aggregators by NALSAR Tech Law Forum
Account Aggregators (AA) appear to be an exciting new infrastructure, for those who want to enable greater data sharing in the Indian financial sector. The key data being shared will extensive personal information about individuals like us – detailing our most intimate and sensitive financial transactions and potentially non-financial data too. This places individuals at the heart of these technical systems. Should the systems be breached, misused or otherwise exposed to unauthorised access the immediate casualty will be the privacy of the people whose information is compromised. Of course, this will also have impacts on data quality across the financial sector.
It is heartening to note that the AA framework builds in a layer of software to operationalise “consent”, ostensibly to overcome consumer data protection and privacy concerns. As we set out in our previous post, consent is a necessary but not sufficient condition for effective data protection. AAs must have strong data accountability systems and access controls that operate independent of consent, to truly offer Privacy By Design. This will be crucial in engendering trust in this new system.
In this post, we introduce the concept of Privacy by Design (PbD) and use that framework to assess certain technical specifications that have been released for the AA architecture. From our analysis, we attempt to identify whether the PbD principles have applied to the designing process of the technical architecture of the AAs.
1. Privacy by Design principles for Account Aggregators
Privacy by Design (PbD) is a widely recognised approach that addresses the emerging systemic effects of Information and Communication Technology (ICT)[1]. Ideally, all information infrastructure must be designed in a privacy-protecting manner that does not create trade-offs between the privacy of the individuals and the efficiency of the infrastructure. Principles to enable such technological design are incorporated in the PbD framework (Cavoukian, 2011).
The PbD framework comprises of seven foundational principles that intend to make IT-interacting entities privacy assuring as a default mode of operation. These principles are as follows:
- Proactive not Reactive; Preventative not Remedial: Anticipation of privacy invasive events before they occur and taking measures to prevent their occurrence.
- Privacy as the Default Setting: Personal data of individuals must be automatically protected even if they take no action to explicitly do so
- Privacy Embedded into Design: Privacy protections must be built into IT systems and should not be treated as add-on of the function being delivered
- Full Functionality — Positive-Sum, not Zero-Sum: PbD does not simply involve the making of declarations and commitments but relates to satisfying all legitimate objectives − not only the privacy goals. PbD is doubly enabling in nature, permitting full functionality − real, practical results and beneficial outcomes to be achieved for multiple parties.
- End-to-End Security — Full Lifecycle Protection: Privacy of individuals’ personal data must be ensured throughout the lifecycle of data.
- Visibility and Transparency — Keep it Open: All individuals and stakeholders involved must have full visibility into the business practices and the technology used for with regards to their data. It must be ensured that their practices are in accordance with the stated objectives.
- Respect for User Privacy — Keep it User-Centric: Privacy of the individual must be given utmost importance through strong privacy defaults, appropriate notices and empowering, user-friendly options (Cavoukian, 2011).
While PbD principles are not an authoritative privacy framework within which information systems can be assessed, this framework can be operationalised through several technological practices and techniques to enhance privacy of the information systems.
2. Assessing the security measures of the Account Aggregator system
In order to assess how AAs fare against the PbD principles, it is necessary to understand the major flows of information within the AA ecosystem. These are between the Financial Information Providers (FIP), AAs, Financial Information Users (FIU) and consumers (users).
Figure 1 and Table 1 below seek to represent the flows that occur systematically between different entities of the AA ecosystem in a simplified form.[2]
This figure shows our representation of three sets of queries and three sets of data flows that are necessary in the AA system. These are summarised in Table 1 (mapping to the corresponding numerals in Figure 1 above).
Table 1: Query flows and data flows in the Account Aggregator ecosystem
| Column 1: Query Flows | Column 2: Data Flows | ||
| 1 | FIU queries the AA for FI | 4 | User provides AA with Consent |
| 2 | AA queries the User for Consent | 5 | FIP transfers information to the AA |
| 3 | AA queries the FIP for FI | 6 | AA transfers information to FIU |
In the AA system,
- Queries are initiated as shown in Column 1 of the Table (from top to bottom) within the AA ecosystem. A query is a request for data or information that one entity may place to another entity that carries a database. For instance, an FIU queries AA for the desirable FI.
- In response to these queries Column 2 (from top to bottom) lists the data flows that occur in response to query flows A1 to C1 respectively. In response to the query flow, the relevant data will be encrypted and flow to the entities identified in the Column 2.
In the following section, we identify whether the PbD principles have been applied to the designing process of the technical architecture of the AAs.[3]
2.1. Assessing the AA’s Query Flows against PbD Principles
(i) Query Flow 1: FIU queries the AA for information (1)
When a customer approaches a new financial institution for a financial product, that financial institution (or FIU) can query the AA for relevant information about such customer. The FIU creates a request for consent, or a query to obtain FI from the consumer2 In this query, the FIU must provide specifications on the required information such as account types, asset types, transaction types etc. and the duration and period in which the FIU will use this FI (NeSL Asset Data Limited, 2018).
The IT measures stipulated for this query flow are that the application programming interface (API)[4] calls between the FIU and AA must take place over a Secure Socket Layer (SSL)[5] (Hypertext Transfer Protocol Secure (HTTPS) is the application layer in this case). Each of these API calls must be digitally signed and encrypted. All internet-facing services (such as the FIU portal provided by the AA) should be placed in demilitarized zone (DMZ)[6] (NeSL Asset Data Limited, 2018).
Purpose specification appears to be a requirement for requesting FI. ReBIT provides Purpose Definitions which include the categories Personal Finance, Financial Reporting and Account Query and Monitoring with further subcategories (ReBIT, n.a.). It can be assumed that the request for consent created by the FIU stipulates the relevant Purpose Definition(s)[7].
In this flow, the privacy and security measures appear to point to the PbD principles of Positive Sum not Zero Sum and End-to-End Security – Full Lifecycle Protection.
(ii) AA queries the User for Consent (2)
Upon receiving the request for consent from the FIU, the AA performs the function of notifying the user that their information is being queried. The user is notified of the FIU, and the classes of information that this FIU is seeking. The AA provides a user interaction front-end (such as a web portal or a mobile device app) to the user through which they may receive these notifications (ReBIT, 2019; NESL Asset Data Limited, 2018).
The IT security measures for this query flow stipulate that the user be required to log-in to a web portal (provided by the AA) or the mobile app to either accept or reject the request for consent from the AA. This web portal or mobile app should be placed in DMZ and must be firewalled. It is also stipulated that a one-time password (OTP) be used for authentication for giving or revoking consent by the user (NESL Asset Data Limited, 2018).
In this flow, the privacy and security measures appear to point to the PbD principles of Positive Sum not Zero Sum and Visibility and Transparency – Keep it Open.
(iii) AA queries the FIP for information (3)
If the user approves the request for consent from the AA, a digitally signed artefact is generated and sent to the FIP along with the request for information initiated by the FIU. The FIP may store the consent artefacts to validate against future requests of information with respect to the same user and FIU (ReBIT, 2019; NESL Asset Data Limited, 2018).
It is stipulated that this query flow, and all other internal networks be firewalled (NeSL Asset Data Limited, 2018).
In this flow, the privacy and security measures appear to point to the PbD principle of Positive Sum not Zero Sum.
2.2. Assessing Data Flows against PbD Principles
(i) User provides AA with Consent (4)
When the user receives the notification from their AA web portal or mobile app, the user may approve or reject such a request. If the user approves the request for consent, the consent artefact thus created is sent to the AA (Reserve Bank of India, 2018).
The IT security measures for this data flow stipulate that all payloads be digitally signed by the requester (in this case, the consent artefact should be digitally signed by the user). The AA client never sees the account of the user or directly participates in consent generation (ReBIT, 2019). All personally identifiable information (PII) (such as account numbers, phone numbers, personal identifiers etc.) present in the User Identifier section of the consent artefact must be tokenised using virtual IDs[8]. The internet-facing services (the AA front-end portal provided by the AA) must be placed in the DMZ (NeSL Asset Data Limited, 2018).
In this flow, the privacy and security measures appear to point to the PbD principles of Positive Sum not Zero Sum, End-to-End Security – Full Lifecycle Protection and Visibility and Transparency – Keep it Open. However, it is difficult to state whether the principle of Respect for User Privacy — Keep it User-Centric given the central importance of consent as a sufficient safeguard for user privacy.
(ii) FIP transfers information to the AA (5)
Once the AA forwards the consent artefact to the FIP, the FIP validates the same and responds with the information requested for in the consent artefact. When the FIP notifies the AA that the required information is available, the AA pulls the information from the which is stored in its transient store. The required information must be returned in real-time.
The IT security measures for this data flow stipulate that API calls between the AA and the FIP take place over the SSL, the information be transferred only once the consent artefact has been validated and the returned information be in encrypted, digitally signed and be in a machine-readable format. Any information stored in the transient store of the AA must also be encrypted (NeSL Asset Data Limited, 2018).
In this flow, the privacy and security measures appear to point to the PbD principles of Positive Sum not Zero Sum and End-to-End Security – Full Lifecycle Protection.
(iii) AA transfers information to FIU (6)
After pulling the information from the FIP and storing it in the transient store, the AA notifies that the required information is ready. The FIU fetches this information from the AA.
The IT security measures for this data flow stipulate that the users’ information never be decryptable while in the transient store of the AA. The data-in-transit (FI) must also be encrypted. The AA is required to stipulate a time frame within which the FIU must pull the information from the transient store of the AA. The information may be stored in the AA for a maximum of 72 hours. Finally, it is also required that once the information has been pulled by the FIU, the AA must delete the information from its transient store (NeSL Asset Data Limited, 2018).
In this flow, the privacy and security measures appear to point to the PbD principles of End-to-End Security – Full Lifecycle Protection.
3. Insights from our assessment of AAs against PbD principles
Our assessment of the AA framework reveals some causes for optimism, and some for concern.
3.1. Consent as the primary safeguard for user privacy is not enough: Theoretically, the DEPA framework provides the user with complete control over how their information is used. The users also have the provision to provide, pause and revoke their consent through the web portal or mobile app of the AA.
However, this approach assumes that consent is a sufficient condition to provide user privacy. It also assumes that the user is comprehensively aware of the consequences of the consent they are providing, which is often not the case. Consent is important in providing agency and autonomy of choice to users, but cannot be considered a holistic, user-based privacy manager. The insufficiencies of consent have been discussed in the previous blog of this series.
3.2. Fulfilment of the PbD principles by the AA ecosystem: From our analysis, it was observed that some PbD principles appear to be fulfilled, sometimes partially if not completely. PbD principles of Positive Sum not Zero Sum, End-to-End Security – Full Lifecycle Protection and Visibility and Transparency – Keep it Open appear to be accounted for in the architecture of the AAs.
However, other significant principles of Proactive not Reactive; Preventative not Remedial, Privacy as the Default Setting, Privacy Embedded into Design and Respect for User Privacy — Keep it User-Centric do not seem to be fulfilled in this architecture. While there may be aspects in the query and data flows that may point to these principles, on an overarching level, it cannot be said that these principles have been incorporated.
For instance, this is reflected in the fact that there are no technical safeguards to ensure that FIU entities do not misuse the personal data they receive from AAs. This does not incorporate the principle of Proactive not Reactive; Preventive not Remedial. We must ensure that FIUs have sound cyber security practices and codes of conduct before they are integrated in to the AA ecosystem.
3.3. Accountability of FIUs and FIPs with respect to the personal data they receive from AAs: A central issue that these flows force us to ask is: how will data be protected after an FIU receives it from an AA, and it disappears into the FIU’s systems? It appears that the first time that a consumers’ data by AAs it would take place in an ecosystem that is designed in a secure and privacy protecting manner. If the data is then ejected into an FIU with insecure, privacy depleting system it would defeat the entire purpose of secure data sharing infrastructures.
The accountability of FIUs and FIPs with respect to the personal data they receive through the AA system needs clarification. Mere legal threats of enforcement will be insufficient – strong technical solutions to address this risk must be developed to ensure privacy is protected after entities receive information from AAs.
These concerns need to be addressed before full-fleshed public release into the market.
Conclusion: Large data infrastructures for finance in India must consider legal obligations as well as technological safeguards
It appears that most cybersecurity and privacy-protecting practices for large data infrastructures have been proposed for the AA ecosystem (European Union Agency for Network and Information Security, 2015). Practices of external security audits and suspicious transaction pattern monitoring have also been stipulated. However, safeguards on the use of FI after it has been obtained by the FIU, and other such provider obligations cannot be seen. If an FIU were to be considered a data fiduciary[9], it is unclear whether they would be obliged to notify data breaches occurring in their organisation internally. There appear to be no technological safeguards hardwired in to the architecture of the ecosystem that prevents misuse of FI by FIUs and legal obligations on FIUs are deemed to be sufficient.
From our analysis of the AA architecture using the PbD framework, we see that some principles of the framework have been incorporated partially, but there appear to be several disjoint points where user privacy do not take priority. This is especially important to consider given that most Indians would be first-time users of such technology, or even enabling technological infrastructures such as mobile phones or internet. Separately, the draft PDP bill stipulates Privacy by Design as a Transparency and Accountability measure that must be implemented by every data fiduciary.[10]
Data Empowerment and Protection Architecture (DEPA) makes for a commendable first step towards empowering Indians with the control of their personal data, it must be noted that consent independent of appropriate accountability measures for the providers and data fiduciaries. Legal obligations are important for this, but there needs to a strong technological backing in terms of codifying concepts of purpose limitation and collection limitation in order to safeguard consumers and their personal information.
—
References
Cavoukian, A. (2011). Privacy by Design – The 7 Foundational Principles. Retrieved from Information and Privacy Commissioner of Ontario: https://www.ipc.on.ca/wp-content/uploads/resources/7foundationalprinciples.pdf
Cisco. (n.a.). Configuring DMZ. Retrieved from Cisco: https://www.cisco.com/c/dam/assets/sol/sb/isa500_emulator/help/guide/ad1681599.html
European Union Agency for Network and Information Security. (2015, December). Big Data Security: Good Practices and Recommendations on the Security of Big Data Systems. Retrieved from European Union Agency for Network and Information Security (ENISA) : https://www.enisa.europa.eu/publications/big-data-security/at_download/fullReport
MEITy. (2018). The Personal Data Protection Bill, 2018. Retrieved from Ministry of Electronics and Information Techonology: https://meity.gov.in/writereaddata/files/Personal_Data_Protection_Bill,2018.pdf
NeSL Asset Data Limited. (2018, June 28). Request for Proposal for Selection of Vendor for Design, Development, Installation, Integration, Configuration, Support. Retrieved from National e-Governance Services Limited (NeSL): https://www.nesl.co.in/wp-content/uploads/2018/06/NADL_RFP_26062018-update.pdf
ReBIT. (2019). Account Aggregator API. Retrieved from Swagger: https://swagger-ui.rebit.org.in/?url=https://s3.ap-south-1.amazonaws.com/api-spec-prod/api_specifications/account_aggregator/AA_1_1_1.yaml#/Consent%20Flow/post_Consent
ReBIT. (n.a.). Account Aggregator Purpose Definition. Retrieved from ReBIT: https://api.rebit.org.in/purpose
Red Hat. (n.a.). What is an API? Retrieved from Red Hat: https://www.redhat.com/en/topics/api/what-are-application-programming-interfaces
Reserve Bank of India. (2018, February 23). Master Direction- Non-Banking Financial Company – Account Aggregator (Reserve Bank) Directions, 2016 (Updated as on February 23, 2018). Retrieved from Reserve Bank of India: https://www.rbi.org.in/Scripts/NotificationUser.aspx?Id=10598&Mode=0
Russell, A. (2019, October 2). What is SSL? Retrieved from SSL: https://www.ssl.com/faqs/faq-what-is-ssl/
Sahamati. (2019, July 25). Nandan Nilekani introducing the Account Aggregator at CUG on July 25, 2019. Retrieved from Sahamati: https://sahamati.org.in/blog/nandan-nilekani-introducing-account-aggregator-at-cug/
Techtarget Network. (n.a.). Tokenization. Retrieved from Search Security: https://searchsecurity.techtarget.com/definition/tokenization
Unique Identification Authority of India. (2018, January 10). Enhancing Privacy of Aadhaar Holders – Implementation of Virtual ID, UID Token and Limited KYC. Retrieved from Unique Identification Authority of India (UIDAI): https://uidai.gov.in/images/resource/UIDAI_Circular_11012018.pdf
Zuppo, C. M. (2012). Defining ICT in a Boundaryless World: The Development of a Working Hierarchy. International Journal of Managing Information Technology (IJMIT), 13-22. Retrieved from https://s3.amazonaws.com/academia.edu.documents/38212933/4312ijmit02.pdf?response-content-disposition=inline%3B%20filename%3DDefining_ICT_in_a_Boundaryless_World_The.pdf&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWOWYYGZ2Y53UL3A%2F20191211%2Fu
[1] Information and communications technology (ICT) is an extensional term for information technology (IT) that stresses the role of unified communications[1] and the integration of telecommunications (telephone lines and wireless signals) and computers, as well as necessary enterprise software, middleware, storage, and audiovisual systems, that enable users to access, store, transmit, and manipulate information (Zuppo, 2012).
[2] It must be noted that this table is only representative of the use-case of the FIU seeking information of a user from the FIPs that have the information of the user. It does not cover the other proposed functions of AAs such as providing users with consolidated views of their FIs, users seeking their own data from FIPs, allowing users to manage previously given consents etc. (NESL Asset Data Limited, 2018; Reserve Bank of India, 2018).
[3] For this analysis, we refer to the following available documentation: Master Direction- Non-Banking Financial Company – Account Aggregator (Reserve Bank) Directions, 2016 released by the RBI (Reserve Bank of India, 2018), Account Aggregator Key Resources on the Sahamati website (Sahamati, 2019) and the Request for Proposal (RFP) for Selection of Vendor for Design, Development, Installation, Integration, Configuration, Support & Maintenance of Account Aggregation software by NESL Asset Data Limited (NeSL Asset Data Limited, 2018).
[4] Application Programming Interfaces or APIs are a set of definitions or protocols used for building or integrating different technological platforms to provide convenience in their interaction for services and/or data (Red Hat, n.a.). For instance, Uber uses the publicly available API of Google Maps on their interface.
[5] Secure Socket Layer, or SSL is a standard protocol used for the secure transmission of documents over a network through authenticated and encrypted links (Russell, 2019).
[6] Demilitarized zone, or DMZ is a sub-network that provides an additional layer of protection to the local network of a given organisation or system. The DMZ is located behind the firewall and is available to the public, i.e., the public can access resources and services present in the DMZ without being able to penetrate the local network (Cisco, n.a.).
[7] Other Purpose Codes include Personal Finance (for wealth management services and obtaining customer spending patterns, budgets or other reporting), Financial Reporting (for aggregated statements) and Account Query and Monitoring (for periodic or one-time consent for monitoring of accounts) (ReBIT, n.a.).
[8] Tokenisation refers to the process of replacing sensitive data or personally identifiable data with unique identification symbols (referred to as the token) that retain all the essential information about the data without compromising its security (Techtarget Network, n.a.). For instance, in 2018, the Unique Identification Authority of India (UIDAI) issued a circular stating that Aadhaar holders could start using temporarily-generated virtual IDs (tokens) in lieu of sharing their Aadhaar numbers for authentications for availing various services (Unique Identification Authority of India, 2018).
[9] Data Fiduciary is a term used in the draft Personal Data Protection Bill, 2018 to refer to any person, including the State, a company, any juristic entity or any individual who alone or in conjunction with others determines the purpose and means of processing of personal data (MEITy, 2018).
[10] S(29), Chapter VII, draft Personal Data Protection Bill, 2018 (MEITy, 2018).
