Welcome!

Cloud Event Processing - Analyze, Sense, Respond

Colin Clark

Subscribe to Colin Clark: eMailAlertsEmail Alerts
Get Colin Clark via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Blog Feed Post

Hope, FPGA’s, High Frequency Trading and the New Market Access Rules

I recently became aware of an emerging practice most likely being implemented by clearing companies at the low end of the capitalization sprectrum offering a unique solution to the recent Market Access Rules.

NO UN-FILTERED DIRECT ACCESS

What the SEC is trying to do is remove, or reduce the opportunity for either crooks, idiots, or algo’s gone wild from doing bad things to the market. Under the new rules, order flow needs to be monitored. This is not something that the HFT crowd like to hear, because it slows them down. So a couple of innovative idiots got together and came up with the solution that I’m going to describe here.

HOPE IS NOT A STRATEGY

Let alone a comprehensive compliance or surveillance strategy. What the idiots are doing is putting a ‘black box’ between the HFT firms FIX engines and the execution venues. The box, most likely powered by an FPGA device, scans the outbound order flow, and if it finds something it doesn’t like, it messes up the payload of the FIX order so that the execution venue (hopefully) rejects the message. Why is this done this way? Because the ‘black box’ is both out of process – both the source of orders and resulting executions, etc. are behind FIX engines, and because the ‘black box’ isn’t actually maintaining connections between the HFT firm’s order generators and execution venue.

A PICTURE IS WORTH A MILLION REJECTS

This is a little complicated, so let’s look at this picture:

In the diagram above, the ‘black box’ isn’t maintaining FIX connections to either the HFT’s order generators or the execution venue.  So, the ‘black box’ can’t just reject the order if it’s out of bounds back to the order generator because then the FIX sequence #’s get all mixed up.  There’s a little more to this, but you get the general idea.

YES, THIS IS REAL, AND I’M NOT KIDDING

So, this whole thing is designed so that an examiner can come into the Olde Thyme Highe Frequency Trading Shoppey and be escorted into the back room and shown the shiny box.  Wow.  Are you serious.  ”Look, we’re making sure that this firm isn’t doing anything wrong – we’re actively monitoring the flow and if they do something we don’t like, we shut them down.”  Right, they shut down the order flow attached to the box.  What about the order generators that the examiner doesn’t see. There’s a host of issues here, but we’re going to focus on one – and it’s a doozy.

DENIAL OF SERVICE ATTACKS

So, we’ve installed the OMICRON 5000 monitoring device and our HFT/algo team is ready to do business.  And everything is fine.  They’re trustworthy chaps and have no intention of gaming the system.  (cough cough).  But their first algo goes completely nuts.  And get’s shut down by the clearing firm.  But it doesn’t really get shut down.  Instead, it’s sending 1000′s of malformed FIX messages to an execution venue per second.  Or maybe 10,000′s of malformed FIX messages to many execution venues.  Wow.  In the internet world, we call this a denial of service attack – flood a destination with more traffic that it can handle.  And while the execution venues can handle normal traffic, what about rejecting every message? Is every execution venue out there ready for this?  I don’t think so.  I’ve been involved with FIX longer than I’ll admit to in public, and I’ve seen a lot of testing  - “Yeah, reject worked.  It worked fine.  I mean, we never thought they’d be sending 1,000′s of orders a second that would all reject…”

I DON’T KNOW

What should be done about this.   I have lots of ideas about surveillance and how it should be done.  But I don’t have any thoughts about this.  Mostly because I never thought anyone would be so stupid as to ever actually deploy this type of ‘solution.’  Where’s the SEC when you need them?

THANKS FOR READING

PrintFriendly

Read the original blog entry...

More Stories By Colin Clark

Colin Clark is the CTO for Cloud Event Processing, Inc. and is widely regarded as a thought leader and pioneer in both Complex Event Processing and its application within Capital Markets.

Follow Colin on Twitter at http:\\twitter.com\EventCloudPro to learn more about cloud based event processing using map/reduce, complex event processing, and event driven pattern matching agents. You can also send topic suggestions or questions to colin@cloudeventprocessing.com