Skip to main content

SIM detection, verified calls, and secure capture on the device.

1) SIM Change Detection (Android)

Subtitle: Detect SIM swaps in real time to protect session integrity and prevent account takeover.

Overview
A lightweight background service monitors the device’s SIM state and reports changes to your STS backend. Typical statuses: NO_CHANGE, SIM_CHANGED, UNKNOWN.

How it works

  • The SDK periodically checks SIM state (with backoff to respect OS limits).

  • On change, it sends a minimal, signed payload (status + device/app metadata) to your backend.

  • Your risk engine applies rules (e.g., step-up auth, session revoke, temporary hold).

SDK & Permissions

  • Android telephony state permissions per OEM/OS version.

  • Event callbacks & webhook destinations configurable in STS Admin.

Security & Privacy

  • No sensitive content—only status and non-PII metadata.

  • Pseudonymize device identifiers; follow data-minimization policies.

Compatibility & Limitations

  • Android only; background restrictions apply on Android 10+.

  • Dual-SIM devices may require extra logic.

  • Not available on iOS.

Key Metrics (KPIs)

  • SIM change rate per 1,000 MAU.

  • Detection-to-action time (ms).

  • False-positive rate on Dual-SIM.

Integration Steps

  1. Enable SIM Change Detection in STS Admin.

  2. Add the STS SDK module + required permissions.

  3. Implement the webhook endpoint to receive events.

  4. Configure risk rules (e.g., block high-risk transactions within 24–72h after a SIM change).

  5. Test on single-SIM and dual-SIM devices.

2) Secure Call Verification

Subtitle: Verify bank-initiated calls to stop social-engineering and number spoofing.

Overview
Before the user answers, the SDK checks whether an incoming call was initiated by your bank and is safe. It returns: CALL_APPROVED, UNAPPROVED_RECENT_CALL, NO_RECENT_CALL, UNKNOWN.

Reference Architecture
Bank Call Center → STS Secure Call Backend → Mobile App SDK

  • API: POST /api/v1/ReportCall with phone_number, uid, and context.

  • SDK method: CheckCallStatus() returning one of the statuses above.

UI Guidance

  • Approved: Green banner/badge + concise explanation.

  • Unapproved/Recently flagged: Yellow warning with “Verify identity.”

  • Unknown: Neutral gray with safety tips.

Security & Privacy

  • Transmit only minimal metadata needed for verification.

  • Log decisions for audit; avoid storing raw audio.

Use Cases

  • Confirming outbound bank calls before sharing sensitive info.

  • Closing the loop on suspected spoofing.

Key Metrics (KPIs)

  • % auto-approved vs. challenged calls.

  • Reduction in social-engineering incidents.

  • Decision latency (ms).

Integration Steps

  1. Register call numbers & policies in STS Admin.

  2. Integrate the SDK and show inline banners based on status.

  3. Send ReportCall events to backend analytics.

  4. Configure push alerts for “approved call in progress.”

  5. Add in-app education (tooltips) about verified calls.

3) Secure Capture (Front Camera, Real-Time, No Storage)

Subtitle: On-device camera analysis with zero image storage and privacy-first design.

Overview
Secure Capture analyzes frames from the front-facing camera on-device and never stores or uploads images. Only analysis metadata is sent to your backend.

SDK Methods

  • startCapture() — start local analysis.

  • stopCapture() — stop analysis and clear buffers immediately.

UX & Permissions

  • Display a clear purpose statement before capture.

  • Request camera permission just-in-time.

Security & Privacy

  • No image transmission—only metadata.

  • Immediate buffer deletion after analysis.

Use Cases

  • Passive liveness signals for step-up auth.

  • Session anomaly detection (multiple faces, occlusions, spoof cues).

Key Metrics (KPIs)

  • On-device inference latency (ms).

  • Metadata event throughput (events/min).

  • False-positive rate on real users.

Integration Steps

  1. Enable Secure Capture in STS Admin.

  2. Add the SDK module and declare camera permission.

  3. Implement handlers to receive analysis metadata.

  4. Tune thresholds/heuristics by client profile.

  5. Provide a concise “Privacy Note” explaining on-device processing.


Back to top