Overview

Travel Rule Support (TRSupport) uses three policy stages (Screening, Missing TRM, and Post-screening) to control transaction compliance processing. Each stage evaluates transactions based on your configured rules, with the first-match principle determining the action. 

Applying TRSupport policies 

1. Fill out the relevant policy template following the instructions:

• Travel Rule Support - Screening Policy Template

• Travel Rule Support - Missing TRM Policy Template

• Travel Rule Support - Post-Screening Policy Template

2. Submit a support ticket with your completed template attached.
3. Our Support team will apply the policy and reach out if they have questions.

Stage 1: Screening policy configuration

This policy determines which transactions must be screened for Travel Rule compliance. Configure your screening rules based on the parameters below.

Customer context

• customerId: Target specific legal entities

Transaction details

• direction: Inbound or outbound
• asset: Specific cryptocurrencies (BTC, ETH, etc.)
• amount: Native currency ranges (min/max)
• amountUSD: USD equivalent ranges (min/max)

Source information

• sourceType: Vault account, exchange account, etc.
• sourceSubType: Specific source details
• sourceAddress: Blockchain addresses
• sourceId: Source identifiers

Destination information

• destType: Vault, unmanaged wallet, etc.
• destSubType: Specific destination details
• destAddress: Blockchain addresses
• destId: Destination identifiers

Actions

• SCREEN: Proceed with Travel Rule screening
• PASS: Bypass screening (immediate approval)

Example rules:

Rule 1: Internal transfers → PASS
Rule 2: Amounts below $3,000 → PASS
Rule 3: High-risk addresses → SCREEN
Rule 4: All others → SCREEN

Stage 2: Missing TRM policy configuration

This policy controls how transactions are handled when travel rule messages (TRM) are unavailable. Configure your rules using these matching conditions:

Additional timing controls

• validAfter: Rule applies after X seconds have passed
• validUntil: Rule applies until Y seconds have passed

Actions

• WAIT: Continue waiting for TRM (respects system timeouts)
• ACCEPT: Proceed without TRM
• REJECT: Block transaction

Example progressive timeout:

Rule 1: First 30 minutes → WAIT
Rule 2: After 30 minutes, amounts < $10,000 → ACCEPT
Rule 3: After 30 minutes, amounts ≥ $10,000 → REJECT

Stage 3: Post-screening policy configuration

This policy determines the final action for each transaction based on the results returned from your Travel Rule provider. Configure your rules using these matching conditions:

Additional criteria

• trmStatus: ACCEPTED, REJECTED, PENDING, or FAILED
• providerIdent: Specific provider identifier
• validAfter/validUntil: Timing constraints

Actions

• ACCEPT: Approve transaction
• REJECT: Block permanently
• ALERT: Approve with monitoring
• WAIT: Continue monitoring (PENDING only)

Example rules:

Rule 1: ACCEPTED status → ACCEPT
Rule 2: REJECTED + outbound → REJECT
Rule 3: PENDING + under 2 hours → WAIT
Rule 4: FAILED status → ACCEPT (business continuity)

System timeouts

Fireblocks enforces non-configurable timeout limits to prevent transactions from remaining in a pending state indefinitely. 

• Outbound: 1.5 hours maximum
• Inbound: 7 days maximum

When limits approach, the WAIT action automatically skips to ensure completion.