Slashdot Mirror
SEC Proposes Wall Street Transparency Via Python
An anonymous reader writes "A US federal agency is considering the use of computing languages to specify legal requirements. 'We are proposing that the computer program be filed on EDGAR in the form of downloadable source code in Python. ... Under the proposed requirement, the filed source code, when downloaded and run by an investor, must provide the user with the ability to programmatically input the user's own assumptions regarding the future performance and cash flows from the pool assets, including but not limited to assumptions about future interest rates, default rates, prepayment speeds, loss-given-default rates, and any other necessary assumptions.' Does this move make sense? If the proposed rule is enacted, it certainly will bring attention to Python or other permitted languages. Will that be a good thing?"
The above quotes were pulled from pages 205 and 210 of the dense, 667-page proposal document (PDF). Market expert and professor of finance Jayanth R. Varma says it's a good idea.
I think a lot of those wall-street types would suddenly admit to everything they've done wrong if you confront them with a big enough Python...
Now, in addition to lawyers and accountants, you need computer programmers to invest. This smells like a racket. On the other hand, it can't get any worse than the legalese, and maybe that is the point.
Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
This would be a fantastic idea. Not only would the rules be transparent and non-ambiguous, but the potential for experimentation and self-analysis would be incredible. Python is definitely one of the better languages to use for this, as it tends to be very readable and self-explanatory as far as programming languages go.
I love Python and I would hate to see it abused this way.
Ruby Neural Evolution of Augmenting Topologies
Maybe if the languages accepted are functional, and therefore logically provable without side-effects.
meh
If you want to confront the devil, a programming language is a good place to do it, since it's all about the details.
Any legal framework, if it does include a specific language, should be based on what the common languages that are currently used, i.e. they should have company XYZ submit that they are using language "ABC" and here is the source code. The problem with mandating a particular language(s) is that these are subject to change with time. A legal framework should stand the test of time, and thus not include requirements for "Python". Python might not exist in five years, or may become obsolete in five years.
downloaded and run by an investor, must provide the user with the ability to programmatically input the user's own assumptions regarding the future performance and cash flows from the pool assets, including but not limited to assumptions about future interest rates, default rates, prepayment speeds, loss-given-default rates, and any other necessary assumptions.'
...it is forbidden to have a straightforward sentence with less than two conjunctions.
'We are trying to prove ourselves wrong as quickly as possible, because only in that way can we find progress.' RPF
Something that needs to be considered is the existence of so called "Filing Agents". I work for such a business.
Right now, the SEC requires companies to file documents in a specific subset of HTML, as well as (in some cases) XBRL, which is an XML-based reporting language. In some rare cases, documents are another type of XML, or even specially formatted ASCII documents (ugh).
Securities lawyers and company administrators don't want to understand the highly technical processes involved, so they outsource their technical reporting requirements to filing agents. We take care of all the nitpicky details that they don't want to consider. Looks like we'll have to learn Python as well. We've been meaning to graduate from Perl anyway, so no big deal. :-)
Occam's Razer does not apply to matters of finance. Ever.
'We are trying to prove ourselves wrong as quickly as possible, because only in that way can we find progress.' RPF
ECMAScript or JavaScript would be a much better language to make this requirement for. Python would be a mistake. JavaScript is a much more limited language in terms of dialect and concepts and is much more neutral than Python is; yet JavaScript can express nearly any level of complexity. It is also readable by majority of the programming world. It is also an excellent data transport language. Python is not readable by the majority of the programming world. It is also terrible as data transport language.
JavaScript is about as neutral a language as you'd be able to find. Plus it is ubiquitous and public financial calculations and records could readily be used in straight HTML/JavaScript webpages - no plugins or server code necessary.
I can see it already, the financial institutions will all cry "but these magical formulas are what makes us money and if we make them available our competitors will be able to use them too"! And of course they would also scramble to hire some of the winners of the Underhanded C Contest: http://underhanded.xcott.com/
Frankly using a mathematically provable means of describing all manner of (if not all) legal requirements would be an excellent idea. The notion of gray-areas wherein judge and jury have traditionally run wild would be non-existent. One could apply legal requirements to any case with absolute confidence of the outcome regardless of venue. Court proceedings would consist of nothing but what they were intended to consist of, the determination of givens.
Two of my imaginary friends reproduced once
Just remember that one instance of the class of person may never touch another instance of the class of person's privates. You need to use protected for that.
Science advances one funeral at a time- Max Planck
actually... they were selling a car with no brakes... claiming it is safe, then taking out a life insurance policy on the sucker they sold it to.
The Street has always been full of sharks, now you want to allow snakes?
09 F9 11 02 9D 74 E3 5B - D8 41 56 C5 63 56 88 C0 45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
def getPerformance(self, assumptions):
"""Return performance estimates.
Arguments:
assumptions: dict, for keys see spec #54
Returns:
How much money you will make
"""
# BUG 91423: was sometimes giving poor results
# workaround fix is to ignore assumptions.
return "Millions and millions"
So rather than actually explain what the item is, they'll just build a model of what it is, and let you put in your own assumptions.
So we'll create a bunch of programming overhead, and end up with huge improvements.
Namely that iInstead of descriptions nobody reads or understands, we'll have programs nobody runs or understands.
I've got an idea, I know it might sound crazy but here it goes.
If you see someone selling a great deal, but you don't quite get what they're selling, how it works, or even why it's such a great deal, DON'T BUY IT.
We could even impose this on industry, maybe make it a legal/ethical requirement that people moving around large sums of money act with due diligence or something.
If people actually stuck to this, and only bought things that they understood and made sense to them, the companies making these confusing products that nobody understands would have to make simpler more straightforward products.
These guys need to step back, and make products that THEY understand. If the designer of the product can't figure it out, it's too confusing. If none of the potential customers can understand it, it's too confusing.
Really if they currently can't implement the description, how does documenting it in python make it any better?
> cat test.legalese
The said variable 'i' hereafter referred to as "i" shall be a variable and not of unvarying or constant except for the purposes of using the said variable within a clausal computation and shall be initially equated to 1 (one) neither less nor more and "i" shall be displayed to a third party within visual distance from the visual display device but not beyond unless further provision is granted and provided by the creator of the said work. These courses of action shall be repeated for 10 (ten) times neither more nor less withstanding any systemic error which may cause the premature termination of the said operations and includes the increment of "i" by 1 (one) in a positive monotonic uniform manner performed prior to each display to the visual display device. Upon termination of the aforementioned operational sequence the operations shall cease until recommenced upon instruction of the operator.
> glegalese test.legalese
> a.out
1
2
3
4
5
6
7
8
9
10
>
Well, this is not entirely without precedent. Even the field of Physics employes this method of specifying things that are complex enough that warrant a "model" which is highly dependent on what the model chose to include or exclude. For example, in tracking satellites, you would think that you should be able to use Physics and the myriad of formulas alone to come up with the position of satellites. But because real world physics (think drag, friction, N-body G forces etc) is too hard to figure out and are often hand-waved away (thus the model), NASA had to devise a set of algorithms to communicate a way to track satellites. They then publish the telemetry at regular intervals which are then run through those algorithms to find out where any of the satellites are at any given time. Last I worked on it, I was looking at Fortran programs which was used as the spec for the algorithm. Now, think about it, how better to describe an algorithm than an actual working program?
see: SGP4 and this in particular.
COBOL was supposed to be about making everything clear and obvious in a business environment. But given the current business world it's time to give obfuscated-perl, brainfuck ( http://en.wikipedia.org/wiki/Brainfuck ), or whitespace ( http://en.wikipedia.org/wiki/Whitespace_(programming_language) ) a fair chance.
OK, how about if instead of providing mileage ratings that car advertisements simply had a URL to a Python program that if you entered information about your driving habits that it would come out with an MPG value for a specific car. Obviously, there would be a completely separate Python program for every single car.
Of course, 99% of the weighting would be handled by the questions "Do you drive with a lead foot?" and "Are jackrabbit starts your normal mode?" But the other 34 questions would be there as specified by the government regulation governing the production of these Python applications.
Having a model and the user gets to make up the assumptions, you are getting a traditional garbage-in, garbage-out algorithym. Any model can conform to any belief system given the "proper" inputs. Isn't this half of what the climate arguments are about? Not the code, but the assumptions being pushed into the model?
I can't imagine that this would provide the average Joe Sixpack any useful information. I would say this isn't "transparent" in any way - unless the inputs to the model were published and required to be adhered to. This would make legally binding assumptions like in 2050 there will be fewer literate people than in 2000. I'd like to see the government come up with a plan for that.
Or worse, if a fundamental assumption of the model is rising interest rates and every investor makes 100% return in five years, great. Does the ability to push out a program that says if you enter the five year interest rates as steadily rising then justify advertising that every investor will make 100% of their money?
This also reeks of the idea that if you can't read a programming language you are a second-class citizen. Richard Stallman would be proud.
This would not have prevented the current financial crisis and it will not prevent the next. It's a small step in the right direction, however. The SEC has been one of the most incompetent agencies for some time and I think they're trying to turn themselves around. In this case the SEC is simply acting like a grown up overseeing a bunch of kids. You want to offer a complicated financial instrument to the public, you document it precisely. There's value in this: For example, you couldn't possibly have a third party clear and settle a financial instrument without some ability to do a valuation. A minimum requirement would for that be code describing the instrument's payoffs. This is just one small step towards a world of greater transparency and financial interoperability.
Keep in mind people don't like computers, programs, math or finance. You have to consider that. So I've gone on Wikipedia and did a search on a computer language that produces *minimal* code.
I briefly glanced only at the first sentence from the following page (http://en.wikipedia.org/wiki/Brainfuck) and trimmed the first sentence for length: "The brainfuck programming language is ... noted for its extreme minimalism.". See, this is what people want, it keeps things simple.
What is the difference in Gambling and Investing?
Whether the odds are with you or against you.
After all, I am strangely colored.
This seems to me to be only valid for long term funds invested in bonds and Treasuries or something.
It applies to CDOs, and perhaps to the broader class of structured investment vehicles. Nothing an individual investor is likely to meet face-to-face. (But your mutual fund manager most likely is wrangling with these beasts...)
Isn't the bulk of what brought the house of cards down either unknowable, in denial, or covered over with Enron type mark to market delusions?
Yes. But denial and deception are made much easier when no one really understands the investments they are making.
I understand the theoretical aspect of codifying some set parameters around an investment fund under which returns could be computed on a range of conditions, and that it couldn't be an attempt to capture business method criteria used in trading.
The purpose here is not just to publish a predictive model. Rather, it's to publish an algorithm that can over time be populated with the actual data on the return of underlying assets (e.g. mortgages), and based on that data give a definitive answer as to which tranche of the investment will receive what payments. The point seems to be twofold: (1) There is presumably less opportunity for litigation when the formula for payout on the investment is precisely specified in code; and (2) By providing an algorithm that exactly describes the investment, it is at least in theory possible for potential investors to understand what they are buying.
I just don't see how the mortgage backed funds such as derivatives fo example could be codified since these people didn't know and quite frankly didn't care what was in them,
Someone (e.g. Paulson & Co) knew and cared what was in those derivatives. Problem is, not everyone had the same level of knowledge. Transparency helps any market.
they counted on a sham ratings scam to say that they were of such and such value
The ratings agencies were often tasked with writing models to describe the investments they were rating. These models were proprietary information, available to investors at the rating firm's discretion, if at all. At least here, the models will be out in the bright light of day, for anyone who wants to examine and try to understand.
2) Badly written laws can just as easily be written in Python as they can be in some human language. Judges etc are normally far more familiar with the official language of the courts.
Yes, but there's a very practical difference here. It's all too common for lawyers to respond to questions about a new law's actual meaning with "We don't know yet; we'll have to ask the court system". This can be and is done; it's not unusual for new laws to trigger a number of court tests to determine the actual legal meaning of the law.
The problem is that this can be expensive, in both time and money. Court tests can take years and millions of dollars.
If the "spec" for a law were coded in Python (or some other language with a public spec and implementation), tests of such laws could be conducted in minutes, with negligible cost. Of course, this would require paying expert programmers who are familiar with the language. But a few hours of such a programmer's time would be orders of magnitude cheaper than months or years of legal costs.
This is really the same argument as the reason that most business computing is now done by computers. Yes, all the calculations could be done by hand, by human accountants using pencil and paper. But this would mean paying large teams of professional accountants for months of work to do what a computer can do in a few seconds for a few dollars (when amortized over the computer's lifetime ;-).
There are, of course, a lot of practical problems with software "solutions" to legal problems. We're all familiar with the difficulty of writing bug-free software. But again, this is not materially different from the difficulties in writing bug-free legislation. The difference is mostly that the software form could be testable in seconds rather than years, for a few dollars rather than millions of dollars.
And, of course, the opportunity for bribery and fraud in the software testing is nonzero. This is similar to the possibility of bribery and fraud in the legal system. It's just faster and cheaper.
A major difference is that a software process is (in principle) totally documentable. This isn't true of the legal system, most of which is hidden from public view and unknowable to those not directly involved. Software tests can easily be recorded and published.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.