Posted on

Technical Standards of the Personal Health Records (PHR) component of the National Health Stack

We have an exciting announcement for you all today!

We are publishing a draft of the technical standards of the Personal Health Records (PHR) component of the National Health Stack (NHS)!

As a refresher, these standards govern the consented sharing of health information between Health Information Providers (HIPs) – like hospitals, pathology labs, and clinics –  and Health Information Users (HIUs) like pharmacies, medical consultants, doctors, and so on. The user’s consent to share their health data is issued via a new entity called a Health Data Consent Manager (HDCM). 

This is a big deal. The problem today is that the electronic health records listed in one app or ecosystem are not easily portable to other systems. There is no common standard that can be used to discover, share, and authenticate data between different networks or ecosystems. This means that the electronic medical records generated by users end up being confined to many different isolated silos, which can result in frustrating and complex experiences for patients wishing to manage data lying across different providers. 

With the PHR system, a user is able to generate a longitudinal view of their health data across providers. The interoperability and security of the PHR architecture allows users to securely discover, share, and manage their health data in a safe, convenient, and universally acceptable manner. For instance, a user could use a HDCM to discover their account at one hospital or diagnostic lab, and then select certain electronic reports to share with a doctor from another hospital or clinic. The flow of data would be safe, and the user would have granular control over who can access their data and for how long. Here is a small demo of the PHR system in action. 

The standards document released today offers a high level description of the architecture and flows that make this possible. You can find version 0.5 of the document embedded below.

Health Information Flows Technical Standards – V 0.5 from ProductNation/iSPIRT.

All the exciting progress we are making on this new digital public infrastructure for healthcare is all thanks to you, the community. We are grateful for your support and look forward to engaging with you further!

The blogpost is co-authored by our volunteers Aaryaman Vir, Saurabh Panjwani and Graphics by Dharmesh BA.

Posted on

Bending India’s COVID-19 Curve Through Science & Data-Led Models

Powered by data-led scientific rigor, the India COVID-19 SEIR Model delivers early infection trends for every district in India. The model is geared to help Indians from all walks of life plan life and work decisions around their region’s projected trends over the next 15-30 days. Hospitals can use the model to plan for a surge in demand for resources (beds, ICUs, ventilators); local and national level leaders across private and public sectors can use the model to decide how best to contain the spread of the disease and re-open safely. Epidemiologists can use the model to define how different behavioural and environmental factors affect disease transmission. We introduce 3 use cases in this blog post—the first in a series aimed at promoting scientific and modelling capability. 

Wherever the Coronavirus curve has bent to our will, it has happened on the back of behaviour changes based on data-led insights. Everywhere, simple shifts in behavior—staying at home, wearing masks, sanitizing hands—have been informed by predictive models that showed us the mirror to a dystopian future if we didn’t edit our lifestyles. As a digital public good for a billion Indians, the value of the India COVID-19 SEIR Model lies in its reach and widespread use. 

Until a vaccine is developed, we have to make sense of today’s numbers in the context of all our tomorrows. Individuals, policymakers—and everyone in between—can make smarter decisions if they know the evolving shape of the outbreak, and the India COVID-19 SEIR Model aims to do just that by enabling identification of potential trends and patterns in the next 15-30 days. 

The approach taken by the model provides flexibility and utilisation from both a view of trends as core model adoption/enhancement.

We can all use it to bend India’s curve. That’s the ultimate use case, really — where the model tells us where it’s going and we, in turn, steer it in an entirely other direction. Models will change and that’s a good thing. It means we are responding. The power of models and data science in this particular moment is the ability to assist a very scientific approach to scenario planning during an ongoing pandemic.

We can turn the course of this pandemic and transform what this model tells us, every 24 hours. We are already watching the shape-shifting in real-time. It’s in your hands. Go on, try it. 

Use Cases

User — Individuals & Businesses (PDF format)

User — Scientists (PDF format)

User — Policy-Makers (PDF format)

About the contributors: The blog post is co-authored by our volunteers Yashvi Jaju, Nikhila Natarajan and Srikar V Cintalagiri

Posted on

NHS Open House Discussion #4: Doctor Registry, Enrollment APIs And PHR

On 13th June, iSPIRT hosted the fourth open house discussion on the National Health Stack (NHS). For anybody unfamiliar with the NHS, here are some introductory blog posts and videos.

In the session, our volunteer Vikram Srinivasan deep dived into the Enrollment APIs of the electronic doctor registry. These APIs are called when a new doctor is being added to the registry, or when a doctor’s information is being uploaded. 

Vikram also spoke about the attestation APIs, which come into play when an attesting institution (such as a state medical council, medical college, or hospital) confirms some data about a doctor. This is crucially important for building trust in the registry and preventing the proliferation of false profiles. With the release of these enrolment and attestation APIs, all the APIs pertaining to the electronic doctor registry are now available here.

After Vikram’s presentation, he and our other volunteer Siddharth Shetty answered some technical questions submitted by the community. Here are some of the questions they fielded:

  • Doctors have multiple identities (from different medical councils), how are these unique IDs handled by the electronic registry?
  • Can anybody access the doctor information in the registry, including phone numbers and photographs of doctors?
  • Who can healthcare companies partner with in the Health Stack Ecosystem?
  • How does the federated network architecture of the PHR system deal with downtimes, incorrect data, and other failure? Is this architecture scalable for a system with 1000s of participants?

As always, these were great questions. You can watch Sid and Vikram answer these questions and walk through their presentations below. Please keep the questions coming by sending them in through this form: https://bit.ly/NHS-QAForm.

If you would like to get involved with Health Stack, we encourage you to watch the recordings of the previous Health Stack open house discussions before reaching out.

Furthermore, if you are interested in the Health Stack and wish to build on top of it or contribute to the working groups being formed, you should reach out to [email protected]

Please note: The fifth open house on PHR Implementation was previously planned for 27th June. This has been postponed to 11:30 am on 4th July due to unavoidable circumstances.

To confirm your participation, continue to register on this form.

Posted on

NHS Open House on PHR & Doctor Registry #3: Summary And Next Steps

On 6th June, we marked the third open house discussion of the National Health Stack (NHS). At the beginning of the session, iSPIRT volunteer Sharad Sharma offered a brief recap of the NHS and painted a roadmap for future developments in this initiative (including timelines, agendas, and future open house sessions). Sharad also discussed the content of the most recent open house session, in which Kiran Anandampillai explained the concept of the electronic registry system. After reiterating the vision for the NHS and the registry system, Sharad passed the floor to iSPIRT volunteer Vikram Srinivasan to dive into the registry APIs.

As a refresher, the electronic registry system is a mechanism for managing master data about different entities in the healthcare ecosystem. In today’ session, Vikram focused on the doctor registry. As the name suggests, the doctor registry will contain information about the doctors licensed to practice in India.

The doctor registry has the following design principles:

  1. Self maintainability: Doctors should be able to enrol themselves and update their own data
  1. Non-repudiable: The data in the registry should be digitally signed by a relevant attester (such as a State Medical Council) so that it can independently be verified by anybody
  1. Layered access: There should be a clear demarcation between public and private data in the registry, with only consent-based access to private data (eg. a doctor’s name and registration status should be public, but mobile number and photo should be private)
  1. Extensible schema: The data in the public registries should be as minimal as possible, allowing private players to build their own extensions around the core schema
  1. Open APIs: The data in the registries should be available via open APIs 
  1. Incentive aligned: The registry must enable convenient use cases so that doctors have an incentive to keep it up to date (eg. doctors can use their registry profile to electronically sign prescriptions, insurance claims etc. or doctors can use their registry profile to streamline and digitize the process of renewing their medical licenses)

After discussing the design principles behind the registry, Vikram dived straight into the details of the doctor registry APIs, which can be broken into the following categories:

  1. Enrollment APIs: These APIs allow doctors to enrol in the registry and update their data
  1. Consented APIs: These APIs allow a doctor to authenticate themselves, share their data/profile, and electronically sign documents
  1. Search APIs: These APIs are used to access the registry to query a doctor’s public data or search for any other publicly available information 

After covering these topics at a high level, Vikram released the API specifications for the Consented APIs and the Search APIs. The Swagger documentation for the same can be found here. The enrollment APIs will be released during next week’s open house session.

Upon completing his walkthrough of the doctor registry APIs, Vikram handed the floor over to our volunteer Siddharth Shetty. In the beginning of his segment, Siddharth answered the community’s technical questions around the NHS. Here are the questions he answered:

  • Is it mandatory to use the Open Source Project Eka codebase that has been published for the Consent Manager, API Bridge, and Gateway? 
  • In case of the Schema Standardization, during the 1st schema-less phase, are HIPs allowed to share data formats like JPEG, PDFs etc? 
  • Can the consent manager give the health locker (as an HIU) a standing consent to keep pulling the user’s information from various HIPs on an ongoing basis i.e. bypass the consent manager for future requests
  • Can the API bridges be configured such that instead of just sending the links to the information based on a request from an HIU (health locker in this case), the information can be sent such that it can be copied into the health locker?
  • Will the consent artifacts be encrypted between parties using any asymmetric key mechanism which will be valid between the services?
  • Is there any defined/recommended timeout for the data transmission from HIU – Bridge – CM- HIP and then HIU – HIP?

These were all great questions, and hopefully Siddharth’s answers helped clarify any doubts. If anybody wishes to ask any other questions around the NHS, please send them in to [email protected] with the subject line “NHS Questions”. Siddharth will continue answering the community’s technical questions during next week’s session (business-related questions will be answered in subsequent sessions).

