A District-Level Dataset of Building Volume and Nighttime Lights

by Ayush Patnaik and Kapilan Mahalingam.

How fast is Pune growing, compared with Nagpur? Is Coimbatore catching up with Chennai? In India, these simple questions are surprisingly hard to answer.

The official statistics that describe the Indian economy are, for the most part, produced at state-level, once a year, often with a significant lag. Policy questions do not respect this. Infrastructure, industrial concentration and urbanisation play out at the district level, and the district is where the Indian statistical system is weakest. There is no official district-level measure of monthly economic activity. There is no official measure whatsoever of the stock of physical capital in a district, or of how fast it changes. For much of what we would like to know about a district, the source is still a census from fifteen years ago.

We have built a new dataset to address this very problem, using satellite data. For each of 640 Indian districts, it gives two measures. The first is nighttime lights, monthly, from 2014 onwards: a flow measure of economic activity. The second is building volume, annually, from 2016 to 2023: a stock measure of physical capital. Both are derived from satellite imagery, both are released as CSVs, and the code that produces them is public.

Satellites were not designed as instruments of economic measurement. But every few days they record the surface of the earth, and economic activity leaves traces on that surface. Buildings appear. Towns spread outwards. Settlements brighten or dim after sunset as activity ebbs and flows. Henderson, Storeygard and Weil (2012) showed that the growth of nighttime lights tracks economic growth in places where the national accounts are weak, and Chen and Nordhaus (2011) worked out the conditions under which luminosity adds information to conventional statistics rather than restating them.

The difficulty is that raw satellite data is not usable as-is. It arrives in unfamiliar formats. It must be corrected for a long list of biases, and processing it at any scale requires serious computational heft. A researcher who wants a district-level series faces months of engineering before they can run their first regression. The purpose of this dataset is to do that engineering once, publicly, reproducibly, so that nobody has to do it again.

Nighttime lights: a measure of economic activity

Nighttime lights are the older of the two measures, and economists have been using them for more than a decade. The data comes from the Visible Infrared Imaging Radiometer Suite (VIIRS) (Elvidge et al., 2021). We use the monthly series from 2014 onwards, at a resolution of 500 metres. For each pixel and month, VIIRS reports the average radiance and the number of cloud-free observations that went into it. Each district-month row in our dataset gives the sum of radiance across the district, the mean radiance per pixel, and the number of pixels.

Raw VIIRS data is messy. In earlier work at XKDR Forum (Patnaik, Shah and Thomas, 2022) we catalogued some of the more notable problems. Four, in particular. First, bloom: bright pixels spill light into their darker neighbours. Second, background noise: pixels with no lights at all do not report zero. Third, outliers: gas flares and fires produce readings that have nothing to do with economic activity. Fourth, and most important for India, seasonal attenuation: there is a marked and poorly understood correlation between the number of cloud-free observations and the measured radiance (Patnaik et al., 2021). Consequently, in the monsoon months, there are fewer cloud-free observations, and the recorded radiance is biased downwards. A new user of the data will not know to correct for this, and the seasonality of clouds shows up as spurious seasonalities of the economy.

Because lights have been studied for so long, solutions exist. We take the raw data and run it through the PSTT2021 pipeline of Patnaik et al. (2021), as implemented in NighttimeLights.jl, which corrects the bulk of these problems, and then aggregate to the district. The map below shows the result for 2021.

Nighttime lights by district, dark is dim

Lights are a flow. They respond quickly: a neighbourhood brightens as it becomes more active, and dims when activity slows. This is what makes them useful at a monthly frequency. Beyer, Chhabra, Galdo and Rama (2018) worked with cleaned VIIRS data at the district level and traced the effect of demonetisation on Indian districts month by month, an episode that annual, state-level data would have largely smoothed away.

A word of caution. As household and street lighting shifts to LEDs, measured radiance can fall even where activity is rising, because LEDs emit less in the band that VIIRS is sensitive to (Kyba et al., 2017). A dimmer district is not necessarily a slower one. Gibson, Olivia and Boe-Gibson (2020) survey this and the other traps in the economic use of nighttime lights, and are worth reading before treating radiance as a direct measure of output.

Building volume: a measure of the capital stock

The second measure is new. Google's Open Buildings 2.5D Temporal dataset (Sirko et al., 2023) is built from Sentinel-2 imagery at an effective resolution of 4 metres. It estimates not just where buildings stand but how tall they are, for every year from 2016 to 2023. Where the lights are high frequency, the buildings are high resolution. We resample the raw data to 100 metres, which is far quicker to process and is plenty for district-level work, and chunk the requests to stay within Google Earth Engine's limits. Each district-year row gives the total building footprint in the district, the mean building height, and the total building volume, which is the product of the two.

Building volume is a stock. It changes slowly, through the accumulation of investment in housing, industry and commerce. Buildings are rarely demolished on a scale that would show up at the district level, so in the ordinary course the series should rise, or stay flat, from one year to the next. The map below shows building volume per square metre of footprint in 2021, which is a rough measure of how tall a district builds rather than how much of it is built on. The dense corridors are visible without any further processing.

Building volume per square metre by district

These are the same districts in the same year, seen in concrete rather than in radiance. The densely built regions broadly match the bright ones, but not exactly. The Gangetic plain and the southern coasts are brighter than their building stock alone would suggest, and parts of the interior are dimmer. That gap is the reason for carrying both measures.

Here the contrast with nighttime lights is instructive. A decade of work has gone into understanding what is wrong with VIIRS data and how to fix it. For building volume, that literature does not yet exist. There are no papers cataloguing its biases and no established cleaning pipeline. We therefore release the building volume data as published by Google, without a cleaning pass of our own, and note its most significant problems in our appendix.

There is one respect in which building volume has more potential than lights, and it is the reason for optimism despite these problems. The height of a building is an objective, verifiable measure. Municipal building registers, property tax rolls and structures of known height give a ground truth against which the satellite estimate can be checked and corrected. Seth, Singh and Uday (2026) have begun to do this in Karnataka: working with building volume inside urban local body boundaries, they find that the summed volume of a body explains much of the variation in its property tax demand. There is no comparable ground truth for the radiance of a district. We are working on a bias correction for building heights that uses known buildings as anchors for the distribution, and we expect that the cleaning methodology for this data will develop in the coming years, as it did for lights.

Putting the two together

Each measure answers a straightforward question on its own. Together they answer a more useful one. Building volume is the stock of capital in a district; lights are the flow of activity running through it.

Across districts in a single year the two agree closely. In 2023 the correlation between log building volume and log radiance is 0.83, and the fitted slope is about 1.5: a district with twice the built volume of another is, on average, close to three times as bright. Some of that is size, since a larger district holds both more buildings and more lit pixels. What is useful is the spread around the line. The six districts furthest from it all lie on the same side, dim for what has been built, by factors of twenty to eighty, and five of the six are in the Himalayas or the Northeast.

Every district in 2023: building volume against summed radiance, both on log scales, with the fitted line. The named districts are the six furthest from it, all of them dimmer than their building stock would suggest

The difference in tempo is easiest to see when the two are drawn on the same axis. Building volume gives eight annual points across the period; lights give twelve times as many.

Mumbai Suburban, Pune and Surat: monthly radiance against annual building volume, both indexed to 2016

Sorting districts by whether the stock and the flow are rising gives four kinds of district. Where both are climbing, a district is likely in the midst of genuine, sustained growth. Where construction is rising but lights are flat, capital is being put in place ahead of use. This is what one sees in a place that is being built out, such as a new industrial area. It is also what one sees in a real estate bubble, where the buildings are made and nobody comes. Where lights are rising with little new construction, existing capital is being used more intensively. That is consistent with constrained land, with limited confidence in long-term growth, or simply with a choice to extract more from what is already there. Where both are falling, the district is in decline.

Every district, 2016 to 2023: the trend in building volume against the trend in nighttime lights. Most sit in the upper right; the named districts are the starkest case of each pattern, plotted in the next chart

