P11 • BACS, CHAPS, Bulk and Batch payments

1. Version control

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.

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.

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)

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:

10.7 Detailed list of use cases

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

10.8 Customer (PSU) research

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

 PDF

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