Разработка AI-системы для Open Banking PSD2 интеграций

Open Banking: где ломаются интеграции на масштабе

Open Banking интеграция редко ломается на уровне одного запроса — она ломается на масштабе. Пока банков два и клиентов десяток, каждый закрывается своим коннектором: свои поля в выписке, свои коды ошибок, свой формат даты и суммы. Как только банков становится двадцать, поддержка превращается в постоянную ручную работу, а подключение к банковским счетам нового партнёра занимает недели вместо дней.

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

PSD2 доступ к счетам добавляет к этому согласия: они живут ограниченный срок, отзываются клиентом в любой момент и требуют своевременного обновления токенов. Если согласие хранится атрибутом пользователя, а не отдельной сущностью со статусом и сроком жизни, сверки и отчётность начинают расходиться с реальностью.

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

Что даёт AI-слой поверх банковских интерфейсов

AI-слой ставится между сервисом и банковскими интерфейсами и не заменяет интеграцию, а снимает с неё разнородность. Berlin Group задаёт общий каркас запросов, но фактические ответы банков расходятся: формат выписок, коды назначения платежа, правила постраничной выдачи. Слой приводит их к единой модели операции — дата, контрагент, назначение, сумма, направление.

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

Устойчивость интеграции строится на изоляции отказов, а не на одном «главном» банке. Каждый банк — отдельный маршрут со своим предохранителем, таймаутом и очередью повторных попыток: если участник недоступен, запросы к нему буферизуются, а остальные маршруты отвечают штатно. Так уходит целый класс отказов, когда падение одного банка обрушивало общий сценарий согласия или выгрузки.

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

Способы подключения к банковским интерфейсам: сравнение

Выбор способа доступа определяется тремя параметрами: сколько банков нужно охватить, как часто запрашиваются баланс и выписка, и что происходит при сбое на стороне банка. Варианты различаются не только трудоёмкостью подключения, но и классом отказов, который ложится на нашу сторону.

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

Кэширование банковских данных снимает часть нагрузки с банковских интерфейсов и сглаживает их недоступность: выписка обновляется по расписанию, баланс — по требованию, а при ошибке возвращается последнее подтверждённое состояние с отметкой времени. Правила маршрутизации решают, какой запрос идёт напрямую, какой через агрегатор и когда ответ берётся из кэша.

Этапы внедрения AI-интеграции в банковский контур

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

1. Аудит интеграций. Инвентаризация подключений: какие интерфейсы банка задействованы, где хранятся согласия, какие лимиты действуют. Итог — карта зависимостей и список узких мест.
2. Схема маршрутизации запросов. Размечаем, что уходит в модель, что решается правилами, как обрабатываются отказы и таймауты. Правила фиксируются спецификацией, а не договорённостью.
3. Настройка доступа к счетам. Роли, области видимости, сроки согласий, журналирование каждого обращения. Доступ выдаётся по минимально необходимому.
4. Тестирование на реальных данных. Теневой режим на исторических операциях и песочница банка; расхождения с решениями действующих правил разбираем до включения.
5. Пилот на доле трафика. Смотрим задержки, долю отказов, полноту журналов. Возврат на прежнюю схему — одним переключателем.
6. Передача и сопровождение. Конфигурации, схемы потоков, регламент реагирования и порядок обновления модели.

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

Политики доступа, схемы и документация на передачу

Готовая интеграция — это не только работающий обмен данными. Без матрицы доступов и регламентов эксплуатации решение живёт до первой ротации сертификата или изменения на стороне банка. Поэтому вместе с системой передаём артефакты, по которым ваша команда сопровождает и развивает её самостоятельно.

• Конфигурации подключений: адреса тестового и продуктивного контуров, идентификаторы клиента, сертификаты взаимной аутентификации, ключи подписи запросов и порядок их ротации.
• Схема потоков данных: полный путь запроса согласия — инициирование, перенаправление пользователя, возврат, обмен токенами, продление и отзыв доступа.
• Матрица ролей и доступов: кто вправе инициировать платёж, читать балансы и историю, отзывать согласия; разделение прав на чтение и запись, минимально необходимые привилегии, журнал действий.
• Регламент обработки отказов: поведение при истёкшем токене, превышении лимита запросов и недоступности банка — повтор с нарастающей задержкой, идемпотентность платежей по ключу операции, порядок разбора зависших переводов вручную.
• Документация интеграции: описание контрактов и форматов обмена, справочник кодов ошибок с расшифровкой и примерами корректных и отклонённых запросов.
• Инструкции для поддержки: как перевыпустить сертификат, отозвать доступ, поднять контур после сбоя и в какой срок эскалировать инцидент.
• Порядок обновления при изменении банковских интерфейсов: набор обязательных проверок перед выкаткой и матрица ответственных.

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

Кейс: агрегация счетов с AI-маршрутизацией запросов

Что было

Агрегатор опрашивал банки синхронно в момент открытия экрана: каждый запрос ждал самого медленного участника, а ошибка на одном подключении ломала всю сводку по счетам. Доля автоматически обработанных обращений держалась около 70%, время до отображения баланса доходило до 6–8 секунд, доля неуспешных обращений к банкам — 12–14%. Внутри этих отказов смешивались разные причины: ограничение частоты запросов, истёкшие согласия и сетевые обрывы, и система реагировала на все одинаково — повтором до предела.

Что изменили

