BACS

Setting up a Direct Debit Instruction

This template allows creating a Direct Debit Instruction in order to process Direct Debits against Mambu deposit account. Direct Debit Instructions can be submitted to Paying Bank by the Service User in one of the following ways: Electronically via Bacs or Paper Instruction.

Sequence diagram

ClearBank Retail Banking: Create mandate

Direct Debit Instructions (DDIs) document an authorisation agreement between a debtor and a beneficiary to collect Direct Debits in Bacs. A Direct Debit Instruction is set up as a record of this agreement and stored by both the beneficiary’s and the debtor’s bank.

Direct Debit Instructions adhere to the Bacs 3-day cycle (three consecutive working days):

  • Day 1: Input Day -> instruction is submitted to Bacs
  • Day 2: Processing Day -> instruction is processed by Bacs & webhook BacsMandateInitiated sent by ClearBank
  • Day 3: Entry day:
    • -> success: instruction becomes effective
    • -> failure: webhook BacsMandateInitiatedFailed sent by ClearBank (instruction fails validation)

Create Paper Mandate

The process Create Paper Mandate [API] is manually triggered from MPO in order to create a Paper Direct Debit Instruction in ClearBank.

A successful response from ClearBank triggers BacsMandateInitiated webhook confirming the Direct Debit Instruction has been set up. Mambu custom field mandatesDetails is updated with the Service User Name and Mandate ID for the created mandate.

mandatesDetails [NETFLIX: 5bcb40d9-b904-438e-8696-1438ab82c968];

In case of failure BacsMandateInitiatedFailed webhook is sent by ClearBank with a specific reason code. If the notification was set to true then a task will be created in Mambu/ZenDesk based on the configuration Notification Setup with a specific error message in order to be analyzed.

Task created due to: Required field: ‘depositAccountId’ is missing for Deposit Account: LXNG616 using IBAN: GB84CLRB04062687167050. Paper Mandate with mandate id: f153e6b6-220c-4623-ac76-07d9a9199264 was already created in ClearBank with SUN: 772353. Mambu custom field was not updated. Process ID: 705999.

Reasons for failed initiation:

  • 5 - No account
  • B - Virtual account is closed
  • F - Real account is closed or does not accept Direct Debits
  • I - Reference is subset or superset of another item for that SUN and account
  • K - The Paying Bank has cancelled the DDI for that Service User

For the negative cases when mandatesDetails custom field is not updated a manual intervention is needed in order to correct the error. mandatesDetails custom field in Mambu should be updated by adding the Originator name (identified in ClearBank as Service User Name) and Mandate ID.
The following format must be used:

  • single mandate: [Service User Name: Mandate ID];
  • multiple mandates: [Service User Name1: Mandate ID1];[Service User Name2: Mandate ID2];

Create Electronic Mandate (AUDDIS)

The process Create AUDDIS Mandate [Bacs] is automatically triggered when an Automated Direct Debit Instruction Service (AUDDIS) instruction is initiated from Bacs system and webhook BacsMandateInitiated is received in MPO. The Bacs service enables Direct Debit Instructions (DDIs) to be electronically setup (by a 0N transaction) by service users.

ClearBank performs validation and screening on the received DDI:

  • if the instruction is accepted ClearBank sends the BacsMandateInitiated webhook confirming the DDI has been set up. After the AUDDIS instruction is created in ClearBank, the mandate details mandate ID and originator name are stored in Mambu in mandatesDetails custom field.
  • if the instruction is rejected ClearBank sends a Bank Returned AUDDIS message to the Service User followed by BacsMandateInitiatedFailed webhook, advising the Service User that the Direct Debit Instruction has been rejected, including the reason.

