Jump to content

User:Alexkachanov/Finance/Technologies/Sell-side

From Wikipedia, the free encyclopedia

Брокер-дилер

[edit]
Main page: User:Alexkachanov/Finance/Sell-side

Общие заметки

[edit]
  • управление проектами: Maven
  • сборка и deployment проектов: Maven, Ant, самописное
  • continuous testing: Hudson/Jenkins, Bamboo, CruiseControl
  • source management: SVN - почти везде, CVS - отмирает, но есть
  • bug management: почти везде JIRA
  • document management: Confluence, MediaWiki, Sharepoint

база данных

[edit]

чаще всего Oracle или IBM DB2/UDB.

Очень популярным был Sybase (особенно в Goldman Sachs), но теперь выходит из моды и заменяется.

MS SQL редко встречается, но используется, например matching engine Лондонской биржи использовал все решения Microsoft, включая MS SQL.

Для скоростных торгов стандартные базы данных слишком медленны, поэтому все структуры данных хранятся в памяти либо используется in-memory базы данных (in-memory databases), которые очень редко пишут на диск и держат все в надежной памяти. DataSynapse, Platform, GigaSpaces, Gemstone and Tangosol. В случае падения приложения данные восстанавливаются обработкой потока пришедших и ушедших сообщений.

Платформа

[edit]
  • очень популярен Linux, иногда встречается Solaris. в back-office часто встречается устаревшая IBM AS/400. Очень редко встречается Microsoft на серверных приложенях. В основном в подавлящем случае - на офсиных десктопах
  • Самые популярные языки: Java, C++, C#.NET. очень разнообразные зоопарк. Нет общего единства. Каждый отдел торгующий своими инструментами может выбирать свою платформу какая ему удобнее.

Java

[edit]
  • Перешли все на Java 5/6. Медленно и очень осторожно рассматривают переход на Java 7. Ходят слухи, что где то еще используется даже Java 1.4, но не встречал
  • J2EE используется, но в солидных back-office приложениях, там где нужна скорость - в трейдинге - там J2EE не используется. очень часто вместо полноценного applciation server-а используется lightweight решение: Tomcat, Spring, Hibernate
  • обратить внимание на Azul и их JVM Zing, которая имеет хитрости с garbage collection

Новые технологии

[edit]
  • FPGA - из-за гибкости настройки под требуемые вычисления: для разбора рыночных данных со скоростью поступления этих данных - данные используются для proprietory trading, для market making, и далее везде где нужны данные как исходная точка для других вычислений
  • GPU - из-за скорости параллельных вычислений с плавающей запятой: для оценки деривативов - опционов методом Monte-Carlo, потом эти данные используются: для оценки рисков открытых позиций в реальном времени, для приняия решения в market making, для оценки portfolio в
  • 10 Gbit сети
  • сетевые карты SolarFlare со встроенным программируемым модулем FPGA, котоырй позволяет на уровне сетевых протоколов фильтровать данные, подавая в карту только те данные, которые интересны получателю на данном компьютере
  • Real time analytics - Hadoop, Shark
  • Excel analytics and Grid compute plugins
  • Complex maths libraries
  • DevOps - Chef, Puppet

Client Connectivity (FIX)

[edit]

Подобно бирже брокерская система общается с внешним миром - buy-side - через протокол FIX. В отличие от биржи у брокеров не бывает своего native протокола, потому что брокер, в отличие от биржи, подстраивается под клиента. Брокер использует свой собственный FIX-движок или покупает существующий у сторнних вендоров, которых полным полно.

  • NYFIX – Appea
  • Aegisoft – Aethna
  • Reuters – Traid
  • Financial Fusion (Sybase) - TradeForce
  • CameronFIX (Orc Software)
  • Other Major vendors support as part of their trading platforms
    • Fidessa
    • GL Trade etc
  • QuickFix – Open Source FIX Engine (C++/Java)

Для подключения клиента к своей системе брокер предоставлят клиенту спецификацию FIX-а, которую он поддерживает, и клиент следуя этой спецификации настраивает свой FIX-движок. Брокер старается со всеми клиентами придерживаться одной и той же спецификаии FIX-а. Чаще всего и популярнее всего - версия FIX 4.2 без каких-либо дополнений и кастомизаций - все зависит от инструментов, которыми торгуют брокер и клиент. Например ранние спецификации FIX не поддерживали сообщения про деривативы или торги с валютой, поэтому для такого обмена сообщений выбирают спецификацию более позднюю. FIXML почти не используется - так как из-за своей разбухлости - он увеличивает latency при формировании сообщений, их передаче и разборе.

Market connectivity

[edit]

Refence database

[edit]

Хранит записи обо всех инструментах которыми торгует данный брокер. Хранится в Золотой базе данных и раздается всем системам брокера на условиях readonly. База данных заполняется работниками back office по мере появления новых инструментов. Крупные брокеры имеют свою базу данных. Мелкие покупают целую систему управления этими данными так как их е тоько надо один раз вводить но и постоянно обновлять

Каждый инстурмент имеет идентификаторы. Эти идентификаторы многочисленны: CUSIP, ISIN, SEDOL, и идентификаторы от reuters (ric) и bloomberg. В каждой стране есть еще и свои организации которые присваивают местным ценным бумагам идентификаторы

Messaging

[edit]

Получив сообщение на своем шлюзе, брокер дальше его передает от системы к системе. здесь несколько вариантов передачи сообщений внутри брокера: либо все тот же FIX либо TibcoRV либо через стандартный messaging: JMS/ MessageQueue - все зависит от того, какая технологическая платформа популярна у брокера.

Introduction

[edit]

