SEPA Direct Debit for Analysts: Mandates, pacs.003, and R-Transactions

A SEPA Direct Debit (SDD) is a euro payment pulled by the creditor under a mandate the debtor signed, sent as pain.008 to the creditor’s bank and as pacs.003 between banks. Almost all of the analysis work sits in the mandate keys and the five R-transactions: reject, refusal, return, refund, and reversal, each with its own message, initiator, and deadline. SDD Core gives consumers an eight-week no-questions refund; SDD B2B removes it and makes the debtor bank check the mandate instead.

Direct debits invert everything an analyst learns on credit transfers. The money moves towards the party that sent the instruction. The debtor never sends anything. The bank that debits the account has, in Core, no obligation to check that a mandate exists at all, and protects its customer after the fact with a refund right that lasts eight weeks. Specify an SDD flow by analogy with SEPA Credit Transfer and you will get the happy path right and most of the exception paths wrong.

This sits in the schemes track of The ISO 20022 Reference, next to SEPA Credit Transfer. It assumes you know the pain versus pacs split and focuses on what is specific to direct debits.

Which rulebook version applies right now?

Current as of October 2026: the SDD Core rulebook in effect is the 2025 SDD Core rulebook version 1.2, and the SDD B2B rulebook in effect is the 2025 SDD B2B rulebook version 1.2. Both were published on 30 September 2026 and replaced version 1.1. Version 1.2 does one thing: it postpones the end date after which unstructured addresses are no longer permitted. The EPC had set that date to 22 November 2026, then moved it to 15 November 2026, and in September 2026 delayed it without setting a new one. No other business or operational rule changed. The address story is covered in structured addresses.

The implementation guidelines for the 2025 rulebooks are built on the 2019 ISO 20022 message versions:

Leg	Message	Purpose
Creditor to creditor bank	pain.008.001.08	Collection initiation
Creditor bank to creditor	pain.002.001.10	Status and rejects
Creditor to creditor bank	pain.007.001.09	Reversal request
Bank to bank	pacs.003.001.08	The inter-PSP collection
Bank to bank	pacs.002.001.10	Reject before settlement
Bank to bank	pacs.004.001.09	Return or refund after settlement
Bank to bank	pacs.007.001.09	Reversal

What is coming: the next regular SDD rulebooks will not take effect before the end of the third quarter of 2028, aligned with the EU Payment Services Regulation. Among the accepted changes are Name elements extended from 70 to 140 characters, a new FR01 reason code for reject, return, and refund of a possibly fraudulent collection, and usage rule changes on organisation and private identification to align with the Funds Transfer Regulation, covered in the travel rule article. Put a named owner on that release.

What is the mandate, and which fields are permanent keys?

The mandate is the debtor’s authorisation for the creditor to collect and for the debtor’s bank to debit. In SDD Core it lives with the creditor: the creditor stores it, and dematerialises its data into every collection. The debtor bank receives the mandate data inside the pacs.003 and, in Core, is not obliged to check it against anything.

Two identifiers carry the mandate through its life.

The Unique Mandate Reference (UMR), rulebook attribute AT-M001, sent in MndtRltdInf/MndtId. Up to 35 characters, and the implementation guidelines say it is case insensitive: 123AAa45678 and 123AAA45678 are the same mandate. Your duplicate checks and mandate lookups have to respect that.

The Creditor Identifier (CI), attribute AT-E005, sent in CdtrSchmeId. Its structure is fixed:

DE98ZZZ09999999999
DE        positions 1-2   ISO country code of the issuing country
98        positions 3-4   check digits, MOD 97-10 over country + national part
ZZZ       positions 5-7   Creditor Business Code ("ZZZ" when unused)
0999...   positions 8-35  national identifier

The rule that matters: the UMR combined with the CI without the business code must let anyone retrieve the mandate indefinitely. The business code is excluded from the check digit and the creditor may change it for business reasons. A system that keys mandates on the full 35-character CI breaks the first time a creditor reorganises its business lines.

Two other mandate rules generate defects:

• 36 months of inactivity. If a creditor presents no collection under a mandate for 36 months, counted from the last collection even if it was rejected, returned, or refunded, the creditor must cancel the mandate. The rulebook does not oblige the banks to check this; it is the creditor’s obligation, so it belongs in the creditor’s requirements.
• Pre-notification. The creditor must notify the debtor of the amount and date at least 14 calendar days before the due date unless they agreed another timeline. An amount mismatch between pre-notification and collection is a listed root cause behind MD06 refunds.

How is a mandate amendment carried?

There is no separate amendment message. The creditor accepts the change, then sends the new data in the next collection with AmdmntInd set to true and the original values under AmdmntInfDtls.

What changed	Element under AmdmntInfDtls
New UMR	OrgnlMndtId (the old reference)
New CI or creditor name	OrgnlCdtrSchmeId
Debtor account, same bank	OrgnlDbtrAcct with the old IBAN
Debtor account, different bank	OrgnlDbtrAcct/Id/Othr/Id = SMNDA

SMNDA (Same Mandate with a New Debtor Account) is the case that causes production incidents. The new debtor bank has never seen the mandate, and many creditor systems still hard-code FRST for the next collection. The 2025 guidelines are explicit that with SMNDA present, the sequence type may be FRST, RCUR, FNAL, or OOFF, with no restriction. Your creditor-side system must emit the amendment block exactly once, on the next collection, and stop emitting it afterwards. Sending it on every collection, or never, are both defects I have seen survive into production.

Is FRST still required?

No, and a surprising number of specifications still say it is.

The rulebook change history is explicit: from the effective date of version 9.0 in November 2016, every collection (first, recurrent, or one-off) can be presented up to D-1, and the use of FRST for the first collection of a recurrent series is no longer mandatory. A first collection can be identified the same way as subsequent ones, with RCUR. The current rulebook keeps FRST as an optional value and says a collection marked first is processed as recurrent.

The implementation guidelines still make PmtTpInf/SeqTp mandatory, with four codes:

Code	Meaning
OOFF	One-off collection under a mandate used once
FRST	First of a recurrent series (optional)
RCUR	Recurrent, not the last
FNAL	Last of the series; the mandate may be cancelled with it

What the debtor bank may still do is reject a sequence that contradicts the mandate history. The EPC reason code guidance lists “recurrent after a one-off” and “one-off after a recurrent” under AG02. So the requirement is not “send FRST first”, it is “keep the sequence consistent with the mandate type, and treat a used OOFF mandate as spent”.

What are the presentation timelines?

One rule for every sequence type since 2016, and the same in Core and B2B.

D-14 calendar days   earliest the debtor bank may receive the collection
D-14 calendar days   latest pre-notification to the debtor (unless agreed)
D-1 inter-PSP day    latest the debtor bank may receive the collection
D                    due date = settlement date = debit date (general rule)
D+5 inter-PSP days   latest settlement of a Core return
D+3 inter-PSP days   latest settlement of a B2B return

Inter-PSP business days follow the TARGET calendar. If D is not a TARGET day, settlement moves to the next one. At inter-PSP level a due date may never be changed; a late collection must get a new due date from the creditor or its bank before it is sent. Intraday cut-off times are not in the scheme at all. They are agreed between creditor, bank, and clearing and settlement mechanism (CSM), which is why “the scheme says D-1” is never the creditor’s real deadline.

What are the five R-transactions?

R-transactions are the exception flows, so called because their names start with R. The rulebook requires that R-transactions presented within the scheme rules are processed, and that rejects, returns, and refunds clear through the same CSM as the original collection unless the participants agreed otherwise.

R-transaction	Who initiates	When	Inter-PSP message	Window
Reject	Creditor bank, CSM, or debtor bank	Before settlement	pacs.002	Before settlement
Refusal	Debtor, to its bank	Before settlement, any reason	Becomes a reject (pacs.002) or, after settlement, a return	Core: before or after; B2B: by preference on D
Return	Debtor bank	After settlement	pacs.004	Core D+5, B2B D+3 inter-PSP days
Refund	Debtor, via its bank	After settlement	pacs.004	Core: 8 weeks authorised, 13 months unauthorised
Reversal	Creditor or creditor bank	After settlement	pacs.007 (pain.007 from the creditor)	Within 5 inter-PSP days after the due date

