--- updatedAt: 2025-09-16T21:51:20.000Z agentTools: projectIndex: https://docs.lmnl.app/v2/llms.txt --- # 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)
Order of priority Protocol Asset Travel Rule Status Outcome Explanation
1. Any ADA Any **Accept** All the outgoing transactions for ADA are accepted irrespective of the Travel Rule status.
2. Ethereum Any Accept, Ack, Saved, Sent **Accept** The transaction is accepted for Ethereum if the Travel Rule status is any one of the following: * Accept * Ack * Saved * Sent
3. Any Any Rejected, Declined **Reject** The transaction is rejected because either the Travel Rule returned “Rejected” or the transaction is declined by the beneficiary VASP.
4. Any Any Not Available **Reject** The transaction is rejected because the Travel Rule status is “Not Available”. Note that all the ADA transactions will still be accepted due to rule number 1.
5. Any Any Any **Reject** "Reject" is the rule for outgoing transactions when a transaction doesn't match any rules.
### Receive rules (for incoming transactions) | Order of priority | Protocol | Asset | Travel Rule Status | Outcome | Explanation | | :---------------- | :------- | :---- | :----------------- | :--------- | :------------------------------------------------------------------------------------------------- | | 1. | Any | ADA | Any | **Accept** | The incoming transactions are accepted for ADA, BTC, and ETH. | | 2. | Any | Any | Decline, Reject | **Reject** | The transaction risk score is severe, so the transaction is rejected. | | 3. | Any | Any | Any | **Accept** | “Accept” is the outcome for all incoming transactions when a transactions doesn't match any rules. |