Weekly Edition
Return to the Announcements page
| |||||||||||||
The SEC to require filings in Python?
As seen in this
ITWorld article, the US Securities and Exchange Commission (SEC) is
currently contemplating new rules for disclosure around the offering of
asset-backed securities. The proposal, a monster PDF
file, reads: "We are proposing to require the filing of a
computer program (the 'waterfall computer program,' as defined in the
proposed rule) of the contractual cash flow provisions of the securities in
the form of downloadable source code in Python, a commonly used computer
programming language that is open source and interpretive." There
are all kinds of interesting implications, including effects on the
language, security, and more.
(Log in to post comments)
The SEC to require filings in Python? Posted Apr 19, 2010 21:09 UTC (Mon) by ajk (subscriber, #6607) [Link]
How long, I wonder, until the rest of "Accelerando" comes to pass.
The SEC to require filings in Python? Posted Apr 19, 2010 21:23 UTC (Mon) by coriordan (guest, #7544) [Link]
What's Accelerando?
The SEC to require filings in Python? Posted Apr 19, 2010 22:07 UTC (Mon) by nix (subscriber, #2304) [Link] It's a mindblowing SF story by Charlie Stross, on sale and also Creative Commons licensed, so you can find a copy e.g. here. It follows one family and their cat through the Singularity and out the other side. The first three chapters (pre-Singularity) are so highly strung that you might find yourself going into Slashdot overload, but it settles down thereafter.Chapter 2, Troubadour, involves as but one of its ramifying plot elements a tree of continuously replicating corporations whose officers and regulations are Python scripts (their purpose: to hide the ownership of certain intellectual property by trading its rights so fast that nobody can possibly sue the right one to get the property back). It is decidedly dystopian, to my eyes. I really really hope the rest doesn't come to pass.
The SEC to require filings in Python? Posted Apr 20, 2010 13:28 UTC (Tue) by alextingle (guest, #20593) [Link]
I am reading that as we speak. Amazing.
The SEC to require filings in Python? Posted Apr 19, 2010 21:26 UTC (Mon) by alvieboy (subscriber, #51617) [Link]
And Python will be known as "the hacker's programming language", as Linux is known as the "hackers operating system". Black Hat ones.
This is what I am afraid of.
The SEC to require filings in Python? Posted Apr 19, 2010 22:08 UTC (Mon) by nix (subscriber, #2304) [Link]
If the SEC is requiring filings in Python, I'd say we're in more danger of its becoming known as the accountants' and lawyers' programming language. (That is to say, not very much danger.)
The SEC to require filings in Python? Posted Apr 19, 2010 22:22 UTC (Mon) by stumbles (guest, #8796) [Link] Well then its about time other professions have "their" own language, after all business has or rather had its COBOL.
The SEC to require filings in Python? Posted Apr 19, 2010 22:49 UTC (Mon) by rfrerebe (guest, #52117) [Link]
Woo !!!!
ABS or Asset Back Securities is what created the current crisis. Basically you exchange your cash against an asset (ie: an asset such as an house). What happened last year is that people finally understood that they exchanged lots of cash for this asset, but this asset is not "paying back".
How you will be pay back was always obfuscated ($10,000 this year, $12,000 next year and so on).
We will see where it goes
The SEC to require filings in Python? Posted Apr 20, 2010 6:25 UTC (Tue) by jzbiciak (✭ supporter ✭, #5246) [Link] When I saw this, I immediately was reminded of some language on the back of my credit card statement, stating how they compute my finance charge. It's obviously describing an algorithm, but not in a manner that I feel lends itself to unambiguous implementation. Here's an excerpt: Calculation of Balances Subject to Finance Charge ...and so on. It goes on like this for a few more paragraphs! Doesn't this read like someone is reading a program to you? And yet, if you were to sit down and try to write the same program, I imagine you would end up having questions on specific details (in particular, the algorithm for determining "pre-cycle balance" looks a bit fun). With an actual program module codifying the business logic in, well, executable code, you now have an executable spec of what you're agreeing to. You can run simulations and get unambiguous results (at least as far as the model goes). You can also double check the numbers in the quarterly reports more readily. All-in-all, it sounds like a good thing.
The SEC to require filings in Python? Posted Apr 20, 2010 6:36 UTC (Tue) by jzbiciak (✭ supporter ✭, #5246) [Link] Oh, and here's a fun one that changed between statements, probably due to the new Cardholder Bill of Rights that took effect: How We Allocate Your Payments Now that is an underspecified algorithm. "In the manner we determine," eh? That was on my Dec 09 statement. On my most recent statement, though, I do get more of an actual algorithm: How We Allocate Your Payments I actually stand a chance at coding that. In contrast, I can't code up "in the manner we determine" without hearing their determination. At best I can assume the worst. If they were forced to provide Python code and access to the same data their business logic works on to compute my bill, then all ambiguity should go away.
The SEC to require filings in Python? Posted Apr 20, 2010 14:50 UTC (Tue) by drag (subscriber, #31333) [Link]
The best thing to do is just to get rid of the card altogether.
You may think you need one, but you don't. What you need is a debit card (no fees, no interest payments, interchangeable with credit cards during transactions) combined with a saved pool of your own money. Generally you should have enough money to live for up to six months without employment.
These two things combined would provide all the security you need at a dramatically reduced risk and expense.
If you think that you cannot do this then that's a serious problem. Your living beyond your means and the next life crisis you run into (which happens to all people periodically) is going to throw you wildly into debt and you will spend the next ten years of your life making bankers richer while you struggle from paycheck to paycheck.
Nobody ever got rich saving up frequent flier miles on a credit card, nor has anybody ever gotten wealthy from any sort of gimped-out cash-back scheme.
The only really good reason I can think of to actually have a credit card is possibly some of the security features they offer, but in that case all the interest hikes and whatnot are completely irrelevant as you should have that shit paid off immediately. The only thing that matters is the fees and if they start charging you money, you cancel the card.
Also housing was always a really shitty investment. Especially your own home. People get confused because it was always seemed a very _safe_ investment. Investing money into a home means your going to lose a great deal of money. But you make up for it by the added value of continued use of the home.
Probably the only people that should really want to make money from investing into real estate are ones that can afford to pay cash for whatever they are purchasing. For everybody else there are much better and more profitable ways to invest your money.
The fact that housing became such a hot thing that seemed safe while returning a high return should of been a (and was) a huge red flag.
Hmmm.... Posted Apr 20, 2010 14:54 UTC (Tue) by corbet (editor, #1) [Link] You know, I think there can be valid reasons to have a credit card, but I'm not going to expound on them here because this is not a personal finance site. One could argue that the original post was marginally off-topic, but this conversation has now gone far off. Maybe it would be better continued somewhere else?Thanks.
Hmmm.... Posted Apr 20, 2010 15:15 UTC (Tue) by jzbiciak (✭ supporter ✭, #5246) [Link]
Agreed. Allow me to distill my original point, since it seems to have been lost.
My main point was that this financial document had a poorly specified algorithm on it that would have been better specified if it were available in program code. If, as a general practice, such algorithms needed to be specified in actual code, I see that as a good thing. I also feel this isn't confined to asset backed securities, which is why I happened to use a different financial instrument.
I have the same issue with the engineering specs I write at work: I find replacing paragraphs with code snippets and tables go a long way to clearer understanding. It's extremely difficult to specify something in English in a manner that will be interpreted the same way by all for anything that's remotely complex.
I probably spent too many words making my minor point (and now too many words distilling it). It certainly wasn't meant to start a debate on financial planning or on the suitability of carrying a credit card. In fact, my point had nothing specifically to do with credit cards. I just used one as an example because I had one at hand and it seemed like a perfect example of poor financial algorithm specification in English.
Hmmm.... Posted Apr 20, 2010 15:47 UTC (Tue) by drag (subscriber, #31333) [Link]
That's fine. But I always aim for the simplest and most effective solution to the problem at hand. Which is to point out that it's all just a huge waste of time.
The problem with the previous post is that these algorithms are already done in programming code.
This is not something that some accountant sat down and written out on paper and they used this to determine your fees, fines, and interest rates.
They use programming code originally. That document is designed to provide the minimal amount of information required by law while simultaneously obfuscating and misleading you to the true nature of the algorithms they have had in their mainframes and have been tweaking since the 1960's.
It's a closed source system and if you take it to your logical conclusion your really asking them to open source it. Which they are not going to do and will fight tooth and nail to prevent that.
Plus it probably would not do you much good anyways. They will change the fees, fines, and interests rates based on the changing economic conditions and fortunes of their particular bank; which you will be unable to predict.
Hmmm.... Posted Apr 20, 2010 16:03 UTC (Tue) by jzbiciak (✭ supporter ✭, #5246) [Link] But I always aim for the simplest and most effective solution to the problem at hand. Which is to point out that it's all just a huge waste of time. My use of an algorithm from a credit card statement was an unnecessary distraction, so going off on that tangent was a bit of a non sequitur. If you're saying all financial instruments are a waste of time, well then... why bother commenting on them at all? It's a closed source system and if you take it to your logical conclusion your really asking them to open source it. Precisely. That's what the Python code proposed for these asset-backed securities would need to do, after all. In the case of the ABSes, the waterfall model would be codified in an unambiguous, executable form. Which they are not going to do and will fight tooth and nail to prevent that. Unless they're required to by law, or if the law dictates the algorithm to them.
Hmmm.... Posted Apr 20, 2010 16:26 UTC (Tue) by drag (subscriber, #31333) [Link]
> If you're saying all financial instruments are a waste of time,
Hardly. Credit cards, in particular, are very predatory and banking institutions that use them frequently engage in fraud, lies, and illegal activities to extract fees from their customers.
And I am sorry for going off tangent. It's just a hugely emotional subject and completely and totally irritating.
My point was that the documentation you posted is intentionally misleading and asking them for a source code version of it is not going to help you any. If the banks were really forced to be transparent about the credit card industry it would probably pretty much kill it off since people would recoil in horror about what a huge rip off and lie it all is.
Credit cards are just one step above "paycheck advance"-style cashing services, and two steps below pawn shops when put on a scale of 'Good things to do with your money'.
> Precisely. That's what the Python code proposed for these asset-backed securities would need to do, after all. In the case of the ABSes, the waterfall model would be codified in an unambiguous, executable form.
That's fine and it's very important for people to understand the terms of loans and be able to gauge expenses out long-term.
I am all for transparency. It's very important for a capitalist system that people understand what they are getting into And usually it's not terribly hard to actually determine the true costs of mortgages and whatnot, unless you fall for the traps around adjustable rate mortgages (which is very difficult to determine, because they depend on information input that is nearly impossible to know in advance).
I suppose having a python program would save you the expense of hiring a accountant to make nice spreadsheets that outlay your costs month by month for the next 15-30 years.
> Unless they're required to by law,
Or customers, collectively, got a brain and demanded it before doing business with them.
Either way it's fine by me. Works out the same in the end, probably.
> or if the law dictates the algorithm to them.
Nobody in the government is qualified, nor should they ever have the authority, to set the algorithms for anybody. It would be a disaster.
Hmmm.... Posted Apr 21, 2010 11:52 UTC (Wed) by nix (subscriber, #2304) [Link] If the banks were really forced to be transparent about the credit card industry it would probably pretty much kill it off since people would recoil in horror about what a huge rip off and lie it all is.What a ridiculous statement. It might kill off people using their credit cards as an extra bank account, but anyone doing that is already being foolish with their money: the existing transparency (APR) is quite enough to make it clear that not paying off your card instantly is a bad idea. Credit cards really are more useful than debit cards for transactions with non-highly-trusted parties, for several reasons, all tied up with security (so, see, this is on topic, if on a different topic than the parent post). I can dispute transactions on credit cards and the onus is on the merchant to prove the transaction is valid; with debit cards, in the UK at least, the opposite is true. I can cancel credit cards whenever a random attacker steals it from one of the online sites that has doubtless stored it. If someone steals my debit card none of this is true: they can empty my current account and possibly command transfers from my savings account into it and there's nothing I can do to stop them. Yes, I suppose I could maintain multiple current accounts and shuffle money between them in case one of them gets broken into (probably losing the money in that account), but that seems like a hell of a lot of extra work and risk compared to simply zapping a defrauded credit card and getting a new one with only a few days' overhead and no financial loss to me. Personally I only use my debit card with bank ATMs and with entities with whom I have long-term legal relationships and contractual recourse if they go bad (and for those I generally use standing orders instead). Using debit cards with e.g. online vendors strikes me as crazily dangerous.
The SEC to require filings in Python? Posted Apr 20, 2010 16:32 UTC (Tue) by iabervon (subscriber, #722) [Link]
I've got a credit card with no fees (for anything I ever actually do), and I always pay the full balance each bill, so I don't pay any interest. In fact, since I pay the bills out of my (slightly) interest-bearing checking account, I get a tiny bit of money for using the credit card instead of the debit card because I get interest in the time between when I make the purchase and the time when I pay the bill.
Also, although there's no way to tell for sure, there's reasonable evidence that credit rating agencies count it as significantly positive if someone has available credit over a long period of time without running into trouble (where they don't seem to care if the way trouble is avoided is by paying minimum balances, by paying full balances, or even by never using the credit). Since credit ratings, which are in theory strictly a measure of whether you can be trusted with loaned money in particular, are often and unfortunately used as a proxy for trustworthiness in other ways, it's worthwhile to have a credit card if it's free, even if you aren't actually going to take out loans you don't have the cash to cover.
Of course, this does make the interest calculation algorithm not matter so much, because you won't actually be paying it.
The SEC to require filings in Python? Posted Apr 20, 2010 15:04 UTC (Tue) by tialaramex (subscriber, #21167) [Link]
The new algorithm is fascinating, and definitely looks like something influenced by consumer legislation. The latter part (paying off high APR credit first) is standard financial good sense, and thus not the kind of thing you'd expect a lender to offer voluntarily.
From what I've read elsewhere it also sounds like US card operators will now be required to highlight the "total cost" of the loan, which might actually save a few people from financial ruin -- there's an obligatory "paying the minimum amount is stupid" text block in my country, but of course the people it's aimed at don't read it.
A Python program would be even less effective than the text block for these people, but hopefully the SEC can afford to employ people to analyse this stuff, and not just look at the headline numbers.
However I caution anyone responsible for implementing this to go read all the literature about how to trick machines (for such filings could only be assessed by machines) when it comes to the expected value of something. The original Ponzi Scheme looks OK in a computer model, it's simple arbitrage - but in the real world the scheme could not have worked, because the sheer number of reply coupons needed was astronomical.
The SEC to require filings in Python? Posted Apr 20, 2010 15:28 UTC (Tue) by jzbiciak (✭ supporter ✭, #5246) [Link] A Python program would be even less effective than the text block for these people, but hopefully the SEC can afford to employ people to analyse this stuff, and not just look at the headline numbers. Oh, agreed. I guess using an example off a credit card statement was a bad idea, since it seems to have sent others off the scent too. I don't want Python on my credit card statements necessarily. While I might be able to read it, no one else in my family would. My point (hidden in the fog of posting long after I should have been in bed) is that it's very difficult to specify an algorithm in English, and it's quite easy to be hand-wavy. Requiring an algorithm in code helps cut through much of that. However I caution anyone responsible for implementing this to go read all the literature about how to trick machines (for such filings could only be assessed by machines) when it comes to the expected value of something. The original Ponzi Scheme looks OK in a computer model, it's simple arbitrage - but in the real world the scheme could not have worked, because the sheer number of reply coupons needed was astronomical. That's an extremely good point. I would imagine in the computer model, though, that you would see that astronomical growth, wouldn't you? As you said, you can't just look at the headline numbers, you have to look at all the parameters and assumptions around the model rhat produced that number. I imagine you'd also have run many, many scenarios to see if there are any gotchas in the model (ie. weird non-linear effects). I wonder if Monte Carlo simulations are sufficient? I must admit, this is not really my territory.
Haskell? Posted Apr 19, 2010 23:14 UTC (Mon) by cesarb (subscriber, #6266) [Link]
I vaguely recalled reading some time ago about using Haskell for something like this. So, I went looking, and found it again: http://research.microsoft.com/en-us/um/people/simonpj/Pap...
Haskell? Posted Apr 19, 2010 23:38 UTC (Mon) by fergal (subscriber, #602) [Link]
Yes, this is a great paper and as others in this thread have pointed out, if you need a turing complete language to specify your contract you are in trouble. The nice thing about the Haskell version is that the contracts are declarative and if I recall correctly in a subset of Haskell. This seems much more suitable than a stateful, imperative program. Perhaps they are using a subset of python to limit the madness that could ensue with non-terminating contract specs etc.
The SEC to require filings in Python? Posted Apr 19, 2010 23:23 UTC (Mon) by jordanb (guest, #45668) [Link]
Here's a better law:
Any security that needs a Turing-complete imperative language to describe, is illegal.
The SEC to require filings in Python? Posted Apr 20, 2010 6:36 UTC (Tue) by nix (subscriber, #2304) [Link]
They're not described that way *now*, so this would ban nothing. Maybe 'any security that requires PhD-level maths to describe is illegal', only now you have to define 'PhD-level'...
The SEC to require filings in Python? Posted Apr 20, 2010 8:33 UTC (Tue) by epa (subscriber, #39769) [Link]
You don't think English is Turing-complete?
The SEC to require filings in Python? Posted Apr 20, 2010 13:57 UTC (Tue) by jonth (subscriber, #4008) [Link]
English is not a regular language, so is not Turing complete. Or maybe I should rephrase the statement by saying your question is not well formed ;-)
The SEC to require filings in Python? Posted Apr 20, 2010 20:35 UTC (Tue) by vonbrand (subscriber, #4458) [Link] Sure, English isn't a regular language. But all Turing-complete languages are non-regular... BTW, Turing's results on computability were explained in English, so English is (at least) Turing-complete ;-)
The SEC to require filings in Python? Posted Apr 21, 2010 10:47 UTC (Wed) by jonth (subscriber, #4008) [Link]
I (partially) stand corrected: all Turing-complete languages are indeed non-regular.
However, my point about the question being not well formed I will stand by: every explanation of Turing Machines I've ever read that could be considered rigorous does not use English as it's means of explanation, it uses some form of symbology to do so. Now, I understand that there is a translation of those symbols into English, but it is a _very_ tightly constrained form of English, where ambiguity is removed entirely by specifying the grammatical rules for any statements written in it.
I would contend that this is a actually not English at all, but a variant of it that mathematicians use so that they can discuss their ideas without misinterpretation. Hence, idiomatic English is not Turing complete: additional grammatical rules are required for it to unambiguously define a Turing Machine.
This is why this whole discussion arose: Why are people suggesting that these models be written in some form of computer code? Because plain English is not sufficiently tightly specified to guarantee an unambiguous result.
The SEC to require filings in Python? Posted Apr 21, 2010 12:10 UTC (Wed) by nix (subscriber, #2304) [Link] Now, I understand that there is a translation of those symbols into English, but it is a _very_ tightly constrained form of English, where ambiguity is removed entirely by specifying the grammatical rules for any statements written in it.Not hardly. Very few mathematicians construct any English phrases by working through a partial grammar of English to do so, not least because the grammar of English is not known (so cannot be simplified) and varies between native speakers of different dialects (at the very least). What mathematicians do do is endeavour to avoid ambiguity, but this doesn't mean they do it by specifying the grammar of that form of English any more than lawyers do.
The SEC to require filings in Python? Posted Apr 21, 2010 12:59 UTC (Wed) by jonth (subscriber, #4008) [Link] I think you may have misunderstood me - or I didn't express myself well (now there's an irony!).What I was trying to convey was that although mathematicians almost always express their ideas symbolically, there is a way to translate these ideas into English (or any other human language). However, there are rules to do with the way those "translations" have to be read in order for those statements to be read unambiguously. When mathematicians discuss things verbally, they do speak to each other in a human language, but they assume these more tightly defined grammars apply. In writing, however, mathematicians almost always express their ideas symbolically (with supplementary explanations in English) because the grammar of whatever symbol system they choose to use is specified tightly enough to avoid ambiguity, and is much more concise and are easier to manipulate than plain English. It's the mathematicians' equivalent of Linus Torvalds saying "show me the code!" An obvious example is the precedence of arithmetic operators. 1+2*3=7 translates to "one plus two times three is 7", which is a valid statement in both idiomatic English and arithmetic grammar. On the other hand "one plus two times three is 9" is a valid statement in idiomatic English, but 1+2*3=9 is not valid in the grammar of arithmetic - because English grammar does not specify precedence and so allows the "plus" to be evaluated before the "times". In this sense idiomatic English is not Turing complete because it is not specified well enough. Back to the original point of the article, I'd be much more comfortable with an (open source) Python program to specify the terms of a loan/investment than an English description, because there's no interpretative wiggle room in a Python program. Or Haskell. Or any Turing equivalent language. And when people say "if you need a computer program to express it, it's too complicated," I think that isn't true at all. A computer program is the ideal way to express a computable number.
The SEC to require filings in Python? Posted Apr 22, 2010 16:11 UTC (Thu) by epa (subscriber, #39769) [Link] every explanation of Turing Machines I've ever read that could be considered rigorous does not use English as it's means of explanation, it uses some form of symbology to do so.Indeed, but that special language is itself defined in English! Consider also language specifications. The Scheme programming language is defined by an IEEE specification written in English, and Scheme is Turing-complete, therefore English is Turing-complete. (It would be very laborious for somebody to evaluate a Scheme program by hand using the standards document as instructions, but in principle it is possible.)
The SEC to require filings in Python? Posted Apr 22, 2010 18:04 UTC (Thu) by jonth (subscriber, #4008) [Link] I haven't seen the spec in question, but if that were true, you should be able to write a parser which encodes the grammatical rules for idiomatic English which can then parse the IEEE Scheme specification to generate a compiler for the Scheme language directly.By your definitions, that same parser should also be able to generate compilers for C, ADA, Python, Perl, etc. directly from their specifications. And you can't rewrite the specifications - the parser must "just work." Show me the code and I'll concede defeat. My belief is that idiomatic English is not unambiguously parseable (see a previous comment), so such a thing is impossible. This is why translation engines such as Babelfish are still not all that good. For a truly excellent discussion of the concepts behind this, I highly recommend The Emperor's New Mind by Roger Penrose.
The SEC to require filings in Python? Posted Apr 22, 2010 20:28 UTC (Thu) by jordanb (guest, #45668) [Link]
It's easy to create a subset of English that is demonstrably both English and context free.
The specifications for the language you mention do contain compilable CFG descriptions of the languages in question, albeit in BNF rather than straight English.
A translation from BNF to straight English should be obvious; the purpose of BNF is to remove tedium that would exist in prose description and reveal structure.
The SEC to require filings in Python? Posted Apr 23, 2010 11:35 UTC (Fri) by epa (subscriber, #39769) [Link]
Hmm. I didn't think that to be Turing-complete a language had to be parsable; only that it must be able to simulate a Turing machine. Perhaps you are right that only parsable languages can qualify; but in that case you no longer have the property that if language A is a subset of language B, and A is Turing-complete, then B is Turing-complete.
A good start ... hopefully the IRS is next Posted Apr 20, 2010 4:18 UTC (Tue) by ccurtis (guest, #49713) [Link]
I don't really have much more to say than what's already in the subject, but hopefully one day the IRS will release all of its regulations in a codified form that's programmatically available. Then the US tax software companies can compete on actually doing something more useful than picking forms and adding numbers, and the open source folks can have a free option to do so without having to submit all of their income and identity data to $RANDOM corporation. I don't think that python is the answer - something more XMLish would be better - but the time for something like this is well past due.
A good start ... hopefully the IRS is next Posted Apr 20, 2010 19:14 UTC (Tue) by raf (guest, #35151) [Link] http://xml.coverpages.org/xmlAndTaxes.html I vaguely remember some initiative requiring states and other localities to express their sales tax laws in some formal way to facilitate, e.g. Amazon to collect those taxes, though it seems like that was more recent than the 2002 date on the above article; maybe it's related to the stuff at statemef.com?
A good start ... hopefully the IRS is next Posted Apr 21, 2010 7:14 UTC (Wed) by bcebul (guest, #41527) [Link]
In Australia this XBRL derivative is called "Standard Business Reporting." it will start functioning at the beginning of the next financial year on 1 July 2010.
Website: http://www.sbr.gov.au/en.aspx
More on this international standard XML taxonomy at:
what??? Posted Apr 20, 2010 5:34 UTC (Tue) by b7j0c (subscriber, #27559) [Link]
i can see them wanting structured data, but a running program?? why?
sounds like what they really want is json
oh well, i await the first instance of the sec getting rooted by a python script uploaded by an intrepid hacker from wall st, or just having their system grind to a halt due to some unterminated loop etc
hey sec, you can trust us, why not let us just insert records directly into your db?
what??? Posted Apr 20, 2010 6:41 UTC (Tue) by nix (subscriber, #2304) [Link]
json? You need to describe relations here (change in X given change in Y, at the very simplest). A data description format cannot do that, even in principle, without another formalism layered on top.
You might as well say they want their filings on paper.
(And, 'rooted by a python script'? They're not going to be running these things as root, you know! Also, it's in the financial wizards' interest *not* to piss off the SEC by submitting security scripts that hang their machines!)
SEC security implications Posted Apr 20, 2010 11:09 UTC (Tue) by pjm (subscriber, #2080) [Link]
I think the point is that rooting the machine is only a local root exploit away.
SEC security implications Posted Apr 20, 2010 11:56 UTC (Tue) by nix (subscriber, #2304) [Link]
But why would a trader want to do that? It'd be like someone trying to root the tax office's machines. At *best* this will result in a giant legal slapping by the SEC (which is, after all, their regulator). I can't see any upside in this for the attacker.
(Ofcom (UK) doesn't have to worry much about ISPs defacing its website, either. You don't launch attacks on your own regulator. You just don't. Or rather, if you do, you make them political, because those might actually work.)
SEC security implications Posted Apr 20, 2010 12:16 UTC (Tue) by hppnq (guest, #14462) [Link] For once, we could have a legitimate flamefest about why it has to be Python rather than Ruby or Perl [*], and people start to complain about this.According to the proposal investors will run these scripts on their own systems, rather than the SEC on their precious database system. The scripts will be audited before they are made available for download. The risk involved should be comparable to that of downloading and using software from any trusted source. [*] No worries, the document addresses this.
SEC security implications Posted Apr 20, 2010 14:35 UTC (Tue) by drag (subscriber, #31333) [Link]
Hells bells people.
Running programs and software is at the core of the financial industry. They've been running hi-torque software for longer then anybody else.
Worrying about the software that financial institutions run and let other companies run on their behalf is something that should of been done in the 1960's.
Sandboxes and narrow interfaces Posted Apr 20, 2010 6:54 UTC (Tue) by jzbiciak (✭ supporter ✭, #5246) [Link] I imagine whatever Python is allowed would have to adhere to rather narrow interfaces. I could totally see a version of Python coming into existence to sandbox "FinancePython" or whatever it gets called that forces everything to go through a narrow interface and does not provide the full access that ordinary Python provides. I imagine that's the security aspect our fine editor alluded to. See my posts further up for how credit card companies shove algorithms at us in legal speak. Sometimes, the description is clear enough I could write my own executable version accurately. Other times, it isn't. Any code that has to be tweaked to match the statement from the bank isn't reliable for verifying that statement. Forcing them to provide program code (and an ability to verify said code) makes it much, much easier to see how some of the complicated terms in some of these securities actually play out. Heck, it'd make it easier to model one's credit card statement more accurately. And, it makes it possible to detect fraud when the published numbers don't match the algorithm's.
what??? Posted Apr 22, 2010 13:57 UTC (Thu) by amk (subscriber, #19) [Link]
Note that the draft says the code is for the use of potential investors, who can take the asset data and run the program to determine the investment's return. I can envision an 'investing workbench' that's something like an IDE, and lets you run code, graph the results, etc.
The SEC to require filings in Python? Posted Apr 20, 2010 12:30 UTC (Tue) by sean.hunter (guest, #7920) [Link]
Declaring an interest upfront: I worked on Wall Street in asset-backed securities (ABS), so I actually know a lot about this. In fact at one point I nurtured the dream that one day I would start a little ABS modeling company based on something like this idea.
There are two big problems in modeling ABS: Firstly modeling what the collateral (ie loans or whatever) is going to do and secondly modeling what actual bondholders get given what happens to the collateral. This second step is called the cashflow model and that's what they're talking about here. The "cashflow waterfall" is the description in the bond prospectus of how the cash should be allocated and then historically various analytics providers (eg intex, ABSnet, bloomberg etc) have made deal models based on this cashflow waterfall.
It's very difficult to truly compare ABS (or asset-backed credit default swaps) because these cashflow models provided by third-party providers are often incomplete, and not every deal will be modeled. So it's hard to compare like with like. It's also hard to couple up your own analytics for the collateral with a third-party cashflow model.
This is a good step which will provide a great deal of additional clarity although I'm disappointed they didn't use Haskell because a pure functional language would be able to give you some other benefits like generating the legalese that describes the cashflow waterfall directly from the cashflow model. You'll struggle to do that 100% robustly in a language that is tolerant of side-effects, and many many deals suffer from drafting errors in the documentation that could just go away if this were possible.
For those of you who are arguing about Turing-completeness and PhD math etc you're missing the point. The existing complexity is truly staggering given that it's described in English and many important features of the deals are not described in full or in a standardised way (eg the exact terms of embedded derivatives in the deals). You need something like the SPJ paper someone linked to precisely describe the performance of a deal issued from a master trust with embedded balance guarantee swaps. You really do. A typical prospectus for such a deal will be 700 pages for the issuing series and then an addendum of 150 pages or so for each actual bond issue. In Haskell, describing this payout exactly would be relatively simple. About 200 lines or so would do it.
Understanding conceptually how a deal waterfall works is not that hard incidentally. Imagine a bunch of bank accounts. Cash can come in to the deal from various sources (mostly the collateral, but also interest on various balances, reciepts from derivatives in the deal etc) and there are rules which say what cash goes into what account. For each account there is a waterfall that says how the money is paid out to various interested parties. The rules often include various trigger events which can change the order of priority of the payments etc. The whole thing is a state machine, but needs to be precise in every detail as generally once the deal is set up the trustees and managing agents have no discretion. They have to follow the script precisely as set out in the deal prospectus.
|
|||||||||||||