Proposition P11 - BACS, CHAPS, Bulk and Batch payments

1. Version control

Version

Date

Authors

Comments

V0.1

 

OBIE API Delivery Team

Draft for information only

V0.2

 

OBIE API Delivery Team

For industry consultation & feedback including RLWG, PMG, PAG, SWFG, DWG

V0.3

 

OBIE API Delivery Team

Update based on consultation feedback for approval at IESG. See change log for details of all changes.

V1.0

 

OBIE API Delivery Team

Final version for approval at IESG

V1.1 OBIE API Delivery TeamUpdate MoSCoW, Rationale and add Implementation for Detailed Product Requirements based on Categorisation of requirements for standards and implementation

2. Roadmap item definition

The Open Banking API's v1.1 covered single immediate payments (Write functionality) where a PSU can initiate, through a PISP, a one off payment to be initiated immediately from their PCA/BCA account held with an ASPSP.

From a regulatory compliance perspective the Open Banking PIS functionality of the Write APIs needs to be extended to enable PISPs to initiate domestic and international payments other than faster payments from online payment accounts, provided and to the extent, that this functionality is available to the PSU, on their ASPSPs' online payment account, in alignment with the requirements of PSD2.

The additional payments to be covered by the new PIS functionality include:

  • Bacs payments
  • CHAPS payments
  • Bulk payments
  • Batch payments

Note: For detailed list of payment types in scope, please refer to section 2.1 below. 

This paper defines the overall proposition to support this extended API functionality, so that participants (ASPSPs and TPPs) and stakeholders (FCA, HMT, CMA) have a common understanding about what is and is not in scope, and how this proposition will support regulatory requirements and key use cases.

For the actual roadmap item definition, please refer to section 10.3 of the Appendix.

2.1 Scope Definition

Evaluation of roadmap item P11 resulted in the following scope being identified:

Notes:

  1. Where BACS payments are currently offered as a PSU choice as part of a CMA9 proposition.
  2. There is provision for this in OB Release 1 specs however testing is required in order to ensure OB fully supports this.
  3. CHAPS cannot support single debit with multiple credits payments.
  4. This includes both templates of multiple payments created in the online platforms and files of payments uploaded to online banking.
  5. Same day and non-same date refer to the payment settlement from the point of execution by the ASPSP.

  6. PISPs will not treat intra-bank payments any differently to inter-bank payments

For the definitions of Direct Submission, Host to Host, Bulk and Batch payments, please refer to section 10.4 of the Appendix. For the reasons why Direct Submission and Host-2-Host channels have been placed out of scope, please refer to section 5.1.

3. Market analysis

3.1 Market size and BAU models

a) Bacs Direct Credits: Bacs Direct Credits are a popular and cost-effective method for businesses and Government to make bulk payments, where the value and timing of the payment are known in advance. As a result Bacs Direct Credits overwhelmingly remained the most common method for businesses and organisations to make payments during 2017. Over nine in ten employees are paid by Bacs Direct Credit. The Government also uses this service to pay
nearly all recipients of state benefits and pensions (Payments UK, UK Payment Markets Summary 2017).

Primary analysis of monthly data statistics from Payments UK show that Bacs Direct Credits volumes continue to decline. While bacs credit volumes still remain significant (i.e. 2.1 billion transactions in 2017) the volume are declining at a rate of -1.2% CAGR in 2017. Bacs Credit values continued growth at 3% reaching £3.6bn at the end of 2017 (Payments UK, Annual Summary of Payment Statistics 2017). In the first quarter of 2018, Bacs Credits volumes continue to decline at -1.3% GAGR while values continue to grow at 2% (Payments UK, Monthly Payment Statistics Mar 2018).

Despite the decline in volumes, it could still be several years until these volumes become less significant for the UK industry. Over the next decade, Bacs Direct Credit is expected to remain the most popular method for businesses to make payments. However, the total volume of payments are not expected to grow significantly. This is because, even though government forecasts suggest steady economic growth, the roll-out of Universal Credit will reduce the total volume of benefit payments made by the government. As a result, just over 2.2 billion Bacs Direct Credit payments are forecast in 2026 (Payments UK, UK Payment Markets Summary 2017).

b) CHAPS payments: CHAPS is used primarily by financial institutions to make wholesale financial payments and by large corporates to make corporate treasury payments. As a result, in 2016 CHAPS accounted for just 0.1% of the total volume of payments in the UK but 90% of the total value of payments. There were 39 million CHAPS payments processed in 2016, worth a total of £75.6 trillion (Payments UK, UK Payment Markets Summary 2017). 

Primary analysis of monthly data statistics from Payments UK show that CHAPS has established a steady growth rate after 2012. In 2017 growth rate was 6.9% while CHAPS volumes reached 41.6m. Growth has been split equally between retail & commercial payments and wholesale Financial transactions (Payments UK, Annual Summary of Payment Statistics 2017). Structural reform caused high increase in volumes from Q4 2017 onwards. This is the ring-fencing of the largest banks, to protect the retail services  from wholesale and risk taking activities elsewhere in their banking group. Some of the volume increase  is expected to be temporary and fall away later in 2018, and some to be permanent. (Bank of England website). In the first quarter of 2018, CHAPS volumes continue to grow at 10% GAGR while values also grow at 10% CAGR (Payments UK, Monthly Payment Statistics Mar 2018).

CHAPS payment volumes are closely related to the state of the UK economy. As such the economic outcome of Brexit and how it affects cross-border trade and investment will likely have an effect on future CHAPS payment volumes. There are forecast to be 43.5 million CHAPS payments in 2026 (Payments UK, UK Payment Markets Summary 2017). The expected increase of the Faster Payment transaction limit to £20m, will be cause large volumes of CHAPS from the Retail and Commercial sector to be migrating to Faster Payments. In the long run, the strategic view for CHAPS is to be used mainly for wholesale financial and settlement payments.

