NHS Open House on Open Health Services Network

It has been a while since our last blog on this topic. After a break of two weeks, we recently completed the fifth Open House Discussion on the National Health Stack (NHS).

In this session, held from 11:30 am-12 pm on 31st July 2020, our volunteers Sharad Sharma, Siddharth Shetty, and Dr Pramod Varma talked about the Open Health Services Network (OHSN – pronounced ‘ocean’).

As a refresher, the OHSN is the interface which governs the relationship between various market players in the healthcare ecosystem such as tele consult providers, pharmacies, or diagnostic centres on one side, and government or private apps and platforms on the other side. 

It is important for these relationships to be properly streamlined and mapped out for two reasons:

  • To establish baseline standards of care
  • And to provide auditable and transparent processes governing the transfer of data and payments

If these two objectives are met, the healthcare ecosystem as a whole can be made more accessible, secure, and efficient for both users and service providers.

This session focused upon the specific relationship between teleconsultation service providers and end-user apps (EUAs) offering teleconsultation services. 

From the perspective of OSHN, tele consultations involve three players:

  • the EUA (an end-user app selected by the user)
  • an OHSN gateway (a matching agent of sorts)
  • a telehealth service provider (‘provider’)

The process follows these steps:

  1. The user signs up on an EUA
  2. The user searches for doctors/consultations
  3. The OHSN gateway forwards this customer intent to the network of providers
  4. Providers reply with tele consultation offerings
  5. The user selects the preferred offering on the EUA interface
  6. The user then confirms the session with the provider 
  7. The user conducts a pre-consult with the provider through their EUA
  8. The consultation takes place over a medium offered by the EUA (could be SMS, chat, video, audio, VoIP)
  9. The consultation then gets completed and the doctor sends over their consultation notes and prescription from the provider app to the EUA.

All these steps are standardized so that any EUA can talk to any provider app to facilitate this flow. The API specifications for this are laid out at https://bit.ly/2X6skVV (Version 0.5). These APIs were developed in association with beckn.org, an open protocol for distributed commerce. 

To learn more about this flow and to hear Sharad, Sid, and Pramod talk about the OHSN principles and APIs, you can visit this link: https://youtu.be/kI7aQw3BUTc

In order to ask some questions which can be answered during the next Open House Session, you can visit https://bit.ly/NHS-QAForm

The next seventh Open House Discussion about the National Health Stack takes place tomorrow, Saturday, August 1st, at 11:30 am. The topic for discussion is the PHR (Personal Health Records) economic model. Interested parties can watched the recording here: https://youtu.be/Y5MIEB1TPw4

The following Open House Discussion will focus upon the OHSN technology architecture, and will take place on Saturday, 15th August at 11:30 am. The link for this session is the same as above – https://bit.ly/NHS-OHD

We hope this summary was useful and we look forward to engaging with you during the next Open House Discussion!

PS. Any parties interested in implementing or contributing to these APIs can reach out to [email protected] with the subject line “Interested in technical contributions for NHS”

NHS Open House on OHSN & PHR Business Model Postponed

The Open house session scheduled for 25th July 2020 has been postponed again. Instead, iSPIRT is hosting today’s topics separately in the coming week and we request you to please sign up again here.


New Schedule
Open House #5 – 11:30 am 31st July
– Open Health Service Network (OHSN), a layer of the health stack which will help enforce transparency, trust, and convenience in accessing health services. 

Open House #6 – 11:30 am 1st August 
– Business Model of PHR, the layer of the stack which will give patients greater control over their longitudinal health records. 


Some of the presenters joining next week are:
–  Anuraag Gutgutia, VP, WorldQuant
–  Ajit Narayanan, CTO of mFine
–  Dr Pramod Varma, Chief Architect of Aadhaar and UPI

If you have any specific questions you would like to have answered by the speakers, please send add them here: https://bit.ly/NHS-QAForm.

iSPIRT First Open House on OCEN: Summary and Next Steps

“The ‘Landline to Mobile’ leapfrog for MSME credit is here.”

On Friday evening we hosted the first open house discussion on the new Open Credit Enablement Network (OCEN). It is the next chapter of the ‘India Stack’ story, one that has provided the building blocks for public digital infrastructure in our country.

