KYC Fill-in Specifications

[ToshiWakayama-KDDI]

Problem description

There is only one proposal from KDDI for KYC Fill-in, so the initial version of KYC Fill-in will be KDDI's YAML base. However, some alignment to KYC Match API is needed, which can be discussed in this issue.

First of all, parameters/attributes for KYC Fill-in API should be agreed. It is believed that the general rule would be that parameters/attributes for KYC Fill-in API should be aligned with those of KYC Match API where applicable.

If you think this general rule is not appropriate, please give your view and alternative ideas.

Many thanks, Toshi

[GillesInnov35]

hi @ToshiWakayama-KDDI, I agree with you: KYC Fill-in API should be aligned with KYC Match API design. In fact the attributes list in Match API request design should be the same as the list of Fill-In API response except what the phone number. That's the case in Orange offers.

[ToshiWakayama-KDDI]

Hi @GillesInnov35 ,

Thank you for your commment. Could you explain a bit more about 'except what the phone number'? Do you use a different attribute name?

Thanks, Toshi

[ToshiWakayama-KDDI]

Hi all,

I would like to propose Fill-in API flows for our first version API documentation, as attached. It is very straightforward, highlevel and generic flow, which could apply to any use cases for Fill-in.

Any comments are welcome.

Note: It was created by PowerPoint and captured as a picture, because I am not familiar with tools for drawing flows. Please let us know if you are familiar with tools.

Many thanks, Toshi

[ToshiWakayama-KDDI]

Hi all, Regarding the parameters/attributes for KYC Fill-in API, as we are finalising those for KYC Match API, we can adopt the same ones for KYC Fill-in API as below:

• phoneNumber
• mainPhoneNumber
• idDocument
• name
• nameKanaHankaku
• nameKanaZenkaku
• givenName
• middleNames
• familyName
• postalCode
• address
• streetName
• streetNumber
• region
• locality
• country
• birthdate
• email
• givenNameInitial
• middleNamesInitials
• familyNameAtBirth
• houseNumberExtension
• gender
• cp_id

Please let us know if you have any other ideas.

Many thanks, Toshi

[ToshiWakayama-KDDI]

Hi all, Regarding the response parameter suffix, similar to the KYC Match API case, I would propose 'Fillin' as suffix.

attribute	Fill-in Response
attribute	attributeFillin
e.g. given name	givenNameFillin

Please let us know if you have any comment.

Many thanks, Toshi

[ToshiWakayama-KDDI]

Hi all, Regarding the Response Codes, I would propose the following based on KDDI's intial YAML contribution:

HTTP Result	KYC Fill-in Consolidated Proposal
400	Problem with the client request
	Code: INVALID_CHARACTERS_INVALID_PARAMS Message: invalid_characters/invalid_params
401	Unauthorized error. Access Token related errors.
	Code: INVALID_TOKEN Message: invalid_token
	Code: EXPIRED_TOKEN Message: expired_token
404	Not Found error. Error if URL is wrong / user is not found.
	Code: NOT_FOUND Message: not_found_contractor/not_found
500	Internal server error. Problem with MNO's server side. Some processing error within MNO's servers.
	Code: MAINTENANCE Message: System maintenance
	Code: MAINTENANCE Message: Service maintenance
	Code: SETTING_ERROR_SETTING_GET_FAILED Message: Setting error/ setting get failed
503	Service Unavailable. Problem with MNO's server side. Any unexpected error within MNO's servers.
	Code: UNAVAILABLE Message: sorry_error

Please let us know if you have any problem.

Many thanks, Toshi

[GillesInnov35]

@ToshiWakayama-KDDI , as the API return the same type of value as the Match request, why shoudn't we return the same attribute ?

attribute	Fill-in Response
attribute	attribute in response
e.g. given name	givenName

[ToshiWakayama-KDDI]

Closed as agreed.