The strange case of the Open Banking Implementation Entity (OBIE)

10 October 2018

For those unaware, the OBIE was established as a result of the Competition and Markets Authority’s Order into Retail Banking, and subsequently had its role expanded to develop API specifications for the purposes of PSD2 compliance. It has now completed this activity, and done much good work, but its PR/Comms output is confusing to the point of being misleading.

OBIE updates

Breaking down this information shows a very odd story. They’ve used large font to highlight they have enrolled 77 providers, made up of;

  • 52 TPPs - but in very small text they make clear that only 6 of these have products which use the APIs live in market.
  • 25 ASPSPs - its not clear what number of these are providing API platforms for live use, but the TPP community is only aware of the CMA9.

So from a headline figure of 77, there is now a total of 15 with services live in market.

Taking the 4.2m API calls, this is at such a high level of detail to be meaningless. To put this in context, to access a data payload (balance, transactions etc.) a minimum of 3 API calls is required:

  1. POST /account-requests,
  2. GET /accounts
  3. GET /accounts/{AccountID}/transactions

Calls 2 and 3 are only possible if the customer successfully authenticates with the ASPSP, and feedback has shown a high rate of dropout at this point. Without clarification of what number of those 4.2m calls are actually successful pull downs of data, outside of any testing/monitoring activity conducted by ASPSPs and TPPs, the headline number shows very little about the health of the ecosystem.

Moving to the key milestones

Updated standards (v3) - it’s true that OBIE published a new specification version, but the major changes in this release related to the expansion of payment resources, which receive no mention. Instead the headline is the changes to the account information specification, which are relatively minor and allow for a wider range of account products.

CMA9 live on v2 - there was a deadline of 7 September, but it’s doubtful whether all of the CMA9 were actually live on this date. Based on the Security Profile Conformance Page, it’s clear that there are still v2 implementation issues outstanding with most ASPSPs, with only AIB and HSBC having implemented successfully. ‘Live with caveats’ might be more accurate.

Finally highlighting Barclays inclusion of an account aggregation function in its mobile banking app. Whether this is a cause for celebration is debatable. It’s clear that the TPP community have faced a number of obstacles to integration with Barclays, and in many cases Barclays have steadfastly refused to accept problems highlighted. Notably, the market leader in open banking customer acquisition Yolt went live with Barclays last among the CMA9, only recently and OBIE’s PR highlights. Given that Barclays have been the hardest of the CMA9 to integrate with, whether as a result of incompetence or intention on their part, it is difficult to understand why the OBIE would promote their new functionality, particularly as it is not available to all of their customers. It is notable that both PSD2 and the CMA Order point to API platforms being primarily for consumption by Third Parties, in part for the purpose of improving competition. Celebrating adoption by an organisation found (by the CMA’s investigation) to be part of this non-competitive market is difficult to understand, even more so when this organisation has been the focus of so much complaint from TPPs themselves.

The OBIE has done admirable work in the delivery of its API specifications and directory service, solving many issues faced by ASPSPs and TPPs alike. In its communications to the outside world, it seems hell bent on creating a positive, but misleading narrative about API adoption, which potentially draws focus away from the many issues which are inhibiting both TPP and customer adoption today. If it really wants to have a success story to tell, its time might be better focussed on resolving these problems and bringing them to the forefront of public discussion.

A Brief History of Conformance and Certification in the World of Open Banking / PSD2

by John Heaton-Armstrong (guest author)

19 September 2018

Those reading the FCA’s CP18-25 Paper on its approach to the PSD2 Regulatory Technical Standards (RTS) will note the references to ‘conformance testing’. This is not a novel concept in the UK - it was developed out of the OpenID Foundation’s approach to certification for implementers of OpenID Connect. To facilitate open banking, the Open Banking Implementation Entity (OBIE) developed a draft security profile which dictates how connections between ASPSPs (banks) and third parties (TPPs) should be secured. This profile is currently on a trajectory where, as a consequence of the need to align around eIDAS certificates as the sole means of identification, the industry will align to the Financial-Grade API Security Profile (FAPI), in its second version. This profile is agnostic of jurisdictional/regulatory context, and is being leveraged for most of the open banking initiatives going on around the world today.

Re-winding to late-2017, whilst the OBIE security profile used elements of FAPI, OpenID Connect and OAuth2, there was no singular means for an implementer to validate the correctness of what they had built. To build trust in the ecosystem, it was important for banks to demonstrate to TPPs that their authorisation server build had followed the security profile correctly, and to enable validation of any unexplained errors. OBIE (represented by the author) and Joseph Heenan of Fintechlabs got to work on a Conformance Suite and Certification Approach to assist banks (and platform vendors) in the validation of their implementations of the security profile, to allow them to self-certify, and publish the fact.

The response to this activity was varied. Some required convincing of the need to ensure that a common profile was implemented correctly. Some of the banks were concerned about the fast development trajectory of the suite, taking little account of the unchanging nature of the standards being validated. In simple terms, the exam questions were increasing, but the subject matter for study had remained the same. Today, the suite has been used thousands of times, and is undoubtedly one of the most significant contributions to the open banking ecosystem worldwide. To quote one senior bank representative - ‘our only complaint about the suite is that we wish it was available earlier’.

Experience of running the Certification process led to the view that a similar conformance suite was essential for validation of implementations of the functional API specifications. This would not only enable banks to test their platforms, but would complete the circle on an open banking Certification Framework, bringing an independent service into the public domain, and laying groundwork for the bank-TPP trust relationships which are essential to the development of this ecosystem. Despite support from the TPP community (see FDATA papers), the proposal was met with some resistance from within the OBIE and banks, due to concerns regarding liability. Thankfully, the CMA’s Trustee supported the idea, and a proposition was adopted at the OBIE Steering Group to move (further) forward with the development of a functional conformance suite, and a framework to bring the two areas together. Thanks must go to Chris Michael, Ezo Saleh, Rob Mckinnon and Mohammed Bana for their commitment to the concept, and patience with a demanding Product Owner! The suite will soon be made open source, and with the code available for scrutiny and collaboration.

