Поделиться
Топ-7 доводов в пользу выпуска регуляторной отчетности из хранилища данных
Заместитель генерального директора компании «Интерсофт Лаб» Юлия Амириди рассказала, зачем выпускать регуляторную отчетность из хранилища данных, если банк использует централизованную АБС.
В автоматизации регуляторной отчетности в российских банках давно наблюдается «эффект маятника». В 90-е годы обязательная отчетность готовилась преимущественно на базе электронных таблиц и АБС, в которых «сводили» поступившие из филиалов показатели и отчеты. В начале 2000-х начались эксперименты с заменой этой технологии на сбор первичных данных из учетных систем обособленных подразделений в единое хранилище данных (ХД). Из него выпускали отчеты головной организации, филиалов и сводную отчетность. Начавшаяся позже неспешная замена децентрализованных банковских систем на централизованные в течение почти двух десятилетий поддерживала спрос на отчетные модули в составе АБС. В противовес этому консолидация банковского сектора на фоне кризиса 2008–2010 годов и последующей пятилетней «чистки» периодически возвращала интерес крупных игроков к подготовке обязательной отчетности на базе ХД. Сегодня под давлением датацентричных инициатив и импортозамещения маятник снова движется в сторону перевода отчетных процессов из АБС в ХД.
Проанализируем актуальные регуляторные, технико-стратегические и функциональные аргументы в пользу выпуска нормативной отчетности из ХД.
Главный вопрос, на который предстоит ответить — зачем переводить подготовку данных для надзора на ХД-платформу, если банк использует централизованную АБС, и консолидировать первичные данные нет необходимости?
Планы цифровизации регулирования и надзора
Некоторое время назад Банк России анонсировал плавный переход на датацентричный сбор информации от кредитных учреждений в рамках цифровизации регулирования и надзора. Стратегическая цель — перейти от реактивного к проактивному и риск-ориентированному пруденциальному надзору. Для этого предполагается заменить получение от банков периодических отчетных форм на сбор практически в реальном времени первичных данных об их деятельности на основе единой референсной модели. На основе поступающих данных регулятор будет сам оценить устойчивость кредитных организаций и указывать им на потенциальные проблемы.
Двигаясь к датацентричности, Банк России модернизирует методическую базу и параллельно зондирует технологическую готовность банков к переходу. В частности, оптимизируется действующая отчетность и вводятся новые более оперативные и детальные формы в датацентричном представлении. Одновременно регулятор оценивает готовность систем управления данными в кредитных организациях, зрелость применяемых для подготовки отчетности моделей данных, инструментов обеспечения качества данных и т.п.
Несмотря на известные неудачи отдельных датацентричных инициатив, риторика Банка России относительно внедрения датацентричного подхода остается неизменной. В частности, продолжение работы по оптимизации сбора отчетности на основе датацентричного подхода обозначено в документах «Основные направления развития финансовых технологий на период 2025–2027 годов» и «Основные направления развития национальной платежной системы на период 2025–2027 годов».
ХД является приоритетной по сравнению с АБС платформой для реализации датацентричного подхода и обладает всеми необходимым для этого характеристиками: расширяемой моделью данных, готовыми встроенными инструментами управления качеством данных, высокой производительностью выполнения запросов и формирования выборок данных и проч. При этом независимо от частоты и объемов передаваемых регулятору данных ХД не создает нагрузку на АБС.
Переход на импортонезависимую (версию) АБС
Согласно «Правилам категорирования объектов КИИ», утвержденных Постановлением Правительства РФ №127, к экономически значимым относятся системы, на которые распространяется угроза прекращения и нарушения проведения платежных операций. По этому критерию АБС присваивается категория экономической значимости, а ХД, напротив, не попадает в разряд значимых объектов КИИ. Это означает, что перейти на импортонезависимую версию АБС предстоит каждому банку.
Сохранить непрерывность подготовки регуляторной отчетности кредитной организации в период перевода АБС на разрешенную СУБД или замены основной банковской системы на новую с опорой на независимые технологии — задача, которую целесообразно поручить ХД.
Уже сейчас ясно, что миграция АБС на независимую СУБД потребует серьезного времени. В переходный период система выпуска отчетности на базе ХД будет функционировать независимо от основной учетной системы. Замену потоков данных, поступающих в ХД из модулей «старой» АБС, на потоки из новых источников можно выполнять по мере ввода соответствующих частей АБС в эксплуатацию. Переключения между источниками будут незаметны специалистам, выпускающим отчетность. Таким образом, использование ХД позволит защитить процессы подготовки данных для надзора от нестабильности и обеспечит высокую дисциплину и качество регуляторной отчетности.
И все-таки консолидация данных
Следует признать, что централизованная АБС не является единственным источником первичных данных для построения регуляторной отчетности, это миф.
В любом банке найдутся модули, данные которых надо консолидировать с данными АБС для подготовки отчетности. Чаще всего это будут торговые системы и системы управления взаимоотношениями с клиентами (CRМ). Кроме того, не стоит сбрасывать со счетов банковские группы, когда одно ХД обслуживает сразу несколько банков, и используется для подготовки отчетности каждого участника и ряда групповых форм, например, 0409115к, 0409117к, 0409118к, 0409127к и др.
Во всех этих случаях ХД будет решать задачу консолидации данных для регуляторной отчетности.
Поддержка изменений методологии подготовки отчетности и данных
Целый ряд форм отчетности требует для подготовки истории изменения данных и их атрибутов. Например, для формы 0409118 с целью оценки концентрации кредитного риска по группе связанных заемщиков требуется история изменения атрибута о связи заемщика с группой. Для этого система подготовки реготчетности должна хранить такие данные.
Не менее важно фиксировать в отчетной системе все изменения в правилах подготовки отчетных форм, то есть сохранять историю метаданных. Как известно, регулятор время от времени модифицирует порядок составления форм. Чтобы выпускать отчеты за любой — прошлый или текущий — период по актуальным для него требованиям, необходимо хранить историю соответствующих настроек и расчетных алгоритмов.
АБС не ведут такие записи, в то время как механизмы историзации данных и метаданных являются обязательными для ХД и сохраняют «следы» редактирования данных, их атрибутов и настроек. Это значит, что любой расчет в системе реготчетности на базе ХД выполняется по действующим на конкретную дату правилам и оперирует актуальными для нее данными. После изменения настроек формы все новые расчеты, сделанные в ХД, будут осуществляться по новым правилам, а расчеты, произведенные ранее даты изменений, — по старым. Кроме того, всегда можно узнать, кто и когда внес исправления в данные и настройки ПО.
Таким образом, выпуск форм, для которых необходима история изменения данных и атрибутов, или может потребоваться расчет показателей на любую дату на основе актуальных для нее правил, целесообразно перевести из АБС в ХД. И это решение не зависит от архитектуры АБС.
Контроль и обеспечение качества первичных данных
Львиная доля сложностей с подготовкой отчетности связана с низким качеством первичных данных в АБС. С одной стороны — это ошибки и несогласованность в данных, с другой — их нехватка для целей надзорной отчетности.
Выявить все проблемы на стороне АБС практически невозможно, особенно, если речь идет о консистентности данных из разных модулей банковской системы. Гораздо эффективнее сделать это при загрузке данных в единое ХД. На этом этапе с помощью автоматических контролей можно обнаружить незаполненные поля и другие технические погрешности в данных, включая дублирование, а также проверить корректность данных бухгалтерского и оперативного учета и их согласованность.
Мало обнаружить проблемы — их необходимо устранить, в том числе добиться полноты данных. Дело в том, что в основной учетной системе банка обычно не предусмотрено ведение всех атрибутов, необходимых для подготовки обязательной отчетности. Обеспечить их ввод в АБС теоретически возможно, но зачастую нецелесообразно. Это может замедлить выполнение основных функций системы или возложить непрофильную дополнительную нагрузку на сотрудников. Кроме того, такой подход не всегда оправдан экономически, как, например, в случае приобретения и внедрения отдельного модуля для учета единичных сделок, например, нескольких аккредитивов. Обычно учет в таких «объемах» ведут внесистемно.
В ХД имеется много способов, чтобы обеспечить полноту данных для регуляторной отчетности: отсутствующие атрибуты можно сгенерировать с помощью встроенных инструментов обогащения данных, загрузить из внесистемных источников или ввести вручную. Например, для Приложения 4(1) к Положению 753-П можно задать правила, по которым счета будут автоматически размечаться 6-значными кодами обозначения на основании анализа атрибутов клиента.
Контроль качества данных и их обогащение — обязательные этапы автоматизированной технологии подготовки регуляторной отчетности. ХД готово к решению этих задач, а АБС, независимо от количества используемых копий, не оснащена соответствующими инструментами.
Поддержка ресурсоемких вычислений
Подготовка ряда форм регуляторной отчетности, например, расчет обязательных нормативов, предполагает несколько этапов сложной обработки больших массивов данных. Производительность АБС практически всегда страдает от такой нагрузки, тормозя основные учетные процессы.
В то же время база данных ХД оптимизирована для массового выполнения запросов и выпуска отчетов. Поэтому подготовку форм, предполагающих ресурсоемкие вычисления с использованием сложных алгоритмов, разумно передать в ХД, даже если банк использует централизованную АБС.
Экономия на масштабе
Ценность ХД заключается в предоставляемых им возможностях. Чем больше задач решается на базе единого ХД, тем ниже издержки на автоматизацию каждой задачи в отдельности. Отдача от масштаба достигается за счет переиспользования данных ХД в интересах разных заказчиков внутри банка.
Сегодня ХД — обязательный компонент ИТ-инфраструктуры любой кредитной организации. В основе зрелого финансового ХД лежит отраслевая модель данных. Она покрывает большинство потребностей банка в анализе и подготовке внутренней и внешней отчетности. Выпуск отчетов для Банка России — задача, перенос которой в ХД позволяет добиться серьезной экономии масштаба. Например, если в интересах риск-департамента в ХД налажен сбор данных о клиентах, бухгалтерского учета и портфелей договоров, то такой набор на 80% обеспечит потребности регуляторной отчетности. Останется дособрать только некоторые сегменты и атрибуты данных.
Поэтому с самого начала, когда определяется стратегическое значение ХД в технологически независимой инфраструктуре банка, целесообразно предусмотреть перевод в ХД процессов выпуска регуляторной отчетности. Это позволит не только разгрузить АБС и вывести на новый уровень технологию подготовки данных для надзора, но и повысить эффективность инвестиций в ХД. В качестве бонуса банк получит непротиворечивую управленческую, аналитическую и регуляторную отчетность, лишенную расхождений в идентичных показателях, подготавливаемых для разных бизнес-вертикалей и регулятора.
■ Рекламаerid:2W5zFK74c5NРекламодатель: ООО «Интерсофт Лаб»ИНН/ОГРН: 9715000862 / ОГРН 5147746205833Сайт: www.iso.ru
Короткая ссылка
