/
Domestic Standing Orders v3.1.1

Domestic Standing Orders v3.1.1

Mar 14, 2019

Version Control

Version

Date

Author

Comments

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

  • Domestic Standing Order Initiation resource updated to include an optional object SupplementaryData, as per Decision 168

  • Type of DomesticStandingOrderId changed to Max40Text from Max128Text to align with other Payment Order Ids

Errata

  • Grammatical Fixes

3.1-draft2

Oct 5, 2018 

OB R/W API Team

Draft2 Changes:

  • Updated example URLs to version 3.1.

3.1-draft3

Oct 11, 2018 

OB R/W API Team

Errata

  • Added x-idempotency-key to usage examples.

Draft3 Changes:

  • Data Model updated with a typed field for Account/SchemeName and Agent/SchemeName fields to reference in Namespaced Enumerations page.

3.1 RC1

Nov 14, 2018 

OB R/W API Team

RC1 Changes:

  • Updated enumerations to use full UK.OBIE namespace.

  • References of OBCharge1 replaced with OBCharge2 class

3.1

Nov 30, 2018

OB R/W API Team

Version 3.1 final release.

No changes from Version 3.1 RC1.

v3.1.1 Draft-1

Jan 31, 2019 

OB R/W API Team

V3.1.1 Draft1 Changes:

  • Corrected frequencies in the Frequency Examples

  • Added frequency pattern (IntrvlDay) for a fixed interval of a specified number of days (CR-183)

v3.1.1 RC1

Feb 18, 2019 

OB R/W API Team

v3.1.1 RC1 changes:

  •  Corrected request and response consent payloads

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-standing-order-consents

POST

POST /domestic-standing-order-consents

Conditional

payments

Client Credentials

Signed Request

Signed Response

Yes

OBWriteDomesticStandingOrderConsent3

OBWriteDomesticStandingOrderConsentResponse3

domestic-standing-order-consents

GET

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

Mandatory (if resource POST implemented)

payments

Client Credentials

Signed Response

No

NA

OBWriteDomesticStandingOrderConsentResponse3

domestic-standing-orders

POST

POST /domestic-standing-orders

Conditional

payments

Authorization Code

Signed Request

Signed Response

Yes

OBWriteDomesticStandingOrder3

OBWriteDomesticStandingOrderResponse3

domestic-standing-orders

GET

GET /domestic-standing-orders/{DomesticStandingOrderId}

Mandatory (if resource POST implemented)

payments

Client Credentials

Signed Response

No

NA

OBWriteDomesticStandingOrderResponse3

POST /domestic-standing-order-consents

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 unique ConsentId to refer to the resource.

Status

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

Status

Status

AwaitingAuthorisation

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

GET /domestic-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 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".

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

Status

Status

AwaitingAuthorisation

Rejected

Authorised

Consumed

POST /domestic-standing-orders

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.

Status

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

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

Status

Status

InitiationPending

InitiationFailed

InitiationCompleted 

GET /domestic-standing-orders/{DomesticStandingOrderId}

GET /domestic-standing-orders/{DomesticStandingOrderId}

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

Status

The domestic-standing-order 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-standing-order-consent resource follows the generic consent state model. However, does not use the "Revoked" status, as the consent for a domestic-standing-order 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-standing-order resource describes the initiation status only. I.e., not the subsequent execution of the domestic-standing-order.

 

 

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 Standing Order API flows.

Reused Classes

OBDomesticStandingOrder3

This section describes the OBDomesticStandingOrder3 class, which is reused as the Initiation object in the domestic-standing-order-consent and domestic-standing-order resources.

UML Diagram

 

Notes

For the OBDomesticStandingOrder3 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-standing-order-consent request immediately.

  • If the ASPSP establishes a problem with the domestic-standing-order-consent after the API call, the ASPSP can set the Status of the domestic-standing-order-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-standing-order-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.

  • The Permission field is restricted to "Create", however, may be extended to "Update" and "Delete" in a future iteration of the specification.

  • Either the NumberOfPayments or FinalPaymentDateTime must be specified (not both) if the domestic standing order is not open ended.

  • The structure allows a PISP to specify a domestic standing order with a different payment amount and date combinations: for the first payment, the recurring payment, and the final payment. The recurring payment (and date) must only be populated if different from the first payment (and date).

  • If the PISP requests a Frequency that is not supported by the ASPSP the ASPSP must respond with a 400 HTTP status code.

Frequency Examples

Frequency

Example

Details

Frequency

Example

Details

EvryDay

EvryDay

Every day.

EvryWorkgDay

EvryWorkgDay

Every working day.

IntrvlDay

IntrvlDay:15

Every 15 Calendar day.

IntrvlWkDay

IntrvlWkDay:01:03

Every week, on the 3rd day of the week.

IntrvlWkDay

IntrvlWkDay:02:03

Every 2nd week, on the 3rd day of the week.

WkInMnthDay

WkInMnthDay:02:03

Every month, on the 2nd week of the month, and on the third day of the week.

IntrvlMnthDay

IntrvlMnthDay:01:-01

Every month, on the last day of the month.

IntrvlMnthDay

IntrvlMnthDay:06:15

Every 6th month, on the 15th day of the month.

QtrDay

QtrDay:ENGLISH

Paid on the 25th March, 24th June, 29th September and 25th December.

Data Dictionary

Name

Occurrence

XPath

EnhancedDefinition

Class

Codes

Pattern

Name

Occurrence

XPath

EnhancedDefinition

Class

Codes

Pattern

OBDomesticStandingOrder3

 

OBDomesticStandingOrder3

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 domestic standing order.

OBDomesticStandingOrder3

 

 

Frequency

1..1

OBDomesticStandingOrder3/Frequency

Individual Definitions:

EvryDay - Every day

EvryWorkgDay - Every working day

IntrvlDay - An interval specified in number of calendar days (02 to 31)

IntrvlWkDay - An interval specified in weeks (01 to 09), and the day within the week (01 to 07)

WkInMnthDay - A monthly interval, specifying the week of the month (01 to 05) and day within the week (01 to 07)

IntrvlMnthDay - An interval specified in months (between 01 to 06, 12, 24), specifying the day within the month (-05 to -01, 1 to 31)

QtrDay - Quarterly (either ENGLISH, SCOTTISH, or RECEIVED).

ENGLISH = Paid on the 25th March, 24th June, 29th September and 25th December.

SCOTTISH = Paid on the 2nd February, 15th May, 1st August and 11th November.

RECEIVED = Paid on the 20th March, 19th June, 24th September and 20th December.

 

Individual Patterns:

EvryDay (ScheduleCode)

EvryWorkgDay (ScheduleCode)

IntrvlDay:NoOfDay (ScheduleCode + NoOfDay)

IntrvlWkDay:IntervalInWeeks:DayInWeek (ScheduleCode + IntervalInWeeks + DayInWeek)

WkInMnthDay:WeekInMonth:DayInWeek (ScheduleCode + WeekInMonth + DayInWeek)

IntrvlMnthDay:IntervalInMonths:DayInMonth (ScheduleCode + IntervalInMonths + DayInMonth)

QtrDay: + either (ENGLISH, SCOTTISH or RECEIVED) ScheduleCode + QuarterDay

 

The regular expression for this element combines five smaller versions for each permitted pattern. To aid legibility - the components are presented individually here:

EvryDay

EvryWorkgDay

IntrvlDay:((0[2-9])|([1-2][0-9])|3[0-1])

IntrvlWkDay:0[1-9]:0[1-7]

WkInMnthDay:0[1-5]:0[1-7]

IntrvlMnthDay:(0[1-6]|12|24):(-0[1-5]|0[1-9]|[12][0-9]|3[01])

QtrDay:(ENGLISH|SCOTTISH|RECEIVED)

 

Full Regular Expression:

^(EvryDay)$|^(EvryWorkgDay)$|^(IntrvlDay:((0[2-9])|([1-2][0-9])|3[0-1]))$|^(IntrvlWkDay:0[1-9]:0[1-7])$|^(WkInMnthDay:0[1-5]:0[1-7])$|^(IntrvlMnthDay:(0[1-6]|12|24):(-0[1-5]|0[1-9]|[12][0-9]|3[01]))$|^(QtrDay:(ENGLISH|SCOTTISH|RECEIVED))$

Max35Text

 

^(EvryDay)$|^(EvryWorkgDay)$|^(IntrvlDay:((0[2-9])|([1-2][0-9])|3[0-1]))$|^(IntrvlWkDay:0[1-9]:0[1-7])$|^(WkInMnthDay:0[1-5]:0[1-7])$|^(IntrvlMnthDay:(0[1-6]|12|24):(-0[1-5]|0[1-9]|[12][0-9]|3[01]))$|^(QtrDay:(ENGLISH|SCOTTISH|RECEIVED))$

Reference

0..1

OBDomesticStandingOrder3/Reference

Unique reference, as assigned by the creditor, to unambiguously refer to the payment transaction.

 

Usage: If available, the initiating party should provide this reference in the structured remittance information, to enable reconciliation by the creditor upon receipt of the amount of money.

 

If the business context requires the use of a creditor reference or a payment remit identification, and only one identifier can be passed through the end-to-end chain, the creditor's reference or payment remittance identification should be quoted in the end-to-end transaction identification.

Max35Text

 

 

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