Open banking и API для финтеха: как и зачем открывать доступ к данным

Что такое open banking и почему это не просто "дать доступ к API"

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

На практике это означает три вещи. Во-первых, технически — это REST или GraphQL API с понятной документацией и предсказуемым поведением. Во-вторых, юридически — это согласия, договоры и распределение ответственности между банком и сторонним сервисом. В-третьих, и это часто недооценивают, это операционная нагрузка: SLA, мониторинг, поддержка партнёров и версионирование. Открыть API — это не разовый проект, а продукт с жизненным циклом.

Стандарты: на что опереться, чтобы не изобретать велосипед

Глобально сложилось несколько ориентиров. Европейский PSD2 и стандарт Berlin Group NextGenPSD2 задали базовую логику: разделение ролей на AISP (доступ к информации о счёте) и PISP (инициация платежа), а также обязательную сильную аутентификацию клиента (SCA). Британский Open Banking Standard пошёл дальше в детализации API. В США и ряде рынков популярна модель Financial-grade API (FAPI) от OpenID Foundation — это профиль поверх OAuth 2.0 и OpenID Connect, специально усиленный для финансовых данных.

В Узбекистане единого обязательного open banking-стандарта на уровне регулятора пока нет в том виде, в каком он существует в ЕС. Поэтому на практике команды берут проверенную международную основу и адаптируют её под локальные реалии — интеграцию с национальными платёжными системами Uzcard и Humo, требования Центрального банка по защите информации и сложившиеся форматы межбанковского обмена.

Безопасность: где open banking ломается чаще всего

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

• Сильная аутентификация (SCA) — два фактора из трёх категорий: знание (PIN), владение (телефон, токен), биометрия. Без неё инициация платежа недопустима.
• OAuth 2.0 с короткоживущими токенами и scope — приложение получает доступ ровно к тем данным, на которые клиент дал согласие, и не более.
• mTLS (взаимный TLS) — банк и сторонний сервис аутентифицируют друг друга сертификатами, а не только API-ключом.
• Подпись сообщений — критичные запросы (особенно платёжные) подписываются, чтобы исключить подмену по пути.
• Rate limiting и аномалийный мониторинг — защита от перебора, утечки токенов и подозрительных паттернов.

Сценарии: что реально приносит ценность

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

• Платёжная инициация для маркетплейсов и сервисов — клиент платит напрямую со счёта, без лишних комиссий эквайринга и редиректов. Для онлайн-торговли это снижение издержек.
• Агрегация счетов — финтех-приложение показывает балансы и операции из нескольких банков в одном интерфейсе. Основа для PFM-сервисов (управление личными финансами) и бухгалтерии для МСБ.
• Скоринг и кредитование — с согласия клиента сервис анализирует историю операций для оценки кредитоспособности. Особенно ценно для сегмента без классической кредитной истории.
• Встроенные финансы (embedded finance) — небанковский бизнес (логистика, ритейл, такси) встраивает платежи и счета прямо в своё приложение через API банка-партнёра.
• B2B-расчёты и автоматизация бухгалтерии — выгрузка выписок, инициация массовых платежей, сверка для ERP-систем.

Тренд в Узбекистане: куда движется рынок

Финтех-рынок Узбекистана последние годы растёт заметно: выросло проникновение карт Uzcard и Humo, появились сильные мобильные кошельки и платёжные приложения, активизировалась цифровизация банковского сектора по линии Центрального банка. Это естественная почва для open banking — спрос на интеграции уже сформирован снизу, со стороны финтех-команд и онлайн-бизнеса.

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

С чего начать технически

Мы рекомендуем не пытаться сразу открыть всё. Рабочий путь — итеративный:

• Начните с read-only сценария (доступ к балансу и истории) — он проще по рискам, чем платёжная инициация.
• Сделайте sandbox с тестовыми данными раньше, чем продакшн — партнёры должны иметь возможность разрабатываться без доступа к реальным счетам.
• Заложите версионирование API с первого дня — ломающие изменения в финансовом API без версий означают сломанных партнёров.
• Постройте портал разработчика с документацией, ключами и аналитикой вызовов — это часть продукта, а не приятное дополнение.
• Заранее продумайте consent management — где и как клиент даёт, видит и отзывает согласия.