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

___

[Henrik Karlsson]

Regarding "PISP as a recipient", is it really important for the HMS to receive the information about the incoming payment in realtime?

It seems easier to allow the HMS to use the PISP API to ask for its transaction history in the FSP where the HMS has its account, filtered by for example incoming payments and the identifier. This would allow the HMS to ask for the status of the payment before sending out a reminder.

[Miller Abel]

It seems to me in reading the description, the HMS is acting in all these cases as a merchant or merchant service provider. Bulk distribution of someone else’s money, as in the first case, requires some form of authorization of the account holder. This is true for 1:m bulk payment in general. I think this is just a bulk payment use case. There are two different use cases in the “requesting transfers without authentication” (though I found the heading misleading). 1) In the first sub-case, the HMS is just a payer. The PISP need not be used, and the HMS may use the bulk pay interface offered by its hosting DFSP. 2) In the second sub-case, the HMS is just a merchant requesting payment. The PISP need not be used for this type of transaction. the HMS may use the merchant request to pay via its hosting DFSP. It seems we are trying to create a new actor in the system that participates directly though the PISP but is not a neutral payment initiator: the HMS is a value-holding participant, unlike a wallet provider. If the HMS is to provide service to hospitals and their patients, by servicing health spend accounts or insurance of some kind, they are a merchant service provider, but not necessarily a participant in the clearing system. A licensed deposit taking financial institution may specialize to provide a health spend account, but then is just a bank to the scheme. It uses the normal participant interfaces and participates in settlement. And it is free to hire a service provider to simplify its technical access to the scheme. Even if these two roles might be combined, they are still separate roles within the scheme. On address resolution The clearing scheme will not likely find the HMS within its administrative authority (unless it’s a bank or other licensed payment service provider) and so the scheme will not rely on an HMS to resolve payment addressing. That is, only direct (or indirect) participants can map account aliases through the ALS, as these addresses are relied upon for all clearing and settlement use cases and presume participation in settlement. So the case of a subscriber paying an HMS requires the use of normal API facilities and over-the-top integration with a merchant service bank or other FI. That’s the private business of the HMS and it’s bank, and seems not something the scheme needs to directly accommodate. Are we forcing this new type of hybrid actor unfairly onto PISP? — Miller On Apr 12, 2022, at 9:50 AM, mjbrichards ***@***.***> wrote:  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

___ — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.

[mjbrichards]

Thanks very much for your comments, @millerabel and @ehenrka; and my apologies for my delay in responding. Let me take Miller's comments first.

It is of course true, Miller, that, as you say, no new features are being added to the interface here: there are already bulk payment and MRP facilities available via FSPIOP. However, there are characteristics of this use case that made me think it would be more productive to manage these via the PISP interface than the FSPIOP interface. We are working with the OpenIMIS project to provide a generalised interface between HMSs using OpenIMIS and payment schemes using Mojaloop. If we were to use the FSPIOP interface to implement the use cases we require, then the interactions between the HMS and the Mojaloop scheme would be mediated through the particular implementation structures provided by the DFSPs which were holding the accounts of the HMS. There is no guarantee that DFSPs in different schemes would implement, for instance, bulk functionality in the same way; nor even that different DFSPs in the same scheme would implement the same external interface for their bulk functionality, and there's no obvious reason that I can see why an HMS shouldn't maintain accounts at different DFSPs in a single scheme for different purposes. OpenIMIS would therefore need multiple adapters to perform the same function in different schemes, whereas extension of the PISP interface would allow any OpenIMIS system to interact with its single or multiple account-holding DFSPs in the same way, without requiring the DFSPs themselves to do anything more than support the (new version of the) standard PISP interface. This seemed to me to avoid the potential problem that we might re-introduce point-to-point interfaces through the back door, and in general to reduce substantially the amount of work required to implement interactions between an HMS and a payment scheme.

With respect to the question of authentication, I want to assume that my argument in the preceding paragraph is convincing. If it is not, and we intend to use the FSPIOP interface to manage these interactions, then you are completely right: there is no need to make any changes to authentication, because it will be outsourced to the direct interaction between the HMS and the DFSP(s) which manage its accounts. If we are, however, then I think that there is a need to extend the current authentication functionality - perhaps as I propose.

I agree with your assertion that we're trying to create a new actor in the system, but it seemed to me that the HMS was exactly the kind of actor which we are trying to support via the PISP interface: that is, an actor which wants to add value to a Mojaloop scheme, and to the society and the economy in which it operates, in ways that include initiating payments; but which doesn't want to, or can't, be an account-holding institution itself. These include people who, like Google, add value to the consumer payments experience; but I think that we always expected that the interface would also support people who wanted to add value in different areas, for instance the M-Kopas of this world. I was struck by the way you formulated it at the convening: that we want to support institutions which are not in themselves providing payments services, but "where payments are contextualised in their services".

