Versions Compared

Version Old Version 2 New Version 3
Changes made by

Manish Haldankar (Deactivated)

Alexandros Dimitrakoudis

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Expand
titleMENU
Table of Contents
stylenone

...

Consent Type

Relevant Use Cases

Consent Parameters Type

Payment Amount

Payment Schedule

Typical Usage Examples

Long-lived

Fixed Recurring Payments (FRPs)

Fixed Recurring

Fixed (known)

Fixed (known)

  • P2P standing orders

  • P2M monthly subscription

  • Installment payments

  • BNPL

Variable Recurring Payments (VRPs)

Fixed On-demand

Fixed (known)

Variable (unknown)

Account top-up

Variable Recurring Payments (VRPs)

Variable Recurring

Variable (unknown)

Fixed (known)

P2M utility payments

Variable Recurring Payments (VRPs)

Variable On-demand

Variable (unknown)

Variable (unknown)

  • Account Sweeping

  • Cab booking App

Variable Recurring Payments (VRPs)

Variable-defined

Variable (Known)

Fixed (known - predefined list of dates)

  • Installment payments (payment plan)

  • Project completion-based payments

Combined Payments (Recurring Payments with a One-Time Setup)

Combined

Known and Fixed or Variable

 Instant and Fixed or Variable

  • Instalments with a different initial payment (payemnt plan with downpayment)

  • Two P2M payments (instant & future)

1.2 Payer and Payee Segments

...

The factors used by TPPs MUST be in alignment with the list of required evidence that will be listed in the liability model.

1.6 Balance Check Permission

The long-lived Multi-Payments Consent can be extended to include optional permission for Balance Check which allows the TPP to check the balance of the User’s Payment account before initiating a payment as part of a long-lived Multi-Payments Consent.

This capability allows the TPP

  • check the balance in advance of payment to be initiated as part of the Multi-Payments Consent consent and ask the user to take remedial action if the funds are insufficient.

  • display the balance to the user at the point of initiating a payment.

2. User Journey

...

3. Wireframes

...

3.1. Consent Setup

...

#

...

Step

...

Rules & Guidelines

...

MPCS-1

...

Multi-Payments Consent

...

Basic Consent Parameters

TPPs MUST:

1.1 Enable Users to provide and review the parameters related to the initiation of a series of Multi-Payments they need to consent to. These parameters include:

Note: Depending on the use case the Payee details may not be displayed to the User in full. However, these need to be part of the payment request sent by the TPP to the LFI.

Fixed Recurring Payments (FRPs) Consent

...

1.7 Combined Payments (Recurring Payments with a One-Time Setup)

TPPs MUST be able to support use cases where Users need to make an initial payment and then require the ability to make further payments on a recurring basis as part of a single Consent request.

A single request can include the consent for a SIP combined with the consent for FRPs or VRPs, which can be authorized by the User with the LFI in a single authentication/authorization flow. The User (Consumer or Business) makes one initial payment and authorizes further recurring payments of a fixed or variable amount with a fixed or variable schedule to a business or a personal beneficiary.

This functionality requires a Long-lived Consent. The consent parameter type for this functionality is Combined Payment Consent, which is a long-lived consent that MUST be used for a combination of a single instant payment and a series of future payments of fixed or variable amounts occurring at fixed or variable schedule.

1.7.1 Example User Story

Panel
panelIconIdfc1ec21b-3d40-498b-93f8-df20afd1c4cf
panelIcon:asffd:
panelIconText:asffd:
bgColor#E6FCFF

User Story

As a User (Consumer or Business),

I want to provide my consent to a TPP to use my payment account for initiating both:

  • a Single Instant or Future Dated Payment of a fixed amount and;

  • a sequence of future recurring payments of fixed or variable amounts with a fixed or variable schedule to a domestic beneficiary account owned by a business or an individual,

so that I can pay an instant downpayment and allow the remaining future payments of my payment plan to the relevant beneficiary.

2. User Journey

...

3. Wireframes

...

3.1. Consent Setup

#

Step

Rules & Guidelines

Balance Check

TPPs MUST:

1.1 be able to request the balance information using the authorized Multi-payment Consent before initiating the payment.

1.2 use this capability only in relation to the Payment initiation step to follow.

1.3 not use this capability as an alternative for Account Information Service,for example, to satisfy use cases like Personal finance manager where the account balance is being refreshed periodically.

1.4 make this request not earlier than 24 hours from when a scheduled payment will be initiated.

LFIs MUST:

2.1 Provide the OFP with the the information related to the balance of the User's account which was used for authorizing the Multi Payment consent. This information must be the same information as defined under the Balances in

#

Step

Rules & Guidelines

MPCS-1

Multi-Payments Consent

Basic Consent Parameters

TPPs MUST:

1.1 Enable Users to provide and review the parameters related to the initiation of a series of Multi-Payments they need to consent to. These parameters include:

Recurring Payments (VRPs) - Fixed On-demand Consent

Note: Depending on the use case the Payee details may not be displayed to the User in full. However, these need to be part of the payment request sent by the TPP to the LFI.

Variable Recurring Payments (VRPs) - Variable Recurring Consent

Fixed Recurring Payments (FRPs) Consent

