Change Request: Modifications to /participants endpoint

Open API for FSP Interoperability - Change Request

1. Preface
- 1.1 Change Request Information
- 1.2 Document Version Information
2. Problem Description
3 Proposed Solution Options

1. Preface

This section contains basic information regarding the change request.

1.1 Change Request Information

1.2 Document Version Information

Version	Date	Author	Change Description
1.0	2024-06-12	Michael Richards	Initial version of template. Sent out for review.

2. Problem Description

2.1 Background

Where the identifier oracles are not populated externally (e.g. via PathFinder), the participants endpoint is used to maintain them. This endpoint is uncommon among FSPIOP endpoints in that its message are directed towards the switch, and not towards other participants in the scheme. The existing specification gives the following definition of the purpose of the endpoint in Section 6.2:

The services provided by the resource /participants are primarily used for determining in which FSP a counterparty in a financial transaction is located. Depending on the scheme, the services should be supported, at a minimum, by either the individual FSPs or a common service. If a common service (for example, an ALS) is supported in the scheme, the services provided by the resource /participants can also be used by the FSPs for adding and deleting information in that system.

The services referred to in the first paragraph are in fact duplicates of the services offered by the GET /parties service, except that the PUT /participants endpoint returns less information than the PUT /parties endpoint.

The ISO 20022 message set doesn't really have an equivalent concept to the Mojaloop ALS structure. It has messages which correspond with the GET /participants endpoint, where a DFSP can ask another DFSP whether it recognises a given identifier. This is equivalent to how GET /participants works in a situation where there is no ALS (see specification, Figure 41). It does not, however, have a message structure corresponding to the Mojaloop concept of a central directory which is maintained by participants in the scheme, and which allows that central directory to process non-specific enquiries from participants and route them to the correct DFSP.

There are messages in the ISO 20022 message set which work in analogous ways; but they are intended to allow DFSPs to exchange information about the association of an identifier with an account at a named institution. For instance, the definition of the Account Management messages (acmt.023 and acmt.024), which are used for address resolution by the Nexus project, for instance, is as follows:

Set of messages used by a financial institution to inform another financial institution of the change of a client's bank and/or the change of a client's account identification. These messages may also be used to ask a bank to verify one of its banks and/or to verify its account identification

It is clear from this definition that the ISO 20022 messages refer rather to the type of service which does not have a central register of associations between identifiers and DFSPs than to those which, like all current Mojaloop implementations, use an Address Look-up Service.

Since it is a Mojaloop Foundation objective to have a fully ISO 20022-compliant version of Mojaloop, we need an answer to this problem.

One answer would be to create a new set of messages to manage this situation. Another might be to move the /participants endpoint to the Admin API, on the basis that, like the other endpoints in the Mojaloop Admin API, it manages conversations between a DFSP and the switch rather than between DFSPs. This would allow us to retain an all-ISO 20022 equivalent of the FSPIOP API, while avoiding the long and tortuous path of creating multiple new ISO 20022 messages.

mojaloop / mojaloop-specification