Compliance, front running and CEP
Here’s an interesting post about front running and why banks don’t have better analytics looking at their trading activity. In the comments, Marc mentions that CEP is good for surveillance.
In the past, banks have made structural changes in response to front running concerns. For example, Prop traders don’t have access to order flow from the rest of the bank or the customers. And traders all over are trained not to give out data that could be used for front running. So the question is valid: why not back this up with analytics?
Well, a bank is only going to enter into a big project for two reasons: profit or cost savings. The structural changes were brought on by penalties, threats of legal action or rules changes or other potential costs. And apparently, those changes worked to stop those costs. So until another round of costs comes up, there’s no major motivation for an innovation in this area of compliance.
Improving detection of front running is actually a big project for the business. Sure, you can use some pretty simple statistics to begin detecting front running. And one can imagine more complex techniques as well. But what happens when you get an alert from the detector? There’s got to be a process for understanding whether it’s a false alarm. And all the desks will need to sign off on that. So there is a huge amount of testing to show the desks what previous trades would have been flagged. And the desks will have to devote significant effort to looking at these results and at the analytics in general. Not a small task, overall. And not cheap.
Also, this kind of project would be a powerful magnet for attracting the interest of regulatory agencies. If those agencies decided to get involved and to compare the analytics between institutions… Ugh.
So again, what’s needed is some new round compliance related costs that would justify a big project like this.
Now about using CEP for this kind of thing. As I posted here, real-time monitoring is not all rosy. This kind of change to compliance rules is a very big project for the business and honestly, if I were running the tech side of such a project, I would not go for real-time monitoring in the initial stage. Detecting front running in real time actually doesn’t provide an enormous benefit. Sure you might find some rogue trader during the day, but so what? One trader front running for one day won’t cost the bank very much. If it’s caught by analytics that night and stopped the next day, regulators will be fine with this. And knowing that your activities will be caught that night is as much of a deterrent as knowing that your activity will be caught in 10 seconds. So the big win comes simply from having the analytics and not from real-time detection.
At the same time, per my post, real-time analytics introduces big risks. So I would see how batch analytics work and then think about identifying opportunities for improvement with real-time processing. I would not start a project like this with real-time processing.
Having said that, though, this is one area in which streaming SQL engines like StreamBase, Coral8 and Esper have a lot to offer. Even if the processing is not done in real-time, streaming SQL engines have features that are not available with traditional SQL. For example, streaming SQL engines offer interesting and high performance pattern detection operators as well as the ability to do analytics over sliding time windows (although Oracle is catching up with the time windows). So even if the compliance project does not go for real-time monitoring, it might be interesting to look at the analytical capabilities of these engines.
leave a comment