Reasons for failed AUDDIS initiation:

  • 1 - Instruction cancelled by payer
  • 2 - Payer deceased
  • 3 - Account transferred
  • 5 - No account
  • 6 - No Instruction
  • 7 - DDI amount not zero
  • B - Account closed
  • C - Account transferred to a different branch of the Paying Bank
  • F - Invalid account type (account does not accept Direct Debits)
  • G - Paying Bank will not accept Direct Debits on account
  • H - Instruction has expired
  • I - Payer Reference is not unique
  • K - Instruction cancelled by Paying Bank for that Service User
  • L - Incorrect payer’s Account Details
  • M - Transaction Code / User Status incompatible
  • N - Transaction disallowed at payer’s branch
  • O - Invalid reference
  • P - Payer’s Name not present
  • Q - Service user’s name blank

Notes:

  • After a paper mandate is created the Mandate Instruction Type displayed in ClearBank is Paper DDI.
  • After an AUDDIS instruction is created the Mandate Instruction Type displayed in ClearBank is AUDDIS.
  • Multiple AUDDIS instruction can be created at once using Bacs file.

Amending a Direct Debit Instruction

This template allows a payer to move their Direct Debit Instruction to another account that they own at that Institution.

Sequence diagram

ClearBank Retail Banking: Amend Mandate

The process Amend Mandate [Bacs] is manually triggered from MPO when the debtor account for a Direct Debit Instruction needs to be changed/updated/moved. The new debtor account must be a valid ClearBank account and be linked to a Mambu deposit account through a virtual account. This flow applies for paper and AUDDIS instructions.

When the instruction is amended:

  • ClearBank stores the Service User Number and Reference against the new account.
  • ClearBank notifies the Service User by the Automated Direct Debit Amendment and Cancellation Service (ADDACS), advising of the change to the Instruction.
  • In Mambu the mandate details Service User Name and Mandate ID are first removed from the initial debtor account and then added to new debtor account in mandateDetails custom field on deposit account level.

Reasons for ADDACS amendments:

  • 0 - Instruction cancelled - Refer to payer
  • 1 - Instruction cancelled by payer
  • 2 - Payer deceased
  • 3 - Account transferred to a new PSP
  • B - Account closed
  • C - Account transferred to a different branch of a PSP
  • D - Advance notice disputed
  • E - Instruction amended
  • R - Instruction re-instated

For the negative flows if a notification was set to true then a task will be created in Mambu/ZenDesk based on the configuration Notification Setup with a specific error message in order to be analyzed.

Task created due to: Required field: ‘depositAccountId’ is missing for Deposit Account: LXNG616. Amend Mandate with ID: f153e6b6-220c-4623-ac76-07d9a9199264 and SUN: 772353 FROM Debtor IBAN: GB84CLRB04062687167050 TO Debtor IBAN: GB44CLRB04062677003916 was done in ClearBank. Mambu Custom Field was not updated (add). Process ID: 705999.

When mandatesDetails custom field is not updated a manual intervention is needed in order to correct the error. mandatesDetails custom field in Mambu should be updated as following:

  • adding the Originator name (identified in ClearBank as Service User Name) and Mandate ID for new deposit account.
  • removing the mandate details Originator name and Mandate ID from the initial deposit account (including the square brackets). The following format must be used:
  • single mandate: [Service User Name: Mandate ID];
  • multiple mandates: [Service User Name1: Mandate ID1];[Service User Name2: Mandate ID2];

Reason codes for amending a Direct Debit Instruction:

  • C - Account transferred to a different branch of bank/building society
  • E - Instruction amended

Notes:

  • For Amending a Direct Debit Instruction no webhook is triggered by ClearBank.
  • The new account may be held on the same sort code as the original account, or on a different sort code issued to the same Paying Bank.

Migrating a Direct Debit Instruction

This template allows migrating a Paper Direct Debit Instruction to Automated Direct Debit Instruction Service (AUDDIS) via Bacs system.

Sequence diagram

ClearBank Retail Banking: Migrate Paper Mandate

The process is automatically triggered when migration cycle of a paper Instruction to AUDDIS is initiated from Bacs system and BacsMandateMigrated webhook is sent by ClearBank and received in MPO. BacsMandateMigrated webhook details are stored in Mandate Migrated Receiver process used only for acknowledgement purpose.

