Shastra · Device intelligence

Know the risk before you add friction.

Shastra combines device recognition, integrity, network context, permissioned behavioral signals, and optional merchant context into an on-device risk score — before authentication begins. Your policy decides what to do with the result.

Talk to us Explore device scenarios
  • On-device score + reason codes
  • No blocking backend round-trip for scoring
  • Android available now · iOS in development

The cost of getting it wrong

False declines cost 13× more than fraud.

Most merchants optimize for catching fraud. The larger loss is the legitimate customers they block — $443 billion a year, exposed by the tools meant to protect them.

$443B

lost to false declines annually

Aite-Novarica / Javelin

30–70%

of declined orders are legitimate

Signifyd

27%

of loyal customers never return after one false decline

Signifyd

6%

of orders declined on average — 65% are false positives

Aite-Novarica

Device context before the decision is made is how you stop blocking the customers you want to keep.

How it decides

Three devices, three different answers.

Recognition is the first question. Integrity, environment, and network context are what stop recognition from being naive — a device you know can still be a device in the wrong hands.

Consistent history and a familiar network contribute to a low-risk sample score of 18 / 100. Recognition does not establish who is holding the device.

On-device result · before 3DS Sample data
Device recognized
18

Low risk

Risk score 18 / 100. Higher means higher risk.

Consistent history and a familiar network.

Recognition and current device conditions are evaluated together.

RECOGNIZED_DEVICECONSISTENT_HISTORYKNOWN_NETWORK
Supporting detail
Bound since14 months ago
Prior authentications47
IntegrityPassed
Sample device binding: bnd_8f2a…b2a1
Recognition history, integrity, app environment, and network context.

Risk score: 0–100. Higher means higher risk. Scores and bands shown are illustrative; merchant-configured thresholds may differ.

Inputs and outputs

What goes in, and what comes back.

A compact neural network runs on the device and weighs four groups of signals together. One flag on its own is noise; the combination is what the score represents, and the reason codes tell you which part of it mattered.

01 · Device recognition & history

Has this device been seen before?

Recognition state and supported device history, so your policy can tell a returning device apart from a new one.

02 · Device & app integrity

Are the device and app what they claim to be?

Root and tamper indicators, emulation, hooking and instrumentation, debugger attachment, and runtime manipulation observed from inside the app.

03 · Network & session context

How does this session look?

Connection characteristics and whether they changed mid-session, plus permissioned behavioral context such as interaction timing and motion patterns, where enabled and disclosed.

04 · Optional merchant context

What is actually being asked for?

Optional and merchant-supplied. Amount and currency first; account age and billing or shipping relationships where the merchant can share them.

Device and app signalsRecognition, integrity, network and session, and optional merchant context.
On-device modelSignals are evaluated together.
Score and reasonsReturned to merchant policy. Risk score: 0–100. Higher means higher risk.
Device history Device integrity Network & session Merchant context ON DEVICE Neural net <1 MB model RETURNED LOCALLY Risk score 0–100 + reason codes
Nothing leaves the device to produce this Scale 0–100; higher means higher risk
ModelFEED-FORWARD NET
RuntimeON-DEVICE · ANDROID
Artifact size< 1 MB
InferenceLOCAL
Blocking round-trips0
OutputSCORE + REASONS

Risk score: 0–100. Higher means higher risk. Example bands: 0–30 low risk, 31–70 medium risk, 71–100 high risk. Merchant-configured thresholds may differ.

Recognition and history

Build context around returning devices.

Shastra returns a pseudonymous device binding and recognition context so your policy can distinguish an established device from a new one. Recognition is context — not proof of cardholder identity.

Continuity

Returning-device context

Use prior recognition and supported device history to add context to the current transaction.

Scope

Portfolio recognition where enabled

For platforms with the appropriate contractual rights and disclosures, recognition scope can extend across participating merchant apps. Scope and retention are configured for the deployment.

Data boundaries

Pseudonymous binding

The device binding is a technical reference, not a customer profile. Data fields, retention, and access boundaries are documented for the deployment.

Recognition context returned to your code
Device bindingbnd_8f2a…b2a1
Recognition stateRETURNING
Bound sinceJUL 2025
Prior authentications47
Scope configured per deployment Sample illustrative
1 authenticationUnknown
5 authenticationsEmerging
20 authenticationsLikely
47 authenticationsConfident
Illustrative history depth, not measured recognition accuracy. More history provides context; it is not proof of identity.

