Skip to main content

​
Overview

Silent mode lets you run one or more anti-fraud services alongside your Primary service without enforcing their decisions. Whenever a Flow rule triggers an anti-fraud check, Silent services are evaluated alongside the Primary, return decisions, and write transaction history events — but those decisions never reject, step up, or otherwise affect the customer’s flow. This is the recommended way to:
  • Warm up a new service. Let it gather data and tune its models on real traffic before you switch over.
  • Validate a new service before switching over. Compare its decisions against your Primary in the dashboard.
  • Decommission an old service gradually. Keep the outgoing service in Silent mode for monitoring after switching to a new Primary.

​
Connection modes

Each configured service is in one of three modes (see Anti-fraud overview): Exactly one service can be Primary at a time. Any number of services can be Silent.

​
How it works

Anti-fraud services are only called when a Flow rule that depends on an anti-fraud score or decision triggers for a transaction (see Anti-fraud overview). When that happens:
  • The Primary service is called synchronously so its decision can be evaluated against your Flow rules.
  • Each Silent service is called asynchronously via the message queue, so it never adds latency to the transaction.
  • All checks (Primary and Silent) are stored against the transaction. The dashboard surfaces every Silent decision as a transaction history event so you can compare side-by-side without affecting the customer.
  • If a webhook arrives for a Silent service (for example, a Cybersource Decision Manager review status change), the corresponding check is updated, but no further action is taken on the transaction.

​
Fingerprinting with multiple services

No matter how many anti-fraud services you have configured (Primary + any number of Silent), your integration only ever passes one device fingerprint value per transaction. There is no per-provider fingerprint field.
A single shared fingerprint identifier per session is used to seed the fingerprinting library of every active provider — that is, the Primary and any Silent services (Inactive services receive no traffic and are skipped). Each provider registers that identifier under its own session/device key. At transaction time you submit the identifier once, on anti_fraud_fingerprint, and the platform forwards it to the Primary and each Silent service using whatever per-provider mapping that connector defines. See each connector’s documentation for the specific field it expects.

​
End-to-end flow with Embed (Primary + Silent)

When you use Embed (web or mobile), this happens automatically — adding a Silent service requires no code changes in your integration. If you don’t use Embed, see Automatic anti-fraud device fingerprinting for how to load f.js yourself or how to seed the same identifier into native mobile SDKs.

​
Migration pattern

The intended migration playbook for switching from one anti-fraud provider to another:
1

Add the new provider as Silent

Configure the new provider in the dashboard with connection mode set to Silent. Your existing Primary keeps enforcing decisions; the new provider starts collecting data and emitting decisions side-by-side.
2

Compare in the dashboard

Review the side-by-side decisions on transactions over a representative period (typically a few weeks). Tune the new provider’s rules and models as needed.
3

Promote the new provider

Flip the flags: set the new provider to Primary and the old provider to Silent (or Inactive). No client-side change is required — the same anti_fraud_fingerprint value keeps flowing on every transaction; only enforcement changes.
4

(Optional) Retire the old provider

Once you’re confident, set the old provider to Inactive to stop traffic to it entirely.

​
API reference

Connection mode is set via the Update anti-fraud service API:
Request body
A service cannot be active and silent at the same time:
  • active: true makes the service Primary (the existing Primary, if any, is automatically deactivated).
  • silent: true makes it Silent.
  • If both are false, the service is Inactive.
anti_fraud_service_definition_id is required by the schema, but the underlying provider can’t be changed on update — you must echo the service’s existing definition string (for example, sift-anti-fraud). Read it from the dashboard or from the Get anti-fraud service API response for the service you’re updating.