Контрольные вопросы при выборе ХД для регуляторной отчетности

Надзорный процесс Банка России перестраивается на датацентричный подход. Современный ответ на требования регулятора — использование хранилища данных для подготовки нормативной информации на основе единой модели. Предлагаем восемь вопросов, обязательных к рассмотрению при выборе перспективной ХД-платформы для надзорной отчетности

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

Адекватный ответ на датацентричные инициативы регулятора — использование хранилища данных. Оно консолидирует атомарные данные, распределенные по системам-источникам внутри банка, в единой предметно-ориентированной базе данных и обеспечивает оперативный доступ к ним. Ежедневная перекладка данных из учетных модулей в ХД выполняется с помощью инструментов ETL (Extract, Transform, Load, извлечение, преобразование, загрузка). Так как архитектура хранилища оптимизирована для быстрой загрузки данных, то, как правило, к началу рабочего дня данные за предыдущий день уже доступны для подготовки отчетности. Для еще большей оперативности в течение дня можно дозагружать в ХД появляющиеся в данных изменения.

По информации из открытых источников, вендорские хранилища данных для подготовки обязательной отчетности сегодня в разной мере задействуют менее 10% российских банков. Остальные применяют сложившиеся годами технологии на базе АБС, хранилищ и витрин данных собственной разработки и электронных таблиц. Отказ от иностранного ПО и перевод основных банковских систем на разрешенный технологический стек — идеальный момент, чтобы модернизировать IT-ландшафт банка в датацентричной парадигме и внедрить современное отечественное хранилище данных для надзорной отчетности.

На этой волне разработчики и интеграторы активно продвигают в банки ХД-платформы разной степени зрелости и готовности к решению регуляторных задач. Проверить их качество поможет чек-лист от компании «Интерсофт Лаб», которая 25 лет разрабатывает и внедряет хранилища данных и системы отчетности в российских кредитных организациях. Он включает в себя восемь контрольных вопросов для банков, выбирающих хранилище с перспективой поддержки датацентричного подхода.

Модель данных

Любое хранилище опирается на модель данных. ХД, ориентированное на решение прикладных задач банка, должно использовать отраслевую модель данных.

Такая модель описывает направления банковской деятельности в виде информационных объектов (например, клиенты, счета, договоры и пр.), их атрибутов (номер счета, остаток на счете, тип договора и др.) и взаимосвязей между ними. Она задает состав первичных и производных объектов и атрибутов данных, необходимых и достаточных для подготовки всех видов банковской отчетности, в том числе обязательной для Банка России, и других данных для предоставления в органы надзора.

Фактически модель объединяет требования к составу данных, которые необходимо собрать в ХД для регуляторных целей.

Банк России ведет работу над созданием единой Национальной модели финансовых данных в интересах всех кредитных организаций. Текущие требования к модели детерминируются методическими рекомендациями Банка России от 16 марта 2023 года № 5-МР «По унификации подходов к формированию кредитными организациями отчетных данных и иной информации по отдельным предметным областям для представления в Банк России». Соответствие им на данном этапе является контрольным критерием качества модели ХД, предназначенного для поддержки датацентричного подхода

Обеспечение качества данных

Нарушения дисциплины и ошибки в обязательной отчетности на 95% вызваны низким качеством данных, на которых она строится. Под качеством данных принято понимать их полноту, согласованность и безошибочность. За обеспечение качества данных в хранилище отвечают встроенные инструменты контроля данных. Их наличие — обязательное требование к ХД-платформе.

В ХД «Контур» от «Интерсофт Лаб», например, реализовано несколько уровней проверок данных:

• технические проверки при заполнении модели данных: заполнение обязательных полей, соответствие типов загружаемых данных, связей между данными, контроль дубликатов и пр.;
• контроли для выверки данных бухгалтерского учета: сверка остатков по лицевым счетам с остатками по балансовым счетам, контроль сходимости баланса по балансовым счетам и т.п.;
• сверки данных бухгалтерского и оперативного учета: сверка остатков по балансовым и лицевым счетам с позициями договоров и др.

Все дистрибутивные проверки выполняются автоматически при загрузке данных в ХД и после ее завершения. Для учета особенностей подготовки отчетных данных в конкретном банке могут потребоваться уникальные, не тиражные, контроли. Софт должен предоставлять возможность подключать дополнительные проверочные процедуры.

Инциденты, то есть обнаруженные при проверках ошибки в данных, должны фиксироваться в специальных журналах. Развитые сервисы обработки инцидентов позволяют проверять готовность данных из учетных систем к прикладной обработке и выпуску отчетов, назначать ответственных и задавать сроки исправления выявленных проблем, а также анализировать динамику состояния данных и затраты на обеспечение качества данных.

В планах Банка России — предоставление рекомендаций по составу и содержанию проверок качества данных при заполнении единой модели. Например, на сайте cbr.ru в разделе для отчитывающихся организаций уже опубликовано и регулярно обновляется описание контролей качества данных для реализованной в датацентричном представлении формы 0409310.

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

Обогащение данных

Автоматические проверки заполнения финансовой модели ХД позволяют обнаружить нехватку поступающих данных для целей надзора.

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

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

Поэтому штатные инструменты обогащения, предназначенные для самостоятельной настройки специалистами по отчетности, — важнейший атрибут зрелой ХД-платформы для регуляторной отчетности. Их наличие и возможности следует пристально изучить.

Историзация данных и метаданных

Некоторые формы отчетности строятся на основе истории изменения атрибутов бизнес-объектов. Например, для формы 0409401 необходима история изменения атрибута о резидентстве подотчетного контрагента.

То же самое касается изменений в методологии подготовки любой отчетной формы. Новые методические требования, вступающие в действие с определенной даты, находят свое отражение в описании данных, настройках и расчетных алгоритмах ПО, то есть в метаданных, если выражаться языком IT. Чтобы выпустить форму за любой период по актуальным для него нормативным правилам, требуется хранить в системе историю изменения метаданных.

Историзация данных и метаданных — исключительно полезное свойство ХД регуляторной направленности. Оно позволяет хранить историю редактирования любых данных, атрибутов и настроек и использовать ее по мере необходимости для анализа данных, подготовленных ранее в надзорных целях.

Историзация практически не встречается в заказных хранилищах и реализована далеко не во всех тиражных ХД-платформах. Проконтролировать это свойство ПО на этапе выбора хранилища — необходимо.

Подготовка отчетных форм

В настоящем отчетность для регулятора готовится в формацентричной парадигме. Перевод ее выпуска на ХД-платформу требует времени и отвлечения ресурсов. Чтобы совместить текущие отчетные процессы и внедрение новой системы, подготовку форм переносят в хранилище поэтапно: в среднем от двух до четырех форм каждые 3–5 месяцев. Порядок перевода форм в каждом банке индивидуален. На приоритеты влияют изменения регуляторных требований, «узкие места» сложившихся подходов к подготовке отчетности, проблемы с ресурсами и пр.

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

• витрину/набор витрин данных с первичными данными и расчетными показателями формы;
• алгоритмы расчета показателей;
• правила проверки бизнес-логики при подготовке отчета;
• интерфейс с каноническим представлением формы;
• механизм выгрузки готовых отчетных данных в ПК «Дельта».

Зрелые решения отличают дополнительные сервисы для подготовки отчетных форм:

• инструменты внесения исправлений в готовую для отправки регулятору форму — востребованы для оперативной корректировки формы непосредственно перед сдачей в Банк России;
• механизмы защиты переданной регулятору формы, включая витрину с детальными данными и показателями, от изменений — позволяют в любой момент вернуться к версии данных, отправленных в Банк России;
• средства выгрузки отчетных данных во внешний табличный редактор — всегда полезны для бухгалтеров, ответственных за подготовку формы.

В датацентричной парадигме часть этапов формацентричной технологии должна перейти к регулятору. На стороне банков останется задача подготовки данных в формате для отправки в Банк России. То есть будут востребованы инструменты для сбора, консолидации и обеспечения качества данных, их обогащения, историзации, расчета показателей, их сверки, обмена данными с регулятором и защиты переданных данных. Это значит, что сделанные сегодня инвестиции в ХД-платформы для регуляторной отчетности продолжат работать и после внедрения датацентричного подхода.

Техническая поддержка

Хорошая практика — изучение проекта договора технической поддержки ПО для регуляторной отчетности на этапе выбора поставщика.

В фокус внимания должны попасть:

• условия поддержки в программном обеспечении изменений в инструкциях регулятора, регламентирующих подготовку отчетности. Принципиально убедиться, что исполнитель обязуется поставлять в банк обновления ПО с учетом актуальных нормативных требований до вступления соответствующих инструкций в действие, чтобы заказчики могли заранее протестировать их работу;
• сроки устранения ошибок в работе ПО, скорость реакции на обращения, доступность службы поддержки, условия оказания услуг во внерабочее время, в срочном режиме и другие параметры предоставления услуг технической поддержки. Важно удостовериться, что включенные в договор сроки реагирования не приведут к нарушению дисциплины отчетности.

Отдельного внимания заслуживают условия сопровождения кастомизированного, то есть выходящего за границы тиражного ПО, решения, например разработанных по заказу банка дополнительных внутри/межформенных проверок или загрузок данных из внесистемных источников. Важно заранее согласовать условия поддержки таких доработок, чтобы обеспечить непрерывность функционирования решения после установки тиражных обновлений. В противном случае от заказных доработок целесообразно отказаться.

Соответствие критериям отечественного ПО

Софт, обеспечивающий подготовку данных для надзора, не категорируется как значимый и не является первоочередным для импортозамещения. Только кредитным организациям с государственным участием согласно обновленным в январе 2024 года «Методическим рекомендациям по цифровой трансформации государственных корпораций и компаний» до 1 января 2025 года предстоит отказаться от использования иностранных офисных пакетов, а к 1 января 2026 года перевести свой софт на отечественные СУБД. Однако на стратегическом горизонте задачу импортозамещения небезопасных хранилищ данных, отчетных систем и их компонентов предстоит решать практически каждому банку.

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

Опыт эксплуатации в российских банках

Помимо функциональных и нефункциональных характеристик решения, весомым критерием выбора является опыт эксплуатации хранилища для подготовки обязательной отчетности в российских банках. Чем больше проектов реализовал вендор, тем более развитой будет модель хранилища, более богатым набор контролей качества данных и функциональных характеристик, более полным пакет отчетных модулей, более широким состав дополнительных сервисных функций, более весомыми компетенции исполнителей.

Лучшим подтверждением качества ПО и опыта внедренческой команды станет референс визит к его непосредственным пользователям. Идеально, если банк организует его, минуя вендора. Как говорится, доверяй, но проверяй.

Автор: Юлия Амириди, заместитель генерального директора по развитию бизнеса, компания Intersoft Lab

Источник: Банковское обозрение