[KYC-Match]: Birth & Citizenship Information

[FabrizioMoggio]

The goal is to introduce additional fields commonly required by AML and KYC regulations:

placeOfBirth:
type: string
description: City and country where the customer was born.

nationality:
type: string
description: ISO 3166-1 alpha-2 code of the customer’s nationality.

Why?
Both attributes are often mandatory in banking, insurance, and governmental onboarding procedures.

[GillesInnov35]

hello @FabrizioMoggio , the question is also to know if a maximum of operators keep those information on contracts to be compared.
Thanks
Gilles

[PaoloCommissari]

Hi @GillesInnov35 , thank you for your thoughtful question.

We fully support @FabrizioMoggio proposal to include placeOfBirth and nationality in the data model. These fields are not only commonly used — they are in fact required or strongly recommended by various international and national regulations governing KYC (Know Your Customer) and AML (Anti-Money Laundering) compliance.

To address your point: yes, many operators do retain this information — not only as part of onboarding workflows, but also as a legal necessity. For example:

• The FATF (Financial Action Task Force) — whose recommendations guide AML laws globally — explicitly includes place and date of birth and nationality as core identity attributes.
• The EU AML Directives (4th, 5th, and 6th) mandate the collection of these fields, especially in contexts requiring Enhanced Due Diligence (EDD).
• At the national level, countries like Germany, France, and Italy legally require institutions to collect and store this information during customer onboarding.

Beyond compliance, these fields are also crucial for:

• Identity verification across borders (e.g., passport matching, sanctions screening)
• Interoperability between systems and services using standardized identity schemas
• Ensuring that CAMARA APIs can be adopted by regulated industries without compliance blockers

For these reasons, we strongly endorse the inclusion of placeOfBirth and nationality in the KYC API spec, as proposed.

Thanks

P.

[GillesInnov35]

Thanks @PaoloCommissari , let's see durning the next periodic KYC meeting if we validate creation of an issue.
BR
Gilles

[ToshiWakayama-KDDI]

Thanks, @Fabrizion, @PaoloCommissari,

It is good to add useful attributes as optional.

If placeOfBirth and nationality are required in Europe, adding them should be fine. But handling these information may vary in regions and countries. I don't think we collect these as they are sensitive information.

Another comment on nationality. I think some countries allow citizens have more than one nationality. We should consider how to handle that if we agree to add the nationality attributes.

Thanks,
Toshi

[FabrizioMoggio]

Dear @ToshiWakayama-KDDI I see your point on nationality. We could collect the information as array of codes (ISO 3166-1 alpha-2 code).

[GillesInnov35]

hello, I think as those 2 parameters will be optional we could had them.
For case of moe than nationality we should simply let the back-end service comparing the input value with information he has in IT (as it may be done for the address).
Gilles

[FabrizioMoggio]

@GillesInnov35 do you mean to just keep it as one string, e.g. with comma separated values? such as:

nationality: IT, ES

rather than an array of strings containing IT and ES in separate rows?

[GillesInnov35]

@FabrizioMoggio ,no what I mean is that only 1 value could be provided. The MNO back-end service should compare the input value with all values it kept.

[PaoloCommissari]

Hello everyone,

Since most identity and KYC standards globally already support multiple nationalities, it makes sense to model nationality as an array of ISO 3166-1 alpha-2 codes.
An array fits better with real-world scenarios (like dual or multiple citizenships) and greatly simplifies validation and interoperability with regulations such as FATF, eIDAS, and ICAO 9303.

Why an array is better than a single string with delimiters:

• Multiple Nationalities Are Legally Recognized
  Many countries (e.g., Italy, France, Canada, UK) officially allow dual or even multiple citizenships.
  The [FATF Recommendation 10](https://www.fatf-gafi.org/en/recommendations/10-customer-due-diligence.html) explicitly requires proper customer identification, including all relevant nationalities when applicable.

• Validation and Parsing Simplicity
  An array allows for direct schema validation: each item must be a valid 2-letter ISO 3166-1 code.
  A single string with delimiters (like commas, pipes, etc.) would complicate validation rules, increase parsing complexity, and introduce potential errors.

• Alignment with Global Standards

  • The [eIDAS Regulation](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A32014R0910) (EU 910/2014) permits multiple nationalities to be recorded in electronic identities.
  • [ICAO Doc 9303](https://www.icao.int/publications/pages/publication.aspx?docnum=9303) (passports) recognizes that individuals can possess multiple nationalities, even if only one appears on the document.
  • [ISO/IEC 29115](https://www.iso.org/standard/45138.html) emphasizes the management of multiple identity attributes for robust authentication (indirectly supporting multi-national identities).

Suggested field definition:

nationality:
  type: array
  items:
    type: string
    description: ISO 3166-1 alpha-2 code of the customer’s nationality.
  description: List of nationalities of the customer, represented as ISO 3166-1 alpha-2 codes.

Benefits:

• Clean and reliable validation.
• Easier client- and server-side handling.
• Fully aligned with legal and regulatory requirements (FATF, eIDAS, ICAO).
• Scalable for real-world onboarding and KYC scenarios.

Thanks

P.

[HuubAppelboom]

@PaoloCommissari In case of multiple nationalities, what is the proof that the end-user has presented ? Do you also record then the different ID Documents numbers, validity date, names, and date of birth of these different documents ?

[PaoloCommissari]

Hi @HuubAppelboom,

regarding the handling of users with multiple nationalities, normally only one nationality is recorded: the one from the identity document used as proof.
In fact, this is why I had proposed it as a single string field.

thanks

P.

[FabrizioMoggio]

I suggest to keep it simple and coherent with the ID Document provided. So the provided Nationality should be just the one related to the ID Document. If the API Consumer want's to verify an user with more nationalities, it should also have more ID Documents and it can anyway make one API call for each Nationality/ID-Document. Otherwise we should manage both nationality and ID-Documents as arrays and I'm not sure that the added complexity is worth it.

[FabrizioMoggio]

PR about this issue: #204

The PR introduces two new inputs:

• placeOfBirth
• nationality

And the related output parameters:

• placeOfBirthMatch
• placeOfBirthScore

and

• nationalityMatch
• nationalityScore

[FabrizioMoggio]

It is better to split city and country like:

cityAtBirth
countryAtBirth

rhater than merging them into just one variable (placeOfBirth)

[GillesInnov35]

hello @FabrizioMoggio , if we have a look at TMF Party Individual API specifications, placeOfBirth is used for city information. It might be interesting to be aligned with those attributes naming.
https://www.tmforum.org/oda/open-apis/directory/party-management-api-TMF632/v5.0

WDYT

Gilles

[FabrizioMoggio]

that's a good idea.

[ToshiWakayama-KDDI]

Close this discussion, as it has been moved to the new kyc-match repo with PR #204 closed, and it has been addressed for the Fall'25 meta-release.