To close off the open house discussion, Siddharth laid out the different working groups in the NHS ecosystem. Since the NHS is an open, public ecosystem, it is crucial for industry players and interested citizens to contribute to its development and pitch in with their feedback, knowledge, and engagement. Here are the working groups that are currently being formed:

  1. Technical Architecture Group: Responsible for working on open technical problems such as circuit breaker flows and time-out mechanisms. Also responsible for extensions and changes to the tech architecture
  1. Data Dictionary Group: This working group deals with moving away from the current schema-less architecture towards a standardized data vocabulary (leveraging existing medical schema projects and also coming up with new ideas relevant to the Indian context)
  1. Pilot Group: This group is comprised of people who have already started building on the NHS components (or would like to start building on the components). 
  1. Ecosystem Incentives Group: This group is looking at the incentive structures that power the NHS ecosystem (monetary and otherwise)

Any readers who are interested in learning more or joining these working groups are invited to reach out to [email protected]. A complete recording of the 6th June’s open house discussion can be found below

During next week’s session, we will be covering the Personal Health Records system (PHR), particularly as it relates to hospitals, and we will also be diving deeper into the Doctor Registry Enrollment APIs.

Readers are advised that next week’s NHS open house discussion will take place from 11:30 am – 12:30 pm on Saturday, June 13th.

The registration form for next week’s session can be found here. 

Posted on

iSPIRT Open House Sessions on NHS: Summary & Next Steps

Yesterday afternoon, we hosted our first Open House Session in partnership with Swasth Alliance on the National Health Stack (NHS). For those unfamiliar with this infrastructure, it is helpful to picture the NHS as a multi-layer cake designed to elevate the capacity of the Indian healthcare ecosystem.

At the base layer is a set of generic building blocks. These building blocks, which include bank accounts, digital identities, and mobile numbers, form the basic rails needed to identify, transact with, and communicate with individuals and businesses. Many components of IndiaStack – such as eSign and DigiLocker – leverage and augment these building blocks. 

The next layer of the NHS is the ‘plumbing layer’. This layer contains fundamental pillars needed to enable simple, intelligent, and secure healthcare solutions. The three main pillars of the NHS plumbing layer are electronic registries, a personal health record framework, and a claims engine. A brief summary of these pillars is provided below:

  1. Electronic Registries: these registries  allow for efficient discovery and authentication of doctors, hospitals, and other healthcare providers
  2. Personal Health Records System (PHR): a system that allows individuals to enjoy a longitudinal view of all their healthcare data and exercise granular control over how this data is stored and accessed
  3. Claims Engine: a software engine that reduces the cost of processing insurance claims, enabling insurers to cover more kinds of healthcare procedures, such as preventive checkups, walk-in consultations, and other low-cost but high-value procedures that are currently excluded from Indian insurance policies

The third layer of the NHS is an augmentation layer which is intended to utilize the three pillars of the NHS to bring greater efficiency to the Indian healthcare ecosystem. The doctor: patient ratio in this country is relatively low, and cannot be changed overnight.

Having said that, increasing the efficiency of each doctor would have a similar effect to increasing this doctor: patient ratio. The augmentation layer of the NHS is designed to drive up doctor efficiency through the use of technology. Examples of this kind of technology could include a matching engine to pair patients with the most relevant doctor, or a system to help doctors securely and remotely monitor the bio-markers of their patients. Unlike the plumbing layer, the augmentation layer of the NHS is not close to completion, but we do envisage the augmentation layer playing an important role in the ascent of Indian healthcare quality. Both the plumbing layer and the augmentation layer are designed as open, standardized interfaces. These layers serve as digital public infrastructure accessible to public and private entities wishing to build atop them.

That brings us to the fourth and final layer of the NHS: the application layer. This layer comprises all the government and private sector applications that aim to serve the diverse needs of Indian patients. The first three layers of the NHS exist so that the innovators and change-makers of the fourth layer are optimally empowered to organize, access, and process the data that they need to deliver the best service to their users.

National Health Stack Overview

The first session on the NHS followed this schedule and published the entire webinar on our official Youtube channel:

  •  An introduction to iSPIRT and our values
  • An overview of the NHS
  • A deep-dive into and demonstration of the PHR pillar of the plumbing layer
  • A question-answer session with the audience

The objective of the session was to drive awareness of the NHS components, objectives, timelines, and design philosophies. We want participants from all walks of healthcare to be engaged with the NHS and take part in building it.

In keeping with this objective, we will be hosting weekly open house sessions to keep diving deeper into the National Health Stack. The next such event will take place on Saturday (30th May) at 11:30 am. The focus of this second session will be on another pillar of the plumbing layer – the electronic registry system. More specifically, the session will focus upon the doctor registry. 

Readers who wish to learn more about the NHS are encouraged to share this post and sign up now for the session below or click here.

Readers may also submit questions about the NHS to [email protected] We shall do our best to answer these questions during next Saturday’s open house discussion. 

About the Author: The post is co-authored by our volunteers Aaryaman Vir, Siddharth Shetty and Karthik K S.

Further Reading

Posted on

iSPIRT Open House Discussion on National Health Stack [Virtual]

The National Health Stack is a set of foundational building blocks that will be built as shared digital infrastructure, usable by both public sector and private sector players. 

Healthcare delivery in India faces multiple challenges today. The doctor-patient ratio in the country is extremely poor, a problem that is exacerbated by the uneven distribution of doctors in certain states and districts. Insurance penetration in India remains low, leading to out-of-pocket expenses of over 80% (something that is being addressed by the Ayushman Bharat program). Additionally, the current view on healthcare amongst citizens as well as policymakers is largely around curative care.

Preventive care, which is equally important for the health of individuals, is generally overlooked. The leapfrog we envision is that of public, precision healthcare. This means that not only would every citizen have access to affordable healthcare, but the care delivered would be holistic (as opposed to symptomatic) and preventive (and not just curative) in nature. This will require a complete redesign of operations, regulations, and incentives – a transformation that, we believe, can be enabled by the Health Stack.

iSPIRT Foundation in partnership with Swasth Alliance is hosting an Open House Discussion on the following building blocks of the Health Stack

  • Doctor Registry
    • The ability for doctors to digitally authenticate themselves and share their electronic credentials with a third-party application such as a telehealth provider
  • Personal Health Record (PHR) System
    • The ability for every Indian to be empowered with control over their health data such that they can share it with trustworthy clinical providers to access a digital service
  • Open Health Services Network 
    • A unified health services network that comprises of a common set of protocols and APIs to allow health services to be delivered seamlessly across any set of health applications, doctors, and providers. 

The virtual session will be from 11:30 AM to 1:00 PM on Saturday 23rd May.

To confirm your participation and receive the virtual link, please click here.

Recommended Reading 

Posted on

COVID-19 Relief announcement for businesses that may benefit Software product MSMEs

Finance Minister, Nirmala Sitharaman announced stimulus to help economic revival in wake of COVID-19. Out of these measure a major portion was announced for businesses in MSMEs category.

Some of the important measures announced and that may directly benefit MSMEs in Software product eco-system are as given below.

  1. Collateral free loan of Rs 3 lakh crores for MSMEs.  This is expected to enable 45+ lakh MSME units to restart work and save jobs. How and who will disburse this is yet to be announced.
  2. This is an announcement which can be used in best ways by many MSMEs. However, the ease of getting this loan will only be known once the complete process and guideline is issued.
  3. Subordinate debt provision of Rs 20,000 crore for 2 lakh stressed MSMEs.
  4. Rs 50,000 crore equity infusion via Mother fund-Daughter fund for MSMEs that are viable but need handholding. A fund of funds with corpus of Rs 10,000 crore will be set up that will help MSMEs to expand capacity and help them list on markets.
  5. Global tenders will be disallowed up to Rs 200 crore for government
  6. Statutory EPF contribution to be reduced to 10% from 12% for all organisations and their employees covered by EPFO. Government expects this to infuse Rs 6,750 crore of liquidity. This measure is temporary and will provide relief to only those who has substantial workforce in lower bracket of Salaries.
  7. TDS rates have been slashed till March 2021 i.e. for entire financial year almost by 25%. An important rate of TDS applicable here is section 194J which is reduced from 10% to 7.5%. This will just increase the liquidity available in hand of Software product companies. A full list is given in link here at Income Tax site.
  8. The Definition of MSMEs has been revised. This was long due and will help more units to take benefit.  In present definition the distinction between manufacturing & services sector MSME has been removed. The new definition will be based on below norm.
    • Micro units with investment till Rs 1 crore, turnover up to Rs 5 crore
    • Small units with investment till Rs 10 crore, turnover up to Rs 50 crore
    • Medium units with investment till Rs 20 crore, turnover up to Rs 100 crore

iSPIRT was pursuing with Govt. of India to provide incentives for MSMEs to buy from Indian Software product companies.

However, in present situation of high volatility and huge pressure from MSMEs which is a sector that is more important for revival, this has not been considered. iSPIRT will keep pursuing with MeitY and MSME ministry for creating a domestic market access.

Posted on

iSPIRT’s responses to The Ken’s questions over the last few days.

In the interest of transparency, here is our entire exchange with The Ken.

Our first email response to The Ken

Dear Sanjay and Siddharth, 

Hope you are safe and doing well. 

