Wat is open banking via PSD2 precies?
Kort antwoord
Open banking is het via een API uitlezen van bankgegevens, met toestemming van de rekeninghouder. De Europese betaalrichtlijn PSD2 verplicht banken om die toegang te geven aan partijen met een vergunning. Je software kan zo saldi en transacties automatisch ophalen, mits de klant de toegang elke 180 dagen bevestigt bij zijn eigen bank.
Banktransacties zijn de ruggengraat van veel bedrijfsprocessen. Een factuur is pas betaald als het geld er is, een huurder pas achterstallig als de huur niet binnenkwam, en een liquiditeitsprognose is pas iets waard als hij op het echte saldo begint. Toch komen die transacties in veel organisaties nog binnen via een handmatige export uit internetbankieren, of één keer per dag via een afschriftbestand.
Open banking maakt dat anders. Je software vraagt de transacties zelf op, wanneer het nodig is, en dat werkt niet alleen voor je eigen zakelijke rekening maar ook voor de rekeningen van je klanten. In dit artikel leg ik uit hoe dat technisch en juridisch in elkaar zit, waar je een vergunning voor nodig hebt, en welke ontwerpkeuzes het verschil maken tussen een koppeling die blijft werken en een die na een half jaar stilletjes stopt.
De twee diensten: rekeninginformatie en betaalinitiatie
PSD2, de tweede Europese betaaldienstenrichtlijn, opende de bankrekening voor derde partijen. Daarbij onderscheidt de richtlijn twee nieuwe diensten, die in de praktijk met hun Engelse afkortingen worden aangeduid.
- Rekeninginformatie (AIS): het uitlezen van saldi, transacties en de naam van de rekeninghouder. De partij die dat doet heet een rekeninginformatiedienstverlener, of AISP. Dit is de dienst die je nodig hebt voor afletteren, cashflowinzicht, kredietbeoordeling en boekhouding.
- Betaalinitiatie (PIS): namens de klant een betaling klaarzetten, die de klant vervolgens bij zijn eigen bank goedkeurt. Dit is de techniek achter "betalen via je bank" en zit dichter bij wat je kent van iDEAL en Wero.
Dit artikel gaat over de eerste: banktransacties ophalen. Betaalinitiatie is een vak apart, met eigen fraude- en aansprakelijkheidsvragen.
Hoe de toestemming werkt
De klant geeft toestemming bij zijn eigen bank, niet bij jou. De flow ziet er in grote lijnen zo uit:
- Je software vraagt toegang aan: voor een specifieke rekening, voor een specifiek doel (bijvoorbeeld saldi en transacties) en voor een bepaalde periode.
- De klant wordt doorgestuurd naar zijn bank: daar logt hij in en bevestigt met sterke klantauthenticatie, dezelfde inlog als bij internetbankieren. Meer over die authenticatie lees je in ons artikel over 3D Secure en SCA.
- De bank geeft een toegangstoken terug: met dat token mag je binnen de afgesproken grenzen gegevens opvragen, zonder dat je ooit de inloggegevens van de klant ziet.
- Na verloop van tijd vervalt de toegang: en moet de klant opnieuw bevestigen. Daarover verderop meer, want dit is de plek waar koppelingen in de praktijk misgaan.
Dat de klant nooit zijn wachtwoord aan jou geeft, is precies het punt. Vóór PSD2 werkte een deel van de markt met screen scraping: inloggen met de gegevens van de klant en de webpagina van de bank uitlezen. Dat is onder PSD2 voor deze toepassing vervangen door een gereguleerde API.
Wie mag banktransacties ophalen?
Hier zit de eerste ontwerpkeuze, en die is juridisch, niet technisch. Banken geven hun PSD2-API alleen vrij aan partijen met een vergunning of registratie. ABN AMRO stelt bijvoorbeeld dat elke rekeninginformatiedienstverlener met een PSD2-vergunning de API mag gebruiken, en vraagt daarnaast een gekwalificeerd eIDAS-certificaat om de partij te identificeren. Rabobank vraagt eveneens een vergunning van de nationale toezichthouder, en biedt een sandbox om te testen voordat je in productie gaat.
De vraag is dus niet "kan ik de API van de bank aanroepen?", maar "wie is in mijn constructie de partij die de dienst levert?".
Wat DNB zegt over uitbesteding en ketens
De Nederlandsche Bank heeft een vraag-en-antwoord gepubliceerd over vergunningplicht bij uitbesteding en meerdere partijen. De kern, vertaald naar softwareprojecten:
- Wie een overeenkomst sluit met de rekeninghouder om rekeninginformatie te leveren, heeft een vergunning nodig. Dat is de partij die richting de klant verantwoordelijk is.
- Een partij die alleen technisch het ophalen verzorgt kan zonder eigen vergunning werken, maar alleen als die geen toegang heeft tot de betaalgegevens van de rekeninghouder en geen beveiligingstokens beheert.
- Een partij die al opgehaalde gegevens verwerkt, terwijl de gebruiker een overeenkomst heeft met de vergunninghouder die de gegevens ophaalde, valt buiten PSD2.
Voor de meeste bedrijven die open banking in hun eigen software willen, is de praktische route daarom een aggregator: een partij met een vergunning die de koppelingen met honderden Europese banken onderhoudt, de toestemmingsflow aanbiedt en de gegevens in één uniform formaat doorgeeft. Voorbeelden in de Europese markt zijn Ponto, Tink en Enable Banking. Je software verwerkt dan de gegevens die de aggregator voor jouw klant ophaalt. Welke variant voor jouw situatie geldt, laat je toetsen door een jurist met betaalrecht in zijn pakket; de grens tussen "verwerken" en "zelf leveren" is in een contract sneller overschreden dan in de code.
De lastigste vraag bij open banking staat niet in de API-documentatie, maar in je contract: wie levert de dienst aan de rekeninghouder?
Rechtstreeks of via een aggregator
| Kenmerk | Rechtstreeks bij de banken | Via een aggregator |
|---|---|---|
| Vergunning | Eigen PSD2-vergunning of registratie nodig | Ligt bij de aggregator, mits je constructie klopt |
| Certificaten | Eigen eIDAS-certificaten beheren | Geregeld door de aggregator |
| Bankdekking | Eén koppeling per bank, elk met eigen afwijkingen | Eén API voor veel Europese banken |
| Onderhoud | Jij volgt elke wijziging van elke bank | De aggregator vangt bankwijzigingen op |
| Afhankelijkheid | Alleen van de banken | Ook van de aggregator; plan een uitwijkroute |
| Past bij | Financiële instellingen en fintechs met eigen toezicht | Vrijwel alle andere software |
De techniek: één standaard, veel dialecten
De meeste Europese banken bouwen hun PSD2-API op de NextGenPSD2-standaard van de Berlin Group, een gezamenlijk Europees API-raamwerk. Dat klinkt als één interface, maar in de praktijk implementeert elke bank de standaard op zijn eigen manier: andere velden verplicht, een andere manier van redirecten, een andere invulling van de omschrijving bij een transactie. Dat is een belangrijke reden waarom aggregators bestaan.
Wat je in elk geval terugkrijgt, ongeacht de route:
- Rekeningen: IBAN, valuta, de naam van de rekening en vaak de naam van de rekeninghouder.
- Saldi: meestal meerdere soorten, zoals het geboekte saldo en het beschikbare saldo. Leg in je software vast welk saldo je toont, want ze verschillen.
- Transacties: bedrag, datum, tegenrekening, naam van de tegenpartij en de omschrijving of het betalingskenmerk. Vaak onderscheiden in geboekte en nog niet geboekte transacties.
Ontwerpkeuzes die je vooraf moet maken
- Een eigen, stabiele sleutel per transactie: niet elke bank levert een unieke en blijvende transactie-ID. Wie dezelfde periode twee keer ophaalt, krijgt anders dubbele regels. Bouw de verwerking idempotent, zodat opnieuw ophalen nooit dubbel boekt.
- Nog niet geboekte transacties apart behandelen: een openstaande transactie kan nog veranderen of verdwijnen. Lettert je software daar al facturen mee af, dan moet hij dat ook kunnen terugdraaien.
- Ophaalfrequentie bewust kiezen: banken beperken hoe vaak je zonder actieve klant gegevens mag opvragen. Haal op met een vast ritme en niet bij elke paginaweergave, en sla de resultaten op.
- De historie in één keer ophalen bij de eerste koppeling: hoe ver je terug kunt, verschilt per bank en per aggregator. Wil je een maand of meer historie, haal die direct na de toestemming op.
- Eén datamodel voor alle bronnen: open banking, een CAMT.053-afschrift en de uitbetalingen van je betaaldienstverlener landen idealiter in dezelfde tabel met transacties, met een veld dat de bron aangeeft. Dan werkt je matchinglogica op alles.
De 180-dagenregel: waarom koppelingen stilletjes stoppen
De toegang die een klant geeft, is niet voor altijd. Oorspronkelijk moest de klant elke 90 dagen opnieuw bevestigen met sterke klantauthenticatie. Met Gedelegeerde Verordening (EU) 2022/2360 is die termijn verlengd naar 180 dagen, van toepassing sinds 25 juli 2023. De wijziging volgt op een voorstel van de Europese Bankautoriteit, die tegelijk een verplichte uitzondering invoerde: banken mogen bij toegang via een rekeninginformatiedienst binnen die periode geen extra authenticatie meer eisen.
In gewone taal: twee keer per jaar moet je klant even naar zijn bank om te bevestigen dat jouw software zijn transacties nog mag zien. Doet hij dat niet, dan stopt de stroom transacties. En dat gebeurt meestal zonder foutmelding die iemand opvalt: er komt gewoon niets meer binnen. Facturen blijven open staan, herinneringen gaan de deur uit naar klanten die allang betaald hebben.
Een open banking-koppeling faalt zelden met een foutmelding. Hij faalt met stilte, 180 dagen na de dag dat hij werkte.
Wat je software daarom moet doen:
- De vervaldatum van elke toestemming opslaan: niet afleiden uit de laatste geslaagde aanroep, maar expliciet bewaren wat de bank of aggregator teruggeeft.
- Ruim van tevoren waarschuwen: een melding in de applicatie en een e-mail, enkele weken voor het verlopen, met een directe link naar de verlengflow.
- Verlopen toegang zichtbaar maken: een rekening zonder geldige toestemming hoort in het dashboard rood op te lichten, niet ongemerkt leeg te blijven.
- Gaten na verlenging opvullen: na een nieuwe toestemming haal je de periode op waarin de koppeling stillag, zodat er geen transacties ontbreken.
Privacy: banktransacties zijn gevoelige gegevens
Een transactieoverzicht vertelt veel meer dan je nodig hebt. Wie bij welke zorgverlener betaalt, welke vakbond of kerk een contributie ontvangt, of er een incassobureau op de afschriften staat. Ook als je de gegevens alleen ophaalt om facturen af te letteren, komen al die regels mee.
Dat vraagt om keuzes in het ontwerp, in lijn met wat we schrijven over AVG in webapplicaties:
- Doelbinding: leg vast waarvoor je de gegevens ophaalt, en gebruik ze niet ongemerkt voor iets anders, zoals marketing of kredietbeoordeling.
- Minimaliseren: heb je alleen inkomende betalingen nodig, sla de uitgaande dan niet op, of verwijder ze direct na verwerking.
- Bewaartermijn: bewaar ruwe bankdata niet langer dan nodig. Het afgeletterde resultaat (factuur X is betaald op datum Y) is meestal genoeg voor je administratie.
- Toegang: niet elke medewerker hoeft volledige transactieoverzichten te zien. Beperk dat tot de rollen die er echt mee werken, en houd een audit trail bij van wie wat heeft ingezien.
Wanneer open banking, en wanneer een afschriftbestand?
Open banking is niet in elke situatie de beste keuze. Voor je eigen zakelijke rekening is een dagelijks CAMT.053-afschrift vaak de stabielere bron: volledig, zonder verlopende toestemming, en rechtstreeks van je eigen bank. Open banking wint wanneer:
- Het om rekeningen van je klanten gaat: bijvoorbeeld een platform dat de administratie van ondernemers bijhoudt, of software die de betaalstatus bij huurders of leden moet kennen.
- Snelheid telt: een betaling die binnen minuten zichtbaar moet zijn, bijvoorbeeld om een levering vrij te geven, wacht niet op het afschrift van morgen.
- Er veel verschillende banken in het spel zijn: één API via een aggregator is dan eenvoudiger dan bestanden van elke bank afzonderlijk.
In de praktijk combineren goede systemen beide. Het afschrift is de volledige, betrouwbare waarheid voor de eigen rekening; open banking geeft het tussentijdse beeld en de rekeningen van derden. Met PSD3 en de PSR worden de bank-API's bovendien strenger geregeld, zoals we uitleggen in ons artikel over de nieuwe EU-betaalregels. Wie nu bouwt, bouwt dus op een fundament dat de komende jaren eerder sterker dan zwakker wordt.
Mijn kijk op open banking in maatwerk
Open banking wordt vaak verkocht als een technische koppeling: een API, een token, klaar. Dat deel is in een paar dagen te bouwen. Wat tijd kost, is alles eromheen. Wie is juridisch de dienstverlener? Wat gebeurt er als de toestemming verloopt? Hoe voorkom je dubbele transacties als een bank geen stabiele ID meegeeft? En wie mag die transacties in de applicatie eigenlijk zien?
Mijn advies is dan ook om klein te beginnen met een duidelijke vraag. "We willen weten welke facturen betaald zijn" is een goede vraag; "we willen alle bankdata van al onze klanten" is dat niet. Hoe smaller het doel, hoe eenvoudiger de privacy, hoe kleiner de impact als de koppeling een keer hapert. En bouw de verlengflow voor de toestemming vanaf de eerste dag mee. Ik heb nog geen open banking-koppeling gezien waar dat achteraf niet de belangrijkste ontbrekende functie bleek.
Voor eigen zakelijke rekeningen blijf ik bovendien een voorstander van het saaie afschriftbestand als basis. Realtime is prettig, maar volledig en betrouwbaar is belangrijker voor de boekhouding.
— Jasper
Zo helpt Coding Agency hierbij
Wij bouwen bankkoppelingen in maatwerksoftware en platformen: via een aggregator met een PSD2-vergunning of via CAMT.053-afschriften, met een gezamenlijk datamodel voor alle transacties, idempotente verwerking, bewaking van verlopende toestemmingen en matchinglogica die betalingen automatisch aflettert. Ook de koppeling naar je boekhoudpakket nemen we mee.
Wil je banktransacties automatisch in je eigen software, of loopt een bestaande koppeling regelmatig vast? Neem contact op voor een vrijblijvend gesprek.
