Standards v1.0-final-errata3

Authentication and Authorization

Authentication by LFI | 2. Redirection

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.

Bank Service Initiation

Single Instant Payments | Authorization

Rule 5.6 of SIP-5 in Single Instant Payments | 3.1.2 Rules & 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:

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

Bank Service Initiation

Single Instant Payments | Payment Initiation

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”

Bank Service Initiation

Single Instant Payments | Payment Initiation

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

Bank Service Initiation

Future Dated Payments | Authorization

Rule 5.7 of FDP-5 in Future Dated Payments | 3.2 Rules & 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:

• User Payment Account

• Payment Amount & Currency

• Creditor Identification details including:

  • Creditor Name

  • Creditor Account (IBAN)

  • Creditor Account Holding LFI

• Debtor Reference (Optional)

• Creditor Reference

• Purpose of Payment

• Requested Execution Date”

Bank Service Initiation

Future Dated Payments | Hand off back to the TPP

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

Bank Service Initiation

Future Dated Payments | FDP Warehousing & Scheduling

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

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

Bank Service Initiation

Future Dated Payments | FDP Warehousing & Scheduling

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.4.1 Reject the FDP payment initiation and provide the necessary error message to the TPP if any checks of the FDP payment initiation request parameters fail against the Consent parameters of the authorized FDP Payment Consent.

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:

• Authorized Payment Consent Identifier

• Payment Amount & Currency

• Debtor Reference (if provided)

• Creditor Reference

• Purpose of Payment

• Requested Execution Date”

Bank Service Initiation

Future Dated Payments | FDP Warehousing & Scheduling

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.

• 7.6.1 Retrieve the Creditor Identification details from the encrypted PII information block included in the original FDP 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.”

Bank Service Initiation

Multi-Payments | Authorization

Rule 5.7 of MPCS-5 in Multi-Payments | 3.2 Rules & 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:

• User Payment Account

• Creditor Identification details (one or more if included in the Consent e.g. for Variable-defined)

  • For Variable Beneficiaries, a message stating the Payee will be specified and validated during the payment initiation

• Debtor Reference (Optional)

• Consent Reference

• Purpose of Payment

• Payment Amount & Currency (if relevant, depending on the type of the long-lived payment Consent)

• Consent Controls Parameters (if relevant, depending on the type of the long-lived payment Consent)

• Consent Control Period & Start Date (if relevant, depending on the type of the long-lived payment Consent)

• The Payment Schedule (Periodic or Variable-defined) (if relevant, depending on the type of the long-lived payment Consent)

• Consent Expiration Date & Time”

Bank Service Initiation

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

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:

• The date of the submitted payment initiation request is within:

  • the validity period of the long-lived Payment Consent (i.e. Consent Expiration Date & Time)

  • the period defined in the Periodic or Variable-defined Payment Schedule (for Fixed Recurring, Variable Recurring and Variable-defined Consent types). In this case, the dates of each payment initiation request MUST match exactly the dates in the Payment Schedule.

• The amount in the submitted payment initiation request:

  • matches exactly the payment amount for consents of type Fixed Recurring and Fixed On-demand.

  • matches exactly the payment amount for the date of the payment initiation for consents of type Variable-defined.

  • is less or equal to the maximum payment value per payment initiation for consents of type Variable Recurring and Variable On-demand.”

Bank Service Initiation

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

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

Bank Service Initiation

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

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:

• Authorized Payment Consent Identifier

• Payment Amount & Currency

• Debtor Reference (If provided)

• Creditor Reference

• Purpose of Payment

Variable Beneficiaries Only

• 2.15.1 For Variable Beneficiaries, the Payment Initiation Request will also include the Creditor Identification details provided by the TPP, as this information was not included in the authorized Multi-Payments Consent.”

Bank Service Initiation

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

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

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

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

Variable Beneficiaries Only

• 2.16.3 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. In case of failure. LFIs MUST reject the payment initiation request and notify the OFP about this rejection with an appropriate error message.”

Variable-defined Beneficiaries Only

• 2.16.4 Check and validate the Creditor Identification details included in the payment initiation request against the Creditor details in the authorized Multi-Payment Consent. In case that the Creditor Identification details do not exactly match any of the Creditor Identification details in the authorized Multi-Payment with Variable-defined Beneficiaries Consent, LFIs MUST reject the payment initiation request and notify the OFP about this rejection with an appropriate error message.”

