Metadata by TLF: Issue 17 (1st August to 15th August)

Posted on August 19, 2020August 18, 2020 by Tech Law Forum @ NALSAR

Welcome to our fortnightly newsletter, where our reporters Kruttika Lokesh and Dhananjay Dhonchak put together handpicked stories from the world of tech law! You can find other issues here.

SC moves to dismiss PIL implicating Jio’s liability in RCom’s AGR dues

Jio was recently made a party in a matter regarding adjusted gross revenue (AGR case) between companies in India and the Department of the Telecommunications and other telecom companies in India. The issue was regarding investigation into whether telcos like RCom, Videocon and Aircel wanted to evade paying their dues to the DoT by filing for insolvency. The DoT had decided that Jio was to be made liable for the 31000 crore AGR dues that RCom owed to the Department, since Jio was using RCom’s airwaves as evidenced by a 2016 spectrum sharing agreement. Jio sought to prove that the spectrum was simply leased and that they didn’t have any exclusive use of the spectrum. They further argued that spectrum sharing agreements do not assume a sharing of liabilities for DoT’s AGR dues.

Blockchain: Catalyzing Revolution in the Copyright Law

Posted on August 12, 2020August 11, 2020 by Tech Law Forum @ NALSAR

[This post has been authored by Ujjawal Bhargava, a fourth-year student at the Institute of Law, Nirma University, Ahmedabad.]

Introduction

Metadata by TLF: Issue 16 (15th July to 31st July)

Posted on August 7, 2020August 7, 2020 by Tech Law Forum @ NALSAR

Welcome to our fortnightly newsletter, where our reporters Kruttika Lokesh and Dhananjay Dhonchak put together handpicked stories from the world of tech law! You can find other issues here.

Union Consumer Affairs Minster issues E-Commerce Rules to shift the focus onto consumer protection

In an increasingly globalised world, major retail companies like Amazon have reached even the most inaccessible places. The consumers that are exposed to e-commerce companies can only be protected in the presence of increased accountability. The newly issued E-Commerce Rules set up a Central Consumer Protection Authority to police companies that violate consumer rights. Misleading ads and unfair trade practices are prevented as e-retailers have to mandatorily disclose return, refund, warranty, exchange, guarantee, delivery and grievance redressal details. Henceforth, prices of products cannot be manipulated to produce unreasonable profits for companies. These rules apply to retailers either registered in India or abroad.

How Facial Recognition Systems Threaten the Right to Privacy

Posted on June 27, 2020June 27, 2020 by Tech Law Forum @ NALSAR

[This post has been authored by Prajakta Pradhan, a 1st year student at Dr. Ram Manhar Lohiya National Law University (RMLNLU), Lucknow.]

Introduction

Facial recognition involves the use of face mapping techniques to identify an individual’s facial features and compares it with available databanks. The facial recognition market is expected to grow to $7.7 billion in 2022 from $4 billion in 2017. The reason for this stellar growth is the varied application of facial recognition technology in both private and public sectors, with governments of many countries using facial recognition for law enforcement and surveillance.

Post-Crypto-Writ Judgement: How(ey) to regulate the ICOs?

Posted on May 26, 2020May 29, 2020 by Tech Law Forum @ NALSAR

[This post has been authored by Harshit Goyal, currently in his 3rd year at National Law School of India University, Bangalore.]

Introduction

Metadata by TLF: Issue 11 (15th April to 31st April)

Posted on May 14, 2020May 14, 2020 by Tech Law Forum @ NALSAR

Welcome to our fortnightly newsletter, where our reporters Kruttika Lokesh and Dhananjay Dhonchak put together handpicked stories from the world of tech law! You can find other issues here.

Private firm blocked from buying “.org” domain

Metadata by TLF: Issue 8 (1st March to 15th March)

Posted on May 9, 2020May 13, 2020 by Tech Law Forum @ NALSAR

Welcome to our fortnightly newsletter, where our reporters Kruttika Lokesh and Dhananjay Dhonchak put together handpicked stories from the world of tech law! You can find other issues here.

Supreme Court quashes RBI circular and permits cryptocurrency trading

Building safe consumer data infrastructure in India: Account Aggregators in the financial sector (Part II)

Posted on December 30, 2019December 30, 2019 by Tech Law Forum @ NALSAR

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)

Posted on December 30, 2019December 30, 2019 by Tech Law Forum @ NALSAR

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.

Chance or Skill: Fantasy Sports Leagues and Gambling

Posted on December 3, 2019December 13, 2019 by Tech Law Forum @ NALSAR

This piece has been authored by Karthik Subramaniam, a second year student at NALSAR University of Law. It discusses the debate surrounding Fantasy Gaming Leagues and gambling.

Spectator sports have been popular since time immemorial. fantasy sports leagues across the world have gained huge fan bases and manage to rake in massive revenues. The National Football League (NFL), the premier American Football tournament in the United States managed to generate revenue of around 13,680 million USD in 2017, which surpasses the GDP of almost 64 countries. Many individuals see these leagues as geese that lay golden eggs, thereby, motivating them to get involved.

