P9 • Status of payment

1. Version Control

2. Roadmap item definition

A meaningful payment status is critical to underpin the successful operation of the Open Banking ecosystem for PISP initiated payments. This roadmap item entails the extension of the Write PIS functionality of the OB R/W APIs to enable ASPSPs to communicate the appropriate payment statuses to PISPs.

2.1 Problem Statement

The current OBIE design supports the provision of a payment status message (pursuant to Reg. 69(2)(b)) from the PSU’s ASPSP to the PISP which provides all information regarding the payment initiation and the payment execution (e.g. pending, rejected, or accepted) at the point in time immediately after the ASPSP has received the payment order from the PISP (i.e. at payment submission). It is important to note that this functionality is limited to the status available to the ASPSP at the point in time at which the payment submission is submitted by the PISP. Accordingly, it does not cater for any subsequent status updates on the payment order. In order to receive further status updates, the PISP would need to submit additional requests to the ASPSP, querying the payment status, and the ASPSP will be able to respond by sending any of these status messages: “rejected”, “pending”, “accepted- settlement in process” or “accepted-settlement completed.” It is worth noting that these status messages at end of the processing phase are not available for all payment types, for example, Standing Orders or Future Dated Payments. For these types of payments, the ASPSP would only be able to provide the status of the initial set-up of the payment order. However PISPs have indicated that they would also find it valuable to receive an additional status once the payments have been submitted for processing on the agreed execution date by the ASPSP.

2.2 Scope

The OBIE standards should enable an ‘adequate’ payment status to be provided to the PISP by the ASPSP at the end of the processing phase (e.g. accepted, successfully processed, debited from PSU’s account and credited to the beneficiary’s account). This will provide both the PISP, the PSU and the beneficiary (e.g a merchant) sufficient certainty that the payment will reach the beneficiary account and thus in the case of the merchant example, the ordered services or goods can be released to the PSU.

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, if any, and key customer use cases.

Have updated the regulatory considerations – see below.

When considering the wider scope, and particularly the provision of other status options (such as whether the funds have been received or not), in several cases ASPSPs may not normally have access to this information. However, even when they do, some ASPSPs currently do not inform PSUs if funds have been sent and/or received by the beneficiary (or their ASPSP), while some other ASPSPs provide this information. We note that consideration has been given for an optional status message to be sent from the ASPSP to the PISP, which informs the PISP that the payment has been successfully received by the payee’s ASPSP and credited to the payee account. This was initially not considered as part of the P9 Evaluation Report scope, however, work undertaken by API Evaluation Working Group has identified this as important functionality. As such, we have included this as an additional optional product requirement in the scope of this proposition to enable the provision of this information for ASPSPs, who choose to support this functionality.  

For the relevant roadmap item definition, please refer to Proposition P9 – Status of payment (V0.5) of the Appendix.

Note 1: Detailed payment status information cannot be provided for all ‘payment account’ products as there are products which do not support all payment types.

Note 2: There are cases where the status that the payment has been successfully received by the payee’s ASPSP and credited to the payee account is complex and cannot be stated accurately. These cases include Indirect Agency Banks of Faster Payments, which connect to Faster Payments via FPS Direct Members. Some of these complexities are covered in section 10.6 

3. Market analysis

3.1 Payment Rejection rates

Out of the total number of bank account payments, approximately 4% by volume (i.e. 2.4% by value) are rejected during payment setup, PSU authentication, payment initiation, and payment processing phases combined. On the contrary, 0.23% by volume (i.e 0.14% by value) are rejected during the payment execution phase, when the payment has been sent to the payment scheme by the ASPSP. Rejection rates cannot be broken down further by phase separately, because today those metrics are not available and because each ASPSP performs its checks at different stages within those phases.

Out of the total number of rejections during all phases, close to 95% by volume (and by value) are rejected during payment setup, authorisation, initiation, and processing phases combined, as shown in the table below. Around 5% by volume (and by value) of all rejections happen during the execution phase.