I’m a reporter with The Ken and I’m working on a story looking at the now pulled-back launch of Sahay on May 21 by PM Modi and the involvement of iSpirt in this project. I had some questions about the iSpirt’s roles and responsibilities with respect to Sahay and the account aggregator framework. And also examine the potential conflicts of interest it opens up. Could you help with responses by Thursday end of the day please, as this is a newsbreak.  

  1. When did iSpirt feel the need to roll out an app like Sahay, was it always part of the account-aggregator roadmap? What have been the roles and responsibilities of iSpirt to get this off the ground?
  2. Who is responsible for owning and operating Sahay when it was scheduled for launch?
  3. We understand iSpirt is conceptualizing and designing the APIs and SDKs for this. Can you confirm?
  4. Why was Juspay given the mandate to make the proof of concept this time around too given that the AA framework is something that has been in the works for over 3 years. Why not let the market players come up with such an app?
  5. With Sahay, IDFC Bank, Axis Bank, Bajaj Finserv are among the first banks to take part, but these banks are also a financial donor to iSpirt. This raises questions on what basis banks can become part of the network. Could you explain the connection here?
  6. We learnt that Setu, which is run by former iSpirt volunteers has applied for an account aggregator license. Given iSpirt’s active involvement in this project, it opens up possibilities for conflicts of interest in terms of preferential treatment when it comes to choosing an iSpirt backed AA when you evangelise the concept. Please comment on that?
  7. Setu is funded by Sanjay Jain-founded Bharat Innovation Fund (BIF). By virtue of being an iSpirt member, Jain’s visibility and roadmap of iSpirt’s projects allow funds like the BIF to back the right horses. This again brings up questions of conflict of interest. Can you comment on this, please? 


Thanks in advance. 

Dear Arundhati,

Thank you for reaching out to us. 

To help you understand iSpirt’s roles and responsibilities with respect to Sahay and the account aggregator framework and to equip you to examine potential conflicts of interest you think it opens up, let me first explain the iSPIRT model as described here: iSPIRT Playgrounds coda. This document sets context for our answers, and many of your questions can be answered by referencing this code. It lays out in detail iSPIRT’s design for working on hard societal problems of India and how we engage with the market and the government actors in that journey.

Now to answer your questions:

1.     When did iSpirt feel the need to roll out an app like Sahay, was it always part of the account-aggregator roadmap? What have been the roles and responsibilities of iSpirt to get this off the ground?.

The idea behind Project Sahay is nearly as old as iSPIRT itself. This is one of our earliest depictions of the idea of a credit marketplace from 2015 on the left. Over time this idea was more popularly encapsulated in the “Rajni” use case depicted on the right.  Despite our evangelism, in the 6 years since this slide was made, no market player has built something like Sahay (Referring to your Q4 here).

When the economic slowdown hit in August of last year, our conviction was that the need for cash flow lending was urgent. Since a credit marketplace needs many moving parts to work well, it would require many market and government participants to accelerate their plans as well. The UK Sinha Committee on MSMEs had done the important groundwork of laying out the basic architecture of what needed to be done. 

Technical documents like API specs do not capture people’s imaginations. In our experience, the simplest and quickest way to unlock the imaginations of market participants and current and potential future entrepreneurs is to build an operational implementation and highlight its capabilities.

We have encouraged building of operational implementations in the past as well. Sometimes we build it with our partners (e.g. Credit Marketplaces), sometimes market participants do (as showcased on 25th July 2019 for Account Aggregators by Sahamati), sometimes government partners do (as NPCI did with UPI).

To this end we chose the temporary working title for an ongoing initiative “Sahay” and gave it a realistic but ambitious deadline of May 21st. The outcome of Project Sahay, was not one app, as you have assumed, but to catalyse several credit marketplaces to come up to help MSMEs access formal credit. We do not see this reflecting in any of your questions. 

Many players who did not opt in to be market partners with iSPIRT (reference 4.b “On market partners”) would opt in once they see the Wave 1 markeplace implementations in operation. We call this Wave 2, and have a model to support them as well.

2. Who is responsible for owning and operating Sahay when it was scheduled for launch?

At iSPIRT, we try to imagine a future and work backwards from there. Project Sahay helped develop early adopters of an ecosystem to come together in a coordinated way.

For cash flow lending, we needed many marketplace implementations. Each marketplace needs multiple lenders to encourage competition and not give any one player a significant head start. Unlike, say BHIM (the reference app for UPI) this marketplace needs much more groundwork and plumbing to come together in time. We used Project Sahay as a forcing function towards this aim.

Project Sahay was about many marketplace implementations. One of them would have been adopted by government partners like NPCI or PSB59. However, the marketplace implementations are still under development. So this question is premature.

Post COVID19, our view is that Cash Flow based lending as an idea itself may get pushed out by a quarter or two in the market, so our efforts on Project Sahay, will also get pushed out. We recently posted a blog (COVID19 strikes cash flow lending for small businesses in the country) about this.

3.     We understand iSpirt is conceptualizing and designing the APIs and SDKs for this. Can you confirm?

In regards to the Account Aggregator component of Project Sahay, the specifications for Financial Information Providers, Financial Information Users, and Accounts Aggregators have been designed & published by ReBIT and are publicly available here: https://api.rebit.org.in/ It was notified by RBI on November 8th 2019: https://www.rbi.org.in/Scripts/NotificationUser.aspx?Id=11729&Mode=0

In regards to the design of the APIs & SDKs for the credit marketplace component of Project Sahay, please refer to our iSPIRT Playgrounds Code (Reference 4b. “Market Partners”). 

4.     Why was Juspay given the mandate to make the proof of concept this time around too given that the AA framework is something that has been in the works for over 3 years. Why not let the market players come up with such an app?

Refer Q1, no market player had built this in 6 years.

JusPay is an active market participant in this ecosystem. They volunteered to build an open-source implementation so that many marketplaces can come up quickly. We saw no conflict, in fact we appreciate this gesture on their part to open-source.

We see the framing here includes “this time around too”. If by this you mean BHIM for UPI, that was entirely a NPCI decision. We do not advise on procurement. (reference 4.c “On government partners”)

The AA framework and thinking has been around for 3 years. Sahamati (https://sahamati.org.in/) is a collective for the AA ecosystem. All  the required resources to guide new AAs to develop are available at Sahamati website.

5.     With Sahay, IDFC Bank, Axis Bank, Bajaj Finserv are among the first banks to take part, but these banks are also a financial donor to iSpirt. This raises questions on what basis banks can become part of the network. Could you explain the connection here?

We want to answer your question at two levels. First, your question implies pay-for-play. We want to categorically deny this. Please understand our donor model first. (reference 5. “How does iSPIRT make money”)

Any allegation of pay-for-play is baseless. We engage with many more market partners who are NOT donors than donors who are market players. Their donor relationship and “market partner” relationship with us are independent.

Second, in case your question here is procedural on “how can banks become part of this network”, as defined in RBI’s Master Directive of Account Aggregator: 

  • Clause 3 (1) xi – any bank, banking company, non-banking financial company, asset management company, depository, depository participant, insurance company, insurance repository, pension fund and such other entity as may be identified by the RBI for the purposes of these directions may become a Financial Information Provider (FIP). 
  • Clause 3 (1) xii – Any entity that’s registered with and regulated by any financial sector regulator can become a Financial Information User.
    • Clause 3 (1) x – “Financial Sector regulator” refers to the Reserve Bank of India, Securities and Exchange Board of India, Insurance Regulatory and Development Authority and Pension Fund Regulatory and Development Authority

Here’s a link to the FAQ on Sahamati website for you https://sahamati.org.in/faq/ that explains this deeper.

On July 25th last year,  Sahamati was launched with 5 early adopter banks who had conducted proof of concept of the Account Aggregator network. Please see here for media coverage.

6.     We learnt that Setu, which is run by former iSpirt volunteers has applied for an account aggregator license. Given iSpirt’s active involvement in this project, it opens up possibilities for conflicts of interest in terms of preferential treatment when it comes to choosing an iSpirt backed AA when you evangelise the concept. Please comment on that?

We object to use of the term “iSPIRT backed” in relation to Setu. We ‘back’ every startup that seeks to build for India. iSPIRT has no financial interests in any of these companies. Setu does not enjoy any special status.

A note on your reporting: I recommend revisiting your phrasing here and ensure you substantiate the claims you make. Our volunteers are employees of many startups and large institutions in the country. We knew this reality and designed governance structures accordingly

Please refer to our model and feel free to report on when we have departed from our stated model. Please avoid sensationalising our regular course of work, by cherry-picking two volunteers and attempting only a tenuous link.

iSPIRT enjoys the confidence of many of its market partners and government partners only because we take a ‘non interested party’ stance to all our work. We are committed to staying this way. It is an existential threat if we do not live up to this principle. So we take these allegations extremely seriously.

Therefore, if you’re going to imply we gave any preferential treatment, I hope you and your editors realise you carry the burden of proof on this allegation. We also believe that sunlight is the best disinfectant. Hence, we do not want to stop you from doing your job, we welcome the criticism. However, in exchange, we request you meet the highest standards and have credible evidence on any allegations or even insinuations you make about us.

7.     Setu is funded by Sanjay Jain-founded Bharat Innovation Fund (BIF). By virtue of being an iSpirt member, Jain’s visibility and roadmap of iSpirt’s projects allow funds like the BIF to back the right horses. This again brings up questions of conflict of interest. Can you comment on this, please? 

We have described our conflict of interest model in the iSPIRT playgrounds code (Reference 6. “How does iSPIRT protect against conflict of interest”?)

To back the right horses, VCs are meant to be on top of trends. Sanjay Jain is not on top of trends because he was a volunteer at iSPIRT Foundation. iSPIRT is on top of trends because Sanjay Jain is a volunteer. We would ask you to look at his history of work, his thoughtful and original comments on many forums (which often diverge from the iSPIRT view, specially in the last 3 years since he has transitioned into becoming a full-time VC)

Think Tanks like us put out bold visions for the country, and Sanjay Jain is not the only VC who keeps an eye on our activity. We often even invite VCs for sessions and encourage them to back all players without recommending any specific one. Most often the locus of this engagement is the public sessions we hold. Some examples:

  • 2015: Whatsapp moment of India. Nandan Nilekani presentation on the future of finance and many articles written about it
  • Startup India Launch – Jan 2016 13th. India Stack unveiled as part of official program of Digital India (Public event)
  • Cash Flow Lending – DEPA launch 2017 August – Nandan Nilekani and Siddharth Shetty Presentation at Carnegie India event
  • Public Presentations by Pramod Varma, Sharad Sharma, Nikhil Kumar on India Stack
  • Siddharth Shetty explaining AA at an event at @WeWork Bangalore
  • 2019 Sahamati Launch with a presentation by Nandan Nilekani and representatives from MeiTY, SEBI, multiple Bank CEOs, and AA entrepreneurs.
  • Sahamati conducts multiple public workshops on the AA ecosystem as published on its website and twitter accounts. 

All the Setu founders who were iSPIRT volunteers and Sanjay Jain have been subject to the prescribed process for managing conflict of interest. We stand by this and ask you once again to demonstrate greater proof than simply Sanjay Jain was once a volunteer, and is now a VC.

We want to add some more perspective on the people & organisations you’ve named:

Sanjay Jain is a beloved volunteer at iSPIRT who we think is one of the best design thinkers in the country. When he moved to BIF, iSPIRT’s Volunteer Fellows Council designed him and his activity within iSPIRT to be conflict-free. He therefore does not participate in any of the Sahay related work. 


JusPay is a supremely talented engineering company with a strong “build for India” bias. They have been market players who embrace some of our big ideas and have demonstrated willingness to pay-it-forward. We are ready to work with any such actors who share our commitment and mission towards solving for Rajni.

Setu and many other startups like them all have a grand vision for India and these are the very private innovators we help co-create public infrastructure for. The more of these there are, and the better they and their competitors innovate, India and Rajni ultimately gain. 

We trust this response gives you ample context to review and assess your allegations of conflicts of interest. You have not reached out once to clarify our plans or ambitions, except this questionnaire 30 hours before your deadline. We have answered these questions even in this aggressive timeline. A more frank and open discussion could have been easily arranged if you had reached out to us earlier, rather than at the end. Given the framing of your questions, and the tight response time you offered us, we can no longer brush this aside as simple oversight.

Your questions frame all iSPIRT engagements with the govt. and market players as potential conflicts of interest. It takes the very essence of what we do – help co-create public infrastructure for private innovation – and attempts to cast a doubtful light on it. To protect ourselves from being misquoted, we intend to publish this email exchange on our blog so people may see the whole exchange in context and decide for themselves.

Our second email response to the The Ken.

Sources allege that when iSpirt was involved in designing the APIs and SDKs for Sahay, there were no inputs taken from the market participants.  

Please refer to Q3 of your previous email. iSPIRT’s code of coordination with market participants is available here: Reference 4b. “Market Partners”)

