Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

1. Description

This bank service request enables original payees (or their TPPs ) to refund a payer (i.e. User), where the original payee is a merchant receiving payments for purchase of goods/services. The functionality relates to refunds of Open Finance TPP initiated payments, which are required as a result of the merchants' commercial relationship with the customer (i.e. User). Refunds are to be fulfilled via Open Finance, and a refund payment would require the submission of a refund payment request via the merchant's TPP to the merchant's LFI, to facilitate the refund back to the payer (i.e. User) of the original transaction.

The Refund bank service request deals purely with TPP related refunds based on the merchant - customer commercial relationship and does not cover refunds for unauthorized, defective, late or non-executed payment transactions. Moreover, the Refund service request provides the applicable functionality to enable a payer (i.e. User) to receive a refund amount (full or partial) when both payer and a payee (merchant) have agreed the refund and no dispute exists between them.

The Refund scope is targeted to domestic payee accounts (i.e. payee accounts offered by LFIs located in UAE) and payments in local currency as used by the local payment systems infrastructure for domestic payments.

This user journey requires a Single Use Consent of type Single Refund Consent.

1.1 Payer and Payee Segments

The scope of the Refund bank service initiation related to the segments of payers and payees is shown below:

...

Payer (Merchant)

...

Payee (Customer)

...

Consumers

...

SME

...

Corporates

...

Consumers

...

SME

...

Corporates

...

(error)

...

(tick)

...

(tick)

...

(tick)

...

(tick)

...

(tick)

1.2 Refund - Example User Story

Panel
panelIconId0cd1bba7-8f00-45e4-bfea-96eab8c2d5f8
panelIcon:dsfa:
panelIconText:dsfa:
bgColor#E6FCFF

User Story

As a User (Business or Corporate),

I want to be able to initiate a partial or full refund of payment received via an Open Finance,

so that I can fulfil the requirement to refund customers in case of returns and undisputed complaints for goods or services.

2. User Journey

2.1 Journey Summary

The User buys goods or services from the merchant. Within the agreed period of time and under the terms & conditions, the User requests a refund for goods or services previously purchased. Both agree to a refund and no dispute exists between them (refund as BAU process). The merchant’s TPP initiates a refund payment from the merchant's LFI account with the merchant's consent using the original Transaction ID. This is a return payment order to the PASP..

...

In cases where the PSU selects their account at the ASPSP as shown in the journey Single Domestic Payments – a/c selection @ ASPSP, the PISP may not be able to obtain the PSU’s account details (sort code and account number) from the PSU directly within their consent journey. This could create challenges for the PISP if the PSU requests a refund for the transaction at a later stage. Accordingly, the PISP would need to obtain these details from either from the PSU, the merchant/service provider or the PSU’s ASPSP in order to provide a refund, if requested.  

This information gap is solved by modifying the original payment journey Single Domestic Payments – a/c selection @ ASPSP  as shown above, which is referred to as Synchronous Refund Information. 

During the consent journey, when the PSU provides their explicit consent to the PISP for initiating a payment order; the PSU would simultaneously provide their permission for the PISP to request their account details (for example sort code and account number for domestic payments) from their ASPSP for the purposes of providing a future refund. This consent is included as a flag within the payload which is submitted to the ASPSP as part of the payment initiation request. The ASPSP then returns the payment details to the PISP for each transaction. 

3. Wireframes

3.1 Rules & Guidelines

...

#

...

Step

...

Rules & Guidelines

...

SIP-1

...

Single Instant Payment Consent

Basic Consent Parameters

TPPs MUST:

1.1 Enable Users to provide and review the parameters related to the SIP they need to consent to. These parameters include:

...

