Анализ рисков внедрения технологий открытых программных интерфейсов в банковской сфере

DOI:

В статье рассматривается внедрение технологии отрытых программных интерфейсов в банковской сфере. Актуальность исследования обусловлена активной разработкой регулятором концепции модели открытого банкинга [1]. Центральным Банком России готовятся стандарты реализации модели открытого банкинга [2-6], фиксируются приоритетные направления и этапность утверждения их обязательными. Однако, прежде чем переходить к очередному витку цифровой трансформации, необходимо четко сформулировать все сопутствующие риски, степень их значимости и способы минимизации.

На основе анализа реализации технологии открытых API целью исследования является выявление и классификация рисков, которые могут возникнуть во время или после внедрения технологии в российские банки, определение направлений их минимизации.

Задачи исследования: изучить предпосылки цифровой трансформации банковской сферы и переход к технологии открытых API, выявить возможности и классифицировать риски внедрения технологии и направления их минимизации.

Проблема недостаточной проработки рисков внедрения открытых программных интерфейсов в банки является важной и актуальной, поскольку, во-первых, финансовые организации в последнее время подвергаются большому количеству кибератак [7], а значит необходимо тщательно регулировать информационный обмен открытыми финансовыми данными. Во-вторых, с 2024 года Центральный Банк России уже вводит требования к реализации открытого обмена финансовыми данными, в том числе перечень направлений, обязательных к реализации крупными игроками, однако перед внедрением новой технологии банкам необходимо быть в курсе возможных рисков, а также путей их минимизации. Современные научные авторы изучают направления развития технологий и инноваций в банковской сфере [8-11], углубляются в технологию открытых программных интерфейсов [12-13], приводят примеры внедрения в крупные банки [14-15], а также описывают возможности и угрозы концепции открытого банкинга [16-17]. Однако риски на момент написания статьи не были классифицированы и не предложены меры для их сокращения.

ПРЕДПОСЫЛКИ ЦИФРОВОЙ ТРАНСФОРМАЦИИ БАНКОВСКОЙ СФЕРЫ И ПЕРЕХОД К ТЕХНОЛОГИИ ОТКРЫТЫХ API

В последние десятилетия информационные технологии на рынке банковских услуг приобретают все большее влияние и распространение. Если ранее для получения финансовых услуг необходимо было тратить личное время на согласование и подачу заявлений в офисе банка, то сейчас большинство услуг можно оформить и обслуживать, не выходя из дома, воспользовавшись удобным мобильным приложением банка. Особый виток развития дистанционных услуг пришелся на момент пандемии COVID-19, когда путь очного обслуживания клиентов был практически полностью заблокирован, что позволило и, даже можно сказать, вынудило взглянуть на модель обслуживания клиентов под другим углом. Так как клиенты более не могли присутствовать в банках, а значит, получать услуги, департаменты информационных технологий банковских компаний вынуждены были в кратчайшие сроки переориентироваться на развитие и распространение дистанционного обслуживания клиентов. Расширение дистанционных каналов позволило не только удержать клиентов, но и потенциально увеличить уровень дохода банков за счет сокращения затрат на привлечение и обслуживание клиентов. Таким образом, сложившаяся в стране ситуация привела к новому витку цифровой трансформации отрасли.

Цифровая трансформация — это процесс, включающий в себя внедрение различных инновационных технологических решений в деятельность банков, который в корне меняет способы и каналы предоставления услуг клиентам [9].

Что же именно банки предприняли, для того чтобы перестроиться на новую модель обслуживания? Большую роль в цифровой трансформации сыграло внедрение в процессы технологии открытых программных интерфейсов. Несмотря на то, что финансовые данные всегда являлись особо чувствительными, требующими строгой защиты и соблюдения конфиденциальности, в современном мире наблюдается совершенно новый виток трансформации отрасли. Если раньше банки аккумулировали финансовые данные и не предполагали их разглашения другим игрокам рынка [17], то теперь вступила в права новая бизнес-модель открытого банкинга, утвержденная Центральным Банком России, которая, наоборот, обязывает банки постепенно организовывать обмен финансовыми данными с игроками. В Концепции внедрения открытых API на финансовом рынке, разработанной регулятором, описываются ключевые этапы перехода финансового сектора к открытым данным.

API – это интерфейс программы, включающий в себя набор функций или структур, которые обрабатываются приложением и предоставляются клиентам. Фактически, в данном контексте клиентами могут быть как сторонние сервисы, расположенные внутри организации, которым для обеспечения своей функциональности необходимы данные, обрабатываемые другой системой, так и части одной системы, например, фронтальная часть приложения, которой необходимо отображать обрабатываемые системой данные на пользовательском интерфейсе.

API можно классифицировать различными способами. Например, по местоположению пользователя API могут быть внутренними или внешними, по доступности - публичными, партнерскими или приватными, по типу пользователя -фронтальными, мобильными или интеграционными, по типу взаимодействия - RESTful, SOAP или RPC. В данной статье будут рассмотрены только открытые API, целью которых является организация обмена данными между банковскими организациями и третьими лицами при условии наличия согласия клиента.

Открытые API – это программные интерфейсы, публикуемые организациями в соответствии с требованиями Банка России для обеспечения возможности цифрового обмена данными с поставщиками услуг и клиентами в рамках организации и предоставления финансовых услуг [1]. Важным пунктом реализации такого обмена данными является наличие согласия со стороны клиента, которое, к слову, согласно Концепции, клиент может отозвать в любой момент времени. Концепция открытых API наследует решение, принятое в стандарте Открытых банковских интерфейсов, об использовании архитектурного стиля RESTful API в интеграциях систем [4]. RESTful API, в отличие от SOAP и RPC, предстают более гибкими, простыми и понятными к реализации.

Внедрение технологий открытых программных интерфейсов открывает большие возможности перед современными российскими банками. У сервисов появляется возможность интегрировать данные сторонних приложений в свои внутренние процессы, что позволяет предлагать клиентам все новые цифровые продукты и сервисы. Объединение данных о счетах клиентов в своих приложениях позволит пользователям управлять финансами в различных банках по принципу “единого окна”, что повысит удобство для клиентов, сократит время на просмотр сведений о средствах и управление ими, а также предоставит клиентам более выгодные предложения и сэкономит время на запрос и передачу справок и выписок.

Для конечных потребителей внедрение открытых API означает улучшение условий обслуживания и повышение качества сервисов, снижение тарифов, появление таких сервисов, как Daily Banking, которые позволяют работать со своим бюджетом в рамках единого окна, то есть объединять финансовые данные пользователя из различных финансовых организаций. Вполне вероятно, что среда обмена потребительскими данными повлечет более глубокий анализ потребителя и, в свою очередь, более персонифицированные услуги.

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

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

КЛАССИФИКАЦИЯ РИСКОВ ВНЕДРЕНИЯ ТЕХНОЛОГИИ ОТКРЫТЫХ API В БАНКИ

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

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

Открытые API увеличивают зависимость от сторонних провайдеров и ограничивают контроль над данными. У банков могут возникнуть трудности с поддержкой открытых программных интерфейсов, которые заключаются в том, например, что при обновлении API необходимо обновляться и системам-потребителям. Поставщик интерфейса может не уведомить или слишком поздно уведомить об изменениях в интерфейсе, что приведет, в лучшем случае, к незапланированным финансовым затратам на доработку, в худшим – к потере работоспособности систем.

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

С точки зрения безопасности, банковские регуляторы могут устанавливать все более строгие правила и новые ограничения на использование API, что может усложнить процесс внедрения. Неопределенность в отношении будущих изменений в технологиях и стандартах может затруднить долгосрочное планирование и инвестиции банков.

При внедрении открытых API, потребуется обеспечить поиск новых кадров, специализирующихся на технологии, адаптировать сотрудников к технологии, изменить бизнес-процессы, что тоже повлечет финансовые затраты.

Перечисленные риски были сгруппированы по категориям и пронумерованы следующим образом, где Р означает сокращение слова риск, далее следуют номер группы и, через точку, номер риска:

• •    безопасность: кражи и утечки данных (Р1.1), увеличение атак на банки (Р1.2), несанкционированный доступ к API (Р1.3);

• •    разработка: непредоставление или некорректное предоставление данных поставщиком (Р2.1), ошибки при проектировании API (Р2.2), доработка сервиса или интерфейса под интеграцию (Р2.3);

• •    регулирование: выпуск новых стандартов обмена данными через открытые интерфейсы (Р3.1), ужесточение существующих стандартов обмена данными (Р3.2), расхождение внутренних требований к спецификациям (Р3.3) и ИТ-архитектуре (Р3.4);

• •    адаптация: неготовность инфраструктуры внутри компаний (Р4.1), изменение ИТ-архитектуры для внедрения технологии (Р4.2), изменение бизнес-процессов в связи с внедрением технологии (Р4.3), переобучение сотрудников (Р4.4), поиск новых кадров в области API (Р4.5);

• •    сопровождение: некорректная доставка обновлений API потребителям (Р5.1), риск недоступности системы-поставщика API (Р5.2).

Для анализа выявленных рисков была составлена матрица, строки которой отражают вероятность возникновения риска в процентах, столбцы – степень ущерба. Риски, описанные выше, были разнесены по соответствующим ячейкам. Показатели оценены автором самостоятельно, методом анализа существующих научных источников и информационных ресурсов. Наименования рисков в таблице приведены в сокращенном виде для удобства прочтения таблицы.

