Address Registry

Address Registry lets you verify the legal entity controlling a blockchain address before sending or receiving a transaction. When enabled, Address Registry allows you to query blockchain addresses and receive certain legal entity information about the institution controlling the associated vault. The Address Registry is designed solely to facilitate counterparty discovery and verification in connection with digital asset transactions.

Address Registry is a free capability available to all Fireblocks customers and enabled by default. Coverage is currently limited to addresses within the Fireblocks network.

What Address Registry returns

When you query an address that belongs to an opted-in Fireblocks customer, Address Registry returns:

• Verification status: Whether the counterparty's legal entity information has been independently verified (leiData: true) or is based on Fireblocks data without independent validation (leiData: false).
• Legal entity information: The entity name, jurisdiction (ISO country code), and Legal Entity Identifier (LEI) if the counterparty has declared one. If the counterparty has also declared a Travel Rule provider and compliance contact email, those are included as well.

When an address cannot be resolved (because the counterparty is not a Fireblocks customer, has opted out, or is in an unsupported environment), Address Registry returns not_found. A not_found result does not indicate that the address is unhosted, illicit, or non-compliant.

How Address Registry works

Address Registry establishes a trust perimeter across the Fireblocks network. Results are deterministic and consent-based: when Address Registry is active for your workspace, any other opted-in Fireblocks customer can look up one of your vault addresses and receive your legal entity name and jurisdiction. Likewise, you can query any address on the network and receive the same information about the counterparty.

Only workspaces with Address Registry enabled can perform queries. See the Acceptable use section for more information.

How to look up an address

1. Go to Security > Policies > Compliance > Address Registry.
2. Enter a blockchain address in the search bar.
3. View the result.

You can also query addresses programmatically using the API. See the Address Registry developer documentation for endpoint details and examples.

Legal entity setup

To appear as a verified entity when counterparties look up your addresses, register your Legal Entity Identifier (LEI) with Fireblocks. An LEI is a standardized 20-character code, maintained by the Global Legal Entity Identifier Foundation (GLEIF), that uniquely identifies a legal entity across jurisdictions.

Registering an LEI is optional if you only want to query addresses. It is required to return verified data to counterparties and to use Address Registry in compliance workflows.

Register your LEI via the Console

1. Go to Security > Policies > Compliance > Address Registry > Add Legal Entity.
2. Enter your default LEI (a 20-character identifier). You can look it up on the GLEIF website. If you do not have one, Fireblocks helps you obtain one from a partner directly within the setup flow.
3. Select Verify. Fireblocks reviews and approves your submission.
4. Map your vault accounts to the correct legal entities. Each vault account supports a maximum of one entity.
5. Optionally, declare your Travel Rule provider(s) and contact email.

You can also register legal entities via the API. See the Address Registry developer documentation for endpoint details.

LEI states

After you submit an LEI, it moves through the following states:

After Fireblocks approves your first LEI, all vault accounts map to that entity by default. If you register additional legal entities and want to map specific vault accounts to different entities, you can do so via the API.

Opting out of Address Registry

All workspaces are opted in to Address Registry by default, including any new workspaces to be created in the future. If you want to opt out at the account level, so that all current and future workspaces are excluded from Address Registry, contact your Customer Success Manager. If you request an account-level opt-out through your CSM, you will have Address Registry disabled across all existing workspaces, and any workspaces you create after the request will also be opted out automatically. If you remain opted in, you can still opt out of individual vault accounts or an entire workspace at any time via the Console or API.

You can opt out of your entire workspace or individual vault accounts at any time. When you opt out, lookups against your addresses return not_found. Opting out also prevents you from querying addresses or using compliance workflows that depend on Address Registry.

Compliance workflows

Once Address Registry is active, you can use it inside your transaction screening policy to automate compliance decisions based on counterparty identity. This involves two steps: defining counterparty groups, then applying rules to those groups in a screening policy.

Counterparty groups

A counterparty group is a named set of counterparties that share specific attributes, such as jurisdiction. You can create as many groups as you need. Jurisdiction is the only available grouping attribute initially — additional attributes such as business type and license type are planned.

To create a counterparty group:

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

You can also manage counterparty groups via the API. See the Address Registry developer documentation for endpoint details.

Screening policy

The screening policy has two parts:

• Transaction screening policy: Defines which transactions trigger a counterparty check. Build rules using source, destination, asset, and amount. Rules evaluate from top to bottom, and the first match wins. A catch-all default rule is required as the last entry. You also configure timeout behavior separately to define what happens if the registry check times out during a transaction (accept or reject).
• Post-screening policy: Defines the action to take based on the counterparty check result.

Common use cases include allowing payouts only to wallets hosted by verified entities in certain jurisdictions, or blocking transactions to addresses belonging to counterparties in restricted jurisdictions.

Availability and limitations

Fireblocks does not currently support Address Registry for workspaces hosted on European or Swiss environments due to infrastructure isolation between production instances. We plan to add support for these environments shortly after the initial release. In the meantime, queries against addresses from European or Swiss-hosted workspaces return not_found.

Address Registry is not available in Developer Sandbox workspaces.

Acceptable use

Address Registry is designed for counterparty verification in connection with digital asset transactions. To maintain the integrity and privacy of the registry, you must use it responsibly. Specifically, you must not:

• Use Address Registry for any purpose other than verifying counterparties in connection with digital asset transactions.
• Scrape, bulk-download, or systematically extract data from the registry.
• Resell, redistribute, or commercialize query results or any data obtained from Address Registry.
• Attempt to identify, profile, or de-anonymize individual persons using Address Registry data.
• Use Address Registry for surveillance or competitive intelligence.
• Circumvent or attempt to circumvent any technical controls, authentication requirements, or rate limits.

Fireblocks monitors usage to prevent misuse and reserves the right to suspend or permanently revoke access, with or without prior notice, when abuse is detected. Use of Address Registry must comply with the terms of your agreement with Fireblocks.

FAQ

What is an LEI and why does Address Registry use it?

A Legal Entity Identifier (LEI) is a 20-character global code, mandated by the G20 and maintained by GLEIF, that uniquely identifies a legal entity across jurisdictions. Fireblocks uses LEIs as the verification anchor because they are tied to an independently maintained global standard, rather than a proprietary database.

What does "verified" mean?

Every lookup result includes a leiData flag:

• leiData: true: The counterparty declared their LEI, the entity data was sourced from GLEIF, and the Fireblocks compliance team verified that the legal entity name matches Fireblocks client records.
• leiData: false: The entity data is not based on a declared LEI, and no independent validation should be assumed.

You can filter for verified entities only when building compliance workflows.

What does not_found mean?

A not_found result means one of the following: Address Registry is not yet available in the counterparty's region, the counterparty has opted out, or the counterparty is not a Fireblocks customer. It does not indicate that the address is unhosted, illicit, or non-compliant.

How does Address Registry relate to Travel Rule requirements?

FATF guidance (paragraph 197) outlines three steps for counterparty identification:

1. Determine whether you are transacting with a VASP or an unhosted wallet.
2. Identify the counterparty VASP using a reliable data source. Address Registry provides a deterministic source that Fireblocks updates in real time.
3. Assess whether the counterparty VASP is eligible to receive customer data. Verified GLEIF data can serve as a first filter.

Address Registry also surfaces which Travel Rule provider the counterparty uses, if declared.

What information can someone learn about my customers or end users?

Nothing. The registry returns only the following information about the legal entity controlling a vault: name, jurisdiction, and LEI (if declared). When someone queries an address controlled by Acme Payments Ltd., Brazil; they see "Acme Payments Ltd., Brazil", not any information about Acme's customers which may own the funds. The registry contains no information about a client's individual account holders.

How does Address Registry differ from blockchain analytics?

Blockchain analytics firms use heuristics to link addresses to entities and beneficial owners, typically without explicit consent. Address Registry operates on institutional consent, is deterministic, and is scoped to a single purpose: counterparty discovery for compliance and security.

What stops someone from scraping the registry?

Address Registry is privacy-preserving by design. You can only look up a specific address to retrieve the controlling entity; you cannot query in reverse or enumerate the registry. Fireblocks enforces query authentication, API rate limiting, daily request caps, and monitoring alerts to keep the number of queries proportional to transaction volume.

Will Fireblocks sell my query data?

No. Fireblocks does not sell Address Registry query results or usage data.

What are the implications under GDPR?

The Address Registry is designed to return attribution at the legal entity level and does not intentionally contain information about individual account holders or end users. Fireblocks does not maintain any direct linkage within the Address Registry between vault addresses and identified natural persons. Participants should conduct their own assessment of applicable data protection obligations with respect to their participation in the Address Registry.