API:er för open banking
Open banking: kontodata och betalningar via bankernas API:er
Kontoinformation och betalningsinitiering via reglerade bank-API:er och aggregatorer, med hantering av samtycken och tokens.
Ritning
Rulla i sidled för att se hela ritningen.
Open banking: data och betalningar med kundens samtycke
Kunden lämnar samtycke, anslutningen håller tokens, och varje anrop till banken auktoriseras och loggas. När samtycket löper ut eller dras tillbaka frågar appen kunden igen i stället för att fallera tyst.
- Primärt flöde
- Asynkront
- Undantagsväg
Flödet i 7 steg
Flödet, steg för steg
- Från Kund till Din app eller plattform: Lämnar samtycke (primärt flöde).
- Från Din app eller plattform till Open banking-anslutning: Konto- och betalningsbegäranden, över REST/JSON (primärt flöde).
- Från Open banking-anslutning till Bank-API:er eller aggregator: Auktoriserade API-anrop, över OAuth 2.0 · FAPI · REST (primärt flöde).
- Från Bank-API:er eller aggregator till Open banking-anslutning: Saldon, transaktioner och betalningsstatus, över REST/JSON · webhook (asynkront).
- Från Open banking-anslutning till ERP eller huvudbok: Normaliserade transaktioner, över REST/JSON (primärt flöde).
- Från Bank-API:er eller aggregator till Open banking-anslutning: Samtycket har löpt ut eller dragits tillbaka, över HTTP 401 · 403 (undantagsväg).
- Från Open banking-anslutning till Din app eller plattform: Kunden ombeds förnya samtycket (undantagsväg).
Översikt
Open banking låter en applikation läsa en kunds konton och starta betalningar via reglerade bank-API:er, med kundens samtycke. Det driver kontosammanställning, kreditprövning för utlåning, betalning via bank i näthandelskassan och treasury-vyer över flera banker.
Referensdesignen lägger en koppling för open banking mellan din applikation och bankerna, antingen direkt eller via en licensierad aggregator. Kopplingen genomför samtyckesresan, förvarar tokens säkert, anropar bankernas API:er enligt standarder som Berlin Group NextGenPSD2 eller UK Open Banking Standard och omvandlar varje banks data till en enhetlig modell.
Ett samtycke är inte permanent, och designen tar höjd för det. När samtycket går ut eller återkallas ombeds kunden förnya det i stället för att applikationen tyst tappar data. Varje anrop auktoriseras, loggas och knyts till det samtycke som tillät det.
Så fungerar flödet
Kunden lämnar samtycke
Kunden väljer bank, ser vad som delas och hur länge, och autentiserar sig hos banken, som skickar tillbaka till din applikation.
Din applikation frågar
Din applikation begär saldon, transaktioner eller en betalning via kopplingens API, aldrig direkt från banken.
Kopplingen anropar banken
Kopplingen använder de lagrade tokens för att göra auktoriserade anrop till bankens API eller aggregatorn, enligt den säkerhetsprofil banken kräver.
Data och status kommer tillbaka
Saldon, transaktioner och betalningsstatus kommer tillbaka som svar eller webhooks, och kopplingen normaliserar dem till en modell över alla banker.
Använd datan
Normaliserade transaktioner går till din produkt, dina riskmodeller eller ditt ERP-system för kassapositioner och avstämning.
När något går fel
Samtycket går ut eller återkallas
Banken avvisar anropet. Kopplingen markerar samtycket som ogiltigt och din applikation ber kunden förnya det och förklarar varför.
En betalning avvisas
Bankens status och orsak kommer tillbaka via API:et eller en webhook, och kunden och ditt operationsteam ser resultatet direkt.
En bank begränsar åtkomsten
Bankerna begränsar hur ofta data får hämtas utan kunden närvarande. Kopplingen schemalägger uppdateringar inom dessa gränser och backar av när en bank signalerar det.
Ett bank-API är otillgängligt
Anropen görs om med ökande väntetider, den senaste fungerande datan visas med sin ålder och ett larm går ut om avbrottet fortsätter.
Standarder och system
- Bankstandarder och kanaler
- PSD2
- Berlin Group NextGenPSD2
- UK Open Banking Standard
- FAPI
- Integration
- REST
- Webhooks
- Identitet och åtkomst
- OAuth 2.0
- OpenID Connect
Frågor och svar
Bör bankerna kopplas in direkt eller via en aggregator?
En aggregator ger många banker genom ett API och hanterar skillnaderna mellan dem, till en kostnad per anrop eller per koppling. Direkta kopplingar ger mer kontroll och kan passa ett litet antal viktiga banker. Många produkter börjar med en aggregator och lägger till direkta kopplingar senare. Vi jämför alternativen mot de banker och länder du behöver.
Krävs det tillstånd för att använda open banking?
Kontoinformation och betalningsinitiering är reglerade verksamheter i många länder. Antingen har ditt företag tillståndet, eller så arbetar du via en licensierad leverantör som har det. Vilket som gäller beror på ditt land och ditt användningsfall, och dina juridiska rådgivare och regelefterlevnadsspecialister bör bekräfta det. Vi bygger integrationen för den väg du väljer.
Hur hanteras kundens samtycke?
Kunden ser vilken data som delas, i vilket syfte och hur länge, och autentiserar sig hos sin egen bank. Kopplingen lagrar samtycket och dess tokens krypterat, och varje anrop knyts till ett giltigt samtycke. Kunder kan återkalla sitt samtycke, och kopplingen slutar då anropa den banken för deras del.
Vilka banker och länder omfattas?
Täckningen beror på reglerna i regionen och bankernas API:er. Europeiska unionen och Storbritannien har bred täckning enligt PSD2 och UK Open Banking Standard. På andra håll varierar täckningen, och aggregatorer fyller en del av luckorna. Vi kontrollerar täckningen för de banker dina kunder använder innan du binder dig till en design.
Ersätter open banking host-to-host-kopplingar till banker?
Inte för det mesta av företagens treasuryarbete. Host-to-host-kanaler hanterar betalningsfiler i bulk och fullständiga kontoutdrag för de egna kontona. Open banking passar kundvända produkter, saldon i realtid och enstaka betalningar. Många företag använder båda: host-to-host för sina egna betalningskörningar och open banking för sina kunder.
Hur skyddas data i open banking?
Tokens och samtyckesregister lagras krypterade, bara kopplingen kan använda dem och varje anrop loggas med samtycket bakom. Vi samlar bara in den data som syftet kräver och bestämmer hur länge den sparas. Dataskyddsregler som GDPR gäller för den här datan, och vi utformar tillsammans med ditt dataskyddsombud.
Börja med ett samtal, inte ett avtal.
Berätta vad du behöver bygga, koppla samman eller skydda. En arkitekt går igenom det med dig och rekommenderar sedan var du ska börja.
Vad som händer härnäst
Vi enas om en tid
Vårt team mejlar dig för att enas om en tid för samtalet.
Förberedande samtal
En kostnadsfri förkonsultation online i 30 minuter: vi går igenom dina mål, system och begränsningar.
Mognadsgenomgång
I en kostnadsfri mognadsgenomgång på 48 timmar prövar en ledande arkitekt ditt projekt mot de sex kriterierna för Definition of Ready och rekommenderar det spår som passar.
Val av spår
Projekt med tydlig omfattning får ett bindande förslag inom 3 till 5 arbetsdagar. Projekt i konceptfasen börjar i Blueprint Studio. Ett system i drift som fallerar, är odokumenterat eller behöver integreras börjar med en diagnostik på 1 till 2 veckor. Blueprint Studio och diagnostiken har var sitt fasta pris som anges i förslaget.