Open Finance Regulation

General

1

Details like commercial model, liability model, dispute management process, Reporting and audit requirements, SLAs, penalties and enforcement actions etc. will be added to regulations in coming days?

Currently there are clauses in regulations covering these points briefly but operational details are missing.

This section will be updated shortly.

2

Not currently

Noted.

3

As per the regulation, a Technical Service Provider does not require an Open Finance License provided that its services are limited to the provision of support services to Open Finance Providers.

Based on this understanding, a licensed TPP that also acts as a TSP for licensed LFIs (Licensed Financial Institutions) or other TPPs does not require any additional license or NOC from CBUAE for its TSP activities. Please confirm.

This section will be updated shortly.

3

Regulation doesn't clarify requirements on compliance to SOC 2 and IA UAE standards assessment. Please clarify below points and suggest having this guidance documented in the standards for reference:

a.     Are TPPs required to undergo an external assessment for compliance with IA regulations and SOC2 requirements ? If so, what are the timelines for TPPs to complete it?

b.     Could you please verify if the UAE Information Assurance (IA) Regulation accessible at https://u.ae/#/ is the most recent version, as of March 2020?

c.     What are the process steps for TPP’s cybersecurity compliance and over what period of time those must be completed?

d.     Similar to SAMA in KSA and CBB in Bahrain, are there plans to introduce a cybersecurity framework to measure compliance and maturity levels for Open Finance Providers?

This section will be updated shortly.

3

The technology risk management function and the independent technology audit function required under Article 24 can be managed by the same independent Risk Management and Internal Audit functions, respectively, as required under Article 12 of the regulation. There is no requirement to create separate technology-specific functions. Please confirm if this understanding is correct.

This section will be updated shortly.

4

Given the Regulations have now been published in the Official Gazette, we have no further feedback to share at this time

This section will be updated shortly.

Liability Model

General

1

QUESTION:

Scenario 1

User had revoked the consent through the TPP but this was not communicated to the LFI as a result erroneously keeps initiating payments.

This scenario is not clear on following counts-

1. While explaining orchestration of multi payments it was told that LFI will process the consent at the start of multi payment and after that TPP will be managing the orchestration, so in this scenario how LFI keeps making payment, in standards also this orchestration has been shifted to LFI, why?

2. If Central platform is the golden source of truth in that case, if consent is revoked at TPP why the change is not reflecting at OFP and what is the mechanism at OFP to communicate this change to the concerned LFI, this lapse can potentially impact other transactions also, and how do you affix the liability in such a scenario?

3. As central platform is effectively managing the consent framework and LFI, TPP can access it via API’s how a change in consent can be affected without getting it updated at the central OFP? Until it’s a case of communication link being broken between channel, the bank OFP, and central OFP, shouldn’t we have some sort of re-trial protocol to mitigate this scenario.

Scenario 2

The TPP did not initiate payment as scheduled resulting in unintended consequences like penalties for the User.

This scenario is in contravention to the scenario described above, as here the TPP is orchestrating the payment after obtaining initial consent from LFI.

Kindly clear this confusion and state this clearly that in case of future dated, multipayment, any kind of long standing consent scenario payment orchestration is done by TPP.

Scenario 3

The LFI was not able to flag alerts and protect the User from fraud in spite of sharp increase in the transaction frequency or value for

payments initiated by TPP using VRP or delegated SCA

Same confusion, here also it’s the TPP orchestrating the Payment after consent for VRP is given once, what controls will LFI have to flag such possibility or its an empirical decision?

Scenario 4

The User acknowledges that they authorized a Long-lived consent but is unable to recognize/reconcile transaction(s) for which they were not physically present Or they had not physically authorized the TPP to initiate the transaction(s)

How do we determine consumer is telling the truth, the entire idea of VRP or delegated SCA is to allow user to give one time consent for transactions happening in future, I think this can be better addressed with the proper boundary conditions defined for transactions at the time of consent like max, min amount per transactions, total number of transactions, or maximum cumulative amount

This section will be updated shortly.

General

2

We believe there should be a cap to liability for LFIs under fraudulent payment scenarios. In a situation where fraud has occurred and both TPP and LFI did not prevent it then the liability should be shared equally.

This section will be updated shortly.

2

We would like to understand more about the mechanisms and processes that will be established for resolving disputes including arbitration, mediation etc.

This section will be updated shortly.

Liability Table (i)

2

What is a stipulated time which should be followed/monitored for the authentication?

This section will be updated shortly.

Liability Table (ii)

2

We understand that the authentication process will be approved by CB. LFIs should not be liable for an unforeseen hack in its system unless it was due to negligence of the LFI

This section will be updated shortly.

Liability Table (iii)

2

LFI was not able to flag alerts and protect the User from Fraud. How will this be achieved? How can the Bank foresee fraud and control – restricting account to control fraud will also lead to customer complaints of not being able to access

This section will be updated shortly.

Liability Table (iv)

2

What is the scope of the screening? What is the timeline? Is this required to be done on real time basis?

This section will be updated shortly.

Liability Table (v) - (i)

2

Requirement: User states that they had not done the authentication for the OF Services or the LFI/CAAP authentication and authorization happened too quickly for them to comprehend to the extent the error was not due to the negligence of the User or the TPP.

