The Direct Debit Schemes in a nutshell
The Direct Debit ( ) Core and the Business to Business (B2B) Schemes developed by the European Payments Council ( ) - like any other direct debit schemes - are based on the following concept: 'I request money from someone else, and, with his prior approval, I can credit it to myself'. For the first time ever, the Schemes enable consumers to make cross-border direct debit payments throughout the 32 Single Euro Payments Area ( ) countries1. At the same time, the Schemes can of course be used domestically. The payer and the biller2 must each hold an account with a payment service provider ( ) located within . The accounts may be held in either euro or in any other currency. The transfer of funds (money) between the payer's bank3 and the biller's bank always takes place in the euro currency. Currency conversion aspects are out of scope of the schemes.
For more information on the Schemes, refer to the publication 'Shortcut to Direct Debit' (see 'related links' below). This four page publication summarises the main features of the Schemes in non-technical terms, including their key benefits. Detailed information on the Schemes is available on the Website (see 'related links' below).
Exception handling under the Schemes
In the fifth article of this series about specific aspects of the Schemes, relevant in particular to billers preparing for migration to , the processes and timelines applicable to refunds, returns, rejects, reversals, revocations and requests for cancellation (commonly referenced as R-transactions) are explained in detail. It should be noted that some of these processes are not mandatory in the schemes. This article addresses processes which are mandatory in the schemes as well as relevant optional features. To facilitate the understanding of R-transactions as detailed in the Core and B2B Rulebooks, the following terms need to be introduced:
- Due date: the Schemes allow payers and billers 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'4. The settlement date is the day on which settlement takes place; i.e. the day when the funds are transferred between the bank 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. The Schemes specify reasons which however prevent a direct debit from being executed as outlined above; i.e. triggering an R-transaction.
Factors which trigger an R-transaction
The Schemes include data elements required to convey information to the payee with regard to the R-transaction. These data elements, which are referred to as 'reason codes' in the Rulebooks, specify the type of the R-transaction; name the initiator of the R-transaction; and detail the reason for the R-transaction.
An R-transaction may be triggered due to:
- Technical reasons:
- 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. (A mandate is signed by the payer to authorise the biller to collect a payment and to instruct the biller's bank to pay those collections).
- 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.
- 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 32 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. It should be noted that the 'Regulation establishing technical and business requirements for credit transfers and direct debits in euro' (the Regulation) obliges payer's banks to offer certain mandate management features if requested by the payer).
It should be noted that for legal reasons, in some countries the payer's bank might not be able to disclose all of the reason codes listed above (such as the reason 'insufficient funds') to the payee and its bank. Due to the different characteristics of the B2B Scheme, some of the technical reasons listed above do not apply to B2B direct debits.
- A refusal of the payer:
In the event of a refusal, the payer instructs its bank not to pay the direct debit. The payer may refuse the collection when:
- The direct debit collection is unauthorised, i.e. no mandate was issued.
- An authorised transaction is disputed. This may be the case if, for example, the payer disputes the specific amount of the collection.
The payer's refusal of the direct debit collection takes place in the customer-to-bank space. In the inter-bank space, refusals in practice become either a reject, return or a refund, depending on whether the payer's refusal is handled before settlement (reject), up to five banking business days after settlement (return) or after five banking business days following settlement (refund).
One of the main benefits of the Schemes is that the scheme rules facilitate standardised exception handling both at the process level and the dataset level. This allows straight-through-processing and automated handling of R-transaction end-to-end.
Definitions: rejects, returns, refunds, reversals, revocations and requests for cancellation
The Schemes identify and describe in detail the following R-transactions which must be supported by all scheme participants; i.e. banks which have formally adhered to the schemes, and handled according to the scheme rules:
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.
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 (see 'Factors which trigger an R-transaction' above). An example of this is when a payer communicates a refusal (see above) of the direct debit to its bank too late to allow the bank of the payer to send a reject message prior to settlement.
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.
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 mandate. 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.
The following R-transaction types are also defined in the Schemes however, are not covered by the scheme rules; i.e. banks are not obliged to offer these features. These features can be offered by the biller's bank to the biller or by clearing and settlement mechanisms (CSMs)5 to the biller's bank on an optional basis:
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. Again, 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.
Revocations: these are requests by the biller to recall an instruction for a direct debit up to a date agreed with the bank of the biller. Billers should contact their bank to agree on the practical use of this optional feature. As stated above, the use of this feature is not covered by the Scheme rules.
Requests for cancellation: Instructions by the bank of the biller to recall the instruction for a direct debit prior to settlement is a request for cancellation. Billers should contact their bank to agree on the practical use of this optional feature. As stated above, the use of this feature is not covered by the Scheme rules.
Javier Santamaría is the Chair of the Payment Schemes Working Group. Herman Segers is a former Secretary General of the and also served as the editor of the Rulebooks for many years.
Related articles in this issue:
Related articles in previous issues :
SEPA Direct Debit for Billers: the SDD Business to Business Timelines ( Newsletter, Issue 13, January 2012)
SEPA Direct Debit for Billers: the SDD Core Scheme Timelines ( Newsletter, Issue 12, October 2011)
SEPA Direct Debit for Billers: the Creditor Identifier (Go Get It!) ( Newsletter, Issue 11, July 2011)
SEPA Direct Debit for Billers: The SDD Mandate ( Newsletter, Issue 10, April 2011)
The Quantum Leap for SEPA Direct Debit. From 1 November 2010, all banks in the euro area are reachable for SEPA Core Direct Debit ( Newsletter, Issue 8, October 2010)
Have it Your Way! The EPC e-Mandate option: a secure way to authorise a SEPA Direct Debit payment ( Newsletter, Issue 6, April 2010)
Refunds and Returns Revisited. Questions and answers on the correlation between the PSD and the SDD Schemes ( Newsletter, Issue 4, October 2009)
Creditors: Help is Here. EPC introduces rules on the use of legacy mandates under the SDD Scheme ( Newsletter, Issue 2, April 2009)
1 currently consists of the 27 Member States plus Iceland, Liechtenstein, Norway, Monaco and Switzerland.
2The technical terms used in the Scheme Rulebooks refer to the payer as 'debtor' and to the biller as 'creditor'.
3The term bank is used in a non-discriminatory fashion and does not exclude payment service providers which are not banks.
4Committee on Payment and Settlement Systems. http://www.bis.org/publ/cpss00b.pdf.
5The term payment system as defined in the PSD, 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 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.