Skip to main content
Sumsub is a Travel Rule provider. It is a premium add-on that Fireblocks Support enables on Developer Sandbox, Testnet, and Mainnet workspaces. Everything, including connecting and creating Travel Rule messages (TRMs), happens through the API: you encrypt the PII on your side, and because Fireblocks does not hold the key that decrypts it, there is no Console flow. Rules are set by Fireblocks Support.

What you can do through the API

Paths marked … start with /screening/trlink/customers/integration/{customerIntegrationId}.

Step 1: Set up the Fireblocks SDK

Install the Fireblocks SDK in your system; TRMs are created and linked from your code. See TypeScript SDK. Before you continue:
  • Sumsub Travel Rule is enabled on your Sumsub account. See Sumsub’s Fireblocks integration guide.
  • Fireblocks Support has enabled Sumsub on your workspace.
  • You have downloaded your key pair from Sumsub. You sign the data you send with your private key, and decrypt the data you receive with it.

Step 2: Connect Sumsub

You do this once, during onboarding.
The Travel Rule legal entity you create here is separate from the legal entity you register in Address Registry. Creating one does not create or change the other.
  1. Create a Travel Rule legal entity, the business subject to the Travel Rule. Most customers need one; if you operate across jurisdictions with different requirements, create one per jurisdiction and assign vault accounts to each. Leave exactly one entity without a vault restriction: it covers every vault account not assigned elsewhere.
  1. Create the integration with the legal entity’s customerId and Sumsub’s partnerIdent from the partner list. The response returns a customerIntegrationId, used in every call after this.
  2. Share the customerIntegrationId with Sumsub. Sumsub supports auto-connect only: it sends your API credentials to Fireblocks directly.
  3. Test the connection. success: true confirms the integration can reach Sumsub.
To update your Sumsub credentials later, submit a ticket to Fireblocks Support. Several Fireblocks workspaces can use one Sumsub account.

Step 3: Set up the policy

Sumsub uses three policy stages: Trigger (Screening Policy), Missing Travel Rule Message, and Outcome (Post-Screening Policy); see Compliance Policies. Missing Travel Rule Message rules can depend on how long a transaction has waited, for example accepting small transactions after 30 minutes but rejecting large ones. Rules are not self-service: fill out a policy template, run it through your compliance approval process, and submit it to Fireblocks Support, who apply it. Read the current policy through the API. Download each policy template and its instructions as CSV files: Fireblocks enforces limits you cannot configure, so a transaction never waits indefinitely: 1.5 hours for outgoing transactions, 7 days for incoming. Near the limit, a Wait rule is skipped instead of holding the transaction. A transaction’s screening status is Completed, Pending, Bypassed (approved without review by your Trigger), or Failed. In a multi-destination transaction, each destination is evaluated separately and the most restrictive result applies to the whole transaction.

Policy examples

Each stage is a list of rules. Fireblocks evaluates the rules from top to bottom, and the first match wins. A rule can be scoped by direction, asset, amount, customer, provider, and source or destination type. Rule shape for each stage:
While a destination waits, two separate policies decide what happens: The default is WAIT, then ACCEPT: hold for a window, then accept if nothing changes. Set the hold window with validAfter and validBefore, in seconds from the start of the screening step.
To record Travel Rule data without ever holding or blocking a transaction, set both policies to a single ACCEPT rule, with no WAIT:

Step 4: Encrypt the PII

Sumsub uses a nested JWT: a JWS signed with your private key, inside a JWE encrypted with Sumsub’s public key. The encrypted result goes in the TRM’s ivms101 object. filledFields lists, in dot notation, every IVMS101 field you populated:
To read data you receive, decrypt the JWE with your private key and verify the inner JWS with Sumsub’s public key.
Below is an example of how to encrypt and decrypt IVMS data exchanged with Sumsub. To encrypt, sign the IVMS data with your private key, then encrypt it with Sumsub’s public key. To decrypt, use your own private key to decrypt the data, then verify the signature with Sumsub’s public key. Your key pair is generated by Sumsub on their marketplace and available to download there.
Custom key pair upload is under consideration for future releases.