Comment: What is a stipulated time which should be followed/monitored for the authentication? LFI should not be liable if the error/loss was suffered due to the negligence of the User or TPP.

This section will be updated shortly.

Liability Table (ii)

2

Requirement: The authentication mechanism of the LFI has been hacked or is not adequate as mandated leading to unauthorized access of the user accounts through the OF Services.

Comment: We understand that the authentication process will be approved by CB. LFI should only be liable if the LFI has not implemented the specifications required by CB and/or negligence.

This section will be updated shortly.

Liability Table (iii)

2

The LFI was not able to flag alerts and protect the User from fraud despite sharp increase in the transaction frequency or value for payments initiated by TPP using VRP or delegated SCA. Liability/losses should be shared between the TPP and LFI to the extent the transactions were initiated by TPP. For example, in the UK's Contingent Reimbursement Model: LSB-CRM-Code-V5.0-17-October-2023.pdf page 17 ALL2(2) notes Where both Firms have breached the SF and an exception under R2(1) or R2(2)(b) applies, the Customer will receive a 66% reimbursement. Each Firm will contribute 33% of the cost of reimbursement.

This section will be updated shortly.

Liability Table (iv)

2

Requirement: The LFI response to request by TPP has poor quality of data where information is either missing or incorrectly mapped to the OF data model adversely impacting the quality and reliability of the service offered by the TPP to the User.

Comment: LFI liability should be limited to incorrect information. TPP should be responsible for informing about the receipt of the poor-quality data received. Failure to inform should transfer the liability to the TPP.

This section will be updated shortly.

Liability Table (v)

2

Requirements: The TPP must onboard individual users via a process which utilizes their KYC-ed record at an LFI, which contains verified data and has not expired as a valid KYC record. The user must only represent themselves on the OF platform and in OF transactions with the same name to be held at the LFI.

Comment: LFI liability is limited to the verified data. Confirm with CB/UBF on the definition of verified data. Is the LFI required to provide information which is not validated by the LFI but simply obtained as part of the onboarding process.

This section will be updated shortly.

P16. Definitions: Technical Service Provider: a Person who provides technical support to third parties for the provision of Open Finance Services

2

12. We note and support this important clarification of the status of Technical Service Providers (TSPs) under the regulations. Specifically, we agree that TSPs should be exempt from requiring a license, providing the TSP itself does not seek to offer Open Finance Services (either Data Sharing and/or Service Initiation.) Clearly, the appointment of a TSP would need to take account of the Outsourcing Regulations in the services contract between the Licensee (or a LFI) and the TSP. Furthermore, the exact nature of the services to be provide by the TSP would need to be understood by all parties, including the Central Bank. For example, a TSP could be simply providing back office technical support with no requirement to (for example) to store or process data or undertake KYC or AML/CFT activities.

Further, greater clarity is required on what is deemed as material outsource for a regulated entity/activity, what is within confines of a TSP service, and what would necessitate an open finance licence. For example, a BNPL provider that is offering credit and consuming open banking data would need lending and open finance licenses; what if the BNPL provider partnered with the bank and was provided the lending data from the bank - would it need its own open banking licence (or could it leverage the bank licence and be regulated only for lending). I.e., the AECB data for the BNPL is replaced by bank (partner)-provided affordability data.

This section will be updated shortly.

P19 (2)8

2

We appreciate the need for Open Finance Providers and Persons Deemed Licensed to take responsibility under the regulations, and not to push down liability to an unlicensed party (the Technical Service Provider). We acknowledge the need to protect the end user customers who have chosen to opt into the open banking environment.

However, we would appreciate guidance on the limits of this particular Article, specifically the term “…cannot be transferred…”. Presumably this does not prevent a licensee (such as an LFI) from imposing secondary liability on the TSP for a blatant breach of contract (between the licensee and the TSP) to supply technical services, which causes a loss to an end-user customer, but please confirm. Here we acknowledge that the licensee would carry the primary liability to the end user and could not avoid liability by claiming the TSP caused the loss.

This section will be updated shortly.

P35 (15)2

2

First, we consider it near impossible, for technical reasons, to physically prevent data scraping in an open banking environment. Such activities are of course being carried out by aggregators under the existing legal framework, before the Regulations come into effect.

The restriction on data scraping appears to be limited to cases where a party is carrying out that activity “…in order to undertake any activities subject to this Regulation…”.

In other words the provision of Open Finance Services (either Data Sharing and/or Service Initiation).

There is a risk that customer data could be gathered for purposes other than for activities subject to the Regulations, which would not breach this Article. There is a concern that data scraping for all purposes should be prohibited. This appears to be supported by Article (22) Data Privacy and Consent for the Use of Personal Data. Therefore, the rather indefinite drafting of this Article (15)2 could be seen as providing a legitimate opening to engage in data scraping.

We would appreciate clarity on whether data scraping is banned for activities that are not 'data sharing/service initiation'

This section will be updated shortly.

P52 (26)

2

Technical standards – we generally support this initiative. From the Bank’s perspective, the more technical regulation and standardization there is the less chance for error or failure, if managed properly with buy-in from all parties.

This section will be updated shortly.

2

In feedback round 1, regarding liability model, the feedback provided as below:

