• Is India Stack a brand?

    Yes, India Stack is a name that is given to a collection of Open APIs. These APIs belong to various public entities in the country.

  • Is India Stack an API?

    No, it is a collection of APIs.

  • Is India Stack an Implementation?

    No - while some of the APIs assume a server side or switch implementation.

  • Which APIs are included in India Stack?

    We consider the following APIs to be a core part of the India Stack
    Aadhaar Authentication
    Aadhaar e-KYC
    Digital Locker
    Unified Payment Interface (UPI)
    Digital User Consent - still work in progress.

    We also consider the following APIs to be societal platforms built on similar principles like India Stack:
    GSTN - The Goods and Services Tax Network
    BBPS - The Bharat Bill Payment System
    ETC - Electronic Toll Collection (known under the brand FASTag)

  • Why India Stack and iSPIRT?

    The term India Stack was created by iSPIRT volunteers, and we have been evangelizing these APIs for some time now. iSPIRT has been a pro-bono partner in the development, evolution, and evangelisation of these APIs and systems. iSPIRT also manages the IndiaStack.org website, and the developer community there. iSPIRT has also managed various hackathons that use India Stack.

    Please see the section “Politics of Technology Platforms” in our 2017 iSPIRT Annual Letter to understand our motivation. India Stack work happens inside iSPIRT’s Open API Team.

  • What is the iSPIRT business model?

    iSPIRT is a volunteer driven, not for profit think tank, committed to transforming India. It is an enabler of a strong ecosystem. With India Stack we seek to provide a foundation for the development of India specific products and solutions. Hence it is a part of the iSPIRT’s mission to build India as a software product nation.

  • I am global SaaS Entrepreneur why should I care about India Stack?

    Certainly, there are many companies to whom India Stack is not relevant. But it is not about Fintech alone. India Stack is relevant to any company that wants to use a real identity system (such as Aadhaar), or digitize various workflows (through the Digital Locker, and e-Sign), or even manage payments in a smooth manner, using UPI.

  • What does Financial Inclusion mean and why is it important to iSPIRT/India?

    Financial Inclusion is the act of providing access to the formal economy, that was denied earlier. It involves making it feasible to provide services to people that was not possible.

    In the context of the India Stack, it is about bringing down the cost of serving a customer so that it is viable to also serve a customer that was not possible before. Hence, it allows banks, mutual funds, insurance companies, etc. to provide services, without a state subsidy, to the entire population.

    Here is short survey of technology platforms driving financial inclusion across the world: Why We’re Excited About Technology Stacks for Financial Inclusion

