ИТ в цифровом брокере

Информационные технологии (ИТ) – это основа цифрового брокера. На мой взгляд у ИТ в цифровом брокере есть две основных задачи:
cоздание цифрового продукта
эффективное выполнение операционной деятельности
Ниже я разберу в чем заключается деятельность при решении каждой из задач, какие технологии используются и какая команда людей нужна. Кроме этого немного затрону особенности инфраструктуры, которая необходима для работы информационных системы брокера.

ИТ для создания цифрового продукта

Деятельность

Базовый продукт для цифрового брокера - это современный пользовательский интерфейс, который позволяет открыть счет, зачислить деньги, выбрать акции, купить/продать акции и вывести деньги.
Современный пользовательский интерфейс сейчас - это в первую очередь мобильное приложение. Но не только. Кроме мобильного приложения цифровой-брокер может предлагать и другие интерфейсы для пользователей: веб-сайт, партнерские платформы и маркетплейсы, чат-боты.
Поэтому ИТ на продуктовом направлении можно разбить на две части:
Разработка мобильного приложения или веб-сайта, т.е. frontend разработка.
Разработка платформы с понятным API, т.е. backend разработка. Этот API сможет использовать не только собственное мобильное приложение или веб-сайт, но и приложения партнеров. Например, банк-партнер сможет воспользоваться API, чтобы отображать брокерские счета в своем приложении.
Мы в Newton занимаемся разработкой обеих частей.

Frontend разработка

Выбор технологии для написания мобильного приложения очень острый и важный вопрос. Он сводится к выбору из двух фундаментальных подходов:
Использовать нативные технологии, которые предоставляет разработчик операционной системы для телефона. Т.к. в мире сейчас две популярных операционных системы: Android и iOS и у каждой свой язык разработки, то писать придется два отдельных приложения.
Использовать технологии, которые позволяют писать один код, но запускать его и на Android и на iOS. В мире сейчас две самых популярных технологии, которые используют такой подход: ReactNative от Facebook и Flutter от Google.
Первый подход позволяет делать более производительные приложения, т.к. он максимально эффективно использует возможности операционной системы. Второй подход позволяет все делать в два раза дешевле(или быстрее), но за счет неоптимальной работы в каких-то местах.
Чтобы выбрать, нужно понять каким будет ваше приложение, насколько оно будет требовательно к производительности. Чтобы было проще оценить. можно выделить три основных типа деятельности, требующей производительности:
Взаимодействие с операционной системой телефона (доступ к фото, файлам, использование GPS).
Скорость рендера визуальных элементов (количество картинок в секунду).
Бизнес-логика.
Т.о нужно ответить на три вопроса:
будет ли ваше инвестиционное приложение активно использовать камеру, GPS или доступ к фото?
будет ли ваше приложение похоже на мобильной игру? будет ли в нем много красивых анимаций и плавных переходов?
много ли сложных вычислений будет производится в вашем мобильном приложении?
Для приложения на фондовом рынке самым спорным является ответ на второй вопрос. Всегда хочется сделать приложение как можно красивее, но нужно помнить, что это может потребовать в два раза больше ресурсов (деньги и/или время).
ReactNative и Flutter активно развиваются и позволяют включать нативные элементы в свой код. Поэтому если какая-то конкретная часть приложения работает не так как бы хотелось, только ее можно реализовать на нативной технологии, а не все приложение.
Нам в Newton нравится такой комбинированный подход, поэтому мы используем ReactNative, в который встраиваем нативные модули, если это необходимо.

Backend разработка

Основная задача backend - это реализация API для мобильного приложения. Стандартный и самый популярный подход - это использование REST API.
Технологий, которые позволяют решить эту задачу масса. Поэтому каждая команда выбирает то, что им удобно и больше нравится.
В команде Newton исторически развивалась экспертиза в PHP, поэтому мы используем популярный PHP фреймворк Laravel.
API не работает сам по себе, он предоставляет информацию, которая хранится в базе данных, работает с кэш, запускает тяжелые задачи с помощью очередей и связывается с другими сервисами.
В Newton в качестве универсальной базы данных мы используем PostgreSQL, для кэша используем Redis, а для очередей Kafka.