Variable Recurring Payments (VRPs) - Fixed On-demand Consent

Variable Recurring Payments (VRPs) - Variable On-demand Consent

Variable Recurring Payments (VRPs) - Variable -defined Recurring Consent

1.2 Set the Accepted Authorization Type

Additional Consent Parameters

70092902/Common+Rules+and+Guidelines#7.-Accepted-Authorization-Type).1.3 Set the Authorization Time Window

Variable Recurring Payments (VRPs) - Variable On-demand Consent

70092902/Common+Rules+and+Guidelines#8.-Authorization-Time-Window) 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.

  • 1.3.1 For Fixed Recurring Consent and Variable Recurring Consent, the Authorization Time Window MUST be less than the time of the first payment in the Periodic Payment Schedule.

  • 1.3.2 For Variable-defined Consent, the Authorization Time Window MUST be less than the time of the first payment in the Variable-defined Payments Schedule.

1.4 Set the Risk Information Block 70092902/Common+Rules+and+Guidelines#9.-Risk-Information-Block)

1.5 Enable Users to provide explicit consent for the initiation of a series of future Multi-Payments of fixed or variable amounts based on a fixed periodic schedule or a variable schedule from their online payment account held at their LFI as per the payment parameters specified in the consent.

Balance Check Permission

1.6 Optionally request permission to check the balance of the payment account before initiating a payment.

MPCS-2

Consent Staging

As 70092902/Common+Rules+and+Guidelines#10.-Consent-Staging

MPCS-3

Hand-off to LFI

As

Variable Recurring Payments (VRPs) - Variable-defined Consent

70092902/Common+Rules+and+Guidelines#11.-Hand-off-to-LFI

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

MPCS-4

Authentication

LFI Authentication Only

As per the following sections:

Additional Consent Parameters

1.2 Set the Accepted Authorization Type (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/

70091622

70092902/

Authentication

Common+Rules+

by

and+

LFI#3

Guidelines#7.-Accepted-

Decoupled

Authorization-

Redirection

Centralized Authentication and Authorization (Federated) Only

As Type).