Bank Service Initiation

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151849156/International+Payments#Payment-Initiation

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

Bank Service Initiation

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151849156/International+Payments#Payment-Initiation

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:

• Authorized Payment Consent Identifier

• Payment Amount & Currency

• Payment Amount in User’s Payment Account Currency (for International-FX Payments)

• FX rate for the transaction (for International-FX Payments) as per the authorized Payment Consent

• Debtor Reference (Optional)

• Creditor Reference

• External Payment Purpose Code

• Payment Order Priority (for International-FX & International Payments)

• Payment Charges model (for International-FX & International Payments)”

Bank Service Initiation

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151849156/International+Payments#Payment-Initiation

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.

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

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

Bank Service Initiation

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151849156/International+Payments#3.2.5-Payment-Initiation

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:

• The date of the submitted payment initiation request is within:

  • the validity period of the long-lived Fixed Recurring IP Payment Consent (i.e. Consent Expiration Date & Time)

  • the period defined in the Periodic Payment Schedule. In this case, the dates of each payment initiation request MUST match exactly the dates in the Payment Schedule.

• The amount in the submitted payment initiation request matches exactly the consented payment amount for the Fixed Recurring IP Consent.”

Bank Service Initiation

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151849156/International+Payments#Processing-of-Payment-Initiation-Requests

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:

• Authorized Payment Consent Identifier

• Payment Amount & Currency

• Payment Amount in User’s Payment Account Currency (for International-FX Payments)

• FX rate for the transaction (for International-FX Payments) as per the authorized Payment Consent

• Debtor Reference (Optional)

• Creditor Reference

• External Payment Purpose Code

• Payment Order Priority (for International-FX & International Payments)

• Payment Charges model (for International-FX & International Payments)”

Bank Service Initiation

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151849156/International+Payments#3.2.5-Payment-Initiation

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.

• 2.11.1 Retrieve the Creditor Identification details from the encrypted PII information block included in the original Fixed Recurring IP Payment Consent message.

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

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

Bank Service Initiation

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850011/Payments+with+Delegated+Authentication#Authorization

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:

• User Payment Account

• Consent Reference

• Currency

• Consent Expiration Date & Time”

Bank Service Initiation

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850011/Payments+with+Delegated+Authentication#Processing-of-Payment-Initiation-Requests

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:

• The date of the submitted payment initiation request is within the validity period of the long-lived Payment Consent (i.e. Consent Expiration Date & Time)”

Bank Service Initiation

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850011/Payments+with+Delegated+Authentication#Processing-of-Payment-Initiation-Requests

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:

• Authorized Payment Consent Identifier

• Payment Amount & Currency

• Creditor Identification details (encrypted)

• Debtor Reference (If provided)

• Creditor Reference”

Bank Service Initiation

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850011/Payments+with+Delegated+Authentication#Processing-of-Payment-Initiation-Requests

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

• 2.9.1 Retrieve the Creditor Identification details from the encrypted PII information block included in the Payment Initiation Request message.

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

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.

Bank Service Initiation

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151849745/Confirmation+of+Payee#COP-Service

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.

• 3.7.1 In this case, LFIs MUST return no data in their response message back to the OFP.”

Bank Data Sharing

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850555/Customer+Data#3.-Customer-Experience

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

Bank Data Sharing

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850555/Customer+Data#3.-Customer-Experience

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

Bank Data Sharing

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850555/Customer+Data#3.-Customer-Experience

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.5.1 Display to Users the full details of their personal data that will be shared with the TPP for the requested period of the Consent.

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

Bank Data Sharing

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850555/Customer+Data#3.-Customer-Experience

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 Variations

3.2.1 User selects account at the TPP & LFI provides Supplementary Information

Open

Banking

https://openfinanceuae.atlassian.net/wiki/x/kQ8NCQ

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

Name: End Date of historical data for Data Sharing Request

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

• Banking: LFIs MUST provide the historical data for the period that they are stored in their systems of record and are available to Users in the LFIs' existing online or mobile channels. As a minimum, all LFIs MUST be able to provide at least 24 months of historical data, if it exists.

