API
Security

Overview

1

none

N/A

2

-

N/A

3

What forensic analysis scope and capabilities will be made available on OFP, will there be APIs made available to support this?

Capabilities such as forensic analysis will be clarified in future iteration of the standards and during OFP onboarding.

3

What is the process and governance for a TPP to notify a data compromise, and any recommendations for playbooks and redbooks

This point is noted, and we will respond to it shortly.

4

FEEDBACK

N/A

5

MTLS or IP-whitelisting should be mandated between TPP and LFI

This is in line with current standards as The FAPI 2.0 UAE Profile mandates mTLS to be used on all API Connections.

5

Apart from tokens do we have any other unique identifier for ongoing session in the API headers?

Yes, the x-fapi-interaction-id is sent on the header and can be used as a unique identifier of every API call.

6

If TPP/LFI wants to make their existing APIs to be part of OFH platform, will OFH make necessary changes to adopt the TPP/LFI security standards?

LFI APIs can be made available to the ecosystem directly, under the auspices of the Trust Framework. They will not be exposed through the OFP. The specifics of the approach to doing so are scheduled for a future iteration of the standards.

OFP may have the capability to support APIs for other parties in future iterations. This is currently under discussion.

7

FEEDBACK

N/A

8

FEEDBACK

N/A

9

The overview is clear and sets form the principles we need to adhere to.

N/A

10

Would there be any conformance tool certification requirements (for example: OpenID Conformance tool)?

Yes. All Participants will be required to certify on the FAPI 2.0 UAE Tests, currently being implemented by the OIDF Foundation, prior to going live.

For the LFIs that integrate with the API Hub the API Hub FAPI OP certification will be considered sufficient for the go-live.

For the TPPs, or other participants that wish to consume data individual FAPI RP Certifications will be required

11

Currently standard defines how TPP communicates with OFP but misses details how LFI communicates with OFP/Ozone layer (central API HUB). We strongly believe that API security profile between LFI and API HUB should be clearly described inside specification as it forms end to end security model.
We propose a clear division in standard to divide api security model in two clear ways:
a) TPP - OFP
b) LFI - OFP
Our understanding is that current specification which describe FAPI usage only consider point a).  

Feedback has been noted.

The scope of the standards describe the security profile for the ecosystem, with OFP acting as Technical Service Provider to the LFIs.

All documentation relating to the security approach between OFP and LFI will be provided separate to the standards, and will be part of the OFP documentation.

API Security

Security Profile - FAPI

1

none

N/A

2

-

N/A

3

No, at this stage

N/A

4

FEEDBACK

N/A

5

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

This is in line with current standards as The FAPI 2.0 UAE Profile, an evolution of OAuth 2.0, already mandates mTLS.

5

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.

This is in line with current standards as The FAPI 2.0 UAE Profile requires Clients to use private_key_jwt as the client authentication method. Details on https://datatracker.ietf.org/doc/html/rfc7523

5

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

As The FAPI 2.0 UAE Profile leverages RaR we expect to broadcast on the Trust Framework the claim “authorization_details_types” for each existing Client. This claim defines which Consent request a Client is authorized to use, allowing for fine-grained control of what each Client on the Ecosystem will be allowed to request consent to.

6

Currently we do not use FAPI 2.0, more information will be required during implementation.

Support for LFIs to integrate with the API Hub will be provided by the Ozone team.

Simlarly, the Security and Functional API teams will support participants with questions around the published standards.

7

FEEDBACK

N/A

8

FEEDBACK

N/A

9

As I understand it, FAPI 2.0 is not a production standard quite yet? Removing the optionality where possible is exceptionally desirable as it facilitates implementation. 

Question:

Although I am pretty sure the use of FAPI 2.0 will operationally be upstream of the LFI, will the LFI externally facing gateways need to support FAPI 2.0?

FAPI 2.0 is a production standard currently being used in multiple jurisdictions. It is considered more secure and easier to implement for TPPs than FAPI 1.0 Advanced and for this reason is the baseline profile used on the OPF UAE Program.

All Participants are expected to comply with FAPI 2.0 UAE profile when sharing data and other profiles will not be accepted to ensure security and interoperability.

The LFI externally facing gateways are being provided by the OFP on behalf of each LFI, so the OFP handles FAPI 2.0 conformance on behalf of each LFI. The LFIs will need to connect to the OFP using mTLS and according to the Ozone Connect specification, which will be provided in due course.

If the LFI exposes other APIs outside the scope of the regulations, then the LFI may choose to expose their own externally facing gateway(s) and then it is up to the LFI as to which security model/profile to use in this case.

10

Is DCR (Dynamic Client Registration) option available?

DCR won’t be available for registration.

We invite you to read the section “2. Rationale for Choosing OIDC Federation as Profile Foundation” of the Registration Framework to evaluate the reasons on why Federation was chosen over DCR as the Ecosystem Registration Framework.

11

FAPI 2.0 itself does not create any further queries but FAPI itself does not have concept of Technical Service Provider where resource server and OpenID provider responsibility is delegated to third party in this case to API Hub / Ozone Layer. Security model for API Platform communication (TSP - Ozone) and LFI should be defined as it may decrease FAPI 2.0 end to end security posture (middle layer).

Feedback has been noted.

There is no perceived degradation in the security posture of the solution based on communications between the OFP and LFI not being bound specifically by FAPI.

All documentation relating to the security approach between OFP and LFI will be provided separate to the standards, and will be part of the OFP documentation.

API

Security

Certificate

Standard

1

none

N/A

2

We would like to seek clarification if there will be a provided library to address common cryptographical concerns for the regulation i.e. certificate validity and verification, signatures, etc. (maybe similar to European DSS library)

We don't expect to provide any library related to managing OPF Certificates

3

No, at this stage

N/A

4

FEEDBACK

N/A

5

No further questions at this point

N/A

6

Will this be using PKI (Public Key Infrastructure) based certificate exchange?

Yes. The Trust Framework has a PKI Integrated on it and the Root and CA Certificates will be maintained by the Trust Framework. This Process of issuing and revoking certificates will be done entirely on the Trust Framework web application. The Trust Framework will also maintain all the certificate validation services like OCSP, CRLs and JWKS

6

What will be the TLS version?

FAPI 2.0 Supports both TLS 1.2 and TLS 1.3 - Please note that not all cipher suits are allowed for TLS 1.2 under FAPI 2.0 - https://openid.net/specs/fapi-2_0-security-02.html 

7

FEEDBACK

N/A

8

FEEDBACK

N/A

9

To be clear, all certificates in the ecosystem will be issued by the Trust Framework.   Will this be centrally administered or be distributed to trusted certificate issuers like the EIDAS certs in EU?  Overall, the certificate standard is clear, what will be required from the LFI to do?

You are correct, all the PKI and the Certificate issuance process will be centralized on the Trust Framework.

LFIs are expected to issue certificates and renew the certificates that will be used by the OPH and by it's API Endpoints that aren't maintained by the OPH.

We note that the Participants are capable of delegating access on the Trust Framework to Third Parties, including members of the OPH for the process of managing certificates

10

Is it allowed for [LFI] to inject [LFI]/product/platform-specific certificate attributes? Or will it cause concerns technical / or otherwise?
Also client certificates for us are a set of two: QWAC & QSEAL for each TPP. Is CBUAE’s model compatible with this?

The Certificates Minted by the Trust Framework will have a well defined set of attributes on most of the Certificate Attributes, like the Subject Distict Name, however, for some attributes, like the X509v3 Subject Alternative Name, injecting attributes is possiblem.

All the Certificates used on the Open Finance UAE ecosystem must be issued by the Ecosystem Trust Framework, and hence, it’s not possible to use existing certificates on the Open Finance UAE Scheme.

11

Current certificate format in our understanding describe usage of them from TPP and API HUB (Ozone API Platform) perspective where Ozone API Platform performs Resource Server and OpenID Provider role on behalf of LFI at Edge. Following point 3 queries we would like to confirm if Ozone Connect and LFI interaction will use same certificate format. Following recommendation to treat Ozone Connect as OIDC entity, we assume same certificate format will be used in communication between Ozone Connect and LFI.

As noted above, communications between the OFP and LFI will take place using certificates issued by the Trust Framework.

All documentation relating to the security approach between OFP and LFI will be provided separate to the standards, and will be part of the OFP documentation.

User

Experience

Principles

General

1

none

N/A

2

-

N/A

3

No, at this stage

N/A

4

FEEDBACK

N/A

5

No further questions at this point

N/A

6

-

N/A

7

FEEDBACK

N/A

8

FEEDBACK

N/A

9

User Journey- As the forum has discussed earlier as well, with a centralized platform in place and all participants following same set of rules and flows, we can consider creating a common template for user journeys for the common processes like consent, payment etc., that the TPPs and LFIs can follow, this can help in creating a uniform language and structure across industry and will be helpful in generating user trust and increase adoption.

QUESTION-

In case the TPPs trade name, brand name is different, or TPP is providing OB services to a third party (user-facing party), the detailed information structure is given in the table as part of standards, will this full information flow in the transaction API as well? because in case of a dispute LFI needs to know the TPP as well as the user facing party, also as LFI is required to display only user facing party name, how does LFI identify the user facing party.

User journeys are modelled via the wireframes provided in the Standard. There are clear rules and requirements for the information the needs to be acquired from the user and what information must be displayed in the Consent, and the authorization screens. In addition, there are specific language requirements that need to be followed on specific elements such as the naming conventions of the data clusters and permissions. In addition, there are principles that must be applied by both the TPPs and the LFIs for creating the user journeys. Thus, at this stage we are providing wireframes for illustrative purposes, however further branded guidelines will be included in future versions of the Standard.

Yes, the information presented in the table is provided in the API during the Consent setup. Thus the LFI has the information of which is the user-facing entity, in case it is required for dispute cases.

10

NIL FEEDBACK

N/A

11

No concerns or suggestions. 

N/A

Consent

Setup

General

1

none

N/A

2

-

N/A

3

Will consent audit trail be made available by OFP through some API? What are the retention policies?

The availability of an API and retention policies will be clarified at a future iteration of the standards.

4

FEEDBACK

N/A

5

5.9 what is the criteria for determining if a consent has been fully consumed. What if the TPP accessed part of the data but not all. What if the TPP accessed all the data, but did not mark the consent as consumed – how would this be detected/avoided?

Consumed is a terminal state, meaning that the bounds of the consent have been met regardless of which API they relate to.

The OFP is responsible for monitoring consent usage, and will update the state of the consent to Consumed when the conditions are met to do so this. This includes the consumption of data sharing consents.

Criteria for the consent to be set to consumed can be found in certain entries in the Business Rules.

For AIS, the consent even for single use will be valid for a period of 1 day before it is moved to consumed to allow the TPP to make several API calls to the consented data.

The management of the Consent lifecycle across various states is handled by the OFP and not the TPP.

6

Is the Consent Management Module integrated with UAE Pass?

Integration with UAE Pass is currently being assessed and more information will be provided in future iterations of the standards based on this assessment.

6

Can we identify customers using UAE Pass?

Integration with UAE Pass is currently being assessed and more information will be provided in future iterations of the standards based on this assessment.

7

Consent should satisfy specific requirements to ensure valid consent is obtained to lawfully give effect to data sharing. The consent must meet the following criteria:

• Freely given: Consent must be given on a voluntary basis, without any inappropriate pressure or influence.

• Specific: Consent must be given for a specific purpose.

• Informed: The data subject must be informed about the processing of their

  personal data.

• Unambiguous: Consent must be an unambiguous indication of the User’s

  wishes.

• A statement or a clear affirmative action: Consent must be given through a

  statement or a clear affirmative action.
  The common component section in the Standard articulates these requirements however, the TPP should be required to satisfy its transparency obligations by ensuring its Privacy Notice is accompanied with the consent to meet data protection requirements. This should be reinforced under the criteria for consent as informed consent is an essential requirement for valid consent.

The Standard sets the requirements for the TPPs including the Consent transaparency requiremens. However, the Standard does not instruct or advise TPPs how to meet these obligations. It is the TPPs responsibility to take the necessary actions to ensure these obligations are met in alignment with all existing regulatory and policy frameworks, such as data protection.

8

FEEDBACK

N/A

9

Can you confirm that service initiation consent applies to all journeys ( Banking information and Payment Initiation) and is there any provision for multiple contents (such as four eyes checks?

Provision for multi-authorisation is provided in the standards, but this is facilitated through a single consent that is then approved by multi-authorisers at the LFI.

9

Do you have any questions or suggestions about the updated Consent State Model?

QUESTION:

Under general consent rules for OFP (point 5.8) if the OFP changes the status of consent from awaiting authorization to rejected, this status change will be broadcasted to both the TPP and LFI to update the status at their respective ends? because the draft mentions communication only to TPP, the status needs to be updated at LFI end as well.

General consent rules for LFI (5.14, 5.15)

5.14 says user must not be allowed to change any consent from LFI, and 5.15 says LFI must inform OFP if a customer revokes a consent.

So while a customer cannot modify any live consent from LFI, he can revoke it completely from LFI interface? Is the understanding correct?

As the OFP is golden source of truth on consent, and it is recommended that TPP’s should sync up their systems with OFP to ensure consistency, what is the recommended frequency of this sync and what is the recommended process for this sync up?

Feedback has been noted. More information will be provided on the supported notifications from the OFP to LFI in future iterations of the standards and during onboarding to the OFP. In this specific example, however, rejection of the Consent according to the prescribed state model always happens at the LFI, either by the User or the LFI, so the LFI will be aware of the Rejected state.

The OFP will provide an API for Consent Management. If a User revokes consent at the LFI the LFI should immediately call the Consent Manager API to notify the OFP the consent is revoke so no further operations can be invoked against that consent.

10

• Coupled / Decoupled consent.

• Redirection styles: App to app, app to web, web to web.

Unable to provide response due to insufficient information.

11

We suggest making Authorization Time Window mandatory to be set by TPP with maximum value of 2 hours and merging points 5.7 and 5.8 as one based on that Authorization Time Window will be always there so there is no need to define rule to check for Maximum Time Window as TPP will not be able to request Authorization Time Window larger than it during consent RAR request. 

The Authorization Time Window cannot be maximum 2 hours. The 2 hours window is the maximum allowable time for the submitter of the consent to authorize it. But in cases where multi-authorization of the Consent is required, the Authorizaton Time Window must allow for both the submitter and then all the following authorizers to authorize the Consent. So, the rules 5.7 and 5.8 cannot merge.

Consent

Management

Overview

1

Question

TPP Consent Management Interfaces | 2.2 Rules & Guidelines: 14

• For how long TPP needs to store the consent status data to show all past connections? 1-2year/indefinite?

TPPs are expected to keep records of the consent data of past connections in a similar manner to the data retention requirements of LFIs for payment services. This period will be confirmed as a rule in the BRs in future versions of the Standard.

2

-

N/A

3

No, at this stage

N/A

4

FEEDBACK

N/A

5

What is the complexity or consequence for users and TPPs of having the consent updated from the LFI – we do not see why there should be asymmetry between LFI consent management and TPP consent management. Please explain

Feedback has been noted. We will ensure this point is clarified in a future version of the standard.

5

CAAP should be restricted to only LFIs who do not have a digital channel as this will open the window for fraudsters if LFIs with a developed digital channel route customers to CAAP

Please can you provide further details on why you believe this to be a risk.

5

We would like firm confirmation that CAAP usage will not be mandated for LFIs in the long term. This could pose a risk by replacing bank authentication methods and confusing customers (or opening doors to fraudsters) around authentication options

Feedback has been noted. We will ensure that the conditions are for CAAP usage is clarified in a future version of the standard.

5

What will the identifier be in CAAP for non-individuals?

We will clarify this in a future version of the standard.

6

can we have a demo/training of the Admin portal for Consent & analytics/reporting modules and align on roles and responsibilities among the ecosystem players? We want pro-actively identify the new tasks and assess the FTE effort to be assigned to our employees

Training needs such as these will be addressed during onboarding to the OFP.

7

Users should remain in control of their data and consents provided to both TPP and LFI. The nature of consent signifies choice and free will of the User, therefore they should have the ability to alter consent parameters as well as be informed of the consequences of such changes. in addition, any changes should not impact the validity of processing that occurs prior to such alterations. if alterations cannot be permitted at this stage, then the consent should be rejected in the process and the TPP should obtain a new consent before data sharing can be permissible.

The consent state model reflects your understanding.

8

FEEDBACK

N/A

9

So for an LFI who is thinking of working as a TPP, does the Consent Management Interface need to be two separate entities or should it be just one?  Can we manage consents side by side if it is clear which area of the interface does what

We will clarify this aspect of consent management in OFP documentation.

10

NIL FEEDBACK

N/A

11

1. Data retention policy should be defined as part of standard for how long all consents in terminal state will be available for LFI and TPP at API HUB Consent Manager to be queried for. Point 3.3 put commitment on LFI and TPP to retain history of terminal consents for one year but, because LFI and TPP will not be golden source requirement for Consent Data and it will be API Hub responsibility (Ozone), we would like to have OFP mandatory requirement for such consent retention period defined which will allow LFI and TPP to fulfil this requirement without own consent copy storage.  

2. We believe a section is missing around OFP Consent Management Interface requirement. OFP is mandatory entity acting as middle layer between TPP and LFI. It is important that rules for OFP Consent Management capability headless interfaces are part of standard. OFP rules for consent change notification for edge parties should be defined so each entity is aware of changes performed at consent by each entity without a requirement for regular pull mechanism as part of Consent Management section not separated inside Banking Service Initiation Section. 

1. Noted. We will be updating the BRs to reflect this requirement to the OFP.

2. Noted, these will be published on Jun 28, 2024.

Consent

Management

TPP
Consent
Management

1

none

N/A

2

-

N/A

3

No, at this stage

N/A

4

FEEDBACK

N/A

5

"Max Authorization Time Window" and "Max Submitter Authorization Time Window" set by TPP needs to be standardized and cannot be left to whim of the TPP as LFIs are risk owners for payments.

The OFP will facilitate standardising these values based on security best practices and operating guidelines. Guidance will be provided in future iterations of the standards.

6

More information will be needed on the OFH Consent Management Module, we prefer to use the centralized consent management module

Feedback has been noted. More information on the Consent Manager will be provided in future iterations of the standards and during OFP onboarding.

7

FEEDBACK

N/A

8

FEEDBACK

N/A

9

This section is clear and we have no questions or feedback.

N/A

10

NIL FEEDBACK

N/A

11

No questions relating to TPP Consent Management.

N/A

Consent

Management

LFI Consent Management

1

none

N/A

2

We would like to seek clarification if a user with ‘SUSPENDED’ consent will be shown this status on the LFI consent dashboard for all TPP granted consent? If not, what will the status be?

Each consent has its own state. The SUSPENDED status is per each consent. So, if a given consent is in a SUSPENDED state other consents will not be unless they specifically placed in that state.

3

If LFI is expected to send-receive/interpret account ids in UUID/hashed form then a mapping of UUID to actual account has to be maintained by LFIs internally?

Bank Data Sharing API - Standards v1.0-draft2 - Confluence the sequence diagram on step 7001 substage it is extracting account ids from consent payload, this indicates that the consent stored and managed by OFP is persisting consent linked banking products/services? Kindly clarify.

The value of AccountId is not expected to be a hash of the account identifier. The value is expected to be a UUID that is used as a surrogate for the account value.

The correct step that relates to the activity of associating consent with given account identifiers is 5003, where an LFI confirms the accounts to the OFP. This step ensures that a given consent is associated with given accounts, as selected by the User.

4

FEEDBACK

N/A

5

Can an LFI create a flag on an account for a vulnerable user / PEP such that no open banking requests can be fulfilled? In this case, these would always fail at consent stage and an error message to TPP would say 'service is not supported'. This would be a business error not a technical error and used sparingly to protect vulnerable users (who can be tricked into OB consents) from doing so

Noted.

5

What is the maximum duration for a long lived consent? This was asked previously but not fully answered

The maximum duration for a long-lived consent is one year.

5

What is the limit on the number of historical consent records available for past connections. Theoretically it is all but in practice a system limit should be set (e.g. last 1,000 consents)

At this stage we will be suggesting past 2 years of connections available to the user.

6

Same as above

Feedback has been noted. More information on the Consent Manager will be provided in future iterations of the standards and during OFP onboarding.

7

FEEDBACK

N/A

8

FEEDBACK

N/A

9

So if a consent is revoked via the LFI CMI, what is the mechanism that that revocation is reflected back in the OFP and is there a possibility of a transaction occurring if consent is revoked on the LFI CMI but not reflected in the OFP? 

The LFI should immediately call the consent API at the Consent Manager on the OFP to reflect the removal of consent. If this change is not reflected correctly in the OFP by the LFI calling the Consent Manager then a transaction could occur.

10

1. What happens if there is a joint bank account?  Do both account holders / owners require to give consent, or one is sufficient?  If both need to give consent, then what is the flow?

2. How login live (fixed/variable) consent will work for business access with multiple authorizations?

• In case of multiple authentications with logical grouping (e.g.: - amount up to 1000 to be approved by 2 individuals from Group A and one person from Group B where both groups have at least 10 users) Do LFI need to communicate all user information to TPP and what happens in case of every approval stage?

     What happens if corporate/business opts for sequential flow for the auth matrix?

     What happens variable amount falls into multiple slabs of the auth matrix?

     What will happen to TPP instruction if any change authorization matrix, amount limit or entitlement to account for any user changes during the lifetime of long live consent?

1. For joint bank accounts, the BAU authorization process that each LFI has in place still holds. So, if the BAU process of an LFI is that both account holders of a joint bank account must authorize a payment, then this process will still be followed. Fo Bank Data Sharing, the principle is that, if a User has access to see the account information, using their login credentials, they will be able to authorize a Consent for Bank Data sharing.

2. Existing BAU mutli-atuhorization processes will be followed. The submitter of the Consent will login to provice the initial authorization and then subsequent authrozers will have to access their account to authorize the pending consent as per existing authroization matrices.

   • Yes, LFIs have to communicate certain information to TPPs in relation to Consents requiring multi-authorizations. This information is as follows:

     • The total number of Authorizers required to process the request

     • For each authorzer:

       • The Authorizer's Identifier

       • The Type of Authorizer. For example, Financial, Management, etc.

       • The DateTime of when the Authorization occurred.

       • The Status (Pending, Approved, Rejected) reflecting the Authorizer's final decision regarding the request

   • Sequential flow for the Authorization matrix is supported provided that there is enough time available in the Authorization Time Window set by the TPP.

   • In scenarios that a Multi_Payment Consent has Consent Control Parameters with variable amounts that fall into multiple slabs of the authorization matrix, the consent will need to be authorized based on the maximum payment amount specified by the Consent, or the maximum amount in Variable-defined payment schedule.

   • Changes to authorization matrix related to amounts, limits or entitlements must be handled in alignment to how these changes are reflected for other LFI services and mandates, for example Standing Orders or Direct Debits. If the BAU process of the LFI is that authorization matrix changes may trigger revocating and re-authorization of direct debit mandates or standing orders, then the same process is expected to be followed for the existing authorized long-lived Consents. However, experiences from other implementations state that changes to the authorization matrix does not trigger post-athorization changes to existing mandates or payment orders.

11

Section 3.1.3 describes a need for LFI to advise customer to contact TPP after revocation. We do not believe this action is valid as LFI after revocation will share this to OFP. TPP should query OFP regularly for valid up-to date consent status and it is TPP that should take any further actions with customer if needed. Customer already took action to revoke access at LFI it would be unnecessary step if same action should be taken at TPP side. We propose to remove this advice and describe clearly how synchronisation of consent changes will be managed between TPP ↔ OFP ↔ LFI.  

Q1: Are these statuses for consents aligned with ISO standard? 

Q2 (also asked above): Section "Consent Setup" – "4. Consent States" lists the following states: AwaitingAuthorization: Authorized, Rejected, Suspended, Consumed, Expired, Revoked.
However, "LFI Consent Management Interfaces" – "2.2 Rules and Guidelines" still lists the other set of states: Awaiting, Authorized, Rejected, Canceled, Finished.
The response to the feedback recommends referring to Consent States section but shouldn’t the "Rules and Guidelines" section be updated as well?

When Users intend to revoke Consent from the TPP, TPPs will present to them the consequences of their action before completing the revocation. For example, if a User is revoking a consent which is used to pay a loan installment, the TPP will present to them information about the consequences of doing this, before the user confirms and proceeds with the revocation. LFIs do not have the information in relaiton to the use of each consent and the consequences of revokign a consent. Thus, the BRs require that LFIs advise their Users to contact the TPP to be informed about the consequences of their actions and not to inform the TPPs about the revocation of consent. This is handled by the Standard by either polling of consent status or TPPs may have registered a webhook for consent revocation events.

Authentication and Authorization

General

1

none

N/A

2

-

N/A

3

No, at this stage

N/A

4

FEEDBACK

N/A

5

We require additional information on how this will be implemented

The technical details will be published and Guidance will provided during onboarding sessions for LFIs that wish you use the CAAP.

For the TPPs there is no special guidance as the redirection URL will automatically detect if it is a CAAP based auth.

5

What are the requirements/steps to become qualified to perform this authentication in a federated model?

The CAAP will be from the Central Bank and will have the integrations done with the LFIs that wish to avail the service.
From a LFI perspective any licensed LFI that wishes to use the CAAP can use it. The technical details will be published and Guidance will provided during onboarding sessions for LFIs that wish you use the CAAP.

5

The Limitation of Liability document must cover this.

All liability related points are covered under the Liability model which is separately published.

5

The technical flows and APIs need to be designed and shared

We have provided an OpenAPI description of the Pushed Authorization Request endpoint. All other flows will be provided at a future iteration of the standards.

6

-

N/A

7

• Biometric Authentication is considered more secure along with “behavioural biometrics”.

• For SMEs and corporate customers using TPP

a. The user details/credentials need to be validated in the authorized signatory solution/database of the bank/FI.

b. For payment transactions, there will be a transaction maker and checker. (A&A for both need to be done)

points a and b are as per BAU processes of the LFI.

8

What is the mechanism of establishing the trust between LFI and CAAP? Presumably the LFI should allow the access using tokens issued by LFI. More diagrams required on how it will be matched with the LFI-owned consent

The technical details will be published and Guidance will provided during onboarding sessions for LFIs that wish you use the CAAP.

For the TPPs there is no special guidance as the redirection URL will automatically detect if it is a CAAP based auth.

9

We trust there will be more concrete guidance in the future of how a LFI will be onboarded to use the CAAP. 

Guidance will provided during onboarding sessions.

10

NIL FEEDBACK

N/A

11

Q1: Once the user has chosen LFI, how CAAP retrieves the user contact details from LFI?

Q2: Does the central authentication and authorisation mean that user is authenticated only with CAAP and then redirected to LFI where they authorise the request, or that user authenticates only to CAAP and request for data sharing / payment is sent by CAAP to LFI without user redirection to LFI?

Q1. The CAAP has an onboarding process, (EFR process) where the Users identity is verified to get Verified Emirates ID number. This will be then sent to the LFI to identify the user and send the user details for further verification of the user.

Q2. The later, The Authentication and Authorization happens within the CAAP. There is not redirection to the LFI.

Authentication and Authorization

General

1

none

N/A

2

-

N/A

3

No, at this stage

N/A

4

FEEDBACK

N/A

5

We welcome its removal. We will review the implications further

Noted

6

we need to know what credentials will be used to authenticate the user, is it UAE Pass?

The LFI will be doing the authentication so the credentials will be as supported by the LFI.

7

FEEDBACK

N/A

8

FEEDBACK

N/A

9

N/A

N/A

10

NIL FEEDBACK

N/A

11

We prefer Redirect journey.
However, we think removal of CIBA Decoupled flow should be avoided as it introduce additional friction for customer with proposed decoupled model using redirection flow as there will be a need for customer to open manually redirect link on another device (example using QR code) - in case if customer identity matching LFI identity can be discovered up front. CIBA flow allows customer to receive authentication/authorization request on separated device thru push notification without a need for customer to take any action. We believe it should still be part of standard as available option enabled by OFP and up to discretion for TPP and LFI to support it.

We will include this feedback along with those of other participant for any future consideration for introducing the CIBA model

Bank

Service

Initiation

Overview

1

none

N/A

2

-

N/A

3

What is the provision for Maker-Checker/Approver functionality coverage for SME and Corporate account transactions on TPP platforms?

Any payment consents or payment initiations that require maker-checker/approver functionality will be using existing BAU processes for multi-authorization supported by the LFIs.

4

FEEDBACK

N/A

5

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). This should be designed as a separate journey with separate wireframes. It is not synchronous with the SIP journey.

Noted. At the moment the functionality for adding a beneficiary to a User’s LFi account using a TPP is not in the scope of the Open Finance platform functionality. However, we will look into this request.

5

Will customers who are FI, NBFI and federal entities be in scope of the open finance infrastructure

These entities will be in the scope of the Open Finance infrastructure if they meet the requirements set in the Open Finance Regulation.

6

FEEDBACK

N/A

7

FEEDBACK

N/A

8

Liability model for payments i.e. Fraud, risk, AML etc, what are TPPs responsibility for the same. Kindly clarify roles & responsibility for liability between TPPs, API Hub & LFI for various payment methods. Detailed clarify required on international payment & Ad hoc beneficiary long live consent.

Please refer to the draft Liability model that discussed at the workshop on May 21, 2024.

2024-05-21 Workshop

8

Detailed workflow missing on transaction enquiry service

Unable to provide response due to insufficient information.

8

Purpose code for payment is missing

We will be updating the Standard to reflect this.

8

Is there a standard for the purpose of transfer based on the client type (SME/Retail)?

Unable to provide response due to insufficient information.

9

This section is clear with only the caveat that it makes reference to international payments as the example.  Is it envisioned that these will be part of scope for the initial deployment.

For all payment initiations and specifically the single instant payments, as we are utilizing underlying real time payment rails of IPP, the transaction status (success/failure/timeout) should be updated immediately to all parties involved. The TPP should get the success/failure msg for payment not the payment initiated msg, so as to preclude the need to querying the system again for final status, otherwise this will add additional traffic to the network.

Question:

When do we get API specs to be used to create Aani-Bank OFP interface for payment transactions, including proxy resolution if required.

Yes, international payments are in the scope of the Standard.

The TPP will get the success/failure response for the payment initiation. This will be in response to the payment consent setup endpoint call. The response will include the information of the Payment resource so that the TPP can check the success/failure status of the payment itself.

OpenAPI descriptions that support payment initiation have been provided. Proxy resolution will be addressed at future iteration of the standards.

10

NIL FEEDBACK

N/A

11

The consent parameters should be fixed for VRP and if the consent parameters are changing, we need new consent.

Correct. VRP consent parameters cannot be changed.

If a different set of VRP consent parameters are required, a new consent must be authorized by the User, and thus they are treated exactly the same as creating a new consent. The existing VRP consent should be removed and a new consent created.

Bank

Service

Initiation

Multi-

Payments

1

none

N/A

2

-

N/A

3

FEEDBACK

N/A

4

FEEDBACK

N/A

5

Please provide the updated wireframes addressing our concerns raised in the previous feedback round; recapped below:

The messaging to customers needs to be that they are approving multiple payments, and potentially, an unknown number of payments (within the rules). This should be made much clearer. Customers may not realise it is many payments not one. Even the title should say payments in plural not in singular. A VRP is not one payment, but many in a subscription/plan

Feedback has been noted. Updates to wireframes will be included in Draft 4.

6

FEEDBACK

N/A

7

FEEDBACK

N/A

8

Can the consent for the Multi payments be authorized together with the account data access or it always require a separate consent flow?

At this stage, Multi-payments and Bank Data Sharing require separate consents.

9

QUESTION-

As we are agreeing to mTLS connectivity with OFP acting as one of the channels for Aani platforms in the bank, all the details of a multi payment transaction will remain within the TPP and TPP will trigger the the transactions at the appointed dates and the bank OFP will connect with Aani to debit customer account, no additional information will be required to share with Aani.

Unable to provide response due to insufficient information.

10

NIL FEEDBACK

N/A

11

Q1: If for variable beneficiaries where beneficiary is not known at point of consent creation an explicitly authorisation is required at point of payment, is this not the same as a Single Immediate Payment?
Therefore why add this complexity when another part of the Open Finance solution works?

There is a clear differency between the 2 cases. The TPP have a long-lived VRP Consent given by the User for initiating payments to unknown beneficiaries based on a number of Consent Control Parameters. However, in this scenario, the TPP requires explicit authorization by the User for initiating the payment when the payment is required and the Beneficiary is known. The explicit authorization is between the TPP and the User and not the User and the LFI, as it is in the case of the Single Instant Payment.

Bank

Service

Initiation

Multi-

Payments

1

none

N/A

2

-

N/A

3

FEEDBACK

N/A

4

FEEDBACK

N/A

5

We suggest VRPs should be phased and that learnings from SIP, FDP and simple recurring payments be applied first then the standards revised

Noted.

6

FEEDBACK

N/A

7

FEEDBACK

N/A

8

FEEDBACK

N/A

9

Variable beneficiary though a good use case in theory, we will recommend keeping it out of scope for now, because of complexities regarding execution, for example the petrol station example that was used in the call, can be theoretically possible only if all vendors are using same payment partner for processing payments, which is not the case in real world.

And we have already provided feedback that beneficiary should always be mapped to an IBAN not proxies.

Noted.

We do not understand the reason why you are stating that in the example of the petrol station all vendors must be using the same payment partner for processing the payments. This is not required. The payment processing TPP, will direct the payment to its onboarded petrol station vendor bank account once the authorizations conditions agreed between the TPP and the User are met.

The Standard already states that the Consent is always mapped to an IBAN even in the case the payment beneficiariy has been initially specified using a Proxy.

10

NIL FEEDBACK

N/A

11

Suggestion would be to remove variable beneficiary where beneficiary is unknown as there is no customer benefit above a single immediate payment. 

Please refer to response in question 17.11. There is a clear difference between the 2 user experiences of the suggested functionalities.

Bank

Service

Initiation

Multi-

Payments

1

none

N/A

2

-

N/A

3

FEEDBACK

N/A

4

FEEDBACK

N/A

5

Will we be having a consolidated debit feature or payments will be debited once per transaction? Ie one batch payment is debited and multiple payments sent/credited.

The current bulk/batch payment feature will implement existing LFI behaviours

6

FEEDBACK

N/A

7

FEEDBACK

N/A

8

FEEDBACK

N/A

9

Strongly recommend that Multi Payments be addressed in a follow on phase of the project as these will introduce complexity that may slow deployment.

Noted.

10

NIL FEEDBACK

N/A

11

Consents for multi-payments need to be static, complications such as consent versioning which the central platform will need to be the golden source will add substantial complexity.

Consent is considered static in terms of the parameters they include.

Operational processes such as consent versioning will be addressed in a future draft of the standard.

Bank

Service

Initiation

International payments

1

none

N/A

2

-

N/A

3

FEEDBACK

N/A

4

If TPP displays all information and LFI is only to authenticate and perform, then it could be since TPP will display all information needed for user to proceed with payment.

If LFI will display the user accounts, confirmation message, then FX to be displayed in here and user would proceed with transaction.

This also be good example if TPP has the FX calculator service based on bank selection by user for comparing rates. (If this example valid for bank to provide)

Noted.

Noted. Just to confirm your proposal is that the TPP does not display the FX rate if the User has only selected their LFI at the TPP and has not provided a payment account.

Noted, we will explore this option for the future draft versions of the Standard.

5

We think the FX rate should be displayed after consent is verified. This will allow the LFI to offer the correct rate and rate validity to the client.

Noted.

6

FEEDBACK

N/A

7

FEEDBACK

N/A

8

Cash rate with Ad hoc beneficiary will have a major liability on LFI, hence need clarity on liability model.

Currently the Standard is not proposing ad hoc beneficiary for international payments. We need more information in order to understand better the point you are raising.

8

Rate without user authentication will be the card rate, user might see another rate after authentication, if they are having pre-defined margin with LFI. Suggest having a method to handle this edge case.

Noted. However, please note that in case the user has provided their account details to the LFI, the LFI is able to return the user specific rate and not the card rate.

9

This particular use case needs further investigation and again we recommend that this should be included in phase 2, in current deployment we should focus on getting domestic payments right and widest coverage possible.

In international payments the preliminary issues that we can identify are as follows-

1. Multiple platforms: banks have variety of platforms available to offer remittance services, from card rails (Visa fast funds, mastercard send), SWIFT, to direct correspondent banking relationships, and each comes with its own commercial, risk and governance model.

2. AML/CFT requirements: remittance payments operate under rigid AML/CFT framework with scrutiny on sender and receiver identities extensive checks, specific codified purpose codes, which impact the approval rates of payments, and speed of transactions.

3. In case transactions don’t go through, checking status or reversal is complex and status of where transaction is stuck or how long it will take for a credit back is not a well laid out process.   

4. How existing rules of CBUAE on FX remittance will sync with open finance as the participants and their roles have changed (TPP, account holding LFI. Processing LFI or institution, processing rails), who carries the liability in this case.

Noted

1. Noted. The approach of the Standard is to use these payment rails as BAU without introducing any changes to these as possible.

2. Noted. Again, the Standard is not proposing any changes in relation to the rigid BAU AML/CFT frameworks for international payments. The Standard facilitates only the initiation process of the payments providing an additional channel to the LFIs, thus extending reach and adoption of payment initiation via TPPs. All existing checks are expected to take place during the processing and execution of the international payments by the LFIs, including the AML/CFT checks.

3. Noted. The Standard will use the existing processes that the LFI has in place for chekcing status and arranging reversals if required. The Standard will allow the LFIs to use the same information processes they have in their online banking or mobile banking apps for keeping the customers informed about their international payments. The information will be passed on to the TPP that the customers used for intitating the payments.

4. The liability model will be covering the answer to this question.

10

NIL FEEDBACK

N/A

11

It would be possible to share on TPP screen only standard FX rate. We're able to present preferential FX rate only on LFI screen because customer is not yet authenticated (we need to receive customer consent to share the FX rate with TPP). 

Our recommendation would be to not share the FX rate with TPP.

Noted. We will do some further analysis on this and make any updates to the standard if deemed necessary.

Bank

Service

Initiation

International payments

1

none

N/A

2

-

N/A

3

FEEDBACK

N/A

4

Not sure as there would be cases even rare ones that FX might be changed. Lock rate cases would occur if TPP will request the rate and display it to User.

In addition, the agreement shall be there in this scenario for LFI to consider the rate sent by TPP along with other transaction details to execute. Otherwise; rate will be considered from backend while performing the transaction, which may differ from TPP sent one and cause an issue.

Feedback has been noted.

5

-

N/A

6

FEEDBACK

N/A

7

FEEDBACK

N/A

8

5 mins

Feedback has been noted.

9

No

Feedback has been noted.

10

NIL FEEDBACK

N/A

11

Technically we are able to lock FX rate in UK but we need to do technical analysis and development to answer this question 

Feedback has been noted.

Bank

Service

Initiation

International payments

1

none

N/A

2

-

N/A

3

FEEDBACK

N/A

4

If the scenario is to return Rate to TPP, rate has many elements based on user segment, transfer amount, etc. for having especial rate or other. In this case, TPP has to send all needed details to return the proper FX rate.

Feedback has been noted.
We would like to understand what additional information is required.

5

-

N/A

6

FEEDBACK

N/A

7

FEEDBACK

N/A

8

Card rate, special rate without user authentication is not feasible

Feedback has been noted.

9

FEEDBACK

N/A

10

NIL FEEDBACK

N/A

11

What is "the suggested FX rate"? Our recommendation would be to not share the FX rate with TPP.

Feedback has been noted.

Bank

Service

Initiation

International payments

1

none

N/A

2

-

N/A

3

FEEDBACK

N/A

4

Not all LFIs like to expose their FX rates and prefer to keep in their Apps. On the hand, if there were an opportunity, then it would be on case based.

Noted

5

We are reviewing this.

Feedback has been noted.

6

FEEDBACK

N/A

7

FEEDBACK

N/A

8

FEEDBACK

N/A

9

Currently we don’t see how open finance can impact this, because these products are offered to corporates anyways on existing systems based on existing relationships.

Noted

10

NIL FEEDBACK

N/A

11

TBD

N/A

Bank

Service

Initiation

International payments

1

none

N/A

2

-

N/A

3

FEEDBACK

N/A

4

Does it include inward and outward?

If Fintech is licensed in UAE and have branches outside it, it still can use the open banking in UAE from and to it ?

The Open Finance Standard is looking to support the initiation of international payments

This scenario requires further analysis and details will be provided in a future iteration of the standards.

5

For Foreign currency transfer, we can also transfer FCY locally i.e I am transferring USD into an account held with ADCB

At the moment this scenario is not in the scope of the Standard.

5

What is the unique identifier to make the payment Bank name or BIC. There are many institutions which are not on SWIFT and hence they will not hold any BIC

For scenarios that the receiving LFI does not hold a SWIFT BIC, the standard support other means of identification for the LFI such as national rooting codes. Please refer to:

International Payments | 4.3 Payee Identification for International Payments

5

Can I transfer AED cross border through this mechanism

Yes, this is an international payment without FX conversion at the sending LFI and thus it is in the current scope of the Open Finance Standard.

5

How are we going to select the Purpose of Payment for the destination country (wherever applicable)

The purpose code will be added in the Standard for International payments where applicable in draft 4.

5

Few of the missing field are as below:

a.    Intermediary

b.    Ultimate Remitter

c. Ultimate Creditor

Noted. We will analyze these fields and update the Standard if required in draft 4.

6

FEEDBACK

N/A

7

FEEDBACK

N/A

8

Define enquiry service & webhook orchestration, as in some cases payment might get delayed due to compliance checks

The API specifications already provide the general pattern for enquiry on payment initiation, which will be followed for international payments.

In the current scope Webhooks provided by the OFP relate only to changes in the status of consent.

8

Service to share SWIFT post successful payment processing

Unable to provide response due to insufficient information.

9

FEEDBACK

N/A

10

NIL FEEDBACK

N/A

11

No, the FX is the main issue here. 

N/A

Bank

Service

Initiation

Bank Service Initiation API

1

none

N/A

2

-

N/A

3

No, at this stage

N/A

4

FEEDBACK

N/A

5

As mentioned in previous feedback, negative journeys need to be designed and documented

Feedback has been noted. Negative flows will be included in a future version.

6

More details sessions will be required before integration

N/A

7

FEEDBACK

N/A

8

FEEDBACK

N/A

9

the technical flows are clear and well-presented but they seem to only show the “happy” path.  As we move forward, more complete diagrams would be appreciated.

Feedback has been noted. Negative flows will be included in a future version.

10

NIL FEEDBACK

N/A

11

No question at this stage

N/A

Bank

Service

Initiation

Bank Service Initiation API Swagger

1

none

N/A

2

-

N/A

3

FEEDBACK

N/A

4

FEEDBACK

N/A

5

As mentioned in previous feedback, the business context is required to validate the payload. API contract should be derived from the business requirements. The reference point should be in place.

Unable to provide response due to insufficient information.

6

More details sessions will be required before integration