To return the FCA’s consultative paper, weight has been placed on the importance of running conformance testing services, and using the results as part of an application for exemption from the requirement to build a fallback interface. Both the CMA Order and PSD2 (although to a lesser extent) place emphasis on the adoption of industry standards. OBIE and the others in Europe have done an excellent job of defining these standards, and the dual challenges the ecosystem now faces are to implement these, and ensure mutual trust around the correctness, performance, availability and stability of API platforms. It is a positive development that both the EBA and the FCA have seen fit to support conformance/certification initiatives, but as with so many elements of this domain, certification should not be seen as a compliance activity. The nature of the framework will be a transparent, objective and universal process which anyone can access to validate their implementation and demonstrate both to the regulator, and to consumers (be they TPP or PSU) that it is usable. In this respect it aligns to the basic aims of the open banking regulatory regimes, and the concept of an open ecosystem based on trust, consent, security and data portability.

John Heaton-Armstrong has worked at the forefront of the UK’s Open Banking initiative since it began, and led the delivery of technical products at Open Banking Ltd in the UK, including model banks, security and functional conformance suites, and reference applications. Up until July 2017 he led the development of the OBIE Open Data standard, the first part of the response to the CMA Order. He was Product Owner for the OB Security Profile and liaised with the OpenID Foundation to ensure a pathway to the adoption of the FAPI standard. He is a member of the OpenID Foundation, and its Financial Grade API (FAPI) Working Group. He works directly with Fintechs to ensure effective representation of their concerns, and has advised the FCA, EBA and Central Bank of Ireland on similar issues. John is a Senior Associate at RAiDiAM, and works with a range of banks worldwide covering both Digital Identity and Open Banking domains. He is a contributor to the Consumer Data Right standard being developed by Data61 and their API Standards Working Group.

Open Banking UK performance metrics by Credit Kudos

23 July 2018

Our good friends at Credit Kudos have published a performance dashboard which tracks API performance across a number of ASPSPs. A performance report was previously published by OpenWrks. The difference here is that this dashboard pulls in data in real-time from Credit Kudos’ production integrations. Data is aggregated over the past 3 months and averages are calculated. We clearly see that the performance anti-champion is the same across both reports (HSBC).

Performance characteristics of these API endpoints have a direct impact on the user experience when using applications built on top of the OB ecosystem. Google claims that a 1 second delay in a mobile application can reduce conversions by up to 20%. This has measurable impact on conversions, and on consequently - on revenue.

One must ask - but how does this compare to what is already out there? Banks have had APIs for a number of years now, but not ones that would be directly user-facing. To perform an unscientific test, simply open your mobile app and see how long it takes to pull your transaction history. I’ll save you the trouble and say this - it is much faster. How is it possible that banks can roll out performant APIs with uptime guarantees for their own purposes, but when directed to do so by a regulator they state that they face numerous challenges and some deliverables cannot be completed?

The performance dashboard is available at http://creditkudos.com/obstats.

Open Banking in the UK; a disaster in the making?

02 July 2018

tl;dr:

Adoption of open APIs by TPPs (third party providers) and the development/implementation of compelling customer facing services is not happening due to poor authorisation journeys implemented by banks, and the limited data available on their API platforms. The hype generated by a range of speakers pointing to a utopia where these factors don’t exist increases the likelihood of disappointment when the reality is understood.

Payment Initiation / PISP

When the the CMA Order went live on 13/1/18, aside from the banks, there were no PISP authorised TPPs, there remain very few today, and there is no sign of a customer (PSU) facing service using APIs available on the open market. The question is why, the answer is simple - the authorisation journeys.

Under the OAuth2-based API flow which forms the basis of the Open Banking Ltd (OBIE) design, once a consent is formed between a PSU and a TPP, the PSU is redirected to the bank (and whatever solution they provide) where they must authorise consent. The API design is standardised, but the authorisation journey that the PSU then goes through is not. Some banks (e.g. Starling) have taken a minimal approach, relying on their own app and (quick and easy) biometric authentication, followed by a display of the consent object with the option to authorise. This journey is automatically invoked, familiar to the PSU, highly secure, and (most importantly) simple to follow. It adds minimum friction but not at the expense of security and control.

Conversely, the implementations of the redirect authentication by the CMA9 have shown poor customer experience (UX). TPPs have no control, but this will impact the view customers have of their applications by association. Multiple steps, requirements to recall opaque user IDs and static passwords / memorable words, needless repetition of the consent object, reliance on web journeys and the like all feature. These are worse for the customer than the biometric approach, and are far more vulnerable to phishing and other security risks. The idea that increased friction in the journey means a reduced likelihood of fraud is a fallacy.

From the TPPs’ perspective they are faced with a choice; do they adopt API-initiated payments in the knowledge that there will be significant customer drop off due to the increased friction versus using a digital card journey as in Apple or Google pay, or do they err on the side of caution, and assume that the loss in customers will outweigh the fees of card-based payments? Every TPP spoken to so far has taken the latter approach.

One response to this has been to benchmark drop off rates on banks’ API platforms against drop off rates on similar journeys which rely on screen scraping, or on payments initiated through their web portals. This is a fool’s errand. In both cases the banks have a captive audience, with no option but to accept whatever UX is put in front of them, otherwise they won’t be able to access the banks’ services. The banks care little for the drop off rates experienced by TPPs, and if anything will be happy to see them, as it will increase the likelihood of customer retention on their own channels, and the continuation of their market dominance that the CMA Order sort to address. If the status quo continues, both aims of payment initiation services developing, and an increase in competition as a result will have failed, partially as a result of design decisions taken by the very organisations subject to the Order.

Account Information / AISP

