Recap: executing a Direct Debit collection
The Direct Debit () Core and Business to Business (B2B) Rulebooks detail the process of executing an collection based on the following terms:
Due date: the Schemes allow payers and billers1 to anticipate the precise date (due date), when their account will be debited or credited, respectively. The due date is assigned by the biller and should be agreed with the payer in the contract underlying a direct debit collection (a newsletter subscription, for example).
Settlement date: settlement is “an act that discharges obligations in respect of funds or securities transfers between two or more parties”2. The settlement date is the day on which settlement takes place; i.e. the day when the funds are transferred between the bank3 of the payer and the bank of the biller.
Debit date: the day on which the payer’s account is debited.
Inter-bank business day: a day when banks are open for business between banks. The ‘Trans-European Automated Real-time Gross Settlement Express Transfer System’ (TARGET) calendar is used to identify inter-bank business days. To avoid frequent changes to TARGET closing days, due to national holidays for example and thus the introduction of uncertainties into financial markets, a long-term calendar for TARGET closing days has been established and applied since 2002. This calendar is published by the European Central Bank.
On the due date, the account of the payer is debited and the amount of the payment presented by the biller’s bank is settled, i.e. the funds are automatically transferred from the bank of the payer to the bank of the biller. Settlement of funds, resulting from direct debit payments, always takes place on an inter-bank business day. As from the due date; the bank of the biller can credit the account of the biller, according to the agreement between the biller and his bank.
Exception handling: refunds, returns, rejects, refusals and reversals (R-transactions)
Possible exceptions to the normal execution of a direct debit collection include refunds, returns, rejects, refusals and reversals (commonly referenced as R-transactions):
Refunds: the Core Scheme goes beyond the requirements of the Payment Services Directive (PSD), by granting consumers a ‘no-questions-asked’ refund right during the eight weeks following the debiting of a consumer’s account. This means that during this time, any funds collected by will be credited back to the consumer’s account upon request. The bank of the biller is entitled to recover the amount of this refund from the biller, in accordance with its terms and conditions agreed with the biller. In the B2B Scheme, the payer (a business) is not entitled to obtain a refund of an authorised transaction.
In the event of unauthorised direct debit collections, the consumer’s right to a refund extends to 13 months as stipulated in the PSD. This means that, according to the payer, the direct debit was not covered by a valid mandate4. The payer must present the claim to its bank. The bank of the payer will need to evaluate if the direct debit may be considered as unauthorised. If required, the bank of the payer will request a copy of the original mandate from the biller through the bank of the biller to support its examination of the claim. The bank of the payer will communicate its decision to the payer. If the refund request is accepted, the payer is credited and the refund is presented to the bank of the biller. The decision of the payer's bank on a refund claim is final for all parties in the scheme.
Returns: an R-transaction triggered up to five inter-bank business days after settlement is a return. A return may be due to technical reasons or due to the bank of the payer not being able to accept the direct debit for other reasons. Since the settlement of the funds has already taken place at inter-bank level, the Scheme rules provide a contractual entitlement for the bank of the payer to recover the amount of this return from the bank of the biller, in accordance with its terms and conditions with the biller. If the biller has already been credited by the bank of the biller, the biller will have to be debited for the undue credit. In the B2B Scheme, a return can only be initiated up to two inter-bank business days after settlement.
Rejects: an R-transaction triggered prior to settlement is a reject. In this case, the settlement did not yet take place, i.e. no funds have been exchanged between the bank of the payer and the bank of the biller. The execution of the direct debit collection is stopped. The direct debit is rejected without any financial impact on the banks involved. The bank of the biller will communicate this rejection of the direct debit to the biller.
Refusals: claims initiated by the payer before settlement, for any reason, requesting its bank not to pay a collection. By way of derogation from Article 66 of the PSD, the time period for a refusal of a collection also includes the due date. The refusal must be handled by the payer’s bank in accordance with the conditions agreed with the payer. The payer’s bank should handle the refusal claim by preference prior to inter-bank settlement, resulting in a reject. If handled after settlement, a refusal is referred to as a return.
Reversals: if the biller concludes after settlement that a direct debit should not have been processed, the biller may initiate a reversal to reimburse the payer with the full amount of the erroneous direct debit. Billers, however, are not obliged to use the reversal facility. Reversals may also be initiated by the bank of the biller for the same reasons. Banks of billers are not obliged to offer the reversal facility to billers. Banks of payers must, however, handle reversals initiated by billers or by banks of billers. Banks of payers do not have to carry out any verification on reversals received. Billers should contact their bank to agree on the practical use of this optional feature in the market where their customers are operating.
It should also be kept in mind that Article 5 (3) d of the ‘Regulation () No 260/2012 establishing technical and business requirements for credit transfers and direct debits in euro’ (the Regulation), states that the payer must have the right to instruct its payment service provider ():
- To limit a direct debit collection to a certain amount or periodicity or both.
- Where a mandate under a payment scheme does not provide for the right to a refund, to verify each direct debit transaction, and to check whether the amount and periodicity of the submitted direct debit transaction is equal to the amount and periodicity agreed in the mandate, before debiting their payment account, based on the mandate-related information.
- To block any direct debits to the payer's payment account or to block any direct debits initiated by one or more specified payees or to authorise direct debits only initiated by one or more specified payees.
With regard to the latter, this means: a consumer may instruct its to block all direct debits to its account or to ‘black list’ a specified biller by blocking direct debits initiated by it. Similarly, under Article 5 (3) (d) a payer may instruct its to only allow collections from a biller identified in a ‘white list’. These mandate checking obligations do not apply to the B2B Scheme.
The Core and B2B Rulebooks specify reason codes identifying the cause of an R-transaction
The Core and B2B Rulebooks specify reasons which trigger an R-transaction, i.e. data elements required to convey information to the payee (biller) with regard to the R-transaction. These data elements, which are referred to as ‘reason codes’, specify the type of R-transaction; name the initiator of the R-transaction; and detail the reason for the R-transaction. This means: in the event of a failed collection, the payer’s bank must send a message to the biller’s bank which includes the correct reason code so that the biller’s bank can inform the biller accordingly. This allows the biller to determine his or her reaction with regard to the outstanding payment.
In some cases, the biller will be able to re-send the direct debit collection a few days later (for example, if there were insufficient funds) or contact the payer for more information (for example, if the payer’s account is closed).
The Rulebooks specify reason codes related to the following circumstances which may trigger an R-transaction:
- Operation / transaction code is incorrect.
- Invalid file format or bank identifier is incorrect (i.e. invalid Business Identifier Code).
- Account identifier is incorrect (i.e. invalid International Bank Account Number).
- Mandate data is missing or incorrect.
- Duplicate collection.
The status of the payer’s account:
- Account is closed.
- Payer is deceased.
- It is prohibited to collect direct debits from the account due to regulatory reasons.
- Account is blocked.
- Insufficient funds.
- No mandate was issued.
- Account is blocked for direct debits by the debtor (payer).
- Creditor identifier is incorrect. (Billers collecting payments under the Schemes are obliged to obtain a creditor identifier which relates to a legal entity, an association, or a person assuming the role of the biller. This ensures that each biller collecting payments under the Schemes within and across the countries is unambiguously identifiable.)
- Specific service offered by the payer’s bank. (A payer's bank may offer specific mandate management features to the payer such as, for example, verification that a collection by a given biller does not exceed the maximum amount defined by the payer as regards collections by this biller. As mentioned above, the Regulation obliges payer's banks to offer certain mandate management features if requested by the payer).
Due to the different characteristics of the B2B Scheme, some of the technical reasons listed above do not apply to B2B direct debits.
publishes ‘Guidance on reason codes for R-transactions’
The correct application of reason codes by a debtor bank, (the bank of the payer), informing a creditor bank, (the bank of the biller) about a failed collection is crucial to allow the biller to determine its reaction. Scheme participants, i.e. that have formally adhered to the schemes, are therefore reminded to apply the specific R-transaction reason codes described in section 4.4, respectively, of the Core and B2B Rulebooks when reporting a failed collection. scheme participants should avoid the use of general codes when a more precise reason can be given which is not legally forbidden in the debtor bank country.
In July 2014, the European Payments Council () published the document ‘Guidance on reason codes for R-transactions’ (see ‘related links’ below). This paper addresses, among others, the following scenarios:
There are some restrictions in the use of R-transaction reason codes due to national legislation, (e.g. data protection laws), in e.g. Austria, Belgium, Germany, Luxembourg, Netherlands, Slovakia and Slovenia.
The debtor bank or communities of debtor banks could use different R-transaction reason codes in specific situations:
- An R-transaction having different basic reasons (e.g. insufficient funds, debtor (payer) account closed or no valid mandate existing).
- The level of control related to the risk policies and the ‘know-your-customer’ (KYC) principles of the debtor bank. The debtor bank decides whether it makes a check on the sequence type5 or creditor identifier and whether an collection should be rejected accordingly.
- An R-transaction could be the result of a limitation for collections to a certain amount and / or periodicity or check on creditors (billers), e.g. an ‘authorisation/stop payment’ feature, implemented as a consumer protection mechanism in line with Article 5 (3) (d) of the Regulation.
Section 4 of the paper provides guidance to scheme participants about the reason codes to be used to report specific collection issues.
The document also reiterates the timelines to be observed with the handling of R-transactions in line with the scheme rules. Last but not least, scheme participants are reminded that they must channel rejects, returns and refunds of collections through the same clearing and settlement mechanism6 used for clearing and settlement of the initial collection unless otherwise agreed between the scheme participants.
Jean-Yves Jacquelin is the Chair of the Payment Schemes Working Group.
Related article in this issue:
Related articles in previous issue:
1 The technical terms used in the Scheme Rulebooks refer to the payer as ‘debtor’ and to the biller as ‘creditor’.
2 Committee on Payment and Settlement Systems. http://www.bis.org/publ/cpss00b.pdf.
3 The term bank is used in a non-discriminatory fashion and does not exclude payment service providers which are not banks.
4 A mandate is signed by the payer to authorise the biller to collect a payment and to instruct the payer’s bank to pay those collections.
5 The Rulebooks require that the payment message used to request a direct debit collection specifies whether the transaction is a first, one-off, recurrent or last collection. These specifications are also referred to as ‘sequence types’.
6 The term payment system as defined in the Payment Services Directive, means a funds transfer system with formal and standardised arrangements and common rules for the processing, clearing and / or settlement of payment transactions. In other words, a funds transfer system enables the exchange of funds (money) and messages between two payment service providers () executing a payment transaction. These funds transfer systems can be as well as separate business - public or private - entities (which may or may not be owned by banks). In the SEPA context, a payment system in the meaning of a 'funds transfer system' is referred to as a 'Clearing and Settlement Mechanism' (CSM).
If you would like to comment on this article, please identify yourself with your first and last name. Your name will appear next to your comment. Email addresses will not be published. Please note that by accessing or contributing to the discussion you agree to abide by the EPC website conditions of use.