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,

Thanks Miller - I think I’m understanding this point a little clearer now.

I’ve posted a reply to mojaloop-specification#68 which goes into detail about what we are proposing with the Transaction object.

I think perhaps we need to be creative with how we can maintain a list of interested parties among participants to a transaction, while also adhering to these fundamental design principles.

I think this is a good principal.

I don’t think it means the hub can’t also be responsible for publishing notifications to subscribers whenever it processes a transfer and for those subscribers to include entities other than the payer and payee DFSP. But we should look at the pros and cons of adding such a feature.

Based on this thread and the discussion in https://github.com/mojaloop/mojaloop-specification/issues/68 it seems like the presence (or not) of that feature is the main point of contention to deal with first before we decide on the mechanism of subscribing (if we do want to add the feature)

Q: Is it a valuable feature of the API to allow any participants in a transaction to subscribe to notifications of the outcome of the transfer?

The implications of such a feature are:

  1. The notification sending machinery of the hub must somehow be provided with a list of participants and send a notification to all of them. That list MUST be provided WITH the transfer so the hub doesn’t need to store the list and recall it later when processing a transfer completion/timeout/rejection
  2. Multiple participants will be notified of the outcome of a transfer in an unpredictable order (the notifications are all sent by the switch at the same time so we can’t know who gets/processes them first)
  3. The payer DFSP doesn’t need to do any additional work after processing the transfer.
  4. The switch will need to sign the notifications OR they will have to be re-broadcasts of the transfer callback from the payer DFSP.

So some questions to ask regarding these:

  1. Are we okay with the switch now being the originator of messages and having a signature or will the messages that are sent by the switch to multiple recipients going to have a signature from the original sender (i.e. the transfer callback from payee DFSP is simply forwarded to all subscribers with the payee DFSP signature)
  2. If the subscriber list is not in the transaction object, where can we put it? What about making the FSPIOP-Destination header an array?
  3. Since the hub is the definitive reference for whether or not a transfer has completed do we care if other participants are notified in an unpredictable order?

What’s the process for us getting to a definitve decision on this? Can we have a call or can @millerabel and @Henrik join a DA call?

1 Like

I would like to know the answer of this question first, before going into any actual design and implications of a potential subscription and notification.

What are the actual use cases for the Switch to notify other participants?

  • For PISP, the user has their account at one of the FSPs, which at least in my mind means that it should be the User’s FSP that delivers the notification to the user’s PISP based on the accounting relationship between the User and their FSP.

@adrianhopebailie, do you envision any other use cases where it is the Switch that should deliver a notification to some other participant than the Payee FSP or Payer FSP?

I can join a call to discuss this. Regarding involving DA, I would assume that we should decide first if it is a valuable feature or not?

Kind regards.

There are 3rd-party initiated on behalf of the payer and on behalf of the payee so that’s 2.

Also, there is already an implicit subscription to the notification by the payee DFSP when it responds to the transfer (via the callback) with a state of RESERVED instead of FULFILLED.

In all 3 of these, the notification from the hub to the payer DFSP is also sent to at least one other participant.

My understanding is that @MichaelRichards and @lewisdaly were hoping to come up with a generic pattern for this that applies to all use cases.

Thanks @adrianhopebailie,

These are not initiated through the Payer FSP or the Payee FSP, they are initiated directly towards the Switch? If these are actually sent directly to the Switch, as it is actually the Switch that is providing a service for the 3rd party, then the Switch should already know that the notification should be sent to the 3rd party?

Is this flow described somewhere? Please note that is not really supported in the FSP Interoperability API to initiate a transaction from a 3rd party (a party other than the Payer or Payee FSP), though it is technically possible to do it.

Yes, that is why I wrote other than the Payee FSP or Payer FSP, as this is already supported.

Kind regards,

This is a long thread. I believe I could give examples of it being valuable with real world examples. But i would rather do it in the context of ensuring i understand the overall flow of this conversation and the design decisions in play. If we have a call, feel free to add me to the conversation. the “is this valuable” and “why” is where Product Council will surely want to support :slight_smile:

Thanks @Henrik,

I’ve been reading through this thread and your proposal here.

I can see that you are coming from the PISP “issue” (if I can use that word) from a wider perspective than how I have been thinking about it. My scope is mostly limited by my experience with the FSPIOP-API in isolation. Thanks for bringing this fresh perspective of a wider ecosystem into my sights!

I certainly see the value in not needlessly creating more APIs than what we need - although I worry about fragmentation if we produce slightly different versions of the same API. A “Mojaloop Version” of the GSMA MM API could be harmful to both ecosystems by muddying the water and requiring integrators to maintain 2 integrations, which defeats the purpose of a shared API.

I’m not sure I agree with your classification of the FSP and PISP roles. It seems to me that both roles are pure system integration (back-end) roles that don’t mandate the APIs that FSPs and PISPs expose to their end users. The FSPIOP-API is concerns with things such as Parties, Transfers, Quotes and the Thirdparty API (in its draft status) is concerned with Transaction Requests, Parties, Authorizations.

The GSMA MM API (as I understand it) is an API for FSPs to expose to their end users - it is a front-end API. Using a front-end API for back-end purposes (ie. the messaging between a PISP and an FSP) seems a little troubling to me. But, as I write this, I think we need to reach a firmer shared understanding of how to define ‘front-end’ and ‘back-end’ in this context.



Thanks @lewisdaly,

The Mojaloop version would not be another version more than that it is a stricter implementation of the GSMA MM API. It would not change any types in the API or similar. The GSMA MM API as it is today is a very open standard, which makes it kind of simple to implement as you can pick and choose how you want it to behave. The problem is that it leads to fragmentation, someone who has integrated towards one FSP can’t expect the integration to work to another FSP that has implemented the same standard.

I’m trying to influence GSMA to make it stricter as part of my existing work. My hope is that there would not be a need for a stricter Mojaloop version, so that they would be fully aligned from the start. There are discussions of a new major version (version 2) of the GSMA MM API, maybe we could work together with GSMA to create a version that is stricter and as such better suited for interoperability?

The GSMA MM API is used as both a front-end and back-end API. To me, the PISP can be seen as another front-end for the user to communicate with its FSP.

See also related discussion in https://github.com/mojaloop/mojaloop-specification/issues/70, regarding how much a PISP needs to be involved in a transaction.

Kind regards,