1. Do you have any questions or suggestions about the overall API Security Model?
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. | @Consortium | ||
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 |
|
| ||
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. |
2. Do you have any questions or suggestions about the FAPI 2.0 Security Profile?
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. |
3. Do you have any questions or suggestions about the Registration Framework?
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. |
4. Do you have any questions or suggestions about the Certificate Standard?
...
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. | @Consortium | ||
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. Alex: 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” | Alex/Manish 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? | Alex/Manish 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 |
|
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.
@Manish The UX guidelines are prescriptive so that implementations have a standardisation and users can easily familiarize themselves with Open Finance which will help build trust.
A section specific to insurance is included in Standards V0.1 Draft-2. |
6. Do you think that the Consent should also include a predefined list of purposes for the payments or data sharing?
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. | Alex/Manish 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) | Alex/Manish 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 |
| Alex/Manish
| ||
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. | Alex/Manish 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. | Alex/Manish 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? | Warren Consents for insurance data sharing will be one-off and will therefore require a new consent for each data sharing request. |
7. Do you think that Consent Management Interfaces should be standardized in the look and feel or only on the information and language presented to the Users?
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. | Alex/Manish 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 |
· 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. | Alex/Manish Noted | ||
10 | I feel it should be standardised to an extent to have consistent user experiences across the board | Noted |
7.1 Do you think that Users should be able to change consent parameters from both the TPP and the LFI Consent Management Interface (CMI)?
...
9. Do you have any questions or suggestions about LFI Consent Management?
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? | Alex/Manish 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 | Alex/Manish 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? | Alex/Manish 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. | Alex/Manish 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). | Alex/Manish Re limit on the history of record: Noted, we will consider setting some limits in future iterations. | ||
9 | · 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. · 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. · 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? · 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. | Alex/Manish Re kill switch: Rather than disabling this should be suspended so that the consents are in a suspended status. Re opting out of OF : @Consortium 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 | · With respect to the wireframes shared, are these set in stone or they can be changed to improve overall experience? · Are LFIs responsible for these consent? Are we expected to get separate consent for TPP and a separate one for LFIs? | Alex/Manish 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. |
10. Do you have a recommendation (or preference) on which authentication model would be most suitable for UAE and which one would be obsolete?
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-
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. | Manish 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? | Manish 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. | Manish 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 |
| Manish
| ||
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. | Manish 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. | Manish 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? | Manish
|
...
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 asit can be achieved by polling and webhooks. | Alex 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? | Alex 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. | Alex - @Consortium 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 | Alex 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? | Warren 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? | Alex 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 |
| Alex
| ||
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)
| Alex 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 ? | Alex 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 |
| Manish | ||
8 | No specific questions or feedback currently. | Noted | ||
9 | · Please confirm if the facility will be limited to domestic payments in AED only
| |||
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. | Alex 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 Bank Service Initiation API - Swagger Documentation 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? | Warren A section specific to insurance is included in Standards V0.1 Draft-2. |
...
14.3 Do you think that a scheduled payment, which was consented using a beneficiary proxy, should be tied to the resolved IBAN of the beneficiary or the proxy itself? (In the former cases, the payment will always be routed to the IBAN related to the proxy when consent was authorized. In the latter, it will be routed to the IBAN that is the most recent associated with the proxy.)
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? | Alex 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 | Alex 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. | Alex Noted | ||
5 | Should be tied to the resolved IBAN of the beneficiary | Alex | ||
6 | None | Noted | ||
7 |
| Alex
| ||
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. | Alex 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. | Alex Noted | ||
10 | FEEDBACK | - |
15. Do the technical flows need further clarification?
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. | @Consortium | ||
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 | - |
...
18. Do you have any general questions or suggestions about Bank Data Sharing?
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:
| The
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 |
| Warren
| ||
7 |
| Warren 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. | Warren 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 | Warren 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 | - |
19. Do the technical flows need further clarification?
...
21. Do you have any questions or suggestions about the Common Rules and Guidelines?
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? | @Consortium |
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. | Alex
9 . Noted for info on Risk block. For consideration in future releases
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 | - |
22. Do you have any questions or suggestions about the Limits and Constraints?
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. | Alex 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? | Alex 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. | Re payments limits - @Consortium The LFI’s will be able to enforce the BAU limits irrespective of the limits set in the consent | ||
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). | Alex 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. | @Consortium | ||
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
Multiple payments to variable beneficiaries
Consent
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.
| ||
10 | FEEDBACK | - |