After the paper Instruction is migrated, in ClearBank UI the Mandate Instruction Type value is updated: from Paper DDI to Migrated therefore no updates are needed in Mambu. The Bacs service enables Direct Debit Instructions (DDI) to be electronically migrated (by a 0S transaction) by service users.

Notes:

  • Only Paper Mandates can be migrated.
  • Multiple paper mandates can be migrated at once using Bacs system.
  • In case of failure no webhook is sent by ClearBank.

Cancelling a Direct Debit Instruction

This template allows cancelling a Direct Debit Instruction (DDI) via ClearBank UI, Bacs system or ClearBank API.

Sequence diagram

ClearBank Retail Banking: Cancel Mandate

Cancel Mandate (UI or Bacs system)

The process Cancel Mandate [UI | Bacs] is automatically triggered when cancellation cycle of a Direct Debit Instruction (paper or AUDDIS) is initiated from ClearBank UI or Bacs system file and BacsMandateCancelled webhook is received in MPO.

A Direct Debit Instruction (DDI) can be cancelled by the Payer, by Bank or by Service User:

  • cancelled by Payer -> cancellation reason should be Cancelled by Payer
  • cancelled by Bank -> cancellation reason should be Cancelled by Paying Bank
  • electronically cancelled by Service User -> AUDDIS 0C transaction code

If the cancellation request is accepted, ClearBank sends the BacsMandateCancelled webhook confirming the DDI has been canceled and also sends the Advice of Direct Debit Amendments and Cancellations (ADDACS) message to the Service User. After the DDI is cancelled in ClearBank, in Mambu the corresponding values [Service User Name: Mandate ID]; are removed from mandatesDetails custom field.

Reasons for ADDACS cancellation:

  • 0 - Instruction cancelled - Refer to payer
  • 1 - Instruction cancelled by payer
  • 2 - Payer deceased
  • 3 - Account transferred to a new PSP
  • B - Account closed
  • C - Account transferred to a different branch of a PSP
  • D - Advance notice disputed
  • E - Instruction amended
  • R - Instruction re-instated

When a DDI is electronically cancelled by Service User, ClearBank checks the cancellation matches a known Direct Debit Instruction. If not matched, ClearBank notifies the Service User of the error using a Bank Returned AUDDIS message and sends BacsMandateCancellationFailed webhook.

For the negative cases if the notification was set to true then a task will be created in Mambu/ZenDesk based on the configuration Notification Setup with a specific error message in order to be analyzed.

Reasons for failed AUDDIS cancellation:

  • 1 - Instruction cancelled by payer
  • 2 - Payer deceased
  • 3 - Account transferred
  • 5 - No account
  • 6 - No Instruction
  • 7 - DDI amount not zero
  • B - Account closed
  • C - Account transferred to a different branch of the Paying Bank
  • F - Invalid account type (account does not accept Direct Debits)
  • G - Paying Bank will not accept Direct Debits on account
  • H - Instruction has expired
  • I - Payer Reference is not unique
  • K - Instruction cancelled by Paying Bank for that Service User
  • L - Incorrect payer’s Account Details
  • M - Transaction Code / User Status incompatible
  • N - Transaction disallowed at payer’s branch
  • O - Invalid reference
  • P - Payer’s Name not present
  • Q - Service user’s name blank

Notes:

  • Multiple mandates can be cancelled using Bacs system.
  • After cancellation by Paying Bank, the Service User cannot set up further DDIs on that account (usually used when the Bank wants to close the account).

Cancel Mandate (API)

The process Cancel Mandate [API] is manually triggered from MPO when a cancellation of an Instruction (paper or AUDDIS) is initiated. Before sending the cancellation request to ClearBank, first the linkage between Mambu Deposit Account and ClearBank virtual account is verified and, second the mandate that needs to be cancelled is identified in ClearBank.

