Как банки становятся IT-компаниями с финансовыми сервисами: путь от SOAP к REST

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

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

Тем временем передовые банки развивают альтернативные бизнес-модели взаимодействия с клиентами: кроме финансовых услуг начали предлагать свою финансовую инфраструктуру в аренду по аналогии с Amazon. Поясню, у Amazon была суперпрокачанная экспертиза в облачном хранении и вычислений для своего розничного бизнеса. Компания увидела возможность монетизации этой экспертизы, предлагая её в качестве услуги. Так Amazon стал пионером IaaS — Infrastructure as a Service, предлагая другим организациям софт и железо.

Это отличный пример win-win модели, где выигрывает сам Amazon за счёт утилизации простаивающего железа и массовый b2b потребитель за счёт покупки готового сервиса в нужном объёме вместо капитальных инвестиций в построение собственной инфраструктуры.

Но в отличие от Amazon, которые запустили AWS в 2006-м, банки сделали робкие попытки выставления своей инфраструктуры наружу аж в 1987 году — тогда был опубликован один из первых стандартов обработки электронных платежей (ISO 8583). С развитием ERP-систем (систем планирования ресурсов предприятия), в частности решений от SAP, банки начали активно интегрировать свою back-инфраструктуру с front-решениями клиентов для работы с банком из корпоративных учётных систем. Эта интеграция осуществлялась через новый тогда банковский канал обслуживания — API.

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

Банки осознали, что могут предоставлять, считай продавать, продукты за периметром традиционных каналов (офис, web, mobile, контактный центр), интегрируясь не только с корпоративными системами, но и с онлайн-сервисами, SaaS и e-commerce-площадками.

В 2017-2018-м и зарубежные банки (BBVA, Citi, DBS), и наши стали запускать API с контекстом работы с пользователем: SaaS/Ecom стали бесшовно сливаться с банковской инфраструктурой, и мы, пользователи, даже не видим этих интеграций.

Я часто привожу в пример Klarna. Это стартап, который дорос до банка и подключил 400 000 онлайн-магазинов. 150 миллионов клиентов оформляют кредиты от Klarna, не покидая e-commerce-площадки.

Этот шведский банк предлагает набор кредитных платёжных механик, которые, судя по статистике, значительно улучшают продажи: средний чек растёт на 41%, конверсия на странице checkout — на 30%, и помогают вовлечь новых клиентов — 40% выбирают платёжные методы от Klarna.

Для мерчанта это сверхвыгодное партнёрство, потому что всю кредитную магию берёт на себя провайдер финансового сервиса. Очевидно, что обычный магазин не сможет сделать правильный скоринг клиентов и постоянно инвестировать в разработку платёжных форм под все digital-каналы. А для клиента это просто дополнительная кнопка способа оплаты на странице checkout.

Мерчант продаёт джинсовку, книги или технику, а Klarna отвечает за кредитный риск и перечисляет деньги за товары клиентов. Всё это работает через API, но в отличие от 2000-х, над host-2-host API реализовано web/mobile UI взаимодействие, учитывающее контекст взаимодействия пользователя.

Банки в России сильно выросли в части финансовых услуг и околофинансовых сервисов совместно с внешними игроками. Теперь они совместно запускают нишевые продукты (Моё дело, МойСклад) для управления и развития бизнеса и интегрируются в гигантские маркетплейсы (Wildberries, Ozon). Это развитие стало возможным только после того, как банки пересмотрели подход к интеграционной инфраструктуре. Раньше интеграция шла месяцами, к ней подключались топовые эксперты в банке и в партнёрской компании.

Теперь в тренде сверхпростота. Инженеры хотят работать с современным технологическим стеком и ожидают от банков удобства, которые уже предоставляют им бигтех-провайдеры Google, Яндекс и другие. Эти моменты мы учли при разработке банковского API — Alfa API.

Например, для безопасного обмена авторизационными данными и организации механизма single sign-on c партнёрами мы используем OAuth 2.0 + OIDC. Более того, мы решили строго следовать отраслевым стандартам (RFC 6749RFC 6750, RFC 7519), а не тюнить их, чем почему-то грешат некоторые коллеги по индустрии.

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

