Standards v1.0-final-errata2

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 errata2.

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 standard prior to errata2 does not provide a mechanism for the TPP to transmit a User identifier 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 shall:

   1. Implement support for providing the Emirates ID or Trade License Number based on customer and use cases requirements.

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

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

   4. Retrieve the public encryption key for the LFI.

   5. 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.

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

   7. 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 a 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 OFP within the Max SIP Payment Initiation Time Interval as defined in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850897/Limits+and+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 SIP Payment Initiation Time Interval.

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

ID: A15

Name: Max SIP 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 will reject the Payment Initiation Request is submitted outside this time window.

Bank Service Initiation

Limits and Constants

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