RegTech. Как новая архитектура взаимодействия банков и регулятора меняет подход к данным
RegTech — это прежде всего архитектурный ответ на упомянутый разрыв. Речь идет не об автоматизации отчетности, а о фундаментальной перестройке того, как банк управляет данными как стратегическим активом.
Почему существующая архитектура перестает работать
Большинство банков сегодня работают в том, что можно назвать «отчетной» архитектурой данных. Отчеты формируются из разных систем, каждая из которых живет по собственным правилам. Бизнес-правила расчета показателей распределены между десятками ETL-процессов (ETL, Extract, Transform, Load – ключевой процесс интеграции данных), и никто не может с уверенностью сказать, какое правило является эталонным. Ручные корректировки при подготовке отчетности — не исключение, а норма.
Последствия этого системного устройства хорошо известны практикам. Один и тот же показатель — например, просроченная задолженность — может давать три разных значения в кредитном модуле, бухгалтерии и DWH, потому что каждая система применяет собственную методологию расчета. Отчеты нельзя воспроизвести из первичных данных, потому что между источником и итоговой цифрой есть ручные правки, о которых никто уже давно не помнит. Регулятор приходит с вопросом об источнике конкретного числа — и банк не может дать ответ за разумное время.
Deutsche Bank заплатил 150 млн долларов штрафа регуляторам США не за мошенничество — за качество регуляторной отчетности. Плохие данные стоят дорого.
Международный стандарт BCBS 239, устанавливающий требования к агрегации данных о рисках и регуляторной отчетности, был введен в 2013 году. Более десяти лет спустя большинство банков по-прежнему не соответствуют ему в полной мере. Это не вопрос желания — это вопрос архитектуры, которую нельзя починить точечными мерами.
RegTech как архитектурный переход
RegTech в широком смысле — это переход от отчетной архитектуры к управляемой архитектуре данных. Суть перехода можно описать через пять изменений, которые происходят одновременно.
Первое — переход от разных источников к единой модели данных. Вместо того чтобы каждая система формировала отчеты по-своему, создается единый слой данных — с централизованными определениями атрибутов, едиными справочниками и общей логикой расчета показателей.
Второе изменение — переход от распределенных правил к централизованным расчетам. Бизнес-правила перестают жить в разных ETL-процессах и переносятся в единый регуляторный data layer поверх DWH. Одно правило — один результат для всех отчетов.
Третье — переход от отсутствия lineage к полной прослеживаемости. Каждый показатель в регуляторном отчете должен быть прослежен до первоисточника автоматически — через технический, атрибутивный и transformation lineage. Это не документация ради документации, это инструмент защиты при аудите.
Четвертое изменение — от ручных корректировок к certification layer. Перед публикацией каждого отчета данные проходят формализованный процесс сертификации: автоматические DQ-проверки, подтверждение lineage, бизнес-контроль и финальная виза Data Owner.
Пятое — переход от отчетов из систем к управляемой отчетности из DWH. Вся регуляторная отчетность формируется из хранилища данных — никогда напрямую из операционных систем. Это единственный способ обеспечить воспроизводимость и единообразие.
Архитектура: как это устроено на практике
Целевая архитектура RegTech строится на принципе централизации: операционные системы банка остаются неизменными, над ними выстраивается трехуровневое хранилище (ODS — DDS — DM), а поверх витрин формируется регуляторный data layer — специализированный слой, в котором централизованы все бизнес-правила расчёта регуляторных показателей. Именно здесь происходит унификация методологий, устраняющая расхождения между разными системами банка.
На вершине архитектуры — KPI-слой с регуляторными показателями, готовыми к публикации. Вся отчетность формируется из него автоматически. Никогда — напрямую из операционных систем. Это единственный способ обеспечить воспроизводимость и единообразие показателей.
Параллельно с технической частью выстраивается Data Governance. Без нее архитектура не работает: можно построить идеальное хранилище, но, если у атрибутов нет владельцев, нет единых определений и нет процесса управления изменениями — качество данных деградирует под давлением операционной реальности.
Data Governance: операционная модель, а не методология
Data Governance в контексте RegTech — это не набор политик, а операционная модель управления регуляторными данными, которая работает ежедневно. На практике именно ее отсутствие чаще всего становится причиной провала трансформации.
Data Owners — бизнес-лидеры, несущие персональную ответственность за корректность данных в своих доменах. Не IT, не CDO Office — именно бизнес. Без этого данные остаются «ничьими», и любой вопрос регулятора превращается в расследование без ответственного.
Business Glossary — единый словарь терминов, утвержденный всеми департаментами. Именно расхождение в определениях — когда кредитный аналитик, бухгалтер и аналитик DWH понимают «просроченную задолженность» по-разному — является источником большинства регуляторных инцидентов. По оценкам Accenture, в 85% случаев причина таких инцидентов в банках — не технический сбой, а ошибки в данных и отсутствие единых определений.
Certification Layer — обязательный этап перед публикацией отчетности: автоматическая проверка качества данных, подтверждение lineage, бизнес-контроль соответствия расчетов и финальное подтверждение Data Owner. Без прохождения всех четырех шагов отчет не публикуется.
Классификация данных: риск-ориентированный подход
Не все данные требуют одинакового уровня контроля. Попытка применить максимальные требования ко всему приводит к операционному параличу. Эффективная система RegTech строится на риск-ориентированной классификации трех уровней.
Критические надзорные данные, влияющие на регуляторные нормативы, требуют полного lineage, обязательной сертификации и SLA в один день. Значимые финансовые данные — базовых DQ-проверок, частичного lineage и SLA до трех дней. Вспомогательные данные — базового мониторинга с SLA до пяти дней.
Аналогичная логика применяется на уровне атрибутов: регуляторные атрибуты первого типа требуют полного lineage, reconciliation и строгих DQ-правил; расчетные — умеренного контроля; справочные — базового мониторинга. Такой подход позволяет концентрировать ресурсы там, где это действительно важно.
Организационные барьеры: где буксует трансформация
Технологическая часть RegTech-трансформации, как правило, решаема. Сложнее — организационная. Практика показывает, что именно здесь большинство проектов теряют темп.
Первый барьер — размытая ответственность. Данные воспринимаются как «общий ресурс», конкретных владельцев нет, и когда возникает вопрос о качестве атрибута, начинается многоуровневое выяснение того, кто за это отвечает.
Второй — разрыв между бизнесом и ИТ. ИТ-специалисты не понимают бизнес-контекст полей. Бизнес не осознает технических ограничений систем. Без выстроенного взаимодействия governance не работает.
Третий — сопротивление переходу от ручного контроля к автоматизированному. Люди, годами применявшие ручные корректировки, воспринимают автоматизацию как угрозу — потому что она делает проблемы данных видимыми.
Трансформация RegTech буксует не из-за технологий, а из-за людей и процессов. Успех требует устранения разрывов в ответственности, коммуникации и операционных моделях.
Эти барьеры не уникальны для RegTech — они характерны для любой data-трансформации. Но в регуляторном контексте цена их игнорирования выше: на кону не только операционная эффективность, но и отношения с надзорным органом.
Выводы: что подтверждается практикой
Опыт реализации RegTech-трансформаций позволяет сформулировать несколько устойчивых наблюдений.
· Архитектуру нельзя обойти. Нельзя внедрить новые регуляторные требования на старом фундаменте — можно только временно замаскировать проблему. Трансформация начинается с архитектурного решения, а не с автоматизации существующих процессов.
· DWH — необходимое, но недостаточное условие. Само хранилище данных не гарантирует готовности к регуляторным проверкам. Без Governance, Lineage и Certification Layer оно остается просто еще одной системой с данными.
· Без ответственного владельца данные не будут качественными. Data Ownership — это не формальная роль в оргструктуре, а операционный механизм обеспечения качества. Именно он определяет, кто отвечает за данные в момент, когда регулятор задаёт вопрос.
· Настоящую защиту при аудите дает только атрибутивный lineage. Не технический, не агрегированный — именно атрибутивный, позволяющий проследить конкретное поле в отчете до конкретного поля в системе-источнике.
· Централизация расчетов исключает расхождения. Единые правила в одном месте — единственный способ гарантировать, что один и тот же показатель будет одинаковым во всех отчетах банка.
RegTech — это не проект, у которого есть дата окончания. Это операционная модель управления данными, которая работает постоянно. Банки, выстраивающие ее сегодня, получают не только соответствие регуляторным требованиям — они получают данные как реальный актив, на основе которого можно принимать управленческие решения. Те, кто откладывает — продолжают тратить ресурсы на ручную работу, которая каждый отчетный период воспроизводит одни и те же проблемы.