When I started thinking about how we might integrate an HMS with a Mojaloop scheme, it seemed to me that the HMS was exactly of this kind. Its main focus is on the administration of health services; but, as part of that, it needs to be able to execute payments and receive notification that payments have been made to it. For the reasons I outlined above, it seemed to me more efficient for the HMS to operate as a TPP in a Mojaloop scheme. We're not, however, creating a new kind of actor in the sense that an HMS is a specialised kind of TPP. But its requirements do highlight qualities that TPPs in general will require from the PISP interface: for instance, the ability to ask for subscription payments in a standard way, or the bill payment requirements proposed for the PISP as a recipient part of the proposal. As you say, @ehenrka, we could implement that as AISP functionality; though that would itself require an extension to the existing structure of the PISP interface if we wanted to provide a generalised way of doing that. Here I think that the argument is the same as it was in the first part of this discussion: if we rely on providing this information via a pre-existing relationship between the HMS and the DFSP(s) that hold its accounts, then each implementation of the HMS will need to make point-to-point connections with its DFSP(s); whereas providing this functionality via the PISP interface will allow the HMS to interface with any DFSP which supports that interface...

[Henrik Karlsson]

Another option which should be in line with @millerabel s comment and also providing a generalised interface in line with @mjbrichards comment would be for the HMS to use the GSMA MM API towards their FSP. The FSP would then use the FSPIOP API and Mojaloop for transactions where the counterparty is within another FSP.

This would allow the HMS to use a standardised interface towards the FSP (GSMA MM API) and the FSP to use a standardised interface between the FSPs (FSPIOP API). It would also mean less work for the FSPs who have already implemented support for both and Mojaloop can focus on other important requirements.

[mjbrichards]

Thanks for your comment, @ehenrka, and my apologies for taking so long to respond to it. I don't believe that the GSMA MM API is at present well adapted for use in this context: specifically because, although I see that they have now added a quotations endpoint, there does not appear to be an equivalent bulk version of this (unless I've missed it,) and we would not therefore be able to use it to implement a bulk transfer which included an agreement of terms. They could add this, of course, and perhaps they will; but for the moment I think it does not meet our needs.

I have some further thoughts in this area; but I will comment separately and wind in a conversation which @millerabel and I started following our discussion at the convening.

[mjbrichards]

@millerabel commented on the PISP issue as follows:

The main purpose of the PISP is to facilitate (broker?) the connection between a debtor and a creditor without the responsibility of participating as a financial intermediary for one or the other.

Whereas a merchant has the need to be paid by various customers, but typically into a single well-published merchant account. (And this is what QR codes do very well.) And acquiring and processing transactions for merchants is the business of bank and non-bank financial intermediaries who participate in the scheme. The merchants’ customers benefit by wide acceptance of their chosen payment method, and the merchants benefit from relative portability between merchant banks.

While there is not yet a cross-scheme QR code that works equally well in multiple markets, schemes are deploying their own merchant registries and QR codes so each market will have one. And markets are dabbling at scheme interconnection. (e.g., Thailand and Singapore).

