Non Custodial Wallet DocsDocumentationAPI ReferenceChangelogCommunityStatusRequest Demo

Transaction screening for developers

Suggest Edits

Overview

Transaction Screening provides automated Transaction Monitoring to enable Anti-Money Laundering/Combating the Financing of Terrorism (AML/CFT) and sanctions compliance. It runs in the background of operations with no effort on the user's part, meaning no additional development work is necessary.

Calling Chainalysis APIs

Incoming transactions

  • Fireblocks sends the transaction details to the API transfers/received.
  • Depending on the result, and in accordance with your policies, Fireblocks accepts or freezes the funds (1).

Outgoing transactions

  • Fireblocks sends the transaction details to the API withdrawaladdresses.
  • Depending on the result, and in accordance with your policies, Fireblocks accepts or rejects the transaction (2).
    • When Fireblocks accepts a transaction, we send the transaction details to the API /transfers/sent for registration.

FAQ

Here are some of the most frequently asked questions about transaction screening for developers.

Can I set User IDs in the transaction monitoring service provider? Can I automatically identify users' transactions in Fireblocks and have that information sent to the transaction monitoring service provider?

Yes. If you set a Customer Reference ID, you can automatically associate transactions with specific customers.

Are screening results available via the webhook?

Yes. Screening results are available with the TRANSACTION_STATUS_UPDATED event. For example, a rejected transaction would send a TRANSACTION_STATUS_UPDATED event with data in the following format:

Are screening results available via the REST API?

Yes. Screening results are available with the following API requests:

Can I set automatic rejections and alerts on screened transactions?

Yes. Transactions can be automatically rejected or can trigger an alert according to your AML Post-Screening Policy.

What is an alert?

An alert is when you receive a Webhook notification for the screened transaction. You can configure the notifications you want to receive.

What is a rejection?

  • For an inbound transaction rejection, Fireblocks will freeze the incoming transaction’s funds within the Fireblocks deposit wallet. The wallet will continue to function normally, with the transaction's funds unavailable to spend.
  • For an outbound transaction rejection, Fireblocks will prevent the outbound transaction from being sent. The rejected funds are not frozen as no illicit action took place and the transaction was prevented. You may manually freeze the funds via the Fireblocks API.

When an outbound transaction is rejected, can I still send the transaction?

Yes. By default, Admin-level users can use the Fireblocks Console to bypass the AML policy and send the rejected transaction. However, you can disable this functionality in your workspace using the AML Advanced Configuration settings.

When a transaction's funds are frozen, the transaction's assets are unavailable to spend. Can I unfreeze the transaction?

Yes. By default, Admin-level users can unfreeze a transaction's funds by:

  • Using the Fireblocks Console to unfreeze the funds
  • Using the Unfreeze a transaction API request
  • Contacting Fireblocks Support to release the frozen funds

However, you can disable this functionality in your workspace using the AML Advanced Configuration settings.

Can I freeze a transaction's funds manually?

Yes, Admin-level users can freeze funds using the Freeze a transaction API request.

Are there guidelines for testing rejections & alerts?

Yes. See below for more information about testing rejections and alerts for our AML providers.

Chainalysis

  • To test the outbound rejection functionality, you can create a reject rule on your AML Post-Screening Policy to match transactions identified as high risk by Chainalysis. You can set one of your destination wallet addresses as a custom address in Chainalysis here.
    • When you set your address as a custom address, you will want to set the category to match one of the high-risk categories. You can delete the custom address after testing.
    • Note that this allows you to only test outbound rejections.
  • To test inbound rejection functionality, two more rules can be added to the end of your AML Post-Screening Policy that will reject small dust transactions (less than $.0568 or some other amount) from an identified source, such as a well-known exchange.
    • The first rule will accept all transactions greater than $.0568 or some other amount.
    • The second rule (the last rule) will reject all transactions.
    • These rules can be disabled at your request. Note that only transactions that have an attribution made within the inbound blocking timeout period will be rejected. This means "Unknown" transactions will not be rejected.

Elliptic

  • To test the outbound rejection functionality, you can create a reject rule on your AML Post-Screening Policy to match transactions identified above a 5. Then you can initiate an outgoing transaction to an illicit destination wallet address.
    • As a backup, you can always cancel in the approval stage if the illicit address is unidentified.
    • The risk score for the illicit destination wallet address must match one of the rejection rules in your policy.
    • You can delete the illicit destination wallet address after testing.
    • Note that this allows you to only test outbound rejections.
  • To test inbound rejection functionality, two more rules can be added to the end of your AML Post-Screening Policy that will reject small dust transactions (less than $.0568 or some other amount) from an identified source, such as a well-known exchange.
    • The first rule will accept all transactions greater than $.0568 or some other amount.
    • The second rule (the last rule) will reject all transactions.
    • These rules can be disabled at your request. Note that only transactions that have an attribution made within the inbound blocking timeout period will be rejected. This means "Unknown" transactions will not be rejected.

When are risk scores available for a transaction?

Risk scores and other risk details provided by your transaction monitoring provider are a result of continuous risk monitoring and attributions. The time it takes a provider to analyze the risk and make an attribution varies between providers and depends on the asset, the type of attribution, and the complexity of the analysis.

For a given transaction you could have a risk attribution made in seconds, minutes, days, weeks, or years due to ongoing attributions from your transaction monitoring provider. It's hard to predict when an attribution will be made as there are so many different situations in which attribution can be made after the transaction is registered with your transaction monitoring provider.

However, you can set the blocking timeout period for your workspace to increase the chance of receiving an initial attribution from your transaction monitoring provider.

Updated 5 months ago