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.
Other pages in this section
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.
The additional payments to be covered by the new PIS functionality include:
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.
Evaluation of roadmap item P11 resulted in the following scope being identified:
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.
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 paynearly 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.
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:
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.
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.
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.
…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.
Reasons for Direct Submission and Host-2-Host being out of scope:
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)
OBIE understands that the P11 payments proposition may need to support the following functionality:
In Discovery / Specification:
In Evaluation – The following roadmap items are in evaluation stage and may extend/enhance the P11 proposition in the future:
For additional assumptions including edge cases, please refer to section 10.9 of the Appendix.
The following metrics will be required to measure the adoption of the P11 payments proposition:
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.
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”
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.
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.
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)
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.
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).
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.
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.
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:
The following is the detailed list of use cases related to proposition item P11.
The following is the preliminary findings of the customer research for proposition item P11.
Model 1 – OBIE Standardised Format
Model 2 – Existing Legacy/Proprietary File Formats