Issue 14 - April 2012
SEPA Credit Transfer (SCT) & SEPA Direct Debit (SDD)
SEPA Direct Debit for Billers: Exception HandlingEPC Newsletter series provides support for billers preparing migration to the SDD Schemes
27.04.12 By Javier Santamaría and Herman Segers
This is the fifth article in a series which provides information on specific aspects of the SEPA Direct Debit (SDD) Schemes, relevant in particular to billers preparing for migration to SDD. In this context, the European Payments Council (EPC) invites readers to be mindful of the 'Regulation (EU) No 260/2012 establishing technical and business requirements for credit transfers and direct debits in euro' (the SEPA Regulation), which defines 1 February 2014 as the deadline in the euro area for compliance with the core provisions of this Regulation. Effectively, this means that as of this date, existing national euro credit transfer and direct debit schemes will be replaced by SEPA Credit Transfer and SDD. In this article, Javier Santamaría and Herman Segers detail the processes and timelines applicable to refunds, returns, rejects, reversals, revocations and requests for cancellation (commonly referenced as R-transactions).
Key Information in this Article
One of the main benefits of the SEPA Direct Debit (SDD) Schemes is that the scheme rules streamline exception handling, both at the process level and the dataset level. This allows straight-through-processing and automated exception handling end-to-end.
Scroll to the end of the page and post a comment.
The SEPA Direct Debit Schemes in a nutshell
The SEPA Direct Debit (SDD) Core and the SDD Business to Business (B2B) Schemes developed by the European Payments Council (EPC) - 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 SDD Schemes enable consumers to make cross-border direct debit payments throughout the 32 Single Euro Payments Area (SEPA) countries1. At the same time, the SDD Schemes can of course be used domestically. The payer and the biller2 must each hold an account with a payment service provider (PSP) located within SEPA. 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 SDD Schemes, refer to the EPC publication 'Shortcut to SEPA Direct Debit' (see 'related links' below). This four page publication summarises the main features of the SDD Schemes in non-technical terms, including their key benefits. Detailed information on the SDD Schemes is available on the EPC Website (see 'related links' below).
Exception handling under the SDD Schemes
In the fifth article of this series about specific aspects of the SDD Schemes, relevant in particular to billers preparing for migration to SDD, 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 SDD Core and SDD B2B Rulebooks, the following terms need to be introduced:
- Due date: the SDD 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 SDD 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 SDD 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 SDD 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 SDD 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 SDD Schemes within and across the 32 SEPA 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 SEPA 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 SEPA 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 SDD 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 SDD 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 SDD 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 SDD 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 SDD B2B Scheme, a return can only be initiated up to two inter-bank business days after settlement.
Refunds: the SDD 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 SDD 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 SDD 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 SDD 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 SDD 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 SDD Scheme rules.
Javier Santamaría is the Chair of the EPC SEPA Payment Schemes Working Group. Herman Segers is a former Secretary General of the EPC and also served as the editor of the SDD Rulebooks for many years.
Related articles in this issue:
Related articles in previous issues :
SEPA Scheme Rulebooks: Next Edition Available in November 2011! The EPC publishes new versions of the SEPA Credit Transfer and SEPA Direct Debit Rulebooks (EPC Newsletter, Issue 12, October 2011)
SEPA Direct Debit for Billers: the SDD Business to Business Timelines (EPC Newsletter, Issue 13, January 2012)
SEPA Direct Debit for Billers: the SDD Core Scheme Timelines (EPC Newsletter, Issue 12, October 2011)
SEPA Direct Debit for Billers: the Creditor Identifier (Go Get It!) (EPC Newsletter, Issue 11, July 2011)
SEPA Direct Debit for Billers: The SDD Mandate (EPC 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 (EPC Newsletter, Issue 8, October 2010)
Have it Your Way! The EPC e-Mandate option: a secure way to authorise a SEPA Direct Debit payment (EPC Newsletter, Issue 6, April 2010)
Refunds and Returns Revisited. Questions and answers on the correlation between the PSD and the SDD Schemes (EPC Newsletter, Issue 4, October 2009)
Creditors: Help is Here. EPC introduces rules on the use of legacy mandates under the SDD Scheme (EPC Newsletter, Issue 2, April 2009)
1SEPA currently consists of the 27 EU Member States plus Iceland, Liechtenstein, Norway, Monaco and Switzerland.
2The technical terms used in the SDD 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 (PSPs) executing a payment transaction. These funds transfer systems can be PSPs 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).
Other articles in this issue
27.04.12 EPC Scheme Change Management: Annual Public Consultation Starts in May 2012 - All stakeholders are invited to provide feedback on possible changes to the SEPA payment schemes By Etienne Goosse 27.04.12 EPC Plenary Meeting Update: EPC Elects New Chair Javier Santamaría and Vice Chair Günther Gall to Take Office in June 2012 - Each edition of the EPC Newsletter reports on main decisions taken by the EPC Plenary By Etienne Goosse 27.04.12 The History and Vision of CBI - The EPC Newsletter series provides an overview of banking communication standards in Europe By Liliana Fratini Passi 27.04.12 The Time to Act is Now: Impact of the SEPA Regulation on Payment Service Users - The SEPA Regulation includes provisions relevant for both the demand and supply sides of the payments market By Dermot Turing and Maria Troullinou 27.04.12 Challenges and Opportunities: 'The Social Media in Payments Report 2012' - Latest research provides insight on the industry´s approach to new digital communication channels By Simon Hardie 27.04.12 SEPA Migration: Facts and Figures - The state-of-play in April 2012 By Etienne Goosse 27.04.12 Early Movers Confirm: ISO 20022 Message Standards Generate Tangible Benefits - A guide for payment service users on the impact of provisions in the SEPA Regulation regarding the use of the ISO 20022 message standards By Francis De Roeck 27.04.12 On Innovation: What the European Union Could Learn from Apple and Facebook - Reflections on the evolution of SEPA in the new regulatory reality governing the euro payments market By Javier Santamaría 27.04.12 Step Up to the Challenge: SWIFT White Paper Sets out Steps to Build a SEPA Migration Plan - A strategy to achieve SEPA compliance by 1 February 2014 By Gottfried Leibbrandt and Harry Newman 27.04.12 Villeroy & Boch: "The Long Term Benefits of SEPA Exceed the Short Term Efforts to Get There." - The group completed migration to SEPA Credit Transfer in 2008 and migration to SEPA Direct Debit in 2011 By Dr Markus Warncke (Interview)
If you would like to comment on this article, please use the box under the headline 'Add New Comment' below. Please identify yourself with your first and last name. Please note that 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 Newsletter Terms and Conditions, so please read them carefully before doing so.
To receive notification when a new comment is added to this specific discussion, please subscribe to get updates by email or RSS using the links below. (These links are not available on the mobile version of the EPC Website, to subscribe by email or RSS, please visit the standard version of the EPC Website).