СоХабр закрыт.

С 13.05.2019 изменения постов больше не отслеживаются, и новые посты не сохраняются.

| сохранено

H Функция look_into_future в учетных системах или как сэкономить 150 000$ в черновиках

Как-то я работал в одной инвестиционной управляющей компании. Перед моей командой была поставлена тривиальная задача — сделать так, чтобы отчеты брокера успевали загрузиться до открытия очередной торговой сессии. Приходили они к нам около 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 и ИТ. Это уже считалось инцидентом, который решался сообразно.

Что мы получили:

  1. Очень приближенную к реальности оценку портфеля в режиме реального времени;
  2. Контроль над структурой и составом активом в соответствии с модельными портфелями и требованиями ФСФР;
  3. Существенно были снижены требования к системе и инфраструктуре по производительности;
  4. Дополнительный механизм контроля над брокером;
  5. Условную автономность от брокера, даже в том случае, если учетная система брокера “обрушилась”;
  6. Существенно сэкономили средства и время компании.

Я решил изложить свой опыт потому, что в последствии, подобный подход, в том или ином виде, мне пригодился многократно. Не претендую на новатора. Но, возможно, это будет полезно кому-то еще.
–1
261

комментарии (0)