"

The liability model must be clearly defined between TPP, the Open Finance Platform, and LFI for aspects such as availability, security, and dispute resolutions. Responsibilities and legal liabilities should be transparent concerning the use of OFP, as well as in cases of data breaches, fraud, and payments.

"

And response noted as "This will be tabled for feedback in round 3 engagement."

In round 3, liability model presented based on LFI and TPP without OFP being considered. Regarding the OFP responsibilities, SLA and issues which can go wrong at OFP end also needs to be identified and clearly documented to present liabilities e.g., service disruption, security incident or data breach at OFP (covering all OFP platform functions e.g. OFP, Ozone API Hub, Radium CA infrastructure and Federation Platform)

This section will be updated shortly.

2

17. In the table presented, regarding the row “Fraud monitoring of all payment activity from LFI held accounts” (also pasted below), LFI is liable and responsible party which is more than what LFI can control.

When a payment request is originated via the TPP, and 2FA enforced and other fraud controls by TPP is passed, then this is a validation level passed by a regulated entity.

After that “Risk Information Block” to be processed by LFI. In that case if data in this block is not sufficient for LFI to understand this type of fraudulent activity, then LFI can’t further identify the fraud because full data activity and fraud related analytics is with TPP.

Accordingly, this can’t be a full liability of LFI because origin of payment initiation is TPP, and TPP has full visibility to user activity and behavior data of all time. Please reconsider this in the liability model.

This section will be updated shortly.

2

In case TPP is not enforcing 2FA for payment initiation e.g. with a software token, and payment is fraudulent, full liability and responsibility must be on TPP.

This section will be updated shortly.

3

In the scenario of Bulk payment where only a few records are not correct, how liability model would work in case of full rejection by LFI. We suggest covering this in the liability model as this would impact rest of the customers and payments in the bulk file.

This section will be updated shortly.

3

For Issue covered under “Payment initiated outside of VRP/future dated payments /bulk payments/part payments / refund consent” - why TPP is liable for processing errors possible by LFIs where an LFI makes the incorrect copies of the consent from the OFP and therefore add an inaccurate validation process. This should fall under LFIs liability

This section will be updated shortly.

3

Please add the liability model to the standards

This section will be updated shortly.

4

Generally further clarity on the Open Finance Compensation scheme - who will it be run by? How will decisions be made? What will be the timelines for arbitration - how will this be executed? E.g. will all participants be required to have capital held with the compensation scheme, and what value will this be?

As was raised during the session - the liability model omits the possibility that a failure could occur at the infrastructure layer, and in what instances and scenarios the Open Finance platform itself would be deemed liable (if at all). For example: payments correctly initiated by the LFI not being executed due to system failure or downtime within the SLAs.

Separately, there are a number of consumer protections around what happens in larger events and who is liable which is not present in A2A or this framework which should be considered further for example a merchant becoming insolvent - who bears the liability there, what insurances should be in place, what recourse should a TPP have in place against a merchant etc.

How would the Open Finance Compensation process work and under what SLAs? How long would TPPs and LFIs have to be compliant to a ruling?

This section will be updated shortly.

Terms and Conditions and Application Forms

General

1

As LFIs are already governed by CBUAE and most of the information asked in application forms is already with CBUAE, can we streamline the documentation for LFIs to a NOC from CBUAE in case they want to operate as TPP providing the details of the services that bank wants to offer and associated documentation, this was raised in the call as well.

This section will be updated shortly.

2

The forms are too long and onerous especially for deemed licence LFIs and seem to request much information that is already held by CBUAE.

This section will be updated shortly.

3

Kindly share the application form along with the finalized details on the requirements and the checklist/policies that need to be submitted with the business plan and application form.

This section will be updated shortly.

3

Please clarify what is expected from below 2 requirements that were covered as part of the application form:

a.     Payment Mechanism to be Relied Upon

b.     Use of agents, branches and Third-Party Providers

c.     List of Applications and Users

This section will be updated shortly.

4

We have no comments on the actual forms. We hope that the CBUAE will commit to process applications within a reasonable timeframe (i.e. 60 days.)

This section will be updated shortly.

FAPI Authorization Code Flow

Security

1

No Comments on FAPI authorization code flow

Feedback:

 As indicated lot of functionalities will be available for LFI via the central OFP, like FAPI, Consent APIs, reporting modules etc.

It will be useful to publish a document listing the capabilities of central OFP that participants can leverage.

This will help us streamline our development plans and system design, for example designing the consent module looks a major task, but if we know what all consent related capabilities we can consume from Central hub directly, can help with effort estimation and design at our end.

Documentation for the Open Finance Platform, which includes the Trust Framework and the API Hub is being created and presented to the LFIs during the Consultation Feedback Cycles and the Workhops with the Technical Teams.

The current version of the Open Finance Platform documentation can be found on: Open Finance Platform

This documentation is under refinement and full version will be released in August. As the platforms will evolve with time those documents will be continuously maintained and updated.

2

As “Organisation Admin” will be a highly privileged user, SSO login with MFA must be mandatory and additional behavior analytics must be in place by Ozone layer also if there’s an unauthorized use of the account. And detailed logs of this account must be monitored continuously. Allowed login IPs must also be whitelisted at the Ozone layer.

Login to the Open Finance Platforms will utilize the Trust Framework Single Sign-On (SSO) functionality, which also incorporates FAPI 2.0 standards.

To access the platform, users must have a valid and active account within the Trust Framework and must always use Multi-Factor Authentication (MFA), including:

• Time-Based One-Time Password (TOTP) from an authenticator app

• Username and password

Access logs can be obtained upon request via the Service Desk once it's live.

2

Regarding privileged actions “Certificate generation” and “Participant Grant and Revoke”, dual control can be enforced. In a breach case even admin account is compromised, a second approver account will be the gatekeeper.

Although Trust Framework users can have a well-defined access scope, such as allowing one user to publish APIs but not issue certificates, actions within the Trust Framework do not require secondary validation.

While breaches are possible, all login attempts require a Time-Based One-Time Password (TOTP), generated by an authentication app such as Google Authenticator. This makes a breach highly unlikely unless the user also loses their validation device, typically a phone. In such cases, access should be revoked until a new OTP device is linked.

3

It was mentioned that TPP can query the trust framework JIT and get the most recent URLs. I think these URLs won't be changing too frequently, if they do then JIT would help for sure. I wonder how this translate in case bank is performing any DR activity, does bank publish those new URLs in trust framework too and we shouldn't have any interruption of service using JIT?

Information about all existing Servers and their endpoints should be obtained from the participant endpoint, in line with the third claim of the Client Discovery Guidelines

Since this information is not updated frequently, implementing a caching and refresh policy is recommended to enhance performance for clients.

The participant endpoint refreshes its information every 15 minutes. We advise all active data receivers to cache this information for 15 minutes or even longer to optimize performance.

4

FEEDBACK

N/A

Delegated SCA

1

For the TPP side MFA, will there be a CB led approval process to approve the MFA method being used by TPP, how will the LFI/customer/any other entity on the network ensures that the TPP MFA adheres to adequate security standards?

There will be no Central Bank led approval process for approval of MFA being used by the TPP. The TPPs have to follow the guidelines in https://openfinanceuae.atlassian.net/wiki/x/HQCiBg

For a delegated model, the TPPs are expected to be liable for disputes with Users regarding unauthorized payments where the MFA was not as per the guidelines.

1

On the balance check capability, for every transaction fired the assumption is TPP will do a balance check first (if customer has provided consent for balance check) and then initiate the transaction, what if there is not enough balance? Will the TPP ask user to initiate a new txn or suggest an alternate payment method? Will this balance check capability be extended to other types of payment transactions as well like single instant payments, Future dated payments, Multi payments etc.

The balance check functionality applies to any long-lived payment consent. If the TPP, as part of this functionality, finds that there is not enough balance to fulfil a transaction, then it is in the competitive space of how the TPP takes remedial action. For example, they could request the user to top up their bank account or ask them to use an alternative payment method for that transaction.

1

How this payment flow is different from a multi payment flow, as customer will be providing MFA here on TPP interface, same functionality can be offered using multi payments with user doing MFA with LFI? This way LFI need not rely on the one time consent and the subsequent TPP authentications.

The primary difference between the multi-payment flow and the payment flow is consent.

It does not have any controls that can be monitored by the LFI. Once consent is set up, there is no redirection to the LFI as part of UX.

For comparison with the card ecosystem, setting up a card in a wallet like Apple Pay or Google Pay is similar. Once set up, the wallet does the authentication, and there is no user interaction with the bank.

1

Delegated SCA as described looks like a high-risk process, a detailed listing of controls that can be enabled to protect consumer and bank interests along with negative scenarios and how they are controlled and managed by these measures will be helpful for banks internal fraud/risk teams

The high risk is catered to by the liability, which will be with the TPP on disputes raised by the user regarding unauthorized transactions.

The LFI will not have any controls to monitor as the consent will not include any control measures. These are entirely managed at the TPP end Payments with Delegated Authentication | 5. Payment Control at TPP

1

Apart from consent details a standard terms and conditions should be agreed upon by the consumer when opting for this payment method (much like google/apple pay) CB can draft a standard T&C which is then used by all participants

Agreed. This will be included in the wireframes and business rules

2

We believe this feature should be optional / commercial for each LFI to decide if it will support or not, in order to ensure risk, ops risk and fraud implications are clearly understood before each institution’s go-live.

This section will be updated shortly.

3

none

Noted.

4

Delegated SCA is an entirely new approach to Open Finance, as echoed on the call we are not aware of successful implementations of this in other markets. As a use-case we believe this is incredibly forward thinking - but there are a large number of risks on liability that this introduces, particularly given the lack of ability for A2A payments to be reversed or charged back by the initiator in a landscape where APP fraud is rising. How will access to this use case be safely rolled out for all participants? How will the liability model be updated for Delegated SCA?

The liability model published caters to the different scenarios for this capability.

Bank Service Initiation

Bulk/Batch Payments

1

As per last discussion of the working group, I understand this process is now shelved pending further investigation and due to loa Aani adoption as of now.

This is not shelved and is part of the standard.

2

1. We have not reviewed this feature given it is highly complex and unlikely to be workable in the immediate term. We should revisit the standard after Day 1 release.

