Event Processing blog

Not Trading but Pricing

(with apologies to Stevie Smith)

Wednesday's announcement at the SIFMA conference of our collaboration with Sun Microsystems highlighted two aspects of our joint endeavor; our support for the Sun Solaris 10 platform on x64 and SPARC in the latest Apama 4.0 release and the development of a new Accelerator in the area of real-time pricing. The latter is a very interesting application of CEP technologies which I want to highlight further.

If there was still a need to justify a broader remit for CEP in Capital Markets beyond Algorithmic Trading, the area of real-time pricing fits the bill nicely. It bears all the hallmarks of an ideal CEP use case: an over-arching need to respond in real-time to high-volumes of streaming events from a variety of sources. Real-time response is critical, as a bad price being shown to the market, even for a few seconds, can result in huge exposure for the price maker as clients gleefully hit the price as fast as they can punch the keys - or more likely nowadays, as algo engines react to the sudden opportunity.

Over the last few years we have deployed the Apama platform in support of real-time pricing use cases in many clients across several asset classes. However, besides the real-time imperative, other commonalities from these use cases exist:

• a multitude of (real-time) inputs: prices are derived as a function of multiple sources, for example real-time price of underlying (derivatives) or related instruments, market volatility, direction and size of deals by "indicative" clients, sector indices, news headlines and more;
• a desire for price differentiation: the ability to make prices specific to individual clients, or "tiers" of clients, based on client relationships, agreed deal sizes, previous and desired success at winning client business (the "hit rate") etc;
• risk management: real-time tracking of the current position or inventory accumulated through dealing on the published prices; the greater the inventory, the higher the potential exposure - so make prices to drive client trade flows in a certain direction to reduce the magnitude of the inventory and therefore the risk.

Of course, the Banks don't stream prices to their clients out of charity - clients pay a premium to deal on instuments they would otherwise need their own direct market connections, memberships and trading software to access. In addition, some Banks - the "Market Makers" - are contractually obliged to provide liquidity through streaming prices for specific instruments to electronic markets (before you start to fret, they get well-rewarded for this seeming altruism). Market Makers are usually contractually obliged to provide prices, within certain spreads, for an agreed number of hours of the trading day; monitoring adherence to ensure a Bank is fulfilling its market making obligations is yet another facet of the real-time pricing space where CEP can - and does - play a part.

Judgement Day

Earlier this week I was told by a client (a proprietary trading shop) that they were switching brokers - the bank to which they submit their (cash equities) orders for execution across a range of European and US Equity markets. Now this was intriguing to me - as I happen to know that their new broker implements their client-facing Direct Strategy Access (DSA) offering using Apama. So Apama will be generating orders and sending them to ... Apama. (Via FIX protocol as it happens)

Brought a smile ... but then they told me the rest. They were planning to go via this broker to a range of markets to run some new cross-market arb strategies - apparently their new broker provides access to more European markets with very low latency. One of their primary markets will be the new Turquoise exchange, which will launch in September. At this point you might see where this is going; at Turquoise their orders will be subject to surveillance by the Turquoise Market Abuse Detection system, built on top of ... Apama.

I am smiling no longer. Didn't Skynet start like this?

On (Complex) Event Processing

I'm sure this has been said before, but I had cause to think again today on what is actual "complex" about CEP. I've never been particularly comfortable with the term CEP (of course, my personal comfort is not required ...) as it suggests that CEP is in some ways "hard". Well, those of us in the business of building CEP technologies know that the challenges of processing 10s of 000s of events per second with sub-millis latency against 000s of event patterns with temporal and logical constraints introduces a shed-load of complexity under the hood - but that's the point really - it is (or should be) all under the hood; we don't call databases "tricky databases" just because they have some fancy background indexing and schema evolution capabilities inside them.

Anyway, that ship has sailed - and I digress. The thing that got me thinking about this (again) was the recent press release regarding our launch - with our partner Detica - of a Solution Accelerator for Market Surveillance. That press release gives some examples of the kinds of surveillance strategies - "front running", "washing" ec. - that the Solution Accelerator provides (along with a handy definition of what this jargon actually means). The point is that the event processing logic required for these types of applications is not in any way "complex" - e.g. "detect a spike in trading volume or rapid price move within 10 minutes prior to a news release regarding a particular instrument" - despite the machinations under the hood that might be required to do this in real-time for all trades and news articles for all listed instruments on an exchange.

No, what is key in supporting these types of applications or strategies is the *lack* of complexity - and the provision of tools allowing strategy builders - here, operational teams at the exchange - to quickly express the business logic, generate a Dashboard to visualise the alerts it generates, and get all this into production before it becomes irrelevant. As markets and traders become ever more sophisticated it is the ease with which strategies can be modified and new strategies deployed that determines whether CEP is the right technology or not, not how clever it might be under the hood.

The term CEP seems to be here to stay, and I'm certainly not volunteering to be the flag carrier for a terminology battle ("Event Processing"? Anyone?). But let's be clear that neither the use case nor the hoops that need to be jumped through to deploy it need be complex for "CEP" to be an effective technology solution.

The key to effective CEP technology is to keep as much of the complexity as possible away from the people who have to use it.