Documentation Index
Fetch the complete documentation index at: https://developers.fireblocks.com/llms.txt
Use this file to discover all available pages before exploring further.
Overview
Travel Rule Support (TRSupport) is Fireblocks’ comprehensive compliance solution for meeting cryptocurrency travel rule regulations across global jurisdictions. TRSupport automates the collection, encryption, and exchange of counterparty information required by regulatory frameworks like the Financial Action Task Force Travel Rule, ensuring your organization remains compliant while maintaining transaction speed and security.Prerequisites
Before integrating TRSupport:- Enable TRSupport Feature: Contact your Customer Success Manager to enable TRSupport for your Fireblocks workspace
- API Access: Ensure you have valid API credentials for your Fireblocks workspace
- Policy Planning: Design your three-stage policy configuration strategy
- Development Environment: Set up test environments for integration testing
Core Concepts
Three-Stage Policy Framework
TRSupport processes transactions through three configurable policy stages:- Screening Policy: Determines whether to contact Travel Rule providers (TRP)
- Missing Travel Rule Message (TRM) Policy: Handles scenarios when TRMs are unavailable
- Post-screening Policy: Determines final actions based on screening results
Multi-Destination Support
TRSupport intelligently handles transactions with multiple destinations:- Each destination is evaluated independently
- Results combine using “worst result wins” logic
- Single transaction verdict with per-destination visibility
Providers
TRSupport integrates with TRP networks to facilitate compliant information exchange between Virtual Asset Service Providers (VASPs).Sumsub
Learn more about the integration flow in the Fireblocks integration article on Sumsub’s documentation site.Global Travel Rule (GTR)
Learn more about the integration flow in the Fireblocks integration article on GTR’s documentation site.Common Patterns and Best Practices
Setup Flow
The initial setup process is typically performed once during onboarding and consists of two main stages: configuring legal entities and establishing TRP integrations.Legal Entities
TRSupport requires at least one legal entity to be configured. A legal entity represents a distinct business entity within your organization, subject to travel rule compliance. Most customers should use a single legal entity for their entire operation. However, if you operate as a large holding company across multiple jurisdictions with different compliance requirements, you can configure multiple legal entities and assign specific vault accounts to each jurisdiction. When configuring legal entities, be aware that only one entity should be configured without vault restrictions. This entity will serve as the default for all vaults not explicitly assigned to other entities. Each legal entity can have multiple TRSupport integrations with different TRPs. For example, a multi-jurisdictional organization might configure:- Legal Entity 1: EU compliance rules (vaults 0-5)
- Legal Entity 2: US compliance rules (vaults 6-10)
- Legal Entity 3: APAC compliance rules (vaults 11-15)
getLegalEntities- Retrieves all configured legal entitiesgetTRLinkCustomerById- Retrieves a specific legal entitycreateTRLinkCustomer- Creates a new legal entityupdateTRLinkCustomer- Modifies an existing legal entitydeleteTRLinkCustomer- Removes a legal entity
TRSupport Integrations
After configuring your legal entities, you must establish integrations for each legal entity with your chosen TRP(s). First, 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 TRP. You can share this Customer Integration ID with your TRP to initiate an “auto-connect” procedure (Sumsub only supports this method), where the TRP automatically provides your API credentials to Fireblocks. Alternatively, you can manually configure the API key and secret using theconnectLegalEntityIntegration endpoint.
Once credentials are configured, use the testTRLinkIntegrationConnection endpoint to verify that the integration is functioning correctly before proceeding with travel rule operations.
Inbound and Outbound Transaction Flows
Always use theassessTravelRuleRequirement endpoint before creating a TRM. This endpoint is the single source of truth for determining if a TRM is needed and what data it must contain.
The endpoint evaluates the transaction against compliance rules and will tell you if the status is REQUIRED, NOT_REQUIRED, or if you NEED_MORE_INFO. When required, it provides a precise list of mandatory IVMS101 fields to guide your data collection process.
Inbound Transaction Flow
For inbound transactions, use the existing Fireblocks transaction ID:Outbound Transaction Flow
For outbound transactions, create the TRM before creating the Fireblocks transaction:Encryption and Decryption (Partner: Sumsub using JWT encryption)
Below is an example of how to encrypt and decrypt IVMS data retrieved from Sumsub. To do this, we must use our private key to sign IVMS data and the partner’s public key (as described in the API Integration section) to encrypt data. For decrypting, we need our own private key to decrypt the IVMS data and a partner’s public key to verify the signature. At the moment, our public/private key pair is generated by a partner on their marketplace and available to download.Note:Custom key pair upload is under consideration for future releases.
Encryption Example
The following illustrates a partner’s public key response:Decryption Example
Here is an example of source IVMS structure with encrypted IVMS data. Note that this data is just an example input file and cannot be used for actual testing, as the parser will throw a token-expired exception. This encrypted data should be the content the partner has sent to us as part of creating or getting a TRM (i.e., signed with their private key and encrypted with our public key). In other words, the output of the previous script cannot be used here for testing.Encryption and Decryption (Partner: GTR using Curve25519)
Security requirement:All PII must be encrypted before transmission to GTR. Plain-text PII is prohibited.
Key Requirements
- Algorithm: Curve25519
- Key Format: ED25519 (Public/Private Key Pair)
- Key Conversion: ED25519 keys must be converted to Curve25519 format
- Key Management: Configure public key in GTR Dashboard (Settings > Public Key)
Differences from Sumsub
| Aspect | Sumsub | GTR |
|---|---|---|
| Encryption Algorithm | RSA with JWT (JWS inside JWE) | Curve25519 |
| Key Format | JWK (JSON Web Key) | ED25519 |
| Key Conversion | Not required | ED25519 → Curve25519 required |
| Public Key Management | Retrieved via getPublicKeyForEncryption | Configured in GTR Dashboard |
Implementation
- Configure public key in GTR Dashboard (Settings > Public Key) with curve25519 algorithm
- Obtain GTR’s public key from GTR integration settings
- Encrypt IVMS101 data using GTR’s encryption tool
- Submit encrypted data via
createTravelRuleMessageendpoint - Decrypt received data using GTR’s decryption tool for inbound TRMs
GTR Encryption Tool
GTR provides a standalone open source encryption tool that handles ED25519 to Curve25519 key conversion, IVMS101 encryption, and decryption. This tool operates independently from the Fireblocks SDK. Use GTR’s encryption tool rather than implementing Curve25519 encryption manually to ensure compatibility with GTR’s requirements. Learn more about the encryption tool in the GTR Fireblocks integration guide.Note:The
getPublicKeyForEncryption endpoint does not apply to GTR integrations. Public keys are managed directly in the GTR Dashboard.API Integration
Legal Entity Management
Legal entity management endpoints handle the creation and maintenance of legal entities requiring travel rule compliance. Each legal entity can have multiple TRSupport integrations with different TRP partners. Legal entities contain essential identifying information such as legal names, geographic addresses, national identifiers, and associated vault accounts. Thediscoverable field controls visibility in partner address books for counterparty discovery.
Create a Legal Entity
Creates a new legal entity for TRSupport integrations. This is the first step in setting up travel rule compliance for a legal entity. The legal entity stores all the legal and identification information required for IVMS101 compliance, including geographic address, national identification numbers, and date of incorporation. Once created, the legal entity can be linked to one or more TRPs through customer integrations. Thevaults array associates specific Fireblocks vault accounts with this customer entity, while the discoverable setting determines if this legal entity should be visible to counterparties in the partner’s address book.
Endpoint:
Get a Legal Entity
Retrieves complete details for a specific legal entity by its unique ID. This endpoint returns all stored information about the legal entity, including their legal identifiers, geographic address, associated vaults, and travel rule configuration. Use this endpoint to verify legal entity details before creating integrations or to display legal entity information in your application. Endpoint:customerId(string, UUID) - The legal entity ID
Get All Legal Entities
Retrieves a list of all legal entities associated with the current tenant. This endpoint is useful for displaying a list of all legal entities configured for travel rule compliance. Each legal entity in the response includes full details, including vaults, addresses, and identifiers. The response is scoped to the authenticated tenant to ensure data isolation between different organizations. Endpoint:Update a Legal Entity
Updates the information for an existing legal entity. This endpoint allows you to modify any legal entity field, including their legal name, geographic address, national identifiers, vault associations, and discoverability settings. Updates are typically needed when business information changes or when correcting registration data. All fields in the request body are optional, allowing partial updates while preserving unchanged fields. Endpoint:customerId(string, UUID) - The legal entity ID
Delete a Legal Entity
Permanently deletes a legal entity and all associated data, including integrations, TRMs, and configuration. This is a destructive operation that cannot be undone. Use this endpoint when a legal entity is no longer operating or when cleaning up test data. All active integrations for this legal entity will be disconnected, and any pending TRMs may fail. Ensure all transactions are complete before deleting a legal entity. Endpoint:customerId(string, UUID) - The legal entity ID
Legal Entity Integrations
Legal entity integration endpoints manage the connections between legal entities and the TRP partners. Each integration represents a configured connection to a specific TRP, such as Sumsub, enabling the customer to send and receive TRMs through that provider’s network. An integration requires API credentials from the TRP to establish connectivity. A single customer can have multiple integrations with different partners to support various compliance networks. These endpoints handle the full lifecycle of partner connections, including creation, credential management, connectivity testing, and disconnection.Create a Legal Entity Integration
Creates a new TRSupport integration that associates a legal entity with a specific TRP partner. This endpoint initializes the integration record but does not yet establish connectivity with the partner’s API. After creation, you must use theconnectLegalEntityIntegration endpoint to provide API credentials. The partnerIdent parameter identifies which TRP to integrate with (e.g., “Sumsub”). You can retrieve available partners using the getPartners endpoint. Each integration is assigned a unique customerIntegrationId used in subsequent API calls for TRM operations.
Endpoint:
Connect a Legal Entity Integration
Establishes active connectivity to the TRP by supplying API credentials. This endpoint stores the API key and optional secret provided by the TRP, enabling the integration to authenticate and communicate with the partner’s API. After connecting, the integration can be used for travel rule operations such as creating TRMs and querying VASPs. The credentials are securely stored and partially censored in API responses. Use thetestTRLinkIntegrationConnection endpoint after connecting to verify that the credentials are valid and the integration is functioning properly.
Endpoint:
customerIntegrationId(string, UUID) - The legal entity integration ID
Get a Legal Entity Integration
Retrieves detailed information about a specific legal entity integration, including its connection status, associated partner details, and legal entity information. The response includes partially censored API credentials for security. This endpoint is useful for displaying integration details in administrative interfaces or verifying integration configuration before performing travel rule operations. Both the legal entity ID and integration ID are required as path parameters for additional security validation. Endpoint:customerId(string, UUID) - The legal entity IDcustomerIntegrationId(string, UUID) - The legal entity integration ID
Get Legal Entity Integrations
Retrieves all TRP integrations configured for a specific legal entity. This endpoint returns a complete list of TRP connections, including their status, partner details, and configuration. Use this to display all available TRP connections for a legal entity or to select which integration to use for a specific transaction. Legal entities may have multiple integrations to support different compliance networks or redundant provider setups. Endpoint:customerId(string, UUID) - The legal entity ID
Disconnect a Legal Entity Integration
Disconnects and permanently removes a legal entity’s integration with a TRP. This endpoint deletes the stored API credentials and removes the integration record. After disconnection, the integration can not be used for travel rule operations. Any pending TRMs may fail or become inaccessible. This is typically used when migrating to a different TRP, cleaning up unused integrations, or when API credentials are compromised and need to be fully removed before reconnecting with new credentials. Endpoint:customerIntegrationId(string, UUID) - The legal entity integration ID
Test Connection
Validates that a legal entity integration can successfully communicate with the TRP’s API. This endpoint makes a test call to the TRP using the stored API credentials to verify authentication and connectivity. It returns a success indicator along with any error messages if the connection fails. This is essential after connecting or updating integration credentials to ensure the setup is correct before attempting actual travel rule operations. Regular connection testing can also be used to monitor integration health. Endpoint:customerIntegrationId(string, UUID) - The legal entity integration ID
Travel Rule Operations
Travel rule operations manage the core compliance workflows for creating, managing, and tracking TRMs. These endpoints assess whether transactions require travel rule compliance based on thresholds and counterparty VASP identification, create and transmit TRMs containing encrypted IVMS101 customer data, and manage TRM lifecycle states, including cancellation and redirection. The operations support both outbound transactions (where you create the TRM before the blockchain transaction) and inbound transactions (where you create the TRM after receiving funds and reference an existing Fireblocks transaction).Assess a Travel Rule Requirement
Determines whether a specific transaction requires travel rule compliance based on regulatory thresholds, transaction amounts, and counterparty VASP identification. This endpoint evaluates the transaction against the partner’s configured travel rule policies and jurisdictional requirements. It returns a decision of"REQUIRED", "NOT_REQUIRED", or "NEED_MORE_INFO" along with an explanation.
When required, it also provides a list of mandatory IVMS101 fields that must be populated in the TRM. Use this endpoint before creating a TRM to verify compliance requirements and understand what legal entity data needs to be collected. For outbound transactions, provide transaction details explicitly. For inbound transactions, you can reference an existing Fireblocks txId to auto-populate transaction data.
Endpoint:
customerIntegrationId(string, UUID) - The legal entity integration ID
Create a TRM
Creates and submits a new TRM to the partner TRP containing IVMS101-compliant legal entity data for a cryptocurrency transaction. The TRM includes encrypted originator and beneficiary information, transaction details, and wallet addresses. For outbound transactions, create the TRM before executing the blockchain transaction to ensure compliance is in place before funds move. For inbound transactions, create the TRM after receiving the transaction and reference the existing FireblockstxId.
The IVMS data must be encrypted using the partner’s public key (retrieved via the getPublicKey endpoint). The endpoint returns a TRM ID that can be used to track the message status and should be associated with the Fireblocks transaction using the set transaction travel rule message ID endpoint.
Endpoint:
customerIntegrationId(string, UUID) - The legal entity integration ID
Get a TRM
Retrieves the current state and details of a specific TRM from the TRP. This endpoint fetches real-time information directly from the partner’s API, including the message status (PENDING, ACCEPTED, REJECTED), encrypted IVMS data, transaction details, and any status reasons. Use this to monitor TRM progress, check for counterparty acceptance, or retrieve message details for audit purposes. The response includes both the original submitted data and any updated fields from the partner network.
Endpoint:
customerIntegrationId(string, UUID) - The legal entity integration IDtrmId(string) - The TRM message ID
Cancel a TRM
Cancels a previously submitted TRM and notifies the counterparty VASP of the cancellation. This endpoint should be used when a transaction is aborted, reversed, or when incorrect information was submitted and needs to be resent. The cancellation reason is transmitted to the counterparty to explain why the TRM is being cancelled. Once cancelled, the TRM cannot be reused, and a new TRM must be created if the transaction proceeds. This returns an asynchronous 202 status as the cancellation is communicated through the TRP network. Endpoint:customerIntegrationId(string, UUID) - The legal entity integration IDtrmId(string) - The TRM message ID
Redirect a TRM
Redirects an existing TRM to a subsidiary or nested VASP within a parent VASP’s organization. This functionality is used in nested VASP scenarios where a parent VASP operates multiple subsidiary entities and needs to route the TRM to the specific subsidiary managing the legal entity relationship. The partner must support nested VASP capabilities for this endpoint to function. The TRM is redirected with its existing data to the specifiedsubsidiaryVaspId. This returns an asynchronous 202 status as the redirection is processed through the TRP network.
Endpoint:
customerIntegrationId(string, UUID) - The legal entity integration IDtrmId(string) - The TRM message ID
Get Required Actions
Retrieves the list of actions required to process a TRM that is inPENDING status. A TRM may enter PENDING when additional information is needed — for example, missing beneficiary PII data or a manual compliance review. This endpoint returns one or more required actions, each with a type, description, and action-specific data such as the list of required IVMS101 fields.
Use this endpoint after receiving a TRLink.RequiredActions webhook notification, or poll it to check the current state of a PENDING TRM. The same endpoint serves both automated systems and manual review workflows.
Endpoint:
customerIntegrationId(string, UUID) - The legal entity integration IDtrmId(string) - The TRM message ID
| Action Type | Description | Required Data |
|---|---|---|
UPLOAD_BENEFICIARY_PII | Client must provide beneficiary PII in encrypted IVMS101 format | data.beneficiaryPii.ivms101 via Resolve Action |
MANUAL_REVIEW | Requires manual compliance review at the TRP | Varies (may be empty) |
Resolve Action
Resolves a single required action on a PENDING TRM by submitting the requested data. For example, when the required action isUPLOAD_BENEFICIARY_PII, this endpoint accepts encrypted IVMS101 data containing the beneficiary’s personally identifiable information.
The TRP processes the action synchronously and returns the updated TRM. If the action resolves the last pending requirement, the TRM status will change from PENDING to the next state (e.g., ACCEPTED). If multiple actions are required, call this endpoint once for each action — it resolves one action at a time.
After resolving an action, call getRequiredActions to check if additional actions remain.
Endpoint:
customerIntegrationId(string, UUID) - The legal entity integration IDtrmId(string) - The TRM message ID
The TRP also pushes the updated TRM via webhook to Fireblocks after processing. The synchronous response lets you see the immediate result, while the webhook ensures the screening pipeline is updated.
Webhook: TRLink.RequiredActions
When a TRM enters PENDING status with required actions, Fireblocks sends a compliance webhook notification to the client. Event ID:Screening_TRLinkRequiredActions
Payload:
- Optionally call
getRequiredActionsto refresh the current state - Collect the required data (e.g., encrypt beneficiary PII)
- Call
resolveActionfor each required action
TRM Operations
TRM operations manage the association between Fireblocks transactions and TRMs created with partner TRPs. These endpoints link TRM identifiers to transactions and specific destinations, enabling tracking and audit trails that connect blockchain transactions to their compliance data. The operations support both transaction-level linking (for simple single-destination transactions) and destination-level linking (for multi-destination transactions where each output may have its own TRM). These associations are critical for maintaining compliance records and enabling automated monitoring of transaction vs. TRM status.Set Transaction TRM ID
Associates a TRM ID with a Fireblocks transaction. This creates a link between the TRM and the transaction record, enabling compliance tracking and audit trails. For single-destination transactions, this single association is typically sufficient. The endpoint accepts the TRM ID as a string or null to clear an existing association. This should be called after creating a TRM to establish the compliance record link. The association enables the Fireblocks platform to display TRM status alongside transaction details and enforce any configured compliance policies. Endpoint:txId(string, UUID) - The Fireblocks transaction ID
Set Destination TRM ID
Associates a TRM ID with specific destinations in a multi-destination Fireblocks transaction. This endpoint supports two matching methods:- Direct lookup (recommended): Use the
destinationScreeningIdfrom a webhook notification (TRLink.NoTRMessageorTRLink.RequiredActions) for a direct, reliable match. - Attribute matching (legacy): Match destinations by amount and destination criteria (type, address).
txId(string, UUID) - The Fireblocks transaction ID
destinationScreeningId is provided, amount and destination are not required. The destinationScreeningId is a unique identifier for the destination screening record, available in webhook notifications.
Response (200):
Manual Decision for Missing TRM
Allows clients to manually ACCEPT or REJECT a transaction when its destinations are waiting for a Travel Rule Message (Missing TRM state), instead of waiting for the automatic policy timeout or TRM arrival. This is useful when clients have internal compliance data (KYC status, risk scores) that allows them to make an immediate decision. The decision applies to all destinations currently in Missing TRM state for the given transaction. Destinations in other states (Screen, Postscreen, Completed) are not affected and will be skipped. If no destinations are in Missing TRM state, the endpoint returns a 400 error. Manual decisions are recorded withsource: "manual" in the screening result, distinguishing them from automatic policy-based decisions.
Endpoint:
customerIntegrationId(string, UUID) - The legal entity integration IDtxId(string, UUID) - The Fireblocks transaction ID
- If the same action is sent again for a destination already carrying that decision, the destination is skipped (idempotent).
- A different action overwrites the previous decision (last call wins).
- Once a destination has moved past the Missing TRM state, the decision cannot be changed.
Get a Public Key for PII Encryption
Note:This endpoint applies to Sumsub integrations. GTR integrations configure public keys in GTR Dashboard. See the GTR Encryption section for details.
kid), and the public key components (modulus and exponent) needed for encryption operations.
Endpoint:
customerIntegrationId(string, UUID) - The legal entity integration ID
VASP Operations
VASP (Virtual Asset Service Provider) operations provide access to the partner’s VASP directory to discover and identify counterparties in TRM exchanges. These endpoints query the TRP’s address book of registered VASPs, retrieving information about VASP identities, geographic locations, national identifiers, and public keys. This information is essential for determining whether a destination address requires travel rule compliance, obtaining VASP IDs for TRM creation, and validating counterparty information before sending TRMs.List VASPs
Retrieves a paginated list of Virtual Asset Service Providers (VASPs) registered in the partner’s network. This endpoint returns the partner’s VASP directory containing all counterparties available for TRM exchanges. Each VASP entry includes identification details, legal names, national identifiers, and geographic addresses. Use pagination parameters to handle large VASP directories. This is useful for building VASP selection interfaces, implementing VASP search functionality, or syncing the partner’s VASP directory to local storage for offline access. Thelimit parameter accepts values from 1 to 1000 VASPs per request.
Endpoint:
customerIntegrationId(string, UUID) - The legal entity integration ID
Get VASP by ID
Retrieves complete detailed information about a specific VASP by its unique identifier. This endpoint returns more comprehensive data than the list endpoint, including the VASP’s public key if available. The TRP uses the public key for encrypted communication with that VASP. Use this endpoint when you have a VASP ID (e.g., from VASP attribution or address ownership verification) and need to retrieve full details about the counterparty, verify their identity information, or obtain their public key for secure messaging. This is particularly useful before creating TRMs to verify counterparty details. Endpoint:customerIntegrationId(string, UUID) - The legal entity integration IDvaspId(string) - The VASP ID
Asset Operations
Asset operations provide access to the partner’s supported cryptocurrency asset catalog and enable verification of asset support for travel rule compliance. These endpoints allow you to discover which blockchain assets and tokens are supported by a specific TRP, retrieve detailed asset information, including naming conventions and network identifiers, and determine whether the partner can handle assets not explicitly listed. This information is critical for validating transaction asset compatibility before creating TRMs and understanding the partner’s asset support capabilities.List Supported Assets
Retrieves a paginated list of cryptocurrency assets supported by a specific customer integration’s TRP. This endpoint returns the partner’s asset catalog containing asset identifiers, names, blockchain networks, and other metadata needed for travel rule messaging. Each asset entry is normalized to the Fireblocks asset format for consistency. The response includes apartnerCanHandleAnyAsset flag that indicates whether the partner can process TRMs for assets not explicitly listed in their catalog. Use pagination parameters to handle large asset catalogs. This is useful for validating asset support before creating TRMs, building asset selection interfaces, or syncing the partner’s asset catalog for reference.
Endpoint:
customerIntegrationId(string, UUID) - The legal entity integration ID
Get a Supported Asset
Retrieves detailed information about a specific cryptocurrency asset’s support status and metadata from the TRP. This endpoint validates whether a partner supports a particular asset and returns comprehensive asset details, including the Fireblocks-normalized asset data, the raw partner response, and a support status indicator. Thesupported field will be true if either the asset is explicitly listed in the partner’s catalog, or if the partner can handle any asset (partnerCanHandleAnyAsset=true). Use this endpoint before creating TRMs to verify that the transaction’s asset is supported, retrieve the correct asset identifiers and formats required by the partner, or understand asset-specific requirements for compliance messaging.
Endpoint:
customerIntegrationId(string, UUID) - The legal entity integration IDassetId(string) - The Fireblocks asset ID (e.g., “ETH”, “BTC”, “USDC_ETH”)
Partner Operations
Partner operations provide access to the catalog of available TRP partners that can be integrated with legal entities. Partners represent different TRP networks, such as Sumsub, each offering varying capabilities, geographic coverage, and supported jurisdictions. These endpoints help discover available partners and their characteristics, enabling informed decisions about which TRP to integrate for specific compliance requirements.Get All Partners
Retrieves the complete catalog of TRP partners available for integration. Each partner entry includes identifying information (ident, name), a description of their services and network coverage, their API base URL, active status, and whether they’re in test or production mode.
Use this endpoint during initial setup to discover available TRPs, present partner selection options to administrators, or filter partners based on environment (test vs. production). The isTest field helps distinguish between sandbox/testing partners and production-ready partners. Only active partners should be used for new integrations.
Endpoint:
Error Responses
All endpoints may return the following error responses:400 Bad Request
401 Unauthorized
Returned when JWT authentication fails or API key is invalid.404 Not Found
Returned when a requested resource (customer, integration, TRM, VASP) is not found.500 Internal Server Error
Transaction Submission
Submit transactions for TRSupport screening using the standard Fireblocks transaction API:Multi-Destination Transactions
For transactions with multiple destinations:Result Data Structure
TRSupport Result Object
TRSupport returns comprehensive screening results:Per-Destination Results
For multi-destination transactions:Policy Configuration
Screening Policy Rules
Configure which transactions require screening:Missing TRM Policy Rules
Configure timeout behaviors:Post-screening Policy Rules
Configure responses to screening results:Implementation Patterns
Pattern 1: Basic Integration
Pattern 2: Multi-Destination Handling
Pattern 3: Monitoring Integration
Testing and Validation
Test Scenarios
Policy Bypass Testing
Threshold Testing
Multi-Destination Testing
Using Test Networks
Test with testnet assets:BTC_TESTETH_TEST5XRP_TEST
Error Handling
Common Error Scenarios
Performance Considerations
Processing Times
- Policy Bypass: < 1 second
- Standard Screening: 2-10 seconds
- Multi-Destination: 30+ seconds
- Extended Wait: Hours to days (configurable)
Optimization Tips
- Use Bypass Rules: Configure
PASSactions for clear exemptions - Optimize Rule Order: Most specific rules first
- Limit Complex Matching: Minimize multi-field rules
- Cache Policy Results: Store bypass decisions when applicable
Support Resources
- API Documentation: Full API reference at docs.fireblocks.com
- Policy Examples: See Help Centre articles for configuration examples
- Technical Support: Contact support@fireblocks.com
- Customer Success: Reach out to your Customer Success Manager
Appendix: Status Codes and Enums
TRSupport Verdicts
ACCEPT: Transaction approvedREJECT: Transaction blockedALERT: Approved with monitoringWAIT: Awaiting additional data
Processing Statuses
completed: Final verdict reachedpending: Still processingbypassed: Policy bypass appliedfailed: Technical failure
TRM Statuses
ACCEPTED: Provider approvedREJECTED: Provider blockedPENDING: Awaiting provider responseFAILED: Provider technical issue