Применение открытых API в банках: вызовы и перспективы — odnoklassniki-jl.ru

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

Содержание статьи

    1 Ситуация на финансовом рынке. Что такое API и Open Banking2 Трансформация API3 Внедрение API в России4 Стандартизация API5 Реализация API-модели6 Составляющие успешного внедрения

Ситуация на финансовом рынке. Что такое API и Open Banking

Open Banking – концепция, в основе которой лежит использование API (application programming interface – англ.) – программного интерфейса из набора готовых функций или структур, которые предоставляются приложением, сервисом или другой системой. Открытые API – это общедоступный набор программных инструментов, который позволяет наладить взаимодействие между приложениями как внутри банка, так и снаружи (Рис. 1).

Описание API может включать тип API REST, SOAP, транспортный протокол HTTP(S), MQ, формат данных JSON, XML, WS-*, безопасность SAML, OAuth 2.0.

API могут быть частными, партнерскими, публичными.

Open Banking Platform – это бизнес-платформа, которая позволяет подробно конструктору LEGO бесшовно интегрировать приложения и сервисы, предоставляя их своим клиентам. У банков уникальные условия для запуска платформы, поскольку они имеют связывать различные сегменты клиентской аудитории, а тем самым создавать дополнительную стоимость (Рис.3).

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

Для чего нужна платформа управления API:

Предоставление API:

    Предоставление документации;
    Регистрация в системе менеджмента API владельца (портал разработчиков);
    Возможность тестирования;
    Статистика использования;
    Разделение сред между разработчиками.

Создание API:

    Проектирование API;
    Изоляция среды;
    Защита от угроз;
    Трансформация форматов данных;
    Интеграция с backend сервисами;
    Интеграция в цикл T&D;
    Фреймворки безопасности;
    Управление версионностью.

Трансформация API

Разработчики давно старались упростить архитектуру взаимодействия между системами. Таком образом, произошло вытеснение де-факто стандарта предоставления API сторонней системе SOAP простым архитектурным соглашением REST, базирующимся на повсеместном HTTP. REST появился в 2000 году и довольно быстро завоевал популярность у разработчиков, однако, и он не решал другую проблему взаимодействия систем, а именно необходимость документирования API. В каждом частном случае разработчикам-владельцам API приходилось почти вручную писать документацию на свои сервисы, а разработчикам-потребителям изучать ее. Появление в 2010 году спецификации документирования REST сервисов Open API дало толчок эффективному решению проблемы взаимодействия владельцев и потребителей API. Существенно сократились временные и производственные затраты на подключение систем, документированных по спецификации Open API.

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

Открытые API становятся каналом, который позволяет осуществить взаимодействие между банком и внешним миром, монетизировать сервисы банка путем прямой или косвенной продажи этих сервисов сторонним партнерским организациям. С помощью этой технологии сторонние компании могут предложить сложенные, как конструктор, приложения, состоящие из сервисов банка. Таким образом, концепция открытых API в банковской сфере превращается в Open Banking.

Если смотреть шире, на страны и регионы, Open Banking используется для построения систем и сервисов, дистрибуции продуктов, использования интерфейсов, анализа продуктов и т.п.

В мире концепция Open Banking является достаточно зрелой. Можно выделить два основных подхода к созданию, регулированию и реализации. Это рыночный подход, когда финансовые регуляторы не форсируют внедрение Open Banking, а участники рынка воспринимают эту систему как возможность дополнительного заработка. Такая ситуация сложилась в США и Канаде, в Новой Зеландии, в Китае, Сингапуре, Шри-Ланке, Швейцарии, Турции, ОАЭ. Второй подход – когда регулятор (например, Центральный банк) выпускает законодательные акты, нормативы, которые обязуют участников рынка предоставлять и открывать доступ к своим сервисам. Примером такого регулирования является обязательство открывать доступ к нескольким определенным сервисам, инициировать платежные транзакции внутри банка и т.п. Такой подход применяется в Австралии, Бразилии, странах Европы, в Индии, Японии, Великобритании.

Внедрение API в России

На протяжении нескольких лет отечественный рынок оставался в стороне от внедрения Open API. Но в августе 2019 под эгидой Центрального банка РФ прошло заседание, на котором была представлена «дорожная карта» развития API для локального рынка. Планируется, что площадкой для внедрения пилотных проектов станет Ассоциация финансовых технологий. С внедрением API вырастут качество и уровень безопасности банковских услуг. Ожидается, что к первому кварталу 2021 года Центральный банк представит набор нормативов, которые будут определять обязанности и сроки предоставления API. Предпосылками для развития Open Banking являются цифровизация, повсеместное внедрение и развитие дистанционного обслуживания, новое поколение клиентов с выросшими ожиданиями по использованию мобильных приложений.