Payment Rejection Rates

Source: P9 Final Evaluation Report

3.2 Market Needs

Engagements with OBIE stakeholder groups, together with regular meetings with representatives in Evaluation Working Group B, workshops with TPPs/PSPs, and other bilateral engagements, highlighted the following points as key issues and concerns:

Merchants

• The earlier the merchant has sufficient certainty that the payment will be successful, the earlier it can ship goods or services. This will have positive impact on cash flow and stock management
• The earlier the merchant knows a payment is rejected, the quicker it can offer alternative payment solutions to a customer. This avoids abandoned carts and loss of revenue

Customers

• Customers may incur penalty fees and excess interest if they don’t know their credit card repayment has failed
• Retail investors can miss their time-limited purchase window for buying shares, if they do not know in time if their payment is rejected
• Customers making international purchases involving currency conversion may miss out on the offered FX-rate if they re-attempt too late after a rejected payment
• The Payments Strategy Forum (PSF) had concluded that status of payment (‘assurance data’) was important to customers (Payment Strategy Forum, Collaborative Requirements and Rules for the End-User Needs Solutions, End-User Requirements and Rules Blueprint, December 2017). This paper identifies the lack of adequate assurance to the payer that: a) they have sufficient funds to make a payment, b) they are making the payment to the intended payee’s account, and c) that a status of the payment is available once they make the payment. Addressing the above increases the end users’ confidence on the payment systems.

SMEs

• Businesses may not get an early discount, or must pay penalty fees if they don’t know their payment has failed
• For some SMEs the payment status is a critical business tool. For those SMEs managing numerous payments a month, including supplier payments and payroll, it is vital that exceptions and payment failures are notified immediately so that alternative arrangements can be put in place
• An SME having to manually check payment status may lose productivity or cost gains

Note: There are cases where Standing Order and Future Dated payments which failed to be executed for valid business reasons (e.g. lack of funds in the debit account) may be retried at a later point in time during the execution day by some ASPSPs. This is not reflected in the above payment status model but will be taken under consideration during the detailed design of the OBIE solution.

3.3 Current Payment Status Analysis

Analysis of ASPSPs’ implementations during evaluation has identified that many ASPSPs are only providing the ‘pending’ status in order to meet the regulatory requirement for an ‘immediate’ response pursuant to Reg. 69(2)(b).

3.3.1 Payment life cycle

The below model as stated in the P9 evaluation report shows the life cycle of a PISP initiated payment and the minimum level of desired (i.e. ‘sufficient’) payment status.

3.3.2 Extending OBIE’s Payment Status Model

The below model illustrates how the OBIE payment status model can be extended to include both payment status beyond the payment processing phase of the payment’s life cycle and also include payment types other than single domestic payments.

( * ) Payment execution. Once the payer’s ASPSP has performed all process steps and checks, the payment can be placed in the infrastructure of the chosen payment scheme, processed and passed on to the payee’s ASPSP. Receiving a payment status message is dependent upon the scheme used and whether the payee’s ASPSP can send a confirmation status that the payment has been received, accepted or rejected and if the payee’s account has been credited. 

Note: To provide the PISP with a payment status message at the end of the processing phase, the GET endpoint call must be used. As per V3 standards, the GET endpoint implementation has been made mandatory. However, the status returned for some payment types describes the initiation status only and not the subsequent processing and execution of the payment. This applies to Domestic Scheduled Payments, Domestic Standing Orders, International Scheduled Payments, International Standing Orders and File Payments. In summary, the gaps of the existing OBIE’s payment status model are summarised as follows:

• Issue 1: Statuses once the payment leaves the debtor agent are not tracked and reported
• Issue 2: For FDPs, SOs and File Payments, the status reflects the state of the payment order initiation – not the payment itself

4. Customer use cases

 The following are some example use cases which have been considered for this proposition. 