Most districts sit in the upper right, where both measures are rising. The interesting cases are where the two disagree. Splitting each measure three ways, into rising, flat and falling, gives nine combinations, of which eight are occupied. The empty one is rising volume with dimming lights. The chart below shows the starkest district in each of the eight: Wayanad, where building volume and lights climbed together; Pithoragarh, where both fell; Central Delhi, where both are flat, as one expects of a district that is built out; Lucknow, where construction ran ahead of measured activity; and so on through the remaining four.

Building volume and nighttime lights, indexed to 2016, for the starkest district in each of the eight occupied combinations

Obtaining the data

This dataset is for public consumption. It is released with the generating code, so that every number in it can be reproduced. The data is available as CSVs (nighttime lights, building volume, and district boundaries). The processing pipeline runs end to end in two Colab notebooks, one for nighttime lights and one for building volume. One note: the nighttime lights CSV was computed at native resolution (500 metres), while the notebook downsamples in order to stay within Colab's usage limits. Point the notebooks at a different set of boundaries, whether another country or another administrative level, and the pipelines will run unchanged.

We built this for two audiences. The first is researchers working on regional inequality, urbanisation and the geography of growth, who have, until now, had to choose between district level data and time series data. The second is anyone in government who needs to know what is happening in a place where the official numbers arrive late, or not at all.

This is a first step. There is a great deal of work to be done: on the bias correction of building heights, on the LED problem in lights, and on validating both measures against ground truth wherever it exists. Economic development leaves visible traces on the landscape long before it reaches official databases. We hope that researchers will use this data, find its problems, and help us improve it.

References

Measuring districts' monthly economic activity from outer space, Robert Beyer, Esha Chhabra, Virgilio Galdo and Martin Rama, World Bank Policy Research Working Paper No. 8523, July 2018.

Using luminosity data as a proxy for economic statistics, Xi Chen and William D. Nordhaus, Proceedings of the National Academy of Sciences, Vol. 108, No. 21, May 2011.

VIIRS night-time lights, Christopher D. Elvidge, Kimberly Baugh, Mikhail Zhizhin, Feng Chi Hsu and Tilottama Ghosh, in Remote Sensing of Night-time Light, Routledge, 2021.

Night lights in economics: Sources and uses, John Gibson, Susan Olivia and Geua Boe-Gibson, Journal of Economic Surveys, Vol. 34, No. 5, December 2020.

Measuring economic growth from outer space, J. Vernon Henderson, Adam Storeygard and David N. Weil, American Economic Review, Vol. 102, No. 2, April 2012.

Artificially lit surface of Earth at night increasing in radiance and extent, Christopher C. M. Kyba and others, Science Advances, Vol. 3, No. 11, November 2017.

But clouds got in my way: Bias and bias correction of VIIRS nighttime lights data in the presence of clouds, Ayush Patnaik, Ajay Shah, Anshul Tayal and Susan Thomas, XKDR Forum Working Paper No. 7, October 2021.

Foundations for nighttime lights data analysis, Ayush Patnaik, Ajay Shah and Susan Thomas, XKDR Forum Working Paper No. 19, December 2022.

Estimating property tax potential in urban local bodies using satellite imagery, Abhishek Seth, Manish K. Singh and Diya Uday, XKDR Forum Working Paper No. 47, March 2026.

High-resolution building and road detection from Sentinel-2, Wojciech Sirko, Emmanuel Asiedu Brempong, Juliana T. C. Marcos, Abigail Annkah, Abel Korme, Mohammed Alewi Hassen, Krishna Sapkota, Tomer Shekel, Abdoulaye Diack, Sella Nevo and others, arXiv:2310.11622, 2023.

The authors are researchers at XKDR Forum, Mumbai.

Better public procurement for IT in India

by Ashok Pal Singh, Karthik Suresh, and Susan Thomas.

Information technologies (IT) are now ubiquitous in government. The Government of India has more than tripled its expenditure in real terms on large-scale "mission mode projects" over the last fifteen years. Yet, we see persistent evidence of failures (see examples here, here, and here). Failures in IT services therefore affect not only convenience but also people's ability to comply with the law. At the same time, there is a wide gap between contracting volumes and contracting capabilities in the Indian state. This makes government IT systems particularly vulnerable to changes in scope, features, and scale that may happen during the course of a project. These problems pose challenges for contract design through which this flow of change requests is processed by private vendors without exorbitant monopolistic pricing. IT systems are not one-off jobs that is akin to building bridges or even repeat jobs like purchasing medicines. This is a tricky problem to address.

In our new paper, Better public procurement for IT in India, we delve into three cases of large-scale IT projects in India --- Aadhaar, Passport Seva, and MCA-21. We ask, what factors drive the performance of IT procurement by the Indian government? We answer the question by analysing the performance of contracts and the underlying factors driving this for IT projects using a contract life-cycle approach. This involves looking at six aspects of each project: (i) the vision, purpose, and objectives of the project which help the government write the specifications and delegate all the other aspects of the project; (ii) the project's governance structure, (iii) the project's contracting model, (iv) how each project dealt with change requests, (v) how did the project deal with closure and transition into newer versions of the IT system, and (vi) did the project reasonably abide by cost and time estimates.

Our general findings are that the Indian government finds it difficult to take on the IT project after the vendor has completed the contract. Further, the government is unable to communicate, handle, and account for change requests in IT projects efficiently. IT projects carry some level of inherent risk and they require some level of adaptive contracting. At the same time, government projects are conducted using public funds and there are rules against profligate spending. Therefore, IT contracts should be designed in such a way that they confine to the strictures of the rules on public spending, while at the same time they are flexible enough to allow the project managers to adapt to change requests, technological improvements, and other developments. On these lines, we suggest the following prescriptions:

• Restricting the mandate of the project to a single goal/ outcome when multiple goals conflict with each other.
• Sufficiently empowering the project leadership team in terms of skillsets, administrative competences, and spending capabilities.
• An inter-disciplinary team that can complement each other's skills and allow for a space for deliberation, while also guarding against technological solutionism.
• Evidence-based decision making that follows the scientific process of discovery, evidence, and analysis.
• Government should take ownership of the project and use the services of consultants and experts for specific outcomes within the project framework.
• Transition management is as important as project management --- a well-defined transition plan that is written into the project document for the first iteration itself.
• Government's IT system should be available in the open source domain. There are significant positive spillovers when government IT systems are digital public goods i.e., open-source code on published websites which speak open APIs.
• Highly specialized IT projects are susceptible to opportunistic hold-ups and sunk costs. Bidders in India therefore tend to price these costs ex-ante i.e., by overstating the bid. This in turn incentivizes the government to use state power to pay only the marginal production cost to the bidder. As a solution, the literature suggests that the government "owns" the system/ asset.
• Contracts are differentiated on the basis of financial risks, operational risks, and ownership. In our view, the government should procure a working proof-of-concept, after which it can scale up the project.

Government IT projects can be thought of as being implemented in the following three phases: Phase 1 being the development of a system that demonstrates the proof of concept (PoC) ending in the delivery of a pilot implementation; Phase 2 where the pilot is scaled up to the state or national level; and Phase 3 where the project then moves into running an operational system. Successful implementations of public IT systems ideally are a mix of "make" and "buy" rather than just "buy". Phase 1 should done through "make" -- where the government itself builds the PoC and delivers a pilot implementation. Once the PoC is established, the IT system is like a well-defined product. With this in place, scaling up of the system over a state or the entire country can be optimally done through "buy", where private vendors can be contracted to deliver on a clearly defined output.

Ashok Pal Singh is a retired civil servant who served in various positions, including that of Deputy Director General with the Unique Identification Authority of India. Karthik Suresh is Assistant Professor at the National Law School, Bengaluru. Susan Thomas is Co-founder and Senior Research Fellow at XKDR Forum.

Supervising what you cannot inspect

by Maninder Singh Juneja and Renuka Sane.

