Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Expand
titleMENU
Table of Contents
minLevel1
maxLevel6
include
outlinefalse
indent
stylenone
exclude
typelist
class
printabletrue

...

#

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 Creditor 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

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

Variable Recurring Payments (VRPs) - Variable Recurring Consent

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

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

Additional Consent Parameters

1.2 Set/no set Is Single Authorization flag as appropriate (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot2draft1/pages/266375125/Common+Rules+and+Guidelines#7.-Is-Single-Authorization-flag).

1.3 Set the Authorization Expiry Date Time (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot2draft1/pages/266375125/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 Fixed-defined & Variable-defined Consent, the Authorization Time Window MUST be less than the time of the first payment in the Fixed-defined & Variable-defined Payments Schedule.

1.4 Set/clear the “Is Pay By Account” flag as appropriate in the case the initiated payment Consent relates to payments at POS or e-commerce payments.1.5 Set the Risk Information Block (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot2draft1/pages/266375125/Common+Rules+and+Guidelines#9.-Risk-Information-Block)

1.6 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.7 6 Acquire 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/standardsv1dot2draft1/pages/266375125/Common+Rules+and+Guidelines#10.-Consent-Staging

MPCS-3

Hand-off to LFI

As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot2draft1/pages/266375125/Common+Rules+and+Guidelines#11.-Hand-off-to-LFI

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

MPCS-4

Authentication

LFI Authentication Only

4.1 As per the following sections:

Centralized Authentication and Authorization (Federated) Only

4.2 As per Centralized Authentication and Authorization

MPCS-5

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/standardsv1dot2draft1/pages/266375125/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 NOT earmark (i.e. block) any funds related to the payment Consent in the Users' payment account at the point of Consent authorization.

5.5 Check the authorization status of the selected payment account is in accordance with the TPPs' Is Single Authorization flag as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot2draft1/pages/266375125/Common+Rules+and+Guidelines#7.-Is-Single-Authorization-flag.

5.6 Display to Users the TPP Trading Name of the TPP that initiated the long-lived payment Consent.

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

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 Fixed-defined or Variable-defined) (if relevant, depending on the type of the long-lived payment Consent)

  • Consent Expiration Date & Time

5.8 Request Users to authorize the Multi-payments Consent, so that TPP can initiate payments from the payment account.

  • 5.8.1 Request Users to additionally authorize the Balance Check Permission, in the case that TPPs have requested permission to check the balance of the Users' payment accounts.

5.9 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 Multi-payments Consent.

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

5.11 Update the payment Consent details stored in the OFP with the relevant information.

OFP MUST:

5.12 Check the Authorization Time Window is valid as perhttps://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850813/Common+Rules+and+Guidelines#19.-Check-Authorization-Time-Window.

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 mandatory Control Period Start Date. 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/standardsv1dot2draft1/pages/266373190/Multi-Payments#8.3.2-VRP-Consent-Control-Period-%26-Start-Date.

Multi-Authorization Journey Only

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

MPCS-6

Hand-off back to the TPP

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

MPCS-7

Confirmation to User

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

...

#

Step

Rules & Guidelines

MPCOMB-1

Combined Payments Consent

TPPs MUST:

1.1 Enable Users to provide a single explicit consent for both a Single Instant Payment and the setup of FRPs and all types of VRPs. More specifically, Users MUST be allowed to combine in a single consent the following options:

  • Single Instant Payment with Fixed Recurring Payments

  • Single Instant Payment with Fixed on Demand Payments

  • Single Instant Payment with Variable Recurring Payments

  • Single Instant Payment with Variable On-demand Payments

  • Single Instant Payment with Fixed-defined Payments

  • Single Instant Payment with Variable-defined Payments

  • 1.1.1. All the above options with fixed or Variable and Variable-defined Beneficiaries

1.2 Set/clear the “Is Pay By Account” flag as appropriate in the case the initiated payment Consent relates to payments at POS or e-commerce payments.1.3 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 LFI.

MPCOMB-2

Combined Payments Consent Processing

LFIs MUST:

2.1 Process the Combined Payments Consent as a single Authentication and Authorization request. LFIs MUST NOT request Users to authenticate twice to authorize both parts of the Consent.

2.2 Enable Users to authorize Combined Payment Consents in a single authentication flow.

2.3 Respond back to TPPs with a failure for the entire request, if there is a failure in processing either part of the Combined Payment Consent request.

...

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

TTPs MUST:

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

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

8.4 Consent Expiration Date & Time

...