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!
iSPIRT turned 10 in February this year. We are about rewriting the script of the nation. The past year indicates that some of this has happened with India Stack. The idea of Digital Public Infrastructure, aka DPI, is now part of the national lexicon. It has also become India’s calling card for the world.
Back in 2015, India Stack was a response to possible digital colonization. This risk has been contained.
We have made progress. It is something to be proud of.
But this doesn’t make us a Product Nation.
India has potential. We can be a France instead of Spain, a Korea instead of Thailand. France and Korea have products that the world needs. Spain and Thailand are countries where people work for foreigners.
So, iSPIRT is only halfway there in its mission. We need to remain focused on this unfinished mission. Our next ten years will make India’s true potential come to life.
Can we make it happen? Yes!
We are doubling down. This year will see more public technology from iSPIRT than ever before.
We seek volunteers who can think outside the box and contribute their unique perspectives for this unprecedented journey. Volunteering is very different from a job. Hence, having the right mindset and approach is essential.
To volunteer for iSPIRT, kindly fill the form located at the bottom of the volunteer page available at this link. Join us as we build on our decade-long journey and welcome the next chapter of iSPIRT’s story.
We are thrilled to announce that Open Credit Enablement Network (OCEN) has been conferred with the prestigious Digidhan 2021-22 award for their Special contribution to the promotion of Digital Payments. The award ceremony was held recently in New Delhi, organized by the Ministry of IT and Electronics, and was handed over to Sagar Parikh, the OCEN lead at iSPIRT, by the Honourable Union Minister, Mr Ashwini Vaishnav.
The Digidhan Awards recognize and celebrate the outstanding contributions made by individuals and organizations towards promoting and adopting digital payments in India. This year, the award was presented to OCEN for their revolutionary work in creating a standardized digital credit infrastructure that enables lending institutions to access and disburse loans digitally.
OCEN‘s platform acts as a bridge between lenders, borrowers, and other credit infrastructure providers, enabling them to interact with each other in a secure, reliable, and efficient manner. With OCEN, borrowers can easily access credit from multiple lenders, while lenders can easily verify the borrower’s identity, creditworthiness, and other relevant details before disbursing the loan.
The platform’s open architecture and standard APIs make integrating with OCEN easy for other credit infrastructure providers, creating a robust credit ecosystem that benefits all stakeholders. Moreover, OCEN’s platform ensures that all transactions are secure, compliant with regulatory requirements, and protect user privacy.
Speaking at the event, Sagar Parikh said, “We are honoured to receive the Digidhan award for our contribution to the promotion of digital payments. At OCEN, we believe that access to credit is a fundamental right, and our platform is designed to ensure that every Indian can access credit securely and efficiently. We are grateful for this recognition and will continue to work towards our mission of financial inclusion for all.”
The Digidhan award is a testament to OCEN’s commitment to promoting financial inclusion and enabling digital transformation in India’s credit ecosystem. The platform’s standardized infrastructure and open architecture have the potential to revolutionize the lending landscape in India, making it easier for borrowers to access credit and for lenders to disburse loans.
This is our response to the Draft Drone Rules 2021 published by the Ministry of Civil Aviation on 14 July 2021.
Introduction
The potential commercial benefits that unmanned aviation can bring to an economy has been well established in several countries. A primary and immediate use-case for drones is in Geospatial data acquisition for various applications such as infrastructure planning, disaster management, resource mapping etc. In fact, as argued in the recently announced guidelines for Geospatial data, the availability of data and modern mapping technologies to Indian companies is crucial for achieving India’s policy aim of Atmanirbhar Bharat and the vision for a five trillion-dollar economy.
The current situation in India, however, is that the drone ecosystem is at a point of crisis where civilian operations are possible in theory, but extremely difficult in practice. Because the regulations in place are not possible to comply with, they have led to the creation of a black market. Illegally imported drones are not only significantly faster, cheaper and easier to fly but also far more easily acquired than attempting to go through the red tape of the previous regulations to acquire approved drones. Thus, rather than creating a system that incentivises legal use of drones, albeit imported, we’ve created a system that makes it near impossible for law-abiding citizens to follow the law of the land and discourages them from participating in the formal system. This not only compromises on the economic freedom of individuals and businesses but it also poses a great national security risk as evidenced in the recent spate of drone attacks. If we do not co-opt the good actors at the earliest, we are leaving our airspaces even more vulnerable to bad actors. This will also result in a failure to develop a world-class indigenous drone & counter-drone industry, thus not achieving our goals of an Atmanirbhar Bharat.
The Draft Drone Rules (henceforth the draft) have addressed some of these problems by radically simplifying and liberalising the administrative process but haven’t liberalised the flight operations. Unfortunately, closing only some of the gaps will not change the outcome. The draft rules leave open the same gaps that cause the black market to be preferred over the legal route.
With the three tenets of Ease-of-Business, Safety and Security in mind, it is our view that while the intention behind the draft rules is laudable, we feel that the following areas must be addressed to enable easy & safe drone operations in India:
Remove Requirement of Certificate of Airworthiness: The draft mandates airworthiness certification for drones whereas, no appropriate standards have been developed, thus, making the mandate effectively impossible to comply with.
Lack of Airspace segregation, zoning and altitude restrictions: The draft doesn’t mention any progressive action for permitting drone operations in controlled airspaces.
Business confidentiality must be preserved: The prescribed rules for access to data is not in consonance with the Supreme Court Right to Privacy Judgement
Lack of transparent Import Policy: This results in severe restrictions on the import of critical components thus disincentivizing indigenous development of drones in India
Insurance & Training must be market-driven and not mandated: We must let market forces drive the setting up of specialised training schools & insurance products & once mature they may be mandated & accredited. This will result in the creation of higher quality services & a safer ecosystem.
Fostering innovation and becoming Atmanirbhar: A. Encouraging R&D: by earmarking airspace for testing for future drones B. Encouraging the domestic drone manufacturing industry: through a system of incentives and disincentivizing imports should be inherent in the Drone Rules. C. Recognition of Hobby flying: Hobbyists are a vital part of the innovation ecosystem; however, they are not adequately recognised and legitimized
Encouraging A Just Culture: Effective root cause analysis would encourage a safety-oriented approach to drone operations. Penal actions should be the last resort and dispute resolution should be the focus.
Enabling Increased Safety & Security: NPNT and altitude restrictions would enhance safety and security manifold.
No Clear Institutional Architecture: Like GSTN, NPCI, NHA, ISRO, and others a special purpose vehicle must be created to anchor the long-term success of Digital Sky in India based on an established concept of operations
Lack of a Concept of Operations: Although drone categories have been defined, they have not been used adequately for incremental permissions, as in other countries; rather the draft appears to prefer a blank slate approach. The failure to adopt an incremental approach can arguably be considered as one of the root causes of the drone policy failures till date in India as regulations are being framed for too many varied considerations without adequate experience in any.
1. Airworthiness
In the long term, it is strategically crucial to India’s national interest to develop, own and promulgate standards, to serve as a vehicle for technology transfer and export. The mandatory requirement for certification of drone categories micro and up is the key to understanding why the draft does not really liberalise the drone industry. It would not be too out of place to state that the draft only creates the facade of liberalising drone operations – it is actually as much of a non-starter as the previous versions of regulations.
The standards for issuance of airworthiness certificates have not been specified yet the requirement has been stipulated as mandatory for all operations above nano category in the draft (pts 4-6). However, most of the current commercial operations are likely to happen in the micro and small categories. And for these categories, no standards have been specified by either EASA or FAA. EASA’s approach has been to let the manufacturer certify the drone-based on minimum equipment requirements. On the other hand, It is only fairly recently that the FAA has specified airworthiness criteria for BVLOS operations for a particular drone type of 40kg, and which it expanded to 10 drone types in November. Building standards is an onerous activity that necessitates a sizable number of drones having been tested and criteria derived therefrom. The only other recourse would be adopting standards published elsewhere, and as of date these are either absent (not being mandated in other countries) or actively being developed (cases noted earlier). Given the lack of international precedent, the stipulation for certificate of airworthiness in the draft needs to be eliminated, at least for micro and small category drones.
2. Airspace
One of the major concerns since the early days of policy formulation in India has been the definition of airspace and its control zones. All regulations till date, including the draft, require prior air traffic control approvals for drone operations in controlled zones. However, given that controlled airspace in India starts from the ground level for the controlled zones upto 30 nm around most airports (unlike many other countries where it starts at higher levels), it effectively means no drone operations are possible in the urban centres in the vicinity of airports in India. While the Green/Yellow/Red classification system is a starting point for Very Low-Level airspace classification, the draft does not move to enable the essential segregated airspace for drone operations up to an altitude limit of 500ft above ground level.
3. Business Confidentiality
In the domain of Privacy Law, India has taken significant strides to ensure protection of individual and commercial rights over data. The draft (pt 23.) in its current form seems to be out of alignment with this, allowing government and administrations access to potentially private and commercially sensitive information with carte blanche. The models of privacy adopted in other countries in unmanned aviation are often techno-legal in nature. It is recommended that DigitalSky/UTM-SP network data access be technically restricted to certain Stakeholder-Intent mappings: executing searches for Law Enforcement, audit for the DGCA, aviation safety investigations and for Air Traffic Control/ Management. This would need due elaboration in the detailed UTM policy complemented with a legal framework to penalise illegitimate data access.
4. Insurance
One constant hindrance to compliance is the requirement of liability transfer. While the principle of mitigating pilot and operator liability in this fashion is sound, the ground reality is that as of date, very few insurance products are available at reasonable prices. The reason behind it is that insurance companies have not been able to assess the risks of this nascent industry. Assuming the regulation is notified in its current form (pt 28), arguably affording a clean start at scaling up drone operations, we will continue in this vicious dependency loop in the absence of incentives to either end. Again, market forces will drive the development of this industry with customers driving the need for drone operators to obtain insurance for the respective operations. Therefore it is recommended that initially, insurance should not be mandated for any category or type of drone operations, and instead be driven by market or commercial necessity. Over a period of time, insurance may be mandated within the ecosystem.
Similar feedback has been shared by Insurers: “Though the regulator (aviation regulator) has made mandatory the third party insurance, the compensation to be on the lines of the Motor Vehicles Act is somewhat not in line with international practices,” the working group set up by Insurance Regulatory and Development Authority of India (IRDAI) said.”
5. Training
Currently, there’s a requirement of training with an authorized remote pilot training organization (RPTO) (pt 25), applicable for micro-commercial purposes and above (pt 24). While the intent is right, it should not be mandated at the initial stage. The reality is that there are very few RPTO’s that offer training and the cost of such training is often higher than the cost of the drones themselves, while quality is inconsistent. While the current draft rules try to address this problem, they do this with the assumption that liberalizing the requirements for establishing RPTO’s will solve this problem. While this incentivizes more RPTO’s to be established, it still does not incentivize quality and leaves in place the same bureaucratic process for registration. This has been the experience of the ecosystem so far. While it is certainly reasonable to expect that remote pilots should receive training, the goal of better informed and equipped pilotry is better achieved, at this time, if left to manufacturers and market participants to drive it.
There are currently two types of training – Type training and Airspace training. Type training can be driven by manufacturers in the early days, as is the current practice, and Airspace training can be achieved through an online quiz, based on a Concept of Operations. It is our view that customers of drones will have a natural incentive to seek training for their pilots, thereby creating the market need for better quality training schools. Furthermore, as manufacturers establish higher levels of standardization and commoditization, they will partner with training schools directly to ensure consistent quality. In the upcoming years, as the drone ecosystem grows more mature, it will become reasonable to revisit the need for mandating pilot training at approved training schools, and DGCA may create a program that accredits the various RPTOs.
6. Fostering innovation and becoming Atmanirbhar
6A. R&D
To encourage institutional research and development further, we recommend authorised R&D zones be designated, particularly where low population and large areas (like deserts, etc) are available, some key areas of experimentation being long range and logistics operations which might require exemptions from certain compliance requirements.
6B. Import policy
Rather than simply delegating the entire import policy to DGFT (pt 8), there needs to be a clear statement of the import guidelines in the rules based on the following principles in the current draft:
No barriers for the importation of components and intermediary goods for local assembly, value addition and R&D activities
Disincentivising import of finished drone products, both pre-assembled and Completely Knocked Down. Possible avenues could be imposition of special import duty as part of well-considered policy of “infant industry protection”, a policy used successfully in the recent past in South Korea and is considered a part of the policy of Atmanirbhar Bharat by the Principal Economic Advisor to the PM, Sanjeev Sanyal.
Incentivising investments in the indigenous manufacturing industry by aligning public drone procurement with the Defence Acquisition Procedure (2020) and supplemented by targeted government programs such as PLI schemes and local component requirements, which will help realise the PM’s vision of ‘Make in India’ and “Atmanirbhar Bharat’.
In the long term, developing incentives for assemblers to embed themselves into global value chains and start moving up the value chain by transitioning to local manufacturing and higher value addition in India, to be in line with the PM’s vision of Atmanirbhar Bharat. Some suggestions here would be prioritisation for locally manufactured drones for government contracts, shorter registration validity for non-locally manufactured drones etc.
6C. Hobby Fliers
While research and development within the confines of institutions is often encumbered by processes and resource availability, hobby and model flying has enjoyed a long history in manned aviation as a key type of activity where a large amount of innovation happens. Hobby clubs such as The Homebrew Computer Club, of which Steve Jobs and Wozniak were members, and NavLab at Carnegie Mellon University are instances out of which successful industries have taken off. Far from enabling hobby or recreational fliers, they are not even addressed in the draft, which would only limit indigenous technology development. Legally speaking, it would be bad in law to ban hobby flying activities considering hobby fliers enjoy privilege under the grandfathering rights. A solution could lie in recognising hobbyists & establishing hobby flying green zones which may be located particularly where low population and large areas are available. Alternatively, institution-based hobby flying clubs could be authorised with the mandate to regulate the drone use of members while ensuring compliance with national regulations. The responsibility of ensuring safe flying would rest with these registered hobby clubs as is the case in Europe and USA.
7. Encouraging A Just Culture
Implementation is the key to the success of any policy. One of the key factors in encouraging voluntary compliance is an effective means of rewarding the compliant actors while suitably penalising any intentional or harmful violations. Therefore, arguably, an important step could be to build such rewards and punishments. In the context of aviation safety and security, the key lies in effective investigation of any violation while fostering a non-punitive culture. Effective investigations enable suitable corrective actions whilst minimal penal actions encourage voluntary reporting of infringements and potential safety concerns. ICAO encourages a just and non-punitive culture to enhance safety. Penal actions, if considered essential, should be initiated only after due opportunity and should have no criminal penalties except for deliberate acts of violence or acts harming India’s national security. However, considering the fallout from any unintentional accident as well, there should be adequate means for dispute resolution including adjudication.
8. Enabling Increased Safety & Security
The draft while taking a blank slate approach clearly aims to reduce hurdles in getting drones flying. However, we argue that lack of clarity on several issues or not recognising certain ground realities actually reduces the chance of achieving this. We list the details of these issues in the subsections below.
Points 13-14 acknowledge the existence of non-NPNT (No Permission No Takeoff) compliant drones and makes airworthiness the sole criteria for legally flying, provided such drone models are certified by QCI and are imported before the end of this year and registered with DigitalSky. This is a great step forward, however, keeping in mind the win-for-security that NPNT provides through trusted permissioning and logs, it is recommended that NPNT be phased back in with an adoption period of 6 months from the date of notification.
To bring back a semblance of safety to the thought process and keeping in mind that manned aviation would be operating above 500 ft except for takeoff, landing and emergencies, it would be pragmatic to enforce altitude fencing in addition to two-dimensional fencing going forward. Permissive regulation has the effect of encouraging good and bad actors alike, and this measure ensures the correct footing for the looming problem of interaction between manned and unmanned traffic management systems, where risk of mid-air collisions may be brought back within acceptable limits.
9. Institutional Architecture
The draft indicates that institutions such as QCI and Drone Promotion Council (DPC), along with the Central Government, would be authorised to specify various standards and requirements. However, no details have been specified on the means for notification of such standards as in the case of the Director-General (Civil Aviation) having the powers to specify standards in the case of manned aircraft. Such enabling provisions are essential to be factored in the policy so as to minimise constraints in the operationalisation of regulations e.g. as was observed in the initial operationalisation of CAR Section 3 Series X Part I which did not have a suitable enabling provision in the Aircraft Rules.
Further, effective implementation demands that responsibility for implementation be accompanied by the authority to lay down regulations which is sadly missed out in the draft. In the instant draft, the authority to lay down standards rests with QCI/ DPC but the responsibility for implementation rests with DGCA which creates a very likely situation wherein the DGCA may not find adequate motivation or clarity for the implementation of policy/ rules stipulated by QCI/ DPC.
It is not clear that setting up a DPC would advance policy-making and be able to effect the changes needed in the coming years to accelerate unmanned aviation without compromising safety and security. We argue that for effective policy and making a thriving drone ecosystem, Digital Sky is a unique and vital piece of digital infrastructure that needs to be developed and nurtured. In the domain of tech-driven industries, the track record of Special Purpose Vehicles (SPV) is encouraging in India, the NSDL, NPCI and GSTN being shining examples.
The field of unmanned aviation has its own technical barriers to policy making. Its fast-evolving nature makes it extremely difficult for regulators who might not have enough domain knowledge to balance the risks and benefits to a pro-startup economy such as that of India. With the context formed through the course of this paper, it is our view that an SPV with a charter that would encompass development of a concept of operations, future standards, policy, promotion and industry feedback, would be the best step forward. A key example of success to model on would be that of ISRO, which is overseen by the Prime Minister. This would remove inter-ministerial dependencies by overburdening the existing entrenched institutions.
10. Lack of a Concept of Operations
The difference in thought processes behind this draft and the rules notified on 12th March 2021 is significant and is indicative of the large gap between security-first and an efficiency-first mindsets; keeping in mind that mature policymaking would balance the three tenets. It also points to the lack of a common picture of how a drone ecosystem could realistically evolve in terms of technology capability and market capacity while keeping balance with safety and security. The evolving nature of unmanned aviation requires an incremental risk-based roadmap; the varied interests of its many stakeholders makes reaching consensus on key issues a multi-year effort. To this end, taking inspiration from various sources and focusing on the harsh realities peculiar to India, we are in the process of drafting a Concept of Operations for India.
Concluding remarks
With the goal of raising a vibrant Indian drone ecosystem, we recommend the following actionable steps be taken by policy makers:
Immediate Term – Enabling The Ecosystem
Changes to the draft
Airworthiness Compliance requirements for all drone categories be removed till such standards are published
Hobby flying and R&D Green zones be designated in low risk areas
Guiding principles for Import policy formulation be laid out to incentivise import drone parts and de-incentivise drone models
A privacy model be applied to DigitalSky ecosystem data access that technically restricts abuse while laying a foundation for a legal framework for penalties
Insurance be not mandated for any drone categories
The provision for setting up the Drone Promotion Council be subsumed by a SPV as discussed below
Next six months – Setting the ecosystem up for long-term success
A) NPNT be re-notified as a bedrock requirement for security
B) An SPV outside of entrenched institutions be set up with a charter to
1. Envision India’s concept of aviation operations for the next few decades
2. Formulate Future Policy and institutionalize some aspects of key enablers of operations currently missing in India:
Development / update of ConOps
Monitor / develop / customize International standards
Establish Standards for Airworthiness and Flight Training
3. Develop and operationalise DigitalSky in an open, collaborative fashion with oversight and technical governance mechanisms
4. Redefine control zones and segregate airspace for drone operations
5. Establish an advisory committee with equitable membership of stakeholders
6. Address all charter items of the Drone Promotion Council
iSPIRT (Indian Software Product Industry Round Table) is a technology think tank run by passionate volunteers for the Indian Software Product Industry. Our mission is to build a healthy, globally competitive and sustainable product industry in India.
“If you want to go fast, go alone. If you want to go far, go together.”
Over the course of four weeks in July and August 2020, iSPIRT conducted a series of Open House Discussions to introduce and familiarise India’s fintech ecosystem with the new Open Credit Enablement Network (OCEN).
Background
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’.
Announced recently, it is a reimagination of the credit ecosystem, where any service provider that has an interface with users (individual or MSME) can now effectively ‘plug in’ lending capabilities into their current operations through the use of a standard set of APIs, thus taking on a new role as Loan Service Providers (LSPs).
The idea behind OCEN is to standardise the various components of a typical lending value chain so that any marketplace, app or platform that already aggregates users can make use of these APIs to cater to the credit demands of their customers. This eliminates the need to expend time and energy on setting up individual integrations with potential lending partners.
OCEN is trying to solve for one of India’s most devastating roadblocks to financial inclusion i.e. access to formal credit for the individuals and businesses that need it most. The unit economics and archaic models of our existing lending setup have led to an MSME credit gap of $330 bn with only 11% of our small businesses being able to access credit from traditional lenders.
By tapping into the existing customer pools of LSPs and working in tandem with other components of our public digital infrastructure (UPI, Account Aggregators, e-KYC etc), lenders can nullify the costs of discovering and servicing new customers, while also leveraging alternate data to offer more personalised, innovative credit products. OCEN will help to facilitate a methodical shift from balance sheet-based lending to cash-flow based lending that will help to bring more borrowers under the canopy of our formal credit system.
There are numerous ways for participants to contribute across this new OCEN-enabled lending value chain, and indeed it will take the combined efforts of lenders, LSPs, TSPs PSPs, and everyone in between for OCEN to achieve its lofty ambitions.
OCEN Developer Community
Based on the interactions with the ecosystem over the past two months, iSPIRT would like to formally announce the creation of the OCEN Developer Community, whose role is to help build and share knowledge required to make OCEN a success for all participants. The specifications for OCEN can be found here.
The goal of this community would be to:
Help reduce the implementation cycles and turnaround times for OCEN APIs
Transfer learnings and best practices from those who are creating and maintaining the OCEN API specs to all the entities keen to implement and experiment with OCEN (LSPs, FIs, AAs etc)
Seek feedback from the developer ecosystem about what changes and/or improvements to make for future releases
Onboard enthusiasts and ‘super users’ to play a more hands on role in overall API creation and implementation
If you’re interested in contributing to this group and being part of the discussion, please log in to http://ocen.discussion.ispirt.in/. For any other questions on becoming an LSP, Technical Service Provider (TSP) or Lender, drop us an email at [email protected].
In case you are curious about other ongoing initiatives outside of OCEN, there are also communities for the Account Aggregator framework (discourse.sahamati.org.in) and National Health Stack (HealthStack.discussion.ispirt.in) that you are also welcome to join.
We know that an engaged developer community is key to ensuring that this initiative is conceptualised and executed properly. We welcome the participation of our talented developer ecosystem and are looking forward to working alongside you.
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!
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].
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 [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:
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 [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.
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 [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.
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.
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.
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.
In 1973, the British economist Ernst Schumacher wrote his manifesto “Small is Beautiful”, and changed the world. Schumacher’s prescription — to use technologies that were less resource-intensive, capable of generating employment, and “appropriate” to local circumstances — appealed to a Western audience that worried about feverish consumption by the ‘boomer’ generation. Silicon Valley soon seized the moment, presenting modern-day, personal computing as an alternative to the tyranny of IBM’s Big Machine. Meanwhile, in India too, the government asked citizens to embrace technologies suited to the country’s socio-economic life. Both had ulterior motives: the miniaturisation of computing was inevitable given revolutions in semiconductor technology during the sixties and seventies, and entrepreneurs in Silicon Valley expertly harvested the anti-IBM mood to offer themselves as messiahs. The government in New Delhi too was struggling to mass-produce machines, and starved of funds, so asking Indians to “make do” with appropriate technology was as much a political message as it was a nod to environmentalism.
And thus, India turned its attention to mechanising bullock carts, producing fuel from bio-waste, trapping solar energy for micro-applications, and encouraging the use of hand pumps. These were, in many respects, India’s first “civic”, or socially relevant technologies.
The “appropriate technology” movement in India had two unfortunate consequences. The first has been a celebration of jugaad, or frugal innovation. Over decades, Indian universities, businesses and inventors have pursued low-cost technologies that are clearly not scaleable but valued culturally by peers and social networks. (Sample the press coverage every year of IIT students who build ‘sustainable’ but limited-use technologies, that generate fuel from plastic or trap solar energy for irrigation pumps.) Second, the “small is beautiful” philosophy also coloured our view of “civic technologies” as those that only mobilise the citizenry, out into farms or factory floors. Whether they took the form of a hand pump, solar stove or bullock cart, these technologies did little to augment the productivity of an individual. However, they preserved the larger status quo and did not disrupt social or industrial relations as technological revolutions have historically done.
Nevertheless, there has always been a latent demand in India for technologies that don’t just mobilise individuals but also act as “playgrounds”, creating and connecting livelihoods. When management guru Peter Drucker visited post-Emergency India in 1979, Prime Minister Morarji Desai sold him hard on “appropriate technology”. India, Drucker wrote, had switched overnight from championing big steel plants to small bullock carts. Steel created no new jobs outside the factory, and small technologies did not improve livelihoods. Instead, he argued, India ought to look at the automotive industry as an “efficient multiplier” of livelihoods: beyond the manufacturing plant, automobiles would create new sectors altogether in road building and maintenance, traffic control, dealerships, service stations and repair. Drucker also pointed to the transistor as another such technology. Above all, transistors and automobiles connected Indians to one another through information and travel. Drucker noted during his visit that the motor scooter and radio transistor were in great demand in even far-flung corners, a claim that is borne by statistics. These, then were the civic technologies that mattered, ones that created playgrounds in which many could forge their livelihoods.
The lionisation of jugaad is an attitudinal problem, and may not change immediately. But the task of creating a new generation of civic technologies that act as playgrounds can be addressed more readily. In fact, it is precisely during crises such as the ongoing COVID-19 pandemic that India acutely requires such platforms.
Consider the post-lockdown task of economic reconstruction in India, which requires targeted policy interventions. Currently, the Indian government is blinkered to address only two categories of actors who need economic assistance: large corporations with their bottom lines at risk, and at the micro-level, individuals whose stand to lose livelihoods. India’s banks will bail out Big Business, while government agencies will train their digital public goods — Aadhaar, UPI, eKYC etc — to offer financial assistance to individuals. This formulaic approach misses out the vast category of SMEs who employ millions, account for nearly 40% of India’s exports, pull in informal businesses into the supply chain and provide critical products to the big industries.
To be sure, the data to identify SMEs (Income Tax Returns/ GSTN/ PAN) exists, as do the digital infrastructure to effect payments and micro-loans. The funds would come not only from government coffers but also through philanthropic efforts that have gained steam in the wake of the pandemic. However, the “playground” needs to be created — a single digital platform that can provide loans, grants or subsidies to SMEs based on specific needs, whether for salaries, utilities or other loan payments. A front-end application would provide any government official information about schemes applied for, and funds disbursed to a given SME.
Civic technologies in India have long been understood to mean small-scale technologies. This is a legacy of history and politics, which policymakers have to reckon with. The civic value of technology does not lie in the extent to which it is localised, but its ability to reach the most vulnerable sections of a stratified society like India’s. The Indian government, no matter how expansive its administrative machinery is, cannot do this on its own. It has to create “playgrounds” — involving banks, cooperative societies, regulators, software developers, startups, data fiduciaries and underwriting modellers — if it intends to make digital technologies meaningful and socially relevant.
About the author: Arun Mohan Sukumar is a PhD candidate at the Fletcher School, Tufts University, and a volunteer with the non-profit think-tank, iSPIRT. He is currently based in San Francisco. His book, Midnight’s Machines: A Political History of Technology in India, was published by Penguin Random House in 2019
One lens I use to evaluate startup opportunities – and have written about in the past – is, are you offering an Aspirin or a Vitamin? My basic premise is that in order to do business with a startup, one has to overcome a lot of inertia – whether you are consuming and more so if you are a business. One way to overcome the inertia is to literally bribe the customer with an offer or cashback that makes it too good to be true. Another is to offer a zero-risk trial period. In most cases, however, savvy customers are simply asking the question – do I need this? Is it solving a pain point? Or is this a nice to have? In other words, is this an Aspirin (pain killer) or a Vitamin (nice to have).
In many cases, startups flounder because the pain isn’t as bad as founders imagine it to be – and the search of establishing Product Market Fit is really one of identifying which customer will deem my product to be an Aspirin. Hopefully, you find that early and if not you keep iterating until you identify that customer segment, the right positioning of the product, and of course getting the product right. At that point, from a VC funding perspective, the other unanswered questions remain, “is this a large enough customer segment – i.e. is the prize worth winning? Can you get to scale before an incumbent or a copycat can outrun you – in other words, is the pain so strong that nobody will look for alternatives? Is the product differentiated enough – and why will YOU win?
When BlackSwan events like Covid19/Coronavirus occur, entrepreneurs often panic and the first reaction is to slow-down everything, hunker down and wait for “normalcy” to return. While this is typically a prudent thing to do, it’s not always the smartest. BlackSwan events do things for us at 1000x the rate of change than one might’ve anticipated – and often lead to permanent behavioral change. This could mean that a product that seemed like a Vitamin before the event suddenly has become an Aspirin, and better still, is likely to remain an Aspirin for ever.
A few examples in the recent past – demonetization in India that ensured that everyone was made aware of digital payments was an opportunity that Paytm and later the UPI Ecosystem grabbed and India hasn’t looked back. While the cynical ones will point out that cash is back, the reality is that everyone from my milkman to my maid to my mother is now at least willing to accept payments digitally – and as I’ve Tweeted elsewhere my 83-year old #digimom is a PhonePe Aficionado! So people’s behaviors change because they have NO alternative.
Covid19/Coronavirus is an even bigger event than Demonetization because it’s global and has impacted EVERYONE – and its caused a change in behaviour that in many cases is likely to be permanent. Suddenly working from home doesn’t seem esoteric – and many founders I’m speaking with are also pleasantly surprised with the increase in productivity, the higher level of trust and creativity with their teams, the more focused execution, etc. Suddenly telling visitors to wash their hands when they meet you, to do namaste, to do contactless delivery no longer seems rude or inappropriate. Suddenly old economy companies are realizing the benefits of Video Conferencing and not insisting on vendors visiting them – rather they are almost insisting on people NOT visiting them. There are dozens of other changes happening in all facets of what we do and how we interact with others.
If you’re an entrepreneur, what do you do? Do you simply wait it out? Do you watch your competitors morph from the sidelines?
Or do you grab the bull by the horn and say “my time has come“!
Whatever you do, make sure you take time out to try and figure out if some dramatic non-linear change is happening, especially directly or in adjacency to your business – especially one that may do one of two things:
dramatically increase your market size
dramatically increase your rate of “adoption”
If you sense either opportunity, then you owe it to yourself to put a skunkworks team together and quickly validate that this is indeed the case and then figure out the fastest path to OWN that opportunity. Make sure that whatever you are doing is going to significantly improve life for a LARGE number of customers. My personal view is that if there are a compelling value proposition and an opportunity to permanently change customer behavior, focus on it and not over-optimize on the business model initially – but that’s a call dependent on your business.
In all cases, however, you may never get this golden opportunity to 1000x your business opportunity and rate of growth – step out of your box, out of your comfort zone and think hard, experiment quickly and make magic happen. That’s the life and luxury of being an entrepreneur! Because if you aren’t – perhaps your competitor is – and certainly some other startup is being born! Disrupt yourself – before someone else does!
A few founders I spoke to about this asked me, “This is a truly unfortunate time for the world – will we be seen as trying to take advantage of this situation”? The answer I give them is simply, “The world will reject whatever isn’t addressing a pain point – and addressing a pain point is not just grabbing the opportunity, it’s fulfilling a responsibility”.
This is an unusual time and certainly an unfortunate time – but make it count!
About the Author: Sanjay Swamy is Co-Founder & Managing Partner at Priven Advisors, advisory to Prime Venture Partners, a Seed-Stage VC Fund in Bangalore. Prime invests in Fintech, SaaS, HealthCare, Logistics & Education focused technology startups that are addressing real pain-points in the industry! Sanjay can be followed on Twitter @theswamy
Please note: The article was first published on Sanjay’s personal linkedin profile.
Interacting even briefly with the healthcare system reveals the issues that plague the sector in India: a severe shortage of high-quality doctors, nurses, or medical supplies (and a lack of information on where the best are); misdiagnoses or late diagnoses; overcrowding and long waits in public hospitals; overpriced and over-prescribed procedures and in private hospitals; a complicated insurance claim system; and significant gaps in health insurance coverage. Those who have worked on trying to improve the healthcare system know the systemic challenges: misaligned incentives in care delivery, a lack of health data to coordinate care, low state capacity, and the political battles between states and the Centre. Yet not one of us is spared bouts of illness or other health incidents over our lifetime. We have no choice but to work with this system. And when it doesn’t function effectively, the largest effects are felt by the poorest: productivity losses and income shocks caused by health issues have a way of spiralling individuals on the cusp of economic well being back into poverty.
Designing for high quality, affordable, and accessible healthcare in India is a challenging societal problem worth solving, with huge potential spillover benefits.
iSPIRT in Healthcare
At iSPIRT, we have started to develop an approach to dealing with complex societal problems at national scale. Our work on India Stack and financial inclusion taught us that public digital infrastructure can create a radical transformation in social outcomes when designed with a regulated and shared back-end that enables a number of (sometimes new!) private players to innovate on the front end to deliver better services. After all, innovative companies like Uber or Amazon are built on digital infrastructure: the TCP/IP Internet protocol and GPS systems that were both funded by public research. iSPIRT targets societal challenges by setting an ambitious target that forces us to think from first principles and innovate on the right digital public goods – which then catalyses a private ecosystem to help reach the last mile and solve the challenge at scale.
Over the last three years, members of our Health Stack team have been thinking deeply about how to design for a radical transformation in healthcare outcomes. We have developed a trusted working relationship with the National Health Authority and the Ministry of Health to better understand their operations and the issues at play. Our approach to addressing the challenge is evolving every day, but we’ve now developed a hypothesis around a set of building blocks that we believe will catalyse the health system. These blocks of digital infrastructure will, we hope, improve capacity at the edges of the system and realign institutional incentives to solve for long term holistic healthcare for all.
Health Stack Digital Building Blocks Overview (Work in Progress!)
Some further teasers to our approach are included in the attached writeup which provides an overview of some of the more mature building blocks we hope to implement in the coming year.
We’re striving for an end state of healthcare that looks something like this (cut by population type on the left):
These ideas were presented by the team recently to Bill Gates in a closed-door meet last month (who said he was excited to see what we could accomplish!)
We need your help!
To help shape our ideas and make them a reality, we need more volunteers — particularly those with the following expertise:
Technical Experts (e.g. microeconomists or engineers): We have a few building blocks with broad design principles that need fleshing out – for instance, a Matching Engine to between individuals and doctors/hospitals. If you are a microeconomist (especially if you have thought about bidding/auction design for a matching engine, and more generally want to solve for misaligned incentives in market structure) or you’re a techie interested in contributing to solve a problem at a national scale, please reach out! Prior expertise in healthcare is not a prerequisite. Also, if you’ve looked through the document and find a block where you think your technical expertise could help us build, certainly let us know.
Current and Future HealthTech Entrepreneurs: Often, a successful health tech startup requires some public infrastructure to be successful. For instance, a powerful rating and recommendation app need a trusted electronic registry of doctors and hospitals providing core master data. Many of our Health Stack modules are designed to catalyse private sector participation and market potential for better products and services, which in turn produce better outcomes for individuals. If you are interested in helping design public infrastructure that your company could use or are a potential health tech entrepreneur interested in learning more about the ecosystem by building for it, please let us know!
Healthcare Policy/Program Implementation Expertise: Field experience in healthcare delivery is invaluable – it gives us a true sense of the real challenges on the ground. If you’ve worked in delivering healthcare programs before with government, a non-profit, the private sector, an international organisation, or philanthropy and have ideas on what’s needed for an improvement in the sector at national scale, we’d love to hear from you.
Market making/ Health Stack Evangelisation: Any technology is only as good as its adoption! As some building blocks of the health stack get implemented, we are looking for volunteers who can help evangelise and drive its adoption.
India’s potential in the health sector is tremendous – partly because we have an opportunity to redesign not just the technology foundation (which is a near-greenfield) but also the market structure. With the right team, we hope to orchestrate an orbit shift in the quality and affordability of healthcare across the country.
Information-technology Promotion Agency, Japan (IPA), Japan External Trade Organization (JETRO), and the Indian Software Product Industry Roundtable (iSPIRT) have shared common views that (i) our society will be transformed into a new digital society where due to the rapid and continued development of new digital technologies and digital infrastructure including digital public platforms, real-time and other data would be utilized for the benefit of people’s lives and industrial activities, (ii) there are growing necessities that digital infrastructure, together with social system and industrial platforms should be designed, developed and utilized appropriately for ensuring trust in society and industry along with a variety of engaged stakeholders and (iii) such well-designed digital infrastructure, social system and industrial platforms could have a great potential to play significant roles to improve efficiencies of societal services, facilitate businesses, realize economic development and solve social issues in many countries.
Today, we affirm our commitment to launching our cooperation and collaboration through the bringing together of different expertise from each institution in the area of digital infrastructure, including mutual information sharing of development of digital infrastructure, in particular, periodic communication and exchange of views to enhance the capability of architecture design and establishment of digital infrastructure. We further affirm that as a first step of our cooperation, we will facilitate a joint study on digital infrastructure, such as (i) the situation of how such digital infrastructures have been established and utilized in India, Japan and/or other countries in Africa or other Asian regions (the Third Countries) as agreed among the parties, (ii) how the architecture was or can be designed for digital infrastructure as a basis for delivering societal services in the Third Countries and (iii) what kind of business collaboration could be realized, to review and analyze the possibility of developing digital infrastructure in the Third Countries through Japan-India cooperation. We may consider arranging a workshop or business matching as a part of the joint study to figure out realistic use cases.
Our cooperation is consistent with the “Japan-India Digital Partnership” launched between the Ministry of Economy Trade and Industry, Government of Japan and the Ministry of Electronics and Information Technology, Government of India in October 2018. We will work closely together and may consider working with other parties to promote and accelerate our cooperation if necessary.