* Note: The above use cases are stated as being met because the existing standards and the requirements included in this paper cover these cases. However, while the ‘Get’ status API call has been made mandatory for the ASPSPs to implement in OBIE V3 Standards, there is no mandatory requirement for ASPSPs to provide the payment status after the payment initiation instance (e.g. ‘pending’ status). Some ASPSPs are expected to provide an updated status while some others will continue responding to the payment status calls with ‘pending’ status. Thus, in reality, all the above use cases are only partially met and not fully met.

5. Regulatory Considerations

Reg. 69(2)(b) requires ASPSPs to provide all information on the payment initiation and all information regarding execution of the payment, which is available to the ASPSP, immediately after receipt of a complete payment order from the PISP (i.e. after authentication of the PSU, when the PISP submits the payment order to the ASPSP). This is a snapshot point-in-time status and could likely often be “pending” (please refer to the Payment Status Model in 3.3.2). As such, if the ASPSP only provides the “pending” status available, it will meet its regulatory requirements providing that status to the PISP and there is no further regulatory requirement to subsequently confirm when the payment has been successfully accepted for execution (unless that information is available to the ASPSP at the time they receive the payment order from the PISP which is practically impossible as shown in the above Payment Status Model).

We note that the recent FCA Approach Document has provided further guidance on the information which ASPSP must provide to PISP pursuant to Reg. 69(2)(b). More specifically, paragraphs 17.29 -17.30 clarify that this information should include all relevant information relating to receipt of payment order, which, depending on the payment type, should include reference, amount, exchange rate, charges, date and status of successful initiation of the payment. The provision of this information by the ASPSP to be PISP is supported by the OBIE solution and ASPSP should consider the inclusion of this information, where applicable, in the context of this guidance. Further, Reg. 44(1)(a) places a separate requirement on the PISP to provide the PSU with a confirmation of a successful initiation of a payment order with the PSU’s ASPSP. The PISP would only need to provide a status to the PSU that the payment has been successfully submitted to the ASPSP for further action (i.e. processing and execution) but not that the ASPSP has actually executed the payment.

ASPSPs need to provide the same amount of information ‘immediately’ after receipt of the payment order. If at that point in time, the ASPSP only has “pending” status, then that’s all they can provide to PISP unless the payment fails, in which case, ASPSPs would need to consider their obligations related to information on failure to execute a payment.

6. Evaluation criteria

OBIE and Evaluation Working Group B (EWG B) have undertaken work to define the scope of the evaluation. Based on the agreed detailed scope of work, use cases were developed to better understand the market requirements. A gap analysis was then undertaken, and, based on this; several potential solutions were considered to address these gaps.

To arrive at the most optimal recommendation, the potential solutions were tested against a set of evaluation criteria:

• Market impacts and benefits to customers
• Cost / proportionality of implementing a particular solution
• Regulatory compliance of, in particular, PSD2/RTS
• Technical feasibility

To collect the evidence and data, OBIE have undertaken market engagement via workshops, bilateral meetings with stakeholders and regular meetings with EWG B, which consists of representatives of all OBIE stakeholder groups.

7. Product Requirements

1. OBIE to enable a PISP to obtain the status of the payment any time after the payment submission for all supported payment types.

The payment status information at the end of the processing phase is not immediately available to ASPSP but should be provided for the following payment types:

• Single, Immediate, Domestic
• Single, Future-dated, Domestic
• Standing-order, Domestic
• Single, Immediate, International
• Single, Future-dated, International
• Standing-order, International
• Bulk & Batch

2. OBIE should enable the ASPSP to send a meaningful status message to a PISP request for each processing phase and particularly when settlement on the debtor’s account has been completed thus providing the PISP with a sufficient status message that the payment will be successful.

As a minimum, the four status messages the PISP should be receiving from the PSU’s ASPSP are:

• Pending: payment initiation or individual transaction included in the payment initiation is pending.  Further checks and status update will be performed.
• Rejected: Payment initiation or individual transaction included in the payment initiation has been rejected.
• AcceptedSettlementInProcess: All preceding checks such as technical validation and customer profile were successful and therefore the payment initiation has been accepted for execution.
• AcceptedSettlementCompleted: Settlement on the debtor’s account has been completed (ISO code ACSC)