Sports Fantasy leagues are games in which participants accumulate points based on the statistical accomplishments of the athletes they have selected to their teams based on a draft. One of the earliest published accounts of a fantasy sports involved Oakland businessman Wilfred “Bill” Winkenbach who devised fantasy golf in the latter part of the 1950s in the United States.With sports leagues such as the National Football League (NFL), the National Basketball Association (NBA), Major League Soccer (MLS), Major League Baseball (MLB) and the National Hockey League (NHL) present in North America, Fantasy Sports Leagues boasted almost 56.8 Million players in 2015. With people spending an estimated 11 Billion USD on online fantasy leagues in 2013, the need for regulations in the area becomes all the more important. The spending of so much money on a game where the pay-outs are highly uncertain draws a very fine line between such spending and the illegal act of gambling.

The Unlawful Internet Gambling Enforcement Act of 2006(UIGEA) is a legislation in the United States that regulates online gambling and ensures the protection of individuals operating in this rapidly booming field. The UIGEA prohibits gambling businesses from knowingly accepting payments in connection with the participation of another person in a bet or wager that involves the use of the Internet and that is unlawful under any federal or state law. The presence of this legislation has made gambling over the internet illegal. In fact, betting on sports is illegal in all American states apart from Nevada. The reason fantasy football and other such fantasy sports fall outside the ambit of being a gamble or wager is due to the UIGEA. The legislation says that games of “skill” played for a certain reward (money in most cases) can be permitted to continue online, while games that involve an element of “chance” cannot. UIGEA includes a specific exemption for fantasy sports from being considered as gambling, provided that they meet three essential requirements: 1) The value of the prize involved is entirely independent of the number of players involved, 2) the outcome is based on the relative knowledge and skill of the participants and determined by statistical results, and 3) the outcome cannot be determined by the score of the game or based solely on one individual player’s performance in a single real sporting event. These specific exceptions were carved out to accommodate the slowly growing (in 2005) industry of online fantasy gaming. In a letter dated Feb. 1, 2006, the top lawyers from the NFL, NBA, NHL and MLB asked members of Congress to co-sponsor UIGEA, which included the fantasy carve-out. The legality of the same has allowed many states to impose taxes on fantasy gaming, allowing them to join in on the money bandwagon as well.

The Indian standpoint on this is based on the differentiation between games involving chance, and games involving skill as well, as laid out in the American context.

The Fantasy Sports League sector in India has been gaining steam for a while. Recently, in April 2019, Dream11, a Mumbai-based fantasy gaming start-up became India’s first gaming unicorn. The online gaming revenue is expected to increase from around 2,000 crores in 2014 to around 11,900 crores in 2023. The sector has undergone a massive change over the last few years with people rapidly gaining interest.

The current Indian legislations that deal with gaming in India are the Public Gambling Act, 1867(PGA) and the Prize Competitions Act, 1955(PCA). The 1867 Act, being a pre-Independence legislation offers a colonial approach to gambling, which put forward a largely anti-gambling rhetoric.[1] While this legislation looks at predominantly criminalising gambling in most cases, it also tries to distinguish between betting on a “game of chance” and staking on a “game of skill” to provide a safe harbour to activities such as wagering on horse races which were extremely popular amongst the British. While the application of this legislation was limited to the erstwhile British presidencies, the adoption of the principle espoused by the statute in most state legislations illustrates a similar mind-set showcased by Indian states.

Very much like the UIGEA, the Indian position with respect to declaring online-fantasy games as legal lies on the emphasis given on “games of skill”. While the PGA does not clearly mention specific games that constitute as games of “mere skill”, Indian courts have by and large adopted the “dominant factor test” or “predominance test” which requires the court to analyses the case and verify if chance or skill “is the dominating factor in determining the result of the game”.[2] Courts have recognised that no game is a game of pure skill alone and almost all games involve an element, albeit infinitesimal, of chance.

Based on the above, Sports Fantasy games have been exempt from the provisions of the PGA and have been declared as a legitimate business activity protected under Article 19(1)(g) of the Constitution of India. With a high potential for growth in the Indian market, foreign entities have been looking at exploring possibilities in the country. The classification of games into those involving “skill” and those involving “chance”, in India has been very vague, and often left up to the interpretation of courts. In an era of growing acceptance and evolution there is a requirement of an effective legislation specifically classifying activities as illegal gambling, separating it from those involving preponderance of skill.

[1]Vivek Benegal, Gambling Experiences, Problems and Policy in India: A Historical Analysis, in 108, =&0=&, December 2013, 2062-2067.

[2]Dr. K.R. Lakshmanan v. State of Tamil Nadu, AIR 1996 SC 1153; State of Andhra Pradesh v. K. Satyanarayana, AIR 1968 SC 825.