A Third Party Provider (TPP) in open banking is a regulated entity that uses bank APIs to offer Account Information Services (AIS) and/or Payment Initiation Services (PIS). Users consent once, and the TPP can then read account data or initiate payments on their behalf. Building a TPP means getting architecture, consent, and compliance right from day one.
AIS vs PIS
AIS (Account Information Services) — про чтение данных: список счетов, балансы, транзакции. Кейсы: дашборды агрегации, кредитование и проверка доходов, бюджетирование. Пользователь даёт согласие «поделиться данными счёта с этим приложением», и TPP вызывает API банка с полученным access token.
PIS (Payment Initiation Services) — про инициирование платежа со счёта пользователя. Пользователь выбирает счёт и сумму; TPP отправляет инструкцию в банк. Никаких карт и отдельных переводов — платёж инициируется через open‑banking‑канал. Кейсы: checkout, оплата счетов, выплаты.
Многие TPP делают и то и другое: сначала показывают счета (AIS), затем позволяют оплатить с одного из них (PIS). Согласие должно быть понятным и ограниченным по scope — какие данные или действия разрешены, на какой срок, и должно быть отзывным.
Consent in practice
Согласие — это не одноразовая галочка. У него есть жизненный цикл: создать, использовать, обновить, отозвать. TPP должен хранить согласие и его scope, связать его с access token и уважать отзыв. Пользователи должны иметь возможность видеть и отзывать согласие в вашем приложении или через централизованный портал. Мы строим управление согласиями и audit trails, чтобы наши клиенты оставались комплаенс‑готовыми и удобными для пользователей.
Strong Customer Authentication (SCA)
Банки обычно требуют SCA (например, 2FA) перед выдачей данных или исполнением платежа. TPP делает редирект пользователя в банк; банк выполняет SCA и возвращает редирект с auth‑кодом. Затем TPP обменивает код на access token. Мы проектируем и реализуем этот redirect‑ и token‑флоу, чтобы вашему продукту не пришлось становиться экспертом по безопасности — мы строим это для вас, как делали для Meras, Infinipi и других.
Regulatory readiness
TPP часто подпадают под лицензирование (например, как платёжные институты или по локальным правилам open banking). Архитектура должна поддерживать audit trails, безопасное хранение токенов и чёткое разделение согласий и исполнения. В FintechPaa мы строим системы, готовые для TPP, с выравниванием по PSD2/Open Banking — чтобы вы фокусировались на продукте и регулировании, а не на низкоуровневой интеграции.
Планируете TPP или добавляете AIS/PIS в продукт? Мы можем построить для вас архитектуру и флоу.
← Назад в блог