Three rules worth writing into the specification verbatim:

The refund is unconditional in Core for eight weeks. The debtor bank grants it on a no-questions-asked basis and recovers it from the creditor bank, plus a refund compensation for interest. The creditor cannot contest it inside the scheme. Your creditor-side design needs a process for receiving refunds weeks after the creditor thought the money was safe.

The 13-month claim is not a refund on request. For an unauthorised collection, the debtor claims within 13 months of the debit date, the debtor bank can request a copy of the mandate through the creditor bank, and the claim is accepted or rejected. MD01 is the reason code when no valid mandate exists.

The reversal is optional to offer and mandatory to accept. The creditor bank does not have to offer reversals to its creditors, but every debtor bank must handle reversals it receives and does not check them. A reversal returns the full amount of an erroneous collection, and the rulebook bars processing it after five inter-PSP business days following the due date.

Two things that look like R-transactions are not in the scheme. A revocation (creditor recalls a collection from its own bank before an agreed date) and a request for cancellation (creditor bank recalls from the CSM before settlement) are both bilateral. The EPC guidelines define no message for them; if your CSM supports a cancellation, you follow its specification, and you document which one you use. The general ISO 20022 mechanics of returns, reversals, and recalls are in returns, reversals, and recalls.

Which reason codes should the specification cover?

The EPC publishes guidance on SDD R-transaction reason codes (EPC173-14, version 8.1, published 30 September 2026) listing each code, the R-transactions it may appear on, the use cases, and the suggested creditor action. The ones that drive most volume and most customer conversations:

Code	Meaning	R-transaction types
AC01	Incorrect account identifier	Reject, return
AC04	Account closed	Reject, return
AC13	Debtor account is a consumer account (B2B only)	Reject, return
AG02	Invalid operation code or sequence type	Reject, return
AM04	Insufficient funds	Reject, return
AM05	Duplicate collection	Reject, return, reversal
BE05	Creditor identifier incorrect	Reject, return
MD01	No valid mandate, or unauthorised transaction	Reject, return, refund
MD02	Mandate data missing or incorrect	Reject
MD06	Refund request by end customer (Core)	Refund
MD07	Debtor deceased	Reject, return
MS02	Refusal by the debtor	Reject, return, reversal, refusal
MS03	Reason not specified	Reject, return, reversal
RR01 to RR04	Regulatory reasons (missing account, name, address)	Reject, return
SL01	Specific service offered by the debtor bank (blocking, limits)	Reject, return

MS03 deserves a note. In some countries data protection law forbids codes such as AC04, AM04, or MD07, and MS03 is the permitted alternative. The guidance asks banks to avoid general codes when a more precise one is allowed. For the creditor this means MS03 is a real, recurring code with no actionable cause, and the customer journey for it must exist. Mapping every code to a creditor action and a debtor message is the method in reason code mapping, and the full external code set is in ISO 20022 reason codes.

The domain grounding behind schemes like this one is in Break Into Banking, and the R-transaction matrix below drops straight into the specification templates in the BA Deliverables Template Pack.

What changes in SDD B2B?

The messages and datasets are identical except for the scheme code (LclInstrm/Cd = B2B instead of CORE) and the removal of most refund references. The behaviour is very different, because the refund right is gone.

• Non-consumers only. The debtor bank must ensure the debtor is not a consumer before debiting. A B2B collection on a consumer account is rejected or returned with AC13.
• The debtor bank checks the mandate. It must obtain the debtor’s confirmation of the B2B mandate data received with the first collection before debiting, store it, and check each later collection against it. A collection for a mandate the debtor has not confirmed is rejected with MD01.
• No refund for authorised collections. The debtor can still claim for an unauthorised collection within 13 months, but under B2B that is between the debtor and its bank: the debtor bank cannot recover it from the creditor bank under the scheme.
• Shorter return window. Returns settle at the latest three inter-PSP business days after settlement, and should ideally happen by D.
• Mandate cancellation must reach the debtor bank. The debtor has to tell its bank when it cancels a mandate so the stored instructions are updated.

