While any computer scientist would quickly agree to the benefits of representing financial terms as a software program, lawyers having seen the value of such an idea at the SEC deserves kudos. A new SEC proposal calls for Asset Back Securities (ABS) registration in EDGAR to include data in XML markup with the waterfall model implemented as Python code. This is a great idea for transparency. It also raises several questions about the efficacy of specifying a language and embedding the model within that language.

I’m a Python fan, which isn’t saying much as I’ve only coded a half dozen example programs in the language. Having come from a Perl / C / C++ / UNIX background with lots of data processing, I appreciate Pythons power and elegance. In the geek community, Python is a well respected language with some functional programming capabilities. The SEC choice could be far worse – much of this kind of work is done in Excel with VBA embedded in spreadsheets and cells.

So let’s consider a few questions …

Is SEC specifying a computer language to represent financial waterfall models a prudent idea?

If I was going to choose a language to tie a waterfall model for public consumption, a better choice than Python would be hard to find. Python is generally well designed with some functional programming capabilities. It is open source, platform independent, stable and reasonably mainstream. As alternatives, Perl would likely see more obfuscated coding examples, C/C#/C++ lacks interpretative benefits and the other choices are too far off the mainstream to consider (name your favorite functional programming languages which are the rage in Europe or logic programming languages like Prolog).

That being said, while pulling the waterfall model out of a 100 page ABS prospectus may be a step in the right direction, burying the model in code has its issues:

• Which is legally correct – prose or code? Given the textual description of the waterfall in the prospectus, there are now two representations of the waterfall.
• Regulators should specify objective, not method. Tying disclosure to a specific language platform specifies how companies are to represent the waterfall at a very specific level. While I understand the prospectus is likely to be required as written in English – we standardized on the English language in the USA by de facto, if not for the founding fathers documents being written in that language. In Computer Science, such standardization has very different implications.
• Now the waterfall is locked in code. While the data is in XML and can be culled and operated upon by any downstream software, the waterfall (which is ostensibly a set of mathematical functions) is locked into a programming language. What’s the basis for legal interpretation of algorithm? Should make for an interesting legal reality of Gödel’s first Incompleteness theorem.

Would a logic and control flow specification provide the same class of transparency? If so what would be the downside?

A better representation of the waterfall might have the following characteristics:

• Referential transparency which programmatically speaking means no side effects. Functional programming can be performed in Python, but few languages limit side effects, and while some have gained more popularity in Europe they are obscure in the USA. A declarative specification would address this issue.
• True portability, versus just open source. If one considers XSLT as an example of declarative specification allowing operational end states to be realized as desired.
• Before the waterfall model was buried in prose. Python means the waterfall is buried in code.

The downside to specification based codification is more up front complexity and less mainstream adoption both for the SEC (versus simply specifying that a prospectus must have a waterfall Python program, it would now have to establish specifications) and the corresponding ABS originator (who is now dealing with something likely even more obscure than coding directly in Python). This would take years to sort out, whereas specifying Python places the onus on the ABS originators who have the financial means and motivation to produce the code.

In short the choice of a mainstream, portable language seems to be a brilliant trade-off of real world factors.

Does code really solve the problem?

It definitely seems to help. Transparency should increase as should the ability for investors to more easily create scenarios – the issue is not so much who gets paid but the likelihood of who is paid how much and when.

Writing a prospectus that is either obfuscating or interpretable benefits the ABS by operational wiggle room – code may help determine where this occurs. Or not. Provability in software is difficult but I believe the greater issue here is simply providing the greater transparency.

The SEC proposal to codify ABS waterfalls has received lots of kudos, from programmers contemplating the possibilities to professors who have been critical of wall street and regulatory ongoings. In spite of some of the issues I note above, I agree that the SEC proposal is a step in the right direction both in intent and in speed in which it can be executed. The shortcomings of specifying a programming language is likely outweighed by the benefits of having a solution now which provides more transparency sooner with almost no risk to achieving the transparency.