/
Domestic Scheduled Payment v3.0

Domestic Scheduled Payment v3.0

Sept 07, 2018

Version Control

Version

Date

Author

Comments

Version

Date

Author

Comments

3.0-draft1

18-Apr-2018

OB R/W API Team

First draft of v3

3.0-draft2

May 8, 2018 

OB R/W API Team

Changes to the Data Model section.

Reused classes for the payment setup request and response objects are documented once:

  • OBInitiation2

  • OBRisk1

Payloads for the payment setup request and response have been updated to reflect requirements for P5a and P10. 

Changes to the request payload for the payment setup object:

  • Permission requested (operation for v3.0 will be limited to "Create")

  • InstructedAmount changes from 1..1 to 0..1 (optional) - as a PISP may stage an EquivalentAmount (to setup an international payment)

  • RequestedExecutionDate - which is a 0..1 (optional) field - which indicates to the ASPSP the payment setup is for a future date

  • ExchangeRateInformation object - where a PISP may indicate requested exchange type and rates, which may have been pre-negotiated with the ASPSP. The ASPSP will reject the request if the requested rate cannot be fulfilled.

  • EquivalentAmount to indicate payment amount in a currency other than the currency of the DebtorAccount

  • CreditorAccount object modified to allow for international beneficiaries (aligned to the beneficiaries endpoint for v2.0)

Changes to the response payload for the payment setup object:

  • The same changes as the request payload

  • StatusUpdateDateTime (to align with v2.0)

  • ExpirationDateTime to indicate the cut-off times and validity of the payment setup (for the ASPSP)

  • Charge array which will be used by the ASPSP to indicate charges, and the ChargeBearer as relevant

  • ExchangeRateInformation (the ASPSP response) - this object will be used to communicate exchange rate information back to the PISP. It must be consistent with what is requested in the Initiation object from the PISP.

For internation payments - have removed reference to:

  • "and the Servicer identification section (either DebtorAgent or CreditorAgent) should be populated with the "BICFI" as the SchemeName" in the case of an IBAN.

3.0-draft3

May 18, 2018 

OB R/W API Team

Modified title from Scheduled Payments to Domestic Scheduled Payments (and merged Payments and Payment Submissions pages)

Draft3 changes:

  • Reverted OBInitiation2 to OBInitiation1 in v3-draft1 (as this endpoint now only relates to domestic scheduled payments) and renamed object to OBDomesticScheduled1 for Domestic Scheduled Payments

  • Added RequestedExecutionDate - which is a 1..1 (mandatory) field - which indicates to the ASPSP the payment setup is for a future date

  • Separated Scheduled Domestic Payments from /payments endpoint

    • /domestic-scheduled-payment-consents endpoint for /payments

    • /domestic-scheduled-payments endpoint for /payment-submissions

  • Updates to specification text to refer to new resource names

  • Updates to Status flow to clarify flow, and allowable values

  • Moved OBRisk1 class from this page to the main Payment Initiation API page

  • CreditorAgent and DebtorAgent have been removed - as these are not required for domestic single immediate payments. DebtorAgent is also identifiable by the ASPSP after the PSU authenticates, so is not required.

Changes to Initiation object:

  • Removed InstructionIdentification and EndToEndIdentification - as ASPSPs were concerned that their systems that warehouse scheduled payment could not store these identifiers, and pass them through to payment execution

  • Added NonWorkingDayAdjustment field from ISO 20022 for PISPs to specify if payment must be executed on Preceding or Following day if RequestedExecutionDateTime is on a non-working day

  • Changed RequestedExecutionDate to RequestedExecutionDateTime for consistency across all API endpoints

The Initiation object from the domestic-scheduled-payment-consent is now replayed in the response object for the domestic-scheduled-payment

Aligned GET operations Mandatory? flag with the equivalent resource POST.

3.0-draft4

May 30, 2018 

OB R/W API Team

Draft4 changes:

OBDomesticScheduled1 object:

  • Added optional LocalInstrument to identify the requested payment scheme

  • Added optional CreditorPostalAddress for CHAPS payments that require the address details for the Creditor

  • Re-added the InstructionIdentification (mandatory - as this is between ASPSP and TPP), and EndToEndIdentification (optional)

Added re-used class description for:

  • OBCharge1

