Openbanking-API’s
Open banking: rekeningdata en betalingen via bank-API’s
Rekeninginformatie en betalingsinitiatie via gereguleerde bank-API’s en aggregators, met afhandeling van toestemming en tokens.
Blauwdruk
Scroll zijwaarts om de hele tekening te zien.
Open banking: data en betalingen met toestemming van de klant
De klant geeft toestemming, de connector bewaart de tokens en elke aanroep naar de bank wordt geautoriseerd en gelogd. Wanneer toestemming verloopt of wordt ingetrokken, vraagt de app de klant opnieuw in plaats van stil te falen.
- Hoofdstroom
- Asynchroon
- Uitzonderingspad
De stroom in 7 stappen
De stroom, stap voor stap
- Van Klant naar Uw app of platform: Geeft toestemming (hoofdstroom).
- Van Uw app of platform naar Open-bankingconnector: Account- en betalingsverzoeken, via REST/JSON (hoofdstroom).
- Van Open-bankingconnector naar Bank-API’s of aggregator: Geautoriseerde API-aanroepen, via OAuth 2.0 · FAPI · REST (hoofdstroom).
- Van Bank-API’s of aggregator naar Open-bankingconnector: Saldi, transacties en betalingsstatus, via REST/JSON · webhook (asynchroon).
- Van Open-bankingconnector naar ERP of grootboek: Genormaliseerde transacties, via REST/JSON (hoofdstroom).
- Van Bank-API’s of aggregator naar Open-bankingconnector: Toestemming verlopen of ingetrokken, via HTTP 401 · 403 (uitzonderingspad).
- Van Open-bankingconnector naar Uw app of platform: Klant gevraagd toestemming te vernieuwen (uitzonderingspad).
Overzicht
Open banking laat een applicatie de rekeningen van een klant lezen en betalingen starten via gereguleerde bank-API’s, met toestemming van de klant. Het ondersteunt rekeningaggregatie, betaalbaarheidscontroles voor krediet, pay-by-bank-checkouts en treasuryoverzichten over banken heen.
Het referentieontwerp plaatst een openbanking-connector tussen uw applicatie en de banken, rechtstreeks of via een gelicentieerde aggregator. De connector doorloopt de toestemmingsreis, bewaart de tokens veilig, roept de bank-API’s aan volgens standaarden zoals Berlin Group NextGenPSD2 of de UK Open Banking Standard, en zet de data van elke bank om in één consistent model.
Toestemming is niet permanent, en het ontwerp houdt daar rekening mee. Wanneer toestemming verloopt of wordt ingetrokken, wordt de klant gevraagd die te verlengen in plaats van dat de applicatie stil data verliest. Elke aanroep is geautoriseerd, gelogd en gekoppeld aan de toestemming die hem mogelijk maakte.
Hoe de flow werkt
De klant geeft toestemming
De klant kiest zijn bank, ziet welke data wordt gedeeld en hoe lang, en authenticeert bij de bank, die terugverwijst naar uw applicatie.
Uw applicatie vraagt
Uw applicatie vraagt saldi, transacties of een betaling aan via de API van de connector, nooit rechtstreeks via de bank.
De connector roept de bank aan
De connector gebruikt de opgeslagen tokens om geautoriseerde aanroepen te doen naar de API van de bank of de aggregator, volgens het beveiligingsprofiel dat de bank vereist.
Data en status komen terug
Saldi, transacties en betaalstatus komen terug als responses of webhooks, en de connector normaliseert ze naar één model over banken heen.
Gebruik de data
Genormaliseerde transacties voeden uw product, uw risicomodellen of uw ERP voor cashposities en afstemming.
Wat als er iets misgaat
Toestemming verloopt of wordt ingetrokken
De bank weigert de aanroep. De connector markeert de toestemming als niet langer geldig en uw applicatie vraagt de klant die te verlengen, met uitleg waarom.
Een betaling wordt afgewezen
De status en reden van de bank komen terug via de API of een webhook, en de klant en uw operationele team zien de uitkomst meteen.
Een bank beperkt de toegang
Banken beperken hoe vaak data mag worden opgehaald zonder dat de klant aanwezig is. De connector plant verversingen binnen die limieten en houdt afstand wanneer een bank dat signaleert.
Een bank-API is niet beschikbaar
Aanroepen worden opnieuw geprobeerd met toenemende vertraging, de laatste goede data wordt met zijn leeftijd getoond, en er volgt een melding als de storing aanhoudt.
Standaarden en systemen
- Bankstandaarden en -kanalen
- PSD2
- Berlin Group NextGenPSD2
- UK Open Banking Standard
- FAPI
- Integratie
- REST
- Webhooks
- Identiteit en toegang
- OAuth 2.0
- OpenID Connect
Vragen en antwoorden
Moeten we rechtstreeks op banken aansluiten of via een aggregator?
Een aggregator geeft u veel banken via één API en handelt de verschillen per bank af, tegen kosten per aanroep of per verbinding. Directe koppelingen geven meer controle en kunnen passen bij een klein aantal belangrijke banken. Veel producten beginnen met een aggregator en voegen later directe koppelingen toe. We vergelijken de opties tegen de banken en landen die u nodig hebt.
Hebben we een licentie nodig om open banking te gebruiken?
Rekeninginformatie en betalingsinitiatie zijn in veel landen gereguleerde activiteiten. Of uw bedrijf heeft de vergunning, of u werkt via een gelicentieerde provider die die heeft. Welke geldt, hangt af van uw land en toepassing, en uw juridische en complianceadviseurs moeten dat bevestigen. We bouwen de integratie voor de route die u kiest.
Hoe wordt de toestemming van de klant afgehandeld?
De klant ziet welke data wordt gedeeld, met welk doel en hoe lang, en authenticeert bij zijn eigen bank. De connector slaat de toestemming en de tokens versleuteld op, en elke aanroep is gekoppeld aan een geldige toestemming. Klanten kunnen toestemming intrekken, en de connector stopt dan met het aanroepen van die bank voor hen.
Welke banken en landen zijn gedekt?
Dekking hangt af van de regels in de regio en de API’s van de banken. De Europese Unie en het Verenigd Koninkrijk hebben brede dekking onder PSD2 en de UK Open Banking Standard. Elders varieert de dekking, en aggregators vullen sommige hiaten. We controleren de dekking voor de banken die uw klanten gebruiken voordat u zich aan een ontwerp vastlegt.
Vervangt open banking host-to-host-bankkoppelingen?
Niet voor de meeste corporate-treasurywerkzaamheden. Host-to-hostkanalen verwerken bulkbetalingsbestanden en volledige afschriften voor uw eigen rekeningen. Open banking past bij klantgerichte producten, realtime saldi en losse betalingen. Veel bedrijven gebruiken beide: host-to-host voor hun eigen betalingsruns en open banking voor hun klanten.
Hoe wordt openbankingdata beschermd?
Tokens en toestemmingsregistraties worden versleuteld bewaard, alleen de connector kan ze gebruiken, en elke aanroep wordt gelogd met de toestemming erachter. We verzamelen alleen de data die het doel nodig heeft en stellen vast hoe lang die wordt bewaard. Privacyregels zoals de AVG gelden voor deze data, en we ontwerpen met uw functionaris voor gegevensbescherming.
Begin met een gesprek, niet met een contract.
Vertel ons wat u wilt bouwen, verbinden of beveiligen. Een architect neemt het met u door en adviseert daarna waar te beginnen.
Wat er nu gebeurt
Een tijd afspreken
Ons team mailt u om een tijd voor de sessie af te spreken.
Voorgesprek
Een gratis online voorafgaand adviesgesprek van 30 minuten: we bespreken uw doelen, systemen en beperkingen.
Gereedheidsanalyse
In een gratis gereedheidsanalyse van 48 uur toetst een Principal Architect uw project aan de 6-punts Definition of Ready en adviseert het traject dat past.
Het traject kiezen
Projecten met een heldere scope ontvangen binnen 3–5 werkdagen een bindend voorstel. Projecten in de conceptfase starten in de Blueprint Studio. Een live systeem dat uitvalt, ongedocumenteerd is of integratie nodig heeft, begint met een diagnose van 1–2 weken. De Blueprint Studio en de diagnose hebben elk een vaste prijs, vermeld in het voorstel.