Открытые банковские API — абсолютно инженерная практика

Для начала давайте поясним, что такое открытые API и почему банки начали работать с ними?

Екатерина Фроловичева: Банки имеют набор систем внутри себя. Для людей снаружи банк — это крепость, окруженная рвом и «мостиком» к ней, пройти по которому могут только те, кого ждут. При этом в России несколько сотен банков и все они стремятся привлечь клиентов, повысить уровень проникновения продуктов и быстро охватить достаточный объем рынка или найти свою уникальную нишу.

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

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

В какие сроки удалось реализовать проект?

Екатерина Фроловичева: Мы начали проект в октябре 2018 года и завершили первый этап уже через два месяца — в декабре 2018 года.

За счет чего получилось все сделать настолько быстро?

Екатерина Фроловичева: Когда идея только зародилась, у нас практически не было собственных ресурсов для ее реализации — в штате имелся лишь один архитектор и ни одного специалиста по продукту. Мы изучили средства и представленные на рынке продукты для взаимодействия с третьими сторонами через открытые API. Посмотрели на игроков, попавших в квадрант Gartner (Гартнер), описывающий инструменты интеграции и взаимодействия через API. Большинство из них живет в модели облачного gateway (гейтвей), и поэтому мы их пока не рассматривали.

Помимо функциональных и технических характеристик конкретного продукта, для нас не менее важным было наличие компетенции на рынке по практической работе с ним, которую можно внедрить, растиражировать и использовать на регулярной основе. Мы руководствовались целым рядом параметров, а именно: наличие компетенций и опыт реализации требований к enterprise-архитектуре (ентерпрайз-архитектуре) и информационной безопасности, невысокая трудоемкость сопровождения, обеспечение совместимости и обратной совместимости с текущим ландшафтом. Не менее важную роль при выборе системного интегратора играло наличие реализованных проектов. В итоге в качестве платформы для построения решения был выбран продукт IBM API Connect, а его внедрение в банке мы безоговорочно доверили компании «Синимекс».

Какие задачи решал «Синимекс» в этом проекте?

Екатерина Фроловичева: Мы активно взаимодействовали с коллегами из «Синимекс», которые предоставили нам весь спектр специалистов, начиная от аналитики и заканчивая специалистами с глубоким пониманием ИТ-инфраструктуры банка.

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

Как выстраивалась работа с открытыми API и заказчиками?

Екатерина Фроловичева: Очень быстро у нас стали появляться бизнес-заказчики, которых мы не ждали раньше марта 2019 года. Они стремились побыстрее интегрироваться с агрегаторами «Банки.ру» и «Сравни.ру» для запуска заявок на кредитные карты. В марте был доработан сайт банка. Это оказалось хорошей пробой пера для выстраивания end-to-end (сквозного) процесса, в котором каналом выступал сайт ГПБ и имелась система, выдававшая бланк заявки на кредитную карту, и все это мы пропустили через наше решение. Так получилось комплексное решение, а дальше уже пошло по накатанной.

У нас пока нет классической модели работы с открытыми API, позволяющей на портале ознакомиться с правилами, авторизоваться, подключиться, получить подтверждение своей авторизации и начать пользоваться сервисами. Мы под каждую задачу проводим отдельный проект мини-интеграции со всеми вытекающими артефактами. В истории с открытыми API активно участвуют специалисты в области защиты информации, имеющие неоспоримый набор четко соблюдаемых требований. Мы, в свою очередь, выступаем как «оппоненты», прокачавшие навыки в соединении экономики и открытых банковских API. С каждой интеграцией мы идем по пути создания документов, сопровождающих ее. Этот процесс теперь налажен благодаря коллегам из «Синимекс».

С какими сложностями вы столкнулись в процессе подготовки проекта и его запуска?

Екатерина Фроловичева: Самые сложные задачи лежали не в плоскости наличия компетенции, а в преодолении внутренних барьеров и получении акцепта на стороне бизнес-заказчика — требовалось показать, какую конкретную пользу приносят открытые API и какой инструментарий дают.

Ольга Махаёва: С учетом многолетнего опыта работы «Синимекс» с Газпромбанком на старте проекта особых сложностей не возникло — было понятно, что и как нужно делать. Особенного внимания потребовали приемо-сдаточные испытания решения на соответствие требованиям к информационной безопасности: во-первых, сам продукт, на котором построено решение, для банка был новый, во-вторых, решение предназначено для предоставления сервисов, реализованных во внутренних системах банка, во внешний мир, из-за чего к нему предъявляются особенно строгие требования.

Разработанные вами сервисы универсальные, ими могут в будущем пользоваться компании из других секторов?

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

Газпромбанк является учредителем и участником Ассоциации Финансовых Технологий, организованной три года назад под эгидой ЦБ. В ней есть рабочая группа по открытым API, в рамках которой появилась версия концепции развития банковских открытых API на российском рынке. Возникла первая спецификация — запросы остатков по счетам и платежи в пользу физического лица. Если эта история срастется, то банки приведут к единому знаменателю спецификации своих сервисов и выстроят back-end (бэкенд) так, чтобы унифицировать состав таких полей, как применяемая модель данных, размерность, формат и логика. Тогда на рынке появятся универсальные сервисы банковских продуктов.

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

А есть разница в выстраивании работы с компаниями малого, среднего и крупного бизнеса?

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

Как вы обеспечиваете безопасность передаваемых данных?

Ольга Махаёва: Безопасность и защищенность передаваемых данных и самой системы — вопрос особенно актуальный для решений подобного класса. Часть требований, предъявляемых к системе с точки зрения информационной безопасности, покрывалась функционалом продукта IBM API Connect «из коробки». Дополнительно к этому пришлось выполнять настройки системы в соответствии со специфичными требованиями банка и интегрировать ее в уже существующую инфраструктуру систем, обеспечивающих информационную безопасность.

Как вы планируете развивать проект?

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

Екатерина Фроловичева: Сейчас, при переходе на новую версию продукта, важнее всего обеспечить его универсальность. Мы стремимся, чтобы команда, разрабатывающая API как инструмент, оказывала консультационные услуги, а специалисты банка могли сами обеспечивать сопровождение и поддержку. Главное, чтобы инструмент был максимально богатым и понятным для команд, обслуживающих продуктовые фабрики. Тогда дело пойдет как по накатанной. Мы планируем сделать так, чтобы процесс подключения через API работал по шаблону в том числе и для службы безопасности — тогда каждый проект не будет изучаться через двойные линзы. В идеале хотелось бы видеть единый сервисный портал, который позволит не держать на каждую интеграцию свою архитектуру и каждый раз проходить все с нуля. Как в облаке можно собирать образ системы, так же должна быть отстроена работа с API. Ведь открытые API — это абсолютно инженерная практика.