Современная банковская отчетность находится в точке напряжения между растущими регуляторными требованиями и ограниченными возможностями существующих в банках систем: требуется своевременное предоставление большого объема регламентированных отчетов различным контролирующим органам и внутренним подразделениям банка, импортозамещение на отечественные разработки, диверсификация банковских операций, увеличение объема данных.
Количество отчетных форм неуклонно растет, при этом требования к качеству и точности предоставляемых данных становятся строже. Штрафы за несвоевременную или некорректную отчетность могут быть от предупреждения и до отзыва лицензии.
Квалифицированных специалистов, понимающих банковский учет и современные технологии обработки данных категорически не хватает. Это создаёт зависимость от узкого круга экспертов и риски при их уходе.
Практически в каждом банке используется несколько систем для учета операций, данные из которых необходимо консолидировать для отчётности.
На данный момент банки предоставляют в Банк России порядка 100 различных форм отчетов. В связи с таким разнообразием отчетных форм возникает вопрос эффективной автоматизации процессов формирования обязательной банковской отчетности. Недостаточность автоматизации данных процессов создаёт дополнительные сложности, увеличивает трудозатраты и снижает качество предоставляемых отчетов.
Автоматизация должна решить ключевые проблемы, возникающие при формировании отчетности:
Избыточность ручного труда: формирование части форм отчетности требует ручной обработки больших объемов данных, агрегации выгрузок из различных АБС в один отчет
Длительность выполнения процедур: многие процессы требуют значительных временных ресурсов даже при наличии современных информационных систем
Недостаточный мониторинг и контроль процессов: часто встречаются противоречия при внесении изменений в процессы сбора и интеграции данных из различных систем, а также это ограничивает принятие эффективных управленческих решений
Legacy-код и недостаточная документация: многие банки продолжают поддерживать старые версии программного обеспечения, разработанные давно, претерпевшие многократные изменения в связи с изменением инструкций Банка России по подготовке отчетных форм и плохо документированных, что усложняет интеграцию новых решений.
Прошлое: Исходные данные как лед – структурированная, но неподвижная система
До появления современных технологий банковская отчетность напоминала замерзшее озеро: данные хранились в жестко заданных структурах, их движение было ограничено, а любое изменение требовало значительных усилий. Отчеты формировались вручную, а проверка данных занимала длительное время. Регуляторные требования росли, но инструменты оставались архаичными – как попытка прорубить путь во льду топором. В этой эпохе зародились первые хранилища данных, но их возможности были далеки от сегодняшних стандартов. Рассмотрим основные этапы развития автоматизации банковской отчетности.
Формирование отчетов средствами MS Excel
Одним из популярных способов является использование формул, создание сводных таблиц и макросов в Microsoft Excel. Этот метод обладает несколькими преимуществами, такими как простота освоения и гибкость инструмента. Правда, есть и недостатки:
Многочисленные выгрузки данных приводят к большому объему работ и увеличивают шансы возникновения ошибок
Отчеты формируются медленно, особенно при обработке больших массивов данных
Применение Microsoft Excel оправдано лишь в отдельных случаях, когда требуется быстрая обработка небольших наборов данных, однако его нельзя считать универсальным решением для комплексной автоматизации отчетности. Тем более он не входит в перечень рекомендованного российского ПО.
Локальные базы данных
Локальные базы данных, например, MS Access, позволяют хранить и визуализировать данные с дальнейшей их обработкой и экспортом отчетных форм. Однако применение локальных баз данных ограничено небольшими командами или отдельными проектами. Основная причина состоит в следующем:
Необходимо предварительно создать выгрузки из основной информационной системы, преобразовать их и импортировать в базу данных
Сложность проектирования модели хранения и ведения истории изменения данных
Настройка отчетов и формирование запросов вручную требует высокой квалификации специалистов и влекут за собой значительные временные затраты
Ручное управление большим объемом данных может приводить к значительным погрешностям и задержкам
Эти ограничения делают решение на локальных БД неприемлемым для крупного бизнеса, которому необходима высокая производительность и надежность систем отчетности.
Автоматизация на уровне АБС.
Многие российские банки используют разработки, основанные на legacy-системах, часто сопровождаемые значительными объемами неструктурированного исходного кода и отсутствующей документацией. Такая практика ограничивает возможности быстрой модернизации и интеграции решений, возникает проблема агрегации данных отчета из нескольких АБС, используемых в банке. Некоторые проблемы связаны с ограниченными возможностями масштабируемости АБС.
Применение АБС в качестве системы формирования отчетности позволяет быстро получать исходные данные, но при этом, из-за закрытости самой системы не позволяет оперативно ее дорабатывать, что неприемлемо в современных условиях постоянно меняющихся требований регулятора.
Реализация отчетности на базе корпоративных хранилищ данных (Data Warehouses)
Развитие локальных баз данных и все большая концентрация накопленных данных привела к внедрению корпоративных хранилищ данных и использованию их возможностей для подготовки регуляторной отчетности.
С приходом корпоративных хранилищ данных и повсеместным распространением философии Agile банковская отчетность обрела гибкость. Данные перестали быть статичными – теперь их можно трансформировать, комбинировать и анализировать в разных разрезах.
Настоящее: Исходные данные как вода – данные обрели текучесть, но еще не вышли за пределы локальных систем
Корпоративные хранилища данных представляют собой мощные средства для централизованного накопления и анализа разнородных данных. Преимущества такого подхода очевидны:
Высокая скорость обработки данных благодаря использованию специальных алгоритмов агрегации и индексации, что позволяет сократить время, необходимое на формирование отчета
Возможность построения сложных аналитических моделей и выявления скрытых закономерностей в данных
Простота масштабирования
Разработка внутренних приложений для формирования отчетности специально под нужды конкретного банка. Это позволяет учесть специфику требований к отчетности, интегрироваться с имеющейся инфраструктурой банка, а также обеспечить высокий уровень безопасности и надежности данных. Правда, разработка такого решения сопряжена с большими начальными вложениями и требует квалифицированных разработчиков и опытных архитекторов
Несмотря на явные плюсы от внедрения корпоративного хранилища данных для нужд построения банковской отчетности, проекты внедрения КХД относятся к трудоемким и всегда требуют значительных вложений. К проекту необходимо привлекать квалифицированных специалистов, системных аналитиков, архитекторов, DevOps и дата-инженеров. Кроме затрат на оплату труда специалистов, нужен бюджет на развитие инфраструктуры и технологий. Но даже вложение значительных средств на внедрение КХД не гарантирует его качественную эксплуатацию и гибкую архитектуру, способную покрывать все возможные запросы, поступающие от специалистов подготовки регуляторной отчетности.
Рассмотрим несколько практических кейсов, которые встретились недавно и демонстрируют возможности решения проблем, возникающих при подготовке данных для отчетов средствами КХД.
Кейс № 1. Формирование продуктовой отчетности по операциям, проведённым вне стандартного продуктового контура АБС
Проблема:
В ряде случаев продуктовые витрины в КХД могут отображать неполную информацию, когда соответствующий тип продукта не заведен в АБС. Это характерно для разовых или новых сделок, а также для операций с малым объёмом, где внедрение полноценного модуля в АБС экономически нецелесообразно или он находится на стадии разработки.
Чтобы не терять клиентов и не блокировать сделки, операции по таким продуктам отражаются напрямую через бухгалтерские проводки, минуя стандартный процесс сопровождения продукта.
Это приводит к тому, что в КХД не фиксируются признаки продукта, его параметры и контекст сделки. Соответственно, продуктовая аналитика и отчетность по таким операциям невозможна, хотя сами проводки в хранилище присутствуют.
В таких случаях поступают следующим образом:
1. Выявляют признаки «ручных» сделок и счетов, оформленных вне продуктового контура. В первую очередь используется текстовое описание/наименование счетов, которое содержит признаки продукта, клиента или цели операции
2. Разрабатывают правила группировки счетов: между собой счета объединяются по маске номера счета, по ключу или по части наименования. Это позволяет восстановить структуру операции и связать счета между собой
3. Собирают дополнительную информацию из внешних справочников и файлов, которая содержит признаки продукта, параметры сделки и назначения счетов
Все вышеперечисленное позволяет строить витрины на основе объединения информации из бухгалтерских проводок, наименований счетов и внешних источников. При этом сохранена возможность аналитики по продуктам даже при отсутствии формализованного сопровождения в АБС. Таким образом, в условиях, когда часть операций проходит вне продуктового контура АБС, требуется обеспечить альтернативные механизмы идентификации продукта и параметров сделки для формирования корректной отчетности. Использование текстового анализа, логических правил группировки счетов и дополнительной справочной информации позволяет обеспечить полноту аналитики и предотвратить потери в отчетных данных.
Кейс № 2. Изменение первичных ключей таблицы в связи с изменением мастер – системы АБС в части счетов.
Для таблицы счетов на детальном слое в хранилище в качестве первичного ключа использовался номер счета. В старой мастер-системе номера счетов имели шестнадцатеричный код с разбиением на четыре блока FFFF:FFFF:FFFF:NNN. Суррогатные ключи в КХД не использовались.
В новой мастер-системе счета имеют стандартный 20-значный числовой формат. Между старой и новой АБС настроена синхронизация счетов, и в новой системе ведется таблица соответствия счетов.
Проблемы:
Т.к. номера счетов выступают в качестве идентификаторов таблицы счетов, а также в качестве идентификатора таблицы договоров, (в формате номер счета + дата заключения договора), то переход на новый формат счета разрушит связанность таблиц по историческим данным. А также не позволит провести расчет остатков и подготовить отчетность МСФО, т.к. проводки, сохраненные в хранилище, имеют старый формат счета.
По условию работы двух АБС (старой и новой) счета, открытые в старой АБС, не переносятся в новую АБС, и все операции по этим счетам ведутся в старой АБС. Поэтому требуется вести параллельную обработку счетов из двух АБС, при этом форматы идентификаторов счетов из двух АБС не совпадают.
Что сделано:
Настроена выгрузка информации по счетам из новой АБС, включая таблицу соответствия новых и старых счетов
Проведен анализ наличия всех необходимых счетов в таблице соответствия и в счетах, имеющихся в хранилище
Выявлено расхождение и недостаток счетов в таблице соответствия. Направлен список расхождений в новую АБС, счета во всех трех системах выправлены (Новая АБС, старая АБС, КХД)
Добавлена таблица суррогатных ключей счетов в КХД, состоящая из полей: автогенерируемый ключ, 20-значный номер счета, номер счета в старом формате
Для таблиц детального слоя, связанных со счетами, добавлено новое поле Суррогатный идентификатор счета. В том числе и для таблицы Операции
Для всех таблиц обновлены исторические данные, проставлены суррогатные ключи
Обновлены алгоритмы расчета витрин отчетности МСФО. Для всех записей проставлены суррогатные ключи и для счетов добавлены 20-значные номера счетов
В калькуляторе расчета резервов переделан расчет на суррогатные ключи счетов
Использование натуральных ключей в корпоративном хранилище данных приводит к проблемам идентификации сущностей, их неоднозначности и пересечению в случае добавления дополнительного источника данных. Поэтому использование суррогатных ключей сущностей в КХД является обязательным.
Кейс номер 3. Добавление функционала исторического пересчета витрин отчетности МСФО.
Проблема:
Витрины отчетов МСФО в КХД рассчитываются каждый день, а итоговые отчеты сдаются раз в месяц, на основе пересчитанных в течении месяца данных. В течении месяца с источника АБС данные могут запаздывать на несколько дней, кроме того, могут приходить корректирующие данные за закрытые периоды, эти все правки должны попасть в итоговой отчет за месяц. Существующая реализация КХД и алгоритмов расчета витрин МСФО этого сделать не позволяла.
Существующая реализация КХД:
1) На детальном слое информация хранится в двух типах историчности SCD1 и SCD2. Причем в формате SCD2 хранятся только данные, имеющие историчность на источнике, такие как: статусы счетов, статусы заявок, этапы обработки и т.д. Основные же сущности (счета, договоры, проводки, и т.д.) и связанная с ними информация хранится в формате SCD1, то есть без сохранения исторических данных. Это, в свою очередь, не позволяет определить актуальность данных на определенную дату, и нет возможности произвести исторический пересчет отчетов
2) Алгоритм расчетов витрин МСФО подразумевает только инкрементальный режим работы без возможности проведения исторических пересчетов данных в случае выявления ошибок и расхождений
3) Не существует механизма сверки итоговых ежемесячных расчетов витрин МСФО с актуальным срезом данных в детальном слое КХД, а за месяц исторические данные могут изменится
Что сделано:
1) На детальном слое все необходимые таблицы переведены в формат хранения историчности SCD2, что, в свою очередь, позволяет однозначно отследить все изменения записи и даты актуальности вносимых изменений
2) На основе отбора исторических данных из детального слоя КХД реализован механизм исторического пересчета витрин МСФО на случай выявления расхождений данных в отчетах и в фактическом учете
3) Реализован механизм сверки результатов расчета денежных потоков (cashflow) отчетов МСФО и базовых витрин КХД, содержащих актуальную информацию по всем сущностям. Выявленные расхождения оперативно доносятся до специалистов отдела отчетов и резервов
Отсутствие хранения исторических данных детального слоя влечет за собой целый ряд проблем, связанных с определением актуальности записи на определённую дату.
Кейс № 4 Проблемы MDM-систем в банке и их влияние на отчетность
Проблема:
В условиях многокомпонентной ИТ-архитектуры банка отсутствие единой системы управления мастер-данными (MDM) приводит к критическим проблемам в отчетности. Разрозненные справочники клиентов, продуктов и договоров в различных системах (АБС, CRM, скоринговых решениях) вызывают дублирование записей, несогласованность атрибутов и, как следствие, ошибки в регуляторной отчетности. Типичные проявления включают отражение одного клиента под разными идентификаторами, вариативные наименования одних и тех же объектов в разных системах, что в итоге приводит к искажению отчетных показателей и риску штрафных санкций со стороны ЦБ.
Для решения проблемы применяется многоэтапный алгоритм.
Первоначально проводится комплексный аудит, включающий инвентаризацию всех источников данных и анализ расхождений в ключевых справочниках
На основании аудита выбираются мастер-системы для различных сущностей (например, АБС для договоров, CRM для клиентов) и разрабатываются правила сопоставления записей
Затем, например, внедряется ETL-процесс регулярной синхронизации данных с использованием суррогатных ключей в КХД, что обеспечивает сквозную идентификацию сущностей независимо от исходной системы
Для обработки сложных кейсов создаются специальные инструменты ручного маппинга и ML-модели для выявления потенциальных дублей по косвенным признакам
Рассмотренные примеры показывают, что тщательное планирование архитектуры КХД позволяет решить множество проблем, ускорить получение актуальных данных и сэкономить операционные расходы заинтересованных сотрудников.
Будущее: Исходные данные как воздух – данные больше не ограничены, они везде и мгновенно доступны
Сегодня банковская отчетность выходит за рамки традиционных хранилищ, превращаясь в динамичную, распределенную систему. Некоторые пытаются освоить облачные технологии, позволяя данным «испаряться» из локальных серверов, становясь частью глобальных аналитических платформ. Но вместе с возможностями появляются и новые вызовы: безопасность, регуляторные ограничения и управление гибридными средами. Банки стоят на пороге новой эры – когда данные не просто текут, а становятся частью цифровой атмосферы.
Главный вызов — не технологический, а организационный: победа достается не банку с самым передовым ПО, а тому, кто сможет навести внутренний порядок в процессах, данных и обеспечить взаимодействие между IT, аналитиками и бизнесом.