Richard Bentley

Friday, November 14, 2008

FX: A CEP Success Story

Posted by Richard Bentley

One of the questions that sometimes comes up in our meetings with prospective clients is "Why should I buy your whizz-bang CEP platform to do <insert use case here> and then build on top of it when I can go get a shrink-wrap app that does most what I want straight off?". Of course, this is a very easy question to answer: "If you can get an app that does what you want now, and you're confident it will meet your requirements as they evolve going forward, play nice with your existing systems, and the price is right, then why are you wasting time talking to us?". Marc Adler said as much recently with his comments on Risk Management systems, which were right on the money.

Of course, this answer is really an open incitement to the audience to start a discussion about what they really need - now and in the future - and often (more often than not in my experience) it is soon apparent that there is no app out there which will do all, or even most, of what they need - and extending a shrink wrap app to do that is often more work and pain, if it's possible at all, than building it themselves.

So here the salesperson will introduce the core value proposition of an open CEP platform; the ability to support existing and future requirements, to meet the underpinning performance requirements, the necessary resilience, to provide the connectivity, and - vitally - the tooling to allow the same vendor-supported and maintained technology to be applied to the client's constantly evolving needs, with rapid time-to-market. In short, the salesperson emphasizes the benefits of a more "strategic", platform-based approach to solving the client's short and longer-term requirements and - if the salesperson has done his homework and read his audience right - that one-size-fits-all shrink wrap approach is often consigned to the trash.

The nice thing about this approach is that there's no sleight of hand here; every word of the pitch is true.

Let's look at the use of Apama within Foreign Exchange (FX). We've blogged previously about how Apama is being used extensively for real-time FX rate Aggregation and algorithmic execution; just last week our latest client to go live - Standard Chartered - talked publically about their deployment of Apama for their FX spot dealing. We've built a Solution Accelerator to offer relevant but customizable connectivity, algorithms, monitoring and dealing GUIs out of the box. We've even won awards (ok, enough already!). However, although we're (clearly) not shy about trumpeting the power of our offering in this area, the more telling aspect of our deployments - and the aspect of relevance for this article - is not what clients do with our Aggregator; it's what they do *next*.

I was visiting one of our large Tier 1 banking clients in New York a couple of weeks back. They've been using Apama for FX Aggregation for nearly a year now. I walked through the door on to the trading floor and first thing I saw was 3 screens with - unfamiliar - Apama Dashboards on them. "That looks nice" said I (somewhat gormlessly). "Yes, it's our new auto-hedger - it uses the aggregated book feed from your Solution Accelerator and lays off our risk positions over your ECN connections according to a new algo we've built". All developed and running in Apama, extending our Solution Accelerator with new algos and screens - and all unbeknown to me!

I was somewhat more in the loop concerning the work of our friends at one of the world's largest Banks, who have been using Apama for FX Aggregation for well over a year, connecting to multiple liquidity pools to improve their execution. That bank has have recently launched a new FX pricing engine - built with Apama - connecting to their Apama FX Aggregator for real-time pricing, running analytics to derive per-client spreads for market making (similar to how I describe [here]). An auto-hedger is in the works - again extending the initial FX Aggregation deployment and based on the Apama CEP platform. And at least 3 other FX clients have either rolled out or are in the process of rolling out market making solutions as extensions of Apama FX Aggregation deployments (and those are the ones I actually know about!).

Moving beyond auto-hedging and market making, we have a growing number of examples of the benefits of a more strategic "platform" approach, such as Apama clients like ING in Europe taking FX feeds into their Equities Algo systems (also built on Apama) for cross-border spreads (locking in an FX rate as the third leg of the trade), prop shops engaged in currency forward / spot arbitrage, and clients like Louis Capital FX extending their Apama-based FX agency hedging their FX options trading. (As an aside, one the hottest topics for us right now in FX is the area of real-time Forward FX price streaming to large corporates - once the province of the very biggest banks - utilizing real-time volatility and depth of book analytics ...)

The power of the more strategic approach enabled by CEP platforms like Apama, armed with the out-of-the-box connectivity, performance, resilience and tooling, to meet client's current and future needs, is nowhere more ably demonstrated by our experiences in FX.

Saturday, September 13, 2008

The Need for Speed: Don't Strangle the Front Office!

Posted by Richard Bentley

I'm currently looking out of my hotel room window at preparations for the upcoming Singapore F1 Grand Prix - a road race under lights which - if the level of preparation is anything to go by - will be a truly awesome spectacle. I only wish I were staying here long enough to see it ...

But enough titillation for the petrolheads out there; there is a (CEP related) point here. In my previous post I mentioned a presentation I gave at last week's Derivatives World Asia event entitled "Real-time Risk Management and Compliance: Don't strangle the Front Office!". The sub-title gives away the thrust of the argument - the increasing need for real-time risk controls without adding unacceptable milliseconds in pre-trade checks to the orders send by Algo and High-Frequency traders.

