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.
> 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.
That is true. But it makes it much easier for potential investors to load up a bond in their own modeling tools, and run their own scenarios. They don't have to reverse engineer the cashflow structure based on the legal wording in the prospectus.
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.
> 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.
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.
> > The hard part is predicting the likelyhood of various events. This proposal does nothing to address that problem.
> 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.
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" 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?
"... 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!
It'd be incredibly stupid. The language and some other programming languages don't even have proper standards written out or they change on the whims on their creators or community. Which version of Python will you use? 2.x or 3? Oh hey and will you use the map and filter functions or use generators instead or maybe you'll use a for-loop? What are the rules for that?
Don't kid yourself, there's still a lot of room for ambiguity.
You may be able to obfuscate the code, but so long as the investor can easily test your model with values of their choice, it doesn't matter if you use a map or a for-loop.
Is a monkey-patching friendly language really the best thing for this? (Asks the Smalltalk guy, whose language is just as monkey-patching friendly and is used in a lot of Financial apps.)
Functional languages would be much better for this purpose.
Python has some FP features. More importantly, it's incredibly easy to learn, available on just about every platform (JVM users and .Net users can use it, Mac, Linux, Windows, etc).
Python has some FP features. More importantly, it's incredibly easy to learn, available on just about every platform (JVM users and .Net users can use it, Mac, Linux, Windows, etc).
Yes, but having "some FP features" is a far cry from being able to use FP to do lots of reasoning about your program.
It's not intended to be a complex statistical model. It's intended to replace XML Files that may have included calculations, with a system that allows people to plug their assumptions into the program and get an answer, rather than parsing XML and turning that into a program.
My understanding is that the type of calculations they're talking about, if you need complex Functional Programming you're doing it wrong.
Good languages actively fight off poor programming. Take ML or Haskell: if you didn't think about the problem well enough beforehand, it won't compile.
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.
I'm sure someone will apply Gödel's incompleteness theorem to the Python syntax, and complain that they want to do something that isn't expressible in python (or any other language you choose).
If this works well, this might cause more legal fields to work with computer languages, enable more legal automation , and could be really disruptive to the legal profession.
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".
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?
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...
Decorators, generators and all the other syntactic sugar that's been added over the years is already too much experimentation with obfuscation for my liking.
Heck, just pushing up the demand for Python devs is a good thing. Rising tide lifts all boats. Probably indirectly raise the boats of non-Python devs as well.
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.
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 ?
Maybe so, but first we need to consider the requirements:
- 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.
I think for financials it should be Python. It is perfectly fit for it and a DSL would only further cloud the amount of people that can easily look at the operations. I think Python is perfect for open financials and maybe gov't.
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:
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.
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.