APIproposal_KYC-Match_KDDI.md

KYC Match API submission

Field	Description
API name	KYC Match
API owner	KDDI – Toshi (Toshiyasu) Wakayama
Initial API Contributors	Telefonica – Jorge Garcia Hospital
API summary	This API provides results of matching specific information submitted by the API invoker against the mobile subscriber information, which can include MSISDN, name, postal code / address, birthdate, email address, etc. No PII returned. Subject to the mobile subscriber’s consent. Note: This API will be a part of GSMA Open Gateway APIs.
Technical viability	This API uses mobile subscribers’ information usually owned by every MNO, that should be made available in matching process, subject to the mobile subscriber’s consent. Some technical initial proposals are as below, but it will be discussed further to be agreed on during CAMARA work. - Input: the following attributes fields are proposed to be matched as input for the API: MSISDN, identity document, name (subscriber, phone user if applicable), given name, family name, kana name(reading), address, street name, region(address), postal code, birthdate, email address, Customer ID, ThirdParty ID. - Output: there would be an output attribute for every input attribute, giving the result of the match for each of them. For example: “subscriber_birthdate_match”: true. - Alignment with KYC Fill-in API should be considered; especially for attributes available for this API. Notes: Other proposals for improvement to be considered. - For input, alternatively, fields may be hashed to avoid information be presented in the clear. Thus, input fields would be, for example, msisdnHashed, identityDocumentHashed, etc. - For output, other results for every match apart from true/false may be conveniently added. For example: “access denied” for all attributes when input information such as the identity document does not correspond to the declared MSISDN. “not available” for an attribute when the MNO does not have that information available. - It is necessary for this API to handle different languages/character sets as local languages/character sets are usually used for some attributes e.g. name and address. - Some processing of the input attributes may be beneficial to harmonize the inputs, if applicable, to minimize false negatives when dealing with special characters of a Language or even to make different Languages compatible. For example, transforming strings to lower case, transforming German non-standard characters (ä->ae, ö->oe, ü->ue, “ß”->“ss”)*, transforming other non-standard characters ("àèìòù äëïöü âêîôû áéíóú ðý ãñõšžçåø“ become "aeiou aeiou aeiou aeiou dy ano szcao"), removing articles/prepositions, truncating strings to a specific length, etc. - Another way to minimize false negatives and make the final API more useful may be, for example, generating a matching score based on Levenshtein distance between strings instead of a true/false result based on equality. For example: “givenNameMatchScore”: “0.87”
Commercial viability	Currently KDDI provides the KYC match service commercially.
YAML code available?	YES / NO. To be provided
Validated in lab/productive environments?	YES In Commercial network
Validated with real customers?	YES It is available for KDDI customers, in B2B scenario.
Validated with operators?	YES It is available for KDDI in Japan, in B2B scenario.