What to do with portin date with Number Recycling and Tenure

[HuubAppelboom]

This morning we had a discussion in the KYC SP meeting on how Number Recycling and Tenure should handle the portin date of phone numbers.

The discussion has risen due to the draft publication on the whitepaper Functional Differences (Use-Case & Data Semantics Edition) for SIM Swap, Device Swap, KYC Tenure and Number Recycling which you can find here https://lf-camaraproject.atlassian.net/wiki/spaces/CAM/pages/288489512/CAMARA+APIs+-+Functional+Differences+Use-Case+Data+Semantics+Edition

One view is to differentiate between Tenure and Number Recycling:

• with Tenure, always consider the port-in date as the start date of the number for a subscriber
• with Number Recycling, do not consider the port-in date as a recycling event (assuming the same subsrciber had control over the subscription before the port-in date).

The other view would be to treat the port-in date the same (so always as the start date for the association of the number with the subscriber), or in case the port-in also includes the original start date of the subscriber with the previous MNO, use that earlier date as a start date.

There may be also alternative solutions possible, but please keep in mind that this will only work if all API providers implement these API's the same way, so that it is clear for developers what to expect.

Your thoughts and ideas please,

[HuubAppelboom]

If you ask me, we should clearly position Tenure to be used when the API Consumer onboards a new end user, while Number Recycling should be used when the API Consumer already knows the end user, and the end user wants to log in again using his phone number as 2nd factor. At onboarding, you simply want to know how long a user has been using a phone number, and use that as a risk factor for fraud. During the life cyle of the end user with the API consumer, you want to know whether the same end user still has control over the phone number, and the login can succeed.

For the case of where there is nothing know about the history before the phone number is ported in, I think we should apply the following:

• For Tenure, simply use the port-in date as the first date of association of the phone number with the end user. If you would ignore this, you may be missing fraudsters abusing the portin process to make phone numbers look like they have been long in use. The negative side of this is that after a port in, the end user may experience that onboarding new services becomes a little more cumbersome (he may have to provide additional proof he is not a fraudster, for example with extra identification steps).

• For Number Recyle, the API consumer knows the end user was trust worthy in the past. If the last login date of that login event was before the port-in date, you may end up in the strange situation that when the end user ports his number, all his accounts that are protected with 2FA start asking for his new number (or an alternative authentication factor) in case the port in date is consider a number recyled event (which it is not). To prevent this kind of friction, I think we should definitely not mark the port-in event as a "number recycled"event. The drawback is ofcourse that there may have been "number has been recycled" events happening in the past before the port-in, so it is important to point this out to the API Consumer. (this can be done in the documenation, or at onboarding, or by providing an extra attribute that you only check Number Recyling events durung the life time with the current API Provider).

[HuubAppelboom]

In the case the original association date of the phone number and the susbcriber is passed on between telco's during the porting process, you probably want to use this original association date, both for Tenure and Number Recycling. In that case, the two API's become more of the same (with the exception that Tenure also contains the billing segment information). In this case you probably never want to consider the port-in date as a reset of the Tenure date or as a Number Recycled date, but always use the original association date. What may be better then is to add both to Tenure and Number Recycling an attribute to the reply which indicates whether history before any port in is is also included. For example a "history" attribute, which has possible values "only_with_current_provider" or "all_providers". That way the API consumer can know whether he has full information on the life cycle of the phone numer, or only with the current API provider.

[Masa8106]

@HuubAppelboom , thank you for opening this issue.
So far my views on Number Recycling are the following:

• As there may be operators which can't get information on a start date for a users before port-in date from operator the user ported out, I think it would be better to avoid defining same port-in supported responses among the operators.
• On the other hand, same responses where port-in date regards as Number Recycling date would be good, because the pursose of Number Recycling is to avoid mis-delivering messages. So if the port-in date is criteria of response, the misdelivering risk doesn't increase.
• I think we can discuss the alternative solution with additional attribute like "history" to show the API consumer the full information on the phone number life cycle. We can discuss the best way how to implement such attribute in the yaml.

[HuubAppelboom]

@Masa8106 Hi Masahura,

I think what needs to be considered with Number Recycling and Tenure is primarily what the API will be used for, and what the differences are.

Tenure should be positioned to be used by API Consumers when onboarding new end users (which the API Consumer is not familiar with). The end users involved here will be both legitimate end users as well as potential fraudsters. The idea is that Tenure can help separating that end user group which ony recently has become active (because that usually involves fraudsters), so the API Consumer can perform here additional checks to single out the fraudsters (like asking additional identitification), or restrict processing to less risky transactions. If you would ignore the port-in for Tenure, you will starting treating for example end users which have a relative short history (for example 3 month with one telco, and 1 month with a new Telco after port-in) the same way as end users with a long history, and that is not a very good idea, because you will be missing the fraudsters. So here it makes sense to flag the port-in as a Tenure start-date.