Команда

Продукт придумывают продакт-менеджеры. Они решают какие функции нужно реализовать в первую очередь. Продакт-менеджеры работают в тесной связке с дизайнерами. Дизайнеры рисуют интерфейс и делают первые прототипы.
Для разработки нужны frontend- и backend-разработчики. Они воплощают продуктовые идеи в коде.
Кроме разработчиков нам нужны DevOps специалисты, они отвечают за то, чтобы быстро выпускать для пользователей то, что было сделано разработчиками. Они же следят за тем, чтобы боевые системы исправно работали.
Нам нужны специалисты по тестированию (QA), которые будут проверят то, что сделали разработчики.
Кроме этого в продуктовой ИТ команде есть проджект-менеджеры, которые следят за тем, чтобы процесс производства шел непрерывно и аналитики, которые разбираются с тем, как именно нужно реализовать идеи продуктовой команды.

Инфраструктура

Нам нужно выбрать на каких серверах запускать backend мобильного приложения. Обычно выбор стоит между собственными железными серверами и облачными.
Облачные технологии уже очень хорошо развиты и их очень удобно использовать. Поэтому мы в Newton выступаем за использование облачных мощностей.
Но здесь есть одна очень важная деталь - это работа с персональным данными. Она накладывает значительные ограничения на выбор. Сервера с персональными данными должны быть в России и они должны удовлетворять определенным условиям.
Поэтому обычно сервера с перс данными выделяют в отдельный сегмент архитектуры и работают с ними особенно аккуратно, а для остальной части выбирают то, что нравится.

Frontend → API backend → ?

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

ИТ для выполнения операционной деятельности

Деятельность

Вспомним какие виды операционной деятельности есть у брокера:
Открытие счета
Прием и вывод денег
Доступ на рынок (DMA)
Риск-менеджмент
Предоставление рыночных данных (MD)
Учет операций в бэкофисе
Учет денег и выплата налогов
Казначейство
ПОД/ФТ
Теперь разберем какие ИТ системы и интеграции обеспечивают эту операционную деятельность.
Системы:
Frontend
Backend
Риск-сервер
Бэкофис: админка + бд
Бухгалтерия: админка + бд
Депозитарий: админка + бд
Интеграции:
С биржей для регистрации клиента
С биржей для торговли
С биржей для получения рыночных данных
С банком для обработки платежей
С системами удаленной идентификации для открытия счета
С реестрами необходимыми для проверки ПОД/ФТ

Открытие счета

Цифровой брокер при открытии счета регистрирует клиента в своих учетных системах и на бирже. Весь процесс происходит в автоматическом режиме, т.к. одновременно могут открываться большое количество счетов.
В системе Newton за открытие счета отвечает модуль AccountCreation. Он предоставляет API для фронтенд и интегрируется с бэкофисом и депозитарием брокера, чтобы напрямую доставлять данные клиента, полученные через API, в учетную систему.
С технической точки зрения бэкофис и депозитарий – это базы данных, у которых есть админки для работы с этими данными. Админка – это обычно десктопное приложение, которое стоит на компьютере специалиста из отдела внутреннего учета брокера.
Перед регистрацией в учетных системах пользователь проходит идентификацию и подписывает документы с помощью смс.
Важной частью открытия счета является проверки ПОД/ФТ. Каждый клиент должен быть проверен по запрещающим спискам.
Кроме своих учетных систем брокер регистрирует клиента на бирже. Например, MOEX предоставляет специальный API, чтобы этот процесс можно было автоматизировать.

Пополнение брокерского счета

