The lack of competition in the financial services industry has been one of the main factors that led the European Union to introduce the second version of the Payment Services Directive (PSD2) , which aims to improve competition by enabling and encouraging bank account holders to share, in a controlled and secure way, their account data. This approach, along with economic opportunities, has clearly also important privacy and security implications that must be carefully considered when building systems allowing data sharing on such scale.
To provide a standard API for the sharing of customer data across different banks, the UK, similarly to other European countries, introduced the Open Banking Standard . The regulation encompasses several API specifications suitable for different Third Party Providers (TPPs) who aim to service consumers that consent to sharing their data. The adoption of a standardised interface allows interoperability and simplifies the implementation of systems for sharing data between banks and TPPs.
In such context, it is clear that formally validating complex software systems, like the one covered in the present work, that can affected by design error and implementation bugs, is of upmost importance to ensure that the system behaves correctly with respect to the specification and a number of desirable properties.
In this paper, we present a formal security analysis of the Open Banking Standard APIs, focusing on the verification of the correctness of the Account and Transaction API protocol. The work relies on a previously proposed methodology  which provided a practical approach to protocol modelling and verification. The methodology utilises the Alice and Bob notation (AnB)  to specify a formal model of the protocol that can be formally verified with the OFMC model checker, which has been used to model and verify a significant number of security protocols, for example a projects like AVANTSSAR .
We formalised and verified a number of security goals that are implicit in the requirements. Although most goals were satisfied in our analysis, the lack of rigourous definition of security properties in the standard can be a source of ambiguity, potentially leading to different interpretation of the security requirements in the implementation. Moreover, the standard seems to rely on a number of current web technologies that could potentially become obsolete to future technological and security needs.
To the best of our knowledge, our formal model represents the first attempt to formally analyse Open Banking protocols. Recently, other authors  made an evaluation of the integration of a web application with the Danish Nordea’s Open Banking APIs considering the security threats of the underlining technology, in light of OWASP Top 10 Web Application Security Risks list. However, they did not analyse the security of Open Banking itself considering and assessing security goals as we did. Therefore, we believe a formal analysis can be valuable for stakeholders considering the adoption of a standard that can have a significant and long impact on the efficiency and security of the financial sector.
2.1 The Open Banking Standard Overview
The Payment Services Directive (PSD) is a European legislation, which aims to improve payment services across the EU in terms of safety and innovation . The first version of PSD was adopted in 2007 , but as the digitalisation of the economy progressed, and new payment services appeared, it became outdated and insufficient to ensure the provision of consumer protection and adequate competition. Therefore, a revised version was adopted in November 2015 in an attempt to:
Ensure that all payment service providers have equal operating conditions;
Expand the market for new means of payment;
Ensure the security of consumers using the payment services .
To deliver the standard, the Open Banking Implementation Entity was established in 2016 by the UK Competition and Markets Authority (CMA) . The Open Banking Working Group (OBWG) published a report on the Open Banking Standard , in which they outlined two key outcomes:
An open API for sharing data regarding the services offered by Account Servicing Payment Service Providers (ASPSPs), e.g. banks;
An open API for sharing the account data of Payment Service Users (PSUs) provided by ASPSPs.
Open Banking is not only concerned about the API endpoints (e.g. location of resources accessible by third parties, such as developers, to build banking and financial applications), but also about data and security standards. The data standard provides data models to the API data format. The API standard covers the API’s operational requirements. The security standard covers API security requirements.
The Open Banking Standard has been released in phases with the latest in September 2018 . By October 2019, the standard has been adopted by 65 regulated ASPSPs with 123 TPPs providing services . This illustrates the significance Open Banking has on the financial services industry and thereby the importance of verifying its standard’s correctness.
2.2 Account Information Service Provider (AISP)
The Account and Transaction API protocol (ATP) flow , which allows AISPs access to the PSUs account data, is shown in Figure 1. An AISP is a regulated entity allowed by ASPSPs to access a PSU’s account data if the PSU provides their consent. This type of access is read-only as the AISPs are not expected to directly affect the payment accounts they are allowed access to. An AISP can then provide different services having the PSU’s account and transaction data, including applications that provide a user-friendly view of the states of the different payment accounts held by the PSU, budgeting advice, price comparisons and product recommendations.
The protocol is initiated with the PSU asking for information regarding their payment account(s) from an AISP (Step 1). The AISP then attempts to create an account access consent with the corresponding ASPSP, based on the access permissions agreed upon with the PSU. First, the AISP authenticates itself to the ASPSP through a client credential grant, which is an approach for machine-to-machine authentication. The ASPSP then provides the AISP with an access token used to request the creation of the consent resource (Step 2). At this point, the created account access consent has to be authorised to be used by the AISP to access the PSU’s account data. This requires the PSUs to authenticate themselves to the ASPSP, followed by authorising the consent. During this phase, the PSU has to select the payment accounts(s) for which the chosen permissions should apply. The AISP then obtains an access token to the account data (Step 3). With this token, the AISP has to first retrieve the accessible accounts, including their unique IDs, through the accounts endpoint. The IDs can later be used to request the data of specific accounts (Step 4). To retrieve specific PSU account data (e.g. balances, transactions, direct debits, beneficiaries, etc.) the AISP will have to request the data via the appropriate link using the correct endpoint and method from the ASPSP.
2.3 Methodology and Specification Language
The formal verification of Open Banking API presented in this work is based on a protocol verification methodology proposed in . The methodology utilises the Alice and Bob notation (AnB)  to specify a formal model of the protocol that can be formally verified through information flow (secrecy and authenticity) goals. Such notation abstracts from implementation details, but allows formal representation and analysis of the security-relevant characteristics of protocols.
An AnB specification comprises of several sections. The Types section declares the different identifiers used in the protocol. This includes the agents, constant and variable (random) numbers and transparent functions. Transparent functions are user-defined through their signature, thereby abstracting from their implementation details (i.e. they are uninterpreted). The Knowledge section describes the initial data each agent has before running the protocol. Fresh values, The information flow is described in the Actions section, where details about messages exchanged by agents are specified. Furthermore, the model can be used to verify specific security properties, such as (weak and strong) authentication and secrecy goals:
A weakly authenticates B on M: agent A has evidence that the message M has been endorsed by agent B with the intention to send it to A (i.e. non-injective agreement );
A authenticates B on M: weak authentication plus evidence of the freshness of the message M (i.e injective agreement );
M secret between A, B: message M is kept secret among listed agents.
The formal model captures the protocol requirements . While the Open Banking API describes in details the information-flow, it lacks definitions of security goals that the exchanges between agents are meant to convey. Therefore, part of our work consisted in identifying suitable goals for the protocol model.
For the verification, we used the Open-Source Fixed-Point Model-Checker (OFMC), a symbolic model-checker supporting the AnB notation. Moreover, the AnBx Compiler and Code Generator  was used to pre-process the model to benefit from a stricter type system and support the extension to AnB that allows named expression abstractions (Definitions section).
We define an AnBx model of the Account and Transaction API protocol (ATP)  to analyse and verify its information flow accurately. We abstract from, and do not directly specify dependant technologies like OAuth 2.0 , which are defined in the Open Banking Security profile .
Confidential messages are exchanged over the internet. Therefore, the specification  mandates the use of Transport Layer Security (TLS) between all parties, as in the Financial API specification . Verifying TLS is not our focus: we assume its security guarantees by partially simulating TLS with confidential and authentic communication using AnB bullet channels . For example, *->* represents a secure channel (authenticated and confidential) and can be used as a suitable abstraction for TLS with mutual authentication .
We abstract from signing exchanged payloads too. Our objective is to model the weakest version the specification allows for as it is likely to be the most vulnerable. Consequently, as the additional layer of encryption is optional, we do not cover it in the model, and may be part of future work. To help explain the model, a sequence diagram containing AnBx action labels is given in Figure 2. We describe each of the AnBx model sections next.
Roles and Responsibilities
There are four agents that participate in the protocol. The PSU initiates the protocol aiming to grant an AISP limited access to their account data. The AISP aims to obtain access to the PSU’s account data to provide the user with a service. The ASPSP has two separate roles: the authorisation server (
aspspA), authenticating AISPs and PSUs to generate tokens that enable AISPs access to endpoints; and the resource server (
aspspR), maintaining resources like consents and PSU account data.
By observing the responsibilities of each agent, the authorisation and resource servers must be trusted parties: if any of them acts maliciously, the protocol can be trivially broken. Trusted agents in AnB are represented by identifiers beginning with a lower-case letter.
The PSU and AISP know each other given that before protocol execution, the PSU has been in contact with the AISP to exchange permissions and to inform of the ASPSP of contact intent. The AISP is assumed to identify the ASPSP’s corresponding authorisation and resource servers. Thus, the AISP knows the identities of both servers. The authorisation and resource servers are known to each other and their identities are also known by the PSU.
PSU/AISP. Authentication requires the PSU and AISP to share a secret with the authorisation server. This secret is known a priori as represented by transparent function calls
fAISPSecret(AISP), which allows us to abstract from the secret agreement mechanism.
Authorisation and Resource Servers. The authorisation server performs numerous state-changing operations over the protocol execution through transparent functions:
fClientCredToken generates a token acquired through a client credential grant;
fAuthCode generates an authorisation code; and
fAuthCodeToken generates a token acquired through the authorisation code. The authorisation server is also aware of its PSU and AISP secrets in order to authenticate them. The resource server performs state-changing operations through transparent functions:
fGetIntent to create and retrieve a consent resource, respectively;
fFetchAccounts retrieves a list of all PSU accounts;
fAuthoriseIntent updates consent authorisation; and
fAccountsEndpoint returns PSU account data.
Roles Restriction. To make our model more realistic, we impose restrictions about the role performed by different agents. To declare which agent is not allowed to act as another agent, we can use the where keyword at the end of the Knowledge section. For example, the PSU cannot act as the AISP, which is unrealistic as in the UK AISPs are regulated by the Financial Conduct Authority (FCA) . We also excluded the possibility for the PSU to act as either of the authorisation or resource servers, as these servers are considered trusted.
The protocol actions are described next alongside its exchanged messages as labelled in Figure 2. Actions are labelled according to each protocol step. There are four steps: 1) Account Information Request; 2) Account Access Consent Setup; 3) Consent Authorisation; and 4) Data Request.
Account Information Request.
First, the PSU informs the AISP of them wanting to share account information through an intent agreement (A1.1): it is a numeric abstraction representing intent agreement between PSU and AISP. This assumes that the PSU already has the permissions asked by the AISP. The PSU then chooses which permissions to accept and adds further restrictions on data access if required, thereby obtaining the intent agreement. This intent agreement is not defined in the requirements and we assume this agreement could differ between different protocol runs. There are two options: either defining it as a random number (the one we chose as the most general option); or variable dependent on parameters passed to a transparent function.
Account Access Consent Setup.
To be able to create a consent resource, the AISP informs the authorisation server that it requires an access token and provides the necessary data for such a token (A2.1). The authorisation server provides the AISP with the access token, referred here as client token, to request the creation of a consent resource from the resource server (A2.2). This is done after the authorisation server internally authenticates the AISP on their credentials. After that, the AISP asks the resource server to create a consent resource based on the agreement between the AISP and PSU (A2.3).
The requirements lack information regarding the communication between the authorisation and resource servers. As a result, we assume these servers are responsible for their roles only and that any limited and controlled access to each other’s resources, if exists, does not have any side-effect on the protocol run. In this case, when the authorisation server requires access to a consent or the PSU accounts, it is assumed that it has to request such information from the resource server. After creating a consent resource based on the request of the AISP, the resource server provides the resource including its identifier to the AISP (A2.4) for later reference.
Authorisation is defined in stages: 1) initiation of consent authorisation; 2) review and authorise the consent; and 3) obtain an access token to the PSU’s account data.
After a consent resource has been created, the AISP instructs the PSU to redirect to the authorisation server with the required data to request for consent authorisation (A3.1.1). Following, the PSU redirects to the authorisation server and requests consent authorisation (A3.1.2).
After internally authenticating the PSU, the authorisation server requests from the resource server resources needed to be reviewed by the PSU before authorising the consent (A3.2.1). The resource server provides the authorisation server with the requested resources (A3.2.2). The authorisation server then forwards these resources to the PSU to review and authorise the consent (A3.2.3), and inform the authorisation server of which of their accounts to associate with the consent (A3.2.4). After the PSU authorises the consent, the authorisation server forwards the authorisation process along with the required data to the resource server (A3.2.5). This is because the authorisation server does not update the consent resources as it is not its responsibility to maintain resources, as previously assumed. Furthermore, sub-step of the requirements sequence diagram in , shows the authorisation server explicitly requesting the resource server to update the consent resource. After authorising the consent resource, the resource server updates the consent’s state and informs the authorisation server of their success (A3.2.6).
When informed that the consent resource has been authorised, the authorisation server instructs the PSU to redirect to the AISP with the required data to request for an access token (A3.3.1). The PSU redirects back to the AISP, providing it with the required information to obtain an access token to the PSU account data, referred to as an authorisation token (A3.3.2). The AISP then requests such a token from the authorisation server (A3.3.3): part of the data used for the request is only obtained after consent authorisation. Subsequently, the authorisation server provides the AISP with the access token (A3.3.4). This is done after the authorisation server internally authenticates the AISP on their credentials.
As the AISP now has the access token, they request the resource server to return the permitted PSU account data (A4.1). The resource server then obtains and returns such data to the AISP (A4.2).
For each action, different messages are exchanged; we give examples of their structure next, where full details is beyond the scope of this paper and can be found in . We abstract from data exchanges that do not affect the model’s goals verification. For example, HTTP response codes and UUIDs are simplified.
Different from most AnB protocols, ATP messages do not have explicit cryptographic expressions. That is because at numerous stages, exchanged authorisation codes/tokens are externally dependant (i.e. OAuth2.0, TLS, etc.). Thus, what would usually be nonces exchanges through some shared crypto principles, have to be abstracted through transparent functions in order to stick to defining the ATP protocol itself, instead of its myriad dependant (internal) protocols.
For example, during account access-consent setup (A2.1), the
ClientTokenReq message is defined as
AISP, fAISPSecret(AISP), which entails the AISP’s identity followed by its secret to the authorisation server, whom must know about it. A more involved exchange (
AuthTokenReq) occurs during consent authorisation (A3.3.3) when the AISP requests from the authorisation server a different token for access to the PSU data after various consent authorisation messages have been exchanged (A3.1.1–3.3.2). This includes the original credentials used for the
ClientTokenReq message (i.e. the AISP’s shared secret with the authorisation server), as well as the actual authorisation code generated after authorising the declared/exchanged intent
IntentRes (A2.4). The intent/consent is defined as
fCreateIntent(ClientToken, IntentAgreement): a transparent function that verifies the validity of the AISP’s client token and creates the account access consent resource based on the intent agreement.
The output, specifically the consent’s ID, is then input into the authorisation code transparent function (
fAuthCode(IntentRes)), which calculates the intermediate authorisation code [9, Sect. 1.3.1] used later by the AISP to request the authorisation token.
Fully expanded,the response message
AuthTokenRes to the token request is
This layering of transparent functions entails various underlying state changes enabling/preventing the correct execution of the protocol, hence characterising whether the various aspects (e.g. agreements, consents, etc.) hold. Details of these transparent functions specification and implementation is also beyond the scope of this paper.
The primary objective of AnB models is to satisfy some protocols’ properties of interest, i.e. security goals than can be verified with some verification tools. There are no explicitly stated goals within the ATP requirements . The goals we identified (and verified) are based on our understanding of the protocol and on its dependencies. For example, OAuth 2.0 security considerations [9, P.52-P.60], protocol use cases in [24, P.20-P.23] and our expectations of the protocol.
We identified eight goals: four on message secrecy, and four on authentication.
Two goals (G1 and G2) are obvious: the exchanged secrets/credentials between the AISP and PSU and the authorisation server remain secret whilst requesting for a client token (Action 2.1 in the specification) and acquiring consent authorisation (A3.1.2 and A3.3.3). That is because if the AISP credentials are leaked (A2.1), many attacks would be possible (for instance [9, Sect. 10.2] discusses client impersonation). Another secrecy goal (G3) states that various exchanged tokens (A2.2–A2.3 and A3.3.4–A4.1) remain secret between the AISP and the authorisation and resource servers. As tokens are AISP bound, a compromised token cannot be directly used. However, [9, Sect. 10.3] requires tokens to be confidential, to prevent attacks involving valid token injection [9, Sect. 10.12]. These goals clearly indicate the inherited potential vulnerabilities of the Account and Transaction Protocol (ATP) dependencies. The final secrecy goal (G7) is about the resource server message to the AISP (A4.2) and is obvious: account information must remain secret.
The authentication goals relate to the PSU authenticating the consent resource to authorise (G4), the resource server authenticating the PSU’s selected accounts information (G5) and the AISP authenticating the PSU’s account information from the resource server (G8). This last goal between the AISP and the resource server is crucial in verifying the integrity of the account data sent to the AISP by the resource server. In addition to direct data modification, it is important to verify that old data cannot be replayed. For instance, in the case of affordability check, if the PSU was an intruder and modified the data, they could trick an AISP into providing a product they are not eligible for. This goal also enforces fraud detection: if the transactional data can be modified by an intruder to hide fraudulent activity. Given the redirections from the PSU to the authorisation server and AISP (A3.1.1 and A3.3.1–A3.3.2), we weakly authenticate that those endpoints cannot be modified by an intruder to help avoid redirected URI manipulation [9, Sect. 10.6] and phishing attacks [9, Sect. 10.11] (G6).
4 Results and Evaluation
We see this work from two perspectives: the actual AnB model and its verification, and the experiment of having a MSc student (the first author) without prior experience in formalism or security protocols tackle and find previously unknown problems. Work was completed in person-days involving: learning AnB and its tools (;%), creating the AnB model versions (;%), verifying the model goals (;%) and documenting the process (;%). When needed, the student had access to experts in the field, supervising his work. The learning time shows the low barrier to entry in using AnB. This is particularly the case given the significant dependencies the Account and Transaction API requirements have [9, 25, 21].
A significant portion of time was spent creating the model, which is unsurprising; and given the acquired experience, we have empirical evidence which suggests the creation time reduces as more models are tackled by the same person. Verification time is similar: it takes a significant amount to time to learn the tool insights; yet this can be leveraged across multiple examples. Crucially, this is an insignificant amount of time to discover important unknown issues and verify implicitly assumed/desired properties of the protocol, compared to the effort required to develop a concrete implementation say in Python . It should be noted that the AnBx compiler  also enables Java code generation, which can be deployed to further experiment with the protocol. Thus, we argue our methodology  can be an effective approach to help design and develop reliable safety/security-critical protocols.
Model Development. The Open Banking ATP is complex and with multiple dependencies. The AnB model aims to provide an abstract and accurate view of its essential aspects and to verify key properties. The initial AnB model was overly detailed with unnecessary data exchanges. To reach the right level of abstraction, we then decided to first determine the protocol goals prior to abstracting. Even after such endevour, verification was unwieldy: it ran for over two days without response. As is common within model checking problems, state explosion must be tackled beyond abstracting details, abstract on irrelevant data.
Restricting the role of the PSU, where it had to be different from the AISP and servers, considerably reduced the state space. This led to termination with goal verification to be reduced to about seven hours. This enabled us to identify further steps to abstract related to data, which reduced the verification time to about six minutes. A final abstraction related to the various TLS-related steps, which we encoded using AnB bullet channels used to encrypt messages based on the identities of the sender and recipient. Their internal efficiency within OFMC led the final version to verify within eight seconds. This exponential efficiency (up to 5 orders of magnitude) increase is not uncommon in model checking problems, so long the right abstractions are taken alongside expert knowledge of the tool’s implementation.
Model Correctness. We used the OFMC model checker  to verify the eight goals described above. At first, three goals (G4,G7,G8) about PSU intent authentication and account information secrecy and integrity failed. This led us to check these goals independently in order to study their reason for failure quickly. The witness for the PSU authentication failure (G4) relates to the resource server authenticating with an unknown agent rather than the PSU. This was fixed by having the resource server being aware of the PSU’s identity early on when setting up the access consent with the AISP (A3.2). Thus, this failure identifies a previously undocumented vulnerability, which our modification fixes.
The account information goals fail due to a limitation of bullet channels: they do not protect against replay attacks, hence their use here allowed breaking both secrecy (G7) and integrity (G8). The intruder could respond to the AISP’s request for account data by replaying a previous message. This breaks integrity as the response received by the AISP, and perceived to be the account data, has been modified. As the data replayed is known to the intruder, it also breaks secrecy of the account data. However, the TLS protocol does protect against message replay [5, P.93-P.94]. To deal with this limitation and ensure that freshness would resolve the issue, we modified the model to include a nonce generated and sent by the AISP when requesting for the PSU account data and is expected to be part of the response.
These modifications enable checking all goals for one session. Multiple sessions verification is important as there could be attacks relying on multiple concurrent protocol runs. Due to increased state space and limited hardware, we were unable to fully verify the model for two parallel sessions due to hardware and software limitations. As customary in such situation (e.g.  for iKP and SET), we were able to obtain partial results by increasing the search space up to the available resource limits (search space depth: plies, GB RAM, hours to run) without being able to reach any attack state.
This paper details the AnB model of the novel Open Banking Account and Transaction protocol. It is a security-critical protocol, which is being enforced on the largest banks in Europe. Given the protocol’s significance and expected wider use, verifying its correctness is crucial. We relied on a verification methodology  using various languages and tools. Our findings were disseminated as part of a presentation on PSD2 at a UK Finance event, with representatives from Visa and MasterCard, as well as several banks. Some of the identified goals were known, others not. The audience was particularly keen on the time/cost analysis. As part of the work, we considered also the socio-technical aspects described in Section 4 indicating that the methodology provides a practical development path for producing dependable formal protocols. Even though the verification pushed the OFMC model checker to its limits, the time/cost involved is negligible compared to the alternative of direct implementation . Our future work will focus on the modelling of the protocol’s state and transparent functions specification in VDM-SL: this is aimed at discovering underlying vulnerabilities related to the myriad of dependant technologies (e.g. OAuth2, TLS, etc.).
We are also grateful to the EPSRC EP/N023641/1 STRATA programme grant for financially supporting this work.
-  (2019) Account and Transaction API Protocol in the Open Banking Standard. Master’s Thesis, School of Computing, Newcastle University. Cited by: §3.
-  (2012) The avantssar platform for the automated validation of trust and security of service-oriented architectures. In Tools and Algorithms for the Construction and Analysis of Systems, C. Flanagan and B. König (Eds.), Berlin, Heidelberg, pp. 267–282. External Links: Cited by: §1.
-  (2005-06) OFMC: a symbolic model checker for security protocols. International Journal of Information Security. Cited by: §1, §4.
-  (2016) Security protocol specification and verification with AnBx. Journal of Inf. Security and Applications 30, pp. 46–63. External Links: Cited by: §4.
-  (2008-08) The Transport Layer Security (TLS) Protocol Version 1.2. Note: https://tools.ietf.org/html/rfc5246. Last accessed date [22 August 2019] Cited by: §4.
-  Payment Services Directive: frequently asked questions. Note: https://tinyurl.com/hmnqqjx. Last accessed date [22 August 2019] Cited by: §2.1.
-  About the FCA. Note: https://www.fca.org.uk/about/the-fca. Last accessed date [22 August 2019] Cited by: §3.
-  (2018) A Methodology for Protocol Verification applied to EMV. In Formal Methods: Foundations and Applications - 21th Brazilian Symposium, SBMF 2018, Salvador, Brazil, November 28-30, 2018, Proceedings, Lecture Notes in Computer Science, Vol. 11254. Cited by: §1, §2.3, §4, §5.
-  (2012-10) The OAuth 2.0 Authorization Framework. Note: https://tools.ietf.org/html/rfc6749. Last accessed date [22 August 2019] Cited by: §3, §3, §3, §3, §3, §4.
-  (2019) Towards secure Open Banking architecture: an evaluation with OWASP. In International Conference on Network and System Security, pp. 185–198. Cited by: §1.
-  (1997) A hierarchy of authentication specifications. In CSFW’97, pp. 31–43. Cited by: 1st item, 2nd item.
-  (2009) Secure pseudonymous channels. In Computer Security–ESORICS 2009: 14th European Symposium on Research in, Proceedings, pp. 337. Cited by: §3.
-  (2009) The open-source fixed-point model checker for symbolic analysis of security protocols. In Foundations of Security Analysis and Design V, pp. 166–194. Cited by: §2.3.
-  (2009) Algebraic properties in Alice and Bob notation. In Int. Conf. on Availability, Reliability and Security (ARES 2009), pp. 433–440. External Links: Cited by: §1, §2.3.
-  (2015) AnBx: automatic generation and verification of security protocols implementations. In Foundations & Practice of Security, LNCS 9482. Cited by: §2.3, §4.
-  (2020)(Website) External Links: Cited by: §4, §5.
-  About us - Open Banking. Note: https://www.openbanking.org.uk/about-us/. Last accessed date [22 August 2019] Cited by: §2.1.
-  Account and Transaction API Specification - v3.1.1. Note: https://tinyurl.com/qs643hq. Last accessed date [22 August 2019] Cited by: Figure 1, §2.2, §3.
-  Open Banking October Highlights - Open Banking. Note: https://tinyurl.com/wc49kkd. Last accessed date [14 January 2020] Cited by: §2.1.
-  Open Banking publishes Open Banking Standards version 3.0 - Open Banking. Note: https://tinyurl.com/u94u3zg. Last accessed date [22 August 2019] Cited by: §2.1.
-  Open Banking Security Profile - Implementer’s Draft v1.1.2. Note: https://tinyurl.com/ybra9v3o. Last accessed date [22 August 2019] Cited by: §3, §3, §4.
-  Payment Initiation API Specification - v3.1.1. Note: https://tinyurl.com/v4a4hvd. Last accessed date [22 August 2019] Cited by: §2.3.
-  UK Open Banking OIDC Security Profile. Note: https://tinyurl.com/t2m7hs5. Last accessed date [22 August 2019] Cited by: §3.
-  (2016-02) The Open Banking Standard. Open Banking Working Group. Cited by: §1, §2.1, §3.
-  (2018-10) Financial-grade API - Part 1: Read-Only API Security Profile. Note: https://tinyurl.com/w24hhkz. Last accessed date [22 August 2019] Cited by: §3, §4.
-  (2007-11) DIRECTIVE 2007/64/EC. Official Journal of the European Union. Cited by: §2.1.
-  (2015-11) DIRECTIVE (EU) 2015/2366. Official Journal of the European Union. Cited by: §1, 3rd item.