Публикации

Intersoft Lab в СМИ - истории успеха клиентов, интервью и мнения экспертов компании по актуальным задачам банковской аналитики, обзоры рынка CPM

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

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

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

Адекватный ответ на датацентричные инициативы регулятора — использование хранилища данных. Оно консолидирует атомарные данные, распределенные по системам-источникам внутри банка, в единой предметно-ориентированной базе данных и обеспечивает оперативный доступ к ним. Ежедневная перекладка данных из учетных модулей в ХД выполняется с помощью инструментов 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

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