SEPA Mandate Amendment and Migration: What Survives a Change of PSP, Creditor ID or Entity

Most of what circulates about migrating SEPA direct-debit mandates is borrowed from schemes where the mandate really is tied to the collecting bank. The SDD Core rulebook is not one of them, and getting this wrong in either direction costs you: re-collect mandates you did not need to and you churn customers; skip an amendment you did need and your collections start rejecting.

The rulebook is precise about which is which.

Start with what a mandate actually contains

The rulebook's definition of the mandate data set lists what the document must contain. The attributes are: the unique mandate reference; the debtor's name, postal code and city, country of residence and IBAN; the creditor's company name, Creditor Identifier, street address, postal code and city, and country; the type of payment; the signature place and time; and the signature(s). The debtor's full address and the debtor PSP's BIC are mandatory only where one of the PSPs sits in a non-EEA SEPA country.

Read that list for what is absent. The creditor's PSP is not on it. Neither is the creditor's account.

That absence is the single most useful fact in this subject. The mandate is an agreement between creditor and debtor about who may collect from which account. It says nothing about which bank presents the file. The rulebook states the principle directly: the amendment of the mandate "is handled between the Creditor and the Debtor", and cancellation "is carried out between the Creditor and the Debtor without the involvement of either of their PSPs."

Change of Creditor PSP: nothing to amend

So: if you move your collections from one bank or PSP to another and nothing else changes — same legal entity, same Creditor Identifier, same name, same mandate references — no mandate amendment is required. The debtor agreed to be debited by you; they still are.

One qualification, and it is about jurisdiction rather than identity. The debtor's full address, and the debtor PSP's BIC, are optional on the mandate only while both PSPs sit in EEA countries. The rulebook makes them mandatory when the creditor PSP or the debtor PSP is located in a non-EEA SEPA country or territory. A migration that moves your creditor PSP from an EEA domicile to a non-EEA one — the UK, Switzerland and several smaller territories are all plausible PSP homes — can therefore turn data your existing mandates never captured into required data. That is not an amendment in the rulebook's sense, but it is a gap your migrated files will reject on.

That is materially different from Bacs, where a Direct Debit Instruction is registered under the originating bureau's Service User Number, or from ACH, where an authorisation sits with an originator whose ODFI relationship has to be re-established. If your mental model comes from either, it is the wrong model here.

What does change is operational. Your new PSP needs the dematerialised mandate data for every mandate you collect under, because the rulebook requires the mandate-related information to travel with the collection:

The Mandate-related information for new Mandates or amended Mandates (if needed, see PR-02) must be sent as part of all the Collections.

The migration risk is therefore in the data handover — mandate references, signing dates, sequence types, debtor IBANs — and not in the debtor relationship. Get the export right and the debtor never knows it happened. Get it wrong and your first collection under the new PSP rejects for "Mandate data missing or incorrect" or "No Mandate", which are both reasons the rulebook lists for a reject by the CSM or the debtor PSP.

The four changes that do require an amendment

The rulebook enumerates them, in the description of the reason-for-amendment attribute and again in the process rules. An amendment is "of concern for the Creditor PSP or for the Debtor PSP" — and therefore has to be transmitted — when:

• the creditor changes the unique mandate reference of an existing mandate because of internal organisational changes
• the Creditor Identifier has changed due to merger, acquisition, spin-off or organisational changes
• the creditor has changed its name
• the debtor decides to use another account, within the same PSP or in another one

The attribute's value range also allows a combination of the first three. Anything not on that list is between you and the debtor and does not need to reach either bank.

Three of the four are triggered by corporate events rather than payments decisions — a re-registration, an acquisition, a rebrand — which is why they get missed. The payments team is often the last to hear that the entity presenting collections has a new name.

How an amendment actually travels

For paper mandates there is no amendment message. The rulebook's process rule is:

After acceptance by the Creditor, the Creditor must dematerialise the amended Mandate, archive the document, and send the information on the Mandate to the Creditor PSP as part of the next Collection, as described in PT-04.03.

The amended mandate data rides inside the next collection file. That has two consequences.

First, the amendment reaches the debtor's bank only when you next collect. A mandate you amend today and collect under next quarter carries the change next quarter.

Second, timing follows the collection cycle: PT-04.03 has the creditor sending collection data "14 Calendar Days before Due Date, unless defined in a bilateral agreement between the Creditor PSP and the Creditor". If your PSP has agreed shorter lead times, the amendment arrives on those.

The creditor or the debtor can amend the mandate at any time, the rulebook says. But the amendment is not effective at the banks until it is carried in a collection.

When a different creditor takes over

The rulebook explicitly provides for "the case that a Mandate is taken over by another Creditor than the Creditor who initiated the Mandate" — the mandate and its underlying contract moving to a new legal entity. It gives that case two dedicated attributes:

• AT-M004 — the Creditor Identifier of the creditor who issued the mandate "before the Mandate and its underlying contract was taken over by another Creditor"
• AT-M005 — the unique mandate reference as originally given by that creditor

Both go in the collection. The debtor's bank can then match a collection presented under the new Creditor Identifier and reference to the mandate it holds on record under the old ones. Omit them, and the debtor bank sees a creditor it has no mandate for.

Then there is the duty most acquirers skip:

When the identity of the Creditor has changed because of merger or acquisition, the 'new' Creditor must inform the Debtor of the related mandate amendments by any means (letter, mail ...) to avoid any further dispute by the Debtor on a Collection, not recognizing the Creditor name or identifier on his account statement.

That notice exists for a specific reason. A debtor who sees an unfamiliar name on their statement has, under SDD Core, a no-questions refund right on the collection. The rulebook's remedy is to tell them first. The notice is not a courtesy — it is the scheme's stated defence against a wave of refunds after a corporate transaction.

The signing date does not move

An amendment does not restart the mandate. The rulebook defines the date of signing — "The date on which the Mandate was signed by the Debtor, as registered by the Creditor in the dematerialisation of the Mandate document." — and adds: "The value of this attribute remains unchanged for the mandate lifecycle."

The same section carries a concession worth knowing if you inherited a portfolio from a legacy national scheme: "For Mandates migrated from other direct debit schemes, this attribute might not be available. In such case, it is up to communities of Participants to define how to provide a valid substitute for this date" So a migrated mandate can legitimately carry a substitute signing date agreed at community level. Do not "fix" those by overwriting them with the migration date.

E-mandates: do not mix channels

For creditors offering electronic mandates, the rulebook adds channel discipline. A creditor "who offer the issuing of e-Mandates, must also offer the possibility of amending and cancelling e-Mandates." A debtor amending an e-mandate "may be executed only by using an electronic channel offered by the Creditor, except when the electronic channel and/or the authentication means are not be available any more."

The reasoning is liability, and the rulebook says so: mixing paper and electronic channels in one mandate's lifecycle "would create a major problem due to the differences in the liability of the Debtor PSP resulting from the validation service executed." So no debtor PSP that offers e-mandate validation is obliged to accept electronic amendment or cancellation of a paper mandate.

Amendment of an e-mandate by the creditor is treated as "a matter between the Creditor and the Debtor" and is out of the rulebook's scope.

E-mandates are also the one place where an amendment does travel as its own message. Where the debtor proposes an amendment, the e-mandate annex has the creditor submit "the e-Mandate amendment through a routing service to the Debtor PSP" for authentication — a real-time flow that runs before, and separately from, the collection. The information still reaches the creditor PSP the same way as for paper: the creditor "sends the information on the e-Mandate to the Creditor PSP, as part of each Collection". So the routing message authenticates the change; the collection still carries it.

One date that will break files regardless of mandates

The version 1.1 cover note records that the date from which unstructured address formats are no longer permitted was moved from 22 November to 15 November 2026, aligned with the Swift MX release weekend, and that this was the only change in version 1.1. The creditor address is a mandate attribute and travels in the collection. A migration that lands an unstructured creditor address in the new PSP's files will start failing on that date irrespective of anything above.

What an operator actually does differently

• Do not re-collect mandates for a PSP change. The PSP is not a mandate attribute. Re-collection is churn you chose.
• Treat the mandate-data export as the migration. References, sequence types, signing dates, debtor IBANs — the new PSP needs all of it in every collection, and the failure mode is a reject for missing or incorrect mandate data.
• Wire corporate-event triggers into the payments team. A re-registration, a rebrand or an acquisition is a mandate amendment. Find out before the next collection run, not after the rejects.
• Send the amendment in the next collection and know it is not effective until you do. There is no separate amendment message.
• On a takeover, populate AT-M004 and AT-M005 with the original Creditor Identifier and mandate reference, or the debtor bank has nothing to match against.
• Write to the debtor after a merger or acquisition. The rulebook requires it, and the refund exposure it prevents is real.
• Leave migrated signing dates alone. A community-agreed substitute is valid; the migration date is not.
• Keep e-mandate amendments electronic. Liability at the debtor PSP depends on the channel.
• Structure the creditor address before 15 November 2026. It is in the collection, and the format rule bites on that date.

For the mandate lifecycle across ACH, SEPA, Bacs and eGIRO, see the direct debit reference; for the scheme-level mechanics of SDD Core and B2B, see the SEPA operator guide; for what happens after a collection fails, see the R-transaction reference.