Questions on Tenure responses for edge cases

[brettrhill]

1. I noticed that the api spec has been updated and that tenureDateCheck in the response can now only be true or false, no option for not_available. What we should return if we for whatever reason have found the customer but don't have the service tenure available?
2. There could be privacy issues on querying tenure over an unlimited time. Would limiting our responses to x number of years (probably 1-5) be an issue?

[HuubAppelboom]

1. For other APIs a 422 error can be used, see also the discussion here 200 OK "not_available" vs 422 SERVICE_NOT_AVAILABLE for not_supported lines KnowYourCustomerMatch#51

2. Regarding the tenure api, there are roughly 2 kinds of applications. One is to detect the risk that a new user (from perspective of the API Consumer) is a fraudster who is using anonymous prepaid. The other one is to give a kind of credit score indicator. The older a phone number is, the older the subscriber, and older people usually have more income.
   So it depends on whether you want to support both use cases or not. For credit score, you may not want to put restrictions on (but you may need to ask for user consent in this case)

In case you only want to support the use case to detect a fraudster, you may want to put a limit of a couple of years on it, depending on how patient fraudsters are. One thing to keep in mind is that (especially with prepaid), you may have phone numbers which are preconfigured, and wherre the msisdn is some time on stock before being used. In case you can't see the actual start date (of usage), you may want to choose a bit longer limit. Usually API Consumers also have to balance between false positives and fraud detection, so they tend to choose a relative recent tenureDate, so I don;t think you will need to set an upper limit in practive for these cases.

In the case you don't allow credit score usage, you may also want to consider that the API Consumer can only check the Tenure once for a given phone number. That may be an alternative which limits the usage (and trying to find out what the start date is).

[GillesInnov35]

thanks @HuubAppelboom for your comment.
@brettrhill, you noticed that the api spec has been updated but I don't see any version where tenureDateCheck prperty's type has been something else than a boolean. Could you clarify, thanks.
For the second point and to complete @HuubAppelboom comment, PR #56 has been closed to update specifications by adding a note

Note: MNOs may implement a threshold for the tenureDate aligned with their respective regulations. In that case if the tenureDate value in the request body is over the operator's threshold an error 400 OUT_OF_RANGE is returned with an explicit message to explain the limitation.
BR Gilles