KYC Match - Compare specifications #18
Comments
|
Hi Gilles,
We can still include the "address" attribute but discourage in some way the use of it. Response Specifications |
|
Thanks very much, @GillesInnov35, for creating this issue. May I ask questions for clarification?
I have one comment: we have agreed that calculating matching score is for our future releases, so, it should not be included for our initial release. Thanks. |
|
Hi @ToshiWakayama-KDDI we agreed to not include the matching score. @GillesInnov35, I figured out my proposal: |
|
Hi @StefanoFalsetto-CKHIOD , @ToshiWakayama-KDDI
use of address
GSMA Mobile Connect KYC Match
|
|
Hi @GillesInnov35 Regarding use of address |
|
Hi @fernandopradocabrillo , yes sure could you send me the list of atributes Telefonica proposes in its solution. |
|
Hi, which can be summarized in: phoneNumber, idDocument, identity (composed of firstName and lastName), address (composed of postalCode, streetName and streetNumber), and birthdate. And the responses would be xxxx_response for each of them. |
|
Hi all, Please find the revised shortlist table below. I have added our proposed parameters/attributes, which are included in our YAML file, to the shortlist table. Also I have added Telefonica's parameters/attributes as well. Hope it is correct. Also I have changed GSMA Match to MobileConnect Match and moved it to the right as MobileConnect is not our proposal. I have one point to ask you at the moment: Match Request Body
KYC Match Response
Many thanks, |
|
Hi all, Also please find the below a short list table for KYC Fill-in attributes/parameters based on our Fill-in YAML. Any comments would be welcome. Fill-in Request Body
Fill Response
Many thanks, |
|
@ToshiWakayama-KDDI, Orange KYC offers differentiate also subscriber and user. The 3-Legged authentication architecture is based on user information who authenticates and should consent. But information returned by the service concern the subscriber who signed the contract. |
|
I have a question regarding Toshi's proposition included language information (user_name and user_name_kana_hankaku). |
Hi @GillesInnov35 , Thanks. |
Hi @GillesInnov35 , Thanks |
|
Hi @ToshiWakayama-KDDI ,
|
Hi Gills @GillesInnov35 , |
Hi @GillesInnov35 , @ToshiWakayama-KDDI |
|
Hi @fernandopradocabrillo , Hi @GillesInnov35 , Many thanks, |
|
Thanks a lot @ToshiWakayama-KDDI
|
|
In the Netherlands, we currently have the following attribute list in use:
We don't use street name, town etc because in the Netherlands postal code + house number + house number extension is very exact already. We already have relatively high match rates (up to 80% for family name). Nevertheless, I think we can still improve by the following:
Often people only record their first Given Name or Initial (although many have multiple Given Names). The use of initials can help for cases where there are multiple ways how to write a given name (for example Steve and Stephen). In the Netherlands we have a list of prefixes that we usually strip from the family name. The reason we do this is that the prefixes can be abbreviated, which hinders the matching. What we can add is an extra attribute in which you compare these prefixes. For Family Name, I think we can improve by adding the Family Name at birth as a separate attribute. In the Netherlands, your familiy name can change when you get married, so this may change during your life time. Your Family Name at birth never changes, and when available, it is better for matching because it stays constant. Streetname we do not use, because our postal code + house number + housenumber extension is very exact. So, we would propose the following list (for NL):
|
|
Annex B - MC Product Specification - Match, v1.4.xlsx Attached also the list of specs we currently use for Match in NL. It also includes the list of prefixes we strip from family name |
|
Thanks @HuubAppelboom |
|
I agree with @GillesInnov35 in the sense that I think we should see it from the perspective of a Service Provider that is asking a user for some contact information, and shows a form to collect several fields of data. Then, IMHO, and recongizing I don't know the habits in the Netherlands, I don't think the Service Provider is going to ask the user for, for example, all potential ways of expressing their name, but will ask for the most common way to express the name in that country. |
The issue is not that we think that Service Providers should ask end users for all different possible variations that you can have, but that MNO's and Service Providers have a history and way of working in collecting the data. For example, in the Netherlands we have a couple of MNO's which only have collected initials. Making Given Name(s) the only option will not work in this case (that's why we have chosen for initials-only in the Netherlands, deviating from the Mobile Connect standard). The other issue you have is when you ask for matching all initials (or given names), and provide that as the only option, you will see that often 2nd and rd initials are missing in current databases (at least we have seen that), which results in a lower match rate than you could have. That's why we propose to make several attribute fields available in the standard, and that you match on all field that you have available. The same principle would apply for family name, if you have the family name at birth also available, that you can aso provide a match on this. In the end , you can safely get to a higher overall match rate through this, without the need to go to more complex solutions like a match score based on whether the attributes are similar. As far as the availability of data is concerned, in case the MNO does not have a specific attribute in their CRM system, you can always answer with "NA". |
Hi @GillesInnov35 , Thanks very mucy. First of all, my understanding is that we are not discussing mandatory attributes, but that all attributes should be optional, as I shared on Tuesday. Surely we need mandatory requirement like 'at least one attribute should be included in a API match request'. So, to answer your question, we would like to have specific attributes kana etc. part of KYC-Match request definiton, as one of the options. Then I understand your point that dataType used as a discriminator would be useful to avoid duplication of concerned attributes, and I think I need to look into it. Many thanks, |
|
Hi @HuubAppelboom , @javier-carrocalabor , @GillesInnov35 , Thank you, all, for your comments. Now I understand the Netherlands needs some spedific attributes. As I shared on Tuesday, I would propose to include all the required attributes, both of commonly used attributes and country/market specific attributes, if we categorise, in our first version. I think that all the attributes should be Optional, as it seems there are many ways to use this API/KYC-Match functionality so it is difficult to identify mandatory ones. Of course, we need some mandatory requirement like 'there should be at least one attribute incuded in a API request'. If you think we may need categorisation of Common attributes and Country/Market specific attributes, we could write it down somewhere in YAML or in API documentation. What do you think? Many thanks, |
|
I would indeed support to include all attributes, and include both commonly used and country/market specific attributes. As a rule, I would suggest that when you can, you support all attributes for which you have data for. For example, for NL we currently do not support streetname (because it is not necessary here), but for the sake of international compatibility we will implement it. On the customer side, the customer can always choose which attributes will be asked to be matched (with the minimum of one of course). For example, for some cases we only need address verification and nothing else, because the customer is already using a different source for the name, date of birth, email etc. What should also be prevented is that customers start offering data in case they don't have it, because this will give you wrong match rate statistics. For example, we had one customer that did not have Date of Birth data, so in stead they always submitted "YYYY-MM-DD" as a hashed string, which ofcourse never matches, or a dummy date like "1900-01-01". You will get low match rates, and it really take some time to find out what is going wrong. So in any case, customers must always submit valid data, and not dummy data. With kind regards |
|
Hi @ToshiWakayama-KDDI , term mandatory was not appropriate because as you say all attributes should be optional of course (except phone number). I was meaning attibutes we'd like to see in the API design (will be common attributes). Thanks a lot |
|
As I said in some other comments, I will be happy to discuss about deprecating the address attribute. It is far better (for many countries around the world) to use different attributes for the single address components. |
|
In order to find the right initial set of attributes, I am sharing the full set of attributes that CKH (and hence all the affiliates operators) are offering to its Partners. As you can see we are supporting all the attributes defined into the GSMA IDY.28 specifications plus some custom ones (e.g., the age verification). Some of the address related attributes such as
|
|
In general, I am not too worried about the attribute list being a bit long, but more worried about trying to put too many flavours in a single attribute. For example, we tried working with all initials available for the given name, but which resulted in a too low match rate, simply because either side (MNO or Relying party) did not have all initials at their disposal. Same will be the case if you this with given names, or for example an attribute with all the address details in it. The more you try to push things in a single match result, the higher the chance of a mismatch, and that is why we propose to split 1st given name from middle names, streetname from street number, street number extension from street number etc. |
|
hello all, that's good this is a very interesting, we are converging to a solution. @HuubAppelboom could you complete your proposition with some examples of atributes' value in order to see what kind of information is waited. I don't see clearly how and middleNamesInitialsMatch and middleNamesMatch will be valued (type array or single). Thanks a lot Regards |
|
Hi @javier, Hi Huub, Hi Gilles, Thank you for your further comments. I have the same view with Huub that I am not worried about the length of the currently proposed attribute list (mine and Huub's). So, Huub's proposed list (plus cp_id/service_id) would be pretty much fine with me. I can understand the view of making the attribute list as short and simple as possible, however, currently proposed attributes are required by operators and their customers, so, I think there is no point deleting required attributes in order to make the list simple. (For example, we are providing Matching for the single 'name' attribute and the single/formatted 'address' attribute which our customers need.) For the API clients, they can use attributes they need and can just ignore attributes they do not need. To avoid their confusion, we can prepare proper description and explanation for each API and further we could prepare some typical examples of attributes set for some typical use cases. For the operators, they can just ignore requests for attributes they do not have. So, it is kind of 'the greater embarces the less', and I don't believe Huub's proposed list (plus cp_id/service_id) is too long. Could we accept it for our first version? Thanks, |
|
Regarding the middleNames attribute, there is two way we can do this, in case there is more than one middle name. Take for example: For Mattheus Franciscus, we could either choose to make it one long string, with everything lowercase, without spaces etc., and hash the result. So in the end you will recieve a hash of "mattheusfranciscus" The alternative would be to make it a list of middle names, and make a hash of each middle name separately (after making everything lowercase). So then you receive a list of two hashes (of "mattheus" and "franciscus"), and for each hash you will provide a Y/N whether you also have that in your list. (in this I assume the order of the middle names is not that relevant). Probably the alternative will give a higher match rate, in case only one of the middle names mismatches you still have a partial match. What do you think ? |
|
Adding which type of ID document may be a good idea, but I know this can also become a bit complex a long list. For example, in the Netherlands we also have special ID documents like a permit for fugitives, an id card for embassy staff, etc, etc. |
|
For ID Card document, you also may want to include the issued date, otherwise you will rund the risk of drawing the wrong conclusion, when you see the same type of document, but no match. The issue date will tell you whether the hashed number must be the same for the same identity or not (or that one of the parties has data on an old document). |
Hu @GillesInnov35 , all, Thanks for your question. Indeed, consumer information (partner id) is commonly transmitted in OAuth token. Actually we use this partner information (cp_id, service_id) included in the request body, in addtion to the information transmitted in OAuth token. As it is our current implementation for commercial service, we would like to have these two included somewhere in the request body (only in the request body, not in the response body), if possible, though they may not be normal KYC attributes. Of course, description of these two items should be properly documented in the YAML and API documentation, e.g. they are only for Japan regional use, how to use them, etc. Many thanks, |
|
Hi all,
Please point out if there is anything wrong or missing. Many thanks, |
|
Hi all, Thank you very much for the discussion yesterday and your compromise. To note, the following is the list of parameters for the initial plain text version of our KYC Match API.
Should there be any attribute that I missed above, please let me know. Many thanks, |
|
@ToshiWakayama-KDDI , this is the list of attributes to which we've concluded yesterdays. It's OK. |
|
I still have some doubts about the kana parameters. These are parameters that are very country-dependant, if more countries add their particular properties, we can end up with a never-ending list of parameters. I have a couple ideas to overcome this topic:
The same way I think we can reduce the list of parameters a bit more removing familyNameAtBirth. If I'am a service that needs the lastName to make a subscription and I want to check the info provided, how do I make the API request? do I check agains all lastName related fields? does the MNO have that much information about their users? Isn't it better to just leave it as lastName and let the country implementation check against what it is commonly used there? For houseNumberExtension I'm not that sure, this one maybe is usefull, do we have an example of its use? gender ? -> this one might be difficult to match. Do we need to stablish some rules or available values? male/female, Prefer not to say / Prefer not to disclose, non-binary genders, etc. So a proposal for the initial list could be:
In addition we also think that it could be usefull to group related properties under the same object: identity for naming properties, address for properties related to the postal address. Thanks! |
|
Thank you, but we have agreed the parameters for our initial version, and we have to complete our initial YAML by Tuesday 19th. If we restart parameter discussion, for example, for us, idDocument is not needed, it will take more time and never end. I understand your point, but why don't we complete our first version once as a basis, and then we can modify and refine it in an agile fashion to make it better. As you know, if we look at some other APIs in CAMARA, they have had several update versions. This is my current view. Best regards, |
|
The house number extension is used in the Netherlands. It is used for example in appartment buidlings in which all appartments have the same housenumber, but each appartment has a different extension. Without it, you don't have a complete address. When we introduced Match as a servcie in the Netherlands, we first tried it without house number extension, but later on added it because we had too many customers complaining it was missing. So, for the Netherlands it is a must have, and there may be also other countries where they have a similar system. |
|
The family name at birth is commonly used to identify someone in my country by the telco's. The reason we use this to identify is because it does never change over time due to marriage etc. What do you commonly use in Spain ? On your passport you familiy name at birth is always present, adding the name of your partner is entirely optional and up to you. In daily use, you can use the family names of you and your partner when you get married in four different ways, and people are free to select how they want to use it:
As you can imagine, this can cause at lot of confusion if you don't specify what you are asking for, or it will give the wrong conclusion regarding someone's identity. In the current Match service we have , we use the family name at birth (because that is most reliable for us), but it would make a good improvement to offer an option to have your current family name as well. When the customer has both attributes, they can try to match both (and obtain a better identification). |
|
Hi @fernandopradocabrillo , |
|
Hi all, |
|
Hello @javier-carrocalabor , Thank you for your comment on the 'gender' attribute. I am not a specialist on this topic, but I generally feel that how special 'gender' is would be different for each country or market, that there are some countries/markets that want to have the 'gender' attribute, that MNOs (KYC API providers) who do not want have it or who are not able to handle it can send a 'not_available' response, and that hence there is no need to remove the 'gender' attribute. Anyway, we can discuss this after the Christmas Break. Many thanks, |
|
Hi @ToshiWakayama-KDDI , In case it helps to generate the final list of attributes with their corresponding descriptions, I'm adding here a summary table:
|
|
Hi @javier-carrocalabor I think you may have mixed up Name and Given Name in the above definitions See for example https://en.wikipedia.org/wiki/Given_name, also for some interesting history and cultural differences |
Thank you, Huub, for the comment. I think I mixed both parameters 'name' and 'givenName'. So, the description for you all to consider could be:
|
|
Thank you, @javier-carrocalabor , @HuubAppelboom , Regarding 'name', the above description sounds the order as first/given name -> middle name -> last/family name, but this is not always the case in some countries. In addition, 'surname' should be added to last/family name. So, my proposal would be:Complete name of the customer, usually composed of first/given name and last/family/sur- name in a country. Depending on the country, the order of first/give name and last/family/sur- name varies, and middle name could be included.
|
|
Frankly speaking, I don't understand why we need to discuss about the use of aggregated fields such as "name". In my humble opinion all the aggregated attributes must be deprecated i.e., like the generic "address". My concerns are the following:
|
|
Thank you @StefanoFalsetto-CKHIOD for the heads up. So, to be practical, I suggest to go ahead for the current proposal in the PR for the rc unless we really have a good quorum on removing the "composed parameters": 'name' and 'address'. |
|
hi @javier-carrocalabor, all. At Orange we do not use aggregated attributes such as name or address. I agree with @StefanoFalsetto-CKHIOD, in case of KYC Match Hashed, aggregated attributes won't be useful. |
|
@javier-carrocalabor Hi, In the attribute table you provided, should Address, Locality, etc not be written without Capitals ? |
You are right. My bad. Edited in the comment to correct it. Fortunately, it had been corrected when taken to the yaml file of the release. |
|
Hi All, I think remainig issues in this issue have been included in Issue #87 (and maybe others). Can we close this Issue? BR |
|
Yes, I think we can close this now |
|
Closed as agreed. |
CAMARA KYC Match - Specifications
Bellow a proposal of comparison matrix between different offers' specifications and CAMARA initial requirements proposal.
Key points :
Request Specifications
Response Specifications
The text was updated successfully, but these errors were encountered: