TITLE: Computer Code in the Legal Code
AUTHOR: Eugene Wallingford
DATE: April 20, 2010  9:58 PM
DESC: 
-----
BODY:
You may have heard about a
<A HREF="http://www.sec.gov/rules/proposed/2010/33-9117.pdf">
   recent SEC proposal</A>
that would require issuers of asset-backed securities
to submit "a computer program that gives effect to the
flow of funds".  What a wonderful idea!

I have written a lot in this blog about programming as
a new medium, a way to express processes and the
entities that participate in them.
The domain of banking and finance is a natural place
for us to see programming enter into the vernacular as
the medium for describing problems and solutions more
precisely.  Back in the 1990s, Smalltalk had a brief
moment in the sunshine as the language of choice used
by financial houses in the creation of powerful,
short-lived models of market behavior.  Using a
program to describe models gave the investors and
arbitrageurs not only a more precise description of
the model but also a <EM>live</EM> description, one
they could execute against live data, test and tinker
with, and use as an active guide for decision-making.

We all know about the role played by computer models
in the banking crisis over the last few years, but
that is an indictment of how the programs were used
and interpreted.  The use of programs itself was and
is the right way to try to understand a complex
system of interacting, independent agents manipulating
complex instruments.  (Perhaps we should re-consider
whether to traffic in instruments so complex that
they cannot be understand without executing  a complex
program.  But that is a conversation for another blog
entry, or maybe a different blog altogether!)

What is the alternative to using a program to describe
the flow of funds engendered by a particular asset-backed
security?  We could describe these processes using
text in a natural language such as English.  Natural
language is supremely expressive but fraught with
ambiguity and imprecision.  Text descriptions rely
on the human reader to do most of the work figuring
out what they mean.  They are also prone to gratuitous
complexity, which can be used to mislead unwary readers.

We could also describe these processes using diagrams,
such as a flow chart. Such diagrams can be much more
precise than text, but they still rely on the reader
to "execute" them as she reads.  As the diagrams grow
more complex, the more difficult it is for the reader
to interpret the diagram correctly.

A program has the virtue of being both precise and
executable.  The syntax and semantics of a
programming are (or at least can be) well-defined,
so that a canonical interpreter can execute any
program written in the language and determine its
actual value.  This makes describing something like
the flow of funds created by a particular asset-backed
security as precise and accurate as possible.  A
program can be gratuitously complex, which is a
danger.  Yet programmers have at their disposal tools
for removing gratuitous complexity and focusing on
the essence of a program, moreso than we have for
manipulating text.

The behavior of the model can still be complex and
uncertain, because it depends on the complexity and
uncertainty of the environment in which it operates.
Our financial markets and the economic world in which
asset-backed securities live are enormously complex!
But at least we have a precise description of the
process being proposed.

As
<A HREF="http://jrvarma.wordpress.com/2010/04/16/the-sec-and-the-python/">
   one commentator writes</A>:

<BLOCKQUOTE><EM>
When provisions become complex beyond a point,
computer code is actually the simplest way to
describe them...  The SEC does not say so, but it
would be useful to add that if there is a conflict
between the software and textual description, the
software should prevail.
</EM></BLOCKQUOTE>

Using a computer program in this way is spot on.

After taking this step, there are still a couple
of important issues yet to decide.  One is:  What
programming language should we use?  A lot of CS
people are talking about the proposal's choice of
Python as the required language.  I have grown to
like Python quite a bit for its relative clarity
and simplicity, but I am not prepared to say that
it is the right choice for programs that are in
effect "legal code".  I'll let people who understand
programming language semantics better than I make
technical recommendations on the choice of language.
My guess is that a language with a simpler, more
precisely defined semantics would work better for
this purpose.  I am, of course, partial to Scheme,
but a number of functional languages would likely
do quite nicely.

Fortunately, the SEC proposal invites comments, so
academic and industry computer scientists have an
opportunity to argue for a better language.
(Computer programmers seem to like nothing more
than a good argument about language, even writing
programs in their own favorite!)

The most interesting point here, though, is not
the particular language suggested but that the
proposers suggest any programming language at all.
They recognize how much more effectively a computer
program cab describe a process than text or diagrams.
This is a triumph in itself.

Other people are reminding us that mortgage-backed
CDOs at the root of the recent financial meltdown
were valued by computer simulations, too.  This is
where the proposal's suggestion that the code be
implemented in open-source software shines.  By
making the source code openly available, everyone
has the opportunity and ability to understand what
the models do, to question assumptions, and even to
call the authors on the code's correctness or even
complexity.  The open source model has worked well
in the growth of so much of our current software
infrastructure, including the simple in concept but
complex in scale Internet.  Having the code for
financial models be open brings to bear a social
mechanism for overseeing the program's use and
evolution that is essential in a market that should
be free and transparent.

This is also part of the argument for a certain set
of languages as candidates for the code.  If the
language standard and implementations of interpreters
are open and subject to the same communal forces as
the software, this will lend further credibility to
the processes and models.

I spend a lot of time talking about code in this
blog.  This is perhaps the first time I have talked
about legal code -- and even still I get to talk
about good old computer code.  It's good to see
programs recognized for what they are and can be.
-----