The loss a security price
leaves behind.

A price can tell a buyer something about the obligation being traded. To use it as evidence about the buyer’s own security exposure, we also need to know when that obligation pays. Two contracts can make the same total payments while leaving very different losses uncovered.

My 2010 paper with Tanveer Zia, The Economics of Developing Security Embedded Software, argues that a well-designed software-risk derivative market could improve the exchange of information between users and vendors. Its public abstract connects that proposal to the allocation of development effort between features and security, and to the cost of alternative controls. The university record identifies a published conference paper, not evidence that the proposed market was established or achieved those outcomes.

That argument opens a further design question. What has to connect the traded event to the loss a particular customer wants to manage? The analysis below is a new illustration of that question, rather than a result attributed to the 2010 paper.

Write down the event that earns a payment

Suppose a contract pays when a specified software incident appears in an agreed incident register. A customer’s loss could instead depend on its installed version, configuration, exposure and recovery arrangements. An entry in the register and an interruption to that customer’s operations are separate observations. Their relationship needs evidence.

A useful comparison comes from the National Association of Insurance Commissioners’ explanation of parametric disaster insurance. It describes payments linked to a defined event measure and identifies basis risk: the payment can differ from the policyholder’s loss, including a loss without the trigger being met. This is an analogy about contract design. It does not establish the legal classification or availability of a software-risk product.

Hold the averages still and change the match

Consider 100 equally likely, invented one-year scenarios for one software customer. In five scenarios the customer loses $100,000; in the other 95 it loses nothing. Each of two hypothetical contracts pays $100,000 in exactly five scenarios. Ignore premiums, discounting, payment delay and counterparty failure for this comparison.

• Contract A pays in four of the five loss scenarios and in one no-loss scenario. One loss scenario receives no payment.
• Contract B pays in one of the five loss scenarios and in four no-loss scenarios. Four loss scenarios receive no payment.

Both contracts have an expected payout of $5,000. Expected customer loss is also $5,000. Subtracting expected payout from expected loss therefore gives zero for both contracts. Yet the expected positive shortfall, calculated as the average of the greater of loss minus payout and zero, is $1,000 under A and $4,000 under B.

The difference is visible when the scenarios remain separate. A has $1,000 of expected payout in no-loss scenarios; B has $4,000. Those payments cancel the shortfalls in the signed average. They do not remove a shortfall in the year in which the customer suffers an uncovered loss. Whether reserves or other financing can bridge that exposure is a further assumption.

These numbers are a constructed comparison, not estimated probabilities or a valuation of an available product. Equal expected payouts also do not establish equal market prices. Pricing can depend on further risks, costs and contract terms. The example isolates the information lost when the assessment keeps only the two averages.

Keep the customer’s exposure in the measurement

A proposed empirical test would record customer loss and contractual payout together, scenario by scenario, including zero-loss observations and losses that never activate the trigger. It would specify the covered software, deployment conditions, observation period, incident source and rules for correcting that source. A missing loss report should remain missing rather than being silently entered as zero.

The comparison should retain both shortfalls and payments beyond recorded loss. It should also show their timing. A later payment may improve the final balance while leaving an immediate recovery expense unfunded. Changing the software version or the population of users requires a new check of how well the trigger follows the exposure.

Evaluate the market and the control separately

The 2010 proposal treats information and incentives as part of the security problem. The next evaluation needs an explicit account of what a quoted price measures. A well-observed contractual event may still be an incomplete proxy for one customer’s losses.

Moving a financial loss between parties and preventing the underlying interruption are distinct effects. A useful comparison would assess the control’s effect on incidents, the contract’s distribution of payments and the remaining demands on recovery resources. That keeps the economic question attached to the system the customer actually operates.