Разделили сбор данных и их отображение: фоновый обход наполняет кэш, экран сразу отдаёт последние известные значения и обновляет их по мере поступления. Маршрутизацию запросов к банкам перевели на правила с приоритетами — свежие балансы идут вне очереди, история и аналитика добираются позже, поэтому медленный банк больше не тормозит остальных. Повторы сделали с нарастающей паузой и разбором по классу отказа: сетевой сбой повторяется, истёкшее согласие по PSD2 уходит в сценарий повторной авторизации, а не в бесконечные попытки. Ключи запросов убрали дубли при повторных отправках.

Что стало

Доля автоматически обработанных запросов выросла до 96%, время до отображения баланса сократилось до 1–1,5 секунды, доля неуспешных обращений к банкам — 2–3%. Оставшиеся отказы теперь классифицированы: пользователь видит, какой банк требует повторного входа, вместо общей ошибки загрузки. Нагрузка на банковские интерфейсы снизилась за счёт кэша и сглаженных повторов, поэтому лимиты частоты перестали быть источником сбоев.

Чем прямое подключение отличается от агрегатора

Разница проявляется в четырёх местах: глубина отдаваемых данных, свежесть этих данных, зона ответственности при сбое и объём работ по поддержанию подключений в живом состоянии. Ниже — как это выглядит на практике, а не в презентации.

Глубина данных. Прямое подключение отдаёт всё, что публикует сам банк: назначение платежа, категорию торговой точки, регулярные поступления, остаток и лимиты по каждому счёту. Агрегатор приводит десятки банков к общему виду — а общий знаменатель всегда беднее: нестандартные поля теряются, категории пересчитываются по собственной модели, часть атрибутов доступна только с определённого уровня доступа.

Свежесть. Прямое подключение обновляет данные по событию — картина на момент запроса. Агрегатор чаще работает на периодическом опросе: движения по счёту подтягиваются по расписанию и лежат в промежуточном хранилище, поэтому между реальной операцией и её появлением у вас проходит от нескольких десятков минут до часов. Для скоринга и аналитики это нормально, для подтверждения платежа — уже нет.

Ответственность за сбой. При прямом подключении инцидент локализуется на стыке с одним конкретным банком: видно, чей ответ не пришёл, диагностика занимает минуты, но переговоры и дежурство — на вашей стороне. У агрегатора появляется единая точка отказа: недоступен он — недоступны сразу все банки. Разбор при этом идёт через третью сторону, и типовой сценарий — взаимные ссылки: агрегатор говорит, что банк не ответил, банк утверждает, что запросов не видел.

Поддержание в актуальном состоянии. Банки меняют схемы согласий, требования к подтверждению клиента, сертификаты и форматы ответов. При прямом подключении объём работ растёт линейно с числом банков, и каждая правка — ваш релиз. Агрегатор берёт это на себя, но обновления приходят в его сроки, вне вашего контроля.

Поэтому на практике чаще собирают гибрид: агрегатор вроде Salt Edge закрывает длинный хвост банков на старте, прямое подключение ставится туда, где нужны полная глубина полей и предсказуемая задержка ответа.

Технические сомнения вокруг AI в банковских данных

Open Banking строится на чужих интерфейсах, поэтому неопределённость — норма: расхождение в выписке клиент замечает раньше мониторинга. До старта фиксируем поведение системы в нештатных ситуациях — ниже четыре сомнения, которые поднимают первыми.

Кто отвечает за качество распознавания операций?

Мы, и это закреплено в условиях приёмки. Каждое сопоставление получает оценку уверенности: выше порога — уходит автоматически, ниже — на ручную проверку, а не в отчёт. Точность по категориям считаем на размеченном наборе регулярно, поэтому деградация видна раньше, чем её заметит клиент.

Что делать с банками, которых нет в наборе?

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

Как защищены банковские данные?

Реквизиты не храним — работаем на токенах, доступ разграничен по ролям, каждое обращение журналируется. Согласие оформляется со сроком и отзывается в один шаг, после отзыва доступ закрывается сразу. Канал и хранилище шифруются, тестовые контуры изолированы от промышленных.

Обсудим задачу: AI-слой для Open Banking

Чтобы взяться за AI-слой поверх Open Banking, доступ к продуктивной среде не нужен. Достаточно тестового контура банка-партнёра, спецификации XS2A в вашей редакции, примеров выписок в ISO 20022 и перечня решений, которые сегодня принимаются вручную — по платежам, лимитам, подозрительным операциям.

Первый результат работ — не презентация, а работающий вертикальный срез: одно согласие, один сценарий, одна модель и замер качества на исторических данных. Со стороны заказчика для старта нужен минимум: доступ в песочницу, контакт интеграционной команды и специалиста по безопасности, обезличенная выборка операций за достаточный период и действующие правила согласия — сроки жизни, объём прав, порядок отзыва.

• карта доступных точек API и прав согласия: что реально отдаёт банк, а что достраиваем на своей стороне
• схема потока данных от согласия до ответа модели, с явными точками отказа и отката
• прототип модели на ваших обезличенных данных: скоринг, классификация операций, разбор выписок
• метрики на отложенной выборке: полнота, доля ложных срабатываний, устойчивость к пропускам в данных
• политика обезличивания, хранения и разграничения доступа к персональным данным
• план пилота: объём нагрузки, критерии успеха, условия остановки и возврата к прежней логике

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