BACS - Inbound Payments

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 the return process is initiated using as return code: 0 - Refer to payer and a notification is sent based on the Notification Setup configuration. If the return process failed to be initiated, 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, otherwise, if the transaction needs to be returned, it shoud be manually returned using the ClearBank UI.

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 Credit Recall

A Bacs Direct Credit may be recalled (cancel 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 client behalf. A recalled Bacs Direct Credit will not be applied to client’s account.

Sequence diagram

ClearBank Retail Banking: Inbound Direct Credit Recalled

The process is automatically triggered when a Direct Credit payment is recalled from Bacs system and webhook BacsDirectCreditRecalled is received in MPO.

Since this means that the Direct Credit payment was cancelled, a notification is sent based on the Notification Setup configuration with the payment details send 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.

Notes:

  • When key monitorDirectCreditTransaction is set to true the transaction will be monitored and posted also in FinCrime module.

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 the return process is initiated using as return code: 0 - Refer to payer and a notification is sent based on the Notification Setup configuration. If the return process failed to be initiated, after the notification is analysed and payments details are known 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, otherwise, if the transaction needs to be returned, it shoud be manually returned using the ClearBank UI.

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.