Data Minimization for Protection Against Misuse of KYC Data

[EfthymisIsaakidis-DTCS]

Colleagues,
I am opening this issue in order to address the topic of how we can better protect the KYC Match/Fill-in APIs against misuse targeting to information phishing. Applying the data minimization principle, as described in EU GDPR and other relative regulations, can be of help to this direction.

A first idea/proposal is to establish a process during the onboarding of new Service Providers and/or New Services, where it will be agreed which KYC data fields are allowed to be exchanged, depending on the specific User Case requirements. This is already happening in many markets.

Then a mechanism that will enforce such agreement needs to be implemented. As discussed, such mechanism(s) are already in place in some "local" implementations. Whether such mechanism should be defined within our specifications needs to be discussed and decided. If yes, scopes can be used to define specific sub-sets of data fields allowed per scope, and SP access to KYC info can be limited to the specific scopes that will be allowed for each UC as required.

As mentioned in our call, this topic is under discussion also in ID & Consent sub-group, thus we should ensure that we are aligned with this discussion as well. However we also need to distinguish the topics of end-user consent for providing specific personal data and the "general" eligibility of an aggregator/service provider to request and get the specific kind of data.

Your feedback and comments are welcome.

Efthymis Isaakidis

[GillesInnov35]

hi @EfthymisIsaakidis-DTCS,

I've a question to your remark:

A first idea/proposal is to establish a process during the onboarding of new Service Providers and/or New Services, where it will be agreed which KYC data fields are allowed to be exchanged, depending on the specific User Case requirements. This is already happening in many market

I wonder if KYC Match is really concerned by this data minimization as it is only a control of provided information.
To well understand, do you have any Use case for Fill-In API where we need to restrict the level of identity description.
Thanks a lot
Gilles

[HuubAppelboom]

Hi @EfthymisIsaakidis-DTCS
For Match and GDPR it really depends what legal basis is applicable for the use case.

In case of user consent, you will need to inform the user when asking for opt-in what data is requested. The user can then decide whether they provide the data or not. If you really want to make it fancy, you can make a distinction between which fields are considered mandatory, and which are optional (and which the end user can decide to include or not).

For other legal basis, like legitimate interest which is often selected in case of fraud prevention, you can agree during the onboarding what data should be included. If the merchant asks in an API call more than agreed, you can simply reply with N-NA for that attribute, since that attribute is not available for the agreed use case.

[ToshiWakayama-KDDI]

To be moved to the new kyc-match repository, as agreed in 2025-09-30 meeting.

[HuubAppelboom]

The issue of over sharing data may be more relevant for KYC Fill-In than for KYC Match, because we Match presumably the API Consumer collects the data already- if they are over asking, people will not onboard, or leave items blank etc.

For KYC fill-in it may be useful to think about which data fields are mandatory (as seen by the API Consumer), and which are optional. And when you ask the user consent, he should be able to tick/untick the optional data fields...

[GillesInnov35]

all, there's no update on this issue. Does it mean data minimization topic has not been highlighted according to kyc-match implementation and usage ? The fact that the legal basis is Legitimate Interest should allow to manipulate data of identity held by the MNO.