1 What’s changed?
- 1.1 Business rules updates
- 1.2 “1.1 Accounts for minors
- 1.3 Technical Specifications

What’s changed?

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

Business rules updates

	Errata version	Section	Subsection	Impacts	Description	Action

	Errata version	Section	Subsection	Impacts	Description	Action
1	2	Bank Service Initiation	Single Instant Payments	LFIs TPPs	The Open Finance Standards do not offer a prototype of a Single Instant Payment flow.	A prototype illustrating an example of a Single Instant Payment flow has been created. TPPs and LFIs should use this prototype in conjunction with the prescribed customer experience screens.
2	2	Common Components	User Experience Principles \| 11. Other Rules for User Journeys	LFIs TPPs	All Customer Experience sections currently provide branded screens without stipulation of whether these are illustrative or prescriptive.	A new rule is added as follows: “LFIs and TPPs MUST implement their customer experience screens in line with what is provided in each Customer Experience section of the Standard for the relevant functionality. This includes colors, branding, spacing and component design.”
3	2	Bank Service Initiation	Common Rules and Guidelines \| 2. User Payment Account Selection	TPPs	Rule CRG-2.1 states the following: “Select their LFI only (so that they can select their Payment Account later on in the journey after authenticating with the LFI). The LFI MUST be identified using the trading name which is familiar to Users.” Further clarification is required to be added about how TPPs will be presenting the LFIs to Users for easier identification.	Rule CRG-2.1 is modified as follows: “Select their LFI only (so that they can select their Payment Account later on in the journey after authenticating with the LFI). The LFI MUST be identified using the trading name which is familiar to Users.” CRG-2.1.1 TPPs MUST* use logos and the brand names of the LFIs as they are defined in the Trust Framework Directory.”*
4	2	Bank Service Initiation	Single Instant Payments \| Payment Initiation	TPPs	The rules SIP-7 in Single Instant Payments \| 3.1.2 Rules & Guidelines do not define the maximum time between the payment Consent being authorized and the Single Instant Payment request being initiated by the TPP.	SIP-7 rule 7.1 is modified to add a new rule as follows: “TPPs MUST: 7.1 Submit to OFP the payment initiation requests with the same parameters as per the Payment Consent authorized by the User. 7.1.1 Submit to OFP the SIP payment initiation request immediately after they receive the SIP Payment Consent authorization confirmation. The SIP payment initiation request MUST be received by the OFP within the Max SIP Payment Initiation Time Interval as defined in Limits and Constants \| A. Limits.”
5	2	Limits and Constants	Limits and Constants \| A. Limits	TPPs	The Limits table does not include an entry for the Max SIP Payment Initiation Time Interval.	A new entry A15 is added to the table as follows: ID: A15 Name: Max SIP Payment Initiation Time Interval Description: This is the period of time that TPPs MUST submit the Single Instant Payment Initiation Request to the OFP. The value defined for this is period is currently 5 sec. The OFP will reject the Payment Initiation Request is submitted outside this time window.
6	2	Bank Service Initiation	Bulk and Batch Payments \| Payment Initiation	TPPs	The rules BBP-6 in Bulk and Batch Payments \| 3.1 Rules & Guidelines do not define the maximum time between the Bulk/Batch payment Consent being authorized and the Bulk/Batch Payment request being initiated by the TPP.	BBP-6 rule 6.1 is modified to add a new rule as follows: “TPPs MUST: 6.1 Submit to OFP the Bulk/Batch payment initiation requests with the same parameters as per the Bulk or Batch Payment (BBP) Consent authorized by the User(s). 6.1.1 Submit to OFP the Bulk/Batch payment initiation request immediately after they receive the Bulk/Batch Payment Consent authorization confirmation. The Bulk/Batch payment initiation request MUST be received by the OFP within the Max Bulk/Batch Payment Initiation Time Interval as defined in Limits and Constants \| A. Limits.”
7	2	Limits and Constants	Limits and Constants \| A. Limits	TPPs	The Limits table does not include an entry for the Max Bulk/Batch Payment Initiation Time Interval.	A new entry A16 is added to the table as follows: ID: A16 Name: Max Bulk/Batch Payment Initiation Time Interval Description: This is the period of time that TPPs MUST submit the Bulk/Batch Payment Initiation Request to the OFP. The value defined for this is period is currently 15 sec. The OFP will reject the Payment Initiation Request is submitted outside this time window.
8	2	Bank Service Initiation	Future Dated Payments \| Authorization	TPPs	The rules FDP-5 in Future Dated Payments \| 3.2 Rules & Guidelinesdo not define the requirement for TPPs to submit the FDP Payment Initiation request to the OFP and the LFI so that the FDP payment initiation can take place and the FDP can be warehoused in the LFI’s systems. Also, there is no rule to define the maximum time between the FDP payment Consent being authorized and the FDP Payment request being initiated by the TPP.	FDP-5 is modified to add a new rule as follows: “TPPs MUST: 5.15 Submit to OFP the FDP payment initiation requests with the same parameters as per the FDP Payment Consent authorized by the User(s). 5.15.1 Submit to OFP the FDP payment initiation request immediately after they receive the FDP Payment Consent authorization confirmation. The FDP payment initiation request MUST be received by the OFP within the Max FDP Payment Initiation Time Interval as defined in Limits and Constants \| A. Limits.”
9	2	Limits and Constants	Limits and Constants \| A. Limits	TPPs	The Limits table does not include an entry for the Max FDP Payment Initiation Time Interval.	A new entry A17 is added to the table as follows: ID: A17 Name: Max FDP Payment Initiation Time Interval Description: This is the period of time that TPPs MUST submit the FDP Payment Initiation Request to the OFP. The value defined for this is period is currently 15 sec. The OFP will reject the Payment Initiation Request is submitted outside this time window.
10	2	Bank Service Initiation	Multi-Payments \| Processing of Payment Initiation Requests	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	Multi-Payments \| Processing of Payment Initiation Requests	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	Multi-Payments \| Processing of Payment Initiation Requests	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.” 2.14.1 In this case: For all payments related to a VRP Consent, the OFP MUST decrement: the cumulative Total Number of payments by 1 and, the cumulative Total Value of payments by the value of the payment For all payments related to a VRP Consent where a Control Period is set, the OFP MUST decrement: the cumulative Total Number of payments per Control Period and, the cumulative Total Value of payments per Control Period.”
13	2	Bank Service Initiation	Multi-Payments \| Processing of Payment Initiation Requests	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.” 2.22.1 In this case: For all payments related to a VRP Consent, the OFP MUST decrement: the cumulative Total Number of payments by 1 and, the cumulative Total Value of payments by the value of the payment For all payments related to a VRP Consent where a Control Period is set, the OFP MUST decrement: the cumulative Total Number of payments per Control Period and, the cumulative Total Value of payments per Control Period.”
14	2	Common Rules and Guidelines	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850813/Common+Rules+and+Guidelines#15.-Payment-Status-Update	OFP	A new rule is required so that when OFP receives updates on the Payment status of a payment, updates the relevant VRP Consent Control Parameters as appropriate.	A new rule is added as follows: “OFP MUST: CRG-15.4.1 Check if the status of the payment has been set to ‘Rejected. In this case: For all payments related to a VRP Consent, the OFP MUST decrement: the cumulative Total Number of payments by 1 and, the cumulative Total Value of payments by the value of the payment For all payments related to a VRP Consent where a Control Period is set, the OFP MUST decrement: the cumulative Total Number of payments per Control Period and, the cumulative Total Value of payments per Control Period.”
15	2	Common Rules and Guidelines	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850813/Common+Rules+and+Guidelines#15.-Payment-Status-Update	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	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848909/Multi-Payments#Authorization	OFP	Within rules 5.12 the Check Authorization Time Window is referenced incorrectly.	Rule 5.12 in MPCS-5 is modified as follows: “5.12 Check the Authorization Time Window is valid as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850813/Common+Rules+and+Guidelines#19.-Check-Authorization-Time-Window.”
17	3	Authentication and Authorization	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151847970/Authentication+by+LFI#2.-Redirection	LFIs	The business rules for App-to-Browser and Browser-to-Browser journeys do not currently permit an LFI to provide a redirect to their mobile banking app to continue the authentication journey. This will cause friction for customers who are enrolled only in an LFIs mobile banking app and do not have internet banking credentials.	Sections 2.3 (Browser-to-Browser) and Section 2.4 (App-to-Browser) are modified as follows: The following alternative experience MUST be implemented by LFIs to allow customers to use their mobile banking app to complete Authentication and Authorization: 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. 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. 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. 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. The LFI MUST provide the means for the User to abandon handoff to a mobile device and instead choose to complete Authentication and Authorization using the LFI web channel, where supported.
18	3	Bank Service Initiation	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848434/Single+Instant+Payments#Authorization	LFIs	Rule 5.6 of SIP-5 in Single Instant Payments \| 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”
19	3	Bank Service Initiation	Single Instant Payments \| Payment 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: Authorized Payment Consent Identifier Payment Amount & Currency Debtor Reference (if provided) Creditor Reference Purpose of Payment”
20	3	Bank Service Initiation	Single Instant Payments \| Payment 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. 7.6.1 Retrieve the Creditor Identification details from the encrypted PII information block included in the original Payment Consent message. 7.6.2 Apply all existing BAU check and validation processes in relation to the Creditor Identification details. In case of failure. LFIs MUST reject the payment initiation request and notify the OFP about this rejection with an appropriate error message.”
21	3	Bank Service Initiation	Future Dated Payments \| Authorization	LFIs	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”
22	3	Bank Service Initiation	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848769/Future+Dated+Payments#Hand-off-back-to-the-TPP	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	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848769/Future+Dated+Payments#FDP-Warehousing-%26-Scheduling	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). 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.”
24	3	Bank Service Initiation	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848769/Future+Dated+Payments#FDP-Warehousing-%26-Scheduling	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.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”
25	3	Bank Service Initiation	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848769/Future+Dated+Payments#FDP-Warehousing-%26-Scheduling	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. 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.”
26	3	Bank Service Initiation	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848909/Multi-Payments#Authorization	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: 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”
27	3	Bank Service Initiation	Multi-Payments \| Processing of Payment Initiation Requests	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:* 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.”
28	3	Bank Service Initiation	Multi-Payments \| Processing of Payment Initiation Requests	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	Multi-Payments \| Processing of Payment Initiation Requests	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: 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.”
30	3	Bank Service Initiation	Multi-Payments \| Processing of Payment Initiation Requests	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 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.”
31	3	Bank Service Initiation	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151849156/International+Payments#Payment-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	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151849156/International+Payments#Payment-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: 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)”
33	3	Bank Service Initiation	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151849156/International+Payments#Payment-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. 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.”
34	3	Bank Service Initiation	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151849156/International+Payments#3.2.5-Payment-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:* 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.”
35	3	Bank Service Initiation	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151849156/International+Payments#Processing-of-Payment-Initiation-Requests	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: 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)”
36	3	Bank Service Initiation	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151849156/International+Payments#3.2.5-Payment-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. 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
37	3	Bank Service Initiation	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850011/Payments+with+Delegated+Authentication#Authorization	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: User Payment Account Consent Reference Currency Consent Expiration Date & Time”
38	3	Bank Service Initiation	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850011/Payments+with+Delegated+Authentication#Processing-of-Payment-Initiation-Requests	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:* 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)”
39	3	Bank Service Initiation	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850011/Payments+with+Delegated+Authentication#Processing-of-Payment-Initiation-Requests	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: Authorized Payment Consent Identifier Payment Amount & Currency Creditor Identification details (encrypted) Debtor Reference (If provided) Creditor Reference”
40	3	Bank Service Initiation	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850011/Payments+with+Delegated+Authentication#Processing-of-Payment-Initiation-Requests	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.” 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.
41	3	Bank Service Initiation	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151849745/Confirmation+of+Payee#COP-Service	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. 3.7.1 In this case, LFIs MUST* return no data in their response message back to the OFP.”*
42	3	Bank Data Sharing	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850555/Customer+Data#3.-Customer-Experience	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	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850555/Customer+Data#3.-Customer-Experience	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	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850555/Customer+Data#3.-Customer-Experience	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.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.”
45	3	Bank Data Sharing	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850555/Customer+Data#3.-Customer-Experience	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 Variations 3.2.1 User selects account at the TPP & LFI provides Supplementary Information
46	3	Banking	https://openfinanceuae.atlassian.net/wiki/x/kQ8NCQ	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: 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.”
47	3	Bank Data Sharing	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850555/Customer+Data#Data-Sharing-Consent	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 Limits and Constants \| A. Limits.”
48	3	Bank Service Initiation	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850813	TPPs	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).”
49	3	Common Components	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151847205	TPPs	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.
50	3	Bank Service Initiation	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151849558/Bulk+and+Batch+Payments#Authorization	LFIs	Rule 5.6 of BBP-5 in Bulk and Batch Payments \| 3.1 Rules & 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.”
51	3	Bank Service Initiation	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151849558	LFIs	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.”
52	3	Bank Service Initiation	https://openfinanceuae.atlassian.net/wiki/x/GwwNCQ	TPPs	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. 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. 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. 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.”
53	3	Common Rules and Guidelines	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850813/Common+Rules+and+Guidelines#1.-Supported-Accounts-%26-Payment-Rails	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 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.”
54	3	Common Components	User Experience Principles \| 11. Other Rules for User Journeys	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.	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.*
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” However this should be “authorization_details_types” with detail on plural.
56	3	Common Components	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151847383/TPP+Consent+Management+Interfaces#2.-TPP-Consent-Management-Interfaces-(CMIs)-examples	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	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151847606/LFI+Consent+Management+Interfaces#2.-LFI-Consent-Management-Interface-(CMI)-Examples	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: “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.”*
58	3	Common Components	https://openfinanceuae.atlassian.net/wiki/x/jgQNCQ	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: 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.
60	4	Banking	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850211/Pay+Request+enabled+by+Open+Finance#Proceed-with-Payment-Initiation-using-Long-lived-Consent	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: Proceed with the 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.”
61	4	Banking	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848909/Multi-Payments#8.2.2-Period-Type-%26-Start-Date	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: Start Date: The date that the first repeating Period starts. It is defined at the start of the date at midnight (00:00:00). Period Type: This MUST be one of the following: Day: A continuous period of time, consisting of 24 consecutive hours, staring from midnight (00:00:00) and finishing at 23:59:59 of the same day. The Period will be repeating every day from the Start Date. For example, if the Start Date is the 10th of the month, then the Period will be repeating on the 11th, 12th, 13th etc. Week: A continuous period of time, consisting of seven consecutive days, staring from midnight (00:00:00) of the Start Date and finishing at 23:59:59 of the 7th day elapsed from the Start Date. The Period will be repeating at the same day every week from the Start Date. For example, if the Start Date is the Thursday 10th October 2024, then the Period will be repeating on Thursday the 17th October 2024, Thursday the 24th October 2024, Thursday the 31st October 2024, Thursday the 7th November 2024 etc. Month: A continuous period of time starting from midnight (00:00:00) of the Start Date and finishing at 23:59:59 of the day before the same date of the next month. The Period will be be repeating at the same date every month from the Start Date. For example, if the Start Date is the 10th October 2024, then the Period will be repeating on the 10th November 2024, the 10th December 2024, the 10th January 2025 etc. The exceptions to this rule are the following: if Start Date is a date not available every month, then the Period will be adjusted to the end date of the month which does not have the Start Date available. For example: If Start Date is 31st, then the Period will be initiated on the 31st for January, March, May, July, August, October and December, on the 30th for April, June, September and November and on the 28th or 29th (depending on leap year) for February. If Start Date is 30th, then the Period will be initiated on the 30th for all months apart from February, for which it will be the 28th or 29th (depending on leap year) for February If Start Date is 29th, then the Period will be initiated on the 29th for all months on leap year or for all months expect February on leap year, for which it will be the 29th Year: A continuous period of time, consisting of 12 months, starting from midnight (00:00:00) of the Start Date and finishing at 23:59:59 of the day before the same date of the next year. The Period will be be repeating at the same date every year from the Start Date. For example, if the Start Date is the 10th October 2024, then the Period will be repeating on the 10th October 2025, the 10th October 2026 etc. The exceptions to this rule are the following: if Start Date is a date not available every year, then the Period will be adjusted to the end date of the month which does not have the Start Date available: For example: If Start Date is 29th of February on a leap year, then the Period will be initiated on the 28th of February on non-leap years and the 29th on leap years.”
62	4	Banking	Multi-Payments \| Processing of Payment Initiation Requests	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:* 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) MUST match exactly one of the dates defined by the Periodic Payment Schedule (for Fixed Recurring and Variable Recurring Payments) or the dates included in the Predefined Payment Schedule for the Variable-defined Multi-Payments. 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.”
63	4	Limits and Constants	Limits and Constants \| A. Limits	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: A15 Name: Max SIP Payment Initiation Time Interval Description: This is the period of time that TPPs MUST submit the Single Instant Payment Initiation Request to the OFP. The value defined for this is period is currently 10min. The OFP will reject the Payment Initiation Request is submitted outside this time window.
64	4	Limits and Constants	Limits and Constants \| A. Limits	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: A16 Name: Max Bulk/Batch Payment Initiation Time Interval Description: This is the period of time that TPPs MUST submit the Bulk/Batch Payment Initiation Request to the OFP. The value defined for this is period is currently 10min. The OFP will reject the Payment Initiation Request is submitted outside this time window.
65	4	Limits and Constants	Limits and Constants \| A. Limits	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: A17 Name: Max FDP Payment Initiation Time Interval Description: This is the period of time that TPPs MUST submit the FDP Payment Initiation Request to the OFP. The value defined for this is period is currently 10min. The OFP will reject the Payment Initiation Request is submitted outside this time window.
66	4	Common Components	User Experience Principles \| 11. Other Rules for User Journeys	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	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151849156/International+Payments#3.2-Long-lived-International-Payment-Consents	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: Fixed Payment Amount: This can either be in account currency or payment currency, if FX is involved in the payment Recurring Schedule: Fixed periodic payment schedule as defined in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848909/Multi-Payments#8.2.1-Periodic-Payment-Schedule Initiated from a User’s payment account held by the LFI in local or foreign currency To a specific Creditor (Beneficiary) owning a payment account located abroad (cross-border)”
68	4	Banking	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151849156/International+Payments#4.5-Payment-Charge-Model-for-International-Payments	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: “SHA” or “Shared”: The sender User of the payment will pay fees to the sending LFI for the outgoing transfer charges. The receiving beneficiary will receive the amount transferred, minus the correspondent (intermediary) LFI charges. Thus, transaction charges on the receiver side are borne by the creditor by deducting these from the received amount. This value maps to the ISO 200022 code name “SHAR”. “OUR” or “Borne By Debtor”: All fees will be charged to the sender User of the payment – i.e. the receiving beneficiary gets the full amount sent by the sender of the payment. Any charges applied by the receiving LFI will be billed to the sender of the payment (usually sometime after sending the payment). This value maps to the ISO 200022 code name “DEBT”. “BEN” or “Borne By Creditor”: BEN (beneficiary) means that the sender User of the payments does not pay any charges. The receiver beneficiary of the payment receives the payment minus all transfer charges, including the sending LFI charges if any. This value maps to the ISO 200022 code name “CRED”.
69	4	Banking	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151849156/International+Payments#4.7-External-Purpose-Code	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	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850813/Common+Rules+and+Guidelines#1.-Supported-Accounts-%26-Payment-Rails	LFIs	Rule CRG-1.4.2 of https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850813/Common+Rules+and+Guidelines#1.-Supported-Accounts-%26-Payment-Rails 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.” The rule will not change to require LFIs to reject the payments if IPP is unavailable.	Rule CRG-1.4.2 has been updated as follows: “LFIs MUST: CRG-1.4.2 In the scenario that IPP is unavailable, for example, it is going through maintenance and planned downtime, the LFIs MUST reject the payment and set the status of the payment to the Rejected terminal state.”
71	4	Banking	https://openfinanceuae.atlassian.net/wiki/x/zQcNCQ	TPPs	Throughout the https://openfinanceuae.atlassian.net/wiki/x/zQcNCQreferences 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 https://openfinanceuae.atlassian.net/wiki/x/zQcNCQ page has been updated as follows: All references to Variable-defined have been replaced with Fixed-defined. A new consent type definition was introduced called Variable-defined. This was added to all the required places in the page. A new variation entry was introduced https://openfinanceuae.atlassian.net/wiki/spaces/standardsv2draft1/pages/244222022/Multi-Payments#3.3.5-Variable-Recurring-Payments-(VRPs)---Variable-defined-Consent
72	4	Banking	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850555/Customer+Data#3.-Customer-Experience	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	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151847606	LFIs	Several inconsistencies and errors in the wireframes related to the LFI Consent Management Interfaces.	Updated all wireframes in all sections of the https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151847606 page.
74	4	Payments with Delegated Authentication	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv2draft1/pages/244223133/Payments+with+Delegated+Authentication#1.4.2-Multi-factor-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	https://openfinanceuae.atlassian.net/wiki/x/BYyQD	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	https://openfinanceuae.atlassian.net/wiki/x/BYyQD	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	https://openfinanceuae.atlassian.net/wiki/x/BYyQD	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	https://openfinanceuae.atlassian.net/wiki/x/BYyQD	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	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv2draft1/pages/244223957/Common+Rules+and+Guidelines#9.3-Additional-TPP-Obligations	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. When a user is known to the TPP, the Emirates ID can be captured during onboarding. When a user is unknown to the TPP, the Emirates ID can be captured prior to the consent customer journey. Note: TPPs are not required to verify the Emirates ID.”
80	4	Banking	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv2draft1/pages/244223957/Common+Rules+and+Guidelines#9.1-TPP-Obligations	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	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv2draft1/pages/244222274/International+Payments#3.-Customer-Experience	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. 8.3.1 Impose the limit for a duration of 48 hours This limit must apply to the sum of multiple payments within the 48 hour period 8.3.2 Revert to the channel limit thereafter.”
82	4	Banking	https://openfinanceuae.atlassian.net/wiki/x/HIyQD	TPPs	Enhancement of the authentication method required for payments with Delegated SCA.	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv2draft1/pages/244223133/Payments+with+Delegated+Authentication#1.4-Prerequisites-for-Payments-with-Delegated-Authentication 1.4.1 The authentication methods are limited to the following: User biometrics on a mobile device: such as fingerprint or facial recognition executed on the customer’s device, where a TPP app is also bound Dynamic tokens on a mobile device: generated by authenticator apps (e.g., Authy, Google Authenticator, Microsoft Authenticator) on the customer’s device, where a TPP app is also bound NFC-based trigger on a mobile device: used as a possession factor through Near Field Communication for secure, contactless verification, on the customer’s device, where a TPP app is bound and logged in NFC based trigger on another IoT device: The device holds credentials that can be used to verify the User identity, provisioned in conjunction with a TPP service. The device MUST have a biometric capability, a means to securely store a private key that is uniquely linked to the User, and can only be activated on presentment of a supported biometric gesture linked to the device.
83	4	Common Components	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv2draft1/pages/244223957/Common+Rules+and+Guidelines#1.-Supported-Accounts-%26-Payment-Rails	TPP & LFIs	Provide clarifications to ensure that channels and use cases are mutually supportive.	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv2draft1/pages/244223957/Common+Rules+and+Guidelines#1.-Supported-Accounts-%26-Payment-Rails The inclusion of CRG-1.6, CRG-1.7 & CRG-1.8.

