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:
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
- prefunded transfer flow continues with second part ->
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 fromIn Review
to an end state ofAccepted
orRejected
webhooks are sent by ComplyAdvantage that automatically trigger the MPO process4. Alerts Analyser Router [linked to CA webhook]
and corresponding manual journal entries are logged in the accounting. The final status of aSuspended
transaction can beAccepted
orRejected
.
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 automaticallyAccepted
since theHard Stop
alerts were already reviewed. Transaction will beAccepted
orRejected
based on theHard Stop
alerts end state logic.S
(Suspended) then the payment will remainSuspended
until allSoft Stop
alerts are also reviewed and a new webhook is sent by ComplyAdvantage that automatically triggers the MPO processAlerts Analyser [to be linked to CA]
and changes thepriority_action
fromSoft Stop
intoNo Stop
(if exists) ornull
. Transaction will beAccepted
orRejected
based on theSoft Stop
alerts end state logic since the third type of alert if exists has the actionI
(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
orRejected
) 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
orRejected
.
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:
AML status Accepted:
- Patch transaction in Mambu with the AML status;
- Check the transfer type by boolean parameters :isPaymentGatewayTransfer
andisPrefundTransfer
, and continue with the dedicated flow.AML status Rejected:
- Patch transaction in Mambu with the AML status;
- Store the transfer in Rejected payments SD.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.AML status Other:
- Unhandled AML status. Stop
4. AML Accounting
Mambu transaction | AML transaction status | DR | CR |
---|---|---|---|
Withdrawal | not posted yet | Savings Control | Transit GL |
Withdrawal | Accepted | Transit GL | Scheme GL |
Withdrawal | Rejected | Transit GL | Withhold GL |
Withdrawal | Suspended | Transit GL | Suspense GL |
Withdrawal | Suspended -> Accepted | Suspense GL | Scheme GL |
Withdrawal | Suspended -> Rejected | Suspense GL | Withhold GL |
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:
Mambu transaction | DR | CR |
---|---|---|
Withdrawal Accepted by AML | Transit GL or Suspense GL | Scheme GL |
Accounting adjustment in case of Listener process failure | Scheme GL | Transit GL |
Withdrawal refund in case of Listener process failure | Transit GL | Savings Control |
- To ensure a better accounting traceability, the
IDs
of the Manual Journal Entries belonging to the same transaction are customised as follows:
Transaction | ids of the JEs | Obsv. |
---|---|---|
Withdrawal | 134282 | automatically generated by Mambu |
Manual JEs - Pending to Accepted | 134282_PA | generated by MPO |
Manual JEs - Pending to Rejected | 134282_PR | generated by MPO |
Manual JEs - Pending to Suspended | 134282_PS | generated by MPO |
Manual JEs - Suspended to Accepted | 134282_SA | generated by MPO |
Manual JEs - Suspended to Rejected | 134282_SR | generated by MPO |
Deposit (refund) | 134283 | automatically generated by Mambu |
For additional details, notes are added to the manual journal entries as well as to the withdrawal and refund(deposit) transactions.