Section

Sub Section

Participant ID

Feedback

Response

API Security

Overview

1

Specification are sufficient

Noted

2

Overview is concise and introduces the topics to be discussed further in the document.

Noted

3

No question at this stage

Noted

4

It is not directly associated with the API itself, but we believe all participants will need to undertake audits. If that’s the case , it will be good to document all of the requirements which are required to get the access.

The application forms and related documentation requests necessary for a TPP to become licensed will be made available.

5

NO, THESE SEEM TO BE ADEQUATE

Noted

6

None

Noted

7

FEEDBACK

-

8

No specific questions or feedback. We are broadly support of the direction of security profile being based on FAPI 2.0 and the OAuth 2.0 Authorization Framework.

Noted

9

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

2. FAPI 2.0 specification is getting mature with its updates. An observation on that, full message payload encryption is not considered in the standard but could be considered for UAE CB Open Finance specification.

3. Did you perform threat modelling on API security model and OFP platform and if yes, what are the outcomes of residual risks and risk ratings after security controls implementation?

4. Ozone API should support the required attributes for LFIs to detect and prevent fraud.

5. Utilizing the existing NPSS/Aani infrastructure (API, networking, etc.) has been the primary objective since the inception of the Open Finance initiative. Could you please clarify to what extent it will be reused?

1. This will be tabled for feedback in round 3 engagement.

2. Payload encryption is not required for FAPI 2.0 as no sensitive data is sent on the Front Channel, meaning that all sensitive data will be communicated via TLS protected endpoints, which already ensures all transfered messages will be encrypted.

3. The API Security is built upon FAPI 2.0, that is, everything that was defined on the FAPI 2.0 CBUAE is compliant with the FAPI 2.0 profile. This means that the Threat Model executed by the OIDF around both FAPI 2.0 and FAPI 1.0 and the Security Considerations can be used for this model, for example - https://arxiv.org/abs/1901.11520

4. The API standards will contain a risk block with metadata supporting LFI transaction risk analysis and fraud detection.

5. The options around this and the feedback have been articulated in some detail in conversations with the LFIs.

10

The API security model seems to be very banking specific, what variations should Insurance Companies expect in the overall security model?

The API Security Profile is data agnostic, that is, there’s no significant difference on the FAPI layer between Banks and Insurance companies.

Section

Sub Section

Participant ID

Feedback

Response

API Security

Security Profile - FAPI

1

FAPI is a comprehensive standard, might be a challenge in implementation.

For Data Providers we expect that the FAPI Layer will be implemented by the API Hub, and hence minimal effort to comply with FAPI is expected for the LFIs

2

Question: Has FAPI 2.0 been finalised as a standard? 

The reduction in optionality is desirable.

Security Profiles Section could do with a model or flow diagram. 

Under consent and management link, I assume this is a placeholder for a future document?

As of 24/04 the FAPI 2.0 WG is on their final definition round and expect to start the process to reach a final standard soon.

We have included a flow diagram on the second version of the Security Profile.

3

FAPI 2.0 is good option and Bank use it for other markets

Noted

4

Will it require additional OpenID certification?  For example, we are already certified by OpenID for FAPI 2.0 for our KSA entity. Do we need to obtain another certification for Lean’s UAE entity? 

The FAPI 2.0 UAE Profile will be different from FAPI 2.0 Vanilla or any other variations and as such, a new certification would be required.

We note that for all LFIs that will use the API Hub for sharing data and managing consents, The OpenID certification will be obtained centrally by the API Hub, so there’s no requirement to issue an individual certification.

For Data Receivers a new will be required.

5

NO

Noted

6

None

Noted

7

Need clarification on what is required on LFI end to ensure & maintain FAPI security profile. There is no clarity on roles & responsibility of what TPP is required to maintain & what LFI has to adhere to & what is the role OFH will pay in the middle. E.g JWKS endpoint who will maintain & who will call?

The FAPI Security Profile will be maintained by the Open Finance Hub, and LFIs will be required to integrate with the API Hub.

JWKS endpoints and certificates will be maintained and issued by the Trust Framework

8

No specific questions or feedback currently.

Noted

9

· Point 12 states "For consents that do not have an expiry, shall issue refresh_tokens without an expiration period, or, if not technically achievable, with an expiration period greater than 100 years.". Each consent must have an expiry set to a predefined period e.g. 2 years. This will allow user to reauthenticate and reauthorize the actions by reviewing. To overcome service disruption for its users, TPP could ask for consent renewal early. (As understood from April 17th call, consent refresh will be required which is 1 year at max. Documentation could be updated with clear explanation that there is no consent that will not expire.).

· OAuth2.0 and mTLS should be mandatory for all the parties who want to be part of Open Finance network.

· Implement Private Key JWT Client Authentication where clients signing JWT assertions using their private keys, which are then verified by the authorization server using the corresponding public keys.

· Implement scopes and claims to manage and limit access to specific types of data and services according to the permissions granted to the client.

· Use of PAR (Pushed Authorization Requests) to pre-register authorization requests before the client starts the authorization.

· Implement encrypted tokens (JWE) to ensure that token contents cannot be tampered with or read while in transit or storage.

· Use TLS1.3 where possible.

· Data masking techniques should be used for all sensitive data.

The reasoning behind the refresh_token expiration is based on experiences with both the UK and Brazil.

Both ecosystems started with a limited-time consent ( example: 12 months ) and transitioned to support consent with no expiration. When this change was rolled out, it was only possible for consents to be updated if they were initially created with a refresh_tokens that didn't include an expiration time. All other consents had to be revoked and recreated, something that could have been avoided if they were created with the change we are planning.

10

No specific feedback, we would like to understand variations expected for Insurance Companies?

The API Security Profile is data agnostic, that is, there’s no significant difference on the FAPI profile between Banks and Insurance companies.

The only difference should be expected on the Consent Journey, more precisely on the Authorization Request, that is, the Payload that is sent when the user is redirected to authorize its consent. In this case the authorization details for Insurance should be different from the one from Banking as what the user will approve is slightly different, however, everything else should be similar.

Section

Sub Section

Participant ID

Feedback

Response

API Security

Registration Framework

1

All is good

Noted

2

Reasoning around the selecting OIDC as a solution is sound as issues with DCR did lead to completely avoidable issues in the UK market. 

On the table, principle and reasoning it mentions cross boarder integration.  Is cross boarder integration something that is on the roadmap, or is it something we need to plan for in the nearer future?

How often is it envisioned that a Data Provider will request the list of all Software Statements?

The Registration Framework has been updated to clarify this point :

“It’s important to note that while there is an expectation of Cross Border Integration between Open Finance UAE and other Data Sharing Ecosystems, no agreements have yet been established by CBUAE, with this being a mid to long-term objective.”

3

No question at this stage

Noted

4

Do we impose having a dedicated dev portal for the banks? What security requirements TPPs / OFPs will need to be fulfilled to get the access to LFIs API. 

Dev Portal will be provided as a central service by the OFP.

From a purely technical perspective, TPPs will have to be FAPI 2 compliant RPs.

Additional operational requirements may be placed on TPPs - this is in the regulatory / compliance space and tbc.

5

NO

Noted

6

None

Noted

7

FEEDBACK

-

8

No specific questions or feedback currently.

Noted

9

· In the section "Reasoning around Selecting OIDC Federation as the base for this Profile", the statement "This approach aims to streamline the data access journey, enabling Data Receivers (e.g., Fintechs) to interact with Data Providers without the need for a pre-registration step." might give misunderstanding as TPP needs to be registered by a Federation Admin first, manually.

· In case an LFI doesn’t want to work with a TPP (e.g. TPP is not fully compliant), in current Federation Framework it seems not possible. What will be the solution for these cases?

Your understanding is correct. Once a Federation Administrator includes a TPP they are capable of easily connecting with a Data Provider. The documentation has been updated to clarify that we are talking about “Authorised Data Receivers”.

As for restricting individual TPPs from interacting with LFIs, this is not possible. Once the Regulator and the Open Finance Structure authorize a TPP to operate within the Ecosystem, they are allowed to consume data from any of the providers that support the data that they are authorized to share. If there’s an understanding that the TPP should not be authorized to consume data because of a specific concern, this should be raised to the OF Structure or the Regulator so their Licenses are revoked and they are blocked from communicating with any Data Provider

10

· No specific feedback, we would like to understand variations expected for Insurance Companies?

The API Security Profile is data agnostic, that is, there’s no significant difference on the FAPI profile between Banks and Insurance companies.

The only difference should be expected on the Consent Journey, more precisely on the Authorization Request, that is, the Payload that is sent when the user is redirected to authorize its consent. In this case, the authorization details for Insurance should be different from the ones from Banking as what the user will approve is slightly different, however, everything else should be similar.

Section

Sub Section

Participant ID

Feedback

Response

API Security

Certificate Standard

1

Fine as per standards

Noted

2

Certificate Revocation Process will be included in future versions of this document? 

The Documentation has been updated to clarify that certificates are expected to have a duration period of 13 months.

The Process around creating and revoking certificates will be included in the Trust Framework Operational Guide, which should be released by June/July.

3

No question at this stage

Noted

4

It is advisable to document and standardize the complete certificate lifecycle which means documenting process for renewing certificates, supporting multiple versions of the certificates (there might be a temporal need of using old and new certificate version)

For the Go-Live it’s expected that all supported certificates will follow exactly the profile mentioned on the guide.

Once the Platform is live we also expect to update the documentation to include all the relevant links for the Intermediates and Roots on the PKI.

As for the Certificate Management and Lifecycle this will be included on the Trust Framework Operational Guide.

5

NO

Noted

6

None

Noted

7

What will be connectivity between OFH & LFI  mTLS or via some other mechanism 

To begin with, mtls will be supported to secure the connection between LFIs and OFH.

We intend to introduce dpop as an alternative for LFIs to adopt in the near future (at their option).

The use of MPLS is the subject of a seperate decision paper and tbc.

8

No specific questions or feedback currently.

Noted

9

· 1. When will the link to Open Finance UAE Certificate Practice Statement become available?

· 2. What are the infrastructure and application layer protections for Ozone API Layer, Radium CA infrastructure and certificate management according to NIST SP 800-53?

· 3. What is the FIPS compliancy level for HSM to be used for CA certificates management?

· 4. How Radium platform's privileged accounts and their access will be protected, especially "Federation Administrator"? In case an account is compromised, what are the controls for detection and mitigation?

· 5. Regarding message encryption, the statement is "Message Encryption JWE (JSON Web Encryption) to ensure the confidentiality of messages exchanged between participants". The content to be encrypted is not clear and need to be defined. We would like to have full message payload encryption as it’s a standard used in today's leading payment providers.

· 6. RSA 2048-bit encryption or ECC (Elliptic Curve Cryptography) should be used for certificates.

· 7. Certificate pinning will help here to prevent MITM attacks or we can also push for mandatory usage for mTLS usage.

· 8. Certificate rotation and revocation should be in place.

1. The Open Finance CPS will be provided by September, a few weeks before the Trust Framework is fully live.

2. The Trust Framework Infrastructure (Raidiam) complies with ISO27001 standards. The Certification document as well as other clarifications around our Infosec compliance can be obtained on http://trust.raidiam.com/

3. Private Keys stored by the Trust Framework are set on an HSM with a FIPS 140-2 level 3 certification.

4. Access to the Trust Framework, regardless of whether the user is a Global Administrator or a Regular User will require password plus a TOTP second factor authenticator ( Example Google Authenticator ). If an account is compromised other existing administrators or Raidiam Service Team are capable of revoking the access of this user. Additionally, the Federation Administrator Role will be limited to the least possible amount of individuals.

5. FAPI 2.0 mandates mTLS, which requires all API calls to be sent via TLS, ensuring end to end encryption of all messages. There’s perceived additional security benefit to use JWE together with mTLS.

6. All Leaf Keys used on Open Finance will have a length of 2048 bits as per the Certificate Profile. For TLS 1.2 the following ciphers should be used as per the FAPI 2.0 profile
   TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
   TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
   TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
   TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

7. mTLS is mandatory as well as Certificate Bound Access Tokens.

8. Certificates will have an expiration period of 13 months, and we expect all certificates to be rotated at least a year.

10

No specific feedback, we would like to understand variations expected for Insurance Companies?

Noted

Section

Sub Section

Participant ID

Feedback

Response

User Experience Principle

General

1

User experience is essential for so many elements:

1. To keep it simple

2. Improve accessibility

3. To be transparent

4. Maintain consistency

5. Provide logical navigation

6. Use clear language

7. Support your customers

8. Improving user experience with app-to-app redirection

Noted

2

The current UX principles are fine and clearly set expectations on how to design a friendly and informative transaction journey for a user while using Open finance services.

But to increase the overall awareness, and trust in Open Finance among the users TPP/LFIs need to establish an information repository or a help centre for their customers (can be bundled with the consent management page) where users can get access to:

1. FAQs on Open finance related processes

2. Best practices to identify and avoid fraudulent transactions

3. Redressal mechanisms in case of any dispute/fraud or any other unforeseen issue with appropriate email ids and phone numbers to lodge complaints with the concerned TPP/LFI (inline with the dispute mgmt. procedures enforced for OF)

4. Information regarding data usage and retention policies if the consent is revoked

And this information page can also be templatized/standardized across TPP/LFI so the user is comfortable seeing similar information across participant interfaces, and this will help generate more trust in the platform and clampdown on misinformation by bad actors.

A website will be made available from the Open Finance Company when established which will contain this type of content.

3

No question at this stage

Noted

4

While it’s good to have a good text description as it’s in point no 3. It would be useful for participants to see sample designs which should be followed by TPPs, OFPs, LFIs.