In traditional financial regulation, supervisors are able to inspect the thing being regulated. For example, a scorecard by a bank was usually a short list of factors that one could comprehend. These factors could be traced to key documents within the bank, banks had a stated rationale for why they were being used, and there was some common sense in making weighted averages. The scorecard itself was static - the same weighted factors were applied over a period of time. Inspecting this process of constructing the scorecard and using it for management decisions was how trust was built. The AI world is different. Models are rented rather than built, change continuously, and behave probabilistically. They cannot be fully inspected even by the institution deploying them let alone by the regulator.

How should we then think of regulation?

One approach is to intensify the traditional approach where regulators demand more explainability, more documentation, and more validation. This will drive up the costs of compliance. But more importantly, this is ill suited to the new world where the technology changes rapidly, where the bank does not control the AI it uses, where there is no clear artefact that the bank can give the supervisor such as a model or a document (Board of Governors et al 2026). When regulators push traditional approaches, banks will respond by choosing AI models which are easy to document rather than the ones best for them, or defer AI deployments altogether. All these are unhappy consequences. What we need are policy makers who understand the live systems of the new world.

In this article, we analyse these emerging problems from first principles. We start from scratch, understand the landscape of market failure in the world of AI in banking, and think about how regulators can grapple with this world.

Our key idea is that AI systems resist replicability. Regulatory strategies that demand replicability will flounder or choke technology deployment. We suggest the regulatory standard applied should be AI deployments that are "supervisable" - the outcomes should be observable, they should be attributable to causes, and reversible by humans.

How AI is actually deployed

Before we get to the puzzles faced by regulators, we need to describe what AI in banking is. This categorisation is not unique to banking. Banking is simply where their consequences are regulated. Five modes span the range.

AI as Tool: AI augments a step, a search, a calculation, a first draft that the human controls. The human is cognitively engaged.

AI as Collaborator: The human and AI co-produce iteratively, and the human participates at every stage.

AI as Recommender: AI generates scores or options, and the human makes the decision. This is the classic human-in-the-loop, but credible only if the human can meaningfully interrogate the recommendation and not degenerate into cognitive surrender.

AI as Preparer: AI does the work and the human signs off. The approval here is closer to a check by a supervisor rather than a re-derivation.

AI as Autonomous executor (agentic AI): AI executes autonomously inside guardrails and the human monitors on exception. Emerging forms of agentic AI for banking run from single-task agents (a payment released, a service query resolved) to multi-step workflows and customer-facing agents that transact.

A central issue here is the true (de facto) role of the human. A reviewer who approves a thousand recommendations a day is not overseeing a model, the model is overseeing her. A feature of any deployment is the measured divergence between the model recommendation (and estimated uncertainty) vs. the human decision. Managers of banks will need to worry about relapses of human behaviour inside the organisation, a bit like how hospital managers worry about bad behaviour by doctors within their organisation.

What AI does to market failure in banking

We now shift gears to look at the standard knowledge on market failure in banking. Regulation may be justified when (and only when) there exist market failures which cannot self-correct fast enough, and there is adequate state capability in banking regulation to be able to correctly identify them and intervene. AI's distinctive feature is that it can cure several classic failures. Better default prediction reduces credit rationing, better fraud detection cuts deadweight loss, richer risk assessment lets banks serve customers they previously could not price, AI advisors help customers avoid some malpractices by the bank. But there are also some new problems that are anticipated.

Information asymmetry: This happens in banking at two levels: borrower-to-lender (adverse selection, hence credit rationing) and firm-to-consumer (product complexity, hence mis-selling). AI narrows the first through alternative data and may widen the second. On one hand, the customer armed with AI can see through many things proposed by the bank which are not in her best interest. But the consumer cannot observe why they were shown a product, offered a price, or steered toward a specific insurance plan. The sales process itself becomes more opaque. Personalised pricing approaches first-degree price discrimination, extracting consumer surplus. A single flawed model can mis-sell to millions simultaneously, converting isolated conduct failures of the pre-AI world into a big correlated event. And redress weakens when a denial comes from a model the firm itself cannot explain.

Systemic externalities from shared infrastructure: Each bank chooses its models, data sources and vendors to optimise its own performance. When multiple entities choose the same ones, the sector's exposures become correlated, which is a cost no individual bank prices in. We list the vulnerabilities below:

Correlated model risk: banks on similar models and the same foundation providers respond identically to an event. The regulator, at the system level, has to manage what happens when institutions move together, because no single entity has experience of such behaviour or of the impact synchronisation adds.

Third party concentration: one vendor's failure propagates everywhere at once. India has already run this experiment, when a ransomware attack on one shared technology provider knocked roughly three hundred cooperative and regional rural banks off the payments network.

Correlated cyber breach: shared stacks mean one exploited vulnerability is every institution's vulnerability. AI lowers the attacker's costs (automated vulnerability discovery, deepfake social engineering) and adds new attack surfaces (data poisoning, model inversion, prompt injection against agents that can move money).

Runs on banks at level 3. The bank runs of old were a queue on the pavement. Then we got to Silicon Valley Bank where over a weekend, customers took away money from the bank. Now we can be at level 3: autonomous agents managing customer cash can turn a shared signal into a self-reinforcing run at machine speed.

The various market failures listed above behave differently across the five modes of AI use. For example, when a human constructs the offer, opaque pricing can get contained. However, when an agent personalises autonomously at scale, this may become severe. Systemic correlation is moderate when AI advises and severe when fleets of similar agents act simultaneously. Any regulation that grades by model type alone, or by use case alone, misses half the object. The next question is the mode of regulation itself.

Regulatory strategy

Regulation can work in two ways. Process-based regulation is ex ante: it prescribes how the firm must operate, defines required controls, mandates oversight, validation standards, limits on autonomy. Outcome-based regulation is ex post: it prescribes ends, fair treatment, solvency, and judges results, leaving the choice of methods to the firm.

Outcome-based regulation is the efficient default. It is technology-neutral, so it does not ossify as methods change; it lets firms find the least cost route to compliance; and it does not require the regulator to understand the firm's production function better than the firm does. But it has important preconditions: the outcome must be observable and measurable; it must be attributable to the firm and, ideally, to the cause; and the harm must be reversible or compensable. Process regulation is the right departure from the default when those preconditions fail and where outcomes are unobservable, harm is catastrophic or irreversible, or damage manifests only systemically or with a lag.

Traditional doctrine treats these preconditions as given: examine the activity, choose the mode. This does not work for AI. Whether an AI deployment's outcomes are observable, attributable, and reversible is an engineering choice, which needs to be settled at design time. We suggest that regulation should mandate observability. This makes it possible to have an "outcome-based supervision" model. There are three ways to ensure observability.

1. Telemetry implies that the institution keeps a track of every decision such that the system records which version of itself it was using, what information it was given, and any time a person stepped in to overrule it. This makes outcomes attributable. That way if a certain group starts getting more (or less) approvals than before, the organisation can evaluate what caused the shift - was it the model, or the group itself. Such a capability is being mandated elsewhere in the world for similar use-cases (European Parliament and Council of the European Union, 2024). The regulator should also consider if it wants to set a minimum common telemetry standard.

2. Boundaries and rollback include putting caps on what the system is allowed to do, rolling out new updates to just a small number of cases first (instead of everyone at once), and having a tested plan for switching back to the older version if something goes wrong. This ensures that if a bad update slips through, it only affects a small slice of decisions.

3. Probes make bias observable. One way is "paired testing": one submits two applications that are exactly the same except for details that hint at things like someone's race or gender, and see if they get treated differently. One can also compare approval rates against the company's own normal levels. Together, these checks can catch an unfair credit model in just a few weeks, instead of waiting years to see who actually pays back their loans. One can also check rejected applicants against credit-bureau data to see which ones got approved by someone else, and how they fared.

These are similar to the idea of decision receipts that record which rules were applied to which facts and in what sequence for every decision made by a government or public system (Srivastava, 2026).

Over time, the supervisor should also build a repertoire of its own test cases drawn from incidents, complaints and examinations across the system and run it against every material AI deployment, much as stress-test scenarios are run against every balance sheet today. This will ensure that what surfaces in one institution becomes a probe for all others. It thus allows the regulator to set its own observability layer.

