> ## Documentation Index
> Fetch the complete documentation index at: https://docs.authmatech.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Identity Intelligence: Trust, Shield & Detect Explained

> How Authmatech turns mobile identity activity into a trust score, a real-time fraud decision, and behavior anomaly detection — Trust, Shield, and Detect.

Verification tells you a customer controls their number. **Identity intelligence** tells you whether to trust the action they're about to take. Three products — Trust, Shield, and Detect — answer three different questions from the activity Authmatech sees.

| Product    | Question it answers                               | Looks at             | Returns                                          |
| ---------- | ------------------------------------------------- | -------------------- | ------------------------------------------------ |
| **Trust**  | How trustworthy is this identity overall?         | Its history with you | A 0–100 score + `ALLOW`/`REVIEW`/`BLOCK`         |
| **Shield** | Should we allow this specific action right now?   | The live session     | A decision: `ALLOW`/`CHALLENGE`/`REVIEW`/`BLOCK` |
| **Detect** | Is there a pattern of abuse around this identity? | Many events together | A list of anomalies + recommended action         |

<Note>
  **The scoring logic is deliberately opaque.** Authmatech does not publish the exact signals, thresholds, weights, or score bands behind these products — doing so would help bad actors stay under the line. Integrate against the outputs documented below (`trustScore`, `decision`, `anomalies`, `reasonCodes`, etc.); treat the internals as a black box that can change.
</Note>

## Shared signals

All three accept the same building blocks in the request body, so you collect them once and reuse them:

* **`device`** ([DeviceSignal](/guides/trust-shield-detect)) — platform, OS version, model, app/SDK version, and integrity flags such as `isRooted`, `isEmulator`, `vpnDetected`, `proxyDetected`, and `appIntegrityStatus`.
* **`network`** ([NetworkSignal](/guides/trust-shield-detect)) — `ipAddress`, `countryCode`, `operator`, and `connectionType`.
* **`mobileNumber`**, **`sessionId`**, and an optional **`sdkSessionId`** that links back to a verified SDK session.
* **`metadataId`** — your own correlation id, echoed back on the response so you can join results to your records.

<Tip>
  Pass the `sdkSessionId` from a recent [verification](/guides/verify) so Shield and Detect can compare the live request against the device context captured at verification time. This is what powers consistency checks like "same device?" and "operator changed?".
</Tip>

## Authmatech Trust

Trust distils an identity's **track record with your account** into a single, identity-grade number, so you can drop confidence into decisions. It reflects history and behaviour over time — not a snapshot of the current device or network.

```json theme={null}
{
  "transactionId": "TR-…",
  "trustScore": 85,
  "confidence": "HIGH",
  "recommendation": "ALLOW",
  "positiveFactors": ["RECENTLY_VERIFIED", "STABLE_DEVICE", "ESTABLISHED_IDENTITY"],
  "riskFactors": ["MULTI_COUNTRY_HISTORY"],
  "breakdown": { "...": "high-level factor contributions" },
  "metadataId": "order-9921"
}
```

* **`trustScore`** — 0–100; higher means more trustworthy.
* **`confidence`** — `HIGH`, `MEDIUM`, or `LOW`, based on how much history the score draws on.
* **`recommendation`** — a suggested action: `ALLOW`, `REVIEW`, or `BLOCK`.
* **`positiveFactors` / `riskFactors`** — human-readable labels for what helped or hurt; the exact set is illustrative and may change.
* **`breakdown`** — a high-level view of the factors behind the number.

Use Trust when you want one portable number to feed into rules you already run. It's strongest on **returning** identities, where there's history to draw on; a never-seen number returns `LOW` confidence. See [`POST /v1/api/trust/score`](/guides/trust-shield-detect).

## Authmatech Shield

Shield is decision-first. It evaluates the session and returns the action to take, with reason codes you can log and act on.

```json theme={null}
{
  "transactionId": "SH-…",
  "riskScore": 42,
  "riskLevel": "MEDIUM",
  "decision": "CHALLENGE",
  "reasonCodes": ["OPERATOR_CHANGE", "RECENT_FAILURE_BURST"],
  "sdkVerified": true,
  "deviceConsistencyLevel": "INCONSISTENT",
  "operatorConsistencyLevel": "CHANGED"
}
```

* **`decision`** — `ALLOW`, `CHALLENGE`, `REVIEW`, or `BLOCK`.
* **`riskScore` / `riskLevel`** — 0–100 and `LOW`/`MEDIUM`/`HIGH`/`CRITICAL` (higher is riskier — the inverse of Trust).
* **`sdkVerified`** — whether the referenced `sdkSessionId` was found and validated.
* **`deviceConsistencyLevel` / `operatorConsistencyLevel`** — how the live session compares to the verified session.

Use Shield at the moment of a sensitive action — login, payout, password reset. See [`POST /v1/api/shield/assess`](/guides/trust-shield-detect).

## Authmatech Detect

Detect looks across time and across your base. It builds a behavior timeline and surfaces anomalies rather than scoring a single action.

```json theme={null}
{
  "transactionId": "DE-…",
  "riskLevel": "HIGH",
  "anomalies": [
    { "code": "DEVICE_MULTI_MOBILE", "severity": "HIGH", "description": "One device linked to several numbers", "affectedCount": 4 },
    { "code": "MOBILE_RETRY_BURST", "severity": "HIGH", "description": "A number retried at an unusual rate", "affectedCount": 6 }
  ],
  "recommendedAction": "REVIEW",
  "anomalyScore": 50,
  "affectedCount": 10,
  "windowStats": { "...": "rolling-window counts behind the findings" }
}
```

* **`anomalies`** — typed findings, each with a `code`, `severity` (`MEDIUM`/`HIGH`), description, and affected count. Categories include retry bursts, multi-account-per-device or per-installation usage, IP concentration, and operator/country failure spikes.
* **`recommendedAction`** — `ALLOW`, `CHALLENGE`, `REVIEW`, or `BLOCK`.
* **`anomalyScore`** — scales with the number of anomalies detected (capped at 100).

Use Detect to feed fraud-ops dashboards and batch reviews. See [`POST /v1/api/detect/analyze`](/guides/trust-shield-detect).

## Choosing between them

* Want **one number** to plug into existing rules? Use **Trust**.
* Want a **ready-made decision** at the point of action? Use **Shield**.
* Want to **find patterns of abuse** over time? Use **Detect**.

They compose well: many teams call Shield inline for the decision and run Detect continuously to catch slow-building abuse.

<Note>
  Each intelligence product must be enabled for your account. If a product isn't on your plan, the API responds with `400 Bad Request` and a message explaining it. Contact [connect@authmatech.com](mailto:connect@authmatech.com) to enable a product.
</Note>