Open banking-API’er
Open banking: kontodata og betalinger via bankernes API’er
Kontooplysninger og betalingsinitiering via regulerede bank-API’er og aggregatorer, med håndtering af samtykke og tokens.
Arkitekturskitse
Rul sidelæns for at se hele tegningen.
Open banking: data og betalinger med kundens samtykke
Kunden giver samtykke, konnektoren opbevarer tokens, og hvert kald til banken er autoriseret og logget. Når samtykket udløber eller trækkes tilbage, spørger appen kunden igen i stedet for at fejle i stilhed.
- Primært flow
- Asynkron
- Undtagelsessti
Forløbet i 7 trin
Forløbet, trin for trin
- Fra Kunde til Din app eller platform: Giver samtykke (primært flow).
- Fra Din app eller platform til Forbindelse til open banking: Konto- og betalingsanmodninger, over REST/JSON (primært flow).
- Fra Forbindelse til open banking til Bank-API’er eller aggregator: Autoriserede API-kald, over OAuth 2.0 · FAPI · REST (primært flow).
- Fra Bank-API’er eller aggregator til Forbindelse til open banking: Saldi, transaktioner og betalingsstatus, over REST/JSON · webhook (asynkron).
- Fra Forbindelse til open banking til ERP eller hovedbog: Normaliserede transaktioner, over REST/JSON (primært flow).
- Fra Bank-API’er eller aggregator til Forbindelse til open banking: Samtykke udløbet eller trukket tilbage, over HTTP 401 · 403 (undtagelsessti).
- Fra Forbindelse til open banking til Din app eller platform: Kunden bedt om at forny samtykket (undtagelsessti).
Oversigt
Open banking gør det muligt for en applikation at læse en kundes konti og starte betalinger via regulerede bank-API’er med kundens samtykke. Det driver kontoaggregering, kreditværdighedsvurderinger ved udlån, betaling direkte fra bankkontoen i onlinekassen og treasuryoverblik på tværs af banker.
Referencedesignet placerer en open banking-konnektor mellem din applikation og bankerne, enten direkte eller via en autoriseret aggregator. Konnektoren styrer samtykkeforløbet, opbevarer tokens sikkert, kalder bankernes API’er efter standarder som Berlin Group NextGenPSD2 eller UK Open Banking Standard og omdanner hver banks data til én ensartet model.
Samtykke er ikke permanent, og det tager designet højde for. Når samtykket udløber eller trækkes tilbage, bliver kunden bedt om at forny det, i stedet for at applikationen i stilhed mister data. Hvert kald er autoriseret, logget og knyttet til det samtykke, der tillod det.
Sådan fungerer flowet
Kunden giver samtykke
Kunden vælger sin bank, ser, hvad der deles og hvor længe, og godkender sig hos banken, som sender kunden tilbage til din applikation.
Din applikation anmoder
Din applikation anmoder om saldi, transaktioner eller en betaling via konnektorens API, aldrig direkte gennem banken.
Konnektoren kalder banken
Konnektoren bruger de gemte tokens til autoriserede kald til bankens API eller aggregatoren efter den sikkerhedsprofil, banken kræver.
Data og status kommer tilbage
Saldi, transaktioner og betalingsstatus kommer tilbage som svar eller webhooks, og konnektoren normaliserer dem til én model på tværs af banker.
Brug dataene
Normaliserede transaktioner leverer data til dit produkt, dine risikomodeller eller dit ERP-system til likviditetspositioner og afstemning.
Når noget fejler
Samtykket udløber eller trækkes tilbage
Banken afviser kaldet. Konnektoren markerer samtykket som ugyldigt, og din applikation beder kunden om at forny det og forklarer hvorfor.
En betaling afvises
Bankens status og årsag kommer tilbage via API’et eller en webhook, og både kunden og dit driftsteam ser resultatet med det samme.
En bank begrænser adgangen
Banker begrænser, hvor ofte data må hentes, uden at kunden er til stede. Konnektoren planlægger opdateringer inden for disse grænser og venter længere, når en bank signalerer det.
Et bank-API er ikke tilgængeligt
Kald forsøges igen med stigende ventetid, de seneste gyldige data vises med deres alder, og der udløses en alarm, hvis nedbruddet fortsætter.
Standarder og systemer
- Bankstandarder og bankkanaler
- PSD2
- Berlin Group NextGenPSD2
- UK Open Banking Standard
- FAPI
- Integration
- REST
- Webhooks
- Identitet og adgang
- OAuth 2.0
- OpenID Connect
Spørgsmål og svar
Skal vi forbinde direkte til bankerne eller via en aggregator?
En aggregator giver dig mange banker via ét API og håndterer forskellene mellem bankerne, til en pris pr. kald eller pr. forbindelse. Direkte forbindelser giver mere kontrol og kan passe til et lille antal vigtige banker. Mange produkter starter med en aggregator og tilføjer direkte forbindelser senere. Vi sammenligner mulighederne ud fra de banker og lande, du har brug for.
Skal vi have en tilladelse for at bruge open banking?
Kontooplysningstjenester og betalingsinitiering er regulerede aktiviteter i mange lande. Enten har din virksomhed selv tilladelsen, eller også arbejder du via en autoriseret udbyder, der har den. Hvad der gælder, afhænger af dit land og dit anvendelsestilfælde, og dine juridiske rådgivere og compliancerådgivere bør bekræfte det. Vi bygger integrationen, uanset hvilken vej du vælger.
Hvordan håndteres kundens samtykke?
Kunden ser, hvilke data der deles, til hvilket formål og hvor længe, og godkender sig hos sin egen bank. Konnektoren gemmer samtykket og dets tokens krypteret, og hvert kald er knyttet til et gyldigt samtykke. Kunderne kan trække samtykket tilbage, og så stopper konnektoren med at kalde den bank på deres vegne.
Hvilke banker og lande er omfattet?
Dækningen afhænger af regionens regler og bankernes API’er. Den Europæiske Union og Storbritannien har bred dækning under PSD2 og UK Open Banking Standard. Andre steder varierer dækningen, og aggregatorer udfylder nogle af hullerne. Vi kontrollerer dækningen for de banker, dine kunder bruger, før du beslutter dig for et design.
Erstatter open banking host-to-host-bankforbindelser?
Ikke for det meste af virksomhedernes treasuryarbejde. Host-to-host-kanaler håndterer bulkbetalingsfiler og fulde kontoudtog for dine egne konti. Open banking passer til kundevendte produkter, saldi i realtid og enkeltbetalinger. Mange virksomheder bruger begge dele: host-to-host til deres egne betalingskørsler og open banking til deres kunder.
Hvordan beskyttes data fra open banking?
Tokens og samtykkeregistreringer krypteres ved lagring, kun konnektoren kan bruge dem, og hvert kald logges med det samtykke, der ligger bag. Vi indsamler kun de data, formålet kræver, og fastsætter, hvor længe de opbevares. Databeskyttelsesregler som GDPR gælder for disse data, og vi designer sammen med din databeskyttelsesrådgiver (DPO).
Start med en samtale, ikke en kontrakt.
Fortæl os, hvad du skal bygge, forbinde eller sikre. En arkitekt gennemgår det med dig og anbefaler derefter, hvor du skal starte.
Det sker der nu
Aftale om tidspunkt
Vores team sender dig en e-mail for at aftale et tidspunkt for sessionen.
Forhåndskonsultation
En gratis online forhåndskonsultation på 30 minutter: vi gennemgår dine mål, systemer og begrænsninger.
Parathedsanalyse
I en gratis parathedsanalyse på 48 timer tjekker en ledende arkitekt dit projekt op mod de 6 punkter i Definition of Ready og anbefaler det spor, der passer.
Valg af spor
Projekter med et klart omfang modtager et bindende forslag inden for 3 til 5 hverdage. Projekter i konceptfasen starter i Blueprint Studio. Et system i drift, der fejler, er udokumenteret eller skal integreres, starter med en diagnosticering på 1 til 2 uger. Blueprint Studio og diagnosticeringen har hver et fast honorar, som er angivet i forslaget.