Travel Rule is the FATF requirement (Recommendation 16) for virtual asset service providers (Virtual Asset Service Providers (VASPs)) to exchange originator and beneficiary information for qualifying transactions. Fireblocks handles this in two ways: through a dedicated Travel Rule provider for most counterparties, or through a direct integration for connected exchanges and on/off-ramps. This article covers both; see How it works for which applies when.
How it works
Travel Rule here covers two different paths, handled differently: dedicated Providers that screen any qualifying transaction with a counterparty, and Connected accounts, where Fireblocks owns the integration directly for specific exchanges and on/off-ramps.
Providers
Travel Rule fits into your compliance policy the same way any other check does: a Trigger decides which transactions require a Travel Rule message, and an Outcome decides what happens based on the response. See Building a Compliance Policy for how Trigger and Outcome work in general.
The "result" here is a message status: whether the required exchange completed, is still pending, was rejected, or failed to complete in time. What you can do with that status differs by provider; some support additional actions like Freeze, Wait, or Cancel, and some let you target rules to a specific legal entity or address rather than just source, destination, asset, and amount.
See each provider's own article for its exact fields and values.
Unlike Anti-Money Laundering (AML) and Know Your Transaction (KYT), you are not limited to one Travel Rule provider at a time. Sumsub and GTR, for example, can both be active on the same workspace.
Connected accounts
For a connected exchange or an on/off-ramp, Fireblocks owns the integration directly rather than routing it through one of the providers above. See Travel Rule for Connected accounts.
Developer portal
See Travel Rule policies and the Travel Rule support integration guide.