High performance messaging:

  • Tervela - implements a pub-sub messaging system in hardware
  • TIBCO (Tibco RV, TibcoEMS)
  • IBM (WebSphere MQ Low Latency Messaging)
  • Wombat
  • 29 West (LBM - Latency Busters Messaging) - For a software-based solution, we might choose the equally impressive LBM and associated products from 29West.
  • RTI
  • Solace Systems

Самым популярным hardware в высокоскоростном messaging явлются продукты компании Tervela.

Лидерами в программном messaging являются TIBCO и IBM, но новые компании с помощью инноваций наступают им на пятки и готовый уже потеснить лидеров.

Functionally there are two application components in the enterprise trading environment, publishers and subscribers. The messaging bus provides the communication path between publishers and subscribers.

Technologies and Innovations

[edit]

NYSE Technologies wrote their own middleware using Remote Direct Memory Access (RDMA) to bypass the operating system, and create a shared memory approach. Each processing node runs its own daemon, or background process, to manage fan-out capabilities of the messaging infrastructure. NYSE Technologies claims they can push 2.1 million 200-byte messages in 700 nanoseconds point-to-point on their middleware

QuantHouse built FeedOS, their proprietary middleware, to move market data through their infrastructure. Customers access the middleware through client-side application programming interfaces written in Java, C++, or C#. Internally, FeedOS is C++ running on a Linux 64-bit architecture. QuantHouse wrote FeedOS to be natively multi-threaded, allowing them to scale up to new hardware as it becomes available.

Другие компании работають с технологией FPGA.

Есть компании которые пользуются оборонными технологиями в messaging. Например, технологии компании Real-Time Innovations (RTI), которые используют протокол data distribution service (DDS).

Протокол DDS и the advanced message queuing protocol (AMQP) сейчас конкурируют друг с другом за право стать стандартом.

очень клиенты хвалят 29 West и их продукт Latency Busters Messaging (LBM) за простоту и стабильность

The messaging bus is middleware software from vendors such as Tibco, 29West, Reuters RMDS, or an open source platform such as AMQP. The messaging bus uses a reliable mechanism to deliver messages. The transport can be done over TCP/IP (TibcoEMS, 29West, RMDS, and AMQP) or UDP/multicast (TibcoRV, 29West, and RMDS). One important concept in message distribution is the “topic stream,” which is a subset of market data defined by criteria such as ticker symbol, industry, or a certain basket of financial instruments. Subscribers join topic groups mapped to one or multiple sub-topics in order to receive only the relevant information. In the past, all traders received all market data. At the current volumes of traffic, this would be sub-optimal.

There are efforts in the industry to standardize the messaging bus. Advanced Message Queueing Protocol (AMQP) is an example of an open standard championed by J.P. Morgan Chase and supported by a group of vendors such as Cisco, Envoy Technologies, Red Hat, TWIST Process Innovations, Iona, 29West, and iMatix. Two of the main goals are to provide a more simple path to inter-operability for applications written on different platforms and modularity so that the middleware can be easily evolved.

