search

mojaloop / mojaloop-specification

This repo contains the specification document set of the Open API for FSP Interoperability
https://docs.mojaloop.io/api
Other
20 stars 40 forks source link

Additions to PartyPersonalInfo object #88

Open mjbrichards opened 3 years ago

mjbrichards commented 3 years ago

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
henrka commented 3 years ago

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?

mjbrichards commented 3 years ago

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?

henrka commented 3 years ago

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.

henrka commented 3 years ago

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?

millerabel commented 3 years ago

I think this proposal is headed towards an unsupportable divergence of “standards” for things like phone number, address format, and even what fields to collect. May I suggest that we hold this information in an enveloped form that is open to scheme’s to specify for themselves? They might, e.g., use ISO20022 data dictionary and data typing; they might use an XML format for the KYC “document”; and they might specify divergence from international standards in a domestic context and according to local convention.

Replace all of the data fields in this proposal with a single composite document, something like “KYCDocument” that has a meta-format only, without specifying the data schema or required fields. Those choices would be left to scheme design.

This accretion of scheme-specific, and transaction type specific data is why we separated transaction logic from transfer logic in Mojaloop. We don’t want to subject the platform to the union of all desires!

— Miller

Miller Abel @.***

On May 4, 2021, at 6:01 AM, Henrik Karlsson @.***> wrote:

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?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/mojaloop/mojaloop-specification/issues/88#issuecomment-831923205, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB6OJ6AXLGJGJ422RPQ4Z73TL7V3TANCNFSM44CO2NGQ.

lewisdaly commented 3 years ago

+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.

henrka commented 3 years ago

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.

mjbrichards commented 3 years ago

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?

henrka commented 3 years ago

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.

henrka commented 3 years ago

The newly proposed structure in Section 3 looks good to me.

jmssebunnya commented 3 years ago

Aligned with the change and proposed data options. Basing on ISO stardard make it robust and uniform.

tilemanrenovations commented 1 year ago

[]()