Банковское обозрение (Б.О принт, BestPractice-онлайн (40 кейсов в год) + доступ к архиву FinLegal-онлайн)
FinLegal ( FinLegal (раз в полугодие) принт и онлайн (60 кейсов в год) + доступ к архиву (БанкНадзор)
Опытом создания решений Open Banking на базе популярной интеграционной платформы WSO2 в интервью «Б.О» поделился Сергей Старовойтенков, ведущий архитектор интеграционных решений компании EmDev
— Сергей, российский мегарегулятор пока не требует от банков открыть доступ к данным, как это произошло в Европе и других странах. Тем не менее многие банки уже занимаются внедрением Open API или по крайней мере задумываются об этом. Какие технические и организационные вопросы возникают у банка в этой связи?
— Первое, нужно добиться понимания принципиального перехода от момента, когда у тебя нет Open API, к тому состоянию, когда он появляется. Переход заключается в том, что банк должен предоставить доступ к данным на некоторой основе, не ограниченной его собственными приложениями. Конечно, это не полностью открытый интерфейс, но с доступом к чувствительным клиентским данным. В свою очередь, эволюция к полноценному open banking подразумевает эволюцию в понимании, что счета, транзакционные данные и прочее — это собственность пользователя. Это такой идеологический рубеж, который надо будет преодолеть.
Один из приоритетных вопросов — это, конечно, инфраструктура доступа. Когда банк выпускает свое собственное приложение, оно получает ограниченный доступ к некому ограниченному объему данных. Обычно используется защищенный канал, через который приложение обращается к определенной системе. В парадигме open banking внешние вызовы поступают из разных мест, и по факту придется открывать возможность вызовов извне банковской системы. Сейчас в банках зачастую вызовы из DMZ, демилитаризованной зоны, в private-зону просто закрыты в соответствии с политикой безопасности. Можно находить какие-то технологические решения, но прежде всего нужно смириться с тем, что такие внешние вызовы приемлемы.
Следующий момент, с которым предстоит столкнуться, — собственно работа с данными, то есть необходимость оперировать ими и предоставлять «наружу» данные корректные и полные. Для этого нужно понимать, где хранятся эти данные и как они между собой связаны. Довольно редкая ситуация, когда все данные находятся в одной backend-системе. Чаще данные разнесены по разным системам, причем они несинхронизированы и вообще плохо связаны между собой.
Возникает понимание необходимости интеграционного слоя над такими системами, который может эти данные консолидировать и отдавать «наружу». Вообще, сейчас интеграционные проекты, не только в банковской сфере, стали набирать обороты. Даже без привязки к open banking финансовые и другие компании начинают заниматься интеграцией. Появился запрос на витрины данных, поддержку совместной работы — элементарно, чтобы информация, внесенная в одной системе, корректно отображалась в другой. Такие интеграционные проекты создают базис и позволяют двигаться дальше — по крайней мере, мы начинаем представлять, где находятся необходимые данные.
Аспект безопасности столь же значим, как управление интерфейсами API. Как правило, в банке уже есть какая-то система identity-менеджмента, которую можно задействовать и для Open API. Однако при работе с открытыми интерфейсами дополнительно появляется, например, необходимость управления согласием пользователя. То есть каким сторонним организациям, приложениям он разрешил доступ, и к каким именно данным. Далее, у клиента должна быть возможность это согласие не только дать, но и отозвать или продлить — желательно каким-то простым способом. Соответственно у службы поддержки банка должны появиться понятные способы управлять согласием пользователя — по звонку или еще как-то.
Дальше — вопросы аутентификации, тоже достаточно широкий пласт. Под эти задачи у банка могут использоваться специализированные продукты, или же эта функциональность может поставляться в составе комплексного решения. Сейчас общепринято использовать мультифакторную, out-of-band аутентификацию. Даже если используется одно устройство, то для разных факторов задействуются разные каналы. Например, первый фактор — логин-пароль, второй — звонок в банк с зарегистрированного номера, или с распознаванием голоса, или подтверждением по QR-коду.
— Вы ничего не сказали непосредственно про API-менеджмент, то есть функционал создания и конфигурации интерфейсов, их оркестрации с core-системами. Это подразумевается или это не самая сложная часть такого решения?
— Получается, что действительно это не самая сложная, по крайней мере, достаточно понятная часть. Как таковые решения по API-менеджменту существуют — вы можете использовать хоть WSO2 API Manager, хоть Apigee, 3scale — что угодно. Но стратегически осмыслив задачу создания платформы open banking, можно сделать вывод, что более важна совокупность продуктов, работающих вместе и покрывающих все функциональное поле, о котором я говорил ранее.
— То есть внедрение Open API — это в большей степени интеграционные проекты, где EmDev как компания-интегратор глубоко вникает в архитектуру IT и бизнес-процессов и закрывает комплекс этих вопросов?
— Да, пожалуй, по сути, это именно интеграционные проекты. Просто установить API-менеджер, сконфигурировать аctive directory, завести внешних пользователей и заявить, что теперь у нас есть open banking, нельзя. Эта ситуация будет так же далека от open banking, как и без приложения API-менеджера. Да, конечно, управление API — важная часть, она столь же значима, как безопасность или аутентификация. Здесь нельзя сказать, что что-то важнее другого, это одинаково важные элементы; например, в стандартах Open API, которые выпускаются по всему миру, одинаковое внимание уделяется и тем, и другим аспектам.
— Можете ли вы описать некий типовой подход или типовую архитектуру решения Open API? С чем вы приходите на проект, что интегрируете, какой функционал и какие возможности появляются у банка на выходе?
Управление API столь же значимо, как безопасность или аутентификация
— В первую очередь мы понимаем, с чем мы должны взаимодействовать снаружи. Бывает, что внешняя площадка предоставляет свой API, бывает, наоборот, что сторонний сервис только запрашивает данные, то есть банк, со своей стороны, должен предоставить API, к которому он будет обращаться. Есть варианты, когда связь двунаправленная, то есть вызовы может делать и банк, и сторонний сервис. Архитектурно — как правило, снаружи закрытой банковской инфраструктуры устанавливается система API-менеджмента. Смотрим по требованиям к проекту, что еще может быть необходимо. Например, некоторые площадки не могли работать по авторизации OAuth. Пришлось использовать дополнительные технологические решения, например ставить перед API-менеджером прокси, который реализует необходимую схему аутентификации.
Дальше уже начинаем погружаться в содержательную часть задачи: какие данные и для чего нужно предоставлять, по каким вызовам работать и так далее. Часто здесь начинаются приключения — например, каких-то данных может в принципе не быть в системах. У нас был проект, когда бэковые системы дорабатывались параллельно с интеграцией с внешними сервисами. Либо же данные могут быть, но системы замкнутые внутри, к ним штатным образом не добраться, поэтому нужно создавать какую-то обвязку, чтобы с ними взаимодействовать.
Работа, связанная с созданием этого интеграционного слоя, обычно наиболее напряженная. Как раз на этом этапе решаются вопросы обработки ошибок, действий в случае недоступности системы, гарантированной доставки и т.д. В случае WSO2 для этого есть отдельный продукт — Enterprise Integrator, достаточно эффективное решение для интеграции разнородных IT-систем с поддержкой широкого набора протоколов и готовых коннекторов.
Компания EmDev, основанная в 2005 году, изначально занималась заказной разработкой. С 2011 года команда сосредоточилась на портальных решениях на платформе Liferay, став первым официальным партнером платформы в России.
С 2015 года EmDev активно развивает интеграционное направление на базе продуктов open source. Компания является партнером таких глобальных лидеров, как Google, Red Hat и WSO2. Успехи EmDev отмечены несколькими партнерскими наградами, в том числе Emerging Partner of the Year (WSO2, 2019 г.).
Компания предоставляет своим клиентам консалтинговые услуги, техническую аналитику и аудит, разработку, внедрение и поддержку программных решений с фокусом на сложные интеграционные проекты. В портфолио EmDev — десятки успешных кейсов, в том числе связанных с реализацией Open API в финансовой сфере.
Сфера Open API в российском банкинге развивается «снизу», за счет появления новых кейсов использования API для взаимодействия между банками и партнерами. Созданием правил игры неспешно занимается не столько регулятор, сколько отраслевая Ассоциация Финтех. Сойдутся ли эти векторы в единой точке, создав революционную ситуацию для Open Banking в России?
Открытый банкинг «драйвит» индустрию. Он помогает финансовым организациям экспериментировать и находить новые бизнес-модели, создавать необычные продукты, выстраивать неочевидные, на первый взгляд, партнерства. Это подтверждает опыт рынков (той же Великобритании), которые инвестируют серьезные ресурсы в создание инфраструктуры для развития банковских Open API
Вопросы поддержки стартапов обсудили генеральный директор компании Mplace Вячеслав Семенихин и исполнительный директор Центра экспертизы и коммерциализации фонда «Сколково» Павел Новиков. Этой беседой мы начинаем серию статей об инновациях в России, их роли, о мерах поддержки, о том, где и как искать деньги на развитие инновационных проектов и о том, на что смотрят институты развития и инвесторы
Онлайн-обучение в школе проходят студенты из Донецкого национального технического университета, Азовского государственного педагогического университета, Херсонского технического университета, а также колледжа при Луганском государственном аграрном университете им. Ворошилова