Dear Brokers… (часть 2)

Получение истории цены

Хотя любой алгоритм торгует в режиме реального времени, на запуске ему все еще нужна история цены для вычисления начальных значений её индикаторов и функций анализа цены. Без доступа к ценовой истории вам бы пришлось ждать пару дней до размещения первой сделки. Так как это не слишком практично, ценовая история является существенной функцией API.

Брокер А предоставляет историю цены без особых проблем. Я могу не верить ему. Поэтому нам снова нужно запустить “фабрику запросов”, сгенерировать запросы и ответы, и приблизительно 50 строк текста программы позволят загрузить историю цены. Брокер не взимает сборы за эти цены (вы даже можете загрузить их с демо-счетом) и, по крайней мере недавние данные, с 2010 и выше, находятся в приемлемом качестве. Восемь из десяти очков для истории цены брокера А.

Брокер В у нас вновь креативный и предприимчвый человек. Его ценовая история бесполезна при просмотре с демо-счетов – вы должны открыть реальный счет и внести 10,000$, если хотите хотите получить эти данные. Эта сумма, конечно, также требуется и от бедняги кодера, который лишь хочет внедрить функцию получения истории цены. Но и дальше не проще. Технически это легко – достаточно нескольких линий кода – но у вас только 60 запросов. После этого сервер с историей цены закрывается на 10 минут. 60 запросов достаточно для системы с одним активом, но не для запуска системы с портфелем, и уж точно не для backtest'а. К чему такое странное ограничение? Возможно, брокер В не может позволить себе быстрое интернет-соединение для своего сервера с историей цены. А возможно, они используют старый PC своего генерального директора, расположенный в его гостиной, и пропускная способность понижается, когда его дети играют на нем в Тетрис. Какой бы ни была причина, брокер В получает только одно из десяти очков.

Есть ли брокер, который получил бы ноль очков за историю цены? Да, есть: у брокера С вообще нет функции API для восстановления истории цены. Очевидно, они не ожидали, что кто-то будет действительно использовать их API. И здесь нет иного совета, кроме как посоветовать клиенту выбрать другого брокера для своей алгоритмической системы.

Обработка сделок

Мы, программисты, склонны мыслить бинарно. Когда мы отправляем приказ «исполнить или аннулировать» в API брокера, мы предполагаем, что позиция будет или открыта (“да”), или закрыта (“нет”). Но время от времени, API брокера приводит к третьему результату, например, “возможно”, или “не скажу”. Позиция, которая, возможно открыта, а возможно и нет, способна привести к потере сделки. Это — сделка, открытая брокером, но не получившая ответ от торгового ПО, и следовательно, не автоматизированная. Такая сделка не будет закрыта аннулированием или остановкой, и может таким образом накопить большую потерю.

Теоретически, потерянные сделки предотвратить просто. API всего лишь должен предоставить простую функцию заказа с идентификатором и пределом применимости, например:

openAtMarket(string Asset, int Amount, int ID, int SecondsValid);

ID = уважаемый брокер, пожалуйста, сохраните этот идентификатор вместе со сделкой и используйте его для восстановления статуса сделки в случае сомнений.

SecondsValid = уважаемый брокер, пожалуйста, игнорируйте заказ, когда после заданного числа секунд ваш API все еще не знает, может ли он заполнить его или нет, или его невозможно подтвердить.

Это — идеал, но как в действительности?



Продолжение читаем на смартлабе через неделю...

Удачных алгоритмов!