Frequently Asked Questions

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.