В этом форуме иногда всплывают обсуждения тем типа Forex, финансы, high-frequency trading, но я не помню, чтобы где-то обсуждалось то чем на самом деле занимаются ISVs в этой области.
Я хочу немного пролить свет, не только на примере компании, в которой я работаю (Tbricks), но и на примере прошлой жизни и компаний-конкурентов.
Наверное, все слышали что компании, торгующие чем-то, посылают какие-то заказы, смотрят какие-то цены, получают какие-то сделки, рисуют какие-то графики. Но что за этим скрывается?
Если идти технологическим путем со стороны рынков, то это интерфейс к рынку. Это может быть реальный рынок, какой-нибудь Eurex или CME, может быть брокер (Goldman Sachs, теперь уже всем известный Knight, Bank Of America/Merill Lynch, Ренессанс-который-не-Текнолоджис), это может быть какой-нибудь data provider типа Activ Financial, Bloomberg, Reuters, Millistream, Quanthouse, Lime etc. С точки зрения технологий тут может быть от multicastа и сокетов до поставляемых библиотек. Проблемы – от того как эффективно парсить/энкодить сообщения, особенно для тех клиентов, которые выжимают микросекунды до того как обеспечивать recovery, отображать модель конкретного рыка на рыночно-нейтральную модель продукта: некоторые инструменты торгуюютя паралленьно на нескольких рынках, на нескольких под-рынках одной биржи (особенно это касается государственных облигаций), у них разные типы заказов, иногда приходится считать один и тот же инструмент одним, а иногда – несколькими инструментами, в зависимости от того как работает клиринг в конкретной компании. Даже простая посылка заказа может сильно отличаться в зависимости от контекста: можно послать один заказ, можно послать 100 заказов пачкой, можно послать в некотором смысле поверхность спроса/предложения и указывать рынку как превращать ее в заказы. И это все market-specific, то что есть на одном рынке не всегда есть на других, особенно что касается supply/demand surface. Да даже понять, что предоставляет конкретный рынок иногда проблема, так как стандартов в этой области просто нет. Есть FIX, который зовется стандартом, но любой, кто интегрировал свою систему с Goldman, знает что неважно то что написано в стандарте или документации брокера, важно как это работает в реальности. Или, например, как представить в системе какой-нибудь швейцарский participation certificate? Это, кстати, совсем не то что имеется в виду под participation certificate в Штатах 
О ценах… Не всегда инструменты, которыми торгуют клиенты существуют на реальных рынках. В-основном все исчерпывается акциями, ETF, производными инструментами, немного экзотики. Но люди иногда торгуют другими вещами, например, корзиной, реплицирующей индекс развивающихся рынков, или корзиной, реплицирующей Russell Index 2000 (для справки – 2000 инструментов, каждый их которых торгуется на нескольких рынках одновременно). Тут встает вопрос о том, как это считать, особенно если таких корзин не несколько, а несколько сотен. И, возможно, механизм вычисления цены не просто линейная комбинация “ног”, а нечто более хитрое (особенно в ситуации индексов из ADR когда основной рынок – американский, закрыт, но открыты локальные рынки, в которых торгуются настоящие бумаги, правда, в другой валюте). А иногда подобные пачки инструментов торгуются на бирже как единое целое, более того, корзины определенной структуры можно создавать на бирже для торговли ими как единым целым.
И это мы затронули только цены “рыночные”, которые нам говорят, сколько что-то стоит купить “сейчас”. А есть еще так называемые “теоретические” или “справедливые” (theoretical, fair) цены. И здесь начинаются забавные вещи наподобие того из каких соображений исходить для вычисления справедливой цены (оптимальное хеджирование, отсутствие арбитража etc), какие модели использовать для вычислений, насколько эти модели соответствуют реальности, насколько они вычислительно эффективны (случай когда компания поддерживает рынок в тысячах инструментов одновременно).
OK, теперь каким-то образом это все куплено или продано и есть как у нас говорят “портфель”. У компании несколько бизнесов, меду которыми по законодательству должна быть китайская стена, значит они не могут видеть портфели друг друга, но общий риск-менеджмент должен. А количество сделок составляет сотни тысяч в день, а хочется не только видеть это в real-time, но иметь возможность посмотреть “а что было вчера?”,
“а сколько я потерял за день за счет того что любая длинная позиция в опционе мироточит кэшем?”. А еще интересно посмотреть – как будет вести себя портфель при разных движениях рынка, а позиций несколько тысяч и большинство из них считается вычислительно совсем не просто (возможность раннего исполнения, выплаты дивидендов, экзотика тика knock-in/knock-out etc). И, если уж речь пошла о производных, какую модель (параметризацию) поверхности волатильности выбрать? Там всякие условия на отсутствие арбитража внутри одного expiration month, между etc. И народ, торгующий разными классами инструментов, привык использовать разные параметризации.
Потом это все раскидано по кучи locations, как у нас говорят co-locations или proximity hosting, это когда компания имеет сервера во Франкфурте, Лондоне, Чикаго, Нью-Джерси, Гон-Конге etc, а там проблемы с сетью, особенно в конце 2008, потом когда flash crash был etc. А если вы ходите предлагать клиентам hosted solutions, то нужно думать о hosting providers, линиях, бэкапных линиях, SLA etc. А есть еще мультиплексинг, когда контора покупает 10 каналов к бирже и хочет таким образом скалировать свою производительность.

