Proposition P9 - Status of payment

1. Version Control 

VersionDateAuthorsComments
V0.1

 

OBIE API Delivery TeamDraft for internal review
V0.2 OBIE API Delivery TeamDraft version for standards workshop
V0.3 OBIE API Delivery TeamUpdated version for publishing for industry consultation
V0.4 OBIE API Delivery TeamUpdated version with feedback from industry consultation
V1.0 OBIE API Delivery Team

Updated version with feedback from industry consultation

Submitted for approval at IESG

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


Total rejectionsRate

Rejections until execution

Rate

Rejections during execution Rate
Volume47,681,083100%45,151,08394.69%2,530,0005.31% 
Value£23,344,272,506100%£22,127,272,50694.79%£1,217,000,000 5.21%

Source: /wiki/spaces/EWGB/pages/593200842

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. 

ID
Use CaseMet*
Personal Customers
UC1

Person to person (P2P) payment (move money)

As a customer, using a personal finance manager to manage multiple accounts across multiple providers, when moving money between my accounts,

I want assurance that the payment I have initiated through a PISP is executed,

so that I do not go overdrawn and pay overdraft fees

Fully
UC2Person to business payment (pay monthly bill)

As a customer, using a personal finance manager to manage my finances,

I want assurance that my standing order payment (SO) I set-up to pay my bill has been made,

so that I don’t get charged additional fees for late payment.

 Fully
UC3

Person to business payment (pay invoice)

As a customer, using a personal finance manager to manage my finances,

I want assurance that my future dated payment (FDP) I set-up to pay an invoice has been made,

so that I don’t get charged additional fees for late payment.

 Fully
UC4Person to business (pay a bill)

As a customer, using a personal finance manager to manage my finances,

I want assurance that the payment I make to my credit card is successful,

so that I don’t get charged additional fees for late payment.

Fully
UC5Person to business (pay a bill)

As a customer, using a personal finance manager app instead of my banks online channel to manage my finances,

I want assurance that the house deposit payment I am making to my solicitor is successful,

so that I can complete my house purchase and move in.

Fully
UC6Person to business (savings)

As a customer, using a personal finance manager to manage my finances, I am making payments to my ISA, which is managed by a third part FI and

I want assurance that the funds have been received by the third party FI,

so that I am not losing any benefits offered by my ISA account. 

Fully
UC7Person to business (investing)

As an investor,

I need to know if my time-critical payment order to invest in shares has been received by the receiving FI or has been rejected,

so that I ensure buying the shares for the agreed price.

Fully
UC8Lending

As a lender,

I want to know if the borrower's payment initiated via my PISP has been successful,

so that I can stop charging daily interest

Fully
UC9E-commerce

As a merchant,

I want to know if the customer's payment initiated via my PISP has been successful,

so that I can release the goods / services that were purchased

Fully
UC10E-commerce

As a merchant,

I want to know immediately if the payment the payer initiatedvia my PISP has been rejected,

so that I can offer the payer alternative form of payment

Fully
Business Customers
UC11Company to company payment

As a business, using my cash flow / accountancy tool to manage my business finances,

I want assurance that a payment I have initiated to pay a supplier invoice is successful,

so that I get the benefit of the early payment discount.

Fully
UC12Company to company payment

As a Treasurer of a travel insurance provider, who I regularly initiate international payments either via the ASPSP direct channels or using our ERP/Treasury platform, directly connected to a PISP (operating as a bureau),

I want to track the status of my payments via my multi-bank (smartphone) app, supplied by a different TPP / PISP / AISP,

so that I am able to view through my app the equivalent level of detail regarding the status of my payments as via the ASPSP direct channel.

Fully
UC13Company to company payment (pay invoice)

As a business, using my cash flow / accountancy tool to manage my business finances,

I want assurance that my future dated payment I set-up to pay an invoice has been made,

so that I don’t get charged additional fees for late payment.

Fully
UC14Company to company multi-authorisation payment (pay invoice)

As a business, using my cash flow / accountancy tool to manage my business finances,

I want assurance that my multi-authorised payment I set-up to pay an invoice has been fully authorised and made,

so that I don’t get charged additional fees for late payment.

 Fully
* 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.

ID

Description

MoSCow

Rationale

Regulatory AlignmentImplementation
1

The OBIE Solution(s) must allow the PISP to query the ASPSP for the status of a payment of any payment type at multiple points in time in the payment life cycle, subject to fair usage policies.

Note 1: It is the responsibility of each ASPSP to define a fair usage policy to control potential high volumes of status requests. OBIE Standards cannot define any limits to these status requests.

Note 2: There may be timing constraints in terms of how long the payment status would remain available for the PISPs after the execution date, especially for non recurring payments. This may be aligned to the duration the status is currently available in the ASPSP's online channel, if available there. The details of this requirement and the implications to the implementation will be considered during the detailed design.  

MCustomer RequirementN/AOptional
2The OBIE Solution(s) must allow the PISP to query the ASPSP for the status of the Scheduled Domestic, Scheduled International, Domestic Standing Order and International Standing Order resources (not the payments generated by them) in order to identify when these have been cancelled by PSUs or any other changes in their status took place that PISPs need to be aware.MCustomer RequirementN/AOptional

3

The OBIE Solution(s) must allow the PISP to query the ASPSP for the processing status of a Domestic Scheduled Payment after the initial set-up of the payment (in addition to the status of the payment initiation currently implemented).

Note 1: Future Dated payments that 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 needs to be considered during the design of the OBIE standards for this requirement.

Note 2: Domestic Future Dated payments are processed in the UK using the Faster Payments Scheme as asynchronous payments. This has some additional implications in relation to the payment status of these payment types and need to be considered during the design of the OBIE standards for this requirement.

M

Customer Requirement

N/AOptional
4

The OBIE Solution(s) must allow the PISP to query the ASPSP for the processing status of each payment under a successfully submitted and setup Domestic Standing Order, after the initial SO set-up.

Note 1: Standing Order payments that 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 needs to be considered during the design of the OBIE standards for this requirement.

Note 2: Domestic Standing Order payments are processed in the UK using the Faster Payments Scheme as asynchronous payments. This has some additional implications in relation to the payment status of these payment types and need to be considered during the design of the OBIE standards for this requirement.

MCustomer RequirementN/AOptional
5

The OBIE Solution(s) must allow the PISP to query the ASPSP for the processing status of an International Scheduled Payment, after the initial set-up of the payment (in addition to the status of the payment initiation currently implemented).

MCustomer RequirementN/AOptional
6

The OBIE Solution(s) must allow the PISP to query the ASPSP for the processing status of each payment under a successfully submitted and setup International Standing Order, after the initial SO set-up.

MCustomer RequirementN/AOptional
7

The OBIE Solution(s) must allow the PISP to query the ASPSP for the processing status of each payment under a successfully submitted File of Payments, after the initial submission the payment file.

MCustomer RequirementN/AOptional
8

The OBIE Solution(s) must allow the PISP to query for the processing status of all supported payment types whether they have been approved by single or multiple authorisation process.

M


Customer RequirementN/AOptional
9The OBIE Solution(s) must allow ASPSPs to respond to GET payment order status requests, as a minimum, with any of the following status messages: “Rejected”, “Pending”, “AcceptedSettlementInProcess” or “AcceptedSettlementCompleted" at any point in time during the payment initiation, processing and execution of payments of all payment types initiated via a PISP.MCustomer RequirementN/AOptional
10The OBIE Solution(s) must allow ASPSP to respond by sending a status “AcceptedCreditSettlementCompleted" (ISO code ACCC) when the Payee account has been credited with the funds of the payment initiated via the PISP.MCustomer RequirementN/AOptional
11

The OBIE Solution(s) must allow ASPSPs to provide more granular payment status information during initiation, processing and execution as per the ISO20022 Payment transaction status codes, extending the existing list of payment status information. For list of proposed status codes, please refer to section 10.4

MCustomer RequirementN/AOptional
12

The OBIE Standards must be flexible to be further updated and enriched with additional optional payment status information as per published or provisionally published ISO 200022 codes and/or proposed status codes by other standards bodies. For list of example additional payment status codes, please refer to section 10.5

MCustomer RequirementN/AOptional
13

The OBIE Solution(s) must allow the ASPSP to return to the PISP, after payment initiation, in addition to the OBIE payment status,other payment systems specific status codes (e.g. Faster Payments Qualified and Unqualified Accept) and payment rejection reasons codes. 

MCustomer RequirementN/AOptional
14The OBIE's Solution(s) must allow ASPSPs to provide MI on metrics and adoption as per section 9 above.MRegulatory

CMA Order Schedule 1, Article 2(j) & The Trustee letter of 10th July 2018 to the CMA, section 2.1.6

Mandatory (if option is implemented)

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:

P9 - Payment Status



Description

Rational

Aligns with

Scope Item description:

  • Extension of write (PIS) functionality of the OB R/W APIs to enable ASPSPs to communicate payment statuses to TPPs

