Domestic Scheduled Payment v3.1
- 1 Version Control
- 2 Endpoints
- 2.1 POST /domestic-scheduled-payment-consents
- 2.1.1 Status
- 2.2 GET /domestic-scheduled-payment-consents/{ConsentId}
- 2.2.1 Status
- 2.3 POST /domestic-scheduled-payments
- 2.3.1 Status
- 2.4 GET /domestic-scheduled-payments/{DomesticScheduledPaymentId}
- 2.4.1 Status
- 2.5 State Model
- 2.5.1 Payment Order Consent
- 2.5.2 Payment Order
- 2.5.2.1 Multiple Authorisation
- 2.1 POST /domestic-scheduled-payment-consents
- 3 Data Model
- 3.1 Reused Classes
- 3.1.1 OBDomesticScheduled2
- 3.1.1.1 UML Diagram
- 3.1.1.2 Notes
- 3.1.1.3 Data Dictionary
- 3.1.1 OBDomesticScheduled2
- 3.2 Domestic Scheduled Payment Consent - Request
- 3.2.1 UML Diagram
- 3.2.2 Notes
- 3.2.3 Data Dictionary
- 3.3 Domestic Scheduled Payment Consent - Response
- 3.3.1 UML Diagram
- 3.3.2 Notes
- 3.3.3 Data Dictionary
- 3.4 Domestic Scheduled Payment - Request
- 3.4.1 UML Diagram
- 3.4.2 Notes
- 3.4.3 Data Dictionary
- 3.5 Domestic Scheduled Payment - Response
- 3.5.1 UML Diagram
- 3.5.2 Notes
- 3.5.3 Data Dictionary
- 3.1 Reused Classes
- 4 Usage Examples
Version Control
Version | Date | Author | Comments |
|---|---|---|---|
3.0 | Sep 7, 2018 | OB R/W API Team | This is the baseline version. No change from RC3. |
3.1-draft1 | Sep 12, 2018 | OB R/W API Team | This is the initial draft version for 3.1. Draft 1 Changes
Errata
|
3.1-draft2 | Oct 5, 2018 | OB R/W API Team | Draft2 Changes:
|
3.1-draft3 | Oct 18, 2018 | OB R/W API Team | Draft3 Changes:
|
3.1-RC1 | Nov 8, 2018 | OB R/W API Team | RC1 Changes:
|
3.1 | Nov 30, 2018 | OB R/W API Team | Version 3.1 final release. No changes from Version 3.1 RC1. |
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 | OBWriteDomesticScheduledConsent2 | OBWriteDomesticScheduledConsentResponse2 |
domestic-scheduled-payment-consents | GET | GET /domestic-scheduled-payment-consents/{ConsentId} | Mandatory (if resource POST implemented) | payments | Client Credentials | Signed Response | No | NA | OBWriteDomesticScheduledConsentResponse2 |
domestic-scheduled-payments | POST | POST /domestic-scheduled-payments | Conditional | payments | Authorization Code | Signed Request Signed Response | Yes | OBWriteDomesticScheduled2 | OBWriteDomesticScheduledResponse2 |
domestic-scheduled-payments | GET | GET /domestic-scheduled-payments/{DomesticScheduledPaymentId} | Mandatory (if resource POST implemented) | payments | Client Credentials | Signed Response | No | NA | OBWriteDomesticScheduledResponse2 |
POST /domestic-scheduled-payment-consents
POST /domestic-scheduled-payment-consentsThe 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.
Status
The default Status is "AwaitingAuthorisation" immediately after the domestic-scheduled-payment-consent has been created.
Status |
|---|
AwaitingAuthorisation |
GET /domestic-scheduled-payment-consents/{ConsentId}
GET /domestic-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 domestic-scheduled-payment-consent has failed some other ASPSP validation, the Status will be set to "Rejected".
Once a domestic-scheduled-payment has been successfully created using the domestic-scheduled-payment-consent, the Status of the domestic-scheduled-payment-consent will be set to "Consumed".
The available Status codes for the domestic-scheduled-payment-consent resource are:
Status |
|---|
AwaitingAuthorisation |
Rejected |
Authorised |
Consumed |
POST /domestic-scheduled-payments
POST /domestic-scheduled-paymentsOnce 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.
Status
A domestic-scheduled-payment can only be created if its corresponding domestic-scheduled-payment-consent resource has the status of "Authorised".
The domestic-scheduled-payment resource that is created successfully must have one of the following Status codes:
Status |
|---|
InitiationPending |
InitiationFailed |
InitiationCompleted |
GET /domestic-scheduled-payments/{DomesticScheduledPaymentId}
GET /domestic-scheduled-payments/{DomesticScheduledPaymentId}A PISP can retrieve the domestic-scheduled-payment to check its status.
Status
The domestic-scheduled-payment resource must have one of the following Status codes:
Status |
|---|
InitiationPending |
InitiationFailed |
InitiationCompleted |
State Model
Payment Order Consent
The state model for the domestic-scheduled-payment-consent resource follows the generic consent state model. However, does not use the "Revoked" status, as the consent for a domestic-scheduled-payment is not a long-lived consent.
The definitions for the Status:
Status | Status Description | |
|---|---|---|
| 1 | AwaitingAuthorisation | The consent resource is awaiting PSU authorisation. |
| 2 | Rejected | The consent resource has been rejected. |
| 3 | Authorised | The consent resource has been successfully authorised. |
| 4 | Consumed | The consented action has been successfully completed. This does not reflect the status of the consented action. |
Payment Order
The state model for the domestic-scheduled-payment resource describes the initiation status only. I.e., not the subsequent execution of the domestic-scheduled-payment.
The definitions for the Status:
Status | Payment Status Description | |
|---|---|---|
| 1 | InitiationPending | The initiation of the payment order is pending. |
| 2 | InitiationFailed | The initiation of the payment order has failed. |
| 3 | InitiationCompleted | The initiation of the payment order is complete. |
Multiple Authorisation
If the payment-order requires multiple authorisations, the Status of the multiple authorisations will be updated in the MultiAuthorisation object.
The definitions for the Status:
Status | Status Description | |
|---|---|---|
| 1 | AwaitingFurtherAuthorisation | The payment-order resource is awaiting further authorisation. |
| 2 | Rejected | The payment-order resource has been rejected by an authoriser. |
| 3 | Authorised | The payment-order resource has been successfully authorised by all required authorisers. |
Data Model
The data dictionary section gives the detail on the payload content for the Domestic Scheduled Payment API flows.
Reused Classes
OBDomesticScheduled2
This section describes the OBDomesticScheduled2 class which is reused as the Initiation object in the domestic-scheduled-payment-consent and domestic-scheduled-payment resources.
UML Diagram
Notes
For the OBDomesticScheduled2 Initiation object:
All elements in the Initiation payload that are specified by the PISP must not be changed via the ASPSP, as this is part of formal consent from the PSU.
If the ASPSP is able to establish a problem with payload or any contextual error during the API call, the ASPSP must reject the domestic-scheduled-payment-consent consent request immediately.
If the ASPSP establishes a problem with the domestic-scheduled-payment-consent after the API call, the ASPSP must set the Status of the domestic-scheduled-payment-consent resource to Rejected.
DebtorAccount is optional as the PISP may not know the account identification details for the PSU.
If the DebtorAccount is specified by the PISP and is invalid for the PSU, then the domestic-scheduled-payment-consent will be set to Rejected after PSU authentication.
Account Identification field usage:
Where "UK.OBIE.SortCodeAccountNumber" is specified as the SchemeName in the Account identification section (either DebtorAccount or CreditorAccount), the Identification field must be populated with the 6 digit Sort Code and 8 digit Account Number (a 14 digit field).
Where the "UK.OBIE.IBAN" is specified as the SchemeName in the Account identification section (either DebtorAccount or CreditorAccount), the Identification field must be populated with the full IBAN.
Neither the InstructionIdentification nor EndToEndIdentification will be used as the domestic-payment-consent resource identifier (ConsentId) as the ConsentId must be uniquely generated by the ASPSP.
Permission field is restricted to "Create", however, may be extended to "Update" and "Delete" in a future iteration of the specification.
LocalInstrument is the requested payment scheme for execution. This is a free-text field.
RequestedExecutionDateTime allows a PISP to specify the date for an ASPSP to execute the domestic scheduled payment.
Data Dictionary
Name | Occurrence | XPath | EnhancedDefinition | Class | Codes | Pattern |
|---|---|---|---|---|---|---|
OBDomesticScheduled2 |
| OBDomesticScheduled2 | The Initiation payload is sent by the initiating party to the ASPSP. It is used to request movement of funds from the debtor account to a creditor for a single scheduled domestic payment. | OBDomesticScheduled2 |
|
|
InstructionIdentification | 1..1 | OBDomesticScheduled2/InstructionIdentification | Unique identification as assigned by an instructing party for an instructed party to unambiguously identify the instruction.
Usage: the instruction identification is a point to point reference that can be used between the instructing party and the instructed party to refer to the individual instruction. It can be included in several messages related to the instruction. | Max35Text |
|
|
EndToEndIdentification | 0..1 | OBDomesticScheduled2/EndToEndIdentification | Unique identification assigned by the initiating party to unambiguously identify the transaction. This identification is passed on, unchanged, throughout the entire end-to-end chain.
Usage: The end-to-end identification can be used for reconciliation or to link tasks relating to the transaction. It can be included in several messages related to the transaction. OB: The Faster Payments Scheme can only access 31 characters for the EndToEndIdentification field. | Max35Text |
|
|
LocalInstrument | 0..1 | OBDomesticScheduled2/LocalInstrument | User community specific instrument.
Usage: This element is used to specify a local instrument, local clearing option and/or further qualify the service or service level. | OBExternalLocalInstrument1Code |
|
|
RequestedExecutionDateTime | 1..1 | OBDomesticScheduled2/RequestedExecutionDateTime | Date at which the initiating party requests the clearing agent to process the payment. Usage: This is the date on which the debtor's account is to be debited. | ISODateTime |
|
|
InstructedAmount | 1..1 | OBDomesticScheduled2/InstructedAmount | Amount of money to be moved between the debtor and creditor, before deduction of charges, expressed in the currency as ordered by the initiating party.
Usage: This amount has to be transported unchanged through the transaction chain. | OBActiveOrHistoricCurrencyAndAmount |
|
|
Amount | 1..1 | OBDomesticScheduled2/InstructedAmount/Amount | A number of monetary units specified in an active currency where the unit of currency is explicit and compliant with ISO 4217. | OBActiveCurrencyAndAmount_SimpleType |
| ^\d{1,13}\.\d{1,5}$ |
Currency | 1..1 | OBDomesticScheduled2/InstructedAmount/Currency | A code allocated to a currency by a Maintenance Agency under an international identification scheme, as described in the latest edition of the international standard ISO 4217 "Codes for the representation of currencies and funds". | ActiveOrHistoricCurrencyCode |
| ^[A-Z]{3,3}$ |
DebtorAccount | 0..1 | OBDomesticScheduled2/DebtorAccount | Unambiguous identification of the account of the debtor to which a debit entry will be made as a result of the transaction. | OBCashAccountDebtor4 |
|
|
SchemeName | 1..1 | OBDomesticScheduled2/DebtorAccount/SchemeName | Name of the identification scheme, in a coded form as published in an external list. | OBExternalAccountIdentification4Code |
|
|
Identification | 1..1 | OBDomesticScheduled2/DebtorAccount/Identification | Identification assigned by an institution to identify an account. This identification is known by the account owner. | Max256Text |
|
|
Name | 0..1 | OBDomesticScheduled2/DebtorAccount/Name | Name of the account, as assigned by the account servicing institution.
Usage: The account name is the name or names of the account owner(s) represented at an account level. The account name is not the product name or the nickname of the account. | Max70Text |
|
|
SecondaryIdentification | 0..1 | OBDomesticScheduled2/DebtorAccount/SecondaryIdentification | This is secondary identification of the account, as assigned by the account servicing institution. This can be used by building societies to additionally identify accounts with a roll number (in addition to a sort code and account number combination). | Max34Text |