Page Comparison

Common Components

Pushed Authorization Request Endpoint OpenAPI

The PeriodSchedule shows all 3 schedule types - DefinedSchedule, FixedPeriodicchedule and VariablePeriodicSchedule as being as mandatory instead of “oneof”

Implementers should follow the specification as per uae-bank-initiation-openapi.yaml.

The specification in uae-pushed-authorization-endpoint-openapi.yaml will be updated in the next version.

Bank Service Initiation

Single Instant Payments

A prototype illustrating an example of a Single Instant Payment flow has been created.

TPPs and LFIs should use this prototype in conjunction with the prescribed customer experience screens.

Common Components

Pushed Authorization Request Endpoint OpenAPI

The standards at version 1.0 do not provide a mechanism to transmit an identifier for the User to the LFI prior to Authentication taking place. Having the mechanism to do this, supported by the standards, has been highlighted by ecosystem participants as a very important enhancement.

The Pushed Authorization Request (PAR) OpenAPI description has been updated to include the login_hint parameter, which is an OpenID Connect parameter that allows a Relying Party to send an indicator (“hint”) of the End User.

The open finance framework implementation of this parameter allows a TPP to send the Emirates ID or Trade License Number, as appropriate, using an encrypted JSON Web Token (JSON Web Encryption - JWE). The mechanics of creating the login_hint parameter value are described in the PAR OpenAPI description.

The steps for creating and processing the JWE are as follows:

1. The TPP will:

   1. Create the payload based on the details found in the PAR OpenAPI description.

   2. Discover the JWKS endpoint for the LFI that holds the Customer account, to which the request will be directed.

   3. Retrieve the public encryption key for the LFI.

   4. Encrypt the payload as a JWE using the public encryption key for the LFI, and include indicators such as kid that will allow the LFI to correlate the corresponding private key.

   5. Set the login_hint parameter to the value of the JWE.

   6. Send the PAR to the LFI endpoint at the API Hub.

2. The OFP will:

   1. Pass the value of the login_hint parameter to the LFI at the Ozone Connect Validate and/or Augment operation, depending on their configuration.

3. The LFI will:

   1. Based on their implementation, select the private encryption key that matches the public key used by the TPP.

   2. Decrypt the value of the login_hint parameter and deserialise the payload value.

   3. Use the Emirates ID or Trade License Number as required in the processing of the Validate or Augment operation.

Please note that the use of login_hint is optional and is intended to provide for enhanced customer experiences based on foresight of the customer identity. It is not a replacement for Authentication and Authorisation.

TPPs and LFIs should follow the described mechanism to implement using the login_hint parameter to send either the Emirates ID or Trade License Number with the Pushed Authorization Request.

Bank Service Initiation

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850813/Common+Rules+and+Guidelines#2.-User-Payment-Account-Selection

Rule CRG-2.1 states the following:

• “Select their LFI only (so that they can select their Payment Account later on in the journey after authenticating with the LFI). The LFI MUST be identified using the trading name which is familiar to Users.”

Further clarification is required to be added about how TPPs will be presenting the LFIs to Users for easier identification.

Rule CRG-2.1 is modified as follows:

• “Select their LFI only (so that they can select their Payment Account later on in the journey after authenticating with the LFI). The LFI MUST be identified using the trading name which is familiar to Users.”

  • CRG-2.1.1 TPPs MUST use logos and the brand names of the LFIs as they are defined in the Trust Framework Directory.”

Bank Service Initiation

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848434/Single+Instant+Payments#Payment-Initiation

Rule SIP-7 in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848434/Single+Instant+Payments#3.1.2-Rules-%26-Guidelines does not define the maximum time between the payment Consent being authorised and the Single Instant Payment request being initiated by the TPP.

SIP-7 rule 7.1 is modified to add a new rule as follows:

“TPPs MUST:

7.1 Submit to OFP the payment initiation requests with the same parameters as per the Payment Consent authorized by the User.

• 7.1.1 Submit to OFP the SIP payment initiation request immediately after they receive the SIP Payment Consent authorization confirmation. The SIP payment initiation request MUST be received by the LFI OFP within the Max Payment Initiation Time Interval as defined in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850897/Limits+and+Constants#Actual-FX-Rate-SLA.Constants#A.-Limits.”

Limits and Constants

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850897/Limits+and+Constants#A.-Limits

The Limits table does not inclue an entry for the Max Payment Initiation Time Interval.

A new entry A15 is added to the table as follows:

ID: A15

Name: Max Payment Initiation Time Interval

Description: This is the period of time that TPPs MUST submit the Sinhgle Instant Payment Initiation Request to the OFP. The value defined for this is period is currently 5 sec. The OFP may reject the