Liminal Firewall is a set of policies which work together to keep your crypto transactions secure and compliant with judicial regulations. You can define rules, investigate risky transactions, and approve transactions. Firewall has integrated with Notabene and TRM Labs for compliance and monitoring. You can also 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.

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.

Similarly, Firewall can have other final outcomes based on the individual policy outcomes. A few examples are given as follows: