iSPIRT works to transform India into a hub for new generation software products, by addressing crucial government policy, creating market catalysts and grow the maturity of product entrepreneurs. Welcome to the Official Insights!
Wi-Fi Access Network Interface (WANI) that was envisaged by TRAI Consultation papers has become a reality as Government approved it as PM WANI, on 9th December 2020, for exponential proliferation of public Wi-Fi networks.
PM WANI will make it possible millions of Wi-Fi hotspots to emerge across the country, giving easy access to internet to common man. New business models will emerge, making it possible to add another layer of Internet providers with access points being provided by corner shops and stores and others.
The Detailed Document about the Scheme can be downloaded and read at (Click to open) Department of Telecom Site.
The simplicity of the scheme is recognised by the very fact that DOT automatically recognised PDOA after application in 7 days.
PM WANI explained in a snapshot
This PolicyHacks Panel discussion with Dr. RS Sharma, Ex-Chairman TRAI, Pramod Varma, iSPIRT Volunteer, gave conceptual Architecture of WANI, Siddharth Shetty, iSPIRT Volunteer, Shubendu Sharma, Founder of Wifi Dabba and Dr. Ajay Data, Founder & CEO of a Class A ISP and other technology companies.
iSPIRT has been a protagonist of the concept of WANI with Pramod Varma, Siddharth Shetty and other volunteers involved in building the concept to unbundle another layer of broadband level Internet access to masses on the go and in far-flung areas.
Dr. RS Sharma explains,”we came to a conclusion that if we can create a technology architecture for some body to market and provide access by unbundling from ISPs like UPI has done, then it will become seamless and easy to implement and Kirana shops can also provide Wi-Fi without hassle”
“And that is how we came up with the concept of PDO like PCO of Telephone booths and PDOA etc”, he added explaining how PDOA will be a layer above PDO.
The main policy issue here was reselling of the bandwidth, which was addressed and then a consultation papers was evolved and a pilot done to test the concept on ground, he mentioned while explaining how TRAI was involved.
“It is a very asset heavy architecture if a Telco alone has to do all that physical investment till the last wire in your house or each hotspot in country” and “all the fiber in BHARATNET and others that we are laying no body knows at the the end, what we have to do and it requires an ‘entrepreneurial model’ to scale to be putting millions of connection” said Pramod Varma.
In Covid year, we have seen real hardship for people who are not privileged to have broadband access and education of children abruptly stop. “We have to make Connectivity a human right”, says Pramod Varma and explains, that is why, how essentials it is to invest into infrastructure and the last mile becomes people property.
“We had the mental model that, if we can create self sustaining interesting parts of it” Said Pramod, explaining how the concept was evolved. Adding further, that a KYC done ones can give a KYC token that can be used to further to authenticate who the person is on access layer in the Model, without doing KYC again and again. “UPI will further provide the payment model, as we have already solved it”, said Pramod.
“You will have multiple providers come together to unbundle this” Said Siddharth Shetty, adding to the conversation.
Shubendu, from Wi-Fi Dabba who had been thinking this as a ‘business model’, deployed the pilot for testing the concept. Explaining his experience, he said, “we wanted to see if we draw a Internet cable from a router in our office to street side shop, how it is used by people, can people pay for it and use it and in a week we had people instead of buying eclairs asking for a Token to use Wi-Fi”.
“In 2016, we took it as a fulltime project, and this was the time when our problem started as ISPs stopped giving us connection, after knowing we were reselling bandwidth” said Shubendu.
He also explained that, “the kind of paperwork you have to maintain and additional costs you have to incur” does not make it viable for small business to apply for an ISP.
“This policy make life simpler for businesses like us” in entirety, added Shubendu.
Dr. Ajay Data, who founded a Class A ISP in Jaipur, was on panel and said, “I am ‘very positive’ about it and this can revolutionise many many things in this Country”.
He explained, how the product “Vedio Meet” they developed to solve local education problem did not work on HD quality for students in last mile and had to be downgraded to SD quality, because of bandwidth in last mile. “we need to have the internet of the ‘streaming quality’ across country, where HD streams can be delivered on any device and if we can achieve this, rest of the applications will work ” said Ajay Data.
He raised apprehensions, on how it will be regulated on ground without harassment of the PDOs by regulatory bodies, giving examples of how even licensed ISPs are harassed and ISPs are charged AGR even in on sale of Computers and routers. Similar legal issue should not be left unaddressed and should be taken care, in languages (including vernacular medium) for PDOs to be not harassed.
“May be a board (Certificate) can be out in each PDO point to ascertain that local police and enforcement does not harass them”, said Ajay Data.
RS Sharma, addressing concerns raised by Ajay Data, Said, “PM himself has tweeted about this” and leadership knows the exact importance of the policy.
He further explained that, “Retail sale of bandwidth has been made passthrough in the AGR Computation”, either the TSPs or ISP pays for the 8% AGR, retailer has nothing to pay, as it has been already paid for.
Dr. Sharma also explained further, that it can save lot of bandwidth, as content can be maintained locally at local access points and last mile user need not traverse through the upstream network for local content, which is a very useful concept for ISPs and TSPs, to decongest the upstream networks.
The PDOs will not have any problems, as the responsibility of who is accessing what by monitoring SSIDs will lie with PDOA (aggregator), not with PDO.
Shri Sharma added that, “what is important is this is implemented well” sharing the issue with Ajay that many a times polices are misused. And we all hope good intentions will prevail and country will be benefited, he had added further.
The panel discussion ended with note of thanks.
Disclaimer: The discussion and ideas expressed here should not be construed as legal advice. The discussion is conducted with Industry practitioners and experts for purpose of benefiting the Industry members in Software product, IT and Telecom sectors.
The new guidelines on Other Service Provider (OSP) issued by DOT on 5th November is one big step taken by Government of India under leadership of Prime Minister Modi in Ease of Doing business for IT and ITeS sector.
iSPIRT Organised a Panel discussion in PolicyHacks to understand the changes that have been announced and how they impact the Industry.
The panellist included 1. Shri R.S. Sharma, Ex-Chairman TRAI 2. Rahul Matthan, Partner, Trilegal 3. Shanmugam Nagarajan, Founder and Chief People Officer, [24]7.ai 4. Chocko Valliappa, CEO, Vee Technologies 5. Sudhir Singh, Core Volunteer, iSPIRT, Policy Hacks Host
The panel discussion can be watched at below given Youtube video or you can read through the excerpts of the discussion given below in this blog.
Background
IT and ITeS companies looking for seamless cross border communication between the Indian Centers and their foreign counterparts centers use a telecom circuit service (IPLC, MPLS, Sip trunk), obtained from an Indian Telecom Service Provider (TSP). Traditionally, they were supposed to apply and get registered as OSP. The application and approval process were cumbersome and required them to submit detailed network diagrams and satisfy that authority of a legitimate use of the Circuits. The process was cumbersome, more bureaucratic than technical in nature and often subject to undue harassment by TERM cell even when use was fully legitimate.
Industry has been demanding this reform for long, as the Circuits were always subscribed through a licenses TSP in India. The Reform will give way to a new era of opening in telecom services. It is most likely to benefit IT and ITeS industry the most, boost innovation and synergistic alliance in Industry. Most importantly this will make India more attractive for FDI, as this was one major irritant in deploying most important part of the International operations i.e. International Communication.
The move will not only help large offshore IT and BPO Centers but also will empower domestic Software product companies. It will give a huge impetus to work from home and hence will be very instrumental in promotion of SaaS industry, both for their internal operations and also promote SaaS product adoption.
Some of the main highlights of this decision are.
1. No need for a Registration any more to operate as an OSP
2. Interconnection of multiple OSP centers and remote agents
3. Work From Home and Remote locations allowed
4. Centralised Infra and consolidated Traffic between Indian POP and International POP
5. Sharing of EPABX and PSTN lines by domestic and International Center
6. Distributed Architecture with main Infra at central POP and media gateways at other centers
7. CUG allowed for internal Communication
8. CDRs, access log, configurations of EPABX and routing tables to be maintained and aggregated for each media gateway for a period of one year
9. No toll bypass allowed and no telecom services to be provisioned
Excerpts of the Panel Discussions
The panel discussions started with a round of Introduction and inviting Rahul to summarise the new regulations.
Rahul Matthan started the panel discussion with a summary of the guidelines announced. He termed the new guidelines issued as Radically simplified.
Starting the introduction to new Guidelines, he said, “OSP or the Other Service Provider regulation in essence regulates Business Process Outsourcing companies and the definition of the types of entities that are regulated by this is very important. Earlier the definition used to include things like call centers, Business Process Outsourcing and other IT services, but also had very broad language at the end which included all IT enabled Services.
So, the first amendment is that it’s been restricted now to voice based business process outsourcing services.”
“The second very significant amendment that has happened is that the registration requirement has been entirely removed. Earlier you had to register with the TERM cell of DOT and that that requirement has been entirely removed,” Said Rahul.
He further mentioned that work from home (WFH) is allowed without any restriction of site or permissions and submission of network diagrams. He added. “it is work from anywhere” and “also, infrastructure sharing has been permitted there are some significant changes in the interconnectivity regulations have been permitted”.
“Bank guarantees used to run into crores for many large companies. The requirement for submitting performance bank guarantee has now been removed”, mentioned Rahul.
He also informed that the general provisions about penalty provisions with regard to inspection have been removed. “In fact, the entire chapter with regard to penalties and inspection has been removed”, mentioned Rahul.
Shri RS Sharma informed the panel how the consultation papers and discussion at TRAI on the subject progressed at TRAI. He informed that whereas the OSP regulation was very old, TRAI got a reference to start the consultation process in September 2018 and the Consultations were submitted by TRAI to DOT in 2019, which is exactly one year back.
“Essentially thought which we had was OSPs are the ones who are the customers of the TSPs telecom, they are paying money to the main service provider which is the TSP, so why should we really come in between and you know ask for all kinds of you know compliance” said Ex-TRAI chief, recalling developments.
He further informed that, next thing that was taken up is the definition, and as these are the entities which are taking resources from the telecom service providers or ISP and actually doing somebody’s work or providing services to some other entity, they should all be called application service providers (ASPs).
“Unfortunately, the OSPs also included those people who were actually providing services internally. We said any entity which provides service to itself after taking resources from the telecom service providers will not be coming within the definition of logical OSPs”, Said Shri Sharma.
He also recalled that it was recommended that everyone need not register, and only voice based OSPs need to be registered, Data based OSP need not be Registered.
The new definition given at chapter 1 point 7 states these recommendations. As said by Rahul earlier, the new guidelines limit OSP to voice-based processes only.
Shri Sharma further recalled that the TRAI recommended the removal of the requirement to submit network diagrams in OSP registration. He also further mentioned that TRAI also took a stand not to include hosted contact center service infrastructure or cloud hosted infrastructure, in OSP application scrutiny.
Shri Sharma said,” Interestingly in the last 10 years not even a single bank guarantee has been encashed.” He said bank guarantee was the most ridiculous part of the provision, as Govt. was not earning any revenue from OSP,
Similarly, he recounts the recommendations made on interconnectivity among the various OSPs, that also we said should be allowed. “I feel really satisfied”. Said shri Sharma, citing that most recommendations have been accepted.
In further discussion, Sudhir added that we were not having regulation at par with the developed world and called Rahul to give his perspective on regulatory aspects of OSP provisions.
Rahul emphasised in past Data was scarce and a licenced kind of regime was brought in with some sort of a performance guarantee to ensure compliance. Data today is not scarce and with the advent of smartphones and choices one has to make calls, the OSP regime was just giving comfort to the Inspector raj of the TERM cell.
“Country ran out of static IP Addresses”, said Rahul, when it tried to tackle the work from home during the Pandemic. Although DOT cooperated in providing relaxation, the actual need was to remove regulations relating to logical separation between Voice and Data and the need for physical EPABX.
S. Nagarajan, joined the discussion and said, “antiquated rules only hurt the industry by not letting us expand freely within the country. We are in other countries like Colombia, Philippines, Guatemala and none of these countries have these regulations”.
“So this has many benefits for us in all the dimensions, one leading to the other.. ease of doing business, geo competitiveness, location diversity, workforce diversity, talent pool expansion and increased quality of delivery through reduced attrition, (taking it back to geo competitiveness) and there by increasing our business potential for the country, creating millions more direct and indirect jobs for the nation. Thus, it is a better stimulus to the economy than just a monetary stimulus.”
Extending the panel discussions further,
Chocko Valliappa, recalled how the Government brought in Texas Instrument to Bangalore and facilitated them with a Red Carpet but in due course with such regulations the Red Carpet became Red Tape.
He mentioned that, “We employ 6000 employees between US, India and Philippines and in US for example 95% of our work is done work from home and that’s how we always operated and but in India, we are operating in just 3 cities, Bangalore Chennai and Salem and I’m sure this (the new OSP guidelines) would give us a big footprint across India and set up offices across other places.”
“In the next 35-40 years India will be capable of handling 15% of the global economy. By 2050, India will be poised to become the manufacturing hub of the world replacing China by harnessing 3D design and printing capabilities. I think India engineering talent would be sought after much more, so I think its a step in the right direction”, he further added.
Shri RS Sharma spoke further in response to a question by Rahul on whether the OSP regulation will fully go away in future. He recalled his experiences and how and why bureaucracy could not implement the ease of doing business issues easily.
Shri Sharma said, “TRAI had given two sets of recommendations, one to Ministry of Information and broadcasting another to the Department of Telecom, where we actually targeted ease of doing business.”
He also said that he has seen that the honourable Prime Minister is passionate towards ease of doing business and ease of living. He wants it, but I think we all need to come together, and we all need to sort of continuously work towards it.
“It’s a great thing which has been done actually and I was so happy, and I complimented each one of the people who are involved including the Department of Telecom”, mentioned Shri R.S Sharma at the end.
Discussion ended thanking all participants.
Disclaimer: The discussion and ideas expressed here should not be construed as legal advice. The discussion is conducted with Industry practitioners and experts for purpose of benefiting the Industry members in Software product, IT or ITeS Industry.
We held an impromptu Open Session on Balloon Volunteering on 20th September 2020. Watch the recorded video and presentation below to learn if iSPIRT volunteering is right for you.
This session will cover some of the available volunteer opportunities and tell you how to engage with us.
Last month, an expert committee chaired by Kris Gopalakrishnan submitted a report on a framework for regulating Non-Personal Data in India. The rest of this blogpost contains iSPIRT’s response to this report.
At iSPIRT Foundation, our view on data laws stems from three fundamental beliefs:
Merits of adata democracy (that is, the user must be in charge),
Competitive effects must be well understood, for creation of a level playing field amongst all Indian companies, and some ring-fencing must exist to protect against global data monopolies
Careful design enables both high compliance and high convenience
It is with these three perspectives that we have analyzed the Non-Personal Data report in our response.
The report makes a well-cited and articulate case for regulating data in India, such that “[data’s] benefits accrue to India, and Indians”. It defines and outlines the roles of various entities relating to the capture, processing and governance of Non-Personal Data. Whereas we are wholeheartedly aligned with the vision of the committee and its members in creating an Aatmanirbhar Bharat and the importance of facilitating a robust AI-industry in the country, we find that the report is sound in premise but murky in detail. Where an overarching legal framework surrounding NPD is proposed, on closer inspection it falls short of achieving the aforementioned goals of protection for Indians and prosperity for Indian businesses. Therefore, more work must be done before a final version of this report can be released.
In what follows, we take the example of one industry that will be affected by the new Non-Personal Data framework and attempt to understand the report in relation to it.
Case Study: X-ray Data
Consider the case of a (fictional) health-tech startup called rad.ai that seeks to generate radiology summaries from lung X-rays. These summaries will help pulmonologists (lung-specialist doctors) identify various pulmonary diseases or early signs of cancer. Such a company requires two things to succeed – data about X-rays and technology to build models.
Under the tenets of the NPD report, it would seem that (given the right technology foundations) such a startup would be well placed to succeed. In particular, the report suggests that the X-ray data as described above will be classified as community data and outlines mechanisms for collecting and sharing it. It suggests that the dual goal of enabling rad.ai while protecting the subjects of the data can be accomplished in the following framework –
rad.ai will first be able to identify that appropriately anonymized lung X-rays, termed community data, are available for access through meta-data that is published by radiology labs engaging in collecting such data.
rad.ai will then be able to access this data for free through a data trust (presumably a virtual API on the cloud) which is created by the radiology labs.
This will all happen with the consent and oversight of a data trustee, an entity that is a representative of the persons from whom this data is collected.
While this sets a broad-strokes framework with the right intentions, there are a few key problems that arise when we dive deeper into the proposed solution. We have outlined some areas where clarifications are needed and details must be made available. These include the definition & value of community data, obligations of the data custodian, access for data users and rights of the data principal. Towards the end, we also discuss the question of NPD’sinterplay with personal data and the definition and use of public data.
Definition and Value of Community Data
While the case of X-ray data seems straightforward, the scope of community data in the report appears to be vast. However, it also seems to suggest that while data explicitly extracted from users is classified as community data, data generated in the course of a business’s activities may be considered private business data – and this may not be mandated to be shared. In that case, it would appear that e-commerce, delivery and employee data fall under private business data – although an argument could be made for classifying this as community data.
Further, the report makes a distinction between raw and processed data. In particular, raw data must be shared free of cost, whereas the price of processed data could be determined based on market or FRAND (fair, reasonable and non-discriminatory) principles. In the case of lung X-ray data, labs obtain such data from anonymizing raw personal data, so presumably it is now processed and need not be shared without remuneration. In the general case, however, we recommend that the lines between raw and (various levels of) processed data should be clearly demarcated.
Data Custodian Perspective
Consider next, the situation from the perspective of the diagnostic labs. There are about 70,000 labs and hospitals offering radiology services in the country [ref]. Each of these has its own technology implementations or third-party TSPs (technical service providers) for collecting and storing any patient data. How can all of these labs and hospitals be mandated to provide control of this data to the data trustee in order to share the X-ray information with companies like rad.ai? Who is/are the data trustee in this case anyway – the MoHWF, the NHA, an NGO serving the interests of cancer patients? If there are multiple data trustees that have an interest in the same underlying data, how is it ensured that every decision that each of them takes is in the best interests of the user? How are labs supposed to even publish the meta-data (meta-information about what data they have collected) in a standard, machine-readable format, so that companies like rad.ai can discover it seamlessly? Finally, considering that such compliance comes with associated costs, what are the concrete benefits for making this data available?
Data User Perspective
Then there is the case of rad.ai itself. Let us assume, for now, the provisions of the previous paragraph and overlook the contentions raised. Say that because of access to this X-ray data, the startup rad.ai has been able to create excellent ML models to predict the early risks of major diseases and help pulmonologists. It has done well and begins to expand across the country. A few years later, a foreign health-tech giant (again, fictional) called Hooli enters the fray by investing in rad.ai. Backed by foreign investment, rad is now stronger than ever. However, the report identifies “to promote and encourage the development of domestic industry and startups that can scale” as one of its key objectives. While rad.ai was originally a fully Indian company, it was allowed access to the community data from radiology labs to develop its models. Now that rad.ai has foreign investment, should it still be allowed to benefit from Indian community data? What if Hooli owns a majority stake? What if Hooli acquires rad.ai outright?
Data Principal Perspective
Finally, consider this from the perspective of the patient herself – the “data principal”. How is she guaranteed that her interests are protected and the aforementioned data is impervious to de-anonymization? As discussed above health data is considered sensitive data and the patient has every right to ensure that it is handled with extreme care. The report also recommends that consent must be taken from the actors in the community before the anonymization and use of their data – but what form will this consent take? How will its purpose be determined and collection be enforced before any data is anonymized and utilized? How can anonymisation be assured when multiple anonymised datasets are capable of being combined together? Finally, the report acknowledges that all sharing of community data should be based on the concept of “beneficial ownership” where the benefits of this data sharing also accrue to the data principal. How is the patient directly benefiting from such a data-sharing mechanism? What mechanisms are in place to enable such benefits?
Interplay With PDP Bill
Consider next, the case of the health-tech giant Hooli and assume that it also operates a search engine. As per the suggestions of the Srikrishna PDP Bill [Clause 14], Hooli could be allowed to collect personal user data and use it directly since its operation of search engines falls under “other reasonable uses of personal data”. When combined with the fact that under the provisions of the Non-Personal Data report sharing of all raw NPD becomes mandatory, Hooli is actually disincentivized from anonymizing its personal search data. By keeping this data personally identifiable, it is prevented from having to share it with competing search engines and startups. Can misaligned incentives such as these hinder progress towards the report’s stated goals?
On Public Data
Consider finally that some of the labs and hospitals conducting X-rays will be government-owned. The report recommends that all data generated through government and government-funded activities are classified as Public data, which is in turn classified as a national resource. There is no guidance on the compliance requirements of the government controlling this public data under such a scenario. Will government hospitals still be required to make it available? More importantly, does the community (i.e. patients) have no claim to their data in this case merely because it was collected by the government instead of a private entity?
Concluding Remarks
In summary, the report importantly conceives a legal notion of community, private and public non-personal data and outlines a framework in which such data might be shared for the advancement of economic, sovereign and core public interests. However, more work must be done to detail compliance requirements and standardize the mechanisms of sharing such data before the final version of the report is released. In its current state, the report only touches upon the rights of the data principal, the obligations of the data trustee and the compliance requirements of the data custodian. In a State with limited regulatory capacity for creating standards and enforcing bodies, these rights, obligations and compliance requirements should be comprehensively and clearly defined before a law ordaining them can come to pass. Custodians must be incentivized to share, industry startups must be enabled to access and the community must be empowered to self-preserve before the vision of an Aatmanirbhar Bharat with a booming AI industry can be realized.
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.
SOFTEX forms filing for international trade
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.
The foreign exchange remittances due against the exports invoiced has been duly received. RBI systems manage this in synch with Authorized dealers (Banks).
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
A huge friction of Digital India concept as it hinders trade of Software products Digitally
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.
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.
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!
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.
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 sid@ispirt.in
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.
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:
Self maintainability: Doctors should be able to enrol themselves and update their own data
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
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)
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
Open APIs: The data in the registries should be available via open APIs
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:
Enrollment APIs: These APIs allow doctors to enrol in the registry and update their data
Consented APIs: These APIs allow a doctor to authenticate themselves, share their data/profile, and electronically sign documents
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 community@ispirt.in 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:
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
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)
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).
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 sid@ispirt.in. 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.
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:
Electronic Registries: these registries allow for efficient discovery and authentication of doctors, hospitals, and other healthcare providers
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
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 community@ispirt.in 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.
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 Allianceis 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.
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.
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.
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.
Subordinate debt provision of Rs 20,000 crore for 2 lakh stressed MSMEs.
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.
Global tenders will be disallowed up to Rs 200 crore for government
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.
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.
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.
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.
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?
Who is responsible for owning and operating Sahay when it was scheduled for launch?
We understand iSpirt is conceptualizing and designing the APIs and SDKs for this. Can you confirm?
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?
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 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?
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 thinkit 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.
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
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?
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:
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 meghana.reddyreddy@ispirt.in for any questions.
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:
Many different public appearances by Pramod Varma, Sharad Sharma, Sanjay Jain, Nikhil Kumar
2019: 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.
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.
With UPI we did not recommend any individual PSPs for inclusion in the network. This was entirely RBI and NPCI prerogative.
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.
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.
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 meghana.reddyreddy@ispirt.in
