Risk and fraud operations
Use device context without hiding the reasoning
Turn mobile observations into versioned backend features that can be calibrated, explained, monitored, and challenged.
The SDK is an evidence source
The SDK does not calculate a risk score, return a trusted verdict, or decide whether an action should proceed. It produces client-side observations that your trusted backend may use alongside account, transaction, behavioral, and platform-attestation evidence.
A defensible feature pipeline
- Bind the event. Associate collection with an authenticated session and a server-known action identifier.
- Validate quality. Check schema, SDK version, timestamp, probe outcome, platform, and freshness.
- Derive on the backend. Convert raw values into stable, documented comparisons or categories.
- Calibrate with labels. Estimate lift, coverage, false-positive impact, and interactions using representative historical outcomes.
- Monitor after release. Track drift, missingness, latency, outcome disparity, appeals, and rule contribution.
Feature families and cautious interpretations
| Family | Example derived feature | What it may support | Common caveat |
|---|---|---|---|
| Application provenance | signing_certificate_expected, installer_known, debuggable_release | Repackaging and unofficial distribution investigation | Enterprise, QA, and alternative-store delivery can be legitimate |
| OS integrity | integrity_evidence_count, grouped by evidence family | Instrumentation or modified-environment context | Client checks are bypassable and device-specific |
| Device security posture | secure_lock_available, trusted_time_disabled, patch_age_bucket | Step-up eligibility and investigation context | Capability differs by hardware and OS; patch age needs external mapping |
| Transaction safety | capture_active_at_action, remote_access_observed | Point-in-time review or user warning flows | Accessibility and support sessions are legitimate |
| Consistency | sim_network_country_mismatch, locale_timezone_mismatch, app_runtime_platform_mismatch | Contradictory context that merits corroboration | Travel, roaming, multilingual users, and stale location are common |
| Collection health | probe_timeout_rate, required_probe_missing | Telemetry quality and tampering investigation | Older devices and OS changes can affect probe reliability |
Velocity, account graph, IP reputation, transaction amount, behavioral sequence, and prior outcomes belong to the backend. They are not device SDK responsibilities.
Worked example: account recovery
Assume the customer is recovering an account from a mobile device. A backend feature view might contain:
{
"action": "account_recovery",
"telemetry_quality": {
"sdk_major": 0,
"event_age_bucket": "under_30s",
"required_probes_complete": true
},
"application_provenance": {
"bundle_expected": true,
"signing_certificate_expected": true,
"debuggable_release": false
},
"integrity": {
"emulator_observed": false,
"debugger_observed": false,
"strong_integrity_evidence_count": 0
},
"consistency": {
"sim_network_country_mismatch": false,
"locale_timezone_mismatch": null
},
"transaction_context": {
"screen_capture_observed": false,
"remote_access_observed": null
}
}null preserves unavailable or inapplicable evidence. It must not be silently converted to false. The feature view may contribute to a model or policy, but the decision should also consider authenticated account history, recovery method strength, transaction context, and a customer recovery path.
Consistency helpers
The package includes deriveConsistencySignals() for deterministic comparisons and deriveObservationMetrics() for bounded ratios, counts, and consistency checks over already-collected values. They omit unavailable calculations and never add weights, an identifier, or a verdict.
Calibration before enforcement
Shadow mode
Collect features without affecting customer outcomes. Establish coverage and operational stability across supported platforms.
Labeled analysis
Measure conditional lift against confirmed outcomes. Segment by app version, OS, hardware class, geography, and accessibility context.
Threshold review
Choose action thresholds from observed tradeoffs, not intuition. Separate allow, step-up, manual review, and decline objectives.
Ongoing monitoring
Watch population stability, missingness, feature contribution, false positives, complaints, and recovery success after deployment.
Operational guardrails
- Keep raw and derived schemas versioned and auditable.
- Do not train on a proxy label created by the same rule you are evaluating.
- Prevent future-outcome leakage when building historical datasets.
- Use time-based validation for changing fraud patterns.
- Review accessibility, travel, developer, refurbished-device, and low-cost-device cohorts.
- Require corroboration for high-impact actions and preserve reason codes.
- Maintain a safe recovery or human-review path.
- Recalibrate after SDK, OS, app-signing, or probe implementation changes.