search

mojaloop / mojaloop-specification

This repo contains the specification document set of the Open API for FSP Interoperability
https://docs.mojaloop.io/api
Other
20 stars 40 forks source link

[cross-currency] Support quote info from intermediaries #20

Open adrianhopebailie opened 5 years ago

adrianhopebailie commented 5 years ago

When a cross-currency payment is routed via and FXP the quote is modified by the FXP. E.g. The sender quotes a SEND in USD but the FXP quotes a SEND in EUR to the receiver.

The following document describes some of the flows and options for accommodating intermediary fees.

https://github.com/mojaloop/cross-network/blob/master/part2-johannesburg-april-2019/quote-flow.md

Let's use this thread to discuss and pick an approach.

henrka commented 5 years ago

Some initial comments:

If there is a need to see the FXP's fee in the quote, then it is incorrect to place this under payeeFspFee. This fee has nothing to do with the Payee FSP's fee. This should have a separate element called fxpFee or similar. (Alternatively the existing element needs to change its name).

Some examples also includes both a fee and a commision from the FSP fsp-red. This is not possible, either the FSP would like to have a fee to perform the transaction or it would like to give a commission to incentivize the transaction.

Should the payeeReceiveAmount also be in USD? Should you show an equivalent both?

The Payee only receives in one currency. Showing both in the existing element would not represent the amount that the Payee will receive, and might not even be possible due to FSP-internal fees or commission (not related to the API) which then have to be converted into the other currency using some FX rate.

MichaelJBRichards commented 5 years ago

It's a general principle of L1P that a customer should always be made aware of the fees that they will be charged for undertaking a transfer. So it seems to me that, if we are to allow FXPs to make a charge and that charge is to be borne by customers, then there will be a need to show that fee somewhere.

It seems to me that there are two ways in which we might support that. One is by adding fields to the quote, as Henrik suggests. My worry about that is that we might have a variable number of parties to an ILP transfer, and that we would therefore need to be careful about assigning individual elements to them. We could, I agree, obviate this by manipulating the cardinality of the element. Another way would be to allow a variable number of transaction objects to be returned, one for each participant. This would enable us to track the route of a transfer, and also offer an enriched set of information which participants could set or request. There could also be a hybrid model in which we supported multiple copies of parts of the response...

On Henrik's second point: there's nothing in the specification that I could see which states this; but, assuming that we were to make it explicit in the specification, might this be an example of something where we would also want also to test the Open API's ability to include it?

On Henrik's third point: it is standard functionality in money transfer services to tell me how much I'm sending if I've specified the receive amount, or how much the recipient will receive if I've specified the send amount. Although it might not be our place to mandate what an FSP should do, it seems to me that it might nevertheless be information which they would require and which we should therefore provide.

henrka commented 5 years ago

@MichaelJBRichards I'm not talking about showing the fees to the consumer or not, I'm talking about if there is a need to see specifically what each party in the transaction is charging (i.e. including the FXP as a separate party), or if it's enough to show the total fee. Of course the consumer should be able to see the total fee, L1P or not.

On my second point: It is not stated specifically in the specification that you cannot use both a payeeFspFeeand a payeeFspCommission, but they are the opposite of each other. They should not be used together. There is no purpose in both incentivizing a transaction and charging a fee for it from the same FSP (the Payee FSP).

On my third point: I'm not saying that we should not tell the Payer how much the Payee will receive. I'm saying that the Payee will receive in their accepted currency, why that is the currency that should be sent in payeeReceiveAmount. The Payer FSP can make an educated estimate of the receive amount in the Payer's currency if necessary, using the amount that the Payer's is paying and the payeeReceiveAmount.