Release Notes
- Chris Michael
- Warren Handley
- Gavin Wong
What’s changed?
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 TPP Consent Management Interfaces
Updated CX screens in TPP Consent Management Interfaces
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 | 2. User Payment Account Selection and from all Banking journeys.
Added clarification in relation to Consent States in Consent Setup | 4. Consent States
Added redirection variation to allow the use of a logo Authentication by LFI | 4.1 Redirection Screen Variation
Minor corrections in the example shown in Payments with Delegated Authentication | 8. Wallet Use Case
Minor corrections in Consent Setup | 3. Consent Types
Minor corrections in Multi-Payments | Authorization and Multi-Payments | 8.3.2 VRP Consent Control Period & Start Date to reflect that the
PeriodStartDatefield in the PAR request was made mandatory from v1.1.Minor corrections in Payment Refunds | Processing of Refund Information Request (REFREQ-3 Rule 3.3) and Payment Refunds | Single Instant Payment Consent with Refund Permission (REF-1 Rule 1.5) to reflect that the Refund Information Flag has been replaced with a
ReadRefundAccountpermission in the PAR request in v1.1.Minor correction in Bank Service Initiation API Guide | 4.4 The TPP Queries the existence of a Service Initiation Resource Using the X ... to remove a duplicate “in”
Minor correction in Bank Service Initiation API Guide | 4.2.4.2 Request: OFP publishes signed/encrypted Service Initiation Data to the ... to update the
EventDateTimeandEventResourcefield values.Minor correction in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot2final/pages/277942715/Insurance+API+Guide#4.3.4.2-Request%3A-OFP-publishes-signed%2Fencrypted-data-to-the-registered-Webhook-Url-provided-by-the-TPP to remove the “UAEOF” reference in the
EventTypefield.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:
https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot2final/pages/277939953/Single+Instant+Payments#Single-Instant-Payment-Consent 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.
https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot2final/pages/277940302/Future+Dated+Payments#Single-Future-Dated-Payment-Consent 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.
https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot2final/pages/277940444/Multi-Payments#Multi-Payments-Consent 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.
https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot2final/pages/277940444/Multi-Payments#Combined-Payments-Consent 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.
https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot2final/pages/277940741/International+Payments#Single-IP-Consent 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.
https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot2final/pages/277940741/International+Payments#Fixed-Recurring-IP-Payment-Consent 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 casesUpdated references in the OpenAPI specification from “IPP” to “Aani Core”
Clarified in OpenAPI specification that the
AEExchangeRateInformationobject 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 | |
|---|---|---|---|---|---|---|
| 1 | 2 | Bank Service Initiation | 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 | 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 | TPPs | Rule CRG-2.1 states the following:
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:
| |
| 4 | 2 | Bank Service Initiation | TPPs | The rules SIP-7 in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848434/Single+Instant+Payments#3.1.2-Rules-%26-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.
| |
| 5 | 2 | 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: A15Name: Max SIP Payment Initiation Time IntervalDescription: 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 | TPPs | The rules BBP-6 in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151849558/Bulk+and+Batch+Payments#3.1-Rules-%26-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).
| |
| 7 | 2 | 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: A16Name: Max Bulk/Batch Payment Initiation Time IntervalDescription: 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 | TPPs | 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).
| |
| 9 | 2 | 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: A17Name: Max FDP Payment Initiation Time IntervalDescription: 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 |
| OFP | 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 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 | OFP | 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 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 | OFP TPPs | 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 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.”
| |
| 13 | 2 | Bank Service Initiation | OFP TPPs | 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 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.”
| |
| 14 | 2 | 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:
| |
| 15 | 2 | 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 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”. | |
| 16 | 2 | Bank Service Initiation | 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 | 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:
| |
| 18 | 3 | Bank Service Initiation | LFIs | Rule 5.6 of SIP-5 in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848434/Single+Instant+Payments#3.1.2-Rules-%26-Guidelines 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:
| |
| 19 | 3 | Bank Service Initiation | 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:
| |
| 20 | 3 | Bank Service Initiation | 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.
| |
| 21 | 3 | Bank Service Initiation | LFIs | Rule 5.7 of FDP-5 in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848769/Future+Dated+Payments#3.2-Rules-%26-Guidelines 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: 5.7 Present to Users the following minimum required information for authorizing the Single Future Dated Payment (FDP) Consent:
| |
| 22 | 3 | Bank Service Initiation | LFIs | The rules of FDP-6 in Future Dated Payments | 3.2 Rules & Guidelines MUST take place after the Hand-off back to TPP as described in the rules of FDP-7. | The order of steps FDP-6 and FDP 7 MUST be reversed. More specifically: FDP-7 → FDP-6 and FDP-6 → FDP-7 | |
| 23 | 3 | Bank Service Initiation | TPPs | The rules of FDP-7 in Future Dated Payments | 3.2 Rules & Guidelines do 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-7 is modified to add a new rule as follows: “TPPs MUST: 7.1 Submit to OFP the FDP payment initiation requests with the same parameters as per the FDP Payment Consent authorized by the User(s).
| |
| 24 | 3 | Bank Service Initiation | TPPs | The rules of FDP-7 in Future Dated Payments | 3.2 Rules & Guidelines do not define the requirement for OFP to check the FDP Payment Initiation request and then submit it to the LFI so that the FDP payment initiation can take place and the FDP can be warehoused in the LFI’s systems. | FDP-7 is modified to add a new rule as follows: “OFP MUST: 7.2 Allow the TPPs to submit the individual FDP payment initiation request under the FDP Payment Consent authorized by the User, without any additional MFA or authorization from the User. 7.3 Check that the received FDP payment initiation request relates to a valid FDP Payment Consent authorized by the User. The Consent MUST be in the Authorized state. The OFP MUST reject a, FDP payment initiation message related to a FDP Payment Consent in a different state and respond back to the TPP with the appropriate error message/code. 7.4 Check the FDP payment initiation request parameters against the authorized FDP Payment Consent. All parameters MUST match exactly.
7.5 Send the FDP payment initiation request to the LFI for warehousing the FDP payment using the payment parameters included in the FDP payment initiation request including:
| |
| 25 | 3 | Bank Service Initiation | LFIs | The rules of FDP-7 in Future Dated Payments | 3.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 FDP Payment Consent. | FDP-7 rule 7.6 is modified to add a new rule as follows: “LFIs MUST: 7.6 Trigger the FDP Payment warehousing process in their systems for it to be scheduled for initiation, processing and execution on the Requested Execution Date as per BAU future dated payments processing, immediately after receiving the FDP payment initiation request from the OFP.
| |
| 26 | 3 | Bank Service Initiation | LFIs | Rule 5.7 of MPCS-5 in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848909/Multi-Payments#3.2-Rules-%26-Guidelines includes reference to Fees to be displayed by LFIs, if applicable. This reference is no longer relevant. | Updated rule 5.7 of MPCS-5 to remove the reference to LFI fees. “LFIs MUST: 5.7 Present to Users the following minimum required information for authorizing the long-lived payments Consent:
| |
| 27 | 3 | Bank Service Initiation | LFIs | The rules of MPPI-2 in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848909/Multi-Payments#5.-Payment-Initiation incorrectly include the requirement for OFP to check the Debtor and Creditor Identification details of the Payment Initiation Request against the authorized consent.
| MPPI-2 rule 2.3 is modified as follows to remove the OFP requirement and move it to the LFI requirements: “OFP MUST: 2.3 Check the payment initiation request parameters against the authorized long-lived Payment Consent. More specifically, the OFP MUST check the following:
| |
| 28 | 3 | Bank Service Initiation | N/A | Rule 2.12 of MPPI-2 in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848909/Multi-Payments#5.-Payment-Initiation incorrectly includes the requirement for OFP to check that the payment initiation request contains valid creditor identification details and that there is a unique identifier related to the User’s authorization of the payment details. This is not possible as this information is encrypted and not available to the OFP. | Rule 2.12 of MPPI-2 is removed from the OFP requirements and is moved to the LFI requirements. Rules numbers are modified as follows: 2.13 → 2.12 2.14 → 2.13 2.15 → 2.14 2.16 → 2.15 | |
| 29 | 3 | Bank Service Initiation | TPPs | The rule 2.15 of MPPI-2 in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848909/Multi-Payments#5.-Payment-Initiation includes the User (Debtor) Payment Account (i.e. account identifier) and the Creditor Identification details as parameters included in the Payment Initiation Request sent from the TPP. The Debtor and Creditor Identification details have now been removed from the Payment Initiation Request and LFIs will get this information from the authorized Payment Consent, except in the case of Variable Beneficiaries. | MPPI-2 rule 2.15 is modified as follows: “OFP MUST: 2.15 Send a payment initiation request to the LFI for initiating an instant payment using the payment parameters included in the Payment Initiation Request including:
Variable Beneficiaries Only
| |
| 30 | 3 | Bank Service Initiation | LFIs | The rules of MPPI-2 in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848909/Multi-Payments#5.-Payment-Initiation do not include the following requirements for LFIs: a) requirement to retrieve the Creditor Identification details from the encrypted PII information block included in the authorized Multi-Payment Consent. b) requirement to check the Creditor Identification details of the Payment Initiation Request against the authorized Multi-Payment Consent, in the case of Variable-defined Beneficiaries. c) requirement to check that the payment initiation request contains valid creditor identification details and that there is a unique identifier related to the User’s authorization of the payment details, for the case of Variable Beneficiaries. | New rules are added to MPPI-2 as follows: “LFIs MUST: 2.16 Trigger the payment initiation process for the payment Consent immediately after receiving the payment initiation request from the OFP. Fixed Beneficiaries Only
Variable Beneficiaries Only
Variable-defined Beneficiaries Only
| |
| 31 | 3 | Bank Service Initiation | LFIs OFP TPPs | The rules of IP-8 in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151849156/International+Payments#3.1.1-Rules-%26-Guidelinescontain duplicate numbering of rules 8.5. | The rule numbers of IP-8 are modified as follows: 8.5 (duplicate) → 8.6, 8.6 → 8.7, 8.7 → 8.8, 8.8 → 8.9, 8.9 → 8.10, 8.10 → 8.11, 8.11 → 8.12, 8.12 → 8.13, 8.13 → 8.14, 8.14 → 8.15 | |
| 32 | 3 | Bank Service Initiation | TPPs | The rule 8.6 IP-8 in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151849156/International+Payments#3.1.1-Rules-%26-Guidelines includes the User (Debtor) Payment Account (i.e. account identifier) and the Creditor Identification details as parameters included in the IP Payment Initiation Request sent from the TPP. The Debtor and Creditor Identification details have now been removed from the IP Payment Initiation Request and LFIs will get this information from the authorized Payment Consent. | IP-8 rule 8.6 is modified as follows: “OFP MUST: 8.6 Send the IP payment initiation request to the LFI for initiating a single International Payment using the payment parameters included in the payment initiation request including:
| |
| 33 | 3 | Bank Service Initiation | LFIs | The rules of IP-8 in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151849156/International+Payments#3.1.1-Rules-%26-Guidelinesdo not include the requirement for LFIs to retrieve the Creditor Identification details from the encrypted PII information block included in the authorized IP Payment Consent. | IP-8 rule 8.8 is modified to add a new rule as follows: “LFIs MUST: 8.8 Trigger the payment initiation process for the payment Consent immediately after receiving the payment initiation request from the OFP.
| |
| 34 | 3 | Bank Service Initiation | OFP | Rule 2.3 of FRIPPI-2 in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151849156/International+Payments#3.2.5-Payment-Initiation incorrectly includes the requirement for OFP to check that the Creditor Identification details in the submitted payment initiation request matches exactly the Creditor Identification in the authorized Fixed Recurring IP Payment Consent. This is not possible as this information is encrypted and not available to the OFP. | Rule 2.3 of FRIPPI-2 is modified to remove the requirement to check the Creditor Identification details from the OFP. The updated rule is as follows: “OFP MUST: 2.3 Check the payment initiation request parameters against the authorized long-lived Fixed Recurring IP Payment Consent. More specifically, the OFP MUST check the following:
| |
| 35 | 3 | Bank Service Initiation | TPPs | The rule 2.9 of FRIPPI-2 in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151849156/International+Payments#3.2.5-Payment-Initiation includes the User (Debtor) Payment Account (i.e. account identifier) and the Creditor Identification details as parameters included in the IP Payment Initiation Request sent from the TPP. The Debtor and Creditor Identification details have now been removed from the IP Payment Initiation Request and LFIs will get this information from the authorized Payment Consent. | FRIPPI-2 rule 2.9 is modified as follows: “OFP MUST: 2.9 Send the IP payment initiation request to the LFI for initiating a single International Payment using the payment parameters included in the payment initiation request including:
| |
| 36 | 3 | Bank Service Initiation | LFIs | The rules of FRIPPI-2 in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151849156/International+Payments#3.2.5-Payment-Initiation do not include the requirement for LFIs to retrieve the Creditor Identification details from the encrypted PII information block included in the authorized IP Payment Consent. | New rules are added to FRIPPI-2 as follows: “LFIs MUST: 2.11 Trigger the payment initiation process for the payment Consent immediately after receiving the payment initiation request from the OFP.
The rule numbers of FRIPPI-2 are modified as follows: 2.11 → 2.12, 2.12 → 2.13, 2.13 → 2.14, 2.14 → 2.15, 2.14 → 2.15, 2.15 → 2.16, 2.16 → 2.17, 2.17 → 2.18 | |
| 37 | 3 | Bank Service Initiation | LFIs | Rule 5.8 of MPCS-5 in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850011/Payments+with+Delegated+Authentication#3.1.-Consent-Setup includes reference to Fees to be displayed by LFIs, if applicable. This reference is no longer relevant. | Updated rule 5.8 of MPCS-5 to remove the reference to LFI fees. “LFIs MUST: 5.8 Present to Users the following minimum required information for authorizing the long-lived payments Consent:
| |
| 38 | 3 | Bank Service Initiation | OFP | Rule 2.4 of DELPI-2 in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850011/Payments+with+Delegated+Authentication#Processing-of-Payment-Initiation-Requests https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151849156/International+Payments#3.2.5-Payment-Initiation should not be a separate rule but instead a bullet point of rule 2.3. | Rule 2.4 of DELPI-2 is modified to become a bullet point of rule 2.3. The updated rules is as follows: “OFP MUST: 2.3 Check the payment initiation request parameters against the authorized long-lived Payment Consent. More specifically, the OFP MUST check the following:
| |
| 39 | 3 | Bank Service Initiation | TPPs | Rule 2.7 of DELPI-2 in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850011/Payments+with+Delegated+Authentication#Processing-of-Payment-Initiation-Requestsincludes the User (Debtor) Payment Account (i.e. account identifier) and the Creditor Identification details as parameters included in the Payment Initiation Request sent from the TPP. The Debtor Identification details have now been removed from the Payment Initiation Request and LFIs will get this information from the authorized Payment Consent. | Rule 2.7 of DELPI-2 is modified as follows: “OFP MUST: 2.7 Send a payment initiation request to the LFI for initiating an instant payment using the payment parameters included in the payment initiation request including:
| |
| 40 | 3 | Bank Service Initiation | LFIs | The rules of DELPI-2 in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850011/Payments+with+Delegated+Authentication#Processing-of-Payment-Initiation-Requests do not include the requirement for LFIs to trigger the payment initiation process immediately after receiving the payment initiation request from the OFP. | New rule added to DELPI-2 as follows: “LFIs MUST: 2.9 Trigger the payment initiation process immediately after receiving the payment initiation request from the OFP.”
The rule numbers of DELPI-2 are modified as follows: 2.9 → 2.10, 2.10 → 2.11, 2.11 → 2.12, 2.12 → 2.13, 2.13 → 2.14, 2.14 → 2.15, 2.15 → 2.16. | |
| 41 | 3 | Bank Service Initiation | LFIs | Rule 3.7 of COP-3 in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151849745/Confirmation+of+Payee#2.4-Rules-%26-Guidelines incorrectly states that LFIs must provide Users (Creditors) with the option to select to opt-out from the COP service, so that their account information is not shared with the OFP. This is not to be allowed for all users, instead this functionality is to be available only for VPIs, PEPs and other special account holders. | Rule 3.7 of COP-3 is modified as follows: “CREDITOR LFIs MUST: 3.7 NOT provide Users (Creditors) the option to select to opt-out from the COP service. However, in exceptional circumstances only, such as where the account holder is a national or Emirati leader or their immediate family, LFIs have the ability to establish processes to agree with the account holder that their account information will not be shared with the OFP when receiving a Customer Data request message from the OFP for COP purposes.
| |
| 42 | 3 | Bank Data Sharing | N/A | Rule 2.8 of CDCS-2 in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850555/Customer+Data#Data-Sharing-Consentis incomplete and must be defined correctly. | Rule 2.8 of CDCS-2 is modified as follows: “2.8 Set/clear the “Is Single Authorization” flag as appropriate (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850813/Common+Rules+and+Guidelines#7.-Is-Single-Authorization-flag).” | |
| 43 | 3 | Bank Data Sharing | N/A | The rules of CDCS-2 in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850555/Customer+Data#Data-Sharing-Consent contain duplicate numbering of rules 2.8. | The rule numbers of CDCS-2 are modified as follows: 2.8 (duplicate) → 2.9 | |
| 44 | 3 | Bank Data Sharing | LFIs | Rules 7.5 and 7.6 of CDCS-7 inhttps://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850555/Customer+Data#Select-Accounts need to provide more clarity for the scenario that the Data Request Consent is related to non-account specific data permissions. | Rules 7.5 and 7.6 of CDCS-7 have been modified as follows: “LFIs MUST: 7.5 NOT request Users to select any account from their eligible account list when the Data Request Consent does not include any account-specific data permissions and instead includes only User data permissions (e.g. in the case of the Parties endpoint).
7.6 Allow Users to proceed to the Data Sharing Consent authorization without selecting any accounts in the case of Consents solely including non account-specific data permissions.” | |
| 45 | 3 | Bank Data Sharing | LFIs TPPs | Customer Experience in Section 3 does not include the case that the TPP only requires the User to share User Information which is not account specific and thus the User is not required to select an account at their LFI during Data Sharing Consent. | Added new sub section in Section 3 to include the case that the TPP only requires the User to share User Information which is not account specific. New section is as follows: 3.2 Journey Variations3.2.1 User selects account at the TPP & LFI provides Supplementary Information | |
| 46 | 3 | Banking | LFIs | Limit A13https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850897/Limits+and+Constants#Max-historical-data-for-Data-Sharing-Requestfor Banking is defined to be 24 months. However, this should be defined to be the minimum supported period by each LFI. The maximum period to be provided by each LFI should be aligned to what is their current capabilities in their existing online and mobile channels. | Limit A13 is modified as follows: “ID: A13Name: End Date of historical data for Data Sharing RequestDescription: The end date of the period of historical data that can be requested by TPPs and which MUST be sent by LFIs for Data Sharing Requests. This will differ based on the industry sector of LFIs, as follows:
| |
| 47 | 3 | Bank Data Sharing | TPPs | Rule 2.4 of CDCS-2 in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850555/Customer+Data#3.1-Rules-%26-Guidelines includes wording which can be confusing for TPPs and LFIs. | Rule 2.4 of CDCS-2 has been updated as follows: “TPPs MUST: 2.4 Define the start and end dates for the period needed for historical data, if required for a specific use case. The end date of the period of historical data that can be requested by TPPs and which MUST be returned by LFIs for a Data sharing Request is as per the End Date of historical data for Data Sharing Request defined in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850897/Limits+and+Constants#A.-Limits.” | |
| 48 | 3 | Bank Service Initiation | https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850813 | TPPs | Rule CRG-17.1.1 has been included: “TPPs MUST: CRG-17.1.1 Notify the debtor about any upcoming scheduled payments, including fixed future payments, future variable payments, and recurring payments one day before the payment date. The notification must include details of the payment amount, date, and beneficiary and should be delivered through the same channels used for payment-related notifications (e.g., SMS, email, app notifications).” | |
| 49 | 3 | Common Components | https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151847205 | TPPs |
| New rule 5.5 has been included: “TPPs MUST: 5.5 Inform customers if their data will be replicated outside the UAE. This notification must include clear details about where the data will be processed and stored. The TPP must obtain explicit agreement from the customer before proceeding with any data sharing or service initiation request.” The rule numbers of https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151847205/Consent+Setup#5.-General-Consent-Rules are modified as follows: 5.5 → 5.6, 5.6 → 5.7, 5.7 → 5.8, 5.8 → 5.9, 5.9 → 5.10, 5.10 → 5.11, 5.11 → 5.12, 5.12 → 5.13, 5.13 → 5.14, 5.14 → 5.15, 5.15 → 5.16, 5.16 → 5.17. |
| 50 | 3 | Bank Service Initiation | LFIs | Rule 5.6 of BBP-5 in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151849558/Bulk+and+Batch+Payments#3.1-Rules-%26-Guidelines includes reference to Fees to be displayed by LFIs, if applicable. This reference is no longer relevant. | Updated rule 5.6 of BBP-5 to remove the reference to LFI fees “LFIs MUST: Supplementary/ Missing Payment Information 5.6 Although the creditor details and total amount are known to the LFI before the User is authenticated, LFIs must introduce a step after authentication to allow Users to provide additional information associated with the bulk/batch payment in order to complete the payment instructions if the payment order is incomplete. This information may include:
| |
| 51 | 3 | Bank Service Initiation | https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151849558
| LFIs | Create BBP-7.3 (https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151849558/Bulk+and+Batch+Payments#Payment-Status-Update) “LFIs MUST: | |
| 52 | 3 | Bank Service Initiation | TPPs |
| Create DELPC-1.4 “TPPs MUST: 1.4 Implement any of the Action-Based Controls to govern the execution of VRPs. These controls must ensure that only specific, predefined actions can trigger a transaction without additional customer authorization.
Any unusual or unexpected actions, such as transactions with significantly higher amounts or non-typical service charges, must require explicit customer approval before payment is processed. Clearly explain to customers the implications of these Action-Based Controls at the time of onboarding or during any update to the payment consent. This explanation should include:
The TPP must ensure that customers fully understand how these controls affect the payment process and their role in managing their consent for different types of transactions.” | |
| 53 | 3 | Common Rules and Guidelines | LFIs TPPs | Section did not include any rules, guidelines or controls about access to accounts of minors.
| New section 1.1 was added to provide guidelines and controls about access to accounts of minors. 1.1 Accounts for minors This section includes key guidelines and parental controls for access to accounts of minors in the context of Open Finance in the UAE. 1.1.1 Consent and Authorization
1.1.2 Data and Security
1.1.3 Age-Appropriate Services
1.1.4 Access Restrictions
1.1.5 Payment Initiation
| |
| 54 | 3 | Common Components | LFIs TPPs | Section 11 of https://openfinanceuae.atlassian.net/wiki/x/-AANCQ does not explicitly state that an LFI must not make use of multi-press buttons, nor that they must not request Users to provide additional confirmations. | https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151847164/User+Experience+Principles#11.-Other-Rules-for-User-Journeys has been updated as follows:
| |
| 55 | 3 | Common Components | https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151846961
| LFIs TPPs | https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151847050
| Currently, the Registration Framework includes the following references in Section 5 and also screenshot/sample code in sections 6.1 and 8.2 “authorization_detail_types” |
| 56 | 3 | Common Components | TPPs | Further clarification is required to be added about how TPPs will be presenting the LFIs to Users for easier identification. | Rule 2.2.15 is added as follows: “TPPs MUST use logos and the brand names of the LFIs as they are defined in the Trust Framework Directory.” | |
| 57 | 3 | Common Components | LFIs | Further clarification is required to be added about how LFIs will be presenting the TPPs to Users for easier identification. | Rule 2.2.3 has been modified as follows:
| |
| 58 | 3 | Common Components | N/A | Further clarification is required to be added about how the CAAP will be presenting the TPPs and LFIs to Users for easier identification. | An addition has been made to the Overview as follows: “The CAAP MUST use logos and brand names of the LFIs and TPPs as they are defined in the Trust Framework Directory.” | |
| 59 | 3 | Common Components | https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848167 | TPPs | Controls have been added that set expectations on the integrity of the mobile device. | The following are added to the Controls section:
|
| 60 | 4 | Banking | TPPs | PR-31 of https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850211/Pay+Request+enabled+by+Open+Finance#3.-Example-Rules-%26-Guidelines states incorrectly that TPPs must proceed with the Single Instant Payment Initiation journey as per the https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848909/Multi-Payments#5.-Payment-Initiation of the Open Finance Standard. | Rule of step PR-31 has been updated as follows: “TPPs MUST:
| |
| 61 | 4 | Banking | TPPs | Further clarifications and examples in relation to the definitions are required. | Section has been updated as follows: “TPPs & OFP MUST: 8.2.2.1 Enable their systems to support the following definitions:
| |
| 62 | 4 | Banking | TPPs | Rule 2.3 of MPPI-2 in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848909/Multi-Payments#5.-Payment-Initiation requires more clarity in relation to the checking of payment initiation date from the OFP. | Rule 2.3 of MPPI-2 has been updated as follows: “OFP MUST: 2.3 Check the payment initiation request parameters against the authorized long-lived Payment Consent. More specifically, the OFP MUST check the following:
| |
| 63 | 4 | Limits and Constants | TPPs | The entry A15 Max SIP Payment Initiation Time Interval must be defined to be 10min instead of 5sec to align to the token validity period. | Entry A15 has been updated as follows: ID: A15Name: Max SIP Payment Initiation Time IntervalDescription: 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 10min. The OFP will reject the Payment Initiation Request is submitted outside this time window. | |
| 64 | 4 | Limits and Constants | TPPs | The entry A16 Max Bulk/Batch Payment Initiation Time Interval must be defined to be 10min instead of 5sec to align to the token validity period. | Entry A16 has been updated as follows: ID: A16Name: Max Bulk/Batch Payment Initiation Time IntervalDescription: 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 10min. The OFP will reject the Payment Initiation Request is submitted outside this time window. | |
| 65 | 4 | Limits and Constants | TPPs | The entry A17 Max FDP Payment Initiation Time Interval must be defined to be 10min instead of 5sec to align to the token validity period. | Entry A17 has been updated as follows: ID: A17Name: Max FDP Payment Initiation Time IntervalDescription: 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 10min. The OFP will reject the Payment Initiation Request is submitted outside this time window. | |
| 66 | 4 | Common Components | LFIs TPPs | In Errata2, a rule was added to User Experience Principles to state that “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.”, without provision of the necessary assets. |  The relevant logos and color codes are attached and are to be implemented in line with the customer experience screens provided in the Standard. | |
| 67 | 4 | Banking | N/A | Link to the Periodic Payment Schedule of Multi-Payments is incorrect. | Updated section 3.2 with the correct link, as follows: “Long-lived multi-payment consents can be combined with International Payments to enable Service Initiation capabilities for recurring cross-border payments. The initial scope of the Standard will supporting Fixed Recurring IP Payments as follows:
| |
| 68 | 4 | Banking | TPPs | Rule 4.5.1 of https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151849156/International+Payments#4.5-Payment-Charge-Model-for-International-Payments requires mapping of the user language for the charge bearer model to the values used in the API Description. | Updated rule 4.5.1 as follows: “TPPs MUST: 4.5.1 Either allow Users to select the charge model for the international payment order. This can be one of the following:
| |
| 69 | 4 | Banking | TPPs | Links in the section are incorrectly displayed. | Updated section 4.7 with the correct links, as follows: “TPPs MUST: 4.7.1 Support all category purpose codes including their descriptions as defined in the international https://www.iso20022.org/catalogue-messages/additional-content-messages/external-code-sets in order to be able to support the requirements for International Payments. 4.7.2 Either allow Users to select the available purpose of payment from a list or pre-populate it for Users. 4.7.3 Ensure and validate that the format of the payment purpose is according to the international https://www.iso20022.org/catalogue-messages/additional-content-messages/external-code-setsformat.” | |
| 70 | 4 | Banking | LFIs | Rule CRG-1.4.2 of states that “In the scenario that IPP is unavailable, (e.g. maintenance) and planned downtime, the LFIs MUST NOT route the Open Finance payments via other payment systems. Instead, LFIs MUST keep the status of the payment to pending and process the payment as normal when IPP is available again.” | Rule CRG-1.4.2 has been updated as follows: “LFIs MUST:
| |
| 71 | 4 | Banking |
| TPPs | Throughout the references to Variable-defined consent has been changed to Fixed-defined consent. That is to allow a new type of predefined schedule with known dates but unknow values. This type was introduced as Variable-defined consent keeping in alignment with the wording structures of Fixed/Variable for payment amounts. | The page has been updated as follows:
|
| 72 | 4 | Banking | LFIs | The LFI customer experience screen displays an option to ‘Review the information you will be sharing’, without indicating what the expected experience is if a user selects the arrow. | The LFI customer experience screen has been updated to display a dropdown with the data clusters being shared, identical to the dropdown displayed at the TPP. | |
| 73 | 4 | Common Components |
| LFIs | Several inconsistencies and errors in the wireframes related to the LFI Consent Management Interfaces. | Updated all wireframes in all sections of the page.
|
| 74 | 4 | Payments with Delegated Authentication |
| TPPs | Update to authentication factors that TPP can use for MFA. | User biometrics, dynamic tokens (using Authenticator apps Authy, Google Authenticator, and Microsoft Authenticator etc. or RFID), mobile phone, plastic card, and other User identification (e.g. Emirates ID). |
| 75 | 4 | Banking |
| TPPs | Previous version incorrectly included a duplicate transaction scenario, stating that TPPs should detect where Users have triggered duplicate transactions and display error message to warn about this. However, there are no BRs requesting TPPs to detect transaction duplicates. | Page has been updated to remove this entry from the PIS scenarios. |
| 76 | 4 | Banking |
| TPPs | Scenario trigger in first entry in the table is incorrectly stated to be Creditor LFI, | Removed Creditor LFI from the first entry scenario triggers. |
| 77 | 4 | Banking |
| TPPs | Table incorrectly includes PIS stage of Proxy Lookup which is currently out of scope of the Open Finance Standard. | Removed the Proxy Lookup entry from the table |
| 78 | 4 | Banking |
| TPPs | Insufficient Funds entry is incorrectly stated as Beneficiary Add and/or Activation PIS stage, instead of Select Account & Confirmation. | Changed the PIS stage to Select Account & Confirmation for the Insufficient Funds scenario |
| 79 | 4 | Banking |
| TPPs | Further clarification was required to indicate the TPP’s obligation to capture the User’s Emirates ID in certain scenarios. | TPPs MUST “CRG-9.3.2.1 Capture a user's Emirates ID for all payments where a long-lived consent is required. CRG-9.3.2.2 Capture a user's Emirates ID for all data sharing use cases where transaction data is shared, regardless of the consent type. CRG-9.3.2.3 Capture the user’s Emirates ID prior to initiating the prescribed user journey for the relevant use case.
Note: TPPs are not required to verify the Emirates ID.” |
| 80 | 4 | Banking |
| TPPs | Further clarification was required to include additional data in the risk block, and specify which data is mandatory, conditional or optional. | The risk block table has been updated to include additional fields, as well as indicators of which fields are mandatory, conditional or optional. |
| 81 | 4 | Banking |
| TPPs | An additional rule was required to specify a payment limit for first-time payments to new beneficiaries. | TPPs MUST “8.3 Impose a payment limit of 15000 AED for all first-time payments made to a new beneficiary.
|
| 82 | 4 | Banking |
| TPPs | Enhancement of the authentication method required for payments with Delegated SCA. |
1.4.1 The authentication methods are limited to the following:
|
| 83 | 4 | Common Components |
| TPP & LFIs | Provide clarifications to ensure that channels and use cases are mutually supportive. |
The inclusion of CRG-1.6, CRG-1.7 & CRG-1.8. |
Technical specifications updates
Errata version | Section | Subsection | Impacts | Description | Action | |
|---|---|---|---|---|---|---|
| 1 | 1 | Common Components | Updated in | The | Implementers should follow the specification as per | |
| 2 | 1 | Common Components | Updated in | The optional | Implementers should follow the specification as per | |
| 3 | 1 | Common Components | Updated in | The | Implementers should follow the specification as per | |
| 4 | 1 | Common Components | Updated in | The | Implementers should follow the specification as per | |
| 5 | 1 | Common Components | TPPs | The | Implementers should follow the specification as per | |
| 6 | 1 | Common Components | LFIs TPPs | The enumerations listed within the | Implementers should follow the specification as per | |
| 7 | 1 | Common Components | LFIs TPPs | Within the | Implementers should follow the specification as per | |
| 8 | 2 | Common Components | LFIs OFP TPPs | 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 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 The steps for creating and processing the JWE are as follows:
Please note that the use of TPPs and LFIs should follow the described mechanism to implement using the | |
| 9 | 2 | Common Components | TPPs | 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 | |
| 10 | 2 | Bank Data Sharing | Updated in | The |
| |
| 11 | 2 | Bank Service Initiation | LFIs TPPs |
|
| |
| 12 | 2 | Common Components | Updated in | The |
| |
| 13 | 2 | Common Components | TPPs | The |
| |
| 14 | 2 | Common Components | LFIs TPPs |
|
| |
| 15 | 2 | Common Components | Updated in |
| The | |
| 16 | 2 | Common Components | LFIs TPPs |
| The Schema Object | |
| 17 | 2 | Common Components | Updated in |
| The Schema Object | |
| 18 | 2 | Common Components | Updated in |
|
| |
| 19 | 2 | Common Components | Updated in |
|
| |
| 20 | 2 | Common Components | LFIs TPPs | The |
| |
| 21 | 3 | Common Components |
| LFIs TPPs | Additional elements required from TPP to facilitate Billing for Data Sharing | AEAccountAccessAuthorizationDetailConsentProperties updated to include OpenFinanceBilling object. UserType:
Purpose:
|
| 22 | 3 | Common Components |
| LFIs TPPs | Additional elements required from TPP to facilitate Billing for Data Sharing | Purpose field has been moved into the OpenFinanceBilling object |
| 23 | 3 | Common Components |
| TPPs OFP | Version and servers read v1.0 | Version and servers in OpenAPI document changed to v1.1 for consistency with rest of specification |
| 24 | 3 | Common Components |
| TPPs OFP | AEAccountAccessAuthorizationDetailsConsent fields incorrectly updated in draft3 to be capitalised (Type and Consent) - this is not compliant with the RAR spec | AEAccountAccessAuthorizationDetailsConsent updated to "type", "consent" and "subscription" |
| 25 | 3 | Common Components |
| TPPs OFP | AEAccountAccessAuthorizationDetailsConsent fields incorrectly updated in draft3 to be capitalised (Type and Consent) - this is not compliant with the RAR spec | AEAccountAccessAuthorizationDetailsConsent updated to "type", "consent" and "subscription" |
| 26 | 3 | Common Components |
| TPPs OFP | AEInsuranceAuthorizationDetailsConsent fields incorrectly updated in draft3 to be capitalised (Type and Consent) - this is not compliant with the RAR spec | AEInsuranceAuthorizationDetailsConsent updated to "type", "consent" and "subscription" |
| 27 | 3 | Common Components |
| TPPs OFP | AEServiceInitiationAuthorizationDetailConsent fields incorrectly updated in draft3 to be capitalised (Type and Consent) - this is not compliant with the RAR spec | AEServiceInitiationAuthorizationDetailConsent updated to "type", "consent" and "subscription" |
| 28 | 3 | Common Components |
| LFIs TPPs | Additional elements required from TPP to facilitate Billing for Insurance | OBInsuranceAuthorizationDetailConsentProperties updated to include OpenFinanceBilling object. Purpose:
|
| 29 | 3 | Bank Data Sharing |
| LFIs TPPs | Consent response updated to align with PAR updates | AEReadConsentResponse updated to include OpenFinanceBilling OpenFinanceBilling has two mandatory fields specified by the TPP (UserType and Purpose); and one optional field specified by the LFI (IsLargeCorporate) |
| 30 | 3 | Bank Data Sharing |
| LFIs TPPs | It has been identified that some LFIs display beneficiary CreditorAccounts that include Credit Card accounts, Proxy accounts, and Utilities This affects beneficiaries, standing orders and scheduled payments | AECashAccount5_0 has been updated to allow for additional enumerations enum:
|
| 31 | 3 | Bank Service Initiation |
| LFIs TPPs | Additional elements required from TPP to facilitate Billing for Payments | New object in the AEPaymentConsentResponse with one optional field specified by the LFI (IsLargeCorporate) |
| 32 | 3 | Bank Service Initiation |
| LFIs TPPs | Additional elements required from TPP to facilitate Billing for Payments | New object in the AEPaymentRequest and AEPaymentIdResponse with one mandatory field Type, and one optional field for the MerchantId - both specified by the TPP at point of payment initiation Type:
description: The type payment for billing |
| 33 | 3 | Bank Service Initiation |
| LFIs TPPs | Additional elements required from TPP to facilitate Billing for File Payments | New object in the AEFilePaymentIdResponse with one optional field for the NumberOfSuccessfulTransactions - updated by the LFI after the file is fully processed |
| 34 | 3 | Common Components |
| OFP TPPs | The existing PersonalIdentifiableInformation object supports only 1 creditor being identified for a payment consent | In the AEPaymentPII example in the PersonalIdentifiableInformation field - have made the creditor identification details an array to support original business requirements This has not been updated in the Bank Initiation spec (as each individual payment will only have 1 creditor) |
| 35 | 3 | Bank Service Initiation |
| LFIs TPPs | The DebtorAccount and CreditorAccount will be taken from the consent, so that an additional check is no longer required if only one DebtorAccount or CreditorAccount is specified in the consent | Removed DebtorAccount from the AEPaymentPII example in the PersonalIdentifiableInformation field - as this will be taken from the consent |
| 36 | 3 | Bank Data Sharing |
| LFIs TPPs | The account statuses did not match the regulations for Inactive, Dormant, and Unclaimed provided by CBUAE. |
|
| 37 | 4 | Common Components |
| TPPs | Business Rules state that consent cannot be more than a year |
|
| 38 | 4 | Common Components |
| TPPs | Reconsent objects removed from standard, as this is not part of the existing Business Rules |
|
| 39 | 4 | Bank Service Initiation |
| TPPs |
|
|
| 40 | 4 | Bank Service Initiation |
| TPPs | The TPP is no longer expected to send in the | Removed |
| 41 | 4 | Bank Service Initiation |
| TPPs |
| Removed |
| 42 | 4 | Bank Service Initiation |
| TPPs LFIs (very minimal impact to LFIs - as it is purely a different way of identifying existing functionality) | For explicitness have added | Added |
| 43 | 4 | Bank Service Initiation |
| TPPs LFIs (very minimal impact to LFIs - as it is purely a different way of identifying existing functionality) |
| To simplify implementation and better align with Business Rules we have created a:
These are both arrays of up to 53 items.
|
| 44 | 4 | Bank Service Initiation |
| TPPs LFIs (very minimal impact to LFIs - as it is purely a different way of identifying existing functionality) |
| Both
|
| 45 | 4 | Bank Service Initiation |
| TPPs LFIs (very minimal impact to LFIs - as it is purely a different way of identifying existing functionality) | New object to reflect |
Where
|
| 46 | 4 | Bank Service Initiation |
| TPPs LFIs (very minimal impact to LFIs - as it is purely a different way of identifying existing functionality)) | New object to reflect |
Where
|
| 47 | 4 | Bank Service Initiation |
| TPPs LFIs (very minimal impact to LFIs - as it is purely a different way of identifying existing functionality) | Issues with
| Removed duplication of Updated |
| 48 | 4 | Bank Service Initiation | LFIs TPPs | Errata for
| Updates:
| |
| 49 | 4 | Bank Service Initiation | TPPs |
|
| |
| 50 | 4 | Bank Service Initiation | TPPs |
| Updated - "BorneByCreditor"
- "BorneByDebtor"
- "Shared" | |
| 51 | 4 | Bank Data Sharing | LFIs |
| Removed | |
| 52 | 4 | Common Components |
| LFIs TPPs | OpenAPI description did not convey the decoded version of the property, making it difficult for implementers to understand. | PII types (Payment, |
| 53 | 4 | Insurance |
| TPPs | API operations to retrieve policies were not differentiated by industry, which has been highlighted as being desirable in early industry sessions for the next insurance release. | API operations for motor insurance are now hosted at |
| 54 | 4 | Bank Service Initiation |
| TPPs | The |
|
| 55 | 4 | Bank Service Initiation |
| TPPs | The | Removed |
| 56 | 4 | Bank Service Initiation |
| TPPs |
| Merged two Schema Objects into one, with one |
| 57 | 4 | Bank Service Initiation |
| TPPs | Enhancements requested for the | Updates to the |
© CBUAE 2024-2025
Open License and Contribution Agreement | Attribution Notice
Please try out our Advanced Search function.