...
Section | Sub Section | Participant ID | Feedback | Response |
User Experience Principle | General | 1 | User experience is essential for so many elements:
| 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:
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 | ||
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 |
|
This is an option for LFIs that do not have mobile channels or that are not able to offer the mobile authentication experience.
|
...
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)
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 https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#8.-Authorization-Time-Window Re: Multi Authorization The consent will move to a Rejected state as explained in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/56885249/Consent+Setup#4.-Consent-States Please refer to the section which details the flow for multi authorization 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. 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 | https://openfinanceuae.atlassian.net/wiki/spaces/StandardsDraft01/pages/39158122/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 |
|
| ||
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 | ||
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 | 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 https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528328/Multi-Payments#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 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 |
| 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· |
| Re kill switch: Rather than disabling this should be suspended so that the consents are in a suspended status. Re opting out of OF: TBCEveryone 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· |
| 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). 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 |
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. | TBCWe 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 |
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 |
| 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 |
Kindly clarify roles & responsibilities of all parties |
| ||
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. TBC. | 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 |
|
|
2 | NA | - | ||
3 | No further questions at this stage | Noted | ||
4 |
|
| ||
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 2nd engagement cycle | ||
6 | None | Noted | ||
7 |
|
| ||
8 | No | Noted | ||
9 | Feedback following 11th - 14th March Workshop
Feedback following 16th - 17th 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
Multiple payments to variable beneficiaries
Consent
| Feedback following 11th - 14th March Workshop
Feedback following 16th - 17th April Workshop Aggregation Noted - will be worked on International payments
Multiple payments to variable beneficiaries
Consent
| ||
10 | FEEDBACK | - |