Change Request: PISP Bulk payment support

[PaulGregoryBaker]

Open API for FSP Interoperability - Change Request

Table of Contents

• 1. Preface
  • 1.1 Change Request Information
  • 1.2 Document Version Information
• 2. Problem Description
  • 2.1 Background
  • 2.2 Current Behaviour
  • 2.3 Requested Behaviour
• 3 Proposed Solution Options

1. Preface

A PISP bulk solution should be designed to support salary payments for medium sized organisations. (Although this is not the only use case that PISP bulk would support, salary repayments is the use case that is well known, and covers the requirements of other use cases.)

The typical usage (not limited to) can then be described as:

1. The number of transactions included in the PISP bulk is typically 10-80.
   • Large organisation paying salaries will have direct connections to their bank, or be using organisations that have a similar service.
   • Small organisation are likely to pay salaries as direct individual payments.
2. Not intended to support large bulk payment for example G2P or beneficary payment, as these payment will be made using other mechanisms that have more controls in place.

These are the typical conserns with this use case:

1. Fraud associated with manipulation of the address list. (Pre-validation of the address list would be advantageous.)
2. Fraud or errors with amounts. (Solution should support using maker-checker flows.)
3. Salary payments are often performed by independent organisations. (Should consider a solution where a checkers is not part of the organisation.)

1.1 Change Request Information

To support the discussion on how this could be implemented, here is a sequence diagrams that describes how the PISP API V2.0 could be extended to perform a bulk PISP transaction.

Requested By	Paul Baker, Infitx
Change Request Status	In review ☒ / Approved ☐ / Rejected ☐
Approved/Rejected Date

1.2 Document Version Information

Version	Date	Author	Change Description
1.0	2023-07-26	Paul Baker	Initial version of template. Sent out for review.

2. Problem Description

Requered to extend the PISP API flow to accomodate a bulk PISP transaction.

2.1 Background

It makes sense that the PISP bulk API extension is made to the new PISP API I.e. v2.0.
This API is defined in detail in issue #89
In summary this flow simplifies the PISP interactions and leaves the heavy lifting with the Payer DFSP.
Another way of looking at it is:

1. The client first validated the address list with the PISP. If the names for the account holders are provided, then the PISP can support the client by validating that the Get Parties payee information corresponds to the names that are provided.
2. The PISP initialtes a payment request to the Payer DFSP.
3. Once the Payer DFSP validate the request, and executes the Aggrement phases using the bulkQuotes resource. Terms and fees are returned to the PISP for agreement.
4. Once the agreement is provided from the PISP to the Payer DFSP to proceed with the payment, the Transfer phase is executed using bulkTransfers
5. PISP is notified that the process is completed with the results showing successfull payments.

2.2 Current Behaviour

Explain how the API currently behaves.
Currently the API does not support PISP bulk payments which means that only DFSP (institutions that manage/hold accounts) are able to perform bulk transactions.
PISP individual payments require an authorisation for each transfers wich is not practical for this use case.

2.3 Requested Behaviour

Here is a sequence diagram to begin the discussion.

![PISPBulkSummary_v2.0.svg]

3. Proposed Solution Options

___

This should only be defined after the flow has been agreed to.

[PaulGregoryBaker]

Add options to initial POST \ttpBulkTransactions payment request to affect the way in which the bulk payment is executed.
E.g.

1. Process All or nothing
2. Specify how the funds are reserved to improve the chance of all the payments being successful.

• Innocent Kawooya and @alaink could you please get some feedback as to what would be appropriate / provide value to users here.

[karimjindani]

Hello, I was going through this Change request and had few questions.

1. The normal PISP flow requires the Account Owner (who has an account in Payer DFSP) to perform secure authentication on a device to Link their account and also every Payment initiation request is signed by them.
2. In case of Bulk PISP, how will the Payer DFSP be sure that the holder of account has authorized this request?

[PaulGregoryBaker]

Hi Karim, Thanks for the question. That is exactly the critical part of this flow. The autorisaction is the same as in the single PISP flow. I.e. the Payer account holder needs to authorise the payment by meeting a challenge that is provided. The difference is only the authorisation is for a bulk disbursement. Now the concern is that the person approving may not have the time to validate all the numbers being passed into the bulk request, and that this is a point of potential fraud. The suggestion is that in the originating bulk request, names are provided for each Payee identifier, and then the system can check that the put partised response returns the names provided. I.e. Making it much harder for that fraud to develop. Thoughts. Regards

…

On Fri, 3 Nov 2023 at 08:26, karimjindani ***@***.***> wrote: Hello, I was going through this Change request and had few questions. 1. The normal PISP flow requires the Account Owner (who has an account in Payer DFSP) to perform secure authentication on a device to Link their account and also every Payment initiation request is signed by them. 2. In case of Bulk PISP, how will the Payer DFSP be sure that the holder of account has authorized this request? — Reply to this email directly, view it on GitHub <#124 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJSI6KHPOA6EXZKAA62W6YLYCSTDZAVCNFSM6AAAAAA22LTLPSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJSGAZTOMZTGY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[karimjindani]

Ok, so the assumption here is that Payer is going to authorize a single request in which the Source of funds is a single account that will be debited and a single bulk payment request will go from Payer DFSP.

If yes, then it makes sense definitely to develop this. This will help Fintechs who provide front-end solutions Payroll and bulk disbursements.

[PaulGregoryBaker]

Bulk Salary payments is the use case that aligns to this. What is less clear are the other bulk disbursement use cases. Could you elaborate on other use-cases that you know of?

…

On Fri, 3 Nov 2023 at 09:13, karimjindani ***@***.***> wrote: Ok, so the assumption here is that Payer is going to authorize a single request in which the Source of funds is a single account that will be debited and a single bulk payment request will go from Payer DFSP. If yes, then it makes sense definitely to develop this. This will help Fintechs who provide front-end solutions Payroll and bulk disbursements. — Reply to this email directly, view it on GitHub <#124 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJSI6KGTAYEHHYL7ITOMEDTYCSYUHAVCNFSM6AAAAAA22LTLPSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJSGA4TGNBTG4> . You are receiving this because you authored the thread.Message ID: ***@***.***>