Versions Compared

Version Old Version 13 New Version 14
Changes made by

CBB Admin

CBB Admin

Saved on

Key

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

1. Introduction

Single future dated domestic payment Future Dated Domestic Payment allows the user/customer to post his/her consent at PISP to make a onetime one-time payment for a specific amount to a specific payee on a specific future date, wherein the PISP provides this instruction to the customer’s ASPSPs (banks)Banks). This use case details out the Customer Experience Guidelines and Technical API Specifications that are required to be developed and followed by both ASPSPs (Banks) and PISPs. The use case is applicable to both retail and corporate customers.

Few sample future dated domestic payments Future Dated Domestic Payments may include account to account transfers, loan re-payment, university/exam fee, merchant payment (including bill payments for electricity, water, telephone, cab, and ticket), restaurant/hotel payments, e-commerce payment, wallet payments, invoice and other corporate payments. This is similar to the single domestic payment, however the payment here is at a future date as against immediate payment in single domestic payment.

2.

...

Customer Experience Guidelines

2.1 Single Future Dated Domestic Payment

2.1.1

...

Customer Experience Journey

PSUs User/Customers can setup, through PISPs, an instruction to their ASPSPs (Banks) to make a one-time payment for a specific amount to a specific payee on a specific future date. The example reference journey illustrates account selection occurring in the PISP domain. However, please note that account selection can take place at the ASPSP (Bank) domain. For this scenario, please follow the approach of reference Section 1.1.3.

...

as documented in Single Domestic Payment a/c selection @ ASPSP (Bank) of Single Domestic Payment.

...

2.1.2 CEG Checklist and CX Considerations:

S. No.

Requirements and Considerations

 Participant

Implementation Requirements

 1 1

Minimum Set of Parameters

PISPs must either allow PSUs user/customers to specify the below minimum set of parameters or or pre-populate them for the PSUsuser/customers:

  • Payment Amount and Currency (BHD for Bahrain implementations)

  • Payee Account Name

  • Payee Account Identification details (e.g. account number and IBAN)

  • Payment Reference - This is optional but it is good practice to be populated for a paymentapayment

 PISP

 Required

2

PSU User/Customer payment Account Selection

PISPs must provide PSUs user/customers at least one of the following options:

  • Enter their Payer's payment Account Identification details

  • Select their Account Identification details (this assumes they have been saved previously)

  • Select their ASPSP (Bank) in order to select their PSU user/customer payment Account from there later on in the journey

 PISP

 Required

3

Execution Date

PISPs must allow PSUs user/customers to select the expected execution date for the payment by the ASPSPs (Banks)

 PISP

 Required

4

PSU User/Customer Consent to PISP

