PISP - Third party Transaction Initiation in Mojaloop

Wednesday October 21, 2020
12:40 PM UTC

Session Leads: Lewis Daly (@lewisdaly), JJ Geewax

Session Description:

Updates from the PISP workstream

Session Slides: https://github.com/mojaloop/documentation-artifacts/raw/master/presentations/October%202020%20Community%20Event/presentations/mojaloop_pisp_pi12.pdf

Session Recording: https://www.youtube.com/watch?v=RvLoP4Tj8q8&list=PLhqcvNJ3bJt7U8ab05ayGv16-6n5jZOH2&index=27

Please post questions, suggestions and thoughts about this session in this thread.

Post by clicking the “Reply” button below.

You can find the slides for our presentation here

In the presentation, we plan to cover:

  1. Background
  2. Third-party APIs
  3. PI 11 Updates
  4. Design Updates
  5. Outputs
    • Account Linking
    • End to End Transaction
  6. Roadmap

For further discussion, a fundamental design principle for Mojaloop is that the central ledger has no knowledge or understanding of the transaction details. It is solely concerned with transfers of value. There is a cryptographic hash-timelock that protects the transaction details, as returned by the receiver during quotation; and the added ILP details supporting the individual transfer.

However, the central ledger doesn’t parse or process the transaction details.

The other requirement that adds complexity is that the hub must protect the integrity of anything sent to it. If data is returned from the hub to a participant, the integrity of that data must be ensured. That creates a service burden that does not directly support the central ledger’s core function—the clearing and settlement of transfers.

So let’s talk about why the hub must be involved in the transaction object traffic, given it was originated by the PISP. And ensure the central ledger is not involved in transaction parsing or integrity protection activities.

1 Like

@lewisdaly Hey Lewis! Thanks a lot for the presentation. Where can I access the docker-local mojaloop switch for local development? I’d love to switch to using that

1 Like

Hi @millerabel, I made a quick proposal yesterday in https://github.com/mojaloop/mojaloop-specification/issues/60#issuecomment-713367629, where Mojaloop is just acting as a proxy between the PISP and the FSP.

It uses the GSMA MM API between the PISP and the FSP for example to check balance and perform transactions. My reasons for suggesting the GSMA API is to enable reuse as many technology providers already support the API, promote industry collaboration and prevent fragmentation in the ecosystem. Mojaloop is then used for any actual transfer of funds between the Payer and Payee FSP, as is done today for transfers between FSPs today.

The implementation of this in Mojaloop should be easy, as Mojaloop should just be acting as a proxy between the PISP and the FSP, thereby minimizing impact on the Mojaloop while still avoiding a requirement of direct integrations between PISPs and FSPs (though a direct integration might in some cases be used, this setup does not prevent that).

1 Like

Thanks Peter! You can find it under ./docker-local on the PISP repo. It’s heavily geared towards the PISP environment, but it shouldn’t be hard to tweak it back to a vanilla mojaloop switch.

We’d love your feedback on using it and any thoughts on how we can spin it off into it’s own standalone dev environment. Ideally we could just send around a docker-compose file, but there’s tons of other config that we need to get it all working…

Ahhh cool. I’d have to be able to differentiate between what’s PISP environment-specific and rip that out. Cool. Thanks.

Yeah exactly. Mostly we have our own variations of core mojaloop images (they have -pisp appended to the docker image tag), and then there are other services (thirdparty-api-adapter, auth-service) that can be removed completely.

Feel free to reach out to me here or on slack and we can walk through it together.

Hi @henrik, I think I followed that thread. There is a similarity to the GSMA MM API, that’s true. But the fundamentals seem different to me.

The centralization of the PISP service is really a simplification. It enables more uniform onboarding of PISPs with full knowledge and supervision of the scheme, rather than one-by-one for each DFSP, and it avoids the integration requirements you mention. Not just at the network layer.

So then does it make sense to use an API designed for over-the-top through a DFSP—but proxied by the hub—to authenticate PISP applications, bind accounts, request balances, and initiate payments, but through the hub via proxy? This seems like double work for the DFSPs and friction for PISPs.

The situation in India for UPI is that PISPs must be sponsored to the scheme by a bank. All message traffic is forced through a financial partner’s technical systems, even though the PISP is not a financial intermediary nor a party to the transaction. That over-the-top indirection adds friction. So enabling proxy access via direct connection to the scheme network exchange is a routing and access simplification.

Where a hub is providing network proxy services as a network service exchange, but not as an application server, most any API would work fine and solve for most of the UPI friction. That’s how bank messaging works… bilateral messages exchanged across a private network with centralized credentialing. If the GSMA MM API were acceptable, it could be used bilaterally between the PISP and the payer DFSP through the central hub network exchange with centralized credentialing in the same way.

But if the Mojaloop system exposes a service API, with service guarantees and supervision, we have to think about identification, authentication, authorization, and accounting, and we have to handle any message forwarding more actively. And we’d want to do this consistently for all APIs, not differently for PISP than we do for DFSPs.

The PISP work focuses on authenticating a user request to direct funds from one account, not hosted by the PISP, to another account, also not hosted by the PISP. This feels a lot like merchant request to pay. That’s been the jumping off point for the current work. But unlike merchants, a PISP has no legal reason to associate with any specific DFSP or account-holding institution.

And also unlike merchant request to pay, the significant interaction for PISP is with the payer DFSP, as an extension of the customer-side of the DFSP logic, and not via the payee DFSP or via the hub transfer logic.

