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 activities.

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 AML Adaptor process and its purpose is to decide the transaction type (e.g:Inbound, Outbound etc.) and route the payment. Once the transaction details are read and processed in the Mambu Process Orchestrator (MPO) process 2. FinCrime Transaction Analysis [linked to Payment Receiver Router] then the transaction details are sent to ComplyAdvantage.

The main two flows/payments that are monitored using AML Transaction Monitoring from Wise are:

• Prefunded Transfer
• Bank Transfer

1. Prefunded & Bank Transfers

An outbound payment is triggered once one of the API wrapper for Prefunded Transfer 4. [EntryPoint] PREFUND Wise transfer flow (1st part) and for Bank Transfer 5. [EntryPoint] Payments Gateways Wise transfer flow is triggered, after a Withdrawal transaction is posted in Mambu, and config option amlCheck is set to true. The The AML Adaptor process is then triggered, where the payment data object is build. The 1. Payment Receiver Router [linked to payments connector] process is then triggered and after the transaction is posted in ComplyAdvantage the AML status returned can be: Accepted, Rejected, or Suspended. The corresponding manual journal entries are logged in the accounting.

If the payment status is:

• Accepted:
  • prefunded transfer flow continues with second part -> 4.1. [EntryPoint] PREFUND Wise transfer flow (2nd part) is triggered
  • bank transfer flow continues with second part in AML Listener -> Extension point to other PAYMENTS GATEWAYS is triggered
• Rejected: a notification is sent, the funds are not returned to the originator since the payment remains under investigation (Withhold account) and is active in all the systems.
• Suspended: 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 MPO process 4. Alerts Analyser Router [linked to CA webhook] and corresponding manual journal entries are logged in the accounting. The final status of a Suspended transaction can be Accepted or Rejected.

For negative use cases: depending on the HTTP code returned the Retry Mechanism will be executed or not. If the error is not fixed after the Retry Mechanism finishes, as when time stored in config 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 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.

Prefunded transfer sequence diagram

Bank transfer sequence diagram

2. Alerts logic

No Alerts

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.

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 on a transaction 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 end state or a temporary state. An alert is considered to be closed when it is moved to an end state: 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 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 config 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 MPO process Alerts Analyser Router [to be linked to CA], but the payload will be Ignored since the transaction was already Rejected.

Hard Stop & Soft Stop

If a transaction triggers Hard Stop and Soft Stop alerts and has a value of R in the config 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 MPO process Alerts Analyser Router [to be linked to CA] 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 config -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 MPO process Alerts Analyser Router [to be linked to CA]. A notification is sent when conflicting statuses (Accepted and Rejected) are set for the alerts flagged for a transaction.

Max Priority Action - Suspended

Only Hard Stop

If a transaction triggers only Hard Stop alerts and in config 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 webhooks are sent by ComplyAdvantage that automatically trigger the MPO process Alerts Analyser Router [to be linked to CA.

Hard Stop & Soft Stop

If a transaction triggers Hard Stop and Soft Stop alerts the config 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 config 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 config 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.

Only Soft Stop

If a transaction triggers only Soft Stop alerts then based on the value of action field from config - 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 MPO process Alerts Analyser [to be linked to CA].

Notes:

• In case that multiple transactions have the same alerts flagged, when at least one of the transaction is reviewed and all the alerts are in an end state (Accepted or Rejected) then the alerts end state is inherited by all the other transactions.
• Each source format from ComplyAdvantage has a unique structure and specific fields that must be mapped in order to be able to submit a transaction.
• If more details need to be pushed in ComplyAdvantage, this can be done using Mambu custom fields or by using an external system.
• When multiple different alerts are flagged for a transaction, multiple webhooks might be sent by ComplyAdvantage based on the priority action after each alert is reviewed and is Accepted or Rejected.

3. AML Listener

The purpose of AML Listener process is to redirect and continue with the dedicated flow based on the AML result. The AML Listener configuration is made in AML Adaptor process, and the value is stored in Wise connector Mambu config. There are three flows, based on the result from the FinCrime Analysis:

1. AML status 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.
   

2. AML status Rejected:
     - Patch transaction in Mambu with the AML status;
     - Store the transfer in Rejected payments SD.
   

3. AML status Error:
     - Patch transaction in Mambu with AML status;
     - Check if the withdrawal has to be canceled.
      - If ‘yes’, then refund Withdrawal transaction in Mambu and do the Reverse accounting.
      - If ‘no’, stop.
   

4. AML status Other:
     - Unhandled AML status. Stop

4. AML Accounting

Notes:

• If the AML connector encounters an error in the flow before reaching the Listener process, no accounting reversals are performed.
• If the payment cannot be continued due to Listener process failures, before refunding the Mambu withdrawal, the money is debited from the Scheme GL and the Transit GL is credited by the withdrawal amount. This prevents the GL inconsistencies in case of adjustments.
  

See below the flow sequence:

• To ensure a better accounting traceability, the IDs of the Manual Journal Entries 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.