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

# Risk scoring

> How Frayme collapses heterogeneous vendor signals and rule outputs into a single 0–100 risk score and four bands.

A **risk score** is the numeric distillation of everything a workflow has learned about a case. Two patterns produce one — and most production workflows use them together.

## Deterministic scorecard

The auditable baseline. Each factor has a weight; each factor has cases that map an observed value to a sub-score; the final score is the weighted sum.

**Example.** A simple onboarding scorecard with three factors:

| Factor                | Weight | Cases (operator, value → score)                         |
| --------------------- | ------ | ------------------------------------------------------- |
| `device.risk_score`   | 35     | `≤ 20 → 0`, `≤ 50 → 40`, `≤ 80 → 70`, `> 80 → 100`      |
| `identity.confidence` | 40     | `≥ 0.9 → 0`, `≥ 0.7 → 30`, `≥ 0.5 → 60`, `< 0.5 → 100`  |
| `case.amount`         | 25     | `≤ 100 → 0`, `≤ 500 → 20`, `≤ 2000 → 50`, `> 2000 → 90` |

Observed values `{ device: 18, identity: 0.92, amount: 350 }` produce sub-scores `{ 0, 0, 20 }` → weighted score `5`. Low band, auto-approve.

Deterministic, auditable, easy to explain in regulator interviews.

## AI synthesis

Frayme is **pro AI synthesis** for the cases the scorecard can't model cleanly — adverse-media free text, document-narrative reasoning, multi-vendor disagreement signals, cross-document corroboration.

When it fits:

* The synthesiser receives the upstream structured signals (identity outcome, AML hits, region check, on-chain exposure) and any free-text artefacts.
* It returns a strict JSON schema: `{ risk_score, risk_band, recommendation, reasoning }`.
* The score and band are written back to the run context; downstream decision tables route on them just like with a scorecard.

The mature pattern combines both: deterministic gates handle the obvious hard fails (sanctions, hard reject labels) so the AI never gets the chance to relax them, and the AI synthesises the borderline cases. See the [`ai` node](/workflows/nodes/ai) for the production reference.

## The four bands

| Band         | Default range | Default routing        |
| ------------ | ------------- | ---------------------- |
| **Low**      | 0–30          | Auto-approve           |
| **Medium**   | 31–60         | Issuer / client policy |
| **High**     | 61–80         | Manual review          |
| **Critical** | 81–100        | Reject or report       |

* **Band** is fixed — every Frayme workflow uses the same four names.
* **Range** is personalizable per client. A more conservative client can shrink Low to 0–20.
* **Routing** is personalizable per client. The same Medium-band score can auto-approve for one client and route to review for another.

## Originator risk level

When the identity suite returns a `risk_level` on the originator (low / medium / high), Frayme surfaces it on the manual review screen as a first-class field — and downstream rules can read it directly. A high originator risk level typically:

* Tightens velocity rules for that originator's subaccounts.
* Triggers paid-per-query counterpart enrichment that wouldn't fire for a low-risk originator.
* Shows up at the top of the Decision Console so the analyst sees it before the per-case detail.