Manage external risk engines
An external risk engine evaluates user or transaction activity and returns risk data to IDaaS.
In a resource rule, external risk is one of the risk signals evaluated during authentication. Based on the risk outcome, IDaaS can require stronger authentication (for example, step-up authentication) or deny access.
When you need to pass client-provided runtime values as risk input, send those values in transaction details.
A common external risk flow works as follows:
- Your application sends an authentication request to IDaaS.
- If needed, the request includes transaction details with runtime risk context.
- IDaaS evaluates internal risk signals and external risk engine rules.
- The resource rule applies the configured outcome for the risk level, such as allow, step-up authentication, or deny access.
To implement this flow, complete the following:
- Configure your external risk engine provider integration in IDaaS.
- Map provider response values to external risk engine rules.
- Add the External risk factor to a resource rule and configure low-, medium-, and high-risk outcomes.
- If your use case requires runtime client signals, use an Authentication API application to configure the application, then use the Entrust Identity as a Service Authentication API guide to implement API calls in your application and pass those values in transaction details.
Common risk engine categories and input requirements
External risk engines can evaluate network, device, behavior, transaction, identity, and telecom signals. The categories below reflect common risk signal types supported by external providers and can help you decide what data your application must provide.
These categories are examples of risk signal types supported by external providers, not built-in IDaaS risk engine types.
For connector-based integrations, required inputs are typically provided from transaction details in the request, user attributes, and environment values such as client IP.
For external risk engine integrations in general, runtime risk signals are commonly passed through Authentication API transaction details.
Some risk engines require client or session telemetry that IDaaS does not collect by default. In these cases, you must update your client application or telemetry pipeline and pass the required values in transaction details. Some providers also require direct communication between the client and the risk engine (for example, through a client SDK or script) to collect and send behavioral or device signals.
| Category | Typical provider inputs | Typical outputs for rules | Implementation notes |
|---|---|---|---|
| IP reputation and network risk | Client IP, optional session ID and user ID | Risk score, proxy or VPN flag, TOR flag | Strong fit for connector-based integrations because client IP can be passed directly. |
| Geolocation and travel velocity | Current IP plus prior location and prior timestamp | Impossible travel flag, distance, speed | Needs historical context from your application or upstream system to be reliable. |
| Device intelligence and fingerprinting | Device fingerprint, device ID, user agent, optional account and session context | Device risk score, known device flag | Requires device telemetry collection in client or backend and passing it in transaction details. |
| Behavioral biometrics | Keystroke, touch, mouse, navigation behavior features | Behavior anomaly score, confidence score | Usually needs continuous telemetry from an SDK or telemetry pipeline. |
| Transaction fraud scoring | Transaction amount, currency, action, payee, channel, account and session context | Transaction risk score, allow or challenge | Common for payment and high-value action protection; often a strong match for Authentication API use cases. |
| Account takeover detection | Account ID, session ID, IP, device signals, sign-in and reset event context | ATO risk score, compromise probability | Quality improves significantly when rich event context is provided. |
| Bot and automation detection | Client integrity signals, challenge outcomes, interaction metrics | Bot score, automation flag | Requires bot telemetry from client, gateway, or dedicated anti-bot tooling. |
| Identity reputation and consortium risk | Email, phone, account identifier, optional IP and device context | Identity trust score, synthetic identity signals | Depends on data quality and normalization for identity fields. |
| Session anomaly and malware-in-session | Session telemetry, anomaly indicators, malware indicators | Session risk score, malware risk flag | Requires session-level telemetry beyond a single static request. |
| Telecom risk (including SIM swap) | Phone number, country, optional carrier context | SIM swap recent flag, telecom risk score | Requires a telecom data provider and phone input. IP-only input is not sufficient for SIM swap checks. |
Feedzai Digital Trust is commonly used for transaction fraud scoring and account takeover detection, depending on how your organization maps provider outputs to resource rule decisions.
Types of risk engines
You can configure IDaaS to use the following types of external risk engines:
Generic API engine
Configure a Generic API external risk engine when your provider supports the IDaaS API. If it does not, use an intermediate proxy server to translate requests between IDaaS and the external risk engine API.
Feedzai Digital Trust
Use this procedure to configure a Feedzai Digital Trust external risk engine in IDaaS.
Connector-based engines
Use this page to configure a connector-based external risk engine integration in IDaaS.