Specter is Hellgate's real-time fraud intelligence layer – a low-latency, high-throughput decision engine that analyses every transaction as it moves through your payment flow, assigns a risk score, and blocks bad actors before checkout. It combines fast in-process rules with integrations to external risk services, and improves detection over time by ingesting transaction data.

Like every CPA component, Specter runs standalone or composed with other services.

→ Explore Specter

Specter evaluates signals such as device fingerprinting, geolocation, behavioural velocity (rolling-window counts per card, customer, device, or IP), and token-level data – without ever exposing sensitive card details. These feed both in-process rules and external risk backends.

The combination lets Specter catch patterns typical of fraud – unusual velocity, mismatched geographies, high-risk device signals – while keeping sensitive data protected.

→ See how Specter evaluates transactions

Specter assigns a real-time risk score (0–100) to every transaction as it moves through Hub. For chargeback-prone patterns – first-time customers, high-value orders from high-risk geographies, unusual velocity – it triggers configurable policies: stepped-up verification, 3-D Secure enforcement, or outright blocking. The score draws on device fingerprinting, geolocation, behavioural velocity, and token-level signals.

Because Specter integrates natively as a CPA component rather than a bolted-on API, its scoring feeds directly into routing and decisioning with zero added latency.

→ Learn more about Specter

Specter is backend-agnostic. It integrates with external risk engines – such as Visa Decision Manager, Worldpay FraudSight, Ravelin, and Featurespace ARIC Risk Hub – reached through a Link integration. You select the backend, or combination of backends, that fits your transaction profile, geography, and risk appetite.

Specter normalises each backend's output into a single Specter Score, and adding a new backend is configured at the platform level without changing your integration.

→ See all Specter backends

Yes. Specter and Guardian are independent CPA components. Specter provides real-time fraud intelligence and risk scoring; Guardian provides PCI-compliant vaulting and tokenization. They integrate naturally when both are in use – Specter can read token-level signals from Guardian to improve scoring accuracy – but each can be deployed standalone or alongside your existing infrastructure.

So you can add Specter for fraud without adopting Guardian, and vice versa.

→ Guardian overview

Specter can run standalone with basic orchestration, providing rule-based scoring and blocking on its own. Full rule appliance and advanced decisioning – where scores drive routing, retries, and step-up in real time – come together with the CPA Hub.

This means you can start with Specter for fraud scoring and unlock deeper decisioning as you compose it with Hub, without re-integrating.

→ See Specter integration options

Hub consumes the Specter Score and executes real-time policies against it – allow, block, step up to 3-D Secure, or route differently. Because Specter is a native CPA component rather than a third-party API, the score flows straight into Hub's routing and decisioning without added latency.

You define the thresholds and rules once; Hub enforces them consistently across every transaction and every provider.

→ See Specter + Hub decisioning

Yes. Specter is a decision engine built to encode complex fraud and business rules. You define local rules (boolean conditions and velocity counters over the decision context), maintain blacklists with optional TTLs, and set the score thresholds at which policies act. Rules and thresholds are yours to configure and tune.

Because everything is expressed as configurable rules, risk teams can adapt to new fraud patterns quickly, without a code release.

→ See the Specter rule engine

The Specter Score is a single, real-time risk score (0–100) assigned to every transaction. It combines Specter's in-process rules and velocity signals with the normalised output of any external risk backends you've connected, so multiple fraud sources resolve into one consistent number.

Downstream, Hub uses the score to make decisions – approve, block, or step up – giving you a single, tunable control point for fraud across all providers.

→ Learn about the Specter Score

Specter offers two integration patterns. The Decision API has your system call POST /api/decisions before authorizing and branch on the result – maximum control and the richest context. The Interceptor sits inline as a transparent proxy in front of your acquirer, forwarding approved transactions and returning a configured response for those it flags – adding fraud checks with no backend changes.

Both evaluate the same rulesets and return the same outcomes; they differ only in where the integration lives.

→ Compare Specter integration patterns

Specter is engineered as a low-latency, high-throughput engine. Local rules and velocity counters are evaluated in-process, with no external calls, so they add minimal latency. Because Specter integrates natively into the CPA rather than as a bolted-on third-party API, its scoring feeds directly into routing and decisioning with effectively zero added latency.

External risk backends, when used, are invoked only where your rules call for them – you control the trade-off between depth and speed.

→ See Specter's architecture

Specter continuously ingests transaction data, so detection sharpens as it observes more of your traffic. Lifecycle events – such as chargebacks and fraud reports – can auto-populate blacklists, closing the loop between confirmed fraud and future blocking. Combined with tunable rules and multiple risk backends, this lets your defences adapt to emerging patterns.

You keep control: the engine learns from your data while you decide the rules and thresholds it enforces.

→ See lifecycle events and learning

Yes. Specter is a decision engine built to encode complex fraud and business rules. You define local rules (boolean conditions and velocity counters over the decision context), maintain blacklists with optional TTLs, and set the score thresholds at which policies act – then Hub enforces them.

Because everything is expressed as configurable rules, risk teams can adapt to new fraud patterns quickly, without a code release.

→ See the Specter rule engine

A local rule runs in-process inside Specter – boolean conditions, velocity counters, and checks over enriched metadata. It evaluates in microseconds, needs no external call, and carries no per-decision fee. A backend rule delegates scoring to an external risk engine (such as Worldpay FraudSight) reached through a Link integration, for judgements a single transaction can't make on its own.

The rule of thumb: deterministic and cheap belongs local; probabilistic or dependent on data you don't hold belongs in a backend. Most fraud is caught by the cheap local net, so the paid model call is reserved for genuinely ambiguous transactions.

→ See how Specter's rule engine works

Specter charges a fixed platform fee for the runtime rather than a fee per decision. That means predictable OPEX that consolidates fraud tooling into one line, instead of a cost that scales linearly with every transaction you screen.

Because most fraud is stopped by cheap, in-process local rules before any paid external call is made, you also avoid paying a model to score transactions a simple boolean check could resolve – lowering both cost per decision and latency.

→ Learn how Specter is priced

No. Legacy acquirer or Feedzai-style rulesets typically collapse into a handful of repeating patterns – velocity, positive and negative lists, geographic and BIN mismatch, IP and email intelligence, fraud-history linkage, and behavioural or ML scoring. Roughly the large majority map directly onto Specter local rules, and only the behavioural or ML minority needs a backend.

Rulesets are versioned and move through a DRAFT to ACTIVE lifecycle with rollback, so you review a diff and activate rather than filing a change request with your acquirer. Pruning a dead rule becomes trivial and safe.

→ See how rulesets migrate to Specter

Every backend rule in Specter has an on_error setting: allow (fail-open, the default, so an outage never blocks genuine customers), block (fail-closed), or review. Specter also checks that a transaction carries the fields a backend needs before calling it; if fields are missing, it skips the call and tells you which ones.

Velocity counters are fail-open too: if the counter store is unavailable, the check never blocks a real customer. This keeps checkout resilient even when an external dependency degrades.

→ See backend error handling

Specter backend groups let you run providers in fallback (try in order), parallel (call all and merge outcomes), or split (weighted A/B) mode. A member can also run in shadow mode, where it executes and its result is recorded but doesn't affect the live decision.

That means you can test a new provider against real traffic before trusting it, then promote or swap it by configuration – without touching your integration or exposing customers to an unproven model.

→ See backend groups and shadow mode

Yes. Specter is backend-agnostic and its catalogue includes engines such as Worldpay FraudSight, Ravelin, Visa Decision Manager, and Featurespace, each reached through a Link integration. FraudSight, for example, returns an outcome, a score, and a human-readable reason such as card unfamiliarity or an unusual transaction for the merchant.

Specter normalises each backend's output into a single Specter Score, so you keep the provider you trust while gaining one consistent decision and one control point across all of them.

→ See supported fraud backends

Because most fraud is caught by cheap, deterministic checks. Running the local net first – velocity, blocklists, amount thresholds, geography and BIN mismatches – stops the majority of fraud for free and in microseconds, and reserves the paid ML call for the genuinely ambiguous remainder.

The result is lower cost per decision, lower latency, and logic your risk team can read and change directly. You can also combine both in one decision: local rules pre-filter, a backend scores the rest, and Specter returns a single combined outcome.

→ See how Specter combines rules and models

Metadata is a flat key–value map you attach to each transaction, available to local rules but not sent to backends. Any signal your checkout or PSP already computes – IP geolocation, an anonymizer flag, BIN country, an email-risk band, a reshipper flag, MIT or CIT type – can be passed once and consumed by local rules.

This is the migration workhorse: it lets the large majority of a legacy ruleset run locally even though Specter itself does no IP, email, or BIN enrichment. You bring the enriched signal; Specter turns it into fast, free decisioning.

→ See how metadata powers local rules

A velocity rule is a rolling-window counter – for example, more than five attempts on the same card in the last hour. Specter maintains these counters per card, per device IP, per device fingerprint, and per customer, so you can catch bursts that a single transaction wouldn't reveal.

Velocity checks are evaluated in-process as local rules, so they add minimal latency and carry no per-decision fee. They are also fail-open: if the counter store is unavailable, the check never blocks a genuine customer.

→ See velocity rules in the rule engine

Each vertical has a distinct card-not-present fraud signature, and Specter pairs a fast local net with a scoped external call for each. Subscription merchants face card testing and free-trial abuse, met with burst velocity per IP and disposable-email blocks. Fashion faces reshipping of high-value goods, met with card velocity and billing-shipping country mismatch rules.

Travel platforms face high-value, non-recoverable bookings behind anonymized traffic; airlines face liquid, high-value tickets with rich booking-level tells such as passenger-not-cardholder on a one-way fare. In each case cheap local rules handle the obvious cases and a backend scores the ambiguous remainder.

→ See Specter for your industry

Specter evaluates the rules in your active ruleset in order and returns one of three outcomes: ALLOW, REVIEW, or BLOCK. A BLOCK stops evaluation immediately, REVIEW outcomes accumulate, and if nothing matches the result is ALLOW. Signals go in and a decision comes out, in real time.

Rules can be condition (boolean logic over the transaction), backend (delegate to an external engine), backend_group (several backends together), or blacklist (block when a field matches a blocked value). You decide the order and the thresholds; Specter enforces them consistently on every transaction.

→ See how the decision engine works

Rules of the form "email or card linked to fraud in the last N days" map onto Specter's blacklist, which supports a TTL and can be auto-populated from lifecycle events such as a chargeback, a fraud report, or a failed transaction. Report the fraud once and the entry lands on the blacklist with, for example, a 60-day expiry.

Future transactions then match automatically, with no manual list-keeping, and the entry ages out when the TTL lapses. This closes the loop between confirmed fraud and future blocking while keeping your lists clean.

→ See blacklists and lifecycle events