1.3 Set the Authorization Time Window (as per https://openfinanceuae.atlassian.net/wiki/x/HoBBAw

MPCS-5

Confirmation/ Authorization

LFIs MUST:

5.1 Enable Users to authenticate using Multi-Factor Authentication (MFA) in order to review and authorize the long-lived payment Consent.

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

5.3 Allow Users to select a payment account for the initiation of the multi-payments, if this was not provided in the retrieved staged Payment Consent details spaces/standardsv1draft3/pages/70092902/Common+Rules+and+Guidelines#8.-Authorization-Time-Window) 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.

  • 1.3.1 For Fixed Recurring Consent and Variable Recurring Consent, the Authorization Time Window MUST be less than the time of the first payment in the Periodic Payment Schedule.

  • 1.3.2 For Variable-defined Consent, the Authorization Time Window MUST be less than the time of the first payment in the Variable-defined Payments Schedule.

1.4 Set the Risk Information Block (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70092902/Common+Rules+and+Guidelines#12Guidelines#9.-PaymentRisk-Account-Selection-at-LFI

  • 5.3.1 Allow Users to select a payment account for the initiation of the multi-payments 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.

5.4 Only present additional screens, if necessary to allow the validation and confirmation of the payment Consent (e.g., Beneficiary adding & activation and Proxy lookup).

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

5.6 Check the authorization status of the selected payment account is in accordance with the TPPs' Accepted Authorization Type as Information-Block)

1.5 Enable Users to provide explicit consent for the initiation of a series of future Multi-Payments of fixed or variable amounts based on a fixed periodic schedule or a variable schedule from their online payment account held at their LFI as per the payment parameters specified in the consent.

Balance Check Permission

1.6 Optionally request permission to check the balance of the payment account before initiating a payment.

MPCS-2

Consent Staging

As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70092902/Common+Rules+and+Guidelines#10.-Consent-Staging

MPCS-3

Hand-off to LFI

As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70092902/Common+Rules+and+Guidelines#13Guidelines#11.-CheckHand-Acceptedoff-Authorization-Type.

5.7 Add to the payment Consent the IBAN of the Payee returned by the Proxy resolution process, if the multi-payments Consent was submitted for User Authorization with one or more Beneficiaries using a Proxy as the Payee Identification. In these cases, the Consent is thereafter tied to the IBAN(s) of the Payee(s) rather than the proxies themselves. This will allow the future multi-payments to be initiated to these IBAN(s) even if the Payee(s) change proxy between the time of the Consent and the initiation of multi-payments related to the Consent.

  • 5.7.1 Include in the payment Consent response to the OFP the IBAN(s) of the Payee identification(s) returned by the Proxy resolution.

5.8 Present to Users the following minimum required information for authorizing the long-lived payments Consent:

  • User Payment Account

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

  • Payer Note (Optional)

  • Consent Reference

  • 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

  • Fees & VAT (if applicable): These are potential charges that will be applied to the User account for making a payment in relation to the long-lived payment Consent. Both bank charges and VAT MUST be presented, stated separately, prior to the User Consent authorization. If applicable, LFIs MUST apply the charges on the date of each payment initiation and not at the point of payment Consent authorization.

5.9 Request for Balance Check Permission: If the TPP has requested permission to check the balance of the User’s payment account.

5.10 Check the Authorization Time window is valid to-LFI

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

MPCS-4

Authentication

LFI Authentication Only

As per the following sections:

Centralized Authentication and Authorization (Federated) Only

As per https://openfinanceuae.atlassian.net/wiki/x/HoBBAw

MPCS-5

Confirmation/ Authorization

LFIs MUST:

5.1 Enable Users to authenticate using Multi-Factor Authentication (MFA) in order to review and authorize the long-lived payment Consent.

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

5.3 Allow Users to select a payment account for the initiation of the multi-payments, if this was not provided in the retrieved staged Payment Consent details as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70092902/Common+Rules+and+Guidelines#12.-Payment-Account-Selection-at-LFI

  • 5.3.1 Allow Users to select a payment account for the initiation of the multi-payments 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.

5.4 Only present additional screens, if necessary to allow the validation and confirmation of the payment Consent (e.g., Beneficiary adding & activation and Proxy lookup).

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

5.6 Check the authorization status of the selected payment account is in accordance with the TPPs' Accepted Authorization Type as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70092902/Common+Rules+and+Guidelines#20Guidelines#13.-Check-Accepted-Authorization-Time-WindowType.

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

5.12 Update the payment Consent details stored in the OFP with all the information included in the payment Consent authorized by the User.

OFP MUST:

5.13 Confirm back to the LFIs that the payment Consent details have been updated successfully.

5.14 Start tracking the Consent Control Parameters for the Control Period at the Control Period Start Date, if provided, or the Consent creation Date otherwise. The Control Period starts from 00:00:00 of the day and ends at 23:59:59 of the Control Period end day, calculated based on the Control Period type as defined in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70092119/Multi-Payments#6.3.2-VRP-Consent-Control-Period-%26-Start-Date.

5.15 Return back to the TPP in the payment Consent response the IBAN(s) of the Payee identification(s) returned by the Proxy resolution, if the payment Consent was submitted for User Authorization with one or more Payees using a Proxy as the Payee Identification.

Multi-Authorization Journey Only

5.16 As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70092902/Common+Rules+and+Guidelines#18.-Multi-User-Authorization-Flow

MPCS-6

Hand-off back to the TPP

6.1 As 7 Add to the payment Consent the IBAN of the Payee returned by the Proxy resolution process, if the multi-payments Consent was submitted for User Authorization with one or more Beneficiaries using a Proxy as the Payee Identification. In these cases, the Consent is thereafter tied to the IBAN(s) of the Payee(s) rather than the proxies themselves. This will allow the future multi-payments to be initiated to these IBAN(s) even if the Payee(s) change proxy between the time of the Consent and the initiation of multi-payments related to the Consent.

  • 5.7.1 Include in the payment Consent response to the OFP the IBAN(s) of the Payee identification(s) returned by the Proxy resolution.

5.8 Present to Users the following minimum required information for authorizing the long-lived payments Consent:

  • User Payment Account

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

  • Payer Note (Optional)

  • Consent Reference

  • 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

  • Fees & VAT (if applicable): These are potential charges that will be applied to the User account for making a payment in relation to the long-lived payment Consent. Both bank charges and VAT MUST be presented, stated separately, prior to the User Consent authorization. If applicable, LFIs MUST apply the charges on the date of each payment initiation and not at the point of payment Consent authorization.

5.9 Request for Balance Check Permission: If the TPP has requested permission to check the balance of the User’s payment account.

5.10 Check the Authorization Time window is valid as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70092902/Common+Rules+and+Guidelines#14Guidelines#20.-HandCheck-offAuthorization-back-to-the-TPP

MPCS-7

Confirmation to User

7.1 As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70092902/Common+Rules+and+Guidelines#16.-Confirmation-to-User

7.2 As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70092902/Common+Rules+and+Guidelines#19.-Payment-Details-Saving

4. Balance Check

Time-Window

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

5.12 Update the payment Consent details stored in the OFP with all the information included in the payment Consent authorized by the User.

OFP MUST:

5.13 Confirm back to the LFIs that the payment Consent details have been updated successfully.

5.14 Start tracking the Consent Control Parameters for the Control Period at the Control Period Start Date, if provided, or the Consent creation Date otherwise. The Control Period starts from 00:00:00 of the day and ends at 23:59:59 of the Control Period end day, calculated based on the Control Period type as defined in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70092119/Multi-Payments#6.3.2-VRP-Consent-Control-Period-%26-Start-Date.

5.15 Return back to the TPP in the payment Consent response the IBAN(s) of the Payee identification(s) returned by the Proxy resolution, if the payment Consent was submitted for User Authorization with one or more Payees using a Proxy as the Payee Identification.

Multi-Authorization Journey Only

5.16 As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70092902/Common+Rules+and+Guidelines#18.-Multi-User-Authorization-Flow

MPCS-6

Hand-off back to the TPP

6.1 As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70092902/Common+Rules+and+Guidelines#14.-Hand-off-back-to-the-TPP

MPCS-7

Confirmation to User

7.1 As per https://openfinanceuae.atlassian.net/wiki/spaces/

standardsv1draft2

standardsv1draft3/pages/

52528609/Customer+Data#6.3-Data-Cluster-Structure-%26-Language

OFP MUST:

3.1 Provide the TPP with all the available information in relation to the balance check request.

3.2 Send an appropriate error response to the TPPs in case the balance check request was not successful.

...

70092902/Common+Rules+and+Guidelines#16.-Confirmation-to-User

7.2 As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70092902/Common+Rules+and+Guidelines#19.-Payment-Details-Saving

4. Balance Check

Variable Beneficiaries Only

#

Step

Rules & Guidelines

MPPI-1

Payment Initiation

Balance Check

TPPs MUST:

1.1

NOT submit to OFP any payment initiation requests in relation to an

be able to request the balance information using the authorized Multi-payment Consent

with Variable Beneficiaries if the User authorization conditions have not been met

before initiating the payment.

1.2

Present to Users for each payment initiation the following minimum required information:Payment Amount & Currency (as per https://openfinanceuae.

use this capability only in relation to the Payment initiation step to follow.

1.3 not use this capability as an alternative for Account Information Service,for example, to satisfy use cases like Personal finance manager where the account balance is being refreshed periodically.

1.4 make this request not earlier than 24 hours from when a scheduled payment will be initiated.

LFIs MUST:

2.1 Provide the OFP with the the information related to the balance of the User's account which was used for authorizing the Multi Payment consent. This information must be the same information as defined under the Balances in https://openfinanceuae.atlassian.net/wiki/spaces/

standardsv1draft3

standardsv1draft2/pages/

70092902

52528609/

Common+Rules+and+Guidelines#3.-Payment-Amount

Customer+Data#6.3-Data-Cluster-Structure-%26-

Currency)

  • Payee Identification details (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70092902/Common+Rules+and+Guidelines#4.-Payee-Identification)

    • 1.3 Ensure that all required authorization conditions as agreed with the User during the Consent setup are met.

    1.4 Generate a unique identifier for the transaction that links the Users’s authorization factors with the payment details (i.e. amount and payee identification). TPPs MUST generate an audit trail of the User’s payment initiation actions during the session. TPPs MUST have all required records as evidence required as listed in the liability model.

    1.5 Provide Users the ability to abort the payment journey, if Users decided to terminate the request.

    Scheduled Multi-Payments Only (Fixed Recurring Payment Consent, Variable Recurring Consent and Variable-defined Consent)

    Language

    OFP MUST:

    3.1 Provide the TPP with all the available information in relation to the balance check request.

    3.2 Send an appropriate error response to the TPPs in case the balance check request was not successful.

    5. Payment Initiation

    #

    Step

    Rules & Guidelines

    MPPI-1

    Payment Initiation

    Variable Beneficiaries Only

    TPPs MUST:

    1.6 Submit 1 NOT submit to OFP any payment initiation requests on the scheduled dates defined in the Periodic or the Variable-defined Payment Schedule of the long-lived Payment Consent authorized by the User.

    1.7 Schedule the execution time of the payments related to the Periodic or the Variable-defined Payment Schedule to occur during time periods of low payment volume such as the early hours of the day, unless there are specific requirements based on their business case.

    TPPs MUST:

    1.8 Submit to OFP payment initiation requests with the same fixed parameters as per the long-lived Payment Consent authorized by the User. In case where the consent was setup using the Payee’s proxy, the payment request MUST also include the IBAN from the proxy Payee identification returned back to the TPP during the payment Consent setup.

    1.9 Submit to OFP payment initiation requests with variable parameters within the allowable limits of the Consent Controls as per the long-lived Payment Consent authorized by the User.

    1.10 Include in each one of the payment initiation requests the same Payer Note as specified in the authorized long-lived Payment Consent, as the default value, if previously provided. However, this may be overwritten by a new Payer Note provided by the User or the TPP, if relevant, for each payment initiation request.

    1.11 Include in each of the payment initiation requests a Payment Reference. This MUST be populated as follows:

    • 1.11.1 If the Payment Reference in the authorized long-lived Payment Consent was provided by the User, TPPs MUST use the same Payment Reference for every payment initiated under the long-lived Payment Consent.

    • 1.11.2 If the Payment Reference in the authorized long-lived Payment Consent was pre-populated by the TPP, TPPs can:

      • EITHER use the same Payment Reference for every payment initiated under the long-lived Payment Consent

      • OR pre-populate the Payment Reference with different information for every payment initiated under the long-lived Payment Consent based on the requirements of the TPPs or their servicing customers.

    VRPs Only

    TPPs MUST:

    1.12 NOT submit any payment initiation requests of amount more than the maximum payment value per payment initiation, if specified in the long-lived Payment Consent for VRPs.

    1.13 Keep track of the cumulative value of all payment initiations and NOT submit any VRP payment initiation requests that will result in exceeding the maximum limit, if specified in the long-lived Payment Consent for the VRPs.

    1.14 Keep track of the maximum cumulative number of all payment initiation and NOT submit any VRP payment initiation requests that will result in exceeding the maximum limit, if specified in the long-lived Payment Consent for the VRPs.

    1.15 Keep track of the cumulative payment value of all payment initiations per time window and NOT submit any VRP payment initiation requests that will result in exceeding the maximum limit, if specified in the long-lived Payment Consent for the VRPs.

    1.16 Keep track of the cumulative payment volume of payment initiations per time window and NOT submit any VRP payment initiation requests that will result in exceeding the maximum limit, if specified in the long-lived Payment Consent for the VRPs.

    Variable-defined Beneficiaries Only

    1.17 Include in each of the payment initiation requests one of the Payee Identification details included in the Pre-defined Beneficiary List, as defined in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70092119/Multi-Payments#6.5.1-Payee-Identification-for-Variable-defined-Beneficiaries

    Variable Beneficiaries Only

    1.18 Include in each of the payment initiation requests the Payee Identification details, which were not provided as part of the long-lived Payment Consent authorized.

    1.19 Include in each of the payment initiation requests the unique identifier for the transaction related to the User’s authorization of the payment details

    MPPI-2

    Processing of Payment Initiation Requests

    OFP MUST:

    2.1 Allow the TPPs to submit individual payment initiation requests under the long-lived Payment Consent authorized by the User, without any additional MFA or authorization from the User.

    2.2 Check that the received payment initiation requests relate to a valid long-lived Payment Consent authorized by the User. The Consent MUST be in the Authorized state. The OFP MUST reject any payment initiation messages related to a Payment Consent in a different state (e.g. expired) and respond back to the TPP with the appropriate error message/code.

    2.3 Check the payment initiation request parameters against the authorized long-lived Payment Consent. More specifically, the OFP MUST check the following:

    • The Payee Identification details in the submitted payment initiation request matches exactly the Payee Identification in the authorized Payment Consent, except in the case of Variable Beneficiaries Consent.

      • 2.3.1 For Variable-defined Beneficiaris, the Payee Identification details in the submitted payment initiation request MUST match exactly one of the Payee Identification entries in the authorized Payment Consent Predefined Beneficiary List.

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

    FRPs Only

    OFT MUST:

    2.4 Check the Fixed Recurring Payment initiation request parameters against the Fixed Recurring Payment Consent. More specifically, the OFP MUST:

    • Check the cumulative Total Number of payment initiations including the submitted payment initiation request is less than the Total Number of Payments as defined in the authorized long-lived Fixed Recurring Payment Consent.

    2.5 Increment the cumulative total number of payments after the payment has been successfully executed and received payment status confirmation from the payee Bank. The initial value of this parameter should be zero for each authorized Fixed Recurring Payment Consent.

    2.6 Set the Fixed Recurring Payment Consent state to a terminal state (Finished), if the cumulative total number of payments requests becomes equal to the Total Number of Payments parameter of the Fixed Recurring Payment Consent.

    VRPs Only

    OFP MUST:

    2.7 in relation to an authorized Multi-payment Consent with Variable Beneficiaries if the User authorization conditions have not been met.

    1.2 Present to Users for each payment initiation the following minimum required information:

    1.3 Ensure that all required authorization conditions as agreed with the User during the Consent setup are met.

    1.4 Generate a unique identifier for the transaction that links the Users’s authorization factors with the payment details (i.e. amount and payee identification). TPPs MUST generate an audit trail of the User’s payment initiation actions during the session. TPPs MUST have all required records as evidence required as listed in the liability model.

    1.5 Provide Users the ability to abort the payment journey, if Users decided to terminate the request.

    Scheduled Multi-Payments Only (Fixed Recurring Payment Consent, Variable Recurring Consent and Variable-defined Consent)

    TPPs MUST:

    1.6 Submit to OFP payment initiation requests on the scheduled dates defined in the Periodic or the Variable-defined Payment Schedule of the long-lived Payment Consent authorized by the User.

    1.7 Schedule the execution time of the payments related to the Periodic or the Variable-defined Payment Schedule to occur during time periods of low payment volume such as the early hours of the day, unless there are specific requirements based on their business case.

    TPPs MUST:

    1.8 Submit to OFP payment initiation requests with the same fixed parameters as per the long-lived Payment Consent authorized by the User. In case where the consent was setup using the Payee’s proxy, the payment request MUST also include the IBAN from the proxy Payee identification returned back to the TPP during the payment Consent setup.

    1.9 Submit to OFP payment initiation requests with variable parameters within the allowable limits of the Consent Controls as per the long-lived Payment Consent authorized by the User.

    1.10 Include in each one of the payment initiation requests the same Payer Note as specified in the authorized long-lived Payment Consent, as the default value, if previously provided. However, this may be overwritten by a new Payer Note provided by the User or the TPP, if relevant, for each payment initiation request.

    1.11 Include in each of the payment initiation requests a Payment Reference. This MUST be populated as follows:

    • 1.11.1 If the Payment Reference in the authorized long-lived Payment Consent was provided by the User, TPPs MUST use the same Payment Reference for every payment initiated under the long-lived Payment Consent.

    • 1.11.2 If the Payment Reference in the authorized long-lived Payment Consent was pre-populated by the TPP, TPPs can:

      • EITHER use the same Payment Reference for every payment initiated under the long-lived Payment Consent

      • OR pre-populate the Payment Reference with different information for every payment initiated under the long-lived Payment Consent based on the requirements of the TPPs or their servicing customers.

    VRPs Only

    TPPs MUST:

    1.12 NOT submit any payment initiation requests of amount more than the maximum payment value per payment initiation, if specified in the long-lived Payment Consent for VRPs.

    1.13 Keep track of the cumulative value of all payment initiations and NOT submit any VRP payment initiation requests that will result in exceeding the maximum limit, if specified in the long-lived Payment Consent for the VRPs.

    1.14 Keep track of the maximum cumulative number of all payment initiation and NOT submit any VRP payment initiation requests that will result in exceeding the maximum limit, if specified in the long-lived Payment Consent for the VRPs.

    1.15 Keep track of the cumulative payment value of all payment initiations per time window and NOT submit any VRP payment initiation requests that will result in exceeding the maximum limit, if specified in the long-lived Payment Consent for the VRPs.

    1.16 Keep track of the cumulative payment volume of payment initiations per time window and NOT submit any VRP payment initiation requests that will result in exceeding the maximum limit, if specified in the long-lived Payment Consent for the VRPs.

    Variable-defined Beneficiaries Only

    1.17 Include in each of the payment initiation requests one of the Payee Identification details included in the Pre-defined Beneficiary List, as defined in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70092119/Multi-Payments#6.5.1-Payee-Identification-for-Variable-defined-Beneficiaries

    Variable Beneficiaries Only

    1.18 Include in each of the payment initiation requests the Payee Identification details, which were not provided as part of the long-lived Payment Consent authorized.

    1.19 Include in each of the payment initiation requests the unique identifier for the transaction related to the User’s authorization of the payment details

    MPPI-2

    Processing of Payment Initiation Requests

    OFP MUST:

    2.1 Allow the TPPs to submit individual payment initiation requests under the long-lived Payment Consent authorized by the User, without any additional MFA or authorization from the User.

    2.2 Check that the received payment initiation requests relate to a valid long-lived Payment Consent authorized by the User. The Consent MUST be in the Authorized state. The OFP MUST reject any payment initiation messages related to a Payment Consent in a different state (e.g. expired) and respond back to the TPP with the appropriate error message/code.

    2.3 Check the payment initiation request parameters against the authorized long-lived VRP Payment Consent. More specifically, the OFP MUST check the following:

    • The cumulative Total Value of all payment initiations including the amount of Payee Identification details in the submitted payment initiation request matches exactly the Payee Identification in the authorized Payment Consent, except in the case of Variable Beneficiaries Consent.

      • 2.3.1 For Variable-defined Beneficiaris, the Payee Identification details in the submitted payment initiation request

      is less or equal to the Maximum Cumulative Value of all payment initiations defined

      • MUST match exactly one of the Payee Identification entries in the authorized

      long-lived Payment Consent (For Variable Recurring and Variable On-demand Consent types)

      • Payment Consent Predefined Beneficiary List.

    • The cumulative Total Number of all payment initiations including date of the submitted payment initiation request is less or equal to the Maximum Cumulative Number of all payment initiations defined in the authorized within:

      • the validity period of the long-lived Payment Consent (

      For Variable Recurring Consent and Variable On-demand Consent types).

    • The cumulative Total Value of all payment initiations per Consent Control Period including the amount of the submitted payment initiation request is less or equal to the Maximum Cumulative Value of all payment initiations within the Consent Control Period as defined in the authorized long-lived Payment Consent (For Variable Recurring Consent and Variable On-demand Consent types).

    • The cumulative Total Number of all payment initiations per Consent Control Period including the submitted payment initiation request is less or equal to the Maximum Cumulative Number all payment initiations within the Consent Control Period as defined in the authorized long-lived Payment Consent (For Variable Recurring Consent and Variable On-demand Consent types).

    2.8 Check that the date of the payment initiation and the payment amount match exactly the Variable-defined Payment Schedule of the authorized Consent for the Variable-defined Payments.

    2.9 Increment the cumulative Total Number and the cumulative Total Value of payments under the VRP Consent after the payment

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

    MPPI-4

    Payment Notifications

    FRPs Only

    OFT MUST:

    2.4 Check the Fixed Recurring Payment initiation request parameters against the Fixed Recurring Payment Consent. More specifically, the OFP MUST:

    • Check the cumulative Total Number of payment initiations including the submitted payment initiation request is less than the Total Number of Payments as defined in the authorized long-lived Fixed Recurring Payment Consent.

    2.5 Increment the cumulative total number of payments after the payment has been successfully executed and received payment status confirmation from the payee Bank. The initial value of these parameters this parameter should be zero for each authorized VRP Fixed Recurring Payment Consent.

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

    2.11 Set the long-lived Payment Consent state to a terminal state (Finished), if the cumulative total number of payment requests becomes equal to the Total Number of Payments parameter of the VRP Consent.

    Variable Beneficiaries Only

    2.12 Check that the payment initiation request contains valid payee identification details and that there is a unique identifier related to the Users’s authorization of the payment details.

    OFP MUST:

    2.13 Allow the description of the Payment Reference in the submitted payment initiation request to be different than the one defined in the Payment Reference of the long-lived Payment Consent.

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

    • User Payment Account (or account identifier)

    • Payment Amount & Currency

    • Payee Identification details

    • Payer Note (If provided)

    • Payment Reference

    LFIs MUST:

    2.16. Allow the OFP to submit the payment initiation request without any additional MFA or authorization from the User.

    2.17 Add to the payment initiation request the IBAN of the Payee returned by the Proxy resolution process, if the payment initiation request was submitted using a Proxy as the Payee Identification. The payment initiation request is thereafter tied to the IBAN of the Payee rather than the proxy itself.

    • 2.17.1 Include in the payment initiation response to the OFP the IBAN of the Payee identification returned by the Proxy resolution.

    2.18 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 or checks.

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

    2.20 Subject to successful BAU checking, validation and payment processing, proceed with the execution of the payment by either submitting the payment to the underlying payment rails or executing internally as Intra-bank payment.

    2.21 Provide the OFP with all the available information in relation to the initiated payment instruction including the payment’s unique identifier Payment Transaction ID. The format of the Payment Transaction ID can be found in the UAE Open Finance Standard specifications.

    OFP MUST:

    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.23 Send to the TPP the appropriate error message in case the payment payment initiation was rejected by the LFI due to insufficient funds in the selected payment account.

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

    MPPI-3

    Payment Status Update

    As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70092902/Common+Rules+and+Guidelines#15.-Payment-Status-Update

    As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70092902/Common+Rules+and+Guidelines#17.-Payment-Notifications6 Set the Fixed Recurring Payment Consent state to a terminal state (Finished), if the cumulative total number of payments requests becomes equal to the Total Number of Payments parameter of the Fixed Recurring Payment Consent.

    VRPs Only

    OFP MUST:

    2.7 Check the payment initiation request parameters against the authorized long-lived VRP Payment Consent. More specifically, the OFP MUST check the following:

    • The cumulative Total Value of all payment initiations including the amount of the submitted payment initiation request is less or equal to the Maximum Cumulative Value of all payment initiations defined in the authorized long-lived Payment Consent (For Variable Recurring and Variable On-demand Consent types).

    • The cumulative Total Number of all payment initiations including the submitted payment initiation request is less or equal to the Maximum Cumulative Number of all payment initiations defined in the authorized long-lived Payment Consent (For Variable Recurring Consent and Variable On-demand Consent types).

    • The cumulative Total Value of all payment initiations per Consent Control Period including the amount of the submitted payment initiation request is less or equal to the Maximum Cumulative Value of all payment initiations within the Consent Control Period as defined in the authorized long-lived Payment Consent (For Variable Recurring Consent and Variable On-demand Consent types).

    • The cumulative Total Number of all payment initiations per Consent Control Period including the submitted payment initiation request is less or equal to the Maximum Cumulative Number all payment initiations within the Consent Control Period as defined in the authorized long-lived Payment Consent (For Variable Recurring Consent and Variable On-demand Consent types).

    2.8 Check that the date of the payment initiation and the payment amount match exactly the Variable-defined Payment Schedule of the authorized Consent for the Variable-defined Payments.

    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 payee Bank. The initial value of these parameters should be zero for each authorized VRP Consent.

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

    2.11 Set the long-lived Payment Consent state to a terminal state (Finished), if the cumulative total number of payment requests becomes equal to the Total Number of Payments parameter of the VRP Consent.

    Variable Beneficiaries Only

    2.12 Check that the payment initiation request contains valid payee identification details and that there is a unique identifier related to the Users’s authorization of the payment details.

    OFP MUST:

    2.13 Allow the description of the Payment Reference in the submitted payment initiation request to be different than the one defined in the Payment Reference of the long-lived Payment Consent.

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

    • User Payment Account (or account identifier)

    • Payment Amount & Currency

    • Payee Identification details

    • Payer Note (If provided)

    • Payment Reference

    LFIs MUST:

    2.16. Allow the OFP to submit the payment initiation request without any additional MFA or authorization from the User.

    2.17 Add to the payment initiation request the IBAN of the Payee returned by the Proxy resolution process, if the payment initiation request was submitted using a Proxy as the Payee Identification. The payment initiation request is thereafter tied to the IBAN of the Payee rather than the proxy itself.

    • 2.17.1 Include in the payment initiation response to the OFP the IBAN of the Payee identification returned by the Proxy resolution.

    2.18 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 or checks.

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

    2.20 Subject to successful BAU checking, validation and payment processing, proceed with the execution of the payment by either submitting the payment to the underlying payment rails or executing internally as Intra-bank payment.

    2.21 Provide the OFP with all the available information in relation to the initiated payment instruction including the payment’s unique identifier Payment Transaction ID. The format of the Payment Transaction ID can be found in the UAE Open Finance Standard specifications.

    OFP MUST:

    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.23 Send to the TPP the appropriate error message in case the payment payment initiation was rejected by the LFI due to insufficient funds in the selected payment account.

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

    MPPI-3

    Payment Status Update

    As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70092902/Common+Rules+and+Guidelines#15.-Payment-Status-Update

    MPPI-4

    Payment Notifications

    As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70092902/Common+Rules+and+Guidelines#17.-Payment-Notifications

    5. UC013 - Recurring Payments with a One-Time Setup

    PISPs MUST be able to support use cases where PSUs need to make an initial payment and then require the ability to make further payments on a recurring basis as part of a single consent request.

    A single request can include the consent for SIP/FDP and the FRPs or VRPs which can be authorized by the PSU with the PASP in a single authentication flow.

    Panel
    panelIconId4ed0005e-603c-41bf-b237-1633f09c6a24
    panelIcon:person:
    panelIconText:person:
    bgColor#EAE6FF

    User Story

    As a PSU (Consumer or Business),

    I want to provide my consent to a TPP to use my payment account for initiating both:

    • a Single Instant or Future Dated Payment of a fixed amount and;

    • a sequence of future recurring payments of fixed or variable amounts with a fixed or variable schedule to a domestic beneficiary account owned by a business or an individual,

    so that I can pay the relevant beneficiary.

    The PSU (Consumer or Business) makes one initial payment and authorizes further recurring payments of a fixed or variable amount with a fixed or variable schedule to a business or a personal beneficiary.

    This use case requires a Generic Business Rules for PIS | B. Long Lived Consent. The consent parameters type for this use case is Combined Payment Consent, which is a long-lived consent that MUST be used for a combination of a single instant payment and a series of future payments of fixed or variable amounts occurring at fixed or variable schedule.

    Panel
    panelIconId1f1f5
    panelIcon:regional_indicator_p:
    panelIconText🇵
    bgColor#DEEBFF

    PISPs MUST:

    5.1 Enable PSUs to provide a single explicit consent for both the single instant or future dated payment and the setup of FRPs or VRPs. More specifically, PSUs MUST be allowed to combine in a single consent the following options:

    • Single Instant Payment with Fixed Recurring Payments or Single Future Dated Payment with Fixed Recurring Payments

    • Single Instant Payment with Fixed on Demand Payments or Single Future Dated Payment with Fixed on Demand Payments

    • Single Instant Payment with Variable Recurring Payments or Single Future Dated Payment with Variable Recurring Payments

    • Single Instant Payment with Variable On-demand Payments or Single Future Dated Payment with Variable On-demand Payments

    • Single Instant Payment with Variable-defined Payments or Single Future Dated Payment with Variable-defined Payments

    5.2 Request both the single instant payment and the FRPs or VRPs setup within a single explicit consent. There MUST be a single Authorization step for this request with the PASP.

    Panel
    panelIconIdbe99de2e-2b7e-4996-aa88-9eede9ccfd75
    panelIcon:bank:
    panelIconText:bank:
    bgColor#E3FCEF

    PASPs MUST:

    5.3 Process this as a single Authentication and Authorization request. PASPs MUST NOT request PSUs to authenticate twice to authorize both parts of the consent.

    5.4 Enable PSUs to authorize a combined consent in a single authentication flow.

    5.5 Respond with a failure for the entire request, if there is a failure in processing either part of the payment consent request.

    All rules under Generic Business Rules for PISapply.

    5. Consent Updates

    #

    Step

    Rules

    MPCU-1

    Consent Update

    TPPs MUST:

    1.1 Enable Users to use the Consent Dashboard to amend the following parameters of a long-lived Payment consent:

    1.2 Require the Users to authenticate with their LFI and authorize the Consent update.

    ...

    Panel
    panelIconId068fdde3-c1f6-4759-9967-8a80e7ba7356
    panelIcon:rock:
    panelIconText:rock:
    bgColor#DEEBFF

    TTPs MUST:

    6.1.1 Allow Users to manually enter the Consent Reference or pre-populate it for the Users (depending on the Use Case). Consent Reference is mandatory due to being the default value to be used for the Payment Reference of the Payment Initiation Requests. The Consent Reference is populated either by the User (i.e. payer) or the TPP using information requested by the beneficiary or any other information that can be provided to the beneficiary to assist in identifying and reconciling any payments initiated using this consent. This information may be mapped to the Payment Reference of each Payment Initiation Request and thus may be transferred via the payment rails to the beneficiary LFI. However, the TPP might not be using this and may be populating the Payment Reference of each of the initiated payment Requests with different information.

    6.1.2 Validate that the format of the Consent Reference is according to the Bank Service Initiation API - Swagger Documentation.

    6.2 Period & Payment Schedule

    ...

    Panel
    panelIconId068fdde3-c1f6-4759-9967-8a80e7ba7356
    panelIcon:rock:
    panelIconText:rock:
    bgColor#DEEBFF

    TTPs MUST:

     6.3.1 Either allow Users to specify the below set of parameters or pre-populate them for the Users based on the specific use-case or the requirements of their receiving beneficiary customer:

    ...

    Panel
    panelIconId068fdde3-c1f6-4759-9967-8a80e7ba7356
    panelIcon:rock:
    panelIconText:rock:
    bgColor#DEEBFF

    TTPs MUST:

    6.3.2.1 Either allow Users to manually enter/specify the below parameters or pre-populate them for Users based on the specific use-case or the requirements of their receiving beneficiary customer:

    6.4 Consent Expiration Date & Time

    ...