
Will Wall Street require Python? - arockwell
http://www.itworld.com/government/105031/will-wall-street-require-python
======
ctkrohn
Quick explanation of what exactly this is:

It's a rule change regarding asset-backed securities. ABS are a type of bond
where the interest and principal payments come from the cashflows of some pool
of underlying assets. The simplest example is the now-infamous mortgage-backed
security: a bunch of mortgages are put into a pool, and each month the
homeowner's payments are passed through to the mortgage-backed securities
holder (with some amount taken off the top to cover the cost of collecting,
processing, and insuring payments).

There are many generalizations of this concept. There's no reason the
underlying asset has to be mortgages. It could be auto loans, credit card
receivables, student loans, whatever. And there's no reason that the cashflows
have to be passed straight through to the bondholders. This is where Python
comes in.

There are a number of complicated rules you can define. For example, let's
suppose I have $100mm of assets. Rather than just having $100mm in bonds on
the other side, I can define two pieces, or tranches. Tranche A is $80mm and
gets paid first; the $20mm Tranche B gets paid next. So if some assets don't
perform and the $100mm face value only turns out to yield $90mm, the investors
in A are completely unaffected. This method is helpful because it can create a
safe asset out of a pool of generally unsafe assets.

Another possible rule would be again to define two tranches, A and B. Each
month, A and B receive the full interest payments on the $100mm assets. But A
gets the first $50mm in principal, and B only starts getting paid principal
when A is completely paid off. That way, tranche A has a shorter average life
than the underlying pool of assets, and tranche B has a longer average life.
This is helpful because some investors might want to buy short-term assets,
but others might want to buy long-term assets.

You can define a hugely complex range of rules, depending on the purpose of
the investment and the type of underlying asset. From what I can tell (I
obviously haven't read the whole document), the SEC is proposing to require
ABS issuers to specify these rules in Python, and to specify the underlying
asset pool in an XML format. This will make it easier for independent
investors to analyze the securities on their own, without having to let the
now-discredited rating agencies do their work for them.

In general, sounds like a great rule to me.

~~~
anamax
> From what I can tell (I obviously haven't read the whole document), the SEC
> is proposing to require ABS issuers to specify these rules in Python, and to
> specify the underlying asset pool in an XML format. This will make it easier
> for independent investors to analyze the securities on their own, without
> having to let the now-discredited rating agencies do their work for them.

Except that this just makes it easier to figure out who gets paid given a set
of events, which isn't the hard part. (Yes, there can be lots of rules, but
....) It's also not where the ratings agencies screwed up.

The hard part is predicting the likelyhood of various events. This proposal
does nothing to address that problem.

~~~
WarDekar
Part of the problem with the mortgage bubble though was that no one (other
than a very select few, that were shorting them by buying CDSes) really knew
what was in all the mortgage bond derivatives, especially once they got put
into CDSes and then re-packaged into CDOs. By the end of it even the people
that knew what was going on had to spend tremendous amounts of time figuring
out what specific mortgages were in what packages, whereas under the new
proposed rules at least all that information will be available up front (in
theory).

And as sibling comments say- once you know what's actually in them, you can
use your own risk models. If you don't know what's in them, tough to do that.

~~~
anamax
> By the end of it even the people that knew what was going on had to spend
> tremendous amounts of time figuring out what specific mortgages were in what
> packages, whereas under the new proposed rules at least all that information
> will be available up front (in theory).

The "in python" rule doesn't provide any information about what's in the
package.

------
kurtosis
Well I love python, but this reminds me of a set of an old paper by Peyton-
Jones of GHC fame, which developed a Haskell combinator lib that did something
like this. I'm sure the state of the art has left this system long behind, but
it's a pretty interesting concept.

Composing contracts: an adventure in financial engineering, Simon Peyton
Jones, Jean-Marc Eber, Julian Seward. ICFP, 2000
<http://www.lexifi.com/downloads/MLFiPaper.pdf>

See also: <http://homepages.inf.ed.ac.uk/wadler/realworld/lexifi.html>

~~~
dons
"Composing Contracts" launched much of the use of FP in the finance industry.
It was specifically cited in Credit Suisse's use for modelling contracts, for
example.

That said, any required language should be fully formally specified -- what's
the semantics of a Python contract? Implementation defined? A testsuite?

------
hakan
"... with Release 33-9117, the SEC is considering substitution of Python or
another programming language for legal English as a basis for some of its
regulations."

If this was actually implemented, it'd be incredible. No more ambiguity when
you have to define all the parameters and outcomes explicitly!

~~~
btilly
_No_ ambiguity?

Suppose the deal goes out there, bonds are sold, but then real world inputs
result in an endless loop. What happens to the money then?

~~~
wtn
Same thing could happen with human language legal copy.

~~~
btilly
Absolutely agreed. In fact all sorts of conflicts and ambiguities can easily
get missed, as well as ambiguous terms such as the bond issuer _at its
discretion_ can rearrange payments. (Yes, this has happened. And money was
diverted from top tranches to lower rated ones.) Furthermore the entire
reverse engineering process is a lot of work for a very imperfect result.

So this is definitely a big improvement.

But my point remains that it is not perfect. There still are ambiguities.

------
ig1
To some extent financial transactions are done on the basis of code anyway.

It's not unusual for transactions to specify a price based upon an agreed
software-as-a-service calculation, for example an agreement might say "we will
purchase 10,000 shares, on the 12th of May at the price defined by Bloomberg
VWAP (volume weighted average price)".

So rather than the parties having to draft a five page document defining
exactly the criteria used to calculate VWAP (i.e. which trades to include and
exclude) they just say "we'll use the criteria defined by this code".

------
markkoberlein
This could open up a very lucrative market for Python experts.

~~~
thorax
The cynic in me thinks it will actually push the state of the art of
obfuscating Python (which isn't widely experimented with as far as I know).

~~~
arebop
I was under the impression that Wall Street typically develops and hosts in-
house, regarding both algorithms and operations as competitive advantages. Is
that incorrect, or is there some other reason to obfuscate?

~~~
thorax
The SEC proposal in question is talking about making these available (publicly
if I read this correctly) when defining new securities:

> _We also are proposing to require that, with some exceptions, prospectuses
> for public offerings of asset-backed securities and ongoing Exchange Act
> reports contain specified asset-level information about each of the assets
> in the pool. The asset-level information would be provided according to
> proposed standards and in a tagged data format using eXtensible Markup
> Language (XML). In addition, we are proposing to require, along with the
> prospectus filing, the filing of a computer program of the contractual cash
> flow provisions expressed as downloadable source code in Python..._

<http://www.sec.gov/rules/proposed/2010/33-9117.pdf>

------
ShardPhoenix
I'd think a DSL would be better for this purpose (defining rules for a
specific type of financial assest) than Python in general.

~~~
branden
You're probably right, but compared to the DSL that hasn't been specified and
that no one has agreed on, Python wins.

The more I think about it, there should be a DSL for all laws. (Something
better than the legalese dialect of English, at least.)

~~~
mseebach
The problem with the law isn't the language of the laws themselves, it's the
input.

I mean, please show me the typedefs for attempted rape and reckless driving.

Most of the time, the interesting cases are about figuring out who's lying, if
there was intent, determining what's reasonably expected, how a certain
condition might count as an aggravating circumstance etc. etc.

~~~
ippisl
Aren't a lot of the work, effort and expertise in legal fields(including
learning) , is about legalese and knowing a lot of laws and cases ?

