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

• PSU Payment Account or PSU PASP details (as per 8.2.5 PSU Payment Account Selection ). This is the account of the Sender of the RTP (Creditor account)

• Payer Identification details (as per 8.2.6 Payer Identification ). This is the Recipient of the RTP.

• RTP Expiry Window: This is the time window during which the RTP is valid. RTPs outside this window are expired. The start of the window is time of the PASP sending the RTP to the Recipient Bank. The window is measured in hours and MUST be less than https://ksaob.atlassian.net/wiki/spaces/BRS20231101final/pages/348554507/PIS+Configuration+Parameters#Max-RTP-Expiry-Window

• Note To Payer (as per 8.2.9 Note To Payer)

• Consent Validity Period (limited to https://ksaob.atlassian.net/wiki/spaces/BRS20231101final/pages/348554507/PIS+Limits+and+Constants#Max-Consent-Validity-Period):

  • 8.2.1.1.1 Set the RTP Consent Start Date and Start Time to the same date and time as the date & time of acquiring consent from PSUs.

  • 8.2.1.1.2 Set the RTP Consent End Date and End Time to the end of day (23:59:59) of date agreed with the PSU.

• RTP Consent Controls applicable (as per 8.3.2 Long lived RTP Consent Control 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.

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.

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.

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.

PISPs MUST:

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

• PSU Payment Account if part of the original consent (as per 8.2.5 PSU Payment Account Selection ).

• Consent Validity period.

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

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:

• Eitherselect to cancel the active RTPs together with the revocation of the long-lived consent.

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

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.

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.

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.

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.

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

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

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.

Note2: 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 PSU list of accounts with a specific PASP, making it easier for the PSU to select the payment account they want to use for receiving the payments.