☰

FPS and CHAPS

Jump to Section

This template allows you to use ComplyAdvantage’s Anti-Money Laundering (AML) feature for monitoring ClearBank 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 Payment Receiver Router process is automatically triggered when a transaction is initiated from Mambu or any other system and its purpose is to decide if the transaction is Inbound or Outbound. If the payment type received is invalid then the error message is stored in the Error Handling -[TM] state diagram.

Once the transaction details are read and processed in the Mambu Process Orchestrator (MPO) processes Outbound Payment [Reading | Processing] or Inbound Payment [Reading | Processing] then the transaction details are sent to ComplyAdvantage.

Outbound payment

A sequence diagram showing the Outbound payment flow between Mambu, MPO, ComplyAdvantage, and a third-party system

An outbound payment is triggered when a Withdrawal transaction is sent from the Mambu UI or API. The Payment Receiver Router process is automatically triggered when a transaction is sent and routed to the Outbound Payment [Reading | Processing] process. 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: a Deposit (Credit) transaction will be posted in the third-party system.
  • 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 Alerts Analyser Router [to be linked to CA] 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 status code returned the retry mechanism will be executed or not. If the error is not fixed after the retry mechanism finishes (when the time to store in config is exceeded), 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 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.

Inbound payment

A sequence diagram showing the Inbound payment flow between Mambu, MPO, ComplyAdvantage, and a third-party system

An inbound payment is triggered when a transaction is sent from an external system. The Payment Receiver Router process is automatically triggered when a transaction is sent and routed to the Inbound Payment [Reading | Processing] process. 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 accounting.

If the payment status is:

  • Accepted: a Deposit transaction will be posted in Mambu.
  • Rejected: a notification is sent, the funds are not returned to the originator since the payment remains under investigation (Withhold account).
  • 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 Alerts Analyser Router [to be linked to CA]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 status 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:
    • Return the transaction in the third-party system (if the system allows it).
    • Cancel the transaction in ComplyAdvantage.
    • Adjust journal entries in Mambu.
    • If the Deposit transaction was created in Mambu it will be Adjusted.
  • AML status is unknown then no reversal will be triggered and a manual analysis and reconciliation is needed.

Notes:

  • If 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.