The past decade has seen us widen the net for financial inclusion in India on the back of open infrastructure for digital identity (Aadhaar, eKYC, eSign) and payments (UPI, AEPS). This year will also see the launch of the Account Aggregator framework, ushering in a new era for data governance in India. Similarly, OCEN is a new paradigm for credit that seeks to provide a common language for lenders and marketplaces to build innovative, financial credit products at scale.

The first session on OCEN covered the following topics broadly

  • By Sharad Sharma
    • An introduction to iSPIRT and our values
    • An overview of India Stack and where OCEN fits in
  • By Siddharth Shetty
    • A product demo of Sahay, the reference app for OCEN
  • By Ankit Singh
    • The reason for the credit gap in India
    • The challenges for lenders and prospective credit marketplaces
    • A reimagined credit ecosystem with OCEN and Loan Service Providers (LSPs)
    • The roles of LSPs
    • A new cash flow-based lending paradigm
    • The opportunity for market participants with OCEN
    • Release of OCEN APIs, Check them on Github: https://github.com/iSPIRT/lsp-lender-protocol-specification
  • Brief Q/A – Nipun Kohli

Why do we need this?

Access to credit is a crucial part of any flourishing economy. It is safe to say that India’s economic engine has not yet gotten out of second gear because of our inability to guide formal credit into the hands of the people and businesses that need it most. The unit economics of our current lending set-up are broken, and don’t suit the needs of either borrowers or lenders. The challenges range from high costs of customer discovery to lack of trustworthy data for underwriting, and an overall mismatch in ticket size, tenure and interest rates of loans. This has resulted in a whopping MSME credit gap of over $330 bn.

OCEN is an effort to recognise that the touchpoints for delivering financial products to individuals and MSMEs extends beyond traditional lenders. In order to democratize access to credit in India, OCEN reimagines an ecosystem where every service provider can become a Fintech-enabled credit marketplace. 

This means that whether you’re an aggregator, a payment gateway, a software provider or any other company that interfaces with consumers, you can now fill in a crucial role in India’s lending value chain. OCEN will allow you to effectively ‘plug in’ lending capabilities into your existing product or service offerings, enabling you to play the role of a Loan Service Provider (LSP) in this framework.

At one end this will simplify and reduce the cost of acquiring and analysing new customers. Working in tandem with the Account Aggregator framework it will also allow applicants to leverage different data sources so that lending can become a Cash flow based operation instead of the existing balance sheet focus. Overall these open standards will enable lenders to accelerate the disbursal of formal credit while allowing LSPs to holistically serve their existing customers.

India’s new credit rails are ready to be laid out, and we look forward to working with our spirited fintech ecosystem participants over the coming months.

We will be hosting weekly open house sessions to keep diving deeper into OCEN. The next session will focus on Open Credit Enablement Network (OCEN) APIs at 5 pm IST on 31st July 2020.

Readers who wish to learn more about OCEN are encouraged to share this blog post and sign up again for the session here: https://bit.ly/LSPOpenHouse (same embedded below)

As always, in order to successfully create a new credit ecosystem for Bharat  it will take the collaborative effort of participants from every corner of our fintech ecosystem.

If you’re interested in participating as a:

  • Loan Service Provider
  • Lender
  • Technology Service Provider

please drop us an email at [email protected]

Readers may also submit any questions about OCEN on the google form: https://bit.ly/LSPQA. We shall do our best to answer these questions during next Friday’s open house discussion.

About the Author: The post is authored by our volunteer Rahul Sanghi.

Recommended Reading

Chapter 7 and 8 in RBI UK Sinha MSME committee report: https://www.rbi.org.in/Scripts/PublicationReportDetails.aspx?UrlPage=&ID=924

Introduction to India Stack’s fourth layer – Data Empowerment & Protection Architecture: https://www.youtube.com/watch?v=mW__azI8_ow

Need to Remove SOFTEX form and TDS on Software products immediately

Subsequent to announcement of the Software product policy there was an expectation in Software product industry that Government of India will make sweeping reforms to promote this Industry. In this regard we bring to your attention two below regulations that create hurdle in ease of doing business very specifically for Software product trade.

  1. SOFTEX forms filing for international trade
  2. TDS on domestic Software product sales

We have been representing through iSPIRT time and again to removal of both these provisions to no avail. Given below is a very short representation on why they are totally unrequired regulation in today’s time.

Given below is the explanation on why these two provisions should be removed. A video recording of same is embedded below.

SOFTEX form

