"Incomplete Contracts and Brinkmanship"

Regulation can be roughly categorized as being one of two types, rules based and principles based. With rules based regulation, behaviors are explicitly ruled out through an extensive set of regulations, ordinances, laws, and the like, whereas with principles based regulation a broad set of guidelines outlining the principless regulators are trying to enforce is issued, then the regulators take whatever steps are needed to enforce those principles.

This post from Jeff Ely at Cheap Talk can be used to highlight a connection between complete/incomplete contracts and rules/principles based regulation:

Incomplete Contracts and Brinkmanship in the iPhone App Store, by Jeff Ely: One of the highly touted features of the iPhone is the abundance of applications...  In traditional Apple fashion,... Apple exercises strict control over which apps are made available through the app store. Short of jailbreaking your phone, there is no other way to install third-party software.

The process by which apps are submitted and reviewed strikes many as highly inefficient.  (It also strikes many as anti-competitive, but that is not the subject of this post...) Developers sink significant investment producing launch-ready versions of their software and only then learn definitively whether the app can be sold. There is no recourse if the submission is denied.

(Just recently, we witnessed an extreme example of the kind of deadweight loss that can result.  A fully licensed, full-featured Commodore64 Operating System emulator, 1 year in the making, was just rejected from the app store. )

Unfortunately, this is an inevitable inefficiency due to the ubiquitous problem of incomplete contracting.  In a first-best world, Apple would publicize an all-encompassing set of rules outlining exactly what software would be accepted and what would be rejected.  In this imaginary world of complete contracts, any developer would know in advance whether his software would be accepted and no effort would be wasted.

In reality it is impossible to conceive of all of the possibilities, let alone describe them in a contract.  Therefore, in this second-best world, at best Apple can publish a broad set of guidelines and then decide on a case-by-case basis when the final product is submitted.  This introduces inefficiencies at two levels.  First, the direct effect is that developers face uncertainty whether their software will pass muster and this is a disincentive to undertake the costly investment at the beginning.

But the more subtle inefficiency arises due to the incentive for gamesmanship that the imperfect contract creates.  First, Apple’s incentive in constructing guidelines ex ante is to err on the side of appearing more permissive than they intend to be.  Apple ... values the option to bend the (unwritten) rules a bit when a good product materializes.  ...

Second, because Apple cannot predict what software will appear it cannot make binding commitments to reject software that is good but erodes slightly their standards.  This gives developers an incentive to engage in a form of brinkmanship:  sink the cost to create a product highly valued by end users but which is questionable from Apple’s perspective.  By submitting this software the developer puts Apple in the difficult position of publicly rejecting software that end users want and the fear of bad publicity may lead Apple to accept software that they would have like to commit in advance to reject.

The iPhone app store is only a year old and many observers think of it as a short-run system that is quickly becoming overwhelmed by the surprising explosion of iPhone software.  When the app store is reinvented, it will be interesting to see how they approach this unique two-sided incentive problem.

To see the connection, here are a few sections from above rewritten so that the Fed rather than Apple is the regulator:

Unfortunately, an inevitable inefficiency arises due to the ubiquitous problem of incomplete contracting. In a first-best world, The Fed would publicize an all-encompassing set of rules outlining exactly what would be accepted and what would be rejected.  In this imaginary world of complete contracts, any financial institution would know in advance whether the new financial product they have created would be accepted and no effort would be wasted.

In reality it is impossible to conceive of all of the possibilities, let alone describe them in a contract. Therefore, in this second-best world, at best the Fed can publish a broad set of guidelines and then decide on a case-by-case basis when the financial product is submitted. This introduces inefficiencies at two levels. First, the direct effect is that financial firms face uncertainty whether their new products will pass muster and this is a disincentive to undertake the costly investment at the beginning.

Second, because the Fed cannot predict what new products will appear it cannot make binding commitments to reject a product that is good but erodes slightly their standards. This gives financial institutions an incentive to engage in a form of brinkmanship:  sink the cost to create a product highly valued by end users but which is questionable from the Fed’s perspective. By submitting this product the financial institution puts Apple in the difficult position of publicly rejecting products that end users want and the fear of bad publicity may lead the Fed to accept products that they would have liked to have committed in advance to reject.

I don't think it's one or the other, there's room for both, and principles based seems useful when it's difficult to explicate all the ways to bypass a particular rule (e.g. the designer drug issue).

But I'm not sure that the distinction between the two types of regulation is all that useful - I find it hard to draw a clear line that separates one from the other - and I doubt most of you are much interested in the topic.

So let me make a comment about Apple. The monopoly problem is set aside here, but I think it's part of the problem. If other competitors existed, it wouldn't necessarily be an all or nothing proposition for applications. If it doesn't make it at one outlet, you can always try another if the marketplace is competitive (and the competition should also help to move the regulation to an optimal configuration, at least in theory). It might take some amendments to the code, but once something is built it's usually not too hard to rewrite it in a different language. Thus, though more competition wouldn't completely eliminate the problem, it would certainly help.

But what I don't understand is why they don't allow pre-approval. Why can't you submit an idea and say something like "my app will emulate Commodore64 Operating System, will you accept that?" Apple might be worried about, say, security holes with a particular app and it may not be able to fully judge this until the code is actually written, but this condition could be written into the pre-approval, and pre-approval would encourage more development while also cutting down on their workload to approve apps after they are developed (since many wopuld be pre-screened). And I think financial regulators could do the same thing, review proposed products prior to their actual development to reduce the waste associated with the development of new products.