So some questions arise:

  • Since all account hosting DFSPs must recognize every PISP that is authorized by the scheme to serve in this role, and that a DFSP’s customer must individually grant specific third-party access to each specific scheme-authorized PISP for their specific account(s), can the service hub centralize this onboarding and supervision (aside from just proxying messages)? If so, then the PISP looks more like other direct participants to the scheme and that simplifies management.
  • Can the GSMA MM API Request-to-Pay function be more easily modified to support PISP than the Open DFS API Request-to-Pay can be? And even if it could be, wouldn’t there still be revisions to the Open DFS API required to support the PISP function such as active notification of committed transfers? What would these minimal changes be?
  • Given that schemes can mandate implementation of the core access API (the Open DFS Interoperability API) but are less likely to mandate specific over-the-top APIs like the GSMA MM API or Open Banking APIs, wouldn’t that tend to chill adoption of the PISP concept?

Should we revise the single Open DFS Interoperability API so it interconnects all customer-facing payment application platforms as scheme participants?

Or do we see the GSMA MM over-the-top API as preferred for hosting non-deposit PISPs?

— Miller

Awesome. Sounds good. Will do…Thanks!

Thank you @millerabel very much for your detailed answer!

Yes, I very much agree. Using the word proxy was a simplification from my side, there would still need to be identification, authentication and authorization performed in Mojaloop to ensure trust in the scheme.

May I ask you for more details on why you think the PISP should have a significant interaction with the Payer FSP for a Merchant request to pay, instead of the FSP where the merchant in this case would have an account?

To me, the most logical would be that the merchant would send a request to its PISP, the PISP would subsequently request the merchant’s FSP to initiate the Merchant request to pay. My reason for this is that there is only a grant/agreement between the Merchant, the PISP, and Merchant’s FSP. The Merchant’s FSP would then handle the request as if it had been done via its normal existing front-end API directly from the Merchant (without PISP involvement). For a Merchant request to pay, this would mean the Merchant’s FSP would either:

  • In case of on-us transaction: The Merchant’s FSP would send an approval request to the Consumer. If approved, the transaction would be performed internally within the FSP.
  • In case of off-us transaction: Use the FSP Interoperability API to request a transaction from the Consumer FSP (the Payer FSP). As this is a Payee-initiated transaction, there would be an approval request sent from the Payer FSP to the Consumer. This approval request could be either direct from the Payer FSP, or if the Consumer is also using a PISP then the approval request could be sent from the Payer FSP to the Consumer’s PISP instead.

After the request has been handled as either an on-us or an off-us transaction, there is a callback sent to the Merchant’s PISP to inform about the outcome of the transaction.

Yes, I think the service hub should centralize the onboarding and supervision. As said earlier, using proxy was a simplification from my side. The difference for me is what kind of service that a PISP role vs a FSP role offers through the Switch:

  • An FSP role offers interoperable transactions to and from other FSPs, which is a pure back-end service.
  • A PISP role offers services for end users (e.g. consumers and merchants), a pure front-end service. If an end user would request a transaction to/from a user that is located in another FSP compared to the end user, the FSP Interoperability API offered by the FSP role would be used to help the Consumer’s FSP to transfer funds to/from the other FSP.

It’s also possible that an FSP would want to take on the role as a PISP…

To me, it seems like there is more work needed to change the POST /transactionRequests into something that can be used for third party requests. Two main issues are:

  • On-us transactions, as these transactions could be performed directly in the FSP.
  • Notification of committed transfers, as you mention, that there is now potentially three parties (or possibly even four if theoretically both the consumer and merchant would use a PISP) that needs to be notified of a commit.

Both these issues can be solved using a front-end API; the on-us transactions are handled just as normal within the FSP without even involving Mojaloop, and the notification of the committed transfer to the PISP is done through the callback (please see the last flow in the referenced Github issue, the PUT /{X-Callback-URL}) after the transaction has been performed, irregardless if it is an on-us or off-us transaction.

This is very similar to how the FSP Interoperability API is implemented in at least our platform today, and I would assume our competitors have implemented it similarly. We have added support in our existing front-end API so that the same API services can be used for interoperable transactions as well. If the other end user is located in another FSP or not is agnostic to the user (or more correct to the user’s front-end application), they are still using the very same front-end API. The only change is a back-end API (the FSP Interoperability API) if the other end user is not within the same FSP. After the transaction is performed, the end user is notified via a callback just as normal.

Using the GSMA MM API as the front-end for the PISP would be very similar. The main issue in our platform is that we do not yet support the GSMA MM API, but many of our competitors do. As long as they have implemented the FSP Interoperability API in a similar way, as in hiding the FSP Interoperability API as a back-end API, it should be simple for them to support the GSMA MM API as the PISP API as well.

Please explain to me why the scheme could not also mandate the implementation of the GSMA MM API as the PISP API? If that is not possible, then I understand your concern that it would chill adoption of the PISP concept. A related risk that I see with reusing the FSP Interoperability API for this, is that FSPs can seem to be forced into supporting PISPs as some changes would be necessary in the FSP Interoperability API to introduce support for PISPs.

My suggestion would be to include a stricter Mojaloop-version of the GSMA MM API as the default PISP API in Mojaloop, then allow schemes to mandate the implementation. As this is then the default PISP API supported by Mojaloop, it should be simple for a scheme to mandate this API. To me, this is similar to how a for example a central bank-controlled scheme could potentially mandate another API than the FSP Interoperability API.

At least to me, there is a value of splitting this into an end user facing (front-end) API, and a system to system integration (back-end) API, as I have tried to explain above. My main wish is that this topic is at least discussed in the community, so that we can make an informed decision.

If you think it would be beneficial, I can add some more detailed example flows of how I would see the GSMA MM API as the PISP API. I would also be happy to help out in any other investigations necessary as part of this.

Kind regards,
Henrik