A successful response from ClearBank triggers the BacsMandateCancelled webhook which confirms that the Direct Debit Instruction was cancelled, and also sends the Advice of Direct Debit Amendments and Cancellations (ADDACS) message to the Service User. In Mambu the mandatesDetails custom field is updated by removing the Service User Name and Mandate ID from the deposit account.

In case of failure the BacsMandateCancellationFailed webhook is sent by ClearBank with a specific reason code. If the notification was set to true then a task will be created in Mambu/ZenDesk based on the configuration Notification Setup with a specific error message in order to be analyzed.

For the negative case when mandatesDetails custom field is not updated a manual intervention is needed in order to correct the error. mandatesDetails custom field in Mambu should be updated by removing the Originator name (identified in ClearBank as Service User Name) and Mandate ID.

Reasons for canceling a Direct Debit Instruction via API:

  • 0 - Institution cancelled - refer to payer. Paying bank has cancelled instruction.
  • 1 - Instruction cancelled by payer. Payer has instructed the paying bank to cancel the DirectDebit Instruction (Mandate).
  • 2 - Payer deceased
  • B - Account closed. Payer has closed their account for an unknown reason.

Returning a Direct Debit Instruction

Sequence diagram

ClearBank Retail Banking: Return Mandate

The process Return AUDDIS Mandate [API] is manually triggered from MPO. This flow applies for returning an existent AUDDIS Instruction using ClearBank APIs which was created on the same day. Before sending the returning request to ClearBank, first the linkage between Mambu Deposit Account and ClearBank virtual account is verified and second the Instruction that needs to be returned is identified in ClearBank.

A successful response from ClearBank triggers the BacsMandateReturned webhook which confirms that the AUDDIS Instruction was returned. In Mambu the mandatesDetails custom field is updated by removing the Service User Name and Mandate ID from deposit account.

In case of failurethe BacsMandateReturnFailed webhook is sent by ClearBank with a specific reason code. If the notification was set to true then a task will be created in Mambu/ZenDesk based on the configuration Notification Setup with a specific error message in order to be analyzed.

Rejection codes for returning an AUDDIS mandate:

  • 1 - Instruction cancelled by payer
  • 2 - Payer deceased
  • 3 - Account transferred
  • 5 - No account
  • 6 - No Instruction
  • B - Account closed
  • C - Account transferred to a different branch of the bank/building society
  • F - Invalid account type
  • G - Bank will not accept Direct Debits on account
  • H - Instruction has expired
  • I - Payer Reference is not unique
  • K - Instruction cancelled by paying bank

For the negative case when mandatesDetails custom field is not updated a manual intervention is needed in order to correct the error. mandatesDetails custom field in Mambu should be updated by removing the Originator name (identified in ClearBank as Service User Name) and Mandate ID.

Notes:

  • A returned AUDDIS mandate is displayed in ClearBank as Cancelled.
  • Paper mandates will need to be returned via post or cancelled if needed.

Inbound Direct Credit Payment

This template allows initiating inbound Direct Credit transactions for existing Mambu clients that have Mambu deposit accounts, using UK payment scheme: Bacs (Bankers Automated Clearing Services).

Sequence diagram

ClearBank Retail Banking: Inbound Direct Credit

The process is automatically triggered when a payment is initiated from Bacs system and webhook TransactionSettled is received in MPO. Bacs Direct Credit is a push method of accepting/depositing payments. When a Service User Number (SUN) holder wants to send money to a payer account (Mambu account), the payer account should be able to accept money in theirs Deposit accounts from Bacs scheme via ClearBank.

In order to initiate a Bacs Direct Credit payment, the payer needs to know the Sort Code, Account Number and the name of the account in which the funds should be transferred (the payee). Bacs payments work on a three day cycle (the earliest date that the payee will receive a payment is two working days after it is submitted).

Bacs Direct Credits 3-day cycle (three consecutive working days):

  • Day 1: Input Day (entry date) -> payment is submitted
  • Day 2: Procesing Day/Contra Entry (processing date) -> BacsDirectCreditInboundPaymentCreated webhook sent by ClearBank
  • Day 3: Entry day (value date) -> TransactionSettled webhook sent by ClearBank (Credit) followed by a Deposit transaction in Mambu

