In the case that refunds are to be fulfilled via Open Banking, a refund payment would require the submission of a new payment order (either a single or bulk order) via a PISP to the merchant’s ASPSP, to facilitate the refund back to the purchaser, relating to a previous transaction.
Other pages in this section
The Open Banking Roadmap describes “reverse payments” as an extension of PIS functionality to enable payees (or their PISPs) to refund a payer (customer) where the payee may be a merchant or a service provider.
This proposition paper aims to address refunds of Open Banking PISP initiated payments, which are required as a result of the business/merchant’s commercial relationship with the customer (PSU). In the case that refunds are to be fulfilled via Open Banking, a refund payment would require the submission of a new payment order (either a single or bulk order) via a PISP to the merchant’s ASPSP, to facilitate the refund back to the purchaser, relating to a previous transaction. However, there may be cases where, depending on the model between the merchant/service provider and the PISP, refund payments may be completed via other payment methods or channels, that do not involve Open Banking.
The PSRs do not contemplate a mechanism for the refund or ‘reversal’ of a ‘push’ payment (including PISP-initiated transactions) except for unauthorised, defective, late or non-executed payment transactions, where there are specific requirements to facilitate those refunds. These fall outside the scope of this proposition, which deals with purely PISP related refunds required as a result of the merchant’s commercial relationship with the customer.
The proposition paper will consider the applicable functionality to enable a customer (PSU) to receive a refund amount (full or partial) when a payer and a payee (merchant/service provider) have previously both agreed to a refund and no dispute exists between them. The merchant/service provider is free to use payment methods other than through a PISP to carry out the refund*.
For the initial Roadmap Item Definition, please refer to section 11.3 of the Appendix.
* Please refer to Constraints Section 9.3.
In the UK, refunds happen often and customers expect a seamless refund to be possible when they purchase goods and services. Refunds are particularly prevalent in the fashion / clothing retail industry, where 23% of all purchases are returned (data over 2016). For all eCommerce purchases in the UK, around 75% are made by a debit or credit card, or card-based products such as eWallets.
Retailers have indicated that it is crucial for them that a payment proposition should include seamless refund functionality. As mentioned earlier, non-food retailers frequently require refund functionality. Also, food retailers such as Sainsbury’s, Ocado, Just Eat, etc make adjustments to transactions when they need to swap brands or something is out of stock which can entail a refund. The merchant business case for having seamless refund functionality is evidenced by a return rate of 15% of turnover (average for all online retail categories) totaling almost £8bn. Often, non-card and some eWallet refunds are handled manually and are time consuming. This leads to higher costs for merchants, which is one of the key elements a merchant is looking to reduce.
Card-based payment propositions do offer more seamless refund functionality for merchants, but card based refunds have a problem with lower speed. Card based refunds can take between 2-5 days for the issuing and acquiring bank to settle. This low speed prompts consumers to make complaints to the retailer, as consumers blame the retailer for the cause of the refund not being processed fast enough.
Making refunds is a critical function to make bank transfers in a merchant environment a viable alternative to card based payments. During the OBIE evaluation, many use cases have been identified in conjunction with retailers, SME, PSUs and Third Party Providers (TPPs). For businesses selling online, a priority use case is managing full or partial refunds for goods and services purchased online. Additionally, merchants have said that, to prevent fraud and money laundering, they want to return the payment to the account it came from.
If Open Banking and PISPs could provide a payment proposition, which includes seamless refund functionality, merchants would consider using it and they would recommend that payment proposition to their customers.
TPPs have told us that offering payment initiation services without refund functionality makes it difficult for them to offer payment initiation services to online retailers. Currently, TPPs can offer customers refunds through screen scraping account details. When the RTS SCA came into force in September 2019, the provision of this type of refund functionality was significantly challenged. Additionally, screen scraping is against the vein of Open Banking and would require two tech builds; one to the APIs and one to enable screen scraping which adds complexity to the product. Therefore, it is essential to provide refund functionality within the Open Banking ecosystem.
Additionally, if no refund functionality exists for an OB payment flow, TPPs say they may struggle to sign up eCommerce customers for the reasons mentioned in the merchant section above.
Many ASPSPs also accept that refund functionality is important to their customers and would reduce operational costs, as it could fall to them to help manage the refund process. ASPSPs also consider driving increased revenue from push payments, if businesses decide to use this payment type as a way to refund their customers.
Furthermore, an ‘all-round’ Open Banking based payment proposition could allow ASPSPs to offer an alternative to customers who are currently using eWallets, pre-paid cards, and credit and debit cards, to make eCommerce payments. This could enable ASPSPs to better retain the relationship with their PSUs and could stop payments fragmenting away from their current accounts.
Refunds are important to stakeholders, but the Open Banking payment initiation model does not currently enable the merchants and their PISPs to initiate a refund in all cases. If this were available, TPPs could develop refund functionalities and open up eCommerce market segments where they can offer services. Also, PSUs would consider using the payment propositions more, provided that their security and anti-fraud concerns were addressed. This supports the broader objectives of PSD2, for instance, ensuring that consumers, merchants and businesses enjoy more choice and competition of payment services. We consider that refund functionality will be beneficial to both customers and merchant when using PISP services.
(Source: P7 Final Evaluation Report)
OBIE performed PSU research (via Engine Trinity McQueen) to capture the customers’ views in relation to providing their permission to the PISPs for refunds purposes. Research included 6 focus groups (4 consumer, 2 SMEs) from 2 different locations Some of the areas of the research included:
The key findings from the research are:
OBIE will conduct both primary customer research and secondary market research to identify the existing market offerings and requirements around refund process. In addition, a series of market engagement workshops are being conducted to validate the requirements, especially from the PISP and the merchants perspective. The following high level use cases requiring refund payments capabilities were identified.
The following journeys are currently available in the v3.1.x Standards. They are described in the OBIE CEGs v3.1.3
(using journey Single Domestic Payments – a/c selection @ PISP)
As part of the payment initiation service, the PISP should be able to request and retain the account details from the customer, for a period of time, provided that this is explicitly agreed with the PSU (customer). This will enable the PISP to provide a refund to the PSU, if and when required.
DPPWG conducted a Legitimate Interest Impact Assessment (LIA), which considered different options, which may be available when account selection occurs at the ASPSP. This included an analysis of the different technical options proposed for ASPSPs to provide the account details to the PISP and a legitimate interest assessment in respect of each option. It further considered the ASPSP’s legal basis for sending the customer (PSU’s) account details to the PISP and the relevant criteria related to “legitimate interest, as contemplated in GDPR,f Art. 6(1)(f) –“processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child.”
The options below illustrate two of the possible alternatives that were considered during this process.
The ASPSP returns the PSU debit account information with each PISP initiated transaction. This happens only in cases where the PISP indicates that the PSU has consented to the PISP requesting their debit account details from the ASPSP. We will also refer to this solution as Synchronous Refund Information.
Based on the support Option A has received and the perceived lower implementation effort, it is recommended that this functionality should be included in the OB Standard for Dec-19. If any option is to be mandated for the CMA9, it should be Option A with implementation completed six months from the publishing date of the Standard.
Option (C) was not in the list of options considered initially by DPPWG. It was added later to offer an additional enhancement compared to the previous options, by preventing the PSU account details from being shared with the PISP. The option is using an ID (i.e. Merchant Order ID) generated by the Merchant/Service Provider which is populating the payment reference field (18 characters) when the PISP is initiating the payment order from the PSU’s account to the Merchant/Service Provider’s account. This payment reference will travel via the payment rails to the merchant/service provider’s ASPSP. (see 5.2 1 below).
When a refund is requested, the Merchant/Service Provider will supply the Merchant Order ID to the PISP together with the request for refund and the refund amount. The PISP will prepare the refund payment initiation order, providing the details of the Merchant debit account, the amount, the Order ID and some additional information (such as the date and the amount of the original transaction). This information will effectively serve as a payment order (with the Merchant Order ID acting as a proxy for the payee details) , which will enable the Merchant ASPSP to search their payment records and identify the original payment, which contains the details of the PSU’s debit account. Thus, the Merchant ASPSP has all the information to proceed with the processing the refund payment, once confirmed by the Merchant (see 5.2 3 below).
Alternatively, the most likely scenario is that the PISP will be collecting multiple refund requests and compiling this into a file, so that it submits a file of refund payments instead of single refund payments. This is particularly useful when a business requires to send more than a few refunds a day as part of their business model (see 5.2 4 below).
In 2020, OBIE will evaluate how well Option A is performing and consider whether there is still a need to develop Option C further.
The fulfillment of the refund payment itself can be achieved using a number of different models and depends on a number of options, including the business model and the contractual agreement between the merchant/service provider and the PISP, their systems capabilities and the way they integrate together. In addition to existing or new business processes at the merchant/service provider’s side.
The Open Banking Standards are aimed at supporting the communication between PISPs and ASPSPs, but they do not define the parameters of the relationship and the mechanisms used between the merchant/service provider and the PISP, in relation to refunds. However, as part of the industry research OBIE was conducting for the purpose of refund payments, we have included models that are being considered within the industry today. These models reflected below are intended to be illustrative only. Entities wishing to engage in these types of models will need to ensure that they have appropriate regulatory permissions and meet applicable regulatory obligations.
There are cases where merchants/service providers (especially large corporate organisations) receive information services files from their servicing ASPSPs, which include details of payments in and out of their bank accounts. These details very often include the payment account details of the payers of incoming payments and in certain cases, they are also supported by the Open Banking Read APIs. In these models, the merchants/service providers already have the PSU bank account details and when a PSU requests a refund payment, merchants/service providers can fulfill the refund request by using any existing payment channels (e.g. their business online banking, host-to-host payment solutions, batch file processing, direct submission etc). They do not have to use an Open Banking channel or a PISP for sending the refund payments.
OBIE industry research shows that, there are models in the industry where organisations holding multiple licenses have contractual agreements to offer “merchant account” services, similar to the acquirers’ in the card payments model, holding incoming payment funds on behalf of the merchant/service provider. These organisations also provide reconciliation and settlement services with the merchants for their receivables on regular intervals (e.g. daily or every few days).
In these models, when a refund is requested by the PSU to the merchant/service provider, and the multi-licensed organisation receives the refund request from the merchant/service provider, the multi-licensed organisation will search its records for the original PIS transaction and identify the PSU’s account details. It will then be able to initiate the refund payment from the funds holding account to the PSU using existing payment channels (such as business online banking, host-to-host payment solutions, batch file processing, direct submission etc). In the cases where the multi-licensed organisation does not have the PSU’s account details (i.e. the PSU selected their debit account at the ASPSP in the original PIS payment), then they can use Option (A) mentioned above to acquire the PSU’s account details for the purpose of refund.
Details of the model will be covered under the contractual agreement between the multi-licensed organisation and the merchant/service provider. Please note that this model assumes the original payment to the merchant was initiated from the PSU’s account by the same multi-licensed organisation as the one requested to process the refund payment.
OBIE industry research also shows that, as a variation of 5.4.2, the organisation holding multiple licenses, including a license which enables an organisation to hold funds, may have a contractual agreement to offer “refund account” services to merchants/service providers, by providing or holding specific funds to be solely used for the purposes of refunds. When requested by the merchant/service provider, the multi-licensed organisation will be initiating the refund payments from the refunds account using existing payment channels (such as business online banking, host-to-host payment solutions, batch file processing, direct submission etc). Finally, the multi-licensed organisation will be settling with the merchant/service provider as would be described in the contractual agreement with them. As above, the multi-licensed organisation could use option (A) to receive the PSU’s account details, provided that the original payment to the merchant was initiated from the PSU’s account by this organisation.
Participants engaging in the models described in Examples 2 and 3 will need to ensure they meet relevant regulatory obligations specifically relating to the services they are providing.
Option (A) provides solution to the information gap of the missing PSU’s account details necessary for the PISP to initiate refund payments back to the PSU. These can then be combined with Open Banking Payments Initiation API calls to send the refund payment from the merchant/service provider’s ASPSP account to the PSU’s account. Two main options exists:
Option (C) will entail modifying the Single Immediate and File Payment APIs to create a refund payments version of these, where the PISP will be able to provide the Merchant Oder ID and the rest of the parameters mentioned in section 5.2.3 above, to allow the initiation of the refunds payments from the merchant/service provider’s account. Once again, it is anticipated that the merchant’s ASPSP will apply SCA for all the above payments to refund the customer, unless the ASPSP applies an available exemption. Similarly, any multi-auth process flow implications will also apply, making these refund payments appropriate only from small or medium size organisations and limited to business models which do not require large number of refund payments as BAU.
Further details of these models are shown in the Appendix, section 11.2
Larger organisations/corporates, in many cases use host-to-host payments solutions, offered by their ASPSPs, in order to submit payments directly to their bank. These solutions are primarily designed for unattended processing (using end-to-end automation via server-to-server connection with very little or none human interaction) in order to increase Straight Through Processing (STP). This functionality can be combined with using either options (A)/(B) to obtain the PSU account details (if not known by the PISP licensed organisation) or alternatively in a more secure end-to-end solution with option (C) by the PISP licensed organisation to submit payment instructions with the Merchant Oder ID instead of the PSU’s account details to the merchant/service provider ASPSP. Details of the model will need be considered in the context of the contractual agreement(s) amongst the PISP licensed organisation, the merchant/service provider and the ASPSP of merchant/service provider, and appropriate consideration to the relevant regulatory obligations under the PSRs.
In this model, using contractual agreements, the requirement of SCA is performed by the PISP licensed organisation on behalf of the merchant/service provider’s ASPSP. The PISP and the merchant/service provider’s ASPSP undergo a setup process, where a unique ID identifying the merchant/service provider’s terminal (or server) is encrypted and associated with the merchant/service provider’s credentials at the ASPSP. This is designed to support the first factor of SCA (possession). The PISP will also attest to the merchant/service provider’s ASPSP, that the merchant PSU has logged in using a second factor of authentication (this could be a knowledge factor such as username/password or a biometric). This would allow any authenticated merchant/service provider PSU, using an authenticated terminal (Trusted platform) to initiate a refund payment using the PISP service without performing any additional SCA at the merchant/service provider ASPSP. Details of the model will be covered under the contractual agreement between the PISP, merchant/service provider and the ASPSP of merchant/service provider. More details on this option would be covered under the standards technical design process.
Note: As refunds are expected to be fulfilled with new payments to the PSUs’ debit accounts with the same payment reference, initiating a partial refunds is simply using a different amount for the payment. If multiple partial refunds are to be initiated at different points in time, then it is in the responsibility of the Merchant to reconcile these so that they much their total payment amounts or not.
ASPSPs and TPPs will need to consider their obligations under PSD2 and GDPR, where applicable.
In the context of processing of personal data i.e. the sort code and account number, both the PISP and the ASPSP must ensure a valid basis for processing. While we note that GDPR obligations are for each data controller to determine based on their individual requirements, we would consider that for the PISP in particular, they could consider the basis below, as applicable. We note for PISP’s relying of consent for the processing of this data, consideration must be given to an appropriate revocation mechanism.
GPPR, Article 6
(a) the data subject has given consent to the processing of his or her personal data for one or more specific purposes;
(b) processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract;
(f) processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data…”
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 this proposition needs to support the following high-level requirements:
For detailed list of Product Requirements, please refer to section 11.1 of the Appendix.
(*) Note: BT/MTs accounts are excluded of this functionality.
There is appetite from ASPSPs to implement functionality to allow PISP initiated payments to be refunded back to the PSU when no dispute between the merchant and the PSU is in place. Enabling refunds capability for all cases of PISP initiated payments will increase the adoption of Open Banking PIS services by merchants, especially for the eCommerce use cases.
Implementation for CMA9 may be required in order to meet the objectives of the CMA Order, subject to further clarification from the Implementation Trustee on rationale and timing.
The following metrics will be required to measure adoption:
These are stated as requirements of the OBIE solution to enable support for key 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.
Conditional (*): Implementation may be required in order to meet the objectives of the CMA Order, subject to further consideration.
OBIE is performing industry research for the purpose of refund payments. Some of the potential PISP/Merchant models that can be implemented for refunds are shown below. The list is not exhaustive and also merchants and PISP need to consider their legal/regulatory obligations in relation to these:
PSR – 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—
(a) communicate securely with the payment initiation service provider in accordance with the regulatory technical standards adopted under Article 98 of the payment services directive;
(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;
(c) treat the payment order in the same way as a payment order received directly from the payer, in particular in terms of timing, priority or charges, unless the account servicing payment service provider has objective reasons for treating the payment order differently;
(d) not require the payment initiation service provider to enter into a contract before complying with the preceding sub-paragraphs.
(3) A payment initiation service provider must—
(a) not hold a payer’s funds in connection with the provision of the payment initiation service at any time;
(b) ensure that a payer’s personalised security credentials are—
(i) not accessible to other parties, with the exception of the issuer of the credentials; and
(ii) transmitted through safe and efficient channels;
(c) ensure that any other information about a payer is not provided to any person except a payee, and is provided to the payee only with the payer’s explicit consent;
(d) each time it initiates a payment order, identify itself to the account servicing payment service provider and communicate with the account servicing payment service provider, the payer and the payee in a secure way in accordance with the regulatory technical standards adopted under Article 98 of the payment services directive;
(e) not store sensitive payment data of the payment service user;
(f) not request any information from a payer except information required to provide the payment initiation service;
(g) not use, access or store any information for any purpose except for the provision of a payment initiation service explicitly requested by a payer;
(h) not change the amount, the payee or any other feature of a transaction notified to it by the payer.
FCA Approach Document
17.68 The PSRs 2017 do not prohibit PISPs from using and storing the payment service user’s account number and sort code for the purpose of providing a payment initiation service, with the customer’s explicit consent.
PSD2 pre read (31)When exclusively providing payment initiation services, the payment initiation service provider does not at any stage of the payment chain hold the user’s funds. When a payment initiation service provider intends to provide payment services in relation to which it holds user funds, it should obtain full authorisation for those services
The ASPSP returns the PSU debit account information only when it is explicitly requested by a PISP, after the PSU has requested a refund, on case by case basis. We will also refer to this solution as Asynchronous Refund Information.