For a creditor this is a trade: more certainty after D+3, more onboarding friction before the first collection. For a debtor bank it is a mandate store, a confirmation workflow, and a per-collection check that Core never required.

How do you model the collection lifecycle?

As a state machine, with the clock as an input. A Core collection on the creditor side can move through:

CREATED -> SUBMITTED -> ACCEPTED_BY_BANK -> SETTLED (D)
SUBMITTED -> REJECTED                       (pain.002 / pacs.002, before D)
SETTLED -> RETURNED                         (pacs.004, until D+5)
SETTLED -> REVERSED                         (pacs.007, until D+5)
SETTLED -> REFUNDED                         (pacs.004, until 8 weeks)
SETTLED -> REFUNDED_UNAUTHORISED            (pacs.004, until 13 months)

Two properties to enforce. First, the money can come back long after the collection looked final, so “settled” is not terminal for eight weeks, and for unauthorised claims not for 13 months. Second, every R-transaction must match its original through OrgnlEndToEndId and OrgnlTxId, or it becomes unmatched cash and a reconciliation break. The free duplicate refund investigation lab practises exactly that matching under pressure.

What does the SDD test matrix look like?

Derive it from the rulebook and the implementation guidelines, not from the base schema. A starting set, organised so each row is one assertion:

#	Scenario	Expected result
1	First collection sent as RCUR, Core	Accepted, processed as recurrent
2	RCUR on a mandate already used as OOFF	Rejected, AG02
3	Collection received at D-1 inter-PSP day	Accepted, settles on D
4	Collection after the D-1 cut-off	Not sent with the original D; new due date assigned before submission
5	UMR differs only by letter case from a known mandate	Treated as the same mandate
6	Amendment with SMNDA, then sequence RCUR	Accepted; amendment block sent once only
7	Insufficient funds on D	Return AM04 settled by D+5 (Core)
8	Return arriving at D+6	Not processed; debtor bank informed
9	Debtor refund request at 7 weeks 6 days	Refund MD06, no reason requested
10	Refund request at 8 weeks + 1 day, valid mandate exists	No unconditional refund; only an unauthorised claim, which is rejected
11	Unauthorised claim at month 12, no mandate	Refund MD01 after mandate copy request fails
12	Creditor reversal at due date + 3 inter-PSP days	Reversal pacs.007 processed, full amount
13	Creditor reversal at due date + 6 inter-PSP days	Not processed
14	B2B collection on a consumer account	Reject or return AC13
15	B2B collection, mandate not confirmed by debtor	Reject MD01
16	B2B return at D+4	Not processed
17	Return received with MS03	Mapped to a generic creditor action and debtor message
18	Mandate with no collection for 36 months	Creditor system cancels it; new collection blocked

Rows 8, 13, and 16 are the ones that get skipped, because they test something that must not happen. Write them anyway, following negative test design: an R-transaction outside its window is a real event in production, and a creditor system that books it is a ledger defect. For timing rows, build the date logic into a decision table first; the table is what reviewers can check and what testers can derive from.

The takeaway

SEPA Direct Debit is a creditor-pulled scheme whose analysis lives in two places: the mandate keys and the exception flows. Treat the UMR and the Creditor Identifier (minus its business code) as permanent keys, carry amendments exactly once, and stop requiring FRST, which the rulebook made optional in 2016. Then specify all five R-transactions as dated state transitions: rejects before D, returns by D+5 in Core and D+3 in B2B, reversals within five inter-PSP days of the due date, refunds for eight weeks, and unauthorised claims for 13 months.

Core and B2B share messages and differ in who carries the risk. Core protects the debtor after the fact with a refund; B2B protects the debtor up front by making its bank check the mandate. Specify the one you are actually building, against the 2025 version 1.2 rulebooks, and keep the 2028 changes on someone’s calendar.

The rest of the scheme layer is on The ISO 20022 Reference.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: SEPA, Direct Debit, ISO 20022, Payments, Functional Analysis, Testing