In very general terms, an AMQP server is analogous to an E-mail server with each exchange acting as a message transfer agent and each message queue as a mailbox. The bindings define the routing tables in each transfer agent. Publishers send messages to individual transfer agents, which then route the messages into mailboxes. Consumers take messages from mailboxes, which creates a powerful and flexible model that is simple (source: http://www.amqp.org/tikiwiki/tiki-index.php?page=OpenApproach#Why_AMQP_).

Market data delivery is a perfect example of an application that needs to deliver the same data stream to hundreds and potentially thousands of end users. Market data services have been implemented with TCP or UDP broadcast as the network layer, but those implementations have limited scalability. Using TCP requires a separate socket and sliding window on the server for each recipient. UDP broadcast requires a separate copy of the stream for each destination subnet. Both of these methods exhaust the resources of the servers and the network. The server side must transmit and service each of the streams individually, which requires larger and larger server farms. On the network side, the required bandwidth for the application increases in a linear fashion. For example, to send a 1 Mbps stream to 1000recipients using TCP requires 1 Gbps of bandwidth.

IP multicast is the only way to scale market data delivery. To deliver a 1 Mbps stream to 1000 recipients, IP multicast would require 1 Mbps. The stream can be delivered by as few as two servers—one primary and one backup for redundancy.

There are two main phases of market data delivery to the end user. In the first phase, the data stream must be brought from the exchange into the brokerage’s network. Typically the feeds are terminated in a data center on the customer premise. The feeds are then processed by a feed handler, which may normalize the data stream into a common format and then republish into the application messaging servers in the data center.

The second phase involves injecting the data stream into the application messaging bus which feeds the core infrastructure of the trading applications. The large brokerage houses have thousands of applications that use the market data streams for various purposes, such as live trades, long term trending, arbitrage, etc. Many of these applications listen to the feeds and then republish their own analytical and derivative information. For example, a brokerage may compare the prices of CSCO to the option prices of CSCO on another exchange and then publish ratings which a different application may monitor to determine how much they are out of synchronization.

The delivery of these data streams is typically over a reliable multicast transport protocol, traditionally Tibco Rendezvous. Tibco RV operates in a publish and subscribe environment. Each financial instrument is given a subject name, such as CSCO.last. Each application server can request the individual instruments of interest by their subject name and receive just a that subset of the information. This is called subject-based forwarding or filtering. Subject-based filtering is patented by Tibco.

A distinction should be made between the first and second phases of market data delivery. The delivery of market data from the exchange to the brokerage is mostly a one-to-many application. The only exception to the unidirectional nature of market data may be retransmission requests, which are usually sent using unicast. The trading applications, however, are definitely many-to-many applications and may interact with the exchanges to place orders.

In many market data applications, optimizing the data organization would be of limited value. Typically customers bring in all data into a few machines and filter the instruments. Using more groups is just more overhead for the stack and does not help the customers conserve bandwidth. Another approach might be to keep the groups down to a minimum level and use UDP port numbers to further differentiate if necessary. The other extreme would be to use just one multicast group for the entire application and then have the end user filter the data. In some situations this may be sufficient.

  • Nasdaq Quotation Dissemination Service (NQDS).
  • Nasdaq Totalview service

A common issue with market data applications are servers that send data to a multicast group and then go silent for more than 3.5 minutes. These intermittent sources may cause trashing of state on the network and can introduce packet loss during the window of time when soft state and then hardware shorts are being created.

Order Management Systems (OMS)

[edit]

По простому OMS это журнал ордеров (trade blotter), в котором ордера создаются, отслеживаются и репортятся. Дополнительный функционал системы включает в себя:

  • коммуникациооный модуль - каналы связи, по которым вводятся ордера в систему, и каналы связи по которым ордера оправляются на исполнение
  • каналы связи с back-office, куда отпраляются отчеты об исполнении
  • менеджмент позиций - отслеживание лимитов, проверка рисков, compliance
  • валидация ордеров по ценам рынка, по свойствам ордеров
  • роутинг ордеров по каналам связи в зависимости от предпочтений оператора
  • UI - в котором смотрятся все ордера, а также элементы UI, если ордера воодятся вручную

Выбор вендора очень сильно зависит от того каким классом ценных бумаг ведется торговля. У одного итого же брокера могжет быть несколько oms причем наромер для торговли деривативами написаная своя а скажем для торговли акциями купленная у вендора и откастомизированная под свои особенности.

У крупных брокеров системы торговли разными классами инструментов между собой не пересекаются, поэтому отделы брокеров делятся именно по классам ценных бумаг и каждый отдел формирует свой зоопарк-экосистему программных продуктов от фронтофиса вглубь до бэк оффиса

Например, в торговле акциями очень часто вижу fidessa. Но все зависит от традиций брокера и регионов и обьемов торгов.

Order Management Systems, (OMSs), place shares in queue for trading but are principally concerned with back- and middle-office functions, such as portfolio rebalancing, accounting, and management and documentation of trading activity.

OMS has functionality, such as portfolio modeling and staging as well as compliance, built in to allow for the involvement of the portfolio manager to facilitate the transfer of trades to the trader in a traditional institutional environment, he explains. According to Little-Gill, the OMS encompasses five components: the FIX messaging capabilities, the trading blotter, post-trade support, compliance and portfolio modeling.

The OMS was architected for holding long-term positions, rebalancing the portfolio around compliance and analyzing the performance. The traditional database architecture of the OMS is not suitable for processing heavy transaction volumes and receiving back thousands of small fills.

OMSs have been around for about 15 years and were intended as a replacement for the paper blotter; originally, traders using the phone as their primary execution device manually entered trades into the electronic blotter. Traditional OMS vendors include Charles River Development, Indata, Advent, Macgregor (recently acquired by broker ITG) and Eze Castle (recently acquired by Bank of New York).

Что такое Order Management System в финансовой индустрии?

  • Eze Castle: Eze OMS (куплен Bank of New York)
  • SunGard: Decalog Trader
  • Indata: Precision Trading
  • Paladyne Systems Portfolio Master,
  • Object Trading Limited (OTL)


In-house vs. Vendor

[edit]

In-house solutions give you a compettive advantage, reduce time to market, more flexible release schedules, more contillable QA, etc. The support costs are also not much higher. You can also alter home grown solutions more easily, for example adding an internal market to cross on, etc. Vendors are great for standard access where latency is important but not crucial. Go in-house for highly latency sensitive or complex rule-based market access and maximum flexibility.

Unlike broker-dealers, buy-side firms do not usually build their trading or order-management systems. Instead, they use off-the-shelf trading and order management applications for their pre-trade analysis and compliance checks, and for sending FIX trade orders to multiple broker-dealers

Fidessa

[edit]
  • OMAR - Order Management And Routing
  • TMAR - Trade Management and Routing
  • CTAC - Client Trade, Allocation and Confirmation System
  • BEAM - controls baskets and waves of orders for program traders
  • Pairs - allows user to create and control pairs of related orders
  • BlueBox - flexible, programmable algorithmic trading engine
  • PMAC - Position Management and Consolidation
  • ROMA - Remote order management application


  • FTW - fidessa trader workbench
  • FTP - fidessa trading platform


  • EMMA - European Multi Market Access System
  • Amma - Asian Multi Market Access
  • JMIS - Japanese Market Interface System
  • NMS - NASDAQ Management System

Execution Management System (EMS)

[edit]

Execution management systems (EMSs) are desktop software applications that provide access to trading venues. Often, they place a layer of intelligence over this access, containing features such as algorithms, market data and predictive technology.

Major EMS providers include TradingScreen, Portware, FlexTrade, Nexa-InfoReach, UNX and Royalblue. Almost all of the major brokers also have their own EMS offerings; the most well-known are Goldman Sachs' RediPlus, Citigroup's Lava Trading and Lehman Brothers' recently acquired RealTick.

EMSs, on the other hand, are wholly offspring of the electronic trading era. They came onto the scene with the rise of day trading by individuals in the late 1990s and early part of this decade. The systems - initially called direct-market-access (DMA) platforms - originally were bare-bones applications that provided single-stock trade execution on electronic markets. They since have been appropriated and upgraded for professional use and now are known as execution management systems

EMSs tend to be less demanding on computers than OMSs and, as such, can be operated remotely by an offering broker on behalf of a buy-side trading client. Often, they are provided to clients for "free" by brokers, which subsidize the systems' maintenance with the buy side's soft-dollar payments for research and other broker services.

EMS basically is a [thin] client ... that can be run on a desktop," he explains. As a result, EMSs often are delivered remotely via ASP. An OMS architecture is a very heavy-client, database-centric architecture" that traditionally requires local installation and tight database and systems integration.

Although they were borne as completely separate systems, the OMS and EMS are starting to bleed together. Traditional OMS vendors, such as Charles River Development, are working on developing EMS applications as closely linked companions to their bread-and-butter software, as well as introducing more EMS-like functions, such as real-time data, into their OMS platforms. At the same time, it is likely that EMS systems will gain broader customer reach, adding portfolio staging capabilities and analytics that once were the sole province of OMSs.

The biggest demand on EMSs from buy-side traders is for strict broker neutrality - the assurance that no matter who owns the application, buy siders will be able to reach all markets and counterparties without interference or espionage from the system's owner. The increasing number of broker purchases of EMSs has some traders nervous - especially when it comes to increasingly important functions, such as trade cost analysis (TCA).

Most of the EMS and OMS vendors interviewed by Advanced Trading expressed a strong desire to remain independent. However, there are different approaches to remaining broker-neutral, even if broker ownership becomes inevitable.

An EMS is a software-based platform that facilitates and manages the execution of securities orders. I would say Bloomberg and SunGard Global Trading's "GL Trade" fall under that category.

These are not to be (but often are) confused with order management systems (OMSs), which place shares in queue for trading but are principally concerned with back- and middle-office functions, such as portfolio rebalancing, accounting, and management and documentation of trading activity.

An OMS should be able to do the above but also feature compliance & PnL functions as well as possibly post trade settlement functionality. I would say Charles River, Fidessa, MacGregor, etc. fall under that category.

An execution management system (EMS) is a software-based platform that facilitates and manages the execution of securities orders typically through the Financial Information eXchange (FIX) protocol. An EMS features four key ingredients: a trading blotter, connectivity, multiple destinations, and real-time market data. This TowerGroup Research Note compares the typical features of an EMS with those of its order management system (OMS) cousins. The Note discusses the evolution of these products, factors to consider when evaluating EMSs, and the future of EMS platforms.

EMS решения

[edit]

Сторониие вендоры

  • Bloomberg: Bloomberg EMS
  • 4th Story: 4S.Everglades
  • EdgeTrade: EdgeTrade EMS
  • FutureTrade: FutureTrade EMS
  • NYFIX Millenium (куплена BNY ConvergEx Execution Solutions, LLC. в декабре 2009):
  • Orc Software: OrcTrader
  • Tethys Technology: Execta Premium Execution Management System


EMS решения от брокеров

  • Goldman Sachs RediPlus
  • Citigroup: LavaX EMS от Lava Trading - EMS Business transferred to TradingScreen after June 30, 2009.
    • Lava ColorBook, which integrates order books from ECNs, exchanges, and liquidity sources into a data feed
    • ColorData and LavaFlow ECN
    • Lava Trading Floor, a front-end trader workstation;
    • Lava ColorMaker, an art market making application;
    • Lava ColorPalette, a sellside trading and order management solution;
    • and LavaX, a neutral and multi-broker platform;
    • Lava Trading Feed, a subscription-based market data feed that consolidates information from exchanges and ECNs
  • Lehman Brothers: RealTick
  • JP Morgan: Neovest
  • Morgan Stanley: Passport
  • Instinet: Trading Portal and Newport

Crossing System

[edit]

У большого брокера ордера на исполнение могут поступать из разных источников (как говорят, разные flow) - через электронную систему, через телефонный звонок. Это значит, что может так получиться, что один клиент брокера хочет продать то, что другой клиент брокера хочет в то же время купить. По обычному эти два ордера брокер должен отправить на биржу, и там они "найдут" друг друга, но можно провести встречу (crosstrade) и внутри брокера, не отправляя ордера на биржу. Это делается в crossing system, которая представляет собой самодельный местный matching engine, потворяющий правила двдижка биржи, где котируются данные ценные бумаги. Это разрешается делать брокерам только при том условии, которое выставляет контролирующий орган, что отчет об исполнении ордеров будет отправлен на биржу, где данные финансовые инструменты котируются, а оттуда попадет в market system, и далее распространится по всем market data system как trade, который произошел на бирже.

Дальнейшее развитие кроссинговой системы привело к созданию так называемых "dark pools". Это свои собственные микробиржи при брокерах, у которых так много клиентов, что те даже не заморачиваются тем, чтобы их ордер в конечном счете попал на биржу, они торгуют внутри этого dark pool, потому что не хотят раскрывать себя или объем своего заказа контрагентам.

Ticker plant

[edit]

Managed remote ticker plant:

  • Activ

A ticker plant is a software platform enabling financial institutions to receive, process, manage, monitor, distribute and report financial market data for feeding proprietary trading applications, client or other third-party downstream applications and program trading applications.

A ticker plant is composed of source servers (also known as feed handlers) and functional components.

Source server (feed handlers)

[edit]

In taking direct data feeds companies are faced with a task of integrating such feeds into their own environment, whether that environment is a standard market data distribution system such as TIBCO or Reuters, or some internally developed market data system.

The source servers normalize various sources of data into a common API while the ticker plant components provide value, which would include datacaching, analytics, data maintenance and cleansing, data decoding and entitlements, among others. This normalized and processed data is often fed into proprietary trading applications or client or third-party downstream applications. Source servers in and of themselves provide little value other than to insulate the downstream applications from the frequent changes and idiosyncrasies of the exchange formats.

Many financial firms, data and technology providers, however, have written source servers to simply pass through data in a normalized format. The value of a “true” ticker plant lies with the add-on components that are fed by the source server.

Functional Components

[edit]

A key component of a ticker plant includes data maintenance and cleansing tools. These tools allow for intra-day and daily corrections to the numerous exchange updates as well as corrections that are required to keep bad ticks and other incomplete information from corrupting the ticker plant’s database. These tools ensure the integrity of the data being sourced from the ticker plant.

Another component is a permissioning system. A ticker plant should include a turn-key entitlements system that is easily accessed via the Internet and easily integrated within the back office. A permissioning system also enables secure entitlement functionality and reporting capabilities to ensure compliance with the exchanges and their respective regulations. Further, entitlement tools should be capable of using a number of industry standard languages including VARS and VRXML.

Another ticker plant component includes a set of system monitoring tools to adequately supervise and manage all stages of the ticker plant. These tools allow for the complete command of communications lines and systems within the ticker plant.

RMDS: Пример решения от Reuters

[edit]

RMDS is the next generation successor for the Reuters Triarch and TIB market data platforms. It integrates the best features from these two systems and provides clients with an unprecedented combination of functionality, flexibility, low total cost of ownership, manageability and reliability.

It is a highly scalable system that distributes real-time market information from a variety of market data sources to a range of analytical, display and trading applications.

RMDS is a modular system consisting of several products which can be introduced incrementally. These products provide a number of powerful capabilities.

  • Point-to-Point delivery (P2PS) – ideal for high volume applications that require a dedicated distribution for desktops.
  • Multicast delivery (RTIC) – ideal for desktop applications with high commonality.
  • Internet delivery (IFP) – ideal for applications with low update frequency integration requirement.
  • Reuters Wireless Delivery System (RWDS) – provides streaming access to Reuters and internal data on the BlackBerry.
  • Wide-Area Networking (WAN) – ideal for efficiently sharing data with remote users or branches.

Reuters Market Data System 6

RMDS 6 is the latest version of Reuters market data platform. Designed around new, ultra-efficient core components, it brings unprecedented speed, resilience and flexibility to your data operations.

Reuters has also introduced the Open Message Model (OMM) in this release. OMM is a new and open set of data modelling tools that allows the representation of data using complex data structures and rich request paradigms. OMM will provide support for Full Order Books, and has the flexibility to allow customers to create their very own domain objects if they so require. SSL 4.x and SASS3 data models will continue to be supported.

A key feature of RMDS 6 is a new binary message format called Reuters Wire Format (RWF) which substantially reduces the size of the market data updates. This increased efficiency will allow RMDS 6 to support higher update rates and comfortably manage the rapid growth in real-time update rates in the market.

RMDS 6 is fully backwards compatible; it will allow users wanting to take advantage of the new components the ability to roll them out gradually with continued support for legacy applications.

Some advantages of RMDS 6 are:

  • Ultra low end-to-end latency
  • Ultra high throughput
  • Multiple architectural options to optimise throughput and latency
  • Reuters Data Feed Direct fully compatible with RDF and RMDS
  • Reuters Data Feed Direct fully managed using RIC symbology and Reuters Data Model
  • Enhanced message layers give more flexibility and support richer data types


RTCE: Пример решения от Reuters

[edit]
Basic Deployment Model
[edit]

Common to the basic RTCE deployment model are the following servers and components:

  • The Feed Handler
  • The Persistence Server
  • The Analytics Engine
  • The RTCE Data Stores

The Feed Handler interfaces with the incoming market data, sending it on to the Persistence server. The Persistence server is responsible for ensuring the data is properly formatted and multicast to the available Analytics Engines. The Analytics Engine is the server that handles user requests (queries). The Analytics Engine interfaces with the time series data store in order to return the applicable results to the user. The time series data store houses all current and historical market data possessed by the firm.

The Feed Handler
[edit]

The Feed Handler is a system component that works with the Persistence Server; it is designed to receive data from incoming market feed sources.

Each different market feed is encoded in a proprietary format. It requires a custom Feed Handler designed specifically for that feed, and the RTCE platform provides direct support for all common market feeds. RTCE can handle one or more feeds simultaneously, with the data from each feed being collated into the same data store for processing by the Analytics Engine.

When the Feed Handler reads the market data from a feed, it maps the feed’s data to the internal RTCE data format. The information is then forwarded on to the Persistence Server. In addition to passing the information on to the Persistence Server, the Feed Handler also writes the original feed records to a log file for optional replay at a later date.

Working in conjunction with the Feed Handler is the Feed Manager. The Feed Manager is a module that runs within the Persistence Server and it is responsible for ensuring that the Persistence Server receives a steady flow of market data from the subscribed feeds.

In a typical deployment, market feeds are doubled up, forming redundant streams of data. The Feed Manager monitors the various feeds coming into the Persistence Server, ensuring that the stream is valid and consistent.

The Persistence Server
[edit]

The Persistence Server receives the relevant market data from the Feed Handler and broadcasts it to one or more Analytics Engines. The communication is via the specialized, proprietary Reliable Multicast Interface. The figure below shows the market feed coming into the Feed Handler and the RTCE-specific information getting sent by the Persistence Server to the Reliable Multicast Interface.

The Analytics Engine
[edit]

The Analytics Engine is a server that works at the heart of the RTCE platform. The Analytics Engine provides interfaces that allow external applications and systems access to the market data that is available in the time series data store and the XDS (the auxiliary data store). Through these interfaces, the Analytics Engine receives user queries, looks up the relevant data in the currently stored market data, and returns results in accordance with the user queries. Before returning results, the Analytics engine can perform computations on the market data, either directly through built-in analytics or indirectly through custom modules that have been added to the server.

Off-the-shelf, the Analytics Engine provides built-in analytics that perform the most common market data calculations. In addition, the Plugin Framework gives you the ability to create custom analytic modules. The analytical routines that you write with the Plugin Framework operate within the same process space as the Analytics Engine itself, ensuring the fastest execution possible of your custom routines.

During the normal course of events, the Analytics Engine operates as follows:

  1. The Analytics Engine receives market data from the Persistence Server via the Reliable Multicast Interface. As the Persistence Server receives the raw market feed, it distills the data into relevant market information by filtering out unneeded data. Before sending the relevant market data to the Analytics Engine, the Persistence Server optimizes the market data for storage size and retrieval speed.
  2. The Analytics Engine adds the market data to the time series data store, making it available for subsequent processing.
  3. Data is sent to the EventStream module to determine if the data is to be published or manipulated immediately. If a user has a subscription for the specific data being received, the EventStream module publishes this data immediately. See “The EventStream Interface” on page 25 for more information on this mode of operation.
  4. The Analytics Engine responds to queries received from external applications and retrieves the corresponding information from the time series data store, as needed by the user queries.
  5. If specified by a user request, the Analytics Engine performs calculations on the market data before sending its response.
  6. The Analytics Engine returns the information requested by the user query.
The RTCE Data Stores
[edit]

The RTCE time series data store can be considered the backbone of the platform: it stores all the real-time and historical time series data, making it available to the RTCE Analytics Engine. In addition to the market data, the data store includes an index to facilitate the ultra-fast retrieval of the needed market data.

P2PS

[edit]

The P2PS combines an optional high-speed in-memory data cache with intelligent distribution semantics used to implement the Point-to-Point Client LAN. The P2PS provides consolidated point-to-point access to all the information available on the Market Data Hub. It consumes data provided on the MDH and/or the Multicast Client LAN, optionally caches it and then re-distributes the data (using TCP/IP) to consumer applications upon request. This protects the consuming applications from the complexities of the multicast based traffic of the MDH and Client LAN. The P2PS supports all forms (RTIC, DTS) of simple publishing.

The P2PS can handle all forms of data, such as quotes, chains, time-and-sales, news stories and headline streams, etc. Access to P2PS data is authorized through DACS and enforced within the P2PS.

Applications typically have backup Point-to-Point Servers in order to provide resiliency. When an application loses connectivity to a P2PS, it will attempt to connect to a backup P2PS and re-open all of the items of interest (also known as failover). During initialization an application will periodically try each P2PS (in its configured list) in a ‘round robin’ fashion until it successfully establishes communication with one of them.

P2PS 6 supports connections with SSL-based client applications, SFC, RFA 5.0 and RFA 6.0. It provides access to all of the data types currently available to SSL-based applications and the new OMM data. In addition, P2PS 6 automatically converts RDM/RWF in the MarketPrice domain to Marketfeed for SSL-based client applications. It also converts Marketfeed data to RDM/RWF so that RFA 6.0 applications do not need to parse Marketfeed.

Ссылки

[edit]

Trading System

[edit]
  • (2009) High-Frequency Trading - A Practical Guide to Algorithmic Strategies and Trading Systems (ISBN 0470563761): page 233: Implementing High-Frequency Trading Systems

Algorithmic Trading Application

[edit]
  • Fidessa: Fidessa BlueBox
  • FlexTrade System

Automated Trading System

[edit]

Tick to trade is the time it takes to:

  1. Receive a packet at the network interface.
  2. Process the packet and run through the business logic of trading.
  3. Send a trade packet back out on the network interface.

Smart Order Router (SOR)

[edit]

smart order routers examine, in real‐time, the liquidity (shares available) across all the trading venues in the market and, to satisfy the requirements of Regulation National Market System or Reg NMS, automatically route an order to those execution venues that offer the best price. This process occurs without any involvement by the firm sending the order to the executing broker.

An “order router” is an application that generally allows an end user to submit an order to an execution venue. A “smart order router” applies preprogrammed analytics that carry out an execution strategy for order flow provided to the smart order router. Analytics programmed into the smart order router continually make adjustments, including re-routing orders in light of updated data feeds, to carry out their strategies and/or avoid unfavorable price movements until its customers’ orders are canceled or executed.

Услуга DMA

[edit]
  • "low touch"
  • DMA platform, direct market access (DMA) trading platform
  • co-location
  • Citigroup’s Lava Trading,
  • Goldman Sachs’ REDIPlus, and
  • Morgan Stanley’s Passport.

Традиционный DMA

[edit]

DMA был создан для day-trader-ов на заре электронного трейдинга в середине-конце 90-ых и в самом начале 2000-ых, когда рынок пер в верх на волне дот-комов и многие обыватели стали всерьез играть на бирже уже не как инвесторы, а как спекулянты. Для обслуживания запросов day-trader-ов появилось множество фирм-брокеров, которые предоставляли прямой доступ к рынку - Direct Market Access - через свои каналы. Когда рынок рухнул, количество day-trader-ов сократилось, следовательно у DMA-фирм поубавилось клиентов. Этим воспользовались крутые брокеры, которые в 2000-2004 годах стали скупать DMA-брокеров и интегрировать их технологии в свои технологии, предоставляя DMA как услугу уже солидным инвесторам и клиентам.

http://www.towergroup.com/research/content/glossary.jsp?page=1&glossaryId=383

Главными пользователями DMA у солидных брокеров стали хеджевые фонды. Стратегия хеджевых фондов требует быстрого исполнения ордеров, часто решение об отправке ордеров на биржу принимает даже не человек, а компьютер black-box. При использовании high frequency trading особенно важен прямой и быстрый доступ к рынку, без вмешательства брокера-посредника. Так вся цепочка приема и обработки ордеров стала автоматизированной: приказы в систему брокера отправлялись электронно через FIX в OMS брокера, они проверялись системой проверки рисков, и тут же отправлялись на биржу без всякой ручной обработки - т.е "low touch" или даже "zero-touch". Клиент сам решает, на какой рынок, из всех рынков, с которыми у брокера была связь, ему отправить ордер. Ордер снабжается меткой, на какой рынок его надо оправить, и брокер-посредник отвечает за прием ордера, его проверку и отправку по своим каналам на ту биржу, на которую ордер был направлен, поддержкой которых он занимался. Это так называемый "traditional DMA".

Это самый простой способ DMA, который может организовать брокерская контора. Просто прием ордера и отправка его на биржу проводятся автоматически с использованием FIX-протокола, а не вручную sales-trader-ом, этакий "автоматизированный sales-trader".

  • по приеме ордера компьютер брокера проводит "sanity check" на предмет того, что ордер не нарушает 1) никаких правил брокера и 2) никаких правил биржи, и 3) не содержит ошибок
  • потом клиенту отправляется уведомление, что ордер получен и принят к исполнению
  • ордер заносится в OMS брокера
  • после protocol transformation посылается на исполнение
  • брокер получает от биржи отчеты об исполнении
  • брокер отправляет отчеты об исполнении клиенту
[edit]

Для более требовательных клиентов брокеры предоставили услугу "sponsored DMA". Клиент сам обеспечивает соединение с дата-центром каждой биржи или с proximity дата-центром, договаривается о размещении своего оборудования, которое торгует на бирже под broker's unique market identifier (or MPID). Если у данного брокера нет договора с какой-то конкретной биржей, то клиент договаривается с другим брокером.

На оборудовании клиента (client trading tool, strategy server) устанавливается пакет проверки рисков (risk tool) от брокера, который проводит проверку риска перед тем, как разрешить ордеру отправиться на биржу, а также отправляет отчеты о торговле брокеру, его центральному серверу управления рисками. Через этот центральный сервер брокер ежедневно обновляет параметры рисков для клиента, и эти параметры передаются каждой рисковой программе и действуют на протяжение всего дня.

В отличие от "традиционного DMA", ордера клиента не проходят через инфраструктуру брокера-посредника и не регистрируются в OMS брокера. Клиент сам лично решает по какому из имеющихся каналов отправить ордера, сам занимается поддержкой связи с дата-центрами бирж и сам решает программыне вопросы передачи своих ордеров по протоколам каждой из бирж. Своим компьютерам в дата-центрах бирж клиент отдает команды по FIX протоколу, а комьютеры сами конвертируют их в родной API-формат биржи (FIX-to-exchange format conversion), если она не поддерживает FIX протокол.

Naked DMA

[edit]

Для еще более требовательных трейдеров брокеры-посредники пошли на еще большие уступки предоставляя так называемый "naked или pure DMA", где проверка риска осуществляется после отправки ордера на биржу, а не перед ней. Разумеется такая услуга связана с еще большим риском для брокера-посредника и может привести к недоразумениям и катастрофам, когда "сошедший с ума" компьютер клиента по ошибке отправит за несколько милисекунд такое количество рискованых ордеров, что потом брокер-посредник схватится за голову. Из-за подобных рисков регулирующие органы стали думать о запрете подобной технологи, так что ее будущее пока неясно.

Выводы

[edit]
  • выгоды для buy-side:
    • более низкая комиссия - по DMA ордерам брокер взимает меньше комиссию, чем за обычные
    • исполнение обязательных законов о best execution
    • более полный котроль за исполнением ордеров - buy-side сам решает (с помощью своих программных систем и своих стратегий), куда когда и как отправить свои ордера, когда их отменить и подправить, не доверяя эту работу трейдерам брокера
    • быстрое исполнение ордеров. Традиционное требование: чертверть секунды - т.е. 250 миллисекунд, для арбитражеров требуется и того меньше
  • риски для sell-side
    • фактически брокер сдает клиенту в аренду свой индетификатор, свое место на бирже. Биржа знает только брокера, и имеет отношение только с брокером. Следовательно брокер несет ответственность за все DMA ордера, сгенерированные его клиентами. Он несет и все риски, связанные с ошибками клиентов. Если клиент не заплатит брокеру, брокер все равно должен расплатиться с клиринговым центром биржи. Чтобы избежать риска дефолта, брокер обычно просит залог у клиента при подписании контракта. И чем "голее" DMA, чем выше риск, тем выше залог.