This form was brought in place to regulate remittances received on foreign exchange on exports, especially in early times of Indian Software industry with advent of Software Technology Park Scheme. The form governs two major aspects given below, with reasoning why this form is an obsolete a redundant mechanism.

  1. The foreign exchange remittances due against the exports invoiced has been duly received. RBI systems manage this in synch with Authorized dealers (Banks).
  2. The valuation of exports was to be certified by STPI/SEZ.

Both these provisions can be regulated through GSTN digitally in case of Software product exports and does not require an extra interference by STPI.

GSTN system should be used by RBI to govern quantum of exports: After GST has come into place, all exports are Invoiced as “Export Invoices” and can be well regulated through GST system. All exports of a Indian company can be well regulated through GSTN and Remittances matched with banking systems. Why should there be one more redundant filing for this purpose. The regular Software exporters also file a LUT with GST online.

Products do not require valuation: There in no valuation of Software product required as these are standard products with a List price / MRP based mechanism unlike Software services where there is case to case variation. Software products are traded just like any other products /goods based on MRP or volume-based discounts.

Most Software products are downloaded or used on cloud (SaaS/PaaS mode). These procurements happen online in majority of cases.

SOFTEX form puts a very unnecessary burden on Software product companies for compliance and an extra cost both on internal Administration and fees paid to STPI.

TDS on Software

In 2012 budget a provision to deduct tax at source (TDS of 10%) was brought in, mainly to check the loss of tax income when Software was procured from foreign entities. However, this was also imposed on purchases of Software from domestic Companies.

The provision is a heavy burden specially for Small and Mid-Size Software product companies as in order to effectively deal with this provisions the Software product companies are now forced to float one more entity to avoid burdening their trading channels from TDS by end buyers.

This is totally unjustified provision as no other product is subjected to TDS.

A Software product is like any other product which is produced and sold unlimited number of times.

The TDS provisions

  1. A huge friction of Digital India concept as it hinders trade of Software products Digitally
  2. Does not bring any extra tax revenue to Government

This reform is highly desired and Removal of these two provisions will greatly benefit and boost the moral of Indian Software product industry and strengthen Indian Software product eco-system, which is much desired in present global economic conditions.

We sincerely request Government of India to expeditiously act on removal and reform of these provisions. Ministry of Electronics and IT should take up leadership on this and get these bottlenecks removed.

Disclaimer: The views expressed here are not in nature of legal advice but a consensus opinion in iSPIRT internally and Software product Industry at large.

India’s New Credit Rails

India is starved of affordable, formal credit. Only 11 % of the 60 million MSMEs* have access to capital from organised lenders today. This under-penetration has shackled our economic growth and economic woes of our growth drivers, the MSMEs has only worsened in wake of the current pandemic.

There is a massive market opportunity to be tapped here that has been inhibited because the current rails for flow of capital to the untapped market are broken. 

They are broken for the lenders, to be able to reach out to these prospective borrowers. Few of the many reasons include high cost of borrower acquisition and time consuming custom third party tie-ups with loan originators.

They are broken for the marketplaces to connect their customers with lenders. The custom integrations and manual processes are costly and time consuming. The Turnaround Time to get loans deposited to customers is high and their ability to provide custom financial products quickly is restricted, owing to implementation challenges.

These broken rails needed to be fixed and the solution must solve the problem at scale.

The fix for this is a ‘Fixed Line to Mobile Telephony’ moment for ‘Credit Borrower’.

In a complete re-imagination of the credit rails, we recently witnessed a loan disbursement :

  • Instantly in borrower’s bank account
  • From application to disbursement in less than 5 minutes, with no human decisioning involved!

The next chapter in the story of ‘India Stack’ that brought this to life is the new ‘Open Credit Enablement Network’. It is a common language for lenders and marketplaces to utilise and create innovative, financial credit products at scale.

In this new credit paradigm, the marketplaces/aggregators using these APIs to embed credit offerings in their applications are called ‘Loan Service Providers’ (LSPs).

  • How are these ‘Loan Service Providers’ playing a vital role in democratizing access to credit? 
  • How are they enabling more choices, better credit products and lower interest rates for their customers?
  • Why are they exuberant about this new ‘Plug and Play’ architecture and what does it mean for their core business and driving additional revenue?
  • What do they mean when they say ‘every marketplace will now become a Fintech company’?

