Skip to main content
RASP (Runtime Application Self-Protection) is the on-device half of Device Intelligence — code that runs inside your app and inspects the device and runtime environment it’s executing in, without needing a network round-trip to make an initial assessment. It’s built against NPCI2025-26IS003, the mandatory mobile application security circular for UPI PSPs, ASPs, and TPAPs, and against CSIRT-Fin guidance for the controls that circular doesn’t fully specify.

​
Why RASP, specifically

Server-side fraud scoring answers “does this transaction look risky.” RASP answers a prior, narrower question: “can I trust the device this transaction is coming from at all?” A rooted device with Frida attached can, in principle, be used to script around almost any client-side control — RASP’s job is to detect that condition itself, as early as possible, rather than only inferring it indirectly from downstream transaction patterns.

​
Detection categories

RASP is organized into detection categories, each independently scored and combined into a final decision (see Scoring & decisions below).
Android: su-binary presence across known paths, root-management app detection (Magisk, KingRoot, SuperSU and others), Magisk filesystem markers, build.prop tamper flags (ro.debuggable, ro.secure), and a system-partition write test.iOS: jailbreak-tooling path checks (Cydia, Sileo), sandbox-escape probing, and a fork() capability test — fork() only succeeds on a jailbroken iOS sandbox.A single root indicator is weighted; several together escalate quickly, since a genuinely rooted device rarely trips only one check.
Root-management tools like Magisk’s DenyList are specifically designed to hide root status from apps that check for it the usual way. RASP’s countermeasure is a native check below the Java/Kotlin (or Swift) layer: reading the kernel’s TracerPid field and probing ptrace(PTRACE_TRACEME) directly via JNI/C (Android) or sysctl() (iOS). This runs beneath the layer most root-hiding and instrumentation-hooking tools operate at, so cloaking that defeats a Java-layer check often doesn’t defeat this one.
Build fingerprint and hardware-string analysis (goldfish, ranchu, vbox86 — QEMU/emulator hardware identifiers that don’t appear on real devices), CPU ABI checks (emulators are overwhelmingly x86/x86_64; real phones are ARM), and accelerometer-absence detection (every real device has one; most emulator images don’t simulate it).
Java-layer debugger attachment checks, a 4-port scan for Frida’s default listening ports, Frida server binary presence, and a scan of loaded process memory/dylib maps for known instrumentation-framework signatures (Frida, Substrate, Xposed).The same native ptrace/TracerPid check from root-cloaking resistance doubles as the strongest signal here — a Frida script attaching to a process is, at the kernel level, indistinguishable from a debugger attaching, and neither can prevent that native check from seeing it.
Android: runtime signing-certificate hash, compared against your app’s known-good hash. A mismatch means the APK was repackaged with a different key — this is a hard block, not a weighted signal, because a repackaged app is categorically a different binary, not a riskier version of your app.iOS: no equivalent runtime signature API exists for third-party apps, so this is a sideload heuristic (App Store receipt presence + absence of an embedded provisioning profile) — meaningfully weaker than Android’s cryptographic check, and documented as such rather than presented as equivalent.Also covers: install-source validation (Play Store/App Store vs. sideload), and allowBackup misconfiguration (Android).
Malicious-app detection against a server-maintained threat list (banking trojans and known fraud tooling), suspicious Android AccessibilityService detection (the dominant vector for on-device overlay/keylogging attacks), overlay-permission checks (tapjacking risk), and screen-recording/mirroring detection.
VPN detection via OS-level transport capabilities (not IP-reputation heuristics, which false-positive heavily on legitimate corporate VPN users), and proxy configuration detection.
Certificate pinning enforced at the SDK’s networking layer, capped at 3 pins (primary + two backups) per NPCI2025-26IS003 — independent of the OS certificate trust store, so a compromised or MITM-injected CA certificate doesn’t defeat it.
A device-bound cryptographic key generated in Android Keystore (TEE or StrongBox-backed) or iOS Secure Enclave — the private key never leaves secure hardware, so it can’t be extracted even from a rooted device’s filesystem. Used to produce a stable, non-spoofable device signature for server-side verification.

​
Scoring and decisions

Every evaluation produces a rasp_score (0–100) and a rasp_action: Full field-level detail on what’s in the scored payload is in Webhooks & Payload Reference.

​
Primary use cases

UPI / payment apps

The core NPCI2025-26IS003 compliance surface — root, tamper, and instrumentation detection at every payment initiation.

Banking app login

Device trust as a factor alongside credentials — a REVIEW verdict routes to step-up auth instead of a flat allow/deny.

Lending / KYC onboarding

Detecting scripted, automated onboarding attempts and device farms during account creation.

Marketplace checkout

Card-testing and bot-driven checkout abuse detection ahead of payment gateway hand-off.