Feedback has been noted. More guidance will be provided in future iterations of the standards.

7

FEEDBACK

N/A

8

FEEDBACK

N/A

9

The payloads detailed in the API calls are sufficient for both upstream and downstream processes as described in this section of the document.

Feedback has been noted.

10

NIL FEEDBACK

N/A

11

Current swaggers define API model for TPP and OFP interaction but they do not define contracts for LFI ↔ OFP interaction.
Please provide clear swaggers divided as per below:
a) TPP ↔ OFP
b) OFP ↔ LFI  

Full details of the OFP and Ozone Connect APIs will be provided at a future iteration of the standard and during OFP onboarding.

Bank Data

Sharing

Overview

1

none

N/A

2

-

N/A

3

-

N/A

4

FEEDBACK

N/A

5

For business and non technical reviewers, we should extract the data fields from the swagger file format and place into a clear table in the business standard for review. In addition the fields are rendered poorly in Edge as below and the text is truncated and illegible.

We will provide an extract of the OpenAPI description documents in Excel spreadsheet format in future iterations of the standard.

6

More details sessions will be required before integration about data sharing from Insurance Provider

N/A

6

We need the OFH data dictionary to identify any data mapping gap, perform data quality readiness assessment and define relevant/appropriate resolutions.

We will provide an extract of the OpenAPI description documents in Excel spreadsheet format in future iterations of the standard. This will provide data attribute names and types by API.

7

Defining data accountability for TPPs and LFIs throughout the data sharing process and data lifecycle it vital. This ensures the responsible party is held accountable and clearly understands their responsibilities that flow from the process.

Data accountability for TPPs and LFIs will be defined by the Liability Model.

8

Is the account API specification final and required from LFI to support? Or will be different mapping between OFP and LFI?

The OpenAPI document provides the description of the API as deployed at the OFP and available for TPPs to call. The contract between the OFP and LFI will be defined by the Ozone Connect APIs.

9

In case a customer has more then one account with LFI, can he provide consent for sharing data for more then one account or each consent request should be mapped to one single account only?

How a LFI ensures that the TPP is asking only for the data relevant to the service he is providing and not additional data? Or we just take customer consent on face value, is there any provision for additional scrutiny by the LFI?

There is a one-to-many relationship between a given consent and the User’s accounts at the LFI. A User will select the accounts they wish to share when they authorise consent.

Consent is an agreement between the User and the TPP. What is considered relevant is bounded by that agreement, with a conscious choice made by the User. Access is authorised by the User, and an LFI must honour the consent that has been authorised.

10

NIL FEEDBACK

N/A

11

In case of other Open Banking frameworks which include central API HUB there is end to end encryption performed by using TPP certificates shared with LFI/ASPSP. This secures that central HUB is not able to access data during data retrieval process. Currently OFP will have access to all data that is being shared as process does not define E2E encryption. TLS mechanism is not sufficient as TPP communicates with OFP and OFP communicates with LFI will leads to multiple TLS sessions terminations. Could you please provide information how E2E encryption process will look like so customer data is secured to be only accessed by TPPs to whom customer agreed to share data with. 

OFP is a trusted entity in the Trust Framework and therefore shares the same certificate chain. All mTLS connections are therefore established through same trust relationship.

The OFP itself operates as a passthrough. Data is never held at rest as a design principle of the Platform, and therefore not accessible to the OFP. Whenever data passes across a public network connection it is secured in-flight through mTLS.

The only exception to this is where a TPP is required to transmit customer (PII) data during consent setup, which is stored in the Consent Manager component. In this case the TPP encrypts the customer data using JSON Web Encryption, where the encryption is performed using the LFI public key. This data is therefore not accessible to the OFP, and can only be decrypted by the LFI using their private key.

In this context, the OFP acts as a Technology Service Provider to the LFI and processes data for the LFI. The arrangement and relationship can be seen to be similar to the relationship between a Data Processor and Data Controller in GDPR, where the OFP would be akin to a Data Processor and the LFI a Data Controller.

Bank Data Sharing

Customer

Data

1

Question:

Customer Data | 6.3 Data Cluster Structure & Language

• There is dependency between Data Cluster Permissions eg. Without Accounts Basic, user can’t request BeneficiariesBasic as accountId is required to use Beneficiary endpoint. Can it be that some Parent Permission are always inherited, and can these be defined?

Additional guidance will be provided to clarify that ReadAccountsBasic is mandatory for access to endpoints that require AccountId as a parameter.

2

-

N/A

3

-

N/A

4

FEEDBACK

N/A

5

Further time is required to review this. For example, we hold the view that credit line is proprietary bank information and we do not publish this information to third parties (except where legally required). Doing so could be market sensitive e.g. credit worthiness of a private company could be revealed. A business review will be needed on whether data points can be shared and in what form.

Not all terms are clear, for example, the below options are shown for creditline type and there is room for interpretation or our systems may define these in a way that is inconsistent with other LFIs. How will consistent application be ensured?

Allowed:   UAEOF.Available, UAEOF.Credit, UAEOF.Emergency, UAEOF.Pre-Agreed, UAEOF.Temporary

Joint accounts should require consent from both parties to the account (2 or more consents from each signatory), just like a multi-authorisation journey for a business does.

Feedback has been noted.

We will provide additional guidance in further iterations of the standard to help with selecting the correct mappings.

6

More details sessions will be required before integration with Insurance Provider

Feedback has been noted.

6

We need the OFH data dictionary to identify any data mapping gap, perform data quality readiness assessment and define relevant/appropriate resolutions.

We will provide an extract of the OpenAPI description documents in Excel spreadsheet format in future iterations of the standard. This will provide data attribute names and types by API.

7

FEEDBACK

N/A

8

Get balance with Account ID will get balances of all the IBANs in the account account, we can have once more service with IBAN as well

Feedback has been noted.

8

Get transaction to have non-mandatory TPP ref ID tag for recon purpose and a tag for TPP name. Same LFI will share in API and publish in bank statement as well. This will add clarity for customer & help LFI in internal audits

Feedback has been noted.

8

APIs missing to fetch open finance payments mandate

The requirement for payment mandates will be assessed and addressed at a future iteration of the standard.

8

For functionalities not supported by LFI, how that will be handled & at what stage consent creation or get API call? Eg: Suppose a LFI does not have Direct debit as a product offering

Feedback has been noted and guidance will be provided at future version of the standards.

8

Get account will support credit cards as well or will there be a separate API for credit products ?

Please refer to Common Rules and Guidelines | 1. Supported Accounts & Payment Rails

9

I do believe that all of the data are supported in our systems but will need to validate this with our core banking/channels teams.   I do not foresee any fields that are not/cannot be supported and I do not think any additional fields should be considered.

Feedback has been noted.

10

NIL FEEDBACK

N/A

11

We need substantially more time to analyse it as it's different model than e.g. UK.

N/A

Bank Data Sharing

Bank Data Sharing API

1

none

N/A

2

-

N/A

3

-

N/A

4

FEEDBACK

N/A

5

As mentioned in previous feedback, negative journeys need to be designed and documented

Feedback has been noted. Negative flows will be included in a future version.

6

live example/integration will help identifying gaps

Noted

7

FEEDBACK

N/A

8

FEEDBACK

N/A

9

the technical flows are clear and well-presented but they seem to only show the “happy” path.  As we move forward, more complete diagrams would be appreciated.

Feedback has been noted. Negative flows will be included in a future version.

10

NIL FEEDBACK

N/A

11

No questions at this stage

N/A

Bank Data

Sharing

Bank Data Sharing API Swagger

1

none

N/A

2

-

N/A

3

Subsequent to the Sequence diagram on the below link, the flows on below steps are unclear

Bank Data Sharing API - Standards v1.0-draft2

1. 2006 – What are the typical consent pre-validation steps that OFP expects/suggests for the LFIs to perform, please cite examples. From a general understanding perspective these may be following validations

• iss / client id (UUID v4)

• "Permissions": [ "ReadAccountsBasic", "ReadAccountsDetail", "ReadBalances",...

2. Why is the Auth code generation by LFI stage shown before the Authenticate user stage in the sequence diagram, general understanding is that unless the user authenticates with LFI and gives consent to a set of accounts federated under a Consent ID, the Auth code will have no structure or mapping.

3001 – Why there is a TPP to LFI direct interaction to get the AuthCode?,

7008 – – Does OFP request contains the exact details on account and other parameters necessary for LFI to fetch the response

Additional guidance will be provided to clarify pre-validation steps.

This is not the Authorization Code. It is an interaction ID, which is used as a reference for the interaction between OFP and the LFI during the consent authorization process.

This flow is indicative of the interaction between the TPP and the LFI, when the user is redirected to authenticate themselves and authorize consent. We will revisit the flow at future iterations of the standard to clarify this flow.

The requested details will mirror the consent properties, in that the accounts required will be retrieved from the Consent Manager store and applied to the request. The association between accounts and the consent is defined at step 5003.

4

FEEDBACK

N/A

5

As mentioned in previous feedback, the business context is required to validate the payload. API contract should be derived from the business requirements. The reference point should be in place

Unable to provide response due to insufficient information.

6

FEEDBACK

N/A

7

FEEDBACK

N/A

8

FEEDBACK

N/A

9

The payloads detailed in the API calls are sufficient for both upstream and downstream processes as described in this section of the document.

Feedback has been noted.

10

NIL FEEDBACK

N/A

11

Current swaggers define API model for TPP and OFP interaction but they do not define contracts for LFI ↔ OFP interaction.
Please provide clear swaggers divided as per below separation:
a) TPP ↔ OFP
b) OFP ↔ LFI

Full details of the OFP and Ozone Connect APIs will be provided at a future iteration of the standard and during OFP onboarding.

Insurance

Motor

Insurance

Quotes

1

none

N/A

2

-

N/A

3

FEEDBACK

N/A

4

FEEDBACK

N/A

5

This will be reviewed in future

Feedback has been noted.

6

We need the OFH data dictionary to identify any data mapping gap, perform data quality readiness assessment and define relevant/appropriate resolutions.

We will provide an extract of the OpenAPI description documents in Excel spreadsheet format in future iterations of the standard. This will provide data attribute names and types by API.

7

FEEDBACK

N/A

8

FEEDBACK

N/A

9

This section does not really apply to us as we are a LFI.

Feedback has been noted.

10

NIL FEEDBACK

N/A

11

TBD

N/A

Common Rules and

Guidelines

General

1

none

N/A

2

We would recommend making the below aspects of the Risk Information Block for TPPs as optional:

• User (Payer) Indicators: Date/time of last password change, Date/time onboarded by the TPP

• Destination Delivery Address: recipient name and type, full delivery address, with region, and country

• Transaction Indicators: Contract Present flag and initiating Channel

• Beneficiary Indicators: Beneficiary Verified by TPP flag and additional Beneficiary Account holder Identifiers (such as a national ID or Passport Number for Retail accounts or business registration number for Business and Corporate accounts).

Feedback has been noted. We will review there properties and incorporate into future iterations of the standards where the review concludes that they should be.

3

FEEDBACK

N/A

4

FEEDBACK

N/A

5

It was not possible to do an itemised review since much of this was the same as last time. Please in future identify clearly if an old section has been modified for ease of review (e.g. with Delta sign of font colour or similar)

Feedback has been noted.

6

FEEDBACK

N/A

7

Is there a fraud playbook or fraud threat assessment being considered or developed in relation to open finance?

Such documentation would serve to outline the potential increased risks of fraud, its key impacts, and preventive measures.

It is also important to take into account the fraud trends and experiences of other regions that have already implemented open finance.

We are collating guidance to support fraud prevention. This feedback will be considered in that context. We aim to have it available for the next round of workshops.

7

Will the Risk Management/Fraud solution that will leverage AI/ML be deployed at the central bank?

This point is noted, and we will respond to it shortly.

7

Will LFIs have the capability to request additional information from TPPs to adequately evaluate the risks? If yes, will this mechanism be catered for on the platform?

At the moment, there is no provision for the LFIs to request additional information from TPPs in relation to a transaction in order to evaluate the risks. The Risk Information block was looking to provide all the necessary information that may be needed by the LFIs in order to avoid time consuming and lengthy interactions between TPPs, OFP and LFIs.

8

FEEDBACK

N/A

9

Common rules and Guidelines section is clear and makes sense, particularly from an LFI point of view as the responsibilities are very well delineated. 

Feedback has been noted.

10

NIL FEEDBACK

N/A

11

Q1: Questions regarding section 7. Accepted Authorisation Type:  What is a use case for Multi Authorisation set by TPP?  Is Accepted Authorization Type not set by LFI? Why LFI need to check it? What is the expected behaviour if the Accepted Authorization Type set by TPP is different than the type set up at LFI? 

Accepted Authorization Type is a Consent Parameter set by the TPP and not by the LFI. Accepted Authorization Type is set the TPP based on the use case that it needs to support. For example, in scenarios where there are tight timelines for the completion of a payment, the TPP may set this Type to Single Authorization as the multi-authorization process may not be completed in time. Moreover, there maybe contractual conditions where the TPP may require the User to be the only authorizer for the Consent.

Limits and

Constraints

General

1

Will LFI implement any rate limits per resource?

LFI should impose rate limits based on their system capabilities. Future iterations of the standard will incorporate further guidance on this subject.

2

-

N/A

3

FEEDBACK

N/A

4

FEEDBACK

N/A

5

It was not possible to do an itemised review since much of this was the same as last time. Please in future identify clearly if an old section has been modified for ease of review (e.g. with Delta sign of font colour or similar)

We will look how to clearly identify changes in a future iteration of the standard.

6

FEEDBACK

N/A

7

FEEDBACK

N/A

8

FEEDBACK

N/A

9

Are the limits described in the first table (A-1 through A-20) open to consultation or has these limits been set as the final limits that the project will go live with.  Constraints are clear.

The limits defined in the first table A1 to A-20 are open to consultation and have not been finalised. Please provide any feedback on these as you find appropriate.

10

In case of Maximum number of Retries - Does the minimum requirement still hold if the payment failure is down to an issue that would require 24 hours or more to resolve?

If the LFI is unavailalbe with an issue taht will require over 24 hours to resolve and the TPPs have been made aware of this, then this requirement does not need to be met by the TPP. .

11

We believe that NFR related to Traffic restrictions TPS should be part of standard similar to Open Banking Australia. This will allow to properly size API Hub and LFI infrastructure to handle service calls. Clear rules around TPS limits, throttling should be defined (TPS - Transactions per second).  

Feedback has been noted and details will be incorporated in a future iteration of the standards and with OFP operational guidelines.