Digital signals (v2)

Preview / Alpha

This version of this step type is in preview / alpha. The functionality and subsequently the documentation can still change. Digital signals (v1) (DIGITAL_SIGNALS:v1) remains the stable version.

Assesses trust signals from a user’s contact details and device context

Helps businesses identify suspicious or trustworthy behaviour based on email, phone, name, and IP data before the user continues with e.g. identity verification or electronic signature processes. This version reads the IP address from a DeviceContext data block instead of the legacy DeviceSignals data block.

Key features

Computes a trust score from email, phone, IP and name signals.
Routes flow using configurable thresholds: suspiciousUserThreshold and trustedUserThreshold.
Required inputSources to specify step IDs (basicIdentity, extendedIdentity, deviceContext). Must cover at least 2 potential claims.
IP from DeviceContext: the IPv4 entry is preferred; when only an IPv6 address is available, the first entry is used.
Produces DigitalSignals for trusted, suspicious, and not_trusted; inconclusive when no definitive assessment.

Configuration

Option	Type	Required	Description
`provider`	string	No	The trust signals provider to use. Currently only `TRUSTFULL` is supported. Accepted values: `TRUSTFULL`.
`suspiciousUserThreshold`	integer	Yes	The score threshold (in percent) below which a user is considered "suspicious". Must be strictly less than `trustedUserThreshold`.
`trustedUserThreshold`	integer	Yes	The score threshold (in percent) above which a user is considered "trusted". Must be strictly greater than `suspiciousUserThreshold`.
`inputSources`	object	Yes	Specifies the flow step IDs to use for sourcing data. The configuration must cover at least 2 potential claims: `basicIdentity` contributes 1 claim, `extendedIdentity` contributes 2 claims (phone + email), and `deviceContext` contributes 1 claim. See `Input mapping`.
`inputSources.basicIdentity`	string	No	The step ID providing basic identity data (e.g., first name, last name).
`inputSources.extendedIdentity`	string	No	The step ID providing extended identity data (e.g., phone, email).
`inputSources.deviceContext`	string	No	The step ID providing device context data (e.g., IP address).

Example configuration

{
  "suspiciousUserThreshold": 25,
  "trustedUserThreshold": 70,
  "inputSources": {
    "basicIdentity": "collect-identity",
    "extendedIdentity": "collect-contact",
    "deviceContext": "collect-device-signals"
  }
}

Input data blocks

Data block	Required	Description
`BasicIdentity`	Conditional	Provides name signal (1 claim). Present only when `inputSources.basicIdentity` is set.
`ExtendedIdentity`	Conditional	Provides phone and email signals (2 claims). Present only when `inputSources.extendedIdentity` is set.
`DeviceContext`	Conditional	Provides IP signal (1 claim). Present only when `inputSources.deviceContext` is set.

The inputSources configuration must cover at least 2 potential claims in total. extendedIdentity alone satisfies this requirement. The referenced steps must have already produced the corresponding data blocks before this step executes — this step never falls back to a legacy DeviceSignals data block.

A DeviceContext data block is produced by Device signals (v2) (DEVICE_SIGNALS:v2), and is also collected at session acquisition for every web session.

Routes

Route	Description
`trusted`	The score computed is greater than or equal to trustedUserThreshold.
`suspicious`	The score computed is strictly between suspiciousUserThreshold and trustedUserThreshold.
`not_trusted`	The score computed is less than or equal to suspiciousUserThreshold.
`inconclusive`	The actual data resolved at runtime amounts to fewer than 2 claims (e.g. `basicIdentity` is configured but the last name is missing, or `extendedIdentity` is configured but both phone and email are absent). Provider errors are not routed here — they cause step failure.

Output data blocks

Route	Data blocks produced
`trusted`	`DigitalSignals`
`suspicious`	`DigitalSignals`
`not_trusted`	`DigitalSignals`
`inconclusive`	`DigitalSignals`

Example payloads

DigitalSignals — trusted

{
  "provider": "TRUSTFULL",
  "timestamp": "2026-02-10T14:00:01.000Z",
  "services": [
    "emails",
    "phone",
    "name",
    "ip"
  ],
  "inputSources": {
    "basicIdentity": "collect-identity",
    "extendedIdentity": "collect-contact",
    "deviceSignals": null,
    "deviceContext": "collect-device-signals"
  },
  "result": "trusted",
  "score": 87,
  "reasons": [
    {
      "code": "RE001",
      "details": "Email Low Velocity:Absence or very low number of connected accounts to this email address"
    }
  ],
  "signals": {
    "email": {
      "score": 90,
      "valid": true,
      "domain_age_days": 4380
    },
    "phone": {
      "score": 84,
      "valid": true,
      "line_type": "mobile"
    },
    "name": {
      "score": 88,
      "match": true
    },
    "ip": {
      "score": 82,
      "valid": true
    }
  }
}

info

The signals field contains the raw, unaltered response from the provider. Its internal structure is not guaranteed and may vary between providers or over time. Do not rely on specific field names or nesting within signals.

Assesses trust signals from a user’s contact details and device context​

Key features​

Configuration​

Example configuration​

Input data blocks​

Routes​

Output data blocks​

Example payloads​