Open banking-API-er
Open banking: kontodata og betalinger gjennom bank-API-er
Kontoinformasjon og betalingsinitiering gjennom regulerte bank-API-er og aggregatorer, med håndtering av samtykke og tokens.
Blueprint
Rull sidelengs for å se hele tegningen.
Open banking: data og betalinger med kundens samtykke
Kunden gir samtykke, koblingen holder tokenene, og hvert kall til banken autoriseres og logges. Når samtykket utløper eller trekkes tilbake, spør appen kunden på nytt i stedet for å feile i det stille.
- Hovedforløp
- Asynkron
- Unntaksbane
Forløpet i 7 steg
Forløpet, steg for steg
- Fra Kunde til Appen eller plattformen din: Gir samtykke (hovedforløp).
- Fra Appen eller plattformen din til Open banking-kobling: Konto- og betalingsforespørsler, over REST/JSON (hovedforløp).
- Fra Open banking-kobling til Bank-API-er eller aggregator: Autoriserte API-kall, over OAuth 2.0 · FAPI · REST (hovedforløp).
- Fra Bank-API-er eller aggregator til Open banking-kobling: Saldoer, transaksjoner og betalingsstatus, over REST/JSON · webhook (asynkron).
- Fra Open banking-kobling til ERP eller hovedbok: Normaliserte transaksjoner, over REST/JSON (hovedforløp).
- Fra Bank-API-er eller aggregator til Open banking-kobling: Samtykke utløpt eller trukket tilbake, over HTTP 401 · 403 (unntaksbane).
- Fra Open banking-kobling til Appen eller plattformen din: Kunden bes fornye samtykket (unntaksbane).
Oversikt
Open banking lar en applikasjon lese kundens kontoer og starte betalinger gjennom regulerte bank-API-er, med kundens samtykke. Det gir kontosamling, betjeningsevnevurderinger ved utlån, betaling med bank i kassen og treasury-oversikter på tvers av banker.
Referansedesignet plasserer en open banking-kobling mellom applikasjonen din og bankene, enten direkte eller gjennom en aggregator med konsesjon. Koblingen kjører samtykkeflyten, oppbevarer tokens sikkert, kaller bank-API-ene etter standarder som Berlin Group NextGenPSD2 eller UK Open Banking Standard, og gjør hver banks data om til én felles modell.
Samtykke er ikke varig, og designet tar høyde for det. Når samtykket utløper eller trekkes tilbake, blir kunden bedt om å fornye det, i stedet for at applikasjonen stille mister data. Hvert kall er autorisert, logget og knyttet til samtykket som tillot det.
Slik fungerer flyten
Kunden gir samtykke
Kunden velger banken sin, ser hva som deles og hvor lenge, og autentiserer seg hos banken, som sender kunden tilbake til applikasjonen din.
Applikasjonen din spør
Applikasjonen din ber om saldoer, transaksjoner eller en betaling gjennom koblingens API, aldri direkte gjennom banken.
Koblingen kaller banken
Koblingen bruker de lagrede tokenene til å gjøre autoriserte kall til bankens API eller aggregatoren, etter sikkerhetsprofilen banken krever.
Data og status kommer tilbake
Saldoer, transaksjoner og betalingsstatus kommer tilbake som svar eller webhooks, og koblingen normaliserer dem til én modell på tvers av banker.
Bruk dataene
Normaliserte transaksjoner går til produktet ditt, risikomodellene dine eller ERP-systemet for kontantposisjoner og avstemming.
Når noe feiler
Samtykket utløper eller trekkes tilbake
Banken avviser kallet. Koblingen markerer samtykket som ikke lenger gyldig, og applikasjonen din ber kunden fornye det og forklarer hvorfor.
En betaling avvises
Bankens status og årsak kommer tilbake gjennom API-et eller en webhook, og kunden og driftsteamet ditt ser resultatet med en gang.
En bank begrenser tilgangen
Banker begrenser hvor ofte data kan hentes uten at kunden er til stede. Koblingen planlegger oppdateringer innenfor disse grensene og venter lenger når en bank signaliserer det.
Et bank-API er utilgjengelig
Kallene forsøkes på nytt med økende ventetid, de siste gode dataene vises med alderen sin, og det sendes et varsel hvis driftsstansen fortsetter.
Standarder og systemer
- Bankstandarder og bankkanaler
- PSD2
- Berlin Group NextGenPSD2
- UK Open Banking Standard
- FAPI
- Integrasjon
- REST
- Webhooks
- Identitet og tilgang
- OAuth 2.0
- OpenID Connect
Spørsmål og svar
Bør vi koble oss til banker direkte eller gjennom en aggregator?
En aggregator gir deg mange banker gjennom ett API og håndterer forskjellene mellom bankene, til en kostnad per kall eller per tilkobling. Direkte tilkoblinger gir mer kontroll og kan passe for et lite antall viktige banker. Mange produkter starter med en aggregator og legger til direkte tilkoblinger senere. Vi sammenligner alternativene mot bankene og landene du trenger.
Trenger du konsesjon for å bruke open banking?
Kontoinformasjon og betalingsinitiering er regulerte aktiviteter i mange land. Enten har selskapet ditt tillatelsen, eller du arbeider gjennom en leverandør med konsesjon som har den. Hvilket som gjelder, avhenger av landet ditt og brukstilfellet, og juridiske rådgivere og rådgivere for etterlevelse bør bekrefte det. Vi bygger integrasjonen for den veien du velger.
Hvordan håndteres kundens samtykke?
Kunden ser hvilke data som deles, til hvilket formål og hvor lenge, og autentiserer seg med sin egen bank. Koblingen lagrer samtykket og tokenene kryptert, og hvert kall er knyttet til et gyldig samtykke. Kunden kan trekke tilbake samtykket, og koblingen slutter da å kalle den banken for kunden.
Hvilke banker og land dekkes?
Dekningen avhenger av reglene i regionen og bankenes API-er. EU og Storbritannia har bred dekning under PSD2 og UK Open Banking Standard. Andre steder varierer dekningen, og aggregatorer fyller noen av hullene. Vi sjekker dekningen for bankene kundene dine bruker før du bestemmer deg for en løsning.
Erstatter open banking host-to-host-tilkoblinger til banken?
Ikke for det meste av treasury-arbeidet i bedrifter. Host-to-host-kanaler håndterer store betalingsfiler og fullstendige kontoutskrifter for egne kontoer. Open banking passer for kundevendte produkter, sanntidssaldoer og enkeltbetalinger. Mange virksomheter bruker begge: host-to-host for egne betalingskjøringer og open banking for kundene sine.
Hvordan beskyttes data i open banking?
Token og samtykkeposter er kryptert i ro, bare koblingen kan bruke dem, og hvert kall logges med samtykket bak. Vi samler bare inn dataene formålet krever og fastsetter hvor lenge de oppbevares. Personvernregler som GDPR gjelder for disse dataene, og vi designer sammen med personvernombudet ditt.
Start med en samtale, ikke en kontrakt.
Fortell oss hva du trenger å bygge, koble sammen eller sikre. En arkitekt går gjennom det med deg og anbefaler deretter hvor du bør starte.
Hva skjer videre
Avtale tid
Teamet vårt sender deg en e-post for å avtale tid til samtalen.
Forhåndssamtale
En gratis forhåndssamtale på 30 minutter på nett: vi går gjennom målene, systemene og begrensningene dine.
Modenhetsvurdering
I en gratis modenhetsvurdering innen 48 timer kontrollerer en ledende arkitekt prosjektet ditt mot definisjonen av klar (6 punkter) og anbefaler sporet som passer.
Valg av spor
Prosjekter med definert omfang får et bindende forslag innen 3 til 5 virkedager. Prosjekter i konseptfasen starter i Blueprint Studio. Et system i drift som svikter, er udokumentert eller trenger integrasjon, starter med en diagnose på 1 til 2 uker. Blueprint Studio og diagnosen har hver en fastpris som angis i forslaget.