Introduction

AML is the module that allows each instance to configure and operate its own AML controls. With this module, an instance can connect its AML provider, define its risk assessment policy, configure notification recipients, maintain a Bypass List, and review AML assessment results.


Supported AML provider:

  • Elliptic

  • Chainalysis

How it works

Overview

The AML engine uses the instance’s current AML Screening configuration to perform risk assessments. This means screening behavior always depends on the combination of:

  • whether AML Screening is enabled or disabled 

  • the selected provider; and
  • the risk profile configured for the instance.


When AML Screening is enabled (active), the system uses the selected provider and the configured risk profile to classify events as Risky or Not Risky. The engine operates across two main evaluation flows:

  • Inbound: incoming transactions, such as deposits

  • Outbound: destination address checks for outgoing transfers


Inbound flow

When an inbound deposit is classified as risky, the system:

  • sends the corresponding e-mail notification (Risky Inbound Transaction Detected)

  • checks whether the source address is registered in the Bypass List

If the address is in the Bypass List, the flow ends there.

If the address is not in the Bypass List, the system:

  • blocks the destination wallet/address that received the deposit and sends the corresponding e-mail notification (Blocked Wallet);

  • blocks the end user, if the wallet is associated with a CaaS Manager end user, and sends the corresponding e-mail notification (Blocked End-user).


Outbound flow

For outbound transfers, there are two possible outcomes.

When the destination address is classified as risky, the system:

  • sends the corresponding e-mail notification (Risky Destination Address Detected)

  • checks whether the destination address is in the Bypass List

If the address is in the Bypass List, the transfer may proceed.

If the address is not in the Bypass List, the system:

  • cancels the transfer

  • when the destination address is an internal Parfin wallet belonging to the instance → blocks the address and sends the corresponding e-mail notification (Blocked Wallet)

  • when the destination is a whitelisted address belonging to the instance → blocks the whitelisted address and sends the corresponding e-mail notification (Blocked Whitelisted Address).


Exception cases

Not every evaluation ends as risky or not risky: the provider may respond with a failure (ERROR) or the Parfin Platform may stop waiting for the response within the configured time (TIME_OUT). In these cases the behavior differs by flow:

  • Inbound: the deposit is credited normally, without blocking the destination wallet or the end user. The result is recorded as ERROR or TIME_OUT.
  • Outbound: the transfer is canceled. The result is recorded as ERROR or TIME_OUT.

The difference between the two results is only the underlying reason: with ERROR the provider responded with a failure; with TIME_OUT the Parfin Platform stopped waiting. The transaction is handled identically in both cases.


Where AML evaluations are applied

The AML engine runs in the following scenarios:

Inbound

  • deposits received in Parfin wallets

  • deposits received in monitored external wallets

Outbound

  • transfers originating from Parfin wallets


Functional structure of the AML module

The AML module is located under the Compliance menu and is composed of five main elements:

  • Provider Connection

  • AML Screening Settings

  • Bypass List

  • Notification Recipients

  • AML Screening Report

Provider Connection

The Providers tab contains the AML provider accounts connected to the instance. Multiple accounts can be connected at the same time, but only one can be used for AML evaluations.


Connecting a provider does not activate AML automatically. A provider connection only makes that provider available for selection in AML Screening. For AML to start monitoring the instance, there must be an active configuration with:

  • a selected provider

  • a valid risk profile

When removing a connected provider account, the following restrictions apply:

  • the connection cannot be in use by AML Screening

  • the connection cannot be associated with a pending AML Screening change request


AML Screening Settings

AML Screening settings defines how the instance applies risk assessment across its AML flows. In this section, the instance selects the provider, defines the risk profile, and enables or disables monitoring.

  • When AML Screening is active, the system uses the instance’s current configuration to perform risk assessments.
  • When AML Screening is inactive, the system does not perform AML evaluations for that instance.

Risk Profile

The risk profile is the rule the AML engine uses to determine whether a given evaluation should be considered risky. Each AML provider has its own risk assessment parameters, so the definition of the risk profile depends on the selected provider.

  • Elliptic risk score
    • Elliptic uses a score from 0 to 10.
    • In this case, the risk profile configured in the AML engine represents the threshold from which an evaluation should be considered risky. Transactions and addresses with a risk score equal to or greater than the value configured in AML Screening are classified as Risky. Values below that threshold are classified as Not Risky.
  • Chainalysis alerts by severity
    • Chainalysis does not use a numeric score, but rather alerts by severity. The risk profile is defined through a cumulative selector for the minimum alert level that makes an evaluation risky:
      • Severe — only severe alerts;
      • High — severe and high alerts;
      • Medium — severe, high, and medium alerts;
      • Low — any alert.
    • The evaluation considers only direct exposure (direct) alerts; indirect exposures are disregarded. When there are multiple alerts, the most severe one prevails.


