Frequently Asked Questions

We’re aware of an issue that’s causing the same Transaction ID to be appearing more than once, if the transactions are related. For example, a non-sterling transaction and the "non-sterling fee" transaction share the same ID – this should be unique. This issue is due to be fixed in our release scheduled for early December 2020

Identified as being linked to our create a company issue we are working on the fix which will solve both of these and should be in by the end of the week. Please check back for any updates. 

We are aware of a current issue with our create company functionality where an error is being displayed suggesting your developer status is inactive. We are working hard to fix this at the moment, please check back to see when this is fixed.

Whilst we are working on a fix for an issue in the FirstPaymentDateTime Field there is a workaround that can be applied in the meantime. Please set the date to the following valid format: 2020-07-24T16:29:24.00Z

There is an issue reported by some TPPs on payments APIs where they are getting an error stating that “x-jws-signature” header submitted in the request is invalid.

This occurrs when the TPPs use the OBSEAL (eIDAS) signing certificate to sign the payments payloads and create the x-jws-signature.

In our current implementation we always validate x-jws-signature and its details in accordance with OB Legacy certificates. Please bear with us whilst we fix this.

Due to a contradicting ask within the OBIE DCR spec 3.1 which has been fed back to OBIE, currently our designs only accept org_ID matching iss value from the information seen in the documentation. We will be updating this to reflect the software_ID matching the iss value and should be released in Q2.

Due to how we translate the date range you may receive a 500 error when requesting 15 months of transaction data. This is likely to occur when requests are made late evening or on weekends.

As a work around please retry your request with +/- 1 day in the date range.

Due to a system limit, if a member has a large number of transactions on their account an error will be returned, rather than returning the members' transactions.

**There is a work around for Third Parties, who will have to request the same data in smaller date ranges to avoid returning an error.

API Affected: GET /accounts/{AccountId}/transactions

Make sure you first register with the FCA or National Competent Authority of your host country and enrol with the Open Banking Directory. We can’t register any unenrolled organisation.

Next, you will need to register your application with us. Details on how to do this can be found on the Open Banking Directory Developer site. We only support application registration (onboarding) through APIs – there’s no manual process for this. You’ll need to use the POST /register API.

We’ll then send you some client information once your registration’s complete, you can then use this to identify your application in all future Open Banking service requests. This information is important and must be held securely and not be shared with anyone.

Here are some common onboarding tips to help you register first time


Should match your TPP software statement, issued by the OBIE. Your redirect_uri parameter can be 2,000 characters, or fewer


Should be the software_client_id value taken from the SSA


This should match what is on your SSA and should be written as "openid" and then followed by "accounts", "payments" or "fundsconfirmations" depending on your app. These can also be grouped to support multiple scopes for your app e.g. "openid accounts payments fundsconfirmations"


The expiry date should be in a Unix time stamp format and not wrapped in speech marks

iss value

The value in the outer JWT should match TPP_orgid from your SSA

aud value

This value should be taken from the well known endpoint


This value should be the time at which the request is issued by you. This should be provided in the Unix time stamp format and not wrapped in speech mark


Your token_endpoint_auth_method should be "tls_client_auth"


Should be "application/JWT" only


Must be "code id_token" only


A unique identifier for the JWT. The value must be a UUIDv4GUID

Yes we do. 

If the Third Party is requesting to re-authorise the same list of accounts from the initial authorisation, the PSU (NBS Member) will skip the ‘account selection’ step of the Digital journey and be directed back to the Third Party once they have authenticated in our channel.

We currently do not offer this functionality, but are looking to include it in the future.

We support the authentication exemption, which means that you will be able to set up enduring access to 90 days worth of balances and transactions data via a single authentication of the customer (PSD2 RTS Article 10)

  • When authentication is completed, you will be able to access all account information the customer has agreed to share during the initial session (1 hour duration), including up to 15 months of transactions data for Personal Current Accounts, and up to 90 days of transactions data for Credit Cards.
  • Subsequent requests for Balance and Transaction data no more than 90 days old will not need to be reauthenticated until the authorisation has expired
  • Where requests are made for account information other than Balances or Transactions, or for data more than 90 days old, a reauthentication is required. We will return a 401(Unauthenticated/Unauthorised) HTTP code to inform you where this scenario occurs

A summary of our technical documentation can be found on our Implementation Guide.

Below you can find a table of all future live APIs and their deployment dates.

API Version Live Date
GET /accounts/{AccountID}/statements v3.1 November
GET /accounts/{AccountID}/statements/{StatementId}/file v3.1 November
GET /accounts/{AccountID}/party v3.1 November

As well as using our Developer Portal UI to access our Sandbox, you can also call our APIs direct from your application by using the below URL followed by the endpoint information that you wish to call.

The only exception to this is if you are calling our GET /.well-known endpoint where you will need to use the below URL.

If you want to take a look at our Member authorisation journeys, you can find these on our Implementation Guide.