Open API Team

  • Could you please tell me more about how the Open API Team works?

    Open API team has four operating principles:
    a. Like IETF, iSPIRT is not a member organisation. Participation is “People, not companies”.
    b. “Design is a team sport”. The focus is on building a modern architecture for country-scale technology systems.
    c. iSPIRT API Teams have people who are “Competent experts that are completely free of conflicts”.
    d. Technical decisions emerge from the intense discussion. They are informed by prototypes, not theory. The motto is: “Code walks, bullshit talks”.

    Open API Team's internal process (akin to the IETF process) has four overlapping stages:
    a. Stage 1: Brainstorming - Idea to Working Draft (aka BOF to WG). Brainstorming is around a problem and may involve possible owner of the public good.
    b. Stage 2: Formalisation - Proposal (aka RFC) to Approval including Public Consultation
    c. Stage 3: Implementation - Approval to Early Adoption (aka winning implementation)
    d. Stage 4: Ecosystem Building and Incremental Improvements

    Every stage involves consultation with key stakeholders. Public consultation starts in Stage 2.

    What we have learnt is that public technology platforms must follow different design principles from private platforms. Our 2017 Annual Letter lists some of these design principles:
    1. Distribute the value created
    2. Align stakeholders to inclusive impact
    3. Act to increase platform openness
    4. Are governed by “impact” goals
    5. Focus on citizen choice
    6. Focus on transparency metrics for governance accountability
    7. Embrace disruption to find new ways to deliver societal impact

  • Can I become a member of the Open API Team?

    The Open API Team is always on the lookout for great architects. But keep in mind that teams that create a proposal are small (and multi-disciplinary and, often, include policy experts). Small teams are not unusual. After all:
    o One person - Jonathan Postel - wrote the SMTP definition RFC 821 in 1982.
    o Two people - Tim Berners-Lee and Mike Sendall - proposed HTTP in 1989.
    o Four people - Mark Handley, Henning Schulzrinne, Eve Schooler and Jonathan Rosenberg - designed SIP in 1996 (which was approved as RFC 2543 in 1999).

  • Is Open API Team evolving into India’s IETF?

    There is no direct global precedent for what iSPIRT's Open API team is doing. We are making steady progress in formalising the principles, process and governance. Keep in mind that it took IETF 18 years starting in 1968 to reach a stable state. Open API team’s journey is much faster.

  • Are the APIs in India Stack open-source or under GPL?

    These are APIs that are 'owned' by an Indian govt / public entity. These are published by them. They are not licensed under Open Source / GPL terms. Implementation/accessing these APIs are based on open criteria put up by owner entities.

    A common misconception is that a "public good" has to be open-source. A public good only has to be non-excludable and non-rivalrous. (Please note that this is not a casual definition. It was sanctified by the 2009 Economics Nobel Prize to Elinor Ostrom.) In practice, this means that a public good must have Open APIs and must not pick winners. GPS meets these criteria without being open source. Making a public good also open-source may be worth considering and merits a discussion. However, one cannot say something isn't a public good if it's not open-source.

  • What does Open API mean? Is it under GPL or Mozilla license?

    Open API means that these APIs are public, a standard criteria for accessing is published, they go through public feedback cycles during API development, ecosystem workshops and other details are available public, and pricing and other aspects are all public and common to all participants. APIs are owned and kept up to date by various Govt and Public utility entities. Anyone can provide feedback and influence the development of these. iSPIRT actively participates during development of these APIs and also evangelizes them.

  • Where can I see the source code?

    India Stack are APIs, and not Open Source products. We encourage developers to build, and open source products around these. We have one example of a QR Code generator which is available in Open Source form around UPI:
    The QR Code specification is at http://www.npci.org.in/documents/UPILinkingSpecificationsVersion10draft.pdf

    There is an open source sample code at: https://srikanthlogic.github.io/CashlessConsumer/index.html

  • What Government bodies does iSPIRT work with?

    Finance ministry, NITI Aayog , MeitY , SEBI , RBI, TRAI. Most of them informally on invitation. These bodies invite many other entities and organizations too as per their rules and needs.


  • What is UPI?

    The Unified Payment Interface is an inter-bank payment protocol. It enables instant payment from any stored value account to any other, using any allowed authentication credential, for a specific transaction context. Currently UPI is enabled on smartphones (PSP and BHIM apps) and feature phones (*99 USSD) for transferring money instantly from bank account to any other bank account. In future it may allow other stored value accounts such as wallets and and other authentication credentials such as Aadhaar and OTP.

  • What is its connection with IMPS and Rupay?

    IMPS, Rupay, and UPI are all owned / run / managed by NPCI.

  • Is NPCI a Government Body?

    No, it is a Section 8 non-profit company, owned by banks and regulated by RBI.

  • How can UPI be a public good if NPCI isn’t a Government Body?

    There is a misconception is that a "public good" has to be owned by a public-body. Ownership, like open-source, is a desirable characteristic of a public good. It is not a requirement! Public goods only need to non-excludable and non-rivalrous. Street lights are a public good. They can be publicly or privately owned. Read more here: https://en.wikipedia.org/wiki/Public_good

  • What is BHIM? What is iSPIRT’s role in BHIM?

    BHIM is a minimal payment application designed, developed, and operated by NPCI on behalf of banks. BHIM is a winning implementation of UPI’s Payment Service Provider. iSPIRT Foundation is a think tank. We provide thought leadership. We did that for BHIM PSP and app as well. However, all operational decisions, including developer selection, were done by NPCI.

  • Why has BHIM generated a buzz?

    In all public goods, winning implementations are key. Examples:
    o SMTP – Sendmail Mail Transfer Agent
    o HTTP – Mosaic browser
    o SIP – Skype client
    o DBT – LPG
    o eKYC in regulated domain – Bank opening
    o eKYC for private sector – Reliance Jio
    o UPI – BHIM app

  • There is a perception that some companies have unfair access to the UPI APIs. Is this accurate?

    All PSPs, including BHIM, have access to the same UPI protocols which connects over 50+ banks & 600M+ bank accounts. Hence this is only a perception and does not reflect ground reality.

    APIs are exposed by the banks to their partners, as long as they comply with the UPI guidelines and security requirements. NPCI, and their Steering Committee (which includes all the major banks) provide oversight to this, hence there is no question of unfair access. For eg: certain banks have even launched a developer focused program for UPI. See here: https://www.yesbank.in/digital-banking/payment-solutions/upi

    The UPI Technical Launch & Hackathon was conducted in Bangalore - Feb 2016 which saw a participation of everyone from the fintech ecosystem including the banks. NPCI gave access to the sandbox irrespective of the type or size of the entity who participated in the hackathon.

  • How does iSPIRT avoid conflicts with respect to UPI?

    iSPIRT does not decide on the future of UPI. The NPCI, under regulation by RBI, determines that. iSPIRT continues to provide support to NPCI, and evangelizes the use of UPI.

    None of our donors influence iSPIRT work. In fact, our work is bringing nonlinear change to banks. All of them realize that business-as-usual is no longer possible. For incumbent banks, this transformation is a tough challenge. We believe that since public sector banks cumulatively account for more than 30 percent of the Indian banking sector, their transformation is of national importance. Therefore we help some Govt. owned banks to navigate this change through our FTLC effort (http://pn.ispirt.in/a-leapfrog-moment-for-indian-banking/).

  • How is UPI taking away the power of incumbency if bank PSPs are the gatekeepers?

    UPI is designed to be a mass-market payment system. RBI, as the regulator of all banking & payment systems also regulates who can be a Payment System Player (PSP). Right now a PSP has to be a regulated entity of RBI - a Scheduled Commercial Bank, a Small Bank, a Payment Bank or (soon) a PPI provider. Within this set of players, UPI does take away the power of incumbency. Anyone of these players can setup PSP services, and acquire customers for payments purposes. Banks will have to work hard to convert their banking customers, or even their credit card users to use UPI. Some banks have realized that their core competence does not lie in the building of mobile applications, and have chosen to find an appropriate partner (or partners) for this purpose. This is clearly not incumbent behavior and is a signal of change. In fact, this allows our entrepreneurs to focus on the product for the customers while the regulatory obligations are fulfilled by the bank.

    This dynamic is why one can see the smaller nimbler players open out their PSP interface to partners. Today 4-5 banks have already made their APIs available and are aggressively seeking new partners for multiple use cases. As UPI adoption gains momentum, we expect more banks to join the fray. UPI is already the most open mainstream payment system when compared to payment duopolies of the West or China. The technology architecture of UPI allows all kinds of business entities to be PSPs. We hope that in the coming years, RBI will relax norms about who can be a PSP.


  • Are apps that use Aadhaar compromising privacy? The apps that are being built using India stack or will be built, are using large amounts of personal data. What happens to that data and how does one know that his/her privacy is not being breached?

    There is no large amounts of personal data being used, it is the same amount as provided when you provide a photocopy of identity documents to a service provider. The responsibility lies with the service provider, and it is governed by the agreement between them and the customer. There is additional protection from the Aadhaar Act, and the IT Act. available to the customer.

  • Is Aadhaar abetting illegal data sharing by apps and companies? These apps or companies are already sharing this data to create detailed information about an individual. Isn't data sharing illegal?

    Sharing personal identity information without consent is restricted under the IT Act, and the Aadhaar Act. If any of these companies is doing that, they would be in violation of the law

  • What is being done to ensure stronger consent norms? Consent, apparently is built in, in Aadhar or many of these applications. But, how do you know that consent is being enforced. Considering that a vast majority of the population is unaware and illiterate, consent might be misused.

    iSPIRT has consistently held that the user / consumer / resident must be actively involved in the sharing of their data, and must provide consent with full knowledge of how their data will be used. This is also specified in the Aadhaar Act.

  • Is Aadhaar system really ignorant? I've heard/read repeatedly that the Aadhar system doesn't know who is making a request for information. However, it surely must be possible to do. Someone who has access to both Aadhaar database and the bank account information can make the connection, if they decide to do so by joining the databases, right? In that case, what is preventing a fraud (or even a terrorist attack) like say – find all names of a particular community, delete all financial records or for that matter delete all digilocker and medical records. The government could be all aghast and blame it on hackers and we wouldn't know who to hold responsible.

    The UIDAI knows who sent the transaction to it - the resident / AUA / ASA involved.
    The UIDAI does not know the purpose of the transaction.
    The transaction path is traceable by the UIDAI to the organizations. Beyond that, these organizations are required to maintain records, and they do (for instance banks track the transaction details including the point of transaction).
    Hence, Aadhaar is a centralised authentication system, but it does not know too much about the transaction which it is facilitating.
    No one has access to the entire Aadhaar database, and you cannot do a join with it - you can only authenticate a person against it.

    Logically, any of the attacks that you are talking about could be done within a bank - you could look up the customer master, and decide your target accounts, and proceed to attack them. However, this is prevented by security in the banking systems, and by legal infrastructure around it to protect the banks, and the consumers. Aadhaar does not even add an attack surface for this.

    Yes, there are hacks done on various banking systems, and it is a constant challenge to fight them. It is the same law and order game being played out - just moved from the physical world to the virtual world. As you build newer systems, you have to continue to build in a way that it is secure against existing threats, and you continue to respond to newer threats as they emerge (and even proactively protect yourselves).

    We have tried to show who knows what in a transaction flow. It may be too detailed (feel free to skip)

    Detailed Example - for what the UIDAI knows, or does not know
    For instance, when you use a business correspondent to withdraw money from your bank account (assuming that your bank is different from the bank whose outlet you used), the following steps happen. Also added a who knows what in bold:
    At the BC outlet, the customer's biometrics are captured, and encrypted for sending ahead. The business correspondent app knows the BC outlet (agent), terminal id, and the customer Aadhaar.
    The BC server sends the request to the bank. The server knows the customer Aadhaar, the Agent id, terminal id.
    The bank processes the request, and sends it to NPCI. The bank knows the customer's Aadhaar, the BC, the terminal id, and the account for the money to go to.
    NPCI does an authentication with the UIDAI, on behalf of the customer's bank. NPCI is the ASA, and the customer's bank is the AUA. NPCI knows the customer Aadhaar, originating bank, destination account for the money (the agent's account) and the bank that the customer banks with.
    UIDAI authenticates the resident. They know that the request came from NPCI, the originating bank, and the resident's Aadhaar number.
    On success, NPCI knows that it succeeded, and sends the request to withdraw money to the customer's bank
    The customer's bank knows that NPCI has authenticated the customer, and does the debit. It uses the Aadhaar number, maps it to the bank account for this purpose. It knows the customer, and the destination account.
    NPCI settles the transaction. Now both banks and NPCI know the 2 bank accounts involved in the transaction.

    At the end of it, it is a transaction between 2 accounts - money moves from the customer's account to the agent's account. The agent provides cash to the customer. The banks have a log of that transaction, as does the switch. They are under an obligation to protect this information.

    A similar flow is used with a debit card at an ATM, except that the PIN is matched by the bank (and not UIDAI). The BC App is similar to the ATM in terms of what it knows and processes.

    UIDAI knows that the transaction came from NPCI, and a bank (the customer's own bank), and nothing else. But in the event of a fraud, it can trace the transaction. This obligation is there on every AUA, and hence for any Aadhaar misuse, they can track it down.

  • Is Aadhaar not susceptible to DOS attacks?

    The UIDAI does not expose auth systems to the internet, only exposing it to ASAs (multiple), who in turn expose it to AUAs. So, in the case of a denial of service attack on one or more points of exposure, UIDAI could shut those down, while keeping the rest of the country running. The only way to get UIDAI DOS'ed would be to DOS out every AUA, and ASA in the country.

    At this time, there are about 25 ASAs in the country, who connect to the UIDAI over a private network - leased lines, or MPLS.

  • In case a data breach happens, what is the recourse? Who regulates a company like Trust ID?

    We don’t want to answer a question about a specific company. However, the IT (Amendment) Act, 2008 (ITAA 2008), under section 43A and Rules under it, hold a ‘body corporate’ accountable to protect data privacy of data subject. There is additional protection under the Aadhaar act as well for data from Aadhaar.

  • Can companies steal our critical data via eKYC?

    Users provide their personal information to various companies when they provide services to them. For instance, when a person is purchasing a SIM, they provide a photocopy of their identity and address proofs to an agent of the service provider, in addition to filling in a customer acquisition form. This information makes it to the database of the service provider. The service provider has to verify the documents in some manner, and then provide the service.

    With Aadhaar eKYC, this same process can be done in a paperless manner, with no photocopies floating around. The information goes straight, with resident consent, to the database of the service provider. There is no leakage of information, and there are no photocopies of identity docs with the agent. Since the information is coming in directly, it is considered to be verified, and the service provider can provide instant service

    In both cases:

    The amount of information provided is the same. The service provider is required to comply with the requirements of the industry they are in (telecom in this case). The IT act applies to the information in the service providers databases, and the fiduciary responsibility of keeping it safe applies. However, in one, there is paper to be managed, which is costly, harder to do (it is very easy to copy a photocopy of a document). In the other, they have to further protect the data under the Aadhaar Act.

    The weakest link in the paper process is the agent, who can retain photocopies from valid customers, or can use fake copies, which are impossible to verify. A quick google search for news [SIM cards with fake documents] leads to innumerable stories. In fact, the Supreme Court recently asked the telecom operators to ensure that SIMs are issued only against verified documents, and in fact asked them to clean up even existing connections.

    Aadhaar, and biometric based eKYC eliminates the use of fake documents, and SIM cards being issued to fake users, thus securing the consumer. It also protects the company from agent fraud. It is a better solution in every respect, and improves security for the user along with convenience and cost.

    In fact, there are various news reports out recently about personal data, from these photo copies is available very cheaply. For instance on News 18 and Economic Times. eKYC prevents the proliferation of paper copies, and can help (but not solve) this issue. Digital consent is an important element of the solution as well, however a broader privacy / data protection act is required.

  • How is a consent informed if there are no options?

    Consent is informed, if the terms of what are are getting into are made available to you, and you have a choice to participate or not.

  • What is iSPIRT’s position on making Aadhaar use voluntary?

    We have to clarify what is "voluntary". There are two ways to look at this:

    #1. A resident should be able to access both subsidies and services with or without Aadhaar. Therefore a State "will have to provide delivery of services without using Aadhaar, if the resident wants it.

    #2. The government [1] has all the right to mandate 'prerequisites' for any 'entitlements/Govt services' as long as it is under the law with constitutional validity. For example, Aadhaar might be mandatory for PDS just like DL is mandated for being allowed to drive on public roads.

    [1] Govt. and UIDAI is not synonymous. IT Dept issues PAN card, Passport authority issues Passport, UIDAI issues Aadhaar. UIDAI is NOT mandating the use of Aadhaar. But, Govt can mandate for specific departments/systems under their laws/rules for their efficiency.

    iSPIRT’s position is more aligned to #2. Without SSN you can't open a bank account in the US. Without Citizen ID, many services cannot be accessed in many countries. iSPIRT has no issue if Govt. mandates Aadhaar for various services as long as the use of it is for increased efficiency and convenience. We oppose usage of Aadhaar for any purposes that harm society (mass surveillance, selective discrimination, etc.) and provide, through our upcoming Digital Consent System, audit trails for civil society watchdogs when such usage happens.

  • There was news about recent data breach and biometric data compromise. Is it true?

    No, As far as we can make out, the rumours are not true. There was NO data theft or biometrics data compromise in the replay attack of Feb ‘17​. As far as we know, it was about a developer testing the authentication system using his own biometrics through a saved image, which is prohibited by the Aadhaar Act.

    Here is what we can make out from the various reports, including the UIDAI statement:

    #1. According to news reports, one of the entities has accepted that one of their developers illegally used (his own) stored biometric to authenticate himself multiple times. The action of the developer was in violation of Aadhaar Act. Only developer’s own fingerprint was used. According to UIDAI as per this new item, no other fingerprints were used or compromised.

    #2. The motivation for this is questionable - it's like a software developer in a bank demonstrating how if he saves the PIN, he can reuse it to make transactions!

    #3. It is our understanding that UIDAI detected this illegal transaction at the backend using analytics and has asked the AUA’s to investigate the incident. Further, we have been made aware of a notification sent to all AUAs to ensure audit and strict compliance.

    #4. As per UIDAI documents, Aadhaar system several preventive mechanisms put in place which include biometric locking, two-factor authentication, registered devices, background fraud detection, etc.. Also as per authentication API and architecture, tracing and non-repudiability mechanisms using API level digital signatures, Aadhaar holder notifications, AUA level API license keys, etc. are also in place.

    #5. Furthermore, in January, UIDAI announced the rollout of registered devices. UIDAI is currently in the process of rolling out registered devices, which eliminates illegal use of biometrics such as this. According to UIDAI, starting June 1, 2017 only registered devices authentication will be allowed for conducting Aadhaar biometric authentication.

    As far as we know, neither any Aadhaar data was compromised nor anyone suffered any financial loss. Looks like someone got this particular developer to demonstrate this by breaching the law, created a video sensationalizing it as a security flaw and data breach.

    See section Replay Attack Protection on page 141 of Aadhaar Technology and Architecture document.

  • More FAQs about Aadhaar answered by UIDAI