Add postpaid / prepaid / business information to KYC Match

[HuubAppelboom]

In the current Mobile Connect specification of KYC Match there is also a feedback what type of subscription the user has.

We have recently seen quite some fraud cases in which this kind of information is valuable for developers. Most fraud cases happen in my country with anonymous prepaid cards, but for business user subscribers there is limited or no risk (because there sim cards are registered by a business).

I therefore we propose to include this kind of info also in the CAMARA version of KYC Match.

In the Mobile Connect spec it is specified as (optional) billing_segment, with Allowed values “PAYG”,” PAYM”, “Business”
See https://www.gsma.com/solutions-and-impact/technologies/mobile-identity/wp-content/uploads/2023/01/IDY.23-v1.0.pdf
Page 16.

[KevScarr]

@HuubAppelboom What rules would you propose for when those attributes are returned, ie how many (if any) of the fields provided would need to match before these values are returned?

[HuubAppelboom]

@KevScarr I would propose to make these return values optional, and let the MNO's decide on local market conditions in what case they return the data. For example, in case you have anonymous prepaid in a market, you always return the data, so the customer decide to ask for additional identification in case the answer is PAYG, ans skip this additional identifcation if the answer is PAYM or Business. In countries where identification for prepaid SIMs is regulated mandatory, I would only offer the data as at least for example family name is matching.

[KevScarr]

@HuubAppelboom Excellent - Sharing your best practise (like the above) or a recommendation would help everyone have a common service; I think this was one failing from the MobileConnect days as we had 4 different sets of logic in our country for when they would be returned. I fully accept your point, Camara can't mandate the return of these values.

[KevScarr]

Adding a comment here to show support for future inclusion into the specification - Spring'25?

[HuubAppelboom]

In case we also support this information with Tenure, there is no need to add this to KYC Match as well.

Tenure might indeed be a better place to share this kind of information. For customers that want to have both, they can always do a Tenure call as well (next to KYC Match).

[scarrk]

Our customers who are using the MobileConnect flavour of KYC wont migrate to Camara KYC until we provide the billing segment so they don't lose functionality (so we/VF will include in order to migrate customers to the new standard) using the camara naming convention/style.
I also support the inclusion in Tenure response (for all the reasons you've mentioned).

[claraserranosolsona]

@scarrk , I agree with the point made by Hub, as a general rule we would like to avoid duplicating same information in different APIs. If a customer wants to know the segment, they could call Tenure where it has been already agreed to expose this information. We can discuss this point in tomorrow's meeting.