SEPA Direct Debit: SDD

A direct debit is a pull payment. The creditor pulls money from the debtor account, but only because the debtor signed a mandate first. It is the standard way Europe collects utility bills, insurance premiums, subscriptions, and loan instalments. There are two variants. The Core scheme is open to all customers, and the B2B scheme is built for business debtors and has different refund rules. The distinction matters in every requirement, because a product that applies Core refund rules to a B2B collection is in breach of the scheme. The mandate is the legal heart of the scheme. A mandate carries a unique reference, the creditor identifier, the debtor name and IBAN, and the signature date. The debtor can sign on paper or electronically, and the creditor must store the mandate and produce it if disputed. The debtor can cancel a mandate at any time. A mandate with no collection for 36 months lapses, and a collection presented without a valid mandate is unauthorised and must be refunded. The analyst must design mandate storage, retrieval, amendment and cancellation as first class features, because the mandate is the evidence that the collection was authorised, and a creditor that cannot produce the mandate loses the dispute. Follow one collection end to end. A utility company in the Netherlands collects 89.50 euro a month from a customer in Belgium for electricity. The customer signed a mandate two years ago with reference UTI-2024-11877, and the utility stores it. Fourteen days before the due date, the utility sends a pain.008, a customer direct debit initiation, to its own bank, ahead of the due date. The message carries the mandate reference, the sequence type, first, recurrent, final, or one off, the due date, and the amount. The creditor bank checks the mandate reference, the creditor identifier, and the format. The sequence type is recurrent, because this is a monthly collection after the first one. The creditor bank sends a pacs.003 to the debtor bank. The interbank collection is a pacs.003, a financial institution to financial institution direct debit. It travels through the clearing system to the debtor bank, which checks the mandate data and debits the account on the due date. In the B2B scheme the debtor bank must verify the mandate before it debits, because the business debtor gives up the refund right in exchange. The creditor bank credits the creditor once the collection settles. The debit and credit entries are simple: the debtor's account is debited 89.50 euro, the debtor bank's settlement account is credited, the clearing system moves the net position, and the creditor's account is credited 89.50 euro in full. The presentation timeline is a rule, not a suggestion. For a first, one off or subsequent collection, the pain.008 must reach the creditor bank at the soonest 14 calendar days and at the latest 1 business day before the due date. A collection presented too late is rejected, and a collection presented too early is also rejected, because the debtor bank needs time to check the mandate and the debtor needs time to see the collection coming. The analyst must build the presentation calendar into the product: the due date drives the presentation date, and the presentation date drives the file generation date, and a public holiday in either country shifts the whole chain. Rejects stop a collection before the due date. When the debtor bank cannot process a collection, it reports a pacs.002 with status RJCT and a reason code. The common codes are MD01 for no mandate, MD02 for mandate data that is missing or wrong, AC04 for a closed account, AG01 for a forbidden transaction, and MS02 or MS03 where no specific reason is given. The creditor must fix the mandate data or contact the debtor. A reject with MD01 is a data problem: the mandate reference in the pain.008 does not match any mandate the debtor bank holds, and the creditor must check the reference before presenting again. A reject with AC04 means the debtor has closed the account, and the creditor needs new bank details. Returns send the money back after the debit. A return happens when the debit has settled but the money cannot stay debited, and it travels back as a pacs.004. The usual reason codes are AM04 for insufficient funds, AC04 for a closed account, AC06 for a blocked account, and MD07 for a deceased debtor. The creditor must decide whether to retry, contact the debtor, or use another method, and the reason code makes that decision possible. An AM04 return is worth retrying after the debtor is paid; an AC04 return is not, because the account is gone. The analyst must map each return code to a retry rule, a contact rule and a write off rule, so the collections team does not retry a closed account five times. Refunds are a right in Core, and not in B2B. In the Core scheme the debtor can claim a refund of an authorised collection within eight weeks of the debit date, with no reason needed, under reason code MD06. For an unauthorised collection the debtor has thirteen months to claim. The debtor bank must refund immediately and then recover the money from the creditor bank, which debits the creditor. In the B2B scheme there is no refund right for authorised collections, because the debtor bank verified the mandate before debiting. The analyst must build two different refund flows, one for each scheme, and must make sure the product never offers a Core refund on a B2B collection. Reversals correct the creditor's own mistakes. When a creditor collects the wrong amount or collects twice, it reverses the collection itself with a pain.007 to its bank, which sends a pacs.007, a payment reversal, to the debtor bank. The usual reason codes are AM05 for a duplicate collection and MS02 or MS03 for other creditor errors. A reversal must be sent shortly after the original collection, inside the window the rulebook sets. The analyst must distinguish a reversal from a refund: a reversal is the creditor admitting its own error, a refund is the debtor exercising a right, and the two travel through different messages with different timelines. A worked example at scale shows why the codes matter. The utility collects from 40,000 customers a month, 3.58 million euro in total. In a typical month it sees 120 returns: 70 with AM04 for insufficient funds, 30 with AC04 for closed accounts, 15 with MD07, and 5 with AC06. The 70 AM04 returns are retried once after payday, and half succeed. The 30 AC04 returns trigger a letter asking for new bank details. The 15 MD07 returns close the accounts and stop further collections. Without the reason codes, the collections team would treat all 120 the same way and would retry closed accounts and write off collectable ones. With the codes, each return has a defined action, and the analyst can report the return rate by code to management. R-transactions are the analyst checklist. Rejects, refusals, returns, refunds, reversals, and revocations are called R-transactions, and every one of them has a message and a reason code defined in the rulebook. The analyst turns that list into screens, files, reconciliation reports, and customer messages. A collection with no matching status message is one nobody is watching, and an unmapped reason code becomes a call to the service desk. The complete R-transaction list, with the message for each one and the code for each reason, should be an appendix to the requirements document, and every code in it should have a test case. What the analyst must check before go live. The checklist has five items. Mandate storage and retrieval must work, including amendments and cancellations. Sequence types must be set correctly, first, recurrent, final, or one off. Due date lead times must follow the rulebook. Refund handling must differ between Core and B2B. And every reason code must map to a clear action and a clear message. A product that gets any of these wrong fails one collection at a time, and a direct debit product that fails one collection at a time loses customers one at a time.