Technical Specifications

	Errata version	Section	Subsection	Impacts	Description	Action

	Errata version	Section	Subsection	Impacts	Description	Action
1	1	Common Components	Pushed Authorization Request Endpoint OpenAPI	Updated in `errata4`	The `PeriodSchedule` shows all 3 schedule types - `DefinedSchedule`, `FixedPeriodicchedule` and `VariablePeriodicSchedule` as being as mandatory instead of `oneof`	Implementers should follow the specification as per `uae-bank-initiation-openapi.yaml`.
2	1	Common Components	Pushed Authorization Request Endpoint OpenAPI	Updated in `errata4`	The optional `Type` string field within the `VariablePeriodicSchedule` object (`MultiPayment`) is no longer applicable and should have been removed.	Implementers should follow the specification as per `uae-bank-initiation-openapi.yaml`.
3	1	Common Components	Pushed Authorization Request Endpoint OpenAPI	Updated in `errata4`	The `MultiPayment` object shows the `Amount` object as being as mandatory instead of optional.	Implementers should follow the specification as per `uae-bank-initiation-openapi.yaml`.
4	1	Common Components	Pushed Authorization Request Endpoint OpenAPI	Updated in `errata4`	The `MultiPayment` object shows the `MaximumIndividualPaymentAmount` object as being as mandatory instead of optional.	Implementers should follow the specification as per `uae-bank-initiation-openapi.yaml`.
5	1	Common Components	Pushed Authorization Request Endpoint OpenAPI	TPPs	The `Subscription` object and the `Webhook` object are shown as being as mandatory instead of optional.	Implementers should follow the specification as per `uae-bank-initiation-openapi.yaml`.
6	1	Common Components	Pushed Authorization Request Endpoint OpenAPI	LFIs TPPs	The enumerations listed within the `AccountSubType` parameter reflect the legacy list of account sub types instead of `CurrentAccount` and `Savings`	Implementers should follow the specification as per `uae-bank-initiation-openapi.yaml`.
7	1	Common Components	Pushed Authorization Request Endpoint OpenAPI	LFIs TPPs	Within the `FilePayment` object, the `RequestedExecutionDateTime` parameter should have been renamed to `RequestedExecutionDate`	Implementers should follow the specification as per `uae-bank-initiation-openapi.yaml`.
8	2	Common Components	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848264	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 `login_hint` parameter, which is an OpenID Connect parameter that allows a Relying Party to send an indicator (“hint”) of the End User. The open finance framework implementation of this parameter allows a TPP to send the Emirates ID or Trade License Number, as appropriate, using an encrypted JSON Web Token (JSON Web Encryption - JWE). The mechanics of creating the `login_hint` parameter value are described in the PAR OpenAPI description. The steps for creating and processing the JWE are as follows: The TPP shall: Implement support for providing the Emirates ID or Trade License Number based on customer and use cases requirements. Create the payload based on the details found in the PAR OpenAPI description. Discover the JWKS endpoint for the LFI that holds the Customer account, to which the request will be directed. Retrieve the public encryption key for the LFI. Encrypt the payload as a JWE using the public encryption key for the LFI, and include indicators such as `kid` that will allow the LFI to correlate the corresponding private key. Set the `login_hint` parameter to the value of the JWE. Send the PAR to the LFI endpoint at the API Hub. The OFP shall: Pass the value of the `login_hint` parameter to the LFI at the Ozone Connect Validate and/or Augment operation, depending on their configuration. The LFI shall: Based on their implementation, select the private encryption key that matches the public key used by the TPP. Decrypt the value of the `login_hint` parameter and deserialise the payload value. Use the Emirates ID or Trade License Number as required in the processing of the Validate or Augment operation. Please note that the use of `login_hint` is optional and is intended to provide for enhanced customer experiences based on foresight of the customer identity. It is not a replacement for Authentication and Authorization. TPPs and LFIs should follow the described mechanism to implement using the `login_hint` parameter to send either the Emirates ID or Trade License Number with a Pushed Authorization Request.
9	2	Common Components	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848264	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 `description` values provided in the PAR Endpoint OpenAPI description.
10	2	Bank Data Sharing	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850759	Updated in `errata3`	The `Purpose` property in the Consent response was incorrectly labelled as optional	`Purpose` is now mandatory in the Consent response, with the `minItems` property set to 1 to indicate the array must not be empty.
11	2	Bank Service Initiation	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850435	LFIs TPPs	`PaymentTransactionId` was incorrectly labelled as mandatory, but could not be populated until a valid payment reference had been created at the payment rails on which the payment instruction was transmitted.	`PaymentTransactionId` is now optional, with additional description that states: “The PaymentTransactionId must be populated if the payment is processed by the LFI.”
12	2	Common Components	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848264	Updated in `errata3`	The `Purpose` property of the `AEAccountAccessAuthorizationDetailConsentProperties` Schema Object was incorrectly defined as optional.	`Purpose` is now mandatory, with the `minItems` property set to 1 to indicate the array must not be empty.
13	2	Common Components	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848264	TPPs	The `Subscription` property of all consent request Schema Object was labelled as mandatory. This was incorrectly defined as TPPs do not have to implement Event Notifications over Webhooks.	`Subscription` updated to be optional.
14	2	Common Components	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848264	LFIs TPPs	`AEAccountSubTypeCode` does not match the enumeration values found in the Data Sharing OpenAPI description.	`AEAccountSubTypeCode` updated to only `CurrentAccount` and `Savings`.
15	2	Common Components	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848264	Updated in `errata4`	`AEServiceInitiationDefinedSchedule` does not match the Bank Service Initiation OpenAPI description as `maxItems` should be set to 50.	The `Schedule` array of the `AEServiceInitiationDefinedSchedule` has been amended with the `maxItems` property set to 50.
16	2	Common Components	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848264	LFIs TPPs	`RequestedExecutionDateTime` does not match the Bank Service Initiation OpenAPI description as the property has been renamed `RequestedExecutionDate` with the `format` property set to `date`.	The Schema Object `AERequestedExecutionDateTime` has been renamed `AERequestedExecutionDate` and the `format` value set to `date`.
17	2	Common Components	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848264	Updated in `errata4`	`AEServiceInitiationLongLivedPaymentConsent` does not match the Bank Service Initiation OpenAPI description as `Amount`, `MaximumIndividualPaymentAmount`, and `PeriodicSchedule` are set to mandatory.	The Schema Object `AEServiceInitiationLongLivedPaymentConsent` has been updated to remove mandatory fields.
18	2	Common Components	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848264	Updated in `errata4`	`AEServiceInitiationLongLivedPaymentConsentPeriodicSchedule` does not match the Bank Service Initiation OpenAPI description as it implements named properties rather than a `oneOf`.	`AEServiceInitiationLongLivedPaymentConsentPeriodicSchedule` has been updated to implement a `oneOf`.
19	2	Common Components	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848264	Updated in `errata4`	`AEServiceInitiationVariablePeriodicSchedule` does not match the Bank Service Initiation OpenAPI description as `MaximumCumulativeValueOfPaymentsPerPeriodType` and `MaximumCumulativeNumberOfPaymentsPerPeriodType` are labelled as mandatory.	`AEServiceInitiationVariablePeriodicSchedule` has been updated to make `MaximumCumulativeValueOfPaymentsPerPeriodType` and `MaximumCumulativeNumberOfPaymentsPerPeriodType` optional.
20	2	Common Components	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848264	LFIs TPPs	The `Amount` and `Currency`Schema Objects are not consistent with the same Schema Object in the Bank Service Initiation OpenAPI description.	`Amount` Schema Object renamed to `AEActiveOrHistoricAmount` and properties updated to match Bank Service Initiation definition. `CurrencyCode` renamed to `AEActiveOrHistoricCurrencyCode` and updated to match Bank Service Initiation definition.
21	3	Common Components	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848264	LFIs TPPs	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
22	3	Common Components	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848264	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	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848264	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	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848264	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	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848264	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	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848264	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	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848264	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	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848264	LFIs TPPs	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
29	3	Bank Data Sharing	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850759	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	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850759	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: IBAN AccountNumber MaskedPAN MobileNumber UtilityName EWallet
31	3	Bank Service Initiation	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850435	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	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850435	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: enum: Collection LargeValueCollection PushP2P PullP2P Me2Me description: The type payment for billing MerchantId: description: "MerchantId" type: "string" minLength: 8 maxLength: 20
33	3	Bank Service Initiation	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850435	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	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848264	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	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848264	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	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850759	LFIs TPPs	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.
37	4	Common Components	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848264	TPPs	Business Rules state that consent cannot be more than a year	`ExpirationDateTime` updated to mandatory in: `AEAccountAccessAuthorizationDetailConsentProperties` `AEServiceInitiationAuthorizationDetailProperties` `OBInsuranceAuthorizationDetailConsentProperties`
38	4	Common Components	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848264	TPPs	Reconsent objects removed from standard, as this is not part of the existing Business Rules	`RichAuthorizationRequestObjects` have Reconsent objects removed
39	4	Bank Service Initiation	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848264 https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850435	TPPs	`ReadRefundAccount` field has been simplified to be an option in the `Permissions` array	`ReadRefundAccount` field has been simplified to be an option in the `Permissions` array
40	4	Bank Service Initiation	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848264 https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850435	TPPs	The TPP is no longer expected to send in the `ExpectedInitiationWindow`, based on updated Business Rules	Removed `ExpectedInitiationWindow`
41	4	Bank Service Initiation	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848264 https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850435	TPPs	`IsPayByAccount` flag is not in the Business Rules	Removed `IsPayByAccount` flag
42	4	Bank Service Initiation	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848264 https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850435	TPPs LFIs (very minimal impact to LFIs - as it is purely a different way of identifying existing functionality)	For explicitness have added `IsDelegatedAuthentication` to indicate a TPP Delegated SCA model - for more explicit schema validation and non-repudiation	Added `IsDelegatedAuthentication` boolean flag
43	4	Bank Service Initiation	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848264 https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850435	TPPs LFIs (very minimal impact to LFIs - as it is purely a different way of identifying existing functionality)	`DefinedSchedule` to be better aligned with Business Rules	To simplify implementation and better align with Business Rules we have created a: `FixedDefinedSchedule` `VariableDefinedSchedule` These are both arrays of up to 53 items. The `FixedDefinedSchedule` is a pair of `PaymentExecutionDate` and `Amount` The `VariableDefinedSchedule` is a pair of `PaymentExecutionDate` and `MaximumIndividualAmount`
44	4	Bank Service Initiation	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848264 https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850435	TPPs LFIs (very minimal impact to LFIs - as it is purely a different way of identifying existing functionality)	`FixedPeriodicSchedule` and `VariablePeriodicSchedule` to be better aligned with Business Rules - to have payments initiated on dates that are on the `PeriodStartDate` + the subsequent `PeriodType`	Both `FixedPeriodicSchedule` and `VariablePeriodicSchedule` to have mandatory fields only. `VariablePeriodicSchedule` updated to have as mandatory only: `Type` `PeriodType` `PeriodStartDate` `MaximumIndividualAmount`
45	4	Bank Service Initiation	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848264 https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850435	TPPs LFIs (very minimal impact to LFIs - as it is purely a different way of identifying existing functionality)	New object to reflect `FixedOnDemand` payment type - which better reflect Business Rules	`FixedOnDemand` to have mandatory: `Type` `PeriodType` `PeriodStartDate` `Amount` `Controls` Where `Controls` is an object with at least one of the following properties specified: `MaximumCumulativeValueOfPaymentsPerPeriod` `MaximumCumulativeNumberOfPaymentsPerPeriod`
46	4	Bank Service Initiation	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848264 https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850435	TPPs LFIs (very minimal impact to LFIs - as it is purely a different way of identifying existing functionality))	New object to reflect `VariableOnDemand` payment type - which better reflect Business Rules	`VariableOnDemand` to have mandatory: `Type` `PeriodType` `PeriodStartDate` `Controls` Where `Controls` is an object with at least one of the following properties specified: `MaximumIndividualAmount` `MaximumCumulativeValueOfPaymentsPerPeriod` `MaximumCumulativeNumberOfPaymentsPerPeriod`
47	4	Bank Service Initiation	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848264 https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850435	TPPs LFIs (very minimal impact to LFIs - as it is purely a different way of identifying existing functionality)	Issues with `MultiPayment` consent top level: Duplication of `MaximumIndividualPaymentAmount`and `Amount` `PeriodicSchedule` is optional and should be mandatory to enforce payment type selection	Removed duplication of `MaximumIndividualPaymentAmount` and `Amount` at the `MultiPayment` consent top level Updated `PeriodicSchedule` to mandatory
48	4	Bank Service Initiation	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850435	LFIs TPPs	Errata for `PaymentConsumption` object as errata: `CumulativeValueOfPaymentsPerPeriod` is not always relevant for a Long Lived Payment Consent - however, is marked as mandatory `CumulativeNumberOfPaymentsPerCurrentPeriod`suggests that this is the same value for all period - however, the intent is that this is only for the current period `CumulativeValueOfPaymentsPerCurrentPeriod`suggests that this is the same value for all period - however, the intent is that this is only for the current period `CumulativeNumberOfPaymentsPerCurrentPeriod` and `CumulativeValueOfPaymentsPerCurrentPeriod` are intended to include all payments except for payments in a `Rejected` state	Updates: `CumulativeValueOfPaymentsPerPeriod` updated from mandatory to optional `CumulativeNumberOfPaymentsPerCurrentPeriod` renamed to `CumulativeNumberOfPaymentsInCurrentPeriod`suggests `CumulativeValueOfPaymentsPerCurrentPeriod`renamed to `CumulativeValueOfPaymentsInCurrentPeriod` `CumulativeValueOfPaymentsPerCurrentPeriod`, and `CumulativeValueOfPaymentsInCurrentPeriod` definitions updated to “The cumulative value of payment instructions in the current period initiated under the consent schedule, excluding instructions in a Rejected state.“
49	4	Bank Service Initiation	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850435	TPPs	`PersonalIdentifiableInformation` object is now optional for the `POST /payments` action - as these details may be derived in most cases from the consent (after changes in `v1.0-errata3`)	`PersonalIdentifiableInformation` is optional in `POST /payments` request
50	4	Bank Service Initiation	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850435	TPPs	`ChargeBearer` for International Payments does not need the `FollowingServiceLevel` option	Updated `ChargeBearer` to only `- "BorneByCreditor" - "BorneByDebtor" - "Shared"`
51	4	Bank Data Sharing	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850759	LFIs	`PartyType` and `AccountRole` describe customer to account relationship - so are not relevant for the `/parties` endpoint	Removed `PartyType` and `AccountRole` from the `GET /parties` endpoint response
52	4	Common Components	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848264	LFIs TPPs	OpenAPI description did not convey the decoded version of the property, making it difficult for implementers to understand.	PII types (Payment, `login_hint`) now implement a `oneOf` to allow both the encoded and decoded property structure to be understood.
53	4	Insurance	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151851051	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 `/motor-insurance-policies`.
54	4	Bank Service Initiation	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848264 https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850435	TPPs	The `CreditorAgent` does not have the option to select the BIC	Extended the enumeration to the `CreditorAgent.SchemeName` to include `BICFI` Removed restriction to `CreditorAgent.Identification` of maxLength 6
55	4	Bank Service Initiation	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848264 https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850435	TPPs	The `PaymentSequenceNumber` is legacy and there are no TPP or LFI Business Rules relating to its use	Removed `PaymentSequenceNumber`
56	4	Bank Service Initiation	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848264 https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850435	TPPs	`DebtorReference` implements two Schema Objects with `oneOf`, each with a `pattern` property, which caused problems for tooling.	Merged two Schema Objects into one, with one `pattern` property supporting both Schema Objects from previous version.
57	4	Bank Service Initiation	https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848264 https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850435	TPPs	Enhancements requested for the `Risk` object - as a result of Delegated Authentication requirements.	Updates to the `Risk` object in the `PersonalIdentifiableInformation` object

Standards v2.0-draft1

Release Notes

What’s changed?

Business rules updates

ID: A15

Name: Max SIP Payment Initiation Time Interval

ID: A16

Name: Max Bulk/Batch Payment Initiation Time Interval

ID: A17

Name: Max FDP Payment Initiation Time Interval

3.2 Journey Variations

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

“ID: A13

Name: End Date of historical data for Data Sharing Request

“1.1 Accounts for minors

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

ID: A15

Name: Max SIP Payment Initiation Time Interval

ID: A16

Name: Max Bulk/Batch Payment Initiation Time Interval

ID: A17

Name: Max FDP Payment Initiation Time Interval

1.4.1 The authentication methods are limited to the following:

Technical Specifications

Related content