Please understand that we first announce our vision in public. Then we co-create with partners who express conviction at an early stage. We call them early adopters or Wave 1. We work with them and iterate till we surface an MVP for wider review. At this point, the path to go live is clear, as is the ‘ownership'(reference your question #2), and it invariably involves a public review phase. After Wave 1, we work with Wave 2 participants as well for scaling adoption.

The mental model you should have for iSPIRT Vision/Wave 1/ Wave 2 is those of Alpha/closed Beta/Public beta in the technology world. This is not an uncommon practice.

I can tell you that I have personally been in multiple feedback sessions on the APIs with Wave 1 market participants. It constitutes a large part of my work. Therefore, I can categorically deny these allegations. I can understand the confusion if your sources are not from Wave 1. They are open to participate in Wave 2. Before you allege that our process is not collaborative, please clarify with your source if they are confused about Wave 1/Wave 2.

Also once iSPIRT hands over the tech platform to the operating units, who guarantees end-use limitation of data, and who is accountable for breaches? Who answers to the Data Protection Authority when it eventually comes up? Also, who will end up owning Sahay?

There will be many marketplace implementations each using common APIs and building blocks. Some of these standards will be de-jure standards (like Account Aggregators). Others, like between Banks and marketplaces will be de-facto standards. Page 125 of the UK Sinha MSME Committee Report provides details of this. Please consult this and feel free to ask further questions.

Please reach out to me at [email protected] for any questions.

Posted on

iSPIRT Playgrounds Coda

As you may have heard from us or read about in our publications, iSPIRT takes the long view on problems. We call ourselves 30 year architects for India’s hard problems. The critical insight to a 30-year journey of success is that it requires one to be able to work with and grow the ecosystem, rather than grow itself. An iSPIRT with more than 150 volunteers would collapse under its own weight. Instead we work tirelessly to build capacity in our partners and help them on their journeys. We remain committed to being in the background, taking pride in the success of our partners who are solving for India’s hard problems.

However, many people think we’re trying to square a circle here. Why would anybody, that too, folks in Tech jobs who get paid tremendously well, volunteer their time for the success of others? 

The motivation for volunteering is hard to explain to those who have not experienced the joy volunteering brings. Our story is not unique. Most famously, when the Open source movement was taking root, Microsoft’s then CEO, Steve Ballmer, called Open Source “cancer”.

We have published all of our thinking on our model as and when it crystallised. However, we realised a compendium was needed to put our answers to the most commonly expressed doubts about iSPIRT in one place. This is that compendium for our volunteers, partners, donors and beyond.

1. What is iSPIRT?

a) iSPIRT is a not-for-profit think tank, staffed mostly by volunteers from the tech world, who dedicate their time, energy and expertise towards India’s hard problems.

b) iSPIRT believes that India’s hard problems are larger than the efforts of any one market player or any one public institution or even any one think-tank like ourselves. These societal problems require a whole-of-society effort. We do our part to find market players and government entities with the conviction in this approach and help everyone work together.

c) In practical terms, this means that the government builds the digital public infrastructure, and the market participants build businesses on top of it. We support both of them with our expertise. We have iterated this model and continue to improve and refine this model.

d) To play this role we use our mission to align with the Government partners, Market partners and our own volunteers. We believe those who have seen us work up close place their trust in us to work towards our mission. Our long-term survival depends on this trust. All our actions and processes are designed to maintain this trust, and so far if we have any success at all, it can only be seen as a validation of this trust.

2. What is our volunteering model?

a) Anyone can apply to be a balloon volunteer, and we work with them to see if there is a fit.

b) The ideal qualities of a volunteer are publicly available in our Volunteering Handbook, the latest one was published in December 2017.

c) We require every volunteer to declare their conflicts, and ask them to select a pledge level. This pledge level determines their access to policy teams and information that can lead to potential conflict of interest. For every confirmed volunteer, we make available this pledge level publicly on our website.

d) We are often asked what’s in it for our volunteers. We let all our volunteers know this is “No Greed, No Glory” work. Wikipedia is maintained by thousands of volunteers, none of them get individual author credits. What volunteers get is the joy of working on challenging problems a sense of pride in building something useful for society a community of like-minded individuals who are willing to work towards things larger than themselves

e) There are not too many people who would do this for no money, but it does not take a lot of people to do what we do. All of this is given in much greater detail in our Volunteer Handbook.

3. How does iSPIRT decide the initiatives it works on?

a) We have seen success due to the quality of our work and the commitment to our mission. We only take on challenges related to societal problems where technology can make a difference.

b) Even within those problems, our expertise and focus is in solving the subclass of problems where the hard task of coordination between State and Market, between public infra and private innovation is crucial to the task at hand.

4. How does it work with State and Market partners

a) On the hard problems we select in #3 above we assemble a team of volunteers. These volunteers outline a vision for the future. We begin by sharing this vision in multiple forums and creating excitement around them. Examples of these forums are: 

  1. 2015: Whatsapp moment of India. Nandan Nilekani presentation on the future of finance and many articles written about it
  2. 2016: Startup India Launch – Jan 2016 13th. India Stack unveiled as part of official program of Digital India (Public event)
  3. 2017: Cash Flow Lending – DEPA launch 2017 August – Carnegie India Nandan Nilekani and Siddharth Shetty Presentation
  4. Many different public appearances by Pramod Varma, Sharad Sharma, Sanjay Jain, Nikhil Kumar
  5. 2019: Siddharth Shetty explaining AA at an event at @WeWork Bangalore
  6. 2019 Sahamati Launch with a presentation by Nandan Nilekani and representatives from MeiTY, SEBI, multiple Bank CEOs, and AA entrepreneurs.

b) On market partners

i. We work with any market partner who shows conviction towards the idea, and are willing to commit their own resources to take the vision forward. Previous and current partners include banks, startups, tech product and service companies. These early adopter partners form part of our Wave 1 cohort. 

ii. We dive deeper with this wave 1 cohort and iterate together to build on the “private innovation” side of the original vision with their feedback. This is developed with the mutual commitment to sharing our work in the public domain, for public use, once we have matured the idea. We work with them and iterate till we surface a MVP for wider review.

iii. At iSPIRT, we don’t like mission capture. There are no commercial arrangements between iSPIRT and any individual market participants. 

iv. We never recommend specific vendors to any of our partners.

v. New infrastructure/ new frameworks often require the creation of a new type of entity. We engage with these through domain specific organizations such as Sahamati for Account aggregators, as an example.

vi. After Wave 1 partners co-create an MVP, we open up for wider public review and participation. We make public all of our learnings to help the creation of Wave 2 of market participants.

vii. The mental model you should have for iSPIRT Vision/Wave 1/ Wave 2 is those of Alpha/closed Beta/public Beta in the tech world.

c) On government partners

i. We work together with any government partners who show conviction towards the idea, and are willing to commit their own resources to take the vision forward. Previous partners have been RBI, NPCI, MeiTY, TRAI, etc.

