Enrich TenureInfo with customerType and pah fields

[shilpa-padgaonkar]

Problem description
The existing TenureInfo structure in the KYC Tenure API
provides a strong foundation for sharing customer tenure information.

To further enrich this model and increase the informational value for API consumers, it would be useful to include attributes that provide more context about the CSP’s end customer — specifically the type of customer relationship (e.g., prepaid, postpaid, or other) and whether the line belongs to the Primary Account Holder (PAH).

These attributes allow API consumers to better interpret tenure data and assess the credibility and reliability associated with the CSP’s customer relationship and strengthens confidence in the tenure data.

Possible evolution
The TenureInfo object can be enriched with two new optional fields:

TenureInfo: type: object properties: ... customerType: type: string description: "Describes the CSP’s customer relationship type. Possible values include: - prepaid: pay-as-you-go relationships - postpaid: billed contractual relationships - other: alternative relationships such as MVNO or partner-based associations" enum: [prepaid, postpaid, other] pah: type: boolean description: "Indicates whether the line belongs to the Primary Account Holder (PAH). True if the line is owned by the account holder, false otherwise."

These fields are optional providing a smooth evolution path for existing implementations.

Alternative solution

Additional context
This enhancement increases the contextual depth of tenure data, enabling API consumers to make more informed decisions when evaluating a CSP’s customer.

customerType complements contractType by clarifying whether the relationship involves prepaid, postpaid, or alternative business models such as MVNO etc., which can signal different levels of validation or risk.

The pah flag helps API consumers understand whether the tenure applies to the account holder.

Together, these additions make the Tenure API more insightful, credible, and interoperable, while maintaining simplicity.

cc @gmuratk

[ssarkar-vf]

@shilpa-padgaonkar agree with the proposal. We do have contractType = PAYG/PAYM/Business but happy to discuss any other suggestion.

[HuubAppelboom]

@shilpa-padgaonkar The current Tenure API already contains (optional) prepaid/postpaid/business information. I would be careful in adding more information, because that may lead to providing too much information, which may lead to discussion around privacy, and introducing another meachnism for controlling what is shared etc. It may be better to keep API's as atomic as possible, and for more information (like for example whether the end user is also the contract owner) create a separate API.
Likewise, information whether a phone number belongs to an MVNO, or what type of subscription one has may be deemed commercially sensitive. Part of this information (in case of full MVNOs) may already be present in a Telco Finder solution.

[shilpa-padgaonkar]

@HuubAppelboom We can surely provide an explanation clarifying how these additional fields differ from the existing ones.

However, I’m not sure I understand the privacy-related concern. This information is optional, and each provider can independently decide whether or not to support it. The approach is similar to KYC fill-in — providers are not required to support the full set of fields and may choose to enable only the subset that’s relevant to them.

[shilpa-padgaonkar]

@shilpa-padgaonkar agree with the proposal. We do have contractType = PAYG/PAYM/Business but happy to discuss any other suggestion.

Thanks @ssarkar-vf.

[HuubAppelboom]

@shilpa-padgaonkar The privacy concern is whether the information provided always contributes towards the purpose that you are trying to achieve, and whether it is strictly necessary to achieve that goal. If it is not strictly necessary, and you are trying to approve a case for legitimate interest (which is often the case for fraud prevention, it makes no sense to ask a fraudster for consent), you may run into trouble getting the use case approved.

For example, you mention in the list of attributes ah: type: boolean description: "Indicates whether the line belongs to the Primary Account Holder (PAH). True if the line is owned by the account holder, false otherwise."
If the end user of the subscription is not the contract owner, that is in my opnion not a clear indicator that it could be a fraudster (there are many bona-fide users that are not the contract owner), and you could get many false positives. Moreover, by adding this kind of information you may end up in a situation where API Consumers start profiling users, and use the data that comes along with Tenure for other purposes. For example if they want to target minors, they can probably use this information as an indicator, because probably there is a strong correlation with the age of the user when the user is not the one paying the bill.
Under GDPR you are expected to minimize the data that is being shared, and not provide extra data that may seem useful, but is not strictly required.

On the otther hand, if you do have verified information that the user is not the contract owner, it may make sense to add this as an optional parameter to KYC fill in or KYC Match, but in this case I would strongly not to provide fill-in information like first name or birthday, because you know it will not be correct (and you don't want the service to be abused).

[HuubAppelboom]

@shilpa-padgaonkar See also the discussion about data minimization here camaraproject/KnowYourCustomerMatch#38

[GillesInnov35]

@HuubAppelboom , @shilpa-padgaonkar, I agree with Huub's comments. egarding privacy aspects, we see that for FraudPreventionAndDetection purpose allowing often Legitim Interest mode we must take care of what kind of information are managed, that means information must be limited to the API concerns. In case Tenure API I'm not sure that pah concerns Fraud prevention.
To be discussed of course. Thanks

[shilpa-padgaonkar]

@HuubAppelboom and @GillesInnov35 — thank you for your comments.

I don’t wish to debate any points specifically related to GDPR. It’s important to remember that Camara is a global open-source initiative, with participants and contributors from across the world.

I’d like to again refer to the KYC-fill-in example, where we have fields such as:

kyc-fill-in:idDocument

kyc-fill-in:idDocumentType

kyc-fill-in:idDocumentExpiryDate

Participants from the EU might choose not to use idDocument, whereas participants from Asia may consider it a critical data point. Camara should not restrict its use simply because it may not be applicable or relevant in certain regions — the framework should remain flexible to accommodate diverse regulatory and business contexts.

Regarding the other point raised:

"If the end user of the subscription is not the contract owner, that is in my opinion not a clear indicator that it could be a fraudster (there are many bona-fide users that are not the contract owner), and you could get many false positives."

That’s certainly a valid perspective.
However, another way to look at it is that a PAH (Primary Account Holder) typically undergoes more rigorous verification checks and, therefore, carries higher credibility. This does not imply that users who are not PAHs should be viewed as potential fraudsters — rather, it highlights the different confidence levels associated with various user types.

[HuubAppelboom]

@shilpa-padgaonkar I don't think that the concept of data minimalisation is something that only applies to GDPR, you will also see this in other territories.

The problem if you overload an API with too much data which is irrelevant for the purpose, you will get discussions with regulators that will only allow the API to be used with user consent (which makes it a lot less usefull).

A much better approach is to keep the API's as atomic as possible; that way you can decide per API / scope / purpose whether user consent is required or not.

Regarding whether the user is also the contract owner: I don't think that it very useful for detecting fraudsters; fraudsters also don't like it when they can be traced via the contract owner (who presumably handed them the SIM); if there is an option for zero traceability, fraudsters will always choose that one.

[HuubAppelboom]

@shilpa-padgaonkar PS. If you look at what determines the chances that someone is a fraudster, there are many more data points that you could add, like where somebody lives, what their nationality is, what their income is, what their payment history is, whether they are male or female, how old they are, etc. I don't think it is a good idea to try an put that all into a single tenure API; it is much better to keep this information atomic, and decide for each use case what can be shared and on what legal basis.

[shilpa-padgaonkar]

@HuubAppelboom Just to clarify — should I understand your comment to mean that if I need the PAH indicator, I would require a separate API?

One additional follow-up question: is this your personal viewpoint, or does it reflect an official position?

[HuubAppelboom]

@shilpa-padgaonkar Yes, I would recommend to make that a separate API, so the principle of data minimization can be adhered to, and that we don't end up in a situation with a ton of optional data fields and fragmentation in the market, because every telco is making a different tenure package.

[shilpa-padgaonkar]

@HuubAppelboom Thank you for the comment.
However I do not agree to it and would like to hear what other participants think about this.

We would not like to offer our customers 2 different set of APIs, just so that we can offer an additional indicator.

[HuubAppelboom]

@shilpa-padgaonkar The other problem you get with this is that most telco's don;t have this information readily available, and that you end up with a similar construction like with Age Verification (where you have to verify given name etc to check whether the end user is the contract owner). In the end you will then probably end up with an API which does the same as with Age Verification for a certain age limit, because in many countries you have an age limit for signing legally a postpaid contract. In the Netherlands for example, this would be the case, and this would directly compete with the Age Verification API.