Key activities:

  • An evaluation phase by the OBIE to assess whether the functionality referred to above should be developed as a standard. Evaluation criteria are likely to include 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 3

Open Banking adoption:

  • Extends functionality of OB Standards for payments use cases and thereby delivers greater utility for TPPs

Consumer / SME utility:

  • Consumers would be able to execute payments with confidence. This solution has the potential to support the multi-auth solution P13

Security / Integrity:

  • Consumers would be able to execute payments conveniently without putting cards on file

CMA Order

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.

IDEquivalent ISO CodeNameDescriptionStatusScope / Notes
1RCVDReceivedPayment initiation has been received by the receiving agent.NEWAll payment types
2RJCTRejectedPayment initiation or individual transaction included in the payment initiation has been rejected.ExistingAll payment types
3PDNGPendingPayment initiation or individual transaction included in the payment initiation is pending. Further checks and status update will be performed.ExistingAll payment types
4ACTCAcceptedTechnicalValidationAuthentication and syntactical and semantical validation are successfulNEWAll payment types
5ACCPAcceptedCustomerProfilePreceding check of technical validation was successful. Customer profile check was also successful.NEWAll payment types
6ACWCAcceptedWithChangeInstruction is accepted but a change will be made, such as date or remittance not sent.NEWMost applicable to future dated payments, International payments, recurring payments etc
7ACSPAcceptedSettlementInProcessAll preceding checks such as technical validation and customer profile were successful and therefore the payment initiation has been accepted for execution.ExistingAll payment types
8ACSCAcceptedSettlementCompletedSettlement on the debtor's account has been completed. ExistingAll payment types
9ACWPAcceptedWithoutPostingPayment instruction included in the credit transfer is accepted without being posted to the creditor customer’s account.NEWAll payment types
10ACCC

AcceptedSettlementCompleted.

New Name: AcceptedCreditSettlementCompleted

Settlement on the creditor's account has been completed.NEWAll payment types
11PARTPartiallyAcceptedA number of transactions have been accepted, whereas another number of transactions have not yet achieved 'accepted' status.NEWFile level status, applicable for file payments
12CNCLPaymentCancelledPSU has cancelled the scheduled payment consent or the processing of the paymentNEWScheduled payment types

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

Equivalent ISO Code

Name

Definition

ACCC

AcceptedSettlementCompleted

Settlement on the creditor's account has been completed.

ACCP

AcceptedCustomerProfile

Preceding check of technical validation was successful. Customer profile check was also successful.

ACSC

AcceptedSettlementCompleted

Settlement on the debtor's account has been completed.
Usage : this can be used by the first agent to report to the debtor that the transaction has been completed.
Warning : this status is provided for transaction status reasons, not for financial information. It can only be used after bilateral agreement

ACSP

AcceptedSettlementInProcess

All preceding checks such as technical validation and customer profile were successful and therefore the payment initiation has been accepted for execution.

ACTC

AcceptedTechnicalValidation

Authentication and syntactical and semantical validation are successful

ACWC

AcceptedWithChange

Instruction is accepted but a change will be made, such as date or remittance not sent.

ACWP

AcceptedWithoutPosting

Payment instruction included in the credit transfer is accepted without being posted to the creditor customer’s account.

PDNG

Pending

Payment initiation or individual transaction included in the payment initiation is pending. Further checks and status update will be performed.

RCVD

Received

Payment initiation has been received by the receiving agent.

RJCT

Rejected

Payment initiation or individual transaction included in the payment initiation has been rejected.

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

Equivalent ISO CodeName
ACTCAcceptedTechnicalValidation
RCVDReceived
PARTPartiallyAccepted
RJCTRejected
PDNGPending
ACCPAcceptedCustomerProfile
ACSPAcceptedSettlementInProcess
ACSCAcceptedSettlementCompleted
ACPTAccepted
ACCRAcceptedCancellationRequest
RJCRRejectedCancellationRequest
ACWCAcceptedWithChange
PACRPartiallyAcceptedCancellationRequest
PDCRPendingCancellationRequest
ACCCAcceptedCreditSettlementCompleted
CNCLPaymentCancelled
NULLNoCancellationProcess

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.

Code

Name

Description

PATC

PartiallyAcceptedTechnicalCorrect

The payment initiation needs multiple authentications, where some but not yet all have been performed. Syntactical and semantical validations are successful.

ACFC

AcceptedFundsChecked

Preceding check of technical validation and customer profile was successful and an automatic funds check was positive.

CANC

Cancelled

Payment initiation has been successfully cancelled after having received a request for cancellation.

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).