ii. We dive deeper with these partners and iterate together to build on the “public infrastructure” side of the original vision with their feedback. As part of the government process, many authorities have their own process to finalize documents, etc. Many of these involve publishing drafts, APIs etc. for feedback, and potential improvement from market participants. We publish the work we do together and invite public comments. Examples: UPI Payment Protocol; MeITY Electronic Consent Artefact; ReBIT Account Aggregator specifications

iii. We only advise government partners on technology standards and related expertise. 

iv. There are no commercial arrangements between iSPIRT and government partners, not even travel expenses.

v. We never recommend any specific market players for approval towards any licenses or permissions. Both iSPIRT and our partners would suffer greatly if this process was tarnished.

  1. With UPI we did not recommend any individual PSPs for inclusion in the network. This was entirely RBI and NPCI prerogative.
  2. Similarly for AA, RBI alone manages selection of AAs for approvals of licenses.

vi. We also respond to public comments wherever they are invited. The following are some examples of our transparent engagement on policy issues.

  1. iSPIRT Public Comments & Submission to Srikrishna Privacy Bill
  2. iSPIRT Public comments to TRAI Consultations
  3. Support to RBI MSME Committee Report
  4. Support to RBI Public Credit Registry Report

5. How does iSPIRT make money?

a) iSPIRT’s expenses includes a living wage for some of its full-time volunteers, travel expenses and other incidental expenses related to our events. This is still a relatively small footprint and we are able to sustain entirely on donations.

b) These donations come from both individuals and institutions who want to support iSPIRT’s long-term vision for India’s hard problems. Sometimes, donor institutions include our market partners who have seen our work up close.

c) Partnerships do not require donations. We engage with many more market partners who are NOT donors than donors who are market players.

6. How does iSPIRT protect against conflict of interest?

We see two avenues of conflict of interest, and have governance mechanisms to protect against both

a) First is Donor Capture. We try to structure donation amounts and partners such that we are not dependent on any one source of funds and can maintain independence

i. We maintain a similar separation of concerns as do many news organizations with their investors.

ii. Our volunteers may have a cursory knowledge of who our donors are. However, this knowledge makes no difference to their outcomes.

b) Second is Volunteer conflicts, where they may get unfair visibility or information to make personal gains.

i. We screen for this risk extensively in the balloon volunteering period.

ii. We have hard rules around this that are strictly enforced and constantly reminded to all our volunteers in all our meetings.

iii. For volunteers who need advice whether a potential interaction could constitute conflict we provide an easy avenue through our Volunteer Fellows Council. The council will advise on whether there is conflict and if yes, how to mitigate it.

iv. To prevent a “revolving door” situation, we require that volunteers from the policy team leaving to continue their careers in the industry undergo a “cooling-off” period.

To volunteer with us, visit: volunteers.ispirt.in

The post is authored by our core volunteers, Meghana Reddyreddy and Tanuj Bhojwani. They can be reached at [email protected] and [email protected]

Posted on

COVID19 strikes cash flow lending for small businesses in the country

Many ongoing industry efforts to bring cash flow lending to life for MSMEs are now on hiatus

COVID19 strikes cash flow lending too

At iSPIRT, with our long-cherished dream of democratising credit in this country, we advocated for and built public infrastructure to enable market players to offer cash flow based lending solutions to small businesses. 

Pre-COVID: We argued that small businesses needed this new breed of products because they were unable to access formal credit otherwise.

During-COVID: As we process, accept and adapt to our new reality as a country, we realise small businesses need something much more urgently than cash flow based solutions from the market – they need rescue and stimulus packages from the government to survive the health and economic distress brought on by COVID19. 

Post-COVID: When the lending cycle picks up again in the market (and we will watch it diligently!) we will revive our efforts to bring cash flow based lending products to the market. For now, we are putting these efforts on a hiatus. This is because we think there’s a while for “Post-COVID” to come and many uncertainties are unfolding every day. So for now, we want to wear a “During-COVID” hat for the foreseeable future. 

This is disappointing for many parallel efforts that were underway in the market

Since July last year, after the U.K. Sinha chaired expert committee on MSMEs submitted its report to the RBI, many parallel efforts including Sahay, revamping of TReDS, PSB59, etc. by different market players were underway to bring cash flow lending ideas in this report to life. iSPIRT engaged with market players to design a digital public infrastructure first approach encapsulated in Sahay. The government was supportive of all of these, highlighting the importance of MSMEs within the economy.

Cash Flow Lending – The idea whose time will come

This slow down in the momentum is obviously disheartening for many iSPIRT volunteers and to all the market players we were working with. Months of hard work may not come to life in the next quarter or two. But these same months of hard work were possible only because we saw ourselves as architects with a 10-20 year horizon to solve India’s hard problems.

Cash Flow lending is a powerful idea to democratise credit in our country. It’s time will come, and come soon. Right now, we need to pace ourselves to our new realities and revive the energy again when lending picks up in this country.

About the Author: Meghana is a core volunteer and orchestrating our efforts in Democraticising credit at iSPIRT. She can be reached at [email protected]

Posted on

The future of ‘civic’ technologies after COVID-19

In 1973, the British economist Ernst Schumacher wrote his manifesto “Small is Beautiful”, and changed the world. Schumacher’s prescription — to use technologies that were less resource-intensive, capable of generating employment, and “appropriate” to local circumstances — appealed to a Western audience that worried about feverish consumption by the ‘boomer’ generation. Silicon Valley soon seized the moment, presenting modern-day, personal computing as an alternative to the tyranny of IBM’s Big Machine. Meanwhile, in India too, the government asked citizens to embrace technologies suited to the country’s socio-economic life. Both had ulterior motives: the miniaturisation of computing was inevitable given revolutions in semiconductor technology during the sixties and seventies, and entrepreneurs in Silicon Valley expertly harvested the anti-IBM mood to offer themselves as messiahs. The government in New Delhi too was struggling to mass-produce machines, and starved of funds, so asking Indians to “make do” with appropriate technology was as much a political message as it was a nod to environmentalism.

And thus, India turned its attention to mechanising bullock carts, producing fuel from bio-waste, trapping solar energy for micro-applications, and encouraging the use of hand pumps. These were, in many respects, India’s first “civic”, or socially relevant technologies.

The “appropriate technology” movement in India had two unfortunate consequences. The first has been a celebration of jugaad, or frugal innovation. Over decades, Indian universities, businesses and inventors have pursued low-cost technologies that are clearly not scaleable but valued culturally by peers and social networks. (Sample the press coverage every year of IIT students who build ‘sustainable’ but limited-use technologies, that generate fuel from plastic or trap solar energy for irrigation pumps.) Second, the “small is beautiful” philosophy also coloured our view of “civic technologies” as those that only mobilise the citizenry, out into farms or factory floors. Whether they took the form of a hand pump, solar stove or bullock cart, these technologies did little to augment the productivity of an individual. However, they preserved the larger status quo and did not disrupt social or industrial relations as technological revolutions have historically done. 

Nevertheless, there has always been a latent demand in India for technologies that don’t just mobilise individuals but also act as “playgrounds”, creating and connecting livelihoods. When management guru Peter Drucker visited post-Emergency India in 1979, Prime Minister Morarji Desai sold him hard on “appropriate technology”. India, Drucker wrote, had switched overnight from championing big steel plants to small bullock carts. Steel created no new jobs outside the factory, and small technologies did not improve livelihoods. Instead, he argued, India ought to look at the automotive industry as an “efficient multiplier” of livelihoods: beyond the manufacturing plant, automobiles would create new sectors altogether in road building and maintenance, traffic control, dealerships, service stations and repair. Drucker also pointed to the transistor as another such technology. Above all, transistors and automobiles connected Indians to one another through information and travel. Drucker noted during his visit that the motor scooter and radio transistor were in great demand in even far-flung corners, a claim that is borne by statistics. These, then were the civic technologies that mattered, ones that created playgrounds in which many could forge their livelihoods. 

The lionisation of jugaad is an attitudinal problem, and may not change immediately. But the task of creating a new generation of civic technologies that act as playgrounds can be addressed more readily.  In fact, it is precisely during crises such as the ongoing COVID-19 pandemic that India acutely requires such platforms.


Consider the post-lockdown task of economic reconstruction in India, which requires targeted policy interventions. Currently, the Indian government is blinkered to address only two categories of actors who need economic assistance: large corporations with their bottom lines at risk, and at the micro-level, individuals whose stand to lose livelihoods. India’s banks will bail out Big Business, while government agencies will train their digital public goods — Aadhaar, UPI, eKYC etc — to offer financial assistance to individuals. This formulaic approach misses out the vast category of SMEs who employ millions, account for nearly 40% of India’s exports, pull in informal businesses into the supply chain and provide critical products to the big industries.

To be sure, the data to identify SMEs (Income Tax Returns/ GSTN/ PAN) exists, as do the digital infrastructure to effect payments and micro-loans. The funds would come not only from government coffers but also through philanthropic efforts that have gained steam in the wake of the pandemic. However, the “playground” needs to be created — a single digital platform that can provide loans, grants or subsidies to SMEs based on specific needs, whether for salaries, utilities or other loan payments. A front-end application would provide any government official information about schemes applied for, and funds disbursed to a given SME.

Civic technologies in India have long been understood to mean small-scale technologies. This is a legacy of history and politics, which policymakers have to reckon with. The civic value of technology does not lie in the extent to which it is localised, but its ability to reach the most vulnerable sections of a stratified society like India’s. The Indian government, no matter how expansive its administrative machinery is, cannot do this on its own. It has to create “playgrounds” — involving banks, cooperative societies, regulators, software developers, startups, data fiduciaries and underwriting modellers — if it intends to make digital technologies meaningful and socially relevant.  

