Versions Compared

Version Old Version 5 New Version 6
Changes made by

Alexandros Dimitrakoudis

Alexandros Dimitrakoudis

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Reverted from v. 4
Panel
panelIconIdatlassian-warning
panelIcon:warning:
bgColor#FFEBE6

NOTE

This page in still WIP and should not be taken under consideration during reviewing this draft version of the Standard

1. Description

This bank service request enables TPPs to initiate a series of Requests to Pay, with the Users' (Payees') consent, from the Users' LFI to a business or a personal Payer. The Request to Pay includes all the information in relation to the payment including the Payee’s payment account which will be used to receive the funds if the RTP is accepted by the Receiver (Payer). The RTP is then fullfiled using the existing LFI channels with the Receiver of the RTP accepting or rejecting the request.

The RTP scope is targeted to domestic payee accounts (i.e. payee accounts offered by LFIs located in UAE) and payments in local currency as used by the local payment systems infrastructure for domestic payments.

This user journey requires a Long-lived Consent of type Request to Pay Payment Consent.

Panel
panelIconIdatlassian-note
panelIcon:note:
bgColor#F4F5F7

Note: The scope of this service currently includes the RTP initiation, cancelation, and reminders journeys only. RTP fulfilment (accepting, and rejecting) is out of scope.

1.1 Payer and Payee Segments

The scope of the SIP bank service initiation related to the segments of payers and payees is shown below:

Requester (Payee)

Receiver (Payer)

Payer

Payee

Consumers

SME

Corporates

Consumers

SME

Corporates

(tick)

(tick)

(tick)

(tick)

(tick)

(tick)

1.2 Request to Pay (RTP) - Example User Story

Panel
panelIconId0cd1bba7-8f00-45e4-bfea-96eab8c2d5f8
panelIcon:dsfa:
panelIconText:dsfa:
bgColor#E6FCFF

User Story

As a User (Consumer, Business or Corporate),

I want to have the ability to send a payment request with all the payment details to a debtor (payer),

so that I can get paid directly to my payment account when the payer accepts the request.

2. User Journey

...

3. Wireframes

...

TBC

3.1. Consent Setup

...

#

...

Step

...

Rules & Guidelines

...

RTP-1

...

RTP 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

...

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) - Variable-defined Consent

...

Additional Consent Parameters