A previous post explained challenges faced as a result of the back of immutable transaction IDs. The points remain, but in the meantime, a survey of current and prospective third parties has taken place. Responses to the challenge vary from the application of proprietary (to the TPP) IDs, to acceptance of the likelihood of issues, to a refusal to use any service without this essential feature.

The issue is challenging from both technical and business standpoints. If the TPP is offering an accounting application, the danger of transactions appearing twice (pending and booked) or changing means that the user could see wildly different account balances. If this data is to be used to offer lending products, a very high level of surety is required around balances and cash flow, so the consequences of a lack of reliability and traceability kill the business case. This is also the case with prospective credit rating generation, and risk analysis. One respondent stated that the lack of reliability of the data necessitated an increase on the risk rating to be applied by an algorithm and a consequent additional margin, meaning a direct impact to the customer in increased cost of product.

Common to the feedback has been significant concern, a recognition of the need for potentially unreliable workarounds in the short term, and of the potential inefficiency of consistently having to pull and analyse complete data sets to perform any business function. Additionally, feedback was given that the absence of immutable IDs would prevent the use of an API using this design for some, if not all of the respondent’s business cases. A change request has now gone to the CMA9 for review, so this very unfortunate feature of the AISP implementations may yet change. In the meantime it is severely limiting development of compelling use cases..

Combatting the hype

Anyone with a LinkedIn account will see several articles a day extolling the virtues of open banking, and the potential it has to revolutionise behaviour in retail banking. Here are some examples from the past week;

There is no coverage online or in print, of the challenges elucidated above, which dictate whether open banking will take off. If these barriers are not overcome, then those building services argue that they simply won’t adopt the open APIs which are mandated under the regulatory regimes. Focussing on comment from traditional spokespeople - high level execs, columnists and consultancies - is part of the problem. Most of these have no direct experience of the ecosystem, but all will recognise that speaking positively about utopias which may never exist will have a positive effect on the market’s impression of them and the organisations they represent. They are just building hype around possibilities that may never result, and, should open banking turn into a white elephant, the disappointment will be even greater as a result of the hype they’ve built.

For example, PwC recently delivered a report on open banking - Open Banking market could be worth £7.2bn by 2022: PwC - PwC UK. Some notable points raised;

  1. The principle growth areas are projected as account aggregation, analytics of expenditure and financial product comparisons. This is difficult to understand given that none of these areas is new - in fact the information is being delivered differently - that is all that has changed. And in most cases (relative to challenger banks) the data delivered is very limited, preventing innovation on these pre-existing services. The major market comparison engines pull richer data through a combination of private means and screen scraping, and have made clear that open banking APIs will not replace this in their current form.
  2. ‘The consumers most likely to share data tend to be young, urban-dwelling, high earners who are comfortable using technology and multibanking’. - sort of stating the obvious - most people in the UK are urban-dwelling, and open banking can only be accessed using some form of tech platform. PwC think account aggregation is important - you can’t use this unless you ‘multibank’.
  3. “Open Banking is a potential game changer for individual and corporate consumers. It provides an opportunity to transform the public’s interaction and everyday experience with the financial services industry. But there are still many ‘hard yards’ to travel. Few disruptive propositions have been developed so far. This is unsurprising given that since the launch of Open Banking in January it remains unclear who needs to get an account information licence or a payments handling licence and how these licences may change in the future.”

It would be interesting to know whether the API specifications were reviewed for this report. The lack of disruptive propositions has nothing to do with confusion around who needs an AISP/PISP licence - its due to factors such as;

  1. A lack of rich data or functionality on the account information APIs,
  2. A regressive method coupled with very poor authorisation journeys on the banks’ platforms,
  3. Technical challenges such as that posed by a lack of immutable transaction IDs’
  4. The absence of any bank-provided, data rich testing environments.

These have been pointed to on this blog, but none of them have changed. PwC would do well to look at the integrations available on the Monzo and Starling API platforms, which are truly disruptive, particularly in cross currency payments where they undercut the retail market by several percentage points. They might consider that this functionality has been built voluntarily by these challenger banks and integrated third parties, but is in stark contrast to what the incumbents have done. Their focus remains the regulatory-mandated bare minimum. Given these misunderstandings / lack of knowledge, it isn’t a great leap to challenge the predictions of PwC of a £7.2bn market worth, and the value of their entire report. It’s just another example of unhelpful hype, which distracts from the really important issues. These need immediate engagement if anything positive is going to happen over the next 6-12 months.

Conclusion

PwC are right in one respect - open banking is a potential game changer. If this is to be realised, then there are significant challenges that the ecosystem needs to address immediately or open banking may not live up to its potential (at best), or may not develop at all. The aim of the CMA Order was to increase competition in the retail banking market, but there is evidence of decisions aimed at thwarting adoption of open banking, and entrenching a non-competitive market. Commentators who talk up potential future ecosystem development are complicit in this, as the column inches they generate, and speeches given at endless conferences, serve only to distract audiences from important issues which need addressing immediately. Open banking has been live in the UK for 6 months but there is little evidence of improvement, and OpenWorks’ recent report showed poor performance levels on the current implementations, even in the context of very limited use. Something must change very soon, or the only response to a GET request will be disappointment.

Open Banking is finally open!

29 May 2018

Happily, this week, a recent development in the ecosystem gives us cause for genuine positivity in the face of continuing inertia.

Up until this week, the only way to access a fully conformant mock bank was to go through Open Banking. This organisation is largely set up to cater for companies whose intention is to get full regulatory authorisation - it fulfils this requirement well, providing a unique trust framework whereby ASPSPs can be sure of the status and identity of a TPP at any point.

What hadn’t previously be catered for was the individual or small organisation beginning their open banking journey, simply wanting to try the functional APIs without going through an onerous and potentially invasive registration process. Quentin Castel and Simon Harding of Forgerock (already the providers of one of the OBIE’s mock banks) have met this need with the development of a ‘directory lite’. This enables those interested to register with a minimum of information, then generate the necessary certification and software statement assertion, which in turn can be used for registration with Forgebank. The functionality is explored in this video Quentin has made - https://youtu.be/-BU12TGbBFA

To supplement this new facility, Quentin has also developed a complete Postman Environment, which contains all the necessary commands for certificate/SSA generation, Forgebank onboarding, and accessing protected resources - in essence he’s done the hard work for you. I’ve been working with Quentin, Simon and the Forgerock guys for some time, and have been continually impressed by their generosity of spirit in contributing to Open Banking in the UK - this is another example of that.

Please watch the video, give the APIs a go and let us know your feedback.

NB CAVEATS

  1. The facility is in Beta at the moment. There will be bugs - we’re happy to receive feedback on these - we’ll add those interested to a slack channel for this purpose.
  2. We provide support via open-banking-uk.slack.com (register at https://signup.openbanking.space) but, given that this is a free to use service, we don’t have an SLA on addressing issues/queries and will respond on a ‘best endeavours’ basis. This said there are a large number of very experienced, clever people in our Slack instance who may be able to help.
  3. Please do not contact OBIE’s service desk in relation to this facility. Their support extends only to their production facilities, and (currently) this isn’t one of them.

Why is Open Banking transactional data inherently useless?

12 May 2018

In this article, I’m going to make a very strong claim about a particular design decision which is currently being hotly debated between the Fintech community and CMA9 banks, and will outline why it is exceptionally important that Open Banking Ltd must push banks to comply.

Open Banking Limited is an entity which was created by the CMA9 to develop data standards and protocols which would permit an open banking ecosystem to operate in the United Kingdom, bringing desperately needed competition to UK’s retail and small business banking sector.

In non-tech speak, they design data “templates” which allow both parties (the TPPs and ASPSPs) to have a “conversation” using a common language. The development of these data standards is a huge undertaking and I bow to my former colleagues at Open Banking Ltd for pushing through such a colossal amount of work at breakneck pace to deliver to CMA’s deadlines.

As is with most standards, they are developed through stakeholder engagement - where representatives of various participants in this ecosystem come together and decide on what should be mandatory, what should be optional, and what can be left out. This group consists primarily of representatives of banks, fintech companies and consumers.

It is extremely unfortunate that during this process it has been suggested that immutable transaction identifiers would not be mandatory. This is truly bad news for everyone wishing to build an application on top of the OB ecosystem. Without immutable transactions, it is impossible to build a system which can be truly relied on in terms of data veracity.

Given that transactions displayed in your online banking platform can appear, then disappear, change dates, change descriptions, have different states (pending, booked, etc.), but contain no unique identifier – there is no way of determining if two transactions are really the same thing. Any application which requires continuous access to an account (which is probably most of them), will have no reliable way of determining if they have already “seen” transactions for a particular account. No reasonably reliable applications can be built on such a brittle foundation. Any workaround strategy for this would focus on solving a problem which should not have existed in the first place.

Providing this information is in the interest of banks as well - the simplest strategy against the above described deficiency is to pull the entire transaction list for an account every time it needs to be refreshed. This could mean months of data, as there is no defined “cut-off” point beyond which transaction data is guaranteed not to change. Pulling large amounts of records on a regular basis means that banks will need to spend more money on additional infrastructure required to handle this excess.

I’d argue (and this is a widely shared view among people attempting to build applications on top of these APIs), that the transaction endpoint must be a reliable single source of truth, otherwise it is a pointless exercise, whose only object is to give the impression that what has been developed is in line with the spirit of what CMA has requested the banks to do.

It is not surprising why – banks see OB in the UK primarily as a compliance exercise, and there is zero appetite to do anything than the bare minimum. Banks have said that providing this identifier would require development effort on their part and thus have zero interest in doing the work. This, naturally is no excuse – just Lloyd’s profits rose by 24% last year to more than 5bn!

It is absolutely crucial that this poor excuse is pushed back on – there are many products which cannot be built if this information is not made available. Furthermore, this design decision goes against the spirit in which OB was brought into existence – to enable competition and to deliver usable data standards and interfaces.

Open banking tech meetup in London

23 April 2018

To celebrate the milestone of reaching four hundred users on our Slack channel, we’ve decided to run a meetup in London. This will be very different from many panels which you may have attended in the past, as we will be discussing primarily technology which enables open banking, rather than anything related to vision or strategy.

The meetup will take place at Monzo’s headquarters in London on May 21st, 2018. We will be hosting a panel debate on technology which enables open banking. Speakers include:

We hope to see you in London on the 21st!

Open Banking Week 8

09 March 2018

Welcome to the next in a series reviewing open banking in the UK. News items on this topic have died recently, as the excitement around the launch has reduced. With that in mind, this post will focus on a number of positive and negative developments that the community may, or may not be aware of, and then a review of the currently available development portals offered by each of the CMA9.

tl;dr:

Some positive developments but the lack of anything tangible in the public view, and stalling from most of the CMA9 means that overall, the project is running at a B-.

Negative

  • We’ve heard on the grapevine that Open Banking Ltd have extended the managed rollout that was questioned in our previous post. This has happened without announcement, thus the concerns voiced two weeks into the initiative remain.
  • We are yet to hear of an example of a service which utilises the OBIE-designed API framework being made available to the public. This clearly depends on both Third Parties and Banks having an offering ready for market, and unlike the latter, there is no regulatory obligation on the former to present such.
  • In her Brexit Speech on Friday, March 2nd, Theresa May explicitly ruled out the continuation of passporting, and appeared to imply that there will be implications for digital initiatives which come out of Europe. Here are a couple of quotations:
    • “We’re not looking for passporting because we understand that it is intrinsic to the single market, which we would no longer be a member of. It would also require us to be subject to a single rulebook over which we would have no say.”
    • “The UK will not be part of the EU’s digital single market which will continue to develop after we leave … it will be particularly important to have domestic flexibility, to ensure the regulatory environment can respond nimbly & ambitiously to new developments.”

As with everything Brexit-related, nothing is set in stone, but this looks to have major implications for the open banking ecosystem, which is built on the PSD2 principles of interoperability through common technical standards, and the ability of organisations to interact throughout Europe with one regulatory registration. It’s also confusing given that the UK was one of the Payment Services Directives’ (i.e. both 1 and 2) biggest advocates, not least because of the huge competitive advantage London has in the fintech market. Time will tell what the effects of this approach are, but the speech certainly makes establishing a base in an EU member a strategic move for any businesses seeking to a European customer base post-Brexit.

Positive

  • Open Banking Ltd has released a second version of its API Standards. Whilst a positive step toward further PSD2 coverage, the release is limited to extended coverage of account types and product data points, as opposed to being an enrichment of the data already available as part of their account information API design.
  • Two freely available sandboxes which use the OBIE standard have been made public;
    • ForgeRock - a group of Digital Identity experts, have produced a facility with a broad range of information. From our initial review, the content is good and helpful for navigating through integration and building applications.
    • O3-Ozone - a new player in the ecosystem, with a very user-friendly website and a series of useful demonstration videos to guide developers through interaction.

CMA9 Developer Portal Review

We previously pointed to the lack of CMA9-provided developer facilities as being one of the major barriers to entry for those seeking to bring applications using the Order-backed initiative to live. They have clearly moved on somewhat, so here’s a quick review of the changes we’ve seen.

  • AIB - we previously pointed to AIB as being one of the leaders in this space. We’ve now had a chance to review their sandbox, and would recommend it in line with those mentioned above.
  • Barclays - whilst a very heavy website to load and tricky to navigate, Barclays have added information covering the Read/Write APIs a reference to a Barclaycard Smartpay API (coming soon). Unfortunately, a link to their sandbox (https://developer-sandbox.barclays.com) is broken, but there is distinct improvement.
  • Danske - no changes. Still terrible.
  • HSBC - see Danske.
  • Lloyds - hasn’t been updated since our last post, but still one of the better portals available.
  • Nationwide - now have a portal available which is fairly well structured but a bit light on content. No sandbox documented at this stage.
  • RBS - extensive new portal covering RBS, Natwest and Ulster Bank. They also have a ‘sandbox’, but in reality this is a mock server in the guise of that which OBIE published some time ago. Useful for those starting their journey, but not interactive in the manner of those listed above.
  • Santander - Santander has a developers’ portal consisting of a list of API specifications, endpoints, but no guiding content and no sandbox to be seen. They are, however, running a hackathon backed by a completely different open banking initiative, the Open Bank Project. Perhaps the hackathon is to develop a portal for the bank?

So a relatively mixed bag of news items; there are positive steps being made, but nothing to (yet) justify the hype that accompanied the launch of open banking in the UK. Until that happens, we’ll maintain cynicism about the effectiveness of the initiative in stimulating change and competition.

‘Open’ Banking Week 1

22 January 2018

tl;dr:

The open banking world is now a week old - despite a huge amount of discussion across digital and print media, very little has focused on the actuality (as opposed to the potential), so here is a brief review of what is available.

Open Banking Implementation Entity (OBIE)

The Open Banking Implementation Entity have a relatively extensive website and Confluence Space which detail a great deal about the ecosystem. They have also developed a set of reference applications including a ‘reference mock server’, which acts as the resource server of an ASPSP implementation, but does very little besides.

If you are minded to, you can enroll with Open Banking, and this will give you a view of their internal reference banks, more akin to full ASPSP implementations, with partial implementation of their custom OIDC Security Profile. Understanding and implementing this is a key part of developing applications for this space, as it is one of the common elements (theoretically) to each ASPSP implementation.

Banks (ASPSPs)

Regrettably, the headline here is less positive. Developer Portals range from the average to the non-existent. Looking at them one by one (details current at the time of writing);

  • AIB - probably the best of the CMA9. Gives a reasonable amount of detail, documentation, and uniquely, a sandbox.

  • Barclays - poor. Provides some information, but no detail on the AIS/PIS APIs. There is a sandbox hyperlink this appears to relate only to Open Data (as distinct from AIS/PIS).

  • Bank of Ireland - nothing.

  • Danske Bank - at the moment this appears only to aggregate news from Danske, as opposed to being a functioning Developer Portal

  • HSBC - static page containing only a paragraph of description and a link to OBIE.

  • LBG - looks great, unfortunately, once there is a bit of digging done, things aren’t as rosy as they appear. For example support requests requiring the submission of a spreadsheet (!) and there is no sandbox to experiment against.

  • Nationwide - nothing, although there is an information page. Oddly enough this misrepresents the consent flow, omitting the authentication and authorisation steps…

  • RBS - n/a, although there is an old portal which appears to relate to a hackathon run in early 2017, before the final Open Banking specifications were published.

  • Santander - nothing.

Analysis

OBIE are currently running a ‘managed rollout’, which amounts to a select range of Banks working with a select range of Third Parties. It’s unclear how this amounts to being ‘live’ or how this, and the absence of an open, functioning, OIDC compliant sandbox anywhere are actually in the spirit of the legislation. Further, it remains unclear when the general public will have access to applications exercising the Open Banking APIs, which ultimately means being able to control, more effectively, data which is theirs.

The aim of the CMA Order, the source of the UK’s version of open banking and the OBIE, was to promote more effective competition through increased customer engagement. This idea has matured over time, to what Imran Gulamhuseinwala, the CMA-appointed trustee, summarised as “trying to build a standard API everyone conforms to. This means that if you’re a fintech entrepreneur, and you want to connect with all the banks in the UK, it’s one set of APIs and boom - they’re all available to you.”

The reality appears to be very different. As a developer, without a test environment and with only specifications for reference, it’s extremely difficult to build a functioning application. Those who are involved in the ‘managed rollout’ appear to have a major advantage as both early adopters, and in the ability to circumvent the exceptionally poor developer portals the banks have made live so far. A cynical observer might go as far as to suggest that, in its current form, open banking in the UK is anything but, and is only continuing to cement the difficult process of engaging with a bank to access data.

The explanation may be in the ‘Rome wasn’t built in a day’ - simply that this is the first step on a journey, but equally no-one should be satisfied with what has been built so far. A frequent complaint about Open Banking, is that by being paid for and driven by the Banks, it serves their interests as opposed to those of the consumer, which was the original aim of the legislation. After a week of being ‘live’, we must remain hopeful that open banking will actually become open, rather than just being business as usual.

How was your data shared so far, and what will change with Open Banking?

11 January 2018

This post is written in response to BBC: Why banks will share your financial secrets.

tl;dr:

Your data is going to be safer when shared through the Open Banking ecosystem. It will only be accessed by whitelisted entities, only a subset of data will be shared, for a limited time, and you will be able to revoke access whenever you will choose to. None of which applies at this time - this is a change for the better, but we have yet to see whether customers see value in having an app store for their bank account.

It is obviously true that your financial history is something to be closely guarded. Saying however, that the information is available to you and your bank only is misleading. Every time you use a credit, or debit card, that transactional information goes to one of payment processors such as Visa or MasterCard - these are huge, American financial services company which indirectly hold insights into the spending habits of approximately 720 million cardholders (if we include Visa, AMEX and UnionPay), this number bubbles up to two billion.

Presently, unless you’re affiliated with a bank, you do not have any official ways of accessing anyone’s banking information programatically. Despite that, many companies will still offer you a service which as an input takes your financial history. How is that possible?

Enter Screen Scraping

Until recently, the primary way to access that information was by asking the end user for their banking username and password, logging in using those credentials, and extracting whatever information was deemed to be valuable, a technique known as screen scraping. This is dangerous for a number of reasons - the chief reason being - once you share your bank login details, that is it - you’ve just given a company access to your bank account, and they can, in theory do whatever they want. There is no way of easily revoking that, unless you change your password. Your bank might decide that there is suspicious activity (as someone has logged in from Mongolia, or some other remote destination), and will deactivate your online banking access. I’m confident many of you know what pains you have to go through to have that reinstated - in the best of cases it will require a visit to the branch. In the worst - who knows - you might be locked out from your bank account for two weeks, until a physical piece of paper arrives and you can finally unlock it.

Screen scraping provides a way for anyone to access your account - this could be a legitimate business, loaded with VC money and regulated by the FCA, two guys in a garage hacking on the world’s best banking aggregation app, or a rogue actor who is just waiting to rip you off. There is no easy way to tell, there is no easy way to cut them off, or shut them down, and once your data is in a jurisdiction which doesn’t care, there’s no way to do anything about that data being leaked, resold - you name it.

How will this change with programatic access?

How would we fix it? Firstly, you would never share your login and password with anyone - that remains your private master key, which you reveal to no-one. Instead of supplying that information, you would visit the page of the business you wish to deal with and click on a button which says “log in with your bank”, or “connect to your bank”. You would then be redirected to and prompted, by your bank to log in with those master credentials, on the bank’s portal or (in future) through their app. Once the bank authenticates you, it will display a list of data categories, which the business is interested in. You, as the end user can then decide if you feel comfortable with the data being shared or not. Unlike with screen scraping, only a subset of data is shared - a subset which you agree to, and for a fixed period of time. The business can only pull this data and has no access to your account through then bank’s portal, in stark contrast to the screen scraping approach.

Once approved, the business is now issued a set of credentials which will work only for that single end user, and only for the subset of data to which consent has been given. Those credentials work for a certain period of time, after which consent must be granted again by the user - so there is little risk that the end user will be unaware of what is happening to their account.

Per-user per-data-scope credentials have the added benefit that they can be revoked at any time. Suppose a user decides they no longer want to share data with a particular business - they can then visit their online banking dashboard and click a button and access will be revoked. Similarly, if that business’ IT infrastructure became compromised, the bank can then revoke access en masse.

Last of all, all those third parties must be regulated. If they can’t prove they are under the watchful eye of their national regulator, they can’t participate in the ecosystem. This significantly reduces the risk that a rogue actor can start extracting data from customers.

When is this coming?

There are two channels which currently make this possible in the United Kingdom: Open Banking UK and Teller. The former is due to make their ecosystem available on January 13th, but this will be to select bank staff and a small range of third party businesses. It remains unclear whether the general public will be able to make use of third party applications and consent to them accessing your data. Teller is available right now.

Adoption - the real issue

Despite all the hype and inflated expectations around being able to connect to your bank account, it remains to be seen whether this is seen as added value by customers. Despite all efforts, only a tiny number of customers in the UK are willing to switch away from their bank. This may well share the fate of Open Data APIs released by Open Banking last year - which is that no one cares and no one uses them.

Regulations - what's that? (CMA Order, PSD2, RTS on SCA)

04 December 2017

Some insight into this subject was given in the prior post (see here), but to elucidate further;

The CMA Order was published following their investigation into retail banking. This requires that 9 Banks in the UK (referred to as the CMA9) implement Application Programming Interfaces (APIs) to deliver information about a range of on sale products (Open Data), to deliver information about customer accounts (AISP) and to allow the initiation of payments on a customer’s behalf (PISP).

The Revised Payment Services Directive (referred to as PSD2) is Europe-wide legislation which places similar obligations (and many more besides in relation to implementation, transaction processing and communication) on financial institutions across Europe. This has now been supplemented by the Regulatory Technical Standards (RTS) on Strong Customer Authentication (SCA), these being essentially the ‘how’ where PSD2 is the ‘what’.

From an implementation point of view, the differences are becoming less significant, as Open Banking Ltd has been given a mandate to expand the functional coverage of its API specifications to cover the functionality required by PSD2; originally their scope was limited to that required by the CMA Order. As I mentioned previously, the best way to understand this relationship, based both on scope and the approach the banks are taking to implementation, is to see the functional scope required by the CMA Order as being the first step on the road to PSD2 compliance.

Participants – who’s who (Regulators vs OB, Banks, TPPs)

European Banking Authority – the EU’s regulatory body for the financial services industry, responsible for drafting EU Law relating to this space.

European Commission – the EU body with responsibility for the adoption of the EBA’s proposals

Financial Conduct Authority – the UK regulatory body for financial services, responsible for drafting the statutory instrument incepting PSD2 into the law of the UK

Competition and Markets Authority – government department responsible for reducing anti-competitive practices, and the progenitor of the order

Open Banking Ltd (OBIE) – body set up by the CMA and nine impacted banks to deliver API specifications, a directory of authorised participants and operational support for the new ecosystem

Component parts – Specifications, Platforms and the Directory

What are the essentials of a Bank’s implementation? From the conceptual to the outer layer, we can start with;

API Specifications – these amount to the functional design of how an API should behave. In the UK, these have been designed by OBIE in collaboration between a number of fintechs and the CMA9, to satisfy the requirements of the order, and are now being expanded to cover the requirements of PSD2. At a high level, they dictate the process of forming a connection (and its properties relating to data security), the structure and contents of the messages exchanged by TPPs and banks (including field types, cardinality, values and occurrences), and the scope of resources that can be accessed. Having a common specification used by (at least) 9 banks means that (in theory) a TPP developer can leverage an economy of scale in building applications as minimal work will be required to account for variances in the interfaces of the banks. In short, as the specifications are common, for the most part the behaviour of each bank implementation should be the same.

Platforms – API platforms assist banks in making their services available. They can provide an interface to communicate designs and other information, issue credentials, expose endpoints, assist with threat protection and a great deal more besides. Essentially, using an API platform can greatly assist in the process of exposing new interfaces to the world. A good explanation of the services an example platform provides can be found on the Apigee website. There are a very wide range of API platforms out there, but as the content of the link reflects, much of their subject matter that advertise is industry standard, as opposed to proprietary.

In the world of open banking, this is inevitable, as API specifications are open, and the ID profile is an industry standard, but it’s clear that many of the platform providers do not make clear that much of their offerings are simply adoptions of the work of organisations like Open Banking, the OpenID Foundation, RAIDiAM. In one example we’ve seen, and organisation purporting to offer its own API specification had copied that from Open Banking and neglected to remove references to the latter’s open licence. As flattering for OBIE as this might be, it goes to show that, rather than specifications or flows, providers should look to factors such as ease of integration and developer concerns when considering the platform market.

OB Directory – this is one of the key offerings of the OB, but it is important to clarify the scope and functionality. The principle of PSD2 is that TPPs registered across the member states can, with passporting rights, interact with any bank. This presents banks across the EU with a challenge – how to validate the status and identity of those TPPs asking to onboard and interact. OBIE have closed this gap by providing a Directory service that offers a verification (of regulatory status) and identification service for both TPPs and banks. These are issued credentials (following validation) which they can use to identify themselves to new partners, who in turn can use the Directory service to validate that the credentials remain current, both when the relationship is initially formed, and on an ongoing basis. This last aspect is particularly important given that TPPs may have their regulatory status revoked.

To date the Directory’s policy is to cover only those TPPs registered or passported into the UK. There has been talk across the EU about the EBA establishing a register, or other organisations like PRETA building a function that would cover the entirety of Europe. Initial indications are that these would be sources of policy only, and would not provide the necessary technical means, such as certificates for assuring identity and securing data against tampering and eavesdropping. Additionally, the EBA have made it clear that their register could not be relied upon from a liability point of view, which renders it of very limited value. Ultimately the OB Directory fills a very important gap in the ecosystem, and is a first attempt at a model, whilst limited in initial scope, where there is significant room for expansion.

Getting ready for a basic customer journey

Frequently asked questions include what the customer interaction looks like, and how a TPP gets ready to fulfil this need. To answer this, we can break it down into several parts, and will answer this in a UK context only.

Getting ready

  1. TPPs will first need to register with Open Banking. The detail of this can be found on their website, but will involve validation of those elements mentioned above.

  2. Before OBIE will issue credentials, a TPP must be authorised by its National Competent Authority, the FCA in the UK, or be issued a passport to the UK.

  3. Once 1&2, are complete, the TPP can onboard with one or all of the CMA9, which can be done automatically or manually depending on the provider. Each bank will check the validity of OB-issued credentials presented (using an API call) then issue credentials which TPPs can use to interact with their APIs.

The customer journey

  1. Any TPP application will need to send the bank the details of the resource it wishes to access, once the customer has reached a point where they are ready to authorise. To keep things simple, we will assume that the customer is seeking to authorise a payment or the flow of some information back to the TPP.

  2. For messages to flow between TPP and bank, a mutually assured, secure connection must be formed between the two. At this point, it is likely that the bank will use the Directory to check that the authorisation status of the TPP is still current, which it can do automatically via an API call.

  3. The TPP must make the scope of the transaction clear to the customer, so that they can consent to it – this might be something as simple as the amount they are going to pay for a product on a date, or giving the ability to check a balance on an account for a period of time. This information will also be sent to the bank to facilitate creation of the authorisation model.

  4. The next step is for the customer to authorise the transaction with the bank. They will be redirected to their bank’s portal / application where they will need to authenticate, and will then have the details of the transaction re-presented to them, and will be prompted to authorise the same.

  5. Once authorisation is provided, the customer is redirected back to the TPP application, and their journey is complete. The application will complete the process of initiating payment or pulling information, which can be used to support a multiple of use cases.

This post and the last have sought to explain the ecosystem, and the basics of the players involved, the design and the process involved in onboarding and making transactions. In the next post we will look to what can be expected after 13 January 2018, the impact of the RTS, and the short term future for open banking.

What is Open Banking?

20 November 2017

TL;DR: – open banking is a new concept in digital banking, which provides for the use of interfaces (and applications) built by third parties accessing banks’ systems. The significance of this change means that, with customers’ permission, access to their accounts, whether for the purposes of pulling information or initiating payments, is now a possibility for third parties. This opens a potentially limitless number of new use cases to the digital ecosystem, which previously weren’t possible due to the very tight control banks exercised over customer accounts.

What is open banking? – open banking is a new concept in digital banking, which provides for the use of interfaces (and applications) built by third parties accessing banks’ systems. In a European context, this has been driven by two pieces of legislation. In the UK, the CMA Order on Retail Banking included as part of its remedies, the need for 9 of the largest retail banks (CMA9) to implement Application Programming Interfaces (APIs) to deliver information about a range of on sale products (Open Data), to deliver information about customer accounts (AISP) and to allow the initiation of payments on a customer’s behalf (PISP).

Across Europe, the Revised Payment Services Directive, better known as PSD2, also provided for the implementation of APIs, as well as a number of changes to system timelines to support this. The principle difference between these two pieces of legislation, is that the CMA Order provided for the creation of a body (the Open Banking Implementation Entity or OBIE) to deliver API specifications or standards, the result being that all of the CMA9 would have at the base of their API ecosystems a common interface.

The reason for this seems to be the relatively specific aims the CMA has in its Order, essentially increasing competition through the levelling of the playing field which larger banks have dominated to date. There is, potentially, a significant economy of scale from the point of view of a developer, in being able to develop one application which can interface with a large number of banks, as opposed to proprietary development for each bank.

There are limited differences to the scope of each piece of legislation, and in many respects the CMA Order and the consequent API specifications can be seen as a stepping stone to PSD2 compliance. Whilst the scope of account information that a bank must publish under the CMA Order is wider, and there is no Open Data element to PSD2, the scope of payments that a bank must allow under PSD2, and the range of accounts are wider.

A further Regulatory Technical Standard on Strong Customer Authentication is expected to be published in January 2018, and will dictate part of the technical design of the interfaces, and which banks will have 18 months to comply with.Most banks impacted by both acts are implementing the required scope of the CMA Order, with a view to achieving PSD2 compliance over the course of the RTS transition period.

What does this all mean for the customer? – in the first instance, the short answer is very little. None of the changes which banks have to implement are customer facing and open banking developing is dependent on whether a market of applications grows and are used by customers. Potentially there is quite a lot of scope for significant change for how customers access financial services.

PISP (Payment Initiation) – both acts provide for banks allowing the initiation of payments by a third party. What this would practically mean is that, rather than using a card to pay for a good or service, an organisation with an online purchase capability would redirect a customer to their banks online portal, where they would be asked to authorise a direct transfer to the merchant in the context of the purchase. Once they’d provided this authorisation using a secure method, the merchant could then initiate the payment which the bank would then execute off line, with a settlement time dependent on the nature of the payment. It should be made clear that this does not give the merchant unfettered access to or control of a customer’s account – this is retained by the customer and the bank, with the latter having the ability to stop an instruction if they had concerns about the merchant.

From the merchant and bank’s point of view, there are substantial cost savings in the use of this method as opposed to traditional card payment, which incurs significant fees. The savings on these could be passed on to customers as an added benefit. The other notable benefit is the immediacy of settlement at the point of execution – once again it is important to make clear that third parties can only initiate payments, and the execution of these (which should take place extremely quickly) remains in the banks’ domain.

The PISP domain also provides for the movement of money between customer accounts – third parties could avail of this service to offer customers gains in leveraging particular rates, avoiding fees and the like. Any third party service is reliant on customer authentication and authorisation, so building a relationship of trust with the customer will be key to the development of an offering.

AISP (Account Information) – contrary to what has been written elsewhere, this service does not grant a third party unfettered access to customer accounts. In real use, a third party would sent up a request to a specific range of information – for example transactions, direct debits, account fees and charges – which the customer would have to then authorise the release of. In contrast to the PISP journey which (at go live) will only be single immediate payments, AISP services can be ongoing so that a third party could request this information multiple times after one authorisation by the customer, though requests can be timed boxed and information can only be pulled a maximum of 4 times a day.

The range of information available is key to analysis of the potential use cases which third parties may seek to develop on behalf of the customer. PSD2 has restricted AISP flows to (de minimis) balance and transaction information, whereas the CMA order provides for a wide range of information. The scope of what is being requested must be defined by the third party and presented to the customer before they authorise it being delivered, so ultimate and granular control of what information flows stays in their hands.

The most frequently cited examples for the AISP flows relate to consolidation of accounts where a customer has multiple accounts with a range of providers, and from a business perspective, giving company accountants direct access to business accounts to assist in the delivery of their services. These are both functions available in today’s marketplace, as is price comparison, and are not particularly exciting. Some challenger banks which already have developed API platforms have linked with third parties to look at more interesting use cases – round up (where a customer’s transactions are rounded up to the nearest single unit and the remainder stored in a savings account) and location based alerts for partnered services being two examples. The reality of the account information space is that it provides for a very significant number of use cases which could improve finance management no end.

The key to the development of this market, whilst trust remains important, will be showing customers what the added benefits of using third parties as the primary interface to their accounts is, as opposed to the banks themselves. This change in customer centricity is perhaps where banks see the greatest threat to open banking, and some are responding in their services already to counter it. Ultimately, much of how open banking effects banks will be dependent on whether they are capable of embracing it, but that should remain the subject of another post.

Conclusion – this closes a brief introduction to open banking. The following topics are planned for the future but any suggestions are welcome.

  • TPPs and the Regulatory Landscape
  • Strategic open banking development for banks
  • Debunking open banking myths