Process regulation is then reserved for the harms that are systemic, correlated, or irreversible at machine speed. For such events there need to be protections such as circuit breakers that halt things before they cause damage, limits on how much the systems can do on their own, model diversity so they don't all fail the same way, and rehearsed back-up plans.

What follows for the supervisor, the board, and the customer

For the supervisor: The unit of examination shifts from the model to the deployment, and the examiner's question shifts from "show me the validation report" to "show me the behaviour": what boundaries were set, what exceptions were thrown, what overrides were exercised, how far the system drifted from its baseline. Supervisors will also need to find the intellectual clarity to avoid a wide variety of extraneous claims about regulation of AI, e.g. the push for economic nationalism which has nothing to do with market failure.

For the board: A board cannot certify systems it cannot inspect or understand. Its role is to govern the framework which includes the limits on what the system is allowed to do, and making the rules for when a decision must be escalated to a human. The board then needs to continuously check the exceptions and overall performance.

Exception-handling should also be written into policy. If a problem stays unresolved beyond a defined size or time limit, it automatically gets escalated to the board. Internal auditors should double-check that the numbers are real. The board sticks to this audited framework and does not inspect the system directly.

If a board is asked to approve something they can't understand, they will default to saying no. But if you let them govern the limits and the exceptions instead, they can say yes.

The customer: The customer becomes part of the supervisory architecture. The widening firm-to-consumer asymmetry has a structural corrective the pre-AI world lacked: the customer now has AI too. Mainstream assistants abroad have begun connecting directly to users' accounts. If product terms (rates, fees, eligibility criteria) are mandated to be structured and machine-readable, the customer's own AI does the comparing, the explaining, and the policing of mis-selling, continuously and at zero supervisory cost. The redress channel weakened by opacity is restored the same way: an adverse decision should carry its reason to the customer, and what would have had to be different for the answer to change. This restores the ability to contest. The same asymmetry that AI widened, AI-equipped customers can close, but only if regulation hands them the data.

An example

Consider a debt-collection example. When borrowers fall behind on payments, the bank has to decide how to chase each overdue account. Contact methods differ in cost. Automated SMS and IVR (the automated phone system - "press 1 to pay") are cheap; having an employee actually phone the customer is expensive. So the bank builds a model that allocates accounts: cheap automated nudges for most, and the costly human call reserved for the accounts where the model predicts that talking to a person will actually "cure" the account (get it back to paying). Human calling works better but it costs more. The model is rationing an expensive resource to where it thinks it'll pay off.

With AI, the collection systems would retrain continuously or run reinforcement-style optimisation against a live reward (cure rate per rupee spent). The model would be moving on its own, faster than the review cycle, toward a target that is a proxy for what the bank may actually want. Under the conventional "inspect-the-artifact" approach, the model is checked before deployment, signed off, and reviewed on a schedule (say quarterly or annually). However, if AI is an active optimiser, a quarterly review discovers deterioration only after it has touched thousands of accounts. It may drift toward a mis-specified target in a way no one can read off the model itself. Further, if the collections model is a shared vendor product, or several banks fine-tune the same foundation model on similar data, they all go bad the same way at the same time when borrower behaviour shifts. In contrast, in a "supervisability-built in by design" approach, a small slice of accounts is deliberately kept on the previous allocation method, running live alongside the new model. This allows comparison between the old and the new in real time.

Every decision should keep a record of a few things: which version of the AI was used, what action it chose, which group of customers it was dealing with, and how things turned out in the end. This is how it helps: Say the AI's overall success rate is going up, but one particular group is quietly getting fewer phone calls from real people and doing way worse because of it. With all that recorded, that gap shows up right as it's happening. You can compare it against what's going well elsewhere, trace it back to a specific version of the AI, and undo it that same day, because the older setup is still up and running as a backup.

The company should never have to dig into the AI's inner "thought process" to realize its behaviour has taken a bad turn. None of this replaces the normal testing that the firm would do anyway. The difference is that here, the ability to observe what's happening, pin down what caused it, and shut it down are all built right into the system from the start, instead of being things you have to go do to the AI afterward.

Conclusion

AI deployments sit uneasily in conventional mores of banking regulation. The intelligence is rented, the behaviour is probabilistic, and harms can move at machine speed. We suggest that the response should not be more inspection of what cannot be inspected, nor blind faith in outcomes that arrive too late. Efficient regulation will emerge from observability, attributability, and reversibility. Regulators should require banks to build these.

References

Board of Governors of the Federal Reserve System, Federal Deposit Insurance Corporation, and Office of the Comptroller of the Currency. "Supervisory Guidance on Model Risk Management." SR Letter 26-2. April 17, 2026. https://www.federalreserve.gov/supervisionreg/srletters/SR2602.pdf.

European Parliament and Council of the European Union. Regulation (EU) 2024/1689 (Artificial Intelligence Act), arts. 12, 26(6), and Annex III(5)(b). https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-12.

Srivastava, Manish. "Digital Governance Needs Decision Receipts." Episode 73 of Big Ideas. XKDR Forum, June 1, 2026. Podcast, video, 13:06. https://youtu.be/WFX4ITb9yok

Trust in the Era of the AI-Informed Customer

by Maninder Singh Juneja.

A patient grappling with a longstanding eye problem was diagnosed with MGD (Meibomian Gland Dysfunction) by an eye specialist. To make sense of the medical jargon, she photographed her meibography report, the gland scan, and uploaded it to an AI, which confirmed the diagnosis and the line of treatment. A few weeks later, wanting to avoid buying shades of cosmetics she already owned, she uploaded a photograph of her stock and of the items she was about to buy to the same AI. Instead of commenting on the shades, the AI told her the waterproof eyeliner she had used for years was blocking the pores of the gland, like wax in a drain, and making her dry eyes worse. She stopped, and this one change brought immediate relief. The AI connected across domains, unasked. Neither the physician nor the cosmetics counter had connected the two. The ophthalmologist saw the eye. The counter saw the product. AI saw the person. Neither was wrong. Each was trained to look at one domain. Every institution serves its own; AI serves the customer. This is not a failure of individuals but a structural shift with strategic implications. In this article we examine these implications.

Verification in markets

For as long as markets have existed, buyers have had to trust sellers, because there was no way to verify their word, or the effort and cost were too high. The economist George Akerlof spent many days puzzling over the nature of the vegetable retail market in Delhi. In 1970, he offered new insights into the market failure that arises when the buyer cannot verify what the seller knows. He later won the Nobel prize in economics for this work which helps us understand asymmetric information.

The market economy combats asymmetric information using substitutes, brands, professional licensing, statutory audits, regulators, and guarantees. For example, the customer trusts the bank's brand name instead of reading the fine print, or the doctor's medical degree instead of evaluating the diagnosis. Half a century of institutional architecture in financial services is built on this logic.

The use of AI has brought about a foundational shift in trust. AI has made verification in many situations quite feasible. Customers who once accepted substitutes for trust in institutions can now check a claim, compare alternatives, or challenge a recommendation on an inkling of doubt. The barriers to specialist access, cost, time, language, jargon, have all collapsed at once. The result is not an end of trust, but the pillars on which trust rests have changed.

How it impacts the brand

The brand is an informational shortcut, one of Akerlof's substitutes for verification. It stood in for the customer's inability to verify. The bank's or insurer's reputation stood in place of the customer's understanding of provider soundness, and the terms and conditions of the contract. AI changes that, but the picture is complicated, because the brand connotes two things at once: A promise of what we will do for you, and an aspiration of who you become or which tribe you join by choosing us.

The promise of what the brand will do is now more verifiable. The customer's AI checks every promise before purchase, searching the wider internet, cross-referencing user reviews and triangulating from multiple public sources. The bank that claims to be customer-first has its complaint-resolution record extracted from annual reports or instantly summarised from X. The insurer that promises easy claims has its claim-rejection ratio surfaced against peers. Promises that survive verification strengthen the brand. Promises that do not are revealed in seconds.

