SIM Binding

SIM Binding is a mechanism that binds a user's app session and device identity to a specific SIM card via a secure SMS challenge flow. This ensures the user is authenticated from a known and verified mobile number, adding a layer of security to identity-based apps.

Flows Affected

Uniken's SIM Binding functionality kicks in when any device needs to be activated, without relying on privileged carrier APIs.

New Device Activation - user registers on app for first time
Additional Device Activation - user registers on a new device eg: changing to a new phone
Forgot Password - user has forgotten his credentials and needs to re-register

Design Summary

SIM Binding is enabled via a single config JSON in the “checkuser” challenge.
SDK triggers a one-time registration SMS containing an encrypted payload a.k.a - “SIM Binding Token”
The server receives, validates the SIM Binding Token.
Token is stored securely against the user-device and reused for subsequent logins
Slot and carrier data are encoded in per-device keys
As an added validation, SMS otp verification can also be coupled with the SIM binding process

Configurations

checkuser challenge info entries

SIM_BINDING_CONFIG

{
  "sms_gateway_numbers": "+919522211995",     //[Mandatoy]This param holds the enterprise's SMS gateway number/s (';' separated in case of multiple numbers)
  "sms_key": "ACT|REG|NDA|NL|QA|ENGG",    //This is an arbitrary short string/keyword which is prepended to the Sim Binding token, primarily used by the SMS gateway provider to do the routing of the SMS to the webhook endpoint
  "sms_key_content_separator": " ",       //[Default = " "] This value will be used as a separator between the Sim Binding Token and the sms_key, which will constitute the entire SMS that the end user will send -<sms_key><sms_key_content_separator><sbim_binding_token>
  "enforce_userid_check": "true/false",  //[Default = "false"] This value will decide whether the user ID will be prompted to the user and checked in the system before proceeding (if required) with SIM binding
  "enforce_smsotp": "false/PRE_SB/POST_SB",    //[Default = "false"] This value will determine whether SMS otp validation is to be done during the sim binding process and if yes then should it be done before starting with simbinding process (PRE_SB) or after completing the simbinding process (POST_SB)
  "android_sim_details": "__SIMTYPE__:__CARRIER__:__SIMSLOT__",  //These values are optional and support the macros mentioned in the config, the value dipict the default behavior if the keys are not configured
  "ios_sim_details": "__SIMTYPE__:__CARRIER__:__SIMSLOT__" //These values are optional and support the macros mentioned in the config, the value dipict the default behavior if the keys are not configured
}

Types of SIM Binding Flows

SIM Binding is configurable per client application through the Gateway Manager Console. When enabled, the app enforces SIM-to-device-to-user association device activation. The flow intelligently adapts to scenarios such as dual SIM, unregistered numbers, and OTP handling.

REL-ID supports 2 types of SIM Binding flows to cater to Banks and non-bank payment apps.

For banks, SIM selection first is a security-first approach — it leverages existing KYC data, cuts down onboarding steps, and detects mismatches early.

Wallets and non-bank payment apps, on the other hand, often capture the mobile number first because they may not have prior KYC records, and they need to know which number the user intends to register before performing SIM-based checks.

SIM Binding Flow Demo app

Upon app startup, the SDK queries its configuration to determine whether SIM Binding is enabled for this app. If not enabled, the flow proceeds directly to standard device activation. If enabled, SIM verification steps are introduced.

✅ Step 1: Ask for user permissions - added for SIM Binding

Following additional permissions have been added for SIM Binding

Android Permissions
iOS permissions

✅ Step 2: Request User Consent

The app explicitly asks the user for consent to bind their SIM to the device. This step ensures user transparency and is typically worded to emphasize added security benefits.

✅ Step 3: Prompt SIM Selection (for Dual SIM Devices)

If the device supports dual SIMs, the user is asked to choose the SIM slot that contains the mobile number registered with the service provider (e.g., bank or telecom app). This ensures accurate verification and avoids false mismatches.

✅ Step 4: Send Silent SMS for SIM Verification

The SDK sends an encrypted SMS from the selected SIM slot. For android this message is a silent message without user intervention, on iOS user has to click on send message. This message helps validate ownership of the mobile number, verifying that the number being used matches the one registered with the server.