Your feedback has been noted.

3

none

N/A

4

FEEDBACK

N/A

Bank Service Initiation

Bulk/Batch Payments

1

Does Aani currently support bulk/batch processing, if not then it might be unworkable.

Assuming that the file format issue is sorted, are we expecting the transactions in the file be fired one-by-one, then this will create an issue with corporates as it will create multiple debit entries in their account statement. Some banks have developed utilities wherein for processing bulk transactions, there is a single debit entry in corporate account and funds taken into an intermediary account and individual credit transactions fired from that account and the utility then does the reconciliation against the file and provides the output to corporate. But how this will work with a TPP (non banks) because they are not allowed to hold funds?

Bulk/Batch Payments aims to reflect the existing bulk payments mechanisms supported by the LFI. All behaviours will reflect existing practices at the LFI.

The OFP will facilitate transfer of the bulk/batch payment instruction and delivery of the processing report.

To clarify, there is no orchestration of payment instructions at the OFP and no expectation of support for bulk/batch payments at Aani.

2

We have not reviewed this feature given it is highly complex and unlikely to be workable in the immediate term. We should revisit the standard after Day 1 release.

However, a few quick observations below:

1. Processing should be based on a string and not the overall batch file.

2. Each node ought to have a respective status – success, failure, timeout or on hold.

3. Insufficient balance – Factor the scenario of insufficient balance if from the time of initiation to fulfillment balance falls short. The processing should be put on-hold with an error with a workaround for remaining transactions.

4. Re-push – A dedicated feature around re-push should be factored to ensure any false positive or technical outage to support partial processing of an in-process file or bulk request.

You feedback has been noted.

Currently the functionality has been based on supported existing practices at the LFIs. As this functionality evolves your comments will be factored into any revisions.

3

none

N/A

4

FEEDBACK

N/A

Bank Service Initiation

Fast-track Single Instant Payment

1

In the Fast Track use case, there are a couple of elements I would like clarity on, particularly not allowing customers to select an account whose balance is below the payment amount and returning an error should the prepopulated payment account not have sufficient funds.  Have the error codes been developed for these two scenarios?

Yes, the business rules define both cases as erroneous. The error code that the LFI will generate will be a generic business rule error. However, we will review if there is a need to introduce explicit error codes for these 2 scenarios.

1

How the TPP will store payer account details? Will there be a common standard for storing and encrypting this information and will this be covered in the data usage and retention policy for the TPP ?

TPPs data usage and retention policies must cover any cases that the TPP stores payer account details. The storing and encrypting of this information is not covered by the Standard and it is in the responsibility of the TPP.

1

Can the payer account information be stored as a proxy? If yes, how and where the proxy resolution will happen.

References to payer account as proxy have been redacted from the Standard at this stage. Adding this back will be considered in future versions.

2

There should be an active touch at the LFI before authentication takes place. It should not be automated/touchless then redirect. This is to avoid customer not paying attention and FaceID being taken without intention.

We agree, Face ID should not be invoked automatically in this case, but only after user request it. This ensures users will have enough time to review the payment information presented to them on the single screen. We will be adding an excplicit rule in the Business Rules to highlight this point.

2

Will there a possibility to modify the amount only for a Fast-track Single Instant?

No, the Open Finance Standard model does not allow the user the provide consent for a Single IInstant payment of a specific amount to the TPP and then change this amount when authorizing the payment at the LFI.

3

none

N/A

4

FEEDBACK

N/A

Bank Service Initiation

Payment Limits

1

Do the payment limits come directly from Aani or are they something specific to Open Finance and if they are Aani driven will the central hub move with the Aani payments limits) if for instance Aani increases them) or will it be up to the individual banks to perform that check.

There are a number of different limits defined for the Open Finance Standard. However, if your question refers to the maximum allowable values for Single Instant Payment initiation, these limits are in alignment with the Aani system as this is the underlying payment rails. These OFP limits will move together with the updates of the Aani limits.

1

And if the limits are coming from Open Finance, then how do we resolve a situation where there is a mismatch in OFP limits and Aani limits at the bank level, which limit prevail?

Aani limits prevail compared to standard BAU limits of the LFIs. This is because Aani is used as the underlying payment system for executing the payments. Standard BAU limits of the LFIs prvail to Open Finance limits., which are mainly in place for controlling the TPPs payment initiaiton behaviour and risk exposure.

2

LFIs should be permitted to restrict payment limits via open finance for the first 6 months, as the service is bedded in, to avoid unexpected fraud. This is a valuable learning from other countries.

Your feedback is noted.

2

Is the regulation factoring a velocity limit for individual customers – number of transactions?

Velocity limit for customers or number of transactions are part of the standard fraud detection checks performed by LFIs. The Standard does not provide for any fraud detection rules or processes but enables their implementation and execution by LFIs by providing data in the Risk Information block.

2

Will there a cooling off period for a high value transfer for a newly authorized / consented TPP? As a fraud mitigant.

Your feedback is noted. Currenlty, the Standard does not have any provisions in relaiton to cooling off period limits for high value transfers for newly consented TPPs. This can be reviewed and updated if deemed necenecessary.

3

none

N/A

4

