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	The liability model must be clearly defined between TPP, the Open Finance Platform, and LFI for aspects such as availability, security, and dispute resolutions. Responsibilities and legal liabilities should be transparent concerning the use of OFP, as well as in cases of data breaches, fraud, and payments. FAPI 2.0 specification is getting mature with its updates. An observation on that, full message payload encryption is not considered in the standard but could be considered for UAE CB Open Finance specification. Did you perform threat modelling on API security model and OFP platform and if yes, what are the outcomes of residual risks and risk ratings after security controls implementation? Ozone API should support the required attributes for LFIs to detect and prevent fraud. Utilizing the existing NPSS/Aani infrastructure (API, networking, etc.) has been the primary objective since the inception of the Open Finance initiative. Could you please clarify to what extent it will be reused?	@Consortium Payload encryption is not required for FAPI 2.0 as no sensitive data is sent on the Front Channel, meaning that all sensitive data will be communicated via TLS protected endpoints, which already ensures all transfered messages will be encrypted. The API Security is built upon FAPI 2.0, that is, everything that was defined on the FAPI 2.0 CBUAE is compliant with the FAPI 2.0 profile. This means that the Threat Model executed by the OIDF around both FAPI 2.0 and FAPI 1.0 and the Security Considerations can be used for this model, for example - https://arxiv.org/abs/1901.11520 The API standards will contain a risk block with metadata supporting LFI transaction risk analysis and fraud detection. The options around this and the feedback have been articulated in some detail in conversations with the LFIs.
		10	The API security model seems to be very banking specific, what variations should Insurance Companies expect in the overall security model?	The API Security Profile is data agnostic, that is, there’s no significant difference on the FAPI layer between Banks and Insurance companies.

...

Section	Sub Section	Participant ID	Feedback	Response
User Experience Principle	General	1	User experience is essential for so many elements: To keep it simple Improve accessibility To be transparent Maintain consistency Provide logical navigation Use clear language Support your customers Improving user experience with app-to-app redirection	Noted
		2	The current UX principles are fine and clearly set expectations on how to design a friendly and informative transaction journey for a user while using Open finance services. But to increase the overall awareness, and trust in Open Finance among the users TPP/LFIs need to establish an information repository or a help centre for their customers (can be bundled with the consent management page) where users can get access to: FAQs on Open finance related processes Best practices to identify and avoid fraudulent transactions Redressal mechanisms in case of any dispute/fraud or any other unforeseen issue with appropriate email ids and phone numbers to lodge complaints with the concerned TPP/LFI (inline with the dispute mgmt. procedures enforced for OF) Information regarding data usage and retention policies if the consent is revoked And this information page can also be templatized/standardized across TPP/LFI so the user is comfortable seeing similar information across participant interfaces, and this will help generate more trust in the platform and clampdown on misinformation by bad actors.	@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 `accept-language` headers that are set by browsers) to provide an indication of preferred language
		9	We suggest the summary information step for vulnerable users should be provided to all users for the first time they use open finance. · Do the User Experience Principles ensure accessibility for users with disabilities or special needs?	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	For Informed decision making, is AI expected to be play a big part in the open finance platform? Is Single Sign on Integrations expected between TPPs and LFIs? Will this be facilitated by the CB UAE or will integrations need to be done individually with each TPP? Every LFI and TPP have their own CX/UX Principles, how does CB UAE aim to consolidate this across all LFI or TPP on the Open Finance Platform? This is very banking specific and what can Insurance companies expect here?	No use of AI is planned in the current release. On the Ozone roadmap, we are reviewing the use of AI to deliver a natural language search on developer portals and for querying report data. This will not result in additional work for LFIs. Manish 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. @Consortium @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. Warren A section specific to insurance is included in Standards V0.1 Draft-2.

...

Section	Sub Section	Participant ID	Feedback	Response
Consent Setup	General	1	It is recommended to have in the consent for audit and compliance matters. On the other hand, For any payment, purpose is mandatory for initiation by the LFIs, which will be part of the payment initiation request. So, shall TPP collect those mandatory from the user and pass it in the payment request along with others parameters to LFI through OFP? Alternatively, when user authenticate the payment request in LFI app, LFI to display the additional fields needed and then execute the request (example; in single payment request)? Having said that for consent standards for TPPs for look and feel and user journey through its app.	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) Customer to Business Customer to Govt. Business to Business Business to Govt. Govt to Customer Govt. to Business Business to Customer On Level 2 will be single payment or multiple And level 3 will have a brief description explain the context (this can be a free text field to be entered by TPP) The way the consent table is designed in the multi payment section of the shared document is a good example. But for data sharing request it might be tough because we will have to think an exhaustive list of business use case and codify them, and still make a provision to accommodate new use cases in future. Question: What are rules regarding Consent request expiry (authorization request expiry)? consider a scenario where a consent request is triggered and customer has not approved it, till when the consent request will remain valid. Question: This was raised in the workshop as well, in case of accounts that require multi-level authorization (joint a/c or business a/c), what happens if the authorization request expiry is reached but all consents have not been granted? Question: In case of multi-level authentication, how does LFI keep the TPP informed of consent progress, just one time update of consent granted when all approvals are in place, or approval by approval communication to TPP (ideally this should not be recommended because this is a risk revealing a client’s approval matrix to the TPP)	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 https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#18.-Multi-User-Authorization-Flow Re: Notifications on Multi Authorization Please refer to the following two sections which details on how the TPP is notified. The TPP will receive the list of pending authorizations. https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#CRG-17.4-Multi-User-Authorization-Flow-Notifications and https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#18.-Multi-User-Authorization-Flow The TPP will be able to inform the LFI if they want to support a multi-auth flow and the expected timeframe in which they expect all the authorizations to be complete. The TPP needs to know the different authorization states to fulfil their use case. We will consider including a guideline where the LFI can inform the user that the information will be shared with the TPP about the pending authorizations.
		3	Needs further analysis	Noted
		4	Yes, it will be easier if more things are standardized.	Noted
		5	YES	Noted
		6	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	Will there be different type of consent other than Account Information for the data access? F.e. Beneficiaries? Will there be different type of consent than Single/Multiple payment? S.a. Credit repayment? Validity of long live consent Is there a cap on number of consents per TPP Can the consent be modified For raising suspension what will be the process Which consent supports user induced payments like vendor payments, bill payments etc For change & update in the consent what is the detailed workflow. If consents are immutable.	Alex/Manish Data sharing will be based on the cluster(s) of data requested by the TPP as explained in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528609/Customer+Data#6.3-Data-Cluster-Structure-%26-Language Single and Multi Payment are differentiated based on the duration of the consent whether it is Single use or a long-lived. These can support a range of TPP payment use cases including Credit repayment. The validity of long-lived consent will depend on the Consent Expiry as well as the control parameters and the schedule which are setup based on the type of long-lived consent. Examples are detailed for payments under https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528328/Multi-Payments#6.-Multi-Payments-Common-Rules-%26-Guidelines There is no such cap Yes. For details refer to the section on Consent updates under https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528328/Multi-Payments#5.-Consent-Updates @Consortium Both Single and long lived consent can support these use cases. For details refer to the section on Consent updates under https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528328/Multi-Payments#5.-Consent-Updates
		8	We believe users would benefit from a predefined, industry accepted list of ‘purpose for the payments’ and ‘data sharing’ – at least at the beginning of Open Finance rollout, to help educate user through standardisation. While TPP business models will vary, the underlying consent mechanics are the same and users may find it difficult to compare services/consent if there are significant different descriptions (to the same underlying services) across TPPs (and LFIs for that matter). Furthermore, we believe that the industry should develop ‘plain language’ labelling to signal and differentiate between ‘single’ and ‘long-lived’ consent. A suggestion might be ‘one-time’ vs. ‘ongoing’ consent – this is important to ensure (a) users understand how long they are consenting for; and (b) we have a simple and consistent way to describe consent models across TPPs and LFIs. Take this one step further, and such an approach would support the establishment of central knowledge repository – provided by the CBUAE – to define the industry accepted ‘purpose for payments’ and ‘data sharing’ lists; the nature of ‘one-time’ vs. ‘ongoing’ consents; how consents are managed and changed across TPPs and LFIS; and potentially a list of all TPPs and the services they are licensed/authorised to provided (i.e. and linking to the information above). This can act as an independent and trusted source for users, to help them navigate the nuances of Open Finance. In General Consent Rules, the specifications talk of a scenario where the TPP is not the user facing entity; however past conversations with CBUAE have indicated that TPPs must act as principal and face the user directly. Please clarify this. We understand that TPPs can provide services for others, however it is not clear who the user will face and how services will be presented to uses and LFIs (in terms of consent authorisation). Further clarification is required on the nature and obligations of consent management ownership. It has been discussed the OFP will provide banks the means to ‘manage consent’ as part of the LFIs ‘extended infrastructure’ – which we understand as being a ‘consent-as-a-service’ capability provided by OFP. LFIs should retain ultimate accountability for consent as a gatekeeper and data protector of its clients – however given that this will largely be facilitated by OFP, liabilities must be clarified and agreed before any model can be set. Finally, we acknowledge that LFIs should not allow users to change an active consent via the LFIs consent management interface/dashboard, however LFIs MUST allow users to revoke consents from LFI consent dashboards. The LFI is the trusted financial provider to the user and should act as a trusted partner for users to view and revoke, consent requests (this is particularly critical in the case where TPPs make the process complex or prohibitive). We understand this is the case – however we wish to reemphasis the importance of this capability.	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 https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52527629/LFI+Consent+Management+Interfaces#3.-Consent-Revocation-Journey
		9	Yes, however predefined purposes should not be overly restrictive or limit users' ability to customise their consent preferences. There should also be provisions for users to specify custom purposes or provide additional context when granting consent. · Question: why can’t we use the single-use consent for an FDP? It can be scheduled, and the request sent to the LFI, and no more consent is required as ongoing. For a single FDP, long-lived seems over-consenting and opens up risk with regards to misuse of a consent. · Consent suspension: it is not clear why it is necessary to have consent suspension. Is it not sufficient to revoke the consent and request a new one once the fraud is mitigated or suspicion removed? · 5.10: change parameters in LFI. Is it a valid use case for a user to reduce the scope of a consent in the LFI’s CMI? E.g. I shared 2 accounts, I changed my mind and now I only want to share 1. A new consent could add friction.	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.

...

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 https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528609/Customer+Data#5.-Consent-Updates Re : creditors account number - This is displayed optionally based on use cases( e.g P2P payment). It’s not mandated to display it.
		3	· Section 2.2 – Rules & Guidelines ID ‘3’ Consent State (“Awaiting", "Authorized", "Rejected", "Canceled" or "Finished") – States highlighted in red are not aligned with defined ‘Consent State’ in Consent Set up. Please clarify the which one is the right state? · Section 2.2 – Rules & Guidelines ID ‘12’ – Is there any duration limit where Bank MUST provide a record of all past connections? Or it will be since inception of user account?	Alex/Manish Re Consent states - Please refer to the updated content on Consent states at https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/56885249/Consent+Setup#4.-Consent-States Re duration limit on the history of connections: The BANK must be able to provide all past connections of a user authorized with them.
		4	There should be an easy way of notifying TPP when the user revokes the consent on LFI side - For example using webhooks for notifications.	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	For change & update in the consent what is the detailed workflow. Are consents immutable? Who will create consent id?	Consents are immutable It will be possible to revise some elements of a consent by referring to the “base consent” the first consent in the group TPPs generate the consent id
		8	We propose the use of ‘Pending’ rather than ‘Awaiting’ as the label for the first (pre-authorized) state, as this is more logical to end-users. In point: 2.2 Rules and Guidelines (ID12) – we propose to place limit on the number of historical records available for past connections (e.g. 2 years).	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). Any suggestions to improve the UX are welcome. Re : Consent responsibility - The consent is requested by the TPP and the same consent is authorized with the LFI. There are no separate consents. The TPPs must display the consent (s) details at their end and similarly, the LFIs must display the same at their end. Both are accessing the consent details from the OFP.

...

Section	Sub Section	Participant ID	Feedback	Response
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	Is there any guideline on what is the transaction narration that will be passed in the transaction statement for the single instant payment transaction done on OFP Why do we need to display payee account, it should be an alias or masked, a business will not want to expose its account number to the customer from whom he is collecting funds. What is the expiry window for SIP requests both single authorization and multi authorization scenarios, is one day or 23:59:59 of consent date is default value? If not then what window can a TPP set both minimum and maximum?	Alex The Payer Note field is used to capture any user initiated narration in relation to the payment that may be used in the user’s statement. However, different LFIs may support different formats for the statement entries of payments. Agreed, thats why there is a note in the BRs in item 1.1 of section https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528102/Single+Instant+Payment#3.1-Rules-%26-Guidelines which states that “Depending on the use case, the Payee details may not be displayed to Users in full.” For Single Instant Payment (SIP), the authorizatoin expiry window can be set by the TPP, if required. The Consent will be awaiting authorization till this window has expired. If this is not set, then the SIP Consent will be awaiting authorization till the https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528887/Limits+and+Constants#Max-Submitter-Authorization-Time-Window expires. After authorization, the SIP Consent will remain valid till it is consumed.
		3	No question at this stage	Noted
		4	It’s important to define a set of errorCodes - indicating why specific payment was failed. We assume not all single payments can be instant (like internationals or with higher value) Also what about purpose codes which are currently used in banking - they have an impact on payments being instant or not.	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	Will there be provisioning for the inline MFA flow? E.g. the TPP is the one to send to API the OTP provided by user instead of the LFI’s embedded screens. Are the single payments requiring OTP authentication For corporate clients or multi-user flow what is required at LFI end What are the identifier that is required to be sent for reconciliation purpose For payments under open finance are LFI required to follow pre-defined user limit for each user or per day limit for account as a whole or these payments will bypass these internal rules. What is the implication on complex account payment approval matrix	Manish Embedded authentication is not supported. The authentication will be done either by the LFI or by the Centralized App trusted by the LFI. The LFI screens are not embedded. The flow will use redirection. Single payments will be authenticated using the Multi factor authentication used by the LFI ( biometrics etc). Once the user is authenticated the consent authorization( Single payment in this case) must not require any further Authentication to avoid friction in the OF journey. The LFI will authenticate the user that initiated the OF journey and after authorization from the user thfirst user they will send the Pending status to the TPP. The LFI follows the BAU process for the authorization from all the authorizers and the TPP will be made aware after each authorization. Please see https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#18.-Multi-User-Authorization-Flow for details The LFI can apply their internal BAU limits for payments
		8	No specific questions or feedback currently.	Noted
		9	· Please confirm if the facility will be limited to domestic payments in AED only. This excludes domestic payments in foreign currency to a TPP. For e.g.: One time insurance premium paid to Zurich in USD. · Presenting supplementary information to Users should not be a decision and evaluation of individual LFIs or per payment journeys including instant payment transactions. This needs to be standardized with the information to be displayed and should be mandatory by LFIs. Otherwise social engineering attacks will be much easier to be successful. · Proxy resolution process stated in "IBAN of the Payee returned by the Proxy resolution process" needs to be explained in the documentation. · Instant payment transaction amount limit is not mentioned and by which participant it must be enforced (OFP/TPP/LFI). · This statement needs to explicitly define what data must be shared by LFI as minimum mandatory "6.10 Provide the TPP with all the available information in relation to the initiated Single Instant Payment (SIP) instruction including the payment’s unique identifier Payment Transaction ID." · For each consent and payment activity, notification to User via email and SMS must be mandatory and set in specification by defining clear responsibilities (TPP/OFP/LFI). This will help to prevent fraud activity to further increase its damage.	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.

...

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	-

...

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 Payer note will be reflected in the standards. It is optional but if sent should be displayed by the LFI in the users' statements. 9 . Noted for info on Risk block. For consideration in future releases The explicit consent will be given to the TPP. We will consider adding the guidelines for TPPs to include sharing of this information if multiple authorizers are involved. Authorization Time Window" is included to aid the TPPs to cater to scenarios where the user has been redirected and they take too long to authenticate/authorize the consent. Similarly for multi-authorization scenarios. For example for an in-store payment, the TPP would expect a short “Max Authorization Time Window” after which they can simply abort the transaction. These cannot be set by the LFIs
		10	FEEDBACK	-

...

Section	Sub Section	Participant ID	Feedback	Response
Limits and Constraints	General	1	Can LFIs limits number of TPPs engaged with? In general, there would be imitation from LFIs for sharing data to TPPs in regards to their compliance, risk and security departments, which make it a bit difficult for TPPs to have such service to provide to users. What is the procedure set? In addition, is there a chance that LFIs will show resistant for any TPP that wants to engage? That LFIs would have many rejections reasons or difficult due diligence done for a TPP. Customer’s education and awareness could be cause limitation in using open banking, but with having clear business model, security, data privacy, Interoperability and Standardization guidelines and regulations for TPPs and LFIs, it would reflect a confidence image to users.	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	Any SLAs on the API performance? Limit of number of transactions / direct debits etc. that can be fetched (number or date). Any constraints on the minimum range of fetched transactions? For example PFM use cases require multiple years of data to provide value to the end user.	Ongoing piece of work - this will be defined but is currently tbc. At a minimum this will be the same as data provided on direct channels, but may be increased later if required for certain use-cases or consistency across the ecosystem.
		5	NO	Noted
		6	None	Noted
		7	Who will maintain the retry register, as many times banks will not even receive the request Who is responsible to maintain the idempotency of the payments Who is responsible to maintain time matrix for the consent authorization Who is responsible for VRP constraints checks Kindly clarify roles & responsibilities of all parties	Not clear on the question here - the TPPs can retry failed authentications OFP The LFI provides this information to OFP. OFP sends on to TPP Detailed breakdown in business rules of the responsibilities of OFP and those of LFI. General principle is that LFI has the data required to enforce a policy, it will do so.
		8	In workshop discussions it was proposed that TPPs should be able to facilitate payments that are beyond the value limits that LFIs set in their own channels. The argument was that this would be ‘managed’ through the liability model. We strongly reject this proposal. As an operating principle, LFIs should not be expected to entertain payments beyond their own limits. Banks in particular, as regulated entities, have arrived at their limits through an assessment of their respective control environments and evaluation of their risk appetites. These should be preserved (not compromised) to ensure the ongoing integrity of UAE the financial system. Furthermore, while it is proposed the OF liability model would support TPPs to facilitate payments beyond LFI limits, we fail to see how TPPs will be sufficiently capitalised and organised, to bear the transfer of liability, that would be required in these instances.	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	Any TPP would be registered with the trust framework and OFP as per the understanding, and request from TPPs to LFIs would be through OFP. Would LFIs have arrangements with TPPs? Like approving them in the first place to work with them. Is there TPPs Onboarding with LFIs? If so, how it would be? Is there a portal for LFIS to view their engaged TPPs? Does this portal have option to disable any TPP that LFI does not want to work with and receive requests? If so, how this workflow works? For employees under corporate organisations, how they can leverage from TPP apps and whether there are standards for them to use TPPs apps taking into consideration their corporate access in their LFIs? There are two types of VRPs; sweeping and commercial, according to the understanding that payments will serve both. Please advice.	All TPPs that have the appropriate license from central bank will be registered on trust framework and will interact with the OFP No. TPPs will be licensed by CBUAE. Automated by OFP using information in trust framework Yes. Admin Portal on OFP. The portal does have the capability to blacklist / whitelist a TPP, but this capability may be disabled. TBC. @Consortium Alex/Manish : Yes the VRPs will support both types of use cases. We have not finalised any commercial model around the VRPs.
		2	NA	-
		3	No further questions at this stage	Noted
		4	Glossary is missing, LFI, OFP are new abbreviations - which are missed. There should be a good description - of what requirements and use cases need to be filled by TPP, LFI, OFP. Many links are not accessible, so it’s hard to do a deep dive. For Data Sharing, single-use consents currently are defined as a single Data Sharing immediately after consent; this is a bit vague and will lead to misunderstandings for TPPs so it should be more precisely defined by a maximum expiration datetime from the time of creation In addition to the above, error codes are missing. As stated above we think defining a set of error codes will help both LFIs and TPPs.	A Glossary will be included in a future draft. This issue will be resolved for Standards v1 draft 0.2 A expiry time will also be added where appropraite (e.g. for SIPs) Noted - will be added on
		5	It would appear that the regulations in their current form focus more generally on the Banking Industry, wherein the Insurance Industry has been included as an Add-on. It would help the insurance companies, if more specific drilldowns relating to the Insurance Operations are incorporated into these processes.	@Consortium
		6	None	Noted
		7	Will LFI be allowed to integrate directly with TPP via their own proprietary APIs & open banking infra? How the integration will happen for customized use cases between LFI & TPPs If an LFI is already having an open banking flow with their own proprietary consent & identity infra, can they continue to use that or they will have to migrate to OFH. For Banking as a service related use cases what are the provisions Are there any classification of mandatory & non mandatory APIs or all the use cases be it the mentioned or future use cases are required to be routed via OFH What are premium & non premium API, is there any difference between the integration of both. Can an LFI bypass OFH & integrate directly with TPP for customized use cases	@consortium We intend to provide this capability through OFP, but likely a 2025 roadmap item @consortium We intend to provide capability to expose “premium” APIs through OFP (2025 roadmap) @consortium @consortium Yes, although it may be a lot easier through OFP as various parts of the platform like trust framework and consent manager can be leveraged
		8	No	Noted
		9	Feedback following 11^th - 14^th March Workshop Regarding all OFP platforms e.g. OFP, Ozone API Hub, Radium CA infrastructure and Federation Platform; Legal responsibility and liabilities must be clearly documented and agreed with LFIs in case of service disruption, security incident or data breach at OFP platforms which will be managed by the new established entity itself in the cloud. OFP should publish consent updated as events/API/etc. for LFIs for synchronization purposes (e.g. consent revocation, or for complex use cases involving non-individual customer segments). What are the measures of a TPP full compromise scenario in means of prevention, detection, containment and recovery at OFP end to protect LFIs? To prevent a user to be a victim of social engineering, what measures will be expected and enforced from a TPP to prevent, detect and recover and how OFP will perform assurance on this? What will be the security and privacy standards of TPP infrastructure and application(s) (web/online and mobile), and any security/compliance/audit report or certification before onboarding of TPP will be required which will confirm OFP defined baselines and standards for both TPP infrastructure and application(s) (web/online and mobile)? How TPP application’s (web/online and mobile) OFP security assurance regarding security posture of the application (With business logical attacks and security vulnerabilities) will be continuously ensured? Will there be public endpoints for TPP/LFI consumption? For any public endpoint, what is the plan against Layer 3,4,7 DDoS attacks for mitigation at OFP end? Will OFP environment (Including all components e.g. API Hub, Radium, UAE Trust Anchor) pass SOC 2 Type 2 audit or any security/compliance certification before go-live? Will full message payload encryption be considered in API design? FAPI security profiles are going to be enforced by CBUAE or can we configure on our own (as LFI/TPP)? For example, read-only, read-write. Will the concept of detached signatures be used where the payload is sent separately from the signature, reducing payload size and improving transmission efficiency? This is w.r.t JWS token. Will the encryption algorithm for data in transit or at rest be defined? Is there any duration defined for key rotation? This is for encryption keys for payloads or sensitive data. Will the minimum key size be set? (2048 bit or 4096 key size) This is for encryption keys for payloads or sensitive data. Will there be WAF to protect all OFP API endpoints working in block mode? What will be the security and privacy controls for data protection and against data infiltration at/from OFP environments (OFP, API Hub, Radium CA, Federation Platform and Portal)? (Mapping to NIST SP 800-53 is possible with your reply?) What will be the protection against ransomware in OFP platform? In addition to MTLS, IP whitelisting will be configured and enforced by all parties which will increase security? (TPP, OFP, LFI) How OFP environments application and security monitoring be performed by whom and continually? For all cloud platforms to be developed and managed by OFP, compliancy to “CIS Microsoft Azure Foundations Benchmark (latest version)” and “NIST SP 800-53 Rev. 5 compliancy” will be targeted and achieved? For all cloud platforms to be developed and managed by OFP, could we able to onboard our Cloud Security Posture Management tool and review security posture of the cloud platforms managed by OFP? For all cloud platforms to be developed and managed by OFP, UAECB requirement for using customer managed key for data at rest encryption will be followed? (Platform managed keys for encryption must not be used) What will be encryption strength for data in transit and at rest, will be secure enough against Quantum computing attacks like harvest and decrypt the data? We have multiple segments of users (Retail, Corporate, SME etc.) and the application used by users of these segments are different. We need to figure out a way to route the consent management to the respective applications from the TPP. Feedback following 16^th - 17^th April Workshop Aggregation Regarding collection of Account Data, from both an efficiency and UX optimisation perspective, how is Account Selection handled for Corporates who hold innumerable Accounts? International payments Please advise if there is any FX conversion between any currency pairs maintained in the hub to facilitate payments wherein payment instruction will be in AED but TPP converts FCY to AED. FX rates may be proprietary/preferential - an LFI may share a rate that is dependent on the genuine customer profile that is asking; rate validity varies between suppliers - this should be customised by LFI; no SME/Corp journey with multi-auth will survive a 5min rate validity; purpose codes seem to be missing; some banks have add bene as a different journey to pay - including a cool off after add bene - there would be no reason to give the TPP a preferential flow - with different level of fraud control - than LFIs’ own journey; similarly LFI may vary the cut off and availability of corridors according to business need Delivery of international payments should be phased to take place after domestic payments are up and running and effective Liability model is missing and limits our ability to understand the risk being borne by LFI Multiple payments to variable beneficiaries Given the complexity & nature of the payment being a marketplace rather than a linear payment this should be delayed for delivery in future releases Beneficiaries are linked at account level not customer which poses an issue as LFI may not be able to share all beneficiaries across all accounts (including joint accounts) in this scenario - this is overly excessive data sharing Purpose code for payments must be mandatory Consent We firmly believe that suspension of consent should be fully managed by the LFI Currently, the use and use cases for when a suspension apply are unclear. For cases of fraud or security, “Revoked” consent status may be more fitting. “Suspended” consent status is more suitable if it’s a customer request e.g. customer raise an issue with a TPP and wants to safeguard activity at the LFI till its sorted. For consents that times out after being in pending state due to in-action of LFI/User what will be its terminal state More detail is required for the multiple authoriser (corporate) use-case to understand the additional work required for LFIs Detailed list of the validations carried out by the OFP should be shared to help LFIs understand if any additional checks are required CAAP should be restricted to only LFIs who do not have a digital channel CAAP should not be used in the long term to replace bank authentication methods What will the identifier in CAAP for non-individuals?	Feedback following 11^th - 14^th March Workshop @Consortium Noted. Will be supported through calls on Ozone Connect TPPs can stop their access in the event of compromise by revoking their certificates Radium Radium Radium Radium Radium Encryption of PII from TPP to LFIs is being worked on as part of the standard so that OFP does not store any PII. Radium We do not plan to use detached signatures. The experience with the standards in UK is that it lead to a lot of implementation complications for TPPs and ASPSPs. We favour full JWS payloads these days. Yes - we are working on a solution to transmit PII from TPPs to ASPSPs as a JWS inside a JWE. Not at present and this will probably be the responsibility of each participant to decide upon based on their security posture Yes. This is defined in FAPI 2 and referenced BCP. TBC. WAF and mtls do not work well in conjunction, but Ozone is actively working on identifying alternatives. Ozone operates under ISO 27001 and SOC2 compliance. We do not publish mappings to NIST controls. The OFP platform will not store PII. IP whitelisting is supported for access to admin portals. Will not be supported for access to auth and resource servers. This is the responsibility of the suppliers - Ozone and Raidiam. Not in the current plan No All the sovereign cloud policies will be adopted. Our understanding is that this is one of the current policies See https://openid.net/specs/fapi-2_0-security-02.html and its references to ciphers in 5.2.2 (Pt 1) and 5.2.2.1 We will work with each LFI to recommend the appropriate approach during onboarding Feedback following 16^th - 17^th April Workshop Aggregation Noted - will be worked on International payments Currently there is no expected functionality in the OFP that will be providing FX pair conversion as per the question. If the users account identifier is provided during the FX Rate Request by the TPP, the LFI may be able to return the agreed/preferential rate a user has with the LFI. If that is not the case, the rate the the LFI will return may be an rate that the LFI will be providing to users during a specific period of time. We agree that no timing window will be appropriate for the scenario of multi-authorization, but this case is more complex. If the corporate has a forward rate agreed with the LFI, then this will be the rate that will be used throughout the authorization process. If not, then the LFI has the opportunity to upsell and agree a forward rate with the first authorizer, and that will be the rate that will be presented for authorization to all authorizers. If that is not the case, then the fx rate presented to each authorizer will be the rate on the time of authorization (which is alinged to the LFIs' BAU process). Again, the release of the Standards should not be associated with the timescales for implementation by participants. @Consortium Multiple payments to variable beneficiaries The variable-beneficiaries for multi-payments functionality is documented in the Standard and will be included in the Standards release. The implementation of the various functionalities included in the published standard will be communicated to participants by CBUAE. (@Consortium to review) We will be updating the business rules to make the purpose of the payment mandatory in the following versions. `PaymentPurposeCode` is included in the standards Consent Agree. We will update this in the guidelines Suspension could be for any fraud suspected on user account or TPP activity or as requested by the User ( like a pause on card usage) The terminal state in this case will be Rejected @Consortium Included in business rules Manish 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. same as above CAAP’s current scope is for personal users only. The details for business entities is work in progress.
		10	FEEDBACK	-

Version	Old Version 32	New Version 33
Changes made by	Alexandros Dimitrakoudis	Manish Haldankar
Saved on	26 Apr 2024	26 Apr 2024

Versions Compared

Key

1. Do you have any questions or suggestions about the overall API Security Model?

Page Comparison

Versions Compared

Key