Процесс пополнения брокерского счета состоит из двух частей:
Интерфейс пополнения для клиента. Тут два стандартных способа: перевод на реквизиты или пополнение с карты. Перевод на реквизиты - это самый простой для реализации способ. Достаточно просто показать реквизиты, остальное будет происходить в интернет-банке клиента. А вот пополнение с карты требует интеграции с эквайрингом банка. В системе Newton такую интеграцию реализует модуль Newton Acquiring.
Обработка платежей, которые приходят на специальный брокерский счет (СБС). Очень важно уметь разбирать и зачислять клиентами платежи автоматически. Таких платежей в день могут быть тысячи. ИТ-сервис, который это делает, должен быть интегрирован с одной стороны с API банка, в котором находится СБС, а с другой стороны с бэкофисом брокера.

Вывод денег

Технически вывод денег означает: регистрацию поручений клиента, расчет и удержание налога, перевод денег со счета брокера на счет клиента.
Регистрация поручения происходит автоматически, для этого используется API бэкенда, который интегрирован с системами брокера. В Newton за это отвечает модуль Portfolio.
Расчет налога обычно происходит в бэкофисе брокера. Например, бэкофис QORT поддерживает такие расчеты.
Перевод денег между счетами может осуществлять сервис подобный сервису, который обрабатывает входящие платежи. С одной стороны этот сервис интегрирован с бэкофисом с другой стороны он умеет работать с API банка, в котором находится СБС.

Доступ на биржу. Торговля

Доступ на биржу схематично выглядит так:
Клиент – https → backend – FIX → Риск-сервер – FIX → Биржа
Backend реализует API для подачи торговых поручений. Он получает поручения и транслирует их в Риск-сервер брокера. Риск-сервер проверяет хватает ли денег у клиента и только после этого транслирует поручения на биржу.
Для риск-сервера или для биржи прием торговых поручений от других ИТ-систем - это стандартная задача. Для решения такой задачи во всем мире используют протокол FIX. Иметь такой стандартный протокол - это очень удобно. Если ваша система поддерживает протокол FIX, то она может быть подключена к почти к любой бирже в мире, т.к. большинство бирж поддерживают FIX. В системе Newton для этого есть модуль OR, он как раз реализует этот протокол.
Но это не единственный возможный вариант. Риск-сервер или биржа могут иметь свой собственный протокол. Это менее удобно, т.к требует дополнительных затрат на интеграцию, но иногда может давать преимущество в скорости обработки поручений.

Команда

Сервисы, которые необходимы для автоматизации операционной деятельности - это в первую очередь backend сервисы. Поэтому в команде нужны backend разработчики. Java - де факто стандарт при выборе языка для разработки таких сервисов. Чтобы разрабатывать сервисы, которые тесно интегрированы с системами брокера, нужны аналитики, которые хорошо разбираются в предметной области. Обязательно нужны тестировщики, чтобы внимательно проверить правильность работы сервисов. Ну и без DevOps инженеров здесь тоже не обойтись.
Риск-сервер, бэк-офис, депозитарный софт обычно поставляется вендором по лицензии. Поэтому брокеру нужны специалисты, которые будет настраивать и поддерживать эти системы.

Инфраструктура

Брокер работает с данными клиентов, поэтому серверы, которые хранят данные, должны соответствовать ФЗ-152.
У брокера должны быть надежные резервируемые каналы доступа на биржу. Поэтому здесь очень важен выбор дата центра. Для розничного фондового рынка не так важна скорость обмена данными, поэтому необязательно ставить сервера в тот же дата центр, что и биржа. Но обязательно нужно следить за качеством каналов между дата центрами. Сама биржа может посоветовать провайдеров, с которыми она работает.

Заключение

Все ИТ системы брокера связаны между собой. Неудачно сделанное мобильное приложение может принести множество проблем работе систем бэкофиса, а слаборазвитый риск-сервер не позволит сделать удобный интерфейс. Поэтому самое главное для успеха цифрового брокера – это совместная слаженная работа всех систем.
Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.