Security Profiles

Getting Started – Open Banking API Security Profile

The Open Banking Standard has adopted FAPI 1 as the security profile. FAPI is a highly secured OAuth profile provided by the Open ID Foundation.

V3 of the Open Banking Standard used FAPI 1 Implementers Draft 2, which was the current specification available at the time of release. This draft version of the specification was deprecated with the final release of FAPI 1 Advanced in 2021 and support/certification services removed in December 2024.

With the introduction of v4 of the Open Banking API Standard it was determined by a vote at the Technical Design Authority to implement the final release of the FAPI 1 Advanced specification.

Other pages in this section

The Open Banking Standard 

Getting started with FAPI

As FAPI builds upon a number of existing specifications it is recommended that implementers adopt a certified product.  OpenID maintain a list of providers who have passed certification and can be found here:

It is important to note that FAPI introduces new security features over and above OAuth which require the use of certificates for both transport layer and message signing.

The Open Banking Directory provides PSD2 (and UK Payment Services Regulations 2017) compliant certificates for both purposes.

Additional considerations

Implementation advice

The UK Open Banking Ecosystem requires an intent ID to be pre-generated using the POST /{API-TYPE}-Consents API endpoint.  This endpoint uses the client credentials grant.

Additionally, ecosystem specific ACR values are used, these are:

FAPI 1 Advanced allows requests without an acr value to be specified however we encourage all TPPs to continue sending the acr claim in requests.  An ASPSP receiving a request without this claim should determine the appropriate level of auth required of the user and the activity being requested  

Clock Skew 

The FAPI 1 spec is silent on the approach participants should take to clock skew. Participants should determine what level of clock skew they are willing to accept and publish details on their developer portal.   

The following has been proposed for inclusion in FAPI 2: 

We encourage participants use this as a starting point to determine appropriate values for their organisations. 


Open Banking maintains a model bank implementation, TPPs are advised to test their FAPI implementation against the model bank before connecting to ASPSPs in the ecosystem.

Information on integrating with the model bank can be found here

TPPs should refer to ASPSPs /.well-known file and developer portals for ASPSP specific implementation information


OpenID provide a FAPI conformance tool.  This is open source, can be downloaded freely and run against an implementation to validate compliance with the FAPI 1 specification is being met.


ASPSPs can certify their FAPI implementations with OIDF to demonstrate conformance with the specification. Please note this service is provided by OIDF and a fee is required for certification.

Migration from FAPI 1 ID2 to FAPI 1 Advanced Final 

FAPI 1 Advanced has a few key differences from Implementers Draft 2, and TPP’s should pay close attention to both the nbf claim (mandatory in the final spec) and the exp claim to ensure alignment of dates/times. 

There is no single migration approach which will address all FAPI 1 ID2 implementations and participants should identify what options are available to them based on their current infrastructure/implementation. The following guidance should be used as a baseline for understanding key steps in the migration and adapted for a participant’s specific implementation where possible: 

Migration to FAPI 1 Advanced should be done in two stages, in order to ensure minimal disruption. Due to a lack of versioning in key URLS and complexities in merging new infrastructure with the migration it is recommended that if an ASPSP dual-runs v3.1.X and v4.0 that FAPI 1 Advanced is introduced on the v3 implementation at the same time as v4. 

Stage 1: 

ASPSPs validate their current infrastructure supports FAPI 1 Advanced’s core requirements and publish a switch over date on their developer portal. After this date requests not meeting the FAPI 1 Advanced spec will be rejected. 

TPPs include nbf claims in requests to 3.1.X APIs.  Clients must ensure the lifetime of their request objects is under 60 minutes. 

ASPSPs should validate the nbf claim if present.

Stage 2 (date of switch over): 

ASPSPs should enable DNSSEC, HTTP STS and remove any keys with duplicate kids (following usual procedures for key rotation). 

ASPSP must reject any requests without a valid nbf claim after the switch over date. 

ASPSPs must accept requests without an acr claim, determining the appropriate level of authentication to use based on the activity being requested.