1.2 Set the Accepted Authorization Type (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft4/pages/98339394/Common+Rules+and+Guidelines#7.-Accepted-Authorization-Type).

1.3 Set the Authorization Time Window (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft4/pages/98339394/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/standardsv1draft4/pages/98339394/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 per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft4/pages/98339394/Common+Rules+and+Guidelines#10.-Consent-Staging

...

MPCS-3

...

Hand-off to LFI

...

As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft4/pages/98339394/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:

...

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/standardsv1draft4/pages/98339394/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/standardsv1draft4/pages/98339394/Common+Rules+and+Guidelines#13.-Check-Accepted-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

  • Purpose of Payment

  • Payment Amount & Currency (if relevant, depending on the type of the long-lived payment Consent)

  • Consent Controls Parameters (if relevant, depending on the type of the long-lived payment Consent)

  • Consent Control Period & Start Date (if relevant, depending on the type of the long-lived payment Consent)

  • The Payment Schedule (Periodic or Variable-defined) (if relevant, depending on the type of the long-lived payment Consent)

  • Consent Expiration Date & Time

  • 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 Users to authorize the Multi-payments Consent, so that TPP can initiate payments from the payment account.

  • 5.9.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.10 Provide Users the ability to abort 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.11 Check the Authorization Time window is valid as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft4/pages/98339394/Common+Rules+and+Guidelines#20.-Check-Authorization-Time-Window

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

5.13 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.14 Confirm back to the LFIs that the payment Consent details have been updated successfully.

5.15 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/standardsv1draft4/pages/98338296/Multi-Payments#8.3.2-VRP-Consent-Control-Period-%26-Start-Date.

5.16 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.17 As per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft4/pages/98339394/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/standardsv1draft4/pages/98339394/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/standardsv1draft4/pages/98339394/Common+Rules+and+Guidelines#16.-Confirmation-to-User

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

8.2 Long-lived RTP Consent

This use case requires a https://ksaob.atlassian.net/wiki/spaces/BRS20231101final/pages/348553780/Generic+Business+Rules+for+PIS#B.-Long-Lived-Consent. The consent parameters type for this use case is Long-lived RTP Consent, which MUST be used for a series of future RTPs of variable amounts to different recipients (payers) occurring at variable schedule.

As part of a long-lived RTP Consent PSUs need to authenticate and authorize with their PASPs once to setup the long-lived consent. Any RTPs initiated using the authorized long-lived consent do not require any further PSU authentication and authorization with their PASPs.

8.2.1 Long-lived RTP Consent Setup

Panel
panelIconId1f1f5
panelIcon:regional_indicator_p:
panelIconText🇵
bgColor#DEEBFF

PISPs MUST:

8.2.1.1 Enable PSUs to review the parameters related to the long-lived RTP consent. These parameters include:

Basic Consent Parameters

Additional Consent Parameters

8.2.1.2 Set the Accepted Authorization Type (as per https://ksaob.atlassian.net/wiki/spaces/BRS20231101final/pages/348553780/Generic+Business+Rules+for+PIS#4.2.11-Accepted-Authorization-Type).

8.2.1.3 Set the Authorization Time Window (as per https://ksaob.atlassian.net/wiki/spaces/BRS20231101final/pages/348553780/Generic+Business+Rules+for+PIS#4.2.12-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. The Authorization Time Window MUST be less than the Consent Validity Period.

8.2.1.4 Set the Risk Information Block (as per https://ksaob.atlassian.net/wiki/spaces/BRS20231101final/pages/348553780/Generic+Business+Rules+for+PIS#4.2.13-Risk-Information-Blockexcluding the Destination Delivery Address and the Beneficiary Indicators information groups due to being irrelevant)

8.2.1.5 Enable PSUs to provide explicit long-lived consent for the initiation of a series of RTPs from their online payment account held at their PASP.

8.2.1.6 Make the long-lived RTP consent available to manage for the PSU from the PISPs consents dashboard.

8.2.1.7 Limit the number of RTPs batched together in a single RTP request message to the https://ksaob.atlassian.net/wiki/spaces/BRS20231101final/pages/348554507/PIS+Configuration+Parameters#Maximum-RTPs-per-Message.

8.2.3 Long-lived RTP Consent Authorization

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

PASPs MUST:

8.2.3.1 Request PSUs to follow the Authentication rules as defined in the https://ksaob.atlassian.net/wiki/spaces/BRS20231101final/pages/348553780/Generic+Business+Rules+for+PIS#4.4-Authentication.

8.2.3.2 Allow PSUs to select a payment account for the Long-lived RTP Consent to be used for the receiving of the RTP payments, if not provided by the PISP.

8.2.3.3 Present to PSUs the following minimum required information for authorizing the Long-lived RTP Consent:

  • RTP Consent Payment Account

  • RTP Consent Expiry Date

  • RTP Consent Control Parameters including:

    • Maximum Amount per RTP

    • Maximum Cumulative Value of all RTPs under the RTP Consent.

    • Maximum Cumulative Number of all RTPs under the RTP Consent.

    • Control Period Type & Control Period Start Date

    • Maximum Cumulative Value of all RTPs per Control Period

    • Maximum Cumulative Number of RTPs per Control Period

  • Fees & VAT: These are the charges that will be applied for making any RTPs in relation to the Long-lived RTP Consent. Both bank charges and VAT MUST be presented, stated separately, prior to the PSU Consent authorization. PASPs MUST apply the charges on the date of each VRP payment initiation and not at the point of Consent Authorization.

8.2.4 RTP Initiation

Image Removed
Panel
panelIconId1f1f5
panelIcon:regional_indicator_p:
panelIconText🇵
bgColor#DEEBFF

PISPs MUST:

8.2.4.1 Enable PSUs to initiate RTPs by providing the below required information:

8.2.4.2 NOT require any Multi-Factor Authentication with the PASP for initiating RTPs

8.2.5 RTP Initiation Processing by PASPs

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

PASPs MUST:

8.2.5.1 Check the Payer Identification specified in the RTP Consent parameters. If the Payer Identification is provided using a Payer Alias, PASPs MUST initiate the Proxy Lookup service available to retrieve the following:

  • Payee IBAN

  • Payee Name (This MUST be displayed to the PSU as per the PASPs existing BAU rules for online channels, i.e. masked by the PASP at a Channel level for Retail Customers)

8.2.5.2 Use the Account Verification service providing it with the IBAN information if the Payer Identification is provided using IBAN. This MUST retrieve the Payer Full Name and the Payer’s Bank related to the provided IBAN.

  • 8.2.5.2.1 Only display to PSUs the Display Name of the Payer as per the current BAU rules the PASPs comply with. Please note the Full Account Name will be used for any the RTP message by the PASP sent to the Recipient Bank after PSU authorization.

8.2.5.3 Present to PSUs the following minimum required information for authorizing the RTP Consent:

  • Payer (RTP Recipient) Display Name

  • Payer (RTP Recipient) IBAN (& alias if specified)

  • Payer (RTP Recipient) Account Holding Entity

  • Purpose of RTP

  • RTP Payment Amount

  • Fees & VAT: These are the charges that will be applied for making any RTPs relation to the Single Use or Long-lived RTP Consent. Both bank charges and the VAT must be presented, stated separately, prior to the PSU Consent authorization.

8.2.5.4 Enable PSUs to provide a Multi-Factor Authentication (MFA) and authorize a long-lived RTP consent.

8.2.5.5 Enable PSUs to provide a Multi-Factor Authentication (MFA) and authorize a single RTP consent.

8.2.5.6 After the long-lived RTP consent has been authorized, PASPs MUST allow the PISPs to submit single or multiple RTPs under the long-lived RTP consent without any additional MFA or authorization from the PSU.

8.2.5.7 Respond with appropriate error to the PISP if there is a failure in processing consent request.

8.2.5.8 Display and notify PSUs for any RTPs status updates via their existing channels (BAU).

8.2.5.9 Treat each RTP in the batch separately. Failure of one or more individual RTPs MUST NOT affect the remaining successful RTPs submitted in the same batch.

8.2.5.10 Continue displaying the Payer (RTP Recipient) Display Name masked at the Channel level for Retail Customers till the RTP request is accepted by the Payer.

Panel
panelIconId1f1f5
panelIcon:regional_indicator_p:
panelIconText🇵
bgColor#F4F5F7

PISPs COULD:

8.2.5.11 Provide a notification to the PSU 5 days before the expiry of the RTP, if they have not received any updates from the PSU’s PASP.

8.2.6 RTP Long-lived Consent Parameters Update

In addition to the consent parameter stated in https://ksaob.atlassian.net/wiki/spaces/BRS20231101final/pages/348553780/Generic+Business+Rules+for+PIS#4.11.3-Updating-Consent-Parameters-%2F-Consent-Renewal, the following consent parameters may also be updated:

Panel
panelIconId1f1f5
panelIcon:regional_indicator_p:
panelIconText🇵
bgColor#DEEBFF

PISPs MUST:

8.2.6.1 Enable PSUs to use the Consent Dashboard to amend the following parameters of a RTP long-lived consent:

8.2.6.2 Require the PSU to authenticate with their PASP and authorize the consent update.

8.2.7 RTP Long-lived Consent Revocation

In addition to the rules stated in https://ksaob.atlassian.net/wiki/spaces/BRS20231101final/pages/348553780/Generic+Business+Rules+for+PIS#4.11-Consent-Management-at-the-PISP, the following rules also hold:

...

panelIconId1f1f5
panelIcon:regional_indicator_p:
panelIconText🇵
bgColor#DEEBFF

PISPs MUST:

8.2.7.1 Enable PSUs to revoke the long-lived RTP Consent. If active RTPs in relation to the long-lived consent are still waiting to be accepted, paid or rejected by the Payer and have not yet expired, PISPs MUST provide PSUs to the following options:

...

Or select to revoke the RTP long-lived consent without cancelling the active RTPs.

8.3 RTP Cancelation Process

Image Removed

 

Panel
panelIconId1f1f5
panelIcon:regional_indicator_p:
panelIconText🇵
bgColor#DEEBFF

PISPs MUST:

8.3.1 Enable PSUs to cancel RTPs before the payment is done by the payer (before the RTP acceptance).

8.3.2 Authenticate the PSUs within their application with a Multi Factor Authentication before allowing the PSU to cancel the RTP.

8.3.3 Display and notify PSUs any RTPs status updates received from the PASP.

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

PASPs MUST:

8.3.4 NOT require any Multi-Factor Authentication for cancelation of RTPs and regardless of the consent type used (single or long-lived) to initiate the RTP.

8.3.5 Respond to the PISP with a failure message if the RTP cancellation fails.

8.3.6 Display and notify PSUs for any RTPs status updates via their existing channels (BAU).

8.3.7 Keep the RTP Consent in an active state so that PSUs are able to cancel the RTPs using via their PISPs.

8.5 General RTP Rules

Panel
panelIconId1f1ec
panelIcon:regional_indicator_g:
panelIconText🇬
bgColor#F4F5F7

General Rules:

8.5.1 For each RTP, there are multiple statuses (Pending, Unsubmitted, Cancelled, Accepted, Expired, Paid, and Rejected).

8.5.2 A PSU can be either an individual or a business.

8.5.3 There are no restrictions on who can send RTPs to whom. Available combinations are:

  • Individual to individual.

  • Individual to business.

  • Business to individual.

  • Business to business.

8.5.4 RTPs can be sent via:

  • PASPs (BAU).

  • PISPs (Open Banking)

8.5.5 It is in the competitive space of participants to innovate for supporting services, for example:

  • Sending multiple RTPs to multiple PSUs who should split a certain payment (friends dinner), percentage wise, custom split

  • Creating pre-defined groups (consists of PSUs) who usually split & share a certain payment (monthly, or yearly)

  • Schedule RTPs to be triggered at a specific time.

8.5.6 While the PSU is sending an RTP to multiple recipients, each RTP transaction should be handled & processed separately and each RTP should have its unique reference and parameters.

8.5.7 If a PSU is initiating multiple RTPs (without an existing long-lived RTP consent), they need to authenticate and authorize with their PASP once only for all requests.

8.5.8 If a PSU is initiating single or multiple RTPs (while having an existing long-lived consent), they MUST NOT authenticate and authorize each request with their PASP.

 

8.2.2 Long-lived RTP Consent Control Parameters

Panel
panelIconId1f1f5
panelIcon:regional_indicator_p:
panelIconText🇵
bgColor#DEEBFF

PISPs MUST:

8.2.2.1 Either allow PSUs to specify the below set of Consent Control parameters or pre-populate them for the PSUs based on the specific use-case or their own business requirements:

  • The maximum cumulative number of all RTPs under the Long-lived RTP Consent.

  • The maximum cumulative value of all RTPs under the Long-lived RTP Consent. Every RTP payment amount related to the Long-lived RTP Consent is added to the total cumulative value of the RTP Consent which cannot exceed the maximum cumulative value agreed with the PSU at the point of consent. Any additional RTP with payment amount resulting to a total cumulative value exceeding the maximum MUST be rejected by the PISP and the PASP.

  • The maximum payment amount per each RTP under the long-lived RTP Consent. This is the maximum payment amount an RTP can take. All RTP payment amounts must be smaller or equal to this value.

  • The Consent Control Period Type & Start Date (as defined in 4.4 Consent Control Period & Start Date).

  • The maximum number of RTPs per Control Period. During each repeating Control Period, the total number of all RTP requests MUST NOT exceed the maximum number defined in the Long-lived RTP Consent. The cumulative number of RTP requests is reset on every new Control Period.

  • The maximum cumulative value of all RTPs per Control Period. During each repeating Control Period, the total cumulative payment amount of all RTPs payment initiations under the Long-lived RTP Consent MUST NOT exceed the maximum value agreed by the PSU during the RTP Consent. Any additional RTP with payment amount resulting to the cumulative value during the Control Period exceeding the maximum MUST be rejected by the PISP and the PASP. The cumulative value is reset on every new Control Period.

8.1.5 Note To Payer

Panel
panelIconId1f1f5
panelIcon:regional_indicator_p:
panelIconText🇵
bgColor#DEEBFF

PISPs MUST:

8.1.5.1 Allow PSUs to manually enter a Note to the Payer or pre-populate it for the PSUs (depending on the Use Case). Note To Payer is optional for PSUs. Note To Payer may be populated by the PSU (i.e. RTP requestor and and Beneficiary of the RTP payment) using information requested by the Payer or any other information the PSU wants to provide to the Payer to assist in identifying and reconciling the payment request. This information will be transferred via the payment rails to the Payer PASP.

Note: PISPs may make the Note To Payer mandatory based on their specific use cases or business requirements (for example invoice payments).

8.1.5.2 Validate that the format of the Note To Payer is according to the https://ksaob.atlassian.net/wiki/spaces/OBF/pages/17924674. The Note To Payer length is limited to https://ksaob.atlassian.net/wiki/spaces/BRS20231101final/pages/348554507/PIS+Configuration+Parameters#Note-To-Payer-Maximum-Length

8.1.5.3 Include a Note To Payer in each RTP in the RTP request message if proved by the PSU. or can be populated by the PISP. The Note To Payer will be used by the PSU PASP to populate the Remittance Information of the RTP message sent to the Payer PASP.

8.1.4 Payer Identification (Recipient of RTP)

Panel
panelIconId1f1f5
panelIcon:regional_indicator_p:
panelIconText🇵
bgColor#DEEBFF

PISPs MUST:

8.1.4.1 Either allow PSUs to manually enter/select the payer identification details or pre-populate them for the PSUs.

Note: It is in the competitive space of PISPs to enable additional services for PSUs that may provide better customer experience where applicable. For example, a TPP with a long-term relationship with a PSU may have dual AISP and PISP role and have access to the Activated Beneficiaries account details.

8.1.4.2 Allow the payer identification using either of the following options regardless of the payment amount:

  1. IBAN: In this case, the information required for the payer are:

  • IBAN of the Payer.

  • Name of the Payer.

  • The Payer account holding entity. PISPs MUST be able to identify the holding entity by decoding the IBAN and MUST NOT ask PSUs to provide it or select from a list.

  1. Account number: In this case the information required for the payer are:

  • Account number of the Payer. This is the 12 digits domestic account number of the payer with their PASP.

  • Name of the Payer (optional information)

  • The Payer account holding entity. This MUST be identified using the trading name which familiar to PSUs. These MUST correspond to a valid IBAN Bank Code.

  1. Alias: In this case the information required for the payer are:

  • Alias of the Payer.

  • The Payer account holding entity. This MUST be identified using the entities trading name which familiar to PSUs.

The acceptable Aliases for the payer are as follows:

  • Mobile phone number.

  • Email.

  • National ID, IQAMA Number or Unified Commercial Number (700)

8.1.4.3 Be able to generate the payer IBAN using the information provided in 8.1.4.2 (#2) as follows:

  • ISO country code = SA, 2 digits IBAN Checksum, 2 digits IBAN Bank Code, 6 digits 000000, 12 digits Domestic Account Number.

8.1.4.4 Ensure that the format and other validation rules of the Payer identification details are correct in case PSUs manually enter the payer identification details. If not, PISPs MUST request PSUs to review and re-enter the information.

8.1.3 PSU Payment Account Selection (Creditor Account)

...

panelIconId1f1f5
panelIcon:regional_indicator_p:
panelIconText🇵
bgColor#DEEBFF

PISPs MUST:

8.1.3.1 Provide PSUs at least one of the following options for selecting their payment account to be used to receive the payment:

  • Manually enter their Payment Account Identification details (e.g. IBAN, account number & PASP, and any other formats supported by the PASP holding the PSUs' payment account).

  • Select their Payment Account Identification details. This assumes they have been saved previously and the PSU has a long-term profile with the PISP, having completed the Setup step.

  • Select their PASP and provide an Alias. The acceptable Aliases for PSUs are the following:

    • Mobile phone number

    • Email

    • National ID, IQAMA Number or Unified Commercial Number (700)

  • Select their PASP only in order to select their Payment Account later on in the journey after authenticating with the PASP. The PASP MUST identified using the trading name which familiar to PSUs.

Note1: In some of the above cases, PISPs may also need PSUs to provide their PASP name so that PISPs can check whether PASPs will be able to match the account identifier to the underlying PSU payment account.

...

TBC

3.2 RTP Initiation

TBC

3.3 RTP Consent Parameters Update

TBC

3.4 RTP Cancelation Process

TBC