INDUSTRIESBANKING & BFSI
The branch you can't see.
Retail banking now happens on hardware the bank does not own, cannot inspect and did not approve. This is where the loss starts, and what it takes to close it.
Four
channels to defend — app, netbanking, rails, assistant
One
device between your customer and their money
8 ms
to decide, inside the call you already make
Zero
customer records leaving your environment
01 — THE CASE
One morning, one customer, ₹18 lakh.
Nothing in this sequence looks like an attack to a server. Every credential is real, every device is the customer's own, every OTP arrives where it should.
09:14
A call from “the bank”The customer is told her KYC lapses today and is walked through installing a screen-sharing app to “complete the update”.SOCIAL ENGINEERING · OFF-PLATFORM
09:31
The handset is rootedA helper APK from the call grants root and disables the play-integrity prompt. The banking app keeps working exactly as before.DEVICE COMPROMISED · NO SERVER SIGNAL
09:38
A new SIM answers the numberA port-out completed at 03:00 means OTPs now land on the attacker's device, while the victim's own phone still shows full signal.NUMBER MOVED · OTP INTERCEPTED
09:47
Login succeeds, correctlyReal credentials, the customer's registered device, her usual city, her usual network. Every server-side check passes on the first attempt.AUTHENTICATED · NOTHING TO SCORE
09:51
A beneficiary is addedAdded from the victim's screen by hands that are not hers, and approved with the OTP that arrived on the swapped SIM.REMOTE CONTROL · GENUINE SESSION
09:52
₹18 lakh leaves in four transfersSplit under the review threshold, to accounts opened last month on an emulator farm. The fraud alert fires at 11:40, after settlement.LOSS BOOKED · RECOVERY UNLIKELY
WITH SENSE
The sequence ends at 09:51.The remote-control session, the rooted handset and the six-hour-old SIM are all on the transfer call before authorisation. The payment is held, a case opens with the four signals attached, and the customer is called back on the branch line.
A fraud engine sees the transaction. It cannot see the room the transaction is happening in.
WHY SERVER-SIDE RULES RUN OUT
02 — THE MAP
Four channels. What you see, and what they use.
Pick a channel to read the exposure in the bank's own terms.
WHAT THE BANK SEESA logged-in customer on a registered device, in her usual city, transacting inside the limits your app enforces.
WHAT THE ATTACKER USESRoot and Magisk to make the client editable, Frida to move the limit check, a screen-sharing tool to borrow the session, and a repackaged build for everything the real one refuses.
rooted_devicefrida_hookremote_sessionrepackaged_buildoverlay_active
03 — THE COUNTER-MOVE
Security that sits where the fraud does: on the device, in the request, around the model.
Three positions, one verdict format, one console. Not a rules engine to tune — evidence your existing engine has never had.
POSITION 01Inside the appThe SDK runs in the same process as the attack, so root, hooks, debuggers, overlays, screen sharing and repacked builds are detected where they happen — and the verdict travels on the transaction call, before authorisation.RASPIN-THREADCode ObfuscationBUILD-TIMEApp AuthATTESTATION
POSITION 02In the request pathNetbanking and API traffic is separated into customers and scripts on behaviour and network evidence, and the customer's number is proven on the handset itself rather than by an SMS that anyone holding the SIM can answer.Bot DetectionWEB & APISilent Mobile VerificationIDENTITYAccount TakeoverSESSION
POSITION 03Around the modelAssistant traffic is inspected in flight — prompt, retrieval, tool call, response — and every model, adapter and tokenizer is scanned and signed before it reaches a customer-facing flow, then re-verified where it runs.AI Runtime SecurityIN-PATHModel Security & TrustPRE-SHIP
04 — THE EXPOSURE INDEX
Eight ways a bank loses money on a device it doesn't own.
Open a line to read the mechanism and the control that answers it.
The victim installs a screen-sharing tool during a support call. Credentials, device and location are all genuine; only the hands are not. Server-side rules have nothing to fire on.Screen capture, remote control and accessibility abuse are reported from inside the app, and the payment is held pre-authorisation.
05 — THE FIRST NINETY DAYS
No core banking change. One release per channel.
01DAYS 1–30The app, in report-onlySDK into the existing build, no enforcement. Your fraud team watches a fortnight of its own traffic and sets thresholds on what it actually sees.
02DAYS 31–60Enforce where money movesHigh-value transfers, beneficiary changes and mandate approvals start carrying the verdict. Netbanking login and payment endpoints get scored.
03DAYS 61–90Onboarding, assistant, evidenceSilent number checks replace OTP on trusted journeys, the assistant path goes behind policy, and the console starts producing audit records.
WHAT THE AUDITOR RECEIVES
A signed verdict per transaction, with the signals that produced itDevice, build and model inventory across customer-facing flowsPolicy version history — what was enforced, and from whenIncident timelines assembled inside the reporting windowControl mapping maintained release by release
MAPPED TO
RBI cyber security frameworkRBI digital payment securityNPCI / UPI controlsDPDP ActPCI DSS 4.0OWASP MASVSISO 27001 / SOC 2CERT-In reporting
Every verdict is a signed record — device state, app build, signals, policy version, action taken. An incident review becomes a query rather than a reconstruction.
NEXT STEP
Give us one release. We'll show you what your app is running on.
A device-and-channel assessment across your banking app and netbanking traffic — tampering, remote-access sessions, emulator clusters, SIM-change exposure and bot load — read against RBI and NPCI control expectations.
Run the assessmentTalk to our BFSI team→Two weeks in report-only mode, on your own traffic, before anything enforces.