Proposal for adding (optional) SIM type information

[HuubAppelboom]

For API Consumers that want to process SIM Swap information as a protection against SIM Swap fraud, it may be beneficial to know what type of SIM Swap was performed, since there may exsist differences in the issueing proces between eSIM cards and physical SIM cards.

By adding the type of SIM card (physical SIM or eSIM) as an optional parameter to the SIM Swap API, API Consumers can differentiate according to the difference in risk associated with the different issueing process.

We propose to add both the type of the new SIM and the old SIM as optional parameters to be returned with the SIM Swap API, for example the parameters

• currentSIMtype
• previousSIMtype

Both parameters need to be optional, and it should be decided by the API Provider whether they only want to share the currentSIMtype, or both the currentSIMtype and previousSIMtype.

What do you think of this enhancement ??

[loloci7]

@HuubAppelboom we are supportive and I am very aware of what this is trying to solve. I also think we need to dig a bit deeper in whether eSIM quick transfer (available in iOS) or device to device transfer (Android) changes the IMSI/MSISDN pairing. I have received anecdotal feedback that it does (still need to verify). If this is the case I believe we should analyse if there is a way to show that the recorded SIM Swap was only as a result of this quick transfer to reduce the false positives. Customers like financial institutions should not be blocking or making it harder for users to onboard if the resulting "SIM Swap" was only as a result of eSIM Quick Transfer. Thoughts?

[HuubAppelboom]

@loloci7 If we can detect somehow a quick transfer or a device to device transfer, that may help in reducing false positives.
There is one assumption here, and that these transfers are inherently more secure / less susceptible to fraudsters. However, you may still need to flag these events as well in case fraud could still occur. In that case you may want to categorize the different kinds of SIM Swap processes, and communicate these as well. For example, you can have a process where an (e)SIM is re-issued in a store after showing a verified ID (passport etc). Another process could be where the user scans a passport online (with NFC), takes a selfie etc. And yet another process could be where the user re-install an eSIM profile from a selfcare environment.

All of these process could have different risk profiles, and I am not sure we should go as far to try to share these, because of the complexity.

Another approach could be (in stead of trying to categorize the various processes) is to simply try to detect SIM Swap fraud with extra information. For example, by adding information on location just before and after a SIM Swap. If the location is far apart, that could be an indication of SIM Swap fraud. Another datapoint could be to compare the IP address of the WIFI the user is on, just before and after SIM Swap. If it is the same, you can probably assume the user is on the same wifi network (and the 2 handsets are in vincinity).