If at least some of the hard work around being a lawyer and being a judge
could be codified in a computer and automated , lawyers and judges could be
better in the other , harder parts of the legal profession ?

------
ctkrohn
It's also worth noting that this is a minor part of a much larger proposal
that came out more than a week ago. A bunch of media outlets ran stories...
the NYT article is here:

<http://www.nytimes.com/2010/04/08/business/08sec.html>

------
cma
previous discussion: <http://news.ycombinator.com/item?id=1272541>

------
pmb
This is definitely a strongly-typed-language situation.

------
kuahyeow
Why not a framework which uses plain English like Cucumber?
<http://cukes.info>

------
rbanffy
What if the rules are self-mutating bytecode?

~~~
rbanffy
Better yet: what if the contracts become self-aware?

------
ShardPhoenix
I would think a DSL would be more appropriate than straight Python for the
proposed purpose.

~~~
rit
But then you need a standard DSL interpreter platform. For any platform that
investors use. I suspect this is a solid reason to take and use an existing
language.

Saying "You need a standard install of Python 2.6 to execute this", versus
"You need a SECLang 2.6 compatible interpreter with support for Spec version
9.1".

Remember - it's not just about providing a common platform for developers to
build their code. The purpose is to have investors able to run the program,
punch in their assumptions and get numbers out.

------
mkramlich
article title is wrong, this isn't Ruby.

should be: "Will Wall Street import Python?"

------
mkramlich
I don't know if I fully understand or agree with their proposal but I like the
fact that they are trying to innovate.

------
malkia
I would only consider a language with built-in big rational numbers.

~~~
ableal
<http://docs.python.org/library/decimal.html>

~~~
JeremyBanks
That's not rational, this is: <http://docs.python.org/library/fractions.html>

~~~
ableal
You're right (and thanks, hadn't seen that 'novelty' yet).

My reply was more in the vein "what you probably need, not exactly what you
asked" - these not strictly 'built-in' either.

( _That_ could be a bad idea, cf. second and last items of the Zen [python -c
"import this"]).

