Tuesday, November 10, 2015

policy of money as a unit of account

A lot of my conclusions here aren't much different from those of a previous discussion, but I'm going to frame/derive them slightly differently.

Suppose two agents are exogenously matched and given an exogenous date in the future for which they can construct a bilateral derivative; maybe we even require zero NPV, or maybe we allow for some cash transfer now, but either way if they're infinitely clever (and assuming e.g. that they don't anticipate future opportunities to insure before that date, etc.) then I believe the negotiations should leave the ratio of marginal costs of utility for the two agents at that date pre-visible. If we add constraints we modify that, but probably in relatively intuitive ways; if we can only condition on certain algebras of events (coarser than what would in principle be measurable at the final date), for example, then there's an expected value on each of those events that should give the same ratio, and if in some states an agent is unlikely to be able to make a payment, that agent is allowed to be better off than the other agent in that state relative to the usual ratio. Further, if there are a bunch of pairs of agents doing this, and the agents can be put into large classes, but need then to have very similar contracts, I'm probably doing more averaging over agents in each class.

I don't know whether this gets me any closer to an answer, but perhaps this is a useful framework for thinking about monetary policy as the medium of exchange consists increasingly of electronic (even interest-bearing) accounts and centrally-managed money is mostly about the unit of account. Buyers and sellers and debtors and lenders still referencing a given unit of account will tend to have certain risk similarities intraclass and differences interclass that one can try to optimize; if a surprise causes borrowers more pain than lenders, I try to weaken the unit of account, and if a surprise causes sellers more pain than buyers[1], then I try to strengthen the unit of account, and everyone ex ante looks at this and says "doing my contract (legal and explicit or customary and implicit) in this unit of account affords me a certain amount of insurance".

[1] A further note on the inclusion of "buyers" and "sellers" here: on some level this only matters for forward contracts, i.e. if we're entering an agreement to an immediate transaction there's none of this sort of uncertainty that resolves itself between the creation of the contract and its conclusion. Parties to a forward contract take on a lot of the properties of borrowers and lenders, insofar as there is a (say) dollar-denominated transfer in the future to which they've committed. Further, in principle borrowers, lenders, and parties to forward contracts can, as above, create their own risk-sharing contract. As a practical matter, of course, this is likely to be impossible to do perfectly, and it's likely that the extent to which it can be done practically leaves a lot of room for a central bank to come in and improve things. This is a usual theory-meets-practice kind of dynamic, especially in monetary theory; somewhat famously, perfect Walrasian economies don't need money, so a useful theory of money will have to figure out what parts of reality outside of Walrasian economics matters, and incomplete contracts would seem to be a biggie.

I believe, though, that more important than difficulties in contracting formally are informal contract-like substances that result from various incompletenesses in information. Buyers and sellers form long-term relationships that may be "at will" for each party, but are formed typically because one or both parties would incur some expense in looking anew for a counterparty each time a similar transaction was to take place. It seems likely to me that this would result in similar long-term dynamics to a contract, and is likely to involve prices that are sticky in some agreed-upon unit of account, whereupon a benevolent manager of that unit of account would again be trying to optimize as discussed above.

No comments: