Address Registry Screening checks a transaction's counterparty against Fireblocks' 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 one you have grouped for special handling?

This article covers using the registry as a screening check. For registering your legal entity, looking up addresses directly, or exporting attestations, see Address Registry in Compliance Tooling.

How it works

Address Registry Screening builds on two things: counterparty groups, and the Trigger and Outcome rules that act on them.

A counterparty group is a named set of counterparties sharing an attribute. Today, that attribute is jurisdiction. You define these groups first, then reference them in your policy.

The Trigger for this check works the same way as any other. See Building a Compliance Policy for how Trigger and Outcome work in general. What is specific here: you also configure timeout behavior separately, to define what happens if the registry check does not return a result in time.

The Outcome maps the registry result to an action:

Setting it up

Before you begin, your workspace needs Address Registry enabled. It is on by default; see Address Registry in Compliance Tooling if you need to check its status.

1. Go to Security > Policies > Compliance > Address Registry > Counterparty Groups > New group.
2. Name the group, for example "Restricted Jurisdictions."
3. Select jurisdictions using the country picker.
4. Select Save.

You can also manage counterparty groups via the API.

Once your groups exist, configure your Trigger and Outcome the same way as any other policy. See Building a Compliance Policy. Both are available via Console or API.

Common use cases

• Rejecting transactions to addresses not found in the registry, so you only transact with verified counterparties.
• Blocking transactions to addresses belonging to counterparties in restricted jurisdictions.

Limitations

Address Registry Screening depends on the underlying registry. It is not available for workspaces hosted on European or Swiss environments, or in Developer Sandbox workspaces. In these cases, every lookup returns no match, so any rule keyed to "Address not found" applies.

FAQ

The questions below are the ones readers ask most often.

Does this replace my Travel Rule due diligence?

No. FATF guidance (paragraph 197) describes counterparty identification as part of Travel Rule due diligence. Address Registry Screening can serve as the data source for that step, but it does not determine Travel Rule applicability or handle message exchange on its own. See About Travel Rule.

What happens if the address is not in the registry?

The transaction matches your "Address not found in registry" condition, and whatever Outcome you have set for that condition applies.

Developer portal

See Address Registry for using the registry in a screening policy.