## Before you start

Make sure you have the following:

Access to the RiskOS™ Dashboard with the **Sigma Identity Fraud** enrichment enabled.

- Your account owner or administrator can enable this for you. If you're unsure who to contact,
  [reach out to support](mailto:support@socure.com) for assistance.

A basic understanding of RiskOS™ workflows and components.

- If this is your first time working with workflows, review the
  [Workflow overview](https://help.socure.com/riskos/docs/workflow-overview)
  to understand inputs, enrichments, routing logic, and decisions.

## How it works

Sigma Identity Fraud is a fraud detection enrichment available in RiskOS™. It evaluates identity attributes against consortium data to identify signals associated with identity-based fraud.

Sigma Identity Fraud returns:

- **Model scores**: Normalized fraud risk scores generated by one or more models.
- **Reason codes**: Indicators that explain the contributing risk factors behind fraud signals.

These outputs can be used to inform routing, review, or escalation decisions in your workflows.

### How Sigma Identity Fraud fits into a workflow

In RiskOS™, workflows are built by connecting reusable components. Sigma Identity Fraud is added as an **Enrichment** step.

Once the enrichment runs, its outputs are available to downstream workflow components, including:

- Conditions
- Decision rules
- Rule score cards
- Manual review steps
- Final decisions

For more detail on these components, see [Workflow Steps](https://help.socure.com/riskos/docs/workflow-steps).

### Execution flow in RiskOS™

Sigma Identity Fraud runs synchronously as part of a RiskOS™ workflow. There is no user handoff or pause in execution.

```
Input

Sigma Identity Fraud

Routing logic

Decision
```

At a high level, the execution flow looks like this:

1. **Input**

You call the Evaluation API with identity attributes.

2. **Sigma Identity Fraud enrichment**

RiskOS™ evaluates the provided attributes and returns model scores and reason codes.

3. **Routing logic**

The workflow evaluates fraud scores and reason codes.

4. **Decision**

The workflow returns a final outcome (for example, **Accept**, **Review**, or **Reject**).

### Workflow components used by Sigma Identity Fraud

Sigma Identity Fraud uses a subset of standard RiskOS™ workflow components.

| Component | Purpose | Typical input | Output / What to use next |
| --- | --- | --- | --- |
| **Input** | Start an evaluation | Identity attributes | Workflow execution begins |
| **Enrichment** | Detect identity fraud | — | Model scores, reason codes |
| **Condition** | Branch based on risk signals | Fraud risk outputs | Route to appropriate path |
| **Decision Rule / Score Card** | Apply policy or scoring logic | Fraud risk outputs | Pass/fail or cumulative risk classification |
| **Decision** | Emit final outcome | Routed value | Accept / Review / Reject |

## Configure Sigma Identity Fraud

### Add Sigma Identity Fraud to a workflow

1. In the RiskOS™ Dashboard, go to **Workflows** and create a new workflow or open an existing one.
2. On the workflow canvas, select the **plus (+)** icon.
3. Add an **Enrichment** step and select **Sigma Identity Fraud**.

After the enrichment is added, its outputs can be referenced by downstream workflow logic.

### Configure routing using model scores

Sigma Identity Fraud returns one or more model scores under:

```undefined
socure_sigmaidentityfraud_response.fraud.scores
```

This field contains an array of objects representing the models enabled for your integration. Each object includes:

- `score` (float): The output score of the model, ranging from 0.001 to 0.999.
- `name` (string): The name of the model, commonly `"sigma"`
- `version` (string): The version of the model, e.g. `"4.0"`

#### Using a single model score

If your integration is configured to return a single model score, you can reference it directly when defining Conditions in your workflow, for example:

```undefined
socure_sigmaidentityfraud_response.fraud.scores.0.score
```

Customers typically define thresholds based on their own risk tolerance and business policies.

#### Using multiple scores

If multiple model scores are returned, do not rely on the position of a score within the array. Instead, Conditions should be written to evaluate both the score value and the associated model version.

For example, to evaluate whether a specific model version meets a given threshold, you can construct Conditions that:

- Check the score value, and
- Confirm the corresponding `version` field matches the intended model

This may require evaluating more than one element in the `scores` array, depending on how many scores are returned for your configuration.

### Configure routing using reason codes

Reason codes are returned under:

```undefined
socure_sigmaidentityfraud_response.fraud.reasonCodes
```

This field contains an array of strings (for example, `"R610"`) that explain contributing risk signals.

You can route based on reason codes by:

1. Adding a **Condition** step
2. Selecting the variable `socure_sigmaidentityfraud_response.fraud.reasonCodes`
3. Choosing **array contains** or **array does not contain**
4. Providing the reason code value in quotes

See the RiskOS™ Dashboard for a list of reason codes available for Sigma Identity Fraud.

### Save and publish

Once your workflow is configured, publish it to go live.

## Workflow testing checklist

Use this checklist to confirm accuracy, resilience, and completeness before going live.

**Input validation**:

Email inputs are collected and passed consistently

Supporting identity attributes are provided where available

**Routing and decisioning**:

Workflow routing reflects your intended risk strategy

Review or fallback paths are clearly defined

**Operational readiness**:

Email Risk scores and reason codes are accessible to relevant teams

Updated 3 months ago