[This post has been authored by Jalaj Jain of the Gujarat National Law University (GNLU), Gandhinagar.]
Introduction
Category: Finance
Post-Crypto-Writ Judgement: How(ey) to regulate the ICOs?
[This post has been authored by Harshit Goyal, currently in his 3rd year at National Law School of India University, Bangalore.]
Introduction
Building safe consumer data infrastructure in India: Account Aggregators in the financial sector (Part II)
TLF is proud to bring you a two-part guest post authored by Ms. Malavika Raghavan, Head, Future of Finance Initiative and Ms. Anubhutie Singh, Policy Analyst, Future of Finance Initiative at Dvara Research.
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 looked at the motivations for building AAs and some consumer protection concerns that emerge in the Indian context.
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 an impact 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 been applied to the designing process of the technical architecture of AAs.
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 in to 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.
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 following section, we identify whether the PbD principles have been applied to the designing process of the technical architecture of the AAs.[3]
Assessing the AA’s Query Flows against PbD Principles
1. 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.
2. 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.
3. 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.
Assessing Data Flows against PbD Principles
1. 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.
2. 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.
3. 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.
Insights from our assessment of AAs against PbD principles
Our assessment of the AA framework reveals some causes for optimism, and some for concern.
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.
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.
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
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
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
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 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. 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.
[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.
[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. 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.
[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).
Building safe consumer data infrastructure in India: Account Aggregators in the financial sector (Part I)
TLF is proud to bring you a two-part guest post authored by Ms. Malavika Raghavan, Head, Future of Finance Initiative and Ms. Anubhutie Singh, Policy Analyst, Future of Finance Initiative at Dvara Research.
Following is the first part of a two-part series that undertakes an analysis of the Account Aggregator system. Click here for the second part. Other posts in TLF’s blog series can be found here.
The Reserve Bank of India (RBI) released Master Directions on Non-Banking Financial Companies – Account Aggregators (Master Directions) in September 2016, and licences for India’s first Account Aggregators (AAs) were issued last year. From these guidelines and related documents, we understand that the purpose of Account Aggregator (AA) is to collect and share:
- consumers’ financial information (FI)[1] with their consent,
- by securely intermediating between entities requesting their data (the Financial Information Users (FIUs)[2]), and
- entities who hold and share the consumers’ data (the Financial Information Providers (FIPs)[3]).
Given that the AA infrastructure is aimed at harnessing the value of consumer’s personal data, does it sufficiently protect them during the data sharing process? We will consider some answers to this two-part blog series. In this post we consider the motivations for the AAs, and specifically look at the consumer protection concerns if consent becomes the main strategy for user protection in a data sharing infrastructure.
The motivation for the Account Aggregator system: Breaking down data siloes
The key motivation for AAs appears to break down siloes of data and enable encrypted sharing of data between firms, taking the consent of the consumer. The appeal of AAs is that they can provide of one-tap information for financial service providers. This can drive down the supply-side costs of disbursing credit. These costs include transaction costs relating to customer identification, data gathering and due diligence as well as related costs of staff and offices to undertake data gathering activities (George & Sahasranaman, 2013). Building this kind of infrastructure for sharing consumer data could reduce the cost of credit disbursement for every additional unit of credit (i.e. for every loan) that arise using physical documentation and customer data collection to a certain extent.[4] This cost saving could apply to all financial products, since most require some degree of customer verification and due diligence documentation.
So AAs could drive down costs in the chain of financial services supply. What is in it for consumers?
1. Potential benefits: Swifter services & lower costs
From the consumers’ perspective, the swifter sharing of their information may enable quicker service delivery. Financial benefit for consumers will depend on whether entities pass on the cost savings they may make or use data effectively to provide more suitable products and services.
Institutions who are seeking to use the AA system will need to invest resources to enable the kind of data-sharing that is envisioned. Additionally, AAs themselves will need to be built securely and effectively. The incentive for entities to participate in this system will be dependent on the quality of the data as well as how secure the AA ecosystem is. To protect consumers whose data is being shared, it is also important to consider if the architecture envisioned in the AA is sufficiently accountable, privacy-protecting and consumer-friendly.
2. Potential risks: Consent is a good first step, but recognised to be an ineffective tool of empowerment for consumers when it comes to data sharing
The AA system adopts a system of obtaining user consent before data-sharing. This system is called the Data Empowerment and Protection Architecture (DEPA).
The DEPA framework developed by Indiastack that allows users to control the sharing and usage of their personal data amongst various services and entities. The framework also maintains the necessary safeguards for the privacy of the data, i.e. the data is used and shared only to the extent that the user allows it for a stipulated purpose. The framework is designed to be transparent, and all transactions will be made traceable and auditable (Indiastack, n.a.).
From the description above, it appears that the DEPA framework seeks to put individuals on notice that their data is being requested. It then asks for their granular consent on whether particular information records about them can be shared or not shared. This form of permission-based data sharing is known as the “Notice and Consent” model in data protection scholarship (Kemp, 2017). Under this approach, the consumer is provided with notice prior to their data being collected, informed of how it might be used in the future and takes consent for the use of the information from the consumer.
Although this might appear to grant agency and autonomy to users, in practice the Notice and Consent is known to have many failings that fails to protect users’ interests, and in most cases presents a false choice to users.
Cognitive limitations operate on individuals’ decision- making about their personal data
Personal data is intangible and its use results in benefits and harms which are not immediately apparent to users. Research is beginning to show that there are severe cognitive limitations that impair individuals’ ability to make informed and rational choices about the costs and benefits of consenting to the collection, use, and disclosure of their personal data (Solove, 2013). Acquisti (2004) has highlighted how immediate gratification bias — due to which individuals overvalue the immediate period as compared to all future periods – can cause individuals to make suboptimal privacy decisions.[5] As a result of this bias, individuals have been shown to choose to receive an immediate gain from data sharing (or avoid immediate costs of protecting data) and discount costs of possible future risks. They are unable to process the effect of cumulative risk over all future periods (Acquisti, 2004).
The threat of denial of service can make “taking consent” a false choice
A major structural issue today is the binary nature of the choice consumers: they can either “agree” to the terms of on which their data is collected under providers’ privacy notices or disagree and be denied the service. This “take it or leave it” scenario leaves consumers with no real choice and impacts how individuals behave when agreeing to the terms under which their personal data is collected, processed and shared (Bailey, Parsheera, Rahman, & Sane, 2018).
Conclusion: DEPA must be supported by other data accountability features, and also become meaningful for non-smartphone users
The concept of Account Aggregators solves for a significant problem of financial data aggregation for individuals and small and medium enterprises alike. It also appears to take consumer data protection & privacy seriously for the first time, unlike previous large architectures. However, to be effective it must be supported by strong accountability systems and access controls that operate independent of consent. Relying solely on consent is not a good idea – as a wealth of data protection and consumer protection thinking has shown that Consent is necessary but not sufficient for data protection.
A broader concern is that a highly smartphone dependent user interface such as DEPA may not address the needs of the substantial feature phone audience in India who may not have access to reasonably good internet connections and electricity. As Account Aggregators gain traction in the financial community, deliberations about its impact of different demographics of the population become important, especially as it comes during a time of increased promotion of a more digital India. Consequently, it is important to improve on consent interfaces for feature phones. This must be done with the knowledge that consent is a necessary but insufficient safeguard for users’ data.
One significant lesson from our last decade of building public data infrastructures in India has been that such projects must carefully consider potential vulnerabilities in the system that could expose people to harm if their data is compromised, misused or inaccurately recorded. In India, we would do well to learn from our past experience with creating large public infrastructure that collates personal information of individuals. The implementation of a new large data infrastructure must ensure that data protection & privacy concerns that have been raised in the past are not replicated, or worse, magnified (Omidyar Network, 2018; Khera, 2019; Sharma, 2019).
It is heartening to see that DEPA is one step towards doing so, but many more features would be necessary to ensure privacy and security by design. How does the AA infrastructure fare when analysed against Privacy By Design principles? We will analyse this in our next post.
In the second post of this series, we undertake an analysis of the technical standards and specifications present across publicly available documents on Account Aggregators. We map the technical standards to the seven principles of Privacy by Design (PbD) and deliberate on the privacy and data protection afforded by the architecture of AAs.
References
Bailey, R., Parsheera, S., Rahman, F., & Sane, R. (2018, December 11). Disclosures in privacy policies: Does “notice and consent” work? Retrieved from NIPFP Working Paper Series: https://www.nipfp.org.in/media/medialibrary/2018/12/WP_246.pdf
George, D., & Sahasranaman, A. (2013, April). Cost of Delivering Rural Credit in India. Retrieved from Dvara Research: https://www.dvara.com/research/wp-content/uploads/2013/04/Cost-of-Delivering-Rural-Credit-in-India.pdf
Indiastack. (n.a.). ABOUT DATA EMPOWERMENT AND PROTECTION ARCHITECTURE (DEPA). Retrieved from Indiastack: https://indiastack.org/depa/
Kemp, K. (2017, August 22). Big Data, Financial Inclusion and Privacy for the Poor. Retrieved from Dvara Research: https://www.dvara.com/blog/2017/08/22/big-data-financial-inclusion-and-privacy-for-the-poor/
[1] According to section 3(1)(ix) of the Master Direction- Non-Banking Financial Company – Account Aggregator (hereafter, NBFC-AA Master Directions), financial information (FI) is defined as, “information in respect of the following with financial information providers: a) bank deposits including fixed deposit accounts, savings deposit accounts, recurring deposit accounts and current deposit accounts, b) Deposits with NBFCs c) structured Investment Product (SIP) d) Commercial Paper (CP) e) Certificates of Deposit (CD) f) Government Securities (Tradable) g) Equity Shares h) Bonds i) Debentures j) Mutual Fund Units k) Exchange Traded Funds l) Indian Depository Receipts m) CIS (Collective Investment Schemes) units n) Alternate Investment Funds (AIF) units o) Insurance Policies p) Balances under the National Pension System (NPS) q) Units of Infrastructure Investment Trusts r) Units of Real Estate Investment Trusts s) Any other information as may be specified by the Bank for the purposes of these directions, from time to time” (Reserve Bank of India, 2016).
[2] Section 3(1)(xii) of the NBFC-AA Master Directions.
[3] Section 3(1)(xi) of the NBFC-AA Master Directions.
[4] According to the Report of the Committee on Financial Inclusion released in January 2008, identifies cost of transactions for small credit accounts as a percentage of loans (for up to INR 25,000). Broadly, some of these process steps include (i) selection of applicants, (ii) carrying out post-sanction inspections (iii) establishment costs (iv) documentation costs etc. The transaction cost of credit as a percentage of the loan amount is found to be 12.95% and 8.62% in observations from Central Bank of India and ICICI Bank respectively (C. Rangarajan Committee on Financial Inclusion, 2008).
[5] Immediate gratification bias is closely related to the concept of Hyperbolic Discounting but differs slightly. Hyperbolic discounting discounts utilities from future periods more heavily the further away the period is, while immediate gratification bias states that individuals disproportionately overvalue the present period and all future periods are discounted uniformly.
The TLF Newsletter: Issue 5
Welcome to our fortnightly newsletter, where our Editors put together handpicked stories from the world of tech law! You can find other issues here.
RBI Releases Discussion Paper on Guidelines for Payment Gateways and Payment Aggregators
The RBI on 17th September released a discussion paper on comprehensive guidelines for the activities of payment aggregators and payment gateway providers. It was acknowledged that payment aggregators and payment gateways form a crucial link in the flow of transactions and therefore need to be regulated. The RBI has suggested that these entities be governed by the Payment and Settlement Systems Act, 2007 which requires all ‘payment systems’ (as defined in the Act) to be authorised by the RBI. Additionally, different frameworks have been proposed for regulating payment aggregators and payment gateways, and full and direct regulation has been discussed in detail. This would entail payment aggregators and gateway services to fully comply with any guidelines issued by the RBI.
Further Reading:
- Trisha Jalan, RBI proposes regulation, licensing of payment aggregators and gateways, Medianama (18 September 2019).
- Full regulation by RBI will require payment gateways, aggregators to be incorporated in India, The Hindu (18 September 2019).
- Shayan Ghosh, RBI could bring payment aggregators, gateways under direct supervision, livemint (18 September 2019).
- RBI paper on payment gateways: Maintain Rs. 100 crore net worth or wind up operations, moneycontrol, (19 September 2019).
Twitter removes more than ten thousand accounts across six countries
Political turmoil and instability in countries is majorly aggravated by the internet and various portals online. In light of this crisis, Twitter has decided to remove more than ten thousand accounts across six countries. These accounts were found to be actively spreading unrest in countries which were already in the wrath of a political turmoil. Twitter removed more than four thousand accounts in United Arab Emirates and China, around thousand in Ecuador, and more than two hundred in Spain.
Twitter has been making an active effort since the past one year to identify and remove accounts which were agitating sensitive issues in countries facing crisis. Online portals even have the power to sway the election processes in Democratic countries. In order to curb these impending threats, Twitter has been removing certain accounts on its platform. Even though thousands of new accounts are created everyday and several people have termed this removal process as arduous and never ending, these measures have to be taken.
Further Reading:
- Trisha Jalan, Twitter removes 10,000 accounts from six countries for political information operations, Medianama (23 September 2019).
- Ingrid Lunder, Twitter discloses another 10,000 accounts suspended for fomenting political discord globally, Tech crunch (20 September, 2019).
- Abrar-al-Hiti, Twitter reportedly removes over 10,000 accounts that discourage voting, Cnet (2 November 2018).
- Christopher Bing, Twitter deletes over 10,000 accounts, that sought to discourage voting, Reuters (3 November 2018).
California passes AB 5 Bill requiring business to hire workers as employees
California legislators approved a landmark Bill on 11 September, 2019 that has the potential to disrupt the gig economy. The Bill known as “AB 5” requires companies like Uber and Lyft to treat contract workers as employees, which gives hundreds of thousands of California workers basic labour rights for the first time. Apart from its immediate impact, the move by the California legislature might set off a domino effect in New York, Washington State and Oregon, where stalled moves to reclassify drivers might witness renewed momentum. The move has been criticised by ride-hailing firms Uber and Lyft which built their businesses on inexpensive labour, and the companies have warned that recognizing drivers as employees could destroy their businesses.
Further Reading:
- Kate Conger and Noam Scheiber, California Bill Makes App-Based Companies Treat Workers as Employees, New York Times (11 September 2019).
- Manish Singh, California passes landmark bill that requires Uber and Lyft to treat their driver as employees, Tech Crunch (11 Septemer 2019).
- Rosie Perper, California passes landmark bill to treat contract workers as employees, sending it to the governor for signature, Business Insider (11 September 2019).
- Alexia Fernandez Campbell, California just passed a landmark law to regulate Uber and Lyft, Vox (18 September 2019).
- Andrew J. Hawkins, California just dropped a bomb on the gig economy — what’s next?, The Verge (September 18, 2019).
Microsoft Announces Change in Policies
Microsoft has stated that most large tech law companies, will change the manner in which content is moderated on their social media platforms, irrespective of the US Congress implementing new laws. Their Chief Legal Officer and President, Brad Smith has indicated that most companies will take initiative, irrespective of U.S. Lawmakers. The statement has been made in light of the recent Christchurch shootings which were livestreamed on most social media platforms. Further, major tech companies are responding to the changes in laws around the world. S. 230 of the U.S. Communications Decency Act, 1996 presently protects these companies from being sued on the basis of the content that is uploaded by its users. Microsoft itself has claimed that it has refused the government’s requests for facial recognition software due to the fear that it may be misused. The President of Microsoft has called for other tech companies as well to stop following the “if it’s legal, its acceptable approach” since companies need to start refusing selling their products to certain clients, irrespective of the legality of the action. However, ACLU, senior legislative council has accused Microsoft of continuing to sell software that can track faces and fear in real-time, leading to violation of privacy.
Further Reading:
- Sheila Dang, Microsoft’s Brad Smith: Tech companies won’t wait for U.S. to act on social media laws, Reuters (13 September 2019).
- Alex Hern, Microsoft boss: tech firm.s must stop ‘if it’s legal, it’s acceptable’ approach, The Guardian (20 September 2019).
- Tom Simonite, Microsoft’s Top Lawyer Becomes a Civil Rights Crusader, MIT Technology Review (8 September 2019).
- Microsoft’s Brad Smith: Tech Companies Won’t Wait For U.S. To Act On Social Media Laws, Communications Today (15 September 2019).
Sahamati: Self Regulatory Organisation for Financial Data Sharing Ecosystem
This post, authored by Mr. Srikanth Lakshmanan, is part of TLF’s blog series on Account Aggregators. Other posts can be found here.
Mr. Srikanth Lakshmanan is the founder of CashlessConsumer, a consumer collective working on digital payments to increase awareness, understand technology, represent consumers in digital payments ecosystem to voice perspectives, concerns with a goal of moving towards a fair cashless society with equitable rights.
On July 25, Nandan Nilekani launched Sahamati (सहमति, consent), a private not for profit company, that aims to be the self-regulatory organisation for the Account Aggregator (AA) ecosystem. The AA ecosystem aims to facilitate financial data sharing among financial institutions with “user consent”. Data Empowerment & Protection Architecture (DEPA) as iSpirt, the software products’ lobby behind Aadhaar and IndiaStack, calls it, will enable consumers to share data to enable further financial access to financial services. Sahamati is tasked to increase the adoption of the AA technology framework via awareness programmes and workshops with potential account aggregators (AAs), Financial Information Providers (FIPs) and Financial Information Users (FIUs). It will also evangelise the use of AA among financial institutions and users for ‘consented’ financial data sharing.
To know more about the Account Aggregator Framework, read:
BQ Explains: How ‘Sahamati’ Hopes To Make Your Financial Transactions Simpler
Exclusive: RBI issues in-principle licenses to 5 Account Aggregators
India still does not have a Privacy Law (Even the proposed law, draft of which is hard kept secret and most protected data in India today — is still only data protection law and not a privacy law). While there are other concerns around AA framework for financial data sharing such as
- Technical soundness of AA being “data blind” claim, aggregation, metadata exposure from consent data (Can metadata tell more than the data itself?)
- Business model tensions, tension between stakeholders in running the AA ecosystem in competitive environments and safeguards needed.
- What AA means to information self determination, privacy, betting on data futures?
This article will attempt to flag dangers of having a Self Regulatory Organisation in the digital financial consumer-space, particularly in under-regulated digital ecosystems.
The fin-tech ecosystem has been pitching for an industry friendly regulatory environment for a while now. Despite there being a general conducive environment due to the extreme push towards digitization / government promotion of digital payments, there are significant regulatory barriers that make it hard for fin-tech startups to enter financial services. Report of the Inter-Regulatory Working Group on Fin-tech and Digital Banking constituted by RBI preferred a disclosure based / light touch regulatory approach as opposed to full-fledged regulation for most areas of digital banking. The lack of regulatory capacity, especially in increasingly digital tech platforms coupled with industry friendly posturing of being a light touch regulatory environment is favoring towards no/self-regulatory mechanisms can often jeopardize not just consumer interest, but overall sustainable growth of the sector as they will prioritize incentives of industry participants who are members of SROs.
Self-Regulatory Organisation
A self-regulatory organisation (SRO) is an organisation that exercises some degree of regulatory authority over an industry or a profession. The regulatory authority could exist in place of government regulation, or applied in addition to government regulation. The ability of an SRO to exercise regulatory authority does not necessarily derive from a grant of authority from the government. (Wikipedia)
SRO is often seen as a ‘sub-regulator’ that reduces the burden of the regulator by performing certain regulatory roles in a limited context. It often exists as a formal/informal body consisting of industry players and sometimes also includes multi-dimensional stakeholders.
SROs in Financial Sector
SROs are not new to the financial sector in India. Despite the popular notion that financial sector is a tightly regulated sector in India, there has been a steady move towards enabling more SROs to self-regulate certain sectors/areas. There are industry bodies, associations and other bodies that are blessed by statutory, regulatory, industry and semi-regulatory powers that flow from the regulator. Here is an incomplete list of SROs/SRO-like bodies that are present in India. SROs/industry associations open a channel with regulators/policy makers to further the collective interest of members of SROs aka industry.
A common objective of industry associations that are SROs/SRO-like is to represent the voice of the industry in matters relating to regulation and having an open channel with regulator on an ongoing basis. They have a say in long-term industry policymaking, code of conduct, pricing and a range of things that impact the consumer. When the regulatory regime had started, it gave away large responsibility of supervision, governance, even policy framework to regulators taking it away from legislators. What we are seeing with increasing role of SROs is an environment where regulation is light touch, self-regulated by industry itself.
Sahamati’s role to ‘ensure success like UPI’
Sahamati aspires to be an SRO for NBFC-Account Aggregator ecosystem. The AA ecosystem consists of multiple industry players with diverse interests such as banks who will be both FIUs and FIPs, some entities (Ex:- GSTN) being only a FIP, while some other class of entities that act as only FIUs, and intermediaries that connect FIP, FIU and users — AA themselves. All of them have various interests in the ecosystem and sometimes could be contradictory/ rivalrous. As an SRO, Sahamati’s primary aim would be to make the multi-sided ecosystem successful.
If one considers data as currency, NBFC-AA ecosystem is to be viewed as a digital data payment system, where users pay personal data (which is housed by some financial entities) to other entities they would like to transact to get access to digital financial services and NBFC-AA will act as payment gateway enabling the same. Viewed in this context, Sahamati follows the Recommendation for SRO in payments sector as mentioned in RBI’s Payment and Settlement Systems Vision 2021.
5.2.1 SELF-REGULATORY ORGANISATION (SRO)
Industry self-governance is an important feature in modern economies which is also useful for industry wide smooth operations and development. With time, bodies representing interests of certain segments of PSOs have evolved and have been engaging with the regulator. There is a need for self-regulatory governance framework to foster best practices on important aspects like security, customer protection, pricing, etc. Such an organisation can be constituted to cover the entire gamut of digital PSOs, including retail products of National Payments Corporation of India (NPCI). The SRO will serve as a two-way communication channel between the players and the regulator / supervisor. The SRO will of course work towards establishing minimum benchmarks, standards and help discipline rogue behavior.
There is also reference to SRO for NBFC-AA in the Deepening Digital Payments Committee chaired by Nandan Nilekani.
Recommendation 51: Facilitate first level regulators/self-regulatory organizations. The regulator must facilitate the creation of a Self-Regulatory Organization for the recently licensed NBFC Account Aggregators. This can serve as a blueprint for more SROs that may be created later.
Besides the conflict of interest in making the proposal for an SRO in a committee on digital payments and going towards launching one, it is grossly incorrect to say NBFC-AA is regulated by FSDC.
Regulation (Lack of) in UPI/Payments, Broadly Tech
A lot of parallels were made to UPI and even the technology design does take some inspiration from the UPI ecosystem. NPCI did play an ecosystem builder role in bringing together banks, non-bank PSPs, large merchants and technology companies to make the UPI ecosystem travel. Although RBI is said to regulate payments, NPCI is largely the forum for drawing finer regulatory decisions for not just UPI, but a large section of retail payments. It is useful to know how NPCI self-regulates a large section of digital payments and RBI rarely acts beyond providing larger directions.
NPCI is a state friendly, multi payment systems operator and retail payments organization (duly captured/disproportionately influenced by some lobbies) that is jointly owned by several banks. It is primarily tasked with settlements and with operating authorized (and unauthorized) payment systems and infrastructure, which are (supposed to be) regulated by (a friendly payments regulator) RBI under the Payments and Settlements Act, 2007 (PSS2007) and Payments and Settlement Systems Regulations, 2008.
Cancellation of eSign based Mandates (Is Aadhaar the only reason ?)
The harms of this industry led regulation meant, UPI/broadly digital payments have a range of issues that include transaction failures, fraud, privacy issues that impact consumers which have not addressed as these don’t affect industry participants. The average consumer either has no recourse, or recourse mechanisms are too costly for one to undertake. It is important to note that open data too is hard to come by and only milestones with words like billions/trillions will be published and there won’t be any other quality metric that reflects the state of the system.
At its core, the AA ecosystem is a multi-player technology platform that enables data transfer between financial institutions with consent of the user. Technology platforms have been under-regulated/unregulated. UIDAI is a classic case of the operator of platform self-regulating and lesser the regulatory failures are said, the better.
When Sahamati tries to be the SRO for AA ecosystem, it might solve for the problems of industry, but issues that matter to consumers like privacy, E2E encryption, over-consenting, identity theft — will be less likely to be in focus. One must therefore supplement SROs with active, responsive regulatory mechanisms such as public consultations, grievance redress mechanisms, stronger transparency, reporting mandates for ecosystem, for an overall, fair development of ecosystem.
SROs role in policy formulation must be clearly defined and transparency and accountability provisions for SROs must be proportionally defined to create adequate checks and balances to ensure (privately funded organization of) industry solely doesn’t determine public policy. In 2009 Advisory panel on Transparency Standards did study transparency of one of the SROs, FEDAI. We need a detailed study on increasing role of SROs, particularly when SROs operate in areas of regulation that have direct consumer impact.
To quote a former Executive director, RBI
“industry organizations … can play a useful role if they increasingly assume the role of a SRO rather than a mere lobbying body for its members.”
Incomplete list of industry bodies that are lobbying groups / SROs in the financial sector in India
Banking
Indian Banks’ Association (IBA) — Voluntary Association of banks having dubious legal stature interpreting sub-ordinate legislation/regulations for banks.
Banking Codes and Standards Board of India (BCSBI) — Society for establishing banking codes and standards for fair treatment of customers.
Micro Finance Institutions Network (MFIN) and Sa-Dhan are officially recognised as SROs by the RBI. It is to be noted that their genesis came after Y.H. Malegam committee report that was formed to study Micro finance sector after a massive regulatory failure in the sector which led to suicides in Andhra Pradesh
Confederation of ATM Industry (CATMi) — Non-profit trade association representing ATM Manufacturing & Outsourcing Companies, White Label ATM Operators, Payment Services Companies, Cash Replenishment & Cash in Transit Agencies, ATM Security Services & Solutions Companies etc. in India
Foreign Exchange Dealer’s Association of India (FEDAI) — Association of banks dealing in foreign exchange in India which had previously performed SRO like function prior to deregulation.
Fixed Income MoneyMarket and Derivatives Association of India (FIMMDA), Primary Dealers association of India (PDAI) as industry associations that deal with money market and government securities respectively.
Currency Cycle Association (CCA) — SRO of Cash Logistics Companies
Finance Industry Development Council (FIDC) — SRO for RBI registered NBFC
Business Correspondent Federation of Indis (BCFI) — SRO-like body for Business Correspondent Network Managers (aka Corporate BCs)
Insurance
Insurance Information Bureau of India (IIB) — IRDA, the insurance regulator, promoted independent non-profit earning society responsible for sector–level data repository and analytics.
General Insurance Council — Legally mandated industry body of all non-life insurers that serves a link between the regulator IRDA and members of industry
Life Insurance Council — Legally mandated industry body of all life insurers that serves a link between the regulator IRDA and members of industry
Insurance brokers association of India — A non-profit company for insurance brokers that is IRDA recognised apex body of licensed Insurance Brokers
Investment
Association of Mutual Funds in India (AMFI) — Industry body of mutual funds that represents MF industry to regulator SEBI as well as government on all matters concerning the industry. Also performs SRO like role defining code of ethics, conduct of industry.
Association of National Exchanges Members of India (ANMI) — A non-profit Association of stock brokers aspiring to be an SRO.