c) Bulk and Batch payments: UK ASPSPs provide a number of different channels for the various customer segments. Each channel provides different options of single payments, bulk and batch payments and other capabilities such as multi-authorisation accounts, future dated payments and payment status reporting. The below table summarises the various CMA9 ASPSPs' capabilities by customer segment and channel, illustrating the high degree of variability of the product offerings. The table has been anonymised and includes information submitted to OBIE by some of the CMA9 ASPSPs. However, some further validation may still be required.

What is offered to PSUs by some ASPSPs as a BAU process today, is the ability to use their online banking platform to select a file of bulk or batch payments and upload this file to the banking platform for processing. The bulk/batch file of payments can be of various format types based on various parameters such as the type of file output that can be produced by the PSU's systems and also the file formats that can be supported by the ASPSPs. In addition, PSUs are also able to use the banking platforms to submit bulk/batch payments for processing using templates of payments being stored in the online banking platforms. Also as a BAU process, ASPSPs will validate the structure of the file, and then will check and validate each payment included in the content of the file. Payments with invalid details (e.g. invalid sort code/account number) may cause the whole bulk/batch to fail or may be extracted from the file for processing. All the validated payments will then be processed by the ASPSP payment processing systems. As a BAU, some ASPSPs provide to their PSUs through their online platforms, a PSR (Payment Status Report) which details the processing status of the payments included in the bulk/batch.

3.2 PSU Research and Prototype Journeys

OBIE performed PSU research through an external company called Engine. Four prototype customer journeys have been produced and have been used for qualitative PSU research. Testing was performed using an Online Review Platform with over 30 SMEs. The key points of the PSU research are highlighted below:

  • The respondents’ experience of preparing payments in third party packages meant that Open Banking SME journeys appeared more familiar to users than those designed for personal customers
  • There was an expectation that the TPP proposition would provide a range of options for preparing the payments with most, or all, of the preparation being done in the TPP domain
  • The ability to understand the status (i.e. has it been authorised as opposed to has it been executed) of a bulk/batch payment is a key PSU requirement
  • Reporting and resolution of payment failure is also a key requirement
  • Authorisation in the ASPSP domain was not cited as an issue by PSUs.

For the details of the customer journey prototypes, please refer to section 10.6 of the Appendix. The details of the preliminary customer research findings can be found in section 10.8 of the Appendix.

4. Customer use cases

OBIE is conducting both primary customer research and secondary market research to identify the existing market offerings and requirements around Bacs, Chaps, bulk and batch payments. In addition, a series of market engagement workshops are being conducted to validate the requirements, especially from the TPP perspective. The following table provides example of some of the most characteristic use cases.  Understanding these allows OBIE to identify the key requirements needed to deliver these use cases. For the detailed list of use cases, please refer to section 10.7 of the Appendix.

ID

Use CaseMet
UC3 - Single domestic payment with payment scheme selected by PSU at TPP

As a Business Customer,

I want to use my accounting software to initiate a single payment and select the payment scheme (i.e. FPS, CHAPS, BACS) that I want my payment to be executed by my ASPSP, so that I have the flexibility to select what meets by business needs best. 

Fully
UC5 - Bulk domestic payments with debit account and/or payment scheme chosen by PSU at TPP

As a Business Customer,

I want to select the payment scheme (i.e. FPS, CHAPS, BACS) and/or the account to be debited directly from my accounting software and submit bulk payments to my ASPSP, so I can make the choices that meet my business needs.

Note: Certain ASPSPs may apply limits to the number of bulk payments allowed per channel.

Prototype: https://invis.io/FJHEH97DZPG

Fully

UC10 - Batch domestic payments with multiple debit accounts and/or multiple payment schemes chosen by PSU at TPP

As a Business Customer,

I want to make multi invoice payments (batch) to multiple beneficiaries by selecting the account to be debited and/or the payment scheme (i.e. FPS, CHAPS, BACS) for each bulk of payments in the batch, and make a single submission directly from my accounting software to my ASPSP, so that I don't have to submit each group of payments separately and choose these parameters at the ASPSP.

Prototype: https://invis.io/CSHK2KKXJKG

Fully
UC15 - Batch payments mixing domestic and international payments 

As a Business Customer,

I want to initiate through my PISP batches containing both domestic and international payments, so that I don't have to submit each group of payments separately.

Fully
UC17 - Status of bulk/batch payments processing

As a Business Customer,

I want to receive the information through my accountancy platform of which payments included in the batch/bulk submission have been accepted for processing, which ones have been executed by my ASPSP (i.e. account debited) and which ones have failed including the reason code of the failure.

Partially

UC18 - Bulk/Batch payments using legacy or proprietary payment formats

As a Business Customer,

I want my accountancy platform to allow me to submit (upload) bulk/batch payments in existing legacy/proprietary file formats to my ASPSP, so that I can use my existing old/legacy platforms with the payment initiation services offered by TPPs using Open Banking APIs.

Fully
UC20 - Bulk/Batch payments using simplified payment messages

As a PISP SME,

I want to be able to use a simplified payment message format to submit my business customers' bulk/batch payments, with their consent, to their ASPSPs, so that I can keep the interface simple and easy to implement. 

Fully

5. Regulatory references

The scope of roadmap item P11 should create the functionality to enable a PISP, with the PSU's consent, to request for an ASPSP to execute bulk/batch payment orders, if and to the extent, this functionality is available to the PSU on their online payment account.

5.1 Dynamic linking (RTS Article 5.3(b))

...in relation to payment transactions for which the payer has given consent to execute a batch of remote electronic payment transactions to one or several payees, the authentication code shall be specific to the total amount of the batch of payment transactions and to the specified payees.

5.2 Other regulatory considerations

Reasons for Direct Submission and Host-2-Host being out of scope:

  • Direct submission and H2H solutions are out of scope because they aren't offered directly by an ASPSP but via a third party.
  • Direct submission and H2H not an integral part of ASPSPs online/mobile services.
  • Established and effective 3rd party market for Direct Submission – e.g. c.100 Bacstel approved software providers and c.700 Bacstel bureaux.
  • H2Host channels are primarily designed for unattended processing (e.g. end2end automation using server to server connection with no or limited human interaction).
  • Both services support functionality beyond the scope of PSD2 (e.g. A-Services for BACS and unlimited for H2H).
  • The bespoke nature of H2H makes standardisation impractical.  Rationale behind H2H is that the corporates do not have to convert their own file formats to what an ASPSP requires.
  • The requirements of strong customer authentication apply to payments made by both consumers and legal entities. The RTS, Article 17 exemption permits ASPSPs not to apply SCA, when a corporate payment is initiated by a legal person (who is not a consumer) through dedicated processes or protocols which guarantee the high levels of payment security. This could include  direct submission and Host-2-Host, provided that the FCA is satisfied with the level of security and the ASPSP chooses to use the exemption.
  • The Corporate opt-out (PSD2 Article 38) means ASPSPs may make a differing level of information available over Host-2-Host.

6. Evaluation criteria

Key evaluation criteria that OBIE have applied for this proposition (that respect the objectives of meeting regulatory requirements as well as being effective and proportionate)

  • Does the proposition meet the use cases from a PSU and a TPP perspective (from both an outcome and risk point of view)?
  • Is the proposition implementable at reasonable cost?
  • Does the proposition comply with all relevant regulations?

7. Product requirements

OBIE understands that the P11 payments proposition may need to support the following functionality:

  • Ability for PISP to initiate single Bacs payments with the consent of the PSU; ASPSP to execute these payment orders.
  • Ability for PISP to initiate single CHAPS payments with the consent of the PSU; ASPSP to execute these payment orders.
  • Ability for PISP to initiate bulk payments with the consent of the PSU; ASPSP to execute these payment orders.
  • Ability for PISP to initiate batch payments with the consent of the PSU; ASPSP to execute these payment orders.
  • Ability to support all domestic and international payment types offered by the ASPSPs online platforms to consumer and business customers.
  • Ability for business PSU to have the option to select the payment scheme or priority to be used for the execution of the payments (single or bulk/batch) by the ASPSP.
  • Ability for PSU to be informed through their ASPSP if any payments of batch/bulk have failed to be validated and executed by the ASPSP.
  • Ability for PSU to initiate bulk/batch payments via a PISP using OBIE's standardised payment message format (both in full and simplified version).
  • Ability for PSU to initiate bulk/batch payments via a PISP using (uploading) existing proprietary/legacy payment file formats through 'format and interface agnostic' OBIE APIs.

8. Considerations

8.1 Constraints

  • The OBIE Consent model principles should apply in the solution of roadmap item P11 to allow the PSU to provide their consent to the PISP to initiate all payment types in the scope of P11. 

8.2 Dependencies

In Discovery / Specification:

  • P10 - Roadmap item P11 has strong dependency on roadmap item P10 in relation to the execution of all payment types of batch/bulk international payments (e.g. SEPA bulk payments). The format of these batch/bulk payments will be covered during the discovery of item P11 so the current scope of P10 is for single payments only and will feed in information of payment format to P11 to enable batch/bulk payments.
  • P20 - Roadmap item P11 will support bulk/batch payments from all PSD2 in scope accounts (sterling) for PIS as defined in roadmap item P20.
  • P21 - Roadmap item P11 will support bulk/batch payments from multi-currency accounts as defined in roadmap item P21. 
  • P5a – Roadmap item P11 future dated bulk/batch payments will be handled in alignment with the proposition defined in item P5a. 
  • P13 – Roadmap item P11 will support bulk/batch payments from multi authorisation accounts as defined in roadmap item P13.
  • P8 – Trusted beneficiaries exemptions under SCA. This will define how to handle P11 payment types in relation SCA exemptions such as payments to Trusted Beneficiaries

In Evaluation - The following roadmap items are in evaluation stage and may extend/enhance the P11 proposition in the future:

  • P9 – Status of payment. This item will define whether or not OBIE solutions will support the execution status of OB initiated payments.
  • P7 – Reverse payments (refunds). This item will define whether or not refunds of OB initiated payments will be supported by the OBIE solutions.
  • P19 - PSD2 alignment ongoing evaluation activity.

8.3 Assumptions

  • Roadmap item P11 will support single Bacs/CHAPS payments and bulk/batch payments from all the appropriate payment accounts that the ASPSPs support this functionality through, including corporate accounts.
  • Bacs Direct Debits are out of scope for roadmap item P11 as Direct Debits are not considered to be part of the payment initiation service defined by PSD2. 
  • The OBIE has to ensure support both proprietary/ legacy formats, as well as standard format, for bulk/batch payments. ASPSPs will have the option to choose the format to facilitate PISP enabled bulk/batch payments.
  • ISO 20022 format is to be considered for the initiation of bulk and batch payments as part of the payload of the bulk/batch API calls. However, a simplified version of this format is also to be additionally considered to accommodate the needs of smaller players in the market.
  • The consent screen for bulk/batch payments could include a summary of the total amount and the number of transactions included in the bulk/batch. Displaying the full details of transactions would be impractical for bulk/batches of large number of transactions. PSU could have the option to inspect the details of all the included transactions on a separate screen or the main screen.
  • The regulation allows bulk/batches of payments to be submitted with the PSU explicit consent, via a PISP, provided this functionality is available on online payment accounts.
  • The PSU will provide consent for the bulk/batch payments in their entirety. Validation of individual payments in the bulk payment order, will happen after the PSU has been authenticated at the ASPSP. For further details, please refer to section 10.5 of the Appendix.
  • Revocation/cancellation of bulk/batch payments with a future date or waiting multiple authorisations, will be handled as stated in the proposition papers P5a and P13.

For additional assumptions including edge cases, please refer to section 10.9 of the Appendix.

9. Adoption Metrics