For the domestic-scheduled-payment-consent response:

  • Added optional CutOffDateTime as some payment schemes have a cut-off time

  • Added optional Charges array as ASPSPs may require the ability to communicate fees and charges

For the domestic-scheduled-payment response:

  • Added optional Charges array as ASPSPs may require the ability to communicate fees and charges

Clarified use of Idempotency Key in endpoint table.

3.0-draft5

Jun 15, 2018 

OB R/W API Team

Draft5 changes:

  • Updated namespacing for LocalInstrument to align with pending decision in 144

  • SchemeName fields to be Max40Text - so Agent SchemeName values and Account SchemeName values will not be enforced via codelist (145)

  • DebtorAccount/Identification field extended to Max256Text to allow for email and other identification schemes

  • CreditorAccount/Identification field extended to Max256Text to allow for email and other identification schemes

  • Removed NonWorkingDayAdjustment field as per 143

  • Clarified that "All elements in the Initiation payload that are specified by the PISP must not be changed via the ASPSP."

  • Reworded section for clarity in POST /domestic-scheduled-payments to indicate "ASPSP may not warehouse the domestic scheduled payment immediately (e.g. busy periods at the ASPSP)"

  • Usage Examples and Alternate flows are moved back to the individual specification pages

  • Errata: removed reference of "International" from International Payment Initiation, in relation to OBCharge1 definition

3.0-draft6/rc1

Jun 27, 2018 

OB R/W API Team

Draft6 changes:

  • Updated the OBDomesticScheduled1 object guidance from "the ASPSP must Reject the Initiation request" to "the ASPSP must reject the domestic-scheduled-payment-consent"

  • Clarified the behavioural difference in when ASPSP rejects the payment-order consent request and when ASPSP sets the status of payment-order consent to Rejected

  • Added section for State Model / Payment Order / Multiple Authorisation

  • Updated definition of Name field in the CreditorAccount and DebtorAccount objects for clarity. Have specified usage that it is "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."

  • Added reused classes for:

    • OBAuthorisation1

    • OBMultiAuthorisation1

  • Updated Data Model section to reflect:

    • Authorisation object in the payment-order consent request and response

    • MultiAuthorisation object in the payment-order resource response

    • ExpectedExecutionDateTime and ExpectedSettlementDateTime in the payment-order consent response and payment-order resource response

  • Added Notes section to describe the content of the POST /domestic-scheduled-payment-consent

  • Updated "PersonToPerson" to "PartyToParty" in Usage Examples

  • Linked GET Mandatory? status to resource POST implementation

3.0-draft7

Jul 5, 2018 

OB R/W API Team

Draft7 Changes:

  • Changed the Grant Type for GET Requests to be Client Credentials Only.

  • Moved definitions of reused classes - OBCharge1, OBAuthorisation1 and OBMultiAuthorisation1 to Payment Initiation API Specification page

  • Added namespace-prefixed enumerations to examples

  • Additional guidance on the ExpectedExecutionDateTime and ExpectedSettlementDateTime

3.0-RC2

Jul 19, 2018 

OB R/W API Team

RC2 Changes:

  • Updated notes on CutOffDateTime to refer to Payment Initiation API Specification, Section - Payment Restrictions -> CutOffDateTime API Behaviour

3.0-RC3

Aug 6, 2018 

OB R/W API Team

No Change

3.0

Sep 7, 2018 

OB R/W API Team

This is the baseline version. No change from RC3.

Endpoints

Resource

HTTP Operation

Endpoint

Mandatory ?

Scope

Grant Type

Message Signing

Idempotency Key

Request Object

Response Object

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

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.

Status

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

Status

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

Status

AwaitingAuthorisation

Rejected

Authorised

Consumed

POST /domestic-scheduled-payments

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.

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

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

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

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

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

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

OBDomesticScheduled1

This section describes the OBDomesticScheduled1 class - which is reused as the Initiation object in the domestic-scheduled-payment-consent and domestic-scheduled-payment resources.

UML Diagram

Notes

For the OBDomesticScheduled1 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 "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 "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

Name

Occurrence

XPath

EnhancedDefinition

Class

Codes

Pattern

OBDomesticScheduled1

 

OBDomesticScheduled1

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.

OBDomesticScheduled1

© Open Banking Limited 2019 | https://www.openbanking.org.uk/open-licence | https://www.openbanking.org.uk