Но зачем все эти цены и заказы? Для того чтобы кто-то принял решение о покупке или продаже.
Даже если это всегда человек (то что в нашей области называется assisted manual trading), то здесь бывают всякие забавные штуки. Человек просто хочет купить инструмент за миллион долларов, проблема в том что этого инструмента на рынке нет и это огромная корзина (=линейная комбинация других инструментов для простоты). Как ее купить, особенно если это малоликвидная хрень? Выполнить это сейчас или растянуть на несколько часов? Что делать если какие-то ноги торгуются в нескольких местах одновременно? А что если в каких-то компонентах торговля приостановлена? А что если есть ненаблюдаемая ликвидность (dark pools, icebergs, hidden quotes, discretionary orders, алго-заказы etc?
Если смотреть на автоматическое выполнение: иногда нужно быть очень быстрым (мы говорим о микросекундах) и вовсю использовать co-location, иногда нужно агрегировать данные на уровне всей компании между всеми географическими локациями, например если мы ходит хеджировать валютный риск всей компании. Тут вылезают вопросы не только latency, но и bandwidth usage, особенно когда практически все пользователи сидят в одном офисе и де-факто смотрят на все.
Добавьте к этому необходимость дать клиентам разрабатывать свои торговые стратегии и тут начнется самый фан. Кто-то выжимает микросекунды, кому-то важен тупо time-to-market, кто-то интегрирует это со своей in-house системой, кто-то тупо пишет в свою базу, запускает свои потоки.
И стратегий таких может работать несколько десятков, а может быть несколько десятков тысяч. И вебовские стандарты качества обслуживания тут вообще не катят.
А сверху на это нужно наложить GUI, от которого все ожидают как минимум функциональность Microsoft Excel, но при этом размер спрэдшита (инструменты, например) исчисляется cсотнями тысяч строк, которые не просто тупо _есть_, а которые меняются по-крайней мере на стороне источника сотни раз в секунду и куча колонок параметризуется исходя из того что написал клиент (= неизвестно разработчикам продукта вообще). И графики хочется, и чтобы это было не захардкожено, а можно было использовать самому, и чтобы GUI делать для собственных модулей.
А потом еще безопасность есть. Про Knight все слышали? Начиная от реализации взглядов конкретного риск-менеджмента на то сколько можно торговать до ограничений на цены/заказы исходя из их справедливых цен и до предупреждения проблем со сходящими с ума самописными стратегиями (а народ, теряющий сотни тысяч долларов за несколько секунд – не выдумка). А если взять всякие банки, но им и аудит всего нужен и permissions.
А еще даже на простой заказ можно посмотреть с юридической точки зрения, особенно если Вы – брокер. И тогда прежде чем что-либо делать с заказом Вам нужно его сохранить. Потому что если что-то упадет (компонента системы, сеть, соединение с биржей, биржа etc), это будет Ваша юридическая проблема. А заказов таких – миллионы в день. И это надо как-то писать в базу. И искать по ней иногда, и иногда чистить. Тут простые ораклы не очень работают (ok, может работают если не нужно все делать в real-time). Ну и disaster recovery всякие. Иногда тупо умирает железо. Недорогое (Sun, например), но неприятно когда компания тупо не может торговать,
И ко всему этому есть поддержка. И тут даже first-line support работает далеко не с такими вещами типа “у меня это, ну это, не работает”, а с вещами начиная от того что “у меня пакеты теряются” до вещей типа “каким образом мне лучше реализовать мое понимание риска в вашей системе” и “почему у меня тета позиции слишком большая”.