Please Note: A version of this was first published on Business Standard on 17 April 2020

About the author: Arun Mohan Sukumar is a PhD candidate at the Fletcher School, Tufts University, and a volunteer with the non-profit think-tank, iSPIRT. He is currently based in San Francisco. His book, Midnight’s Machines: A Political History of Technology in India, was published by Penguin Random House in 2019

Posted on

The history of technology is about to change radically. India must seize the moment

There are no atheists in foxholes, and there appear to be no capitalists in a global pandemic either. The head of Honeywell’s billion-dollar GoDirect Trade platform, which uses a permission-based blockchain to buy and sell aviation parts, declared on March 20 that American corporations had a “walled-garden” approach to data. “They need to start sharing data, a huge paradigm shift”, said Lisa Butters. Only a couple of weeks ago, Honeywell had been defending the virtues of a permission-based system, saying enterprises “needed some constraints to operate in”. 

What a difference a few days can make. 

Historically, the aviation industry has been one of the most secretive among ‘Big Tech’ sectors, with its evolution tied intimately to the Second World War, and the US-Soviet Cold War rivalry that followed soon after. Concerns around China’s theft of aerospace IP was among the foremost drivers behind the Obama administration’s negotiation of the 2015 agreement with China to prohibit “economic espionage”. It is the ultimate “winner-takes-all” market — but Boeing, its lynchpin, has now approached the US government for an existential bailout. Honeywell’s call for a “paradigm shift” is proof that the sector is not thinking just in hand-to-mouth terms. The aviation sector may get a lifeline for now, but as an industry forged by a global war, it knows more than most that a transformational moment for technology is upon it, which needs to be seized. 

As the economist Branko Milanović has highlighted, the correct metaphor for the Covid-19 pandemic and ensuing crisis is not the Great Recession of 2008, but the Second World War. To win WWII, and retain its military superiority, the United States pioneered technology complexes that placed innovation at the trifecta of a university lab, government, and market. (The blueprint for this model was drawn up in 1945 by Vannevar Bush, founder of Raytheon and director of the Office for Scientific Research and Development, and presented to the US government. The document was titled, “Science: The Endless Frontier”.) This was by no means a Western endeavour alone. Several countries, including India, followed suit, trying to perfect a model of “organised science”. In India, the Council for Scientific and Industrial Research was the totem for this effort and created a centralised network of national labs. The primary difference between Western models and ones in developing countries like India was the role of the state. In the US, the state retained regulatory agency over the process of technological innovation, but gradually ceded into the background as the Boeings, Westinghouses, GEs, Lockheed Martins, and IBMs took over. In India, the state became both the regulator and purveyor of technology. 

India’s attempts to create “national champions” in frontier technologies (think Hindustan Antibiotics Ltd, Electronics Corporation of India Ltd, Defence Research and Development Organisation, etc) failed because the state could not nimbly manufacture them at scale. Even as India pursued “moonshots”, those businesses in the United States that were incubated or came of age during the Second World War began to occupy pole positions in their respective technology markets. Once those markets matured, it made little sense for America to continue creating “organized” technology complexes, although research collaborations between universities and the federal government continued through the National Science Foundation. The banyan-ization of the internet and Silicon Valley — both seeded by generous assistance from the US Department of Defence — into a market dominated by the FAANG companies affirms this shift.

In the wake of the Covid-19 pandemic, however, the tables are turning. The United States is not only shifting away from “moonshots” but also pivoting towards “playgrounds”, settling on a model that India has perfected in the last decade or so.

The United States has often sought to repurpose private technologies as public utilities at key moments in its history. Communications technology was built and moulded into a public good by the American state. It was US law that enabled patent pooling by Bell Labs in the 19th century, leading to the creation of a “great new corporate power” in telephony. A few decades into the 20th century, American laws decreed telephone companies would be “common carriers”, to prevent price and service discrimination by AT&T. Meanwhile, both railroads and telecommunications providers were recognised as “interstate” services, subject to federal regulation. This classification allowed the US government to shape the terms under which these technologies grew. IT is precisely this template that Trump has now applied to telehealth technology in the US. Tele-medicine services could not previously be offered across state lines in the US, but the US government used its emergency powers last week to dissolve those boundaries. And on March 18, President Trump invoked the Defence Production Act, legislation adopted during the Korean War and occasionally invoked by American presidents, that would help him commandeer private production of nearly everything, from essential commodities to cutting-edge technologies. 

Invoking the law is one thing, executing it is another. Rather than strong-arming businesses, the Trump administration is now trying to bring together private actors to create multiple “playgrounds” with an underlying public interest. The Coronavirus Task Force was the first of its kind. The Task Force brought together Walmart, Google, CVS, Target, Walgreens, LabCorp and Roche, among others to perform singular responsibilities aimed at tackling the coronavirus pandemic. Walmart would open its parking lots for testing, Google would create a self-testing platform online, Roche would develop kits, LabCorp would perform high-throughput testing, and so on. The COVID-19 High-Performance Computing Consortium, created on March 23, is another such playground. It includes traditional, 20th-century actors such as the national laboratories but is doubtless front-ended by Microsoft, IBM, Amazon and Google Cloud. The Consortium aims to use its high computational capacity to create rapid breakthroughs in vaccine development. Proposals have been given an outer limit of three months to deliver. 

In some respects, the United States is turning to an approach that India has advanced. To be sure, we may not currently be in a position to develop such a playground for vaccine R&D and testing at scale. But India is well-positioned to create the “digital playgrounds” that can help manage the devastating economic consequences of the Covid-19 epidemic. There is a universal acknowledgement that India’s social safety nets need to be strengthened to mitigate the fallout. One analyst recommends “a direct cash transfer of ₹3,000 a month, for six months, to the 12 crores, bottom half of all Indian households. This will cost nearly ₹2.2-lakh crore and reach 60 crore beneficiaries, covering agricultural labourers, farmers, daily wage earners, informal sector workers and others.” The same estimate suggests “a budget of ₹1.5- lakh crore for testing and treating at least 20 crore Indians through the private sector.” 

The digital public goods India has created — Aadhaar, UPI and eKYC — offer the public infrastructure upon which these targeted transfers can be made. However, cash transfers alone will not be enough: lending has to be amplified in the months to come to kickstart small and medium businesses that would have been ravaged after weeks of lockdown. India’s enervated banking sector will have meagre resources, and neither enthusiasm or infrastructure to offer unsecured loans at scale. “Playgrounds” offers private actors the opportunity to re-align their businesses towards a public goal, and for other, new businesses to come up. Take the example of Target, which is an unusual addition to the Coronavirus Task Force, but one whose infrastructure and network makes it a valuable societal player. Or Amazon Web Services in the High-Performance Computing Consortium, which has been roped in for a task that is seemingly unrelated to the overall goal of vaccine development. 

If digital playgrounds are so obvious a solution, why has India not embraced it sooner? None of this is to discount the deficit of trust between startup founders and the public sector in India. Founders are reluctant to use public infrastructure. It is the proverbial Damocles’ sword: a platform or business’ association with the public sector brings it instant legitimacy before consumers who still place a great deal of trust in the state. On the other hand, reliance on, or utilisation of public infrastructure brings with it added responsibilities that are unpredictable and politically volatile. To illustrate, one need only look at the eleventh-hour crisis of migrating UPI handles from YES Bank in the light of a moratorium imposed on the latter earlier this month. On the other hand, the government retains a strong belief that the private sector is simply incapable of providing scalable solutions. In most markets where the India government is both player and regulator, this may seem a chicken-and-egg problem, but c’est la vie.

Nevertheless, there are milestones in history where seemingly insurmountable differences dissolve to reveal a convergence of goals. India is at one such milestone. A leading American scientist and university administrator have called the pandemic a “Dunkirk moment” for his country, requiring civic action to “step up and help”. By sheer chance and fortitude, India’s digital platforms are poised to play exactly the role that small British fishing boats played in rescuing stranded countrymen on the frontline of a great war: they must re-imagine their roles as digital platforms, and align themselves to strengthen the Indian economy in the weeks to come. 

Arun Mohan Sukumar is a PhD candidate at the Fletcher School, Tufts University, and a volunteer with the non-profit think-tank, iSPIRT. His book, Midnight’s Machines: A Political History of Technology in India, was recently published by Penguin RandomHouse.

Posted on

When one door closes…

An inspiring effort in response to COVID-19

Last Tuesday, for the first time in recorded history, India pulled the emergency brakes on all of the complex interactions that make up the economy and society of 1.3 Billion Indians.

We’re going to see a lot more cascading effects of bringing almost all economic activity to a sudden and near-complete stop. Some of those effects are already visible and others will reveal themselves over time. One thing that’s easy to predict is that this disaster, like most others, will affect Bharat more than it does India.

However, at iSPIRT, we remain impatient optimists for Bharat. It does not suffice for our volunteers to simply predict the future; we want to help create it. When the lockdown hit, we could immediately see that the country’s messy supply chains would be hard-pressed to disentangle essential services from non-essential ones. On the very first day of the lockdown itself, you may have seen videos or news about the police using their lathis on innocent essential service providers like doctors.

This is undeniably tragic, but at its heart is an information and social trust issue inherent in India. When you distil the problem, it comes down to how does the administration identify those travelling for essential-services vs those who are not. Consider this, Swiggy and Zomato alone – who only work on the last mile of one category of food – claim to have a fleet of close to 500,000. For the entire supply chain, even restricted to essential items only, will require authorisations for millions of people and another few million vehicles.

