I’m a little bit mature these days ... some of you might even say old ... but you realise you’re getting on when something looks like an antique and you realise that, when you first saw it, you thought it was the future.
In my case, this would be the first mainframe I programmed.
Way back when, I was trained in an ancient programming art called PL/1, using JCL.
That’s Programming Language One and the Job Control Language, for those who were wondering.
This was during a graduate year out, training with IBM as a programmer on their wondrous S/360 instruction set mainframe processor.
Yabba-dabba doo.
I still remember creating this amazing program that played Black Jack.
Not very useful for IBM, but good training for me before going to Las Vegas.
Oops, sorry, good programming experience I mean.
Walking down the corridor with my 100's of punch cards carefully placed in order, I still remember to this day dropping them all as I opened the door to the computer room.
Result: I had to go through the whole lot to put them back in order ... line by line of code, card by card.
Each card was a line of code you see.
I realise that not many folks will remember the days of punch card programming, but this picture puts it in context:
The cards only held a limited amount of data, and so 800 million punch cards would equal today’s 64GB microSD.
Oh, and the programming was harder back then. For example, here’s a bit of JCL:
//IS198CPY JOB (IS198T30500),'COPY JOB',CLASS=L,MSGCLASS=X
//COPY01 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DSN=OLDFILE,DISP=SHR
//SYSUT2 DD DSN=NEWFILE,
// DISP=(NEW,CATLG,DELETE),
// SPACE=(CYL,(40,5),RLSE),
// DCB=(LRECL=115,BLKSIZE=1150)
//SYSIN DD DUMMY
That’s nine punch cards, 25 words and over a 1,000 characters.
What does it say?
It’s JCL for “copy oldFile newFile”, the latter being the radical innovation of MS-DOS!
Now it’s just drag and drop!
The reason for sharing this nostalgia is that there was a key lesson back then.
It was the mantra of every programmer.
The mantra was: “Garbage In, Garbage Out” (GIGO).
One line of code or instruction in the wrong place would screw up the whole system.
So you had to be careful how you programmed, with lots of phase controls and management checkpoints built into the system to ensure you could not enter anything that would mess up the whole.
Detailed user testing and acceptance tests were then placed into these checkpoints.
Eventually, you would be able to add the new code and rollout the system.
This got really rigorous when you were talking about 300,000+ lines of code for payroll apps or similar, where each line of code would have a linkage and knock-on effect with all the other lines of code.
This is why new developments took so long, as there was such a danger of messing up.
It's also why you were looking at years to develop systems, rather than days or months.
Everything is faster now, which is good, but the mantra of GIGO remains.
In fact, it's even more essential as programming is so much easier these days, that making serious errors is also easier if the right controls are not put into place.
And the essence of programming is still the same: the program is only as good as the people who program it.
Humans make errors, not machines.
After wallowing in the good old days for a bit, you’re probably wondering what's the point?
The point is that GIGO is a lesson that is just as critical today as it was back then, and regulators seem to be in danger of losing sight of this fact.
This suspicion was prompted by a headline yesterday: European Parliament piles pressure on dark pools.
This headline was immediately followed by another headline: Regulator warns of the dangers of High Frequency Trading.
This was a commentary from Martin Wheatley, CEO of the Hong Kong Securities and Futures Commission and formerly a Deputy Chief Executive of the London Stock Exchange, on the BBC’s Business Daily program.
These headlines follow on from Christine Lagarde, the respected French Finance Minister, comments: “My natural tendency would be at least to regulate, to oversee [HFT] very strictly and after a cost-benefit analysis of these methods, maybe to forbid it. Or at least give market authorities the power to forbid it in circumstances that are considered exceptional.”
This is all in response to the flash crash in the USA in May, where share prices bounced around massively during a short period of trading.
This is an issue that has prompted several new global regulatory movements.
For example, IOSCO are drafting proposals to restrict HFT activities which will be published next year, and other global regulatory movements are underway to control market activities in order to avoid further flash crashes.
All of this movement seems to be saying:
HIGH FREQUENCY TRADING IS BAD AND SHOULD BE STOPPED
... when all of this has nothing to do with High Frequency Trading.
It is to do with the programming of the systems by the people who want to be engaged in High Frequency Trading.
And it is this programming that is flawed.
For example, the flash crash was not caused by High Frequency Trading, but by a plain old vanilla trade from an asset manager.
The issue is that the trade sparked rapid movements amongst the automated HFT systems in response.
For example, the SEC report shows that, over the course of just 14 seconds, 27,000 contracts of e-Mini S&P 500 futures were traded, half by HFTs.
On a net basis, however, only 200 additional contracts were bought in those seconds.
So what this is really showing is that there is a huge volume of trading at razor thin margins, which is why firms engage in HFT strategies, which will react to abnormal market actions.
However, it is the abnormal market action that causes the issue, not the High Frequency Trading.
Therefore the target for regulation should be:
- To ensure that markets stop trading fast when a ‘flash crash’ style moment occurs, which is what the SEC has put in place with their circuit breakers whereby a share price movement of more than ten percent in a five minute period halts trading;
- To ensure that there is more uniformity of markets to avoid fragmentation, as it is fragmentation that causes dramatic action by HFT systems because wide disparities between execution venues and poor visibility causes the systems to sell automatically, as they start running in fear;
- To ensure that trade reporting is tightened up across the board, as inconsistent post-trade reporting is a key reason why item (b)’s fragmentation exists, and consistent post-trade reporting standards across all key markets would make a massive difference; and
- To ensure that there is efficient price formation which, within Europe, requires a consolidated tape as the lack of a visible single venue for pricing is causing cost overheads and adds to the issues of fragmentation.
Finally, the fact that we have HFT and dark pools is not the cause of issues.
HFT and dark pools exist thanks to bank innovation in utilising the latest technologies of low latency fibre and unlimited scale computing to deliver best execution to clients and make markets.
Just because they trade in volume and in the dark is what makes the regulators worry.
They are scared of things that are out of control or lack transparency, which is what they believe is the case with HFT and dark pools.
However, their real worry should be the people programming these systems and how they program them, and whether the regulations on how they program and the way in which their programs trade are right.
I get the impression that it is more the regulator’s fear of these systems, rather than the people who program them, that is driving their agenda.
That is wrong and I urgently recommend the regulators consider the “Garbage In, Garbage Out” (GIGO) programming mantra, before they commit GIGO with their regulations.
Recent Comments