Duplicate avoidance in GET /parties

[mjbrichards]

Request Summary:

Modify switch behaviour on receipt of a GET /parties message to avoid problems with duplicates

Request Details:

• Deadline: ASAP
• Impact (Teams): MMD team, TIPS team
• Impact (Components): ALS

At present, a GET /parties request is always routed to the appropriate oracle by the ALS. There are circumstances, however, where that is not appropriate. In particular, where there is a danger that a particular identifier (e.g. an MSISDN) will not map uniquely onto a DFSP, the fact that the API systax allows only for a single value to be returned will mean that the value returned from a GET /parties response may not be reliable.

The management of duplicate identifiers is an outstanding issue in the overall design of Mojaloop which needs to be addressed, probably jointly by the DA and CCB. In the short term, however, two implementers of Mojaloop schemes (MMD and TIPS) face the problem and need an immediate solution. In both cases, the requesting DFSP is in a position to know from its customer which DFSP they intend to transfer funds to.

The solution proposed to the DA is:

• If the requesting DFSP knows which DFSP it needs to route the GET /parties request to, then it should set the FSPIOP-Destination field in the request header to the ID of the DFSP to which it wants to route the request.
• If the ALS receives a request with the FSPIOP-Destination field in the request header present and non-blank, then it should route the request directly to the specified DFSP without passing it through an oracle.

This solution is simple to implement, solves the immediate problems of current implementers, and does not prevent a more sophisticated handling of duplicate entries when one is agreed. Effectively, it allows a requesting DFSP to say to the ALS: "thanks for your offer, but I already know who to ask about this account. Please don't trouble yourself." It will still be possible for the receiving DFSP to respond negatively via the PUT /parties call if it does not recognise the identifier or if it cannot accept transfers to the account.

Artifacts:

• [ ] Artifact to consider [@Contributor]

Dependencies:

• none

Accountability:

• Owner: @michaeljbrichards
• Raised By: @michaeljbrichards

Decision(s):

- **Approved By:** ### Details - [ ] Actual decision made as a result of discussion ## **Follow-up**: - [ ] Actions to implement the decisions

[elnyry-sam-k]

hi @MichaelJBRichards , the proposal looks fine to me (from implementation perspective at least)..

The FSP receiving the GET /parties can always respond with an error callback if the user ID isn't found..

In a way - this seems like an advantage of of the current spec, having separate calls - GET /participants and GET /parties :-)

[bushjames]

This proposal makes a lot of sense to me. I struggle to see any downsides at this point.

[mdebarros]

+1 from me.

[bushjames]

Discussed at DA weekly call on 2021-07-07. Agreement reached by attendees to accept the change. Discussion indicated no further documentation changes are required.