If we receive more than four requests for data where the Member is not present from a third party within a 24hr period, we will process requests on the understanding that the third party (AISP) has obtained consent from our Member to request data more frequently.

  • In live, we support version 1.1 of the PIS endpoints but these are not available in our Sandbox.
  • We also offer AIS version 1.1 and 2 in live but only offer version 3 in the Sandbox.
  • Open Data APIs are available to everyone in our production environment hence they are not part of our Sandbox.
  • Here in our Sandbox environment, we have provided a number of test accounts covering a multitude of scenarios that can be used to fully test your application. In live, you will be using Member's real data.
  • We are providing a simulated Customer Auth UI where authorisations will be consented to, by default, as there is no Member present in this journey.
  • To test out expiration of a consent, you will need to wait for the test account’s authorisation to expire.
  • To test revocation of a consent, you will need to create an authorisation on a test account and then delete it by calling the DELETE endpoint for that consent. You can then come back and call your chosen test account to cover this scenario.

If you double URL encode, your calls to both OAuth and GET/ authorize endpoints will fail.

From 13 March, we will only accept requests signed with the PS256 signing algorithm in both the live and Sandbox services.

Our payloads and ID Tokens will be signed using PS256.

You can deregister an app, or your entire account, by getting in touch with our team through our Support page. We'll let you know once we've done it.

Below is a list of the APIs and versions available in live and the Sandbox

API Live Sandbox
POST /account-requests v1.1, v2 N/A
DELETE /account-requests/{AccountRequestID} v1.1, v2 N/A
GET /account-requests/{AccountRequestId} v2 N/A
GET /accounts v1.1, v2, v3, v3.1       v3.1
GET /accounts/{AccountID} v1.1, v2, v3, v3.1 v3.1
GET /accounts/{AccountID}/balances v1.1, v2, v3, v3.1 v3.1
GET /accounts/{AccountID}/beneficiaries v1.1, v2, v3, v3.1 v3.1
GET /accounts/{AccountID}/direct-debits v1.1, v2, v3, v3.1 v3.1
GET /accounts/{AccountID}/scheduled-payments v1.1, v2, v3, v3.1 v3.1
GET /accounts/{AccountID}/standing-orders v1.1, v2, v3, v3.1 v3.1
GET /accounts/{AccountID}/transactions v1.1, v2, v3, v3.1 v3.1
GET /accounts/{AccountID}/product v1.1, v2, v3, v3.1 v3.1
DELETE /account-access-consents/{ConsentId} v3, v3.1 v3.1
POST /account-access-consents v3, v3.1 v3.1
GET /account-access-consents/{ConsentId} v3, v3.1 v3.1
GET /accounts/{AccountId}/statements N/A v3.1
GET /accounts/{AccountId}/statements/{StatementId}/file N/A v3.1
GET /accounts/{AccountId}/offers v3.1 v3.1
POST /payments v1.1 N/A
POST /payments-submission v1.1 N/A
GET /payment-submissions/{PaymentSubmissionId} v1.1 N/A
POST /domestic-payment-consents v3, v3.1 v3.1
GET /domestic-payment-consents/{ConsentId} v3, v3.1 v3.1
POST /domestic-payments v3, v3.1 v3.1
GET /domestic-payments/{DomesticPaymentId} v3, v3.1 v3.1
POST /domestic-scheduled-payment-consents v3, v3.1 v3.1
GET /domestic-scheduled-payment-consents/{ConsentId} v3, v3.1 v3.1
POST /domestic-scheduled-payments v3, v3.1 v3.1
GET /domestic-scheduled-payments/{DomesticScheduledPaymentId} v3, v3.1 v3.1
POST /domestic-standing-order-consents v3, v3.1 v3.1
GET /domestic-standing-order-consents/{ConsentId} v3, v3.1 v3.1
POST /domestic-standing-orders v3, v3.1 v3.1
GET /domestic-standing-orders/{DomesticStandingOrderId} v3, v3.1 v3.1
GET /domestic-payment-consents/{ConsentId}/fundconfirmation v3.1 v3.1
POST /funds-confirmation-consents v3.1 v3.1
GET /funds-confirmation-consents/{ConsentId} v3.1 v3.1
POST /funds-confirmations v3.1 v3.1
DELETE /funds-confirmation-consents/{ConsentId} v3.1 v3.1
Open Data
ATM v2.2 N/A
Branch v2.2 N/A
Personal Current Accounts v2.2 N/A
Service Quality Metrix v1 N/A

The following utility APIs are versionless and are available in both the live environment and Sandbox; GET /.wellknown; GET /authorize; POST /register; POST /token 

APIs for version 3 now return granular error codes. All previous APIs return standard HTTP codes. The HTTP codes used within Nationwide Open Banking APIs are:

  • 400 (Bad Request) 
  • 401 (Unauthenticated/Unauthorised)
  • 404 (Not Found)
  • 403 (Forbidden)
  • 429 (Too Many Requests)
  • 500 (Internal Server Error)
  • 503 (Services unavailable or too busy)

For more details, refer to the detailed API specifications available on the central industry Open Banking website.