Nederlandse bank die een API vrijstelt?

[gijsgoudzwaard]

Dit is er waarschijnlijk niet maar ik hoop het toch van wel. Is er een Nederlandse bank die een API vrijsteld voor developers?
Je zou dus je eigen bank activiteiten op kunnen halen via die API.

Bestaat dit of komt dit eraan?

Ik hoor het graag!

[McKaamos]

Hang op, klik weg, bel uw bank!

Enige goede advies is je bank bellen, of als je overweegt om naar een andere bank te gaan, bel hen en stel die vraag.

Als het er nog niet is, misschien kan je dan je mobiele bank-app reverse engineeren.
Ik weet dat de SNS Bank een soort van permanente auth-token oid instelt waardoor je met je mobieltje geen key hoeft te genereren met de Digipas.
Uiteraard heeft dat beperkte rechten, maar je kan dan wel je saldo en transacties zien.

[NMe]

Een API voor je bankzaken? Speciaal om het voor kwaadwillenden nog makkelijker te maken om geld te stelen?

[TripleQ]

Indien juist geïmplementeerd hoeft dit de veiligheid toch niet per se te verergeren?

Maar om antwoord te geven op je vraag:
Nee, geen enkele Nederlandse bank bied dit aan....

En het reverse engineeren van bestaande apps (als je dat uberhaupt lukt) gaat vast tegen alle voorwaarden in ;-)

[Gomez12]

Wat wil je ermee?

Zakelijke bankrekeningen bieden wel functies voor batchbetalingen en overhalen van mutatie-overzichten etc aan. Enkel kost het wel geld (en de bestandsformaten zijn ietwat apart etc)

[NMe]

TripleQ schreef op maandag 24 augustus 2015 @ 22:21:
Indien juist geïmplementeerd hoeft dit de veiligheid toch niet per se te verergeren?

De veiligheid van de API an sich niet, maar als zo'n API bestaat is er vanzelf wel een jojo die het gaat misbruiken om zijn phishingsite authentieker te laten ogen. Dan haal je bijvoorbeeld volledig veilig via de API bij de bank de rekeninggegevens op, toont die aan de gebruiker en komt vervolgens met een melding dat hij zijn gegevens moet verifiëren (of iets dergelijks). Alles tot aan de laatste stap oogt authentiek en betrouwbaar.

Gomez12 schreef op maandag 24 augustus 2015 @ 22:25:
Zakelijke bankrekeningen bieden wel functies voor batchbetalingen en overhalen van mutatie-overzichten etc aan. Enkel kost het wel geld (en de bestandsformaten zijn ietwat apart etc)

offtopic:
Ik had inderdaad gehoopt dat de banken IBAN zouden aangrijpen om dat drama van een CLIEOP3 eens te verbeteren, maar naar wat ik er van een collega van begrepen heb is het nieuwe formaat vrijwel niet beter.

[Voor 28% gewijzigd door NMe op 24-08-2015 22:39]

[markvt]

Bij de meeste kan je wel exports draaien van je transacties.

Het bestandsformaat is bijvoorbeeld in Wikipedia: MT940

[lubbertkramer]

AFAS had toen een automatische koppeling met de banken maar deze is helaas offline gehaald door de banken. Inmiddels zijn er wel gesprekken maar komt het automatisch koppelen nog niet echt weer van de grond af en blijft een handmatige import nodig.

Een API hoeft van mij niet gelijk maar geef gecontroleerde partijen die een beter financieel overzicht kunnen leveren icm budgetten en dergelijke bijvoorbeeld een eigen ingang. Hier oa meer informatie - > Voortgang gesprekken met banken over bankkoppeling

[RayNbow]

Er is een API, ja, maar die is niet gedocumenteerd. De apps voor de Rabobank zijn bijv. na eenmalige registratie met de Random Reader/Rabo Scanner te gebruiken zonder de reader/scanner. Het enige wat nog nodig is een pincode en de cookies/etc. die je van de server ontvangen hebt.

[Firefly III]

-

[Voor 99% gewijzigd door Firefly III op 23-10-2016 15:36. Reden: Leeg vanwege privacy.]

[lubbertkramer]

Slarioux schreef op dinsdag 25 augustus 2015 @ 11:04:
Of misschien voor je spaargeld. Ik heb nu drie spaarrekeningen om verschillende spaardoelen uit elkaar te houden. Waarom kan ik geen potjes maken? Of iets anders hips? Er zijn wel "voorzieningen" maar echt veel is het nog niet.

Kijk eens bij Knab, zit ik zelf ook naast ABN voor de gezamenlijke rekening + spaarrekeningen. Principe is daar dat je een spaarrekening hebt en daaronder potjes maakt en het geld verdeeld. Zo hebben wij een potje woning/trouwerij, vakantie, cadeaus (voor fam/vrienden die jarig zijn of jubileum hebben) en ga zo maar verder. Werkt goed moet ik zeggen En kost trouwens niets extra, hoeveel potjes je ook maakt

[Voor 4% gewijzigd door lubbertkramer op 25-08-2015 11:10]

[Firefly III]

-

[Voor 103% gewijzigd door Firefly III op 23-10-2016 15:36. Reden: Leeg vanwege privacy.]

[PromWarMachine]

Zo'n API lijkt mij ook wel interessant.
Nu de meeste banken NFC ondersteunen, zouden API's ook best moeten kunnen.

NFC is ook 'voorzichtig' ingevoerd. Max. €25 per transactie, max €50/dag, schadeloos gesteld worden als er misbruik van gemaakt wordt, etc. Dat zijn prima kaders waarin een API ook gemaakt zou kunnen worden.

Daarnaast zou je onderscheid kunnen maken.
• Geen API
• Informatieve API (alleen saldi, transacties, spaardoelen, catogrieen, etc.)
• Functionele API (ook transacties doen, binnen kaders, zoals beschreven)

Default uit en je kunt het in je internetbankieren aanzetten.

Verder helemaal eens met Slarioux. Qua functionaliteiten mis ik nog ontzettend veel.
• Waarom moet ik (extra) betalen om mijn eigen transacties te laten categoriseren?
• Waarom kan ik niet per dag sparen?
• Waarom kan ik maar één spaardoel aangeven? Ik wil sparen voor computer, auto, vakantie, etc.
• Waarom kan ik niet dagelijks geld overschrijven naar X met variabele referentie Y.
• Waarom kan ik mijn transacties uit 2011 niet meer downloaden?