So today, we’re announcing the release of an open-source tool called, ePass. ePass is a tool to help the administration issue digital lockdown passes. These e-Passes are secure and can be verified when needed. iSPIRT got this solution going from zero to launch in less than 4 days. In the following interview, Tanuj Bhojwani speaks with Sudhanshu Shekhar, who led the effort to build the tool and Kamya Chandra, who helped liaison with the Karnataka administration.

Tanuj Bhojwani: Hey Sudhanshu, let’s start with what e-Pass is?

Sudhanshu Shekar: Sure, so the objective is to make sure that those who are on the road providing essential services or regular citizens seeking them can face minimal friction from the authorities.

We imagine a simple 4-step flow

  1. Individuals, such as you or me, or businesses providing essential services, can apply for a pass.
  2. The administration sees these requests digitally, and can authorise them from the backend, either manually or via automated rules.
  3. People can download their digitally signed passes on their devices
  4. The on-ground personnel, such as the police, can verify the curfew pass is valid by scanning it.

We’ve built tools for each part of that flow.

When we started working with the administration, they gave another great suggestion. If the beat officers could provide pre-authenticated “tokens” – like a gift-code, we could make this process even more convenient for some essential service providers. For example, they could distribute tokens to all the informal businesses in a mandi in one go, helping bring the supply-chain back online that much faster.

Tanuj Bhojwani: And you’ve made this open-source. How can a local administration use this?

Kamya Chandra: Everything is a configuration. The administration will have to decide who the approving authorities are. An admin dashboard allows bulk uploads, approvals, tracking statistics of issued passes, etc. It also allows them to configure timings, the validity of the pass, which identity fields are required, etc.

And finally, they have to instruct their beat officers to download the verification app and use it.

Tanuj Bhojwani: so the local government hosts this themselves?

Sudhanshu Shekar: Yes, the governments need to host this themselves, either directly or through a service provider. As iSPIRT, we have only provided the code and will not be providing any managed services. Even the code is open-sourced for others to use and remix as they see fit.

Tanuj Bhojwani: iSPIRT doesn’t work with the Karnataka administration normally, so how did this all happen? How did the team come together?

Sudhanshu Shekar: Sharad called me at 8 pm Tuesday or Wednesday? Maybe it was 8 in the morning. I’m no longer sure. What’s a day anyway? *laughs*

Kamya Chandra: I want to interrupt here and say I am super impressed by Sudhanshu and the rest of the team. No matter how little sleep they got, they didn’t let it affect their judgement or mood. Their decisions were always geared towards what’s the best that’s needed.

Sudhanshu Shekar: Thank you. We’re all just doing what we can.

But basically, on Monday, as Karnataka started enforcing curfew, we realised that people are going to need curfew passes. We started kicking around the idea on Monday, but there was no team. The next night the PM announced a nation-wide lockdown. We knew this was going to be a problem everywhere.

On Wednesday, the Karnataka administration also got in touch with Sharad asking for a similar solution, and they made it clear they need the solution in two days.

Sharad called and said, “I’m going to ask you about something, and you’re going to want to do it, but be really sure and think about it. This is a hard project and has very tight timelines. Everybody will understand if you say no”.

Sharad was right, I did want to do it, so I said yes and immediately got to work. I reached out to several friends and iSPIRT volunteers for help and a few – namely Mayank, Manish, Vibhav, Mohit and Ashok – agreed to help. It was easy to convince everybody, given the importance of fighting COVID. Manish has a few friends in China and was very aware about the seriousness of this situation. We quickly agreed on the basic product outline and started working. Wednesday was a flurry of activity and we got frequent reviews done with the Administration.

We realised we needed an admin console for the police to manage pass issuance. None of us was really an expert in building front-end applications and therefore, I started making calls trying to find an expert. Through referrals, I managed to reach Vishwajeet at 12 pm. I spoke to him about the project, its importance and the strict timelines. I told him we’d fail without him!

Tanuj Bhojwani: So you called a guy you’ve never met and asked him to deliver a complex task, on a ridiculous deadline for no pay nor any certificate or recognition. How did he respond?

Sudhanshu Shekar: He called his office to take a holiday. Vishwajeet sat down, worked for 15 hours straight, and delivered before time!

Kamya Chandra: *laughs* I want to add that this team, which did not know each other, did sleep shifts – including Vishwajeet, who became a volunteer that afternoon. I remember Sudhanshu taking turns with the devs to sleep at night in 2-hour batches just to keep the engine going. I’d run demos with the administration for feedback in the morning, while they all got a little shut-eye. From afternoon, they’d repeat another day and night of development.

Tanuj Bhojwani: Wow, that’s a lot of effort, and what sounds like very little sleep! What was happening on the police end, Kamya? 

Kamya Chandra: Honestly, I went in with a negative impression of the police and administration – because all you see are videos of people being beaten. However, I was very impressed with the few people I was working with. They were very knowledgeable about the challenges they were going to face operationally. Also, it was obvious they were doing their best. The first call I got from them was at 11.45pm!

They made time for our demos, gave excellent, considered feedback on all of it that has definitely helped the product. For example, we added a quick and easy way to verify the ID alongside the QR, so that it can work even if the beat policeman verifying does not have a smartphone.

All of this was happening by a remote team in lockdown. I was in Delhi talking to officers in Karnataka. Other than Sudhanshu, I’ve never met any of the other volunteers! In every other organisation, this kind of a crisis response doesn’t happen as smoothly even if the team knows each other. Anywhere else, it would have been near impossible if the team didn’t know each other.

Tanuj Bhojwani: Oh! I assumed they were all from Bangalore?

Sudhanshu Shekar: No.

 Mayank is in Bundi, a small town in Rajasthan. Kamya is in Delhi. I’m in Indiranagar, Bangalore. Ashok, our design guy, is in Koramangala and Mohit – I have no idea where he stays – I have never met him *everyone laughs*

Kamya Chandra: Knowing everyone’s location is harder, we still don’t know full names! One of the volunteers who helped us test the security of the product was Sasi Ganesan. I spelt his first and last name wrong in the first email I sent to him! He still helped though. On the 4th day of working together, I needed everyone’s last names, I still only knew Sudhanshu’s and Sasi’s!

Compared to the places I’ve worked before, I was surprised to see Pramod send an email with such savage truths. That’s a great example of how radical candour works, why it is in direct opposition to corporate culture.

Tanuj Bhojwani: *laughs* What were the “savage truths” in this email?

Kamya Chandra: To be fair to Pramod, it was more surprising than savage. Pramod said DO NOT GO LIVE (in bold and underline) until security and related aspects weren’t complete. The contents weren’t particularly shocking, but that he sent it to all of us – including people he barely knew. There was no secrecy or pretending to be bigger than we are. All our failures were also publicly available to a team we’ve never worked with before or met. It’s quite a unique experience.

Sudhanshu Shekar: Yeah, we were planning on going live on Friday, and we knew we needed to do security testing before we went live. Pramod’s email was a good one, and all fair asks about security, usability and data retention. He connected us to another iSPIRT volunteer, Sasi Ganesan for help. Ten hours before the scheduled launch, Sasi wrote back with a list of tasks we must do BEFORE we go live. This Thursday night email doubled our todo list. Thankfully, we were able to pull in Bharat, Sireesha and a few others from Thoughtworks to help close these tasks But at the time it felt brutal, we realised this was going to be a very hard few hours.

Kamya Chandra: Yeah, I think this is around the time Rohit started helping us enhance our UX. To me, this email was a clear indication of the high bar every iSPIRT volunteer must meet. Tight timelines or urgent needs are not enough to excuse sloppiness. I am glad we have senior volunteers such as Pramod to keep the bar high.

Tanuj Bhojwani: But I believe this story has a twist?

Kamya Chandra: Well, we did the demos in time, and everyone seemed very impressed. Unfortunately, the Karnataka administration decided to go with someone else. Their decision to go with someone else was disappointing for us.

However, they are policymakers making scale decisions. They probably had to keep many balls in the air and have redundancy. It’s good they have backup plans for backup plans.

They handled it with grace and were very kind about it. They sent a thank you and a commendation letter to each of our volunteers. One of the senior lady officers asked me – do you only take techies? I do not have a computer science degree, but I want to volunteer!

I told her I was an economist too and that she should definitely volunteer.

Sudhanshu Shekar: For me, the toughest part was when I heard the news that our work won’t be going live on Friday like I had promised all these guys. I was really sad. For about an hour, I tried to fight the decision, but then I realised that I would have to do the difficult thing and break the bad news to a bunch of volunteers who’ve slept less than 6 hours total in the last 72 hours.

What happened next is what surprised me the most about this whole thing.

All of them – every single one – took it so well! They all said something to the effect of working on a solution with other volunteers felt better than not working on one and worrying about the lockdown.

I thought this is the end of the line, but it was they who cheered me up and suggested we should open-source it. I was hoping to tell the volunteers to get some rest. Instead, these guys were so passionate that they worked for a couple more days to complete the documentation, which is why we were able to launch ePass today!

Tanuj Bhojwani: Wow. That’s quite a lot of team-spirit for a team that has never even met! So what happens now that this is open-source? How do you expect it will get traction?

Kamya Chandra: The decision to open-source paid off! Even though Karnataka didn’t take ePass, the officers messaged their batchmates and told them about what the volunteers did.

Sudhanshu Shekar: Now, we have demos scheduled with several other state governments as well as a few national ministries. We think this could be live in at least a couple of places soon.

Tanuj Bhojwani: That sounds like a fairy tale ending. Do you have any advice for anyone who is reading this and wants to volunteer?

