Release Notes

Release Notes

What’s changed?

v2.0-draft2

Technical specification updates

  • Added the ATM Data OpenAPI specification

v2.0-draft1

 

v1.2

These are the changes that have been introduced in v1.2 from v1.1

Business rules updates

  • New Product Data and Product Data OpenAPI pages included within the Bank Data Sharing section to reflect the business rules associated with TPPs retrieving product information from LFIs and sending information about leads to LFIs.

  • Updated CX screen in section 3.1.3.3 and added new customer journey 3.2.3.1 in page Single Instant Payments

  • Replace term ‘IPP’ with ‘Aani Core’.

  • Added a clarification between a consent being paused and a consent being suspended in https://openfinanceuae.atlassian.net/wiki/x/5gGRE

  • Updated CX screens in https://openfinanceuae.atlassian.net/wiki/x/5gGRE

    • added search functionality to align with business rules

    • added consent ID display to align with business rules

    • changes terminology from ‘reconfirm’ to ‘update’

  • Updated CX screens in https://openfinanceuae.atlassian.net/wiki/x/-AKRE

    • added search functionality to align with business rules

    • added consent ID display to align with business rules

    • changes terminology from ‘reconfirm’ to ‘update’

  • Removed the manual entry of debtor account details from Common Rules and Guidelines and from all Banking journeys.

  • Added clarification in relation to Consent States in Consent Setup

  • Added redirection variation to allow the use of a logo Authentication by LFI

  • Minor corrections in the example shown in Payments with Delegated Authentication

  • Minor corrections in Consent Setup

  • Minor corrections in Multi-Payments and Multi-Payments to reflect that the PeriodStartDate field in the PAR request was made mandatory from v1.1.

  • Minor corrections in Payment Refunds (REFREQ-3 Rule 3.3) and Payment Refunds (REF-1 Rule 1.5) to reflect that the Refund Information Flag has been replaced with a ReadRefundAccount permission in the PAR request in v1.1.

  • Minor correction in Bank Service Initiation API Guide to remove a duplicate “in”

  • Minor correction in Bank Service Initiation API Guide to update the EventDateTime and EventResource field values.

  • Minor correction in Insurance API Guide to remove the “UAEOF” reference in the EventType field.

  • Minor corrections in the following sections to reflect that the “Is Pay By Account” flag was removed from the PAR API spec as part of the v1.1. changes:

    • Single Instant Payments Section 3.1.2 - SIP-1: Rule 1.4 “Set/clear the “Is Pay By Account” flag as appropriate in the case the initiated payment is a payment at POS or e-commerce payment” has been removed. The subsequent rules within Section SIP-1 have been renumbered.

    • Future Dated Payments Section 3.2 FDP-1: Rule 1.4 “Set/clear the “Is Pay By Account” flag as appropriate in the case the initiated payment is a payment at POS or e-commerce payment” has been removed. The subsequent rules within Section FDP-1 have been renumbered.

    • Multi-Payments Section 3.2 MPCS-1: Rule 1.4 “Set/clear the “Is Pay By Account” flag as appropriate in the case the initiated payment Consent relates to payments at POS or e-commerce payments” has been removed. The subsequent rules within Section MPCS-1 have been renumbered.

    • Multi-Payments Section 6.2 MPCOMB-1: Rule 1.2 “Set/clear the “Is Pay By Account” flag as appropriate in the case the initiated payment Consent relates to payments at POS or e-commerce payments” has been removed. The subsequent rules within Section MPCOMB-1 have been renumbered.

    • International Payments Section 3.1.1 IP-2: Rule 2.4 “Set/clear the “Is Pay By Account” flag as appropriate in the case the initiated payment is a payments at POS or e-commerce payment” has been removed. The subsequent rules within Section IP-2 have been renumbered.

    • International Payments Section 3.2.3 FRIP-2: Rule 2.4 “Set/clear the “Is Pay By Account” flag as appropriate in the case the initiated payment Consent relates to payments at POS or e-commerce payments” has been removed. The subsequent rules within Section FRIP-2 have been renumbered.

Technical specification updates

  • New Open Finance Product API specification for

    • Leads - for TPPs to send information about leads to LFIs

    • Products - for TPPs to retrieve product information from LFIs

  • Updated Standing Orders fields from mandatory to optional - FinalPaymentDateTime, NumberOfPayments, FinalPaymentAmount - as these are not available in all cases

  • Updated references in the OpenAPI specification from “IPP” to “Aani Core”

  • Clarified in OpenAPI specification that the AEExchangeRateInformation object is returned by the LFI

v1.1

These are the changes that have been introduced in v1.1 from v1.0

Business rules updates

Errata version

Section

Subsection

Impacts

Description

Action

Errata version

Section

Subsection

Impacts

Description

Action

1

2

Bank Service Initiation

Single Instant Payments

LFIs

TPPs

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.

2

2

Common Components

User Experience Principles

LFIs

TPPs

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 colors, branding, spacing and component design.”

3

2

Bank Service Initiation

Common Rules and Guidelines

TPPs

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

4

2

Bank Service Initiation

Single Instant Payments

TPPs

The rules SIP-7 in Single Instant Payments 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.”

5

2

Limits and Constants

Limits and Constants

TPPs

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

6

2

Bank Service Initiation

Bulk and Batch Payments

TPPs

The rules BBP-6 in Bulk and Batch Payments 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.”

7

2

Limits and Constants

Limits and Constants

TPPs

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.

8

2

Bank Service Initiation

Future Dated Payments

TPPs

The rules FDP-5 in Future Dated Paymentsdo 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.”

