Bacs Inbound Payments

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 Webhook Listener Router [AWS] 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 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.

Inbound Direct Credit payment

(https://swimlanes.io/u/V_j6PyL22)

An inbound Direct Credit payment is initiated from the Bacs system and BacsDirectCreditInboundPaymentCreated is received in MPO. After the payment type is identified in the WebHook Retailers Receiver, the payload is routed to the Direct Credit Webhook Receiver process. A Direct Credit payment is sent to be monitored on Day 2 when BacsDirectCreditInboundPaymentCreated is sent and received in MPO.

The Payment Receiver Router [Outbound & Inbound] 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 on Day 3, once ClearBank sends the TransactionSettled webhook.
• Rejected:
  • If the rejection occurs before or on Day 4 of the Bacs cycle, the Direct Credit payment is returned in ClearBank and funds are moved to the Scheme account.
  • If the rejection occurs after Day 4 of the Bacs cycle, the Direct Credit payment can no longer be returned in ClearBank. A notification is sent and the funds are moved into the Withhold account.
• Suspended: Once all alerts are transitioned from In Review to an end state of Accepted or Rejected, webhooks are sent by ComplyAdvantage and automatically trigger the MPO process Alerts Analyser Router [to be linked to CA] and the corresponding manual journal entries are logged in accounting. The final status of a Suspended transaction can be Accepted or Rejected.

Since a payment might be Suspended in ComplyAdvantage for a long time until it is reviewed, and the Bacs Direct Credit is a three-day cycle (over consecutive working days), the TransactionSettled webhook sent on Day 3 can be received before or after the final AML status of a transaction is known.

In the case of Suspended payments, when TransactionSettled from Day 3 is sent:

• After the final AML status: The transaction is stored in an Accepted or Rejected state until the TransactionSettled webhook is sent and received in MPO.
• Before the final AML status: The transaction is stored in the Suspended state until a final AML status from ComplyAdvantage is received.

If the Suspended transactions are released as:

• Accepted: A deposit transaction is posted in Mambu regardless of the day it was released by ComplyAdvantage.
• Rejected: A Direct Credit return is only triggered via API if the current day is the same as third day - when the TransactionSettled webhook arrives - or the fourth day in the BACS cycle and the funds are moved into the scheme account. To find the fourth day of the BACS cycle, when the return in ClearBank can be triggered, a check is done to see if the next day is a working day or a non-working day. If the next day is a non-working day, the day is skipped and the next day is checked until a working day is found. If the current day is not the same as either the third or the fourth day in the BACS cycle, the return cannot be initiated anymore in ClearBank, the funds are moved into the withhold account, and a notification is sent for manual reconciliation.

Inbound Direct Credit Recall

A Bacs Direct Credit may be recalled, which cancels processing of the payment, by the Service User’s Payment Service Provider (PSP) up until 15:45 on Day 2 of the Bacs processing cycle. ClearBank will manage recall requests on the client’s behalf. A recalled Bacs Direct Credit will not be applied to the client’s account.

Since a Direct Credit payment is sent to be monitored on Day 2, when BacsDirectCreditInboundPaymentCreated is received in MPO, and recall can be made on Day 2, the following logic applies based on the AML status:

If the payment status is:

• Accepted or Rejected: Funds are moved to the Scheme account since no payment was applied to the client’s account.
• Suspended: Funds are moved to the Scheme account regardless of when all the alerts are reviewed and transitioned from In Review to an end state of Accepted or Rejected (before or after Day 4).

Since a payment may be Suspended in ComplyAdvantage for a long time until it is reviewed, and the Bacs Direct Credit is a three-day cycle (over consecutive working days), the BacsDirectCreditRecalled webhook sent on Day 2 with the field source = Bacs can be received before or after the final AML status of a transaction is known. Regardless of when the final AML status of Accepted or Rejected (before or after Day 4) is sent, the funds are moved to the Scheme General Ledger (GL) from the Suspended state, as the payment has already been recalled. When webhooks are sent by ComplyAdvantage and automatically trigger the MPO process Alerts Analyser Router [to be linked to CA], the payload will be ignored as the payment has already been recalled in ClearBank.

Receiving the BacsDirectCreditRecalled webhook means that the Direct Credit payment has been cancelled and a notification is sent based on the Notification Setup configuration with the payment details sent from ClearBank with the following message:

Task created due to: Bacs Direct Credit Payment was Recalled. Task was created from MPO for: Transaction Type: DirectCredit, Bacs Transaction ID: a761c3f2-c22h-2j7a-228c-b23rf3685c1e, Transaction Status: Recalled, Service User Number: 916201, RecallReference: DCMRCHRECALL for Mambu Creditor with Account Number: 00000192. Process ID: 43967.

Inbound Direct Credit returns

When a Direct Credit payment cannot be applied for any reason, the funds will be returned no later than Day 5 (Day 3 of ARUCS) of the Bacs processing cycle. In the connector three types of returns are handled:

• Automatic return
• Manual return from APIs (active on Day 3 and Day 4 of the Bacs cycle)
• Manual return from the ClearBank Portal UI (active only on Day 3 of the Bacs cycle)

Automatic returns

An Automated Return of Unapplied Credit Service (ARUCS) report will be generated by Bacs advising that the payment has not been applied and providing reasons why.

ClearBank automatically returns a Direct Credit as unapplied if the destination account is unknown, is disabled, or cannot accept credits. The BacsDirectCreditReturnCreated webhook is sent by ClearBank on Day 3 and the payment is re-routed to the Bacs Suspense account and the ARUCS process is used to return the funds. As no corresponding Deposit (Credit) transaction exists in Mambu, the TransactionSettled (Debit) webhook sent by ClearBank on Day 5 will be acknowledged but will not be followed by any action in the connector - since the original Credit transaction sent on Day 3 has already been returned in ClearBank.

Since a Direct Credit payment is sent to be monitored on Day 2, when BacsDirectCreditInboundPaymentCreated is received in MPO, and the automatic return can be made starting with Day 3, when TransactionSettled webhook is sent with Bacs Suspense IBAN Account, the following logic applies based on the AML status:

If the payment status is:

• Accepted or Rejected: Funds are moved to the Scheme account as the payment is already returned in ClearBank.
• Suspended: Funds are moved to the Scheme account regardless of when all the alerts are reviewed and transitioned from In Review to an end state of Accepted or Rejected (before or after Day 4).

As a payment may be Suspended in ComplyAdvantage for a long time until it is reviewed, and the Bacs Direct Credit is a three-day cycle (over consecutive working days), the TransactionSettled webhook which is sent on Day 3 can be received before or after the final AML status of a transaction is known. Regardless of when the final AML status of Accepted or Rejected (before or after Day 4) is sent, the funds are moved to the Scheme account from the Suspended state as the payment has already been returned by ClearBank. When webhooks are sent by ComplyAdvantage and automatically trigger the MPO process Alerts Analyser Router [to be linked to CA], the payload will be ignored as the payment has already been returned in ClearBank.

When a Direct Credit payment is automatically returned by ClearBank, a notification is sent in MPO based on the Notification Setup configuration in Mambu or Zendesk with the following message:

Task created due to: Bacs Direct Credit Payment was Automatic Returned by ClearBank. Task was created from MPO for: Transaction Type: DirectCredit, Bacs Transaction ID: a1629572-a4c1-4fa2-b47d-6145866fb630, Transaction Status: Settled, Service User Number: 710011 for Mambu Creditor with IBAN: GB41CLRB04071700000036. Process ID: 43967.

Manual returns via APIs

If a Bacs Direct Credit payment cannot be applied to the destination account - due to, for example, a transferred account or the Mambu deposit account is an invalid state to receive transactions - ClearBank sends an ARUCS message to the Service User, and the funds will be debited from the Suspense account and credited to the originator.

The ClearBank BacsDirectCreditReturnCreated webhook is sent with the source Api when a return via API is initiated on Day 3 (Day 1 of ARUCS) or, in exceptional cases, Day 4 (Day 2 of ARUCS) with the reason code 0 - Refer to payer as to why the payment was unapplied. The ARUCS payments are identified by transaction code RA in the Bacs input record.

A Direct Credit payment is sent to be monitored on Day 2 when BacsDirectCreditInboundPaymentCreated is received in MPO and the manual return via APIs can be made starting with Day 3 when TransactionSettled webhook is sent. The following logic applies based on the AML status.

If the payment status is:

• Accepted: The Inbound Direct Credit - Deposit [API] process is triggered
• Rejected:
  • If the rejection occurs on or before Day 4 of Bacs cycle, the Direct Credit payment will be returned in ClearBank via APIs and the funds are moved to the Scheme account.
  • If the rejection occurs after Day 4 of Bacs cycle then the Direct Credit payment cannot be returned anymore in ClearBank, a notification will be sent and the funds will be moved into the 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 and automatically trigger the MPO process Alerts Analyser Router [to be linked to CA] and the corresponding manual journal entries are logged in accounting. The final status of a Suspended transaction can be Accepted or Rejected.

Since a payment might be Suspended in ComplyAdvantage for a long time until it is reviewed, and the Bacs Direct Credit is a three-day cycle (over consecutive working days), the TransactionSettled webhook which is sent on Day 3 can be received before or after the final AML status of a transaction is known.

In the case of Suspended payments, when TransactionSettled from Day 3 is sent:

• After the final AML status, the transaction is stored in the Accepted or Rejected state until TransactionSettled webhook is sent and received in MPO.
• Before the final AML status, the transaction is stored in the Suspended state until a final AML status from ComplyAdvantage is received.

If the Suspended transactions are released as:

• Accepted: The Inbound Direct Credit - Deposit [API] process is triggered regardless of the day ComplyAdvantage releases the transaction.
• Rejected: A Direct Credit return is only triggered via API if the current day is the same as the third day, when the TransactionSettled webhook arrives, or the fourth day in the BACS cycle and the funds are moved into the scheme account. To find the fourth day of the BACS cycle - the last day when the return in ClearBank can be triggered - a check is done to see if the next day is a working day or a non-working day. In the latter case, the day is skipped and the next day is checked until a working day is found. The date of the possible next working day is checked with the values of the elements in the publicHolidays array stored in the ClearBank Config state diagram. If the current day is not the same as either the third or the fourth day in the BACS cycle, the return cannot be initiated anymore in ClearBank, the funds are moved into the withhold account, and a notification is sent for manual reconciliation.

If the Deposit transaction cannot be posted to the Mambu Deposit Account due to an invalid deposit account state, the manual return process via ClearBank APIs is initiated using the return code: 0 - Refer to payer, funds are moved to the Scheme account, and a notification of [INFO] is sent. If the return is not active anymore a notification is sent, funds are moved to the Withhold account, and the client will return the funds to the originator via manual reconciliation.

As no corresponding Deposit (Credit) transaction exists in Mambu, the TransactionSettled (Debit) webhook sent by ClearBank on Day 5 with the field IsReturned = true will be acknowledged but will not be followed by any action in the connector since the original Credit transaction has already been returned in ClearBank.

When a Direct Credit payment is manually returned via ClearBank APIs, a notification is sent in MPO based on the Notification Setup configuration in Mambu or Zendesk with the following message:

Task created due to: INVALID_DEPOSIT_ACCOUNT_STATE Transaction with ID: db29d6f0-a8a1-404d-be1e-ea24313d2ed4 initiated by Mambu was Returned via APIs. . Task was created from MPO for payment scheme: Bacs, Transaction Type: DirectCredit, Bacs Transaction ID: fe2dcdc6-8e18-406c-bb66-a4c4668bfbb9, EndToEnd transaction ID: fe2dcdc68e18406cbb66a4c4668bfbb9, Service User Number: 710011, transaction Identifier Field Ref: 04071700000192DEMORET040717000001920000000200020220530 for Deposit Account: WEPG115 Process ID: 44060.

When a Direct Credit payment is manually returned via ClearBank APIs but fails, a notification is sent in MPO based on the Notification Setup configuration in Mambu or Zendesk with the following message:

Task created due to: INVALID_DEPOSIT_ACCOUNT_STATE ClearBank API error : {"d72a0e65-795a-4f88-a178-a6471e7612a8":["NotBacsTransaction"]} Validation Error ClearBank API error for creating a DD/DC transaction return Direct Credit Transaction in Clearbank was not Returned via APIs. Manual Intervention needed! Potential actions: return the Direct Credit from ClearBank Portal UI or contact ClearBank support. . Task was created from MPO for payment scheme: Bacs, Transaction Type: DirectCredit, Bacs Transaction ID: 5dc9839d-e16f-4ef0-a948-725b0cb0e996, EndToEnd transaction ID: 5dc9839de16f4ef0a948725b0cb0e996, Service User Number: 710011, transaction Identifier Field Ref: 04071700000192DEMORET040717000001920000005020020220526 for Deposit Account: WEPG115 Process ID: 44015.

Manual returns via UI

Manual returns via the ClearBank Portal UI can be triggered on demand only on Day 3 or when an initial return via ClearBank APIs has failed. The ClearBank BacsDirectCreditReturnCreated webhook is sent when a return via the Clearbank Portal UI is initiated on Day 3 (Day 1 of ARUCS) with a specific reason code explaining why the payment was unapplied. The ARUCS payments are identified by transaction code RA in the Bacs input record.

A Direct Credit payment is sent to be monitored on Day 2 when BacsDirectCreditInboundPaymentCreated is received in MPO, and the manual return via ClearBank Portal UI can be made only on Day 3 when TransactionSettled webhook is sent and received in MPO. The following logic applies based on the AML status:

• Accepted: The Inbound Direct Credit - Deposit [API] process is triggered and a Deposit transaction is created in Mambu. When the return is made from ClearBank Portal UI the following webhooks will be sent to MPO:

  • TransactionSettled - Credit with scheme Transfer and Bacs Suspense Account IBAN, which is acknowledged in MPO (no action is taken).
  • TransactionSettled - Debit with scheme Transfer and Bacs Suspense Account IBAN, which is acknowledged in MPO (no action is taken).
  • BacsDirectCreditReturnCreated with scheme Bacs, source Portal, and the OriginalBacsTransactionId field, which represents the link between the initial TransactionSettled received on Day 3 and the returned transaction. The OriginalBacsTransactionId field is stored in Bacs Return Webhooks from CB UI state diagram from MPO along with the returnSource and returnReasonCode.
  • When TransactionSettled - Debit with scheme Bacs is sent on Day 5, first the Deposit transaction is searched in Mambu by the OriginalBacsTransactionId. If a Deposit transaction is found then it is adjusted by posting a withdrawal transaction in Mambu using the transaction channel CB_Return_Bacs. If the Deposit transaction is not found, due to the fact it was not created, a notification is sent.

• Rejected: Manual return via the ClearBank Portal UI is not applicable for AML Rejected since for this state the return is handled always via ClearBank APIs. This can be triggered only when the return via APIs fails on Day 3. As no corresponding Deposit (Credit) transaction exists in Mambu, the TransactionSettled (Debit) webhook sent by ClearBank on Day 5 with field IsReturned = true will be acknowledged ,but will not be followed by any action in the connector since the original Credit transaction was processed only in ClearBank.

• Pending and Suspended: When BacsDirectCreditReturnCreated is sent with the source Portal and the transaction is still Suspended or Pending in MPO, the funds are sent to Scheme as the payment has already been returned from the ClearBank UI, and a notification of [INFO] is sent regardless of when a final AML status of Accepted or Rejected (before/after Day 4) will be sent. When webhooks are sent by ComplyAdvantage and automatically trigger the MPO process Alerts Analyser Router [to be linked to CA], the payload will be ignored as the payment has already been returned in ClearBank. As no corresponding Deposit (Credit) transaction exists in Mambu, the TransactionSettled (Debit) webhook sent by ClearBank on Day 5 with field IsReturned = true will be acknowledged, but will not be followed by any action in the connector since the original Credit transaction has already been returned in ClearBank.

When a Direct Credit payment is manually returned via ClearBank Portal UI, a notification is sent in MPO based on the Notification Setup configuration in Mambu or Zendesk with the following message:

[INFO] A return transaction has been initiated from ClearBank Portal UI for the Direct Credit payment with Bacs Transaction ID: e24e2f64-b781-4a03-b3ad-3d4eca813732, End to End Transaction ID: e24e2f64b7814a03b3ad3d4eca813732 and return reason code 0. The Direct Credit payment was successfully reversed in Mambu by posting a Withdrawal transaction with ID [374707] and encoded key [8a015a8e81141878018114eae365035b].

Error handling

If a failure occurs during execution the following actions will be taken in the connector:

• When the return via APIs in ClearBank is active (Day 3 and/or Day 4 of Bacs cycle): The payment will be returned from MPO using the return code 0 - Refer to payer, funds are moved to the Scheme account, and at least one notification is sent with the failure reason. Inbound Direct Credit transaction in ComplyAdvantage remains Active.
• When the return via APIs in ClearBank is active (Day 3 and/or Day 4 of Bacs cycle) but fails: The payment will be returned manually by the client, funds are moved to the Scheme account, and at least one notification is sent with the failure reason. Inbound Direct Credit transaction in ComplyAdvantage remains Active.
• When the return via APIs in ClearBank is not active (after Day 4 of Bacs cycle): The payment will be returned manually by the client, funds are moved to the Scheme account, and at least one notification is sent with the failure reason. Inbound Direct Credit transaction in ComplyAdvantage remains Active.

For Suspended payments failures that are triggered in 1. Alerts Analyser Router [to be linked to CA] process, if the accounting was not posted or fails for a final known AML status of Accepted or Rejected, this part is re-attempted in the error handling logic and posted. If the final AML status is still Suspended and an error occurs posting the accounting (Debit Suspense and Credit Transit) is skipped to be posted from the error handling mechanism and the funds are sent to the scheme directly from Suspense account (Debit Suspense and Credit Scheme).

If the Modify Task node in the Send AML status to Bacs state diagram from 1.1 Alerts Analyser process fails, this part is re-attempted in the error handling logic and the [Bacs] FinCrime AML Transaction state diagram is updated with the correct AML status. Therefore, the flow continues as a successful flow and not a failure, and a notification is sent with the failure reason as [INFO].

Inbound Direct Credit Held payment

Following an Inbound Direct Credit Held payment and if the payment is successful, two webhooks will be received: BacsDirectCreditInboundPaymentHeld and TransactionSettled.

A direct credit payment is sent to be monitored on day 2 when the BacsDirectCreditInboundPaymentCreated webhook is received in MPO and the BacsDirectCreditInboundPaymentHeld webhook will be received on day 3 before the TransactionSettled webhook is sent. The results that can be returned by ClearBank are:

• False positive: the BacsDirectCreditInboundPaymentHeld and TransactionSettled webhooks are received (payment is release)
• True positive: only the BacsDirectCreditInboundPaymentHeld webhook is sent (payment remains under investigation)

The following logic applies based on the AML status and response from ClearBank.

If the result from the ClearBank investigation is a false positive and the payment status is:

• Accepted: The Inbound Direct Credit - Deposit [API] process is triggered
• Rejected:
  • If the rejection occurs on or before day 4 of Bacs cycle, the direct credit payment will be returned in ClearBank via APIs and the funds are moved to the scheme account.
  • If the rejection occurs after day 4 of the Bacs cycle then the direct credit payment cannot be returned anymore in ClearBank, a notification will be sent and the funds will be moved into the withhold account.
• Suspended: Once all the alerts are transitioned from an In Review state to an end state of Accepted or Rejected, webhooks are sent by ComplyAdvantage and automatically trigger the Alerts Analyser Router [to be linked to CA] process and the corresponding manual journal entries are logged in accounting. The final status of a suspended transaction can be Accepted or Rejected.

In the case of suspended payments, when the BacsDirectCreditInboundPaymentHeld and TransactionSettled webhooks from day 3 are sent:

• After the final AML status: The transaction is stored in an Accepted or Rejected state until the TransactionSettled webhook is sent and received in MPO.
• Before the final AML status: The transaction is stored in the Suspended state until a final AML status from ComplyAdvantage is received.

If the suspended transactions are released as:

• Accepted: A deposit transaction is posted in Mambu regardless of the day it was released by ComplyAdvantage.
• Rejected: A direct credit return is only triggered via API if the current day is the same as third day - when the TransactionSettled webhook arrives - or the fourth day in the BACS cycle and the funds are moved into the scheme account. To find the fourth day of the BACS cycle, when the return in ClearBank can be triggered, a check is done to see if the next day is a working day or a non-working day. If the next day is a non-working day, the day is skipped and the next day is checked until a working day is found. If the current day is not the same as either the third or the fourth day in the BACS cycle, the return cannot be initiated anymore in ClearBank, the funds are moved into the withhold account, and a notification is sent for manual reconciliation.

If the result from the ClearBank investigation is a true positive and the payment status is:

• Accepted: In the [BACS] FinCrime AML Transaction - Direct Credit state diagram, the payment will be moved from the Accepted State to the Rejected by ClearBank state and the accounting will be updated (Debit - Transit GL and Credit - Withhold GL).
• Rejected:
  • In the [BACS] FinCrime AML Transaction - Direct Credit state diagram, the payment will be moved from the Rejected state to the Rejected by ClearBank state and the accounting will be updated (Debit - Transit GL and Credit - Withhold GL).
• Suspended: Funds are moved to the withhold account regardless of when all the alerts are reviewed and the payment will be moved from the Suspended state to the Rejected by ClearBank state.

As a payment may be suspended in ComplyAdvantage for a long time until it is reviewed, and the Bacs direct credit is a three-day cycle (over consecutive working days), the BacsDirectCreditInboundPaymentHeld webhook which is sent on day 3 can be received before or after the final AML status of a transaction is known. Regardless of when the final AML status of Accepted or Rejected (before or after day 4) is sent, the funds are moved to the withhold account from the Suspended state. When webhooks are sent by ComplyAdvantage and automatically trigger the Alerts Analyser Router [to be linked to CA] process, the payload will be ignored as the payment has already been returned in ClearBank.

Inbound Direct Debit payment

An Inbound Direct Debit payment is initiated from Bacs system and the BacsDirectDebitInboundPaymentCreated is received in MPO. After the payment type is identified in the WebHook Retailers Receiver, the payload it is routed to Direct Debit Webhook Receiver process. A Direct Debit payment is sent to be monitored on Day 2 when BacsDirectDebitInboundPaymentCreated is sent and received in MPO.

The Payment Receiver Router [Outbound & Inbound] 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 or Suspended based on the AML configuration of the alerts and rules created in ComplyAdvantage. The corresponding manual journal entries are logged in accounting.

If the payment status is:

• Accepted: A withdrawal transaction will be posted in Mambu on Day 3 once ClearBank sends the TransactionSettled (Debit) webhook.
• Suspended: Once all alerts are transitioned from In Review to an end state of Accepted or Rejected, webhooks are sent by ComplyAdvantage and automatically trigger the MPO process Alerts Analyser Router [to be linked to CA] and the corresponding manual journal entries are logged in accounting. The final status of a Suspended transaction can be Accepted or Rejected.

If the Direct Debit payment is Accepted, a withdrawal transaction will be posted in Mambu on Day 3 once ClearBank sends TransactionSettled webhook.

If alerts are flagged for the Accepted payment with the action I- Ignore in ComplyAdvantage config and reviewed, when webhooks are sent by ComplyAdvantage and they automatically trigger the MPO process Alerts Analyser Router [to be linked to CA], the payload will be ignored as the payment was already processed and a final status was provided.

In the case of Suspended payments, when the TransactionSettled (Debit) webhook from Day 3 is sent:

• After the final AML status: If the Suspended transactions are released before the TransactionSettled webhook as Accepted or Rejected, then a withdrawal transaction is posted in Mambu.
• Before the final AML status: A withdrawal transaction will be posted in Mambu on Day 3 once ClearBank sends the TransactionSettled webhook. If the alerts from ComplyAdvantage are reviewed at a later date after the withdrawal transaction is made in Mambu, the webhooks received are ignored in the MPO process Alerts Analyser Router [to be linked to CA].

Inbound Direct Debit returns

When a Direct Debit payment cannot be applied for any reason, the funds will be returned no later than Day 5 (Day 3 of ARUDD) of the Bacs processing cycle. In the connector three types of return are handled:

• Automatic return
• Manual return from APIs (active on Day 3 and Day 4 of Bacs cycle)
• Manual return from the ClearBank Portal UI (active only on Day 3 of Bacs cycle)

Automatic returns

An Automated Return of Unpaid Direct Debit (ARUDD) report will be generated by Bacs advising that the payment has not been applied and providing reasons why.

ClearBank returns a Direct Debit unpaid if:

• The account does not exist.
• The Client Money Account is disabled or does not accept debits.
• There is no Direct Debit Instruction matching the collection request.
• There are insufficient funds in the Client Money account associated with the Virtual account.

If a transaction is returned because of these conditions, the BacsDirectDebitReturnCreated webhook is sent by ClearBank on Day 3 and the payment is re-routed to the Bacs Suspense account and the ARUDD process is used to return the funds. As no corresponding Withdrawal (Debit) transaction exists in Mambu, the TransactionSettled (Credit) webhook sent by ClearBank on Day 5 will be acknowledged, but will not be followed by any action in the connector as the original Debit transaction sent on Day 3 has already been returned in ClearBank.

Since a Direct Debit payment is sent to be monitored on Day 2 when BacsDirectDebitInboundPaymentCreated is received in MPO, and the automatic return can be made starting with Day 3, when TransactionSettled webhook is sent with Bacs Suspense IBAN Account, the following logic applies based on the AML status. If the payment status is Accepted or Suspended funds are moved to the Scheme account as the payment has already been returned in ClearBank.

When a Direct Debit payment is automatically returned by ClearBank, a notification is sent in MPO based on the Notification Setup configuration in Mambu or Zendesk with the following message:

Task created due to: Bacs Direct Debit Payment was Automatic Returned by ClearBank. Task was created from MPO for: Transaction Type: DirectDebit, Bacs Transaction ID: a1629572-a4c1-4fa2-b47d-6145866fb630, Transaction Status: Settled, Service User Number: 710011 for Mambu Debtor with IBAN: GB41CLRB04071700000036. Process ID: 43967.

After the notification is sent, funds are moved to the Scheme account, and the client returns the funds to the originator via manual reconciliation. As no corresponding withdrawal (Debit) transaction exists in Mambu, the TransactionSettled (Credit) webhook sent by ClearBank on Day 5 with field IsReturned = true will be acknowledged, but will not be followed by any action in the connector since the original Debit transaction has already been returned in ClearBank.

Manual Returns via APIs

If a Bacs Direct Debit payment cannot be applied to the destination account - due to, for example, a transferred account or the Mambu deposit account is an invalid state to receive transactions - ClearBank sends an ARUDD message to the Service User, and the funds will be debited from the Suspense account and debited to the originator.

ClearBank BacsDirectDebitReturnCreated webhook is sent with the source Api when a return via APIs is initiated on Day 3 (Day 1 of ARUDD) or in exceptional cases Day 4 (Day 2 of ARUDD) with the reason code 0 - Refer to payer as to why the payment was unapplied.

A Direct Debit payment is sent to be monitored on Day 2 when BacsDirectDebitInboundPaymentCreated is received in MPO, and the manual return via APIs can be made starting with Day 3 when TransactionSettled webhook is sent, the following logic applies based on the AML status. If the payment status is Accepted, Suspended or Rejected, the Inbound Direct Debit - Withdrawal [API] process is triggered.

If the withdrawal transaction cannot be posted to Mambu Deposit Account due to deposit account state is invalid or insufficient funds, the manual return process via ClearBank APIs is initiated using the return code: 0 - Refer to payer, funds are moved to the Scheme account, and a notification of [INFO] is sent.

If the return fails a notification is sent, funds are moved to the Scheme account, and the client returns the funds to the originator via manual reconciliation. As no corresponding Withdrawal (Debit) transaction exists in Mambu, the TransactionSettled (Credit) webhook sent by ClearBank on Day 5 with field IsReturned = true will be acknowledged, but will not be followed by any action in the connector since the original Debit transaction has already been returned in ClearBank.

When a Direct Debit payment is manually returned via ClearBank APIs, a notification is sent in MPO based on the Notification Setup configuration in Mambu or Zendesk with the following message:

Task created due to: INVALID_DEPOSIT_ACCOUNT_STATE Transaction with ID: db29d6f0-a8a1-404d-be1e-ea24313d2ed4 initiated by Mambu was Returned via APIs. Task was created from MPO for payment scheme: Bacs, Transaction Type: DirectDebit, Bacs Transaction ID: fe2dcdc6-8e18-406c-bb66-a4c4668bfbb9, EndToEnd transaction ID: fe2dcdc68e18406cbb66a4c4668bfbb9, Service User Number: 710011, transaction Identifier Field Ref: 04071700000192DEMORET040717000001920000000200020220530 for Deposit Account: WEPG115 Process ID: 44060.

When a Direct Debit payment is manually returned via ClearBank APIs but fails, a notification is sent in MPO based on the Notification Setup configuration in Mambu or Zendesk with the following message:

Task created due to: INVALID_DEPOSIT_ACCOUNT_STATE ClearBank API error : {"d72a0e65-795a-4f88-a178-a6471e7612a8":["NotBacsTransaction"]} Validation Error ClearBank API error for creating a DD/DC transaction return Direct Debit Transaction in Clearbank was not Returned via APIs. Manual Intervention needed! Potential actions: return the Direct Debit from ClearBank Portal UI or contact ClearBank support. Task was created from MPO for payment scheme: Bacs, Transaction Type: DirectDebit, Bacs Transaction ID: 5dc9839d-e16f-4ef0-a948-725b0cb0e996, EndToEnd transaction ID: 5dc9839de16f4ef0a948725b0cb0e996, Service User Number: 710011, transaction Identifier Field Ref: 04071700000192DEMORET040717000001920000005020020220526 for Deposit Account: WEPG115 Process ID: 44015.

Manual Returns via UI

Manual returns via the ClearBank Portal UI can be triggered on demand only on Day 3 or when an initial return via ClearBank APIs failed. ClearBank BacsDirectDebitReturnCreated webhook is sent when a return via ClearBank Portal UI is initiated on Day 3 (Day 1 of ARUDD) with a specific reason code as to why the payment was unapplied.

A Direct Debit payment is sent to be monitored on Day 2 when BacsDirectDebitInboundPaymentCreated is received in MPO, and the manual return via ClearBank Portal UI can be made only on Day 3 when TransactionSettled webhook is sent and received in MPO. The following logic applies based on the AML status:

• Accepted, Suspended, or Rejected: The Inbound Direct Debit - Withdrawal [API] process is triggered and a withdrawal transaction is created in Mambu. When the return is made from the ClearBank Portal UI the following webhooks will be sent to MPO:

  • TransactionSettled - Credit with scheme Transfer and Bacs Suspense Account IBAN, which is acknowledged in MPO (no action is taken).
  • TransactionSettled - Debit with scheme Transfer and Bacs Suspense Account IBAN, which is acknowledged in MPO (no action is taken).
  • BacsDirectDebitReturnCreated with scheme Bacs, source Portal, and the OriginalBacsTransactionId field - which represents the link between the initial TransactionSettled received on Day 3 and the returned transaction. The OriginalBacsTransactionId field is stored in Bacs Return Webhooks from CB UI state diagram in MPO, along with the returnSource, returnReasonCode, returnCreditorBBAN, and returnCreditorName.
  • When TransactionSettled - Credit with scheme Bacs and field IsReturned = true is sent on Day 5, first the withdrawal transaction is searched in Mambu by the OriginalBacsTransactionId. If a withdrawal transaction is found then it is adjusted by posting a Deposit transaction in Mambu using the transaction channel CB_Return_Bacs. If the withdrawal transaction is not found, due to the fact it was not created, a notification is sent.

• Pending: When BacsDirectDebitReturnCreated is sent with source Portal and the transaction is still Pending in MPO, the funds are sent to the Scheme since the payment has already been returned from the ClearBank UI, and a notification of [INFO] is sent regardless of when a final AML status of Accepted or Rejected (before/after Day 4) is sent. When webhooks are sent by ComplyAdvantage and automatically trigger the MPO process Alerts Analyser Router [to be linked to CA] the payload will be ignored as the payment has already been returned in ClearBank. As no corresponding Withdrawal (Debit) transaction exists in Mambu, TransactionSettled (Credit) webhook sent by ClearBank on Day 5 with field IsReturned = true will be acknowledged, but will not be followed by any action in the connector since the original Debit transaction has already been returned in ClearBank.

When a Direct Debit payment is manually returned via ClearBank Portal UI, a notification is sent in MPO based on the Notification Setup configuration in Mambu or Zendesk with the following message:

[INFO] A return transaction has been initiated from ClearBank Portal UI for the Direct Debit payment with Bacs Transaction ID: e24e2f64-b781-4a03-b3ad-3d4eca813732, End to End Transaction ID: e24e2f64b7814a03b3ad3d4eca813732 and return reason code 0. The Direct Debit payment was successfully reversed in Mambu by posting a Deposit transaction with ID [374707] and encoded key [8a015a8e81141878018114eae365035b].

Error handling

In case of Direct Debit failures, there can be two different outcomes depending on the value of the returnDirectDebitTransaction parameter in the ClearBank config:

• When the value of the returnDirectDebitTransaction parameter is set to true: All failures from MPO, Mambu, ComplyAdvantage, or ClearBank in the first part of the AML extension (until the Alerts Analyzer process) will return the Direct Debit transaction in ClearBank and send a notification with the failure reason.
• When the value of the returnDirectDebitTransaction parameter is set to false: The Direct Debit transaction is returned only if the Mambu deposit account is in an invalid state or has insufficient funds. Otherwise, only a notification is sent with the failure reason and on Day 3 the payment is processed. Manual intervention could be needed in case a failure occurs.

If a failure occurs during execution and the returnDirectDebitTransaction parameter is set to true, the following actions are taken in the connector:

• The payment is returned via APIs in ClearBank from MPO using the return code 0 - Refer to payer, funds are moved to the Scheme account, and at least one notification is sent with the failure reason. Inbound Direct Debit transaction in ComplyAdvantage remains Active.
• When the return via APIs in ClearBank is initiated (Day 3 of Bacs cycle) but fails, the payment needs to be returned manually by the client, funds are moved to the Scheme account, and at least one notification is sent with the failure reason. Inbound Direct Debit transaction in ComplyAdvantage remains Active.

For Suspended payments failures that are triggered in 1. Alerts Analyser Router [to be linked to CA] process until the Modify Task node in the Send AML status to Bacs, the transaction is updated in the [BACS] FinCrime AML Transaction - Direct Debit state diagram with one of Accepted,Rejected, or Suspended - if the final status is unknown. The accounting is logged either from error Hhandling or from the state diagram and the flow continues with the withdrawal in Mambu.

If the Modify Task node in the Send AML status to Bacs state diagram from 1.1 Alerts Analyser process fails, this part is re-attempted in the error handling logic and the [Bacs] FinCrime AML Transaction state diagram is updated with the correct AMLstatus. Therefore, the flow continues as a successful flow and not a failure, and a notification is sent with the failure reason as [INFO].

Other scenarios that may occur are listed in the table below: