Для понимания понятия latency возьмем простой пример. Представьте себе некий «черный ящик» с одним входом и одним выходом. Вы подаете сигнал на вход и ожидаете появление сигнала на выходе. При проведении экспериментов вы замечаете, что при подаче сигнала на вход сигнал на выходе появляется через 1 секунду. Причем это происходит постоянно с отклонением +/- 10 миллисекунд. То есть выдача сигнала на выходе происходит с определенной задержкой. Это и есть latency — время задержки.
Как вы можете использовать Java для финансовых торговых приложений? Ведь Java тормозная, жрет много памяти, сборщик мусора останавливает приложение, когда захочет. Разве Java годится для low-latency? Для этого непременно нужно писать на C, C++, а еще лучше на Verilog и использовать FPGA, не меньше! Java для high-frequency trading? Да вы шутите!? Java для алгоритмической торговли? Не смешите мои тапки!
Так или примерно так реагируют некоторые разработчики на использование Java в финансовых приложениях, где критичны скорость работы и высоки требования к latency.
Уверяю вас Java вполне подходит для финансовых торговых приложений и вот несколько причин почему.
Понятие «торговая система» в различных контекстах имеет различные смыслы, поэтому, когда в разговоре или тексте вы видите это словосочетание, важно разобраться в каком контексте оно употреблено, чтобы не запутаться и понять, о чем конкретно идет речь. Читать далее
FIX Protocol — протокол передачи финансовых сообщений между участниками финансового рынка. В настоящее время наиболее часто встречаются версии протокола FIX 4.2 (старый добрый конек, но все еще используется), FIX 4.4 (на него преходят те, кого уже не устраивает FIX 4.2), и FIX 5.0SP2 — самый современный на настоящее время.
Хоть протокол за время своего существования претерпел множество изменений, некоторые его базовые основы остались неизменными. В данной статье я расскажу о базовых тегах FIX-сообщений, которые надо знать на зубок.
В четверг 5 июля мне удалось посетить интересное мероприятие Tokyo Financial Information & Technology Summit 2018. Тема конференции была инновации в сфере финансов. На конференции присутствовало много людей из сферы IT местных инвестиционных банков. Я ниже изложу несколько плодотворных идей, которые мне удалось почерпнуть во время посещения этой конференции и общения с коллегами.
FIX Protocol используется участниками рынка для передачи ордеров и информации об их исполнении друг другу в электронном виде.
До появления FIX Protocol-а ордера передавались от инвестора к брокеру и от брокера на биржу по телефону, что приводило часто к ошибкам, разночтениям и неточностям. Ситуация напоминала испорченный телефон: например, работник брокера в разговоре с инвестором по телефону мог что-то не так понять или не расслышать или чисто по-человечески перепутать и предать неверный приказ своему сотруднику на биржу. Тот тоже мог что-то не так понять или в спешке перепутать. В результате клиент получал не то, что хотел, а потом начиналась долгая история между клиент и брокером, на кого повесить убытки по неправильно исполненному ордеру.
Отступление: У некоторых брокеров алгоритмы исполнения ордеров называются словом «стратегии» (strategy). Просто так красивее звучит. Это вносит путанницу в обсуждениях, потому что слово «стратегия» в другом контексте, например, в словосочетании «инвестиционная стратегия» приобретает совершенное значение.
Где-то около 2004 года крупные брокеры стали помимо DMA-сервиса предоставлять клиентам доступ и к своим алгоритмическим движками. Теперь клиент мог прислать ордер с параметрами, где было указано, какой именно алгоритм брокера он выбирает, насколько агрессивно надо выполнять ордер, когда надо начать выполнение ордера и когда закончить. Этот особый ордер внутри брокерской инфрастурктуры пренаправляется в алгоритмический движок, который потом «работает» над ордером, отправляя на биржу его по маленьким кусочкам.
Direct Market Acess это буквально «прямой доступ к рынку». В DMA-сервисе брокер пропускает ордер через свою торговую систему на рынок в полностью автоматическом режиме без дополнительного ручного вмешательства.
Помните, что помимо «discretionary» ордеров есть еще “non-discretionary», которые требуют минимум внимания. Если ордер от клиента принимается электронно и уже находится в компьютере, то трейдеру просто оставётся посмотреть на него, проверить параметры ордера и нажать кнопку «отправить на рынок».
Но почему бы тогда не запрограммировать компьютер на выполнение определенных проверок и отправить ордер на биржу автоматически, не привлекая к этому трейдера?
Все клиентские ордера, которые поступают к брокеру на исполнение, делятся на «discretionary» и «non-discretionary».
«Non-discretionary» ордера немедленно отправляются трейдерами брокера на рынок, не задерживаясь, как есть. Это мелкие простые ордера, для которых важна скорость исполнения. DMA-ордера по определению являются non-discretionary. Они составляют 50% объема всех ордеров проходящих через брокера.
«Discretionary» ордера задерживаются у брокера и исполняются трейдером брокера по его усмотрению («at dsicretion», отсюда и название «discretionary»). Это большие, «толстые» ордера, по которым у клиентов главное требование – исполнить их наилучшим образом, не двигая рынок.
После того, как весь (или не весь) parent-ордер был исполнен алгоритмическим движком, все child-ордера собираются в кучку и производится анализ того, как parent-ордер был исполнен алгоритмом, т.е. на сколько результат исполнения ордера отошел от критериев, которые были заданы до запуска алгоритма.
Этот анализ называется «анализом издержек» (Transaction Cost Analysis — TCA) и является дополнительным сервисом, который брокер предоставляет клиенту. Клиент может и сам делать анализ издержек, если он получает информацию от брокера по исполнению child-ордеров (и если брокер предоставляет ему эту информацию).