Zo kan ik nog wel even doorgaan.
Het budgetteren is ook een goede. Als AFAS automatisch kan bepalen dat mijn rekening van een tankstation in de categorie 'auto' valt, kan de bank dat ook van mijn auto budget afhalen inderdaad.

Dit alles zou bankieren en persoonlijke financien leuker kunnen maken.

[Standeman]

Ik denk dat ik niet snel een 3rd party app toegang ga geven tot mijn bankgegevens en zeker niet wanneer het closed source is.

[Gomez12]

Slarioux schreef op dinsdag 25 augustus 2015 @ 11:12:
[...]
Waar ik op hoop is dat dit soort API's er komen om derde partijen (of ikzelf met wat programmeerkennis) in staat te stellen ook met jouw/mijn eigen financiële gegevens aan de slag te gaan.

Ik denk dat dit er of nooit van komt, of je trekt als klant (als keuze) 100% van de verantwoordelijkheid naar je toe over wat er gebeurt met je geld...

Het probleem hiermee zit hem niet in beveiliging, maar vooral in vertrouwen...

Momenteel hebben de banken icm Equins (/pinautomaten) 100% van het traject in handen, daarom kunnen ze ook bij scamming etc geld teruggeven, daarom kan je een automatische overboeking terugdraaien etc. etc. etc.

Met vrije API's gaat een bank dus niets meer vergoeden als de klant zegt dat er een overschrijving zonder toestemming is gedaan, want ze kunnen niet verder kijken dan jouw API-call en ze vertrouwen jou nou ook weer niet zogoed dat ze het wel even voor jou gaan voorschieten.

Zoals je zelf al zegt, maandelijks 1000 euro overmaken aan het begin van de maand dat is een legitieme actie en in december laat ik alle gebruikers van die app het eenmalig overmaken naar mijn rekening, dat is ook een volledig legitieme handeling vanuit de bank gezien, het is alleen geen legitieme handeling vanuit de gebruiker bezien.

[Gomez12]

PromWarMachine schreef op dinsdag 25 augustus 2015 @ 11:42:
Zo'n API lijkt mij ook wel interessant.
Nu de meeste banken NFC ondersteunen, zouden API's ook best moeten kunnen.

NFC is ook 'voorzichtig' ingevoerd. Max. €25 per transactie, max €50/dag, schadeloos gesteld worden als er misbruik van gemaakt wordt, etc. Dat zijn prima kaders waarin een API ook gemaakt zou kunnen worden.

En wie verwacht je dat het schadeloos stellen op zich gaat nemen? Want de bank gaat dat niet doen als een 3e partij er gebruik van maakt. En menig 3e partij heeft geen zin om die verzekering te gaan betalen...

[Firefly III]

-

[Voor 99% gewijzigd door Firefly III op 23-10-2016 15:35. Reden: Leeg vanwege privacy.]

[D4NG3R]

Het dichtste wat hier in de buurt van zal komen is Paypal maar die kan je dan weer niet gebruiken voor alledaagse aankopen in fysieke winkels e.d.

[Gertjuhjan]

Interresante discussie.
Ik heb op dit moment ook een applicatie gebouwd waarvan ik de afschriften van ING moet importeren. (En ook de PDF van Creditcard).
Dan kan je verschillende categoriën instellen en dan ga je iedere transactie aan een categorie verbinden. Maar iedere keer als je een transactie categoriseerd slaat voegt hij ook alle trefwoorden toe aan die categorie. Dus na ongeveer 3 maanden weet hij de meeste transacties automatisch te categoriseren. Hoef je het alleen nog even na te lopen en de niet gecategoriseerde transacties te binden aan een categorie.

Met een API zou dit veel makkelijker kunnen. Maar ik ben allang blij dat ING mogelijkheid geeft tot export van CSV bestanden, want met mijn creditcard kan ik alleen export doen naar een PDF.

Maar.... als een online tool dezelfde functionaliteit aan zou bieden, zou ik mijn bankgegevens echt niet naar een 3e partij exporteren. Vandaar dat ik hier een eigen tool voor gemaakt heb.

[NMe]

Ik vind het persoonlijk een beetje eng hoe happig sommige mensen hier zijn op een API zoals deze. Het is ongelofelijk lastig om een API te maken die wél zinnig is maar niet potentieel aanvallers het leven makkelijk maakt. Ik was laatst mijn bankpas kwijt. Het enige dat ik moest doen om een nieuwe te krijgen was telefonisch mijn geboortedatum verifiëren (niet bepaald een geheim...) en van een van mijn maandelijkse afschrijvingen aangeven wie de begunstigde was en hoeveel die elke maand afschreven. Met die API kun je een goed ogende en werkende app schrijven die wat met je transacties doet maar die transacties ook ergens centraal opslaat. Niemand die iets in de gaten heeft. Vervolgens hoef je alleen maar wat social engineering te doen, de bank te bellen dat je je pas kwijt bent en de postbode te onderscheppen.

Als programmeur lijkt het me ook heel leuk om met zo'n API te spelen, maar als klant van een bank draai ik dus mede op voor de vergoedingen die uitgekeerd worden aan mensen die schadeloos worden gesteld door hun eigen domme internetgebruik, dus ik heb veel liever dat dit soort meuk er niet komt...

[raptorix]

Een collega van mij komt van ING af en was daar vaak betrokken bij Labs achtige ontwikkelingen, ik zal hem eens vragen of hij iets weet.

Overigens zijn banken extreem voorzichtig met alle zaken die persoonsgegevens of data van klanten raken, dat word vrijwel alleen inhouse gedaan. Ik heb redelijk veel voor banken gewerkt, maar dat betrof altijd content achtige sites (o.a. de zakelijke kant van ING en wat magazine). Daar mochten dus nooit registraties op gedaan worden omdat het anders verwarrend zou werken voor consumenten.

[begintmeta]

Diverse zakelijke paketten bieden uitwisseling met diverse banken, ik neem aan dat er dus al wel APIs voor het een en ander beschikbaar zijn, maar iedereen lijkt zijn eigen ding te doen en het is niet publiek beschibaar. Bijvoorbeeld Duitsland heeft voor een wat openere aanpak gekozen met FinTS, zou voor NL misschien ook niet slecht zijn.

[Voor 6% gewijzigd door begintmeta op 25-08-2015 13:19]

[Firefly III]

-

[Voor 100% gewijzigd door Firefly III op 23-10-2016 15:35. Reden: Leeg vanwege privacy.]