The following metrics will be required to measure the adoption of the P11 payments proposition:

  • Number of TPPs initiating Bacs and CHAPS single payments using Open Banking.
  • Number of TPPs initiating batch and bulk payments using Open Banking.
  • Number of customer authorisations for Bacs and CHAPS single payments to ASPSPs.
  • Number of customer authorisations for batch and bulk payments to ASPSPs.
  • Volume of successful transactions generated for Bacs and CHAPS single payments.
  • Volume of successful transactions generated for batch and bulk payments.
  • Volume of failed transactions, by type of failure, for Bacs and CHAPS single payments
  • Volume of failed transactions, by type of failure, for batch and bulk payments.



10. Appendix

10.1 Detailed product requirements

Requirements marked as 'M'(Must) and 'S'(Should) as per the MoSCoW ratings are in scope for delivering the minimum viable product. All other requirements are listed for future consideration.

These are stated as requirements of the OBIE solution to enable implementers to meet regulatory compliance and/or customer use cases.

Requirements marked as 'M'(Must) are in scope of the OBIE solution. All other requirements are listed for future consideration. The final column indicates whether each requirement is 'mandatory', 'conditional' or 'optional' for implementation by ASPSPs and/or TPPs. These terms are defined here: Categorisation of requirements for standards and implementation.

ID

Requirement

MoSCoW

Rationale

Use Cases

P19 AlignmentImplementation

1

OBIE's Solution(s) must support payments initiation of single non-urgent (i.e. Bacs) domestic payments with the consent of the PSU from all types of payment accounts as identified in item P20 for payment initiation.

M

Regulatory 

UC1, UC3

PSR2PSR4PSR5PSR6PSR7PSR12

Conditional

(Mandatory if provided by ASPSP on existing channel)

2OBIE's Solution(s) must support payments initiation of single high value (ie CHAPS) domestic payments with the consent of the PSU from all types of payment accounts as identified in item P20 for payment initiation.MRegulatory UC2, UC3PSR2PSR4PSR5PSR6PSR7PSR12

Conditional

(Mandatory if provided by ASPSP on existing channel)

3OBIE's Solution(s) must support payments initiation of bulk domestic payments with the consent of the PSU from all types of payment accounts as identified in item P20 for payment initiation.MRegulatory UC4, UC5, UC6, UC7, UC8   PSR2PSR4PSR5PSR6PSR7PSR12

Conditional

(Mandatory if provided by ASPSP on existing channel)

OBIE's Solution(s) must support payments initiation of bulk international payments (SEPA) with the consent of the PSU from all types of payment accounts as identified in item P20 for payment initiation.MRegulatory UC13, UC16PSR2PSR4PSR5PSR6PSR7PSR12

Conditional

(Mandatory if provided by ASPSP on existing channel)

5OBIE's Solution(s) must support payments initiation of batches of domestic payments with the consent of the PSU from all types of payment accounts as identified in item P20 for payment initiation.MRegulatory UC9, UC10, UC11, UC12PSR2PSR4PSR5PSR6PSR7PSR12

Conditional

(Mandatory if provided by ASPSP on existing channel)

6OBIE's Solution(s) must support payments initiation of batches of international payments (eg non SEPA) with the consent of the PSU from all types of payment accounts as identified in item P20 for payment initiation.MRegulatory UC14, UC16PSR2PSR4PSR5PSR6PSR7PSR12

Conditional

(Mandatory if provided by ASPSP on existing channel)

7OBIE's Solution(s) must support payments initiation of batch payments containing both domestic and international payments (SEPA and non SEPA) with the consent of the PSU from all types of payment accounts as identified in item P20 for payment initiation.MRegulatory UC15PSR2PSR4PSR5PSR6PSR7PSR12

Conditional

(Mandatory if provided by ASPSP on existing channel)

8OBIE's Solution(s) must allow a PISP to transmit or confirm the PSU's consent to the submission and execution of all payment types stated in requirements 1 -7 MRegulatory All

PSR8

Conditional

(Mandatory if provided by ASPSP on existing channel)

9

OBIE's Solution(s) must support all the bulk/batch payments requirements stated in section 10.1 using a standardized payment message format between PISP and ASPSP. 

Determination of implementation will be in the domain of the ASPSP.

MRegulatory All bulk/batchFCA 17.29

Conditional

(Mandatory if provided by ASPSP on existing channel)

10

OBIE's Solution(s) must provide the PSU the ability, through their PISP and with their consent, to forward (upload) to their ASPSP bulk and batches of payments in existing legacy and proprietary file formats for processing by their ASPSPs, if currently supported by the ASPSPs' online offering.

Determination of implementation will be in the domain of the ASPSP.

MRegulatory UC18FCA 17.29

Conditional

(Mandatory if provided by ASPSP on existing channel)

11

OBIE's Solution(s) must support all domestic and international payment types offered by the ASPSPs online platforms to consumer and business customers for single payments and bulk/batch payments.

MRegulatory All

PSR3

Conditional

(Mandatory if provided by ASPSP on existing channel)

12OBIE's Solution(s) must enable the ASPSP to request the same information from the PISP as is requested from the PSU when making the single (FPS, CHAPS, BACS etc) or batch/ bulk payments directly MRegulatory All

RTS26

Conditional

Refer to Customer Experience Guidelines

13OBIE's Solution(s) must allow PSUs to select the payment scheme or priority to be used for the execution of the payments (single or bulk/batch) at the ASPSP, if currently supported by the ASPSPs' online offering and it has not been provided by the PISP already.MCustomer UC7, UC12FCA 17.29

Conditional

Refer to Customer Experience Guidelines

14OBIE's Solution(s) must  allow ASPSPs to notify the PSU prior to the receipt of the payment order if unable to execute the payment using the selected payment scheme as per requirement 13. MCustomer UC7, UC12

Conditional

(Mandatory if provided by ASPSP on existing channel)

15

The OBIE's Solution(s) must enable the PISP to return a confirmation of successful initiation of the bulk/batch payment to the PSU along with the payment amount and charges applied by the PISP (with breakdown where applicable)

Note: This is for file level validation

MRegulatory UC17PSR4,

Conditional

(Mandatory if provided by ASPSP on existing channel)

16

