Shastra
Device intelligence
On-device transaction risk intelligence that gives merchant policy the context to decide what should happen next.
Explore ShastraMitra · Visibility & policy control
See every decision. Control what happens next.
Mitra gives merchants one operating surface for transaction risk, authentication outcomes, and policy control. Understand why a transaction scored the way it did, see what happened during 3DS, and tune thresholds and rules as your risk strategy evolves.
01
Why did this transaction score this way?
See the risk score, reason codes, device context, and recognition state behind an individual transaction.
02
What did our policy do?
Understand which merchant-owned threshold or rule was applied and whether the transaction proceeded without additional authentication or moved into 3DS.
Rule controls in development
03
What happened when authentication ran?
Inspect the 3DS outcome, challenge type, latency, and protocol diagnostics when Kavaach was invoked.
From visibility to active risk operations.
Mitra is designed as both the lens and the control surface for Vyuha. Today's demo shows transaction-level visibility across risk and authentication. The next control layer lets merchants configure thresholds and rule-based decisions from Mitra, so policy can evolve without changing application code.
Use Mitra with Shastra to understand scored transactions and tune risk policy, with Kavaach to diagnose native 3DS, or with both to connect the original risk decision to the final authentication outcome. It is an optional add-on; neither product needs it to function.
Mitra
partner: acme-payments
Illustrative · sample data
Policy controls
In development
Scope
Portfolio (selected)MerchantApp
Risk thresholds
0–30Low risk
31–70Medium risk
71–100High risk
Merchant rules
- IF integrity_failed THEN require_3ds
- IF risk_score > 75 THEN require_3ds
- IF known_device AND risk_score < 25 THEN follow_low_risk_policy
Transaction view
7c3e…d18
56
Medium riskShastra risk score 56 / 100. Higher means higher risk.
UNSEEN_DEVICENEW_NETWORK
Merchant policy31–70 band → require_3ds
3DSInvoked · Kavaach
Challenge01 Text · 2 rounds
Outcomecompleted
Decision + outcome in one transaction view. Policy controls are in development. Scores and thresholds are illustrative; merchant-configured thresholds may differ.
Start with one failure.
Here is a single authentication that did not complete, and the reason it did not.
Mitra
partner: acme-payments · last 24h
Sample data
| Transaction | ACS | Challenge | Outcome |
|---|---|---|---|
| 4f2c…a19 | demo.acs03 | 01 Text | completed |
| 9b71…c04 | demo.acs01 | 05 HTML | failed |
| c3a8…77e | demo.acs02 | 02 Single | completed |
| 1d50…b62 | demo.acs06 | 04 OOB | timed out |
LENGTH
One failure, explained
Round 1 of transaction 9b71…c04 failed because challengeInfoText arrived from demo.acs01 over its specified maximum length.
That is a specific field, a specific issuer ACS, and a count you can take to them — instead of a transaction that simply did not complete.
Sample data from a fictional partner portfolio. No live connection.
Explore sample Mitra Hide sample Mitra
Auth success▲ 1.4pt
96.2%
1.84M authenticated / 1.91M initiated
Frictionless▲ 2.1pt
71.8%
28.2% routed to challenge
Challenge E2E▲ 0.3s faster
4.5s
initialize → completion · p95 11.2s
Challenge success▼ 0.8pt
88.4%
11.6% abandon or fail at challenge
Sample finding: elevated failure rates at demo.acs01 and demo.acs06.
Transaction log
transaction-level viewSample transaction records
| 3DS Server txn ID | Merchant | ACS | Route | Challenge | E2E | Fields | Buffer | Outcome | Details |
|---|
—
Diagnostics
ACS fault matrix
challenge-fail rate by ACS × UI type last 7d
Fail rate
0% → 25%+
value = fail% · n = volume
| ACS | 01Text | 02Single | 03Multi | 04OOB | 05HTML |
|---|
Sample failure rates by issuer ACS and challenge type. Field-level diagnostics appear alongside.
Problematic CRes fields
validation failures by field by acsRefNumberMISSING absent · FORMAT malformed · LENGTH over limit · ENUM illegal value
ACS health
where authentication is degrading sorted by fail rate| ACS | Volume | Fail rate | Trend | CRes | Timeouts |
|---|
Challenge type mix
frequency vs. fail rateIllustrative challenge distribution. Frequency and failure rate describe different aspects of the sample.
Latency by phase
median contribution to E2Ep50
initialize()credentials + snapshot A
0.5s
Device databuild + encrypt for the DS
0.3s
Challenge setupnative UI + first CReq
0.4s
CReq / CRes roundsACS + cardholder
2.9s
Completeparse, validate, return result
0.4s
E2E median 4.5s · p95 11.2s · challenge rounds are 64% of E2E
Outcomes over time
last 24h, stacked by result success abandon fail timeout00:0006:0012:0018:00now
Your policy. Clear decision boundaries.
01
Issuer decisions stay issuer-controlled
Merchant policy decides whether to invoke 3DS. If 3DS is invoked, the issuer controls the authentication outcome and challenge decision.
02
No card secrets
Vyuha does not need PAN, CVV, or authentication secrets to provide transaction-level risk and diagnostic visibility.
03
Merchant-controlled policy
Your policy owns the decision. Shastra evaluates the risk, and Mitra gives you the controls to define the thresholds and rules that determine what happens next. Applying merchant-configured policy through Mitra is in development; it does not replace issuer authentication decisions.
The rest of the platform.
Mitra
See what your mobile traffic is actually doing.
Discuss transaction visibility, policy controls, and portfolio scope for your integration.