[NMe]

Slarioux schreef op dinsdag 25 augustus 2015 @ 13:45:
[...]

Ik geloof niet dat er iemand is in dit thread die op een API vooruit loopt zonder te erkennen dat de door jouw aangegeven problemen ook opgelost moeten worden.

Het probleem is dat het nogal moeilijk is om een balans te vinden tussen de informatie geven die een gebruiker nodig heeft en het niet geven van informatie die een phisher kan gebruiken. Ik denk eerlijk gezegd dat dat onmogelijk is.

[Firefly III]

-

[Voor 100% gewijzigd door Firefly III op 23-10-2016 15:35. Reden: Leeg vanwege privacy.]

[Xanaroth]

Op het moment dat er een API zou zijn voor ontwikkelaars, introduceer je een 3e partij in je bankzaken. Maffiosi, hackers, criminelen en alle andere kwaadwillenden zouden je eeuwig dankbaar zijn voor het beschikbaar maken van een dergelijke functie.

Dan kunnen ze volledig legaal tussen jou en de bank in gaan zitten, en bij elke transactie 1 cent vragen. Die eigen transacties kunnen ze dan in de API mooi wegfilteren (zeer populaire scam bij EVE online trouwens, creatief werken met API codes en wat er wel/niet te zien is) om miljarden te verdienen.


Dus laten we hopen dat geen enkele bank het ooit vrijstelt, want dan krijg je EVE online achtige scams in het echte leven.

[Voor 12% gewijzigd door Xanaroth op 25-08-2015 15:53]

[begintmeta]

Xanaroth schreef op dinsdag 25 augustus 2015 @ 15:51:
Op het moment dat er een API zou zijn voor ontwikkelaars, introduceer je een 3e partij in je bankzaken. Maffiosi, hackers, criminelen en alle andere kwaadwillenden zouden je eeuwig dankbaar zijn voor het beschikbaar maken van een dergelijke functie.
...

Dus laten we hopen dat geen enkele bank het ooit vrijstelt, want dan krijg je EVE online achtige scams in het echte leven.

In hoeverre strookt dat met ervaringen met FinTS, of is dat gewoon iets anders dan wordt bedoeld?

[Voor 71% gewijzigd door begintmeta op 25-08-2015 16:03]

[MarcoC]

Zoiets gaat in de toekomst zeker komen. De banken zullen namelijk wel moeten, mede mogelijk gemaakt door de Payment Services Directive II.

Dit artikel is wel leuk om te lezen wat de gevolgen van PSD II zouden kunnen zijn.

Now, amplified through PSD2, external APIs are becoming a pan-European business topic for bankers. With these APIs customers will have more options to interact with their bank, next to usual online and mobile banking applications. Put differently, driven by XS2A, APIs will open up banks’ ‘Pandora’s box’ (i.e. account and associated data) through dis- and re-intermediation by so-called Third Party Providers (TPPs).

[Voor 7% gewijzigd door MarcoC op 25-08-2015 16:12]

[stefanass]

Gertjuhjan schreef op dinsdag 25 augustus 2015 @ 12:28:
Interresante discussie.
Ik heb op dit moment ook een applicatie gebouwd waarvan ik de afschriften van ING moet importeren. (En ook de PDF van Creditcard).
Dan kan je verschillende categoriën instellen en dan ga je iedere transactie aan een categorie verbinden. Maar iedere keer als je een transactie categoriseerd slaat voegt hij ook alle trefwoorden toe aan die categorie. Dus na ongeveer 3 maanden weet hij de meeste transacties automatisch te categoriseren. Hoef je het alleen nog even na te lopen en de niet gecategoriseerde transacties te binden aan een categorie.

Met een API zou dit veel makkelijker kunnen. Maar ik ben allang blij dat ING mogelijkheid geeft tot export van CSV bestanden, want met mijn creditcard kan ik alleen export doen naar een PDF.

Maar.... als een online tool dezelfde functionaliteit aan zou bieden, zou ik mijn bankgegevens echt niet naar een 3e partij exporteren. Vandaar dat ik hier een eigen tool voor gemaakt heb.

Wat jij beschrijft is precies wat je bij de Rabo bij internetbankieren kan doen
Ik hoef daar alleen na te lopen wat nog ongecategoriseerd is en ik heb een mooi overzichtje van waar mijn geld precies naartoe gaat.

[begintmeta]

MarcoC schreef op dinsdag 25 augustus 2015 @ 16:11:
Zoiets gaat in de toekomst zeker komen. De banken zullen namelijk wel moeten, mede mogelijk gemaakt door de Payment Services Directive II.

Dit artikel is wel leuk om te lezen wat de gevolgen van PSD II zouden kunnen zijn.

[...]
[afbeelding]

In FinTS 4.0 worden inderdaad ook intermediairs etc gespecificeerd, maar ik weet niet in hoeverre dit in de praktijk ook al wordt gebruikt.

[MarcoC]

begintmeta schreef op dinsdag 25 augustus 2015 @ 16:17:
[...]

In FinTS 4.0 worden inderdaad ook intermediairs etc gespecificeerd, maar ik weet niet in hoeverre dit in de praktijk ook al wordt gebruikt.

Dat is een technische specificatie, PSD II is een EU-richtlijn (op functioneel niveau) .

[Voor 3% gewijzigd door MarcoC op 25-08-2015 16:20]

[begintmeta]

MarcoC schreef op dinsdag 25 augustus 2015 @ 16:19:
[...]

Dat is een technische specificatie, PSD II is een EU-richtlijn (op functioneel niveau) .

Dat had ik inderdaad gezien, FinTS is dus mooi in lijn daarme opgesteld (wat uiteraard te verwachten is, maar het leek me toch wel interessant dat ook te posten).


De vraag hier is naar een API, omdat er nogal wat kanttekening mbt veiligheid worden gemaakt vraag ik me af in hoeverre de praktijkervaringen met die verwachtingen overeenkomen.

[Shinoki]

Afhankelijk van wat je doel is hebben de grootzakelijke banken al systemen om betalingen en ophalen van betaalgegevens te automatiseren.

Ik heb zelf bij de bank gewerkt die zo een systeem heeft. Dit werkt echter simpelweg door de betaalgegevens automatisch te laten exporteren en weer in te lezen in een ander systeem.

Voor betalingen werkt dit precies hetzelfde maar dan de andere kant op. Je levert dan betaalbestanden aan volgens europese normen(http://www.betaalverenigi...tierichtlijnen-nederland/)

[Haan]

Misschien zou het kunnen als je een persoonlijk certificaat moet gebruiken voor het aanroepen van de API. Bijvoorbeeld de Belastingdienst heeft ook een publieke end point om oa aangiftes in te dienen, maar daarvoor heb je wel je eigen certificaat nodig. Aan de andere kant beperkt dat het gebruik wel weer, want zo'n certificaat kost wel geld

[BlueZero]

Zoals hierboven besproken is er inderdaad een europese richtlijn voor bovengenoemde zaken welke in de toekomst actief wordt, zie hier er meer over.

Vooral PAAS is hier dus van belang, ik weet dat de meeste grootbanken van Nederland op dit moment op bestuursniveau aan het beraadslagen zijn hoe dit te implementeren. Echter het gaat hier om een richtlijn oftewel elke implementatie zal per bank gaan verschillen in de praktijk.

Ook zal zo een 'API' enkel opengesteld worden voor door de bank toegestane derde partijen. En verder blijft het zo dat de klant toestemming moet geven voor het delen van zijn/haar informatie. Zie het als een facebook OAUTH2 protocol waarbij je toestemming geeft voor een bepaalde scope en vervolgens kun je vanuit je internetbankieren omgeving deze toestemming weer intrekken.

Verder zoals hierboven beschreven de API's zijn er wel degelijk elke nacht dient elke bank de transactiedata van afgelopen dag door te sturen naar de AFM dit gaat geautomatiseerd. Verder zijn er inderdaad boekhoudpakketten die koppelingen hebben. Rabobank heeft een read/write koppeling waarbij de klant wel moet authoriseren voor een betaling in de internetbankieren omgeving. De ABN heeft een read only koppeling.

Hier blijkt al uit dat er nu geen uniforme standaard is op het gebied van informatie uitwisseling en die gaat er waarschijnlijk/helaas ook niet komen.

[begintmeta]

Zou FinTS theoretisch niet ook gewoon in NL kunnen worden gebruikt of vergis ik me gewoon en is dat simpelweg niet wat in de OP wordt bedoeld?

[BlueZero]

FinTS zou ik Nederland gebruikt kunnen worden echter daar is geen noodzaak toe. Het gaat niet om het niet kunnen van de banken maar om het niet durven/willen.

De Legal en Compliance afdelingen van een bank zijn niet zo happig op dit soort veranderingen.

In principe hebben banken al op kleine schaal koppelingen door exports klaar te zetten in zogenaamde postbussen voor derde partijen. Dit gebeurt ook op grote schaal voor beleggingsportefeuilles. Omdat sommige grootbanken derde partijen inhuren om de beleggingsdata om te zetten naar maandrapportages.

Zo zou een bank ook het rekeningoverzicht wat jij elke maand kan downloaden kunnen mailen naar een door jou op te geven emailadres, als hier het emailadres van een derde partij staat heb je al een simpele koppeling gecreëerd.

In Amerika zijn ze al veel verder met dit soort zaken, deze dienst is daar een voorbeeld van: [url="http://byallaccounts. Morningstar.com/"]http://byallaccounts. Morningstar.com/[/url]

[Gomez12]

BlueZero schreef op dinsdag 25 augustus 2015 @ 18:39:
Ook zal zo een 'API' enkel opengesteld worden voor door de bank toegestane derde partijen. En verder blijft het zo dat de klant toestemming moet geven voor het delen van zijn/haar informatie. Zie het als een facebook OAUTH2 protocol waarbij je toestemming geeft voor een bepaalde scope en vervolgens kun je vanuit je internetbankieren omgeving deze toestemming weer intrekken.

FB is dan zo ongeveer het slechtste voorbeeld wat je kan geven, die halen hun bestaansrecht aan het zo onduidelijk mogelijk definiëren van de scopes zodat er zoveel mogelijk gaten in zitten die de gemiddelde mens niet doorheeft maar waar hun hun profielen op kunnen bouwen.

Dat wil ik dus absoluut niet met mijn bankzaken, met 100% duidelijk omschreven scopes valt er over te praten wellicht, maar FB (en Google en de meeste social media dingen) zijn toch echt wel voorbeelden hoe de banken het niet moeten opzetten, het doel van een FB / Google is totaal anders dan het doel van een bank.

[BlueZero]

Gomez12 schreef op dinsdag 25 augustus 2015 @ 23:48:
[...]
het doel van een FB / Google is totaal anders dan het doel van een bank.

Ik denk dat je je hier wel eens in kan vergissen aan een standaard rekening met daarop 10k wordt niet zo veel verdiend door een bank. Zie hierin ook de recente casus van de ING

Lang verhaal over we verkopen geen data, privacy voorop, expliciete toegang etc. Echter Facebook noemt akkoord gaan met de "gewijzigde gebruikersvoorwaarden" ook expliciete toegang geven.

Ik sta zeer achter een open omgang van klantdata. Veel mensen die moeite hebben met hun persoonlijk huishoudboekje kunnen onwijs geholpen worden als bijvoorbeeld een Afas na toestemming van de klant "opnieuw" geautomatiseerd toegang kan krijgen tot transactiegegevens. Het eigendom van de transactiedata ligt zelfs (gedeeltelijk) bij de klant. Het is toch van de zotte dat ik bij de Rabobank moet betalen om mijn rekeningafschriften ouder dan 1 a 2 jaar te verkrijgen.

[Gomez12]

BlueZero schreef op woensdag 26 augustus 2015 @ 15:28:
[...]
Ik sta zeer achter een open omgang van klantdata. Veel mensen die moeite hebben met hun persoonlijk huishoudboekje kunnen onwijs geholpen worden als bijvoorbeeld een Afas na toestemming van de klant "opnieuw" geautomatiseerd toegang kan krijgen tot transactiegegevens. Het eigendom van de transactiedata ligt zelfs (gedeeltelijk) bij de klant.

De voordelen zie ik wel, maar overzie jij ook wat er gaat gebeuren als er 1 fout persoon bij Afas komt te werken die "even" besluit om al het geld te pakken, of als Afas een bug introduceert die de hele boel openlegt voor een hacker?

Afas heeft niet dezelfde sollicitatie eisen als een bank, Afas heeft ook niet dezelfde kwaliteitseisen als een bank.
En dan tref je dus net de mensen die al moeite hebben met hun persoonlijke huishoudboekje...

[begintmeta]

BlueZero schreef op dinsdag 25 augustus 2015 @ 19:39:
FinTS zou ik Nederland gebruikt kunnen worden echter daar is geen noodzaak toe. Het gaat niet om het niet kunnen van de banken maar om het niet durven/willen.
...

Juist naar achtergronden/gegeven omtrent dat laatste ben ik benieuwd, in dit topic is gepost dat het vrijgeven van een dergelijke api vragen om (diverse) veiligheids- of gebruikersproblemen is, mij lijkt dat men daarmee dan toch in Duitsland ook al enige ervaring moet hebben opgedaan. Of is het daar bijvoorbeeld juridisch noodzakelijk heel anders geregeld dan in Nederland?

[BlueZero]

Gomez12 schreef op woensdag 26 augustus 2015 @ 15:58:
[...]

De voordelen zie ik wel, maar overzie jij ook wat er gaat gebeuren als er 1 fout persoon bij Afas komt te werken die "even" besluit om al het geld te pakken, of als Afas een bug introduceert die de hele boel openlegt voor een hacker?

Afas heeft niet dezelfde sollicitatie eisen als een bank, Afas heeft ook niet dezelfde kwaliteitseisen als een bank.
En dan tref je dus net de mensen die al moeite hebben met hun persoonlijke huishoudboekje...

Dat is redelijk eenvoudig te overzien hoor, op dit moment is het al zo dat zeer veel mensen bij Afas Personal zelfstandig hun transactiegegevens uploaden en die laten verwerken door Afas. Het enige wat dit makkelijker zou maken is om toe te staan dat die gegevens automatisch overgehaald kunnen worden, aan de data veranderd dus weinig aan de manier waarop het bij de partij komt wel.

Dit bedoelde ik ook met Scopes, Afas is dan een partij die de volgende scope zou kunnen krijgen, het nachtelijks kunnen ophalen van klaargezette transactiegegevens met daarin een rekeningnummer/datum/omschrijving.

Er is geen enkele noodzaak om betalingen te kunnen uitvoeren of wat dan ook ik voorzie ook geen nuttige toepassing in de particuliere sector die dit wel gewenst zou maken.

begintmeta schreef op woensdag 26 augustus 2015 @ 16:43:
[...]

Juist naar achtergronden/gegeven omtrent dat laatste ben ik benieuwd, in dit topic is gepost dat het vrijgeven van een dergelijke api vragen om (diverse) veiligheids- of gebruikersproblemen is, mij lijkt dat men daarmee dan toch in Duitsland ook al enige ervaring moet hebben opgedaan. Of is het daar bijvoorbeeld juridisch noodzakelijk heel anders geregeld dan in Nederland?

Ik denk niet dat je het enkel in de juridische hoek moet zoeken dit is eenvoudig op te lossen bij read-only calls, het is zelfs opmerkelijk te noemen dat Capitol One (Voorheen ING Direct) bijvoorbeeld gebruik maakt van het Yodlee protocol wat ook dit soort calls toestaat.

Het lijkt erop dat de banken nog een concurrentieel voordeel denken te bezitten zolang ze de data niet openstellen. Echter ze zijn er zelf niet erg succesvol mee. ING's huishoudboekje Tim is al gestopt en ABN Amro's Financieël dagboek is ook niet meer.

[Martink]

Ik wacht hier ook al een tijdje op. Er is maar 1 bank die heeft bevestigd hier mee bezig te zijn. Tot mijn verbazing was dat de Rabobank. Ze hebben een deel van de api al gebruikt voor een hackaton. Halverwege volgend jaar zou die live moeten gaan volgens mij.

Qua veiligheid, tja. Ik denk dat je een soort iDeal achtinge omgeving moet hebben om transacties te bevestigen

[Ventieldopje]

Volgensmij is die API er al lang gewoon maar is die alleen beschikbaar voor financiële bedrijven. Veel boekhoudpakketten hebben namelijk gewoon een automatische koppeling met de bank. De bedrijven gaan echt niet voor elke rekening van elke klant handmatig een MT940 downloaden en parsen

Natuurlijk is dat een beetje security through obscurity maar als je weet met welke partijen je te maken hebt is het wel veel makkelijker te beveiligen (whitelist etc.).

Misschien offtopic maar betalingsproviders als PayPal en Mollie hebben wel een API dus zo lang het om betalingen gaat zou je daar gebruik van kunnen maken.

[Hydra]

Martink schreef op woensdag 12 oktober 2016 @ 08:41:
Ik wacht hier ook al een tijdje op. Er is maar 1 bank die heeft bevestigd hier mee bezig te zijn.

Nee hoor. Elke Europese bank is hiermee bezig. Het wordt voor banken ergens in 2018 verplicht een API open te stellen. Dit heet PSD2.

Ventieldopje schreef op woensdag 12 oktober 2016 @ 10:27:
Natuurlijk is dat een beetje security through obscurity

Euh nee. Die bestaande bank-specifieke API's zijn gewoon gedocumenteerd en daarnaast gewoon vaak REST gebaseerd. Het probleem is alleen dat je er zonder valid keys geen gebruik van kunt maken. En die keys en documentatie krijg je natuurlij niet zomaar.

[Voor 31% gewijzigd door Hydra op 12-10-2016 15:40]

[begintmeta]

Hydra schreef op woensdag 12 oktober 2016 @ 15:39:
...

Nee hoor. Elke Europese bank is hiermee bezig. Het wordt voor banken ergens in 2018 verplicht een API open te stellen.
.... Die bestaande bank-specifieke API's ...

Ik hoop dat men ervoor zal kiezen een niet-bank-eigen API te gebruiken, of zal dat ook moeten? Want voor zover ik heb gevonden wordt dat niet direct door PSD2 verplicht.

[Voor 8% gewijzigd door begintmeta op 12-10-2016 15:59]

[Ventieldopje]

Hydra schreef op woensdag 12 oktober 2016 @ 15:39:
[...]


Euh nee. Die bestaande bank-specifieke API's zijn gewoon gedocumenteerd en daarnaast gewoon vaak REST gebaseerd. Het probleem is alleen dat je er zonder valid keys geen gebruik van kunt maken. En die keys en documentatie krijg je natuurlij niet zomaar.

Tuurlijk is dat beveiligd maar het wordt óók niet zomaar aan de grote klok gehangen zoals bij veel andere bedrijven. Je kunt niet alvast een koppeling schrijven zonder eerst contact met je bank op te nemen om te vertellen wat je plannen zijn.

Dat is dus óók security through obscurity Maar natuurlijk niet alleen maar, dan zou ik die bank vandaag nog verlaten

[CMG]

Ik heb een aantal jaar geleden voor de SNSBank een scraper gemaakt; kreeg dan via Notifo (bestaat niet meer) meteen een push bericht van nieuwe transacties (is leuk in de supermarkt; pin -> ok -> Beep beep, Push msg met transactie )

SNSBank maakt het mogelijk om met een 'DigiCode' (username/password combo) in te loggen en een beperkt aantal zaken doen (betalingen kan met thresholds per dag; heb dat zelf gewoon op 0 staan) en is daarmee ideaal om dit soort data mee op te halen.

Imho zou het mooi zijn als je dit zelf bij de bank kon in stellen (web hook zoals bij paypal als je een betaling krijgt zou al fijn zijn).

[Firefly III]

Ventieldopje schreef op woensdag 12 oktober 2016 @ 16:03:
[...]


Tuurlijk is dat beveiligd maar het wordt óók niet zomaar aan de grote klok gehangen zoals bij veel andere bedrijven. Je kunt niet alvast een koppeling schrijven zonder eerst contact met je bank op te nemen om te vertellen wat je plannen zijn.

Dat is dus óók security through obscurity Maar natuurlijk niet alleen maar, dan zou ik die bank vandaag nog verlaten

Zulke verbindingen zijn redelijk standaard. Je gaat niet voor elke klant een andere API implementeren, je blijft bezig. De end-points kan je ook nog wel online vinden, vermoed ik. Maar als er bijvoorbeeld een lijstje geaccepteerde client-certificates is en je staat er niet bij, krijg je niks bij zo'n systeem naar binnen natuurlijk

[eterps]

Bunq heeft hun API vrijgesteld: https://www.bunq.com/en/news/international-and-api-launch

[James25]

Nederlandse bank Bunq brengt publieke api uit

*edit - spuit11*

[Voor 7% gewijzigd door James25 op 09-03-2017 11:39]

[Kajel]

Monzo is een internationale bank die hun publieke API voorop plaatst in hun digitale strategie. De ontwikkelingen vanuit Monzo en Bunq zullen gaan uitwijzen hoe het zal verlopen met de veiligheid.

[begintmeta]

Men is er ogenschijnlijk wel met pogingen voor een overkoepelende standaard bezig, zo kwam ik net de 'Berlin Group' tegen die ogenschijnlijk een technische standaard in het publieke domein willen bewerkstelligen, zijn er nog meer dergelijke beginsels?

[Voor 26% gewijzigd door begintmeta op 03-10-2017 11:22]

[Hydra]

begintmeta schreef op dinsdag 3 oktober 2017 @ 11:21:
Men is er ogenschijnlijk wel met pogingen voor een overkoepelende standaard bezig, zo kwam ik net de 'Berlin Group' tegen die ogenschijnlijk een technische standaard in het publieke domein willen bewerkstelligen, zijn er nog meer dergelijke beginsels?

Er zijn een hoop bedrijven met dit soort zaken bezig. Je hebt ook verschillende aanbieders die via web scraping werken (google maar, we gebruiken er een maar die mag ik niet melden). Als PSD2 landt straks gaan er nog veel meer bedrijven zijn die voor banken een uniforme API aan gaan bieden. Dat wordt wel een naar smerig ding overigens; PSD2 verplicht helaas banken niet om hier goeie keuzes in te maken.

[Harrie_]

Waar wil je het precies voor gebruiken?

Een jaar of wat geleden was ik op zoek naar dezelfde functionaliteit om automatisch binnenkomende betalingen 'af te vinken'. Ik heb toen met alle grote banken contact gezocht maar niemand bood een dergelijke API aan. Ik heb het uiteindelijk opgelost door bij een Rabo-rekening m.b.v. 'Rabo Alerts' alle transacties per mail te laten versturen waarbij een script de mailbox uitleest en de individuele transacties matcht en verwerkt in de DB

[Stoelpoot]

Hydra schreef op dinsdag 3 oktober 2017 @ 12:58:
[...]


Er zijn een hoop bedrijven met dit soort zaken bezig. Je hebt ook verschillende aanbieders die via web scraping werken (google maar, we gebruiken er een maar die mag ik niet melden). Als PSD2 landt straks gaan er nog veel meer bedrijven zijn die voor banken een uniforme API aan gaan bieden. Dat wordt wel een naar smerig ding overigens; PSD2 verplicht helaas banken niet om hier goeie keuzes in te maken.

Is Nederland / EU niet bezig dit dan toch verplicht te stellen? Is het niet sowieso verplicht aan banken om hun dienstverlening veilig te houden?

[DJMaze]

Harrie_ schreef op dinsdag 3 oktober 2017 @ 13:14:
Ik heb het uiteindelijk opgelost door bij een Rabo-rekening m.b.v. 'Rabo Alerts' alle transacties per mail te laten versturen waarbij een script de mailbox uitleest en de individuele transacties matcht en verwerkt in de DB

Ik heb een script dat automatisch inlogt op de website van de bank, "bladert" naar de export pagina, de MT940 download, en als laatste weer netjes uitlogt.
Om detectie tegen te gaan gebeurt elke scrape actie met random seconden.

Netjes is anders

[Voor 6% gewijzigd door DJMaze op 03-10-2017 13:21]

[Harrie_]

DJMaze schreef op dinsdag 3 oktober 2017 @ 13:20:
[...]

Ik heb een script dat automatisch inlogt op de website van de bank, "bladert" naar de export pagina, de MT940 download, en als laatste weer netjes uitlogt.
Om detectie tegen te gaan gebeurt elke scrape actie met random seconden.

Netjes is anders

'Netjes is anders', dat denk ik ook over mijn eigen oplossing via een mailbox. Maar je moet iets als de functionaliteit er gewoon niet is / niet wordt vrijgegeven. Helaas kan ik met Rabo niet inloggen zonder de Rabo-scanner dus scrapen was voor mij geen optie.

Ik begrijp de hierboven genoemde bedenkingen m.b.t. een API waar je ook daadwerkelijk transacties mee kunt doen maar zie zelf het gevaar niet zozeer in wanneer je vanuit een API alleen transacties kunt inzien...

[Hydra]

Stoelpoot schreef op dinsdag 3 oktober 2017 @ 13:18:
Is Nederland / EU niet bezig dit dan toch verplicht te stellen?

Niet dat alle banken dezelfde API aanbieden nee.

Is het niet sowieso verplicht aan banken om hun dienstverlening veilig te houden?

Ik heb niks gezegd over veilig? Het zal ongeveer net zo veilig zijn als internetbankieren zelf is.

Harrie_ schreef op dinsdag 3 oktober 2017 @ 13:28:
Ik begrijp de hierboven genoemde bedenkingen m.b.t. een API waar je ook daadwerkelijk transacties mee kunt doen maar zie zelf het gevaar niet zozeer in wanneer je vanuit een API alleen transacties kunt inzien...

Er zijn redelijk wat bedrijven die iets met betalingen doen en 1 cent overmaken om te verifieren dat dat account van jou is. Dus ook kunnen lezen van transacties is om dit soort redenen best wel een dingetje.

[Harrie_]

Ik schreef op dinsdag 3 oktober 2017 @ 13:28:
Ik begrijp de hierboven genoemde bedenkingen m.b.t. een API waar je ook daadwerkelijk transacties mee kunt doen maar zie zelf het gevaar niet zozeer in wanneer je vanuit een API alleen transacties kunt inzien...

Hydra schreef op dinsdag 3 oktober 2017 @ 13:52:
Er zijn redelijk wat bedrijven die iets met betalingen doen en 1 cent overmaken om te verifieren dat dat account van jou is. Dus ook kunnen lezen van transacties is om dit soort redenen best wel een dingetje.

Sorry Hydra, maar dat kan ik niet helemaal volgen... Ik weet dat je bijvoorbeeld bij het aanmaken van een Paypal-account de 1cent-transactie moet doen om te verifiëren dat de bankrekening die je wil koppelen ook daadwerkelijk van jou is. Wat is de link dan met een API waarmee je wel transacties kunt zien maar niet kunt uitvoeren

[xares]

Wij gebruiken hiervoor Reeleezee, met een gratis account kan je je bankrekening koppelen en hun API gebruiken. Wij lezen met een PHP cron de Reeleezee API de banktransacties uit en voert deze in de MySQL database van ons CRM. Zo matchen we dus transacties met een verkoop of inkoop-factuur.

Dat is ook niet wat het zou moeten zijn, maar beter dan een web-scaper die je moet aanpassen als het uiterlijk van internetbankieren veranderd

[Voor 20% gewijzigd door xares op 03-10-2017 14:43]

[Harrie_]

Allemaal 'gare' oplossingen, maar TS heeft nu in ieder geval 3 opties om e.e.a. toch te kunnen doen bij het ontbreken van een API

[SPee]

Harrie_ schreef op dinsdag 3 oktober 2017 @ 14:32:
[...]
Ik weet dat je bijvoorbeeld bij het aanmaken van een Paypal-account de 1cent-transactie moet doen om te verifiëren dat de bankrekening die je wil koppelen ook daadwerkelijk van jou is. Wat is de link dan met een API waarmee je wel transacties kunt zien maar niet kunt uitvoeren

Omdat het zo was dat Paypal de transactie deed en je ter verificatie de ontvangen code moest invoeren. Dus iedereen die de transacties kon bekijken, kon die code gebruiken en dus een account aanmaken.
Ik weet niet of dat nog steeds zo is, of dat inmiddels de aanvrager de transactie moet doen.
Toen was er immers ook al ophef over, dat je met enkel leesrechten tot de transacties een Paypal account kon aanmaken waarmee je geld van die rekening kon schrijven.

Heb jij als platform leestoegang tot de transacties van meerdere rekeningen, dan kun je bij bedrijven die op die verkeerde manier werken vrij makkelijk accounts aanmaken. En je klanten betalen de rekening

[Harrie_]

SPee schreef op dinsdag 3 oktober 2017 @ 18:09:
[...]

Helder verhaal, ik snap 'm nu, bedankt voor de opheldering

[DJMaze]

SPee schreef op dinsdag 3 oktober 2017 @ 18:09:
Heb jij als platform leestoegang tot de transacties van meerdere rekeningen, dan kun je bij bedrijven die op die verkeerde manier werken vrij makkelijk accounts aanmaken. En je klanten betalen de rekening

En daarom heb ik geen boekhoudkoppelingen met Asperion, Cash, e-Boekhouden.nl, Informer, Moneybird, MoneyMonk, MUIS, Reeleezee, SnelStart, Twinfield, Yuki, etc. etc.
Als het daar mis gaat ben je ook afhankelijk.
Natuurlijk moeten die bedrijven goedkeuring krijgen van De Nederlandsche Bank zodat er een vertrouwensband is, maar dat is net zo betrouwbaar als de DSB.

Het maakt ook allemaal niks uit, boekhoudkoppeling, e-mail, API, scraping, etc. In alle gevallen kan er een gaatje zitten/ontstaan.

In het geval van e-mail/API/scraping is het je eigen verantwoordelijkheid en ik begrijp dat banken daar niet happig op zijn.

[Gomez12]

DJMaze schreef op dinsdag 3 oktober 2017 @ 18:34:
[...]
In het geval van e-mail/API/scraping is het je eigen verantwoordelijkheid en ik begrijp dat banken daar niet happig op zijn.

Banken hebben niets tegen eigen verantwoordelijkheid hoor.
Alleen de meeste mensen snappen niet wat dat inhoud en gaan alsnog bij de bank klagen als al hun geld weg is. Waardoor een bank extra kosten heeft aan die "eigen verantwoordelijkheid".

[axis]

Harrie_ schreef op dinsdag 3 oktober 2017 @ 13:14:
Waar wil je het precies voor gebruiken?

Een jaar of wat geleden was ik op zoek naar dezelfde functionaliteit om automatisch binnenkomende betalingen 'af te vinken'. Ik heb toen met alle grote banken contact gezocht maar niemand bood een dergelijke API aan. Ik heb het uiteindelijk opgelost door bij een Rabo-rekening m.b.v. 'Rabo Alerts' alle transacties per mail te laten versturen waarbij een script de mailbox uitleest en de individuele transacties matcht en verwerkt in de DB

Harrie, heb jij een zakelijke- of een consumentenrekening? Als ik voor mijn consumentenrekening rabo-alerts per mail instel krijg ik alleen het bedrag van de laatste transactie te zien en het saldo, maar geen andere gegevens

[axis]

DJMaze schreef op dinsdag 3 oktober 2017 @ 13:20:
[...]
Ik heb een script dat automatisch inlogt op de website van de bank, "bladert" naar de export pagina, de MT940 download, en als laatste weer netjes uitlogt.
Om detectie tegen te gaan gebeurt elke scrape actie met random seconden.
Netjes is anders

Zolang het werkt! Maar je hebt vast geen rabobank waar je met een scanner moet inloggen?

[Harrie_]

axis schreef op woensdag 22 november 2017 @ 11:40:
[...]

Harrie, heb jij een zakelijke- of een consumentenrekening? Als ik voor mijn consumentenrekening rabo-alerts per mail instel krijg ik alleen het bedrag van de laatste transactie te zien en het saldo, maar geen andere gegevens

Consumentenrekening. Krijg je geen rekeningnummer te zien dan?

[axis]

Harrie_ schreef op woensdag 22 november 2017 @ 16:39:
[...]


Consumentenrekening. Krijg je geen rekeningnummer te zien dan?

Nope, ik krijg nu deze mails. Zien die van jou er anders uit??

[Harrie_]

axis schreef op donderdag 23 november 2017 @ 14:37:
[...]

Nope, ik krijg nu deze mails. Zien die van jou er anders uit??

[afbeelding]

Heb er zojuist een aangezet en ziet er inderdaad hetzelfde uit. Vroeger stond daar een rekeningnummer bij waarop ik kon matchen; ik heb dit halfbakken gebeuren al een tijd niet meer draaien.

[axis]

Harrie_ schreef op donderdag 23 november 2017 @ 14:56:
[...]
Heb er zojuist een aangezet en ziet er inderdaad hetzelfde uit. Vroeger stond daar een rekeningnummer bij waarop ik kon matchen; ik heb dit halfbakken gebeuren al een tijd niet meer draaien.

Helaas, denk dat ze slimmer zijn geworden en alles doen om hun zakelijke pakketten met boekhoudkoppelingen te promoten..

[Harrie_]

axis schreef op donderdag 23 november 2017 @ 15:16:
[...]

Helaas, denk dat ze slimmer zijn geworden en alles doen om hun zakelijke pakketten met boekhoudkoppelingen te promoten..

Dan misschien overstappen naar Bunq? Ik heb daar een rekening geopend om met hun API te testen en daar een webinterface omheen te ontwikkelen en ik moet zeggen dat het goed werkt. Op together.bunq.com kun je bovendien zien wat anderen maken en doorgaan naar desbetreffende git-repo's.

[aex351]

Bunq snap ik niet helemaal, ze zijn duur en bieden weinig. Verder vanaf 2018 zal PSD2 van kracht gaan, waardoor alle banken te benaderen zijn via een open standaard API. En dat is op zich goed nieuws omdat dit de positie van de banken op zijn kop zet. Met PSD2 worden banken, simpel gezegd, puur een plek waar geld bewaard blijft. Als klant kan je via de API bepalen hoe je hier gebruik van maakt. Dit houdt in dat specifieke bank apps eigenlijk niet meer nodig zijn en ga zo maar door. Omdat al deze diensten door anderen opgepakt kunnen worden. Daarom is PSD2 eigenlijk een behoorlijke dreiging voor de traditionele bank. Banken zullen het dus moeten hebben van hun 'specialistische' diensten. Daarom beginnen steeds meer banken in te zetten op technologie. ING begon hier al vrij vroeg mee en ABN hobbelt er een beetje achteraan.

[BrainFeeder]

ik kwam vandaag, naast dit gesprek, ook OpenBankProject tegen, ik weet alleen niet welke banken al ondersteund zijn. ING lijkt er bij te zijn, en PNB Paribas Fortis. Maar ik kan het niet maken van dit te implementeren als er maar 2 banken ondersteund zijn. ..

https://openbankproject.com/
https://github.com/OpenBankProject

Iemand die hier al ervaring mee heeft?

[Hydra]

aex351 schreef op donderdag 23 november 2017 @ 16:12:
Bunq snap ik niet helemaal, ze zijn duur en bieden weinig. Verder vanaf 2018 zal PSD2 van kracht gaan, waardoor alle banken te benaderen zijn via een open standaard API.

Nope

[Jantje2000]

Zou die API die bij PSD2 verplicht wordt eigenlijk wel voor iedereen te gebruiken moeten zijn? Want voor zover ik weet gaat de PSD2 morgen ( 13 januari ) in, dus zouden de rabobank en dergelijke banken dan allemaal een api beschikbaar moeten stellen, of mogen ze nog steeds eisen dat jij daarvoor eerst contact op neemt?

[We Are Borg]

PSD2 implementatie is uitgesteld, toenmalig minister van financieren heeft een brief gestuurd naar de kamer dat 'het voorjaar realistischer wordt geacht'

Conform de richtlijnen van PSD2 moet de API 'vrij' beschikbaar zijn, maar er zijn wel eisen aan de partijen en registratie bij de AFM/DNB (weet het even niet meer) is wel verplicht

[dotramses]

Bunq heeft een api https://www.bunq.com/nl/developer

[Hydra]

dotramses schreef op zondag 14 januari 2018 @ 13:16:
Bunq heeft een api https://www.bunq.com/nl/developer

Joh!

James25 schreef op donderdag 9 maart 2017 @ 11:38:
Nederlandse bank Bunq brengt publieke api uit

[etrans]

ABN AMRO heeft sinds november 2017 een developer portal: https://developer.abnamro.com/

Wel gericht op de zakelijke gebruiker, maar er is ook een tikkie API.

[dotramses]

Hydra schreef op maandag 15 januari 2018 @ 09:53:
[...]


Joh!


[...]

Ja sorry, krijg je als je alleen de eerste pagina leest...

[etrans]

ING Bank: https://developer.ing.com/openbanking/

Deutsche Bank: https://developer.db.com/

[RobIII]

@gijsgoudzwaard is sinds dat 'ie deze vraag in 2015 stelde in geen velden of wegen meer te bekennen. Ik neem aan dat 'ie dus wel vond dat 'ie geholpen was ofwel ergens anders z'n heil heeft gevonden. Either way; we hoeven dit topic niet tot in den treure te blijven schoppen telkens als er ergens een nieuwe API bij komt. Voor diegenen die dit in 2038 lezen: informeer gewoon even bij je bank. Kans is groot dat ze inmiddels een API hebben.