While the expectations are clear from the MUST and SHOULD statements. There is too much subjectivity in the language as proposed. The standard should outline what specific information must be presented to users, and where applicable the correct terminology to use to describe that information - terms like ‘straightforward and easy to use interface’ leave a large amount of gray area both to TPPs and LFIs which can become somewhat unenforceable.

Sample designs with CBUAE branding will be available. Time lines to be confirmed.

Section 3 has a detailed textual description of the main user experience principles that the Standard follows and that participants must/should follow when designing their user experience. Samples of the designs are shonw in the wireframes in the Banking Service Initiation and Data Sharing pages.

The page in section 3 only documents the principles at a high level. The Service Initiation and Data Sharing pages in the Banking section provides the exact information that must be dsiplayed to the users by TPPs and LFI during each differct consent scenario. Similarly, it provides the correct teminology and language to use to each user screen.

5

NO

Noted

6

None

Noted

7

Provide the sample “approved” content of the Consent information page. For example, the requirements for the Transparency, Trust and Sense of Control are very robust in terms of information provided – but then mentions as unhelpful element “Where there are fewer screens but a significant amount of text on the screen”

Sample “approved” content is included in the wireframes in the Banking Service Initiation and Data Sharing pages.

8

Principles should be exactly that – principles, not regulations. On the basis that the ‘Use Experience Principles’ are provided and governed as ‘principles’ (and not prescriptive mandates), we are broadly in line with the proposal.

However, LFI’s as regulated entities are obliged to do whatever they deem necessary to protect their clients and themselves against risk and fraud and the principles MUST be broad enough to enable LFIs to carry out this duty. An example may be additional step-ups in authentication (based on the LFIs own risk assessment) to validate the authenticity of a consent request. In some cases, this may add additional friction to the flow, but this would be by design, in order to raise the threshold required to appropriately validate the user/request. LFI’s MUST have discretion to authenticate users/consent requests, as they deem appropriate, and consistent with, the measures they apply to their own channels.

We operate in a multi-lingual market; however nothing is covered in the principles with regards to language preferences. We should consider a language parameter in the consent interaction, to enable English or Arabic language preferences to be handed from the TPP to the LFI, to ensure a seamless experience. It is possible that users may have an Arabic language preference on their LFI channel, but be coming from an English TPP site/service (or vice versa) – we need to consider how to handle such scenarios (e.g. should the session override the existing channel language preference).

Noted

The key principle here is that of parity between direct and API channels - there should be no additional friction carte blanche for all transactions initiated through API channels.

LFIs will have the flexibility to apply additional authentication where appropriate based on risk factors. LFIs will be measured on successful authentication rates across channels and will need to demonstrate that risk measures are commensurate and not barriers.

The multilingual aspect is noted. LFIs could utilise the same measures that they utilise on their direct channels (e.g. http accept-language headers that are set by browsers) to provide an indication of preferred language

9

We suggest the summary information step for vulnerable users should be provided to all users for the first time they use open finance.

· Do the User Experience Principles ensure accessibility for users with disabilities or special needs?

The summary information step is specifically designed for usage by vulnerable users, who may not be in a position to get informed appropriately for the use of Open Finance. For standard users, the information and education about Open Finance must be performed by the ecosystem participants.

No, the current user experience example wireframes do not cater for users with disabilities or special needs. LFIs and TPPs are expected to adapt their UX to accommodate for these users.

10

1. For Informed decision making, is AI expected to be play a big part in the open finance platform?

2. Is Single Sign on Integrations expected between TPPs and LFIs? Will this be facilitated by the CB UAE or will integrations need to be done individually with each TPP?

3. Every LFI and TPP have their own CX/UX Principles, how does CB UAE aim to consolidate this across all LFI or TPP on the Open Finance Platform?

4. This is very banking specific and what can Insurance companies expect here?

1. No use of AI is planned in the current release. On the Ozone roadmap, we are reviewing the use of AI to deliver a natural language search on developer portals and for querying report data. This will not result in additional work for LFIs.

2. Single Sign On is a capability provided in form of the Centralised Authentication and Authorisation Centralized Authentication and Authorization (Federated)

This is an option for LFIs that do not have mobile channels or that are not able to offer the mobile authentication experience.

3. The service CX/UX will be monitored and any corrections managed through CBUAE Supervision regime where necessary. Certain screens will be mandated to be in a standardized format, for particular parts of the journey.

4. A section specific to insurance is included in Standards V0.1 Draft-2.

Section

Sub Section

Participant ID

Feedback

Response

Consent Setup

General

1

It is recommended to have in the consent for audit and compliance matters.

On the other hand, For any payment, purpose is mandatory for initiation by the LFIs, which will be part of the payment initiation request.

So, shall TPP collect those mandatory from the user and pass it in the payment request along with others parameters to LFI through OFP?

Alternatively, when user authenticate the payment request in LFI app, LFI to display the additional fields needed and then execute the request (example; in single payment request)?

Having said that for consent standards for TPPs for look and feel and user journey through its app.

The purpose for the consent if included will be sent by the TPP. This purpose is around the kind of use case that the Open Finance request is made for example, Account Aggregation, Personal Finance Manager,Tax Filing, Wallet Topup, P2P etc

This is not to be mixed with the purpose which the user is asked to enter by the LFI for example in an international payments etc. That purpose which is specific to use cases like international payments or SME payments will also be sent by the TPP as part of the consent.

2

Having a predefined list of purpose statements is a good idea to codify the consent structure,

For payment transactions we can create a multi-level classification, level 1 will indicate participants in the txn and flow of funds (left to right) (example given below)

1. Customer to Business

2. Customer to Govt.

3. Business to Business

4. Business to Govt.

5. Govt to Customer

6. Govt. to Business

7. Business to Customer

On Level 2 will be single payment or multiple

And level 3 will have a brief description explain the context (this can be a free text field to be entered by TPP)

The way the consent table is designed in the multi payment section of the shared document is a good example.

But for data sharing request it might be tough because we will have to think an exhaustive list of business use case and codify them, and still make a provision to accommodate new use cases in future.

Question: What are rules regarding Consent request expiry (authorization request expiry)? consider a scenario where a consent request is triggered and customer has not approved it, till when the consent request will remain valid.

Question: This was raised in the workshop as well, in case of accounts that require multi-level authorization (joint a/c or business a/c), what happens if the authorization request expiry is reached but all consents have not been granted?

Question: In case of multi-level authentication, how does LFI keep the TPP informed of consent progress, just one time update of consent granted when all approvals are in place, or approval by approval communication to TPP (ideally this should not be recommended because this is a risk revealing a client’s approval matrix to the TPP)

Agree that the purpose needs to be a codified list and it will be on the lines of

Account Aggregation, Personal Finance Manager,Tax Filing, Wallet Topup, P2P etc

We will consider your input on also indicating the participants as part of the coded list.

Re: Authorization Request Expiry: The consent authorization request expiry is defined by the TPP as in Common Rules and Guidelines | 8. Authorization Time Window

Re: Multi Authorization

The consent will move to a Rejected state as explained in Consent Setup | 4. Consent States

Please refer to the section which details the flow for multi authorization

Common Rules and Guidelines | 18. Multi User Authorization Flow

Re: Notifications on Multi Authorization

Please refer to the following two sections which details on how the TPP is notified. The TPP will receive the list of pending authorizations.

Common Rules and Guidelines | CRG 17.4 Multi User Authorization Flow Notifications and

Common Rules and Guidelines | 18. Multi User Authorization Flow

The TPP will be able to inform the LFI if they want to support a multi-auth flow and the expected timeframe in which they expect all the authorizations to be complete. The TPP needs to know the different authorization states to fulfil their use case.

We will consider including a guideline where the LFI can inform the user that the information will be shared with the TPP about the pending authorizations.

3

Needs further analysis

Noted

4

Yes, it will be easier if more things are standardized.

Noted

5

YES

Noted

6

Consent Setup | 3. Consent types For Single use Consent for Customer Data, need clarification on when will the Consent reach Terminal state after Authorization [is it based on time hour/min or once all of the resource is accessed eg. Account, transaction]

Noted - this will be clarified in a future draft

7

1. Will there be different type of consent other than Account Information for the data access? F.e. Beneficiaries?

2. Will there be different type of consent than Single/Multiple payment? S.a. Credit repayment?

3. Validity of long live consent

4. Is there a cap on number of consents per TPP

5. Can the consent be modified

6. For raising suspension what will be the process

7. Which consent supports user induced payments like vendor payments, bill payments etc

8. For change & update in the consent what is the detailed workflow. If consents are immutable.

1. Data sharing will be based on the cluster(s) of data requested by the TPP as explained in Customer Data | 6.3 Data Cluster Structure & Language

2. Single and Multi Payment are differentiated based on the duration of the consent whether it is Single use or a long-lived. These can support a range of TPP payment use cases including Credit repayment.

3. The validity of long-lived consent will depend on the Consent Expiry as well as the control parameters and the schedule which are setup based on the type of long-lived consent. Examples are detailed for payments under Multi-Payments | 6. Multi Payments Common Rules & Guidelines

4. There is no such cap

5. Yes. For details refer to the section on Consent updates under Multi-Payments | 5. Consent Updates

6. The process will be published in a future engagement.

7. Both Single and long lived consent can support these use cases.

8. For details refer to the section on Consent updates under Multi-Payments | 5. Consent Updates

8

We believe users would benefit from a predefined, industry accepted list of ‘purpose for the payments’ and ‘data sharing’ – at least at the beginning of Open Finance rollout, to help educate user through standardisation. While TPP business models will vary, the underlying consent mechanics are the same and users may find it difficult to compare services/consent if there are significant different descriptions (to the same underlying services) across TPPs (and LFIs for that matter).

Furthermore, we believe that the industry should develop ‘plain language’ labelling to signal and differentiate between ‘single’ and ‘long-lived’ consent. A suggestion might be ‘one-time’ vs. ‘ongoing’ consent – this is important to ensure (a) users understand how long they are consenting for; and (b) we have a simple and consistent way to describe consent models across TPPs and LFIs.

Take this one step further, and such an approach would support the establishment of central knowledge repository – provided by the CBUAE – to define the industry accepted ‘purpose for payments’ and ‘data sharing’ lists; the nature of ‘one-time’ vs. ‘ongoing’ consents; how consents are managed and changed across TPPs and LFIS; and potentially a list of all TPPs and the services they are licensed/authorised to provided (i.e. and linking to the information above). This can act as an independent and trusted source for users, to help them navigate the nuances of Open Finance.

In General Consent Rules, the specifications talk of a scenario where the TPP is not the user facing entity; however past conversations with CBUAE have indicated that TPPs must act as principal and face the user directly. Please clarify this. We understand that TPPs can provide services for others, however it is not clear who the user will face and how services will be presented to uses and LFIs (in terms of consent authorisation).

Further clarification is required on the nature and obligations of consent management ownership. It has been discussed the OFP will provide banks the means to ‘manage consent’ as part of the LFIs ‘extended infrastructure’ – which we understand as being a ‘consent-as-a-service’ capability provided by OFP. LFIs should retain ultimate accountability for consent as a gatekeeper and data protector of its clients – however given that this will largely be facilitated by OFP, liabilities must be clarified and agreed before any model can be set.

Finally, we acknowledge that LFIs should not allow users to change an active consent via the LFIs consent management interface/dashboard, however LFIs MUST allow users to revoke consents from LFI consent dashboards. The LFI is the trusted financial provider to the user and should act as a trusted partner for users to view and revoke, consent requests (this is particularly critical in the case where TPPs make the process complex or prohibitive). We understand this is the case – however we wish to reemphasis the importance of this capability.

Agree on the standardization.

Agree on the “plain-language” point

An example of TPP not being end-user facing is that of a merchant using a TPP to accept Open Finance based payments. The merchant will present the consent which has to mention the TPP to whom the user is consenting to.

We are in the process of finalising the market participants roles, specifically around support for 4th parties that leverage the services of TPPs to fulfil their use cases.

The users can revoke the consent from the LFI consent management interface. Please refer to

LFI Consent Management Interfaces | 3. Consent Revocation Journey

9

Yes, however predefined purposes should not be overly restrictive or limit users' ability to customise their consent preferences. There should also be provisions for users to specify custom purposes or provide additional context when granting consent.

· Question: why can’t we use the single-use consent for an FDP? It can be scheduled, and the request sent to the LFI, and no more consent is required as ongoing. For a single FDP, long-lived seems over-consenting and opens up risk with regards to misuse of a consent.

· Consent suspension: it is not clear why it is necessary to have consent suspension. Is it not sufficient to revoke the consent and request a new one once the fraud is mitigated or suspicion removed?

· 5.10: change parameters in LFI. Is it a valid use case for a user to reduce the scope of a consent in the LFI’s CMI? E.g. I shared 2 accounts, I changed my mind and now I only want to share 1. A new consent could add friction.

Re purpose - Agree on point 1

Re FDP - We have updated the content now for FDP to be using a single-use consent.

Re Consent suspension - A suspension state is included to offer flexibility for handling suspensions on individual consents. The LFI can for example verify by calling the user or expect a response to an SMS to clear the suspension. By only having revoking as the option it leaves no choice to the user other than having to go to the TPP and initiate the request again.

Re consent update - Consent can only be revoked from the LFI dashboard, it cannot be updated.

10

How long are consents valid for or is it expected to carry them out at every interaction with Insurance Companies?

Consents for insurance data sharing will be one-off and will therefore require a new consent for each data sharing request.

Section

Sub Section

Participant ID

Feedback

Response

Consent Management

Overview

1

It could be both aligning the standards and regulations of what to display. Since it depends on the nature of the service that TPPs would provide and requested from LFIs.

