Can you move Direct Debit mandates and saved cards without customers re-signing?

A platform with large Direct Debit volumes, or a customer base paying by card on file, hears one objection before any other: "our customers will have to sign up again". If that were true, a move would cost a share of every customer's customers, and no sensible platform would ask. It is mostly not true, but the honest version has conditions, and a platform should know them before it tells a customer anything.

The two rails behave differently. A Direct Debit mandate is an instruction the payer gave to their bank in favour of a named service user, and the Bacs scheme has a defined process for transferring it. A saved card is a token held in a provider's vault, and whether it moves depends on what kind of token it is and whether the old provider will cooperate. Take them in turn.

A bulk change moves a group of Direct Debit Instructions from one service user number (SUN) to another on an agreed date. In the scheme's own terms it is a cancellation and a re-creation on the same day, not a literal transfer: the instructions are cancelled under the old SUN and set up under the new one, and the payer's original authorisation carries across. The payer must be told in writing, using wording approved for the purpose, but does not sign anything and does not have to act.

Three parties have to agree before it happens: the old service user (your current provider, or you if you hold your own SUN), the new service user, and the sponsoring bank of each. The new sponsoring bank accepts a Bulk Change Deed, a printed document signed by directors of both service users, under which the new service user takes on liability for indemnity claims on the transferred instructions, including claims arising from collections made before the transfer date. The deed must be signed by hand; electronic signatures are not accepted, and the name on it must match the legal entity registered against the SUN.

The scheme sets the shape; the timings in the table below are from GoCardless's published process, which states the whole thing takes four to six weeks and cannot be made faster because the constraints are external. Other bureaux publish similar steps. Your own sponsoring bank is the authority on your SUN.

The sequence for moving Direct Debit mandates between service users, with who acts at each step. Timings are indicative and from published provider guidance; each party's own turnaround can stretch them. Checked October 2026.

Three things the table makes plain. It is a project with a date, not a switch. The schedules and collection amounts do not transfer; the mandates do, and the collection plan is rebuilt on the new side from your data. And the old provider is a party to it: one that is slow or unwilling sets the pace, which is why the first conversation is with them.

We say mandates can usually be moved rather than re-signed, and we mean usually. The cases where a bulk change does not apply: a customer who collects under a provider's SUN where that provider will not release instructions; a set of mandates where payer data is incomplete, since the file needs a bank account and an address for every mandate; a SUN that is not AUDDIS-enabled, where cancellation is a manual step with a final collection; and a platform whose customers each hold their own SUN as direct submitters, who do not need a bulk change at all because nothing changes for them.

So the plan is: find out which of your customers' mandates sit under which SUNs, who sponsors each, and what the old provider's process is, before any customer is told a date. That is work done with you in the discover stage, and it is why nobody on our side will promise a mandate move on a call.

A saved card is not a card number sitting in your database. It is a token: a reference your provider's vault issued in place of the number. Whether it can move depends on which kind of token it is.

Provider tokens are issued by a provider's own vault and mean something only inside it. They do not travel on their own. To move them, the old provider must either send its tokens directly to the new provider's vault, or export the underlying card data in encrypted form under a process governed by PCI DSS, usually with sign-off from the acquirer or processor on both sides, so the new provider can re-tokenise it. The output is a mapping: old token, new token, same card. Some providers do this on request, some charge for it, and some refuse.

Network tokens are issued by the card scheme (Visa or Mastercard) and are tied to the card rather than to the provider. They can follow the cardholder to a new acquirer, but the receiving provider must be a certified token requestor and the relinking is coordinated with the scheme. One vault provider's published guide puts that at about four to twelve weeks. Account updater enrolments, which keep tokens current when a card is reissued, are tied to the old vault and have to be re-enrolled with the new one.

Where neither route is available, the fallback is to collect the card again at the next charge. That is the outcome a platform is trying to avoid, so the questions to ask the old provider before anything else are: what kind of tokens do we hold, do you export them, on what terms, and how long does it take.

Tell a customer what will happen to each rail only after you know. For Direct Debit: "your payers will get a letter in our name saying the collecting name is changing; they do not need to do anything; collections continue on the same schedule". For cards: either "your saved cards move across and your customers will not be asked again", or, if the old provider will not export, "your customers will be asked for their card once, at the next payment, and here is how we will handle the ones that fail". A platform that says the first and delivers the second loses the customer's trust when it needs it most.

This is why the move is planned in groups. A group whose cards are network tokens with a cooperative provider moves differently from one on a provider that will not export. The groups are set by what the rails allow, and each message is written once the answer is known.