ACT submitted comments this week to the Securities and Exchange Commission regarding its proposed new rule to increase transparency in the Asset-Backed Securities (ABS) market. ACT supports added transparency in reporting of the Assets-Backed Securities market, but is concerned that specific elements of the proposal could backfire.
The SEC’s planned changes require ABS disclosure filings to be in the form of a waterfall computer model. Such a program essentially measures how funds flow from a pool of assets to different classes of securities in an ABS offering. So far so good.
But the SEC proposal becomes troubling for ACT members with its requirement that these filings be written exclusively using the Python programming language. Establishing a technology mandate is not an appropriate role for a government agency in the process of drafting regulations for financial reporting. Surely the SEC’s mission to “protect investors, maintain fair, orderly, and efficient
Some experts have suggested other methods may prove as good or better than the one mandated by the SEC. For instance, some have proposed that the waterfall structure be filed and available to investors in XBRL format.
ACT member Steve Smith suggested still other alternatives.
An Excel document could contain all of the data as well as the formulae necessary, and most likely would not require the end-user to install anything on their machine.
The SEC could simply create a calculator “in the cloud” such that any/all investors could use a single canonical web-based (or web-service-based) tool.
ACT member and python programmer Darrell Hawley summed up his concerns this way.
What version of Python [should be required]? 2.7, 3.1? Keep in mind that Python is not shy about introducing breaking changes into new versions of the language. Of course, what makes Python so much better than every other language? Why not Ruby? Or C#? Or Java? Or Haskell? … In short, the government should not be in the business of determining how we accomplish something. They are in the business of determining what needs to be done.
If only this was the worst of it. Beyond the mandate, the SEC also indicated it’s considering a ban on non-open source software at the agency. Curiously, the Commission sees the issue as a choice between open source and commercial products. In its request for comments, the SEC asked:
Should we restrict ourselves to only open source programming languages or allow fully commercial languages (such as C-Sharp or Java) to be used?
It’s disappointing that we once again find ourselves in an open source versus commercial debate. By defining its options under these terms, the SEC misses the point that many open source products are fully commercial and many commercially built products make code freely available. Open source and proprietary products differ only in the way in which intellectual property rights are licensed.
The Commission has taken bold steps to improve reporting and transparency for financial products that contributed to the recent economic crisis. Let’s hope when the SEC issues its final rule, it meets the scrupulous standards required and declines to show favoritism in the financial technology marketplace.
The request for comment by the SEC is an early stage of the regulatory process. The Commission will consider comments, like those submitted by ACT, before deciding upon the final version of the new regulation.