NPCI-recognised · UPI 2FA · India

Bind the session to the SIM.

SIM Binding locks a user's account to one SIM in one device. The SIM is verified at the network layer, then watched for the life of the session — and the moment it's swapped, cloned, or removed, the session is revoked. No code to intercept. No window for takeover.

Talk to our team See how it works
SNA-verified· Instant revoke on swap· RBI & NPCI aligned
SIM Binding · Session Monitor Live
Session active SIM change detected Session revoked SIM matches binding record Subscriber identity moved Re-authentication required
Mobile +91 70699 14791
SIM subscriber 8991·1010·5☐☐☐☐·a91f …a91f→ …7c20
Carrier · slot JIO · slot 1
Bound device iQOO I2410
SIM matched · session token valid POST /sim/validate · comparing record… Mismatch · token killed · forced re-auth
<1s
Revoke on SIM change
3
SIM-presence methods
−85%
SIM-swap fraud
2FA
NPCI-recognised factor
The problem

The number is the identity. So attack the SIM.

Mobile numbers anchor login, payments, KYC, and recovery. That makes the SIM the highest-value target in the stack — and SIM-based fraud has climbed accordingly. SIM Binding closes the gap by proving possession at bind time and enforcing it for the whole session.

Attack surface

What breaks when the number alone is trusted

  • SIM swapAttacker socials the carrier into porting the number to a new SIM.
  • SIM cloningA duplicate SIM receives the same OTPs and call routing.
  • Account takeoverThe next OTP resets the PIN — the wallet is drained.
  • Device–SIM mismatchA valid session continues on a SIM that has quietly changed.
  • OTP interception & replayCodes are phished, screenshotted, or captured in transit.
The guarantee

What SIM Binding holds true, end to end

  • Possession is proven, not assumedThe user must prove the SIM is physically present before binding.
  • The session is leashed to the SIMIt stays valid only while the exact bound SIM remains active.
  • Any change is caught in real timeOS-level SIM events trigger validation against the binding record.
  • Mismatch means instant revokeThe token is killed and re-authentication is forced — no grey area.
  • Audit trail by defaultEvery bind, check, and revoke is logged for RBI / NPCI evidence.
The architecture

Four layers. One source of truth.

Binding is built from four cooperating layers — prove the SIM is present, read what it is, store the 1:1 link, then watch it for the life of the session.

LAYER 01
SIM-presence auth
Prove the SIM is physically in the device — via SNA, an outbound SMS token, or OTP with sender-ID validation.
LAYER 02
SIM identification
Read the identifiers that uniquely represent the SIM — carrier, MCC/MNC, and SIM subscriber ID.
LAYER 03
SIM binding record
Store a secure 1:1 link — subscriber ID, user ID, timestamp. The source of truth for every future check.
LAYER 04
SIM activity monitoring
Listen for OS-level SIM broadcasts — removed, swapped, carrier changed, eSIM disabled — and act in real time.
The end-to-end lifecycle
01
Authenticate presence
SNA, outbound SMS token, or OTP + sender-ID confirms the SIM is real and present.
02
Collect identifiers
Read carrier, MCC/MNC and SIM subscriber ID from the verified SIM.
03
Store binding record
Backend writes the 1:1 SIM ↔ user link and opens the session.
04
Monitor the SIM
The app listens for SIM-state changes for the whole session lifecycle.
05
Change → revoke
A mismatch against the record kills the session token immediately.
06
Re-authenticate
The user re-binds on the new SIM before access is restored.
Steps 04–06 run continuously — the binding is enforced, not a one-time check.
Presence verification

Three ways to prove the SIM.

Before binding, the SIM must be proven present. Pick by UX, telco support, and device capability — OTPless routes to the strongest available method and falls back automatically.

Primary

Silent Network Auth

network-grade · zero-tap

The carrier confirms SIM ownership silently over the mobile-data channel. No SMS, no prompt, no user action.

  • Zero friction, runs in the background
  • No SMS cost or permissions
  • Needs mobile data on the bound SIM
Fallback

Outbound SMS token

highest possession proof

The device sends an SMS carrying a one-time bind-token to a VMN. Because it originates from the SIM, the MSISDN cannot be spoofed.

  • Strongest proof — SMS comes from the SIM
  • Works without internet connectivity
  • Needs SMS permissions and an active pack
Fallback

OTP + sender-ID

RSMS · UPI-recognised

An OTP is sent over a registered sender ID; the app validates the code, sender-ID authenticity, and device integrity together.

  • Familiar UX, broad device reach
  • Sender-ID check blocks spoofed routes
  • Auto-read needs Android GMS 24.20+
Attribute Silent Network Auth Outbound SMS token OTP + sender-ID
Possession assuranceNetwork-gradeHighestHigh
User frictionZero-tapOne silent sendReads OTP
ConnectivityMobile dataNone requiredSMS delivery
PermissionsNonePhone · SMSSMS read
Fallback orderPrimarySecondThird
Detection & revocation

A changed SIM ends the session.

