Fix drop copy что это

Программные интерфейсы FIX

Программные интерфейсы FIX* предназначены для организации взаимодействия сервера QUIK с внешними приложениями и программными комплексами средствами протокола FIX.

Основные решаемые задачи

FIX adapter

Программный интерфейс FIX adapter предназначен для подключения внешних приложений к серверу QUIK для получения информации и передачи торговых поручений.

Интерфейс позволяет получать с сервера QUIK рыночную информацию (market data), справочную информацию (reference data), данные обо всех обезличенных сделках, а также информацию о заявках и сделках, осуществленных через данный экземпляр интерфейса.

Через интерфейс потенциально доступны все торговые системы, режимы торгов и типы заявок, которые поддерживаются на cоответствующем сервере QUIK, а также полный функционал комплекса QUIK по online pre-trade контролю операций.

Интерфейс поддерживает работу с Алго-заявками Модуля алгоритмической торговли и OMS-заявками Системы QUIK-OMS.

Интерфейс не поддерживает операции в режиме РЕПО (кроме безадресного РЕПО с ЦК).

Используются три вида программного интерфейса FIX adapter с ограничением на:

Технологически интерфейс является FIX API к серверу QUIK.

FIX Client Connector

Программный интерфейс FIX Client Connector предназначен для подключения внешних клиентских приложений для получения информации и подачи торговых поручений на сервер QUIK.

Интерфейс позволяет получать с сервера QUIK рыночную информацию (market data), справочную информацию (reference data), данные обо всех обезличенных сделках, а также информацию о заявках и сделках, осуществленных через данный экземпляр интерфейса.

Через интерфейс потенциально доступны все торговые системы, основные режимы торгов и типы заявок, которые поддерживаются на соответствующем сервере QUIK, а также полный функционал комплекса QUIK по online pre-trade контролю операций.

Интерфейс не поддерживает операции в режимах РПС, РЕПО (кроме безадресного РЕПО с ЦК), также не поддержаны алго- и OMS-заявки.

Программный интерфейс позволяет обслуживать до 10 клиентских счетов на спот- и срочном рынках.

Технологически интерфейс является FIX API к серверу QUIK.

FIX drop copy

Интерфейс предназначен для передачи с сервера QUIK рыночной информации (market data), справочной информации (reference data) и информации по заявкам и сделкам для определенного счета или группы счетов во внешнее приложение (мидл-, бэк-офисы и другие системы, используемые брокером).

Поддержана интеграция трейд-репортинга с compliance-системой компании «RedKite».

Технологически интерфейс является FIX API к серверу QUIK.

FIX order router

Программный интерфейс предназначен для подачи торговых поручений из QUIK во внешние торговые платформы и передачи информации о собственных заявках и сделках из внешних программных комплексов на сервер QUIK. Возможна организация получение рыночной информации через одного из маркет-дата вендоров — партнеров ARQA Technologies.

Через интерфейс потенциально доступны все торговые системы, режимы торгов и типы заявок, которые доступны во внешней торговой платформе.

Как правило, интерфейс применяется для FIX-интеграций с платформами зарубежных брокеров-партнеров с целью организации доступа к зарубежным торговым площадкам. Возможна загрузка справочной информации (reference data) из других серверных модулей QUIK, а также вручную.

FIX-интеграция в данном случае осуществляется специалистами ARQA Technologies. Для ее осуществления необходимо описание FIX-протокола, используемого внешней платформой, и доступ к тестовой торговой среде.

По запросу на sales@arqatech.com может быть предоставлена документация на используемую в интерфейсах FIX adapter, FIX Client Connector и FIX drop copy версию FIX-протокола.

Также по запросу возможно предоставление доступа к тестовой среде ARQA Technologies для отладки интеграций, выполненных внешними разработчиками.

Требования к оборудованию

Процессор не хуже Intel Xeon Gold 5118,

Оперативная память не менее 2 ГБ,

10 ГБ свободного места на жестком диске.

Операционная система Windows Server 2008/2012/2016/2019 (x64).

Источник

Торговля с помощью протокола FIX. Часть вторая: создание FIX-клиента

В предыдущей статье мы использовали приложение MiniFIX для подключения и отправки сообщений на тестовую биржу с помощью протокола FIX. В этой статье напишем собственную реализацию клиента для получения рыночных данных в виде небольшого SpringBoot-приложения. Код доступен в репозитории.

Для реализации приложения нам понадобится:

Содержание для упрощения навигации по статье:

FIX-Engine и запуск тестового сервера

FIX-Engine, или FIX-движок, обеспечивает связь со сторонними системами по протоколу FIX. Он отвечает за преобразование данных в FIX-сообщения, а также за создание сессии и обеспечение ее работы: проверку валидности сообщений, генерацию контрольных сумм, восстановление работы после потери связи и т.д (здесь можно почитать более подробно).

В нашем случае в роли такого движка выступает QuickFix/J. В предыдущей части я использовала пример Executor из модуля examples, но в нем обрабатываются только сообщения на создание торговых заявок. В этом же модуле есть более подходящий пример — OrderMatch (quickfixj-examples-ordermatch), в нем помимо поддержки торговых заявок присутствует обработка сообщений на получение рыночных данных (MarketDataRequest).

Когда вы первый раз клонируете репозиторий, обязательно нужно выполнить сборку проекта, чтобы сгенерировались FIX-сообщения для различных версий протокола. В Readme проекта есть описание команд для различных видов сборки (с тестами и без), самый быстрый:

Процесс сборки длился у меня где-то минут 6-7, так что в это время можно заварить себе чашечку чая изучить настройки сервера и приступить к написанию клиента.

Как я уже описывала ранее, открываем файл resources/quickfix.examples.ordermatch/ordermatch.cfg, проверяем SocketAcceptPort и заполняем поле TargetCompID нужным значением для нашего клиента (можно оставить BANZAI, которое указано по умолчанию, можно написать любое другое на ваше усмотрение):

Если хотите поменять значение идентификатора клиента, то лучше, конечно, сделать это перед сборкой, чтобы не пришлось собирать еще раз.

Когда сборка завершится, заходим в quickfixj\quickfixj-examples\ordermatch\target, проверяем, что там появились *.jar файлы:

Запускаем файл quickfixj-examples-ordermatch-2.2.0-SNAPSHOT-standalone.jar, так как он содержит все необходимые для запуска зависимости:

Если появилась запись «Started QFJ Message Processor» – значит, сервер запустился. Проверьте, что в строке «Listening for connections at … [FIX4.2:EXEC->FIX_CLIENT]» указано нужное значение идентификатора клиента.

Структура проекта

Вот так выглядит готовый проект (стандартная структура веб-приложений: сервисы, контроллеры, модельки и т.д):

Создаем maven-проект со стандартными зависимостями и добавляем библиотеку QuickFix/J для работы с протоколом FIX:

Я подключила 2 модуля: quickfixj-core и quickfixj-messages-fix42 для работы с сообщениями только версии FIX 4.2.

Если в вашем приложении предполагаются сообщения различных версий протокола, можно подключить quickfixj-core + quickfixj-messages-all или просто quickfixj-all.

Настройка параметров подключения

По аналогии с файлом настроек на сервере, создадим файл resources/config/client.cfg с настройками нашего приложения.

В файле может быть один блок [default], в котором находятся параметры, общие для всех сессий, и несколько блоков [session] для описания параметров конкретной сессии (если сервер поддерживает сообщения различных версий протокола FIX, то для каждой версии создается отдельный блок [session]).

Начнем с блока [default]:

В настройках конкретной сессии (в блоке [session]) главное – заполнить параметр BeginString, в котором указывается версия протокола FIX, использующегося в сообщениях.

Любые настройки можно указывать непосредственно при создании подключения в коде с помощью класса SessionSettings.

Подробнее о конфигурации клиента можно почитать в официальной документации.

Создание FIX-приложения

Теперь перейдем непосредственно к коду клиента. Чтобы создать FIX-приложение, нам нужно просто реализовать интерфейс Application:

Эти методы вызываются в результате событий, происходящих в приложении (подробнее).

В приложении может быть установлено несколько сессий, поэтому в базовом классе будем хранить все сессии:

Так как метод onCreate срабатывает при создании новой сессии, в нем будем сохранять сессию по полученному ID с помощью метода lookupSession :

Когда сессия отключается от сервера (мы завершили сеанс сообщением Logout или произошли какие-то технические проблемы и связь оборвалась), мы удаляем её из нашего хранилища.

В FixClientService у нас находится главный обработчик сообщений – метод fromApp :

С помощью класса MessageUtils библиотеки QuickFix/J можно получить тип входящего сообщения и далее обработать каждый случай (здесь для примера я указала несколько типов сообщений и вывела их в лог). В этой статье реализуем получение рыночных данных и их сохранение в кэш, остальные типы сообщений и их обработку более подробно разберем в следующих статьях и дополним логику нашего клиента.

Создание сервиса для подключения к серверу