As noted during the session - payment limits are somewhat dynamic, there is the total available daily limits set by a bank, but often the question will be how much of that limit is left that can currently be initiated? This will drive better UX - as rather than simply telling a user that a transaction “exceeds their daily limit” they can be signposted with “This transaction exceeds the daily limits with your bank. You have X AED remaining to transfer today”.

Your feedback is noted. We agree this is a valuable message to present to Users for the case of exceeding the daily bank limit/allowance. We will consider this proposal for future versions of the Standard.

Bank Service Initiation

Refunds

1

My first question feeds into the second.  How long should TPPs have to keep customers account details when a customer makes a purchase from a merchant using the TPPs services.  Is this use case modelled on cards? 

TPPs should ask for the payers account details only if the payer has initiated a refund BAU process and there is an undisputed requirement to refund the payment amount to them. Usually the TPPs would not need to retain the payers account details but there are certain cases where this may be required. For example, in the case that the refund is a partial refund, then the TPPs may decide to retain the payer account details in case further refund to the payer may be required in the future. The period that TPPs will need to retain the information depends on the T&Cs of the merchant with their customers, and the retention period should be enough to cover the return/refund period defined in the T&Cs. This is to be agreed between the onboarded merchant and the TPP.

1

What controls will the CBUAE impose on the data governance practices of TPPs in this scenario?

Existing rules and regulations for data retention and privacy will be applicable in this scenario.

1

From the implementation perspective of phase 1 do we now implement the modified SIP journey, including the provision for refunds?

Please refer to the implementation plan communicated via UBF.

2

More time needs to be spent with product teams and e-commerce stakeholders to define the use cases and rules around refunds. A journey/ standard has been shared without regard to the business rules, industry norms and likely usage / unexpected consequences. For example, a partial refund for an annual insurance is different from retail

The Open Finance Standard does not define specific methods which merchants must use to fulfil the refund requirements. So, all the existing BAU refund methods are still applicable. The Open Finance Standard is looking to enable merchants to initiate refunds for Open Finance initiated payments where there is an information gap and the merchant is not aware of the payer’s payment account details.

We agree that refunds processes may be operating differently for different types of businesses and that is the reason why the Open Finance Standard is flexible in terms of refunds fulfilment and only acts as an enabler providing all the information necessary for merchants to execute refunds.

2

Use cases need to be defined for when refunds are applicable and when TPPs are eligible to trigger a refund request

This is outside the scope of the Open Finance Refunds functionality. The BAU processes that merchants have in place for users to trigger refund request and the eligibility rules and terms are all dependant on the merchants processes and are not be specified as part of the Standard.

3

The process of receiving consumer consent for account details to enable a refund is clear. Please provide more details on how the refund can be initiated by the merchant.

SectionPayment Refunds | 5. Fulfilment of Refund Paymentsprovides all the details of available options for merchants to fulfil the refund request obligations.

4

We understand the current model is that merchants will not be able to see the source of funds (IBAN, identity connected etc.) before getting those details for a refund. When processing card transactions, merchants (or their PISPs) see name and card numbers - they are also able to reverse the transaction on the card network itself. We believe that merchants should be able to see the IBAN and a verified identifier (e.g. National ID Number and Name) associated with the transfer - this is particularly important for merchants that are required to check and verify the source of payments to prevent money laundering.

Your feedback is noted. However, we believe that merchants should not see sensitive payer information such as card numbers, IBAN or other forms of user identifiers without the need for it. On a need basis, such as in the case the the user triggers a refund request, the merchant can request their TPP to retrieve the payers account details from their LFI solely for the purpose of fulfiling a refund payment initiation. Depending on the model of fulfilment adopted by the merchant as per Payment Refunds | 5. Fulfilment of Refund Payments, the merchant may request the TPP to provide them with the retrieved payment account information or not (in case they just instruct the TPP to fulfil the refund). However, it is important to know that the refund can only be returned to the payment account used for making the payments and this is a vital requirement for reducing fraud or money laundering. The Open Finance Standard is looking to enforce this using our approach to retrieving the payer’s account information for the purpose of refunds.

Bank Service Initiation

Refunds

1

Yes we should have a fixed maximum window to process refunds, all merchants have a pre-defined return and refund policies, card schemes also follow a fixed timeframe after which a customer cannot raise any dispute for a transaction,

Defining a maximum window to process refunds is outside the scope of the Standard. It is up to the merchants to specify the return/refund rules and set pre-defined windows for accepting a return/refund request from users and proceeding granting this to users. The Standard is only an enabler in this case and is not looking to prevail to existing BAU processes. So, if a merchant accepts to refund a user, they can proceed with any functionality required by the Open Finance Standard.

2

Yes, the period of time within which a refund can be initiated should not exceed 31 days

We believe that this time frame will not fit all use cases in the industry. Please refer to the previous answer for pre-defined window of refunds.

3

Market driven may be best here, as the appropriate length will differ based on use case and vertical.

Agreed, this is why we believe that the Standard should not define this window.

4

No - there can be many instances where a refund request may be initiated months later - ultimately refunds are utilizing a streamlined SIP, and tying the identifier between the original transaction and the reversal (refund) is a gain for reconciling those events no matter the length of time between them.

Agreed, as stated in our previous answers.