as per the Payment Status Model defined in section 3.3.2 

3. OBIE should enable the ASPSP to provide or make available to the PISP a confirmation from that the payment has been executed (e.g. provide the status message AcceptedCreditSettlementCompleted, ISO code ACSC), as illustrated in the Payment Status Model defined in section 3.3.2

4. Moreover, OBIE will enrich the existing list of payment status messages, currently supported by V3 standards, with additional optional status information as per the ISO 200022 standard and other standards, in order to future proof the OBIE standards and allow ASPSPs to provide more granular level of payment initiation, processing and execution status information to PISPs. For list of payment status codes, please refer to sections 10.4 and 10.5

8. Considerations

8.1 Assumptions

• The ASPSP can provide the PISP with status at all stages of a payment after execution for all payment types.

8.2 Dependencies

• There are some dependencies on payment schemes (domestic and international) in relation to making status information available to the ASPSPs and PSUs for certain payment types. Similarly, for international payments, there is dependency on SWIFT for the wider adoption of the GPI standard which will allow a fully traceable payment status for international payments.

8.3 Constraints

• There is dependency on the quantitative research to be performed once statistically significant number and mix of payments, across a representative sample of active PISPs, have been initiated determine whether further actions to enable status provision

9. Measuring Adoption

The following metrics will be required to measure adoption:

1. Number of TPPs making and GET status call and receiving status of payments of all types and various stages using Open Banking
2. Volume of reported pending payments with status ‘Pending’, generated by each payment type
3. Volume of failed payments with status ‘Rejected’, generated by each payment type
4. Volume of accepted payments with status ‘AcceptedSettlementInProcess’, generated by each payment type
5. Volume of successful payments with status “AcceptedSettlementinCompleted” generated by each payment type
6. Volume of successful payments with status “AcceptedCreditSettlementinCompleted”’, generated by each payment type, where applicable.

10. Appendix

10.1 Detailed product requirements

The following 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.

Note: To the extent that any personal data is provided within the context of the proposed statuses, entities must consider their relevant obligations under GDPR.

10.2 Roadmap Item Definition

The roadmap item definition as per the original roadmap is shown below:

10.3 Regulatory references

10.3.1 RTS

Article 36(1)(b) Data exchanges

Account servicing payment service providers shall comply with each of the following requirements:

 (b) they shall, immediately after receipt of the payment order, provide payment initiation service providers with the same information on the initiation and execution of the payment transaction provided or made available to the payment service user when the transaction is initiated directly by the latter;

10.3.2 PSRs

Information required after the initiation of a payment order
44.—(1) Where a payment order is initiated through a payment initiation service provider, immediately after the initiation of the payment order the payment initiation service provider must
provide or make available to the payer and, where applicable, to the payee—
(a) confirmation of the successful initiation of the payment order with the payer’s account servicing payment service provider;

Access to payment accounts for payment initiation services

69.—(1) This regulation applies only in relation to a payment account which is accessible online.

(2) Where a payer gives explicit consent in accordance with regulation 67 (consent and withdrawal of consent) for a payment to be executed through a payment initiation service provider, the payer’s account servicing payment service provider must—

 (b) immediately after receipt of the payment order from the payment initiation service provider, provide or make available to the payment initiation service provider all information on the initiation of the payment transaction and all information accessible to the account servicing payment service provider regarding the execution of the payment transaction;

10.3.2.1 FCA – Approach Document Information on the initiation of the payment transaction (regulation 69(2)(b))

17.29 In our view, the requirement to provide or make available ‘all information on the initiation of the payment transaction and all information accessible to the ASPSP regarding the execution of the payment transaction’ would  include, as a minimum, the information, as specified in regulation 45 of the PSRs 2017, that would be provided or made available to the customer directly if the customer initiated a payment. It would therefore include: 

