Backends

Specter Connect Backends are a Specter Connect capability. On Specter Core, the engine runs local rules and the blacklist only. A backend is an external risk engine that scores transaction data as input to a decision. Specter does not integrate any backend directly — it connects through a Link instance, which hosts the backends and exposes them to Specter. Specter discovers them and makes them available to your backend rules.

​

How it works

1. Your instance is on the Specter Connect edition — backends are unavailable on Specter Core.
2. You need a Link instance in your Hellgate Cloud Platform tenant to use backends.
3. The Specter protocol is enabled on that instance and your chosen backends are configured.
4. Specter registers the Link instance as an integration and discovers the backends it exposes.
5. The discovered backends become available to your rulesets automatically.

​

Available backends

The catalogue of backends grows continuously — for example VISA Decision Manager, Ravelin, Worldpay FraudSight, and Featurespace. Contact your account representative for the current list and help choosing the right backend for your requirements.

​

Context validation and fail-open

Before calling a backend, Specter validates that the decision context contains the fields the backend requires. If a required field is missing, no call is made: the backend_results entry records an insufficient_context error so you know exactly what to add. Backend rules also carry an on_error setting (allow, block, or review) that governs what happens when a backend errors or times out — allow skips the backend so an infrastructure failure never blocks a customer.

​

Composing backends

A single backend rule calls one backend. A backend group rule orchestrates several — the foundation for migrating from one backend to another, A/B testing, and high-availability setups. A group runs its members with one of three strategies: For a parallel group, the merge strategy decides the combined outcome:

​

Shadow members

A group member can run in shadow mode (live: false): it executes and its result is recorded in backend_results, but it does not contribute to the decision. Shadow members let you trial a new backend against live traffic before trusting it. (In a split, the selected member always runs live.)

​

Asynchronous groups

A backend group can run asynchronously (async: true). Specter returns a PROVISIONAL decision from the local rules immediately and evaluates the group in the background, delivering the final outcome by webhook — see Asynchronous decision with delayed capture.

​

Configuration

Backends are reached through integrations — connections to your Link instance, managed through the Admin API (scopes admin:integrations:read / admin:integrations:write). A single integration can expose several backends, and each backend rule selects one to invoke.