Binding is only as strong as how fast you notice a change. The SDK listens for every OS-level SIM event and re-validates against the binding record on the spot.

SIM removed
The bound SIM is pulled from the device.
SIM swapped
A different subscriber ID appears in the slot.
SIM disabled
Subscription state drops or the SIM deactivates.
Carrier changed
MCC/MNC shifts — a port or new operator identity.
eSIM profile deleted
The embedded profile is switched or removed.
Reboot with new SIM
Device restarts holding a SIM that isn't the bound one.
Revocation flow Enforced
01
SIM event fires
The OS broadcasts a SIM-state change; the SDK reads the current subscriber ID.
02
Validate against the record
App calls POST /sim/validate with the live SIM identifier.
03
Backend compares
The stored binding record is checked against the presented SIM.
04
Mismatch → revoke
Session token is killed; the user must re-authenticate on the new SIM.
Flagship · UPI payments

Recognised by NPCI for UPI.

Every UPI account must be bound to the SIM that holds the registered mobile number — NPCI and RBI treat it as a recognised 2FA factor. The legacy outbound-SMS flow is slow and opaque. SIM Binding via SNA makes it silent, fast, and audit-ready.

NPCI · Recognised
UPI SIM binding · SNA Secure
01
User enters mobile in the UPI app
No outbound SMS, no permission prompt.
02
SNA verifies the SIM at the operator
The carrier confirms the SIM matches the MSISDN — silently.
03
PSP / bank receives a signed bind token
The token is validated before VPA creation proceeds.
04
UPI handle bound to the verified SIM
Account ready · audit trail preserved · no SMS sent.
Onboarding conversion lift
+30%

Measured against outbound-SMS binding.

SIM-swap & spoofing fraud
−85%

On first-time binding flows.

P90 bind time
≤3s

Silent — no SMS sent.

Integration

Bind once. Validate on every SIM event.

One SDK call binds the SIM after presence is verified. The SDK then watches SIM state and re-validates against your backend — you just handle the verdict.

SimBinding.kt android · kotlin 
import com.otpless.main.OtplessManager
import com.otpless.dto.SimBindRequest

// 1. Presence verified → bind the SIM in the chosen slot
val req = SimBindRequest()
req.setPhoneNumber("91", "7069914791")
req.setSlot(0)

otpless.bindSim(req, ::onBound)

// 2. Listen for SIM-state changes for the session's life
otpless.onSimChange { event ->
    val res = otpless.validateSim()   // → /sim/validate
    if (res.status != "MATCH") {
        session.revoke()                // kill token
        startReauth()                   // re-bind new SIM
    }
}
// build.gradle  implementation 'io.github.otpless-tech:otpless-android-sdk:2.5.3'
POST /sim/validate
120ms
bindingRecord · stored
subscriberId…a91f
userIdusr_8c21f
boundAt1778612141195
presented · live SIM
subscriberId…7c20
carrierAIRTEL
eventSIM_SWAP
slot0
verdict
SIM match MISMATCH
⊘ session.revoked ↻ reauth.required
action: REVOKE_SESSION latency: 120ms
Frequently asked

Common questions.

Is SIM Binding mandatory for UPI apps in India?
Yes. NPCI and RBI guidelines require a UPI account to be bound to the SIM that holds the registered mobile number, and SIM Binding is recognised as a 2FA factor. OTPless implements this with SNA as the primary method and SMS-based fallbacks, with a full audit trail.
Which presence method should we use?
SNA is the default — it's zero-friction and network-grade. Outbound SMS token validation is the strongest possession proof and works without internet, but needs SMS permissions and an active pack. OTP with sender-ID validation is the broadest fallback. The SDK picks the strongest available method and falls back automatically.
Does it work with eSIM and dual-SIM devices?
Yes. The user selects the slot at bind time, and the binding record stores that SIM's subscriber identity. eSIM profile changes — switched, disabled, or deleted — are detected as SIM-state events and trigger the same validation and revocation flow.
How fast is revocation after a SIM change?
Effectively immediate. The OS broadcasts the SIM-state change, the SDK reads the live subscriber ID and calls /sim/validate, and a mismatch kills the session token in under a second — before the next sensitive action can run.
What permissions does the app need?
SNA needs none. The outbound SMS token method requires read-phone-state and SMS permissions to send and confirm the bind-token. OTP with sender-ID needs SMS read for auto-fill on supported Android versions. SNA-first keeps most users on the zero-permission path.
What stops a man-in-the-middle on the bind token?
The outbound SMS token is single-use, at least 35 characters with mixed character sets, expires in ≤45 seconds, and is rate-limited per attempt. The SIM must be active — airplane-mode and no-network states are rejected — so a token can't be replayed or relayed off-device.
Bind the SIM

Stop trusting the number. Bind the SIM behind it.

SNA-verified binding with instant revoke-on-change — NPCI-aligned and audit-ready. Talk to us about a binding pilot on your app.

Talk to our team Read the docs
SOC 2 · ISO 27001 · NPCI · RBI aligned