PISPs must request for the PSUsuser/customers' consent to the payment in a clear and specific manner. PISPs must display the following information in the consent screen:

  • Payment Execution Date

  • Payment Amount and Currency (BHD for Bahrain implementations)

  • Payee Account Name

  • Payment Reference, if it has been entered by PSUs user/customers or pre-populated by PISPs in item #1

  • PSU User/Customer payment Account Identification and/or the selected ASPSP (Bank) (based on item #2 options)

    • Note 1: if PSU user/customer payment Account identification is selected in item #2, PISPs should mask the PSU user/customer payment Account details on the consent screen. Otherwise, if the PSU user/customer payment Account identification has been input by PSUs user/customers in item #2, PISPs should not mask these details to allow PSUs user/customers to check and verify correctness

    • Note 2: if PSU user/customer payment Account identification is provided by PSUs user/customers in item #2, PISPs could may use this to identify and display the ASPSP (Bank) without having to ask PSUsuser/customers

For Payee Account Identification details (e.g. account number and IBAN):

  • If this has been provided by PSUs user/customers in item #1, then PISPs must also display this in the consent screen to allow PSUs user/customers to check and verify correctness

  • If this has been pre-populated by PISPs (e.g. in a ecommerce payment scenario) PISPs could may choose whether to display this information or not

 CX consideration:

  • PISPs should provide messaging to inform

PSUs

  • user/customers that they will be taken to their ASPSPs (Banks) to complete the payment

  • . Example wording: "You will be securely transferred to

YOUR

  • your ASPSP (Bank) to authenticate and make the payment"

 PISP

CX consideration:

 Required

5

  • Generic PISP to ASPSP (Bank) redirection screen and message

. Please refer to Section 2.2.5

 

SCA Authentication

 PISP

 Required

5

SCA-Strong Customer Authentication

SCA (including dynamic linking) must be the only action required at the ASPSPs (Banks) (unless supplementary information required, refer to section 1.1.3).

The ASPSP (Bank) authentication must have no more than the number of steps that the PSU user/customer would experience when directly accessing the ASPSP (Bank) channel           

 ASPSP

 Required

6

Additional Supplementary Information

ASPSPs (Banks) must display the payment details and any supplementary information about difference in actual execution date

CX consideration:

  • ASPSPs must inform PSUs (Banks) should inform user/customers about their “point of no return” for making the payment and that their payment will be made after pressing the proceed button. Example wording: "Press proceed to make payment”

  • ASPSPs must allow PSUs ASPSPs (Banks) should allow user/customers to review the information described above. The PSU user/customer can either proceed with the payment or cancel it, on the same screen using options with “equal prominence”

  • Generic Generic PISP to ASPSP (Bank) redirection screen and message. Please refer to Section 2.2.5

 ASPSP

 Required

7

PISP Confirmation

If received from ASPSPs (Banks), PISPs must display the information received from the ASPSP. This information may include:

  • The unique identifier assigned to the payment instruction by ASPSPs (Banks)

  • The payment status (and status update date & time) - Confirmation of successful payment initiation

If received by ASPSPs, PISPs must display any of the following information regarding initiation and execution of the payment:

  • The expected payment execution date & time

  • The expected settlement date & time (i.e. the value date of the payment)

  • The ASPSP (Bank) charges (where applicable)

 PISP

 Required

8

Further Payment Status Update

PISPs must follow up with ASPSPs (Banks) in order to check and update the PSUs user/customers with the most updated information that can be received by ASPSPs (Banks) in relation to the execution of the payment. For more details on Payment Status, please also refer to section Payment Status

 PISP

 Required

2.2 Cancellation of Single Future Dated Domestic Payment

2.2.1

...

Customer Experience Journey

PSUs User/Customers can setup, through PISPs, an instruction to their ASPSPs (Banks) to cancel a future dated domestic payment.Future dated payments Future Dated Domestic Payment. Future Dated Payments can also be amended or cancelled via the ASPSP’s (Bank’s) direct online channel (where supported). Cancellation of these payments must be consistent with available capabilities on ASPSP's (Bank’s) existing online platform, as well as, in accordance with the provisions of the regulations relating to revocation of payment orders. Note: PISPs can allow cancellation of only those specific payments that are initiated through the respective PISPs portal. PSU User/Customer needs to initiate the cancellation process atleast 48 hours prior to the existing execution date of the future dated paymentFuture Dated Payment.

 

...

2.2.2 CEG Checklist and CX Considerations

S. No.

Requirements and Considerations

 Participant

Implementation Requirements

1

Minimum Set of Parameters

PISPs must provide PSUs user/customers to view and select from the list of future dated payment Future Dated Payment initiated at the PISP

PISPs must allow PSUs user/customers to select only those payments that have at least 48 hours buffer from the execution date and time

`CX ConsiderationCX consideration:

PISP could may send notifications to PSUs user/customers with the following detail:

  • Last applicable date for cancellation of the initiated future dated payment Future Dated Payment from PISP portal

PISP

Required

2

PSU User/Customer Consent to PISP

PISPs must request for the PSUsuser/customers' consent to the cancellation of the future dated payment Future Dated Payment in a clear and specific manner. PISPs must display the following information in the consent screen:

  • Payment identifier assigned by the ASPSP

  • Payment Amount and Currency (BHD for Bahrain implementations)

  • Payee Account Name

  • Payment Reference, if it has been entered by PSUs user/customers or pre-populated by PISPs

  • Expected Payment Execution date

  • PSU User/Customer payment Account Identification and/or the selected ASPSP

 

CX consideration:

  • PISPs should provide messaging to inform

PSUs

  • user/customers that they will be taken to their ASPSPs (Banks) to complete the cancellation

  • . Example wording: "You will be securely transferred to

YOUR

  • your ASPSP (Bank) to authenticate and cancel the initiated payment"

PISP

Required

3

CX consideration:

  • Generic PISP to ASPSP (Bank) redirection screen and message

. Please refer to Section 2.2.5SCA

PISP

Required

3

SCA–Strong Customer Authentication

SCA Authentication (including dynamic linking) must be the only action required at the ASPSPs (Banks) (unless supplementary information required, refer to section 1.1.3).

The ASPSP (Bank) authentication must have no more than the number of steps that the PSU user/customer would experience when directly accessing the ASPSP (Bank) channel           

ASPSP

Required

4

Additional Supplementary Information

ASPSPs (Banks) must display the cancellation details and any supplementary information such as charges incurred, etc.

CX consideration:

  • ASPSPs must inform PSUs (Banks) should inform user/customers about their “point of no return” for cancellation and that their cancellation will be made after pressing the proceed button. Example wording: "Press proceed to cancel the initiated payment”

  • ASPSPs must allow PSUs (Banks) should allow user/customers to review the information described above. The PSU user/customer can either proceed with the cancellation  or cancellation  or terminate the process, on the same screen using options with “equal prominence”

  • Generic PISP to ASPSP (Bank) redirection screen and message. Please refer to Section 2.2.5

ASPSP

Required

5

PISP Confirmation

PISPs must display the information received from the ASPSP. This information may include:

  • The unique identifier assigned to the cancelation instruction by ASPSPs (Banks)

  • The cancellation status (and status update date & time) - Confirmation of successful cancellation of the initiated payment

If received by ASPSPs, PISPs must display any of the following information regarding the ASPSP

  • ASPSP (Bank) charges (where applicable)

PISP

Required

6

Further Status Update

PISPs must follow up with ASPSPs (Banks) in order to check and update the PSUs user/customers with the most updated information that can be received by ASPSPs (Banks) in relation to the execution of the cancellation

PISP

Required

3. API

...

Specification: Brief description

3.1 Domestic Future Dated Payment Consents

This API Specification document details out the Domestic future dated Payment Consent Consents resource that is used by a PISP to register an intent to initiate a Domestic Future Dated Payment.

...