Standard Bacs Direct Credit transactions are identified by transaction code 99 in the Bacs input record.

Bacs Direct Credit acts like a ‘Direct Deposit’/‘Bank Transfer’, therefore in Mambu a Deposit transaction is logged using a dedicated Transaction Channel based on the payment scheme: CB_Deposit_Bacs. This flow can be executed using any of Mambu deposit product type for which Deposit transaction can be posted.

The transaction codes that indicates a Direct Credit transaction:

  • 99 – Bacs Direct Credits
  • Z4 – Interest payments
  • Z5 – Dividend payments
  • 86 – Settlement Credits
  • 17 – Credit contract (a debit record to balance credit record)

For the negative cases when the payment was settled and TransactionSettled webhook is sent by ClearBank, but due to other issues the Deposit transaction was not posted in Mambu a notification is sent based on the Notification Setup configuration. After the notification is analyzed, if the Deposit transaction needs to be manually posted in Mambu, transaction channel CB_Deposit_Bacs should be used since the payment is already done in ClearBank.

Notes:

  • The MPO process for Inbound Direct Credit payment will be triggered only when TransactionSettled webhhok is sent by ClearBank and received in MPO.
  • If errors are indentified after the payment was credited, as a result of a mistake or the payee/beneficiary is unable to recognise the payment, the remitting bank requests the return of the payment using the Credit Payment Recovery (CPR) process.

Inbound Direct Credit Returns

Direct Credit payments must be submitted with the appropriate transaction code to indicate the type of credit being submitted. If the 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.

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. A Direct Credit should only be returned if the item cannot be applied.

ARUCS reason codes:

  • 0 - Invalid details
  • 2 - Beneficiary deceased
  • 3 - Account transferred
  • 5 - No account
  • B - Account closed
  • C - Requested by Remitter

Bacs Direct Credit returns (ARUCS) follow Bacs 3-day cycle:

  • Day 1: Input Day -> webhook BacsDirectCreditReturnCreated sent by ClearBank
  • Day 2: Procesing Day/Contra Entry
  • Day 3: Entry day:
    • -> success: webhook TransactionSettled sent by ClearBank (Debit) followed by Withdrawal transaction in Mambu
    • -> failure: webhook BacsCreditPaymentNotSettled sent by ClearBank (due to, for example Contra not received)

Automatic Returns

ClearBank returns a Direct Credit unapplied if the destination account is unknown or is disabled or cannot accept credits. BacsDirectCreditReturnCreated webhook is sent by ClearBank and the payment is re-routed to Bacs Suspense account and then use the ARUCS process to return the funds.

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

Task created due to: Transaction in ClearBank was automatically Returned with: BacsTransactionId - c3232984-495c-4605-b5ab-55b914a6cd22, TransactionID: [1d4dd717-c8a9-4c75-9a59-e57ff157d3ed], transaction Identifier Field Ref: 04062670034851AUDDISFILE11040626700348510000000390020200417 and End to End ID: [c3232984495c4605b5ab55b914a6cd22], SUN: 181115.

Manual Returns

If a Bacs Direct Credit payment cannot be applied to the destination account due to, for example, account was transferred, ClearBank sends an ARUCS message to the Service User and the funds will be debited from the Suspense account and credited to the originator.

ClearBank BacsDirectCreditReturnCreated webhook is triggered when a return is initiated on Day 3 (Day 1 of ARUCS) and sent to MPO with an appropriate reason code as to why the payment was unapplied. The ARUCS payments are identified by transaction code RA in the Bacs input record.

