Identity & Access Management

When a user initiates authentication, the platform queries the MNO's API with the phone number on the account. The carrier returns a signal indicating whether the SIM associated with that number has been recently changed. If a swap is detected, authentication is halted, and the account is flagged for verification through an out-of-band channel. The detection uses the carrier's own SIM assignment records — not inferred signals from device behaviour — which is what makes it reliable against a swap that has already completed before the authentication attempt.

Silent authentication uses MNO APIs to verify that the device initiating a session is connected to the network on the SIM registered to the account — without sending an OTP. The carrier confirms the match in the background. The user completes authentication without entering a code. This is used for low-risk session continuations and step-up authentication flows where reducing friction is a priority without removing the SIM-based verification layer.

The deprecated iOS APIs allowed direct SIM identifier reads. The replacement implementation uses network operator identity — the carrier name and network codes visible to the application — combined with SIM tray validation signals that change when a physical SIM swap occurs. These are combined into a binding token at registration and validated at each authentication event. The approach does not replicate direct ICCID access but produces a binding that detects the SIM change events that matter for fraud prevention.

Commercial SMS providers charge per-message rates that compound at banking application volumes. SMPP protocol integration connects the platform to a local SMS gateway — a direct routing path to carriers that removes the commercial provider layer. Message delivery follows the same carrier routing, delivery confirmation, and retry logic. The cost reduction of 60% reflects the margin difference between commercial provider pricing and direct gateway rates at high volume.

The authentication layer applies different factor combinations based on the transaction or session risk profile. A low-risk session continuation may use silent authentication alone. A high-value transaction triggers SIM binding validation plus biometric confirmation. A new device registration requires the full factor stack. The risk thresholds and factor combinations per scenario are configured during implementation and are adjustable without a code change.

IoT devices do not have a user present to complete a biometric or OTP step. Authentication for IoT devices uses device identity — a registered fingerprint bound to the device at provisioning — combined with session token management that enforces rotation and expiry. Access is scoped to the permissions the device registration defines. A device that presents a mismatched identity or an expired token is denied access and flagged for review.

Scope determines the timeline. A full implementation covering carrier API, SIM swap detection, device and SIM binding for iOS and Android, silent authentication, and local SMS gateway integration typically runs eight to fourteen weeks from architecture sign-off to production. iOS custom implementation adds time relative to Android, given the API constraint. We assess jurisdiction-specific carrier API availability during the discovery phase before committing to a timeline.

The system is handed over production-ready, tested against the carrier APIs in each target market, and documented at the integration and configuration level. Your engineering team manages authentication rule adjustments independently. We do not build on proprietary frameworks that require ongoing GeekyAnts involvement. If a formal support arrangement post-launch makes sense, that is a separate conversation.