Open Banking API Process ‘to be’

Published on January 1, 2018

Happy New 2018 Year to All!

My best wishes to you in have a luck of safing your bank accounts

An Open Banking initiative is a UK specific adoption of the EU PSD2 Regulation. The UK enthusiasts wanted to be “more saint than the Pope of Rome” and added almost a dozen of new options to be provided via APIs (OB APIs) as shown in Figure 1.

This enumeration of options clearly demonstrates that an overall set of data includes both personal (account data) and highly sensitive commercial data. This results in the need of not only secured communications about this data via the API, but in the highly-secured communication. Is any EU or British Bank ready for this?

Every second publication about PSD2 and Open Banking tells us a story how secured the API-based communication has to be, but I have never seen a one particular description or a standard to support this. “Under PSD2,… Firms intending to provide these [AIS and PIS] services from 13 January 2018 will likely need to apply to be authorised or registered. The Treasury has included an exception to this in the PSRs 2017 (see transitional provisions in Regulation 154). Firms providing AIS or PIS before January 2016 will be able to operate without authorisation or registration, should they wish to do so, until 18 months following the adoption of the EBA’s regulatory technical standards on strong customer authentication and common and secure communication under article 98 of PSD2 (SCA RTS). This is likely to be after mid-2019.” [FCA].

I beg your pardon – how the UK Government supposes the companies to be compliant with something that will be available in a year after the time when incompliance becomes penalised?

 The Open Banking Standard states that “[EU] Member states are required to establish a public register of the home authorised payment institutions, AISPs and their agents… The public register will identify the payment services for which the payment institution is authorised or for which the AISP is registered. The register is to be ‘publicly available for consultation, accessible online, and updated without delay’.” Have anyone seen such registries or known the rules of registration?

Well, according to PSD2 Article 98, the RTS should define authentication and communication from technology perspectives. Following the PSD2 terminology, the “PISP and AISP are required to identify themselves to the AS PSP “every time a payment is initiated” (PIS) or “for each communication session” (AIS) and communicate with the AS PSP, payer, payee, PSU in a secure way in accordance with the common and secure open standards of communication (Article 98(1d)) to be developed as part of the EBA RTS on authentication and communication.” Wonderful, it would be very helpful if the Authority were provided us with the means of verification of these identities and the means of control of the potential fraud related to the requesters and their requests (under Article 96(6) of the PSD2).

Banking.com says, “Banks will have the power to deny PSPs access to a customer’s account, but only for “objectively justified and substantiated” security reasons that have been reported to supervisory bodies. Third-party payment providers will have an obligation to guarantee safe authentication of the user and to ensure that personal data is transmitted through secure channels, and only with the customer’s consent”. This sounds nice, but how they prove (at the moment of their requests reached the Bank’s APIs) that   they fully and reliably implemented all these requirements? What would guarantee to the Bank and to its Account Holders that the claimed consent was given by particular Account Holder freely and that the data is not altered, that the channel was really well secured in the transition and at intermediary hubs? Here, I am talking about potential commercial and wealthy accounts, that can attract serious investments into the breaking of even sophisticated protections.

Banks have a challenge not only to create, but also to execute such protections and controls online and in nearly real time. I do not know how to realise all these controls, but I can reasonably assume what should be done for each OB API request on the Bank’s side. A high-lever processing of such request is illustrated in Figure 2.

In the diagram, a reader can see that a Bank provides an OB API Service, which accepts API requests from a Requester and returns the responses to this Requester via the OB API Service Interface. For simplicity, I have omitted all elements of processing related to handling exceptions, error and bugs.

 I assume, that the OB API Service Interface includes all types of data (information) that is needed to convince the Bank that the request is real, legal and secured, i.e. trustful and suitable for the processing and responding. Otherwise, the request will be denied. In the first step, the data delivered by the request should be extracted from it by the OB API Service or by other services orchestrated by the OB API Service. I do not define accurate service boundaries and responsibilities in the diagram of Figure 2 to keep it at a high-level. I only show that the OB API Service triggers a process, which can be realised as inside of this service as via orchestration of other services. So, the input data to be assessed in this process should include:

1. A confirmation that the Requester is a legal registered entity. Since the Bank does not know who might request an access to the held Accounts, the Bank must verify the identity of the Requester with the Authorised Registry for each request (PSD2 Article 98). It is impossible to store or cache the Requester’s identity to reuse it later and speed up the processing because the Bank should not know how to compare the newly provided identity with the previous one; this is a prerogative of the Authorised Registry only. Otherwise, a distribution of the registration knowledge “opens the door” to an unlimited fraud.
2. A confirmation that the request and related data, e.g. a value of withdrawing from the Account, is not altered during the transmission to the OB API Service Interface. There may be several different methods for verification of the data integrity. One of them is the old PKI-based digital signing. However, PKI also requires verification of the Security Certificate for each request, as well as an entire PKI infrastructure. This verification should confirm that particular request has been issued by the entity registered with the Authorised Registry (each EU Member state may have its own Authorised Registry and there should be a cross-registry verification capability accessible to the banks).
3. Finally, the data related to the identity of the Account Holder and his/her consent must be verified as well. Obviously, that the data integrity should be controlled, but it is not all. The Requester must prove that the consent was provided by specified Account Holder with full understanding of the consequences and voluntarily. At the moment, I do not know how this can be done. If a Bank would issue a special physical or information token for the purpose of the use of PSD2 APIs, how such token can be secured from the Requester and how to prevent the token reuse in the absence of the Account Holder? What Bank would accept as a means of trust in this case? It is a matter of fact that it is the very bank that is still an Account custodian and that is fully responsible to its Account Holder. If the Bank releases an Account information to an inappropriate Requester, the Account Holder can sue the Bank. You can imagine the case if it would be a commercial or wealthy Account.

