ACM weighs in on SEC proposed Python requirement
sec.gov
sec.gov
http://www.sec.gov/rules/proposed.shtml
Look for 33-9117.pdf
Interesting questions based on my reading from the pdf (see excerpt below, italics by me): If it's not currently practical to evaluate an investment before making an investment decision, why would you make the decision to invest? <cough,cough, index fund, cough>
Next, who wants to do a constraint-programming back-end web app that takes a prospectus and generates this functional code? How much would institutions pay us for this?
From the pdf:
"The ABS issuer or the underwriter generally will have a computer model of the waterfall. However, the issuer or underwriter currently has no obligation to share the computer model with actual or potential ABS investors. Because prospective investors in ABS typically do not have access to the ABS issuer’s computer models, under current conditions, an investor must create its own computer program. It does this by taking the priority of payment rules stated in the trust agreement, pooling and servicing agreement, indenture, or other operative document for the ABS and described in the prospectus, converting the English language statement of those provisions into one or more algorithms, and then expressing the algorithms as computer code in a programming language. As a practical matter, it is often not possible to complete these steps before making an investment decision. This is particularly onerous for smaller institutional investors, for whom it may not be feasible to acquire the financial and technological expertise necessary to develop a computer program of the waterfall. Thus, investment decisions with respect to ABS may be made without the benefit of the investor performing its own quantitative valuation analysis. This may encourage undue reliance on the determinations of credit rating agencies. Further, there is the possibility that some investors will program the waterfall erroneously, leading to inaccurate ABS valuations."
I'm only half way through reading it, but these don't seem to be Python-specific objections. A big part of it seems to be contesting the logic behind choosing Python, and they also suggest that there should be a process for having other languages declared acceptable for this purpose. They also worry that differences in versions/implementations of a language may lead to problems with reproducibility
If it were me, I would be tempted to say that they can write it in anything, so long as they offer a compiled version that targets the JVM. But I might not have given it enough thought and they probably need more requirements than that.
My advice: don't buy that one!
I say let people code however they want, and the market will decide!
For me the deal killer about Python in particular is that it uses native arithmetic, which means that going from machine to machine, and operating system to operating system any program that uses floating point will have unspecified behavior.
I've worked in finance and dealt with programs that use floating point. I've encountered the fact that behavior changes on different machines. Now a 1 or 2 penny difference on a several million bond flow may seem unimportant, but it is unfortunately very important because the first thing anyone in finance does to verify that two numbers match is look at the first digits, the length of the number, and the pennies. If those agree, you move on.
So those insignificant penny differences are unfortunately the first thing that gets noticed. Been there, done that, not fun.
Or perhaps a better generalization of my question: is there any language which won’t be abused horribly by Joe random bond issuer? Python seems like a pretty good choice for minimizing the damage a clueless guy can do, and making it as possible as can be hoped for others reading even awful code to figure out what it does.
It shouldn't. But you would be amazed how much bad code there is out there. A lot of it just uses floating point arithmetic because it is easy. (Actually for Monte Carlo simulations it isn't even a bad idea. There speed matters over precision.)
(Furthermore you get fun issues when you add in the complication of having multiple currencies that vary against each other.)
100 cents instead of 1.00 dollars
On a 32-bit machine, using native integers limits you to $40 million dollars or less ($20 million or less if you have to use signed integers). Double precision floating point gives you something like 52-bit integers.
When dividing, you would have to explicitly use floor, round, or ceil to make the result be an integer.
It's Phil Wadler's version of "what color is your bikeshed?"
None of their arguments seems to preclude some compiled subset of Python, e.g. what you can feed into the shed_skin compiler (plus some sandboxing...)
SEC is proposing that prospectuses (prospecti?) for asset backed securities include a simulator written in Python. The investor can use this simulator to test out the behavior of their investment under various conditions.
Fascinating idea, I wonder, though, what is going to happen when the simulator and the prospectus disagree. I would assume the text of the prospectus would override the source code. It is going to be quite a challenging task trying to align legalese and Python, or any other programming language for that matter.
However, as I understand the proposal, most such legal problems would be irrelevant as far as the python program is concerned. The python program would only answer questions like "what happens if party XXX becomes insolvent" or "what if 84% of mortgages are repaid, 10% are prepaid and 6% are in default". Most legal disputes would center on issues like "were material factors relating to mortgage repayment rates properly disclosed" or "are former home borrowers currently squatting 'in default' or merely 'delinquent' if the mortgage servicer has failed to evict them". The answer to questions like these is simply the input to the python program.
However current practice is that the prospectus also describes, in legalese, the rules by which you determine what happens if party XXX becomes insolvent, or what happens if 84% of mortgages are repaid, 10% are prepaid and 6% are in default. And then there are multiple scenarios supplied to clarify people's understanding of how those rules work.
There is a cottage industry that basically consists of taking these prospectuses and creating computer versions of them. This is called reversing a deal. I've seen these models take anywhere from a day to a week for simple models, and for complicated ones outside specialists may need to be used. These models are considered valuable property, and so a given deal may wind up being reversed by multiple people. These created models often do not agree with each other or the servicer.
If the prospectus continues to contain the authoritative explanation, then this activity is still a necessary sanity check. If the script is definitive, then this error-prone step can be greatly streamlined and automated. Getting rid of this expensive activity strikes me as a very good thing.
Disclaimer, I used to work for a company whose main job was reversing deals, and then keeping models up to date as the cash flows came in. I did not work on that side of the business, but I've seen how important it is.
Users (non institutional investors?) will download a program with the asset backed security information in a separate XML file, use that file to perform their own analysis of the possible performance and cash flow (called the waterfall in the proposal) to make an individual determination of the actual value of an ABS pile of investments.
You've got to be kidding me, right? This is how we are to increase transparency in pooled ABS investments?
Forget the fact that the ACM is weighing in on the appropriateness of Python as the program's implementation language here - say there is a bug in the implementation of the program that allows you to model this waterflow cash flow. Who can I sue, if as an individual investor, I relied on this implementation (along with my subtle tweaking of simulation variables) to make an investment decision?
Forgive my naivete, maybe I've made a bad assumption about what the program is supposed to actually reflect. Does it represent a firm contract or rule set about how cash flow in the ABS pool will work given certain inputs?