Salt Edge: Open Banking API и кабинет финансовой организации

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

В этом кейсе единая модель API стала границей между клиентом и банковской неоднородностью. Коннекторы изолировали особенности банков, sandbox позволил пройти сценарии до production, а согласия и платежные состояния получили отдельный аудируемый контур.

Контур банковского подключения

• Задача: Дать финансовой организации единый API для подключения счетов, получения транзакций и запуска платежа через разные банки.
• Направление: Fintech, API, backend, безопасность.
• Точная ответственность AIFlowPoint: Разработка единого Open Banking API, банковских коннекторов, управления согласиями, платежной инициации, кабинета клиента и sandbox
• Продолжительность: 10 месяцев на ядро платформы, sandbox и первые банковские коннекторы.
• Команда: Product manager, системный аналитик, solution architect, security engineer, 4 backend-разработчика, frontend-разработчик, 2 QA и DevOps/SRE. Всего 12 человек.
• Фокус: Open Banking, API, Безопасность.

Почему различия банков нельзя отдавать клиенту

Банки использовали разные модели данных, способы авторизации и правила повторных запросов. Финансовой организации при этом требовался единый интерфейс для счетов, балансов, транзакций и платежей, где срок доступа зависит от согласия пользователя.

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

Граница между единым API и коннекторами

Объем работ охватывает единый Open Banking API, коннекторы, согласия, платежную инициацию, кабинет и sandbox. Указанная продолжительность относится к ядру платформы, sandbox и первым банковским коннекторам. Создание всей платформы Salt Edge, подключение всех банков и владение банковской инфраструктурой в объем работ AIFlowPoint не входили.

Один внешний контракт, отдельный коннектор на банк

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

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

Жизненный цикл подключения и платежа

• Разработали API регистрации клиента, подключения банка и управления согласиями.
• Создали единые модели счета, баланса, владельца и транзакции.
• Добавили платежную инициацию с подтверждением через банк.
• Реализовали коннекторы для разных способов авторизации и повторного входа.
• Подготовили кабинет клиента с ключами, webhook, логами и тестовым окружением.
• Добавили подпись webhook, ротацию секретов, ограничение запросов, дедупликацию транзакций и мониторинг коннекторов.
• Настроили повторную синхронизацию и контроль пропусков в банковских данных.
• Разработали дашборд качества коннекторов и уведомления о деградации конкретного банка.

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

Согласия, секреты и трассировка

Ruby и Go разделяют продуктовую и высоконагруженную интеграционную логику. PostgreSQL хранит согласия и финансово значимые состояния, Redis используется для коротких технических данных, Kafka передает события синхронизации. OAuth 2.0, OpenID Connect и mutual TLS защищают авторизацию между участниками. Vault хранит секреты, Terraform описывает инфраструктуру, OpenTelemetry связывает запрос клиента с конкретным коннектором.

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

Технологический контур проекта: Ruby, Go, PostgreSQL, Redis, Kafka, REST API, OpenAPI 3.1, OAuth 2.0, OpenID Connect, mutual TLS, HashiCorp Vault, Docker, Kubernetes, Terraform, OpenTelemetry, Prometheus, Grafana, Contract tests и k6. Связка технологий важна не сама по себе. Она объясняет, где находятся состояния, секреты, события, инфраструктурный код и trace от запроса клиента до конкретного банка.

Отзыв, повтор и деградация банка

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

Sandbox как приемочный контур

• Клиент работает по одной спецификации независимо от банка.
• Отозванное согласие прекращает дальнейшую синхронизацию.
• Повторная транзакция не появляется как новая.
• Повторный платежный запрос с тем же идентификатором не создает второй платеж.
• Webhook с неверной подписью отклоняется.
• Деградация одного банка видна отдельно и не скрывает состояние остальных.
• Sandbox воспроизводит успешные, ошибочные и ожидающие подтверждения сценарии.

Скорость подключения и качество коннекторов

Финансовая организация подключает счета разных банков, получает единые данные и инициирует платеж через один контракт. Отзыв согласия останавливает дальнейшую синхронизацию, повторные данные и запросы не создают вторую транзакцию или платеж, а sandbox позволяет пройти успешные и ошибочные сценарии до подключения банка.

Измеримый результат: Подключение клиента к sandbox за 10 рабочих дней; первый production-коннектор за срок до 8 недель после получения доступов; доля дублированных транзакций ниже 0,01%.

Эффект: Единая модель API сократила сложность банковских подключений, а согласия, платежи и восстановление получили проверяемые правила.

Что осталось команде для подключения следующего банка

• Единый API и кабинет клиента
• Sandbox с разными банковскими сценариями
• Банковские коннекторы
• OpenAPI-спецификация
• Модель угроз и политика секретов
• Дашборды и contract tests
• Инструкция подключения нового банка

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

Проверка API и коннекторов

Артефакты проекта: OpenAPI contract tests, sandbox-протоколы, reconciliation-отчеты, replay-тесты и dashboard качества коннекторов. Они показывают стабильность внешней спецификации, корректность повторения и сверки, а также отдельную видимость качества банковских коннекторов.

Кейс релевантен fintech-командам и B2B-платформам, которые соединяют несколько внешних провайдеров через единый контракт и несут риск повторной значимой операции. Он особенно полезен там, где интеграцию нужно сначала безопасно пройти в sandbox, а затем подключать production-контур после получения доступов.

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