Some of the top lenders in the country such as State Bank of India, HDFC Bank, ICICI Bank, IDFC First Bank, Axis Bank and Bajaj Finserv have come onboard and will soon be in a state of readiness to usher in this new credit paradigm.

Just as UPI presented an opportunity for massive companies to be built and delightful customer experiences to be created, we are excited to see entrepreneurs capitalise on this massive opportunity.

We are excited to share with you :

  1. Answers to all the questions above
  2. A product demo depicting the ‘5-minute digital credit journey’ 
  3. Introduction to ‘Open Credit Enablement Network’

When: 5 pm to 6:30 pm, IST on Friday, 24th July

Where: Online virtual session on Zoom. Webinar details will be shared with the registered participants. 

To confirm your participation and receive the virtual link, please click here: https://bit.ly/LSPOpenHouse1 (same form has been embedded below)

____________________________________________________________

Recommended Reading :

Chapter 7 and 8 in RBI UK Sinha MSME committee report: https://www.rbi.org.in/Scripts/PublicationReportDetails.aspx?UrlPage=&ID=924

Introduction to India Stack’s fourth layer – Data Empowerment & Protection Architecture: https://www.youtube.com/watch?v=mW__azI8_ow

*Source – Ujjivan small finance Bank RHP & UK Sinha RBI MSME Committee Report

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

Covid19 Crisis: Sharpen the Saw with Marginal Costing

When reality changes, it’s important for the firms to acknowledge and adjust to the new situation. This is the time to remember the mantra ‘Revenue is Vanity, Profit is Sanity, Cash is Reality’.

The Covid-19 crisis is much written about, debated and analyzed. If there is one thing everyone can agree about on the future, it is that there is no spoiler out there for this suspense. The fact is that no one knows the eventual shape of the business environment after the pandemic ends. 

When revenue momentum slows down or even hits a wall as it is happening in the current scenario, costs take centre stage even as every dollar of revenue becomes even more valuable for the firms. So, enterprises need an arsenal of strategic weapons to operate and survive, maybe even thrive, in this period of dramatic uncertainty. The same old-same old, push-push methods will not move the needle of performance. 

As an entrepreneur and CEO, I have always found the theory of Marginal Costing (MC) to be practically powerful over the years. Let me tell you why.

At the best of times, MC is a useful tool for strategic and transactional decision making. In a downturn or a crisis, it is vital for entrepreneurs and business leaders to look at their businesses through the MC filter to uncover actionable insights.

Using MC-based pricing, the firm can retain valuable clients, win new deals against the competition, increase market share in a shrinking market and enhance goodwill by demonstrating dynamism in downmarket.

As the firm continues to price its products based on MC, the idea is to continually attempt to increase the price to cover the fixed costs and get above the Break-Even Point (BEP) to profitability. However, this happens opportunistically and with an improving environment. 

Pricing for outcomes is more critical during these times and playing around with your costing models can go a long way in determining the most optimal outcome-based pricing approaches. 

Steps to Get the Best Out of MC:

1. Determine bare minimum Operating level

Estimate the bare minimum operating level or fixed costs you will need to bear to stay afloat and capitalize on revenue opportunities. This is the BEP of the business. This estimate can include:

  • Facilities, machines, materials, people and overheads. 
  • All R&D expenses required to support product development
  • Necessary support staff for deployment and maintenance of products/services.

2.  Ascertain the variable costs

Identify the incremental costs involved in delivering your business solutions to fulfil contractual and reputational expectations to both existing and new customers. These costs are the variable costs in your business model. Try to maximize capacity to flexibly hire, partner or rent variable costs as needed, based on incremental revenues.

3. Distinguish between fixed costs and transactional variable costs.

Take your fixed costs at your operating level as costs for a full P&L period. Let’s say, the fiscal year. Take your variable costs as what it takes to fulfil the Revenues that you can book. Make sure you only take the direct, variable costs. Note that if Revenues less Variable costs to fulfil the revenues is zero, then you are operating at MC.

4. Sweat the IP already created.

For every rupee or dollar you earn over and above the MC, you are now contributing to absorbing the fixed costs. Do bear in mind that all historical costs of building the IP are ‘sunk’, typically to be amortized over a reasonable period. Hence, it doesn’t figure in the current level of fixed costs. The idea now is to ‘sweat’ the IP already created. 

5. Peg the base price at marginal cost.

