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

# Backends

> How Specter connects to external risk backends through Link integrations.

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](/products/link/overview) instance, which hosts the
backends and exposes them to Specter. Specter discovers them and makes them available to your
[backend rules](/products/specter/concepts/rule-engine).

## How it works

1. Every Specter instance comes with a **bundled** [Link](/products/link/plans-and-access#editions) instance that
   serves its backends and scales with it — there is no separate Link contract to arrange.
2. The Specter protocol is enabled on that instance and your chosen backends are configured.
3. Specter registers the Link instance as an integration and discovers the backends it exposes.
4. The discovered backends become available to your rulesets automatically.

<Note>
  The bundled Link instance is locked to serving your Specter backends. To run other protocols or send other load
  through it, unlock it into a [Standalone](/products/link/plans-and-access#editions) instance — see
  [Link Plans & Access](/products/link/plans-and-access).
</Note>

## 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](/products/specter/concepts/rule-engine) 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:

| Strategy   | Behavior                                                                                                             |
| ---------- | -------------------------------------------------------------------------------------------------------------------- |
| `fallback` | Try members in order; use the first live member that returns a result. If one errors or lacks context, try the next. |
| `parallel` | Call all members at once and combine their outcomes with a `merge` strategy.                                         |
| `split`    | Route each request to exactly one member, chosen by weighted random distribution.                                    |

For a `parallel` group, the `merge` strategy decides the combined outcome:

| Merge          | Outcome                                                      |
| -------------- | ------------------------------------------------------------ |
| `strictest`    | The most severe outcome wins (`BLOCK` > `REVIEW` > `ALLOW`). |
| `most_lenient` | The least severe outcome wins.                               |
| `consensus`    | The shared outcome if all members agree, otherwise `REVIEW`. |

### 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](/products/specter/integration/via-api#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.

<Card title="Configure a backend integration" icon="link" href="/products/specter/api-reference/integrations/create-integration">
  Register a Link instance and discover its backends in the API reference.
</Card>