Travel Rule policy

The Travel Rule policy is used to set up rules to approve or reject transactions based on the Travel Rule status. It requires you to integrate with a supported Travel Rule provider. Currently, Liminal Firewall supports Notabene for Travel Rule compliance.

Rule parameters

The Travel Rule policy has the following rule parameters:

• Direction: Specifies whether the rule pertains to inbound or outbound transactions. You get the following options to select from:
  • Send: Indicates that the rule is applicable to outgoing transactions.
  • Receive: Indicates that the rule is applicable to incoming transactions. Note that Liminal currently doesn’t support the incoming transactions (receive) workflow, however, it is in the process to be released soon.
• Protocol: Determines the protocol to which the rule is applied. You get the following options to select from:
  • Any: Indicates that the rule is applicable to all protocols.
  • Select a protocol from the dropdown. You can only select a single protocol.
• Assets: Determines the assets to which the rule is applied. You get the following options to select from:
  • Any: Indicates that the rule is applicable to all assets.
  • Select an asset from the dropdown.
• Travel Rule Status (Notabene): Reflects the status of the Travel Rule message associated with this transaction. The statutes along with their descriptions are as follows:
  • Any: Any given status.
  • Saved: The transaction has been saved but not yet submitted.
  • Missing Beneficiary Data: Essential data for the transaction recipient is incomplete or missing.
  • New: The transaction is newly created and awaiting further action.
  • Waiting For Information: Additional information is required to proceed with the transaction.
  • Sent: The transaction is sent to the recipient or next party. Approval is requested from another party.
  • Rejected: The transaction is rejected due to non-compliance or other issues.
  • Declined: The transaction is not accepted by the recipient or the intended party.
  • ACK: Acknowledged; the transaction is recognised by the receiving party.
  • Canceled: The transaction is canceled and will not be processed.
  • Incomplete: The transaction is not fully processed due to missing components or actions.
  • Accepted: The transaction is accepted and is compliant with all required regulations.
  • Not Ready: The transaction is not ready for processing due to various preparatory reasons.
  • Not Available: Travel Rule is not setup or the API for the Travel Rule transaction has failed due to the missing Travel Rule details in the API request body.
  • Not Available: Travel Rule is not setup or the API for the Travel Rule transaction has failed.
• Outcome: This is the outcome of the rule. The outcomes of a transaction can be any one of the following:
  • Reject: Indicates that the transaction will be halted (or frozen if incoming).
  • Accept: Indicates that the transaction will proceed.
  • Approval: Indicates that the transaction requires approval from the dedicated compliance team. Enter the values in the following fields:
    • Team Name: This is the name of the compliance team that is required to approve a transaction.
    • Min Approval: This is the minimum number of approvals required for a transaction.

To understand rule parameters and outcomes, a few examples of the Travel Rule policy are illustrated in the following table. These examples are just for your reference and not a recommendation.

Send rules (for outgoing transactions)

Receive rules (for incoming transactions)