The actual use of DMA versus ST (sales-trader) managed order flow differs from firm to firm, however the trend has increasingly been for smaller order size but higher frequency trades to be traded on DMA systems.

DSA

[edit]

Direct means clients can directly use/access any of Broker's strategies once they have a brokerage account with Broker's that allows them to use the DSA product

So client can decide whether to use DMA - to trade himself - or to delegate trade to the algo box

Commissions from these trades are also different. it's negotiable on a per client basis and depending on the sophistication of the product. DMA is much cheaper around 5 bps on each trade. DSA oscillates between 15 and 25 bps per order

Рабочее место трейдера

[edit]

Trading Workplace. As financial institutions race to provide the best trade executions for their clients, traders are utilizing several simultaneous critical applications that facilitate complex transactions. It is not uncommon to find three or more workstations and monitors at a trader’s desk which provide visibility into market liquidity, trading venues, news, analysis of complex portfolio simulations, and other financial tools. In addition, market dynamics continue to evolve with Direct Market Access (DMA), ECNs, alternative trading volumes, and upcoming regulation changes with Regulation National Market System (RegNMS) in the US and Markets in Financial Instruments Directive (MiFID) in Europe. At the same time, business seeks greater control, improved ROI, and additional flexibility, which creates greater demands on trading floor infrastructures.

