Bank Service Initiation

Confirmation of Payee

1

None

Noted.

2

CoP business rules relating to Payer's LFI have been removed from the Standards draft 5, including the sentence below:

"LFIs MUST:

5.1 Request the OFP to perform Confirmation of Payee for the Payee Identification provided in the staged payment Consent. "

Does it mean that Payer's LFI doesn't have to or can't request OFP to perform Confirmation of Payee service? 

2. BR COP-2:

"TPPs MUST:

2.1 Send a request to the OFP in order to discover the LFI entity of the Payee that will be used to confirm the payee using the COP service and receive the information of how to make a Confirmation of Payee (COP) API call to the Payee’s LFI.

OFP MUST:

2.2 Resolve the request received by the TPP and respond back to the TPP with the information of how to access the COP service on the LFI entity that holds the Payee Account."

But BR COP-3:

"TPPs MUST:

3.2 Request the OFP to perform Confirmation of Payee for the Payee Identification provided by the User for the payment Consent.

3.3 Provide the necessary information to the OFP to execute the Confirmation of Payee service."

OFP MUST:

3.4 Make a Customer Data Request to the Payee’s LFI" 

Also in the Payee API design there is nothing indicating that TPP will make a Confirmation of Payee (COP) API call to the Payee’s LFI / access the COP service on the LFI entity so why OFP shares this information with TPP?

Correct, the payers LFI is no longer required to undertake CoP. This position could be reevaluated in the future. LFIs are not required to perform CoP as was defined in previous versions of the Standard.

LFIs are only required to return requested information in the Parties endpoint to be used for the CoP operation, as per the Bank Data Sharing functionality obligations defined in the Open Finance Standard.

BR COP-2

BR 2.1 refers to the activity of Discovery. Before a Confirmation of Payee (CoP) operation takes place, the TPP will need to resolve the LFI that will service the account properties request.

This is because the APIs for a given LFI are always physically separated in the OFP implementation.

BR 2.2 refers to the response of the OFP to the Discovery process. The OFP will return back to the TPP:

• the Authorization Server URL, where the Access Token to invoke the Confirmation of Payee operation for the beneficiary LFI entity should be sought, and

• the Resource Server URL, where the Confirmation of Payee operation for the beneficiary LFI entity should be invoked.

BR COP-3

BR 3.2 and 3.3 refer to the Confirmation of Payee endpoint call the TPP MUST make to the OFP to initiate the COP operation. As stated above, there will be a separate endpoint for each of the beneficiary LFIs, and the discovery process will help the TPP to identify the correct endpoint to call.

BR 3.4 Refers to the action taken by the OFP when the Confirmation of Payee operation for a specific LFI has been initiated. The OFP will make a Parties endpoint call to the beneficiary LFI in order to acquire the account name related to a specific IBAN. The OFP will then compare the payee name provided by the TPP and the account name retrieved by the the beneficiary LFI for the IBAN. The OFP wil respond back to the TPP with a Yes or No for an exact match or not. In case of not exact match the name will be returned back to the TPP both in full and masked format. The TPP is only allowed to show the masked name to the User for requesting their action to proceed or not.

Please note that there is no direct COP call of the TPP to the beneficiary LFI. The only COP call of the TPP is to the OFP specific entry for the beneficiary LFI and the OFP wil then make a call to a Data Sharing Parties endpoint at the beneficiary LFI.

3

FEEDBACK

4

We are Life Insurance Company this is not applicable to us

Yes, that is correct, this is not relevant to you subject to not initiating any payments to Users.

5

Please update document with details of use cases (e.g.: SIP) in which real time COP is required and uses cases (e.g.: TPP onboarded Merchants) in which offline COP is carried by TPP.

LFI are not required to perform COP.please confirm our understanding.

LFI are not required to store payee. please confirm our understanding.

CBUAE new beneficiary cooling period rule not applicable for OFP transactions. please confirm our understanding.

COP has been moved to a separate page and it is now referred to by the various payment functionality pages that need to use the COP service. In summary, COP can be used in the following cases:

• In the SIP and FDP journeys when the beneficiary is NOT a business onboarded by the TPP (e.g. for e-cormmerce payments) and therefore the user is providing the beneficiary details

• In Multi-Payments long-lived consent journey (with a single or variable-defined beneficiaries) when again the beneficiaries are not businesses or individuals onboarded by the TPP.

• In Multi-Payments long-lived consent journey (with variable beneficiaries) when the beneficiaries are not businesses or individuals onboarded by the TPP. In these cases, CoP will take place at payment initiation and User must explicitly authorize each payment initiation with the TPP.

• Similarly to c, for Delegated Authentication payments

Note: CoP is not relevant for International cross-border payments.

LFIs are not required to perform CoP as was defined in previous versions of the Standard. LFIs are only required to return requested information in the Parties endpoint to be used for the CoP operation, as per the Bank Data Sharing functionality obligations defined in the Open Finance Standard. This position could be reevaluated in the future.

LFIs must provide Users the option to select whether they want the beneficiary of an Open Finance payment initiaiton to be added to the list of beneficiaries for the user. User selects the option at the point of authorization of the consent.

If a user is added in the new beneficiary list, then any existing LFI processes related to the beneficiary are still relevant unless they are in conflict with the rules of the Open Finance Standard.

6

N/A

Bank Service Initiation

Confirmation of Payee

1

None

Noted, thanks

2

What will be the error returned by Payee LFI if account is not active (account status dormant, inactive, closed, etc.)? 

1.3 Step 3: Confirm Payee Account Details at the LFI - does LFI need to build only this API for CoP?

The section 3.3.2 - What is the purpose of the access token here? We believe access token should go from OFP to TPP and sequence diagram reflects that but 3.3.1 Request: Access Token Request using the Client Credentials Grant Type at the LFI Authorization Server Instance.

A HTTP Status 204 will be returned in this scenario. This is also the expected behaviour if a Payee has opted out of the CoP service.

We are currently scoping how the /discovery endpoint works, this may also require LFI build, however, is yet to be confirmed

The current design has two steps: (1) First stage to identify the LFI that holds the account using the IBAN, (2) Second stage to call a Resource server (hosted at the Ozone Platform), specifically for the LFI, which will return the CoP check. The Access Token Request in 3.3.1 is specifically for the Second stage. There may be merit in simplifying this - however, it depends on how the IBAN service (1) works, which is currently being scoped.

3

FEEDBACK

Noted

4

We are Life Insurance Company this is not applicable to us

Noted

5

1.Please evaluate the option to use UAEFTS IBAN validation service for domestic payee confirmation.

2. Did COP is applicable for International payment?

1. Noted - will investigate

2. CoP is not applicable for International Payments

6

• Why is there a need to obtain access tokens twice if everything is going through the Open Finance Platform? Going further, couldn't the whole process be simplified to only 2 API calls (auth and confirmation)?

• Wouldn't it be easier to use boolean instead of enum in AccountNameMatchIndicator?

• How will masking in the MaskedAccountName work?

1. There may be merit in simplifying this - however, it depends on how the IBAN service (which identifies the LFI holding the IBAN) works. This service is currently being scoped.

2. Allowing for an enum allows us to add other match results in the future - other than true and false

3. The masking is to be defined - we will provide additional guidance here

Bank Service Initiation

Risk Block

1

None

Noted.

2

From the perspective of user journey, the only difference is that in Fast-track SIP users don't authenticate before payment but at the moment when they confirm payment so what is the meaningful benefit of Fast-track SIP comparing to standard SIP?

There are basic differences between the Standard journey and the Fast track journey. In the fast-track journey, all the informaiton related to the payment order, including the debtor user account for the payment have already been provided by the user. So, the user only has to authenticate in order to authorize the payment and this is expected to happen in a single screen, using biometrics. In that screen all the key information required to dynamically link a payment amount from a payment account to a creditor with an user authorization, are present in the screen and no further steps are required by the LFI. User can be redirected back to the TPP with the payment confirmation.

In Standard journey, the User first authenticates with their LFI, and then is presented with a screen with account selection, or other supplementary information required to be provided to the user befor taking the decision to authorize the payment. The User then has another call to action to authorize the payment initiation.

So, the 2 journeys are quite different and have different customer experience.

3

·       Who is liable for wrong beneficiary details in case of fast-track journey?

·       LFI will run their backend process as it even through the payment is routed via OFH?

The liability model does not change between the standard journey and the fast-track journey. In both cases, the user is not able to change the beneficiary details at the LFI, only to authorize the payment. The beneficiary details are selected at the TPP by either user manual entry, are being pre-populated by the TPP. Based on this any liability of the LFI will be the same as in the cases where Users provided incorrect details for the beneficiary when initiating a payment using the LFIs existing online channels.

LFIs are expected to run their backend processess for the technical validation and profile validation and limits for the OFP intiated payments in exactly the same manner as if the payments have been initiated using the existing LFI’s online channels.

4

We are Life Insurance Company this is not applicable to us

Yes, that is correct, this is not relevant to you subject to not initiating any payments to Users.

5

1. Is it mandatory for LFI to enable fast track SIP journey?

2. How LFI understand redirect received from TPP is for fast track Single Instant Payment?

3. please provide detailed sequence diagram for fast track Single Instant Payment.

4. In initial documentation and in workshops, ozone team confirmed TPP is responsible to Initiate Single Instant Payment or Future Dated Payment after successful Consent Authentication & Authorization. But we observed in recent documentation Ozone team updated Single Instant Payment and future dated payment will be initiated by LFI not TPP. this change never communicated in workshops and bank service initiation sequence diagram not updated in latest draft .  

Draft2:

Open

Draft5

Open

Payment Initiation sequence diagram not in line with latest SIP and future dated payment description or rules. please update sequence diagram

1. Yes

2. The only difference is a Fast Track payment consent (created by the TPP) also includes the User’s DebtorAccount details - so there does not need to be an account selection at the LFI authorisation screen. So, LFI’s must display the Fast track journey, unless certain supplementary information is required to be displayed to Users. Please refer to Common Rules and Guidelines | 22. Supplementary Information for more information on Supplementary information.

3. This is the same sequence diagram in terms of interactions

4. This has been updated in the latest documentation FTSIP-7.
   Please note the following. The change introduced relates to the Future Dated Payment and not the Single Instant payment. Future Date payment changed from being scheduled by the TPP to being warhehoused and scheduled at the LFI. Thus, the description for the FDPs has been changed to match the sequence diagrams.
   For Single Instant payments, the changes relate to the BR & Guidelines vs the sequence diagrams. The BRs stated that the SIP will be initiated immediately by the LFI once the User has authorized the Consent. The BRs have now been updated to reflect that after consent authorization the user is redirected back to the TPP and the TPP makes another endpoint call to initiate the payment with the LFI. Thus, the BRs and sequence diargrams are not aligned to reflect this.

6

• Wireframes: is there an expected meaningful difference between Add New Bank Details and Select Bank or Building Society?

• Suggest the consent at the end to opt-in for saving payment details be part of the non-fast track SIP

• Suggest the consent at the end to opt-in for saving payment details be related to “remember my account for future payments / transactions” - refunds should not be contingent on this consent - merchants and TPPs as a default should have the capability to reverse a transaction back to its original destination.

• Yes, there is. the add new bank details, the user has to provide the IBAN details of their payment account that it to be used for the payment. In addition, he still has to select their bank name or segement. When selecting from a list, this example assumes that the user has either provided the details in the past or the TPP may have value added services such as Data Sharing, which allowed the user to see a list of accounts to select. In this case the user only selects the account from the list and also does not have to select their bank name or segement, reducing the friction by 1 step.

• This feature has been removed as this was something optional for TPPs. TPPs may still be able to request this, but it is in the competitive space.

• Unfortunately, merchants and TPPs do not alwasy have the ability to reverse the transaction for a refund as explained inPayment Refunds. However, we have now updated the Standard so that it is clear that consent is given by the user to the TPP and authorized in the LFI as part of the payment consent that the TPP is authorized to request the user’s payment account for refund purposes.

Bank Service Initiation

Payments

1

Adding options for domestic account numbers should also be allowed for consumer convenience.

Noted, we will be considering this addition in future versions of the Standard.

2

We prefer the payer or payee identification should be limited to only IBAN. If seemed necessary from customer experience perspective, we will be open to the option of consumers by first selecting their LFI from a list of predefined LFIs and then providing their domestic account number. In that case, our question would be how this ability will be aligned with IBAN regulation issued in 2012. We would like to seek more information on the above from CBUAE on alignment with regulation.

Noted. We will be checking with the CBUAE for aligment with the regulation that you mentioned.

For the payer identification, the selection of the payer holding LFI is already taking place at the TPP irrespective if the user provides an IBAN or a domestic account format. Thus, we see no reason why to request the user to provide a 23 characters IBAN compared to a domestic 12 or 14 characters account number.

For the payee identification, provided that the domestic account number number is sufficient for routing the payment to the correct beneficiary LFI, we also believer that the additional option will be less error prone for users to input.

We will be considering your feedback in any analysis that may be undertaken in the future in relation to this matter.

3

With Alias Payment option supported by Aani infra we should think of enabling the same for any kind of payment. So along with IBANS alias to be supported which are there in Aani?

Noted. We were considering these at the early stages of the drafts but this was generating a dependency that users had to be registered with Aani. So, at the moment, this options for alias has been removed but will be considered again in the future.

4

We are Life Insurance Company this is not applicable to us

Yes, that is correct, this is not relevant to you subject to not initiating any payments to Users.

5

If we considered using UAEFTS IBAN validation service for domestic payee confirmation, IBAN will be good option as UAEFTS service accepts only IBAN.

Noted. We are not using the UAEFTS IBAN service for validation, instead Open Finance has implemented a different CoP service. Thus, there is no dependency on using IBAN for the purpose of validation, the Open Finance CoP service could easily be extended to work this domestic account numbers, as per the early versions of the Standard.

6

The Open Finance platform should avoid multiple definitions of requirements wherever possible to enable easy integrations. Secondly, all banks in the region have migrated and adopted IBANs as the accepted value for bank transfers as far as we have observed. Given that IBANs are a deterministic value from the account number - we would suggest that implementing an account number + LFI selection be left to the integrating parties rather than a core functionality of the platform and how it works.

Noted for first point.

Note for second point. However, we are not entirely clear how you are suggesting this could be implemented by the integrating parties, if not supported by the Standard. Even if we assume that this will be done by the TPPs and IBAN will be generated based on account number and LFI selection by users, this still needs to be part of the Open Finance Standards, as the Standard controls the Customer experience screens that TPPs must present to the Users.

Bank Service Initiation

Risk Block

1

None

Noted.

2

This is under review and would revert shortly

Noted.

3

FEEDBACK

N/A

4

We are Life Insurance Company this is not applicable to us

Yes, that is correct, this is not relevant to you subject to not initiating any payments to Users.

5

Add below TPP Device details in Risk Block this will help in case of Decoupled authentication and authorization journey.

deviceId

isRootedDevice

screenBrightness

elapsedTimeSinceBoot

osVersion

userTimeZoneOffset

language

screenDimensions

  -height

  -width

accountTenure

geolocation

 -latitude

 -longitude

isCallInProgress

isDevModeEnabled

isMockGPS

isEmulated

isMonkeyRunner

isCharging

antennaInformation

isUsbConnected

appRecognitionVerdict

deviceRecognitionVerdict

browserUserAgent details

wifiDetails.

isConnected

macAddress

ipAddress

netmaskAddress

gatewayAddress

broadcastAddress

userEnabled

We will review this requirement for a future version of the Standard.

6

No Feedback from our end.

Noted.

Operational Guidelines

Availability, Performance and Usage Benchmarks

1

It would be helpful to provide guidelines on how TPPs can manage rate limiting with LFIs, e.g. when a TPS (transactions per second) policy on API gateways are restricting use cases or delivering a service to an end user. We would prefer to see guidelines on expected rate limiting/throttling policies that TPPs can expect to see from LFIs or via the hub itself. This becomes increasingly important for specific use cases such as those needing high volume, small window refresh rates of transactions from accounts for example.

There is currently no standard for TPS. This will be continuously monitored.

2

Based on our experience with many other regions running Open banking, this “An average TTLB of 500ms per response across all bank data APIs, or per page of up to 100 records for large datasets” is a very stretched target, extremely difficult to be achieved.

Standards v1.0-draft5 doesn’t define any capacity requirements. What kind of throughput is expected from the bank?  

Noted, the ability to meet this benchmark will be continuously monitored.

Capacity is outside the scope of the Standard, however guidance can be provided if required.

3

·       How the liability model will work in case there is an issue in OFH which has resulted in a financial loss for a user?

·       Is there a specific TPS standard that is required to be maintained by an LFI for OFH connectivity?

The liability model is documented in the Open Finance UAE confluence space. It is not included in the Standard.

There is no specific TPS standard.

4

Concept-wise the parameters and Benchmarks seem efficient. Unless implementation stage is reached in Life Insurance Industry, no specific suggestions can be made now.

Noted.

5

No

Noted.

6

No Feedback from our end.

Noted.

Operational Guidelines

Fraud Prevention Measures

1

Under section 3.2 (KYB/KYC) and 3.3(AML), the links to CBUAE rule are related to AML standards applicable to exchange houses. Kindly confirm if the linked documents are correct.

Section 5. Liability model should include all scenarios presented by CBUAE during workshop as guidelines. Currently only link to the presentation is available.

AML and Fraud guidelines and the Liability Model are documented in the Open Finance UAE confluence space.

2

Guidance required on how to incorporate fraud prevention measures into our existing the fraud monitoring systems

AML and Fraud guidelines and the Liability Model are documented in the Open Finance UAE confluence space.

3

• How will the case management work for any fraud?

• Incident reporting flow?

• Will LFI get an access to a dashboard having que of all raised cases? Need clarity in the complete workflow of fraud reporting & liability assignment?

AML and Fraud guidelines and the Liability Model are documented in the Open Finance UAE confluence space.

Problem resolution processes are being developed and will be subject to future communication.

4

No. Nothing in specific.

Noted.

5

No

Noted.

6

We note that the CBUAE is still yet to publish information regarding the licensing framework and is now targeting an end of July publication date. We would strongly encourage the CBUAE to share details regarding the application and specific supporting documentation in order for the ecosystem to prepare within the allotted grace period.

Following the session, it was not always clear who is responsible for fraud monitoring and resolutions. In one place, it says OFCo/CBUAE will provide real-time monitoring and controls but later on it was said that LFIs would need to employ their own fraud detection systems. Whereas in the workflow shared, it shows fraud investigations as being jointly raised to and investigated by LFIs/TPPs. It would be helpful to get clarity on the expected roles of each of CBUAE/OFCo, LFIs and TPPs when it comes to putting in place fraud prevention measures, who needs to investigate it, etc.

Confirmation that the liability tables shared will form part of the Open Finance Rules, and what is the dispute resolution mechanism to address any disputes between the parties. Further clarity on where a B2B TPP acting as a form of aggregator would fit within the liability model - does the liability rest with the B2C TPP who owns the end-user relationship?

AML and Fraud guidelines, the Liability Model and the Certification Model are documented in the Open Finance UAE confluence space.

Consent Setup

2

If the consent provided is fake (ie account takeover, social engineering) who will be liable?

The liability is be subject to the investigation on whether the account takeover was due to the negligence by the user or some only inadequacy in the security framework of the LFI.

The details will be covered under the dispute resolution process which is a work in progress and we will be communicating once this is published.

Common Components

Authentication and Authorisation

2

1. Redirection - The User consumes the User-facing TPP service and authenticates for the OF request with the AE on a separate application on the same device. The authentication data is exchanged only between User and the AE through the AE and the User-facing TPP has no visibility of this. Redirection uses the principle of deeplinking when the User’s action within the User-facing TPP app/website invokes the AE app/website.

2. Decoupled - The User consumes the User-facing TPP service and authenticates with the AE on separate applications on separate devices. The authentication data is exchanged only between User and AE through the AE application and the User-facing TPP has no visibility of this. A Decoupled experience on the two devices can be achieved by using Redirection where the User uses a deeplink within the User-facing TPP app/website on one device to invoke their AE app/website on another device – if fraud happens on this case, who’ll be responsible

The dispute handling for fraud in the decoupled scenario will be no different to that in a standard redirection scenario. The dispute resolution process will determine the liable party in the similar way.

Common Components

Authentication and Authorisation - Centralized Authentication and Authorization (Federated)

2

Is CAAP mandated or can we use the existing authentication? What kind of authentication we’re going to use to be confirmed by the IT and tech teams?

CAAP is optional and LFIs can use their existing authentication

The CAAP will be using device biometrics/device PIN which is bound to the verified identity of the user. The identity will be verified either using UAE PAss or embedded FRA

Consent Setup

Consent Types - Long-Lived Consent

2

How long that consent identifier will be in place? Will it get refreshed or a new one will be given? Will the customer be every time authenticated for long lived consent?

A long-lived consent is currently allowed a maximum validity period of 12 months, as defined in Limits and Constants | Max Consent Validity Period.

During this 12 months period, the actual access token for the long-lived consent will be refreshed several times using the refresh token, as, for security purposes, the tokens will not have a very long life span. This is happening on the background and there is no User action required for this process. However, once the 12 months period is reached, the refresh token can no longer be used to generate further access tokens. At this point, a new consent will be generated by the TPP. However, it is at the TPPs disposal whether this consent will be made to appear to the User as a “refreshed/renewed” consent using several of the consent parameters in the previous (expired) consent or it will appear as a totally new consent. In the former case, the new consent will have a new id but will have the same base consent id as the previous consent. In the latter case, the new consent will have a new consent id and a new base consent id. In both cases, the user will be required to provide consent to the TPP and be redicted to the LIF to authenticate and authorize the new consent.