API відкритого банкінгу
Відкритий банкінг: дані рахунків і платежі через банківські API
Інформація про рахунки й ініціювання платежів через регульовані банківські API й агрегатори з обробкою згоди й токенів.
Архітектурний план
Прокрутіть убік, щоб побачити весь малюнок.
Open banking: дані та платежі за згодою клієнта
Клієнт надає згоду, конектор зберігає токени, а кожен виклик до банку авторизується й журналюється. Коли згода спливає або відкликається, застосунок знову запитує клієнта, а не збоїть мовчки.
- Основний потік
- Асинхронний
- Шлях винятків
Потік у 7 кроках
Потік крок за кроком
- Від Клієнт до Ваш застосунок або платформа: Надає згоду (основний потік).
- Від Ваш застосунок або платформа до Конектор open banking: Запити рахунків і платежів, через REST/JSON (основний потік).
- Від Конектор open banking до Банківські API або агрегатор: Авторизовані виклики API, через OAuth 2.0 · FAPI · REST (основний потік).
- Від Банківські API або агрегатор до Конектор open banking: Баланси, транзакції та статус платежу, через REST/JSON · webhook (асинхронний).
- Від Конектор open banking до ERP або головна книга: Нормалізовані транзакції, через REST/JSON (основний потік).
- Від Банківські API або агрегатор до Конектор open banking: Згода спливла або відкликана, через HTTP 401 · 403 (шлях винятків).
- Від Конектор open banking до Ваш застосунок або платформа: Клієнта просять поновити згоду (шлях винятків).
Огляд
Відкритий банкінг дає застосунку змогу читати рахунки клієнта й ініціювати платежі через регульовані банківські API за згодою клієнта. Він живить агрегацію рахунків, перевірки платоспроможності для кредитування, оплату банківським переказом у касах і казначейські огляди між банками.
Еталонний проєкт ставить конектор відкритого банкінгу між вашим застосунком і банками, напряму чи через ліцензований агрегатор. Конектор проводить шлях згоди, безпечно тримає токени, викликає банківські API за стандартами, як-от Berlin Group NextGenPSD2 чи UK Open Banking Standard, і перетворює дані кожного банку на одну узгоджену модель.
Згода не є постійною, і проєкт це враховує. Коли згода спливає чи відкликається, клієнта просять її поновити, а не застосунок тихо втрачає дані. Кожен виклик авторизується, журналюється й привʼязаний до згоди, що його дозволила.
Як працює потік
Клієнт надає згоду
Клієнт обирає свій банк, бачить, що й на скільки передається, і автентифікується в банку, який перенаправляє назад у ваш застосунок.
Ваш застосунок запитує
Ваш застосунок запитує баланси, транзакції чи платіж через API конектора, ніколи не через банк напряму.
Конектор викликає банк
Конектор використовує збережені токени для авторизованих викликів API банку чи агрегатора, дотримуючись профілю безпеки, якого вимагає банк.
Дані й статус повертаються
Баланси, транзакції й статус платежу повертаються як відповіді чи вебхуки, а конектор нормалізує їх в одну модель між банками.
Використайте дані
Нормалізовані транзакції живлять ваш продукт, ваші моделі ризику чи вашу ERP для позицій грошових коштів і звіряння.
Коли щось збоїть
Згода спливає чи відкликається
Банк відмовляє у виклику. Конектор позначає згоду як недійсну, а ваш застосунок просить клієнта поновити її, пояснюючи причину.
Платіж відхилено
Статус і причина банку повертаються через API чи вебхук, а клієнт і ваша операційна команда одразу бачать результат.
Банк обмежує доступ
Банки обмежують, як часто можна отримувати дані без присутності клієнта. Конектор планує оновлення в цих межах і сповільнюється, коли банк про це сигналізує.
API банку недоступний
Виклики повторюються з наростаючими затримками, останні добрі дані показуються з їхнім віком, а якщо збій триває, піднімається оповіщення.
Стандарти й системи
- Банківські стандарти й канали
- PSD2
- Berlin Group NextGenPSD2
- UK Open Banking Standard
- FAPI
- Інтеграція
- REST
- Webhooks
- Ідентичність і доступ
- OAuth 2.0
- OpenID Connect
Запитання й відповіді
Підключатися до банків напряму чи через агрегатор?
Агрегатор дає багато банків через один API й обробляє відмінності кожного банку за плату за виклик чи за підключення. Прямі підключення дають більше контролю й можуть пасувати для малої кількості важливих банків. Багато продуктів починають з агрегатора й додають прямі підключення пізніше. Ми порівнюємо варіанти щодо потрібних вам банків і країн.
Чи потрібна нам ліцензія для відкритого банкінгу?
Інформація про рахунки й ініціювання платежів є регульованою діяльністю в багатьох країнах. Або ваша компанія має авторизацію, або ви працюєте через ліцензованого провайдера, який її має. Що застосовується, залежить від вашої країни й сценарію, і це мають підтвердити ваші юридичні радники й радники з відповідності. Ми будуємо інтеграцію для обраного вами шляху.
Як обробляється згода клієнта?
Клієнт бачить, які дані передаються, з якою метою й на скільки, і автентифікується у своєму банку. Конектор зберігає згоду та її токени зашифрованими, а кожен виклик привʼязаний до дійсної згоди. Клієнти можуть відкликати згоду, і тоді конектор перестає викликати для них цей банк.
Які банки й країни охоплено?
Покриття залежить від правил регіону й API банків. Європейський Союз і Велика Британія мають широке покриття за PSD2 і UK Open Banking Standard. В інших місцях покриття різниться, і агрегатори закривають частину прогалин. Ми перевіряємо покриття для банків, якими користуються ваші клієнти, перш ніж ви зобовʼяжетеся на проєкт.
Чи замінює відкритий банкінг підключення до банків хост до хосту?
Не для більшості корпоративної казначейської роботи. Канали хост до хосту обробляють пакетні платіжні файли й повні виписки для ваших власних рахунків. Відкритий банкінг пасує клієнтським продуктам, балансам у реальному часі й окремим платежам. Багато бізнесів використовують обидва: хост до хосту для власних платіжних циклів і відкритий банкінг для своїх клієнтів.
Як захищені дані відкритого банкінгу?
Токени й записи згод зашифровані в стані спокою, ними може користуватися лише конектор, а кожен виклик журналюється разом зі згодою за ним. Ми збираємо лише дані, потрібні для мети, і визначаємо, як довго їх зберігати. До цих даних застосовуються правила захисту даних, як-от GDPR, і ми проєктуємо разом із вашим уповноваженим із захисту даних.
Почніть із розмови, а не з договору.
Розкажіть, що вам треба побудувати, зʼєднати чи захистити. Архітектор пройде це з вами, а потім порадить, з чого почати.
Що буде далі
Узгодження часу
Наша команда напише вам, щоб узгодити час сесії.
Попередня консультація
Формат: безкоштовна 30-хвилинна онлайн-консультація перед співпрацею. Ми разом розбираємо ваші цілі, системи й обмеження.
Оцінка готовності
На кроці «безкоштовна 48-годинна оцінка готовності» головний архітектор перевіряє ваш проєкт за 6 пунктами Definition of Ready і рекомендує відповідний трек.
Вибір треку
Проєкти з готовим обсягом отримують обовʼязкову пропозицію протягом від 3 до 5 робочих днів. Проєкти на стадії концепції починаються в Blueprint Studio. Робоча система, яка дає збої, не має документації або потребує інтеграції, починається з діагностики тривалістю від 1 до 2 тижнів. Blueprint Studio і діагностика мають фіксовану плату, зазначену в пропозиції.