For documentation of the APIs and testing them, follow the below links as required:
- PISP - Payment Initiation Service Provider
- AISP - Account Information Service Provider
- Confirmation of Funds
- PISP - Payment Initiation Service Provider
- Payment Initiation
- Domestic Payments
- Domestic Scheduled Payments
- Domestic Standing Orders
- File Payments
- POST /file-payment-consents
- POST /file-payment-consents/{ConsentId}/file
- GET /file-payment-consents/{ConsentId}
- GET /file-payment-consents/{ConsentId}/file
- POST /file-payments
- GET /file-payments/{FilePaymentId}
- POST /file-payments
- GET /file-payments/{FilePaymentId}
- GET /file-payments/{FilePaymentId}/report-file
- International Payments
- International Scheduled Payments
- International Standing Orders
- Authenticate
- Login
- Generate Token
- Payment Initiation
- AISP - Account Information Service Provider
- Confirmation of Funds
PISP - Payment Initiation Service Provider
| Endpoints | |||||||||
Resource | HTTP Operation | Endpoint | Mandatory ? | Scope | Grant Type | Message Signing | Idempotency Key | Request Object | Response Object |
| domestic-payment-consents | POST | POST /domestic-payment-consents | Yes | payments | Client Credentials | Signed Request Signed Response | Yes | OBWriteDomesticConsent1 | OBWriteDomesticConsentResponse1 |
| domestic-payment-consents | GET | GET /domestic-payment-consents/{ConsentId} | Yes | payments | Client Credentials | Signed Response | No | NA | OBWriteDomesticConsentResponse1 |
| domestic-payments | POST | POST /domestic-payments | Yes | payments | Authorization Code | Signed Request Signed Response | Yes | OBWriteDomestic1 | OBWriteDomesticResponse1 |
| domestic-payments | GET | GET /domestic-payments/{DomesticPaymentId} | Yes | payments | Client Credentials | Signed Response | No | NA | OBWriteDomesticResponse1 |
Payment Initiation
Domestic Payments
POST /domestic-payment-consents |
The API endpoint allows the PISP to ask an ASPSP to create a new domestic-payment-consent resource.
|
GET /domestic-payment-consents/{ConsentId} |
A PISP can optionally retrieve a payment consent resource that they have created to check its status. |
/domestic-payment-consents/{ConsentId}/funds-confirmation |
The API endpoint allows the PISP to ask an ASPSP to confirm funds on a domestic-payment-consent resource. |
POST /domestic-payments |
Once the domestic-payment-consent has been authorised by the PSU, the PISP can proceed to submitting the domestic-payment for processing.
|
GET /domestic-payments/{DomesticPaymentId} |
A PISP can retrieve the domestic-payment to check its status. |
Domestic Scheduled Payments
| Endpoints | |||||||||
Resource | HTTP Operation | Endpoint | Mandatory ? | Scope | Grant Type | Message Signing | Idempotency Key | Request Object | Response Object |
| domestic-scheduled-payment-consents | POST | POST /domestic-scheduled-payment-consents | Conditional | payments | Client Credentials | Signed Request Signed Response | Yes | OBWriteDomesticScheduledConsent1 | OBWriteDomesticScheduledConsentResponse1 |
| domestic-scheduled-payment-consents | GET | GET /domestic-scheduled-payment-consents/{ConsentId} | Mandatory (if resource POST implemented) | payments | Client Credentials | Signed Response | No | NA | OBWriteDomesticScheduledConsentResponse1 |
| domestic-scheduled-payments | POST | POST /domestic-scheduled-payments | Conditional | payments | Authorization Code | Signed Request Signed Response | Yes | OBWriteDomesticScheduled1 | OBWriteDomesticScheduledResponse1 |
| domestic-scheduled-payments | GET | GET /domestic-scheduled-payments/{DomesticScheduledPaymentId} | Mandatory (if resource POST implemented) | payments | Client Credentials | Signed Response | No | NA | OBWriteDomesticScheduledResponse1 |
POST /domestic-scheduled-payment-consents |
The API endpoint allows the PISP to ask an ASPSP to create a new domestic-scheduled-payment-consent resource.
|
GET /domestic-scheduled-payment-consents/{ConsentId} |
A PISP can optionally retrieve a payment consent resource that they have created to check its status. |
POST /domestic-scheduled-payments |
Once the domestic-scheduled-payment-consent has been authorised by the PSU, the PISP can proceed to submitting the domestic-scheduled-payment for processing:
|
GET /domestic-scheduled-payments/{DomesticScheduledPaymentId} |
A PISP can retrieve the domestic-scheduled-payment to check its status. |
Domestic Standing Orders
| Endpoints | |||||||||
Resource | HTTP Operation | Endpoint | Mandatory? | Scope | Grant Type | Message Signing | Idempotency Key | Request Object | Response Object |
| domestic-standing-order-consents | POST | POST /domestic-standing-order-consents | Conditional | payments | Client Credentials | Signed Request Signed Response | Yes | OBWriteDomesticStandingOrderConsent1 | OBWriteDomesticStandingOrderConsentResponse1 |
| domestic-standing-order-consents | GET | GET /domestic-standing-order-consents/{ConsentId} | Mandatory (if resource POST implemented) | payments | Client Credentials | Signed Response | No | NA | OBWriteDomesticStandingOrderConsentResponse1 |
| domestic-standing-orders | POST | POST /domestic-standing-orders | Conditional | payments | Authorization Code | Signed Request Signed Response | Yes | OBWriteDomesticStandingOrder1 | OBWriteDomesticStandingOrderResponse1 |
| domestic-standing-orders | GET | GET /domestic-standing-orders/{DomesticStandingOrderId} | Mandatory (if resource POST implemented) | payments | Client Credentials | Signed Response | No | NA | OBWriteDomesticStandingOrderResponse1 |
POST /domestic-standing-order-consents |
The API endpoint allows the PISP to ask an ASPSP to create a new domestic-standing-order-consent resource.
|
GET /domestic-standing-order-consents/{ConsentId} |
A PISP can optionally retrieve a payment consent resource that they have created to check its status. . |
POST /domestic-standing-orders |
Once the domestic-standing-order-consent has been authorised by the PSU, the PISP can proceed to submitting the domestic-standing-order for processing:
|
GET /domestic-standing-orders/{DomesticStandingOrderId} |
A PISP can retrieve the domestic-standing-order to check its status.
|
File Payments
| Endpoints | |||||||||
Resource | HTTP Operation | Endpoint | Mandatory ? | Scope | Grant Type | Message Signing | Idempotency Key | Request Object | Response Object |
| file-payment-consents | POST | POST /file-payment-consents | Conditional | payments | Client Credentials | Signed Request Signed Response | Yes | OBWriteFileConsent1 | OBWriteFileConsentResponse1 |
| file-payment-consents | GET | GET /file-payment-consents/{ConsentId} | Mandatory (if resource POST implemented) | payments | Client Credentials | Signed Response | No | NA | OBWriteFileConsentResponse1 |
| file-payment-consents | POST | POST /file-payment-consents/{ConsentId}/file | Conditional | payments | Client Credentials
| Signed Request Signed Response | Yes | File | NA |
| file-payment-consents | GET | GET /file-payment-consents/{ConsentId}/file | Conditional | payments | Client Credentials | Signed Response | No | NA | File |
| file-payments | POST | POST /file-payments | Conditional | payments | Authorization Code | Signed Request Signed Response | Yes | OBWriteFile1 | OBWriteFileResponse1 |
| file-payments | GET | GET /file-payments/{FilePaymentId} | Mandatory (if resource POST implemented) | payments | Client Credentials | Signed Response | No | NA | OBWriteFileResponse1 |
| file-payments | GET | GET /file-payments/{FilePaymentId}/report-file | Conditional | payments | Client Credentials | Signed Response | No | NA | File |
POST /file-payment-consents |
The API endpoint allows the PISP to ask an ASPSP to create a new file-payment-consent resource.
|
POST /file-payment-consents/{ConsentId}/file |
The API endpoint allows the PISP to upload a file to an ASPSP, against a file-payment-consent resource.
|
GET /file-payment-consents/{ConsentId} |
A PISP can optionally retrieve a payment consent resource that they have created to check its status. |
GET /file-payment-consents/{ConsentId}/file |
The API endpoint allows the PISP to download a file (that had been uploaded against a file-payment-consent resource) from an ASPSP.
|
POST /file-payments |
Once the file-payment-consent has been authorised by the PSU, the PISP can proceed to submit the file-payment for processing:
|
GET /file-payments/{FilePaymentId} |
A PISP can retrieve the file-payment to check its status. |
POST /file-payments |
Once the file-payment-consent has been authorised by the PSU, the PISP can proceed to submit the file-payment for processing:
|
GET /file-payments/{FilePaymentId} |
A PISP can retrieve the file-payment to check its status. |
GET /file-payments/{FilePaymentId}/report-file |
A PISP can retrieve the file-payment to check its status. |
International Payments
| Endpoints | |||||||||
Resource | HTTP Operation | Endpoint | Mandatory ? | Scope | Grant Type | Message Signing | Idempotency Key | Request Object | Response Object |
| international-payment-consents | POST | POST /international-payment-consents | Conditional | payments | Client Credentials | Signed Request Signed Response | Yes | OBWriteInternationalConsent1 | OBWriteInternationalConsentResponse1 |
| international-payment-consents | GET | GET /international-payment-consents/{ConsentId} | Mandatory (if resource POST implemented) | payments | Client Credentials | Signed Response | No | NA | OBWriteInternationalConsentResponse1 |
| international-payments | POST | POST /international-payments | Conditional | payments | Authorization Code | Signed Request Signed Response | Yes | OBWriteInternational1 | OBWriteInternationalResponse1 |
| international-payments | GET | GET /international-payments/{InternationalPaymentId} | Mandatory (if resource POST implemented) | payments | Client Credentials | Signed Response | No | NA | OBWriteInternationalResponse1 |
POST /international-payment-consents
1 | POST /international-payment-consents |
The API endpoint allows the PISP to ask an ASPSP to create a new international-payment-consent resource.
- The POST action indicates to the ASPSP that a payment consent has been staged. At this point, the PSU may not have been identified by the ASPSP, and the request payload may not contain any information of the account that should be debited.
- The endpoint allows the PISP to send a copy of the consent (between PSU and PISP) to the ASPSP for the PSU to authorise.
- The ASPSP creates the international-payment-consent resource and responds with a unique ConsentId to refer to the resource.
The default Status is "AwaitingAuthorisation" immediately after the international-payment-consent has been created.
Status |
|---|
| AwaitingAuthorisation |
GET /international-payment-consents/{ConsentId}
1 | GET /international-payment-consents/{ConsentId} |
A PISP can optionally retrieve a payment consent resource that they have created to check its status.
Status
Once the PSU authorises the payment-consent resource - the Status of the payment-consent resource will be updated with "Authorised".
If the PSU rejects the consent or the international-payment-consent has failed some other ASPSP validation, the Status will be set to "Rejected".
Once an international-payment has been successfully created using the international-payment-consent, the Status of the international-payment-consent will be set to "Consumed".
The available Status codes for the international-payment-consent resource are:
Status |
|---|
| AwaitingAuthorisation |
| Rejected |
| Authorised |
| Consumed |
POST /international-payments
1 | POST /international-payments |
Once the international-payment-consent has been authorised by the PSU, the PISP can proceed to submit the international-payment for processing:
- This is done by making a POST request to the international-payments endpoint.
- This request is an instruction to the ASPSP to begin the international single immediate payment journey. The international payment must be submitted immediately, however, there are some scenarios where the international payment may not be executed immediately (e.g. busy periods at the ASPSP).
- The PISP must ensure that the Initiation and Risk sections of the international-payment match the corresponding Initiation and Risk sections of the international-payment-consent resource. If the two do not match, the ASPSP must not process the request and must respond with a 400 (Bad Request).
- Any operations on the international-payment resource will not result in a Status change for the international-payment resource.
Status
An international-payment can only be created if its corresponding international-payment-consent resource has the status of "Authorised".
The international-payment resource that is created successfully must have one of the following PaymentStatusCode code-set enumerations:
Status |
|---|
| Pending |
| Rejected |
| AcceptedSettlementInProcess |
GET /international-payments/{InternationalPaymentId}
1 | GET /international-payments/{InternationalPaymentId} |
A PISP can retrieve the international-payment to check its status.
Status
The international-payment resource must have one of the following PaymentStatusCode code-set enumerations:
Status |
|---|
| Pending |
| Rejected |
| AcceptedSettlementInProcess |
| AcceptedSettlementCompleted |
International Scheduled Payments
| Endpoints | |||||||||
Resource | HTTP Operation | Endpoint | Mandatory ? | Scope | Grant Type | Message Signing | Idempotency Key | Request Object | Response Object |
| international-scheduled-payment-consents | POST | POST /international-scheduled-payment-consents | Conditional | payments | Client Credentials | Signed Request Signed Response | Yes | OBWriteInternationalScheduledConsent1 | OBWriteInternationalScheduledConsentResponse1 |
| international-scheduled-payment-consents | GET | GET /international-scheduled-payment-consents/{ConsentId} | Mandatory (if resource POST implemented) | payments | Client Credentials | Signed Response | No | NA | OBWriteInternationalScheduledConsentResponse1 |
| international-scheduled-payments | POST | POST /international-scheduled-payments | Conditional | payments | Authorization Code | Signed Request Signed Response | Yes | OBWriteInternationalScheduled1 | OBWriteInternationalScheduledResponse1 |
| international-scheduled-payments | GET | GET /international-scheduled-payments/{InternationalScheduledPaymentId} | Mandatory (if resource POST implemented) | payments | Client Credentials | Signed Response | No | NA | OBWriteInternationalScheduledResponse1 |
POST /international-scheduled-payment-consents
1 | POST /international-scheduled-payment-consents |
The API endpoint allows the PISP to ask an ASPSP to create a new international-scheduled-payment-consent resource.
- The POST action indicates to the ASPSP that an international scheduled payment consent has been staged. At this point, the PSU may not have been identified by the ASPSP, and the request payload may not contain any information of the account that should be debited.
- The endpoint allows the PISP to send a copy of the consent (between PSU and PISP) to the ASPSP for the PSU to authorise.
- The ASPSP creates the international-scheduled-payment-consent resource and responds with a unique ConsentId to refer to the resource.
Status
The default Status is "AwaitingAuthorisation" immediately after the international-scheduled-payment-consent has been created.
Status |
|---|
| AwaitingAuthorisation |
GET /international-scheduled-payment-consents/{ConsentId}
1 | GET /international-scheduled-payment-consents/{ConsentId} |
A PISP can optionally retrieve a payment consent resource that they have created to check its status.
Status
Once the PSU authorises the payment-consent resource - the Status of the payment-consent resource will be updated with "Authorised".
If the PSU rejects the consent or the international-scheduled-payment-consent has failed some other ASPSP validation, the Status will be set to "Rejected".
Once an international-scheduled-payment has been successfully created using the international-scheduled-payment-consent, the Status of the international-scheduled-payment-consent will be set to "Consumed".
The available Status codes for the international-scheduled-payment-consent resource are:
Status |
|---|
| AwaitingAuthorisation |
| Rejected |
| Authorised |
| Consumed |
POST /international-scheduled-payments
1 | POST /international-scheduled-payments |
Once the international-scheduled-payment-consent has been authorised by the PSU, the PISP can proceed to submit the international-scheduled-payment for processing:
- This is done by making a POST request to the international-scheduled-payments endpoint.
- This request is an instruction to the ASPSP to begin the international scheduled payment journey. The PISP must submit the international scheduled payment immediately, however, there are some scenarios where the ASPSP may not warehouse the international scheduled payment immediately (e.g. busy periods at the ASPSP).
- The PISP must ensure that the Initiation and Risk sections of the international-scheduled-payment match the corresponding Initiation and Risk sections of the international-scheduled-payment-consent resource. If the two do not match, the ASPSP must not process the request and must respond with a 400 (Bad Request).
- Any operations on the international-scheduled-payment resource will not result in a Status change for the international-scheduled-payment resource.
Status
An international-scheduled-payment can only be created if its corresponding international-scheduled-payment-consent resource has the status of "Authorised".
The international-scheduled-payment resource that is created successfully must have one of the following Status codes:
Status |
|---|
| InitiationPending |
| InitiationFailed |
| InitiationCompleted |
GET /international-scheduled-payments/{InternationalScheduledPaymentId}
1 | GET /international-scheduled-payments/{InternationalScheduledPaymentId} |
A PISP can retrieve the international-scheduled-payment to check its status.
Status
The international-scheduled-payment resource must have one of the following Status codes:
Status |
|---|
| InitiationPending |
| InitiationFailed |
| InitiationCompleted |
International Standing Orders
| Endpoints | |||||||||
Resource | HTTP Operation | Endpoint | Mandatory ? | Scope | Grant Type | Message Signing | Idempotency Key | Request Object | Response Object |
| international-standing-order-consents | POST | POST /international-standing-order-consents | Conditional | payments | Client Credentials | Signed Request Signed Response | Yes | OBWriteInternationalStandingOrderConsent1 | OBWriteInternationalStandingOrderConsentResponse1 |
| international-standing-order-consents | GET | GET /international-standing-order-consents/{ConsentId} | Mandatory (if resource POST implemented) | payments | Client Credentials | Signed Response | No | NA | OBWriteInternationalStandingOrderConsentResponse1 |
| international-standing-orders | POST | POST /international-standing-orders | Conditional | payments | Authorization Code | Signed Request Signed Response | Yes | OBWriteInternationalStandingOrder1 | OBWriteInternationalStandingOrderResponse1 |
| international-standing-orders | GET | GET /international-standing-orders/{InternationalStandingOrderPaymentId} | Mandatory (if resource POST implemented) | payments | Client Credentials | Signed Response | No | NA | OBWriteInternationalStandingOrderResponse1 |
POST /international-standing-order-consents
1 | POST /international-standing-order-consents |
The API endpoint allows the PISP to ask an ASPSP to create a new international-standing-order-consent resource.
- The POST action indicates to the ASPSP that an international standing order consent has been staged. At this point, the PSU may not have been identified by the ASPSP, and the request payload may not contain any information of the account that should be debited.
- The endpoint allows the PISP to send a copy of the consent (between PSU and PISP) to the ASPSP for the PSU to authorise.
- The ASPSP creates the international-standing-order-consent resource and responds with a unique ConsentId to refer to the resource.
Status
The default Status is "AwaitingAuthorisation" immediately after the international-standing-order-consent has been created.
Status |
|---|
| AwaitingAuthorisation |
GET /international-standing-order-consents/{ConsentId}
1 | GET /international-standing-order-consents/{ConsentId} |
A PISP can optionally retrieve a payment consent resource that they have created to check its status.
Status
Once the PSU authorises the payment-consent resource - the Status of the payment-consent resource will be updated with "Authorised".
If the PSU rejects the consent or the international-standing-order-consent has failed some other ASPSP validation, the Status will be set to "Rejected".
Once an international-standing-orders has been successfully created using the international-standing-order-consent, the Status of the international-standing-order-consent will be set to "Consumed".
The available Status codes for the international-standing-order-consent resource are:
Status |
|---|
| AwaitingAuthorisation |
| Rejected |
| Authorised |
| Consumed |
POST /international-standing-orders
1 | POST /international-standing-orders |
Once the international-standing-order-consent has been authorised by the PSU, the PISP can proceed to submit the international-standing-orders for processing:
- This is done by making a POST request to the international-standing-orders endpoint.
- This request is an instruction to the ASPSP to begin the international standing order journey. The PISP must submit the international standing order immediately, however, there are some scenarios where the ASPSP may not warehouse the international standing order immediately (e.g. busy periods at the ASPSP).
- The PISP must ensure that the Initiation and Risk sections of the international-standing-orders match the corresponding Initiation and Risk sections of the international-standing-order-consent resource. If the two do not match, the ASPSP must not process the request and must respond with a 400 (Bad Request).
- Any operations on the international-standing-orders resource will not result in a Status change for the international-standing-orders resource.
Status
An international-standing-orders can only be created if its corresponding international-standing-order-consent resource has the status of "Authorised".
The international-standing-orders resource that is created successfully must have one of the following Status codes
Status |
|---|
| InitiationPending |
| InitiationFailed |
| InitiationCompleted |
GET /international-standing-orders/{InternationalStandingOrderPaymentId}
1 | GET /international-standing-orders/{InternationalStandingOrderPaymentId} |
A PISP can retrieve the international-standing-orders to check its status.
Status
The international-standing-orders resource must have one of the following Status codes:
Status |
|---|
| InitiationPending |
| InitiationFailed |
| InitiationCompleted |
Authenticate
| Method Type | Method Name | Description |
| GET | authenticate |
Login
| Method Type | Method Name | Description |
| GET | loginpage | |
| POST | consent | |
| POST | authenticate |
Generate Token
| Method Type | Method Name | Description |
| POST | generatetoken |
AISP - Account Information Service Provider
Account Information
Account Access
| Endpoints | ||||||||||
Resource | HTTP Operation | Endpoint | Mandatory? | Scope | Grant Type | Idempotency Key | Parameters | Request Object | Response Object | |
| 1 | account-access-consents | POST | POST /account-access-consents | Mandatory | accounts | Client Credentials | No | OBReadConsent1 | OBReadConsentResponse1 | |
| 2 | account-access-consents | GET | GET /account-access-consents/{ConsentId} | Mandatory | accounts | Client Credentials | No | OBReadConsentResponse1 | ||
| 3 | account-access-consents | DELETE | DELETE /account-access-consents/{ConsentId} | Mandatory | accounts | Client Credentials | No | |||
POST /account-access-consents
The API allows the AISP to ask an ASPSP to create a new account-access-consent resource.
- This API effectively allows the AISP to send a copy of the consent to the ASPSP to authorise access to account and transaction information.
- An AISP is not able to pre-select a set of accounts for account-access-consent authorisation. This is because the behaviour of the pre-selected accounts, after authorisation, is not clear from a Legal perspective.
- An ASPSP creates the account-access-consent resource and responds with a unique ConsentId to refer to the resource.
- Prior to calling the API, the AISP must have an access token issued by the ASPSP using a client credentials grant.
GET /account-access-consents/{ConsentId}
The PSU must authenticate with the ASPSP and authorise the account-access-consent for the account-access-consent to be successfully setup.
The account-access-consent resource that is created successfully must have the following Status code-list enumeration:
Status | Status Description | |
| 1 | AwaitingAuthorisation | The account access consent is awaiting authorisation. |
After authorisation has taken place the account-access-consent resource may have these following statuses.
Status | Status Description | |
| 1 | Rejected | The account access consent has been rejected. |
| 2 | Authorised | The account access consent has been successfully authorised. |
| 3 | Revoked | The account access consent has been revoked via the ASPSP interface. |
GET /account-access-consents/{ConsentId}
An AISP may optionally retrieve an account-access-consent resource that they have created to check its status.
Prior to calling the API, the AISP must have an access token issued by the ASPSP using a client credentials grant.
The usage of this API endpoint will be subject to an ASPSP's fair usage policies.
Account Access Consent Status
Once the PSU authorises the account-access-consent resource - the Status of the account-access-consent resource will be updated with "Authorised".
The available Status code-list enumerations for the account-access-consent resource are:
Status | Status Description | |
| 1 | Rejected | The account access consent has been rejected. |
| 2 | AwaitingAuthorisation | The account access consent is awaiting authorisation. |
| 3 | Authorised | The account access consent has been successfully authorised. |
| 4 | Revoked | The account access consent has been revoked via the ASPSP interface. |
DELETE /account-access-consents/{ConsentId}
If the PSU revokes consent to data access with the AISP - the AISP must delete the account-access-consent resource with the ASPSP before confirming consent revocation with the PSU.
- This is done by making a call to DELETE the account-access-consent resource.
- Prior to calling the API, the AISP must have an access token issued by the ASPSP using a client credentials grant.
Accounts
Endpoints for the resource - and available methods.
| Endpoints | ||||||||||
Resource | HTTP Operation | Endpoint | Mandatory? | Scope | Grant Type | Idempotency Key | Parameters | Request Object | Response Object | |
| 1 | accounts | GET | GET /accounts | Mandatory | accounts | Authorization Code | No | Pagination | OBReadAccount2 | |
| 2 | accounts | GET | GET /accounts/{AccountId} | Mandatory | accounts | Authorization Code | No | OBReadAccount2 | ||
GET /accounts
The first step for an AISP after an account-request is authorised - is to call the GET /accounts endpoint.
An AISP will be given the full list of accounts (the AccountId(s)) that the PSU has authorised the AISP to access. The AccountId(s) returned may then be used to retrieve other resources for a specific AccountId. The selection of authorised accounts happens only at the ASPSP's interface.
GET /accounts/{AccountId}
An AISP may retrieve the account information resources for the AccountId (which is retrieved in the call to GET /accounts).
Balances
| Endpoints | ||||||||||
Resource | HTTP Operation | Endpoint | Mandatory? | Scope | Grant Type | Idempotency Key | Parameters | Request Object | Response Object | |
| 1 | balances | GET | GET /accounts/{AccountId}/balances | Mandatory | accounts | Authorization Code | No | OBReadBalance1 | ||
| 2 | balances | GET | GET /balances | Optional | accounts | Authorization Code | No | Pagination | OBReadBalance1 | |
GET /accounts/{AccountId}/balances
An AISP may retrieve the account balance information resource for a specific AccountId (which is retrieved in the call to GET /accounts).
GET /balances
If an ASPSP has implemented the bulk retrieval endpoints - an AISP may optionally retrieve the account information resources in bulk.
This will retrieve the resources for all authorised accounts linked to the account-request.
Beneficiaries
Endpoints for the resource - and available methods.
| Endpoints | ||||||||||
Resource | HTTP Operation | Endpoint | Mandatory? | Scope | Grant Type | Idempotency Key | Parameters | Request Object | Response Object | |
| 1 | beneficiaries | GET | GET /accounts/{AccountId}/beneficiaries | Conditional | accounts | Authorization Code | No | OBReadBeneficiary2 | ||
| 2 | beneficiaries | GET | GET /beneficiaries | Optional | accounts | Authorization Code | No | Pagination | OBReadBeneficiary2 | |
GET /accounts/{AccountId}/beneficiaries
An AISP may retrieve the account beneficiaries information resource for a specific AccountId (which is retrieved in the call to GET /accounts).
GET /beneficiaries
If an ASPSP has implemented the bulk retrieval endpoints for beneficiaries - an AISP may optionally retrieve the beneficiaries information in bulk.
This endpoint will retrieve the beneficiaries resources for all authorised accounts linked to a specific account-request.
Partys
Endpoints for the resource - and available methods.
| Endpoints | ||||||||||
Resource | HTTP Operation | Endpoint | Mandatory? | Scope | Grant Type | Idempotency Key | Parameters | Request Object | Response Object | |
| 1 | party | GET | GET /accounts/{AccountId}/party | Conditional | accounts | Authorization Code | No | OBReadParty1 | ||
| 2 | party | GET | GET /party | Conditional | accounts | Authorization Code | No | OBReadParty1 | ||
GET /accounts/{AccountId}/party
If the ASPSP has chosen to implement the /accounts/{AccountId}/party endpoint - the ASPSP must return details on the account owner:
- In the case of a business - this will be the details of the business
- In the case of a joint account - this will be the party that has given authorisation to the AISP to view the account. If the AISP wishes to access details of other parties linked to the AccountId, the AISP must go through an authorisation flow with the other parties.
GET /party
If the ASPSP has chosen to implement the the /party endpoint - the ASPSP must return details on the user that has authorised the account-request with the ASPSP:
- In the case of a business account - this will be the details of the party that has given authorisation to the AISP to view the account
- In the case of a joint account - this will be the party that has given authorisation to the AISP to view the account
Products
Endpoints for the resource - and available methods.
| Endpoints | ||||||||||
Resource | HTTP Operation | Endpoint | Mandatory? | Scope | Grant Type | Idempotency Key | Parameters | Request Object | Response Object | |
| 1 | products | GET | GET /accounts/{AccountId}/product | Conditional | accounts | Authorization Code | No | OBReadProduct2 | ||
| 2 | products | GET | GET /products | Optional | accounts | Authorization Code | No | Pagination | OBReadProduct2 | |
GET /accounts/{AccountId}/product
An AISP may retrieve the account product information for a specific AccountId (which is retrieved in the call to GET /accounts).
While this endpoint is marked as Conditional, it will be Mandatory for ASPSPs and account types covered in the CMA Order.
GET /products
If an ASPSP has implemented the bulk retrieval endpoints for products - an AISP may optionally retrieve the products information in bulk.
This endpoint will retrieve the products resources for all authorised accounts linked to a specific account-request.
Scheduled Payments
Endpoints for the resource - and available methods.
| Endpoints | ||||||||||
Resource | HTTP Operation | Endpoint | Mandatory? | Scope | Grant Type | Idempotency Key | Parameters | Request Object | Response Object | |
| 1 | scheduled-payments | GET | GET /accounts/{AccountId}/scheduled-payments | Conditional | accounts | Authorization Code | No |
| OBReadScheduledPayment1 | |
| 2 | scheduled-payments | GET | GET /scheduled-payments | Optional | accounts | Authorization Code | No | Pagination | OBReadScheduledPayment1 | |
GET /accounts/{AccountId}/scheduled-payments
An ASPSP may provide this endpoint for AISPs to retrieve the scheduled-payments for a specific AccountId (which is retrieved in the call to GET /accounts).
GET /scheduled-payments
If an ASPSP has implemented the bulk retrieval endpoints - an AISP may optionally retrieve the scheduled-payments resources in bulk.
This will retrieve the scheduled-payments resources for all authorised accounts linked to the account-request.
Standing Orders
Endpoints for the resource - and available methods.
| Endpoints | ||||||||||
Resource | HTTP Operation | Endpoint | Mandatory? | Scope | Grant Type | Idempotency Key | Parameters | Request Object | Response Object | |
| 1 | standing-orders | GET | GET /accounts/{AccountId}/standing-orders | Conditional | accounts | Authorization Code | No | OBReadStandingOrder3 | ||
| 2 | standing-orders | GET | GET /standing-orders | Optional | accounts | Authorization Code | No | Pagination | OBReadStandingOrder3 | |
GET /accounts/{AccountId}/standing-orders
An AISP may retrieve the standing-order resource for a specific AccountId (which is retrieved in the call to GET /accounts).
GET /standing-orders
If an ASPSP has implemented the bulk retrieval endpoints - an AISP may optionally retrieve the standing-order resources in bulk.
This will retrieve the resources for all authorised accounts linked to the account-request.
Statements
Endpoints for the resource - and available methods.
| Endpoints | ||||||||||
Resource | HTTP Operation | Endpoint | Mandatory? | Scope | Grant Type | Idempotency Key | Parameters | Request Object | Response Object | |
| 1 | statements | GET | GET /accounts/{AccountId}/statements | Conditional | accounts | Authorization Code | No | Pagination Filtering | OBReadStatement1 | |
| 2 | statements | GET | GET /accounts/{AccountId}/statements/{StatementId} | Conditional | accounts | Authorization Code | No | Pagination | OBReadStatement1 | |
| 3 | statements | GET | GET /accounts/{AccountId}/statements/{StatementId}/file | Optional | accounts | Authorization Code | No | File | ||
| 4 | transactions | GET | GET /accounts/{AccountId}/statements/{StatementId}/transactions | Conditional | accounts | Authorization Code | No | Pagination | OBReadTransaction3 | |
| 5 | statements | GET | GET /statements | Optional | accounts | Authorization Code | No | Pagination Filtering | OBReadStatement1 | |
GET /accounts/{AccountId}/statements
An ASPSP may provide this endpoint for AISPs to retrieve the statements information resource for the AccountId (which is retrieved in the call to GET /accounts).
GET /accounts/{AccountId}/statements/{StatementId}
An ASPSP may provide this endpoint for AISPs to retrieve the statement information resource for a specific statement in the AccountId (which is retrieved in the call to GET /accounts).
GET /accounts/{AccountId}/statements/{StatementId}/file
An ASPSP may provide this endpoint for AISPs to retrieve a non-json representation of a specific statement.
GET /accounts/{AccountId}/statements/{StatementId}/transactions
An ASPSP may provide this endpoint for AISPs to retrieve transactions that appear on the selected statement.
The data model for the returned objects is documented in the transactions resource.
GET /statements
An ASPSP may provide this endpoint for AISPs to retrieve statement information for all accounts that the PSU has consented to. This will retrieve the statement resources for all authorised accounts linked to the account-request.
Transactions
Endpoints for the resource - and available methods.
| Endpoints | ||||||||||
Resource | HTTP Operation | Endpoint | Mandatory? | Scope | Grant Type | Idempotency Key | Parameters | Request Object | Response Object | |
| 1 | transactions | GET | GET /accounts/{AccountId}/transactions | Mandatory | accounts | Authorization Code | No | Pagination Filtering | OBReadTransaction3 | |
| 2 | transactions | GET | GET /transactions | Optional | accounts | Authorization Code | No | Pagination Filtering | OBReadTransaction3 | |
GET /accounts/{AccountId}/transactions
An AISP may retrieve the transaction resource for a specific AccountId (which is retrieved in the call to GET /accounts).
GET /transactions
If an ASPSP has implemented the bulk retrieval endpoints - an AISP may optionally retrieve the transactions in bulk.
This will retrieve the resources for all authorised accounts linked to the account-request.
Generate Token
| Method Type | Method Name | Description |
| POST | generatetoken |
Authenticate
| Method Type | Method Name | Description |
| GET | authenticate |
Login
| Method Type | Method Name | Description |
| GET | loginpage | |
| POST | consent | |
| POST | authenticate |
Confirmation of Funds
Confirmation of funds
| Endpoints | |||||||||
Resource | HTTP Operation | Endpoint | Mandatory? | Scope | Grant Type | Message Signing | Idempotency Key | Request Object | Response Object |
| funds-confirmation-consent | POST | POST /funds-confirmation-consents | Mandatory | fundsconfirmations | Client Credentials | No | No | OBFundsConfirmationConsent1 | OBFundsConfirmationConsentResponse1 |
| funds-confirmation-consent | GET | GET /funds-confirmation-consents/{ConsentId} | Mandatory | fundsconfirmations | Client Credentials | No | No | NA | OBFundsConfirmationConsentResponse1 |
| funds-confirmation-consent | DELETE | DELETE /funds-confirmation-consents/{ConsentId} | Mandatory | fundsconfirmations | Client Credentials | No | No | NA | NA |
| funds-confirmation | POST | POST /funds-confirmations | Mandatory | fundsconfirmations | Authorization Code | No | No | OBFundsConfirmation1 | OBFundsConfirmationResponse1 |
POST /funds-confirmation-consents
1 | POST /funds-confirmation-consents |
The API allows the CBPII to ask an ASPSP to create a new funds-confirmation-consent resource.
- This endpoint allows the CBPII to propose a consent to be agreed between the ASPSP and PSU, to authorise the CBPII access to confirm funds are available.
- The ASPSP creates the funds-confirmation-consent resource and responds with a unique ConsentId to refer to the resource.
- Prior to calling the operation, the CBPII must have an access token issued by the ASPSP using a client credentials grant.
Status
The PSU must authenticate with the ASPSP and agree the funds-confirmation-consent with the ASPSP, for the funds-confirmation-consent to be successfully setup.
The funds-confirmation-consent resource that is created successfully must have one of the following Status code-list enumerations:
Status | Status Description | |
| 1 | AwaitingAuthorisation | The Funds Confirmation Consent is awaiting agreement. |
After consent has been agreed the funds-confirmation-consent resource may have these following statuses.
Status | Status Description | |
| 1 | Rejected | The Funds Confirmation Consent has been rejected. |
| 2 | Authorised | The Funds Confirmation Consent has been successfully agreed. |
| 3 | Revoked | The Funds Confirmation Consent has been revoked via the ASPSP interface. |
GET /funds-confirmation-consents/{ConsentId}
1 | GET /funds-confirmation-consents/{ConsentId} |
A CBPII may optionally retrieve an funds-confirmation-consent resource that they have created to check its status.
Prior to calling the operation, the CBPII must have an access token issued by the ASPSP using a client credentials grant.
Status
Once the PSU agrees the consent outlined in the funds-confirmation-consent resource - the Status of the funds-confirmation-consent resource will be updated with "Authorised".
The available Status code-list enumerations for the funds-confirmation-consent resource are:
Status | Status Description | |
| 1 | Rejected | The Funds Confirmation Consent has been rejected. |
| 2 | AwaitingAuthorisation | The Funds Confirmation Consent is awaiting agreement. |
| 3 | Authorised | The Funds Confirmation Consent has been successfully agreed. |
| 4 | Revoked | The Funds Confirmation Consent has been revoked via the ASPSP interface. |
DELETE /funds-confirmation-consents/{ConsentId}
1 | DELETE /funds-confirmation-consents/{ConsentId} |
If the PSU revokes consent to confirm funds with the CBPII - the CBPII must delete the funds-confirmation-consent resource.
- This is done by making a call to DELETE the funds-confirmation-consent resource.
- Prior to calling the operation, the CBPII must have an access token issued by the ASPSP using a client credentials grant.
POST /funds-confirmations
1 | POST /funds-confirmations |
If the CBPII would like to confirm funds with the ASPSP, it should create a new funds-confirmation resource, and check the funds available flag in the response.
- The ASPSP creates the funds-confirmation resource and responds with a unique FundsConfirmationId to refer to the resource, and a flag confirming if funds are available.
- The CBPII must use a token issued via authorization code grant and specify the ConsentId in the request payload.
- This CBPII must use a currency of the account.
Login
| Method Type | Method Name | Description |
| GET | loginpage | |
| POST | consent | |
| POST | authenticate |
Authenticate
| Method Type | Method Name | Description |
| GET | authenticate |
Generate Token
| Method Type | Method Name | Description |
| POST | generatetoken |