Risk signal sources

A risk signal source is an instance-level, reusable definition of something that produces risk data: a built-in Strivacity capability or a third party integration. You configure a source once (credentials, inputs, outputs, and level mapping), then reference it from any number of risk policies.

Configuring sources at the instance level means decisions like credentials and level mappings are made once, and the same signal means the same thing in every policy that uses it.

To manage sources, select Instance configuration from the left-hand menu, and then Risk signal sources. The catalog lists every source with its type, the state of its level mapping, and the policies that use it.

Source types

• Built-in: Strivacity's own risk detection capabilities, preloaded in the catalog. They can't be deleted or renamed.
• Prebuilt: Ready-made integrations for popular third party risk services. You supply credentials and adjust the level mapping.
• Custom: Code-defined integrations your team builds for any REST-based risk service. Custom integrations appear in the same catalog and behave like prebuilt ones.

The level: normalized risk

Every source, built-in or third party, produces one mandatory normalized output: the level, with the values none, low, medium, or high. The level is what makes risk scoring source-independent: scoring consumes levels, so any source can participate in any policy's scoring without policy-side translation.

Each source carries a Level mapping that defines how its data translates to the level:

• Enumerated values: maps specific vendor or built-in values to levels (for example, Tor detected maps to high).
• Score thresholds: when a vendor returns a numeric score, maps score ranges to levels. The integration defines the valid score range (0-1 vs 0-100) and directionality (whether high numbers are good or bad); the ranges presented in level mapping match the vendor documentation and will differ from source to source.

Every source ships with a default mapping that you can edit per instance. The mapping applies everywhere the source is used. All other vendor data flows through the source's raw outputs, which risk rules can evaluate after you map them to local variables in a policy.

Built-in sources

Built-in sources expose the platform's own risk detection the same way as third party integrations: same catalog, same input and output model, same level semantics. Built-in sources include:

• Bot detection
• Anonymous proxy / Tor detection
• Geolocation
• Improbable travel
• Behavior analytics
• Known device detection
• Breached password detection (requires a password credential in the current flow, so it's only available where a password is present)
• Phone risk evaluation, with an identity verification subscription: phone line type (mobile, landline, fixed VoIP, non-fixed VoIP, or other) and recent SIM and subscriber pairing changes

To edit a built-in source, select it in the catalog. Its outputs are listed for reference, and you can edit its level mapping. For example, the Geolocation source lets you assign locations to each level; unlisted locations report a level of none.

Add a third party source

Third party risk services (fraud and digital identity intelligence, bot and automated attack detection, threat intelligence, IP reputation) expose authenticated REST APIs, and each integration wraps one of them.

1. From the left-hand menu, select Instance configuration, and then Risk signal sources.
2. Select Add source.
3. Choose an integration from the catalog. Prebuilt integrations are grouped by category: bot detection, fraud detection and response, digital identity and device intelligence, IP reputation and proxy detection, and threat intelligence. Your custom integrations appear under Custom.
4. Name the source instance. Names like reCAPTCHA Enterprise - Production keep multiple instances of the same integration distinguishable.
5. Configure the sections described below, and select Save.

Credentials

Each integration authenticates to the vendor API with the mechanism the vendor requires, such as an API key and secret or OAuth. Credentials are stored in the source instance's configuration, along with any vendor-specific settings the integration declares (for example, a cloud project identifier or endpoint).

Inputs

The integration declares the data it needs, with each input marked required or optional. You don't supply input values here: you choose where each value comes from (native claims, context variables, or local variables) when you add the source to a risk policy. Values are validated before the query is sent.

Each input also declares what it needs from the point in the journey where the policy runs, such as Session data, Identified customer, or Web/mobile SDK. These requirements roll up to any policy that uses the source and decide where in the customer journey that policy can be selected.

Some vendors also want to know what kind of action is being evaluated: login, registration, account update, or password reset. The type of flow under evaluation is available as a context input that can be mapped.

Outputs

The integration exposes the vendor's raw return values as mappable outputs, plus the normalized level. Raw outputs are typed (string, number, boolean, list) and described in the source's configuration screen. Map the outputs you need to local variables where the source is added to a risk policy.

Front-end data collection

Most fraud and behavior vendors require client-side collection through a web or mobile SDK. Integrations that use one carry an explicit SDK activation switch, off by default.

The source instance also holds the SDK's instance-level configuration values, such as the identifier for your account with the vendor. Integrations may additionally declare per-policy SDK values, supplied as static values where the source is added to a risk policy.

If you build your own UI instead of using Strivacity-hosted pages, an API path lets you pass SDK-collected identifiers into the session.

Error handling

Retry / fallback logic and rate limits appropriate to the vendor's API is defined in the integration. A signal query only counts as failed after the integration's own retry logic is exhausted; what happens then depends on whether the signal is marked required in the policy that queried it.

Delete a source

Deletion is blocked while any risk policy references the source. Remove the source from those policies first. Built-in sources can't be deleted.

Troubleshooting

Every signal query records metrics: the integration, latency, cache hit or miss, retry count, and outcome (success, failure, or timeout). When an evaluation is slow or failing, these metrics attribute the problem to a specific integration. Signal query failures are also logged.