Traders no longer require multiple workstations at their desk. Thin clients consist of keyboard, mouse, and multi-displays which provide a total trader desktop solution without compromising security. Hewlett Packard, Citrix, Desktone, Wyse, and other vendors provide thin client solutions to capitalize on the virtual desktop paradigm. Thin clients de-couple the user-facing hardware from the processing hardware, thus enabling IT to grow the processing power without changing anything on the end user side. The workstation computing power is stored in the data center on blade workstations, which provide greater scalability, increased data security, improved business continuance across multiple sites, and reduction in OPEX by removing the need to manage individual workstations on the trading floor. One blade workstation can be dedicated to a trader or shared among multiple traders depending on the requirements for computer power.

The “thin client” solution is optimized to work in a campus LAN environment, but can also extend the benefits to traders in remote locations. Latency is always a concern when there is a WAN interconnecting the blade workstation and thin client devices. The network connection needs to be sized accordingly so traffic is not dropped if saturation points exist in the WAN topology. WAN Quality of Service (QoS) should prioritize sensitive traffic. There are some guidelines which should be followed to allow for an optimized user experience. A typical highly-interactive desktop experience requires a client-to-blade round trip latency of <20ms for a 2Kb packet size. There may be a slight lag in display if network latency is between 20ms to 40ms. A typical trader desk with a four multi-display terminal requires 2-3Mbps bandwidth consumption with seamless communication with blade workstation(s) in the data center. Streaming video (800x600 at 24fps/full color) requires 9 Mbps bandwidth usage.

