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.

The POST action indicates to the ASPSP that a domestic 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 domestic-payment-consent resource and responds with a uniqueConsentIdto refer to the resource.

AwaitingAuthorisation

The default Status is "AwaitingAuthorisation" immediately after the domestic-payment-consent has been created

GET /domestic-payment-consents/{ConsentId}

A PISP can optionally retrieve a payment consent resource that they have created to check its status.

The available Status codes for the domestic-payment-consent resource are:

AwaitingAuthorisation

Rejected

Authorised

Consumed

Once the PSUauthorisesthe payment-consent resource - the Status of the payment-consent resource will be updated with "Authorised".
If the PSU rejects the consent or the domestic-payment-consent has failed some other ASPSP validation, the Status will be set to "Rejected".
Once a domestic-payment has been successfully created using the domestic-payment-consent, the Status of the domestic-payment-consent will be set to "Consumed".

/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.

This is done by making a POST request to the domestic-payments endpoint.
This request is an instruction to the ASPSP to begin the domestic single immediate payment journey. The domestic payment must be submitted immediately, however, there are some scenarios where the domestic 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 domestic-payment match the corresponding Initiation and Risk sections of the domestic-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 domestic-payment resource will not result in a Status change for the domestic-payment resource.

The domestic-payment resource that is created successfully must have one of the following PaymentStatusCodecode-set enumerations:

Pending

Rejected

AcceptedSettlementInProcess

A domestic-payment can only be created if its corresponding domestic-payment-consent resource has the status code "Authorised".

GET /domestic-payments/{DomesticPaymentId}

A PISP can retrieve the domestic-payment to check its status.

The domestic-payment resource that is created successfully must have one of the following PaymentStatusCodecode-set enumerations:

Pending

Rejected

AcceptedSettlementInProcess

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.

The POST action indicates to the ASPSP that a domestic 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 domestic-scheduled-payment-consent resource and responds with a unique ConsentId to refer to the resource.

AwaitingAuthorisation

The default Status is "AwaitingAuthorisation" immediately after the domestic-payment-consent has been created

GET /domestic-scheduled-payment-consents/{ConsentId}

A PISP can optionally retrieve a payment consent resource that they have created to check its status.

The available Status codes for the domestic-scheduled-payment-consent resource are:

AwaitingAuthorisation

Rejected

Authorised

Consumed

Once the PSUauthorisesthe payment-consent resource - the Status of the payment-consent resource will be updated with "Authorised".
If the PSU rejects the consent or the domestic-payment-consent has failed some other ASPSP validation, the Status will be set to "Rejected".
Once a domestic-payment has been successfully created using the domestic-payment-consent, the Status of the domestic-payment-consent will be set to "Consumed".

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:

This is done by making a POST request to the domestic-scheduled-payments endpoint.
This request is an instruction to the ASPSP to begin the domestic scheduled payment journey. The PISP must submit the domestic scheduled payment immediately, however, there are some scenarios where the ASPSP may not warehouse the domestic scheduled payment immediately (e.g. busy periods at the ASPSP).
The PISP must ensure that the Initiation and Risk sections of the domestic-scheduled-payment match the corresponding Initiation and Risk sections of the domestic-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 domestic-scheduled-payment resource will not result in a Status change for the domestic-scheduled-payment resource.

The domestic-scheduled-payment resource that is created successfully must have one of the following Status codes:

InitiationPending

InitiationFailed

InitiationCompleted

A domestic-scheduled-payment can only be created if its corresponding domestic-scheduled-payment-consent resource has the status of "Authorised".

GET /domestic-scheduled-payments/{DomesticScheduledPaymentId}

A PISP can retrieve the domestic-scheduled-payment to check its status.

The domestic-scheduled-payment resource must have one of the following Status codes:

InitiationPending

InitiationFailed

InitiationCompleted

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.

The POST action indicates to the ASPSP that a domestic 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 domestic-standing-order-consent resource and responds with a uniqueConsentIdto refer to the resource.

AwaitingAuthorisation

The default Status is "AwaitingAuthorisation" immediately after the domestic-payment-consent has been created

GET /domestic-standing-order-consents/{ConsentId}

A PISP can optionally retrieve a payment consent resource that they have created to check its status. .

The available Status codes for the domestic-scheduled-payment-consent resource are:

AwaitingAuthorisation

Rejected

Authorised

Consumed

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 domestic-standing-order-consent has failed some other ASPSP validation, the Status will be set to "Rejected".
Once a domestic-standing-order has been successfully created using the domestic-standing-order-consent, the Status of the domestic-standing-order-consent will be set to "Consumed".

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:

