Liminal Firewall is a set of policies which work together to keep your transactions secure and compliant with judicial regulations. You can define rules and investigate risky transactions. Based on the configured rules for transactions, Firewall will accept, reject, or require approvals from the signing team. Firewall has integrated with Notabene and TRM Labs, the third-party providers for Travel Rule and Transaction Risk policies, respectively. These providers offer transaction compliance and monitoring. The Transfers policy is a built-in policy that doesn't require integration with any third-party providers.

Additionally, you can customise your workflow with webhooks for timely updates on transactions.

Transaction lifecycle

Liminal Firewall screens all outgoing (send) and incoming (receive) transactions. After an outgoing transaction is initiated, Liminal Firewall performs all necessary checks before sending it for signing and then broadcasting.

Note: Liminal currently doesn’t support the incoming transactions (receive) workflow, however, it is in the process to be released soon.

The following flowchart illustrates the outgoing transactions flow through Liminal Firewall.

Firewall policy and rules

Liminal Firewall consists of several policies. A transaction is evaluated against all policies concurrently, each resulting in a single outcome. Liminal Firewall currently supports the following policies:

• Travel Rule policy
• Transaction Risk policy
• Transfers policy

The following policies are in the pipeline for release:

• Transaction Anomaly policy
• User Accounts policy

A policy contains several rules. A rule contains various parameters, such as protocols and assets. The parameters in a rule are matched against a transaction's parameters. Rules are evaluated from top to bottom, which means if a transaction matches the topmost rule in a policy, it will exit the policy with the outcome, without comparing with the other rules. If the transaction doesn’t match a rule, it will be matched against the next rule in the order. The rules can result in any one of the following three outcomes:

• Accept - The transaction is accepted to go through and proceed to the signing phase.
• Reject - The transaction is rejected. This will trigger the following actions:
  • Cancels the outgoing transaction.
  • Quarantines the incoming transaction.
• Approval - The transaction requires additional approvals from the designated compliance team based on the outcome. The transaction requires the configured number of minimum approvals from the compliance team. For example, “1 of X team”, which means that one approval is required from the compliance team named X.

Examples

A few examples of the policy outcomes and the final outcome by Firewall are the following:

Travel Rule policy outcome

The following table shows that, if the Travel Rule status is “Accepted” for the specified parameters, then the outcome will be “Accepted” for a transaction.

To learn about Travel Rule policy, see Travel Rule policy .

Transaction Risk policy outcome

The following table shows that, if the risk score is “High or Medium” for the specified parameters, then the outcome will be “Approval, 1 of X team” for a transaction.

To learn about Transaction Risk policy, see Transaction Risk policy.

Transfers policy outcome

The following table shows that, a transaction from a warm MPC wallet into a whitelisted address with any protocol and asset type, with the amount above $100,000, will require two final approvals from team A. If the amount is lower than this amount, the transaction will move to the next rule that matches it.

To learn about Transaction Risk policy, see Transfers policy.

Firewall outcome

Firewall combines all the policy outcomes and generates a final outcome. The most restrictive outcome is the final outcome, as illustrated in the following table.