Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change Request: PISP Bulk payment support #124

Open
PaulGregoryBaker opened this issue Jul 27, 2023 · 5 comments
Open

Change Request: PISP Bulk payment support #124

PaulGregoryBaker opened this issue Jul 27, 2023 · 5 comments
Labels
thirdparty-change-request Change request for the PISP / third party API

Comments

@PaulGregoryBaker
Copy link

PaulGregoryBaker commented Jul 27, 2023

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:

  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![PISPBulkSummary_v2.0.svg]

3. Proposed Solution Options

___

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

@PaulGregoryBaker PaulGregoryBaker added the thirdparty-change-request Change request for the PISP / third party API label Jul 27, 2023
@PaulGregoryBaker
Copy link
Author

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
Copy link

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
Copy link
Author

PaulGregoryBaker commented Nov 3, 2023 via email

@karimjindani
Copy link

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
Copy link
Author

PaulGregoryBaker commented Nov 3, 2023 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
thirdparty-change-request Change request for the PISP / third party API
Projects
None yet
Development

No branches or pull requests

2 participants