Как-то я работал в одной инвестиционной управляющей компании. Перед моей командой была поставлена тривиальная задача — сделать так, чтобы отчеты брокера успевали загрузиться до открытия очередной торговой сессии. Приходили они к нам около 9:00, а сессия открывалась в 10:00. Трейдеры должны были получить актуальные портфели, иначе их деятельность была блокирована.
В целом, получалось, что у нас был час. Правда, нужно отнять время подготовки отчетов с переоценкой портфелей для трейдеров. Плюс, нужно учесть, что брокер мог и “слегка” опоздать. И тогда наш Back Office становился центром вселенского Зла.
В общем, каждый день начинался с напряга. Middle Office должен был прийти пораньше, чтобы “вытрясти” из брокера отчеты, успеть загрузить их и передать в Back Office, который должен был успеть все учесть и выкатить актуальные портфели трейдерам. Как вспомню, так вздрогну.
Естественно, первым делом рассматривались средства оптимизации алгоритмов учета. Сложные сделки проводились достаточно медленно. Если я правильно помню те времена, то отчет брокера на 1000 сделок грузился и учитывался около 5 минут. Если учитывать, что портфелей было много, около 30, то легко понять, что в отведенное время мы могли не уложиться (даже учитывая, что загрузка по портфелям шла параллельно). Это как-то решалось приоритетами по загрузке отчетов.
Оптимизация, отчасти, решала вопрос. Наш DBA совместно с системными администраторами добился ощутимого прироста. Опять же, если память не изменяет, где-то на 50% была улучшена производительность. Но это, к сожалению, в корне не решало проблемы.
Дальнейшая оптимизация вела нас уже к обновлению железа. Тут было не все просто. Наш ЦОД был построен на базе железа HP. И упирались мы тогда в СХД, которая трудилась в паре с blade-корзиной. Для обновления требовалось комплексный upgrade что и было нам посчитано где-то в 150 000$. А вот результат… результат был не очень-то и прогнозируемый.
Но однажды, возникла ситуация, когда у брокера его учетная система “упала” (т.е. Шлюзы работали, а вот лимиты он выгрузить не мог). Мы просто не смогли запуститься. Т.е. Мы явно почувствовали насколько наш бизнес зависит от качества ИТ-службы брокера.
Размышляя над сложившейся ситуацией, я начал погружаться в сам процесс взаимодействия УК и брокера. И у меня родилась мысль, что мы можем сами рассчитывать все параметры сделки, еще до того, как брокер пришлет нам отчет.
Естественно, у нас были заключены договоры на обслуживание фондов. В этих договорах прописаны условия. Меня интересовал % комиссии и порядок ее начисления.
Далее, нужно было получать сделки в режиме online. Тут нам помог Quik который предоставил такой продукт как Quik Export. Он выгружал наши сделки в указанную таблицу в MS SQL Server.
В итоге, в прототипе мы создали подсистему, которая в режиме online предоставляла нам данные отчета брокера для биржевых сделок. Неохваченной оставалась только внебиржа. Но объем внебиржевых сделок у нас был мизерный.
После того, как прототип прошел испытания путем ежедневной сверки с отчетом брокера, было принято решение об имплементации данной технологии.
Теперь, мы в режиме online (T0) загружали сделки в учетную систему и тут же проводили их. Утром приходили все те же отчеты брокера. Но, теперь они не загружались, а по ним проводилась сверка, что сокращало время в 1000чи% и главное не останавливало процессы. Причем, это уже шло в автоматическом режиме. Если система определяла расхождение, она направляла письмо в Back Office, Middle Office и ИТ. Это уже считалось инцидентом, который решался сообразно.
Что мы получили:
Я решил изложить свой опыт потому, что в последствии, подобный подход, в том или ином виде, мне пригодился многократно. Не претендую на новатора. Но, возможно, это будет полезно кому-то еще.
В целом, получалось, что у нас был час. Правда, нужно отнять время подготовки отчетов с переоценкой портфелей для трейдеров. Плюс, нужно учесть, что брокер мог и “слегка” опоздать. И тогда наш Back Office становился центром вселенского Зла.
В общем, каждый день начинался с напряга. Middle Office должен был прийти пораньше, чтобы “вытрясти” из брокера отчеты, успеть загрузить их и передать в Back Office, который должен был успеть все учесть и выкатить актуальные портфели трейдерам. Как вспомню, так вздрогну.
Естественно, первым делом рассматривались средства оптимизации алгоритмов учета. Сложные сделки проводились достаточно медленно. Если я правильно помню те времена, то отчет брокера на 1000 сделок грузился и учитывался около 5 минут. Если учитывать, что портфелей было много, около 30, то легко понять, что в отведенное время мы могли не уложиться (даже учитывая, что загрузка по портфелям шла параллельно). Это как-то решалось приоритетами по загрузке отчетов.
Оптимизация, отчасти, решала вопрос. Наш DBA совместно с системными администраторами добился ощутимого прироста. Опять же, если память не изменяет, где-то на 50% была улучшена производительность. Но это, к сожалению, в корне не решало проблемы.
Дальнейшая оптимизация вела нас уже к обновлению железа. Тут было не все просто. Наш ЦОД был построен на базе железа HP. И упирались мы тогда в СХД, которая трудилась в паре с blade-корзиной. Для обновления требовалось комплексный upgrade что и было нам посчитано где-то в 150 000$. А вот результат… результат был не очень-то и прогнозируемый.
Но однажды, возникла ситуация, когда у брокера его учетная система “упала” (т.е. Шлюзы работали, а вот лимиты он выгрузить не мог). Мы просто не смогли запуститься. Т.е. Мы явно почувствовали насколько наш бизнес зависит от качества ИТ-службы брокера.
Размышляя над сложившейся ситуацией, я начал погружаться в сам процесс взаимодействия УК и брокера. И у меня родилась мысль, что мы можем сами рассчитывать все параметры сделки, еще до того, как брокер пришлет нам отчет.
Естественно, у нас были заключены договоры на обслуживание фондов. В этих договорах прописаны условия. Меня интересовал % комиссии и порядок ее начисления.
Далее, нужно было получать сделки в режиме online. Тут нам помог Quik который предоставил такой продукт как Quik Export. Он выгружал наши сделки в указанную таблицу в MS SQL Server.
В итоге, в прототипе мы создали подсистему, которая в режиме online предоставляла нам данные отчета брокера для биржевых сделок. Неохваченной оставалась только внебиржа. Но объем внебиржевых сделок у нас был мизерный.
После того, как прототип прошел испытания путем ежедневной сверки с отчетом брокера, было принято решение об имплементации данной технологии.
Теперь, мы в режиме online (T0) загружали сделки в учетную систему и тут же проводили их. Утром приходили все те же отчеты брокера. Но, теперь они не загружались, а по ним проводилась сверка, что сокращало время в 1000чи% и главное не останавливало процессы. Причем, это уже шло в автоматическом режиме. Если система определяла расхождение, она направляла письмо в Back Office, Middle Office и ИТ. Это уже считалось инцидентом, который решался сообразно.
Что мы получили:
- Очень приближенную к реальности оценку портфеля в режиме реального времени;
- Контроль над структурой и составом активом в соответствии с модельными портфелями и требованиями ФСФР;
- Существенно были снижены требования к системе и инфраструктуре по производительности;
- Дополнительный механизм контроля над брокером;
- Условную автономность от брокера, даже в том случае, если учетная система брокера “обрушилась”;
- Существенно сэкономили средства и время компании.
Я решил изложить свой опыт потому, что в последствии, подобный подход, в том или ином виде, мне пригодился многократно. Не претендую на новатора. Но, возможно, это будет полезно кому-то еще.