LinkedIn
Twitter
Here are an API Architect's thoughts on the new rules around Open Banking in the UK and the EU. I will be providing a summary, along with some opinions, from an API perspective. For a banking perspective, please see here.
CMA
The Competition and Markets Authority are a government department in the UK. They released a report titled 'Retail Banking Market Investigation' which contains a number of remedies that affected banks must implement.
Their objective was to understand:
- Is there a weak customer response due to lack of engagement or barriers to search and switch?
- Are there barriers to entry and expansion for banks?
- Is the level of concentration of banks having an adverse effect? (7)
The report proposed a number of remedies to improve customer response. It identifies "Open APIs are central to our package of remedies". (169)
The remedies can be summarized as follows:
Foundation Measures
- Largest retail banks in GB and NI to adopt an Open Banking Standard. This is to be created by the OBWG. (168,169)
- Service Quality Information must be provided. The preferred format of this information is likeliness to recommend the bank to a friend. (172-173)
- Customer prompts must be provided as 'most customers hold a bank account for many years without ever being prompted to make a conscious choice about whether to continue or switch provider'. (175)
Current Account Switching Measures
- Improve awareness and confidence in measures switch current accounts.
- Guarantee the transaction history in previously closed accounts
- Account number portability is suggested, however this is unlikely giving the cost.
PCA Overdrafts
- Banks must auto-enroll customers in an unarranged overdraft alert (193)
Measures for Small Businesses
- CMA promotes the work of the Nesta charity's competition to create a Comparison tool as a 'one-stop-shop' for SMEs to compare banks by price, service quality and lending criteria.
- There are a number of other measures including more transparency and detailed information for loans and the sharing of information.
Other Points
- "Customers who are satisfied about privacy and security safeguards, and are willing to give consent, will be able to share their own transaction data with trusted intermediaries, which can then offer advice tailored to the individual customer". (168) This sounds a lot like a use case for Three-legged OAuth 2.
- Please note that CMA does not prescribe any specific security mechanisms.
- Public Information must be provided by March 2017 - 'for example about prices, terms and conditions and branch location' (171)
You can find the full summary of the report here.
OBWG
If you are a member of the Open Bank Working Group, you can get the latest specifications on their Confluence site. Once release, specifications will be found here.
The Open Bank Working Group was set up as a result of the CMA report results, and is made up of banks, open data and FinTech professionals. The CMA report suggested that APIs should be used to address the issues found, however much of the detail was deferred. The OBWG is defining the Open Banking standard which contains details on how these Open APIs should be implemented and secured.
The standards are still evolving, but here is what we know so far...
Data Standard
Sensitive commercial data is not in scope of the Open Banking Framework. Only the following
- Open Data, such as Product Information and ATM locations
- Customer transaction data, such as Balance Information and Transaction History
- Customer reference data, such as Eligibility Checks and KYC process results
- Aggregated data, such as average cash withdrawals per month for a given post code
Permissions and Scopes must related directly to reading/writing different types of data
The data model to be used is still being investigated. It is likely that either the ISO 20022 Financial Repository model will be used, or the Open Banking Standard will define a consistent data model
API Standard
- API Schemas must be developed and stored in public repositories. Whilst the format hasn't been specified yet, Swagger/Open API, HAL and RAML have been considered. I personally consider Swagger/Open API to be the most suitable format.
- APIs must be RESTful and support JSON content types.
- Northbound API Versioning must be implemented and support major and minor versioning
- Key Performance Indicators will need to be published to indicate API performance. Monitoring best practices should be followed.
- GET requests should support HTTP Cache-Control headers to improve scalability and performance
- Write operations should be modeled asynchronously where possible.
Security Standard
- Sensitive information should not be included in URIs, to avoid them being stored in server logs, browser history etc.
- Scopes should not be part of the resource path, as they may change over time
- Sensitive information should be tokenized, e.g. "account1" instead of an account number
- Users should be able to grant and revoke consent to third parties allowing them to access their data. Access should have an expiry time.
- Data Attribute Providers (Banks) and Third Parties (Developer Apps) should retain control over authentication
- OAuth 2 / Open ID Connect are recommended. In my opinion, the authorization_code grant type appears most suitable given the information at this time.
- Out-of-band / Multi-factor authentication should be supported
- TLS 1.2 must be used
- There should be a central registry containing a whitelist of approved companies. Certificates will be used to manage this.
Developer Engagement
- A "developer hub" should be provided containing reference documentation for APIs. In my opinion it is likely that there will be both a Central Developer Portal and one for each Payment Service Provider.
- A sandbox should be available for developers to use the core banking APIs.
Other Notes
- Section 7c 10.3 encourages penetration and performance testing as well as code reviews to encourage "secure coding".
- Section 7c 11 states that even Open APIs may require some form of Identification (e.g. API Key) to reduce the risk of denial of service attacks.
- Section 7a 4.1 states "A working assumption has been made that the Open Banking API will initially be pull rather than push and that streaming protocols will not be considered in early phases." In my opinion, sticking with this assumption will improve usability, scalability and developer adoption. Wherever possible, APIs should return a 202 Accepted with a request id. They can poll a 'requests status' API to see if the request is still in progress or has completed.
Use Cases
Chapter 6.1 lists a number of possible customer journeys. I recommend you check them out in detail, however they cover:
- Current Account Comparison Services
- Personal Finance Management
- Access To Credit
- Affordability Check
- Online Accounting
- Fraud Detection
To keep up to date with the latest developments, keep checking here.
PSD2
For a high level summary of PSD2, please check here. The full directive can be read here.
PSD2 looks to support two new types of payment service that have entered the market.
- Payment Initiation Services - "a service to initiate a payment order at the request of the payment service user with respect to a payment account held at another payment service provider"
- Account Information Services - "an online service to provide consolidated information on one or more payment accounts held by the payment service user with either another payment service provider or with more than one payment service provider"
The directive requires that Payment Service Providers (i.e. banks) expose certain data through APIs to be consumed by AISPs and PISPs.
In order to establish trust between all parties, a central registry will be created with all AISPs, PISPs and PSPs registered. Specific details of the registry and it's implementation are still emerging.
Here are the key points for me:
- Third parties should be able to authenticate using the PSP. This means each Bank must develop its own Identity APIs
- Article 1.49 states "provide proof to the payment system that its internal arrangements are sufficiently robust against all kinds of risk". This means that API providers will need to demonstrate that they have performance tested and penetration tested their platform suitably.
- Article 1.69 states "The obligation to keep personalised security credentials safe is of the utmost importance to protect the funds of the payment service user and to limit the risks relating to fraud and unauthorised access to the payment account". As such, it is vital to use the correct OAuth 2 grant type to ensure that user credentials are not exposed to third party apps, and that client credentials are stored securely.
- Article 1.96 states "The security measures should be compatible with the level of risk involved in the payment service". For example, it would not make sense to require multi-factor authentication for an ATM Location API.
- Strong authentication in the context of PSD2 refers to Multi-Factor authentication. (Article 4.30). It is required (Article 97) when a customer:
- accesses its payment account online
- initiates an electronic payment transaction
- carries out any action through a remote channel which may imply a risk of payment fraud or other abuses
- Article 64 discusses the issuing and revoking of customer consent. It addresses the same issues as previously discussed in this article and I believe they are met by the use of the OAuth 2 protocol with scopes.
- Article 98 indicates that the development of technical standards on authentication and communication will be defined at a later time.
Andrea Enria gave an update on PSD2 progress on 21st February 2017. Please find her update here.
I will continue to update this article as and when more details emerge about the state of Open Banking in the UK and EU. Please comment with corrections/opinions, and Apigeeks feel free to edit and contribute!