Switching the selected provider (Elliptic ↔ Chainalysis) discards the previous risk profile, since each provider has its own assessment model.


All changes made in the AML Screening section go through an approval flow defined by the Compliance Controls governance rule, available in Governance > General Policies, before they take effect. This includes:

  • enabling or disabling AML Screening

  • selecting or changing the AML provider

  • defining or changing the risk profile


Bypass List

The Bypass List defines controlled exceptions for addresses that, even when classified as risky by the AML provider, should not trigger the automatic actions normally expected for that flow, such as wallet blocking or user blocking.


The bypass does not remove screening. It only changes the consequence applied when the AML result is Risky.


The list can be used in two contexts:

  • Inbound flows: to register source addresses for deposits

  • Outbound flows: to register destination addresses for outgoing transfers

Each Bypass List entry contains:

  • Address – the address itself

  • Network – the blockchain/network

  • Direction – defines in which flows the address should be considered:

    • Origin – treats the registered address as a deposit source address

    • Destination – treats the registered address as a withdrawal destination address

    • Both – treats the registered address as both source and destination

  • Reason – free-text field used to document the rationale and approval context

  • Expiration Date – the date after which the bypass automatically stops taking effect


Any new address added to the Bypass List must go through the approval flow defined by the Compliance Controls governance rule in Governance > General Policies.


Notification Recipients

The Notification Recipients section allows the instance to define which email addresses should receive AML-related alerts.

If no recipients are configured, the actions still take place in the system, but no email notifications are sent.


At the moment, the instance manages the list of recipients, but the event types are fixed. Configured recipients are notified whenever:

  • an identified deposit is classified as risky – Risky Inbound Transaction

  • a withdrawal destination address is classified as risky – Risky Destination Address

  • wallets or whitelisted addresses are blocked – Blocked Wallet / Blocked Whitelist Address

  • an end user registered in CaaS Manager is blocked due to an associated wallet block – Blocked End-user

  • the AML Screening status changes – AML Enabled / Disabled


Configuration changes and approval flows

Some AML module changes must go through governance before they take effect. While a change request is still pending approval, the current configuration remains in force.


The applicable approval flow is defined by the Compliance Controls governance rule in Governance > General Policies. Whenever there is a pending change request, the AML page continues to display the current active configuration and shows a pending approval banner with a Review Changes action.


Below is a summary of which actions require governance and when they are applied:

ActionRequires Approval FlowApplication
Add a new AML providerNoImmediate
Select or change the AML provider in AML ScreeningYesAfter approval
Change the risk profile in AML Screening YesAfter approval
Enable or disable AML ScreeningYesAfter approval
Add an address to the Bypass ListYesAfter approval
Remove an address from the Bypass ListNoImmediate
Add or remove a Notification RecipientNoImmediate


Additional provider-specific considerations

Elliptic

Although Elliptic returns a risk score for evaluations performed on its platform, in some cases it may return other responses that may look like errors at first glance, but are not treated that way by the Platform.


Below is how the Platform AML engine maps and interprets those scenarios:

  • Null or 404 Error – usually indicates the address has no history in the provider’s database.
    Platform mapping: NOT_RISKY.

  • 400, 401, 403, 500, or any other unexpected Elliptic error
    Platform mapping: ERROR.


Chainalysis

Chainalysis responds with alerts by severity and exposure. The Platform AML engine maps each scenario as follows:

  • The provider responded with an error: ERROR.
  • The Platform received no response from the provider within the 30-second waiting time: TIME_OUT.
  • No alerts, or only indirect-exposure alerts: NOT_RISKY.
  • There is a direct-exposure alert with severity equal to or greater than the configured level: RISKY (which may become RISKY_BYPASS if covered by the Bypass List).


Step by step

1. Access AML Self-Service

  1. In the instance menu, click Compliance.

  2. The page opens with the Providers and AML tabs.

  3. Use the Providers tab to manage AML provider connections.

  4. Use the AML tab to configure screening, bypass, and notifications.

 


2. Connect an AML provider

  1. Go to Compliance → Providers.

  2. Click + Provider.

  3. Fill in the following fields:

    • Provider

    • Alias

    • Credentials (for Elliptic: API Key and API Secret; for Chainalysis: API Token)

    • 2FA

  4. Confirm the action.

  5. The system validates the credentials.

  6. Once created successfully, the connection becomes available for selection in AML Screening.


 

3. Configure AML Screening

  1. Go to Compliance → AML.

  2. Click Edit.

  3. Select a connected provider.

  4. Define the Risk Profile.

  5. Adjust the AML Screening status according to the instance policy.

  6. Click Save Changes and confirm with 2FA.

The change request is then created and remains pending approval.

Changes only take effect after the request is approved through the governance flow.

If the request is rejected, canceled, or expires, the previous active configuration remains in effect.


 

Whenever a change request is pending approval, a banner is displayed at the top of the page.

 

4. Manage the Bypass List

  1. Go to Compliance → AML.

  2. Click Edit.

  3. Go to the Bypass List section.

To add a new entry:

  1. Click + Add Address.

  2. Provide:

    • Address

    • Network

    • Direction

    • Reason (optional)

    • Expiration Date

To remove an existing address:

  1. Click the trash icon.

  2. Confirm the deletion.

Then:

  1. Save the changes.

  2. Confirm with 2FA.

New addresses follow the instance’s governance flow and only take effect after approval.

Address removals are applied immediately after confirmation.
 

Whenever a Bypass List change request is pending approval, a banner is displayed at the top of the page.


5. Configure Notification Recipients

  1. Go to Compliance → AML.

  2. Click Edit.

  3. Go to the Notification Recipients section.

To add new recipients:

  1. Click + Add Recipient.

  2. Enter a valid email address.

To remove existing recipients:

  1. Click the trash icon.

  2. Confirm the deletion.

Then:

  1. Save the changes.

  2. Confirm with 2FA.

The configured recipients will begin receiving AML alerts for that instance.

 

Visibility and reports

AML Screening Report

The AML Screening Report can be exported by the instance and provides the results of the screenings performed, including the AML module result and the provider response for applicable cases.

The report is available under Reports > AML Screening and includes the following information:

  • ID – unique identifier of the evaluation in the Platform

  • Created At – UTC date and time when the evaluation was created

  • Provider – provider used in the evaluation (for example, Elliptic)

  • Provider Response ID – identifier returned by the provider, useful for checking details in the provider’s own platform

  • Screening Type – Automatic for evaluations triggered by the AML engine on inbound and outbound transactions

  • AML Check – consolidated evaluation result:

    • NOT_SUPPORTED – the asset or blockchain is not covered by the selected provider

    • NOT_RISKY – the result is considered not risky

    • RISKY – the result is considered risky

    • RISKY_BYPASS – the result is considered risky, but the address involved is currently covered by an active bypass. No block or cancellation actions are applied

    • ERROR – screening failed due to provider or internal Platform error

    • TIME_OUT – no response from the provider within the configured Provider Response Timeout (currently 30 seconds). No block or cancellation actions are applied

  • Screen Subject – indicates what was sent to the provider for the risk evaluation: Address and/or Transaction Hash

  • Address – address sent to the AML provider when the subject is Address

  • Transaction Hash – transaction hash sent to the AML provider when the subject is Transaction Hash

  • Parfin Transaction ID – identifier of the transaction in the Platform when the evaluation is associated with an instance transaction

  • Provider Response – raw provider response, useful for deeper analysis, audit, and reconciliation


Transaction Details (AML Check)

The AML Screening result associated with a transaction can also be consulted through the API and through webhook-based transaction events.


Transaction details expose the AML Check field, which contains the evaluation result. Possible values include:

  • DISABLED
  • NOT_SUPPORTED
  • RISKY
  • RISKY_BYPASS
  • NOT_RISKY
  • ERROR
  • TIME_OUT


Endpoints that include AML Check information


CaaS Manager End user Funding

When deposit wallets are associated with CaaS Manager endusers, the AML evaluation result for a given deposit made into those wallets can be reviewed. In CaaS Manager > Funding, the AML result is displayed in the AML Result column (in the Pending and Completed tabs and in the Transaction Details modal).


The possible values are displayed as: Disabled, Not supported, Not risky, Risky, Risky bypassed, Error, and Timed out; and "-" when not applicable.


Frequently Asked Questions (FAQ)

What is the AML Module?

It is the Parfin Platform module that allows each instance to configure and operate its own AML setup, including provider connection, screening rules, bypass configuration, notification recipients, and AML result visibility.


Which AML provider is supported?

The supported providers are Elliptic and Chainalysis. 


Does connecting a provider automatically enable AML?

No. Connecting a provider does not change the engine behavior on its own. The provider must be selected, the risk profile must be configured and approved, and AML Screening must be active.


What happens when AML Screening is disabled?

The engine stops running AML evaluations. Transactions continue through the normal execution flow without AML checks and are recorded with AML Check = DISABLED. The provider and risk profile settings remain saved, so when AML is re-enabled, the configuration returns to the same setup that existed before it was disabled.


Can an instance operate without Notification Recipients?

Yes. In that case, no AML alert emails are sent.


Can I choose which notification types I want to receive?

No. Recipients are configurable, but the event types sent are fixed.


What happens if an address is in the Bypass List?

Screening still runs. If the result is Risky, the bypass prevents the automatic consequence that would normally apply to that flow, according to the configured direction.


Does adding an address to the Bypass List require approval?

Yes. Adding an address goes through governance. Removing an address is applied immediately and does not require governance.


Where can I see the AML result for a transaction?

You can review it in transaction details through the API, in transaction webhooks/events, and in the AML Screening Report.