Почему переход к XBRL-CSV - не очередная регуляторная инициатива, а системный ответ на структурные проблемы рынка
Регуляторные проверки ведения внутреннего учета профучастниками рынка заметно ужесточились. Это требует системного ответа - переход к XBRL-CSV, который задает новую модель взаимодействия между брокером и регулятором.
В последние годы Центробанк усилил контроль не только за отчетностью, но и за логикой формирования первичных данных: теперь особое внимание уделяется полноте отражения операций, наличию сквозной связи между поручением и исполнением, корректности меток доверенного времени и идентификации активов. А ведь многие брокеры до сих пор работают на унаследованных, фрагментированных системах, где данные об одной сделке «размазаны» между торговой платформой, бэк-офисом и депозитарием. В результате, сбор полного досье клиента занимает не один день ручной работы. Именно «неполнота отражения операций» - самое частое замечание в актах Банка России.
Наш опыт сопровождения подготовки к проверкам и предварительных аудитов у десятков брокеров показывает, что замечания регулятора чаще всего связаны не с единичными ошибками, а с системными недостатками архитектуры данных, низкой гранулярностью учета и широким применением ручных процедур. И проверка внутреннего учета превращается из формальной процедуры в стресс-тест всей архитектуры брокера: насколько она способна обеспечить целостную картину операций в машинно-читаемом виде. Поэтому переход к XBRL-CSV становится разумным и современным ответом на все эти вызовы.
Анализ проблем
1. Разрозненность данных: «распыленный» ландшафт систем
Типичной ситуацией является существование нескольких специализированных систем: торговая площадка, депозитарный модуль, CRM/счета клиентов, бэк-офисная система расчетов и отдельные справочники. Данные, относящиеся к одной сделке или клиентскому поручению, фрагментированы между системами и часто дублируются в разных форматах.
В результате, при запросе регулятора сотрудники вынуждены вручную собирать данные и сопоставлять отчеты из разных источников, что приводит к ошибкам в идентификации контрагентов, несоответствиям по датам и невыполнению регламентных сроков предоставления данных. В актах проверок регулярно встречаются такие замечания: в регистрах внутреннего учета нет данных о времени поступления поручения и данных об исполнителе, идентификаторы активов указаны некорректно или не в том формате.
На практике это выглядит так: инспектор запрашивает информацию о сделках клиента Иванова И. И. за определенный период. Специалист брокера вручную выгружает все сделки из торговой системы, сверяет их с выпиской из депозитария, ищет в CRM поручения и переписку с трейдером. На это уходит день, и риск ошибки - огромен.
Наши кейсы подтверждают: наличие «островков» данных увеличивает время подготовки выборок для проверяющих в разы и повышает риск формальных нарушений.
Многие брокеры пытаются компенсировать фрагментарность данных построением корпоративных хранилищ (data lake) или сводных витрин. Такие решения действительно помогают для аналитики и управленческой отчетности, но не решают проблему первичного учета. В момент проверки регулятор требует не агрегированные данные, а восстановление цепочки «поручение - исполнение - отражение», и сотрудники все равно вынуждены поднимать записи из исходных систем вручную.
Эта архитектурная разобщенность - фундаментальная причина замечаний о неполноте отражения операций. Именно отсюда вытекает следующая проблема - недостаточная регуляторная атомарность учета, когда данные по сделке формально ведутся, но не обеспечивают требуемого уровня детализации.
2. Низкая гранулярность и недостаточная «регуляторная атомарность» учета
Формально большинство учетных систем брокеров уже ведут учет на «атомарном» уровне - это требование 577-П действует с 2017 года. Однако на практике эта атомарность операционная, а не регуляторная: данные по сделке и клиенту фиксируются, но не содержат полноты контекста, который требуют надзорные органы.
Проблема возникает на следующем уровне: при попытке сформировать выгрузку «как видит регулятор» оказывается, что в базе:
- не хватает связки «поручение > исполнение > отражение в регистре»;
- отсутствуют атрибуты, позволяющие однозначно идентифицировать лицо, давшее поручение;
- не сохранены идентификаторы активов/инструментов в форме, пригодной для передачи регулятору;
- часть данных «размазана» по смежным модулям (КИС/CRM/депозитарий), и в исходной транзакции нет полного контекстного набора.
Получается, брокер ведет атомарный учет и технически соблюдает 577-П, но не в той модели, по которой потом проверяющий требует восстановить цепочку и при первой же сквозной проверке сталкивается с типовыми замечаниями.
3. Преобладание ручного контроля и Excel-процедур
До сих пор распространена практика использования Excel-сверок, ручного копирования выгрузок, «локальных» макросов и отдельных скриптов, поддерживаемых узкими специалистами. Такие подходы повышают операционные риски: ошибки, связанные с человеческим фактором, отсутствие версионирования, сложная трассируемость изменений и невозможность централизованной машинной валидации. Проверяющие регулярно фиксируют типовые нарушения, связанные с документальными несоответствиями, нарушением сроков размещения регламентов и ошибками сотрудников при переносе данных вручную. В материалах о типовых нарушениях это самые повторяющиеся замечания - и они напрямую коррелируют с использованием ручных процедур.
Операционные последствия таких подходов - это задержки сверок, множественные корректировки отчетности, повышенный риск штрафных санкций и утрата уверенности регулятора в постоянстве и надежности внутре