Change Request: Extensions to 3PPI Interface

[mjbrichards]

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

___

This section contains basic information regarding the change request.

1.1 Change Request Information

| Requested By | Michael Richards, ModusBox | | Change Request Status | In review ☒ / Approved ☐ / Rejected ☐ | | Approved/Rejected Date | |

1.2 Document Version Information

Version	Date	Author	Change Description
1.0	2022-04-11	Michael Richards	Initial version of template. Sent out for review.

2. Problem Description

___

2.1 Background

We are currently working on interfaces between an open-source Health Management System (HMS) and the Mojaloop system. The purpose of the interface is to allow Mojaloop to function as the payment system for the HMS, allowing the HMS to trigger payments to suppliers (for instance, hosptials which carry out procedures on behalf of the HMS) and to the HMS itself (for instance, when participants in a health plan administered by the HMS pay subscription fees.)

The overall architectural plan is for the HMS to act, via a proxy, as a Third Party Provider (TPP) in the Mojaloop scheme. The HMS is not an account-holding institution, and should not therefore be a participant in the scheme.

As a consequence of this, new requirements have arisen. These requirements do not appear to be answered by the current status of the PISP interface. They are as follows:

Bulk requests

One of the activities performed by an HMS is the disbursement of health-related benefits: for instance, maternity grants to families with a new baby, or grants to support patients' rehabilitation after illness or health procedures. In the nature of things, these payments will tend to be regular disbursements to multiple recipients. At present, the PISP interface only supports a single request, but the requirement here is for the ability also to support bulk requests for payment in a form analogous to the existing bulkQuotes and bulkTransfers endpoints. This will allow Third Party Providers to offer standard services such as payroll management, as well as supporting the requirements of the HMS for bulk disbursements.

Requesting transfers without authentication

The HMS will need to support two types of payment request to the Mojaloop system. In the first, the payer DFSP will hold an account on behalf of the HMS: this pattern will be used, for instance, for the HMS to reimburse a hospital for carrying out procedures at its instruction. In these cases, we would expect that the PISP interface would work in the way it does at present, and the HMS would provide some form of authentication which would satisfy its DFSP that it had in fact instructed the payment. In other cases, though, the request to pay would be sent to a DFSP acting on behalf of someone other than the HMS: for instance, to ask a member of a health plan to pay a subscription which has become due. In this case, the HMS wants authorisationto be carried out by the sender's DFSP, in the same way as it would in the FSPIOP request to pay. So we need an endpoint which belongs to the PISP API, but allows a request to pay to be made with authorisation carried out by the sender's DFSP.

PISP as a recipient

Consider the use case described in the section above, in which a subscriber to a health plan pays their subscription after a reminder from the HMS. We also need to support the use case in which the subscriber decides to pay their subscription on their own account, without waiting for a reminder from the HMS. In this situation, it's fundamental to the use case that the HMS should be informed that the subscription has been paid: otherwise, it will continue to send reminders to the subscriber for payments that they have already made.

A simple way of doing this would be for the HMS to ask the subscriber to pay their subscription using an identifier that the switch will resolve to the PISP that is representing the HMS. This will notify the PISP that the subscriber is attempting to pay their subscription. The PISP can then pass the request to the DFSP which holds the account that the HMS wants to credit with subscription payments.

In order for the payment to be correctly recorded, however, it is not sufficient for the HMS to know that it has been attempted. The HMS needs to know what the outcome of the payment request is. The Mojaloop system will therefore need to have a way of registering that the PISP has a legitimate interest in knowing the outcome of the transfer. One way of doing this would be to put the responsibility onto the payee DFSP; but this would mean that the DFSP would need to be PISP-aware. This might not be a problem if the DFSP holds an account which is used by the HMS, since it would have to be possible for the PISP to initiate debits from the account. So as long as it is a good assumption that the payee DFSP would be PISP-aware, that solution would work.

2.2 Current Behaviour

None of these functions is currently available via the PISP API.

2.3 Requested Behaviour

Proposed behaviour is described in section 2.1 above.

3. Proposed Solution Options

___