Latest Updates: Trading RSS

  • Comet Servers for a Single-Dealer Platform (SDP)

    Martin Tyler 10:10 am on 27th April, 2010 | 8 Permalink | Reply
    Tags: , SDP, Trading

    There is a lot more to a Single-Dealer Platform than just a Comet Server, but it is still a key component and often one of the components bought in rather than developed in house. At Caplin we have dedicated much of our time to building what we believe is the Comet server that offers the best performance and feature set on top for building a SDP. Hopefully this post will explain why we believe this, and where you might have more work to do with the other products.

    A Comet server allows an SDP to deliver prices and manage trading between a backend system and a browser client – although many will support other clients too. These days there are a number of choices for a Comet server, and more of them are realising that financial data is a great use case and targeting effort in that direction.

    Questions?

    If you are choosing a Comet server for an SDP there are a number of questions you should be asking that will have a big impact on the amount of integration and other work you will have to do.
    (More …)

     

  • Negative Latency - Breaking the Zero Barrier

    John Anderton 6:30 am on 1st April, 2010 | 1 Permalink | Reply
    Tags: latency, , Trading

    Every second counts - or in financial markets, we’re usually talking milliseconds or even microseconds. The faster you can get a price to a client the better.

    We have been very busy recently on R&D and are now close to releasing the Agatha negative latency trading platform.

    Using advanced predictive algorithms we are able to send price changes to clients in advance of all other trading platforms.

    This technology effectively breaks the zero latency barrier by predicting future events. The Agatha platform allows users to “pretrade” leading to more profitable arbitrage strategies.

    Agatha is self tuning. The more confident the price prediction the earlier it will be sent out. There is a danger that when prices are predicted too early that it can actually have a knock on effect on future events.

    Ongoing testing shows predicted prices are accurate 99.8% of the time, and the minority of prices that are inaccurate are reported back into the system acting as a feedback loop which allows the self tuning to adjust how early prices are sent.

    Over the years we have carried out benchmarks on Liberator that focus on latency, sending high update rates to large numbers of clients in the shortest possible time. We have always been proud of our ‘close to zero’ latency figures.

    The problem is that the margins of improvements are getting smaller and more and more people are in the low latency game now. Customers are demanding more and we had to make a game changing move.

    Vast sums of money are made, and lost, based on latency of information. In this article by InformationWeek it was estimated that a 1 millisecond advantage in trading applications can be worth $100 million a year to a major brokerage firm.

    Think of the effect negative latency could have on profits!

     

  • 3 Generations of RIA Trading

    Martin Tyler 11:57 am on 31st March, 2010 | 0 Permalink | Reply
    Tags: , , Trading

    Matt’s post on RIA Streaming Architectures is something we have experienced over the years too.

    Liberator has always supported bidirectional messaging, but the first people to use it for trading still decided to do the trading part using an App Server, with real time responses and market data through Liberator – a kind of circular architecture. This wasn’t strictly down to the capabilities of Liberator, but more about using existing technology and skills rather than putting all eggs in the new tech basket.

    In recent years we have focussed more on trading in the financial markets and customers have got more familiar with the technology, so they do it all through Liberator (Matt’s third generation). This allows the backend applications to work more like a real time event based application rather than being shoe horned into a web server paradigm.

    We’ve built higher level APIs specific to the trading domain, rather than just the low level capabilities of request/response/topics/queues etc, so you don’t have to work out the best way to layer your domain model on top of a generic messaging system. This doesnt change the overall architecture as such, just how much of it you have to write yourself – so maybe it’s 3.5G :)

     

  • Ignoring UX could cost you

    Sarah 3:23 pm on 28th January, 2010 | 3 Permalink | Reply
    Tags: , Trading, ,

    This is why it’s all about the UX and not the UI.  Those in the business of developing front-end trading applications – take note.

    You have got to look beyond the graphics and explore the interaction while thinking about avoiding those “fat finger” moments… http://arstechnica.com/business/news/2010/01/how-a-stray-mouse-click-choked-the-nyse-cost-a-bank-150k.ars

    Here at Caplin we are passionate about RIAs and are now seeing a rapid acceleration of client interest in this area, that’s why we are expanding our team in this area.

    Related Posts with Thumbnails