✅ Step 5: OTP Delivery for Registered SIM

If the mobile number is successfully verified, an OTP is sent to the number via SMS. This acts as a second factor to confirm possession of the mobile number. Client can configure if they need otp verification or not.

✅ Step 7: Auto-Fill or Suggest OTP

The app attempts to auto-fill or assist OTP entry:

On Android, the OTP can be auto-filled via SMS permissions.
On iOS, the OTP appears in the keyboard’s suggestion bar (QuickType).

This improves user experience and reduces friction in the verification step.

✅ Step 8: Display Linked Bank Accounts

After OTP verification, the backend returns a list of bank accounts associated with the verified mobile number. The user is then prompted to select the account they wish to activate the app for.

✅ Step 9: Continue with Device Activation Flow

Once the user selects an account, the app proceeds with the rest of the device activation journey. This may include:

Email OTP verification
Document scan (ID proof)
Face or selfie match
Profile information setup

These steps vary based on the client app’s onboarding policy.

Complete End-to-End Scenarios

Scenario 1: Successful Flow (PRE_SB Configuration)

Workflow: GenerateOTP → SimBinding

Configuration: enforceSmsOtp = "PRE_SB" 
1. GenerateOTP Request → Rate Check → Allow (1/3 attempts) 
2. User enters OTP → Success 
3. InitiateSimBinding Request → No Rate Check (second step) 
4. SIM Binding Success → UserSessionTicketServiceImpl → Reset Rate Limit 
5. Event: SIM_BINDING_RATE_LIMIT_RESET

Scenario 2: Successful Flow (POST_SB Configuration)

Workflow: SimBinding → GenerateOTP

Configuration: enforceSmsOtp = "POST_SB" 
1. InitiateSimBinding Request → Rate Check → Allow (1/3 attempts) 
2. SIM Binding Success → Continue to OTP 
3. GenerateOTP Request → No Rate Check (second step) 
4. User enters OTP → Success 
5. Event: SIM_BINDING_RATE_LIMIT_RESET

Scenario 3: Rate Limit Exceeded (PRE_SB Configuration)

Workflow: GenerateOTP → SimBinding (rate limit on first step)

Configuration: enforceSmsOtp = "PRE_SB" 
1. GenerateOTP Request → Rate Check → Allow (1/3 attempts) 
2. GenerateOTP Request → Rate Check → Allow (2/3 attempts) 
3. GenerateOTP Request → Rate Check → Allow (3/3 attempts) 
4. GenerateOTP Request → Rate Check → BLOCKED 
5. Response: "Rate limit exceeded for OTP generation attempts" + Event: SIM_BINDING_RATE_LIMIT_EXCEEDED 
6. Wait cooling_period (24h) → Rate limit expires → Reset

Scenario 4: Rate Limit Exceeded (POST_SB Configuration)

Workflow: SimBinding → GenerateOTP (rate limit on first step)

Configuration: enforceSmsOtp = "POST_SB" 
1. InitiateSimBinding Request → Rate Check → Allow (1/3 attempts) 
2. InitiateSimBinding Request → Rate Check → Allow (2/3 attempts) 
3. InitiateSimBinding Request → Rate Check → Allow (3/3 attempts) 
4. InitiateSimBinding Request → Rate Check → BLOCKED 
5. Response: "Rate limit exceeded for SIM binding attempts" + Event: SIM_BINDING_RATE_LIMIT_EXCEEDED 
6. Wait cooling_period (24h) → Rate limit expires → Reset

Scenario 4: Device Registration Reset (Both Configurations)

1. User completes Step 1 → Rate limited after multiple attempts (3/3 attempts used) 
2. User completes Step 2 successfully (when rate limit allows) 
3. User completes other required challenges successfully 
4. Device Registration Process → ActiveUserNewDeviceRegistrationState/ActiveUserNotBoundState 
5. Device Registration Success → Reset Rate Limit automatically 
6. Event: SIM_BINDING_RATE_LIMIT_RESET 
7. User's rate limit is cleared for future SIM binding attempts