Bank Service Initiation

Refunds

1

This is a big question. I think there should be a model that defines everyone in a transactions role and what their level of responsibility for the transaction is and should the TPP be at fault for a dispute then they should be help liable, same as every other firm in the banking/finance industry.

The liability model is detailed under Limitation of Liability Model

2

Please clarify the situation and current behaviour.

We will need clarification on this point.

3

Yes

Noted.

4

Chargebacks are a significant draw back for merchants on card schemes. Not only because they may lose the money that has already been paid to them, but also because they are often hit with a chargeback fee of around $15 which they pay regardless of a favorable or unfavorable resolution.

Dispute resolution should focus on two things in our opinion:

1. Clear guidance and framework for the evidence that MUST be kept (and for how long) and submitted in the event of a dispute so that responding to disputes can be automated.

2. Where a customer claim is found in favor of the merchant, the merchant and TPP should not be in a position where they are at a net loss due to dispute resolution fees.

The above being said Customers should not be incentivized to abuse the dispute resolution framework by having no penalty for abuse of the system - but that should not be at the expense of normal usage where a claim is unsuccessful and the customer incurs a liability. Systems such as rate-limiting the number of disputes a customer can make, or otherwise impeding improper use would be more beneficial in the long term.

The dispute resolution process is work in progress and we will be communicating once this is published.

We will ensure that the points raised in this feedback are addressed.

Bank Service Initiation

Refunds

1

Yes, the customer should be the sovereign of their data and must be able to determine if, when and why their data is used.  It’s an extra check box at worst.  

We will review this feedback along with that of other participants before we finalise on optionality. The current approach is that it will be mandatory.

2

We believe that refund for certain scenarios could be standardised so that a customer cannot opt out. The parameters for this should be agreed with industry and merchant bodies e.g., consumer e-commerce payments of a specific value range could be mandatory. But mandating refund details for scenarios where refunds will not occur (e.g., non-refundable transactions) would not be sensible. It could be open to abuse and mass refund requests.

Refund capability is also required for dispute resolution even when the transaction is non-refundable.

We therefore feel that it is essential for the TPP to have these details so that they can refund a customer.

3

No

N/A

4

No - for the reasons outlined at the top of this section.

N/A

Bank Service Initiation

Confirmation of Payee

1

Having done this in the UK, I do not think creating CoP from scratch is a small nor insignificant piece of work in itself, particularly with the added complexity of varying ways to do transliteration of Arabic names and even questions of percentage matches of names and if each participant determines “near matches” or if there is a central agreement.  I understand the appeal of having this be part of the ecosystem, but it seems like a massive project in and of itself.

We agree with the complexity part.

From a User experience perspective, it should be done at the TPP end rather than redirecting the user to the LFI to go through the authentication process to find out that the payee is incorrect.

Furthermore, in case of a long-lived consent with variable payees, this is critical functionality for the TPP to avoid human entry error and potential fraud scenarios.

Please note that at the moment, the Standard only specifies Exact Match or No match without a third partial match outcome. This reduces complexity for the initial implementation. Future versions of the Standard may introduce a partical match taking under consideration the complexity of trnasliteration of Arabic names.

2

Confirmation of Payee is one of the most critical use cases for fraud prevention and it should be one of the first to be delivered.

Agree

2

We should look holistically at the options proposed (re-use Aani, build new in OF, re-use CB database) and come to agreement on the best options short term and long term.

Your feedback is noted.

2

COP should have a masking feature. Character masked appropriately to avoid misuse especially around common names.

Currently, the response is a Yes and No based on match or no match. In the cases of Not exact match, the Payee Name returned is masked to avoid the misuse.

3

None

N/A

4

Confirmation of Payee should ideally include the following attributes: IBAN, Name and a hard identifier such as National Identity Number or Company Registration number..

We need further clarity on the provided feedback, especially on the purpose of requesting any additional fields for making a COP request.

The first 2 items are already included in the COP process. However, requesting a hard identifier for every payment consent or every single payment that is to be initated is adding an extreme amout of friction that would be a stopping factor to user adoption of the Open Finance Standard.

Bank Service Initiation

Confirmation of Payee

1

Yes, CoP should be anchored to the most substantial element of data available in my opinion.

Your feedback is noted.

2

We propose that IBAN is mandated for consistency.

Your feedback is noted. IBAN is supported but we believe that allowing users to use domestic accounts of 14 digits together with the Bank Name is a better customer experience and less error prone process compared to providing the 23 digits of IBAN. So, while IBAN is supported, we think that an additional option should be provided to users.

3

None

N/A

4

FEEDBACK

N/A

Bank Service Initiation

Customer Proxy Look Up

1

If this functionality has already been delivered by Aani, I think it would be a good idea to cross reference how this functionality will interplay with Open Finance.  In fact, it wouldn’t be a bad idea to cross reference all the Aani touch points with Open Finance, so the interplay and overlaps are clear to the banks undertaking this project.

Your feedback is noted. However, please note that Customer Proxy functionality has been redacted from this version of the Open Finance Standard.

2

Please confirm that all proxies on Aaní Overlay layer are supported.

Please note that Customer Proxy functionality has been redacted from this version of the Open Finance Standard.

3

None

N/A

4