What is less well developed and less widely deployed is the standardized over-the-top API for merchants that want to use an acceptance strategy that is not based on QR codes (like M-Kopa). The GSMA has their Open Payments API (https://www.gsma.com/mobilefordevelopment/mobile-money/mobile-money-api/), and banks have Open Banking (https://www.openbanking.org.uk/, and https://www.openbankproject.com/).

See also Barclays for a good primer on open banking, who it’s for, and how to enroll as a fintech: https://developer.barclays.com/open-banking

It is tempting to follow the Open Banking lead and see PISP as the replacement for merchant acquirer interfaces. But it feels in conflict with the merchant registry and QR code strategies that TIPS and other schemes are deploying.

This is the center of the issue I think we should discuss.

I'd like to start by looking at the question of the relative merits of the two potential ways for a fintech to connect to a Mojaloop scheme in order to request or initiate payments. The first of these is by connecting to an API provided by the DFSP which holds the account or accounts which the fintech wants to interact with; and the second is by connecting to the PISP API in some potentially extended form.

In the first instance, the DFSP needs to provide the interfaces to support the functionality the fintech requires, and to connect them to its Core Banking System and to the Mojaloop scheme to which the DFSP belongs. Once this investment has been made, the service can be offered to as many fintechs as required without significant additional investment on the DFSP's part. The fintech needs to undertake development work to connect its app to the particular DFSP. If the account with which it interacts moves to another DFSP, or if it connects with multiple accounts at different DFSPs (as might be the case, for instance, with a payroll bureau or a savings aggregator,) then the connection work will need to be repeated for each DFSP. Where a fintech provides services on behalf of an account holder (e.g. payroll services,) the movement of accounts between one DFSP and another may take place at short notice.

Miller rightly points out that there are movements towards standardisation of the APIs offered by DFSPs, but I am less optimistic than is he about the real availability of these standards. The GSMA API is effectively restricted, as far as I am aware, to Mobile Money providers; and the Open Banking initiative has resulted in multiple different implementations of what was intended to be the same standard, such that intermediaries have found a profitable (though not, perhaps, socially useful) business in integrating access to the multiple different Open Banking APIs offered by individual DFSPs in particular markets. I think it was Herakleitos who remarked a propos of the Open Banking Standard that the Word is everywhere the same, but each woman behaves as if they had a private revelation of their own.

Overall, then, it is my view that connection via a DFSP's API makes more work for the fintech, and less work for the DFSP. There may, of course, be justice in this, since it is the fintech whose business benefits from the connection.

In the second instance, the work required from the fintech is less. Once a fintech has developed a connection between their app and the PISP API, they can connect to accounts held at any DFSP attached to any Mojaloop scheme, provided that the DFSP supports PISP interactions. Assessing the work required from the DFSP is more difficult. It is certainly easier to support a published and well-defined API than it is to develop your own; but in cases where DFSPs already provide some or all of the functionality required through their own APIs, this work will need to be duplicated. Once a DFSP has elected to provide support for the Mojaloop PISP interface, then, as would be the case with an internally developed interface, any number of DFSPs can be supported with minimal additional work by the DFSP.

It's also worth adding that the attractions of GPay may provide a powerful motivator for DFSPs to support the PISP interface. GPay offers DFSPs the powerful attractor of providing a high-function user experience for the DFSP's customers at no cost to the DFSP; and the UPI experience may provide supporting evidence for this supposition. If this is the case, then we would expect to see DFSPs connecting to the Mojaloop PISP interface in any case, and the overall cost arguments for fintechs to use the PISP interface become correspondingly more attractive.

So this is my current thinking about the relative costs and difficulties of connecting via DFSPs' own APIs versus the PISP API; I shall start a new comment relating to Miller's thoughts on merchant acquisition and QR codes.

[mjbrichards]

I'd like to comment on whether there is a conflict between allowing PISPs to provide merchant acquirer interfaces or not. It seems to me that we need to draw a sharp distinction between the aspects of this question that relate to KYC and the aspects that don't. Allowing a PISP to provide a merchant acquirer interface can only be additional to that merchant's acquisition of an account with a DFSP and its provision of the appropriate KYC information to allow the DFSP to open its account. Where the provision of a merchant ID also requires the evaluation of that KYC information by the scheme, as seems to be being proposed in recent extensions to the merchant ID interface, this will still form part of the relationship between the merchant's account-holding institution and the scheme; and I think that restricting the acquisition of a merchant ID to the account-holding DFSP is a reasonable constraint. So I think that there need not be any conflict between DFSP and PISP in this area.

I assume that regulations relating to the production of QR codes will be decided and implemented at the scheme level. As such, I'm not sure that I see any reason not to allow PISPs to produce QR codes, either static or dynamic, as part of the service they offer their merchant customers; provided always that these codes are consistent with the scheme's regulations. These QR codes will be processed by the customer's application and, I assume converted into a request for quotation, which will be directed in the normal course of things to the merchant's DFSP.

The question arises: are there circumstances where we would want to support routing of the request from the customer's application to the fintech rather than the merchant's DFSP? Well, an example might be: the merchant is using the fintech's application to total up the customer's purchases. When the goods are paid for, the fintech adjusts the stock levels for the items purchased and, if necessary, re-orders from the supplier. So the fintech needs to know that the bill has been paid; if the quote request went directly to the DFSP, this circle could not be closed; unless by the fintech having AISP access to the merchant's account and checking inflows into the account. An efficient way of managing this might be to support a form of AISP notification under which every movement relating to an account was reported by the account-holding DFSP to the fintech via the PISP interface. I would regard this as an acceptable substitute for supporting access to the PISP as the payee in a transfer, and I think it would be a simpler way of managing credits to the merchant's account. The other attraction of this way of proceeding would be that QR codes would work in exactly the same way for a merchant whose accounts are being managed by a fintech as they would for a merchant whose accounts are being managed by a DFSP.

So my feeling is that extending the forms of access available to a DFSP should not impact our strategy for merchant acquisition and QR code implementation, provided we were to adopt the proposed alternative to allowing a PISP to act as the payee in a transfer.

[mjbrichards]

Is anyone reading these comments? If so, does anyone have any thoughts on them?