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 |
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.
|
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.
|
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.
|
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.
|
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 |
1 | POST /international-payment-consents |
The API endpoint allows the PISP to ask an ASPSP to create a new international-payment-consent resource.
The default Status is "AwaitingAuthorisation" immediately after the international-payment-consent has been created.
Status |
---|
AwaitingAuthorisation |
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 |
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:
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 |
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 |
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 |
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.
Status
The default Status is "AwaitingAuthorisation" immediately after the international-scheduled-payment-consent has been created.
Status |
---|
AwaitingAuthorisation |
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 |
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:
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 |
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 |
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 |
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.
Status
The default Status is "AwaitingAuthorisation" immediately after the international-standing-order-consent has been created.
Status |
---|
AwaitingAuthorisation |
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 |
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:
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 |
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 |
Method Type | Method Name | Description |
GET | authenticate |
Method Type | Method Name | Description |
GET | loginpage | |
POST | consent | |
POST | authenticate |
Method Type | Method Name | Description |
POST | generatetoken |
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 |
The API allows the AISP to ask an ASPSP to create a new account-access-consent resource.
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. |
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.
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. |
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.
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 |
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.
An AISP may retrieve the account information resources for the AccountId (which is retrieved in the call to GET /accounts).
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 |
An AISP may retrieve the account balance information resource for a specific AccountId (which is retrieved in the call to GET /accounts).
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.
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 |
An AISP may retrieve the account beneficiaries information resource for a specific AccountId (which is retrieved in the call to GET /accounts).
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.
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 |
If the ASPSP has chosen to implement the /accounts/{AccountId}/party endpoint - the ASPSP must return details on the account owner:
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:
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 |
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.
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.
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 |
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).
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.
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 |
An AISP may retrieve the standing-order resource for a specific AccountId (which is retrieved in the call to GET /accounts).
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.
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 |
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).
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).
An ASPSP may provide this endpoint for AISPs to retrieve a non-json representation of a specific statement.
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.
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.
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 |
An AISP may retrieve the transaction resource for a specific AccountId (which is retrieved in the call to GET /accounts).
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.
Method Type | Method Name | Description |
POST | generatetoken |
Method Type | Method Name | Description |
GET | authenticate |
Method Type | Method Name | Description |
GET | loginpage | |
POST | consent | |
POST | authenticate |
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 |
1 | POST /funds-confirmation-consents |
The API allows the CBPII to ask an ASPSP to create a new funds-confirmation-consent resource.
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. |
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. |
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.
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.
Method Type | Method Name | Description |
GET | loginpage | |
POST | consent | |
POST | authenticate |
Method Type | Method Name | Description |
GET | authenticate |
Method Type | Method Name | Description |
POST | generatetoken |