OBIE's Solution(s) must allow the ASPSP to return to the PISP, immediately after the receipt of the payment order, the information on initiation and execution, for example, the status of the bulk/batch payment order (i.e. payment status report).

Note: This may include which payments included in the batch/bulk submission have failed validation and have been rejected by the ASPSP, including the reason code of the failure. Optionally, the payment status report may also include the successfully validated payments.

MRegulatory UC17PSR12

Conditional

(Mandatory if provided by ASPSP on existing channel)

17

OBIE's Solution(s) must allow PSUs, through their PISPs, at any further time,to receive the information (e.g. payment status report) of which successfully validated payments included in the batch/bulk submission have been executed by the ASPSP and which ones have failed to be executed and the reason code of the failure.

Note: For single immediate payments successful execution would mean PSU account debited. For future dated payments, successful execution will be limited to the payments have been successfully warehoused by the ASPSP for execution. 

M

Customer UC17

Conditional

(Required for PISP to know the status of each payment within bulk/batch.)

18OBIE's Solution(s) must allow business PSUs to select the payment scheme or priority to be used for the execution of the payments (single or bulk/batch) at the PISP, if currently supported by the ASPSPs' online offering (e.g through file uploading).MCustomer UC3, UC5, UC10, UC16

Conditional

(Mandatory if provided by ASPSP on existing channel)

19OBIE's Solution(s) must allow ASPSPs to notify the PISP prior to the receipt of the payment order if unable to execute the payment using the selected payment scheme as per requirement 18. MCustomer UC3, UC5, UC10, UC16

Conditional

(Mandatory if provided by ASPSP on existing channel)

20

OBIE's Solution(s) must allow PSUs, through their PISPs, to receive any batch/bulk payment status information from their ASPSPs in legacy and proprietary file formats, if currently supported by the ASPSPs' online offering.

MCustomer UC19

Conditional

Refer to Customer Experience Guidelines

21OBIE's Solution(s) must allow PSUs to select the execution date for the bulk/batch payments in order to allow submission of future dated bulk\batch payments,  if currently supported by the ASPSPs' online offering.MCustomer UC6, UC8,  UC11, UC12 

Conditional

(Mandatory if provided by ASPSP on existing channel)

22OBIE's Solution(s) must allow PSUs to select the execution date for the single Bacs or CHAPS payment at the PISP,  in order to allow submission of future dated Bacs or CHAPS payments.MCustomer UC1, UC2, UC3

Conditional

(Mandatory if provided by ASPSP on existing channel)

23OBIE's Solution(s) must allow PISPs to identify which file formats are supported by which ASPSPs to allow PISPs to manage the options that they make available to their PSUs. MCustomer UC18, UC19

Conditional

(Mandatory for TPPs to know what is supported by ASPSP)

24

OBIE's Solution(s) must allow PSUs to select the account to be debited for the single or bulk/batch payments at the PISP. 

Note: For batches including many different transactions it could be considered that the PISP  should provide the account info to avoid PSU customer experience challenges on the banks' UI,

MCustomer UC4, UC5, UC9, UC10, UC11

Conditional

(Mandatory if provided by ASPSP on existing channel)

25OBIE's Solution(s) must allow PSUs to select the account to be debited for the single Bacs or CHAPS payment at the PISP. MCustomer UC1, UC2, UC3

Mandatory

(But the field is Optional)

26OBIE's Solution(s) must allow PSUs to select the account to be debited for the bulk/batch payments at the ASPSP, if this has not been provided by the PISP already.

Note: This is usually an edge case.

MCustomer UC7, UC8, UC12, 

Conditional

(For good customer journey experience)

27OBIE's Solution(s) must allow PSUs to select the account to be debited for the single Bacs or CHAPS payment at the ASPSPMCustomer UC1, UC2, UC3

Conditional

(Mandatory if provided by ASPSP on existing channel)

28

OBIE's Solution(s) must be able to support bulk/batch payments for multi-authorisation accounts in alignment with proposition item P13. 

MRegulatory All

Conditional

(Mandatory if ASPSP supports Multi-Auth on existing channel)

29OBIE's Solution(s) must provide the ability to PISPs to use a simplified version of the OBIE standardised payment message format to submit their business customers' bulk/batch payments, with their consent, to their ASPSPs.MCustomerUC20

Optional 

(No specific regulatory requirement for this capability; but has been perceived to be required by some TPPs to implement their proposition)

30OBIE's Solution(s) must support bulks/batch sizes that can carry at least as many payments as possible via existing ASPSP channel.MCustomer All bulk/batch

Conditional

(Mandatory for TPPs to know what is supported by ASPSP)

31

The OBIE's Solution(s) could allow the ASPSP to return to the PSU, via their PISP, at any further time, the full status of payment execution for each payment included in the batch/bulk submission, including which one have been successfully received (if available) and which ones have failed and the reason code of the failure.

The details of this requirement will be covered by roadmap item P9 - Status of payment

CCustomer UC17

Future Consideration

(To be covered under P9)

10.2 Regulatory references and considerations

10.2.1 Regulatory references

The following regulatory references are relevant when considering the scope of item P11:

FCA Approach Document (17.29):

"In order to meet this requirement, we expect ASPSPs to allow each customer to initiate a payment via a PISP to the same level of functionality that is available to a customer if they initiate a payment directly with their ASPSP. ASPSPs are not, however, required to provide functionality via a PISP that exceeds the functionality they offer to their customers directly"

OBIE View: 

Scope of roadmap item P11 should create the functionality to enable a PISP, with the PSU's consent, to request for an ASPSP to execute bulk/batch payment orders, if and to the extent, this functionality is available to the PSU on their online payment account.

RTS Article 5 - Dynamic linking

1. Where payment service providers apply strong customer authentication in accordance with Article 97(2) of Directive (EU) 2015/2366, in addition to the requirements of Article 4 of this Regulation, they shall also adopt security measures that meet each of the following requirements:

(a) the payer is made aware of the amount of the payment transaction and of the payee;

(b) the authentication code generated is specific to the amount of the payment transaction and the payee agreed to by the payer when initiating the transaction;

