Posted on

A Great Leap Forward to Transform Fintech: Data Empowerment

India is one of the first nations in the world to kick off Open APIs for consented financial data sharing. And nobody’s heard about it! 

Dear Kickass Financial Product Managers and (current & future) Fintech Entrepreneurs,

Amidst the usual flurry of sensational headlines, you may have missed a quiet announcement a few weeks ago that marked a monumental shift: RBI became the first central bank globally to publish a common technology framework – including detailed APIs – for consent driven data sharing across the entire financial sector (banking, insurance, securities, and investment).

This is a gamechanger for the industry.

Out of context, yet another circular with a good deal of jargon is an easy thing to gloss over. But it turns out this effort is actually a global first: although the UK, EU, Bank of International Settlements (BIS), Canada, and others have begun thoughtful public conversations around Open Banking (e.g. through that famous BIS report making the case, initiatives like PSD2, conferences, and various committees), India is one of the first nations in the world to actually make it a market reality by publishing detailed technical API standards — standards that are quickly being adopted by major banks and others across the financial sector in the country without a mandatory requirement from RBI. It’s not just the supposedly cutting edge banks of Switzerland, the UK, or the US driving fintech innovation: the top leadership of our very own SBI, ICICI, IDFC First, Bajaj Finserv, Kotak, Axis, and other household names have recognised that this is the way forward for the industry, and are breaking through new global frontiers by actually operationalising the powerful interoperable technology framework. Not only are they adopting the APIs, some are also starting to think through the new lending and advisory use cases and products made possible by the infrastructure. We think many new fintech startups should also be considering doing the same.

Why do the APIs Matter?

The world is focusing heavily on data protection and privacy – and rightly so. Securing data with appropriate access controls and preventing unauthorised third-party sharing is critical to protecting individual privacy. But to a typical MSME, portability and control of their data is just as critical as data security to empower them with access to a stream of new and tailored financial products and services. For instance, if an MSME owner could share trusted proof of their business’ regular historic GST payments or receivables invoices digitally with ease, a bank could now offer regular small ticket working capital loans based on demonstrated ability to repay (known as Flow-based lending) rather than just loans backed on collateral. Data sharing can become a tool for individual empowerment and prosperity by enabling many such innovative new solutions.

Operationalising a seamless and secure means to share data across different types of financial institutions – banks, NBFCs, mutual funds, insurance companies, or brokers – requires a common technology framework for data sharing. The published APIs create interoperable public infrastructure (a standard ‘rails’) to be used for consented data sharing across all types of financial institutions. This means that once a bank plugs into the network as an information provider, entities with new use cases can plug in as users of that data without individually integrating with each bank. Naturally, the system is designed such that data sharing occurs only with the data owner’s consent — to ensure that data is used primarily to empower the individual or small business. The MeiTY Consent Framework provides a machine-readable standard for obtaining consent to share data. This consent standard is based on an open standard, revocable, granular (referring to a specific set of data), auditable, and secure. Programmable consent of this form is the natural next innovation of the long terms and conditions legalese that apps typically rely on. RBI has also announced a new type of NBFC – the Account Aggregator – to serve as a consent dashboard for users, and seven new AAs already have in principle licenses. 

The Data Empowerment and Protection Architecture (DEPA) – in one image

In many other nations, market players have either not been able to come together to agree on a common technical standard for APIs, or have not been able to kick off its adoption across multiple competing banks at scale and speed. In countries like the US, data sharing was enabled only through proprietary rails – private companies took the initiative to design their own infrastructure for data sharing which end up restricting players like yourselves from innovating to design new products and services which could benefit people on top of the infra. 

What other kinds of innovative products and services could you build? 

Think of the impact that access to the Google Maps APIs allowed: without them, we would never have seen startups like Uber or Airbnb come to life. Building these consented data sharing APIs as a public good allows an explosion of fintech innovation, in areas such as:

  • New types of tailored flow-based lending products that provide regular, sachet sized loans to different target groups based on GST or other invoices (as described above). 
  • New personal financial management apps which could help consumers make decisions on different financial institutions and products (savings, credit, insurance, etc.) based on historic data and future projections. This could also branch out into improved wealth management or Robo advisory. 
  • Applications that allow individuals to share evidence of financial status (for instance, for a credit card or visa application) without sharing a complete detailed bank statement history of every transaction

