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.
- 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.
-
Create the integration with the legal entity’s
customerIdand Sumsub’spartnerIdentfrom the partner list. The response returns acustomerIntegrationId, used in every call after this. -
Share the
customerIntegrationIdwith Sumsub. Sumsub supports auto-connect only: it sends your API credentials to Fireblocks directly. -
Test the connection.
success: trueconfirms the integration can reach Sumsub.
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:- Screening Policy: template (CSV) and instructions (CSV)
- Missing Travel Rule Message Policy: template (CSV) and instructions (CSV)
- Post-Screening Policy: template (CSV) and instructions (CSV)
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:
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.
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:
Reference implementation: JWT encryption and decryption
Reference implementation: JWT encryption and decryption
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.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 (
Custom key pair upload is under consideration for future releases.
Encryption example
Sumsub’s public key response looks like this:node encrypt.js public-key.json private-key.json ivms.json) produces:Decryption example
To decrypt, use the sameTRJWTCodec 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.- Assess the requirement, passing the amount, asset, source, destination, and
beneficiaryVaspId.decisionisREQUIRED,NOT_REQUIRED, orNEED_MORE_INFO; whenREQUIRED,requiredFieldslists the IVMS101 fields to collect. - Encrypt the PII (Step 4).
- Create the TRM with the same transaction details and the
ivms101object. - Create the transaction with
travelRuleMessageIdset to the TRM’sid, for exampletrm_1234567890abcdef. If the transaction already exists, link the TRM to it instead. In a multi-destination transaction, link a TRM to each destination, matching byamountanddestination; the endpoint does not acceptdestinationScreeningId.
Step 6: Receive an incoming transaction
Create the TRM after Fireblocks detects the transaction.- Assess the requirement, passing the
txIdand theoriginatorVaspId. The transaction details are filled in from thetxId. - Encrypt the PII you hold for your beneficiary.
- Create the TRM with the
txId,originatorVaspId, andivms101object. - 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".
PENDING, ACCEPTED, REJECTED, and FAILED. A canceled TRM cannot be reused; create a new one if the transaction goes ahead.
Testing and monitoring
Test withBTC_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.