Open banking платформа против open banking API: что ждут регуляторы

Спросите трех вендоров, что такое "open banking", и получите четыре ответа. Одни покажут API-шлюз, другие лицензируемую платформу. Очень немногие объяснят разницу, а зря: разница это ровно то, что оценивают регуляторы. Коротко: open banking API это дверь. Open banking платформа это здание с охраной, камерами и книгами. Двери регуляторы не проверяют.

Чего требует PSD2 на самом деле

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

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

API без ядра: почему это ломается

Нас просили прикрутить open banking API к системам, где ядро не могло его поддержать, и от таких проектов мы теперь отказываемся. Не из пуризма, из арифметики. Мод отказов известен:

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

Каждый пункт это функция ядра в костюме API. Шлюз пропускает запрос дальше; выполнить его способно только ядро.

Платформа: где живут обязательства

Open banking платформа, в том смысле, который вкладываем мы, это ядро плюс API-слой плюс комплаенс-механика: записи согласий, SCA-потоки, журналы доступа, отчетность. API это поверхность контракта; платформа то, что делает контракт правдой. Когда учреждение ведет свои open banking обязательства на полноценной платформе, где ядро, API и управление согласиями одна система, разговор на аудите меняет форму. Вы показываете регулятору, где хранится согласие и как оно исполняется на уровне книг, а не диаграмму шлюза.

Скажем позицию прямо: open banking API без ядра позади это обуза, а не продукт. Он создает видимость комплаенса, перекладывая реальную работу, свежесть остатков, исполнение согласий, исполнение платежей, на инфраструктуру, которая этого не умеет. Если вендор продает вам дверь без здания, спросите, кто будет отвечать на вопросы регулятора.

Как это выглядит по модулям, описано на странице open banking API. Ядро, которое стоит за ним, разобрано на странице ABS Core, а если взвешиваете вендоров, наша таблица сравнения раскладывает критерии рядом.

Куда движется регулирование

PSD2 задала минимум; последующие акты его поднимают. Регулирование мгновенных платежей в ЕС добавляет обязательства по верификации получателя и убирает возможность брать за мгновенные переводы больше, чем за обычные. Open banking-режимы за пределами Европы, Open Finance в Бразилии, стандарты open banking в Великобритании, толкают ту же логику дальше: стандартизованные API, явные жизненные циклы согласий, правила ответственности за неверные данные. Общая нить это ответственность. Каждое новое требование ложится на того, кто держит данные клиента, а не на того, кто оперирует шлюзом.

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

Комплаенс-цена неверного выбора

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

Есть и медленная цена. Учреждения, начавшие с API-оболочки, рано или поздно перестраивают те же функции на уровне ядра: хранение согласий, доступ к свежим остаткам, API статусов платежей, и платят за шлюз дважды. Мы видели этот сценарий достаточно часто, поэтому теперь он первый вопрос в любом open banking разговоре: на чем стоит ваш API?

Что проверить до подписания

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