permanent id Number

[FabrizioMoggio]

Do we need to introduce the permanent identification number?

I'm creating this discussion to drive all the different thread on this topic into this discussion. We still need to discuss about the topic before opening an Issues and creating a PR specifically on this topic.

This discussion continues what we discussed here about the persona identifier:
#207
#197

[HuubAppelboom]

@FabrizioMoggio I think in spain Telefonica is already using the persistent identification number (which makes sense), but in other markets (FR, NL) this is not allowed.

One more proposal to see if we can somehow share what identification number is being shared in the idDocument field:

We can also add a field "idNumberType", with as possible values personalAdministrativeNumber and documentNumber

That may be simpler for developers to handle than to put all kinds of tags in the idDocument field.
It can work both for KYC Match and for KYC Fill In.
And in case you need to have both numbers processed, you do 2 subsequent API calls.

WDYT ?

[FabrizioMoggio]

That's a good idea. To implement this it would be better, in my opinion, to modify the name from idDocument to idDocumentNumber to make the life easier for the Developer to better understand the meaning of the variables.

Possible Solution:

idDocumentNumber:
type: string
description: Identification number associated to the official identity document in the country. It may contain alphanumeric characters. It can be permanent (assigned by the government once and for all) or temporary (e.g. modified at each document renewal).

idDocumentNumberType:
type: string
enum: [permanent, temporary]

idDocumentType:
type: string
enum: [passport, national_id_card, residence_permit, diplomatic_id, driver_licence, social_security_id, other]
description: Type of the official identity document provided.

Alternative Possible Solution:

if we don't want to change the name of idDocument:

idDocument:
type: string
description: Identification number associated to the official identity document in the country. It may contain alphanumeric characters. It can be permanent (assigned by the government once and for all) or temporary (e.g. modified at each document renewal).

idDocumentType:
type: string
enum: [permanent, temporary]

idDocumentCategory:
type: string
enum: [passport, national_id_card, residence_permit, diplomatic_id, driver_licence, social_security_id, other]
description: Type of the official identity document provided.

Anyway, I initially was a bit confused because idDocument is not the identification document but it is the number inside the identification document. Nevertheless, I understand the compatibility issue with the other KYC APIs, so we can move on with the second solution.

[HuubAppelboom]

Better leave idDocument as is, because that is already in use.

For the enum, maybe better to use [personalNumber, documentNumber] (after all a documentNumber is also permanent, it never changes for that document)

[FabrizioMoggio]

Possibile solution:

idDocument:
type: string
description: Identification number associated to the official identity document in the country. It may contain alphanumeric characters. It can be personal (assigned by the government once and for all) or related to the identification document (e.g. modified at each document renewal).

idDocumentType:
type: string
enum: [personalNumber, documentNumber]
description: states if the idDocuments refers to a personal identifier (assigned by the government once and for all) or if it is elated to the identification document (e.g. modified at each document renewal).

idDocumentCategory:
type: string
enum: [passport, national_id_card, residence_permit, diplomatic_id, driver_licence, social_security_id, other]
description: Type of the official identity document provided.

[FabrizioMoggio]

Are we planning to introduce this in Fall25?

[FabrizioMoggio]

Please let's continue here: camaraproject/KnowYourCustomerMatch#13

[FabrizioMoggio]

unless we think this is a general discussion that could impact also other APIs in the KYC match family