Managing duplicate identifiers in Mojaloop
mjbrichards opened this issue · comments
Open API for FSP Interoperability - Change Request
Table of Contents
1. Preface
___This section contains basic information regarding the change request.
1.1 Change Request Information
| Requested By | Michael Richards, ModusBox |
| Change Request Status | In review ☒ / Approved ☐ / Rejected ☐ |
| Approved/Rejected Date | |
1.2 Document Version Information
| Version | Date | Author | Change Description |
|---|---|---|---|
| 1.0 | 20122-06-27 | Michael Richards | Initial version of template. Sent out for review. |
2. Problem Description
___2.1 Background
It has been clear for some time that the identifier type/identifier value pattern used to identify a party to a Mojaloop payment has a problem with duplicate values. A duplicate value occurs when a single identifier value is used by more than one DFSP to give access to a client. There are three types of duplication which we propose to consider; but only one of these is considered for remediation in this change request, for reasons that will be discussed below. The three types are:
- Some identifier types used in RTP systems are nonce values: they are assigned a meaning within the payments system, but have no meaning outside it. An example is a merchant ID, which is assigned to a particular merchant by a DFSP, or by an RTP scheme, as a convenience for merchants and their customers. Where DFSPs have already assigned merchant IDs to their customers prior to joining the RTP scheme, there is a strong possibility that the IDs assigned by different DFSPs will overlap with each other, so that the same identifier will be used to refer to two or more merchants in the RTP scheme. We regard this as a scheme set-up issue. One of the DFSP tasks associated with joining an RTP scheme will be to ensure that any nonce values it has assigned are either unique within the RTP scheme or replaced by unique values as part of joining the scheme. The scheme itself will typically take on the responsibility of issuing new nonce values, so that it can ensure that they are unique across the scheme address space. Duplicates of this type are therefore omitted from further discussion in this document.
- Some identifier types have duplicate values which are meaningful outside the RTP system, but which refer to different customers. An example of this is a bank account number in jurisdictions where reliable branch identifications are either not available or are not generally used. For bank account numbers, the problem is complicated by the fact that Core Banking Systems typically use parts of the account number to encode information about the account: account type or customer type, for instance. Since different DFSPs may very well use the same CBS, the likelihood of duplication is greatly increased. There is no obvious solution to this duplication problem, unless it is to replace the account number with a nonce value which includes both the account number and an invented (or existing, such as a BIC) identifier for the DFSP which controls it. Duplicates of this type are therefore omitted from further discussion in this document.
- Finally, there are duplicates which result from the same customer having an account identified by the same identifier at more than one DFSP. For example, there are jurisdictions in which a number of the available MMSs are operated by organisations who are not themselves MNOs. These MMSs, like the MMSs operated by MNOs, identify their customers by their MSISDN. A customer may very well belong to more than one of these MMSs; and, in that case, all of the MMSs to which they belong will use the customer's MSISDN as their account identifier. For instance, in Tanzania banks are actively marketing simple low-KYC accounts which are identified by MSISDN; and Myanmar has a large number of non-MNO MMS operators and numerous customers who belong to two or more of them. It is this category of duplicates that this document addresses; and it will use MSISDN as an example. In Tanzania and Myanmar, the problem is currently being worked round by requiring the payer DFSP explicitly to state which DFSP to route the directory request to. This is not, however, a solution which is sustainable, given that we are now looking at supporting cross-network payments in Myanmar, and it would place an unacceptable burden on remitting DFSPs to allow their users explicitly to select which payee DFSP to route a payment request to.
2.2 Current Behaviour
At present, the API assumes that identifiers will be unique. The PUT /parties call returns information which describes a customer at a single DFSP. The question of how the scheme should behave if a DFSP attempts to register an identifier which is already associated with another DFSP in a particular oracle is undefined; and, if the scheme allows duplicate identifiers to be registered in an oracle, the question of which DFSP will be contacted for information following a GET /parties using that identifier is similarly undefined.
2.3 Requested Behaviour
Where duplicate identifiers exist, we need some way of identifying which of the DFSPs associated with a single identifier is the one to which GET /parties requests which use that identifier should be routed.
3. Proposed Solution Options
___Tow possible solutions to this problem have been canvassed at various times:
- The oracle for a particular identifier type could insist on uniqueness, and either reject attempts to add duplicate entries or overwrite the existing entry with a duplicate entry when one is received. As discussed above, this is a solution which would work well for nonce values like merchant IDs, but is not well adapted for values which represent real-world attributes, such as bank account numbers or MSISDNs. If a DFSP uses an MSISDN to identify a customer's account, whether or not that identifier is itself an account number, then it seems unreasonable for the oracle not to record that identification simply because another DFSP also uses the MSISDN as an identification.
- Proposals for global (or extra-scheme) identifier repositories typically address this problem by proposing some means of direct interaction between the customer and the repository. This interaction would allow the customer to identify which of their duplicate identifier entries they wanted to use as the default one. This technique has been proposed for the Mojaloop system too; but there are two objections to it which seem to me intractable. First, Mojaloop has always eschewed any direct interaction with customers: as far as Mojaloop is concerned, matters relating to individual customers should be left to the DFSP which controls that customer's account. Second, global identifier repositories are typically proposed by organisations who think in terms of first-world digital privilege: they assume that these customer interactions can be hosted via internet-based interactions on smart phones. If Mojaloop were to provide such interactions, it would need to be in a way which was capable of supporting the rural poor in developing economies (read: via USSD interactions on feature phones.)
For the reasons given above, neither of the possible solutions seems to offer a suitable solution to the problem. Discussions relating to the proposed cross-border proof of concept hosted by MAS have resulted in the following possible solutions to the problem.
First, the addition of a new endpoint to the specification to allow a DFSP to specify that it should be the default target tor a GET /parties for a specific identifier type and value. For example:
- We call the endpoint /defaults
- The DFSP issues a POST /defaults whose payload is a correlation ID representing the registration and a PartyIdInfo object containing the identifier type and value for which the issuing DFSP wants to be registered as the default account holder.
- The switch records the identification (as described below) and responds to the DFSP with a PUT /defaults/{ID} or a PUT /defaults/{ID}/error.
This solution has the disadvantage of requiring the addition of a new endpoint to the API; but it has the advantages of being relatively easy to understand, and of the semantics of the operation being closely aligned with the operation itself.
Second, the addition of a new identifier type (for instance, DEFAULT) to the PartyIdType enumeration. Issuing a POST /participants request for this identifier type means: please register me as the default account holder for this identifier type and value. One drawback of this approach is that the PartyIdInfo object would need some other data to store the identifier type for which default status is being requested; but it would be possible either to use the PartySubIdOrType item or to add the identifier type to the ExtensionList in the call. This approach also has the drawback of not representing very clearly what is actually happening as a result of making this call.
Third, the use of the ExtensionList to specify that a registration is to be treated as the default entry for that identifier, using a structure to be agreed and implemented by individual schemes. This solution has the advantage of simplicity, but loses visibility and generality of how Mojaloop responds to this issue in general.
For any of the above solutions, changes will be required as follows:
- Scheme rules will need to be modified to:
- Define the circumstances under which a DFSP is allowed to define itself as the default owner of a specified identifier
- Define example processes which show how to resolve any disputes.
- Define the behaviour when there are duplicate entries for an identifier but no default has been defined.
- The oracle template will need to be modified to:
- Include a means of recording whether a given entry is the default entry for an identifier or not.
- Return the default entry for a given identifier where one has been defined.
- Respond in a deterministic way where there are duplicate entries for an identifier but no default has been defined.
One simple change that was discussed in the SIG meeting today was to allow multiple FSPs to be returned for a single identifier. Scheme implementation and rules can then decide if only one FSP should be returned as today, or if multiple FSPs should be returned to let the Payer decide on which FSP to transfer funds to.
This issue will be parked until later as discussed on today's FSPIOP SIG meeting.