А ещё отраслевые стандарты радикально облегчают жизнь аналитикам, разработчикам, тестировщикам и даже кибербезопасникам. Начинают работать паттерны: нашёл на GitHub реализацию по RFC для своей среды разработки и за два часа сделал интеграцию, применил готовые автотесты, провёл типовой аудит кибербезопасности, использовал существующие результаты пентестов.

Интеграция с нашей платформой аналогична интеграции с API от Google и Яндекс. Ключевой инструмент — Swagger для проектирования и документирования RESTful веб-сервисов. Со Swagger можно разрабатывать API с прекрасно структурированной документацией, плюс просматривать и тестировать API прямо из интерфейса Swagger UI без написания тестового приложения.

Мы собрали тестовый контур (sandbox) с prod-like данными, чтобы партнёр тестировал интеграции в безопасном окружении. Мы за популяризацию API с сообществом, поэтому сделали нашу спецификацию публичной.

Мы сознательно отказались от архитектуры SOAP в пользу REST API. SOAP, как многолетний стандарт банковских API, менее гибок. REST API — норма современной веб-разработки из-за его простоты. Он поддерживает удобные форматы данных (не только XML, как SOAP) и использует стандартные методы HTTP для операций. Это очень просто.

Мы сделали революционный скачок в использовании банковского API. Кроме host-to-host взаимодействия мы подключили web/mobile UI компоненты. Обычно в банковском API серверы обмениваются данными host-to-host. Так можно интегрировать ERP, но банку сложно взаимодействовать с конечным потребителем.

Мы добавили в эту схему web/mobile UI сценарии и вовлекли третью сторону — пользователя. Например, мы можем предлагать бесшовное онлайн-кредитование: клиент получает деньги из интерфейса партнёра, пока финансовые операции управляются и обрабатываются внутри банка.

Конечно, в платформу API заложен онбординг. Наломав дров, мы отладили его от подписания нормативных документов (привет, OpenAPI, которое на самом деле не open) до выдачи сетевых доступов и сократили средний срок интеграции до двух недель. Хотя бывают кейсы полноценной интеграции за 1 день, но это, скорее, исключение.

А что разработчики? Bigtech like подходы построения API, строгое следование отраслевым стандартам значительно снижают порог входа для junior и middle-разработчиков. Даже у senior-специалистов возникали огромные трудности имплементации гост-инструментов защиты (ФПСУ). На такие проекты уходили месяцы, иногда и годы с сопутствующим костом за работы. Поэтому многие просто отказывались от самой идем интеграции с банкам. Сегодня мир изменился.

Стремительная трансформация банковских API стимулирует прогресс, открывая новые бизнес-модели и сценарии потребления. Один из моих любимых отечественных кейсов — Яндекс Сплит. Пользователи просто покупают товар в рассрочку без знаний финансовой «магии» за кулисами. Действие происходит на Яндекс Маркете, где под капотом банк организует весь кредитный процесс.

Ещё пример. Компании-клиенты Альфа-Банка верифицируют учётную запись на SuperJob по Alfa ID. За пару кликов работодатель получает статус «Дополнительно проверен» — то есть его знают представители банка, и учётная запись принадлежит реальному лицу. С аутентификацией SuperJob экономят на разработке комплаенс-процессов и получают доверие соискателей и больше откликов.

С интеграцией по API в плюсе остаются банк, партнёр банка и конечный пользователь — это win-win-win модель. Ждём от банков новых финансовых сервисов, выставленных в канал API, от SaaS и Ecom — активные интеграции, а мы как потребители будем наслаждаться бесшовными процессами.

Если вы увлекаетесь интеграциями, изучайте современные стандарты BigTech. Например, в нашей спецификации Alfa API к каждому платформенному или продуктовому методу собраны примеры кода. Про развитие банковских технологий я пишу в Telegram. Это мой новый авторский канал, в котором я буду писать про финтех, менеджмент, Web3-инфраструктуру, про опыт, ошибки и чуть-чуть про лайфстайл.

На сегодня всё, ваши вопросы и предложения в комментариях крайне приветствуются.