This is a very topical subject for CEP right now. Our friends at Coral8 and Aleri have both recently discussed this use case. Here at Apama, our upcoming and much extended Algorithmic Trading Accelerator (watch this space!)  includes a comprehensive Risk "Firewall" for real-time breach detection, alerting and prevention. By considering each trade instruction (order placement, amendment, cancel etc) as an Event, the requirements of real-time risk and market abuse detection would seem ideal for a CEP solution:

  • processing multiple event sources concurrently - algo flow, treasury flow, DMA etc - scalable to 000s of updates / second
  • extensible risk rule base - evolved through scripting and graphical tools
  • real-time dashboards for monitoring e.g. positions and position limits and adjustment
  • filtering combined with stateful risk rules for tracking e.g. open P&L, value at risk etc

Not to mention the need for ultra-low latency decision making - don't strangle the front office!

aside: There is something of an irony here. CEP in its current incarnation found its initial home in the Front-Office for Algo Trading. Now the same technology is being deployed in the middle-office Compliance Unit (the "Profit Prevention Department" as some of my trader friends refer to it) to directly combat the risks from the Algos ... a case of fighting fire with fire?

Before we get carried away here though, CEP - or any technology - can never be a panacea for real-time risk management. In researching my talk I reviewed a number of case studies of recent incidents where risk management and compliance seems to have failed - none more so than the infamous case from earlier this year at SocGen, where one trader's actions brought about a 5 billion Euro loss on the Eurex Futures Market. In this case, however, existing controls did their job (though not in real-time of course) - prior to the approx 50 billion Euro position being "discovered", 75 separate warnings were issued including:

  • trade settlement dates falling on a Saturday;
  • trades which broke counterparty credit limits;
  • trades where the bank was both both seller and buyer;
  • distorted counterparty brokerage fees

and more. Such issues could easily be translated into risk rules and embedded in a real-time firewall, but the failings here were not those of detection - they were principally human failings in taking appropriate subsequent action.

We can of course seek to address such failings e.g. by adding "trip switches" to our real-time CEP firewalls which require reset by senior Compliance officers but we'll never solve the problem entirely. In the SocGen case, the trader explicitly circumvented existing risk controls by logging fictitious trades using knowledge of the risk rules that were being applied - risk firewalls will only ever be as good as the rules they manage and the data they get; compliance will always, to some extent, be playing "catch-up".

But when we're talking about risk, we are talking mitigation, not necessarily guarantees. To get back to the opening topic of this post, traders are like racing drivers; we need to give them the tools to go as fast as possible but tools which, when they crash - which they will from time to time - allow them to get out of the car and walk away with nothing more than a few bruises.

That is where the (CEP-powered) real-time risk firewall comes in.

Singapore Sling

Posted by Richard Bentley

I'm currently in Singapore as part of a road trip visiting clients in SE Asia. As well as enjoying a nice change from the lousy British climate (winter followed by a slightly wetter winter, as an ex-pat described it to me), I'm very much enjoying meeting with traders and IT folk to discuss Algo Trading and CEP as it pertains to Asia specifically. Algo Trading is really big news in the region - and we're seeing significant growth for Apama as a result (see our recent press releases on our deployments at Bank of China International in Hong Kong and Leading Investment and Securities in Korea).

I spent the last couple of days at the Derivatives World Asia conference, giving a presentation on Real-time Risk Management and Surveillance (a rapidly growing area for Apama and CEP in general) and hosting a workshop on Algo Trading. A strong theme from this event concerned the huge regional variations in Asia concerning technological maturity, readiness of the banks to adopt algo, regulatory frameworks etc. Japan, for example, was one of the first to deploy sophisticated network infrastructure and electronify its markets, but is now suffering scaling issues as a result - a case of "first mover disadvantage". In countries like Singapore, which are coming later to the game, lessons have been learned with very impressive results. The Singapore Stock Exchange (SGX) recently launched a new platform for its Equities and Derivatives markets offering sub-millisecond access to the exchange through proximity hosting, and a trading platform capable of scaling to thousands of orders per second. Singapore is really gearing up for Algo - not only on the technology side, but also through incentives to attract the big banks into the country - with Citigroup and RBS joining Standard Chartered in locating significant operations here. The local banks are also in the game, with regional acquisitions driving growth in their Investment Banking and Brokerage operations.

Algo is big news in Asia and in Singapore specifically; it currently accounts for 12% of all Equities and 18% of Derivatives traded in Singapore but those numbers are set to grow rapidly. Having the fastest trading platform in Asia will certainly help nicely!

Thursday, June 12, 2008

Not Trading but Pricing

Posted by Richard Bentley

(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.

Saturday, April 26, 2008

Judgement Day

Posted by Richard Bentley

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?

Wednesday, April 23, 2008

On (Complex) Event Processing

Posted by Richard Bentley

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.