• Insurance: LFIs MUST provide the historical data for the period that they are stored in their systems of record. As a minimum, all LFIs MUST be able to provide at least up to 5 years of historical data, if exist.”

Bank Data Sharing

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850555/Customer+Data#Data-Sharing-Consent

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

Bank Service Initiation

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

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

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

Common Components

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

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151847205/Consent+Setup#5.-General-Consent-Rules

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.

Bank Service Initiation

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151849558/Bulk+and+Batch+Payments#Authorization

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:

• User payment Account Identification details (for bulk payments only) 

• Requested Execution date (for bulk payments and for batch only if it applies to all payments in the batch and if not already part of consent)

• LFIs should be able to introduce a step after authentication to display additional /supplementary information in relation to the bulk/batch payment instructions such as expected execution date, specific terms related to this payment type etc.”

Bank Service Initiation

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

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850555/Customer+Data#6.-Permissions-and-Data-Clusters

Create BBP-7.3 (https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151849558/Bulk+and+Batch+Payments#Payment-Status-Update)

“LFIs MUST:
7.3 Provide individual transaction details within bulk or batch payments through the transaction API. The LFI must ensure that individual transactions are fully itemized and visible to the TPP.”

Bank Service Initiation

https://openfinanceuae.atlassian.net/wiki/x/GwwNCQ

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850011/Payments+with+Delegated+Authentication#5.-Payment-Control-at-TPP

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.

1. Retailer-Based Control:

• Control: Payments from any other retailer outside the approved list would either be blocked or flagged for additional authorization.

• Purpose: This limits recurring transactions to trusted retailers where the customer has given consent, reducing the risk of unauthorized transactions.

2. Action-Based Control:

• Control: Only specific types of actions are allowed to trigger payments automatically. If an unusual action occurs, it could require extra authorization or approval from the customer.

• Purpose: This ensures that only expected actions trigger payments, protecting customers from unexpected or erroneous charges.

3. Context-Based Control:

• Control: The TPP might approve payments automatically if they occur during the gym’s normal business hours or within an expected geographic region. However, if a transaction request comes at 3 AM or from a different city, the TPP could flag the transaction for further review or customer confirmation.

• Purpose: This control uses the context in which the payment occurs (time, location, frequency) to detect potentially suspicious or fraudulent transactions, ensuring payments are made only when expected.

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:

• A description of the actions that will automatically trigger payments.

• A list of scenarios where additional authorization will be required (e.g., higher-than-normal charges or unusual service fees).

• The security benefits of these controls, specifically how they help protect the customer from unauthorized or erroneous charges.

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

Common Rules and Guidelines

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850813/Common+Rules+and+Guidelines#1.-Supported-Accounts-%26-Payment-Rails

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

• Parental Control: For children under 16, parents or guardians act as the legal representative and must provide consent on behalf of the child. The child cannot independently grant access to TPPs for Open Finance services. Parents maintain control over which third-party apps or services can access their child’s account data, ensuring that only trusted services are connected.

1.1.2 Data and Security

• Parents control whether data from their child’s bank account is shared via Open Finance APIs. They can revoke access at any time to protect their child’s privacy. Given that children may not fully understand the implications of sharing their financial data, parents play a critical role in vetting third-party providers and ensuring that their child’s data is secure and used responsibly.

1.1.3 Age-Appropriate Services

• Parents can choose which services are connected to their child’s account, ensuring they align with age-appropriate spending and financial management. For example, parents may opt to connect budgeting apps, but not payment initiation services. This control ensures that children under 16 are not exposed to inappropriate financial services, like loans or investments, which could misuse their personal data or negatively impact their financial education.

1.1.4 Access Restrictions

• Parents can restrict third-party access to only certain types of data (e.g., viewing balances without allowing payments). They can also monitor the data shared and revoke access if they suspect misuse. This layered control protects children from unauthorized access to their accounts or malicious third-party services, ensuring they can benefit from Open Finance features like financial insights without compromising security.

1.1.5 Payment Initiation

• For children under 16, parents are responsible for authorizing any payment initiation through Open Finance connected services. Most children’s accounts do not allow for overdrafts or credit facilities, and this restriction is crucial to Open Finance services that may otherwise allow payments or transfers. Payment services through Open Finance need to ensure that any transactions on a child’s account are fully authorized by the parent. Parents can deny access to TPPs that offer payment services, limiting a child’s ability to spend money through third-party apps.”

Common Components

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

Additional elements required from TPP to facilitate Billing for Data Sharing

AEAccountAccessAuthorizationDetailConsentProperties updated to include OpenFinanceBilling object.
This object has two mandatory fields - UserType and Purpose

        UserType:
          description: Type of User
          enum:

• Retail

• Corporate

        Purpose:
          description: Purpose of data sharing request
          type: string
          enum:

• AccountAggregation

• RiskAssessment

• TaxFiling

• Onboarding

• Verification

• QuoteComparison

• BudgetingAnalysis

• FinancialAdvice

• AuditReconciliation

Common Components

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

Additional elements required from TPP to facilitate Billing for Data Sharing

Purpose field has been moved into the OpenFinanceBilling object

Common Components

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

version and servers - incorrectly updated in errata2

version and servers in OpenAPI document reverted back to v1.0 for consistency with rest of specification

Common Components

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

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"

Common Components

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

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"

Common Components

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

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"

Common Components

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

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"

Common Components

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

Additional elements required from TPP to facilitate Billing for Insurance

OBInsuranceAuthorizationDetailConsentProperties updated to include OpenFinanceBilling object.
This object has one mandatory fields - Purpose

        Purpose:
          description: Purpose of data sharing request
          type: string
          enum:

• AccountAggregation

• RiskAssessment

• PremiumHistory

• ClaimHistory

• Onboarding

• Verification

• QuoteComparison

• FinancialAdvice

Bank Data Sharing

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

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)

