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

# Onboarding Fraud Checks

Learn how to implement Onboarding Fraud Checks to assess risk using device, IP, email, and phone signals.

## Introduction

FrankieOne's Onboarding Fraud solution enables you to build a risk-based onboarding workflow by incorporating powerful fraud signals. By analyzing signals from an applicant's device, IP address, phone number, and email address, you can optimize your onboarding process—introducing more robust checks for high-risk applicants while ensuring a smooth journey for legitimate users.

This allows you to effectively reject bad actors showing strong fraudulent indicators while safely onboarding genuine customers.

## Key Capabilities

<CardGroup>
  <Card title="Device Risk" icon="mobile">
    Analyze device characteristics to identify suspicious setups like emulators or jailbroken devices.
  </Card>

  <Card title="IP Risk" icon="globe">
    Assess the risk associated with an IP address, detecting usage of VPNs or proxies.
  </Card>

  <Card title="Email Address Risk" icon="desktop">
    Verify email addresses to uncover potential fraud indicators.
  </Card>

  <Card title="Phone Number Risk" icon="phone">
    Validate phone numbers and identify associated risk signals.
  </Card>
</CardGroup>

## The End-to-End Fraud Check Flow

The fraud verification process involves a sequence of API calls to create an entity, register a device session (if applicable), and execute a workflow to get a result.

<Steps>
  <Step title="Create an Individual Entity">
    Before you can perform a fraud check, you need an `entityId` for the user. If you don't already have one, create an individual entity by making a server-side call to the API. Ensure you provide email and phone details if you intend to check those signals.

    ```bash theme={null}
    POST /v2/individuals
    ```

    This request creates the user's profile in the FrankieOne system and returns the essential `entityId` that will be used in all subsequent steps.
  </Step>

  <Step title="Register a Session (For Device & IP Checks)">
    To obtain device and IP signals, your application must integrate our oneSDK (either hosted or embedded). The oneSDK captures device data and establishes a session. This session must be registered with FrankieOne.

    Make a server-side call to register the session against the entity. This step is only necessary if you require device and IP checks.

    ```bash theme={null}
    POST /v2/individuals/{entityId}/sessions
    ```

    This ensures that when the fraud check workflow is executed, FrankieOne can retrieve and analyze the data captured during that specific user session.
  </Step>

  <Step title="Execute Workflow">
    Once the entity is created (and a session is registered, if needed), you can execute the onboarding workflow. The workflow must be configured to include the `FRAUD` step to perform the checks.

    ```bash theme={null}
    POST /v2/individuals/{entityId}/serviceprofiles/{serviceName}/workflows/{workflowName}/execute
    ```

    This triggers the Fraud step, which analyzes the available signals (Email, Phone, Device, IP) and generates the results.
  </Step>

  <Step title="Get and Resolve Results">
    The workflow execution response will contain the results of the fraud checks. The overall step result will indicate a `HIT` or `CLEAR` based on the process results for each signal. You can then investigate any hits and resolve them.

    To learn how to analyze the detailed outcomes, please see our dedicated guide:\
    <a href="/docs/fraud-checks-guide-results"><strong>Understanding Fraud Check Results</strong></a>
  </Step>
</Steps>

## Limitations

Please be aware of the following limitations:

* **oneSDK Requirement:** To get device and IP signals, you must implement oneSDK. Without it, only email and phone signals can be used.
* **Single Provider per Step:** The fraud step is designed to support only one provider at a time. If you need to use different providers for different signals, you must configure separate fraud steps.
* **Supported Connectors:** To find out which connectors are available for the v2 fraud step, please consult your implementation support manager.