User Payment Account or User LFI (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70092902/Common+Rules+and+Guidelines#2.-User-Payment-Account-Selection).

...

Payment Amount & Currency (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70092902/Common+Rules+and+Guidelines#3.-Payment-Amount-%26-Currency).

...

1. Description

This bank service functionality enables original payees (or their TPPs) to refund payers (i.e. Users), where the original payees are merchants receiving payments for purchase of goods/services. The Refund capability relates to Open Finance TPP initiated payments, and is required as a result of the merchants' commercial relationships with customer (i.e. Users). The Open Finance Refunds functionality does not cover payment refunds for unauthorized, defective, late or non-executed payment transactions. Instead, it enables merchants (or their TPPs) to refund payers (i.e. Users) with the payment amounts (full or partial) when both payer and a payee (merchant) have agreed the refund and no dispute exists between them.

The Refunds scope is targeted to domestic payee accounts (i.e. payee accounts offered by LFIs located in UAE) and payments in local currency as used by the local payment systems infrastructure for domestic payments.

The Refunds capabilty allows merchants (or their TPPs) to acquire the payers' bank account details used to make the original payment. The Refund is then fullfiled by the merchants (or their TPPs) using any of their preferred or existing BAU payment methods.

1.1 Payer and Payee Segments

The scope of the Refunds functionality related to the segments of payers and payees is shown below:

Payer (Merchant)

Payee (Customer)

Consumers

SME

Corporates

Consumers

SME

Corporates

(error)

(tick)

(tick)

(tick)

(tick)

(tick)

1.2 Refund - Example User Story

Panel
panelIconId0cd1bba7-8f00-45e4-bfea-96eab8c2d5f8
panelIcon:dsfa:
panelIconText:dsfa:
bgColor#E6FCFF

User Story

As a User (Business or Corporate),

I want to be able to initiate a partial or full refund of a payment received via an Open Finance,

so that I can fulfil the requirement to refund customers in case of returns and undisputed complaints for goods or services.

2. User Journey

2.1 Pre-conditions

The User buys goods or services from the merchant. Within the agreed period of time and under the terms & conditions in relation to the commercial transaction, the User requests a refund for the goods or services previously purchased from the mercahnt. Both User and Merchant agree to a refund and no dispute exists between them, thus making the refund part of a BAU process.

2.2 Original Payment Account selected at TPP

In cases where Users provided their payment account (or payment proxy) to a TPP for initiating Open Finance payments to a merchant for the purchase of goods or services, the TPP has all the available information required to facilitate the merchants' refund payments, when requested by Users. The TPP can provide to the merchant the original payment details including the payment amount, payments account details, payment reference, date and transaction ID. The merchant can then use this information to initiate refund payments as new credit transfers using their existing BAU processes. For more details, please refer to section https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/

...

Note: Depending on the use case, the Payee details may not be displayed to Users in full. However, these still need to be part of the payment Consent request sent by the TPP.

Additional Consent Parameters

TPPs MUST:

1.2 Set the Accepted Authorization Type (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70092902/Common+Rules+and+Guidelines#7.-Accepted-Authorization-Type).

...

70811733/Payment+Refunds#5.-Fulfilment-of-Refund-Payments.

2.3 Original Payment Account selected at LFI

However, in cases where Users select their account at the LFI, the TPP is does not obtain the Users' payment account details from the Users directly within their Consent journey. This creates challenges for the TPP when Users request refunds for their transaction at a later stage. Accordingly, the TPP would need to obtain these details from either from the Users, the merchants or the User’s LFIs in order to facilitate a refund, if requested.

This information gap is solved by modifying the original payment journey of the Single Instant Payment as shown below, to allow on demand refund information, which is referred to as Asynchronous Refund Information.

...

During the payment Consent journey, when the User provides explicit consent to the TPP for initiating a payment order, the User simultaneously provides their permission for the TPP to request the payment account details from their LFI for the purposes of providing a refund, if required in the future. This permission is included as a flag within the payment Consent payload which is submitted to the LFI as part of the payment initiation request. When a refund is required, the TPP will request the User’s payment account details from the LFI and the LFI will respond providing the details so that the refund for the transaction can be fulfilled.

Similarly for the Consent of the Multi-Payments payment jounrey.

3. Wireframes

...

3.1 Consent Setup

#

Step

Rules & Guidelines

REF-1

Single Instant Payment Consent with Refund Permission

As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/7009290270091893/CommonSingle+Rules+and+Guidelines#18.-Multi-User-Authorization-Flow).

1.4 Set the Consent Expiry Date accordingly if the Authorization Time Window is set to more than 1 day. This is to avoid the consent expiring before all necessary authorizations are completed. Otherwise, the default value of the Consent Expiry Date MUST be set to the same day (i..e current day). The Consent Expiry Time MUST always be set to 23:59:59 of the Consent Expiry Date.

1.5 Set the Risk Information Block (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70092902/Common+Rules+and+Guidelines#9.-Risk-Information-Block)

TPPs MUST:

1.6 Enable Users to provide explicit consent for the initiation of a SIP payment order from their online payment account held at their LFI as per the payment details specified in the payment Consent.

SIP-2

Consent Staging

As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70092902/Common+Rules+and+Guidelines#10.-Consent-Staging

SIP-3

Hand-off to LFI

As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70092902/Common+Rules+and+Guidelines#11.-Hand-off-to-LFI

Example wording to use: ‘We will securely transfer to YOUR LFI to authenticate and make the payment“.

SIP-4

Authentication

LFI Authentication Only

LFIs MUST:

4.1 Enable Users to perform authentication with their LFIs, as per the following sections:

  • https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70091622/Authentication+by+LFI#2.-Redirection

  • Instant+Payment#Single-Instant-Payment-Consent

    User Consent to TPP

    In addition to Users’ consent to the payment initiation:

    TPPs MUST:

    1.1 Request Users' explicit consent before they are able to request the Users' payment account details from the LFI for the purpose of refunds, as part of the payment initiation process.

    1.2 Present the User consent for payment initiation and Asynchronous Refund Information in a single step.

    1.3 Make it clear to Users that they will share these details with the payee or use the details for refund processing, if the User requests and agrees a refund with the payee (i.e. the merchant)

    • 1.3.1 Provide clear messaging to the Users in relation to providing consent to TPPs for requesting their payment account details for refund purposes. Example wording may be as follows: 

    “If you ask for a refund, we will request your LFI to share your payment account details with us. These details may be shared with the payer or may be used by us to process your refund request. We will not use these details for any other purpose and we will not retain these details after your refund request has been processed.”

    1.4 NOT request the Users' consent for Asynchronous Refund Information of their payment account details from the LFI, in cases where there is no realistic chance the refund information data (i.e. the User account details) to be used (e.g. where the merchant business model does not offer refunds).

    1.5 Set the appropriate Refund Information flag in the payment Consent payload that the User has provided explicit consent for Asynchronous Refund Information request.

    REF-2

    Consent Staging

    As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/

    70091622

    70091893/

    Authentication

    Single+

    by

    Instant+

    LFI#3.-Decoupled-Redirection

    4.2 Re-direct Users back to the TPPs, with information that the Consent has not been authorized, if User Authentication has failed or Users opted to cancel the authentication/authorization process.

    Centralized Authentication and Authorization (Federated) Only

    4.3 Payment#Consent-Staging

    REF-3

    Hand-off to LFI

    As per https://openfinanceuae.atlassian.net/wiki/x/HoBBAw

    SIP-5

    Confirmation/ Authorization

    Standard Journey

    LFIs MUST:

    5.1 Enable Users to authenticate using Multi-Factor Authentication (MFA) in order to review and authorize the Single Instant Payment (SIP) Consent.

    5.2 Retrieve from the OFP the Single Instant Payment (SIP) Consent details staged by the TPP using the unique Consent Identifier and present to Users all the details included in this.

    5.3 Allow Users to select a payment account for the initiation of the Single Instant Payment (SIP), if this was not provided in the retrieved staged payment Consent details, as spaces/standardsv1draft3/pages/70091893/Single+Instant+Payment#Hand-off-to-LFI

    REF-4

    Authentication

    As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70091893/Single+Instant+Payment#Authentication

    REF-5

    Confirmation/ Authorization

    As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/7009290270091893/CommonSingle+Rules+and+Guidelines#12.-Payment-Account-Selection-at-LFI

    • 5.3.1 NOT allow Users to select a payment account from their list of available payment accounts that has insufficient funds for the Single Instant Payment (SIP) initiation. This only applies in case Users do not select their payment account when providing their Consent to TPPs.

    • 5.3.2 Reject the Single Instant Payment (SIP) initiation, if the payment account identification was part of the Single Instant Payment (SIP) payment Consent provided to the TPPs and the payment account has insufficient funds. The OFP MUST be notified about this rejection with an appropriate error message.

    5.4 Check the authorization status of the selected payment account is in accordance with the TPPs' Accepted Authorization Type as Instant+Payment#Confirmation%2F-Authorization

    LFIs MUST:

    5.1 Provide clear messaging to the Users in relation to the consent provided to TPPs for requesting their payment account details for refund purposes. Example wording may be as follows:

    “TPP will be permitted to request your account details for refund purposes.”

    REF-6

    Payment Initiation

    As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70091893/Single+Instant+Payment#Confirmation%2F-Authorization

    REF-7

    Payment Status Update

    As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70091893/Single+Instant+Payment#Payment-Status-Update

    REF-8

    Hand-off back to the TPP

    As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/7009290270091893/CommonSingle+Rules+and+Guidelines#13.-Check-Accepted-Authorization-Type.

    5.5 Add to the Single Instant Payment (SIP) Consent the IBAN of the Payee returned by the Proxy resolution process, if the Single Instant Payment (SIP) Consent was submitted for User Authorization using a Proxy as the Payee Identification. The Consent is thereafter tied to the IBAN of the Payee rather than the proxy itself.

    • 5.5.1 Return back to the OFP in the payment Consent response the IBAN of the Payee identification returned by the Proxy resolution.

    5.6 Present to Users the following minimum required information for authorizing the Single Instant Payment (SIP) Consent:

    • User Payment Account

    • Payment Amount & Currency

    • Payee Identification details including:

      • Payee Name

      • Payee IBAN (& alias if specified)

      • Payee Account Holding LFI

    • Payer Note (Optional)

    • Payment Reference

    • Fees & VAT (if applicable): These are the charges that may be applied to the User account for making the payment in relation to the Single Instant Payment (SIP) Consent. If applicable, both bank charges and VAT MUST be presented and stated separately, prior to the User Consent authorization.

    5.7 Request Users to authorize the Single Instant Payment (SIP) Consent, so that a single instant payment can be initiated.

    5.8 Provide Users the ability to abort the payment journey, if Users decided to terminate the request. The LFI MUST hand-off the Users back to the TPP, providing the necessary error message to the OFP and reject the Single Instant Payment (SIP) Consent.

    5.9 Check the Authorization Time window is valid as Instant+Payment#Hand-off-back-to-the-TPP

    REF-9

    Confirmation to User

    As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70091893/Single+Instant+Payment#Confirmation-to-User

    TPPs MUST:

    9.1 Confirm to Users that they have received permission to request their payment account information in the future for the purpose of refunds.

    9.2 Provide clear messaging to the Users confirming the permission provided to them for requesting payment account details for refund purposes. Example wording may be as follows:

    We have saved your permission to request your payment account details from your LFI for refund purposes. If you ask for a refund, we will request these detaisl and share them with the payee or use them to process your refund request. We will not use these details for any other purpose.”

    9.3 Additionally consider displaying some of the following information points, which would be of value in relation to refunds:

    • The type of information that will be accessed e.g. payment account number

    • The purpose for which the information will be used  e.g. to provide a refund payment or facilitate the refund process with the payee

    • How long the TPP will retain or store the information, if required

    • Details on security and safety measures applied by the TPP

    • An indication of how quickly refunds will be processed if requested.

    Note: This list is not intended to be exhaustive and TPPs should adapt it to include the information relevant to their service offering. User details usage and retention should be covered by the TPPs' Privacy Policy.

    REF-10

    Payment Notifications

    As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/7009290270091893/CommonSingle+Rules+and+Guidelines#20.-Check-Authorization-Time-Window

    5.10 Change the state of the Single Instant Payment (SIP) Consent from Awaiting Authorization to Authorized, when all Authorizers (one or more) have authorized the payment Consent.

    5.11 Update the Single Instant Payment (SIP) Consent details stored in the OFP with all the information included in the Single Instant Payment (SIP) Consent authorized by the User.

    1. Fast-track Journey Only

    LFIs MUST:

    5.2.1 Display as minimum the Payment Amount, Currency and the Payee Account Name to make the User aware of these details. These details MUST be displayed as part of the authentication journey on at least one of the following screens without introducing additional confirmation screens (unless supplementary information is required):

    1. LFIs’ Authentication screen (recommended)

    2. TPP to LFI redirection screen

    5.2.2 Display the balance of Users payment account (not shown on the user journey) as part of the authentication journey on any of the aforementioned screens (stated in 5.2.1), in the case that Users are redirected to authenticate using an app (thus meeting 1 authentication factoer). Displaying the balance in this instance need not require any additional strong customer authentication. Displaying the balance is other cases is optionaly for LFIs.

    5.2.3 Allow the same minimum and maximum payment limits, as they offer in the Standard Journey and their other direct online channels.

    5.2.4 Inform Users about their “point of no return” for making the payment and that their payment will be made after authentication occurs. Example wording: ‘Authenticate to make payment”. For recognition based biometrics (e.g. Face ID) which can be more immediate, the biometric authentication should be invoked after a delay or through a call to action to allow the User the ability to view the details of the payment that needs to be authorized.
    5.2.5 Ensure their authentication has no more than the number of steps that the User would experience when directly accessing the LFI channel. MFA Authentication MUST be the only action required by Users at the LFIs (unless supplementary information required).

    OFP MUST:

    5.12 Confirm back to the LFIs that the Single Instant Payment (SIP) Consent details have been updated successfully.

    Multi-Authorization Journey Only

    5.13 As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70092902/Common+Rules+and+Guidelines#18.-Multi-User-Authorization-Flow

    SIP-6

    Payment Initiation

    LFIs MUST:

    6.1 Trigger the payment initiation process for the payment Consent immediately after the Single Instant Payment (SIP) Consent has been fully authorized by all required authorizers (one or more).

    6.2 Additionally apply all existing BAU payment account controls and limits such as single transaction value limit, total transaction value limit, AML checking (if applicable) and others, as if the payment request has been initiated by the existing channels of the LFI. LFIs MUST send an appropriate error response to the OFP in case the payment is rejected due to violating any of these limits.

    6.3 Reject the payment initiation if the payment account selected for the payment has insufficient funds. The OFP MUST be notified about this rejection with an appropriate error message.

    6.4 Subject to successful BAU checking, validation and payment processing, proceed with the execution of the payment by either submitting the payment to the underlying payment rails or executing internally as Intra-bank payment.

    6.5 Provide the OFP with all the available information in relation to the initiated payment instruction including the payment’s unique identifier Payment Transaction ID. The format of the Payment Transaction ID can be found in the UAE Open Finance Standard specifications.

    6.6 Ensure that the Payment Reference provided in the Single Instant Payment (SIP) Consent is made available to the Beneficiary’s account information in the case of Intra-bank payments within the same LFI.

    OFP MUST:

    6.7 Return back to the TPP in the Single Instant Payment (SIP) Consent response the IBAN of the Payee identification returned by the Proxy resolution, if the Single Instant Payment (SIP) Consent was submitted for User Authorization using a Proxy as the Payee Identification.

    6.8 Send an appropriate error response to the TPPs in case the payment is rejected due to violating any of the LFIs BAU payment accounts checks or limits.

    6.9 Send to the TPP the appropriate error message in case the payment initiation was rejected by the LFI due to insufficient funds in the selected payment account.

    6.10 Provide the TPP with all the available information in relation to the initiated Single Instant Payment (SIP) instruction including the payment’s unique identifier Payment Transaction ID.

    SIP-7

    Payment Status Update

    As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70092902/Common+Rules+and+Guidelines#15.-Payment-Status-Update

    SIP-8

    Hand-off back to the TPP

    As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70092902/Common+Rules+and+Guidelines#14.-Hand-off-back-to-the-TPP

    SIP-9

    Confirmation to User

    1. Standard Journey Journey

    9.1.1 As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70092902/Common+Rules+and+Guidelines#16.-Confirmation-to-User

    1. Fast-track Journey Only

    TPPs MUST:

    9.2.1 Display to Users the information received from the LFIs. This information may include:

    • The payment unique identifier Transaction ID assigned to the payment instruction by the LFIs.

    • The payment status (and status update date & time) – Confirmation of successful payment initiation.

    9.2.2 Display any of the following information regarding initiation and execution of the payment, if received by the LFIs:

    • The expected payment execution date & time.

    • The expected settlement date & time (i.e. the value date of the payment).

    • The LFI charges (where applicable).

    SIP-10

    Payment Notifications

    As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70092902/Common+Rules+and+Guidelines#17.-Payment-Notifications

    7.2 Single Refund Payment Consent

    This use case requires a https://ksaob.atlassian.net/wiki/spaces/BRS20231101final/pages/348553780/Generic+Business+Rules+for+PIS#A.-Single-Use-Consent. The consent parameters type for this use case is Single Refund Consent, which MUST be used for a batch of single refunds which will be initiated by the PASP immediately after PSU authorization at the PASP.

    Panel
    panelIconId1f1f5
    panelIcon:regional_indicator_p:
    panelIconText🇵
    bgColor#DEEBFF

    PISPs MUST:

    7.2.1 Enable the merchant to initiate a refund request with the following details:

    7.2.2 Check the details provided by the merchant and validate they match their previous records of initiated payments.

    7.2.3 Check if any previous Partial Refunds were initiated against the same original transaction and that the cumulative value including the new Partial Refund request does not exceed the value of the original transaction. If it does exceed, then the PISP MUST inform the merchant accordingly and abort the request.

    7.2.4 Enable the merchant to review the parameters related to the Refund payment they need to give consent for.

    7.2.5 Enable the merchant to provide explicit consent for the initiation of a Refund payment from their online payment account held at their PASP as per the refund payment parameters specified in the consent.

    7.2.6 Enable Merchants to initiate Refunds to multiple beneficiaries (original payers) using a single Refund Consent.

    7.2.7 Limit the number of Refunds batched together in a single Refund request message to the https://ksaob.atlassian.net/wiki/spaces/BRS20231101final/pages/348554507/PIS+Limits+and+Constants#Max-Refunds-per-Message.

    7.2.8 Redirect the merchant to the PASP of the payment account to be used for the refund payment.

    7.2.9 NOT initiate a new Single Use Refund Consent with bulk Refunds before all the Refunds in a previous bulk Refund Consent have completed processing and have a conclusive payment status.

    7.2.10 NOT initiate any Refunds of a payment date older than the https://ksaob.atlassian.net/wiki/spaces/BRS20231101final/pages/348554507/PIS+Configuration+Parameters#Max-Refunds-Allowable-Time-Window.

    7.2.11 Set the Risk Information Block (as per https://ksaob.atlassian.net/wiki/spaces/BRS20231101final/pages/348553780/Generic+Business+Rules+for+PIS#4.2.13-Risk-Information-Blockexcluding the Destination Delivery Address and the Beneficiary Indicators information groups due to being irrelevant)

    Panel
    panelIconIdbe99de2e-2b7e-4996-aa88-9eede9ccfd75
    panelIcon:bank:
    panelIconText:bank:
    bgColor#E3FCEF

    PASPs MUST:

    7.2.12 Follow the Authentication rules as defined in the https://ksaob.atlassian.net/wiki/spaces/BRS20231101final/pages/348553780/Generic+Business+Rules+for+PIS#4.4-Authentication.

    7.2.13 Use the information included in the Refund Consent to search records and identify the original transaction.

    7.2.14 Check and validate that all the information of the Refund Consent matches the parameters of the original transaction.

    7.2.15 Check and validate that all the payment account to be used for the Refund payment specified in the authorized Refund Consent matches the Payment Account used to receive the original payment.

    7.2.16 Use the original transaction information to identify the account details of the PSU that initiated the original payment.

    7.2.17 Display all the parameters of the Full or Partial Refund payment and request the merchant to authorize the initiation of a new single payment payment as a full or partial refund payment with the original payer PSU as the beneficiary.

    7.2.18 Reject the request for initiation of refund and respond with an appropriate message for the following scenarios:

    • the payment account used for the Refund(s)does not have enough balance for the total amount of all Refund(s) in the request.

    • the Refund request is made after the stated refund allowable period.

    • the Refund request is made for a transaction that has already been refunded.

    • the amount in the refund request exceeds the original transaction amount . The amount must be checked against a cumulative value if there were any previous partial refunds made for that transaction.

    • there are any issues with the originating account that block any transaction initiation from the that account.

    • the transaction is declined by the recipient’s PASP

    7.2.19 Formulate and send to the payment rails for processing the single payment message using the parameters of the authorized refund payment consent.

    7.2.20 Confirm to PISP the successful initiation of the Refund payment.

    7.2.21 Provide the PISP with the ability to check the status of the Refund payment as per the Rules in https://ksaob.atlassian.net/wiki/spaces/BRS20231101final/pages/348553780/Generic+Business+Rules+for+PIS#4.8-Payment-Status-Update.

    ...

    panelIconId1f1f5
    panelIcon:regional_indicator_p:
    panelIconText🇵
    bgColor#DEEBFF

    PISPs MUST:

    ...

    4. Requesting Asynchronous Refund Information

    #

    Step

    Rules & Guidelines

    REFREQ-1

    Pre-condition

    1.1 Both User and Merchant MUST have agreed to a refund and no dispute exists between them.

    REFREQ-2

    Request Asynchronous Refund Information

    TPPs MUST:

    2.1 Submit to OFP a Refund Information Request specifying the payment Consent ID related to the original payment for which a refund has been requested.

    REFREQ-3

    Processing of Refund Information Request

    OFP MUST:

    3.1 Allow the TPPs to submit the Refund Information Request in relation to a single-use or long-lived Payment Consent authorized by the User, without any additional MFA or authorization from the User.

    3.2 Check that the received Refund Information Request relate to a valid Payment Consent authorized by the User.

    3.3 Check that the Refund Information flag in the Payment Consent has been set confirming that the User has provided permision for this payment account details to be provided for the purpose of Refund payments.

    3.4 Send the Refund Information Request to the LFI for acquiring the User’s payment account in relation to the Cosnent ID specificed.

    LFIs MUST:

    3.5 Allow the OFP to submit the Refund Information Request without any additional MFA or authorization from the User.

    3.6 Search their records for the User payment account in relation to the payment Consent ID specified in the Refund Information Request.

    3.7 Search their records for the User payment account in relation to the payment Consent ID specified in the Refund Information Request.

    3.8 Provide the OFP with the User payment account details in relation to the specified payment Consent ID as response to the Refund Information Request. The format of the User payment account is as per as per Common Rules and Guidelines | 2. User Payment Account Selection.

    OFP MUST:

    3.9 Send an appropriate error response to the TPPs in case the Refund Information Request is rejected due to an invalid payment Consent.

    3.10 Provide the TPP with the User payment account in relationall to the payment Consent ID used to make the original payment, which has been requested to be refunded.

    REFREQ-4

    Refund Information Received

    TPPs MUST:

    4.1 Confirm to PSUs using notifications that they have received their payment account information to be used for the purpose of refunds.

    Note: Using, accessing and storing the User account details is the responsibility of the TPP. TPPs would need to ensure that if required to be stored, these details are stored securely and in line with relevant regulatory obligations.

    • 4.1.1 Consider the following parameters when storing User payment account details, if required for the purposes of refunds:  

      • Security:  TPPs MUST have robust procedures in place to ensure account details are stored in a secure manner, in order to minimise the risk of these details being compromised.

      • Duration of storage: TPPs MUST ensure that the User payment account details are stored for an appropriate length of time to meet the purpose for which they are required, and should not store these longer than necessary, in line with the refund policy and applicable regulatory obligations.

      • Purpose of storage: TPPsMUSTensure that the account details are being stored solely for the purposes of making a refund. If TPPs want to use the account details for other purposes, for example, for the future transactions, TPPs MUST ensure this is clearly communicated to the Users as part of the Consent journey.They must also consider the appropriate lawful bases for requesting this.

    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 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 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 file processing etc). 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.

    Note

    Participants (TPPs) engaging in the Model A will need to ensure they meet relevant regulatory obligations specifically relating to the services they are providing.

    • 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

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

    Panel
    panelIconId068fdde3-c1f6-4759-9967-8a80e7ba7356
    panelIcon:rock:
    panelIconText:rock:
    bgColor#DEEBFF

    TTPs MUST:

    5.2.1 Ensure that, if multiple partial refunds are to be initiated at different points in time, it is in the responsibility of their customer Merchant/Service Provider to reconcile these, so that they much the total amount of the original payment.

    5.2.2 Refund Payment Reference

    Panel
    panelIconId068fdde3-c1f6-4759-9967-8a80e7ba7356
    panelIcon:rock:
    panelIconText:rock:
    bgColor#DEEBFF

    TTPs MUST:

    5.2.2Ensure that the refund payments, initiated by themselves or their customer Merchant/Service Providers depending on the fulfilment model used, MUST be clearly identified in order to allow easy identification and reconciliation by the User.

    • 5.2.2.1 Ensure that, in addition to using the same payee payment reference as the original payment, where possible, the refund transaction payment reference MUST also be preceded with the identifier ‘REF ‘ or ‘REFUND ‘ as a prefix, to easily allow the payment to be identified as a refund. The prefix must MUST be used without truncating the original payment reference as this could make reconciliation of the refund payment against the original transaction more difficult.