…and many others, such as that germ of an idea that’s possibly started taking shape in your mind as you were reading.

In summary

This ecosystem is where UPI was in mid-2016: with firm, interdepartmental, and long term regulatory backing, and at the cusp of operationally taking off. UPI taught us that those who make a bet on the future, build and test early (PhonePe and Google were both at the first ever UPI hackathon!), and are agile enough to thrive in an evolving landscape end up reaping significant rewards. And just as with UPI, our financial sector regulators are to be lauded for thinking proactively and years ahead by building the right public infrastructure for data sharing. RBI’s planning for this began back in 2015! They have now passed the innovation baton onto you — and we, for one, have ambitious expectations.

With warmest regards,

iSPIRT Foundation

I’m Pinging A Few Whatsapp Groups Now, What Else Should I Send Them To Read? 

For any further questions or queries, please reach out to [email protected] and [email protected]

Posted on

Why the SC ruling on ‘Private Players’ use of Aadhaar doesn’t say what you think it does

On behalf of iSPIRT, Sanjay Jain recently published an opinion piece regarding the recent supreme court judgement on the validity of Aadhaar. In there, we stated that section 57 had been struck down, but that should still allow some usage of Aadhaar by the private sector. iSPIRT received feedback that this reading may have been incorrect and that private sector usage would not be allowed, even on a voluntary basis. So, we dug deeper, and analyzed the judgement once again, this time trying to disprove Sanjay’s earlier statement. So, here is an update:

Section 57 of the Aadhaar act has NOT been struck down!

Given the length of the judgement, our first reading – much like everyone else’s was driven by the judge’s statement and confirmed by quickly parsing the lengthy judgement. But in this careful reanalysis, we reread the majority judgement at leisure and drilled down into the language of the operative parts around Section 57. Where ambiguities still remain, we relied on the discussions leading up to the operative conclusions. Further, to recheck our conclusions, we look at some of the other operative clauses not related to Section 57. We tested our inference against everything else that has been said and we looked for inconsistencies in our reasoning.

Having done this, we are confident in our assertion that the judges did not mean to completely blockade the use of Aadhaar by private parties, but merely enforce better guardrails for the protection of user privacy. Let’s begin!

Revisiting Section 57

Here is the original text of section 57 of the Aadhaar Act

Nothing contained in this Act shall prevent the use of Aadhaar number for establishing the identity of an individual for any purpose a purpose backed by law, whether by the State or any body corporate or person, pursuant to any law, for the time being in force, or any contract to this effect:

Provided that the use of Aadhaar number under this section shall be subject to the procedure and obligations under section 8 and Chapter VI.

Now, let us simply read through the operating part of the order with reference to Section 57, ie. on page 560. This is a part of paragraph 447 (4) (h). The judges broke this into 3 sections, and mandated changes:

  1. ‘for any purpose’ to be read down to a purpose backed by law.
  2. ‘any contract’ is not permissible.
  3. ‘any body corporate or person’ – this part is struck down.

Applying these changes to the section, we get:

Nothing contained in this Act shall prevent the use of Aadhaar number for establishing the identity of an individual for any purpose a purpose backed by law, whether by the State or any body corporate or person, pursuant to any law, for the time being in force, or any contract to this effect:

Provided that the use of Aadhaar number under this section shall be subject to the procedure and obligations under section 8 and Chapter VI.

Cleaning this up, we get:

Nothing contained in this Act shall prevent the use of Aadhaar number for establishing the identity of an individual pursuant to any law, for the time being in force:

Provided that the use of Aadhaar number under this section shall be subject to the procedure and obligations under section 8 and Chapter VI.

It is our opinion that this judgement does not completely invalidate the use of Aadhaar by private players, but rather, specifically strikes down the use for “any purpose [..] by any body corporate or person [..] (under force of) any contract”. That is, it requires the use of Aadhaar be purpose-limited, legally-backed (to give user rights & protections over their data) and privacy-protecting.

As an exercise, we took the most conservative interpretation – “all private use is struck down in any form whatsoever” – and reread the entire judgement to look for clues that support this conservative view.

Instead, we found that such an extreme view is inconsistent with multiple other statements made by the judges. As an example, earlier discussions of Section 57 in the order (paragraphs 355 to 367). The conclusion there – paragraph 367 states:

The respondents may be right in their explanation that it is only an enabling provision which entitles Aadhaar number holder to take the help of Aadhaar for the purpose of establishing his/her identity. If such a person voluntary wants to offer Aadhaar card as a proof of his/her identity, there may not be a problem.

Some pointed out that this is simply a discussion and not an operative clause of the judgement. But even in the operative clauses where the linking of Aadhaar numbers with bank accounts and telecom companies is discussed, no reference was made to Section 57 and the use of Aadhaar by private banks and telcos.

The court could have simply struck down the linking specifically because most banks and telcos are private companies. Instead, they applied their mind to the orders which directed the linking as mandatory. This further points to the idea that the court does not rule out the use of Aadhaar by private players, it simply provides stricter specifications on when and how to use it.

What private players should do today

In our previous post, we had advised private companies to relook at their use of Aadhaar, and ensure that they provide choice to all users, so that they can use an appropriate identity, and also build in better exception handling procedures for all kinds of failures (including biometric failures).

Now, in addition to our previous advice, we would like to expand the advice to ask that each company look at how their specific use case draws from the respective acts, rules, regulations and procedural guidelines to ensure that these meet the tests used by this judgement. That is, they contain adequate justification and sufficient protections for the privacy of their users.

For instance, banks have been using Aadhaar eKyc to open a bank account, Aadhaar authentication to allow operation of the bank accounts, and using the Aadhaar number as a payment address to receive DBT benefits. Each of these will have to be looked at how they derive from the RBI Act and the regulations that enable these use cases.

These reviews will benefit from the following paragraphs in the judgement.

The judgement confirmed that the data collected by Aadhaar is minimal and is required to establish one’s identity.

Paragraph 193 (and repeated in other paras):

Demographic information, both mandatory and optional, and photographs does not raise a reasonable expectation of privacy under Article 21 unless under special circumstances such as juveniles in conflict of law or a rape victim’s identity. Today, all global ID cards contain photographs for identification alongwith address, date of birth, gender etc. The demographic information is readily provided by individuals globally for disclosing identity while relating with others and while seeking benefits whether provided by government or by private entities, be it registration for citizenship, elections, passports, marriage or enrolment in educational institutions …

The judgement has a lot to say in terms of what the privacy tests should be, but we would like to highlight two of those paragraphs here.

Paragraph 260:

Before we proceed to analyse the respective submissions, it has also to be kept in mind that all matters pertaining to an individual do not qualify as being an inherent part of right to privacy. Only those matters over which there would be a reasonable expectation of privacy are protected by Article 21…

Paragraph 289:

‘Reasonable Expectation’ involves two aspects. First, the individual or individuals claiming a right to privacy must establish that their claim involves a concern about some harm likely to be inflicted upon them on account of the alleged act. This concern ‘should be real and not imaginary or speculative’. Secondly, ‘the concern should not be flimsy or trivial’. It should be a reasonable concern…

Hence, the privacy risk in these use cases must be evaluated in terms of the data in the use case itself, as well as in relation to biometrics, and the Aadhaar number in the context of the user’s expectations, and real risks. Businesses must evaluate their products, and services – particularly those which use Aadhaar for privacy risks. It is helpful that the UIDAI has provided multiple means of mitigating risks, in the form of Registered Devices, Virtual Ids, Tokenization, QR Codes on eAadhaar, etc. which must be used for this purpose.

What private players should do tomorrow

In the future, the data protection bill will require a data protection impact assessment before deploying large scale systems. It is useful for businesses to bring in privacy and data protection assessments early in their development processes since it will help them better protect their users, and reduce potential liability.

This is a useful model, and we would hope that, in light of the Supreme Court judgement, the Government will introduce a similar privacy impact review, and provide a mechanism to regulate the use of Aadhaar for those use cases, where there are adequate controls to protect the privacy of the users and to prevent privacy harms. Use cases, and an audit/enforcement mechanism matter more than whether the entity is the state, a public sector organization, or a private sector organization.

Note: This is in continuation of Sanjay Jain’s previous op-ed in the Economic Times which is available here and same version on the iSPIRT blog here.

The writer is currently Partner, Bharat Innovation Fund, and Chief Innovation Officer at the Centre for Innovation, Incubation and Entrepreneurship, IIM Ahmedabad. As a volunteer at iSPIRT, he helped define many of the APIs of the India Stack.  He was the Chief Product Manager of UIDAI till 2012

(Disclaimer: This is not legal advice)