Optional ageTiers parameter for privacy-preserving granularity

[yyeAduna]

Problem description
Current consumers of the API (e.g., banks) often need more granular signals to assess account-takeover risk alongside their own data. A simple boolean result (True/False) doesn’t provide enough detail, while returning the underlying event date/time isn’t feasible due to strict privacy requirements (e.g., GDPR) and operator restrictions. As a result, clients must make multiple calls with different maxAge values (for example, 1 hour, then 24 hours) to infer the risk level—creating unnecessary network and API load and poor overall performance.

Possible evolution
Introduce an optional input parameter ageTiers (list of integers) that enables a "Tiered Response" mode, where the highest tier is the maxAge.

Backward Compatible: If ageTiers is omitted, the API behaves exactly as it does today (using maxAge).

Privacy Friendly: Returns a tier index rather than an exact timestamp.

Efficient: Reduces N API calls to 1 call.

Alternative solution
make multiple calls with different maxAge values

Additional context
Samples1: Swapped at 3 hour ago

input:
{
"phoneNumber": "+1234567890",
"maxAge": 240,
"ageTiers": [1,4,24,72,240]
}

output:
{
"swapped": true, // Calculated using maxAge (3 < 240)
"tierIndex": 1 // 3 hours is > 1 but <= 4. It falls in the second bucket (Index 1).
}

Samples1: Swapped at more than 240 hour ago
output:
{
"swapped": false,
"tierIndex": -1 // out of the maxAge
}

[bigludo7]

Hello @yyeAduna
Thanks for the proposal. I tend to not get the value of the evolution regarding the added complexity.
IMHO our consumer want to know if there is a sim swap for the last x hours. this x is from their fraud policy rules and not sure why they will ask for an array.
Happy to hear from other companies.

[yyeAduna]

There are three reasons that the Age Tiers are useful for the SIM SWAP:

1. Banks' Risk Scoring is Probabilistic, Not Binary. Financial institution risk assessments are rarely binary "Yes/No" decisions. Instead, they are probability calculations designed to optimize the trade-off between Detection Rate (DR) and False Positive Rate (FPR). The acceptable "recent-ness" of a SIM swap (the MaxAge) fluctuates dynamically based on the transaction context. A routine login, OR a $200 P2P transfer, OR a $20,000 wire to a new beneficiary each requires a different risk tolerance. A rigid, single-threshold API forces banks to over-simplify this complex reality.

2. Prevention of Banks Information Leakage (Side-Channel Risk): If a bank is forced to send a different MaxAge parameter (e.g., "has swap occurred in the last 1 hour?") for different transactions, they inadvertently leak sensitive context to the MNO.
   By analyzing the strictness of the MaxAge request, an external party could infer the nature of the customer's transaction (e.g., a strict MaxAge implies a high-value/high-risk transaction) and reverse-engineer the bank's internal risk policies. It is something banks will try their best to stay way.

"Age Tiers" allow banks to request a standardized set of data without revealing the specific transaction trigger, preserving client privacy and corporate security. It perfectively solves the challenges from #1 and #2 at the same time.

3. Feature Engineering for Machine Learning Models Modern Banking fraud engines do not use SIM Swap data as a sequential "gate" (i.e., Check Swap -> If Safe -> Proceed). Instead, they ingest the SIM status as one of hundreds of weighted features into a Machine Learning ensemble (e.g., Random Forest) to generate a final risk score.

Reducing this signal to a boolean "True/False" is a form of lossy compression. It strips away valuable nuance.

Providing "Age Tiers" preserves data granularity, allowing the ML model to learn subtle correlations that a boolean flag would completely miss. Thus it increases the potential use case(s) and market this service can address.