What happens with Tenure when there is a change of phone number for the user

[HuubAppelboom]

What happens with Tenure when an end user ask to change their phone number to a new number (for example because they receive phone calls by a stalker), will the Tenure clock be reset ?

After all the end user and contract owner are still the the same.

[eric-murray]

Converted to discussion. If an issue is identified, the issue can be re-opened.

[GillesInnov35]

hi @HuubAppelboom, this is one of the main point for tenure I think. What tenure refers to ? is it the phone number or the user's contract. From what I know use cases concern fraud prevention, so msisdn is concerned. In my opinion tenure should concern the new one in your uc.
BR
Gilles

[HuubAppelboom]

In case you reset the clock with a change of phone number, that may lead to false positive signals which customers dont want. If the contract owner is still the same, and the underlying IMSI is also the same, I would not reset the clock.

[GillesInnov35]

hi @HuubAppelboom, yes it makes sense. I wonder if CAMARA API (Tenure in this case) should have to specify those functional rules implemented in the backend solution. Perhaps it should to meet the use case.

[eric-murray]

CAMARA can capture such requirements in two ways:

• As documentation in the OAS definition itself
• As pre-conditions for test cases within the test definition specification

So CAMARA should agree how the API will work for different scenarios, and capture this in the above documents. The documentation will tell the API consumer what should be meant by a given tenure response. But ultimately it is up to the API provider to follow these requirements, and CAMARA cannot enforce compliance.

[GillesInnov35]

hi all, @eric-murray , regarding scenarios and rules which MNO should applied, see bellow my understanding of Tenure's test cases and decisions

on 01/01/2012 John Doe opened a new line 06xxxx01
on 01/01/2014 John Doe opened a second line 06xxxx02
on 01/01/2018 John Doe modified 06xxxx02 by selecting a new mobile plan
on 01/01/2018 John Doe opened a third line 06xxxx03
on 01/01/2022 John Doe canceled line 06xxxx03

on 01/01/2025
Tenure {phoneNumber:"06xxxx02", tenureDate:"05/03/2022"} will return tenureDateCheck : false
Tenure {phoneNumber:"06xxxx02", tenureDate:"05/03/2015"} will return tenureDateCheck : true
Tenure {phoneNumber:"06xxxx01", tenureDate:"05/03/2012"} will return tenureDateCheck : true
Tenure {phoneNumber:"06xxxx03", tenureDate:"05/03/2020"} will return HTTP 40x
Do you confirm this is what we're waiting for the API's behavior ?
BR
Gilles

[HuubAppelboom]

@GillesInnov35 I don't understand the examples you give for 06xxxx02. Why would selecting a new mobile plan have impact on the tenure outcome ? If you change the mobile plan, and the user is still the same , the fraud risk is similar.
Moreover, I don't think ti is a good idea to expose information on whether a user has changed a mobile plan.
For both the examples you give for 06xxxx02, I would expect the return value to be true, because John Doe had the phone number in use at those dates.

[eric-murray]

Tenure {phoneNumber:"06xxxx03", tenureDate:"05/03/2020"} will return HTTP 40x

If 06xxxx03 has been re-assigned to another customer of the API provider, then the response will be HTP 200 with tenureDateCheck: false.

Even if not re-assigned to another customer, but still "owned" by the API provider (though not in use), I think the response should still be tenureDateCheck: false, but that is the sort of detail to be discussed and agreed. There is a separate API "Subscription Status" which allows the API consumer to know if the phone number is currently in use or not.

Only if the number was ported to a different API provider should the response be 404 IDENTIFIER_NOT_FOUND

For both the examples you give for 06xxxx02, I would expect the return value to be true, because John Doe had the phone number in use at those dates

I agree with @HuubAppelboom here. John Doe has had continuous tenure of 06xxxx02 since 01/01/2014, and a change of mobile plan does not change this. Mobile plans change all the time, and sometimes remaining on your current plan is not an option.

[GillesInnov35]

hi @HuubAppelboom , @eric-murray, sorry I've made a mistake in my first example. The tenureDate was wrong, date to be checked is TenureDate:"05/03/2012" and not "05/03/2022".
So in fact
Tenure {phoneNumber:"06xxxx02", tenureDate:"05/03/2012"} will return tenureDateCheck : false
Tenure {phoneNumber:"06xxxx02", tenureDate:"05/03/2022"} will return tenureDateCheck : true
BR
Gilles