Additions to PartyPersonalInfo object
mjbrichards opened this issue · comments
Open API for FSP Interoperability - Change Request
Table of Contents
1. Preface
___This change request is to support extended KYC information for parties.
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 | 2021-05-04 | Michael Richards | Initial version of template. Sent out for review. |
| 1.1 | 2021-08-06 | Michael Richards | Proposed solution following reviews. |
2. Problem Description
___2.1 Background
Non-national Mojaloop schemes such as Mowali are regulated like a DFSP. In particular, they need to be able to comply with KYC regulations relating to the parties involved in the transfers they facilitate. Schemes do not, however, undertake any KYC activity on their own account: the Mojaloop principle is that information relating to individual account holders is owned by the scheme's participants, not by the scheme itself.
Since this is the case, a scheme which needs to comply with KYC regulation about the transfers it facilitates will need to obtain that information from the DFSPs who are the parties to the transfer. There is already an object in the specification which contains some information about a party to the transfer. This is the PartyPersonalInfo object (Section 7.4.14 of v1.1 of the FSPIOP API definition.) This object forms part of the information which is returned by the payee DFSP in the PUT /parties response, and also forms part of the payer's quote request (POST /quotes,) which allows personal information for the payer and the payee to be included.
The PartyPersonalInfo object currently supports two items of data: the full name of the party and their date of birth. Standard KYC requirements, however, frequently require additional items of information to ensure that a customer is correctly identified. This change request proposes extensions to the PartyPersonalInfo object to support these requirements.
2.2 Current Behaviour
The PartyPersonalInfo object currently supports two items of data: the full name of the party and their date of birth.
2.3 Requested Behaviour
The PartyPersonalInfo object should be extended to include an opaque data object which individual schemes can use to hold KYC information as defined by their requirements. The API itself will not mandate the content of this data object, but individual schemes will be free to validate its contents, e.g. by the applicaiton of rules.
3. Proposed Solution Options
___The proposed structure for the PartyPersonalInfo object is given below:
| Name | Cardinality | Type | Description |
|---|---|---|---|
| complexName | 0..1 | PartyComplexName | First, middle and last name for the Party |
| dateOfBirth | 0..1 | DateOfBirth | Date of birth for the Party |
| kycInformation | 0..1 | String(1..2048) | KYC information for the party in a form mandated by an individual scheme |
Thanks @mjbrichards,
Some quick initial comments:
msisdn should be in a standardized format. From PartyIdType definition today: "The MSISDN identifier should be in international format according to the ITU-T E.16437 standard. Optionally, the MSISDN may be prefixed by a single plus sign, indicating the international prefix."
address should preferable be structured instead of just 5 possible elements. For example streetName, town, country, etc to make it easier to interpret.
partyRelationship should be possible to have as an enum?
Thanks for your comments, Henrik.
I considered requiring a standard form for MSISDN, but eventually rejected the idea. My reasoning was that, although an MNO would have a clear and accurate view of a customer's MSISDN, other types of institution might well not have such a good view, and from a KYC point of view the scheme is effectively dependent on the information collected by the DFSPs as specified by their regulators. The same point applied, I thought, to the address. I originally considered using (some of) the detailed format provided by the ISO20022 data dictionary; but it seemed to me that a more detailed constraint might lead to participants struggling to map their information onto our fields.
It should, as you say, be possible to have the relationship as an enum, provided we could locate a standard structure for it. Do you know of one?
How can it be used for e.g. screening purposes if everyone is using their own standard? How difficult can it be for an institution to convert their internal standard to an agreed common standard? It is much more difficult the other way around, if some other institution (e.g. the regulator) should try to convert another institution's unknown format into a common standard. There is already a standard for MSISDNs which should be used within this API. By leaving the format open, we are effectively making interoperability much harder.
As you say, the same point applies to the address. It will be much easier to perform e.g. screening if you know exactly which field you are screening. It is much easier for another institution (the receiver of the information) to convert a structured format into an unstructured format, than the other way around.
Forgot to answer regarding relationship enum, I would guess there is some examples from regulations that we could use? Can we otherwise ask regulators which kind of relationships that they would expect?
+1 @millerabel . This strikes me as a similar principle to Extension Lists... we have to walk a line between being too prescriptive and not prescriptive enough.
The API shouldn't be too opinionated about the data formats or indeed the data that will be sent (hence why these fields are optional), but should give schemes the tools they need to get what they want done without resorting to hacky workarounds.
I'm fine with having an opaque data element with a reasonable safe size limit as well, where the actual data is defined in the scheme. I just don't want to have a number of elements in the API which are loosely defined.
I'm happy with this proposal. Presumably we should also consider adding some material to the scheme rules template to explain how a scheme would define the KYC information it requires participants to provide.
What would you think to be a reasonable limit for the size of the field, @ehenrka? And I assume we no longer need to worry about the enumeration of relationship types, since schemes will define that for themselves if they need to?
I took a look at some related remittance APIs which includes a lot of possible KYC details, and based on that I think that around 2000 characters should be sufficient without being excessive..
And yes, no need to worry about an enumeration of relationship types as it will anyways be defined in schemes if required.
The newly proposed structure in Section 3 looks good to me.
Aligned with the change and proposed data options.
Basing on ISO stardard make it robust and uniform.
