In my macro course I teach students about the role of financial frictions using the classic Handbook chapter of Bernanke, Gertler and Gilchrist (BGG). As preparation we first discuss the modelling of asymmetric information between borrowers and lenders using the costly state verification framework. It turns out that in this framework, as described in BGG or in section 9.9 of Romer’s Advanced Macroeconomics, efficient contracts have the very special form of “debt with bankruptcy”. That is, there is a cutoff value such that whenever the borrower’s project earns more than this cutoff value the borrower pays a fixed amount to the lender (“debt”) while if the project earns less than the cutoff value then the lender gets to keep the entire earnings (“bankruptcy”).
In previous years I have found it very hard to convince students that efficient contracts have this form. This year I wrote a small program in Haskell to allow students to experiment with different contracts in a simple discrete variant of the problem. I tried it out in class today and being able to quickly create and check concrete examples turned out to be much more effective than abstract hand-waving.
The Economic Problem
A project run by an entrepreneur can yield a revenue of 0, 2, 4, 6 or 8; each with probabilty 1/5. The entrepreneur borrows money from an investor and writes a contract describing the terms of repayment. There is asymmetric information in the form of costly state verification: once the project is completed the actual revenue received is known only to the entreprenuer and not to the investor. If the investor wants to find out the actual revenue, she has to run an audit which costs her 1 unit of output.
The contract between the entrepreneur and investor specifies, for each value of revenue, the payment to be made to the investor and whether an audit is to be run. It is expected that once the project is complete the entrepreneur will announce a revenue. If the contract does not specify an audit for that revenue level then the entrepreneur simply pays the amount specified in that contract for that revenue level. If the contract specifies an audit for that revenue level then the investor pays 1 unit of output to carry out the audit and then the entrepreneur has to make the payment specified for the actual revenue earned (which is revealed by the audit).
Both the entrepreneur and the investor are risk-neutral, i.e. they care only about their expected earnings. For the investor this is the earning net of any audit cost.
Our goal is to specify a contract which is incentive-compatible — the entrepreneur announces the actual revenue earned — and efficient — there is no other contract which can make one of the parties strictly better off without making the other party worse off.
Program Usage
The program interactively accepts a contract specification and reports whether it is feasible, incentive-compatible and efficient or not. If it is not incentive compatible it reports the conditions under which the entrepreneur lies. If it is not efficient then the program demonstrates another contract which makes the entrepreneur better off without making the investor any worse.
An example session
When run the program prints a banner with some usage information then then waits for the user to enter a contract.
Incomes, p: [(0.0,0.2),(2.0,0.2),(4.0,0.2),(6.0,0.2),(8.0,0.2)].
Audit cost: 1.0
Enter entrepreneur's payment for each state separated by commas
Put a '*' after a payment to denote a verified state.
For eg: 0*,2*,4,4,4
The audit cost is payed by the investor.
Type 'q' to quitA infeasible contract
> 0*,3*,4,5,6
Invalid: Claim greater than incomeA contract which is not incentive compatible
> 0*,0*,4,5,6
Untruthful: 6.0 -> 4.0, 8.0 -> 4.0The entrepreneur has an incentive to announce a revenue of 4.0 when her true revenue is 6.0 or 8.0.
An inefficient contract
> 0*,0*,0*,4*,5
Inefficient
Your contract pays Ent=2.20, Inv=1.00
Try: 0.00*,1.50,1.50,1.50,1.50
which pays Ent=2.80, Inv=1.00A Pareto superior contract is printed out as evidence of inefficiency.
An efficient contract
> 0*,2*,3,3,3
Your contract is efficientCode
The code is available on Github here.
The program is fairly simple. It uses
haskeline
for the command-line interface and
Parsec for
parsing the contract specifications entered by the user. This was my first-time using Parsec and I found it really pleasant to use. The parser function which takes a string of the form "0*,0*,2" and returns [(0.0,True),(0.0,True),(2.0,False)] is just:
parseContract::String->Either ParseError Contract
parseContract = parse (contractP <* eof) "<interactive>"
where
lexer = makeTokenParser emptyDef
contractP = entryP `sepBy` symbol lexer ","
entryP = do
claim' <- naturalOrFloat lexer
let claim = case claim' of
Left i -> fromIntegral i
Right d -> d
verified <- option False (symbol lexer "*" *> pure True)
return (claim,verified)