Что такое открытый банкинг и как работают банковские API

Коротко о главном

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

Есть два основных вида доступа:

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

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

Как было раньше: screen scraping

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

Основные типы API

Многие банки также открывают корпоративные API для бизнес-клиентов: выписки, пакетные платежи, вебхуки о поступлениях. Их не всегда называют открытым банкингом, но технически они устроены похоже.

Как работают согласие и безопасность

Типичный процесс:

1. Клиент выбирает свой банк в вашем приложении.
2. Приложение запрашивает согласие с конкретным scope — например, чтение операций за 90 дней.
3. Клиента перенаправляют в приложение или на сайт банка, где он входит в систему.
4. Банк применяет строгую аутентификацию (например, биометрия плюс устройство или одноразовый код) и показывает, что именно запрашивается.
5. После подтверждения ваша система получает токен доступа по схеме на основе OAuth 2.0.
6. Вы вызываете API с этим токеном, пока согласие не истечёт или клиент его не отзовёт.

Уровни защиты обычно включают:

• взаимный TLS и сертификаты, идентифицирующие лицензированную третью сторону;
• профили OAuth 2.0 и OpenID Connect с короткоживущими токенами;
• подписанные запросы и ответы в более строгих стандартах;
• согласия со сроком действия и ограниченным scope;
• журналы аудита с обеих сторон.

Что бизнес строит поверх

• Оплата со счёта на сайте — клиент платит без карты, что может снизить расходы на эквайринг и риск чарджбэков.
• Кредитование и скоринг — реальные данные операций вместо загруженных PDF-выписок.
• Синхронизация с учётом и ERP — автоматический импорт операций и сверка оплат по счетам.
• Приложения личных финансов — все счета из разных банков в одном месте.
• Проверка владельца счёта — перед выплатами клиенту.
• Казначейские дашборды — остатки по всем счетам компании на одном экране.

С чего начать

1. Изучите рынок. У каких банков есть API, открытые они или только для партнёров, нужна ли лицензия.
2. Выберите: напрямую или через агрегатор. Прямые интеграции дают контроль, но работы больше с каждым банком. Агрегатор даёт один API для многих банков, но добавляет зависимость и комиссии.
3. Продумайте UX согласия. Понятно объясните, зачем нужен доступ и на какой срок.
4. Обрабатывайте сбои. У банков бывают простои, лимиты запросов и разные форматы данных: нормализуйте данные и аккуратно повторяйте запросы.
5. Защищайте данные. История операций — крайне чувствительная информация: храните минимум и шифруйте.

Частые ошибки

• Запрашивать более широкий scope, чем нужно продукту, — это пугает пользователей и регулятора.
• Игнорировать срок действия согласия и молча ломаться, когда токен перестаёт работать.
• Считать, что все банки отдают одинаковые поля и описания операций.
• Принимать инициирование платежа за подтверждение оплаты, не проверяя финальный статус.