(c) the authentication code accepted by the payment service provider corresponds to the original specific amount of the payment transaction and to the identity of the payee agreed to by the payer;

(d) any change to the amount or the payee results in the invalidation of the authentication code generated.

2. For the purpose of paragraph 1, payment service providers shall adopt security measures which ensure the confidentiality, authenticity and integrity of each of the following:

(a) the amount of the transaction and the payee throughout all of the phases of the authentication;

(b) the information displayed to the payer throughout all of the phases of the authentication including the generation, transmission and use of the authentication code.

3. For the purpose of paragraph 1(b) and where payment service providers apply strong customer authentication in accordance with Article 97(2) of Directive (EU) 2015/2366 the following requirements for the authentication code shall apply:

(a) in relation to a card-based payment transaction for which the payer has given consent to the exact amount of the funds to be blocked pursuant to Article 75(1) of that Directive, the authentication code shall be specific to the amount that the payer has given consent to be blocked and agreed to by the payer when initiating the transaction;

(b) in relation to payment transactions for which the payer has given consent to execute a batch of remote electronic payment transactions to one or several payees, the authentication code shall be specific to the total amount of the batch of payment transactions and to the specified payees.

10.2.2 Regulatory considerations

OBIE primarily recognises two ways that the OBIE solution can provide for bulk/batch payments, either by introducing an OBIE standard format or by using existing legacy/proprietary formats.

From a regulatory perspective, the FCA Approach Document states the following:

17.29 read together with section 17.28 deals with the treatment of payment orders initiated by a PISP and the relevant requirements under Reg 69(2)(c):

17.28 For PIS, ASPSPs are required to treat the payment order in the same way, in particular in terms of timing, priority or charges, as a payment order initiated by the customer directly.

17.29 In order to meet this requirement, we expect ASPSPs to allow each customer to initiate a payment via a PISP to the same level of functionality that is available to a customer if they initiate a payment directly with their ASPSP.

OBIE’s view is that 17.28 requires payment orders submitted by the PISP, to be treated equally to those submitted by the customer directly. Further 17.29 states that in order to meet those requirements, the ASPSP must provide the same level of functionality that is available to a customer if they initiate a payment directly.

In our view, that this does not require an identical functionality from a technical standpoint (although the same can be provided) but the equivalence to initiate the same payment types as available to the PSU on their ASPSP’s online channel, in line with the non-discrimination principles of the PSRs.

From an industry consultation standpoint, there have been requests for both types of formats. We have changed the assumption in 8.3 to meet both these requirements, leaving the ASPSPs with the optionality to choose which solution to implement.

10.3 Roadmap item definition