Таблица 1. Матрица рисков внедрения Открытых API в банки.

Table 1. Risk matrix for implementing Open APIs in banks.

Вероятность				Степень ущерба
возникновения	Низкая	Средняя	Высокая	Очень высокая	Критическая
0-20%% 21-40%% 41-60%% 61-80%% 81-100%%	Р4.1 Р4.2 Р3.1, Р4.3 Р3.2, Р4.4, Р4.5	Р2.3 Р3.3, Р3.4	Р2.1	Р2.2	Р5.1, Р5.2 Р1.1, Р1.3 Р1.2

Из таблицы 1 следует сделать вывод о том, что наиболее критичными рисками для банков при внедрении технологии Открытых API являются риски, связанные с допущением неточностей при разработке открытых программных интерфейсов, недостаточно проработанной системой регулирования безопасности обмена данными и некорректным сопровождением открытых программных интерфейсов. Наиболее вероятными рисками являются неготовность инфраструктуры и ИТ-архитектуры, изменения в законодательной и регулирующей базах, влекущие дорогостоящие доработки, адаптация процессов и сотрудников под новые технологии.

ПУТИ МИНИМИЗАЦИИ РИСКОВ И ДАЛЬНЕЙШИЕ НАПРАВЛЕНИЯ ИССЛЕДОВАНИЯ

Чтобы минимизировать риск допущения неточностей при разработке банковских API, автором предлагается усилить контроль процесса проектирования и дизайна API, например, задействовав инструменты валидации API-контрактов. Инструмент необходимо адаптировать и держать в актуальном состоянии согласно требованиям регулятора к открытым API [1-6]. В качестве примера реализации такого инструмента можно привести разработку ООО «Группы компаний Иннотех» для ПАО ВТБ «Реестр API», который позволяет пользователям проектировать API с использованием встроенного механизма валидации json или yaml спецификации согласно требованиям регулятора и внутреннего департамента информационной безопасности, а также настраивать нефункциональные требования к поставщику и потребителям проектируемого API [18]. Кроме того, автором предлагается задействовать унифицированный автоматизированный инструмент тестирования разработанных API, который позволит выявлять неточности исполнения требований регулятора и принудит устранить их до вывода продукта потребителю. Наиболее эффективной моделью тестирования было бы использование инструмента, разработанного и сопровождаемого самим регулятором.

Создание безопасных условий обмена финансовыми данными посредством технологии API является важным и актуальным направлением в современных условиях, которому должно уделяться особое внимание финансовых организаций. Информационным системам, разрабатывающим API, необходимо в обязательном порядке реализовывать механизмы аутентификации и авторизации запросов, защищать каналы взаимодействия в зависимости от категории данных, а также предпринимать меры для отражения кибератак, следуя рекомендациям и стандартам регулятора [2-6,19].

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

Минимизировать риск некорректного сопровождения открытых API можно внедрением в процессы сопровождения технологий, позволяющих максимально исключить человеческий фактор, такие как автоматизированные инструменты мониторинга, журналирования и аудита. Информационным системам необходимо соблюдать актуальные требования ИТ-архитектуры и надежности для обеспечения георезервирования и отказоустойчивости.

В связи с тем, что в настоящее время ЦБ РФ активно прорабатывает регуляторную базу открытого банкинга, а в правилах уже появляются данные, которыми необходимо на обязательной основе осуществлять обмен, финансовым организациям рекомендуются не игнорировать грядущие изменения в процессах и уже активно планировать изменения в существующей инфраструктуре и ИТ-архитектуре компаний. Кроме того, при планировании изменений важно не забывать о требованиях к импортозамещению оборудования и ПО.

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

ЗАКЛЮЧЕНИЕ

Таким образом, в статье было рассмотрено актуальное направление цифровой трансформации банковской отрасли – переход к модели открытого банкинга за счет внедрения технологии открытых программных интерфейсов. Дано определение API как технологии, описаны типы реализации, выявлены возможности и преимущества внедрения открытых программных интерфейсов в банковские процессы. Затем были выявлены и сгруппированы по категориям риски: безопасность, разработка, регулирование, сопровождение, адаптация. Наиболее критичными группами рисками оказались допущения неточностей при разработке программных интерфейсов, непроработанность системы регулирования и некорректным сопровождением открытых программных интерфейсов. Наиболее вероятными рисками выделены изменения в законодательной и регулирующей базах, адаптация архитектуры, процессов и сотрудников компаний. На основании рассмотренных в статье рисков и мер по их минимизации, в дальнейшем возможно выработать более детализированную концепцию внедрения технологии в российские банки, учитывающую выявленные проблемы и обеспечивающую наиболее качественный процесс трансформации.