Start at the level of marginal cost, not fully absorbed costs. Then, try and increase the price to absorb more and more of the fixed costs. The goal is to get to BEP and beyond during the full P&L period. At the deal level, be wary of pricing based on the fully-loaded costs (variable and fixed costs, direct and indirect).

6. Close the deal to maximize cash flows

Price your product at marginal cost + whatever the client or market will bear to get the maximum possible advance or time-linked payments. This is a simple exchange of cash for margins wherever possible and an effective way to maximize the cash flows. Many clients, especially the larger ones, worry more about budgets than cash flow. 

Let’s look at a high-level illustration. 

Assume a software product company providing a learning and development platform to the enterprise marketplace. Let’s call this company Elldee.

Elldee has a SaaS business model that works well in terms of annuity revenues, steady cash flows and scale. Clients prefer the pay-as-you-model representing OpEx rather than CapEx. Investors love the SaaS space and have funded the company based on the future expectations of rapid scale and profitability.

However, given the ongoing crisis condition, Elldee needs to take a good re-look at the licensing model. By applying MC filters, it may make more market and financial sense to maximize upfront cash by doing a longer-term `licensing’ deal for the software-as-a-service at even a deep discount, with back-ended increments in price. The variable costs of on-boarding a client are similar to a SaaS deal yet the revenue converts to contribution to absorb fixed costs quickly to help survival and longer runway for future growth. So the client pays lesser than what they would have for a three year SaaS deal but Elldee is able to sweat its IP while maximizing cash flows.

Elldee can even move its existing SaaS clients to this model to capture more revenues upfront by being aware of MC and figuring out the right pricing models to get to the BEP of the business or product. Outcome-based pricing can also be designed to deliver margins beyond the MC, contributing to the absorption of fixed costs more aggressively.

Elldee is now in a position to address different types of markets, clients and alliances. It can calibrate higher and higher margins as the environment improves and client relationships deepen. Over the next two years, Elldee would come out stronger with a more loyal client base, higher market share and a growth trajectory aligned with its pre-Covid19 business plans.

Yes, this is a simplified example but many variations to the theme can be crafted, based on a firm’s unique context.

Remember that a strong tide lifts all boats but a downturn separates the men from the boys. Marginal costing techniques, when customized for sector-specific operating models, delivers a competitive edge at a time from which will emerge stronger winners and weaker losers. Be a winner.

About the contributor: Sam Iyengar is a PE investor, mentor and advisor focused on Innovation and Impact. He can be reached at [email protected].

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.

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

iSPIRT NHS Open House Session #2: PHR and Doctor Registry

iSPIRT hosted the second open house session on the National Health Stack (NHS). 

In this session, our health stack volunteers dived deeper into the Personal Health Record (PHR) system and also covered the concept of the Electronic Doctor Registry.

In the first part of the session, our volunteer Siddharth Shetty answered technical questions pertaining to the PHR system. These questions, which were all submitted by the community, covered topics ranging from blockchains and zero-knowledge proofs to assisted consent flow for low tech-savvy users. A link to a recording of the session can be found at the end of this post.

In the second half of the session, our volunteer Kiran Anandampillai explained the concept of the doctor registry. The electronic registry system is a mechanism for managing master data about different entities in the healthcare ecosystem. Although some of these entities do appear in existing databases, these legacy systems are often incomplete, outdated, and seldom accessible via APIs. In contrast, the registries in the NHS are intended to capture trusted, non-repudiable data and enable self-maintainability. These registries will also have open APIs and will allow for secure authentication and data sharing. 

In the context of doctors, the electronic doctor registry can be used to:

  • Prove their identity and credentials as doctors
  • Electronically sign documents such as prescriptions, insurance claims, operating theatre notes, and more
  • Streamline workflows such as joining or telehealth application or registering for CME points (Continuing Medical Education points necessary for renewing a doctor’s license)

A recording of the entire session, including a breakdown of the design principles, APIs, and timelines behind the doctor registry, can be found below.

Inquisitive readers are also encouraged to submit their technical questions around the NHS to [email protected].

We will be answering those questions at the start of next week’s open house session, which will begin at 11:30 am on Saturday, 6th June. An invite to that session will be sent out to all participants who sign up at this link: https:// www.bit.ly/NHS-OHD

Although these sessions have so far been focusing on technical features of the NHS, the business and design aspects are also crucially important and will be covered in short order.

The blog post is authored by our volunteer Aaryaman Vir and he can be reached at [email protected].

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

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 

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.

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]