Application Security (RASP)

A Web Application Firewall and API security controls operate at the network boundary — they inspect and filter traffic between the client and the server. They have no visibility into what is happening on the device running the application. RASP operates inside the application's runtime environment — it observes the execution context directly and can detect threat conditions that never produce anomalous network traffic. A rooted device, a reverse engineering tool attached to the process, or a screen recording running in the background are invisible to network-layer controls and detectable by RASP. The two layers are complementary, not interchangeable.

Android exposes SIM card identifiers — ICCID, IMSI — through standard APIs that a banking application can read and bind to at onboarding. iOS does not. Apple restricts direct SIM API access for privacy reasons, which means the standard Android SIM binding approach is not available on iOS. Our implementation uses network operator identity and SIM tray validation as proxy signals — combinations of values that change when a SIM swap occurs. This requires a custom detection model rather than a direct API read, and it requires validation against the specific ways iOS handles network identity across devices and carrier configurations. Most implementations skip this and leave SIM swap detection as an Android-only capability.

The standard React Native bridge operates asynchronously — native module calls from JavaScript are queued and processed on a separate thread, introducing latency between the security event and the application's response to it. For UI rendering, this latency is acceptable. For security instrumentation, where the response needs to happen within the execution cycle in which the threat is occurring, asynchronous processing means the threat may complete before the response reaches it. JSI provides synchronous access to native modules from JavaScript — detection and response happen in the same execution cycle, which is what makes real-time RASP practical in a React Native banking application.

DevRev receives diagnostic data needed for crash analysis and session replay — stack traces, device state at the time of the crash, and user interaction sequences leading to the crash event. The masking layer redacts field categories defined in the masking configuration: account numbers, card numbers, transaction amounts, names, addresses, and any other PII field types the configuration specifies. What DevRev does not receive is any data that would allow a person with access to the analytics platform to reconstruct a user's financial position or identity. The masking configuration is versioned and auditable, so the compliance team has a documented record of what the masking rules covered at any point in time.

Screen recording prevention uses OS-level APIs — specifically, the secure flag on Android window rendering and equivalent iOS mechanisms — to mark the application's views as protected content. The OS then excludes those views from screen capture, screen recording, and AirPlay/screen mirroring output. This applies at the view level rather than the application level, so it can be applied selectively to the screens that contain sensitive data — transaction confirmations, account balances, card details — while leaving non-sensitive screens unaffected. Attempts to bypass this through third-party recording tools are detected by Lookout SDK's runtime monitoring.

RBI's guidelines for mobile banking security require that security events — including authentication failures, unusual access patterns, and security control activations — be logged with sufficient detail to support audit investigation. Our backend logging captures each security event with a timestamp, the device identifier, the event type, and the context data relevant to the event — a SIM validation failure includes the validation mechanism used and the mismatch detected, a malicious app detection event includes the detection category and the Lookout SDK confidence level. This produces a structured, queryable audit record rather than raw application logs that require interpretation to extract compliance evidence.

A full RASP implementation — covering Lookout SDK integration, custom iOS and Android SIM binding, JSI security bridge, screen recording prevention, DevRev data masking, and backend compliance logging — typically runs eight to twelve weeks from architecture sign-off to production. The range depends on the complexity of the existing application's native module architecture, the specific RBI compliance requirements in scope, and whether the DevRev integration is greenfield or requires migration from an existing analytics platform. We assess scope during the discovery phase before committing to a timeline.

The implementation is handed over production-ready, tested against the threat scenarios it is designed to detect, and documented at the SDK integration, JSI bridge, and compliance logging levels. Your security team can adjust Lookout SDK detection thresholds and your engineering team can extend the masking configuration independently. We do not build on proprietary frameworks that require ongoing GeekyAnts involvement to operate. If a formal support arrangement post-launch makes sense, that is a separate conversation.