Пилотное внедрение API проходит на территории Евразийского Экономического Сообщества. Для этого участниками ЕЭС было выбрано по нескольку банков (в России – 5). Цель пилота – апробация и отработка методологии между участниками рынка.

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

Стандартизация API

Согласно исследованию Open Banking Monitor, технология API развивается с точки зрения открытости, количества данных и т.п. Банки используют платформы для централизованного использования API и предоставления к ним доступа.

Центральный банк выделяет несколько типов открытых API:

    Коммерческие;
    Инфраструктурные (СБП, «Маркетплейс», ЕБС, «Цифровой профиль», «Мастерчейн»);
    Регуляторные (отчетность, API для федеральных органов исполнительной власти).

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

Реализация API-модели

Согласно статистике за 2019 г. (Рис. 4), банки активно развивают свои API-модели.

Реализация платформы API от RAMAX Group позволить ускорить процесс создания API и сделать их использование более прозрачным и безопасным.

Какие же по сути преимущества дает использование централизованной платформы менеджмента API?

Здесь следует учесть, что, помимо разработки самих сервисов, которые представляют собой ценность для клиентов, необходимо еще обеспечить безопасность, прозрачность и управление жизненным циклом этих сервисов. Кроме того, имеет важное значение снижение порога вхождения для потенциальных потребителей API. Чтобы проиллюстрировать эти аспекты представим, что некая компания «А» хочет монетизировать некие сервисы, а компании «B» и «С» являются их потенциальными потребителями. При этом, компания «B» хочет использовать сервис по периодической подписке, так как у нее есть предсказуемый годовой объем потребления данного сервиса, а компания «С» пока не располагает прогнозами по использованию и хотела бы использовать возможность оплаты сервиса по мере потребления. Очевидно, что обоим потребителям необходимо разработать и протестировать свои решения. Но после этого этапа они хотят начать использовать эти сервисы на разных условиях. А компания «А» хочет без особых ухищрений производить биллинг использования своих сервисов. Именно тут в полной мере проявляются преимущества использования платформы менеджмента API, которая предоставляет комфортные возможности для начала разработки, включая concept-proof, без прямых затрат со стороны потенциального потребителя, а именно, предоставляет полную документацию, примеры, и, что немаловажно, средства доступа к тестовым контурам сервисов, не требуя кастомизации со стороны разработчиков компании «А». Более того, после того, как компании «В» и «С» убедились в работоспособности концепции и закончили свои разработки, менеджер из компании «А» за считанные минуты, может предоставить доступ к производственным версиям своих сервисов, настраивая при этом тарифные планы использования этих сервисов разными потребителями.

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

Составляющие успешного внедрения

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

При этом обязательным элементом реализации является создание стратегии. Она включает учет бизнес-задач и целей (как будет развиваться сервис, какие продукты будут востребованы) и техническую сторону вопроса (как версионировать, обеспечивать обратную совместимость, развитие, наполнение, использование незатронутого функционала).

Важный аспект – удобство использования API. Если организация применяет набор сервисов, пользователю удобнее воспользоваться привычными («домашними») опциями. Вопрос открытости, удобства, своевременности изменения информации о road maps, о новых версиях, сообществе специалистов, которое вокруг складывается, очень важны в проекте внедрения открытых платформ и менеджмента API.

Основополагающими аспектами разработки API-стратегии организации являются исследование бизнес-ландшафта, то есть вопрос того, как она себя позиционирует на рынке; исследование IT-ландшафта. Затем происходит формирование и проверка гипотез, определение целевых сегментов аудитории, формирование и приоритизация пула гипотез, выявление потребности пользователей с представителями целевых сегментов. Осуществляются выбор приоритетных сценариев, определяются потребности в партнерствах с внешними компаниями, проработка моделей монетизации и тарифообразования, выделение перечня необходимых API. Затем осуществляются формирование требований к реализации для дальнейшего развития проекта, определение ключевых рисков и разработка road map реализации.

Сегодня на рынке существует порядка 10 решений по внедрению API, из них 4-5 представляют необходимый функционал. API Connect на базе существующих решений – самое распространенное в банковском и финансовом секторе. Результатами оптимального решения должны быть корректное проектирование, отсутствие проблем дупликации и переписывания API. Важными компонентами являются скорость и повышение производительности разработчиков, возможность повторного использования и нивелирование рисков за счет централизованного решения типичных проблем разработки.

Ещё новости

Добавить комментарий