Standards v1.0-final-errata2

Bank Service Initiation

Single Instant Payments

The Open Finance Standards do not offer a prototype of a Single Instant Payment flow.

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 Open Finance Standards do 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 shall:

   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 shall:

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

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.

Please see updated OpenAPI description document.

Common Components

Pushed Authorization Request Endpoint OpenAPI

Several arguments of the JWT-Secured Authorization Request (JAR) implemented in Pushed Authorizaton Request Endpoint OpenAPI did not offer detailed descriptions for their usage.

The PAR Endpoint have been updated to offer more extensive document.

TPPs should review the description values provided in the PAR Endpoint OpenAPI description.

Please see updated OpenAPI description document.

Common Components

User Experience Principles | 11. Other Rules for User Journeys

All Customer Experience sections currently provide branded screens without stipulation of whether these are illustrative or prescriptive.

A new rule is added as follows:

“LFIs and TPPs MUST implement their customer experience screens in line with what is provided in each Customer Experience section of the Standard for the relevant functionality. This includes colours, branding, spacing and component design.”

Bank Service Initiation

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

Single Instant Payments | Payment Initiation

The rules SIP-7 in Single Instant Payments | 3.1.2 Rules & Guidelines do not define the maximum time between the payment Consent being authorized 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 Limits and Constants | A. Limits.”

Limits and Constants

Limits and Constants | A. Limits

The Limits table does not include 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

Bulk and Batch Payments | Payment Initiation

The rules BBP-6 in Bulk and Batch Payments | 3.1 Rules & Guidelines do not define the maximum time between the Bulk/Batch payment Consent being authorized and the Bulk/Batch Payment request being initiated by the TPP.

BBP-6 rule 6.1 is modified to add a new rule as follows:

“TPPs MUST:

6.1 Submit to OFP the Bulk/Batch payment initiation requests with the same parameters as per the Bulk or Batch Payment (BBP) Consent authorized by the User(s).

• 6.1.1 Submit to OFP the Bulk/Batch payment initiation request immediately after they receive the Bulk/Batch Payment Consent authorization confirmation. The Bulk/Batch payment initiation request MUST be received by the OFP within the Max Bulk/Batch Payment Initiation Time Interval as defined in Limits and Constants | A. Limits.”

Limits and Constants

Limits and Constants | A. Limits

The Limits table does not include an entry for the Max Bulk/Batch Payment Initiation Time Interval.

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

ID: A16

Name: Max Bulk/Batch Payment Initiation Time Interval

Description: This is the period of time that TPPs MUST submit the Bulk/Batch Payment Initiation Request to the OFP. The value defined for this is period is currently 15 sec. The OFP will reject the Payment Initiation Request is submitted outside this time window.

Bank Service Initiation

Future Dated Payments | Authorization

The rules FDP-5 in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848769/Future+Dated+Payments#3.2-Rules-%26-Guidelinesdo not define the requirement for TPPs to submit the FDP Payment Initiation request to the OFP and the LFI so that the FDP payment initiation can take place and the FDP can be warehoused in the LFI’s systems. Also, there is no rule to define the maximum time between the FDP payment Consent being authorized and the FDP Payment request being initiated by the TPP.

FDP-5 is modified to add a new rule as follows:

“TPPs MUST:

5.15 Submit to OFP the FDP payment initiation requests with the same parameters as per the FDP Payment Consent authorized by the User(s).

• 5.15.1 Submit to OFP the FDP payment initiation request immediately after they receive the FDP Payment Consent authorization confirmation. The FDP payment initiation request MUST be received by the OFP within the Max FDP Payment Initiation Time Interval as defined in Limits and Constants | A. Limits.”

Limits and Constants

Limits and Constants | A. Limits

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

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

ID: A17

Name: Max FDP Payment Initiation Time Interval

Description: This is the period of time that TPPs MUST submit the FDP Payment Initiation Request to the OFP. The value defined for this is period is currently 15 sec. The OFP will reject the Payment Initiation Request is submitted outside this time window.

Bank Service Initiation

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848909/Multi-Payments#Processing-of-Payment-Initiation-Requests

Rule 2.9 of MPPI-2 in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848909/Multi-Payments#5.-Payment-Initiation states the following:

“2.9 Increment the cumulative Total Number and the cumulative Total Value of payments under the VRP Consent after the payment successfully executed and received payment status confirmation from the creditor LFI. The initial value of these parameters should be zero for each authorized VRP Consent.”

The OFP at this stage is not able to know whether the payment has been successfully executed and the LFI has received payment status confirmation from the creditor LFI. This is because this check is happening before the OFP has forwarded the Payment Initiation request to the LFI and thus the payment has not been initiated yet.

Rule 2.9 of MPPI-2 in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848909/Multi-Payments#5.-Payment-Initiation is modified as follows:

