Change Request: Requesting detailed party information

[MichaelJBRichards]

Open API for FSP Interoperability - Change Request

Table of Contents

• 1. Preface
  • 1.1 Change Request Information
  • 1.2 Document Version Information
• 2. Problem Description
  • 2.1 Background
  • 2.2 Current Behaviour
  • 2.3 Requested Behaviour
• 3 Proposed Solution Options

1. Preface

___

This section contains basic information regarding the change request.

1.1 Change Request Information

| Requested By | Michael Richards, Mojaloop Foundation |
| Change Request Status | In review ☒ / Approved ☐ / Rejected ☐ |
| Approved/Rejected Date | |

1.2 Document Version Information

Version	Date	Author	Change Description
1.0	2024-12-18	Michael Richards	Initial version of change request. Sent out for review.

2. Problem Description

___

2.1 Background

In domestic schemes, there is little requirement for participants to establish that the parties to a payment are bona fide customers and not criminals or terrorists. In the case of international payments, however, this is an important consideration. The key resource in this area is the set of recommendations published by the Financial Action Task Force (FATF).

The FATF recommendations provide alternative methods which participants can use to identify their customers to other parties who have a legitimate interest in identifying those customers. In most cases, these methods involve including information about the customer (for instance, their address and their date of birth in the case of natural entities) in the relevant payment message (in the Mojaloop world, the relevant payment messages are the /quotes resources which allow the participants to agree the terms of the payment with each other.

The inclusion of information (Personal Identifying Information, or PII) which can be used to identify natural entities (or people, as we call them) is, however, frequently governed by strict rules about privacy, and sometimes also by additional rules prohibiting the export of such information across national boundaries. Mojaloop schemes may need to apply for special exemptions to these rules in order to include in their messages the information which may be required by FATF.

This is particularly problematic for Mojaloop schemes, part of whose mission is to encourage the participation of smaller and more informal account-holding institutions. These institutions may find it more onerous than more traditional FIs to meet the security requirements surrounding PII, and their customers may not be required, and may not even possess, some of the information that may be required by FATF Recommendation 16.

2.2 Current Behaviour

At present, the FSPIOP API has elements of the PartyPersonalInfo object which allow a DFSP to specify a customer's date of birth and a version of their full name (although this structure is not well adapted to diverse cultural name structures.) For legal entities, there is no provision for information specifying their identity except for the identifier which was used to resolve their address. Any additional information identifying a customer must be included in the ExtensionList fields for the message.

The ISO 20022 version of the API has much more extensive information about parties. However, this does not alter the underlying structure, which results in information which can be used to identify parties to a payment being passed around in messages, and in imposing on participants the responsibility for ensuring the integrity of that information.

2.3 Requested Behaviour

One of the alternate ways of providing information about a party to a payment provided by FATF is a "customer identification number" (p.81). This is defined as "a number which uniquely identifies the originator to the originating financial institution and is a different number from the unique transaction reference number referred to in paragraph 7. The customer identification number must refer to a record held by the originating financial institution which contains at least one of the following: the customer address, a national identity number, or a date and place of birth." Identifying a party by using a customer identification number would allow Mojaloop to meet the requirements of FATF without requiring PII to be passed round the system and retained by participants as part of the content of messages.

This solution would require the addition of functionality to allow permitted parties (for instance, a regulator or a counterparty to a payment) to request from an account-holding institution the information which is referred to by the customer identification number. The account-holding institution would respond to this request with the information required, as specified in the FATF definition of the customer identification number given above.

3. Proposed Solution Options

Add an optional customer identification number to the Party object. This would allow participants to share a reference to a customer instead of including PII about the customer. The name of the field should be customerId. Cardinality should be optional (0..1). Type should be string(1..36), to allow UUIDs to be used if convenient to the issuing DFSP. Description should be: "A number which uniquely identifies the DFSP's customer to the DFSP, and which can be used by the DFSP to access at least one of the following: the customer address, a national identity number, or a date and place of birth. This number conforms with the definition of a customer identification number given on p.81 of the November 2023 release of the Financial Action Task Force (FATF) Recommendations for International Standards on Combating Money Laundering and the Financing of Terrorism & Proliferation as part of Recommendation 16."

Add a new identifier type to the PartyIdType enumeration: CUSTOMER_ID. This would allow participants to issue a GET /parties/CUSTOMER_ID/{ID} to request the KYC information for the customer whose Id number was given. DFSPs would register their customer numbers in the normal way: that is, via the participants resource. An alternative would be for the switch automatically to register customer unique identifiers when they were received as part of a PUT /parties response, but this is not a requirement for implementation.

[henrka]

As an alternative, could the existing ACCOUNT_ID be used as the customer identification number? It seems to me like this should satisfy the definition in 2.3:

a number which uniquely identifies the originator to the originating financial institution and is a different number from the unique transaction reference number referred to in paragraph 7

Advantage is that no changes would be required..

[MichaelJBRichards]

The potential problem here is that that solution would overwrite the identifier originally used by the debtor participant to identify the beneficiary. I see the advantage, but worry that it would lose information that might be of value later....

[henrka]

OK, then my only comment is that CUSTOMER_ID should be used instead of CUSTOMER_ID_NO. Both ID and NO seems a bit superfluous, and aligns better with the other enum values. CUSTOMER_NO would be another alternative..

[MichaelJBRichards]

Updated Proposed Solution section based on the discussion above. Please review.

[henrka]

CUSTOMERID should be CUSTOMER_ID to align better with existing values ACCOUNT_ID and PERSONAL_ID.

[MichaelJBRichards]

Thanks, @henrka . Modified