Will Wall Street require Python?
itworld.com
itworld.com
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.
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.
Actually, it does. It lets you, as a potential investor, plug in your own values to the model. So if you think the issuer is undervaluing the default risk, you can use your own default risk numbers and remodel just by changing some values in a XML file or Python script and then running the interpreter again.
Of course, you need your own predictions for the likelihood of various events, but you could even just toss in a "default_risk = default_risk*1.5" line if you wanted to.
> Actually, it does.
Actually it doesn't. As you wrote later
> Of course, you need your own predictions for the likelihood of various events,
That's the hard problem.
> It lets you, as a potential investor, plug in your own values to the model.
Right. It does nothing to help you figure out what those values should be. It merely tells you the consequences of whatever values you use.
Expressing how payout works as a python program does nothing to help you figure out whether 10% of the mortgages in a given portfolio will go into default. It only lets you compute the consequences of that event.
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.
The "in python" rule doesn't provide any information about what's in the package.
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
That said, any required language should be fully formally specified -- what's the semantics of a Python contract? Implementation defined? A testsuite?
If this was actually implemented, it'd be incredible. No more ambiguity when you have to define all the parameters and outcomes explicitly!
(Actually something as straightforward as a de-crufted PHP with APL's matrix handling would be a pretty wonderful language, when you think about it.)
EDIT: oh, and that annoying halting problem...
Functional languages would be much better for this purpose.
Also, Python is clearly a step up from English on a variety of metrics, including the reduction of the ability to monkey-patch.
Yes, but having "some FP features" is a far cry from being able to use FP to do lots of reasoning about your program.
My understanding is that the type of calculations they're talking about, if you need complex Functional Programming you're doing it wrong.
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?
So this is definitely a big improvement.
But my point remains that it is not perfect. There still are ambiguities.
Don't kid yourself, there's still a lot of room for ambiguity.
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".
> 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...
The more I think about it, there should be a DSL for all laws. (Something better than the legalese dialect of English, at least.)
A DSL whose programmers are lawyers and whose interpreters are courts.
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.
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 ?
- There's a reference implementation, because the whole point is that the asset specification is executable
- At least one implementation is open-source, so it can be validated independently (could compromise here, but why bother these days), and cross-platform
- Financial-industry programmers, including investors, are already familiar with it and want to use it
- More readable and concise than legalese (since the goal is transparency)
- Has a built-in XML parser, or simple bindings for one, since XML configuration is another part of the proposal
I'm not sure how important type-checking or automatic code verification is here, but since Python was even mentioned in the proposal, it must not be crucial -- the main point is that investors can download the code and play with it. If the emphasis was more on creating a rigorous specification of how things work, I'd expect SML or maybe Prolog would be at the top of the list.
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.
should be: "Will Wall Street import Python?"
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"]).