This article is written on 5th June 2019 during API Days Finland Presentations highlighting the experience, issues, challenges of non-standard PSD2 and Open Banking APIs Published by various European Banks so far
I have had at least 5 speaking engagements in last 2 years around the topics of sharing best practices of Banking API integrations & Challenges as available PSD2 APIs Consumer. No surprise for guessing that it was four times for the latter and once for the
former
I tried to segment and categorize those issues into following prevalent at the moment
1. API Hell: We all I love the concept of exposing data, but implementation, most of the time, sucks. PSD2 APIs maybe ready by their stipulated revised time of September 2019, but ready does not mean useful !
2. Non-standard by Origin & Design: What started as ambitious wishful project once PSD2 draft was out has now gotten spilled itself into multiple standards. The available different standard definitions now include 6-7 different Open Banking
API standards within EU, namely STET, OpenBankingUK, PSD2-Berlin Group, NextGenPSD2, Czech Local, and Polish Local standards
3. Creation of another License Regime: What started as idea to liberalize and push more competition within financial space has now become enabler of new form of license regime around AISP ( Account Information Service Provider ), and PSP
( Payment Service Provider) license acquisition. The "scraping" of financial accounts related data which was termed illegal post 13 Jan 2018, is virtually replaced now with next generation of scraping services (aka AISP license holder businesses)
4. Monolith Bank Flyweights: This might sound technical, and yes it literally means that "some" banks who took such approach to expose certain data, went all the way in exposing a huge flyweight ( by no means a microservice, aka API ) that
is touchpoint of account details, balances, and tranactions list pages, all in one call. Would you call it API or data dump ?
5. Cache me Not: The situation is that while overall API reliability is in question to fit a real time need, does it make sense that such requests have to pass through a caching infrastructure at this stage, with its own caching strategy?
6. Consent is not a singular CRUD (data) Object: The most disinformed implementation of consent objects are seen around when a singular flag determines all-or-none approach to any end-user's banking data details and all attributes including
PII (Personal Identificable Information) pertaining to a user's banking record or activity. Surely Consent architecture has lot to evolve from here, unless there are more of privacy policy drats like
Spotify becoming fashionable ( reads: "If you don't agree with the terms of this Privacy Policy, then please don't use the Service") against the promises of open banking ecosystem with suitable guards for user privacy and consent
7. Consent Revocation Cascade: This concerns primary from the point that an end-user who is subscriber to a 3rd party consumer app built using banking APIs, has to have a mechanism to revoke consent. If the consent is to be revoked by him/her
informing within 3rd party app, or to his/her bank account, or at two places. Or otherwise if Bank is main point where consent is given , revoked, or stored, then how does every API response from bank for that particular user would change afterwards since
3rd party app would be actually unaware of that ? (
A case for very Banking API Error Codes?)
8. Consent Storage Location: Who should be storing user consent then, the 3rd party app, Bank, or a neutral location. This area is yet to evolove based on active and available consumer activism and related data protection law enforcements,
but if such solutions emerge they would pretty much absolve the concerns in prior two points highlighted
9. Do we need API versioning?: I would reiterate the point mentioned in API Hell as first point while starting this article. Only the usable API is only seen as available API. A lot many of API platform companies do not
rely on versioning yet. There could be specification differences and evolutions like Open banking draft versions, but having multiple versioned APIs individually for a series of compatible Open Banking Draft versions would be a true API Hell which nobody would
like to maintain or build documentation or services upon
10. Bank may not see REST as a Religion as Developer Communities do, but then how do they push?: While it is rudimental sometime to get pulled into discussions if certain API should be
POST or PUT ( e.g. a Transaction Redaction Sync is POST for a 3rd party when done to a core banking endpoint, but it falls under PUT/PATCH category when received from another peer system within Bank); yet it is important how the current needs of push notifications
for end user are to be served if there is change in banking information or suitable alerts. If there is banking information which has gotten changed, are the banks' architectures rely on sufficient underlying CQRS design to trigger suitable resultant webhook
pushes where end users within 3rd party app context can subscribe to? Only development practices and architecture change will enable that, not just exposing the data for now
Any more points? I am more than eager to hear views