The following table is taken 'as-is' from the published roadmap: 
(https://www.openbanking.org.uk/wpcore/wp-content/uploads/2017/11/FAO-CMA_Proposed-Amendments-to-Agreed-Arrangements_v_final-1.pdf)

P11- BACS, CHAPS, Bulk and Batch payments

Description

Rationale

Aligns with

Scope Item description:

  • Extension of write (PIS) functionality of the OB R/W APIs to cover payments other than faster payments (including but not limited to BACS, CHAPS, bulk and batch payments)

Key activities:

  • An evaluation phase by the OBIE to assess whether the payment types referred to above should be developed as a standard. Evaluation criteria are likely to include alternative online offerings, consumer utility, consumer uptake, consumer risk, technical complexity and cost to implement and prioritisation of other OB items.
  • (pending the outcome of the evaluation) The development of standards by the OBIE for the products and functionality referred to above
  • (pending the outcome of the evaluation) The implementation of those standards by the CMA9 for Release 4

Regulatory alignment:

  • Fulfils the requirements of the Order by aligning with PSD2

Open Banking adoption:

  • Extends functionality of OB Standards payment types

Consumer / SME utility:

  • Consumers would be able to benefit from high value payments and SME’s in particular from bulk and batch payments

PSD2

10.4 Definitions

Direct Submission

The submission of payment orders by a PSU directly to a payment scheme without additional payment processing by the PSU’s ASPSP (beyond sponsoring the PSUs participation in this mechanism where necessary).  The PSU will access the direct submission mechanism through a separate interface provided by their ASPSP or a third party approved by the payment scheme.  This direct channel interface will be separate from the ASPSPs’ online or mobile banking service. Direct submission is currently only available for payments into the BACS scheme (via Bacstel-IP) or the Faster Payments scheme (via Direct Corporate Access DCA and File Input Module FIM).

Host to Host

The submission of payment orders by a business PSU to their bank using a dedicated secure point to point channel. This could be implemented using multiple connectivity options ranging from dedicated data connection lines to over-the-internet solutions using a secure protocol for sharing and uploading files such as secure FTP. In the majority of cases, each submitting organisation has a dedicated FTP folder at the bank side for their files and secure authentication credentials. Maybe the primary characteristic of host to host solutions is the fact that it does not require physical persons to be present and allows machine to machine authentication (using hardware security modules - HSMs) and interfacing enabling straight-through-processing (STP). The STP is a highly desirable feature for larger organisations and FIs  which submit multiple payments on behalf of their customers.

Bulk Payments

In the context of roadmap item P11, bulk payments refers to a group of payment orders (payment instructions) to be processed together as a single total debit at the PSUs account and multiple individual credits to be send to multiple beneficiaries. Bulk payments are typically homogeneous meaning that they are treated as a whole and are processed by the same payment scheme. Typical examples of bulk payments include Bacs (st18 format), FPS DCA and SEPA (pain001).

Batch Payments

In the context of roadmap item P11, batch payments refers to a group of payment orders (payment instructions) submitted as a group of payments in the same file. However, they are processed separately each one as a single payment generating a single debit at the PSUs account and a single credit to an individual beneficiary (note: This PSU accounting feature can vary between ASPSPs and batches of payments can still generate a single debit entry). Batch  payments are usually heterogeneous meaning that they may contain arrays of payments with different debit accounts and even to be processed by different payment schemes. Typical examples of batch payments include SWIFT FileAct files or proprietary files supported by ASPSPs through host to host solutions and file upload.

10.5 Dynamic linking process models

No validation of individual payments during the payment bulk/batch setup. Dynamic linking takes place after authentication take place.

Note 1: The above diagram is specific to the redirection model.

Note 2: Considerations relating to the dynamic linking at payee level will be taken in the next phase of work.

10.6 PSU research prototypes

OBIE is performing PSU research through an external company called Engine. Four prototype journey's have been produced and are used for the PSU research:

IDNameTest topicURL
1Bulk payroll payment, debit account selection at TPP, (single user, no multi-auth, immediate payment)The user would create a file of payments in their accounting package (e.g. a list of all the payroll payments to be made, beneficiary name, amount, account details etc.).  This file would be available for them to select and submit to the bank.  They would also select the account they want to debit.  They would then be re-directed to their bank (based on the sort code of the account they chose to debit).  Once in the bank domain they would authenticate themselves, the bank would playback a summary of the payment instruction (total debit, debit account, value date, number of payments) and offer a drill down into the detail (individual payments). https://invis.io/FJHEH97DZPG
2Bulk payroll payment, debit account selection at bank, (single user, no multi-auth, immediate payment)The user would create a file of payments in their accounting package as in Journey 1.  This file would be available for them to select and submit to the bank.  They would select their bank and be re-directed there to authenticate themselves. They would then select the account they want to debit and the bank would playback a summary of the payment instruction (total debit, debit account, value date, number of payments) and offer a drill down into the detail (individual payments). The user would then confirm or cancel the instruction.https://invis.io/D4HENNJHCBZ
3Batch of invoice payments, multiple debit accounts selection at TPP, single payment channel (e.g. FPS)The user would create batches of payments in their accounting package.  In this scenario we assume that all payments in a single batch could be from a variety of accounts (e.g. one for each department paying an invoice) but all those accounts are with the same bank.  The user would select the batch they want to submit (e.g. invoices200418).  The TPP would then present a “summary” consent request (number of payments from each account, total debit).   User confirms and is re-directed to bank based on sort code of accounts being debited.  The user authenticates themselves.https://invis.io/3GHFA66F4VX
4Batch of invoice payments, multiple debit accounts selected at TPP, multiple payment channels (e.g. FPS, CHAPS and BACS)The user has created a batch of payments in their accounting package.  These payments are from a number of accounts (all with the same bank) and have been flagged to be delivered through specific payment channels (e.g. for pricing or timing reasons).  The user selects this batch to submit and is presented with a “summary” consent (number of payments from each account to each payment scheme and the total amount).  The user confirms consent and is re-directed to the bank for authentication.https://invis.io/CSHK2KKXJKG

10.7 Detailed list of use cases

The following is the detailed list of use cases related to proposition item P11.

ID

Use CaseMet
Single Payments
UC1 - Single non-urgent domestic payment (i.e. Bacs)

As a Business Customer,

I want to use my accounting software to make a single non-urgent domestic payment (i.e. Bacs payment) to my supplier through my ASPSP, so that i can keep my transaction charges low.    

Fully
UC2 - Single high value domestic payment (i.e. CHAPS)

As a Business Customer,

I want to use my accounting software to make a high value single domestic payment (i.e. CHAPS payment) through my ASPSP, so that I can pay my suppliers' high value invoices. 

Fully
UC3 - Single domestic payment with payment scheme selected by PSU at TPP

As a Business Customer,

I want to use my accounting software to initiate a single payment and select the payment scheme (i.e. FPS, CHAPS, BACS) that I want my payment to be executed by my ASPSP, so that I have the flexibility to select what meets by business needs best. 

Fully
Bulk/Batch Payments

UC4 - Bulk payments (e.g. payroll) with debit account and payment scheme chosen by TPP

As a Business Customer,

I want to make payroll payments (bulk) directly from my accounting software through my ASPSP, so that  I can keep my process simpler and easier.

Note: accounting software knows is payroll and defaults to Bacs and payroll account to use for debiting

Fully
UC5 - Bulk domestic payments with debit account and/or payment scheme chosen by PSU at TPP

As a Business Customer,

I want to select the payment scheme (i.e. FPS, CHAPS, BACS) and/or the account to be debited directly from my accounting software and submit bulk payments to my ASPSP,  so I can make the choices that meet my business needs.

Prototype: https://invis.io/FJHEH97DZPG

Fully
UC6 - Future Dated bulk domestic payments with payment value date chosen by PSU at TPP

As a Business Customer,

I want to select a value date in the future for the bulk payments directly from my accounting software and submit bulk payments to my ASPSP,  so I have flexibility of submitting my bulk payments early.

Note: selecting the value date may also be an implicit way to select the payment scheme to use for the execution of the bulk payments

Fully

UC7 - Bulk domestic payments with debit account and/or payment scheme chosen by PSU at ASPSP

As a Business Customer,

I want to submit bulk payments directly from my accounting software to my ASPSP and then select the account to be debited and/or the payment scheme (i.e. FPS, CHAPS, BACS) for the payment, so I have full flexibility by the options available.

Note: Low probability/edge use case

Fully
UC8 - Future Dated bulk domestic payments with date chosen by PSU at ASPSP

As a Business Customer,

I want to submit bulk payments directly from my accounting software to my ASPSP and then select a date in the future (or future value date) for the bulk payments to executed by my ASPSP,  so I have flexibility of submitting my bulk payments early.

Note: Low probability/edge use case

Fully

UC9 - Batch domestic payments with multiple debit accounts chosen by PSU at TPP

As a Business Customer,

I want to make multi invoice payments (batch) to multiple beneficiaries by selecting the account to be debited for each group of payments (bulk) and make a single submission directly from my accounting software to my ASPSP, so that I don't have to submit each group of payments (bulk) separately. 

Fully

UC10 - Batch domestic payments with multiple debit accounts and/or multiple payment schemes chosen by PSU at TPP

As a Business Customer,

I want to make multi invoice payments (batch) to multiple beneficiaries by selecting the account to be debited and/or the payment scheme (i.e. FPS, CHAPS, BACS) for each batch of payments, and make a single submission directly from my accounting software to my ASPSP, so that I don't have to submit each group of payments separately and choose these parameters at the ASPSP.

Prototype: https://invis.io/CSHK2KKXJKG

Fully
UC11 - Batch domestic payments with multiple debit accounts and date chosen by PSU at TPP

As a Business Customer,

I want to make multi invoice payments (batch) to multiple beneficiaries by selecting the account to be debited and/or the execution date for each batch of payments, and make a single submission directly from my accounting software to my ASPSP, so that I don't have to submit each group of payments separately and choose these parameters at the ASPSP.

Fully
UC12 - Batch domestic payments with multiple debit accounts and/or multiple payment schemes and/or value date chosen by PSU at ASPSP

As a Business Customer,

I want to submit multi invoice payments (batch) to multiple beneficiaries directly from my accounting software to my ASPSP and then select the account to be debited and/or the payment scheme (i.e. FPS, CHAPS, BACS) and/or the desired value date for each bulk of payments in the batch, so that I don't have to submit each group of payments separately.

Note: Low probability/edge use case

Fully
UC13 - Bulk international payments

As a Business Customer,

I want to initiate through my PISP bulk international payments in Euro (SEPA)  from one of my UK Euro bank accounts or other currency accounts, to suppliers' accounts in the SEPA zone, so that I can import the goods and services necessary for my business.

Fully
UC14 - Batch international payments

As a Business Customer,

I want to initiate through my PISP batches of international payments in Euro and other currencies from multiple GBP or other currency accounts, to multiple suppliers' accounts in Europe and Rest of the World (ROW), so that I can import the goods and services necessary for my business.

Fully
UC15 - Batch payments mixing domestic and international payments 

As a Business Customer,

I want to initiate through my PISP batches containing bulks of both domestic and international payments, so that I dont have to submit each group of payments separately.

Fully
UC16 - Batch international payments with payment scheme selected by the PSU at TPP

As a Business Customer,

I want to initiate through my PISP batch international payments selecting the payment scheme for each batch of international payments submitted to my ASPSP, so that I can make the choices that meet my business needs.

Fully
UC17 - Status of bulk/batch processing

As a Business Customer,

I want to receive the information through my accountancy platform of which payments included in the batch/bulk submission have been accepted for processing, which ones have been executed by my ASPSP (i.e. account debited) and which ones have failed including the reason code of the failure.

Partially

UC18 - Bulk/Batch payments using legacy or proprietary payment file formats

As a Business Customer,

I want to use a PISP service to submit bulk/batch payments contained in legacy/proprietary file formats to my ASPSP, so that I can use my existing old/legacy platforms with the payment initiation services offered by PISPs using Open Banking APIs.

Fully
UC19 - Bulk/Batch payments status reports using legacy or proprietary payment file formats

As a Business Customer,

I want to use a PISP service to receive payment status reports of my bulk/batch payments submissions in legacy/proprietary file formats from my ASPSP, so that I can use my existing old/legacy platforms with the payment initiation services offered by PISPs using Open Banking APIs.

Fully
UC20 - Bulk/Batch payments using simplified payment messages

As a PISP SME,

I want to be able to use a simplified payment message format to submit bulk/batch payments to ASPSPs on behalf of my business customers, with their consent, so that I can keep the interface simple and easy to implement. 

Fully

10.8 Customer (PSU) research

The following is the preliminary findings of the customer research for proposition item P11.

10.9 Additional detailed assumptions & edge cases

  • In cases where the TPP sets the 'no multi-auth' flag as per proposition P13 for a bulk/batch payments submission, it is in the ASPSP domain to either reject the whole of the batch/bulk of payments or individual payments within a batch that are to be paid from an account requiring multi authorisation. However, in any case, the ASPSP should inform both the PSU and the TPP of the rejected batch/bulk payments.
  • In multi authorisation cases, PSUs authorisers will not be asked to authorise payments in a batch submission, if the authoriser does not have permission to approve all debit accounts included in the batch file. Handling of this cases is in the ASPSP domain, however it may be expected that the authoriser will only be asked to authorise the payments of the batch for the debit accounts they have permission to do so. 
  • it is assumed that all payment API messages for bulk/batch payments will be digitally signed. However, OBIE will not be responsible for digitally signing of any files (in any format) by the PSU as it may be taking place today in certain implementations. However, the fact that OBIE may allow TPP applications to send payments directly to the  ASPSP, via a PISP, without the need to export and import a file, can make customers more comfortable with these solutions.
  • It is assumed that the submitting PSU of the bulk/batch payments, after SCA at the ASPSP, will be able to have access to the whole of the bulk/batch payments and not to certain groups of the payments. 
  • It is assumed that the validation of the structural format of the payload of bulk/batch payments will cause ASPSPs to reject the whole of the bulk/batch in case of failure. However, payload content validation is expected to take place later on in the process and after the submitting PSU completes SCA with the ASPSP.
  • It is assumed that during bulk/batch payload content validation the ASPSPs will apply the same BAU process as per bulk/batch payments submitted through their own online platforms. It is thus in the ASPSP domain to select whether they would reject to whole submission or individual payments within the bulk/batch submission. In certain occasions, ASPSPs allow customers to select this.
  • It is assumed that ASPSPs will apply the same level of syntax, format and structural validation as per their existing BAU process for bulk/batch payments submitted through their own online platforms.
  • It is assumed that in certain occasions, TPPs (i.e. PISPs) cannot rely on the customers to provide them with the format of payments that the ASPSPs support. In these cases, TPPs will be providing mapping of these legacy/proprietary formats to formats supported by the processing ASPSP.
  • It is assumed that there will be cases where batch payments will simply include arrays of payments constructed by the TPPs. These cases should also be supported by the OBIE solutions.

10.10 High level concept designs

Model 1 - OBIE Standardised Format

Model 2 - Existing Legacy/Proprietary File Formats