Когда мы создали реализацию FIX-приложения, можно приступить к сервису для подключения к серверу – ConnectorService. При запуске приложения он будет создавать и запускать сокет для обмена сообщениями.

Для обмена сообщениями нужно создать SocketInitiator (на сервере аналогично создается SocketAcceptor). При создании передаются следующие параметры:

Путь к файлу настроек и дополнительные параметры (хост и порт подключения) для удобства я вынесла в конфигурацию приложения (application.yaml):

Соответственно при создании настроек сессии я использую этот файл и с помощью метода sessionSettings.set(String key, String value) добавляю параметры SocketConnectHost, SocketConnectPort:

После создания настроек сессии объявляем LogFactory, MessageFactory, MessageStoreFactory и передаем их в конструктор SocketInitiator. Вызвав метод start() запустим подключение и сможем получать сообщения.

Отправка запроса на получение рыночных данных

Когда приложение запустится и установится соединение с сервером, мы сможем отправлять и получать сообщения. Так как взаимодействие у нас построено на сокетах, отправка сообщения и получение ответа на него происходят асинхронно. Поэтому у нас будет два контроллера:

Напишем метод для создания сообщения типа MarketDataRequest (о тегах сообщения можно почитать в спецификации).

Например, тег symbol=55 :

Стандартные теги (соответствующие спецификации конкретной версии FIX) обычно можно заполнить напрямую. Например, для сообщения MarketDataRequest (далее буду сокращенно писать MDR) определены методы

Создадим объект класса MarketDataRequest:

В конструкторе передается три параметра:

Далее нужно указать параметры, которые мы хотим получить в результате запроса рыночных данных. Некоторые параметры в FIX-сообщениях задаются группами. При этом начинается такая часть сообщения с тега, в котором указывается количество последующих групп. В нашем случае параметр NoMdEntryTypes хранит количество групп, а сами группы формируются из тегов MdEntryType. Например, 269=0 означает, что мы хотим получить цену, по которой можно продать инструмент (Bid), а 269=1 – цену, по которой мы сможем купить инструмент (Ask, или Offer). Полный список стандартных значений этого тега можно посмотреть в спецификации. QuickFix/J автоматически заполняет в теге количество параметров, мы можем только заполнить нужные нам поля и добавить каждую группу в сообщение:

Можно делать MDR сразу для нескольких инструментов, в поле NoRelatedSum передается их количество и далее заполняются группы тегов для каждого инструмента. Для простого запроса достаточно передать идентификатор инструмента в теге (для более сложных запросов на фьючерсы или опционы нужно указывать дополнительные параметры, но для нашего базового случая это не нужно).

Наш полученный MDR теперь можно отправить на сервер с помощью метода session.send() :

Аналогично можно реализовать методы отправки любого другого сообщения (на создание заявки, на получение детальной информации об инструменте и т.д).

Для полученного метода отправки запроса на получение рыночных данных создадим REST endpoint, чтобы мы могли инициировать его отправку:

В результате будет отправлено сообщение:

8=FIX.4.2 9=117 35=V 34=3 49=FIX_CLIENT 52=20200601-17:10:34.103 56=EXEC 262=FixClient-1 263=0 264=1 146=1 55=AAPL 267=2 269=0 269=1 10=018

Обработка ответа и сохранение рыночных данных

Создадим отдельный сервис (MarketDataService), который будет обрабатывать рыночные данные, полученные в результате отправки запроса. Он будет сохранять полученные данные в объект, записывать их в память и отдавать при запросе по идентификатору инструмента.

Класс для хранения рыночных данных:

Теперь нужно разобраться, как правильно обработать сообщение с данными и сохранить его.
Вот так выглядит сообщение, отправленное нам в ответ на запрос по символу AAPL:

Так как при запросе мы указывали группы параметров (Bid, Ask и т.д), разбирать сообщение тоже будем по группам:

В теге хранится название параметра, а в теге его значение. Соответственно, если тип параметра = 0 (т.е. Bid), то мы сохраняем значение соответствующего ему тега в поле bid нашего объекта.

Далее проверяем тег – идентификатор инструмента, и сохраняем по нему наши данные:

Осталось только добавить сохранение данных в метод fromApp в случай обработки сообщения типа MarketDataSnapshotFullRefresh:

Теперь при получении нашим приложением сообщения типа MarketDataSnapshotFullRefresh будет происходить обработка и сохранение данных в память приложения.

Соответственно в отдельный Rest-Controller добавляем метод получения данных по идентификатору:

Вызвав метод GET localhost:9090/fix-client/v1/market-data?symbol=AAPL
получим ответ:

Запуск приложения

Наконец, можем запустить наше приложение, убедиться, что подключение к серверу осуществляется успешно, и попробовать отправить запрос на получение рыночных данных.

Если при запуске приложения в логах отображаются ошибки подключения (ConnectException), как на скриншоте ниже, проверьте, что сервер запущен и что вы указали правильные идентификаторы клиента и сервера и хост и порт для подключения:

В случае успешного запуска клиент и сервер должны обменяться Logon-сообщениями:

Кстати, сообщения можно удобно парсить с помощью сайта – просто вставляете текст сообщения и получаете разбор по тегам и значениям:

Теперь вызвав метод GET localhost:9090/fix-client/v1/market-data?symbol=AAPL
мы должны получить ответ:

Конечно, на таком “игрушечном” примере далеко не уедешь, но для начала он хорошо подходит. Для более сложных примеров и для работы с условиями, приближенными к реальной бирже, можно получить доступ к тестовому контуру Московской биржи (MOEX) — для этого нужно оставить заявку на сайте. Я не нашла аналогичных тестовых контуров у других крупных бирж (именно для подключения напрямую через FIX-протокол), кроме симуляторов биржевой торговли, где выдаются виртуальные деньги и с помощью терминалов осуществляется торговля. Если знаете, где найти хороший тестовый сервер для работы по протоколу FIX, — поделитесь в комментариях, буду благодарна.

В следующей статье я планирую рассмотреть основные виды FIX-сообщений (соответственно дополнить приложение методами для их создания) и далее перейти к подробному рассмотрению процесса создания торговых заявок и их обработки биржей. Все примеры сообщений по-прежнему можно создавать с помощью приложения MiniFIX, если не хотите писать реализацию своего клиента.

Источник

Fix drop copy что это

Участникам торгов фондового и валютного рынков Московской Биржи (торговая система ASTS) предоставляется возможность осуществлять операции в режиме основных торгов, подключая собственные внешние программно-технические средства с использованием протокола FIX версии 4.4 (информация о FIX-протоколе доступна по адресу http://www.fixprotocol.org).

Доступен публичный тестовый контур для предоставления разработчикам клиентского программного обеспечения возможности заблаговременно провести интеграцию уже существующих на рынке или новых FIX-решений с сервисом MFIX Transactional.

Публичное тестирование проводится круглосуточно на тестовом сервере, имитирующем работу фондового и валютного рынков и доступном для подключения через сеть Интернет.

Для участия в тестировании, а также для сертификации готовых разработок, отправьте заявку свободного вида на адрес help@moex.com с фразой MFIX Transactional в теме письма.

Адреса для подключения (фондовый рынок):

Адреса для подключения (валютный рынок):

Доступ к ASTS (OTC с провайдерами ликвидности на валютном рынке)

Участникам клиринга на валютном рынке доступна возможность подключения к режиму торгов OTC с провайдерами ликвидности (BoardID: OTCT) по протоколу FIX 4.4, включая получение рыночных данных по данному режиму.

Адреса для подключения (OTC FIX)

FIX Gate работает в соответствии со спецификацией протокола FIX версии 4.4, широко распространённой в мире.

FIX Gate предназначен для управления заявками в торговой системе Spectra в режиме электронной торговли. Для получения биржевой информации в целях ведения торговли следует подключаться к интерфейсу FAST Gate.

Для получения биржевой информации в иных целях необходимо обращаться к брокеру и информационным агентствам.

Подключение FIX платформы Spectra

Технические требования

Требования к компьютеру для установки FIX Gate

** в случае использования компьютера для установки ПО Системы ЭДО

Адреса для подключения (Срочный рынок):

Право удаленного использования программы для ЭВМ FIX Gate предоставляется Техническим центром Пользователю, являющемуся Участником торгов на срочном рынке ПАО Московская Биржа. Право удаленного использования программы для ЭВМ FIX Gate может быть передано Пользователем Клиенту, имеющему Идентификатор спонсируемого доступа (ИСД).

Документы по FIX платформы SPECTRA:

Уважаемые посетители сайта, чтобы отправить свое предложение или задать вопрос, используйте форму обратной связи.

Мы ценим Ваше мнение и обязательно рассмотрим Ваши вопросы и в случаях, когда это возможно, подтвердим получение Письма и предоставим письменный ответ.

В случае наличия обоснованных и существенных претензий, Биржа совместно с Экспертными Советами примет меры по разработке и реализации соответствующих изменений.

Источник