...

...

5. Fulfilment of Refund Payments

5.1 Fulfilment Models

Fulfilment of refund payments 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 TPP, their systems' capabilities and the way they are integrated.  In addition, refund fulfilement can be implemented using existing or new business processes at the merchant/service provider’s side.

The CBUAE Open Financen Finance Standards aim to support the communication between TPPs and LFIs, but they do not intend to define the parameters of the relationship and the mechanisms used between the merchants/service providers and TPPs, in relation to refunds. However, we have summarized below models that are being considered within the industry worldwide. These models are intended to be for illustrative purposes 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. 

The following are some potential models for refund fulfilment:

• Model 1: Merchants/Service Providers receive User original payment account details from their LFIs

  There are cases where merchants/service providers, especially large corporate organisations, receive information services files from their servicing LFIs, 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. In these cases, the merchants/service providers already have the User original payment account details and when a User requests a refund payment, merchants/service providers can fulfill the refund request by using any existing payment channels (e.g. their business

  A: Multi-licensed TPPs Services: TPPs holding the multiple licenses (such as authorized Payment Institutions), including license which enables them to hold funds, can offer Refund Services to Merchants/Service Providers. Industry research identifies 2 different potential options for this model:

  • Option 1: Multi-licensed TPPs offer “merchant accounts” to Merchants/Service Providers

    • There are worldwide industry models where TPPs holding multiple licenses (such as authorized Payment Institutions) have contractual agreements to offer “merchant account” services, similar to the acquirers’ model in card payments, holding incoming payment funds on behalf of the merchants/service providers. These TPPs also provide reconciliation and settlement services with the merchants for their receivables on regular intervals (e.g. daily or every few days). In these cases, when a refund is requested by the User to the merchant/service provider, and the multi-licensed TPP receives the refund request from the merchant/service provider, the TPP will search its records for the original Open Finance Service Initiation transaction and identify the User’s account details. It will then be able to initiate the refund payment from the funds holding account of the merchant/service provider to the User as a credit transfer using existing payment channels (such as business online banking, host-to-host payment solutions, batch

    /bulk

    • file processing etc).

    These merchants/service providers do not require the Asynchronous Refunds Information functionality to support refund payment fulfilment as they already have the required refund information.

• Model 2: TPPs acting as Payment Institutions offer “merchant accounts” to Merchants/Service Providers

  • There are worldwide industry models where organisations holding multiple licenses (such as authorized Payment Institutions) have contractual agreements to offer “merchant account” services, similar to the acquirers’ model in card payments, holding incoming payment funds on behalf of the merchants/service providers. 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 cases, when a refund is requested by the User to the merchant/service provider, and the multi-licensed organisation receives the refund request from the merchant/service provider, the organisation will search its records for the original Open Finance Service Initiation transaction and identify the User’s account details. It will then be able to initiate the refund payment from the funds holding account of the merchant/service provider to the User using existing payment channels (such as business online banking, host-to-host payment solutions, batch file processing etc). In circumstances where the multi-licensed organisation does not have the User’s original account details (such as when the User selected their debit account at the LFI during the original Bank Service Initiation payment), the organisations can use the Asynchronous Refund Information capability mentioned above to acquire the User’s original payment account details for the purpose of refund. The details of the models will be covered under the contractual agreements between the multi-licensed organisations and the merchants/service providers. Please note that this model assumes that the original payment to the merchant/service provider was initiated from the User’s original payment account by the same multi-licensed organisation as the one requested to process the refund payment.  

• Model 3: TPPs acting as Payment Institutions offer “refunds accounts” to Merchants/Service Providers

  • Worldwide industry research also identifies 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 the Synchronous Refund Information 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.

• Example 4: Use of Open Financen APIs to initiate refund payments from the merchant/service provider’s LFI account

• Example 5: Use of the Merchant/Service Provider’s LFI host-to-host solution – (Under consideration)

• Example 6: Use of ‘assisted’/’shared’ SCA model for Refund Payments – (Under consideration)

...

• • • In circumstances where the multi-licensed TPP does not have the User’s original account details (such as when the User selected their debit account at the LFI during the original Bank Service Initiation payment), the organisations can use the Asynchronous Refund Information capability mentioned above to acquire the User’s original payment account details for the purpose of refund. The details of the model will be covered under the contractual agreements between the multi-licensed TPPs and the merchants/service providers. Please note that this model assumes that the original payment to the merchant/service provider was initiated from the User’s original payment account by the same multi-licensed TPP as the one requested to process the refund payment.  

  • Option 2: Multi-licensed TPPs offer “refunds accounts” to Merchants/Service Providers

    • Worldwide industry research also identifies a variation of Opton 1, where TPPs holding the multiple licenses (such as authorized Payment Institutions), including license which enables them to hold funds, may have contractual agreements to offer “refund account” services to merchants/service providers. These refund services involve providing or holding specific funds to be solely used for the purposes of refunds. When requested by merchants/service providers, the multi-licensed TPPs will be initiating refund payments from these refunds accounts using existing payment channels (such as business online banking, host-to-host payment solutions, batch file processing etc). Finally, the multi-licensed TPPs will be settling with the merchants/service providers as would be described in the contractual agreement between them. As above, the multi-licensed TPPs may use the Asynchronous Refund Information capabilityto receive the Users' original payment account details, provided that the original payments to the merchants/service providers were initiated from the Users' payment accounts by the multi-licensed TPP.

• Model B: Use of Open Finance APIs to initiate credit transfers as refund payments from the merchant/service provider’s LFI account: TheAsynchronous Refund Information capability provides solution to the information gap of the missing Users' original payment account details necessary for merchants/service providers and TPPs to initiate refund payments back to the Users. This can then be used in conjunction with other Open Finance Bank Service Initiation APIs to initiate credit transfers as refund payments from the merchants/service providers' LFI accounts to the Users' accounts. The following options exist:

  • Option 1: Single Instant Payments API:

    • This can be used to send a single credit transfer as a refund payment to a User. Please note that, that the merchant/service provider’s LFI will apply MFA for these refund payments to customers (unless the LFI decides to apply an exemption). An additional implication is that there may be a multi-authorization process flow implemented at the LFI for the merchant/service provider’s account since it is a business/corporate account. Therefore, this option is only expected to be acceptable in cases of very small businesses/startups that will have a small volume of refund payments to process during each day.

  • Option 2: Bulk and Batch Payments API

    • This can be used to send multiple credit transfers as refund payments to a number of Users. The refund requests will be processed as a batch and will be submitted to the merchant/service provider’s LFI in a single file. Please note that, similarly to Option 1 above, the merchant/service provider’s LFI will apply MFA for the file of refund payments customers (unless the LFI decides to apply an exemption). However, submitting the refund payments in a file reduces the ‘call to action’ required by the merchant/service provider Users to initiate the refund payments. In addition, the same implications with the multi-authorization process flow apply for the Bulk and Batch Payments.

  • Option 3:Payments with Delegated Authentication/VRP Multi-Payments to Variable Beneficiaries APIs

    • This can be used to allow any authenticated merchant/service provider User, to initiate a credit transfer as a refund payment using the TPP without performing any additional MFA with the merchant/service provider’s LFI. This is the most flexible mechanism to facilitate refund payments by initiating new credit transfers and it suitable for most types and sizes of merchant/service provider organisations. Details of these models can be found in https://openfinanceuae.atlassian.net/wiki/x/GIotB and https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70092119/Multi-Payments#1.5-Multi-Payments-to-Variable-Beneficiaries.

• Model C: Alternatives

  • Merchants/Service Providers receive User original payment account details from their LFIs

    • There are cases where merchants/service providers, especially large corporate organisations, receive information services files from their servicing LFIs, 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. In these cases, the merchants/service providers already have the User original payment account details and when a User 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/bulk file processing etc). These merchants/service providers do not require the Asynchronous Refunds Information functionality to support refund payment fulfilment as they already have the required refund information.

5.2 Fulfilment Rules for TPPs

5.2.1 Partial Refunds

As refunds are expected to be fulfilled with new payments to the Users' original payment accounts with the same payment reference, initiating a partial refund 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.

5.2.2 Refund Payment Reference