Solution Proposal: Track proximate sender for inter-scheme transfers

[MichaelJBRichards]

[Change ID] -- [Change Request Name]

---

Open API for FSP Interoperability -- Solution Proposal

Table of Contents

• 1. Preface
  • 1.1 Solution Proposal Information
  • 1.2 Document Version Information
• 2. Change Request
  • 2.1 Background
• 3. Proposed Solution
  • 3.1 Specify how IDs can be generated
  • 3.2 Add quote ID to POST /transfers data model
• 4. Other Considered Solutions
  • 4.1 Add transaction ID to the POST /transfers data model
  • 4.2 Force the Payer FSP to use the transaction ID as transfer ID

1. Preface

---

This section contains basic information regarding the solution proposal.

1.1 Solution Proposal Information

Change Request ID	Not used
Change Request Name	Track Proximate Sender for Inter-scheme Transfers
Prepared By	Michael Richards, INFITX
Solution Proposal Status	In review [X] / Approved [ ] / Rejected [ ]
Approved/Rejected Date

1.2 Document Version Information

Version	Date	Author	Change Description
1.0	2024-05-22	Michael Richards	Initial version of Proposal. Sent out for review.

2. Change Request

2. Change Request

---

2.1 Background

In an inter-scheme context, a payment may be forwarded between a number of schemes before it arrives at its eventual destination. Its overall origin and destination are designated in the FSPIOP-Source and FSPIOP-Destination parameters in the header, and both of those form part of the non-repudiation signature. Mojaloop wants, if at all possible, to retain the original non-repudiation signature so that the recipient (and, indeed, any intermediaries) can confirm that the message really did originate from the source DFSP, and that it has not been altered in transit.

On the other hand, Mojaloop switches which receive messages in what may be an inter-scheme context need some way to understand whether the message was forwarded to them via a proxy; and, if so, which proxy it was. This will enable the switch to store an association between the sending DFSP and the proxy, so that it can route subsequent responses to that DFSP via the correct proxy.

We would therefore like to have an FSPIOP-specific parameter in the header with the following characteristics:

1. It does not form part of the material over which the non-repudiation signature is taken.
2. A proxy can set the value of the parameter to its FSP idea in the scheme where it is forwarding the message. This will inform the switch:
   • That the message was forwarded by a proxy.
   • Which proxy forwarded the message.
3. An ordinary DFSP needs to know nothing of this mechanism. If a message is forwarded without the parameter, or with a null value in the parameter, then the switch should assume that the message was forwarded by a DFSP.

3. Proposed Solution

Table 1 of the specification should have another parameter added to it, as described in Section 3.1.2 below.

Example:

FSPIOP-Proxy: Proxy1

3.1.1 Current text

There is no current text.

3.1.2 New proposed text

• The name of the parameter will be FSPIOP-Proxy
• The content of the parameter will be the FSP ID of the proxy which forwarded the message, in the scheme to which the message was forwarded. For example: PROXY1.
• The parameter will be optional (Cardinality 0..1)
• The description of the parameter will be something like: The FSPIOP-Proxy header field is a non-HTTP standard field used by the API for HTTP header-based routing of requests and responses to the destination. If the message is being forwarded by a proxy, the field must be set by the proxy, so that any entities between the client and the server, as well as the server itself, can recognise that the message has been forwarded by a proxy, and which proxy it was which forwarded it. The server can therefore take action accordingly. If the message is being sent by a DFSP, an FXP or any other type of entity, then this parameter should be omitted or, if not omitted, left blank.

This change will be a non-breaking change. Existing calls in a single-scheme context will continue to work as they do now.

3.2.1 Addition to the HTTP Request header fields table (Table 1)

Field	Example	Cardinality	Description
FSPIOP-Proxy	Proxy1	0..1	The FSPIOP-Proxy header field is a non-HTTP standard field used by the API for HTTP header-based routing of requests and responses to the destination. If the message is being forwarded by a proxy, the field must be set by the proxy, so that any entities between the client and the server, as well as the server itself, can recognise that the message has been forwarded by a proxy, and which proxy it was which forwarded it. The server can therefore take action accordingly. If the message is being sent by a DFSP, an FXP or any other type of entity, then this parameter should be omitted or, if not omitted, left blank

4. Other Considered Solutions

---

We considered using the X-Forwarded-For parameter defined by W3C to hold an IP address for the proxy. After discussion, this was felt to be too complex and vulnerable to the value being changed by intermediaries for their own purposes.

[henrka]

Thanks @MichaelJBRichards, do we have the full end-to-end flow for inter-scheme transfers documented anywhere?

[MichaelJBRichards]

Here is an example:

[henrka]

Some questions on the E2E-flow above:

• Which scheme is FXP1 in? Can it be "reached" by both Zambia scheme and Malawi scheme?
• Seems to be some "Malawi international payments" account that is used for the transfer in the Zambia Switch, how will the FSP (in this case Zanaco) know that this account should be used? Or should they just use a standard account in the Switch for these kinds of transfer when there is a proxy involved?
• Are there any other requirements on the FSPs for the proxy header parameter?
• How will message signing work between schemes? For example when FSP Zanaco gets the message, it would probably try to verify the signature using the public key from the FSP in FSPIOP-Source, is this available somehow?

[MichaelJBRichards]

• FXP1 is in a regional scheme, which is accessible from all the jurisdictional schemes (Malawi, Zambia and so on...)
• The obligation is registered against the proxy. The proxy represents an account opened by the scheme to manage international (i.e. inter-jurisdictional) payments. It is also used to settle the jurisdictional schemes obligations to the FXP in the regional scheme.
• No, don't think so.
• In the first instance (COMESA) we will provide each participant DFSP with the public keys of all the other DFSPs. Eventually, I'd like to add an endpoint to allow a DFSP to request the public key of a named DFSP; but that's not required for MVP.

[henrka]

Thanks!

The obligation is registered against the proxy. The proxy represents an account opened by the scheme to manage international (i.e. inter-jurisdictional) payments. It is also used to settle the jurisdictional schemes obligations to the FXP in the regional scheme.

So is the FSP expected to use a pre-founded account for the proxy in case of international transfer? The internal switch reservations are part of the flow, but I don't know how it is expected to work in the FSP, for example for reconciliation purposes.

[MichaelJBRichards]

No, the FSP can use its normal pre-funding account if it is the payer (unless there is a separate settlement model for inter-scheme payments, in which case it will use another account). When the FSP is a creditor party in an international payment, then the switch will check liquidity cover on the international payments account before allowing the payment to proceed.

[henrka]

Thanks Michael, then I think it is fine from my perspective to add the suggested proxy header parameter.