The aspiration is not in the product, it lives in the customer. People buy Apple products partly because Apple-ness signals something about themselves. Customers bank with a private bank not for any major service benefit but for who else banks there. People ride Royal Enfield partly because owning one says something no specification sheet captures. AI audits the promise. It cannot interpret the tribe.

The split deepens in the AI-to-AI world, where the customer's AI transacts with the institution's AI. The customer only experiences the outcomes, settlement speed, dispute rate, complaint-resolution time and median application-to-approval. It does not watch advertisements. In this perspective, brands need to invest in advertising that bolsters tribal loyalty, but advertising that is supposed to bolster the promise is now less important.

How it impacts labour

Like the brand, the professional is going to be hit by the AI wave. The professional of the old world was, by training, organised around the domain. The cardiologist gave the right answer to the heart in front of her, not to the medicine cabinet or the financial situation at home. The mutual fund agent recommended within his manufacturer's product set, not against the seven existing funds in the customer's portfolio. The AI can see the landscape comprehensively and the professional has to now compete with it.

In most domains the gap between the bottom and the top decile of professionals has been wide. AI compresses the gap from below. The advisor who tests his recommendation with AI before delivering it catches the portability clause he had not considered. The relationship manager who has the model argue the customer's case against his own pitch will close more often. Every word the professional says can now be cross verified; the smartest professionals will go up against 'unsophisticated consumers' with more respect.

In recent research, Brynjolfsson, Li and Raymond (2023) studied 5,179 customer-support agents at a Fortune 500 software firm and found that average productivity rose 14% with access to a generative AI assistant. Within this overall average, novice and low-skilled workers improved by 34%, while experienced and highly skilled workers showed minimal gain. By this reasoning, AI-powered unskilled labour will be tough competition against skilled practitioners.

The pattern is visible in India also. At one NBFC, the productivity of fresh-college LAP underwriters rose 40% with AI assistance, while experienced underwriters showed minimal gain. The bottom of the labour quality distribution comes closer to the top.

As the floor rises, the implications are twofold. First, the customer's worst experience disappears, and with it the customer's reason to switch providers. Second, the professional's competence becomes the table stakes. They have to now provide what AI cannot supply: Trust earned over time, judgement under ambiguity, the willingness to take a customer-friendly call when things are not going well with the business. These are the qualities that live on the aspiration side of the brand, and they are the real moats of professional competence.

When the asymmetry reverses

So far the shift has run one way, AI in the customer's hand against the institution. The same architecture runs the other way too. Institutions have always known what customers did. But AI interactions reveal something deeper, what the customer considered doing. The questions asked, the scenarios tested, the decisions abandoned. These are cognitive traces, and they sit closer to intent than anything an institution has had access to before. If applied to underwriting, pricing or customer acquisition, they create a new informational advantage that did not exist a year ago.

The trust consequence runs deeper than the privacy one. Behaviour is what the customer did once it was done. Intent is what she rehearsed before she was ready to be seen. A customer can absorb the knowledge that her behaviour was logged. When she learns the institution priced her, or declined her, on the strength of her question, the breach is of a different order. The first asymmetry was about information she did not have. This one is about information she did not know she was giving. This may lead the customer to stop being candid with the one tool that was working for her, because she now suspects it is also working for the firms. The independence this piece began with is the first thing she loses when the architecture turns around. We will have to face a new world of consumer protection complexity, going beyond the simpler questions of data privacy.

What then survives in trust? Not the part that rested on the customer's inability to check. What survives is what AI cannot manufacture. Judgement under ambiguity, the call no model will take responsibility for. A relationship proven over time, the banker who backed the customer through a bad cycle and was proved right. The human presence in a hard moment, the advisor who delivers difficult news with care. None of this can be read off a document, so none of it can be verified, and so none of it can be commoditised. The trust that survives is the trust that was never about information in the first place.

The institutions that Akerlof described were built on substitutes for verification. Those substitutes served a purpose. They filled a gap the customer could not fill herself. That gap is closing. What remains when the substitute is no longer needed is the thing the substitute was always standing in for. Genuine expertise, honestly applied, in the customer's interest. The institutions that had that all along have nothing to fear from the informed customer. The institutions that were selling the substitute will find, quietly and permanently, that the customer has stopped calling back.

The scarce asset is the question

If one risk is that the institution reads the customer's question, the other is that she asks a wrong question. While AI can reduce the information asymmetry, friction has not entirely disappeared. It rests on arriving at the right question to ask. Speed and convenience applied to the wrong question produce a confident wrong answer faster. The customer who compares home loans on interest rate alone misses the prepayment clause. The customer who has already decided to switch insurers asks questions that confirm the decision. The informed customer is powerful. The misinformed customer with AI is powerfully wrong.

The question itself is the unclaimed opportunity. No bank will build a question set that surfaces its own prepayment clause weaknesses. No insurer will build a question set that exposes its own claim-rejection ratio. This needs independent actors: non-profits, researchers, consumer bodies, who can make a GitHub for the questions consumers should be asking financial institutions.

What the Boardroom should debate

Every earlier wave of technology was institution first. Computing, internet, mobile was adopted and absorbed by the organisation and then passed onto the customer on their terms. AI exploded in consumers' hand, 100 million users in two months. The Board is now governing businesses where customers will know as much if not more than the organisation.

The first institutional response to AI has been operational, adding chatbots, analytical tools, dashboards, voice bots, service automation, that are good cost-saving initiatives. The strategic question is the viability of the business model itself.

What happens when the customer arrives informed? Which elements of the value proposition survive verification? Which revenue streams depend on customer ignorance or high search costs? Which promises would survive an AI audit? Which parts of the sales process assume an information asymmetry that no longer exists? These are not technology questions for the CTO. They are business-model questions for the Board.

The institutions that emerge stronger will not be those that adopted AI fastest. They will be those whose value remains after verification becomes cheap.

References

Akerlof, George A. (1970). "The Market for 'Lemons': Quality Uncertainty and the Market Mechanism". Quarterly Journal of Economics, 84(3), 488-500. https://www.jstor.org/stable/1879431

Brynjolfsson, Erik, Danielle Li and Lindsey R. Raymond (2023). "Generative AI at Work". NBER Working Paper 31161. https://www.nber.org/papers/w31161

Reuters / Similarweb (2023). ChatGPT user-growth figures. https://www.reuters.com/technology/chatgpt-sets-record-fastest-growing-user-base-analyst-note-2023-02-01/

Reserve Bank of India. Annual Report of the Ombudsman Scheme. https://www.rbi.org.in/Scripts/AnnualReportPublications.aspx

Maninder Singh Juneja is a partner at True North. He serves on the boards of Pine Labs, Nivara Home Finance and Integrace, and has previously served on the boards of Niva Bupa Health Insurance, Federal Bank Financial Services and HomeFirst Finance. The author thanks participants at a talk at XKDR Forum for myriad good ideas, and Ajay Shah, Renuka Sane and Aditi Mascarenhas for comments on earlier drafts.

Evaluating capital market responses to cybersecurity incidents in Indian listed companies

by Sayan Dasgupta, Renuka Sane and Karthik Suresh.

In a previous report on the Information Technology Act, 2000 we described the infirmities in the laws and institutions that govern cybersecurity threat detection and response in India. However, two questions persist. Firstly, what is the true scale of the cybersecurity problem among Indian firms? Secondly, what are the financial and reputational consequences of a cybersecurity breach at an Indian firm?

It is difficult to find answers to the first question in the public domain. But when it comes to the second question, we can gain some insights by looking at how investors respond to the news of cybersecurity incidents whenever such details are made public. In the United States, the results of these studies range from a slightly negative effect on stock prices following the announcement of an incident (e.g. Cavusoglu et al, 2004 estimated an average 2.1% loss in the first two days after disclosure) to no significant effects (e.g. Kannan et al, 2007). Amir et al (2018) however observed that there is a significant difference between the fall in stock prices for firms that disclosed the cybersecurity incident (0.7% decline in one month) vs. firms that withheld this information (3.6% decline in one month).

It is important and interesting to understand the current state of play. How many Indian listed companies made public disclosures of cybersecurity incidents? How did investors in these companies respond to this news given the limited information they had? We attempt to provide some insights into this question by conducting an event study of stock price movements that follow cybersecurity incidents in Indian listed companies. We found that there was a significant negative effect on stock prices given the prior system of disclosures.

Why is it important to make disclosures of cybersecurity incidents?

A cybersecurity incident can be a costly negative externality. In 2022, IBM surveyed 49 Indian companies and estimated the loss they suffered from a single data breach to be USD 2.32 million (INR 184.5 million). A firm suffers direct costs (e.g. costs of data recovery) as well as indirect costs (e.g. loss of trust and goodwill) due to a cybersecurity incident. These costs, along with the reluctance to divulge details about its vulnerabilities to competitors, mean that firms are not incentivized to share information on their cybersecurity incidents.

There are two reasons why firms should make disclosures about cybersecurity incidents. Firstly, consumers have a reasonable expectation of privacy. In India, the Supreme Court in the Puttaswamy decision traced this expectation of privacy to one's right to life and personal liberty. On these grounds, data privacy legislations, such as Article 34 of the EU General Data Protection Regulation and Section 8 of the Digital Personal Data Protection Act, 2023 require firms to disclose details of data breaches to their users. Secondly, securities laws are concerned with whether cybersecurity risks are "material information" that should be disclosed to investors. The concept originated in the United States --- the US Supreme Court in TSC Industries v. Northway held that a given piece of information is "material" if there is "a substantial likelihood that a reasonable shareholder would consider it important in deciding how to vote".

Specifically on materiality, the US Securities and Exchanges Commission (SEC) issued non-binding guidance in 2011 and 2018 which provided the format in which a listed entity or market participant should report on cybersecurity risks. However, in March 2023, the SEC proposed a framework for compulsory disclosures of cybersecurity risk and preparedness. In India, SEBI's general disclosure requirements on materiality are found in Regulation 30 read with Schedule III of the SEBI (Listing Obligations and Disclosure Requirements) Regulations, 2015 ("LODR Regulations"). Sub-part B, no. 6 requires the listed entity to report "disruption of operations of any one or more units or division ... due to natural calamity (earthquake, flood, fire etc.), force majeure or events such as strikes, lockouts etc." While it was not explicitly mentioned that cybersecurity risks are to be reported, many listed companies (example) made such disclosures anyway. In June 2023, specific reporting requirements for cybersecurity incidents were added to the LODR regulations which we describe in the discussion section.

Data

Our list of cybersecurity incidents comes from two datasets that provide firm-specific incident information. The first dataset --- the "CISSM Cyber Attacks Database" --- is based on the work of Harry and Gallagher (2018). It is hosted by the University of Maryland (UoM). It has a set of 285 incidents that took place in India between 2014 and 2023. Of these, 45 incidents took place in companies listed in India. This dataset includes detailed information on the type of data that was compromised, the method of attack, and the responses of the affected companies. This data was collected by deploying a customised script that queries a list of news websites for articles or news items on cybersecurity incidents which are collected, sorted and stored. Another script then categorizes these incidents into various types.

The other dataset, called the Data Breach Investigations Report (DBIR), is hosted by Verizon. It has information on the type of breach (e.g., malware, hacking, social engineering), the target of the breach (e.g., government, enterprise, small business), the method of attack (e.g., phishing, spear phishing, watering hole attack) and the impact of the breach (e.g., data loss, financial loss, reputational damage). The DBIR dataset accepts information from a broad set of user-reported sources which are manually sorted by varying levels of confidence. The dataset has 83 incidents that took place in India between 2009 and 2017, of which 11 incidents took place in Indian-listed companies. 8 of the 11 incidents are already mentioned in the UoM database, so we are left with 3 unique entries in the DBIR. We manually categorized these three incidents based on the typology provided by Harry and Gallagher (2018).

The distribution of the different types of cybersecurity incidents is as follows:

Type	Description	No. of incidents
Data attack	This type of attack covers the manipulation, destruction, or encryption of data in the target network.	7
Exploitation of application server	This type of attack uses a misconfiguration or vulnerability to gain access to data in a server-side application (e.g. a database) or the server itself.	27
Exploitation of network infrastructure	This type of attack covers the theft of data through direct access to network infrastructure such as routers, switches and modems.	1
Denial of service	This type of attack is meant to degrade or deny access to other parts of the firm's network.	3
Message manipulation	This type of attack covers interferences with the target's ability to accurately communicate information to its customers.	3
Combination of methods		5
Undetermined		2
Total		48

In total, our dataset has 40 unique companies and 48 incidents that took place between June 2013 and March 2023.

For stock prices, we retrieved the NSE daily closing prices for all the affected companies from CMIE Prowess for the period between 1 March 2013 to 31 July 2023.

Methodology

The event study methodology (ESM) is commonly used to measure stock price reactions to certain events (Fama et al, 969). We use the ESM to analyze the stock price consequences of cybersecurity incidents. Price reactions are represented by abnormal returns, which are stock returns adjusted for the normal daily stock price and market. We use the eventstudies package developed by Anand et al (2014) for our analysis.

This methodology involves the following steps:

1. Identifying the event date: The event dates are the dates on which each of the cybersecurity incidents were made public i.e. the date of the news article.
2. Calculating the abnormal returns: The abnormal returns for the affected companies are calculated on the event date and 45 days before and after the event. Abnormal returns are the difference between the actual returns of the affected companies and the expected returns of the market. The expected returns are calculated using the market model.
3. Statistical tests: They help us determine whether the abnormal returns are statistically significant. The abnormal returns are used to test whether the cybersecurity incidents had a significant impact on the stock prices of the affected companies. The statistical tests are conducted using a variety of methods such as the t-test and the Wilcoxon signed-rank test.
4. Analyzing the results: The results of the event study are analyzed to determine (i) the magnitude of the impact of cybersecurity incidents on stock prices, (ii) the factors that influence the impact of cybersecurity incidents on stock prices, and (iii) the implications of the results for investors, companies, and regulators.

Results

Event study results covering all incidents

Fig 1: Event study results for all 48 incidents.

We observe a significant decrease in the cumulative abnormal return (CAR) after the event date. The average decrease in the first month after the event was 3.48%. At its lowest, the CAR was -8.06%. However, with a widening 95% confidence interval, there is some uncertainty about the true effect of the cybersecurity incident on the stock prices of the companies. The sample size is low and the information available regarding the nature and magnitude of the incident is limited.

Event study covering incidents of the type "exploitation of application server"

Fig 2: Event study results for 27 incidents which were of the type "exploitation of application server".

The majority of the cybersecurity incidents were of the type "exploitation of application server". We conducted another event study on this set of incidents. However, we do not see significant results. In the first month after the event, the CAR increased by an average of 9.79%.

Limitations

Our list of 48 incidents is certainly not exhaustive. Many cybersecurity incidents may not have been reported. Given that the majority of our data comes from news sources, some disclosures may have been made long past the incident date.

Discussion

We began by asking about the financial and reputational consequences of a cybersecurity breach in a listed Indian firm. The trends in our analysis show that investors do tend to react negatively to the news of a cybersecurity incident.

As time progresses, we may be able to find more conclusive answers to both questions. This is thanks to some recent changes in the disclosure regime which will give us the true picture of cybersecurity incidents at Indian listed companies. In November 2022, SEBI in its consultation paper proposed amendments to these regulations. The consultation paper notes that cybersecurity incidents "may impact the operations and/or performance of the listed entity" but also recognizes that the "immediate disclosure of such events may not be desired since the entity may be vulnerable to further attacks". SEBI therefore proposed that the disclosures be made on a quarterly basis in the corporate governance report where the listed entity mentions the root cause of the incident as well as the remedial measures that they undertook. In June 2023, these proposals were adopted by amending Regulation 27(2) of the LODR regulations. Given the recent amendments to the SEBI LODR regulations, the quality of information on cybersecurity incidents could become richer. This could inform further studies which could deploy more sophisticated methodologies that control for other factors that could affect stock prices and remove the variation caused by them before performing the event study.

