Bank Service Initiation

Confirmation of Payee

1

None

Noted.

2

CoP business rules relating to Payer's LFI have been removed from the Standards draft 5, including the sentence below:

"LFIs MUST:

5.1 Request the OFP to perform Confirmation of Payee for the Payee Identification provided in the staged payment Consent. "

Does it mean that Payer's LFI doesn't have to or can't request OFP to perform Confirmation of Payee service? 

2. BR COP-2:

"TPPs MUST:

2.1 Send a request to the OFP in order to discover the LFI entity of the Payee that will be used to confirm the payee using the COP service and receive the information of how to make a Confirmation of Payee (COP) API call to the Payee’s LFI.

OFP MUST:

2.2 Resolve the request received by the TPP and respond back to the TPP with the information of how to access the COP service on the LFI entity that holds the Payee Account."

But BR COP-3:

"TPPs MUST:

3.2 Request the OFP to perform Confirmation of Payee for the Payee Identification provided by the User for the payment Consent.

3.3 Provide the necessary information to the OFP to execute the Confirmation of Payee service."

OFP MUST:

3.4 Make a Customer Data Request to the Payee’s LFI" 

Also in the Payee API design there is nothing indicating that TPP will make a Confirmation of Payee (COP) API call to the Payee’s LFI / access the COP service on the LFI entity so why OFP shares this information with TPP?

Correct, the payers LFI is no longer required to undertake CoP. This position could be reevaluated in the future. LFIs are not required to perform CoP as was defined in previous versions of the Standard.

LFIs are only required to return requested information in the Parties endpoint to be used for the CoP operation, as per the Bank Data Sharing functionality obligations defined in the Open Finance Standard.

BR COP-2

BR 2.1 refers to the activity of Discovery. Before a Confirmation of Payee (CoP) operation takes place, the TPP will need to resolve the LFI that will service the account properties request.

This is because the APIs for a given LFI are always physically separated in the OFP implementation.

BR 2.2 refers to the response of the OFP to the Discovery process. The OFP will return back to the TPP:

• the Authorization Server URL, where the Access Token to invoke the Confirmation of Payee operation for the beneficiary LFI entity should be sought, and

• the Resource Server URL, where the Confirmation of Payee operation for the beneficiary LFI entity should be invoked.

BR COP-3

BR 3.2 and 3.3 refer to the Confirmation of Payee endpoint call the TPP MUST make to the OFP to initiate the COP operation. As stated above, there will be a separate endpoint for each of the beneficiary LFIs, and the discovery process will help the TPP to identify the correct endpoint to call.

BR 3.4 Refers to the action taken by the OFP when the Confirmation of Payee operation for a specific LFI has been initiated. The OFP will make a Parties endpoint call to the beneficiary LFI in order to acquire the account name related to a specific IBAN. The OFP will then compare the payee name provided by the TPP and the account name retrieved by the the beneficiary LFI for the IBAN. The OFP wil respond back to the TPP with a Yes or No for an exact match or not. In case of not exact match the name will be returned back to the TPP both in full and masked format. The TPP is only allowed to show the masked name to the User for requesting their action to proceed or not.

Please note that there is no direct COP call of the TPP to the beneficiary LFI. The only COP call of the TPP is to the OFP specific entry for the beneficiary LFI and the OFP wil then make a call to a Data Sharing Parties endpoint at the beneficiary LFI.

3

FEEDBACK

4

We are Life Insurance Company this is not applicable to us

Yes, that is correct, this is not relevant to you subject to not initiating any payments to Users.

5

Please update document with details of use cases (e.g.: SIP) in which real time COP is required and uses cases (e.g.: TPP onboarded Merchants) in which offline COP is carried by TPP.

LFI are not required to perform COP.please confirm our understanding.

LFI are not required to store payee. please confirm our understanding.

CBUAE new beneficiary cooling period rule not applicable for OFP transactions. please confirm our understanding.

COP has been moved to a separate page and it is now referred to by the various payment functionality pages that need to use the COP service. In summary, COP can be used in the following cases:

• In the SIP and FDP journeys when the beneficiary is NOT a business onboarded by the TPP (e.g. for e-cormmerce payments) and therefore the user is providing the beneficiary details

• In Multi-Payments long-lived consent journey (with a single or variable-defined beneficiaries) when again the beneficiaries are not businesses or individuals onboarded by the TPP.

• In Multi-Payments long-lived consent journey (with variable beneficiaries) when the beneficiaries are not businesses or individuals onboarded by the TPP. In these cases, CoP will take place at payment initiation and User must explicitly authorize each payment initiation with the TPP.

• Similarly to c, for Delegated Authentication payments

Note: CoP is not relevant for International cross-border payments.

LFIs are not required to perform CoP as was defined in previous versions of the Standard. LFIs are only required to return requested information in the Parties endpoint to be used for the CoP operation, as per the Bank Data Sharing functionality obligations defined in the Open Finance Standard. This position could be reevaluated in the future.

LFIs must provide Users the option to select whether they want the beneficiary of an Open Finance payment initiaiton to be added to the list of beneficiaries for the user. User selects the option at the point of authorization of the consent.

If a user is added in the new beneficiary list, then any existing LFI processes related to the beneficiary are still relevant unless they are in conflict with the rules of the Open Finance Standard.

6

N/A