FEEDBACK

N/A

Bank Data

Standing Orders

1

Direct debit

Your feedback is noted. However, our question refers to scheduled payments that users warehouse with their LFIs so they are Payer initiated payments. Direct Debits are collections and are initiated by Payees based on mandates agreed with payers.

2

Standing instructions is commonly used, but there is no consistent industry wide payment type corresponding to it.

Your feedback is noted.

3

None

N/A

4

Standing Order is the known term across the industry - mandated suggests ‘not unilaterally cancellable’

Your feedback is noted.

Bank Data

LFIs ingesting LFI data

1

Feedback

There is little information on how an LFI would register to do this, what information would be required and if it banks are required to do this (it was included in the list of things presented as “scope”) I think this requires quite a bit more detail before its ready, especially clarity on the point if the mandate requires banks to ingest data.

Do we then need to apply as TPP? Are we just demonstrating a technical ability to generate a consent request and accept data or the ask is a specific use case.

Need specific details o the data fields to be provided in the account information APIs, what data fields are required under products, transactions, parties etc.

An LFI is not mandated to ingest LFI data but may choose to do so by acting as a TPP. The LFI will be required to submit an application to do so, and will receive permission under a deemed license.

The data fields are available in the API documentation.

2

Please could you clarify the connection requirements for a LFI as TPP. Is the LFI required to connect a second time to Ozone for its TPP behaviour, or is the single LFI connection sufficient for both purposes?

Only a single connection will be required for the LFI.

3

None

N/A

4

FEEDBACK

N/A

Motor Insurance API Design

1

FEEDBACK

N/A

2

N/A

N/A

3

None

N/A

4

N/A

N/A

Motor Insurance API Design

1

FEEDBACK

N/A

2

N/A

N/A

3

None

N/A

4

N/A

N/A

Motor Insurance API Design

1

FEEDBACK

N/A

2

N/A

N/A

3

None

N/A

4

N/A

N/A

Common Rules and Guidelines

LFIs MUST connect all mandatory APIs to the Open Finance Platform and may provide direct access to TPPs

2

If Standards does not support direct access of LFIs to TPPs then does that mean LFIs can build bi-lateral connectivity directly with TPP?

If yes, then are there any expectations from the participants to update OFP of any transactions/exchange owing to this direct connectivity?

This section will be updated shortly.

Limits and Constraints

Max Authorization Time Window - Authorization window is defined as 30 days.

2

Where is the consent stored while in authorization window - at LFI or OFP?

All consent resources are stored at the OFP, which is accessible to the LFI to complete the Authentication and Authorization flow.

VRP related limits/controls - Mentioned as "to be confirmed in future"

2

Is VRP in scope for first release? If yes, when will OFP share the details with the participants?

The OFP specifications is due to be published Aug 2, 2024 .

User Experience Principles

The principle here is to ensure that the information that the User is presented with is kept to a minimum. If it is unavoidably necessary for the TPP and Sponsored TPP to convey more complex information, it is more likely to be read and understood when presented as a series of smaller amounts of information across more than one screen.

2

How does OFP define a "Sponsored TPP"?

In the workshop, it was mentioned that OFP will not support any agency model and will allow only direct participants either as TPP, LFI or entities acting as both TPP and LFI. There were examples of merchants who avail Open Finance services of TPPs but those were classified as “customers or partners of TPP”.

There is no market participant defined as “Sponsored TPP” for OF

Merchants will be customers or partners of TPPs that are onboarded by the TPPs through due diligence. They are the ultimate beneficiaries of the payments in that model.

Consent Management

Assisted revoke functionality

2

What is OFP’s view on extending Assisted revoke functionality to end users where the end users can walk into a branch or make a call to the contact center to revoke the consent?

Rationale: In Account Take Over scenarios

We feel this should be supported by the LFIs just as any other requests related to their online channels are supported when they walk into a branch or call the contact centre.

Consent Management Interfaces

Rendering suspended consent

2

Should a "suspended consent" be shown under "Current" and classified as "suspended"?

Yes as it is not expired but temporarily suspended

TPP Consent Management

The User-facing TPPs MUST inform LFIs that Users have Paused their Consents, and the Consent state “Suspended” MUST be reflected to the User in the Consent Management Interface (CMI) Overview page.

2

How will the TPP inform LFIs? Is there going to be a direct connectivity between platform participants or will Ozone act as an Orchestration layer?

A PATCH operation is available to change the status of the consent at the OFP. The OFP forms the system of record for consent, and will therefore prohibit operations from a TPP that reflect a suspended consent.

Reactivating a Paused Consent Journey

2

When will the wireframes be available for this journey?

We will publish this in the next minor release soon.

Once Users have clicked “Activate” in the Consent Management Interface (CMI) Detailed page, the TPPs MUST inform LFIs that Users have requested to Reactivate the Paused Consent. This MUST not require authentication of the User with the LFI or the Centralizes Authentication and Authorization App.

2

Every change to the consent status must involve authentication to capture the explicit intent of the customer for that action. Doing away with it compromises on security ethos of Open Finance.

We feel Pausing, revocation and reactivation should be managed by the TPP without any additional MFA friction with the LFI.

These actions should be undertaken with a MFA at the TPP end