Риск — дело плодородное: помогаем банку анализировать риски и зарабатывать на них

Привет, Хабр. Меня зовут Максим Мишута, и я расскажу вам про «Платформу исследования рисков». Это проект, реализованный «Иннотехом» для банка ВТБ, я в нём участвовал в роли IT-менеджера.

Хороший специалист обязан быть увлечён своим проектом. Я постараюсь также быть хорошим рассказчиком и увлечь этим проектом вас. Если зайдёте под кат, сможете узнать следующие любопытные (надеюсь) вещи:

• что вообще происходит с IT-инфраструктурой ВТБ;

• как банки зарабатывают на рисках;

• что такое «Платформа исследования рисков»;

• как мы её разрабатывали;

• почему это не было легко.

Глобальная трансформация ВТБ

«Глобальная трансформация» — это очень модное словосочетание в последние несколько лет. Многие крупные компании приходят к мысли о необходимости масштабных изменений. Чаще всего эти изменения связаны с модернизацией IT-инфраструктуры, но это лишь средство. Цель — модернизация процессов.

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

«Платформа исследования рисков» (далее — RRP, Risk Research Platform) относится к программе «Модернизация платформы данных», запущенной в 2020 году. Эта программа призвана переосмыслить и качественно улучшить источники данных для IT-систем банка, сделать их максимально доступными, надёжными и консистентными.

Торговля рисками

«Риски» звучит, как что-то плохое. Как банку удаётся на них зарабатывать? Если удариться в философию, можно сказать, что риск — обратная сторона ценности. У вас есть деньги? Есть риск, что их могут украсть. Поэтому вы несёте деньги в банк. Банк берёт на себя ваш риск, но при этом он также получает и выгоду: может пустить вклад «в рост». При этом риск для банка меньше, чем для простого человека, а выгоду он умеет извлекать более эффективно.

Это максимально упрощённый пример, но он показывает суть. Риск и выгода везде идут рука об руку. Банк выдаёт кредит? Есть риск, что заёмщик не сможет или не захочет по нему расплатиться. Банк принимает этот риск, но взамен получает выгоду — процент по кредиту. Банк обменивает одну валюту на другую? Существует риск, что курс изменится в невыгодную сторону, и, чтобы получить свою выгоду, банк берёт комиссию за обмен. Любое движение средств — это также сопутствующее движение рисков.

С рисками имеют дело все. Если так задуматься, спустить всю получку в игральных автоматах — это тоже в каком-то роде риск-менеджмент, но крайне не эффективный. Банк отличается тем, что работает с рисками профессионально, на основании тщательного и трезвого расчёта.

Это не значит, конечно, что банк никогда не проигрывает. Порой проигрывает, да ещё как: Lehman Brothers или Barings Bank с грустью это подтвердят. Однако также банк хорошо умеет делать выводы из своих и чужих ошибок. А на случай, если он выводы делать не хочет, существуют рекомендации Базельского комитета. Можно сказать, что эти рекомендации написаны кровью: обычно они обновляются после очередного мирового экономического кризиса и направлены на то, чтобы не допустить его повторения.

По сути, Базельские рекомендации стимулируют развитие культуры управления рисками. Они запрещают банкам чрезмерно рискованные виды финансового поведения. Например, в них есть требования к уставному банковскому капиталу и его ликвидности. Грубо говоря, это не даёт банку слишком заиграться в финансовые инструменты и потерять намного больше средств, чем у него есть.

Так что же такое RRP?

Чтобы управлять рисками, в первую очередь необходимо их анализировать. А для анализа нужны данные, крайне желательно — качественные.

Наверное, каждому знакомо если и не понятие, то ощущение «предельной сложности». Например, когда при ведении бизнеса уже не хватает экселевской таблички и приходится заводить CRM-систему. Или когда в разработке программного продукта вдруг понимаешь, что пора разбить монолит на микросервисы. У банков также случается момент «предельной сложности», когда работа с данными становится запутанной, хаотичной, и хочется как-то её унифицировать.

Крупный банк — это живой организм, который растёт и меняется, и вместе с ним растут и меняются источники его данных. Слияния и поглощения, изменения в IT-инфраструктуре — всё это приводит к тому, что у банка оказывается одновременно несколько источников, которые могут иметь разные форматы, разную степень достоверности и т. д. Нетрудно представить, в какой ад может превратиться анализ рисков при таком раскладе.

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

Как это работает

В рамках проекта нам нужно было создать промышленные регулярные процессы по доставке данных систем-источников в единое место, по очистке данных, проверке данных на консистентность, непротиворечивость и соответствие данных разных источников в разрезе исследуемой сущности (клиента, контракта и прочее). Также нам нужен был слой витрин, с которым будут работать аналитики и который можно использовать как источник для разных подразделений. Витрины данных — это логическое объединение специально созданных таблиц и представлений для решения определённых утилитарных задач.

В проект мы заложили следующее изменение тракта данных, чтобы отсечь львиную долю ручного труда: первоначальные процессы подготовки данных с использованием труда аналитиков (as is) мы подменили на процессы промышленной подготовки данных (to be).

На момент начала проекта у нас сложился IT-ландшафт, схематично изображённый ниже. По каждому направлению анализа рисков существует свой источник: данные по кредитному, по рыночному риску, по резервам… Отдельно существует большой RDM-источник (Reference Data Management, управление справочными данными). Каждая система-источник предоставляет свою витрину данных. Отдельно существует автоматизированная система для работы с этими витринами. Система развернута на базовом функционале SAS, что позволяет пользователям выстраивать сложные аналитические процессы и формировать витрины, необходимые для расчёта риск-метрик и отчётности.

Но эти процессы нельзя назвать промышленными: они не отвечают критериям регулярности, надёжности, масштабируемости, отсутствует релизная политика. Также везде присутствует человеческий фактор, а, как известно, причина 90% ошибок находится между креслом и монитором. Теоретически эту SAS-систему можно было допилить до состояния промышленной. Однако программа «Модернизация платформы данных» ставила перед нами более глобальную цель: внедрение общих стандартов для процессов получения данных из источников. Так появилось озеро данных.

Наша область RRP выделена в область витрины DRP, поскольку предоставляет данные непосредственно бизнес-пользователям. Для озера же RRP занимает лишь небольшой финальный кусочек общего пространства данных.

На первом этапе мы сделали репликацию данных источников на промышленном движке озера данных. Причём сделали это два раза. Первые процессы по репликации реализовали на EFW (ETL Framework: sqoop/jdbc + ObjectDispatcher/CaptureDispatcher), но озеро не стоит на месте и переехало на движок Spark Airflow (Apache Spark — ETL, Airflow — оркестратор), так что итоговую репликацию мы сделали на Spark Airflow. По своей сути репликация — это механизмы запуска SQL-запросов, оптимизированные под Impala, которую регулярно запускает Spark Airflow.

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

Вторым этапом мы сделали кросc-сверки. Кросc-сверка — комплекс запросов по загруженным данным из источников, которые проверяют данные по параметрам. Главным на данном этапе было разработать и запрограммировать логику кросc-сверок. Здесь мы тесно сотрудничали с аналитиками заказчика. Аналитики помогли нам с логикой, и они же работают с результатами проверок, сохранёнными в виде таблиц. Изучение этих результатов позволяет им лучше понять, как движутся данные.

Третьим этапом мы реализовали аналитические витрины. Витрины разного назначения: для риск-аналитиков, для построения отчётов, для предоставления данных другим подразделениям банка.

Доступ к витринам осуществляется с помощью инструмента Hadoop Hue (тонкий клиент), DBeaver. Из самого интересного — это отчёт по AQR (оценка качества активов) и витрина расчёта риск-показателей для RORAC (рентабельность капитала, скорректированного на риск).

Логика отчётов — это полноценная story по Agile. Именно так мы её и сдавали: по кусочкам. Сделали совместно с заказчиком логику, защитили её. Отработали на прототипе и перед заказчиком же защищали прототип. Только после этого выкатили в прод. Впрочем, это не конец пути, лишь очередной этап: дальше отчёты будут дорабатываться с учётом опыта их использования заказчиком.

Четвёртым этапом стала реализация глоссария данных. Нумерация условна: мы занимались этим параллельно с другими задачами. Глоссарий — очень полезный инструмент для аналитиков, работающих с моделированием, data mining, отчётностью, аудитом и т. п., поскольку позволяет понять входные данные и повышает прозрачность всего процесса расчёта.

В рамках системы Informatica Axon мы описывали входные данные источников. Основной объём информации брали из самих источников, их метаданных, но также многое восстанавливали, опускаясь на уровень учётных систем и документации. Это была кропотливая ручная работа.

Наш проект длился примерно год. На выходе мы получили новые тракты данных, существенно изменяющие IT-ландшафт.

Мы многого достигли, но ещё более важно то, чего можем достичь в дальнейшем. На базе архитектуры RRP будет легче наращивать количество источников данных, развивать аналитический слой витрин. В IT есть такое понятие, как технический долг — так вот, у нас эдакий технический долг наоборот, что-то, что облегчает дальнейшую разработку и поддержку. Также RRP позволяет увеличить автоматизацию и качество тракта данных рисков, что, безусловно, повышает внутреннюю культуру по управлению рисками.

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

Что могло пойти не так

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

Проект RRP зарождался, когда ВТБ жил по водопадной модели разработки. Под эту модель были заточены архитектурные документы, интеграционные карты, бизнес-требования, функциональные спецификации. Когда же проект открылся, банк почти без разбега прыгнул в Agile. Поменялось всё: структуры подразделений, роли, процессы взаимодействия и т. д. Но главное для нас — изменились и продолжали изменяться требования к документам. Все учились и набивали шишки, получали новые опыт и вводные. Так что комплект обязательной документации пережил 14 этапов согласований. И это было очень критично, поскольку без документов мы не могли получить доступы для разработчиков, а также открыть доступы для интеграций. Процесс сдвинулся, когда на уровне программы появился директор-координатор технологических проектов и взял эту боль на себя.

Ещё одним сюрпризом стала смена движка репликации. Руководители разогнали банк так, что некоторые процессы пошли быстрее, чем ожидалось. Под самый Новый год, 27 декабря, озеро данных получило новый движок. Мы же в это время завершали тестирование первого релиза на старом движке, поэтому не уследили. Так что после новогодних каникул вся команда, скажем так, очень удивилась, а менеджерам пришлось оперативно переделывать план проекта.

На этом фоне пандемия повлияла существенно меньше: как только команды научились удалённо работать (а для «Иннотеха» удалённая работа команд — это естественный процесс, ведь сама компания была создана в пандемию), проект быстро вошёл в график. Возникли некоторые трудности, когда учились удалённо собирать и выводить первый релиз, но мы быстро их преодолели.

Спасибо, что дочитали эту статью. Надеюсь, что оказался хорошим рассказчиком и вам было интересно.

Буду рад, если оцените наш проект на портале Global CIO. Оставляйте ваши вопросы/комментарии, с удовольствием на них отвечу.