GTR

​

What you can do through the API

​

Step 1: Set up the Fireblocks SDK

• You have a GTR account with a valid subscription, an API key and secret, and your VASP’s public key configured in the GTR Dashboard. See GTR’s Fireblocks integration guide.
• Fireblocks Support has enabled GTR on your workspace.
• You have generated an ED25519 key pair and configured its public key in GTR. You decrypt the data you receive with the private key.

​

Step 2: Connect GTR

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.

2. Create the integration with the legal entity’s customerId and GTR’s partnerIdent from the partner list. The response returns a customerIntegrationId, used in every call after this.
3. Connect the integration with your GTR API key and secret. Fireblocks stores the credentials and returns them censored in later responses.
4. Test the connection. success: true confirms the integration can reach GTR.

​

Step 3: Set up the policy

• 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

// Trigger (Screening Policy): which transactions require screening
interface PreScreeningRule {
  // Matching criteria
  customerId?: string;
  direction?: "inbound" | "outbound";
  asset?: string;
  amount?: {
    range?: {
      min?: number;
      max?: number;
    };
    currency: "USD" | "NATIVE";
  };
  sourceType?: string;
  destType?: string;

  // Required action
  action: "SCREEN" | "PASS";
}

// Missing Travel Rule Message: what to do while no message exists
interface MissingTRMRule {
  // Matching criteria: same as the Trigger, plus timing constraints
  validBefore?: number; // seconds
  validAfter?: number; // seconds

  // Required action
  action: "WAIT" | "ACCEPT" | "REJECT";
}

// Outcome (Post-Screening Policy): how to respond to the screening result
interface PostScreeningRule {
  // Matching criteria: same as the Trigger, plus the message status
  trmStatus?: "ACCEPTED" | "REJECTED" | "PENDING" | "FAILED";

  // Timing constraints
  validBefore?: number;
  validAfter?: number;

  // Required action
  action: "ACCEPT" | "REJECT" | "ALERT" | "WAIT";
}

// Wait, then accept (default behavior)
const waitThenAccept = [
  { action: "WAIT", validBefore: 3600 }, // hold up to 1 hour
  { action: "ACCEPT" }, // then accept
];

// Accept immediately (no hold)
const acceptImmediately = [{ action: "ACCEPT" }];

// Block on fallthrough instead of accepting
const waitThenReject = [
  { action: "WAIT", validBefore: 3600 },
  { action: "REJECT" },
];

const postScreening = [{ action: "ACCEPT" }]; // PENDING: accept
const missingTrm = [{ action: "ACCEPT" }]; // no message: accept

​

Step 4: Encrypt the PII

{
  "version": "IVMS101.2020",
  "data": "<encrypted IVMS101 data>",
  "filledFields": [
    "Originator.originatorPerson[].naturalPerson.name.nameIdentifier[].primaryIdentifier",
    "Beneficiary.beneficiaryPerson[].naturalPerson.name.nameIdentifier[].primaryIdentifier"
  ]
}

​

Step 5: Send an outgoing 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.

const { data: assessment } = await fireblocks.trLink.assessTRLinkTravelRuleRequirement({
  customerIntegrationId,
  tRLinkAssessTravelRuleRequest: {
    amount: "1500",
    assetId: "ETH",
    direction: "OUTBOUND",
    source: { type: "VAULT_ACCOUNT", id: "0" },
    destination: { type: "ONE_TIME_ADDRESS", oneTimeAddress: { address: "0xabcd..." } },
    beneficiaryVaspId: "vasp-456",
  },
});

if (assessment.decision === "REQUIRED") {
  const { data: trm } = await fireblocks.trLink.createTRLinkTrm({
    customerIntegrationId,
    tRLinkCreateTrmRequest: {
      amount: "1500",
      assetId: "ETH",
      direction: "OUTBOUND",
      source: { type: "VAULT_ACCOUNT", id: "0" },
      destination: { type: "ONE_TIME_ADDRESS", oneTimeAddress: { address: "0xabcd..." } },
      beneficiaryVaspId: "vasp-456",
      ivms101: ivms, // encrypted IVMS101 object
    },
  });

  await fireblocks.transactions.createTransaction({
    transactionRequest: {
      assetId: "ETH",
      amount: "1500",
      source: { type: "VAULT_ACCOUNT", id: "0" },
      destination: { type: "ONE_TIME_ADDRESS", oneTimeAddress: { address: "0xabcd..." } },
      travelRuleMessageId: trm.id,
    },
  });
}

​

Step 6: Receive an incoming 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

• 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".

​

Testing and monitoring

​

Troubleshooting

​

Limitations

• Rules are not self-service; Fireblocks Support applies them.
• Combining providers: GTR can run alongside Sumsub 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.

​

On the Help Center