Door karma4: Die openheid om api's door derden te laten gebruiken in opdracht van de gebruiker is eenopgelegde eu verplichting.
Eris nog wel een confomiteitseis van betrouwbaarheid naar gebruiker en geen misbruik van api's bij de banken terwijl banken een verplichte minimale functionaliteit moeten bieden.
https://www.europeanpaymentscouncil.eu/news-insights/insight/eu-payments-legislative-package-strong-concerns-european-banks
Dat is een opiniestuk, in de kantlijn staat:
The views expressed in this article are solely those of the authors and should not be attributed to the European Payments Council.
Los van dat het niet de EU-verplichting die je noemt onderbouwt laat je het aan de lezer over om in een flinke lap tekst het relevante fragmentje te vinden. Ik neem aan dat je dit bedoelt
[verduidelijkingen toegevoegd door mij]:
But it [proposal for a Network and Information Security (NIS) Directive] does not seem consistent with the draft PSD2 [revised Payment Services Directive] which, as proposed by the Commission, would allow payment users to share their personal banking credentials with TPPs [third party providers] for which cyber security concerns should also have been taken into account.
Een van de vele hyperlinks onder dat artikel (de enige die duidelijk over PSD2 en TPPs gaat) verwijst naar een van de nieuwsbrieven van het EPC:
https://www.europeanpaymentscouncil.eu/news-insights/insight/psd2-epc-key-considerations-address-aspects-related-third-party-payment?articles_uuid=715B964B-5056-B741-DB6CB0030BB504E9Daar wordt een hoop gezegd over de valkuilen van die toegang door TPPs, maar ik zie volgens mij niet expliciet gemaakt dat het geven van die toegang verplicht is voor een bank. Ik heb startpage dus maar de zoekopdracht "PSD2 TPPs" gegeven en vond deze PDF van Deutsche Bank:
http://cib.db.com/docs_new/White_Paper_Payments_Services_Directive_2.pdfDaarin staat op pagina 36:
Access
Every ASPSP offering access to online payment accounts - having an online agreementwith a customer, and having provided the customer with tools for online authentication - will have to be accessible to TPPs and to provide them with an online interface. There need not be any contractual relationship between a TPP and an ASPSP.
Hèhè, eindelijk zie ik ergens staan dat de EU inderdaad toegang door derden verplicht via een online interface. Beste karma4, ik vind het lovenswaardig dat je een link opneemt ter onderbouwing van een bewering, maar zou je alsjeblieft zo zorgvuldig willen zijn dat je een link opneemt die die onderbouwing ook daadwerkelijk levert? En bij alles behalve heel korte teksten even aangeven waar in de gelinkte tekst die onderbouwing te vinden is? Het is veel efficiënter als één persoon (de schrijver van een reactie) het uitzoekwerk voor zijn rekening neemt dan dat iedereen die het leest zo'n zoektocht moet uitvoeren.
Goed, nou weet ik genoeg om inhoudelijk op je reactie te reageren. De openheid op API's door derden te laten gebruiken is specifiek op third party providers gericht, ze hebben het daarbij niet over consumenten zelf. Hier gaat het wel om een consument die zijn eigen API-aanroepen wil regelen. Niet dezelfde situatie, zeker niet als je in de EPC-nieuwsbrief die ik hierboven linkte nadrukkelijk wordt gesteld dat ze sterk afkeuren dat die TPPs met de credentials van de klant van de bank werken. Daarmee heb je het volgens mij al snel over
andere API's dan die voor rechtstreekse toegang door de klant worden gebruikt, al zullen de twee sets API's wel overlappen. Ik ben er daarmee niet van overtuigd dat deze verplichting aan banken op de situatie die hier speelt van toepassing is.
Maar ik denk wel dat het vanuit een technisch perspectief geen kwaad moet kunnen. Dergelijke API's moeten sowieso robuust zijn, foutief gebruik ervan mag nooit de server die ze afhandelt in problemen brengen (zolang het geen grote DDOS-aanvallen betreft), en ongeautoriseerde toegang tot data van anderen via die API's mag ook niet mogelijk zijn, alle invoer moet op de server gevalideerd worden. In dit opzicht moet het veilig zijn.
Dan kom ik bij:
Door ackna10: Ik zou er als bank niet blij van worden als mensen zelf met APIs gaan zitten spelen, maar zuiver juridisch denk ik dat ze idd niet veel meer kunnen doen dan je blocken. Hoe zit dat echter met aansprakelijkheid als er iets fout gaat met je saldo of diensten?
Ik denk dat een bank die zijn API's, validaties en logging op orde heeft niet wakker hoeft te liggen van gebruik ervan vanuit software die mensen zelf schrijven, als correct ingelegde opdrachten maar correct worden uitgevoerd en foute invoer wordt geweigerd met een foutmelding of -code.
Maar iemand die dergelijke software schrijft is daarmee wel verantwoordelijk voor zijn eigen blunders. Als je door een stom foutje met euro's en centen honderd keer zoveel overmaakt dan je dacht over te maken is het helemaal je eigen probleem, de bank kan echt niet weten dat je wat anders bedoelde en
moet afgaan op wat je aanlevert. En al je tests doe je in een echte live-omgeving, je hebt geen veilige omgeving waar alles voor spek en bonen gebeurt waar je je eigen aanroep van die API's kan debuggen.
Ik kan me levendig voorstellen dat een bank helemaal geen zin in het gezeur heeft dat dat soort ongelukken kan opleveren. Ik weet niet of het voor de vraagsteller geldt, maar er lopen genoeg mensen rond die als het ernstig misgaat zullen proberen te doen alsof (of zichzelf wijsmaken dat) de bank zelf de fout heeft gemaakt.
Ik zou de vraagsteller sterk aanraden om dit soort risico's niet te lopen. Zelfs de beste programmeurs blunderen af en toe stevig. Testen in een live omgeving is daarom iets wat je moet mijden als de pest. En dat is zonder actieve medewerking van de bank de enige mogelijkheid die je hebt.