Change Request: PISP Bulk payment support
PaulGregoryBaker opened this issue · comments
Open API for FSP Interoperability - Change Request
Table of Contents
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:
- 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.
- 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:
- Fraud associated with manipulation of the address list. (Pre-validation of the address list would be advantageous.)
- Fraud or errors with amounts. (Solution should support using maker-checker flows.)
- 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:
- 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.
- The PISP initialtes a payment request to the Payer DFSP.
- 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.
- Once the agreement is provided from the PISP to the Payer DFSP to proceed with the payment, the Transfer phase is executed using bulkTransfers
- 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.
3. Proposed Solution Options
___This should only be defined after the flow has been agreed to.
Add options to initial POST \ttpBulkTransactions payment request to affect the way in which the bulk payment is executed.
E.g.
- Process All or nothing
- 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.
Hello, I was going through this Change request and had few questions.
- 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.
- In case of Bulk PISP, how will the Payer DFSP be sure that the holder of account has authorized this request?
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.