9

2

Limits and Constants

Limits and Constants

TPPs

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.

10

2

Bank Service Initiation

Multi-Payments

 

OFP

Rule 2.9 of MPPI-2 in Multi-Payments 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 Multi-Payments 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 initiated that could exceed the Maximum values of the respective Consent Control parameters. The initial value of the cumulative Total Number and the cumulative Total Value of payments should be zero for each authorized VRP Consent.”

11

2

Bank Service Initiation

Multi-Payments

OFP

Rule 2.10 of MPPI-2 in Multi-Payments 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 Multi-Payments 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 initiated that could exceed the Maximum values of the respective Consent Control parameters. 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.”

12

2

Bank Service Initiation

Multi-Payments

OFP

TPPs

Rule 2.14 of MPPI-2 in Multi-Payments 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 cumulative 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.”

13

2

Bank Service Initiation

Multi-Payments

OFP

TPPs

Rule 2.22 of MPPI-2 in Multi-Payments 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 cumulative 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.”

14

2

Common Rules and Guidelines

Common Rules and Guidelines

OFP

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

15

2

Common Rules and Guidelines

Common Rules and Guidelines

LFIs

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 Common Rules and Guidelines 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 Common Rules and Guidelines.

16

2

Bank Service Initiation

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

OFP

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

17

3

Authentication and Authorization

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151847970/Authentication+by+LFI#2.-Redirection

LFIs

The business rules for App-to-Browser and Browser-to-Browser journeys do not currently permit an LFI to provide a redirect to their mobile banking app to continue the authentication journey. This will cause friction for customers who are enrolled only in an LFIs mobile banking app and do not have internet banking credentials.

Sections 2.3 (Browser-to-Browser) and Section 2.4 (App-to-Browser) are modified as follows:

The following alternative experience MUST be implemented by LFIs to allow customers to use their mobile banking app to complete Authentication and Authorization:

  1. The LFI MUST support a web-based landing page that opens on redirection with a Call to Action (CTA) to trigger an interaction using the User’s mobile banking app.

  2. The CTA provided on the page must be:

    • For non-mobile devices, a QR Code that can be scanned by the User. Direction must be displayed that indicates to the User that they must scan the QR Code with a device that has the LFI app installed.

    • For mobile devices without the LFI app installed, a CTA that enables the User to download the app from the relevant app store.

  3. The QR Code displayed MUST be scannable directly by any mobile device camera and resolve into a deep link which will invoke the LFI mobile app on that device. The deep link will result in the User being prompted to complete Multi-Factor Authentication and be presented with a screen that allows them to complete consent authorization.

  4. Where the CTA results in the User installing the LFI mobile app, the LFI must inform the User that they may have to reinitiate the request from the TPP, as the delay introduced in installing and setting up the LFI app is likely to expire the authorization window set by the TPP.

  5. The LFI MUST provide the means for the User to abandon handoff to a mobile device and instead choose to complete Authentication and Authorization using the LFI web channel, where supported.

18

3

Bank Service Initiation

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

LFIs

Rule 5.6 of SIP-5 in Single Instant Payments includes reference to Fees to be displayed by LFIs, if applicable. This reference is no longer relevant.

Updated rule 5.6 of SIP-5 to remove the reference to LFI fees.

“LFIs MUST:

5.6 Present to Users the following minimum required information for authorizing the Single Instant Payment (SIP) Consent:

  • User Payment Account

  • Payment Amount & Currency

  • Creditor Identification details including:

    • Creditor Name

    • Creditor Account

    • Creditor Account Holding LFI

  • Debtor Note (Optional)

  • Creditor Reference

  • Purpose of Payment”

19

3

Bank Service Initiation

Single Instant Payments

TPPs

The rule 7.5 SIP-7 in Single Instant Payments | 3.1.2 Rules & Guidelines includes the User (Debtor) Payment Account (i.e. account identifier) and the Creditor Identification details as parameters included in the SIP Payment Initiation Request sent from the TPP. The Debtor and Creditor Identification details have now been removed from the SIP Payment Initiation Request and LFIs will get this information from the authorized Payment Consent.

SIP-7 rule 7.5 is modified as follows:

“OFP MUST:

7.5 Send the SIP payment initiation request to the LFI for initiating an instant payment using the payment parameters included in the payment initiation request including:

  • Authorized Payment Consent Identifier

  • Payment Amount & Currency

  • Debtor Reference (if provided)

  • Creditor Reference

  • Purpose of Payment”

20

3

Bank Service Initiation

Single Instant Payments

LFIs

The rules of SIP-7 in Single Instant Payments | 3.1.2 Rules & Guidelines do not include the requirement for LFIs to retrieve the Creditor Identification details from the encrypted PII information block included in the authorized Payment Consent.

SIP-7 rule 7.6 is modified to add new rules as follows:

“LFIs MUST:

7.6 Trigger the payment initiation process for the payment Consent immediately after receiving the payment initiation request from the OFP.

  • 7.6.1 Retrieve the Creditor Identification details from the encrypted PII information block included in the original Payment Consent message.

  • 7.6.2 Apply all existing BAU check and validation processes in relation to the Creditor Identification details. In case of failure. LFIs MUST reject the payment initiation request and notify the OFP about this rejection with an appropriate error message.”

21

3

Bank Service Initiation

Future Dated Payments

LFIs

Rule 5.7 of FDP-5 in Future Dated Payments includes reference to Fees to be displayed by LFIs, if applicable. This reference is no longer relevant.

Updated rule 5.7 of FDP-5 to remove the reference to LFI fees.

“LFIs MUST: