Fireblocks is a platform that companies use to safely store and move digital assets. Fireblocks integration enables its clients to use Sumsub as their Travel Rule Provider (TRP) under the Fireblocks Travel Rule Link (TRLink) framework.

By integrating Fireblocks with Sumsub, you can:

• Perform compliant Travel Rule data exchange transactions with counterparties worldwide.
• Ensure Personally Identifiable Information (PII) is encrypted end-to-end.
• Monitor all outbound Travel Rule data exchange transactions directly in both Fireblocks and Sumsub dashboards.

Before enabling the integration, make sure that you meet the following requirements:

• Sumsub Travel Rule is enabled in your organization. If not, reach out to your Sumsub Customer Success Manager.
• TRLink is enabled in your Fireblocks workspace. If not, contact your Fireblocks Customer Success Manager to activate it.
• You have valid Fireblocks API credentials and Sumsub Dashboard access.
• You have configured a Fireblocks Legal Entity for TRLink.
• You can generate and store encryption and signing keys securely in your environment.

How Fireblocks integration works

Fireblocks orchestrates the transaction (including policy checks, routing, signing), while Sumsub manages the Travel Rule data exchange between VASPs.

Fireblocks integration supports both outbound and inbound Travel Rule data exchange flows.

Outbound flow

Use the outbound flow when you initiate a crypto transfer in Fireblocks and need to send Travel Rule data to the counterparty VASP.

Processing each outbound transaction includes the following steps:

1. User initiates a crypto transfer in Fireblocks.
2. Fireblocks TRLink determines that the transaction requires Travel Rule screening.
3. Fireblocks returns the required IVMS101 fields that must be populated for the transaction.
4. You retrieve the partner’s current public key for encryption.
5. You prepare the IVMS101.2023 payload, sign it, encrypt it, and create a Travel Rule message (TRM).
6. Fireblocks returns a TRM ID.
7. You create the Fireblocks transaction and reference the TRM by ID.
8. Sumsub performs VASP attribution and exchanges data with the beneficiary VASP.
9. If Sumsub does not find VASP, enable unhosted wallet verification:
   • End user verifies control (signs a message) or submits self-declaration via WebSDK link.
   • On success, we store the wallet for future reuse.
10. We send the result (accepted, rejected, awaiting, and so on) back to Fireblocks.
11. Fireblocks processes response and proceed with on-chain transaction if possible.

❗️

Important

All PII is encrypted with the private key you generate during setup. Fireblocks does not have access to your PII data.

Inbound flow

Use the inbound flow when a Fireblocks transaction already exists and you need to create and link a Travel Rule Message for that transaction.

Processing each inbound transaction includes the following steps:

1. Fireblocks creates or receives the transaction.
2. You create the Travel Rule Message and reference the existing Fireblocks transaction ID.
3. Fireblocks returns a TRM ID.
4. You link the TRM to the transaction using the returned TRM ID.
5. Sumsub processes the incoming Travel Rule data exchange.
6. We send the result (accepted, rejected, awaiting, and so on) back to Fireblocks.
7. The result appears in both Fireblocks and Sumsub dashboards.

For multi-destination transactions, link the TRM to the relevant transaction destination rather than to the whole transaction.

❗️

Important

Do not include plaintext PII in Fireblocks transaction requests. Encrypt Travel Rule PII before sending it through the TRLink flow.

Enable Fireblocks integration

The following steps describe how to connect your Fireblocks workspace to Sumsub and configure Travel Rule data exchange.

Step 1: Enable Travel Rule Link in Fireblocks

To integrate with Fireblocks, you need to start with performing the following steps on the Fireblocks side:

1. Contact your Fireblocks Customer Success Manager to enable TRLink.
2. Create or assign a Legal Entity for TRLink:
   1. Select Entity Purpose: TR Link.
   2. Assign relevant vaults.
   3. Configure how counterparties can discover your entity information by setting a discoverability mode: hidden, anonymous, or discoverable. For more information, refer to the Fireblocks documentation.

      👍

      Tip

      We suggest selecting discoverable mode which allows counterparties to access all shared legal entity information. It lets you fully automate the process of confirming wallet ownership during Inbound Travel Rule data exchange transactions.

3. Establish integrations for each legal entity with Sumsub. Initiate the integration by creating a customer integration record. This action generates a unique Customer Integration ID that identifies the connection between your legal entity and the Sumsub.

Step 2: Connect Fireblocks to Sumsub

Use the Sumsub Dashboard to link your Fireblocks workspace and set up encryption keys for secure Travel Rule data exchange.

1. In the Sumsub Dashboard, navigate to the Marketplace section and select Fireblocks.
2. Click Settings on Fireblocks.
3. Enter your Fireblocks Customer Integration ID (integration ID generated from Fireblocks workspace).
4. Once you test and save it, Sumsub will automatically generate app token and send it to Fireblocks to initiate an auto-connect procedure.
5. Click Generate Key Pair. Sumsub will create a public or private key pair. You will need them to encrypt and decrypt PII data.
   • Public key is stored by Sumsub to encrypt PII.
   • Private key remains in your environment only.
6. Once verified, connection status should change to active.

Step 3: Configure Travel Rule settings and rules

Use the Sumsub Dashboard to define your Travel Rule preferences.

1. Fill out either the Registration Form or Due Diligence Questionnaire.
2. Install the Travel Rule rules bundle from the Rules Library along with jurisdiction-specific rule bundles (such as Travel Rule: UK, Travel Rule: EU, and so on) based on your country of registration.
3. After installation, switch from the test mode and activate the rules.
4. Navigate to the Transactions and travel rule section. Open settings and select Travel Rule.
5. Set the confirmation timeout (the time period during which you want to receive the Travel Rule data exchange transaction details from the counterparty).
6. Select the originator/beneficiary fields to share and specify the data-matching strictness. For more information about Travel Rule settings, see this article.

Step 4: Assess Travel Rule data requirements

Before creating the Fireblocks transaction, call assessTravelRuleRequirement.

Use this endpoint to determine:

• Whether the transaction requires a Travel Rule Message.
• Which IVMS101 fields must be populated.
• Which data requirements apply to the transaction corridor.

Treat this assessment as the source of truth for Travel Rule screening decisions.

After you receive the response, collect and prepare the required originator and beneficiary data according to the returned field requirements.

Step 5: Encrypt data

Fireblocks requires the encrypted Travel Rule payload to use a nested JWT structure.

The payload must contain:

• An inner JWS signed with the sender’s private key.
• An outer JWE encrypted with the partner’s public key.
• A wrapper object that includes the encrypted payload and the list of populated IVMS101 fields.

Retrieve partner public key

Before encrypting the payload, call getPublicKeyForEncryption to retrieve the partner’s current public key.

Use this key to encrypt the Travel Rule payload. Do not reuse outdated keys.

Build payload

Prepare the payload according to the full IVMS101.2023 schema.

Do not send a free-form PII object. Example:

{
  "Originator": {
    "originatorPersons": [
      {
        "naturalPerson": {
          "name": {
            "nameIdentifier": [
              {
                "primaryIdentifier": "Smith",
                "secondaryIdentifier": "John"
              }
            ]
          }
        }
      }
    ]
  }
}

The required fields depend on the result returned by assessTravelRuleRequirement and your Sumsub Travel Rule configuration.

Create inner JWS

Create a signed JWT that contains the following mandatory claims:

The receiver validates the expected issuer, iat, exp, and mandatory jti. Allow a clock skew of ±60 seconds.

Encrypt signed JWT

Encrypt the full signed JWT into a compact JWE string using the partner’s public key.

The JWE header must include:

{
  "cty": "JWT"
}

The result is a nested JWT: JWS inside JWE.

Create outer wrapper

Submit the encrypted payload in the following wrapper format:

{
  "version": "IVMS101.2023", // Version is the IVMS version. Use IVMS101.2023. 
  "data": "<compact JWE string>", // data is the compact JWE string.
  "filledFields": [ "Originator.originatorPersons.naturalPerson.name.nameIdentifier.primaryIdentifier"
  ] // filledFields is an array of dot-notation paths for all non-null leaf fields in the source IVMS object.
}

Generate filledFields from the actual IVMS101 payload. Do not add fields that are missing or null.

The Travel Rule payload must use the nested JWT format expected by Fireblocks, not a free-form PII object.

📘

Note

For more details, see the examples of implementations for encrypting PII data.

Step 6: Create Travel Rule message

After you prepare the encrypted wrapper, call createTravelRuleMessage.

Use this endpoint to register the Travel Rule Message separately from the Fireblocks transaction.

The response returns a TRM ID. You must use this ID when creating or linking the Fireblocks transaction.

Recommended TRM reference format: <partnerIdent>:<trmId>. For example, sumsub:12345.

Step 7: Create Fireblocks transaction

After you create the Travel Rule Message, create the Fireblocks transaction and reference the TRM by ID.

Do not send the compact JWE directly in the transaction request. The transaction request must reference the existing TRM.

Use the travelRuleMessageId field. Example:

{
  "assetId": "ETH",
  "source": {
    "type": "VAULT_ACCOUNT",
    "id": "0"
  },
  "destination": {
    "type": "ONE_TIME_ADDRESS",
    "oneTimeAddress": {
      "address": "0xRecipient..."
    }
  },
  "operation": "TRANSFER",
  "amount": "1.0",
  "note": "Payment to beneficiary",
  "travelRuleMessageId": "sumsub:12345"
}

📘

Note

If the Fireblocks transaction already exists, call setTransactionTravelRuleMessageId to link the TRM to the transaction.

Use this flow for inbound scenarios or when the transaction was created before the Travel Rule Message.

For multi-destination transactions, call setDestinationTravelRuleMessageId. This links the TRM to a specific transaction destination.

Step 6: View results

Once you send the transaction, Fireblocks applies TRLink policies and forwards the encrypted Travel Rule message to Sumsub.

• Sumsub performs VASP attribution and exchanges data via the appropriate protocol.
• Beneficiary VASP confirms wallet ownership and matches PII.

After that, you will receive outcomes in both Dashboards.