API-uri de open banking
Open banking: date de cont și plăți prin API-urile băncilor
Informații de cont și inițierea plăților prin API-uri bancare reglementate și agregatori, cu gestionarea consimțământului și a tokenilor.
Blueprint
Derulați lateral pentru a vedea întregul desen.
Open banking: date și plăți cu consimțământul clientului
Clientul își dă consimțământul, conectorul păstrează tokenurile, iar fiecare apel către bancă este autorizat și înregistrat. Când consimțământul expiră sau este retras, aplicația îl întreabă din nou pe client, în loc să eșueze în tăcere.
- Flux principal
- Asincron
- Cale de excepție
Fluxul în 7 pași
Fluxul, pas cu pas
- De la Client la Aplicația sau platforma dumneavoastră: Acordă consimțământul (flux principal).
- De la Aplicația sau platforma dumneavoastră la Conector open banking: Cereri de cont și de plată, prin REST/JSON (flux principal).
- De la Conector open banking la API-uri bancare sau agregator: Apeluri API autorizate, prin OAuth 2.0 · FAPI · REST (flux principal).
- De la API-uri bancare sau agregator la Conector open banking: Solduri, tranzacții și starea plăților, prin REST/JSON · webhook (asincron).
- De la Conector open banking la ERP sau registru: Tranzacții normalizate, prin REST/JSON (flux principal).
- De la API-uri bancare sau agregator la Conector open banking: Consimțământ expirat sau retras, prin HTTP 401 · 403 (cale de excepție).
- De la Conector open banking la Aplicația sau platforma dumneavoastră: Clientul este rugat să își reînnoiască consimțământul (cale de excepție).
Prezentare generală
Open banking permite unei aplicații să citească conturile unui client și să inițieze plăți prin API-uri bancare reglementate, cu consimțământul clientului. Stă la baza agregării conturilor, a verificărilor de bonitate pentru creditare, a plăților direct din cont la finalizarea comenzii și a vizualizării trezoreriei între mai multe bănci.
Arhitectura de referință pune un conector de open banking între aplicația dumneavoastră și bănci, direct sau printr-un agregator autorizat. Conectorul parcurge fluxul de consimțământ, păstrează tokenii în siguranță, apelează API-urile băncilor conform unor standarde precum Berlin Group NextGenPSD2 sau UK Open Banking Standard și transformă datele fiecărei bănci într-un singur model consecvent.
Consimțământul nu este permanent, iar arhitectura ține cont de asta. Când consimțământul expiră sau este retras, clientul este rugat să îl reînnoiască, în loc ca aplicația să piardă datele în tăcere. Fiecare apel este autorizat, jurnalizat și legat de consimțământul care l-a permis.
Cum funcționează fluxul
Clientul își dă consimțământul
Clientul își alege banca, vede ce date sunt partajate și pentru cât timp și se autentifică la bancă, care îl redirecționează înapoi în aplicația dumneavoastră.
Aplicația dumneavoastră solicită datele
Aplicația dumneavoastră cere solduri, tranzacții sau o plată prin API-ul conectorului, niciodată direct de la bancă.
Conectorul apelează banca
Conectorul folosește tokenii stocați pentru a face apeluri autorizate către API-ul băncii sau către agregator, respectând profilul de securitate cerut de bancă.
Datele și starea se întorc
Soldurile, tranzacțiile și starea plății se întorc ca răspunsuri sau webhooks, iar conectorul le normalizează într-un singur model pentru toate băncile.
Folosirea datelor
Tranzacțiile normalizate alimentează produsul dumneavoastră, modelele de risc sau ERP-ul, pentru poziții de numerar și reconciliere.
Când ceva eșuează
Consimțământul expiră sau este retras
Banca refuză apelul. Conectorul marchează consimțământul ca nevalid, iar aplicația dumneavoastră îi cere clientului să îl reînnoiască, explicându-i de ce.
O plată este respinsă
Starea și motivul băncii se întorc prin API sau printr-un webhook, iar clientul și echipa dumneavoastră de operațiuni văd rezultatul imediat.
O bancă limitează accesul
Băncile limitează cât de des pot fi obținute date fără ca clientul să fie prezent. Conectorul programează actualizările în aceste limite și își reduce ritmul când banca îi semnalează acest lucru.
Un API bancar este indisponibil
Apelurile sunt reîncercate cu intervale tot mai mari, ultimele date valabile sunt afișate împreună cu vechimea lor, iar o alertă este declanșată dacă indisponibilitatea continuă.
Standarde și sisteme
- Standarde și canale bancare
- PSD2
- Berlin Group NextGenPSD2
- UK Open Banking Standard
- FAPI
- Integrare
- REST
- Webhooks
- Identitate și acces
- OAuth 2.0
- OpenID Connect
Întrebări și răspunsuri
Ar trebui să ne conectăm direct la bănci sau printr-un agregator?
Un agregator vă oferă multe bănci printr-un singur API și gestionează diferențele dintre ele, cu un cost pe apel sau pe conexiune. Conexiunile directe oferă mai mult control și pot fi potrivite pentru un număr mic de bănci importante. Multe produse încep cu un agregator și adaugă conexiuni directe mai târziu. Comparăm opțiunile în funcție de băncile și țările de care aveți nevoie.
Avem nevoie de o autorizație pentru a folosi open banking?
Informațiile de cont și inițierea plăților sunt activități reglementate în multe țări. Fie compania dumneavoastră deține autorizația, fie lucrați printr-un furnizor autorizat care o deține. Ce se aplică depinde de țara și de cazul dumneavoastră de utilizare, iar consilierii juridici și de conformitate ar trebui să confirme. Construim integrarea pentru oricare dintre variante.
Cum este gestionat consimțământul clientului?
Clientul vede ce date sunt partajate, în ce scop și pentru cât timp, și se autentifică la propria bancă. Conectorul păstrează consimțământul și tokenii săi criptați, iar fiecare apel este legat de un consimțământ valid. Clienții își pot retrage consimțământul, iar conectorul nu mai apelează acea bancă pentru ei după retragere.
Ce bănci și țări sunt acoperite?
Acoperirea depinde de regulile regiunii și de API-urile băncilor. Uniunea Europeană și Regatul Unit au o acoperire largă în cadrul PSD2 și al UK Open Banking Standard. În alte părți, acoperirea variază, iar agregatorii umplu unele goluri. Verificăm acoperirea pentru băncile pe care le folosesc clienții dumneavoastră înainte de a vă angaja la o arhitectură.
Open banking înlocuiește conexiunile bancare host-to-host?
Nu pentru cea mai mare parte a activității de trezorerie corporativă. Canalele host-to-host gestionează fișiere de plăți în volum mare și extrase complete pentru conturile proprii. Open banking se potrivește produselor pentru clienți, soldurilor în timp real și plăților individuale. Multe companii le folosesc pe amândouă: host-to-host pentru propriile loturi de plăți și open banking pentru clienții lor.
Cum sunt protejate datele din open banking?
Tokenii și înregistrările de consimțământ sunt criptate în repaus, doar conectorul le poate folosi, iar fiecare apel este jurnalizat împreună cu consimțământul din spatele lui. Colectăm numai datele de care are nevoie scopul și stabilim cât timp sunt păstrate. Acestor date li se aplică reguli de protecție precum RGPD, iar noi proiectăm împreună cu responsabilul dumneavoastră cu protecția datelor.
Începeți cu o conversație, nu cu un contract.
Spuneți-ne ce trebuie să construiți, să conectați sau să securizați. Un arhitect parcurge totul împreună cu dumneavoastră, apoi recomandă de unde să începeți.
Ce se întâmplă în continuare
Convenirea unei ore
Echipa noastră vă scrie prin e-mail pentru a conveni o oră pentru sesiune.
Sesiune de preconsultanță
O sesiune online gratuită de preconsultanță de 30 de minute: trecem în revistă obiectivele, sistemele și constrângerile dumneavoastră.
Evaluarea de pregătire
Într-o evaluare de pregătire gratuită în 48 de ore, un arhitect principal verifică proiectul dumneavoastră față de definiția „pregătit” în 6 puncte și recomandă traseul potrivit.
Alegerea traseului
Proiectele cu scop definit primesc o propunere fermă în 3–5 zile lucrătoare. Proiectele aflate în faza de concept încep în Blueprint Studio. Un sistem live care eșuează, nu este documentat sau are nevoie de integrare începe cu un diagnostic de 1–2 săptămâni. Blueprint Studio și diagnosticul au fiecare un tarif fix, cotat în propunere.