Kamya Chandra: I used to work at the World Bank in DC, and we were trying to implement national-level digital systems in many countries. When we had technical challenges there, I was often told to get on a video call with iSPIRT volunteers for guidance and inputs. The more I interacted with them, the more I realised there is magic here to learn from. So I gave up my diplomatic passport and got on a plane to Bangalore!

So my advice is that you should try volunteering even if you’re many, many oceans away!

Sudhanshu Shekar: *laughs* I have a more straightforward test than Kamya’s for those who want to volunteer. These are also the three reasons I volunteer.

First, Societal Impact. You feel useful because you get to work on something that genuinely helps people.

Second, exposure to a wide variety of topics – such a different set of problems – you don’t exactly stick to your lane. Hence, you also meet people with very diverse backgrounds and work experiences. Because my peers are not age-bracketed with me, I feel like there are many lessons that I usually would’ve learned in ten years of my career, I’ve learned already at iSPIRT. 

Third, you draw energy from others’ passion. It’s just amazing to go to work with people like this every day. I’ve realised iSPIRT is a self-selecting group – it’s only the people who seek to find it, find it. It is not easy to be a volunteer, because the environment is open and the volunteers are self-driven, people will clearly be able to see if you can walk the talk. When you have people respected in a system not for who they are, but what they do, it is magical for everyone.

Tanuj Bhojwani: That is very true. Thank you for the chat!

Like Sudhanshu says, Volunteering at iSPIRT is hard and definitely not for everyone. However, if one or more of these reasons resonate with you, you should read the volunteers handbook to learn more about balloon volunteering.

Posted on

Union Budget 2020: A Good Start That Needs Swift and Decisive Action


 “Words can inspire but only action creates real change.” 

Presenting the second Union Budget, the Finance Minister asserted that entrepreneurship has always been the strength of India and proposed a number of measures and policy changes to help boost the Indian startups. The Budget was a step in the right direction, but these are just baby steps for an economy that needs giant leaps to become an innovation hub. 

We are also hopeful that the investment clearance and advisory cell will go a long way in strengthening the startup environment and improve the ease of doing business within our community. The proposed 5-year deferment of tax payments on ESOPs by startup employees in the Union Budget, we believe, is a step in the right direction. However, it does not satisfactorily address the complete concerns and other pain points that have been plaguing the startup ecosystem. 

Firstly, the ESOP taxation change, in its current form, applies only to around 200 startups recognised by the IMB (Inter-Ministerial Board), thereby, severely restricting its scope. It is only fair that all DPIIT-registered startups enjoy the benefits of the proposed changes equally. Secondly, we strongly believe that ESOP taxation must be revised as per global norms, else, it would become an ineffective tool of talent acquisition and retention. 

We also require cohesive measures towards improving the ease of doing business and strengthening the overall ecosystem. To ease the working capital crunch faced by startups, a lowering of TDS rates on payments to DPIIT registered startups and MSMEs is necessary. To enable greater rupee capital participation, allowing universities and public trusts to invest in Alternative Investment Funds (AIF) will make a considerable impact. Achieving tax parity between listed and unlisted securities, which at present vary significantly, will enable startups to attract greater investments. The provision of R&D benefits for companies will help spur innovation and startup activity in India, enabling a structural shift in the economy towards building high-value capabilities. 

We believe that more cross-cutting measures across industries are necessary and so is the reduction of frictions between the businesses and government players. This will help us to cover more ground in fulfilling the mission of making India a high-value, innovation economy. 

Overall, Union Budget 2020 does reflect the Government’s keenness in improving the ease of doing business but considering that the lofty goals we have set out to achieve, good intentions and keenness do not suffice. These must be augmented with robust policy changes, as well as, swift and decisive action to strengthen and accelerate the startup ecosystem. 

India is at a crossroads and must decide how she is going to traverse the next decade and champion the change the world needs. It reminds one of Robert Frost, “Somewhere ages and ages hence:

Two roads diverged in a wood, and I—I took the one less travelled by,

And that has made all the difference”

Posted on

Union Budget 2020 – iSPIRT Recommendations

India is among the top startup ecosystems in the world with home to 50,000+ startups and 3,500+ funded startups growing at a rapid pace at 30 per cent. While the future outlook of the Indian startup ecosystem is definitely promising, further accelerated growth can happen only if the government introduces more startup-friendly policies, other than the existing support under ‘Startup India’.

With Budget 2020 less than two months away, the startup ecosystem is hoping to get a major boost with respect to the following measures:

  • Improve ease of doing business for startups.
  • Attract domestic and foreign investors.
  • Increase working capital flow for startups.

iSPIRT has made a 13-point recommendation list for Budget 2020 with respect to the above-mentioned measures:

1. Remove the TDS payment for DPIT registered Startups

Currently, payments to DPIT registered startups are subject to Tax Deduction at Source (TDS) of 10% under section 194J. It takes at least 1-2 years for startups to get refunds after filing of their returns, which blocks their working capital for that time period. 

2. Harmonise the Tax Rate and Holding Period between Listed and Unlisted Securities of Startups 

The higher holding period and higher tax rate disincentivise investments into startups from Indian sources. Globally, no such differentiation exists.

This recommendation seeks:

  • Reduction of the holding period for unlisted securities to 12 months from the current 24 months.
  • Levy of a lower tax rate of 10% on the sale of unlisted securities.
  • Removal of the “superrich” surcharge of 25%/37% on the sale of unlisted securities.

3. Change in the taxation of ESOPs for Startups:

The existing definition of Rule 3(8)(iii) of the Income Tax Rules, 1962 does not take into consideration the discrepancies in the determination of ‘Fair Market Value’.

The new recommendation seeks amendment to this rule as as per Rule 11UA(1)(c)(b), provided such fair market value shall not be less than the exercise price.”

4. Clarification on the February 19th, 2019 DPIIT circular on “Angel Tax” with regard to Form 2

This circular states that the exemption lapses in the case the startup has or will invest or conduct any of the activities below for a period of 7 years after investment, inter alia:

  • Make capital contributions to other entities, 
  • Make investments in shares and securities, 
  • Give loans and advances (except in the case of lending startups

The recommendation seeks an amendment to this notification

  • Extend the “business model” test applicable to all the other investments mentioned in Form 2 to all points mentioned therein
  • Allow Startups to make Loans and Advances in the ordinary course of business provided that the PAN of the recipient is reported
  • Allow startups to invest into shares and securities and make capital contributions provided that such downstream investments do not make further investments into any of the other points listed in Form 2

5. Allow for AIF expenses to be capitalised/passed-through

Expenses of an AIF can add up to up to 25%-30% of its corpus during the lifetime of a scheme, making a large chunk of the fund is a “dead-loss”.

The new recommendation seeks AIF expenses to be capitalised as the Cost of Acquisition or allowed to be set off against the income.

6. Classification of securities held by AIFs as Capital Assets by amending section 2(14) of the Income Tax Act, 1961.

There is still friction between the startups, investors and income tax department with respect to taxation of short-term gain from the sale of securities under AIF.

The new recommendation seeks an amendment to Section 2(14) as “any securities held by a Foreign Institutional Investor or AIF which has invested in such securities in accordance with the regulations made under the SEBI. 

7. Pass-Through Status for CAT III AIFs

Unlike CAT I and CAT II AIFs, CAT III AIFs do not have pass-through tax status, rendering their income to be taxed at the maximum marginal rate for their income earned, regardless of the tax status of the underlying investor.

The new recommendation seeks an amendment to Section 115UB and Section 10(23FBA) by including CAT III AIFs.

8. Allow Universities and Public Trusts to invest in AIFs

Currently, investments are allowed in SEBI registered Mutual Funds or notified Mutual Funds set up by a public sector bank or a public sector financial institution.

The new recommendation seeks an amendment to this section to include ‘Units of an Alternative Investment Fund registered with the Securities and Exchange Board of India”

9. Notify all SEBI registered AIFs as “long-term specified assets” under section 54EE

Section 54EE was introduced on April 1, 2016, to give capital gains exemption of Rs 50 lakhs for any gains invested into “long-term specified assets”, defined as “a unit or units, issued before the 1st day of April 2019, of such fund as may be notified by the Central Government in this behalf”

So far, the Central Government hasn’t notified any such funds, so no tax-payer has been able to avail of this benefit.

The new recommendation seeks issuance of a Central Government notification to notify all SEBI registered AIFs as “long-term specified assets” under section 54EE and announce measures to extend this to April 1, 2025.

10. Time-bound response from the Inter-Ministerial Board (IMB) and allowing all startups to reapply

The IMB has not been effective yet in timely responses to startups.

The new recommendation proposes DPIIT to issue a notification stating that:

  • IMB will respond in 60 days from the date of submission by the Startup.
  • Startups who were denied IMB recognition prior to February 19th, 2019 can re-apply for IMB recognition once again under the new criteria.

11. Exempt Software product Companies from Softex

Software product exporters are required to file SOftex form to report the inward remittance on export invoices in convertible foreign currency. However, Software products have a publicly listed MRP/List price and hence do not require any valuation.

The new recommendation seeks RBI to exempt software product companies from filing Softex and create a separate category of Purpose code for disposal of inward remittances by authorised dealers.

12. Creation of aHSN code for Software Product Startups

Under the GST regime, all IT Software has been treated as “Service”.  Yet, there exists HSN codes and SAC codes both. 

It is recommended that an HS code classification for specific categories can be issued using the last 2 digits (first 6 Digits being defined under international system). 

13. R&D Credits for Software Product Companies 

As startups and young software product companies don’t have taxable profits, they are unable to take advantage of current R&D tax benefits that involve setting off R&D expenses against taxable profits. To overcome this limitation, they should be allowed a deferred tax credit for up to 7 years after the R&D investment.

You can read about Budget Representation 2020 in detail here.