•  a reference enabling the payer to identify the payment transaction and, where appropriate, information relating to the payee

• the amount of the payment transaction in the currency used in the payment order

• the amount of any charges for the payment transaction payable by the payer (to the payer’s PSP) and, where applicable, a breakdown of the amounts of such charges

• where an exchange rate is used in the payment transaction (by the payer’s PSP) and the actual rate used in the payment transaction differs from the rate provided in accordance with regulation 43(2)(d) of  the PSRs 2017, the  actual rate used or a reference to it, and the amount of the payment transaction after that currency conversion

• the date on which the PSP received the payment order

17.30 Additionally, under regulation 44 of the PSRs 2017,a PISP is required to provide the payer certain additional information after the initiation of the payment order. This includes confirmation of the successful initiation of the payment order with the payer’s ASPSP. It is necessary, therefore, for the ASPSP to provide this confirmation to the PISP,in order for the PISP to provide it to the payer. The ASPSP must also provide any other information on the initiation and execution of the payment transaction that it would otherwise provide directly to the payment service user pursuant to SCA-RTS Article 36(2).

10.4 Proposed List of Payment transaction status codes for OBIE

The  below table lists the payment status codes that OBIE will be looking to include in the OBIE Standards further to discovery and technical specifications process.

10.4.1 Payment Status Model for Domestic Single Payments (Swagger)

10.5 ISO20022 Payment transaction status codes

International standards are used to make industries more efficient and effective and ISO 20022 standard messages are the messages proposed by the International Organization for Standardization (ISO) to develop all financial messages. e.g. for banks, it is mandatory to use ISO 20022 in interbank SEPA communication.

The below list is the complete ISO20022 SWIFT codes and maybe not relevant for your organisation.

10.5.1 Current Payment Status ISO codes set

Tables below extracted from the ISO 20022 External Code Sets spreadsheet – dated 29 November 2018

ExternalPaymentTransactionStatus1Code

10.5.2 Potential future Payment Status ISO codes set

The below link and table include a list of registered and provisionally registered payment status codes indicating the status of a single payment transaction or of a group of payment transactions.

https://www.iso20022.org/standardsrepository/public/wqt/Description/mx/dico/codesets/_Z7RUV9p-Ed-ak6NoX_4Aeg_-481257913

10.5.3 Potential ISO codes extension (Berlin Group Change Request)

Change Request (CR) submitted by the Berlin Group for the addition of  3 codes to the External Payment Transaction Status code set.

PATC: The payment initiation needs multiple authentications, where some but not yet all have been performed. In the case of multi authorisations of a payment initiation in a TPP/bank case, the TPP has to manage complex authorisation models, specifically in a corporate context. The authorisation status of the payment initiation needs to be reported to the TPP after a first successful authorisation, such that the TPP is informed that further authorisations are missing. It is further important for TPPs to see that (at least) the first authorisation has been successful. This will support the expected major case of a multi authorisation in the PSD2 context – a 4 eyes principle – in a very detailed way. This support is expected to heavily reduce operative issues in TPP/bank API processing.

ACFC: Information whether fund checks are automated or not shall not be part of a transaction status, same as whether fund checks are included in customer profile check which varies from agent to agent. Fund checks as such might be complicated as this may include checking of credit lines or bank employees decisions. Fund checks are often part of a later step, i.e. step 7 of chapter 5.1 “Customer to Bank Payment Order” flowchart in “Message Definition Report Part 1” where the debtors account is debited. Fund checks are a possible but not a mandatory step of risk management checks described in step 3.2 of the same document.

CANC: From the viewpoint of the transaction flow the transaction has reached one of the possible endpoints, either settled (with various further information) or rejected. “Cancelled” is a specific aspect of “Rejected” and therefore has to be provided with a StatusReasonCode.

10.6 Payment Systems specific status discussion

OBIE will be looking to publish a page with information about some of the complexities of the UK payment systems (e.g. Faster payments, CHAPS, Bacs etc).