Storage

[edit]

хранение tick data, historical data, time-series database

vendors:

  • Kx Systems
  • Vhayu
  • Sybase

Ссылки

[edit]
  • Fiorano JMS


Middle Office

[edit]

Clearing

[edit]

FFastFill SEALS - свое решение предлагает как сервисSaaS, а не в качестве продукта. То есть для составления отчетов и подбивки результатов торгов брокеру надо посылать свои отчеты которые обрабатываются компанией. У нее есть свой канал с биржей откуда компания тоже получает данные и сверяет все данные торгов чтобы выяснить кто кому слько должен и все ли торги записаны правильно у всех сторон

http://www.ffastfill.com/component/content/article/228

GL Trade Clearvison - это был программный продукт. Устанавливался у брокера. GL Trade была куплена SunGard в 2009 году и продукт включен в комплекс от SunGard.

Back Office

[edit]

Exchange traded derivatives

[edit]

Booking and Billing - здесь безраздельно властвует комапния SunGard со своим программным комплексом SunGard GMI. Некоторые крупыне брокеры пытались создать что-то свое похожее, но потратив кучу бабок, так ничего и не создали. GMI давно работает на AS/400, и вроде как переносить ее на что то современное не собираются. Поэтому для работы Back Office требуеются программисты, которые знают GMI и умеют AS/400.

Straight Through Processing (STP)

[edit]

STP, as defined by the Securities Industry Association (SIA), is “…the process of seamlessly passing financial information to all parties involved in the transaction process, spanning the investment manager decision through to reconciliation and statement production, without manual handling or redundant processing in real time.”

Two types of STP exist: internal and external. In the case just discussed, internal STP is required because you need to connect modules installed in a broker’s office. But some other entities such as custodians, fund managers, and so on, play an equally important role in settlement. To achieve true STP, even these need to be connected to each other. Any attempt to connect such entities beyond the organization in pursuit of STP is called external STP. We will lay the foundation for STP in this section and discuss some related but advanced concepts in Chapters 6 and 7.

The industry wants to put processes in place that will allow an order to flow right from deal entry to conversion to trade to affirmation and confirmation and finally through settlement and accounting without manual intervention. This is because the industry wants to move toward T+1 settlement. This means trades done on one day will get settled the next day. This is an ambitious plan because it will call for a lot of process change, technology change, and industry change. Applications will have to come together and orchestrate the entire business process.

STP provides a lot of benefits to industry participants:

  • STP reduces settlement time. This essentially reduces risk because transactions will be settled faster and will be irrevocable. Settlements are said to be irrevocable when they are considered to be final and cannot be reversed. Reduced settlement time also means better utilization of capital.
  • Less manual intervention will mean fewer operational risks and errors. It will also mean fewer costs.
  • STP will force the entire industry to move toward standard communication protocols. This will mean standardized systems and fewer system development and maintenance costs. Interoperability will be a prerequisite for this to happen; we will go into depth about this in Chapter 7.
  • Increased automation will lead to increased throughput in transaction processing, thereby enabling institutions to achieve greater transaction volumes.

Equity trading and STP by itself are vast subjects, and understanding every minute business detail in a single go is not possible; furthermore, the functioning of every stock exchange is different from one another (though the concepts are fairly standard). We hope you by now understand the importance of financial markets, why equities are issued, and how they are traded and settled. We will discuss STP concepts in more detail in Chapters 6 and 7. You should also be in a position to understand the various entities in a financial system relating to equities trading and settlement.

Ссылки

[edit]
Retrieved from "https://wiki.riteme.site/w/index.php?title=User:Alexkachanov/Finance/Technologies/Sell-side&oldid=822723773"