Once the return request has been generated, the funds will then transfer to the Bacs Suspense Account. This will trigger a TransactionSettled (Debit) webhook. The Contra record will need to be submitted on Day 3 (Day 1 of ARUCS) in which return cycle begins. Credit Contras are debits with a transaction code of 17.

  • If the Contra has been submitted, ClearBank will receive the record on Day 4 (Day 2 of ARUCS), the BacsCreditContraReceived webhook will be sent, and by Day 5 (Day 3 of ARUCS), the TransactionSettled webhook will be sent to the originating account and the funds will be debited from the Suspense account and credited to the originator. In MPO process Inbound Direct Debit - Withdrawal [API] process is automatically triggered and a Withdrawal transaction is posted using a dedicated Transaction Channel based on the payment scheme: CB_Withdrawal_Bacs
  • If the Contra is not submitted, on Day 5 (Day 3 of ARUCS) BacsDebitPaymentNotSettled webhook will be sent with a specific transaction code/message.

In case the notification was set to true then a task will be created in Mambu/ZenDesk based on the configuration Notification Setup with a specific error message in order to be analyzed.

On initial creation, the status of the Credit Contra is Pending followed by the status Processed in short time. Once the status is changed, the TransactionSettled webhook is received, creating a Debit transaction in Client Money Account. This webhook will trigger in MPO the Inbound Direct Debit - Withdrawal [API] process which will create a Withdrawal transaction in Mambu for correspondent deposit account.

If the Deposit transaction cannot be posted to Mambu Deposit Account due to, deposit account state is invalid, a notification is sent based on the Notification Setup configuration and return process is initiated using as return code: 0 - Refer to payer. Since no corresponding Deposit(Credit) transaction exists in Mambu, TransactionSettled (Debit) webhook sent by ClearBank will not be processed since the original Credit transaction was proccesed only in ClearBank.

If the funds cannot be credited from Mambu Deposit Account due to, for example, incorrect date format a notification is sent based on the Notification Setup configuration. After the notification is analyzed it might need that the Deposit transaction be manually re-posted in Mambu using transaction channel CB_Deposit_Bacs since the payment is already done in ClearBank.

Important:

  • When a return is initiated (manual/automatic) but no corresponding Deposit (Credit) transaction exists in Mambu, when TransactionSettled (Debit) webhook is sent by ClearBank and received in MPO in order to balance the accounts, this webhook will not be processed since the original Credit transaction was proccesed only in ClearBank, therefore there is no need to balance Mambu accounts.
  • No funds are transferred with a contra, and, a contra cannot be declined or returned.
  • A contra has service user’s reference set to “CONTRA” on input and “BACS” on output.
  • The beneficiary and debtor account detailes of a contra are always identical and points to the main settlement account that is registered with Bacs.
  • For all sended credits a Credit Contra/Contra Record should exist (where the money has come from).

Inbound Direct Credit Held Payment

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

  • BacsDirectCreditInboundPaymentHeld:
    • False Positive -> payment released - TransactionSettled (Credit)
    • True Positive -> payment remains under investigation

ClearBank webhook BacsDirectCreditInboundPaymentHeld is triggered only when the payment should be monitored/investigated (Sanction Screening).

BacsDirectCreditInboundPaymentHeld webhook is stored in Retail Banking Payments state diagram. A notification is sent based on the Notification Setup configuration in Mambu/Zendesk with the following message:

Task created due to: Bacs transaction with ID: [f688dfa0-584e-22b9-4444-584301077bbb] and Reference: [d7eac213eb6143e0900c0cea2620ec8a] was Held. Transaction type: [BacsDirectCreditInboundPaymentHeld]. Transaction Code: [99]. Payment Reference: [d7eac213eb6143e0900c0cea2620ec8a]. Processing Date: [2019-04-01T00:00:00Z]. Payment Source: Bacs. Process ID: 705995.

If after the analysis the result is False Positive then the payment is automatically released by ClearBank, TransactionSettled webhook is sent (these are matched by the Reference and BacsTransactionId in ClearBank) and the Deposit transaction is automatically posted in Mambu.

In case the result is True Positive then the payment will be re-routed to the Suspense account until instructions are received.

Inbound Direct Debit Payment

