...
Section | Subsection | Description | Action | |
|---|---|---|---|---|
| 1 | Bank Service Initiation | 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 | Common Components | The standard prior to The Pushed Authorization Request (PAR) OpenAPI description has been updated to include the The open finance framework implementation of this parameter allows a TPP to send the Emirates ID or Trade License Number, as appropriate, using an encrypted JSON Web Token (JSON Web Encryption - JWE). The mechanics of creating the The steps for creating and processing the JWE are as follows:
Please note that the use of | TPPs and LFIs should follow the described mechanism to implement using the | |
| 3 | Common Components | Several arguments of the JWT-Secured Authorization Request (JAR) implemented in the PAR Endpoint have been updated to offer more extensive document. | TPPs should review the | |
| 4 | Common Components | All Customer Experience sections currently provide branded screens without stipulation of whether these are illustrative or prescriptive. | A new rule is added as follows: “LFIs and TPPs MUST implement their customer experience screens in line with what is provided in each Customer Experience section of the Standard for the relevant functionality. This includes colours, branding, spacing and component design.” | |
| 5 | Bank Service Initiation | Rule CRG-2.1 states the following:
Further clarification is required to be added about how TPPs will be presenting the LFIs to Users for easier identification. | Rule CRG-2.1 is modified as follows:
| |
| 6 | Bank Service Initiation | The rules SIP-7 in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848434/Single+Instant+Payments#3.1.2-Rules-%26-Guidelines do not define the maximum time between the payment Consent being authorized and the Single Instant Payment request being initiated by the TPP. | SIP-7 rule 7.1 is modified to add a new rule as follows: “TPPs MUST: 7.1 Submit to OFP the payment initiation requests with the same parameters as per the Payment Consent authorized by the User.
| |
| 7 | Limits and Constants | The Limits table does not include an entry for the Max SIP Payment Initiation Time Interval. | A new entry A15 is added to the table as follows: ID: A15Name: Max SIP Payment Initiation Time IntervalDescription: This is the period of time that TPPs MUST submit the Sinhgle Instant Payment Initiation Request to the OFP. The value defined for this is period is currently 5 sec. The OFP will reject the Payment Initiation Request is submitted outside this time window. | |
| 8 | Bank Service Initiation | The rules BBP-6 in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151849558/Bulk+and+Batch+Payments#3.1-Rules-%26-Guidelines do not define the maximum time between the Bulk/Batch payment Consent being authorized and the Bulk/Batch Payment request being initiated by the TPP. | BBP-6 rule 6.1 is modified to add a new rule as follows: “TPPs MUST: 6.1 Submit to OFP the Bulk/Batch payment initiation requests with the same parameters as per the Bulk or Batch Payment (BBP) Consent authorized by the User(s).
| |
| 9 | Limits and Constants | The Limits table does not include an entry for the Max Bulk/Batch Payment Initiation Time Interval. | A new entry A16 is added to the table as follows: ID: A16Name: Max Bulk/Batch Payment Initiation Time IntervalDescription: This is the period of time that TPPs MUST submit the Bulk/Batch Payment Initiation Request to the OFP. The value defined for this is period is currently 15 sec. The OFP will reject the Payment Initiation Request is submitted outside this time window. | |
| 10 | Bank Service Initiation | The rules FDP-5 in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848769/Future+Dated+Payments#3.2-Rules-%26-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-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).
| |
| 11 | Limits and Constants | The Limits table does not include an entry for the Max FDP Payment Initiation Time Interval. | A new entry A17 is added to the table as follows: ID: A17Name: Max FDP Payment Initiation Time IntervalDescription: This is the period of time that TPPs MUST submit the FDP Payment Initiation Request to the OFP. The value defined for this is period is currently 15 sec. The OFP will reject the Payment Initiation Request is submitted outside this time window. | |
| 12 | Bank Service Initiation | Rule 2.9 of MPPI-2 in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848909/Multi-Payments#5.-Payment-Initiation states the following: “2.9 Increment the cumulative Total Number and the cumulative Total Value of payments under the VRP Consent after the payment successfully executed and received payment status confirmation from the creditor LFI. The initial value of these parameters should be zero for each authorized VRP Consent.” The OFP at this stage is not able to know whether the payment has been successfully executed and the LFI has received payment status confirmation from the creditor LFI. This is because this check is happening before the OFP has forwarded the Payment Initiation request to the LFI and thus the payment has not been initiated yet. | Rule 2.9 of MPPI-2 in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848909/Multi-Payments#5.-Payment-Initiation is modified as follows: “2.9 Increment the cumulative Total Number and the cumulative Total Value of payments under the VRP Consent after the payment resource has been created and it is in ‘Pending’ status and has not been rejected. This will prevent multiple payments being initated that could exceed the Maximum values of the respective Consent Control papameters. The initial value of the cumulative Total Number and the cumulative Total Value of payments should be zero for each authorized VRP Consent.” | |
| 13 | Bank Service Initiation | Rule 2.10 of MPPI-2 in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848909/Multi-Payments#5.-Payment-Initiation states the following: “2.10 Increment the cumulative Total Number and the cumulative Total Value of all payment initiations per Control Period after the payment successfully executed and received payment status confirmation from the creditor Bank. These parameters are reset to zero when a new Consent Control Period starts at 00:00:00 of the first day of the Control Period.” The OFP at this stage is not able to know whether the payment has been successfully executed and the LFI has received payment status confirmation from the creditor LFI. This is because this check is happening before the OFP has forwarded the Payment Initiation request to the LFI and thus the payment has not been initiated yet. | Rule 2.10 of MPPI-2 in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848909/Multi-Payments#5.-Payment-Initiation is modified as follows: “2.10 Increment the cumulative Total Number and the cumulative Total Value of all payment initiations per Control Period after the payment resource has been created and it is in ‘Pending’ status and has not been rejected. This will prevent multiple payments being initated that could exceed the Maximum values of the respective Consent Control papameters. The cumulative Total Number and the cumulative Total Value of all payment initiations per Control Period are reset to zero when a new Consent Control Period starts at 00:00:00 of the first day of the Control Period.” | |
| 14 | Bank Service Initiation | Rule 2.14 of MPPI-2 in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848909/Multi-Payments#5.-Payment-Initiation states the following: “2.14 Reject the payment initiation and provide the necessary error message to the TPP if any other checks of the payment initiation request parameters fails against Consent parameters of the authorized long-lived Payment Consent.” The OFP at this stage is able to decrement the relevant VRP cummulative counters, but this rule is missing from this step. | MPPI-2 rule 2.14 is modified to add a new rule as follows: “2.14 Reject the payment initiation and provide the necessary error message to the TPP if any other checks of the payment initiation request parameters fails against Consent parameters of the authorized long-lived Payment Consent.”
| |
| 15 | Bank Service Initiation | Rule 2.22 of MPPI-2 in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151848909/Multi-Payments#5.-Payment-Initiation states the following: “2.22 Send an appropriate error response to the TPPs in case the payment is rejected due to violating any of the LFIs BAU payment accounts checks or limits.” The OFP at this stage is able to decrement the relevant VRP cummulative counters, but this rule is missing from this step. | MPPI-2 rule 2.22 is modified to add a new rule as follows: “2.22 Send an appropriate error response to the TPPs in case the payment is rejected due to violating any of the LFIs BAU payment accounts checks or limits.”
| |
| 16 | Common Rules and Guidelines | 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:
| |
| 17 | Common Rules and Guidelines | 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”. | |
| 18 | Bank Service Initiation | 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.” | |
| 19 | Data Sharing OpenAPI Document | Purpose is now mandatory in the Consent response - updated Purpose to have a minItem of 1 | TPPs should review the updated PAR Endpoint OpenAPI description. | |
| 1920 | Service Initiation OpenAPI Document | PaymentTransactionId is now optional - but with additional definition to say “The PaymentTransactionId must be populated if the payment is processed by the LFI.” | TPPs should review the updated PAR Endpoint OpenAPI description. | |
| 2021 | Pushed Authorization Request OpenAPI Document | The following changes have been made to the PAR Endpoint OpenAPI description.
| TPPs should review the updated PAR Endpoint OpenAPI description. |
...