Open Banking API: как подключить PSD2 и построить платформу AISP/PISP

Open Banking API по PSD2 открывает доступ к банковским данным и платежам через стандартизированные интерфейсы: сервисы AISP (агрегация счетов) читают данные, PISP (инициация платежей) запускают переводы с согласия клиента.Разбираем подробно: подключение к банкам API. В 2026 году открытый банкинг стал основой финтех-экосистем: необанки, учётные приложения и платёжные сервисы строятся на нём. В статье — роли AISP/PISP, стандарты API, подключение к банкам и практика построения платформы.

Что такое Open Banking и кто такие AISP и PISP?

Open Banking — доступ третьих сторон к банковским данным и платёжным функциям через API по согласию клиента. PSD2 обязала банки предоставлять такие API, а финтех-компании получили роли: AISP (Account Information Service Provider) — чтение счетов, PISP (Payment Initiation Service Provider) — инициация платежей, CBPII — подтверждение доступности средств.

Для получения роли AISP/PISP нужна лицензия или регистрация у национального регулятора (для AISP — регистрация без полной лицензии, для PISP — лицензия платёжной организации). Дополнительно требуется страховка на 50 тыс. евро (EBA-требование).

Роли в Open Banking

РольФункцияЛицензия
AISPЧтение данных счетовРегистрация у регулятора
PISPИнициация платежейЛицензия платёжной организации
CBPIIПодтверждение средствРегистрация
ASPSPБанк, предоставляющий APIБанковская/платёжная

Какие стандарты API используются?

Основные стандарты: Berlin Group (NextGenPSD2) — самый распространённый в Европе, STET (Франция), UK Open Banking Standard (Великобритания) и национальные расширения. Стандарты описывают эндпоинты, аутентификацию (OAuth 2.0 + OIDC) и форматы данных.

Практическая сложность: каждый банк реализует стандарт по-своему, поэтому агрегаторы (Tink, Plaid, TrueLayer) унифицируют доступ: один API к сотням банков. Для MVP выгоднее подключить агрегатор, для контроля над продуктом — прямые интеграции с ключевыми банками.

  1. Berlin Group NextGenPSD2 — стандарт ЕС
  2. STET — Франция, UK Open Banking — Великобритания
  3. OAuth 2.0 + OpenID Connect для авторизации
  4. Агрегаторы: Tink, Plaid, TrueLayer, Salt Edge
  5. Прямые интеграции с ключевыми банками

Как построить платформу AISP?

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

Технически: OAuth-потоки для получения согласия, периодическая синхронизация счетов (cron/вебхуки), обработка ошибок банков и дедупликация транзакций. Безопасность: шифрование данных, минимальный доступ, журналирование — и соответствие GDPR.

Модули платформы AISP

МодульФункция
ИнтеграцииПодключение банков и агрегаторов
НормализацияЕдиный формат данных счетов
СогласияУправление доступом клиентов
APIДоступ для клиентских приложений
АналитикаКатегоризация, отчёты

Как построить платформу PISP?

Платформа PISP: выбор банка для инициации платежа → аутентификация клиента (SCA у банка) → подтверждение платежа → отслеживание статуса → уведомления. Ключевое преимущество для мерчантов — отсутствие карточных комиссий: переводы со счета дешевле карт.

Интеграция: API банка/агрегатора для инициации, обработка редиректов SCA (клиент аутентифицируется в банке), вебхуки статусов, обработка отмен и возвратов. Для PISP критичны идемпотентность и корректная обработка ошибок банка.

  1. Выбор банка для инициации платежа
  2. Редирект SCA у банка-эмитента
  3. Подтверждение и отслеживание статуса
  4. Вебхуки и уведомления
  5. Идемпотентность и обработка ошибок

Какие требования предъявляет регулятор?

AISP/PISP обязаны: зарегистрироваться/получить лицензию, иметь страховку на 50 тыс. евро, соблюдать требования к защите данных (GDPR), вести журналы доступа, уведомлять регулятора об изменениях и проходить проверки.

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

Требования к AISP/PISP

ТребованиеСуть
Регистрация/лицензияРоль у национального регулятора
Страховка50 тыс. евро покрытия
GDPRЗащита персональных данных
Журналы доступаФиксация всех обращений
СогласияПрозрачность и отзыв доступа

Какие ошибки допускают при внедрении Open Banking?

Частые ошибки: игнорирование различий API банков (каждый банк по-своему), слабое управление согласиями, отсутствие обработки ошибок и ретраев, недооценка требований SCA при инициации платежей и недостаточное тестирование на реальных банках.

Также команды забывают про мониторинг: API банков меняются, согласия истекают, интеграции ломаются. Внедрите мониторинг интеграций, алерты и процедуры быстрого восстановления — это основа надёжной платформы открытого банкинга.

Частые вопросы

Что такое AISP и PISP?

AISP — сервис чтения данных счетов, PISP — сервис инициации платежей. Обе роли введены PSD2 и требуют регистрации или лицензии у национального регулятора.

Какие стандарты Open Banking API существуют?

Berlin Group NextGenPSD2 (ЕС), STET (Франция), UK Open Banking (Великобритания). Агрегаторы вроде Tink и TrueLayer унифицируют доступ к сотням банков.

Нужна ли лицензия для AISP?

Для AISP достаточно регистрации у регулятора + страховка 50 тыс. евро. Для PISP — лицензия платёжной организации.

Сколько стоит построить платформу Open Banking?

MVP на агрегаторе — 30–100 тыс. евро, прямые интеграции с банками — дороже и дольше. Полная платформа с лицензированием — от 150 тыс. евро.

Как обрабатывается SCA при PISP?

Клиент перенаправляется в банк-эмитент для SCA, после аутентификации банк подтверждает платёж. PISP отслеживает статус через API и вебхуки.

Как защитить данные клиентов?

OAuth 2.0 + OIDC, шифрование данных, минимальный доступ, журналирование и соответствие GDPR. Согласия прозрачны и отзываемы.

Источники и методология

PSD2 (EU) 2015/2366, стандарты Berlin Group NextGenPSD2, спецификации агрегаторов (Tink, TrueLayer, Salt Edge). Практика — из Open Banking проектов Konomic.

Автор: Дмитрий Орлов (CTO) — CTO, Konomic. 10+ лет в разработке: core banking, платёжные системы, блокчейн-архитектура, безопасность. Актуальность: 2026-08-20.

Explore: [Платёжные решения](https://konomic.com/) · [BaaS development](https://konomic.com/baas-development)

Скачать Markdown исходник статьи:

⬇ Скачать .md