If any one of the aforementioned assessments of the API’s data brings a negative result, the API request should be denied. Otherwise, the request moves into the processing and, depending on the API type – payment or informational – it passes to appropriate component or another service. The latter executes appropriate operations, and forms the response – outcomes to return. The denial response or the outcomes are propagated via the OB API Service Interface back to the Requester.

I also would like to point an attention of the readers on the overlapping between PSD2 and GDPR regulations related to giving and revoking a user consent. A bank Account information is recognised by GDPR (due to get in force on 25 May 2018) as “personal data”, i.e. the Account Holder gets all rights for managing it, including what to release upon request, in which cases, to whom, when and so forth. Now, imagine a situation where a request from a Third-Party Payments Provider (TPP), which includes the Account Holder’s consent, reaches the Bank. This Bank has a restriction or even a prohibition to operate on this Account set by the same Account Holder (see the “Data Object to fetch Account Holder consent state” in the diagram). This restriction/prohibition had been set by the Account Holder directly with the Bank and, thus, has much hire credence than a request from an unknown TPP. If the Bank responds to the TPP request other than with a denial, the Account Holder gets real legal chances to sue the Bank and win.

With this post, I’d like to warn the developers of the OB APIs and API consuming code that when an API opens personal and commercial accounts, the overall solution is much more complex than a routine WS or REST interfaces and Microservices behind them. This complexity is dictated not by technology, but by fully scaled business capabilities, including a whole spectrum of business risks. Now, the outcome of this development will be validated, tested and continuously challenged not by Project Managers, QA and corporate business stakeholder. In addition, millions of bank customers will watch over these API and related bank behaviour.

I know that many Fintech, other TPPs and even banks count on a revenue generated by the use of OB and PSD2 APIs. I can predict that the very developers will be made guilty in any case of implicit or explicit failure in this endeavour. An implicit failure is a failure of the API-based solution or implementation of the PSD2 or the Open Banking standard. An example of such failure is a mass denial of API requests by banks or a mass denial of giving consent to merchants or TPP caused by the absence of trust from the Account Holder’s side.

When development with APIs and Microservices is focused on internal application, a trust between the provider and consumer is given a priori by the existence of the company. If APIs and Microservices are used between businesses without preliminary established business trust, this is a mistake of IT management and corporate governance; this might be allowed because of unawareness of corporate Compliance and Legal departments. When dealing with PSD2 or Open Banking APIs, the importance of controllable trust between the Account Holders, the Banks and the TPPs is a must have precondition for using the programmatic API and Microservices. If our developers and corporate management do not get it before using the API, we should anticipate a very difficult time and a global fraud attack on our Bank Accounts.

Follow-up

This section is added a few days after writing the article. While the latter considered only programmatic OB/PSD2 API, the follow-up discusses the OB/PSD2 API that expose a user interface. Particularly, an invocation of the OB/PSD2 API results in opening a page in the chosen browser; it may be a Web or Mobile browser.

Such a page has to contain:

1. A field for specifying the business name of the Requester. It is highly recommended that this name would match the name of the merchant or TPP that has initiated the API call and presents the page to the customer.
2. A control that would allow to upload an evidence of the Requester’s registration with the Authorised Registry. This evidence should be verified with the particular Authorised Registry. The name or contact information of the Authorised Registry may be provided together with the evidence or as an area on the page to be filled in.
3. A field for specifying the name of the Account Holder
4. A set of fields for identifying the Account in particular Bank (bank dependent)
5. A field to be filled with the description of the Bank’s service requested via given API. If this is a payment service, the action – deposit or withdraw – should be explicitly chosen and the amount of money have to be specified in an additional field.
6. A field where the consent with aforementioned description could be explicitly specified by the customer
7. A control that can set the time period (in hours, minutes, days, months) when the described service and related conditions can be executed. It is highly recommended adding another control that can specify a number of times of the service execution during the specified time period.
8. A set of controls that support the log-in into the Account by the Account Holder personally. The log-in should be under the cover of a 2-factor authentication model. If the log-in fails, all information in the form must be discarded and erased.

It is a responsibility of the API provider to guarantee the integrity, confidentiality and robustness of delivery of the page content into the Bank’s environment over the Web if the Account Holder log-in succeeded. The Bank then needs only to verify the identity of the TPP with the specified Authorised Registry (as well as the legitimacy of the Authorised Registry itself).