Multi-hop on Mojaloop - Githubissues

NicoDuvenage commented 5 years ago

Request:

Urgent discussion regarding the design and implementation of a Multi-hop functionality on Mojaloop is required.

Artifacts:

[ ] Artifact to consider [@Contributor]

Decision(s):

[ ] Actual decision made as a result of discussion

Follow-up:

[ ] Alternative actions

Dependencies:

[ ] If Applicable

Accountability:

Owner: [ @adrianhopebailie ]

Notes:

NicoDuvenage commented 5 years ago

From Adrian Hope-Bailie to Everyone: (17:33)  https://bit.ly/2JDBt1J

adrianhopebailie commented 5 years ago

Feedback from a discussion today

I believe we have agreement on the following (let me know if not)

There is a difference between a transfer and a transaction
A transfer is a single hop. It is a single currency clearing of funds from one DFSP to another and is proxied through a switch.
A transaction is a chain of transfers, executed in sequence that may go through the same switch (e.g. Mowali FX use case) or multiple switches.
A message (e.g. from DFSP to Switch) contains a signature in the form of a JWS
Current expectations are that a transfer SHOULD involve the same message sent from the Payer FSP to Switch and Swtich to Payee FSP. i.e. The signature is the same.
Where the switch needs to supplement the message (e.g. with a change to the expiry time of the transfer) this will be done additively using headers that can be excluded from the message during JWS validation at the Payee FSP
The switch MAY provide an additional way to validate the extra data (a second JWS) but this is scheme specific and not a Mojaloop feature today
The expectation is that the quote and transaction ids will be end-to-end (i.e. the same for all hops) whereas the transfer id is unique per hop.
The condition and fulfilment are also end-to-end and the scheme rules will define HOW they are generated. In the Mojaloop case the recommendation is that the fulfilment is an HMAC of the transaction object (using a MAC key known only to the Payee FSP)

Actions:

The transaction object needs to be updated to provide more detail on the agreed transaction (note that when the Quote is for a specific RECEIVE amount, the send amount is not known at the time the transaction object is created at the Payee FSP therefor it can't be used as input - to be discussed further)
Discussion with existing implementors on adjustments that may be required to accommodate the above

adrianhopebailie commented 5 years ago

See sequence diagram here

We have elected to follow Option A as a model

adrianhopebailie commented 5 years ago

@MichaelJBRichards have you had any feedback from your discussions with implementors that would add some detail to this.

@elnyry what are our next steps?

MichaelJBRichards commented 5 years ago

@adrianhopebailie Yes, I have. I have a revised Mowali proposal in the form of a sequence diagram to which I am adding a presentation. I will circulate that to the DA participants from the discussion last week. It also covers some thinking about transaction objects. I'll make sure that I upload it here...

millerabel commented 5 years ago

I’m not following the Option A sequence diagram which appears to show a full path from payer to payee DFSP, which would not be possible in a cross-system environment. And it shows use of the FXP in a mode that I don’t follow. I understood the role of the FXP as an _intermediary facilitator. It is a member of two schemes and can handle all foreign scheme addressing and routing. So all quoting and transfers flow through the FXP, and are not directly addressed to the payee.

In the domestic, cross-currency case (which is a pretty narrow case), there are other optimizations, given that the FSP’s can directly address each other during quotation and transfer, but the switch must then handle multiple settlement currencies.

I’m not sure which scenario we are discussing, but don’t really see the fit of Option A to any of the common scenarios. Sorry for being dense. I’ll wait for the proposal, but please explain the (several) scenarios that give rise to FX treatment so we know which we are discussing.

NicoDuvenage commented 5 years ago

I will table this for the DA meeting tomorrow (Jul, 24) for discussion and clarification.

adrianhopebailie commented 5 years ago

@millerabel - repeating my comment from Slack:

This sequence diagram shows two scenarios:

domestic p2p (i.e. 2 DFSPs and a switch)
in-network cross-currency as being implemented by Mowali (i.e. 2 DFSPs and an FXP and a switch all part of the same network/scheme)

We have assumed that, even though there are two settlement ledgers at the switch, the cross-currency transaction consists of two transfers (one in each currency) and the FXP is the payee of the first transfer and payer of the second.

In the Mowali case the FXP happens to be the same legal entity that runs the switch. i.e. This is the same way an FX transaction across two systems would be performed (two distinct domestic transfers) however in this case both transfers occur in the same system.

MichaelJBRichards commented 5 years ago

I promised at the end of the Design Authority meeting last week that I would revisit the proposed FX design for Mowali and propose a way in which it would align more closely with the ILP pattern for transfers. I attach a proposal which I think does this, together with a sequence diagram showing how a parties/quote/transfer process would work and the detail of the message content.

This model is relatively light on switch development, but requires the DFSPs to do more work than the original proposal, one of whose objectives was to minimise the amount of work required of DFSPs. It is also based on a set of assumptions about how the proposed changes to the ILP packet and the Transaction object will eventually be agreed. I think that these are documented in the sequence diagram; but I don't think that the proposal depends on them being solved in that particular way.

I'm afraid the sequence diagram is too large to be properly converted into a png file, and Github doesn't seem to allow the upload of svg files, so I have uploaded the source file. Let me know if you'd like me to mail the svg file.

ILP FX Transfer.txt Mojaloop aligned Mowali FX Proposal.pptx

mdebarros commented 5 years ago

@adrianhopebailie I think it would be great to have an SD where we can visualise the use-cases of where/when Condition-Fulfiments are generated.

MichaelJBRichards commented 5 years ago

I thought that our objective was that, in all cases, the Fulfilment and Condition should be generated by the (eventual) Payee DFSP at the point when the Payee DFSP approves a request for quotation. Have I misunderstood?

MichaelJBRichards commented 5 years ago

Mojaloop aligned Mowali FX Proposal.pptx

FX ILP for Mowali.pdf

Revised version of the presentation and the sequence diagram, based on our discussions yesterday.

MichaelJBRichards commented 4 years ago

Action is now with me and Adrian to review and propose changes to the Open API specification to support the agreed position

adrianhopebailie commented 4 years ago

Apologies for the delay in completing this. Aiming to have it done by 30 Aug

adrianhopebailie commented 4 years ago

Work on this is being done here: https://github.com/mojaloop/mojaloop-specification/pull/22

adrianhopebailie commented 4 years ago

@NicoDuvenage this can be closed, as I said above it is now being tracked in the API specification repo