This is done by making a POST request to the domestic-standing-orders endpoint.
This request is an instruction to the ASPSP to begin the domestic standing order journey. The PISP must submit the domestic standing order immediately, however, there are some scenarios where the ASPSP may not warehouse the domestic standing order immediately (e.g. busy periods at the ASPSP).
The PISP must ensure that the Initiation and Risk sections of the domestic-standing-order match the corresponding Initiation and Risk sections of the domestic-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 domestic-standing-order resource will not result in a Status change for the domestic-standing-order resource..

The domestic-standing-order resource that is created successfully must have one of the following Status codes:

InitiationPending

InitiationFailed

InitiationCompleted

A domestic-standing-order can only be created if its corresponding domestic-standing-order-consent resource has the status of "Authorised".

GET /domestic-standing-orders/{DomesticStandingOrderId}

A PISP can retrieve the domestic-standing-order to check its status.

The domestic-standing-order resource must have one of the following Status codes:

InitiationPending

InitiationFailed

InitiationCompleted

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.

The POST action indicates to the ASPSP that a file 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(s) that should be debited.
The endpoint allows the PISP to send metadata of the consent (between PSU and PISP) to the ASPSP.
The metadata of the consent must include the FileType of the request.
The metadata of the consent must include the FileHash, which is a base64 encoding of a SHA256 hash of the file to be uploaded
The ASPSP creates the file-payment-consent resource and responds with a unique ConsentId to refer to the resource.

The domestic-standing-order resource that is created successfully must have one of the following Status codes:

AwaitingUpload

The default Status is "AwaitingUpload" immediately after the file-payment-consent has been created.

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.

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 PISP must upload the file against the ConsentId before redirecting the PSU to authorise the consent.
The file structure must match the FileType in the file-payment-consent request.
An ASPSP must confirm the hash of the file matches with the FileHash provided in the file-payment-consent Metadata
The metadata for the file-payment-consent must match the contents of the uploaded file.
- If the content of the metadata does not match the content of the file, the ASPSP must reject the file-payment-consent.
The file is sent in the HTTP request body.
HTTP headers (e.g. Content-Type) are used to describe the file.

AwaitingAuthorisation

The default Status is "AwaitingAuthorisation" immediately after the file has been uploaded.

GET /file-payment-consents/{ConsentId}

A PISP can optionally retrieve a payment consent resource that they have created to check its status.

The available Status codes for the file-payment-consent resource are:

AwaitingUpload

AwaitingAuthorisation

Rejected

Authorised

Consumed

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 file-payment-consent has failed some other ASPSP validation, the Status will be set to "Rejected".
Once a file-payment has been successfully created using the file-payment-consent, the Status of the file-payment-consent will be set to "Consumed".

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.

The file is sent in the HTTP response body.
HTTP headers (e.g. Content-Type) are used to describe the file.

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:

This is done by making a POST request to the file-payments endpoint.
This request is an instruction to the ASPSP to begin the file payment journey. The PISP must submit the file payment immediately, however, there are some scenarios where the ASPSP may not stage the file payment immediately (e.g. busy periods at the ASPSP).
The PISP must ensure that the Initiation section of the file-payment match the corresponding Initiation section of the file-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 file-payment resource will not result in a Status change for the file-payment resource.

The file-payments resource that is created successfully must have one of the following Status codes::

InitiationPending

InitiationFailed

InitiationCompleted

GET /file-payments/{FilePaymentId}

A PISP can retrieve the file-payment to check its status.

The file-payments resource must have one of the following Status codes:

InitiationPending

InitiationFailed

InitiationCompleted

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:

This is done by making a POST request to the file-payments endpoint.
This request is an instruction to the ASPSP to begin the file payment journey. The PISP must submit the file payment immediately, however, there are some scenarios where the ASPSP may not stage the file payment immediately (e.g. busy periods at the ASPSP).
The PISP must ensure that the Initiation section of the file-payment match the corresponding Initiation section of the file-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 file-payment resource will not result in a Status change for the file-payment resource.

The file-payments resource that is created successfully must have one of the following Status codes::

InitiationPending

InitiationFailed

InitiationCompleted

GET /file-payments/{FilePaymentId}

A PISP can retrieve the file-payment to check its status.

The file-payments resource must have one of the following Status codes:

InitiationPending

InitiationFailed

InitiationCompleted

GET /file-payments/{FilePaymentId}/report-file

A PISP can retrieve the file-payment to check its status.

The API endpoint allows the PISP to download a payment report file from an ASPSP.

This endpoint enables ASPSP to return a report on the processing results of Payments in the file
The file is sent in the HTTP response body.
The file structure may match a payment execution report for the corresponding FileType in the file-payment-consent request.
HTTP headers (e.g. Content-Type) are used to describe the file.

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