Native SDK context can expose mobile integrity and in-app signals that a browser-only integration does not provide in the same way.

Browser-only

What a browser integration typically sees

  • User agent and screen metrics
  • Coarse locale and timezone
  • Storage that expires, partitions, or gets cleared
  • Limited view of mobile app and device integrity
Native SDK

What Shastra adds

  • Whether this device has an existing binding
  • How long, and how many prior authentications, within the configured scope
  • Device and app integrity from inside the process
  • Connection context and optional merchant context

Integration and control

One call. A device decision your policy can use.

Shastra returns a device binding, recognition state, risk score, and reason codes to your application. Optional transaction context can be supplied by the merchant. The result stays in merchant policy and is not inserted into 3DS protocol messages.

  • Nothing is added to the 3DS messages

    The device binding and the score never enter AReq, CReq, or CRes. They are returned to the merchant's own code to act on.

  • The merchant decides what the answer means

    Your policy owns the decision. Shastra evaluates risk; your thresholds and rules determine the action. Configuring and applying merchant-owned policy through Mitra, without an app release, is in development.

  • Model updates without an app release

    Signed model artifacts are versioned and delivered at initialization, staged across traffic, with automatic revert to last known good.

  • Shadow mode first

    Score live traffic alongside your existing decisions and compare the two before a single transaction depends on it.

How the SDK integrates
Kotlin · Android · illustrative 
// Optional — context the merchant already has
val context = RiskContext.builder()
  .amountMinor(50000)
  .currency("USD")
  .build()

// Resolved locally during initialize()
val device = service.deviceDecision(context)

device.bindingId     // "bnd_8f2a…b2a1"
device.recognized    // true
device.priorAuths    // 47
device.boundSince    // 2025-07-14
device.score         // Sample: 18 / 100; higher means higher risk
device.reasonCodes   // [RECOGNIZED_DEVICE, …]

// Your policy, your call
if (device.recognized && device.score < policy.frictionlessCeiling) {
  checkout.requestFrictionless()
}

Illustrative API shape, for orientation.

How it is sold.

Shastra is licensed on its own and metered per scored transaction, independently of the 3DS SDK.

Standalone

Licensed independently of Kavaach and metered per scored transaction. Early customers can run Shastra in shadow mode against live traffic before using the score in policy.

Evaluation and rollout

Android is available for evaluation today; iOS is in development. Shastra operates independently of the 3DS flow, so evaluation runs alongside your existing policy.

Your thresholds, your data

Routing stays in your policy engine. Signals are permissioned, and data rights are set in the contract before anything is enabled.

Questions

Before you ask.

Does this mean our merchants can skip 3DS?

No. Merchant policy decides whether to invoke 3DS, subject to applicable authentication requirements. If 3DS is invoked, the issuer controls the authentication outcome and challenge decision. Shastra's result is returned to your code, not inserted into 3DS messages.

Which direction does the score run?

Shastra returns a risk score from 0 to 100. Higher means higher risk. Reason codes explain the risk context. The illustrated bands are 0–30 low risk, 31–70 medium risk, and 71–100 high risk; merchant-configured thresholds may differ.

How is the device binding derived?

Shastra derives a pseudonymous device binding from signals available to the native SDK. The derivation method is proprietary. The binding is not a PAN, CVV, authentication secret, advertising ID, or cookie. Exact signal use, retention, and disclosure requirements are documented for the deployment.

What happens the first time we see a device?

It is reported as unrecognized, with a new device binding created and a score that reflects having no history. An unknown device is not treated as a bad one — it is treated as a device worth authenticating properly.

Can recognition span multiple merchant apps?

Where contractually enabled, recognition scope can include participating apps in a platform or portfolio. This requires the appropriate data rights, disclosures, retention policy, and tenant isolation. It is not assumed or silently enabled.

Does it slow the transaction down?

Collection starts at initialize() and the answer is produced locally against a sub-megabyte model. There is no blocking network call in the checkout path, so the result is ready before the authentication request is assembled.

The rest of the platform.

Kavaach

Native 3DS SDK

Keeps the authentication step inside your merchants' app, working with the certified 3DS Server you already operate.

Explore Kavaach

Mitra

Visibility & policy control

See why each transaction scored the way it did and what happened next, then tune thresholds and rules from one surface. Policy controls are in development.

Explore Mitra

Shastra

Put device context to work.

Start in shadow mode, keep the comparison, and switch it on when the numbers are yours rather than ours.

Talk to us