This template allows collecting payments against Mambu deposit account from a payer who have completed a Direct Debit Instruction previously, using UK payment scheme Bacs (Bankers Automated Clearing Services).

Sequence diagram

ClearBank Retail Banking: Inbound Direct Debit

The process is automatically triggered when a Direct Debit payment is initiated from Bacs system and webhook TransactionSettled is received in MPO.

Bacs Direct Debit is a method of collecting/withdrawing payments from a deposit account against a Direct Debit Instruction created before. When a Service User wants to collect a payment from a payer account (Mambu account), the payer account should have sufficient amount in theirs Deposit account to send the money via ClearBank.

In order to do a Bacs Direct Debit payment, the service user needs to send the payer’s Sort Code, Account Number, the SUN number from the DDI with the appropriate transaction code.

The transaction code indicates the status of the Direct Debit collection:

  • 01 - For the first collection
  • 17 – For the collection of all Direct Debits (standard), i.e. not a first, final or re-presented Direct Debit
  • 18 – For re-presentations
  • 19 – For final collections
  • 99 – Debit contract (a credit record to balance debit record)

This flow can be executed using any of Mambu deposit product type for which Withdrawal transaction can be executed. Bacs payments work on a three day cycle, so the earliest date that the service user will collect a payment is three working days after it is submitted.

Bacs Direct Debit 3-day cycle (three consecutive working days):

  • Day 1: Input Day (entry date) -> Service User submits the payment to Bacs
  • Day 2: Processing Day/Contra Entry (processing date) -> BacsDirectDebitInboundPaymentCreated webhook is received
  • Day 3: Entry day (value date) -> TransactionSettled webhook is received (Debit) followed by Withdrawal transaction in Mambu

Standard Bacs Direct Debit transactions are identified by transaction code 17 in the Bacs input record.

For the negative cases when the payment was settled and TransactionSettled webhook is sent by ClearBank, but due to other issues the Withdrawal transaction was not posted in Mambu a notification is sent based on the Notification Setup configuration. After the notification is analysed and payments details are know then the Withdrawal needs to be manually posted in Mambu using the following transaction channel CB_Withdrawal_Bacs since the payment is already done in ClearBank.

Note:

  • The MPO process for Inbound Direct Debit payment will be triggered only when TransactionSettled webhhok is sent by ClearBank and received in MPO.
  • The Bacs Direct Debit services comes with an assurance to Direct Debit users that in case of an error, they can easily reclaim money that has been debited from them. There is no limit on the time between a Direct Debit collection and the reclaim or the amount (other than that is has to match the Direct Debit it’s reclaiming).

Inbound Direct Debit Returns

A Direct Debit transaction can be returned if there are insufficient funds in the Virtual Account or if there is an Instruction from the customer not to pay a transaction. If the 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.

Bacs Direct Debit returns (ARUDD) follow Bacs 3-day cycle:

  • Day 1: Input Day -> webhook BacsDirectDebitReturnCreated sent by ClearBank
  • Day 2: Procesing Day/Contra Entry
  • Day 3: Entry day:
    • -> success: webhook TransactionSettled sent by ClearBank (Credit) followed by Deposit transaction in Mambu
    • -> failure: webhook BacsDebitPaymentNotSettled sent by ClearBank (due to, for example Contra not received)

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.

ARUDD reason codes:

  • 0 - Refer to payer
  • 1 - Instruction cancelled
  • 2 - Payer deceased
  • 3 - Account transferred
  • 4 - Advance notice disputed
  • 5 - No account (OR wrong account type)
  • 6 - No Instruction
  • 7 - Amount differs
  • 8 - Amount not yet due
  • 9 - Presentation overdue
  • A - Service user differs
  • B - Account closed

Automatic Returns

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 one of these conditions was met,BacsDirectDebitReturnCreatedwebhook is sent by ClearBank and the payment is re-routed to Bacs Suspense account and then use the ARUDD process to return the funds.

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