“2.9 Increment the cumulative Total Number and the cumulative Total Value of payments under the VRP Consent after the payment resource has been created and it is in ‘Pending’ status and has not been rejected. This will prevent multiple payments being initated that could exceed the Maximum values of the respective Consent Control papameters. The initial value of the cumulative Total Number and the cumulative Total Value of payments should be zero for each authorized VRP Consent.”

Bank Service Initiation

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848909/Multi-Payments#Processing-of-Payment-Initiation-Requests

Rule 2.10 of MPPI-2 in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848909/Multi-Payments#5.-Payment-Initiation states the following:

“2.10 Increment the cumulative Total Number and the cumulative Total Value of all payment initiations per Control Period after the payment successfully executed and received payment status confirmation from the creditor Bank. These parameters are reset to zero when a new Consent Control Period starts at 00:00:00 of the first day of the Control Period.”

The OFP at this stage is not able to know whether the payment has been successfully executed and the LFI has received payment status confirmation from the creditor LFI. This is because this check is happening before the OFP has forwarded the Payment Initiation request to the LFI and thus the payment has not been initiated yet.

Rule 2.10 of MPPI-2 in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848909/Multi-Payments#5.-Payment-Initiation is modified as follows:

“2.10 Increment the cumulative Total Number and the cumulative Total Value of all payment initiations per Control Period after the payment resource has been created and it is in ‘Pending’ status and has not been rejected. This will prevent multiple payments being initated that could exceed the Maximum values of the respective Consent Control papameters. The cumulative Total Number and the cumulative Total Value of all payment initiations per Control Period are reset to zero when a new Consent Control Period starts at 00:00:00 of the first day of the Control Period.”

Bank Service Initiation

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848909/Multi-Payments#Processing-of-Payment-Initiation-Requests

Rule 2.14 of MPPI-2 in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848909/Multi-Payments#5.-Payment-Initiation states the following:

“2.14 Reject the payment initiation and provide the necessary error message to the TPP if any other checks of the payment initiation request parameters fails against Consent parameters of the authorized long-lived Payment Consent.”

The OFP at this stage is able to decrement the relevant VRP cummulative counters, but this rule is missing from this step.

MPPI-2 rule 2.14 is modified to add a new rule as follows:

“2.14 Reject the payment initiation and provide the necessary error message to the TPP if any other checks of the payment initiation request parameters fails against Consent parameters of the authorized long-lived Payment Consent.”

• 2.14.1 In this case:

  • For all payments related to a VRP Consent, the OFP MUST decrement:

    • the cumulative Total Number of payments by 1 and,

    • the cumulative Total Value of payments by the value of the payment

  • For all payments related to a VRP Consent where a Control Period is set, the OFP MUST decrement:

    • the cumulative Total Number of payments per Control Period and,

    • the cumulative Total Value of payments per Control Period.”

Bank Service Initiation

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848909/Multi-Payments#Processing-of-Payment-Initiation-Requests

Rule 2.22 of MPPI-2 in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848909/Multi-Payments#5.-Payment-Initiation states the following:

“2.22 Send an appropriate error response to the TPPs in case the payment is rejected due to violating any of the LFIs BAU payment accounts checks or limits.”

The OFP at this stage is able to decrement the relevant VRP cummulative counters, but this rule is missing from this step.

MPPI-2 rule 2.22 is modified to add a new rule as follows:

“2.22 Send an appropriate error response to the TPPs in case the payment is rejected due to violating any of the LFIs BAU payment accounts checks or limits.”

• 2.22.1 In this case:

  • For all payments related to a VRP Consent, the OFP MUST decrement:

    • the cumulative Total Number of payments by 1 and,

    • the cumulative Total Value of payments by the value of the payment

  • For all payments related to a VRP Consent where a Control Period is set, the OFP MUST decrement:

    • the cumulative Total Number of payments per Control Period and,

    • the cumulative Total Value of payments per Control Period.”

Common Rules and Guidelines

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850813/Common+Rules+and+Guidelines#15.-Payment-Status-Update

A new rule is required so that when OFP receives updates on the Payment status of a payment, updates the relevant VRP Consent Control Parameters as appropriate.

A new rule is added as follows:

“OFP MUST:

CRG-15.4.1 Check if the status of the payment has been set to ‘Rejected. In this case:

• For all payments related to a VRP Consent, the OFP MUST decrement:

  • the cumulative Total Number of payments by 1 and,

  • the cumulative Total Value of payments by the value of the payment

• For all payments related to a VRP Consent where a Control Period is set, the OFP MUST decrement:

  • the cumulative Total Number of payments per Control Period and,

  • the cumulative Total Value of payments per Control Period.”

Common Rules and Guidelines

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850813/Common+Rules+and+Guidelines#15.-Payment-Status-Update

Within rules CRG-15.5 and CRG-15.8 the payment status model is referenced incorrectly as GRC 15.12 Payment Status Model.

CRG-15.5 and CRG-15.8 are modified as follows:

“CRG-15.5 Respond to payment status query requests from a TPP with the appropriate status codes as listed below in section https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850813/Common+Rules+and+Guidelines#GRC-15.10-Payment-Status-Model based on the status information provided by the LFI.”

“CRG-15.8 Be able to notify the OFP asynchronously about any changes in the status of the payment request. More specifically, LFIs MUST provide asynchronous notification to the OFP by sending the appropriate status codes as listed below in section https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850813/Common+Rules+and+Guidelines#GRC-15.10-Payment-Status-Model”.

Bank Service Initiation

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848909/Multi-Payments#Authorization

Within rules 5.12 the Check Authorization Time Window is referenced incorrectly.

Rule 5.12 in MPCS-5 is modified as follows:

“5.12 Check the Authorization Time Window is valid as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850813/Common+Rules+and+Guidelines#19.-Check-Authorization-Time-Window.”

Bank Data Sharing

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850759

The Purpose property in the Consent response was incorrectly labelled as optional

Purpose is now mandatory in the Consent response, with the minItems property set to 1 to indicate the array must not be empty.

Please see updated OpenAPI description document.

Bank Service Initiation

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850435

PaymentTransactionId was incorrectly labelled as mandatory, but could not be populated until a valid payment reference had been created at the payment rails on which the payment instruction was transmitted.

PaymentTransactionId is now optional, with additional description that states: “The PaymentTransactionId must be populated if the payment is processed by the LFI.”

Please see updated OpenAPI description document.

Common Components

Pushed Authorization Request Endpoint OpenAPI

The Purpose property of the AEAccountAccessAuthorizationDetailConsentProperties Schema Object was incorrectly defined as optional.

Purpose is now mandatory, with the minItems property set to 1 to indicate the array must not be empty.

Please see updated OpenAPI description document.

Common Components

Pushed Authorization Request Endpoint OpenAPI

The Subscription property of all consent request Schema Object was labelled as mandatory. This was incorrectly defined as TPPs do not have to implement Event Notifications over Webhooks.

Subscription updated to be optional.

Please see updated OpenAPI description document.

Common Components

Pushed Authorization Request Endpoint OpenAPI

AEAccountSubTypeCode does not match the enumeration values found in the Data Sharing OpenAPI description.

AEAccountSubTypeCode updated to only CurrentAccount and Savings.

Please see updated OpenAPI description document.

Common Components

Pushed Authorization Request Endpoint OpenAPI

AEServiceInitiationDefinedSchedule does not match the Bank Service Initiation OpenAPI description as maxItems should be set to 50.

The Schedule array of the AEServiceInitiationDefinedSchedule has been amended with the maxItems property set to 50.

Please see updated OpenAPI description document.

Common Components

Pushed Authorization Request Endpoint OpenAPI

RequestedExecutionDateTime does not match the Bank Service Initiation OpenAPI description as the property has been renamed RequestedExecutionDate with the format property set to date.

The Schema Object AERequestedExecutionDateTime has been renamed AERequestedExecutionDate and the format value set to date.

Please see updated OpenAPI description document.

Common Components

Pushed Authorization Request Endpoint OpenAPI

AEServiceInitiationLongLivedPaymentConsent does not match the Bank Service Initiation OpenAPI description as Amount, MaximumIndividualPaymentAmount, and PeriodicSchedule are set to mandatory.

The Schema Object AEServiceInitiationLongLivedPaymentConsent has been updated to remove mandatory fields.

Please see updated OpenAPI description document.

Common Components

Pushed Authorization Request Endpoint OpenAPI

AEServiceInitiationLongLivedPaymentConsentPeriodicSchedule does not match the Bank Service Initiation OpenAPI description as it implements named properties rather than a oneOf.

AEServiceInitiationLongLivedPaymentConsentPeriodicSchedule has been updated to implement a oneOf.

Please see updated OpenAPI description document.

Common Components

Pushed Authorization Request Endpoint OpenAPI

AEServiceInitiationVariablePeriodicSchedule does not match the Bank Service Initiation OpenAPI description as MaximumCumulativeValueOfPaymentsPerPeriodType and MaximumCumulativeNumberOfPaymentsPerPeriodType are labelled as mandatory.

AEServiceInitiationVariablePeriodicSchedule has been updated to make MaximumCumulativeValueOfPaymentsPerPeriodType and MaximumCumulativeNumberOfPaymentsPerPeriodType optional.

Please see updated OpenAPI description document.

Common Components

Pushed Authorization Request Endpoint OpenAPI

The Amount and CurrencySchema Objects are not consistent with the same Schema Object in the Bank Service Initiation OpenAPI description.

Amount Schema Object renamed to AEActiveOrHistoricAmount and properties updated to match Bank Service Initiation definition. CurrencyCode renamed to AEActiveOrHistoricCurrencyCode and updated to match Bank Service Initiation definition.

Please see updated OpenAPI description document.

Bank Data Sharing OpenAPI

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850759

Bank Service Initiation OpenAPI

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850435

Pushed Authorization Request Endpoint OpenAPI

Pushed Authorization Request Endpoint OpenAPI