Skip to main content
Address Registry Screening (ARS) checks a transaction’s counterparty against Fireblocks’ shared registry of known, verified addresses, as part of your compliance policy. It answers one question: does this transaction involve an address that belongs to a verified entity, or to a counterparty you have grouped for special handling? ARS covers both incoming and outgoing transactions, matching on the source or the destination address. It is the first check in the screening flow, before AML/KYT and Travel Rule, and it is free. ARS is not a risk screening, and it does not decide whether the Travel Rule applies. A not found result does not mean an address is unhosted, illicit, or non-compliant: it may belong to a counterparty that is not a Fireblocks customer, or that has opted out. To register your legal entity or look up addresses directly, see Address Registry.

​
Common use cases

  • Transact only with verified counterparties: reject transactions to or from addresses not found in the registry.
  • Restrict jurisdictions: block transactions with counterparties in jurisdictions you have grouped as restricted.

​
What you can do through the API

​
Before you start

ARS depends on Address Registry. All workspaces are opted in to Address Registry by default. If your workspace has opted out, activating ARS fails, and opting out later disables ARS until you opt back in. See Address Registry.

​
How ARS decides

You build the ARS policy in the Console, under Policies > Compliance. It works like any other compliance policy (see Compliance Policies):
  • Trigger (Screening Policy) decides which transactions get a counterparty check, by source, destination, asset, and amount.
  • Timeout behavior decides whether a transaction is accepted or rejected if the registry check does not return in time.
  • Outcome (Post-Screening Policy) decides the action based on the result:

​
Step 1: Create counterparty groups

A counterparty group is a named set of counterparties matched by jurisdiction. Today, jurisdiction is the only grouping attribute. You define groups first, then reference them in your Outcome (Post-Screening Policy). Create as many groups as your policy needs. Creating, updating, and deleting groups requires the Admin or Non-Signing Admin role. Create and update requests accept an optional Idempotency-Key header, valid for 24 hours; the delete endpoint does not accept this header.

​
Step 2: Build the policy

In the Console, add Trigger (Screening Policy) rules that decide which transactions ARS checks, then Outcome (Post-Screening Policy) rules that reference your counterparty groups. See About Address Registry Screening on the Help Center.

​
Step 3: Activate ARS

Both return the current configuration:
Once active, ARS applies to every transaction that matches your Trigger (Screening Policy). Deactivating it stops the check until you activate it again.

​
Results

  • While it runs: the transaction is in PENDING_AML_SCREENING, the same status as every other check.
  • On rejection: subStatus is REJECTED_AML_SCREENING, the same value as other checks, delivered on the transaction.status.updated webhook event. See Compliance Events & Webhooks.
  • Full result: ARS results are not included in GET /screening/transaction/{txId}, which covers AML/KYT and Travel Rule only.
  • Next steps: to bypass a rejected transaction, see Transaction Screening Operations.

​
Limitations

  • European and Swiss-hosted workspaces: Address Registry, and so ARS, is not supported. Lookups against addresses from these workspaces return not_found.
  • Developer Sandbox workspaces: Address Registry, and so ARS, is not supported.
  • Coverage: the registry only resolves addresses within the Fireblocks network.
Wherever the registry returns no match, your rule for “Counterparty not found in the registry” applies.

​
On the Help Center

To build the ARS policy or manage counterparty groups in the Console, see About Address Registry Screening.