Business Flows

This template allows you to use ComplyAdvantage’s Anti-Money Laundering (AML) feature for monitoring Wise transactions to identify and stop potential money laundering or terrorist financing activity. Transaction monitoring is the processing of transactions against a series of rules to look for suspicious or fraudulent activity.

The AML Adaptor process is automatically triggered when a transaction is initiated from Mambu or any other system and its purpose is to map the output payload from the payments connector to the input parameters required by the AML scheme in use, and it can be used to connect to any AML system.

The 1. Payment Receiver Router [linked to payments connector] process is automatically triggered from the AML Adaptor process and its purpose is to decide the transaction type - for example: Inbound or Outbound - and route the payment accordingly. Once the transaction details are read and processed in the Mambu Process Orchestrator (MPO) 2. FinCrime Transaction Analysis [linked to Payment Receiver Router] process, the transaction details are sent to ComplyAdvantage.

The main flows or payments that are monitored from Wise are:

• Prefunded transfers
• Bank transfers

Prefunded transfers and bank transfers

An outbound payment is triggered when either the 4. [EntryPoint] PREFUND Wise transfer flow (1st part) or the 5. [EntryPoint] Payments Gateways Wise transfer flow process is triggered, after a withdrawal transaction is posted in Mambu, and configuration option amlCheck is set to true.

The AML Adaptor process is then triggered, where the payment data object is built. The 1. Payment Receiver Router [linked to payments connector] process is triggered and, after the transaction is posted in ComplyAdvantage, an AML status of Accepted, Rejected, or Suspended is returned. The corresponding manual journal entries are logged in the accounting.

If the payment status is:

• Accepted:
  • The prefunded transfer flow continues with second part by triggering the 4.1. [EntryPoint] PREFUND Wise transfer flow (2nd part) process.
  • The bank transfer flow continues with second part in the AML Listener process. The Extension point to other PAYMENTS GATEWAYS process is also triggered.
• Rejected: A notification is sent, the funds are not returned to the originator while the payment remains under investigation and is active in all systems. The funds are kept in a withhold account.
• Suspended: Once all the alerts have transitioned from In Review to an end state of Accepted or Rejected, webhooks are sent by ComplyAdvantage that automatically trigger the 4. Alerts Analyser Router [linked to CA webhook] process and corresponding manual journal entries are logged in the accounting. The final status of a suspended transaction can only be Accepted or Rejected.

For negative use cases: based on the HTTP status code, the system will determine whether to execute the retry mechanism. If the error is not fixed after the retry mechanism finishes, for example when time stored in the configuration is exceeded, then a notification is sent based on the method chosen in the setup. If the:

• AML status is Accepted, then a reversal process will be triggered that will:
  • Adjust the withdrawal transaction in Mambu.
  • Cancel the transaction in ComplyAdvantage.
  • Adjust Journal Entries in Mambu.
  • If the transaction was created it can be automatically returned or not, depending on the third-party system.
• AML status is unknown then no reversal will be triggered and a manual analysis and reconciliation is needed.

Alerts logic

ComplyAdvantage produces a number of alerts depending on how submitted transactions are processed. If a transaction is submitted and analyzed by ComplyAdvantage and no alerts are flagged based on the configured rules, the payment AML status is automatically changed to Accepted since no rule was violated. For flagged alerts, with transactions that have issues, the following applies.

Flagged alerts

Each defined rule generates a pass or fail response and the failed responses create an alert. Therefore a single transaction can contain one or more alerts. Each alert should be analyzed, investigated, and moved through a series of customer-defined workflow states - such as In Review, Escalated, or Accepted. Alert states can either be in an end state or a temporary state. An alert is considered to be closed when it is moved to an end state of either Accepted or Rejected.

A transaction has a priority action, which is the overall action for the transaction and is derived from the actions of all of the open alerts that a transaction has, such as Soft Stop or Hard Stop. Webhooks can be triggered when a transaction’s priority action changes due to a change in one of its related alerts state. The final webhook received for a transaction is priority action null - at this point all alerts are in an end state.

Max Priority Action - Rejected

Only Hard Stop

If a transaction triggers only Hard Stop alerts and has a value of R in the configuration action field, then the payment is automatically Rejected due to the Hard Stop alert, and the funds are not returned to the originator since the payment remains under investigation. Once all alerts are transitioned from In Review to an end state of Accepted or Rejected, webhooks are sent by ComplyAdvantage that automatically trigger the Alerts Analyser Router [to be linked to CA] process. But the payload will be ignored since the transaction was already Rejected.

Only Soft Stop

If a transaction triggers only Soft Stop alerts, then based on the value of the action field from configuration - either I or S - the payment can be Suspended or Accepted. Once all the alerts have been transitioned from In Review to an end state of Accepted or Rejected webhooks are sent by ComplyAdvantage that automatically trigger the Alerts Analyser Router [to be linked to CA] process. A notification is sent when conflicting statuses - for example, Accepted and Rejected - are set for the alerts flagged for a transaction.

Hard Stop and Soft Stop

If a transaction triggers Hard Stop and Soft Stop alerts and has a value of R in the configuration action field, then the payment is automatically Rejected due to the Hard Stop alert and the funds are not returned to the originator since the payment remains under investigation. Once all the alerts are transitioned from In Review to an end state of Accepted or Rejected webhooks are sent by ComplyAdvantage that automatically trigger the Alerts Analyser Router [to be linked to CA] process. But the payload will be ignored since the transaction was already Rejected.

Max Priority Action - Suspended

Only Hard Stop

If a transaction triggers only Hard Stop alerts and the configuration action field has a value of S, then the payment is Suspended in ComplyAdvantage until all alerts are reviewed. Once all the alerts have been transitioned from In Review to an end state of Accepted or Rejected, a webhook is sent by ComplyAdvantage that automatically triggers the Alerts Analyser Router [to be linked to CA process.

Only Soft Stop

If a transaction triggers only Soft Stop alerts then based on the value of action field from configuration - either I or S - the payment can be Suspended or Accepted in ComplyAdvantage. Once all the alerts have been transitioned from In Review to an end state of Accepted or Rejected, a webhook is sent by ComplyAdvantage that automatically triggers the Alerts Analyser [to be linked to CA] process.

Hard Stop and Soft Stop

If a transaction triggers Hard Stop and Soft Stop alerts the configuration action field will have a value of S (for Hard Stop) the payment is Suspended in ComplyAdvantage until the alerts are reviewed. Once the Hard Stop alerts have transitioned from In Review to an end state of Accepted or Rejected a webhook is sent by ComplyAdvantage that automatically triggers the MPO process Alerts Analyser [to be linked to CA] and changes the priority_action from Hard Stop into Soft Stop.

When the corresponding action for Soft Stop alerts in configuration is:

• I (Ignore) then the payment will be automatically Accepted since the Hard Stop alerts were already reviewed. Transaction will be Accepted or Rejected based on the Hard Stop alerts end state logic.

• S (Suspended) then the payment will remain Suspended until all Soft Stop alerts are also reviewed and a new webhook is sent by ComplyAdvantage that automatically triggers the MPO process Alerts Analyser [to be linked to CA] and changes the priority_action from Soft Stop into No Stop (if exists) or null. Transaction will be Accepted or Rejected based on the Soft Stop alerts end state logic since the third type of alert if exists has the action I (Ignore).

If any of the triggered alerts with corresponding action in configuration I (Ignore) are reviewed after a transaction already has a final status, a webhook is sent by ComplyAdvantage that automatically triggers the MPO process Alerts Analyser [to be linked to CA] due to changed priority_action, but the payload will be ignored since the payment was already processed.

AML Listener process

The AML Listener process redirects and continues with the dedicated flow based on the AML result. The AML Listener configuration is set in the AML Adaptor process, and the value is stored in the Wise connector’s Mambu configuration.

There are three flows based on the result from the FinCrime analysis.

• When the AML status is Accepted:
  • Patch transaction in Mambu with the AML status.
  • Check the transfer type by boolean parameters isPaymentGatewayTransfer and isPrefundTransfer and continue with the dedicated flow.
• When the AML status is Rejected:
  • Patch transaction in Mambu with the AML status.
  • Store the transfer in the Rejected payments state diagram.
• When the AML status is Error:
  • Patch transaction in Mambu with the AML status.
  • Check if the withdrawal has to be canceled. If yes, refund the withdrawal transaction in Mambu and do the reverse accounting. If no, stop the flow.
• When the AML status is Other: For any unhandled AML statuses, stop the flow.

AML accounting

Accounting, and which General Ledgers (GL) are used, is affected in different ways depending on the AML transaction status.

The flow sequence of AML accounting is described in the following table.

To ensure a better accounting traceability, the IDs of Manual Journal Entries (JEs) belonging to the same transaction are customised as follows.

For additional details, notes are added to the manual journal entries as well as to the withdrawal and refund (deposit) transactions.