Taking into consideration time to market, unification of main consent service that would be the first step of any request.

On the other hand, information and language presented to the users in TPPs apps, this could depends on how TPPs would display to users matching the nature of provide services.

Noted

2

Consent management interfaces should be standardized in terms of information and language presented to the user and guidelines should be laid out on how it will be displayed to the user.

But the participants should have freedom to design the look and feel of the interfaces because it should be inline with the overall brand/design language of the app or website being used by LFI or TPP

Noted

3

Needs further analysis based on more details re: standardisation

Noted

4

We believe that the information to be displayed should be standardized and regulated - however the opportunity for UX innovation and improvements will be lost if it is a set regulatory screen.

Noted

5

YES

Noted

6

None

Noted

7

Only the information and language

Noted

8

Consent Management Interfaces (CMIs) should NOT be standardised, as these should follow the inherent design systems and styling of the respective LFIs. Consistency and predictability of user experience within an LFI is something many LFIs have worked hard to building for their users over time; therefore, provided that CMIs standardise on language criteria ONLY (as we provided feedback on earlier); and align to the User Experience Principles; standardisation on look and feel is NOT required and should NOT be mandated. We would however, recommend a standardised approach to labelling/presenting each LFI (together with a logo), so that as an industry we have standardised labels for LFIs and how they are presented, to users, in each CMI.

The standardization is expected on the user experience (how easy it should be accessible, the number of screens, unnecessary friction etc ) and the content and the labelling of content to be displayed and not on the UI (look and feel and branding)

9

1. Naming of CMIs

· Naming of Open Finance Connected Services. This is ambiguous. Service is also a type of open finance action (service initiation). It is possible that the service provided by a TPP is data visualisation and not a ‘service’ as denoted by TPPs for service initiation. Basically, rather than say “click to view the services you have connected your account to” it could be “click to view the TPPs whose services you have connected your account to”.

Do you think that Consent Management Interfaces should be standardised in the look and feel or only on the information and language presented to the Users?

· Only on the information presented. We would like to be able to customise and brand our CMI in line with own design/policies.

Noted

10

I feel it should be standardised to an extent to have consistent user experiences across the board

Noted

Section

Sub Section

Participant ID

Feedback

Response

Consent Management

Overview

1

Users to have this option in order to give them the choice of managing their consent(s) with any TPPs or LFIs.

A user can manage consent(s) from a TPP app or from LFI app. In this case and since OFP is the single source of truth for consents, then the changed consent has to be updated in OFP when its been changed by a user either from TPP or LFI apps. So for any future request, this consent has to be validated whether it’s valid or not.

In this case, an update consent API shall be available for such cases.

On another point of view, since open banking approach of giving users the opportunity to manage their accounts, payment, etc. from a TPP app, and this would happens only when user gives consent from TPP and approves from LFI, then managing consents can be done from TPP side in once app place rather than changing consents in different LFIs apps. Taking into consideration that OFP in the middle entity for such communications sand validations.

Noted.

Our current view is that consent must not be updated from the LFI as this adds too much complexity and may have unintended consequences for TPPs in supporting their use cases.

We are collating more feedback on this.

2

For long standing consents both data sharing and service initiation, we should allow a user to revoke/renew his consent from TPP as well as LFI interface.

For any other parameter change he should go to TPP interface to make the change, for example changing the amount for a multi payment fixed amount instruction or minimum, maximum transaction limits for a Variable recurring payment instruction.

For single instant consents the assumption is transaction is executed in real time so there is no possibility of recall or rollback

Question: What are the various consent parameters available for the customer to update if he wants to modify the consent, accordingly the impact of each can be analysed and decided if change can be done at TPP or LFI end. And this list needs to be classified under data sharing and service initiation consents.

Our current view is that consent must not be updated from the LFI as this adds too much complexity and may have unintended consequences for TPPs in supporting their use cases.

We are collating more feedback on this.

For consent update from TPP please refer to Multi-Payments | 5. Consent Updates, https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528609/Customer+Data#5.-Consent-Updates

3

Needs further analysis

Noted

4

It's our opinion that users being able to change consent parameters can create confusion both for users and for market participants. Consider the existing wireframes with ‘Active’ and ‘History’ tabs for consents - within each of the consents you would also need to provide a historical log of changes that have taken place with that consent.

It is much simpler to have an immutable log of current and previous consent parameters. Consents should be immutable and users should have only permission to revoke the consent and create new if needed - that will provide consistency. But both these operations should be doable from TPP and LFI side.

Agree

Our current view is that consent must not be updated from the LFI as this adds too much complexity and may have unintended consequences for TPPs in supporting their use cases.

5

YES

Noted

6

None

Noted

7

The authorized consents should be immutable. They can only be revoked by the user or TPP.

Will there be a state “REVOKED” when consent is revoked by either TPP or user?

Yes there is a Revoked state

8

We believe that allowing users to change consent parameters from both TPP and LFI CMI may create unnecessary complexity – at least at the beginning of Open Finance implementation and adoption. Provided that LFIs can allow the revocation of consents from their CMIs, this will suffice for phase 1.

In the workshop, there was a centralised consent app concept (CAAP) shared. We understand that this is intended to serve smaller LFIs who may not wish to build out dedicated consent services and/or who do not have web or app channels. We also understand that this will not be mandated for LFIs who offer their own consent management service (& CMI). We strong support this ‘non-mandatory approach for LFIs’ and would like this to be documented.

Also note, we have no objection to the use of Open Finance Connections; Connected Accounts; and Connected Services – as a labelling taxonomy. If a broader scheme name is developed, then potentially ‘Open Finance’ can be replaced by the scheme name.

Agree

Our current view is that consent must not be updated from the LFI as this adds too much complexity and may have unintended consequences for TPPs in supporting their use cases.

Re CAAP - Noted and we will update to content

9

· No, we think the consent should be managed primarily by the LFI as gatekeeper to their financial data and services. TPP could have secondary access through the LFI’s APIs. The consent should be impossible to tamper with or manipulate except for a user’s request to their LFI.

· Consent “expiry times / time windows” can be separated into “non-payment consents” and “payment consents”. As payment related consents are in a different risk profile, they must be shorter in duration.

· "Max Authorization Time Window" and "Max Submitter Authorization Time Window" set by TPP. After completion of these a payment can be initiated. These time windows should not be set by TPP as LFIs are risk owners for payments.

Our current view is that consent must not be updated from the LFI as this adds too much complexity and may have unintended consequences for users and TPPs in supporting their use cases.

Re: Consent “expiry times / time windows” - we will consider this feedback and assess if this needs to be included in the standards.

"Max Authorization Time Window" and "Max Submitter Authorization Time Window" are included to aid the TPPs to

cater to scenarios where the user has been redirected and they take too long to authenticate/authorize the consent. Similarly for multi-authorization scenarios.

For example for a in-store payment, the TPP would expect a short “Max Authorization Time Window” after which they can simply abort the transaction. These cannot be set by the LFIs

10

Yes they should be as this is an important principle of Data Standards.

Our current view is that consent must not be updated from the LFI as this adds too much complexity and may have unintended consequences for TPPs in supporting their use cases.

We are collating more feedback on this.

Section

Sub Section

Participant ID

Feedback

Response

Consent Management

TPP Consent Managementew

1

In the demo presented, it shows that TPPs will display to the user the reasons or purposes of such consent, and what TPPs will do with the data shared or accessed and this is according to compliance regulations of transparency,

This would cause users panic when reading such disclosure before submitting the consent request, which will let them rethink of proceeding with the request or not. So is there a unified standards of this kind of presenting the reason of data sharing or TPPs have their own way to display?

Can User select number of days the consent is valid for?

Is there a cap of consents requested by TPPs? What we meant in here in case of fraud cases, would be there monitoring and alerting in OFP for such?

If yes, how the procedure would be for alerting TPPs or LFIs? In addition, what is the action taken?

Corporate can use TPP app to register and submit consent, how the treatment would be for corporate VS TPP since it has different elements of being a consumer user?

Re Purposes - Noted. We will look at providing guidelines to TPPs. The purpose itself will be codified rather than free text.

Re Consent validity - This is not a mandatory capability and it would be for TPP based on the use cases they support if the want the user to be able to specify the number of valid days.

Re Cap on consents - There is no cap on the number of consents requested by a TPP.

The OFP will not carry out fraud monitoring - this remains the responsibility of LFIs and TPPs.

In the case of compromise, TPPs can revoke their certificates on the directory which will stop their access to the LFIs.

2

As the customer initiates all consent journeys from a TPP interface and in case of long-standing consent it’s the TPP who is responsible for initiating the transaction requests using the consent, a customer should be able to modify all possible consent parameters from the TPP interface

Question: The single instant consents (data sharing and service initiation) will always show in history section of consent mgmt. dashboard because they are always executed in real time?

Question: What are the various consent parameters available for the customer to update if he wants to modify the consent at TPP interface

Yes the TPP is responsible for initiating the transactions using the long-lived consent.

Yes, single instant consents will always show in the history section of consent mgmt.

For consent update from TPP please refer to Multi-Payments | 5. Consent Updates

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528609/Customer+Data#5.-Consent-Updates

3

·Section 2.2 – Rules & Guidelines ID ‘3’ Consent State (“Awaiting", "Authorized", "Rejected", "Canceled" or "Finished") – States highlighted in red are not aligned with defined ‘Consent State’ in Consent Set up. Please clarify the which one is the right states?

Please refer to the updated content on Consent states at

Consent Setup | 4. Consent States

4

5

NO – BUT TPPs must be accountable for any consequences of data breach, which could cause a legal liability to the LFI

Noted

6

None

Noted

7

FEEDBACK

-

8

While we agree with the principle to clearly separate ‘Data Sharing’ and ‘Service Initiation’ consent types, these should roll up to a single, entry point (in the shape of a dashboard or summary page etc), such that TPPs offer a single entry point into their services/consents obtained and users aren’t required to navigate to separate areas/pages to view/manage different consent types. We believe this is addressed in 2.2 (ID2), but for completeness we mention here again.

TPPs should be very narrow on the data they are facilitating consent for, such that it should be the minimum data required to full the service provisioned i.e. TPPs should not seek data beyond what is require for their service and should be explicit in demonstrating/communicating this to users. This should be achieved through (a) clear consent justification – linking consent to specific services provided; and (b) narrow API specifications, that only demand the minimum data/parameters required, to complete the service (i.e. optional fields should not be mandated for implementation or testing).

We propose that consent should be provided for a maximum of 180 days, for the following reasons: (a) this is broadly in line with many LFI back/future dated serviced (such as statements or payments); (b) this time period is more than sufficient time to enable TPPs to demonstrate their value to the user; and (c) this time period is not so long, that users forget about the consents they have provided and/or the paid services they may have subscribed to.

We propose the use of ‘Pending’ rather than ‘Awaiting’ as the label for the first (pre-authorized) state, as this is more logical to end-users.

Point number 4 refers to scenarios where TPPs are not the customer/user-facing entities, however past conversations with CBUAE have indicated that TPPs must act as principal and face the user directly. Please clarify this; in particular who is obtaining consent and for what (i.e. a non-OF licensed business should not be able to obtain consent to receive data or initiate payments – and if this flows via a licensed TPP, then who is consenting to whom and where to liabilities reside in the case of a dispute or fraud)?

Noted and agreed

Maximum duration is to be confirmed.

9

·There should be operational forums where consent success rates and challenges are reviewed by ecosystem parties in BAU.

· What happens if user see consent revoked at TPP end but TPP failed to complete the action and user got compromised, and consents are abused by attacker? Rules, penalty and financial responsibility on this revocation failure needs to be set and TPPs could take preventive and detective actions against this.

· When consent revoked, what will happen to already obtained data at TPP end especially for data obtained via "Data Sharing Consent"? In the "Rules & Guidelines" table, this is not clearly defined but stated as "TPPs MUST ensure that they are fair and transparent about how existing data is processed and that no longer required data is deleted, where appropriate, in accordance to any relevant laws and regulations.". This is a critical action on data which should not be open on interpretations by different TPPs. Therefore a structured approach which is compliant with UAE laws and regulations could be part of the specification.

· Data lifecycle and retention time with deletion/truncating rules and timelines and TPP actions must be defined in the specification with data elements clearly addressed.

· As stated in the Rules table "TPPs offering Service Initiation MUST provide the Service Initiation transaction details within the transaction log depending on the type of Service initiated.". Based on that, detailed service initiation usages, e.g. history of money transfers, must be available to be reviewed by User in case of suspicious activity concern.

-Re operational forum : Noted

-Re consent not revoked by TPP - These scenarios will be covered under the liability model which is a work in progress.

-Re already obtained data - For this TPP will have to be compliant with the UAE laws on Data protection that already exist as they do for any other data received through other non OF channels. The specification cannot monitor and mandate this.

-Re Data lifecycle : The same UAE laws on Data protection will apply in this case. The specification will not be adding any additional rules.

-Re history : Noted

10

· With respect to the wireframes shared, are these set in stone or they can be changed to improve overall experience?

· Are TPP responsible for these consent? Are we expected to get separate consent for TPP and a separate one for LFIs?

We are prescriptive on the user experience ( how easy it should be accessible, the number of screens, unnecessary friction etc ) and the content and the labelling of content to be displayed and not on the UI ( look and feel and branding).
Any suggestions to improve the UX are welcome.

Section

Sub Section

Participant ID

Feedback

Response

Consent Management

LFI Consent Management

1

If a user rejects the consent request in the LFI app, the response is sent to OFP, in this case, there would not be a token generated and sent back to TPP, is it?

In rejection consent scenario, would be there option for a user to share why he rejected the consent to OFP? How OFP would take such feedback and analyse for future arrangement among TPPs and LFIs?

Would be there validity on consent send to LFI, if a user did not approve or reject with X time, would be it be expired? If so, how OFP would be updated or it will consider no consent is granted?

Can LFIs set time limit of received consent requests?

Can LFIs set cap of requests for each TPP they deal with for certain request if applicable?

If LFI sees that certain TPP is at risk on it, what is the procedure in this case with OFP?

Do LFIs have the right to reject a request from OFP before displaying to User? This would be in case of validating the received request.

What LFIs space given for consent management or shall they rely and trust on OFP received request and that is it?

If consent is rejected by the user at the LFI then the response back to the TPP will have the rejected status.

Re rejection of consent - There is no provision for adding a reason for rejection of consent. We will assess this feedback for future releases.

Re validity on consent - Please refer to Authorization Request Expiry defined by the TPP as in Common Rules and Guidelines | 8. Authorization Time Window

Re limits: Any BAU limits of the FI related to payments will apply. for ex maximum single payment transaction amount, total transaction amount in a day across all channels.

Since there is no precedence for data sharing there cannot be any additional limits applied by LFI for data sharing requests

Re TPP risk : This will be elaborated in the operational model and liability framework which are work in progress

Re rejection by LFI : There needs to be a valid reason for doing this like real fraud or security concerns and the user experience needs to be managed.

Re consent management : In case of the user being authenticated by the LFI the consent will be authorized at the LFI and then passed to the OFP. Thereafter the Consents will be stored and managed by the OFP. The LFI’s can also create their own copy of this for any internal processes.

2

A customer should be able to revoke or renew any long-standing consent from LFI consent management interface, for any other modification in consent parameters it should be done from TPP interface only

Question: The single instant consents (data sharing and service initiation) will always show in history section of consent mgmt. dashboard because they are always executed in real time?

Question: What are the various consent parameters available for the customer to update if he wants to modify the consent at LFI interface

Question: In case of service initiation consents detail page, why the creditors account number displayed, a corporate using service initiation to collect payments from his customer will not want to display his account details to its customers, we should remove this filed or at least mask the account number and display only last 4 digits

Re Consent revocation: Agree. We are not supporting renewing from the LFI yet.

Yes, single instant consents will always show in the history section of consent mgmt.

For consent update from TPP please refer to Multi-Payments | 5. Consent Updates

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528609/Customer+Data#5.-Consent-Updates

Re : creditors account number - This is displayed optionally based on use cases( e.g P2P payment). It’s not mandated to display it.

3

· Section 2.2 – Rules & Guidelines ID ‘3’ Consent State (“Awaiting", "Authorized", "Rejected", "Canceled" or "Finished") – States highlighted in red are not aligned with defined ‘Consent State’ in Consent Set up. Please clarify the which one is the right state?

· Section 2.2 – Rules & Guidelines ID ‘12’ – Is there any duration limit where Bank MUST provide a record of all past connections? Or it will be since inception of user account? 

Re Consent states - Please refer to the updated content on Consent states at

Consent Setup | 4. Consent States

Re duration limit on the history of connections: The BANK must be able to provide all past connections of a user authorized with them.

4

There should be an easy way of notifying TPP when the user revokes the consent on LFI side - For example using webhooks for notifications.

This notification is not included in the current standards as the TPP can always check the status of the consent. We will assess industry feedback to see if this notification needs to be included.

5

NO

Noted

6

None

Noted

7

1. For change & update in the consent what is the detailed workflow.

2. Are consents immutable?

3. Who will create consent id?

Consents are immutable

It will be possible to revise some elements of a consent by referring to the “base consent” the first consent in the group

TPPs generate the consent id

8

We propose the use of ‘Pending’ rather than ‘Awaiting’ as the label for the first (pre-authorized) state, as this is more logical to end-users.

In point: 2.2 Rules and Guidelines (ID12) – we propose to place limit on the number of historical records available for past connections (e.g. 2 years).

Re limit on the history of record: Noted, we will consider setting some limits in future iterations.

9

1. As an LFI we would like to have a kill switch to disable all active consents that are on the customers’ accounts. This should be an option for LFIs.

2. As an LFI we would like PEPs or VIP customers such as royalty to have a default opt-out set for open banking services. This is to be determined selectively by the LFI. This is to reduce risk of PEP or VIP data being misused.

3. If an LFI doesn't want to work with a TPP because for example because of their consent management interface is not according to specification e.g. enforcing user additional screens or steps to revoke consent, how this could be achieved by LFI?

4. When User revokes consent at the LFI end, there has to be explanation of what will happen to user data (which TPP also has) and responsibilities defined in specification. This is not available in the Rules table.

Re kill switch: Rather than disabling this should be suspended so that the consents are in a suspended status.

Re opting out of OF: Everyone by default is opt out, until they opt in. If the LFI wants to call and engage certain customer after an opt in takes place, this is ok.

Re not wanting to work with a TPP : Raising a complaint against a participant and the process of resolving it will be covered in the dispute resolution process which is a work in progress.

Re On revocation at TPP : Noted we will add guidelines for the LFIs on what to display to the user

10

1. With respect to the wireframes shared, are these set in stone or they can be changed to improve overall experience?

2. Are LFIs responsible for these consent? Are we expected to get separate consent for TPP and a separate one for LFIs?

We are prescriptive on the user experience ( how easy it should be accessible, the number of screens, unnecessary friction etc ) and the content and the labelling of content to be displayed and not on the UI ( look and feel and branding).
Any suggestions to improve the UX are welcome.

Re : Consent responsibility - The consent is requested by the TPP and the same consent is authorized with the LFI. There are no separate consents. The TPPs must display the consent (s) details at their end and similarly, the LFIs must display the same at their end. Both are accessing the consent details from the OFP.

Section

Sub Section

Participant ID

Feedback

Response

Authentication and Authorization

General

1

What have been presented is sufficient.

Noted

2

Looking at overall preference of mobile as an interface and best practices from some global implementations (e.g UPI in India) and the security requirements as customers bank credentials are used as part of authentication and authorization flow. The preferred flows will be-

1. Redirection- mobile app to mobile app redirection

2. Decoupled- TPP interface can be a kiosk, a website or any other non-mobile digital experience (gaming console, VR headset).

Embedded flow will be obsolete as it requires deep integration of LFI into TPP interface (for e.g SDK) and its more one-to-one integration which is counterintuitive to the centralized model we are building in UAE and also hampers scale up.

Agree. We are not supporting embedded flows.

3

· Redirection is the widely used method but Decoupled Redirection can also be explored with further due diligence.

· There is no clarity on Embedded method, please elaborate Embedded method more with an expected user journey?

We have updated the content and will not be including the embedded flows due to the complexity and a higher risk profile it carries.

4

We believe the main focus should be on Redirect flows - especially App2App, QR codes (allowing people to pay by OpenFinance APIs in POS). In case of regular redirect, TPP / OFP should have visibility over why the user journey failed (on which step)

Embedded flow - should be marked as obsolete - users should add the credentials on the LFI side as this is the party they trust the most. Decoupled CIBA flow has historically not provided much additional value.

Yes , Redirection is the main flow that needs to be supported by both the LFIs or the Centralised App. The decouple presented in the journeys is purely the Call to action modified by the TPP ( e.g QRCode which has a deeplink). It triggers the same redirection journey on the LFI or the centralised app.

We have updated the content and will not be including the embedded flows due to the complexity and a higher risk profile it carries.

5

NOT AT THIS POINT IN TIME

Noted

6

None

Noted

7

1. What all authentication mechanism LFI must support, we can opt for any one from the mentioned flow or we have to support all the three as an LFI

2. Who will manage the user path & direct the user to the required flow.

3. What is the definition the apt Authentication flow for end user

4. Are there any standard T&C which are required to be shown to user or LFI can have their own T&C

1. As per the updated content if LFIs want to authenticate the users then they must support the redirection flow.https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/54526002
   Authentication by the centralised app is optional for LFIs that do not have mobile channels or those that need a speedy integration.

2. This will be using the Deeplink that is published for each LFI. The deeplink must be able to redirect the user either to the LFI mobile/web channel Or if the LFI is using the centralized authentication the deeplink will redirect the user to the Centralized app.

3. We need more clarification in relaiton to this question.

4. LFI’s are not expected to include any T&Cs as part of the Open Finance journeys. This must be part of the general T&C updates that the LFIs usually undertake and notify the user in the form of a Notice of variation.

8

We recommend using on the ‘redirection’ and ‘decoupled redirection’ methods ONLY, as these cater to all use cases and support a more rapid implementation and adoption across the market.

Decoupled CIBA adds significant complexity due to the variations of patterns and increases likelihood of failure due to interpretation of implementation and lack of standards. These more complex use cases and scenarios can be explored at a future state, once we have solid and proven foundations on which we can build.

We have updated the content and the LFIs are expected to support only the Redirection flow. The LFIs do not need to do anything specific for a Decoupled flow as this experience is managed by the TPP.

9

· Redirection and decoupled authentication methods provide robust security measures, user convenience, and flexibility in accessing banking services across multiple devices, ensuring compliance with industry standards, and enhancing the overall user experience. In contrast, embedded authentication within TPP interfaces may introduce security risks, such as potential vulnerabilities to phishing attacks.

· Moreover, both redirection and decoupled authentication methods may be necessary. For instance, if the journey commences in the TPP mobile app, redirection to the LFI mobile app may occur, whereas if it starts in a web application/offline parking kiosk/etc., decoupling is necessary.

Agree

We have updated the content and the LFIs are expected to support only the Redirection flow. The LFIs do not need to do anything specific for a Decoupled flow as this is managed by the TPP.

We are not including the embedded flows due to the complexity and the higher risk profile it carries.

10

· How will this work for Insurance Companies?

· Will this all be single sign on or multiple sign on?

1. The authentication flow is agnostic of the sector as the principle is that if the LFI wants to authenticate the user for an Open Finance request then they must use the same authentication method(s) which they currently support on their other online channels ( web /mobile)

2. Each new consent requires an authentication and authorization flow. The consent itself could be for a single use (Single Immediate payment) or for multiple uses(Variable recurring payments).

Section

Sub Section

Participant ID

Feedback

Response

Bank Service Initiation

Overview

1

Not for now.

Noted

2

No

Noted

3

No question at this stage

Noted

4

TPPs are then further able to retrieve the status of the payment orders. This needs further clarification as it can be achieved by polling and webhooks.

Noted, we have updated the page to reflect this.

5

NO

Noted

6

None

Noted

7

Are all the bank services required for the LFI to join?

Services offered by the LFIs via their existing banking channels which are covered in the Standard, are expected to be provided by the LFIs when joining Open Finance.

8

International payments are mentioned in this section, however it is not mentioned in any of the subsequent sections (on Bank Service Initiation). International Payments are (a) less standardised across LFIs; (b) introduce a range of complexities around the model (including FX, risk management and consent scope creep); and (c) moves OF into a domain this is not exclusively reregulated by the CBUAE and is therefore more complex to navigate.

We acknowledge the vision and ambition to support International Payments, however we strongly recommend a focus on domestic uses ONLY, first. This will enable us to build out a comprehensive integration with, and adoption of, Aani and validate the simpler domestic PIS usecases, before extending this for international payments.

Finally, we have many questions on the multiple-authoriser model for corporate usecaes as propose a separate session to walk through this topic on detail.

International payments are in the scope of the Open Finance Standard. There was no international payments page in the draft v0.1 of the Standard, but in the following draft, a detailed international payments page is provided.

We understand that international payments have an increased level of complexity and that LFIs have different approaches using these, but the standard will try to cater for all this.

We acknowledge the suggestion that participants should focus on the domestic payments only at the start, but this is something that can be discussed and agreed upon from the implementation perspective between CBUAE and the participants.

We are happy to have a walk through on multi-authorization model for corporate use cases in one of the following engagements.

9

· It will be ideal if a standard operating guideline is drafted enlisting SLA for all Non-STP flows, i.e. on-hold, reject, time-out, etc. Also establish cut-off until when customer funds can be held if not credited to the beneficiary, for whatever reason, along with a workaround for consent especially for single payment instruction.

· First step in a payment process is to add a beneficiary - this can be separate from the make payment flow, with a built in cooling period (no payments allowed or limited vol/value during cool off). TPP journey needs to bake this in order to for a new been set up as an FDP after cool off ends

All existing BAU SLAs and cut-off times that LFIs have in place for payments initiated via existing online banking channels such as mobile app or online banking, are still applicable for payments initiated via Open Finance APIs from TPPs. If the need is identified to introduce additional SLAs, then this can be added to the Operational Guidelines that will be produced as part of the Standard.

10

· This is all very banking specific, we would be need to understand how this would all apply to Insurance Companies?

A section specific to insurance is included in Standards V0.1 Draft-2.

Section

Sub Section

Participant ID

Feedback

Response

Bank Service Initiation

Single Instant Payments

1

What if a user want to initiate payment request through PISP, and PISP needs to connect to AISP for user accounts, what is the flow for consent, authentication, authorisation, communication and OFP position?

For above scenario which PISP and AISP are two different TPPs; is it a redirection from AISP to user to select the account? Or an alternative authentication and account selection?

Usually, LFIs display to user some information before execution the payment such as accepting T&C, estimate date, FX, transfer amount, etc. So how a TPP will display such details in its app to user? Since TPP will initiate a payment request.

Is there a pre-confirmation API that TPP will call that LFI returns all those info, TPP will display, User will confirm then the payment

On the other hand, when request to consent the payment from TTP to LFI, user will see all details on LFI app and then approves it?

There are two approaches of account selections, either user selects account for a payment in the TPP app, or TPP fires the request and when user been authenticated in the LFI app, there he chooses the account and payment is executed. Which approach could be used in here? Alternatively, is both possible?

Is there predefined payment entitles like electricity, universities, etc. that TPPs would display to user to initiate a payment? Is there a lookup list approach for such?

A PISP may also have account information role with the User. As part of this, the TPP will have a long-lived Data Sharing consent with the User to access certain data permissions from the User’s account including the number of accounts, account identifiers etc. The standard Data Sharing flow is use in this case. Then, the TPP can use this information to pre-populate information for the user during the service initation flow.

In the scenario that PISP and AISP are different TPPs, each of the User flows for Data Sharing and Payment initiation will take place, The exchange of information between the 2 TPPs is not covered by the Standard, it is part of the integration between the 2 TPPs.

LFI’s can still display the same information to the Users before the execution of the payment. This can take place after user authentication and at the stage of User authorizing the payment Consent provided by the TPP.

There is no reason for pre-confirmaiton API that the TPP will call to get this info from the LFI.

Yes, the TPP will pass all the consent information to the LFI via the OFP and the LFI will display this information to the User for authorization.

Both approaches are supported by the Standard. The TPP can choose which one to offer to the User or even both options.

The Standard does not cover predefined payment entities. However, the TPPs can provide these to the users to avoid having them to entery the beneficiary account details and provide a better user experience.

2

1. Is there any guideline on what is the transaction narration that will be passed in the transaction statement for the single instant payment transaction done on OFP

2. Why do we need to display payee account, it should be an alias or masked, a business will not want to expose its account number to the customer from whom he is collecting funds.

3. What is the expiry window for SIP requests both single authorization and multi authorization scenarios, is one day or 23:59:59 of consent date is default value? If not then what window can a TPP set both minimum and maximum?

1. The Payer Note field is used to capture any user initiated narration in relation to the payment that may be used in the user’s statement. However, different LFIs may support different formats for the statement entries of payments.

2. Agreed, thats why there is a note in the BRs in item 1.1 of section https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528102/Single+Instant+Payment#3.1-Rules-%26-Guidelines which states that “Depending on the use case, the Payee details may not be displayed to Users in full.”

3. For Single Instant Payment (SIP), the authorizatoin expiry window can be set by the TPP, if required. The Consent will be awaiting authorization till this window has expired. If this is not set, then the SIP Consent will be awaiting authorization till the https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528887/Limits+and+Constants#Max-Submitter-Authorization-Time-Window expires. After authorization, the SIP Consent will remain valid till it is consumed.

3

No question at this stage

Noted

4

It’s important to define a set of errorCodes - indicating why specific payment was failed. We assume not all single payments can be instant (like internationals or with higher value)

• Also what about purpose codes which are currently used in banking - they have an impact on payments being instant or not.

Agreed, not all single payments are instant (such as international payments or high value payments). The Standard will support errorCodes indicating specific failures for payment initiation.

Purpose codes for the payment will be added to the Standard in the following draft.

5

NO

Noted

6

https://openfinanceuae.atlassian.net/wiki/spaces/StandardsDraft01/pages/39160988/Common+Rules+and+Guidelines#GRC-15.12-Payment-Status-Model : There are 2 successful terminal states [AcceptedCreditSettlementCompleted, AcceptedWithoutPosting]. From definitions AcceptedCreditSettlementCompleted  implies that payment was complete. So, can there be a transition from AcceptedWithoutPosting  to AcceptedCreditSettlementCompleted ?

Our understanding so far is that the response that will be provided by the underlying payment rails is either that the payment has been succesfully received by the receiving bank with the credit being applied to the beneficiary account (AcceptedCreditSettlementCompleted) or that the payment has been received but not applied to the beneficiary account yet (AcceptedWithoutPosting). While logically, there is a transition from AcceptedWithoutPosting to AcceptedCreditSettlementCompleted, in reality, this status does not update in the sending bank as there is no subsequent message from the payment rails to confirm this to the sending bank and update the status.

7

1. Will there be provisioning for the inline MFA flow? E.g. the TPP is the one to send to API the OTP provided by user instead of the LFI’s embedded screens.

2. Are the single payments requiring OTP authentication

3. For corporate clients or multi-user flow what is required at LFI end

4. What are the identifier that is required to be sent for reconciliation purpose

5. For payments under open finance are LFI required to follow pre-defined user limit for each user or per day limit for account as a whole or these payments will bypass these internal rules. What is the implication on complex account payment approval matrix

1. Embedded authentication is not supported. The authentication will be done either by the LFI or by the Centralized App trusted by the LFI. The LFI screens are not embedded. The flow will use redirection.

2. Single payments will be authenticated using the Multi factor authentication used by the LFI ( biometrics etc). Once the user is authenticated the consent authorization( Single payment in this case) must not require any further Authentication to avoid friction in the OF journey.

3. The LFI will authenticate the user that initiated the OF journey and after authorization from the first user they will send the Pending status to the TPP. The LFI follows the BAU process for the authorization from all the authorizers and the TPP will be made aware after each authorization. Please see Common Rules and Guidelines | 18. Multi User Authorization Flow for details

4. This is a unique identifier generated either by the user, or the TPP or the beneficiary merchant. It is referred to as the Payment Reference. This identifier is used at the beneficiary to uniquely identify the payment and the relate it to any informaiton that need to be reconciled (e.g. a transaction id, an invoice number, a customer id, a contract id, etc.). The Payment Reference is passed on via the payment rails to the beneficiary LFI and must be provided to the beneficiary.

5. The LFI can apply their internal BAU limits for payments

8

No specific questions or feedback currently.

Noted

9

· Please confirm if the facility will be limited to domestic payments in AED only. This excludes domestic payments in foreign currency to a TPP. For e.g.: One time insurance premium paid to Zurich in USD.

· Presenting supplementary information to Users should not be a decision and evaluation of individual LFIs or per payment journeys including instant payment transactions. This needs to be standardized with the information to be displayed and should be mandatory by LFIs. Otherwise social engineering attacks will be much easier to be successful.

· Proxy resolution process stated in "IBAN of the Payee returned by the Proxy resolution process" needs to be explained in the documentation.

· Instant payment transaction amount limit is not mentioned and by which participant it must be enforced (OFP/TPP/LFI).

· This statement needs to explicitly define what data must be shared by LFI as minimum mandatory "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."

· For each consent and payment activity, notification to User via email and SMS must be mandatory and set in specification by defining clear responsibilities (TPP/OFP/LFI). This will help to prevent fraud activity to further increase its damage.

Yes, the SIP wil be related to domestic payments for AED only. The domestic payments in foreign currency is covered under the International Payments section.

Each LFI uses different approach in relation to the supplementary information they present to users before payment authorization. The Open Finance Standard is not looking to change the existing BAU processes of LFIs. Thus the Standard caters for this by requesting LFIs to provide the same information as they presenting in existing digital panels keeping the parity principle.

The Proxy resolution process is an existing overlay service already used by the LFIs today, so it is a BAU process,

The maximum SIP payment transaction limit is referenced in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#3.-Payment-Amount-%26-Currency. This is to be enforced by the TPP and the OFP. At the moment there is no value specified for this limit (unlimited).

The detailed data model for the response from the OFP to the TPP when initiating a payment is defined in the https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/59408417

Confirmation of payment consent setup is mandatory for TPP to users and is part of the overall consent setup user journey, For payment initiaiton, when users are present, confirmation of payment initiation if mandatory for TPPs. When users are not present, noifications are mandatory for TPPs. For LFIs, notifications are mandatory for single payment consent/initiations, long-lived consents setup, and each payment initiation related to a long-lived consent. Please refer to https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#16.-Confirmation-to-User and https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#17.-Payment-Notifications

10

· This is all very banking specific, we would be need to understand how this would all apply to Insurance Companies?

A section specific to insurance is included in Standards V0.1 Draft-2.

Section

Sub Section

Participant ID

Feedback

Response

Bank Service Initiation

Future Dated Payments

1

In a scenario that user initiate a future payment in TPP app by selecting the date of the request, LFI records the payment request on that date, what if user wants to cancel this payment ? How would he do that? Is it through TPP app or LFI app?

Is there period of X hours (e.g 24, 48, xxx hours) for such?

The user will have to cancel the payment via the LFI. This cannot be done by the TPP. The existing BAU processes for Future Datd Payments that each LFI supports are still valid for the Users and are outside the scope of the Standard.

2

Future dated payment instruction will freeze the amount at the time of initiating consent and the TPP or customer cannot change the amount when the consent is invoked on the set date.

No, this is not the behaviour documented by the Standard. The LFI MUST not earmark any funds in the users account in relation to the payment. Instead, the existing BAU processes of LFIs will apply, such as the payment will be initiated on the scheduled date and normal BAU checks including funds checking will take place before the payment is executed. If there are insufficient funds in the user account, the payment will be rejected. If the LFI has a retry process in place, that will be followed as normal.

3

No question at this stage

Noted

4

Does this require long lived consent? That should be single use consent which can be used in the future. It’s important to handle that properly. It should be single use consent with expiry date set to the payment due date.

This will be a single use consent which will be used immediately to schedule a payment with the LFI. The BRs are being adjusted to reflect this.

5

NO

Noted

6

None

Noted

7

1. Do LFI require to have additional authentication (OTP/Biomatrices) before execution of future dated payments

2. Do as LFI we have to override all the workflow

3. Are these tried to specific beneficiaries

4. Do we require authentication before adding beneficiaries

1. No, that would not be necessary

2. No, you will not have to override any workflow

3. FDPs can be sent to any beneficiaries required by the Users, it doesn’t have to be to existing tried beneficiaries

4. Stardard BAU LFI processes are expected to apply when adding beneficiaries

8

No specific questions or feedback currently.

Noted

9

· FDP consent: we believe that the consent for an FDP does not need to be long-lived, but rather, a single use consent with an expiry the day after the FDP is due to execute.

· FDP Consent updates will be problematic if the user can change the amount after the consent is made. This could affect e.g., pricing and VAT that would have to be played back to the user to accept or reject. Reject in this case would mean leave the FDP as it was before.

· In case beneficiary account numbers could not be fixed (immutable) in the consent, attacker’s motivation will increase for this scenario. Legal liabilities and possible mitigations on TPP, OFP and LFI end must be clearly documented for this use case. And payment limits must be carefully restricted and fraud controls must analyse suspicious behaviour at OFP platform before request being forwarded to LFI.

· Future dated payment transaction amount limit is not mentioned, and description needed for which end it must be enforced (OFP/TPP/LFI).

· For each consent and payment activity, notification to User via email, SMS or in-app must be mandatory and set in specification by defining clear responsibilities (TPP/OFP/LFI). This will help to prevent fraud activity to further increase its damage.

The FDP will be using a single-use consent.

FDP Consent updates will not be required as FDPs will be using a single use consent.

The beneficiary is fixed for the FDP functionality and it is part of the authorized Consent.

The maximum FDP payment transaction limit is referenced in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#3.-Payment-Amount-%26-Currency. This is to be enforced by the TPP and the OFP. At the moment there is no value specified for this limit (unlimited).

Confirmation of payment consent setup is mandatory for TPP to users and is part of the overall consent setup user journey, For payment initiaiton, when users are present, confirmation of payment initiation if mandatory for TPPs. When users are not present, noifications are mandatory for TPPs. For LFIs, notifications are mandatory for single payment consent/initiations, long-lived consents setup, and each payment initiation related to a long-lived consent. Please refer to https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#16.-Confirmation-to-User and https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#17.-Payment-Notifications

10

· This is all very banking specific, we would be need to understand how this would all apply to Insurance Companies?

A section specific to insurance is included in Standards V0.1 Draft-2.

Section

Sub Section

Participant ID

Feedback

Response

Bank Service Initiation

Multi-Payments

1

If we are talking about VRP on TPPs side, then it could have. For LFIs, all controls are there in their Backend systems that validates the payments before executing them.

Noted

2

As of now the controls look sufficient.

Question: Can customer set the max amount limit in case of a variable recurring payments with variable amount or number of transactions allowed in case number of transactions is a variable, or is it done by TPP only

Yes, in case the number of transactions are variable, the user can set in the VRP Control Parameters the max amount per each payment. Moreover, the user can set all the other max cumulative limits both for the whole consent period and during the VRP control period.

3

Needs further analysis

Noted

4

There might be additional parameter which specify how many payments can be done in general through that consent in addition to other limitations

This limit is already there as one of the 5 controls of the VRP Control parameters. It is the max cummulative number of payments during the consent period.

5

NO

Noted

6

None

Noted

7

-

8

This is a very complex topic with numerous variables, ranging from fixed and variable recurring and on demand payment. There were also aggregation usecases discussed in the workshop (e.g. where a TPP may have numerous underlying merchants and each merchant will charge in variable way). We would like to understand how consent will work for such scenarios; how the transaction will appear in the users account (e.g. as the TPP or the merchant) and how the liability model will work (given this is more of a pass-through service and not a true aggregation). It’s unclear who the customer or LFI will ultimate face and who will be the risk of the transaction (in case of dispute etc). This requires a more detailed discuss/workshop and alignment with LFIs, before this can proceed.

Assuming the aggregation model will be based on a pre-defined list of merchant beneficiaries. This means that the TPP will be offering payment services to these merchant beneficiaries and thus will have checked as part of their onboarding the beneficiary LFI accounts that will be receiving the payments. In this case, the VRP consent will be provided by the user to the TPP and will include all necessary VRP control parameters and all the receiving beneficiaries and their accounts. The User will authorize the VRP consent with the LFI. When the user wants to pay one of these beneficiaries for goods/services, the TPP will initiate the payment to one of the predefined merchants and for the amount that is within the alowable VRP control parameters. These parameters will be checked at the OFP. The payment initiation that will be sent to the LFI, will include all the payment details including the amount, and the merchant beneficiary and will be initiated by the LFI as a normal single payment to the merchant. The liability model that will be produced will cover all the scenarios when there is a dispute between user and beneficiary. The beneficiary merchant is the user facing entity and will probably also be included in the model. Further discussions will take place on this topic in future engagement sessions.

9

· Multi-payments: the wireframes are unclear and misleading. The messaging to customers needs to be that they are approving many payments, and potentially, an unknown number of payments (within the rules). This should be made much clearer. Customers may not realise it is many payments not one. Even the title should say payments in plural not in singular. A VRP is not one payment, but many in a subscription/plan. For current context, no bank journey includes the approval of an unknown number of payments.

· VRP consent updates: these could be problematic. In a use case where a payment plan is set up to pay for a car, merchant may want that the consent cannot be updated. Otherwise, they risk the user changing the payment plan and breaching the car sale contract. Consent update should be optional based on the use case (and set by the merchant not the user).

· Will the beneficiary account number(s) for Fixed Recurring Payments (FRPs) be in the consent and static? This will prevent fraud cases significantly.

· Will the beneficiary account number(s) for Variable Recurring Payments (VRPs) be in the consent and static? This will prevent fraud cases significantly.

· In case beneficiary account numbers could not be fixed (immutable) in the consent, attacker’s motivation will increase for this scenario. Legal liabilities and possible mitigations on TPP, OFP and LFI end must be clearly documented for this use case. And payment limits must be carefully restricted and fraud controls must analyse suspicious behaviour at OFP platform before request being forwarded to LFI.

· What will be the maximum time allowed for long-lived consents for FRPs and VRPs? It must not be unlimited.

· For each consent, data sharing and payment activity; Notification to User via email, SMS or in-app must be mandatory and set in specification by defining clear responsibilities for this communication (TPP/OFP/LFI). This will help to limit fraud activity to further increase its damage.

Do you think that there are more consent control parameters required to manage the different risk profiles of the various VRP payment types?

Yes. Users can exercise greater control over their VRP transactions, tailoring consent settings to align with their risk tolerance and preferences, also allowing banks to tailor their services effectively. Duplication, value, poor customer understanding of purpose could be potential risks.

Noted. We will review the wireframes for the VRP. We realise that currently no bank journey includes the approval of an unknown number of payments but on the other hand, this is similar to setting up a mandate for a direct debit, for a period of time, to a specific beneficiary without a fixed amount. However, the Direct Debit does not have the additional protective controls that the VRP consent has.

Agreed, the consent update is conditional based on the use case and it is something that can be set by the TPP based on the use case and the requirements of any underlying service initation beneficiaries (such as merchants).

Yes, beneficiary account numbers will be included in the Consent for Fixed Recurring Payments and for VRPs.

A pre-requisite for variable beneficiaries which are not defined in the consent, is that there will be liabilities for the TPPs in relation to these multi-payments. Our expectation is that TPPs will only initiate payments to their onboarded list of business customers who wil have been onboarded and passed throug a KYB process. So, the target beneficiaries will not be infinite and will not be unknown to the TPPs. Even so, we agree that payment limits will be carefully restricted by both the User and the TPP (who has liabliity anyway) and fraud controls will be in place by the TPPs to reduce risks. The OFP is not expected to run any fraud controls at this stage, as this is not in its expected functionality. However, additional information will also be provided to the LFI in the risk information block of each payement to allow any additional risk check by the LFI, if required.

All long-lived consents can be specfied to have an expiry date. This may be set, depending on the use case, to be smaller or greater than the maximum date that consent refresh must take place, which at the moment is expected to be in the range of 12 months.

Noted, we will analyze these additional control parameters and evaluate if they extend the current control parameters set.

10

Not Applicable

Noted

Section

Sub Section

Participant ID

Feedback

Response

Bank Service Initiation

Multi-Payments

1

Despite user consent to TPP to execute such recurring payments, there might be scenarios that user forgets, change his mind set, his financial situation might change, etc. so it could be a case for having such period on VRP or if whether there is an alerting, reminders or other to user so he will be aware about and takes the needed actions.

The guidelines will be updated to cover notifications to be sent to the user before initiating a payment for a fixed schedule.

2

Yes, as it can provide an additional layer of security to the customer.

Noted

3

Needs further analysis

Noted

4

FEEDBACK

-

5

NO

Noted

6

None

Noted

7

Do you think that we need VRP Control periods even for the cases of variable payments on fixed recurring schedules?

8

This is a very complex topic with numerous variables, ranging from fixed and variable recurring and on demand payment. There were also aggregation usecases discussed in the workshop (e.g. where a TPP may have numerous underlying merchants and each merchant will charge in variable way). We would like to understand how consent will work for such scenarios; how the transaction will appear in the users account (e.g. as the TPP or the merchant) and how the liability model will work (given this is more of a pass-through service and not a true aggregation). It’s unclear who the customer or LFI will ultimate face and who will be the risk of the transaction (in case of dispute etc). This requires a more detailed discuss/workshop and alignment with LFIs, before this can proceed.

These topics will be covered under the liability model and which is currently a work in progress. We will also publish in future releases roles of 4th parties which will be served by TPPs.

The TPPs could be serving merchants and the merchants here are customer-facing.

The consent will include information of the TPP or beneficiary party(merchant) on behalf of the TPP which acquired the User Consent.

9

Yes. It may not be needed always so perhaps can be optional if TPPs choose to set the control period for fixed schedule VRPs.

Noted

10

Not Applicable

Noted

Section

Sub Section

Participant ID

Feedback

Response

Bank Service Initiation

Multi-Payments

1

This would depend on LFIs as well and how they perform recurring payments along with their users. Therefore, TPP alignment with such mechanism is needed.

Noted

2

Yes this is fine

Noted

3

Needs further analysis

Noted

4

Potentially there might be a requirement for quarterly granularity.

Noted

5

YES

Noted

6

None

Noted

7

Do you think the granularity of day, week, month, year is sufficient for most of the use cases for recurring payment schedules?

Noted

8

This is a very complex topic with numerous variables, ranging from fixed and variable recurring and on demand payment. There were also aggregation usecases discussed in the workshop (e.g. where a TPP may have numerous underlying merchants and each merchant will charge in variable way). We would like to understand how consent will work for such scenarios; how the transaction will appear in the users account (e.g. as the TPP or the merchant) and how the liability model will work (given this is more of a pass-through service and not a true aggregation). It’s unclear who the customer or LFI will ultimate face and who will be the risk of the transaction (in case of dispute etc). This requires a more detailed discuss/workshop and alignment with LFIs, before this can proceed.

These topics will be covered under the liability model and which is currently a work in progress. We may also publish in future releases roles of 4th parties which will be served by TPPs.

The TPPs could be serving merchants and the merchants here are customer-facing.

The consent will include information of the TPP or beneficiary party (merchant) on behalf of the TPP which acquired the User Consent.

9

Yes, but we should add more than 1x the period.

Custom Intervals: Some users may prefer more flexibility in scheduling payments, such as bi-weekly or quarterly intervals. i.e., enable day, week, month, year to be set to multiple (one payment every two weeks; or one payment per 3 months)

Noted. We will consider this for a future release.

10

FEEDBACK

-

Section

Sub Section

Participant ID

Feedback

Response

Bank Service Initiation

Multi-Payments

1

This is as card tokenisation approach which a token is generated for a certain card number, making transferring such information is secured.

Taking into the fact that IBAN is not changeable. So proxy can be used as long as any action on the beneficiary by user in the LFI app will make the proxy invalid. For such case, is there a procedure for validation by TPP, OFP or LFI for the same? What are the actions set for it?

Noted. We do not have a procedure for invalidation. we will consider this for a future release.

2

The payment should always be tied to the IBAN, if we tie it up to proxy and for whatever reason the IBAN behind keeps on changing then, tracking and reconciliation can be a problem, also in case of dispute it will pose problems and also exposes us to possibility of money laundering risks

Noted

3

Needs further analysis

Noted

4

Ideally consents should be tied directly to the original IBAN for which the payment consent was created. A mutable source of funds could create challenges with AML-CTF requirements whereby the proxy is updated to an account that is not associated with a KYC’d user. Businesses who operate VRPs should still be able (whether a Proxy is used or not) be able to verify the source of funds as being attached to the individual they have performed KYC on during their onboarding.

Noted

5

Should be tied to the resolved IBAN of the beneficiary

Noted

6

None

Noted

7

1. To avoid the problems with reconciliation and the fraud, the scheduled payment should be only tied to the IBAN, not the proxy

2. How to accommodate for recurring payments which have variable amount in nature but are user induced i.e. vendor payments, supplier payments

3. What is the orchestration of payment enquiry service

4. If there a provision for non-registered or non-consented beneficiaries. Eg blanket beneficiary authentication to trigger variable user induced payments

1. Noted

2. The multiple payments have the option of variability of amount as well as variability of schedule. So the payment can be ad-hoc user induced using a variable. Please refer to https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528328/Multi-Payments#1.1.-Long-Lived-Payment-Consent

3. We need more clarity on this question.

4. Registering beneficiaries with any additional friction at the point of payment will induce a lot of friction and break the journeys. The consent requested from the TPP and the authentication done by the LFI should suffice to trigger variable user induced payments

8

This is a very complex topic with numerous variables, ranging from fixed and variable recurring and on demand payment. There were also aggregation usecases discussed in the workshop (e.g. where a TPP may have numerous underlying merchants and each merchant will charge in variable way). We would like to understand how consent will work for such scenarios; how the transaction will appear in the users account (e.g. as the TPP or the merchant) and how the liability model will work (given this is more of a pass-through service and not a true aggregation). It’s unclear who the customer or LFI will ultimate face and who will be the risk of the transaction (in case of dispute etc). This requires a more detailed discuss/workshop and alignment with LFIs, before this can proceed.

These topics will be covered under the liability model and which is currently a work in progress. We will also publish in future releases roles of 4th parties which will be served by TPPs.

The TPPs could be serving merchants and the merchants here are customer-facing.

The consent will include information of the TPP or beneficiary party(merchant) on behalf of the TPP which acquired the User Consent.

9

It is recommended that the instruction is connected to the beneficiary’s IBAN. It aids ease and supports consolidated views for the future especially when the pull is instructed from the beneficiary and honoured by the customer’s consented LFI.

Noted

10

FEEDBACK

-

Section

Sub Section

Participant ID

Feedback

Response

Bank Service Initiation

Bank Service Initiation API

1

Sufficient

Noted

2

Technical workflows have sufficient information for the “happy path” Will the unhappy paths be added later?

Error messages and error structure will be defined

3

Yes, it would be useful to have further details any future workshops.

Noted

4

Flows seem to be described properly, but error handling with error codes are missing. There must be agreement on token expiry - VRP can be done in 1 year in the future, it’s unusual that tokens are valid for 1 year.

Also the multi-auth flow needs further clarification. Will the authorization be from the bank portal or via APIs? How and when to exchange the code with the access token?

Error messages and error structure will be defined

Refresh tokens to be used for long lived consents

Secondary authentications will be through bank portals

5

NO Specific Suggestions at this point in time

Noted

6

None

Noted

7

FEEDBACK

-

8

We require a more detailed analysis to assess if current prescribed technical flows are clear enough. But at this stage, we have no specific, material feedback on the API specifications.

However, our general feedback with regards to all APIs is that the scope should be limited to only what is necessary to perform the call/transaction and that API rollout should be phased in order of usecase, where foundational usecase come first. If the CB insist on including ‘optional’ fields in API calls, these should therefore be non-mandatory to implement and/or test as part of implementation.

We won’t have optional fields, if available then the entire API spec must be met by the LFI.

9

An overview of the Open Finance Platform and detailed design elements like Swagger were provided. However, there seems to be a gap in between, as only a few sequence diagrams with happy path scenarios were included. E.g. validating the payload is difficult without the necessary business context and data.

Adding sequence diagrams for all scenarios, including negative journeys mapped to the corresponding endpoints, is advised as it enhances comprehension and streamlines the analysis.

Error messages and structures will be defined

These are apis - the paths and sequence are the same, only with different http response codes

10

FEEDBACK

-

Section

Sub Section

Participant ID

Feedback

Response

Bank Service Initiation

Bank Service Initiation API Swagger

1

Sufficient

Noted

2

Yes

Noted

3

Needs further analysis

Noted

4

Apart from Swagger definition - it would be useful to have a Postman Collection, which allows you to execute all the flows api call after api call.

There are a lot of fields - which are not required. What is the benefit of using them? If the benefit is low - why not get rid of some of them? If there is a need for usage in some particular flows it should be well described.

Fields like PaymentPurposeCode - should be an enum.

PaymentStatus should offer more options which can be found in ISO20022 standard.

Will be delivered as part of sandbox

We need more specific feedback on the fields that are not required

Noted

ISO have recently added a whole set of additional payment statuses - these have limited use outside of the LFI’s domain

5

YES

Noted

6

Can we include the consent setup request/response [/par request as mentioned in https://openfinanceuae.atlassian.net/wiki/spaces/StandardsDraft01/pages/39159686/Bank+Service+Initiation+API#2.-BSI-Sequence-Diagrams

Where would you like to see this included?

7

FEEDBACK

-

8

We need further analysis to answer this question.

Noted

9

In general, providing the business context (use cases) along with the required data would be valued, as it is a bit challenging to determine whether the data currently included in the payloads is adequate or not. The payload need verification against certain criteria.

-

10

FEEDBACK

-

Section

Sub Section

Participant ID

Feedback

Response

Bank Data Sharing

Overview

1

Yes correct

Noted

2

Current detailing is sufficient.

Question: Is there a plan to expand the Your product information cluster, because products will have various attributes for example credit card can include, card type, credit limit, etc. a mortgage might include, loan amount, outstanding amount, EMI, no. of payments outstanding.

Product information will be expanded to incorporate additional fields, including fields related to account-based financial products.

3

 Needs further analysis

Noted

4

From our point of view this is sufficient.

Noted

5

NO

Noted

6

None

Noted

7

FEEDBACK

-

8

We need further analysis to answer this question

Noted

9

Yes, as data elements will be needed to understand TPP’s purpose statement and help to understand justification, granular review will help. TPP could set baseline data elements and if would like to ask for additional data from the User then has to explain why these are requested.

Noted

10

FEEDBACK

-

Section

Sub Section

Participant ID

Feedback

Response

Bank Data Sharing

Customer Data

1

All communications are running through OFP, which means, any user request from TPP app will go through OFP, in its turn, OFP will send the request to LFI, and LFI will return the response to OFP, OFP returns response to TPP.

Is response stored in OFP?

What kind of data is stored?

Is there any period of keeping data? Is there validation of LFI response?

The OFP only stores consent.

The consents will be structure in a manner that all PII is encrypted end-to-end and will not be accessible to the OFP.

The OFP does not store any data returned by LFIs as part of AIS journeys.

2

No

Noted

3

No question at this stage

Noted

4

We have following questions/clarifications/suggestions:

• Consents are tightly associated with the refresh_tokens which allows generating access_tokens. Does refresh_token length should be equal to consent length?

• How do we handle long-lived consents? Is the situation when the refresh token expires and consent is still valid is possible? If yes, how the new token shall be generated.

• A very important data point (which is not present in the specifications is a government issued identifier for the individual or corporate account holder (typically this would be Emirates ID number for individuals and Trade License for corporates). This will help lenders be certain that the bank data being shared belongs to the applicant which is key to use the data for risk assessment purposes.

The refresh_token for a long lived consent will have a lifespan that is the shorter of:

• the lifespan of the consent

• the maximum re-authentication period defined for the ecosystem (tbc, likely circa 1 year)

Once a refresh_token for a consent has expired, the TPP should get the customer to re-authenticate the consent. Re-authentication journeys function in the same manner as an authentication journey.

Emirates ID and Trade License have been noted and will be included in a future version of the data model.

5

NO

Noted

6

1. https://openfinanceuae.atlassian.net/wiki/spaces/StandardsDraft01/pages/39160160/Customer+Data#6.3-Data-Cluster-Structure-%26-Language We don’t see Parties permission in the list, is this intentional or any plan to include it in future?

2. Once consent is revoked/expired, could you clarify on the behaviour of refresh token endpoint [error from the bank?]

1. Parties is not currently in the standards. The feedback has been noted and will be assessed with potential to include Parties data in a future draft.

2. This will result in an error response to the TPP from the OFP.

7

1. Do LFI required to share data related to Loan account, credit cards, investments & insurance

2. Under any consent are LFI required to share customer PI data, as there is no clarity for the same.

3. Do we LFI has to provide data in the given API swagger only or LFI can leverage their existing APIs to share data

Product data including that relating to loan accounts will be included in the data model.

The data in the current swagger will be expanded on. Existing APIs can be leveraged, provided all mandatory requirements are met.

8

We have concerns with the scope of data covered in this service. We are aligned with the direction of basic account and transaction information to enable TPP services; however, many of the data elements extend well beyond ‘basic’ which LFIs will be able to support. For example, not all LFIs will be able to provide MCC out of the box; the structure and approach to managing scheduled and future-dated payments will vary significantly between LFIs (and will be challenging to implement homogeneously); account information such as mobile numbers and email are PII and will require greater data controls and clarity on indemnity models; and product information in many cases is propriety in nature (e.g. deposit, credit and rates may be offer to specific segments or customers) should not be disclosed outside of the LFI.

Feedback has been noted.

MCC is only required if it is currently supported.

PII data will be encrypted and will only be shared with the user’s consent. The liability model will be discussed in a future draft.

In the case of PFM, a user should know how much they are being charged/offered for various products.

9

· Without regulation, the finalised scope of data for open banking sharing is not confirmed.

· User should be able to deselect data points at either the TPP stage or the LFI stage, or to restrict the historical extent of data sharing. E.g. as a user I only want to share last 12 months. E.g. as a user I do not want to share my account benefits.

· When an LFI account is not available to select for data sharing, information on the existence of this account cannot be shared with the TPP. It will be shown to the user only in LFI screens (CDCS-7)

· We welcome the use of data permissions. We would like to review what is included in each permission at a data field level

· Joint accounts should require consent from both parties to the account, just like a multi-authorisation journey for a business does

Feedback has been noted.

MCC is only required if currently supported.

PII data will be encrypted and will only be shared with the user’s consent. The liability model will be discussed in a future draft.

In the case of PFM, a user should know how much they are being charged/offered for various products.

10

FEEDBACK

-

Section

Sub Section

Participant ID

Feedback

Response

Bank Data Sharing

Bank Data Sharing API

1

Sufficient

Noted

2

Technical workflows have sufficient information for the “happy path” Will the unhappy paths be added at a later date?

Error codes and messages will be defined

3

Yes, it would be useful to have further details any future workshops.

-

4

FEEDBACK

-

5

NO

Noted

6

None

Noted

7

FEEDBACK

-

8

We need further analysis to answer this question

Noted

9

An overview of the Open Finance Platform and detailed design elements like Swagger were provided. However, there seems to be a gap in between, as only a few sequence diagrams with happy path scenarios were included. E.g. validating the payload is difficult without the necessary business context and data.

Adding sequence diagrams for all scenarios, including negative journeys mapped to the corresponding endpoints, is advised as it enhances comprehension and streamlines the analysis.

Error codes and messages will be defined

10

FEEDBACK

-

Section

Sub Section

Participant ID

Feedback

Response

Bank Data Sharing

Bank Data Sharing API Swagger

1

Yes

Noted

2

Yes

Noted

3

Needs further analysis.

Noted

4

• LFIs have the tendency to share only the fields which are required or a minimal set of the data. E.g if there are multiple types of balances - there is a high chance that only one of the balances will be exposed. It is possible that some of the data is not available (e.g. specific transaction type) - but there should be some guidelines when certain fields should be returned. E.g. merchant details in POS transactions, Creditor and Debtor in transfers.

• Additional examples of guidelines for the data that should be mandated to be returned are: IBAN as identifier for any savings and current accounts, MaskedPAN as identifier for credit card accounts, TransactionInformation field for all transactions so that we get a description of the transactions similar to what we would see in a bank statement, ValueDateTime for transactions in Corporate Accounts which is important for enterprise finance management use case

The general approach and rule is that data exposed on direct channels should be exposed through API chanels.

5

YES

Noted

6

1. Can we include the consent setup request/response [/par request as mentioned in

https://openfinanceuae.atlassian.net/wiki/spaces/StandardsDraft01/pages/39160276/Bank+Data+Sharing+API#2.-Sequence-Diagram ]

1. Get Transaction: Is it possible to include guidelines on how pagination should be implemented for transaction by LFI

Noted

7

FEEDBACK

-

8

We need further analysis to answer this question

Noted

9

In general, providing the business context (use cases) along with the required data would be valued, as it is a bit challenging to determine whether the data currently included in the payloads is adequate or not. The payload need verification against certain criteria.

Noted

10

FEEDBACK

-

Section

Sub Section

Participant ID

Feedback

Response

Common Rules and Guidelines

General

1

When the regulations and standards of TPPs and LFIs Onboarding will be ready?

Have Disputes, Frauds, Legal implications, etc. guidelines been finalised?

Regulations now published.

A timetable for when in engagement rounds this will be made available will be shared with participants.

2

No

Noted

3

No question at this stage.

Noted

4

How and when TPPs should be notified about downtimes / maintenance? We shall have a process for reporting issues etc.

Operational Guidelines will be developed as part of the OF standard. These will be the topic of discussion at a future engagement.

5

NO

Noted

6

None

Noted

7

FEEDBACK

-

8

No specific feedback.

Noted

9

· 5. Payer note. It appears the payer note is not sent with the payment. Should be optional for LFIs to display or disregard.

· 9. Risk information block. More details should be provided to aid LFI to know that the customer is human in the TPP channel including use of behavioural data (e.g., screen touch patterns, timing of interactions, etc.)

· 18. Multi auth flow. The extent of data shared with the OFP on the authorizers is excessive and would not normally be shared by the LFI without explicit consent from the corporate. This includes PII including the name and type of the authorizer (e.g. Ahmed Bilal - Director)

· Authorization Time Window should not be set by TPP. As payments executed over LFIs, this risk parameter must be determined globally or by each participant bank.

· For mobile devices, Risk Information Block can include if phone is protected with a PIN or biometrics and Android/iOS version and security patch version of the mobile device.

5. Payer note will be reflected in the standards. It is optional but if sent should be displayed by the LFI in the users' statements.

9 . Noted for info on Risk block. For consideration in future releases

18. Note. We will review the information shared in relation to the authorizers in the mult-authorization flow.

Authorization Time Window" is included to aid the TPPs to cater to scenarios where the user has been redirected and they take too long to authenticate/authorize the consent. Similarly for multi-authorization scenarios.

For example for an in-store payment, the TPP would expect a short “Max Authorization Time Window” after which they can simply abort the transaction. These cannot be set by the LFIs

10

FEEDBACK

-

Section

Sub Section

Participant ID

Feedback

Response

Limits and Constraints

General

1

Can LFIs limits number of TPPs engaged with?

In general, there would be imitation from LFIs for sharing data to TPPs in regards to their compliance, risk and security departments, which make it a bit difficult for TPPs to have such service to provide to users. What is the procedure set?

In addition, is there a chance that LFIs will show resistant for any TPP that wants to engage? That LFIs would have many rejections reasons or difficult due diligence done for a TPP.   

Customer’s education and awareness could be cause limitation in using open banking, but with having clear business model, security, data privacy, Interoperability and Standardization guidelines and regulations for TPPs and LFIs, it would reflect a confidence image to users.

LFIs cannot limit the number of TPPs engaged with them.

TPPs will be licensed entities and will have to go through all the compliance, risk and security requirements laid down for licensing.

LFIs cannot resist any TPP from using the OF service. If the LFI has any specific compliance related observations about the TPP they can raise the complaint. The process of raising such disputes and the liability model is a work in progress.

2

No

Noted

3

The terms require more clarification, for example: Maximum Retry Frequency, does it mean that TPP can retry only once every 2 hours? How is it aligned with Minimum Number of Retries where TPP needs to retry at least 3 times?

Noted, We will clarify it more in future releases. These have been included for defining retru rules for TPP scheduled payments which have not been included in the current draft versions of the Standard.

4

• Any SLAs on the API performance? Limit of number of transactions / direct debits etc. that can be fetched (number or date).

• Any constraints on the minimum range of fetched transactions? For example PFM use cases require multiple years of data to provide value to the end user.

Ongoing piece of work - this will be defined but is currently tbc.

At a minimum this will be the same as data provided on direct channels, but may be increased later if required for certain use-cases or consistency across the ecosystem.

5

NO

Noted

6

None

Noted

7

1. Who will maintain the retry register, as many times banks will not even receive the request

2. Who is responsible to maintain the idempotency of the payments

3. Who is responsible to maintain time matrix for the consent authorization

4. Who is responsible for VRP constraints checks

Kindly clarify roles & responsibilities of all parties

1. Not clear on the question here - the TPPs can retry failed authentications

2. OFP

3. The LFI provides this information to OFP. OFP sends on to TPP

4. Detailed breakdown in business rules of the responsibilities of OFP and those of LFI. General principle is that LFI has the data required to enforce a policy, it will do so.

8

In workshop discussions it was proposed that TPPs should be able to facilitate payments that are beyond the value limits that LFIs set in their own channels. The argument was that this would be ‘managed’ through the liability model. We strongly reject this proposal.

As an operating principle, LFIs should not be expected to entertain payments beyond their own limits. Banks in particular, as regulated entities, have arrived at their limits through an assessment of their respective control environments and evaluation of their risk appetites. These should be preserved (not compromised) to ensure the ongoing integrity of UAE the financial system.

Furthermore, while it is proposed the OF liability model would support TPPs to facilitate payments beyond LFI limits, we fail to see how TPPs will be sufficiently capitalised and organised, to bear the transfer of liability, that would be required in these instances.

There needs to be minimums for certainty functionality, just like with contactless card payments, but generally the limits on proprietary channels can be followed.

 TPP’s capital will match their volumes and risks, as imposed by CBUAE.

9

· A4 Max auth window of 30 days is too long for practical purposes and should be restricted to 3-7 days.

·  A5 should be lower for a single authoriser journey. 15 minutes is ample when compared to OTP validity which stands at 5-10mins.

· A11 50 max defined payment date/amount pairs may not be enough for SME/corporate use cases.

· B1 Retry time window should end sooner to avoid affecting end of day batches and to reduce non-STP payments from having different posting/value dates. A customer could reasonably expect that a payment not made by 9pm will not be made that day and could trigger a duplicate. Suggest 20:59 instead.

· Regarding payment limits for SIP, FRP, VRP it's not clear whom will be responsible to enforce the control (TPP/OFP/LFI).

Noted on the parameters. We will revisit these based on overall feedback

· Regarding payment limits the OPF will enforce the control on the limits specified in the consent. Any LFI specific limits (e.g max amount that can be paid out across all channels) will be enforced by the LFI

10

FEEDBACK

-

Section

Sub Section

Participant ID

Feedback

Response

Other

N/A

1

1. Any TPP would be registered with the trust framework and OFP as per the understanding, and request from TPPs to LFIs would be through OFP.

2. Would LFIs have arrangements with TPPs? Like approving them in the first place to work with them.

3. Is there TPPs Onboarding with LFIs? If so, how it would be?

4. Is there a portal for LFIS to view their engaged TPPs? Does this portal have option to disable any TPP that LFI does not want to work with and receive requests? If so, how this workflow works?

5. For employees under corporate organisations, how they can leverage from TPP apps and whether there are standards for them to use TPPs apps taking into consideration their corporate access in their LFIs?

6. There are two types of VRPs; sweeping and commercial, according to the understanding that payments will serve both. Please advice.

1. All TPPs that have the appropriate license from central bank will be registered on trust framework and will interact with the OFP

2. No. TPPs will be licensed by CBUAE and will operate on standardised terms via the centralised hub.

3. Automated by OFP using information in trust framework

4. Yes. Admin Portal on OFP. The portal does have the capability to blacklist / whitelist a TPP, but this capability may be disabled. TBC.

5. The authentication will refer back to the LFI.

6. Yes the VRPs will support both types of use cases. We have not finalised any commercial model around the VRPs.

2

NA

-

3

No further questions at this stage

Noted

4

1. Glossary is missing, LFI, OFP are new abbreviations - which are missed. There should be a good description - of what requirements and use cases need to be filled by TPP, LFI, OFP.

2. Many links are not accessible, so it’s hard to do a deep dive.

3. For Data Sharing, single-use consents currently are defined as a single Data Sharing immediately after consent; this is a bit vague and will lead to misunderstandings for TPPs so it should be more precisely defined by a maximum expiration datetime from the time of creation

4. In addition to the above, error codes are missing. As stated above we think defining a set of error codes will help both LFIs and TPPs.

1. A Glossary will be included in a future draft.

2. This issue will be resolved for Standards v1 draft 0.2

3. A expiry time will also be added where appropraite (e.g. for SIPs)

4. Noted - will be added on

5

It would appear that the regulations in their current form focus more generally on the Banking Industry, wherein the Insurance Industry has been included as an Add-on. It would help the insurance companies, if more specific drilldowns relating to the Insurance Operations are incorporated into these processes.

Focussed engagement sessions for Insurance Industry were included from 2^nd engagement cycle

6

None

Noted

7

1. Will LFI be allowed to integrate directly with TPP via their own proprietary APIs & open banking infra?

2. How the integration will happen for customized use cases between LFI & TPPs

3. If an LFI is already having an open banking flow with their own proprietary consent & identity infra, can they continue to use that or they will have to migrate to OFH.

4. For Banking as a service  related use cases what are the provisions

5. Are there any classification of mandatory & non mandatory APIs or all the use cases be it the mentioned or future use cases are required to be routed via OFH

6. What are premium & non premium API, is there any difference between the integration of both.

7. Can an LFI bypass OFH & integrate directly with TPP for customized use cases

1. Yes, but they also must be available on the central API hub. The trust framework must also be used at all times.

2. We intend to provide this capability through OFP, but likely a 2025 roadmap item

3. It will need to be integrated and meet common standards.

4. We intend to provide capability to expose “premium” APIs through OFP (2025 roadmap)

5. All APIs in the standards so far are mandatory. There might be non-mandatory APIs in future.

6. No integration difference only commercial differences.

7. Yes, although it may be a lot easier through OFP as various parts of the platform like trust framework and consent manager can be leveraged

8

No

Noted

9

Feedback following 11^th - 14^th March Workshop

1. Regarding all OFP platforms e.g. OFP, Ozone API Hub, Radium CA infrastructure and Federation Platform; Legal responsibility and liabilities must be clearly documented and agreed with LFIs in case of service disruption, security incident or data breach at OFP platforms which will be managed by the new established entity itself in the cloud.

2. OFP should publish consent updated as events/API/etc. for LFIs for synchronization purposes (e.g. consent revocation, or for complex use cases involving non-individual customer segments).

3. What are the measures of a TPP full compromise scenario in means of prevention, detection, containment and recovery at OFP end to protect LFIs?

4. To prevent a user to be a victim of social engineering, what measures will be expected and enforced from a TPP to prevent, detect and recover and how OFP will perform assurance on this?

5. What will be the security and privacy standards of TPP infrastructure and application(s) (web/online and mobile), and any security/compliance/audit report or certification before onboarding of TPP will be required which will confirm OFP defined baselines and standards for both TPP infrastructure and application(s) (web/online and mobile)?

6. How TPP application’s (web/online and mobile) OFP security assurance regarding security posture of the application (With business logical attacks and security vulnerabilities) will be continuously ensured?

7. Will there be public endpoints for TPP/LFI consumption? For any public endpoint, what is the plan against Layer 3,4,7 DDoS attacks for mitigation at OFP end?

8. Will OFP environment (Including all components e.g. API Hub, Radium, UAE Trust Anchor) pass SOC 2 Type 2 audit or any security/compliance certification before go-live?

9. Will full message payload encryption be considered in API design?

10. FAPI security profiles are going to be enforced by CBUAE or can we configure on our own (as LFI/TPP)? For example, read-only, read-write.

11. Will the concept of detached signatures be used where the payload is sent separately from the signature, reducing payload size and improving transmission efficiency? This is w.r.t JWS token.

12. Will the encryption algorithm for data in transit or at rest be defined?

13. Is there any duration defined for key rotation? This is for encryption keys for payloads or sensitive data.

14. Will the minimum key size be set? (2048 bit or 4096 key size) This is for encryption keys for payloads or sensitive data.

15. Will there be WAF to protect all OFP API endpoints working in block mode?

16. What will be the security and privacy controls for data protection and against data infiltration at/from OFP environments (OFP, API Hub, Radium CA, Federation Platform and Portal)? (Mapping to NIST SP 800-53 is possible with your reply?)

17. What will be the protection against ransomware in OFP platform?

18. In addition to MTLS, IP whitelisting will be configured and enforced by all parties which will increase security? (TPP, OFP, LFI)

19. How OFP environments application and security monitoring be performed by whom and continually?

20. For all cloud platforms to be developed and managed by OFP, compliancy to “CIS Microsoft Azure Foundations Benchmark (latest version)” and “NIST SP 800-53 Rev. 5 compliancy” will be targeted and achieved?

21. For all cloud platforms to be developed and managed by OFP, could we able to onboard our Cloud Security Posture Management tool and review security posture of the cloud platforms managed by OFP?

22. For all cloud platforms to be developed and managed by OFP, UAECB requirement for using customer managed key for data at rest encryption will be followed? (Platform managed keys for encryption must not be used)

23. What will be encryption strength for data in transit and at rest, will be secure enough against Quantum computing attacks like harvest and decrypt the data?

24. We have multiple segments of users (Retail, Corporate, SME etc.) and the application used by users of these segments are different. We need to figure out a way to route the consent management to the respective applications from the TPP.

Feedback following 16^th - 17^th April Workshop

Aggregation

Regarding collection of Account Data, from both an efficiency and UX optimisation perspective, how is Account Selection handled for Corporates who hold innumerable Accounts?

International payments

1. Please advise if there is any FX conversion between any currency pairs maintained in the hub to facilitate payments wherein payment instruction will be in AED but TPP converts FCY to AED.

2. FX rates may be proprietary/preferential - an LFI may share a rate that is dependent on the genuine customer profile that is asking; rate validity varies between suppliers - this should be customised by LFI; no SME/Corp journey with multi-auth will survive a 5min rate validity; purpose codes seem to be missing; some banks have add bene as a different journey to pay - including a cool off after add bene - there would be no reason to give the TPP a preferential flow - with different level of fraud control - than LFIs’ own journey; similarly LFI may vary the cut off and availability of corridors according to business need
   Delivery of international payments should be phased to take place after domestic payments are up and running and effective

3. Liability model is missing and limits our ability to understand the risk being borne by LFI

Multiple payments to variable beneficiaries

1. Given the complexity & nature of the payment being a marketplace rather than a linear payment this should be delayed for delivery in future releases
   Beneficiaries are linked at account level not customer which poses an issue as LFI may not be able to share all beneficiaries across all accounts (including joint accounts) in this scenario - this is overly excessive data sharing

2. Purpose code for payments must be mandatory

Consent

1. We firmly believe that suspension of consent should be fully managed by the LFI

2. Currently, the use and use cases for when a suspension apply are unclear. For cases of fraud or security, “Revoked” consent status may be more fitting. “Suspended” consent status is more suitable if it’s a customer request e.g. customer raise an issue with a TPP and wants to safeguard activity at the LFI till its sorted.

3. For consents that times out after being in pending state due to in-action of LFI/User what will be its terminal state

4. More detail is required for the multiple authoriser (corporate) use-case to understand the additional work required for LFIs

5. Detailed list of the validations carried out by the OFP should be shared to help LFIs understand if any additional checks are required

6. CAAP should be restricted to only LFIs who do not have a digital channel

7. CAAP should not be used in the long term to replace bank authentication methods

8. What will the identifier in CAAP for non-individuals?

Feedback following 11^th - 14^th March Workshop

1. Will be addressed in agreements between the Open Finance company when established and the LFIs, alongside the regulation and abovementioned liability model.

2. Noted. Will be supported through calls on Ozone Connect

3. TPPs can stop their access in the event of compromise by revoking their certificates

4. Step up on the bank side for payments, if alternative biometric credentials are utilised for example, via metadata from the TPP. TPP’s will be expected to meet high FS standards for SCA and fraud prevention.

5. They will have to meet all the encryption and FAPI 2.0 standards defined in the API standards, as well as be SOC2 compliant. We will also completed as will TPPs, vulnerability and penetration testing.

6. They will have to meet all the encryption and FAPI 2.0 standards defined in the API standards, as well as be SOC2 compliant. We will also completed as will TPPs, vulnerability and penetration testing. TPPs will be obliged and liable to monitor their own perimeters too.

7. Working with azure and the ISPs we will utilise functionality to prevent such attacks. There will be public endpoints.

8. The platform will meet FAPI 2.0 standards as the high watermark globally for API security. The individual platform businesses are SOC2 compliant already.

9. Encryption of PII from TPP to LFIs is being worked on as part of the standard so that OFP does not store any PII.

10. They are part of the API standards mandated.

11. We do not plan to use detached signatures. The experience with the standards in UK is that it lead to a lot of implementation complications for TPPs and ASPSPs. We favour full JWS payloads these days.

12. Yes - we are working on a solution to transmit PII from TPPs to ASPSPs as a JWS inside a JWE.

13. Not at present and this will probably be the responsibility of each participant to decide upon based on their security posture

14. Yes. This is defined in FAPI 2 and referenced BCP.

15. WAF and mtls do not work well in conjunction, but Ozone is actively working on identifying alternatives. They will have to meet all the encryption and FAPI 2.0 standards defined in the API standards, as well as be SOC2 compliant. We will also completed as will TPPs, vulnerability and penetration testing.

16. Ozone operates under ISO 27001 and SOC2 compliance. We do not publish mappings to NIST controls.

17. The OFP platform will not store PII.

18. IP whitelisting is supported for access to admin portals. Will not be supported for access to auth and resource servers.

19. This is the responsibility of the suppliers - Ozone and Raidiam.

20. Not in the current plan

21. No

22. All the sovereign cloud policies will be adopted. Our understanding is that this is one of the current policies

23. See https://openid.net/specs/fapi-2_0-security-02.html and its references to ciphers in 5.2.2 (Pt 1) and 5.2.2.1

24. We will work with each LFI to recommend the appropriate approach during onboarding

Feedback following 16^th - 17^th April Workshop

Aggregation

Noted - will be worked on

International payments

1. Currently there is no expected functionality in the OFP that will be providing FX pair conversion as per the question.

2. If the users account identifier is provided during the FX Rate Request by the TPP, the LFI may be able to return the agreed/preferential rate a user has with the LFI. If that is not the case, the rate the the LFI will return may be an rate that the LFI will be providing to users during a specific period of time. We agree that no timing window will be appropriate for the scenario of multi-authorization, but this case is more complex. If the corporate has a forward rate agreed with the LFI, then this will be the rate that will be used throughout the authorization process. If not, then the LFI has the opportunity to upsell and agree a forward rate with the first authorizer, and that will be the rate that will be presented for authorization to all authorizers. If that is not the case, then the fx rate presented to each authorizer will be the rate on the time of authorization (which is alinged to the LFIs' BAU process). Again, the release of the Standards should not be associated with the timescales for implementation by participants.

3. The principles make it clear, you will be liable for the tasks you undertake, but it will be published in draft format soon.

Multiple payments to variable beneficiaries

1. The variable-beneficiaries for multi-payments functionality is documented in the Standard and will be included in the Standards release. The implementation of the various functionalities included in the published standard will be communicated to participants by CBUAE.

2. We will be updating the business rules to make the purpose of the payment mandatory in the following versions.

PaymentPurposeCode is included in the standards

Consent

1. Agree. We will update this in the guidelines

2. Suspension could be for any fraud suspected on user account or TPP activity or as requested by the User ( like a pause on card usage)

3. The terminal state in this case will be Rejected

4. Noted. More details will be provided in future versions of the Standard

5. Included in business rules

6. CAAP is not mandated for any LFIs but is there to assist LFIs that do not have a mobile channel or need simpler integrations with the Open Finance platform. We see no reason to restrict this.

7. same as above

8. CAAP’s current scope is for personal users only. The details for business entities is work in progress.

10

FEEDBACK

-