Client Engagements
The following describes a number of our current projects we’re supporting, or have supported, for clients past and present. All of the clients described are among the top global investment banks:
Background
Historically, stock markets were physical locations where buyers and sellers met and negotiated. With the improvement in communications technology, the need for a physical location is of diminishing importance as the buyers and sellers can electronically exchange indications of interests as well as negotiate from a remote location. Electronic trading makes transactions easier to complete, monitor, clear, and settle.
The Financial Information eXchange (FIX) protocol is an electronic communications protocol developed for international real-time exchange of information related to the securities transactions and markets. FIX has become the standard electronic protocol for pre-trade communications and trade execution.
The challenges
When a new order in FIX format arrives from a client it must be validated, normalized, enriched, and delivered to a proper destination, e.g., directly to an exchange or a trader or rejected. In certain situations some trading strategy should be applied. The system should also transparently support order replacements and cancellations and send executions back to a client.
The software that receives such orders must be capable of making many decisions quickly, based on a number of factors, including incoming order details, client idiosyncrasies, internal corporate policy, and global compliance. The system must be quite reliable and support 24/6 scheme. The architecture also must be robust enough to store considerable amounts of data and to be high performing. The latency of the system must be minimal with the highest possible throughput.
The existing software is written purely in C++ for Linux and Solaris platforms. It is dramatically redesigned to become a distributed system supporting clouds of services, so client gateways can be installed geographically closer to clients whereas exchange gateways can run geographically closer to stock exchanges.
The recovery mechanism is redeveloped to prove high reliability and decrease time required to recover and restart the system.
Memory caching mechanism is changed to support in-memory database. The system is also ported to 64-bit platform to get corresponding advantages.
Support of new versions of FIX is implemented.
Background
Trader desktop is a critical mission application that runs on trading-floor computers. This application usually displays a lot of information, including incoming orders, outgoing executions, and market data to help a trader make a trade. Performance and reliability of this application are extremely important, as a trader must make decisions quickly, and a short delay might cost the trader.
The challenges
The desktop is a .Net application that runs on MS Windows workstations. We were required to collect performance data in a live production environment during the trading day so statistics could be viewed in a convenient manner and analyzed later to find bottlenecks. Automatic alerts needed to be sent during the day if some counters exceeded their preconfigured thresholds. The system needed to be set up with some extra code to collect, calculate, and log performance figures such as durations and numbers of method calls to multiple destinations, e.g., plain file, database, or application server. Some of the most important requirements included affecting the existing code as little as possible and keeping the latency introduced by logging within a predefined percentage.
The Aspect Oriented Programming (AOP) technique helped us to inject logging code to the system with a minimal impact to existing code. Dedicated application server was written, so the logging can be done in 3-tier way. A rich-GUI analysis tool has been written to display analysis data in different manners.
On the other hand use of profilers helped us to find faults with design and implementation of existing code.
Background
Historically, stock markets were able to provide liquidity without transparency. Technology and the evolution of global real-time markets have demanded transparency and increased competition. Clients have become more diverse and well informed, and have many more options for executions. All of these advances have increased competition, reduced margins, and increased risk on portfolios, execution, and order processing.
Trading and execution environments require high volume, low latency, and stable matrix pricing capabilities that take into account global markets and need to do so on a 24/6 scheme.
The challenges
Build strategic pricing infrastructure for the Secondary markets trading desk globally. The goal is to provide a scalable and flexible pricing infrastructure based around core Risk capabilities and pricing infrastructure. Platforms must be designed with the open technology and latest high volume low latency abilities. Core applications such as this require continuous advancement and adjustment in order to meet the demands of global trading and competition.
Monitoring capabilities are an integral part of these platforms so that analysis of execution abilities can be made and used to plan future modifications of the software.
Background
Risk Management Tools are at the core of trader and trading needs. Fast-paced global markets have driven the requirements of risk management tools to complex new heights. In this fully integrated global market, the development of good risk management tools is never ending.
Tools deployed to traders and risk managers must have both the control and stability of centralized systems and databases and yet still be open enough to interact with the numerous customized tools and sources of information supporting the nuances of market strategies or a product.
The challenges
The risk viewer or desktop needs to be both an integrated and completely open architecture and processing paradigm. Good risk platforms are not only fast in execution and rich in analytic and pricing abilities but must be smartly architectured. These systems need to be COM-based distributed systems with 3 major layers: 1) GUI: trade capture tools, trade blotters, market data viewers, Excel spreadsheets with VBA code; 2) risk calculation libraries; 3) high performance databases: components for reading/writing trades to database, SQL code: tables, views, packages.
Background
The Engine is the central processing server for all equity trades and the main interface to systems on the street as well as to other internal systems. It validates trade requests against internal business rules and can reject poorly formed trades. It stores only accepted trade requests and trade events like orders and executions. The Engine is written in C/C++ language and runs on UNIX.
The challenges
The server experiences maximum load at the end of the trading day when traders close their orders. Thus the challenge was to re-architecture the server to
- support multithreading and clusterization for better parallelism and reliability
- change maintenance cycle to 24/6
- support new application-level network protocol
- improve the recovery mechanism dramatically, so not only the current state of trade could be restored but so the whole trade lifecycle could be replayed upon client request.
Apart from the server changes, client API’s needed to be redesigned and reimplemented. Those include C++, .Net and Java API’s.
Background
The Financial Information eXchange (FIX) protocol is a messaging standard developed specifically for the real-time electronic exchange of securities transactions. A FIX Engine is a piece of software that manages a network connection, creates and parses outgoing and incoming messages and recovers if something goes wrong. The Engine is written in Java language and runs on UNIX.
The challenges
As the low latency and high throughput and high availability are critical for real-time electronic trading, the challenge was to develop highly optimized and reliable system that can
- communicate via FIX over TCP protocol with the client
- communicate with other internal systems using fast proprietary protocols and third-party messaging systems
- implement recovery mechanism, so when the Engine starts up after a failure it can process any lost messages from the downstream applications
Background
Many trading applications need to know exchange working days and open hours to accept orders and function properly. This is of special importance for financial conglomerates operating across the globe.
The challenge
The purpose and objectives of this project included
- provide applications with a modern, robust, and powerful yet simple approach to obtaining date and time stock exchange information via web service
- provide application developers with simple API’s that wraps communication with the web service. Those API’s include three major development platforms, C++, .Net and Java
Background
The role of the trades and positions processing integration system in the bank is as a financial guardian of the bank’s sales and trading activities. This role fulfils through
- ensuring complete, accurate and timely P&L and Balance Sheets
- independent validation of bank’s trading positions’ valuations
- evaluating and integrating new products and businesses into bank’s financial environment
These activities are performed via application for trading– a key element in the trades and positions processing integration system infrastructure.
The challenge
The application for trading is a strategic data-store of reference data, trades, positions, cash balances, trial balances, and adjustments in a standardized data-model. Its major business functions are the following:
- validating and exception handling of key business attributes on all trades, positions, and cash
- building unadjusted trial balance sheet
- validating and reconciling front/back office trades, positions, cash flow/payable receivables, cash balances, and P&L
- producing balance sheet and P&L reporting, including Clean P&L
- aggregating cash flows into cash balances