Task created due to: Transaction in ClearBank was automatically Returned with: BacsTransactionId - 7244716a-0487-4593-b24d-20b74a252a61, TransactionID: [e08a08b7-2c0e-4aec-8fae-cfe4759bdba4], transaction Identifier Field Ref: 04062687167050MOREFUN2040626871670500000007500020200414 and End to End ID: [7244716a04874593b24d20b74a252a61] for Debit mandate ID: [91421kjad4d570c476550170d35fe2481514] with SUN: 520155. Task was created from MPO for payment scheme: Bacs, Transaction Type: DirectDebit. Process ID: 705941.

Manual Returns

If a Bacs Direct Debit payment cannot be applied to the destination account ClearBank sends an ARUDD message to the Service User and the funds will be credited from the Suspense account and debited to the originator.

ClearBank BacsDirectDebitReturnCreated webhook is triggered when a return is initiated on Day 3 (Day 1 of ARUDD) and sent to MPO with an appropriate reason code as to why the payment was unpaid. The ARUDD payments are identified by the following transaction codes:

  • U1 - Return of Unpaid DD – First Collection
  • U7 - Return of Unpaid DD – Regular Collection
  • U8 - Return of Unpaid DD – Re-Presented
  • U9 - Return of Unpaid DD – Final Collection

Once the return request has been generated, the funds will then transfer to the Bacs Suspense Account. This will trigger a TransactionSettled (Credit) webhook. The Contra record will need to be submitted on Day 3 (Day 1 of ARUDD) in which return cycle begins. Debit contras are credits with a transaction code of 99.

  • If the Contra has been submitted, ClearBank will receive the record on Day 4 (Day 2 of ARUDD), the BacsDebitContraReceived webhook will be sent, and by Day 5 (Day 3 of ARUDD), the TransactionSettled webhook will be sent to the originating account and the funds will be credited from the Bacs Suspense Account and debited to the originator. In MPO process Inbound Direct Credit - Deposit [API] process is automatically triggered and a Deposit transaction is posted using a dedicated Transaction Channel based on the payment scheme: CB_Deposit_Bacs
  • If the Contra is not submitted, on Day 5 (Day 3 of ARUDD) BacsCreditPaymentNotSettled webhook will be sent with a specific transaction code/message.

In case the notification was set to true then a task will be created in Mambu/ZenDesk based on the configuration Notification Setup with a specific error message in order to be analyzed.

On initial creation, the status of the Debit Contra is Pending followed by the status Processed in short time. Once the status is changed, the TransactionSettled webhook is received, creating a Credit transaction in Client Money Account. This webhook will trigger in MPO the Inbound Direct Credit - Deposit [API] process which will create a Deposit transaction in Mambu for correspondent deposit account.

If the Withdrawal transaction in Mambu cannot be posted due to insufficient funds or invalid deposit account state, the account holder requests the paid debit to be returned via API using as return code: 0 - Refer to payer. Since no corresponding Withdrawal(Debit) transaction exists in Mambu, TransactionSettled (Credit) webhook sent by ClearBank will not be processed since the original Debit transaction was processed only in ClearBank.

If the funds cannot be debited from Mambu Deposit Account due to, for example, incorrect date format a notification is sent based on the Notification Setup configuration. After the notification is analyzed it might need that the Withdrawal transaction be manually re-posted in Mambu using transaction channel CB_Withdrawal_Bacs since the payment is already done in ClearBank.

Important:

  • When a return is initiated (manual/automatic) but no corresponding Withdrawal (Debit) transaction exists in Mambu, when TransactionSettled (Credit) webhook is sent by ClearBank and received in MPO in order to balance the accounts, this webhook will not be processed since the original Debit transaction was processed only in ClearBank, therefore there is no need to balance Mambu accounts.
  • A contra looks similar to an ordinary payment, but its purpose and processing rules differ - a contra cannot be declined or returned.
  • The beneficiary and the originator of a contra are always identical and points to the main settlement account that is registered with Bacs.