TPPs MUST:

Enable Users to provide the parameters related to the IP payment order they want to initiate. These parameters include:

• User Payment Account & Currency or User LFI (as per International Payments | 4.1 User Payment Account & Currency SelectionPreview)

• Payment Amount & Currency (as per International Payments | 4.2 Payment Amount & CurrencyPreview)

• Creditor Identification details (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv2dot0final/pages/361958357/International+Payments#4.3-Creditor-Identification-for-International-Payments)

• Debtor Reference (as per Common Rules and Guidelines | 5. Debtor ReferencePreview) (Optional)

• Creditor Reference (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv2dot0final/pages/361961620/Common+Rules+and+Guidelines#6.-Creditor-Reference)

International-FX & International Payments Only

• External Payment Purpose Code (as per International Payments | 4.7 External Purpose CodePreview)

• Payment Order Priority (as per International Payments | 4.4 Payment Order Priority for International PaymentsPreview)

• Payment Charge Model (as per International Payments | 4.5 Payment Charge Model for International PaymentsPreview)

Basic Consent Parameters

TPPs MUST:

2.1 Enable Users to review the parameters related to the IP they need to consent to. These parameters include:

• User Payment Account & Currency or User LFI

• Payment Amount & Currency

• Creditor Identification details

• Debtor Reference (Optional)

• Creditor Reference

International-FX & International Payments Only

• External Payment Purpose Code

• Payment Order Priority

• Payment Charges model

Additional Consent Parameters

TPPs MUST:

2.2 Set/clear the ‘Is Single Authorization’ flag as appropriate (as per Common Rules and Guidelines | 7. Is Single Authorization flag).

2.3 Set the Authorization Expiration Date Time (as per Common Rules and Guidelines | 8. Authorization Expiration DateTimePreview) if there are specific timing requirements that must be met for the consent authorization. This is also relevant to cases where multiple authorizers are required to authorize the payment consent (Please refer to Common Rules and Guidelines | 18. Multi User Authorization FlowPreview).

2.4 Set the Risk Information Block (as per Common Rules and Guidelines | 9. Risk Information BlockPreview)

TPPs MUST:

2.5 Enable Users to provide explicit consent for the initiation of a single IP payment order from their online payment account held at their LFI as per the payment details specified in the payment Consent.

As per Common Rules and Guidelines | 10. Consent StagingPreview

As per Common Rules and Guidelines | 11. Hand off to LFIPreview

Example wording to use: ‘We will securely transfer to YOUR LFI to authorize and make the payment“.

LFI Authentication Only

LFIs MUST:

5.1 Enable Users to perform authentication with their LFIs, as per the following sections:

• Authentication by LFI | 2. RedirectionPreview

• Authentication by LFI | 3. Decoupled RedirectionPreview

5.2 Re-direct Users back to the TPPs, with information that the Consent has not been authorized, if User Authentication has failed or Users opted to cancel the authentication/authorization process.

Centralized Authentication and Authorization (Federated) Only

5.3 As per Centralized Authentication and AuthorizationPreview

LFIs MUST:

6.1 Enable Users to authenticate using Multi-Factor Authentication (MFA) in order to review and authorize the single IP Consent.

6.2 Retrieve from the OFP the single IP Consent details staged by the TPP and present relevant details to Users.

6.3 Allow Users to select a payment account for the initiation of the single IP, if this was not provided in the retrieved staged payment Consent details, as per Common Rules and Guidelines | 12. Payment Account Selection at LFIPreview

• 6.3.1 NOT allow Users to select a payment account from their list of available payment accounts that has insufficient funds for the single IP initiation. This only applies in case Users do not select their payment account when providing their Consent to TPPs.

• 6.3.2 Reject the single IP initiation, if the payment account identification was part of the single IP payment Consent provided to the TPPs and the payment account has insufficient funds to cover the payment amount and any related charges, if applicable. The OFP MUST be notified about this rejection with an appropriate error message.

• 6.3.3 NOT allow Users to select a payment account from their list of available payment accounts that is of currency different than the payment account currency selected during the payment Consent at the TPP.

6.4 Verify that the authorization status of the chosen payment account aligns with the TPPs' Is Single Authorization flag as per Common Rules and Guidelines | 7. Is Single Authorization flag.

International-FX Only

6.5 Use the reference information provided in the IP Consent to identify the User's preferred forward FX rate agreement (e.g. future contract) related to User's account profile with the LFI, if this was included in the IP Consent.

6.6 Provide to the User the details of any forward FX rate agreement (e.g. future contract) they have in place in relation to the selected payment account and use this for the currency conversion required for the transaction.

6.7 Display to the User the details related to the Forward FX rate agreement, if applicable

• 6..7.1 Display all Forward FX rate agreements and allow Users to select the preferred one to use, in case there are multiple Forward FX rate agreements related to the Users' account profiles.

6.8 Provide the same actual (deal) FX rate and charges as it would be offered to the User via the LFIs' other channels such as mobile or online banking, if the User has no FX agreement with the LFI.

6.9 Display to Users the TPP Trading Name of the TPP that initiated the single IP Consent.

• 6.9.1 If there are customer-facing service providers (e.g. Merchants) who are not TPPs but have commercial relationships with TPPs, the LFIs MUST display the customer-facing service provider name along with the TPP trading name.

6.10 Present to Users the following minimum required information for authorizing the single IP payment Consent:

• User Payment Account & Currency

• Payment Amount & Currency

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

• FX rate for the transaction (for International-FX Payments)

• Time remaining for the FX rate to be valid (for International-FX Payments), if applicable (optional)

• Creditor Identification details including:

  • Destination Country (for International Payments)

  • Creditor Account Identification (IBAN, alias if specified, other local account format)

  • Creditor Account Holding Entity/Routing Identification (BIC/SWIFT Code, NCC, ABA Routing etc.) (for International Payments)

  • Creditor Account Name

  • Creditor Account Address (for International Payments)

  • Creditor Account Holding LFI Name

  • Creditor Account Holding LFI Address (for International Payments)

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

• Fees (if applicable): These are the charges that may be applied to the User account for making the payment in relation to the single IP payment Consent. If applicable, MUST be presented and stated prior to the User Consent authorization.

6.11 Refresh the Actual FX Rate if the remaining time has expired (if applicable)

6.12 Request Users to authorize the single IP payment Consent, so that a single IP payment can be initiated.

6.13 Provide Users the ability to cancel the payment journey, if Users decided to terminate the request. The LFI MUST hand-off the Users back to the TPP, providing the necessary error message to the OFP and reject the single IP payment Consent.

6.14 Change the state of the single IP payment Consent from Awaiting Authorization to Authorized, when all Authorizers (one or more) have authorized the payment Consent.

6.15 Update the single IP payment Consent details stored in the OFP.

OFP MUST:

6.16 Check the Authorization Time Window is valid as per Common Rules and Guidelines | 19. Check Authorization Time WindowPreview.

6.17 Confirm back to the LFIs that the single IP payment Consent details have been updated successfully.

Multi-Authorization Journey Only

6.18 As per International Payments | 4.6 Multi User Authorization for IP PaymentsPreview

As per Common Rules and Guidelines | 14. Hand off back to the TPPPreview

TPPs MUST:

8.1 Submit to OFP the IP payment initiation requests with the same parameters as per the IP Payment Consents authorized by Users.

8.2 Submit to OFP the IP payment initiation request immediately after they receive the IP Payment Consent authorization confirmation. This is required in the case that there is FX conversion related to the International Payment AND the FX rate included in the IP Payment Consent was the actual rate (i.e. deal rate) and not indicative rate or a fixed rate related to a future contract agreement. The IP payment initiation request MUST be received by the LFI within the Limits and Constants | Actual FX Rate SLAPreview.

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.

OFP MUST:

8.3 Allow the TPPs to submit the individual payment initiation requests under the Payment Consents authorized by Users, without any additional MFA or authorization from Users.

8.4 Check that the received payment initiation request relates to a valid IP Payment Consent authorized by the User. The Consent MUST be in the Authorized state. The OFP MUST reject an IP payment initiation message related to an IP Payment Consent in a different state and respond back to the TPP with the appropriate error message/code.

8.5 Check the payment initiation request parameters against the authorized IP Payment Consent. All parameters MUST match exactly.

• 8.5.1 Reject the payment initiation and provide the necessary error message to the TPP if any checks of the payment initiation request parameters fails against the Consent parameters of the authorized IP Payment Consent.

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)

8.7 Submit to the LFI the IP payment initiation request immediately after they receive the IP Payment request from the TPP. This is required in the case that there is FX conversion related to the International Payment AND the FX rate included in the IP Payment Consent was the actual rate (i.e. deal rate) and not indicative rate or a fixed rate related to a future contract agreement. The IP payment initiation request MUST be received by the LFI within the Limits and Constants | Actual FX Rate SLAPreview.

Note: In cases where the IP Payment request has not been received within the Limits and Constants | Actual FX Rate SLAPreview and the FX in the authorized IP Consent was not related to a future contract rate, the LFI is expected to use a different FX rate for the transaction. This rate will be provided back to the TPP in the IP Payment response message. This scenario can also occur in the exceptional circumstances of the IP Consent authorization being provided to the LFI just at the point of the FX deal cut-off time. This is more prominent to occur in cases where the LFI is not using the CLS system. Similarly, the same scenario can occur in situations where the IP Consent was authorized at the cut-off time of the underlying payment system causing the payment to be executed in the next available window on the following date with a different value date.

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.

8.9 Additionally apply all existing BAU payment account controls and limits such as single transaction value limit, total transaction value limit, AML checking (if applicable) and others, as if the payment request has been initiated by the existing channels of the LFI. LFIs MUST send an appropriate error response to the OFP in case the payment is rejected due to violating any of these limits.

8.10 Reject the payment initiation if the payment account selected for the payment has insufficient funds. The OFP MUST be notified about this rejection with an appropriate error message.

8.11 Subject to successful BAU checking, validation and payment processing, proceed with the execution of the payment by submitting the payment to the underlying payment rails.

8.12 Provide the OFP with all the available information in relation to the initiated payment instruction including the payment’s unique identifier Payment Transaction ID.

OFP MUST:

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

8.14 Send to the TPP the appropriate error message in case the payment initiation was rejected by the LFI due to insufficient funds in the selected payment account.

8.15 Provide the TPP with all the available information in relation to the initiated single IP instruction including the payment’s unique identifier Payment Transaction ID.

As per Common Rules and Guidelines | 15. Payment Status UpdatePreview

As per Common Rules and Guidelines | 14. Hand off back to the TPPPreview

As per Common Rules and Guidelines | 16. Confirmation to UserPreview

As per Common Rules and Guidelines | 17. Payment NotificationsPreview

TPPs MUST:

1.1 Enable Users to provide the parameters related to the Fixed Recurring IP payment order they want to initiate. These parameters include:

• User Payment Account & Currency or User LFI (as per International Payments | 4.1 User Payment Account & Currency SelectionPreview)

• Creditor Identification details (as per Common Rules and Guidelines | 4. Creditor IdentificationPreview)

• Debtor Reference (as per Common Rules and Guidelines | 5. Debtor ReferencePreview) (Optional)

• Consent Reference (as per Multi-Payments | 6.1 Consent ReferencePreview)

International-FX & International Payments Only

• External Payment Purpose Code (as per International Payments | 4.7 External Purpose CodePreview)

• Payment Order Priority (as per International Payments | 4.4 Payment Order Priority for International PaymentsPreview)

• Payment Charge Model (as per International Payments | 4.5 Payment Charge Model for International PaymentsPreview)

Fixed Recurring IP Payment (IP-FRPs) Consent

• Payment Amount & Currency (as per International Payments | 4.2 Payment Amount & CurrencyPreview)

• Periodic Payment Schedule (as per Multi-Payments | 6.2.1 Periodic Payment SchedulePreview)

• Consent Expiration Date & Time (as per Multi-Payments | 6.4.1 Consent Expiration for FRPs (Fixed Recurring Consent)Preview)

Basic Consent Parameters

TPPs MUST:

2.1 Enable Users to review the parameters related to the IP they need to consent to. These parameters include:

• User Payment Account & Currency or User LFI

• Payment Amount & Currency

• Creditor Identification details

• Debtor Reference (Optional)

• Consent Reference

International-FX & International Payments Only

• External Payment Purpose Code

• Payment Order Priority

• Payment Charges model

Additional Consent Parameters

2.2 Set/clear the ‘Is Single Authorization’ flag as appropriate (as per Common Rules and Guidelines | 7. Is Single Authorization flag).

2.3 Set the Authorization Expiration Date Time (as per Common Rules and Guidelines | 8. Authorization Expiration DateTimePreview) if there are specific timing requirements that must be met for the consent authorization. This is also relevant to cases where multiple authorizers are required to authorize the payment consent.

• 2.3.1 The Authorization Expiration Date Time MUST be less than the time of the first payment in the Periodic Payment Schedule.

2.4 Set the Risk Information Block (as per Common Rules and Guidelines | 9. Risk Information BlockPreview)

2.5 Enable Users to provide explicit consent for the initiation of a series of Future Recurring IP payments of fixed amounts based on a fixed periodic schedule from their online payment account held at their LFI as per the payment parameters specified in the consent.

As per Common Rules and Guidelines | 10. Consent StagingPreview

As per Common Rules and Guidelines | 11. Hand off to LFIPreview

Example wording to use: ‘We will securely transfer to YOUR LFI to authenticate and authorize your payments setup“.

LFI Authentication Only

LFIs MUST:

5.1 Enable Users to perform authentication with their LFIs, as per the following sections:

• Authentication by LFI | 2. RedirectionPreview

• Authentication by LFI | 3. Decoupled RedirectionPreview

5.2 Re-direct Users back to the TPPs, with information that the Consent has not been authorized, if User Authentication has failed or Users opted to cancel the authentication/authorization process.

Centralized Authentication and Authorization (Federated) Only

5.3 As per Centralized Authentication and AuthorizationPreview

LFIs MUST:

6.1 Enable Users to authenticate using Multi-Factor Authentication (MFA) in order to review and authorize the long-lived Fixed Recurring IP Consent.

6.2 Retrieve from the OFP the payment Consent details staged by the TPP using the unique Consent Identifier.

6.3 Allow Users to select a payment account for the initiation of the Fixed Recurring IP payments, if this was not provided in the retrieved staged payment Consent details, as per Common Rules and Guidelines | 12. Payment Account Selection at LFIPreview

• 6.3.1 Allow Users to select a payment account for the initiation of the Fixed Recurring IP even if it has insufficient funds at the time of the payment Consent authorization. This allows Users to fund the payment accounts appropriately before the dates of the payment initiation. However, the LFIs MUST inform the User, if the selected payment account has insufficient funds.

• 6.3.2 NOT allow Users to select a payment account from their list of available payment accounts that is of currency different than the payment account currency selected during the payment Consent at the TPP.

6.4 NOT earmark (i.e. block) any funds related to the payment Consent in the Users' payment account at the point of Consent authorization.

6.5 Verify that the authorization status of the chosen payment account aligns with the TPPs' “Is Single Authorization” flag as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv2dot0final/pages/361961620/Common+Rules+and+Guidelines#13.-Check-Is-Single-Authorization-flag.