Encryption example

Sumsub’s public key response looks like this:
Here is an example of a private key:
Here is an example of source IVMS data:
This utility takes the paths to Sumsub’s public key, your private key, and the IVMS data, and produces an encrypted IVMS block with its filled fields:
Running it (node encrypt.js public-key.json private-key.json ivms.json) produces:

Decryption example

To decrypt, use the same TRJWTCodec class with its decryptAndDecode method. The example input below is for illustration only — it cannot be decrypted with the keys above, since it is sample data that has already expired; test with the data Sumsub actually sends you as part of creating or reading a TRM.

Step 5: Send an outgoing transaction

Create the TRM first, then the transaction.
  1. Assess the requirement, passing the amount, asset, source, destination, and beneficiaryVaspId. decision is REQUIRED, NOT_REQUIRED, or NEED_MORE_INFO; when REQUIRED, requiredFields lists the IVMS101 fields to collect.
  2. Encrypt the PII (Step 4).
  3. Create the TRM with the same transaction details and the ivms101 object.
  4. Create the transaction with travelRuleMessageId set to the TRM’s id, for example trm_1234567890abcdef. If the transaction already exists, link the TRM to it instead. In a multi-destination transaction, link a TRM to each destination, matching by amount and destination; the endpoint does not accept destinationScreeningId.

Step 6: Receive an incoming transaction

Create the TRM after Fireblocks detects the transaction.
  1. Assess the requirement, passing the txId and the originatorVaspId. The transaction details are filled in from the txId.
  2. Encrypt the PII you hold for your beneficiary.
  3. Create the TRM with the txId, originatorVaspId, and ivms101 object.
  4. Link the TRM to the transaction.

Resolve pending and missing messages

Fireblocks notifies you of both cases in the Compliance webhook category; see Compliance Events & Webhooks for the payloads. A TRM needs more data (TRLink.RequiredActions, once per destination). The TRM is PENDING. Read its required actions and resolve them one at a time; each call returns the updated TRM, which leaves PENDING once the last action is resolved. A transaction has no TRM (TRLink.NoTRMessage). It waits in the Missing Travel Rule Message stage until a TRM arrives or your rule times out. To decide without waiting, for example from your own KYC data, submit a manual decision with action ACCEPT or REJECT and an optional reason of up to 500 characters, without PII.
  • The decision applies to every destination currently in that stage; it returns an error if there are none.
  • Repeating the same action has no effect; a different action replaces the earlier one.
  • Once a destination has moved past the stage, its decision cannot be changed.
  • Manual decisions are recorded with source: "MANUAL".
TRM statuses are PENDING, ACCEPTED, REJECTED, and FAILED. A canceled TRM cannot be reused; create a new one if the transaction goes ahead.

Testing and monitoring

Test with BTC_TEST, ETH_TEST5, and XRP_TEST before real value. In the Console, Transaction History shows the policies and rules applied to each transaction, Sumsub’s responses, and the final verdict with an explanation.

Troubleshooting

Transactions not screened: check that the vault accounts are assigned to a legal entity and that the Trigger rules match. Unexpected verdicts: check the rule order and the Valid After and Valid Before windows. Integration errors such as 401 or 404 come from Sumsub; Fireblocks does not validate credentials when you connect and returns the error as is. Check that the app token and secret were created in the same Sumsub environment and application as this integration.

Limitations

  • Rules are not self-service; Fireblocks Support applies them.
  • Combining providers: Sumsub can run alongside GTR and TRUST, but not Notabene.
  • Disconnecting permanently deletes the stored credentials and the integration, and pending TRMs may fail. Deleting a Travel Rule legal entity also deletes its integrations, TRMs, and configuration. Neither can be undone.
  • Key pair: Sumsub generates your key pair; you cannot upload your own.

On the Help Center

For Sumsub setup and monitoring in the Console, see Sumsub.