Bank Data Sharing

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

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:

• IBAN

• AccountNumber

• MaskedPAN

• MobileNumber

• UtilityName

• EWallet

Bank Service Initiation

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

Additional elements required from TPP to facilitate Billing for Payments

New object in the AEPaymentConsentResponse with one optional field specified by the LFI (IsLargeCorporate)

Bank Service Initiation

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

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

• Collection

• LargeValueCollection

• PushP2P

• PullP2P

• Me2Me

          description: The type payment for billing
        MerchantId:
          description: "MerchantId"
          type: "string"
          minLength: 8
          maxLength: 20

Bank Service Initiation

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

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

Common Components

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

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)

Bank Service Initiation

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

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

Common Components

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151847164/User+Experience+Principles#11.-Other-Rules-for-User-Journeys

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:

• LFIs and TPPs MUST NOT make use of multi-press buttons whereby a User is required to press a button more than once for the same intended action

• LFIs and TPPs MUST NOT create friction in the form of additional requests for confirmations

• The User MUST go through an MFA with the LFI only once before they authorize the consent. There should be no additional authentication required.

Common Components

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

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” 
However this should be “authorization_details_types” with detail on plural.

Common Components

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151847383/TPP+Consent+Management+Interfaces#2.-TPP-Consent-Management-Interfaces-(CMIs)-examples

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

Common Components

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151847606/LFI+Consent+Management+Interfaces#2.-LFI-Consent-Management-Interface-(CMI)-Examples

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:

• “LFIs MUST display the TPPs' trading name/brand name to Users. They MAY also display the registered company name of TPPs, if it is different.

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

Common Components

https://openfinanceuae.atlassian.net/wiki/x/jgQNCQ

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

Bank Data Sharing

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

The account statuses did not match the regulations for Inactive, Dormant, and Unclaimed provided by CBUAE.

AEAccountStatusCode has been changed as follows:

• NotActive has been moved to Inactive and now references the CBUAE guidance on inactive status.

• Dormant now references the CBUAE guidance on dormant account status.

• Unclaimed now references the CBUAE guidance on unclaimed account status.

• Suspended has been clarified with more description to improve understanding.

Common Components

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

Controls have been added that set expectations on the integrity of the mobile device.

The following are added to the Controls section:

• TPPs must safeguard against installation of their apps on jailbroken devices and prohibiting initiating redirects for Authentication and Authorization when installed on a jailbroken device.

  • Provides opportunities for activities by miscreants that comprise data sharing or service initiation.

• TPPs must not allow installation or usage of their apps from within sanctioned countries, including but not limited to initiating redirects for Authentication and Authorization.

  • Ensures the integrity of data sharing and service initiation operations by prohibiting activity in sanctioned countries.

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

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

Insurance OpenAPI

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