References

Chirag Anand, Vimal Balasubramaniam, Vikram Bahure and Ajay Shah, eventstudies: an R package for conducting event studies and a platform for methodological research on event studies, NIPFP Macro/Finance group, 2014.

Hassan Cavusoglu, B. K. Mishra, and S. Raghunathan, The Effect of Internet Security Breach Announcements on Market Value: Capital Market Reactions for Breached Firms and Internet Security Developers, International Journal of Electronic Commerce, Vol. 9 (2004), no. 104, pp. 70--104.

Karthik Kannan, Jackie Rees and Sanjay Sridhar, Market Reactions to Information Security Breach Announcements: An Empirical Analysis, International Journal of Electronic Commerce, Vol. 12 (2007), no. 1, pp. 69--91.

Eli Amir, Shai Levi and Tsafrir Livne, Do Firms Underreport Information on Cyber-Attacks? Evidence from Capital Markets, Review of Accounting Studies, Vol. 23 (2018), issue 3, no. 11, pp. 1177-1206.

Charles Harry and Nancy Gallagher, Classifying cyber events: a proposed taxonomy, Journal of Information Warfare, Vol. 17 (Summer 2018), no. 3, pp. 17-31.

Eugene F. Fama, Lawrence Fisher, Michael C. Jensen and Richard Roll, The Adjustment of Stock Prices to New Information, International Economic Review, Vol. 10, no. 1, pp. 1--21.

Sayan Dasgupta and Karthik Suresh are researchers at XKDR Forum. Renuka Sane is a researcher at TrustBridge. We thank Ajay Shah, Geetika Palta and Siddhant Bharti for their useful comments.

A conservative path to get to a fully working Linux computer

by Ajay Shah.

Linux has long been a great operating system, but there is a bottleneck on getting it properly installed and working. It is hard to get it to work with all the hardware such as the wifi, USB devices, audio, suspend/hibernate, etc. This is because this hardware tends to evolve rapidly. The device vendors frequently do not release source code, or even binaries for Linux. The Linux community solves this through large applications of brainpower. As a consequence, Linux support for the devices comes through with a lag. If you get a state of the art computer, and try to install Linux on it, this will often prove to be challenging.

How can we avoid these risks and complexities? There are three conservative pathways to get to a fully working Linux machine.

 

Method 1: Use a chromebook

 

Chromebooks are wonderful machines where Google takes responsibility for your Linux install, and for over-the-air updates (exactly as they do with Android). There are a wealth of good Chromebooks out there, and one that is noteworthy is the Acer Chromebook Spin 513. The basics all work on a Chromebook, and then you get "the Linux development environment" which gives a familiar apt-get interface to installing packages. I have installed emacs, svn, R, latex, etc. and it all just-worked. On many Sundays, my morning ritual of writing a column for the Business Standard is done using emacs on a chromebook.

Method 2: Buy linux pre-installed

 

Firms like Dell or Lenovo offer Linux pre-installed on some computers [example]. Here, again, you're up and running with zero friction. You are guaranteed that all the devices are supported. But there is a downside: You are stuck with the distribution that was chosen by the vendor. This may or may not be to your taste.

 

It's good to have the complete knowledge, so as to deal with future situations of systems administration or full reinstall. As an example, it's nice to have your servers on the identical distribution as your laptop. So I feel incomplete if someone gives me a perfectly working machine that I did not install. This is indeed schizophrenic: with a chromebook or an android device, I do not expect to ever require systems administration or reinstall, but with a Linux machine, I do.

Method 3: A conservative path to choosing hardware and OS

 

As a long-time Linux user, I have found that it's good to understand and get used to one Linux distribution, and then stick with it across the years on all my systems. For me, this distribution of choice is Debian stable.

Debian stable will often not work well on a state of the art laptop. The moniker `stable' implies something that has stabilised after years of testing, and it will not know recent developments in the hardware. What is the way out?

 

Two factors that should be kept in mind. The laptops where Linux is available pre-installed from the vendor are those where device support is superior. And, the laptops that have high production volume are more likely to go out into the expert community that makes Linux work. As an example, Xiaomi's Mi laptops are a high volume part (so the second factor is in favour) but where Linux pre-installed is not a choice (so the first factor is not).

The key idea of this article is to look at the gap between the date of a laptop release and the date of the Linux kernel. Based on your ability to deal with glitches, you must establish a minimum delay that makes you comfortable. For me, this minimum delay is 1 year: once the linux kernel is atleast a year younger than the laptop, I'm in good shape, based on my ability to deal with difficulties and my risk tolerance. Each person should choose this one number.

With this in hand, we have a recipe for screening a laptop before purchase :

1. For a laptop of interest, find out its release date. As an example, when I liked the Mi Notebook Ultra, I found this the release was in August 2021. Similarly the release date for the Xiaomi Notebook Pro 120G was August 2022.
2. Look carefully at the Debian release of interest. The Debian stable of today, which is called `bookworm' has the kernel version 6.1. This has a release date of December 2022. 
3. Restrict yourself to machines which are atleast a year older than this kernel.
   

Example: Mi Notebook Ultra. There is a decent delay between the release date of the Mi Notebook Ultra (August 2021) and the 6.1 kernel release date (December 2022). Hence, this is likely to work well.

Example: Xiaomi Notebook Pro 120G. This has a release date of August 2022. As an example of how these problems play out, this laptop has the sweet Intel work in the 12th generation "Alder Lake" CPU, with performance cores and efficiency cores. Harnessing these properly in the Linux kernel is non-trivial, and got done for kernel 5.18 in August 2022. Going by our recipe, we should wait a year after the laptop release, and thus ask for kernel 6.4. We don't yet know when it will show up in future Debian releases. What is Debian testing today ("trixie") uses kernel 6.3 that was released in April 2023, which does not satisfy the one-year test when compared with the release date of August 2022.

A long-run strategy that harnesses this recipe, to stay on contemporary hardware and software, consists of buying a new machine every time Debian testing reaches "release candidate 1" ("RC1"):

1. Watch the current Debian testing. (At present, this is `trixie').
2. Wait for it to achieve its Release Candidate 1 ("RC1"). For Debian 12 this was 3 April 2023.
   
3. Identify the kernel version that they have in it and the release date of this kernel (using the URLs placed above).
   
4. Limit yourself to examining equipment which has a release date of more than a year prior to this kernel release date. Buy this, and it's likely to work well.
   
5. At this point, you are on a fully working Debian testing RC1, but this will rapidly mature into Debian stable, and then you have a few years of stability. For Debian 12, the stable release was 10 June 2023, which was about two months after RC1.
   

Under this strategy, every few years, when Debian testing reaches RC1, it is time to buy a new laptop. You will regularly buy a laptop that is at least one year older than the kernel version in Debian testing. Modern computers are fast enough that this is not an important constraint, and older laptops are cost-efficient.

Jumping into a testing RC1 is a bit risky. This level of risk seems fine for a personal laptop but for production systems it is better to do this differently: instead of going in roughly 3 months before the release date, it's good to wait 6 months after the release date.

I thank Chirag Anand, Ayush Patnaik and Megha Patnaik for useful conversations.

Revising the Information Technology Act, 2000

by Rishab Bailey, Vrinda Bhandari, Renuka Sane and Karthik Suresh.

The Information Technology Act, 2000 ('IT Act') is a comprehensive law enacted to build trust in the digital ecosystem by regulating e-commerce, e-filing of documents, and by creating criminal offences applicable to the digital ecosystem. Despite amendments in 2009, it is widely considered that the IT Act is outdated, not least due to the proliferation of the Internet and a range of new technologies (e.g. Bahl, Rahman and Bailey 2020; Nappinai 2017; Nigam et al 2020). Recently, the government has proposed replacing the IT Act with a new legislation known as the 'Digital India Act'.

In a new report, Revisiting the Information Technology Act, 2000, we attempt to contribute to the process of revision of the IT Act, by examining four critical issues pertaining to the online ecosystem. These are:

1. Censorship: The provisions in the IT Act pertaining to censorship and blocking were framed in an era when the digital ecosystem was not as pervasive as today and before the use of social media platforms exploded. The provisions in the IT Act that empower the government to block content from public access are largely based on Article 19(2) of the Constitution. However, the institutional framework for carrying out blocking suffers from significant lacunae, including a lack of accountability of the relevant oversight institutions. We recommend that appropriate procedural safeguards be introduced through statute, to ensure greater transparency and neutrality in the blocking processes.
2. Intermediary liability: The IT Act protects intermediaries from prosecution for content posted or transmitted by third parties upon the following three conditions: (a) that they act as passive agents (or distributors) of content, (b) they disable access to unlawful content upon receiving 'actual knowledge' thereof, and (c) they observe 'due diligence' conditions laid down by the government. The 'safe harbour'' provision was introduced at a time when the digital ecosystem was still nascent. The variety of online harms that have since proliferated raise questions about whether such a system is required. We find that there is value in retaining a safe harbour for intermediaries in contexts where they have played a passive role in the ecosystem. Removing safe harbour is likely to incentivise greater private censorship, a role that intermediaries are not well positioned to undertake. However, this does not mean that intermediaries should not be responsible for ensuring the safety of the digital ecosystem. Any further obligations (such as greater transparency, the introduction of grievance redress mechanisms, etc.) ought to be implemented outside the safe harbour framework and certainly not as part of amorphous 'due diligence' obligations. We point to how new intermediary rules introduced in 2021 and 2022 have imposed a variety of new and onerous obligations on intermediaries. Many of these obligations, such as the obligation to enable traceability of the originator of information on messaging platforms and the obligation or the need to practically police a host of proscribed content, should be done away with. Any new obligations must be introduced based on evidence of harm in a proportionate manner.
3. Surveillance: The current framework pertaining to interception and monitoring of digital communications was established before the seminal decision of the Supreme Court in Justice K Puttaswamy vs. Union of India which recognized privacy as a fundamental right. Our report builds on the literature on surveillance reform in India to suggest that significant revision is required in our legal framework. Currently, the executive is provided extremely broad powers with insufficient safeguards to mitigate abuse. Certain surveillance programs such as the Centralised Monitoring System are per se disproportionate as they conduct mass surveillance. Our primary recommendation is therefore to enact a new stand-alone surveillance-related legislation, which could harmonise surveillance processes while ensuring that appropriate procedural and institutional safeguards are implemented. In the alternative, the revised IT Act should narrow the scope of powers given to the executive, while also implementing workable oversight and accountability mechanisms, not least ensuring judicial review, legislative oversight, and greater accountability of relevant bodies involved in the surveillance apparatus.
4. Cybersecurity: While the IT Act lays down various offences pertaining to cybersecurity that are broadly in accordance with international standards, we find that there is a significant need for reform of the institutional mechanisms that manage incident reporting and response. We recommend that the revised IT Act clarify the role and powers of CERT-in and NCIIPC --- the two primar cybersecurity-related agencies in India. In particular, their rule-making powers should be clarified/limited. The law should also avoid duplicating functions of each agency while limiting incident reporting requirements to large and systemically important systems and entities --- this avoids imposing disproportionate costs.

As we move towards an economy that is ever more dependent on the digital ecosystem, it is vital that the law promotes trust in the online ecosystem. This involves finding an appropriate balance between a range of competing interests --- national security and public order, the need to protect fundamental rights, and the need to promote innovation in and development of the digital ecosystem. Finding such a balance will require the government to take a considered stance on several thorny issues. Carrying out detailed and inclusive consultations will also be a vital part of the process towards establishing the digital ecosystem on a sound legal footing.

References

Varun Sen Bahl, Faiza Rahman and Rishab Bailey, Internet intermediaries and online harms: Regulatory Responses in India, Data Governance Network Working Paper no. 6, March 2020.

N S Napinnai, Cyber security and challenges: Why India needs to change IT Act, February 2017.

Aniruddh Nigam, Kadambari Agarwal, Trishi Jindal, Jaai Vipra, Primer for an Information Technology Framework Law, Vidhi Center for Legal Policy, September 2020.

Rishab Bailey, Vrinda Bhandari, Renuka Sane, Karthik Suresh, Revisiting the Information Technology Act, 2000, XKDR Forum, March 2023.

Rishab Bailey and Karthik Suresh are researchers at XKDR Forum. Vrinda Bhandari is a practising advocate. Renuka Sane is a researcher at TrustBridge.

The industry structure of India's large firms: IT is the biggest industry

by Ajay Shah.

When trade liberalisation took place, roughly 1991-2007, there was large turbulence in the structure of production in India. It's interesting to take stock and wonder: What is the present industry structure of the large firms of India?

The overall output of the country is, of course, made up of both large and small firms. Small firms are illegible, so we know much less about what is going out in the vast informal sector. What we do observe with confidence is the large firms. So, while we recognise that the industry structure of the large firms is not the industry structure of the overall economy, we examine this here.

We look at the 26,040 non-financial firms where data is visible for 2018-19 in the CMIE database. For each firm, we focus on gross value added (GVA) and the wages paid. Our crude estimator of GVA, from the income side, is profit before tax (PBT) + depreciation + wages. All values are nominal.

Industry	No. firms	Wages	GVA	Share in	Share in
		(Rs. Trn.)	(Rs. Trn.)	wages (%)	GVA (%)
Information technology	1117	3.83	5.56	30.92	22.84
Chemicals	1997	0.95	3.44	7.69	14.12
Mining	175	0.64	1.82	5.16	7.49
Transport equipment	899	0.69	1.78	5.60	7.30
Miscellaneous services	4043	1.08	1.37	8.75	5.62
Metals, metal products	1525	0.48	1.34	3.86	5.51
Wholesale, retail trading	4378	0.61	1.19	4.93	4.90
Food, agro-based products	1645	0.40	1.06	3.27	4.37
Machinery	1591	0.51	0.98	4.08	4.03
Electricity generation	640	0.30	0.88	2.41	3.62
Electricity trans., distn.	120	0.47	0.66	3.77	2.69
Consumer goods	645	0.25	0.58	2.02	2.38
Construction materials	416	0.18	0.58	1.43	2.36
Transport services	783	0.45	0.57	3.67	2.36
Ind., infr. construction	2255	0.39	0.54	3.11	2.21
Communication services	153	0.32	0.50	2.55	2.07
Textiles	1111	0.31	0.50	2.48	2.04
Misc. manufacturing	1005	0.14	0.35	1.15	1.44
Div. non-fin. services	692	0.20	0.31	1.58	1.26
Div. manufacturing	82	0.05	0.13	0.40	0.55
Hotels, tourism	564	0.12	0.13	0.93	0.54
Real estate	204	0.03	0.07	0.26	0.29
All non-fin. firms	26040	12.39	24.35	100.00	100.00

IT was the most important industry: with 30.92% of the wages and 22.84% of the GVA. This category includes computer services and IT-enabled services.

There are six big industries, which have atleast 5\% of either wages or GVA, and they are: IT, Chemicals, Mining, Transport equipment, Misc. (non-financial) services, and metals. The fortunes of the economy are now primarily about the fortunes of these six industries, which add up to about 60 per cent of the total.

It's surprising, how little is going on in some labour-intensive industires like textiles which is at 2.48 or 2.04 per cent.

The mean firm size (overall) is Rs.935 million of GVA or about \$12 million. In the case of IT, the mean firm is bigger, at about Rs.4,978 million or \$65 million.

Some will read read this table and jump to calls for industrial policy that favours these six industries. This would work poorly, as all industrial policy does. But this table should influence our thinking on the prioritisation of the public goods that will serve the six most important industries, and most notably IT.

India is in a position of strength in IT. This is inconsistent with the language of weakness in a lot of policy thinking on IT, where we see an emphasis upon national champions and protectionism [example]. It is in India's best interests to favour an open global order for the IT industry, but the Indian state tends to argue for a world of narrow domestic walls.