Number Recycling should be used on existing users after onboarding. This group of end users only contains legitimate users (because they have been previously onboarded), and which have been using their mobile number for 2 factor authentication in the past. For this group it makes no sense to treat a port-in as a "number recycled" event, because the API Consumer knows the end user was already legitimate, and before and after the port-in the end user is still the same. From the end user perspective it also makes no sense, because they will notice that after porting their mobile number they will would be asked to register their new number (which they don't have, they are still using the same number). So here it is better to ignore the port-in.

So concluding, because of the differences in end user groups (one is not yet verified and may contain fraudsters, and the other has already been screened and should be considered legitimate) the treatment of the port-in should be differentiated.

[KevScarr]

Would agree with @HuubAppelboom around the use-cases and when each API would be used.
For (line) 'tenure' any previous history with another MNO (prior to a port) should be ignored (as it's how long the current provider has known that line for). For NumberRecyling (should be tied to Quarantines - noted exception in the document around MSISDN Port). Unclear if it's considered 'recycled' at the start-of or end-of the quarantine period.
Is there a use-case to expose port-in indicators?

[Masa8106]

@HuubAppelboom , thank you for your reply.
It is reasonable that it needs to be considered what differences between two APIs are. However I still wonder how an operator which receives NumberRecycling API request can get information on the onboarding date in the past before port-in from another operator which an end user used to subscribe bofore port-in. Could you elaborate how to do that? (This is a question for all.) It would be good to hear an actual example.

@KevScarr , I see one of the use case is to avoid a message misdelivering. It is one of the main purposes of NumberRecycling. This is becuase even an operator which cannot get an information of the onboarding date in the past before port-in response to API request with the port-in indicators.

[albertoramosmonagas]

Hi, from the TEF side (I'm speaking on behalf of Clara Serrano, who is having problems logging into her GitHub account), we're agree with @HuubAppelboom and @KevScarr, in summary few points:

(Line) Tenure: activation date of the MSISDN in its current telco

• MSISDN activation (new or recycled)
• Port in activation
• Prepaid – postpaid change activation (as it is reflected in the systems as a new activation, and additionally risk profile could * change)

Number Recycling: change of ownership in its current telco,

• Could be checked in the contractual records OR
• From the MSISDN lifecycle: check if the MSISDN went through the recycling process (activation->deactivation->quarantine period-> recycled to a new user). Note total new activations or port ins are not considered recycled events as they do not strictly imply a change of ownership, there is no information of the ownership of the MSISDN when it belonged to another network

Difference: Line Tenure within its current operator (phone number activation date) vs Phone Number ownership change within its current operator (phone number recycled and assigned to someone else). Tenure does not specify the source of activation while number recycling only refers to line activations from a contract owner to another one in the same provider (MNO).Also, note that SIM cards can be handed to a person who is not the contract owner (for example, in family contracts where multiple lines are in use by family members but the MNO only keeps track of the contract holder).

Complementarity: Combined, Number Recycling can inform there has not been a change of ownership within the phone number Tenure. Beyond that Tenure, the API Provider does not know because the number belonged to another MNO.

[Masa8106]

Hi, from KDDI side, we can't agree that Number Recycling does not consider the port-in date as a recycling event, as far as we can't clarify on how an operator which receives NumberRecycling API request can get information on the onboarding date in the past before port-in from another operator which an end user used to subscribe bofore port-in.
We see the use case is to avoid a message misdelivering. If the port-in event doesn't mark as a "number recycled"event, API invoker may miss "number has been recycled" events happening in the past before the port-in. This is a risk of misdelivering a message for the API invoker.

I think the difference in opinion comes from the differing nature of the use cases we are considering, 2FA and misdelivering prevention. Therefore, I believe it would be good way forward to have an attribute to reply whether history before any port in is also included or not.

[HuubAppelboom]

Hi all,

Following the discussion of this morning there seem to be at least four possible solutions (and there may be more):

1. Don't change anything to the current API specifications. For use cases where you want to prevent that the wrong end user is receiving messages intended for someone else, use Tenure. For use cases where you want to prevent 2 factor accounts to become locked, use Number Recycling (and don't mark the port-in date as a Number Recycling event).
2. Add an extra optional return parameter to the Number Recycling API, which tells whether the date requested by the API Consumer was before a port-in date. So the answer for the API remains a boolean, but an extra parameter is added.
3. Change the answer for the Number Recycling API from a boolean to a 3 state answer for example "true, false, unkown". If there has been any Number Recycling event to your knowledge, you answer yes, if there was no event to tour knowledge, you answer no when the request date is after the port-in date, if the request date is before the port-in date, you answer unknown
4. What you can also do is in case the request date is before a port-in date, always return unknown (or an error code).

Note that solution 3 may not be backwards compatible with current implementations.

Please consider these options in the coming weeks, and let's try to come to an agreement in our next meeting.

Regards
Huub

[GillesInnov35]

Thanks @HuubAppelboom , your comment on backward compatibility breaking on solution3 is important. As I understand the API has been already implemented in some countries, I don't support this option.
BR
Gilles

[Masa8106]

@HuubAppelboom , thank you for listing possible solutions.

So far, I believe solution#2 would be good way forward, as I mentnioned before.

For my clarification, may I ask you what is "an error date" in solution#4?

[HuubAppelboom]

@Masa8106 that should be port-in date, I corrected it

[GillesInnov35]

for solution2, what kind of response could be returned ?
I don't see exactly how to manage the phoneNumberRecycled boolean field with the added attribute. Is it still required ?

[HuubAppelboom]

@GillesInnov35 For solution 2, the return could look like:

{
"phoneNumberRecycled": false,
"specifiedDateBeforePortIn": false
}

And yes, the phoneNumberRecycled is still need, this reflects what happens with the number after the PortIn

[GillesInnov35]

@HuubAppelboom , in your use case does it mean: unknown ?