Processing Bacs reports

FinDock processes incoming Bacs reports that are uploaded to Chatter for Bacs Manual targets or automatically fetched from SmartDebit targets. The Bacs reports are parsed and saved as Inbound Report records.

This article outlines the actions that FinDock carries out through Guided Matching managed rules. Additional custom Guided Matching rules can be added as needed.

Bacs report reconciliation is carried out in two phases:

ProcessingHub first tries to find and match related mandate and installment records for an incoming Bacs report using Id references and processing or collection dates.
FinDock then uses Guided Matching to handle report actions.

Processed inbound reports are assigned a specific status depending on the Guided Matching results. The status options are:

Matched: the report has been successfully processed and matched
Guided Review: the report type was identified and related rule set assigned
Failed: there was an error processing the report
Manual: the report type could not be identified and requires manual review

If you add custom Guided Matching rules, you should create a rule to update the inbound report status to one of the defined Guided Matching End States.

If no such rule is created, FinDock automatically updates the status of the inbound report to Matched as part of the Manage Source rule. This is only the case when you add your own custom rules. With the default Guided Matching rules, the inbound report status after Guided Matching is as defined in the following tables.

Input Report code handling

Input reports are generated on Day 1 (Input Day) of the Bacs 3-day collection cycle. They are an important source of information that needs to be processed as soon as possible.

Code	Reason	Actions by FinDock
E	Amended	Set status to Manual.
O	Returned	Set status to Manual.
Y	Rejected	Reverse installment and create negative payment.

AUDDIS reports

An Automated Direct Debit Instruction Service (AUDDIS) report arrives at different times in cycle and may include similar findings as input reports.

Code	Reason	Actions by FinDock
1	Instruction cancelled by payer	Set status to Manual.
2	Payer deceased	Cancel mandate.
3	Account transferred	Cancel mandate.
5	No account	Cancel mandate and deactivate payment profile.
6	No instruction	Set status to Manual.
7	DDI amount not zero	None. Contact FinDock Support.
B	Account closed	Cancel mandate.
C	Account transferred	Set status to Manual.
F	Invalid account type	Cancel mandate.
G	Bank will not accept Direct Debits on account	Cancel mandate.
H	Instruction has expired	Set status to Manual.
I	Payer reference is not unique	None. Contact FinDock Support.
K	Instruction cancelled by paying bank	Set status to Manual.
L	Incorrect payer's account details	Cancel mandate and deactivate payment profile.
M	Transaction code / user status incompatible	None. Contact FinDock Support.
N	Transaction disallowed at payers’ branch	Cancel mandate.
O	Invalid reference	None. Contact FinDock Support.
P	Payer's name not present	None. Contact FinDock Support.
Q	Service user's name blank	None. Contact FinDock Support.

AUDDIS mandate matching

For mandate matching, we use the following attributes of <MessagingAdvice> from AUDDIS and ADDACS reports.

For matching:
- reference to match against cpm__Mandate__c.cpm__Mandate_ID__c
For duplication protection (of cpm__Inbound_Report__c.cpm__Checksum__c):
- reference
- reason-code
- aosn

Here's an example of what that how the mandate matching works:

<MessagingAdvice
		user-number="123456"
		record-type="A"
		effective-date="**2009-07-28**"
		reference="**ABC1234567**"
		payer-name="payer"
		payer-account-number="12345678"
		payer-sort-code="000000"
		reason-code="1"
		aosn="**00000020**">
</MessagingAdvice>

FinDock searches for a cpm__Mandate__c record with cpm__Mandate_ID__c=ABC1234567. The duplicate check on cpm__Inbound_Report__c field cpm__Checksum__c=ABC1234567100000020. The checksum value is an md5 hash and not readable.

ADDACS reports

An Automated Direct Debit Amendment and Cancellation Service (ADDACS) report informs you of DDI amendments and cancellations. ADDACS reports can arrive at any time.

Code	Reason	Actions by FinDock
0	Instruction cancelled - refer to payer	Cancel mandate.
1	Instruction cancelled by payer	Cancel mandate.
2	Payer deceased	Cancel mandate.
3	Account transferred to a new bank or building society	Set status to Manual.
B	Account closed	Cancel mandate.
C	Account transferred to a new bank or building society	Set status to Manual.
D	Advance notice disputed	Set installment(s) status to On Hold.
E	Instruction amended	Set status to Manual.
R	Instruction re-instated	Activate mandate.

For ADDACS mandate matching, see above

ARUDD reports

An Automated Return of Unpaid Direct Debits (ARUDD) indicates a DDI could not be collected and includes the reason for the unpaid direct debit. Further information about these reason codes can be found from the Bacs Pay UK resources.

Code	Reason	Actions by FinDock
0	Refer to payer	Reverse installment.
1	Instruction cancelled	Cancel mandate and reverse installment.
2	Payer deceased	Cancel mandate and reverse installment.
3	Account transferred	Reverse installment.
4	Advance notice disputed	Reverse installment.
5	No account (OR wrong account type)	Reverse installment.
6	No instruction	Reverse installment.
7	Amount differs	Reverse installment.
8	Amount not yet due	Reverse installment.
9	Presentation overdue	Reverse installment.
A	Service user differs	Reverse installment.
B	Account closed	Cancel mandate and reverse installment.

ARUDD installment matching

ARUDD reports are matched to installments based on following attributes of the <ReturnedDebitItem> element in the report.

For matching:
- ref to match against cpm__Installment__c.cpm__Mandate_ID__c
- valueOf to match against cpm__Installment__c.cpm__Amount__c
- originalProcessingDate to match against:
  - cpm__Payment_Schedule__r.cpm__Bacs_Processing_Date__c
  - Or cpm__Payment_Schedule__r.cpm__Collection_date__c
For duplication protection (of cpm__Inbound_Report__c.cpm__Checksum__c):
- ref
- valueOf
- originalProcessingDate

Here is an example ARRUD entry and how it would be processed:

<ReturnedDebitItem
		ref="**ABC123456**"
		transCode="17"
		returnCode="0205"
		returnDescription="REFER TO PAYER"
		originalProcessingDate="**2009-07-24**"
		valueOf="**10.00**"
		currency="GBP">

Based on the example above, FinDock searches for a cpm__Installment__c record with:

cpm__Mandate_ID__c=ABC123456
AND cpm__Amount__c=10.00
AND
- (cpm__Payment_Schedule__r.cpm__Bacs_Processing_Date__c=2009-07-24
- OR cpm__Payment_Schedule__r.cpm__Collection_date__c=2009-07-24)

FinDock then also does a duplicate check on cpm__Inbound_Report__c field cpm__Checksum__c=ABC12345610.002009-07-24. The checksum value is an md5 hash and not readable.

DDIC reports

Direct Debit Indemnity Claim reports indicates a payer requested a payment refund under the Bacs Direct Debit Guarantee.

Code	Reason	Actions by FinDock
1	Amount and/or date of direct debit differs from advanced notice	Reverse installment.
2	No advance notice received by payer	Cancel mandate and reverse installment.
3	DDI cancelled by paying bank	Cancel mandate and reverse installment.
4	Payer has cancelled DDI direct with service user	Cancel mandate and reverse installment.
5	No instruction held, payer disputes having given authority	Cancel mandate and reverse installment.
6	Signature on DDI is fraudulent or not in accordance with account authorized signature(s)	Cancel mandate and reverse installment.
7	Claim raised at service users request after direct debit applied to payers account	Reverse installment if not already reversed.
8	Service user name disputed Payer does not recognize service user collecting Direct Debit	Reverse installment.

DDICA installment matching

For matching DDICA reports with installments, we use the following attributes of <DDCollection> under the <DDICAdvice> entry.

For matching:
- SUReference to match against cpm__Installment__c.cpm__Mandate_ID__c
- Amount to match against cpm__Installment__c.cpm__Amount__c
- DateOfDirectDebit to match against:
  - cpm__Payment_Schedule__r.cpm__Bacs_Processing_Date__c
  - Or cpm__Payment_Schedule__r.cpm__Collection_date__c
For duplication protection (of cpm__Inbound_Report__c.cpm__Checksum__c):
- SUReference
- Amount
- DateOfDirectDebit

Here's an example entry and how it is matched:

<DDICAdvice>
    <SeqNo>2018091200X000000000</SeqNo>
    <PayingBankReference>DDIC00000000000000</PayingBankReference>
    <SUNumber>000000</SUNumber>
    <PayingBankName>XXXXX UK plc</PayingBankName>
    <SUReference>**XX00000000**</SUReference>
    <ReasonCode>1</ReasonCode>
    <PayerSortCode>000000</PayerSortCode>
    <PayerAccount>00000000</PayerAccount>
    <PayerName>MR X X XXXX</PayerName>
    <NoOfAdvForClaim>1</NoOfAdvForClaim>
    <TotalAmount>800</TotalAmount>
    <DDCollections>
        <DDCollection>
						<DateOfDirectDebit>**2018-09-03**</DateOfDirectDebit>
            <Amount>**200**</Amount>
        </DDCollection>
        <DDCollection>

FinDock searches for a cpm__Installment__c record:

cpm__Mandate_ID__c=XX00000000
AND cpm__Amount__c=2.00
AND
- (cpm__Payment_Schedule__r.cpm__Bacs_Processing_Date__c=2018-09-03
- OR cpm__Payment_Schedule__r.cpm__Collection_date__c=2018-09-03)

Then, a duplicate check is performed on cpm__Inbound_Report__c field cpm__Checksum__c=XX000000002002018-09-03. As in other reports, the checksum value is an md5 hash and readable.