Blog article
See all stories ยป

Contemporary Issues in building Solutions over European Banking APIs

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

a member-uploaded image

Comments: (4)

A Finextra member
A Finextra member 19 June, 2019, 15:25Be the first to give this comment the thumbs up 0 likes

Hey Amandeep,

you forgot about Slovak API standard, so in point 2. there should be 7-8 standards at least :)

Slovak Anonymous

A Finextra member
A Finextra member 19 June, 2019, 16:15Be the first to give this comment the thumbs up 0 likes

Sure :-) Would be great to get such link reference to Slovak API standard

Oliver Kamenský
Oliver Kamenský - Tatra banka, a.s. - Bratislava 19 June, 2019, 16:18Be the first to give this comment the thumbs up 0 likes

There cant be pasted a link, so try to look for:

Slovak API banking standard ver. 2.0 and you should be able to find it out on

A Finextra member
A Finextra member 02 July, 2019, 22:36Be the first to give this comment the thumbs up 0 likes

Added :)

Retired Member

Member since

19 Mar 2009


Blog posts




This post is from a series of posts in the group:

Banking Architecture

A community for discussing the latest happenings in banking IT. Credit Crunch impacting Risk Systems overall, revamp of mortgage backed securities, payment transformations, include business, technology, data and systems architecture capturing IT trends, 'what to dos?' concerning design of systems.

See all