SEPA / Learning brief
SEPA Payments Schemes
Your notes
In simple terms / 01
What this means in plain language
Defines the difference between a payment scheme and a processing system before introducing SEPA's four principal rule sets.
A payment scheme defines shared business rules, participant responsibilities, and service expectations. A processing system is the technical and operational infrastructure used to exchange and settle transactions under those rules. In SEPA, common rule sets cover standard credit transfers, instant credit transfers, core direct debits, and business-to-business direct debits. The scheme says what participants must support; the chosen mechanism determines how they connect and process. Keeping these layers separate prevents requirements from confusing a product promise with a specific vendor, network, or clearing route.
Complete lesson / 02
Understand the full idea, step by step
Think of two very different euro payments Asha Traders makes in a month. One is a single invoice paid to a new supplier — money pushed out, once. The other is a monthly software subscription that the software firm pulls from Asha's account on its own schedule. Same currency, same area, but genuinely different jobs. SEPA does not use one scheme for both, and this lesson is about the ones it uses instead.
A scheme is a rulebook, not a wire
Before the schemes themselves, one distinction saves endless confusion. A scheme is the shared set of business rules that participating banks agree to follow — who may take part, what a valid instruction looks like, how normal and exceptional cases are handled. The processing system (the rail, the infrastructure) is the operational route that actually carries and settles the transactions. One scheme can run over more than one processing system, and a bank can change the system it uses while still offering the same scheme. Keep the two apart and the rest is straightforward.
Payment scheme — a shared rulebook that makes different banks' services compatible
A SEPA scheme is published and maintained by the European Payments Council (EPC) as a rulebook. Every participating bank agrees to the same roles, message content, timing obligations, and handling of returns and rejects. Because the rules are shared, a payment created at one bank is understood and processed the same way at another. The scheme moves nothing itself — it is the agreement that lets the machines underneath interoperate.
| Scheme | Direction | Typical use | Notable feature |
|---|---|---|---|
| SCT — SEPA Credit Transfer | Push (payer sends) | One-off and regular payments, e.g. paying a supplier | The everyday euro transfer; typically completes by the next business day |
| SCT Inst — SEPA Instant Credit Transfer | Push (payer sends) | When money must be available at once, any hour | Around-the-clock; funds available to the payee within the scheme's tight time limit |
| SDD Core — SEPA Direct Debit Core | Pull (payee collects) | Collecting from consumers, e.g. subscriptions, utilities | Runs on a mandate; consumers keep a defined refund right |
| SDD B2B — SEPA Direct Debit Business-to-Business | Pull (payee collects) | Collecting between businesses | For business debtors; a different refund regime from Core |
You may be wondering: for Asha's two jobs, which schemes are these?
The one-off supplier payment is a credit transfer — Asha pushes the money, so it is SCT (or SCT Inst if it must land immediately). The monthly subscription is collected by the provider, so it is a direct debit pulled under a mandate Asha signed. Because Asha is a business paying a business, whether that collection uses SDD Core or SDD B2B depends on the arrangement the provider set up. Direction of the money — push versus pull — is the first fork; the rest follows from who the parties are and how fast it must be.
COMMON CONFUSION
“SCT Inst is just a faster version of SCT, so choosing between them is only about speed.”
They are separate schemes with separate rulebooks and different obligations. SCT Inst demands around-the-clock availability, a strict per-payment time limit, and all-or-nothing completion — commitments an ordinary SCT does not make. Speed is the visible difference, but the rules, the guarantees, and the operational demands behind them differ too. Picking a scheme by speed alone ignores what each one actually promises.
STRICTLY SPEAKING
Strictly speaking, each scheme is a versioned rulebook that the EPC updates over time, and there are further scheme documents beyond these four principal ones. A bank offers a scheme only if it has adhered to that rulebook, so reachability varies between banks. Before relying on any specific limit, timing, or feature, check the version of the rulebook in force rather than assuming it is fixed.
FOR NOW, REMEMBER
- A SEPA scheme is a shared rulebook; the processing system underneath is a separate thing, and one scheme can run over several.
- The four principal schemes are SCT, SCT Inst (push, credit transfers) and SDD Core, SDD B2B (pull, direct debits).
- Push versus pull — payer sends versus payee collects — is the first choice; who the parties are and how fast it must be decide the rest.
- The schemes are versioned EPC rulebooks; a bank must adhere to a scheme to offer it.
TRY IT YOURSELF
A cloud provider will collect EUR 220.00 from Asha Traders every month, and Asha has signed a mandate authorising it. Which family of SEPA schemes fits this arrangement?
You have the four schemes. But who writes these rulebooks, who runs the machines underneath, and who oversees the whole thing? Next, the cast of organisations that make SEPA work.
KEEP GOINGKey takeaways / 03
Three things to remember
- 01
A scheme is a rule set, not a processing platform.
- 02
Different SEPA services address distinct payment needs.
- 03
Product requirements should separate rules from infrastructure choices.
Practical use cases / 04
Where you would use this
A product manager selects a SEPA service for a recurring collection versus a supplier transfer.
An architect evaluates clearing providers without rewriting scheme-level business requirements.
A compliance analyst checks whether participant procedures match the selected rule set.
Worked example / 05
Put the idea into a real situation
A bank wants to offer fast euro transfers and chooses the instant credit-transfer rule set for the customer proposition. It then evaluates mechanisms that can process those instructions and connect to its payment engine. The rule set defines participant obligations, while the mechanism supplies the route and operating connection. If the bank changes its processor later, many scheme requirements remain. This simplified example avoids implying that every institution offers every SEPA service.
Evidence & review / 07
Evidence & review
The four principal SEPA schemes (SCT, SCT Inst, SDD Core, SDD B2B) as maintained by the EPC.
What this brief simplifies: Presents four principal schemes and the scheme-vs-system distinction without cataloguing every rulebook variant, mandate mechanic, or refund window.
Sources for this brief5
- Scheme-specific rule2025 version 1.1 (EPC125-05)
2025 SEPA Credit Transfer rulebook ↗ — European Payments Council
Version 1.1 replaced version 1.0 at publication on 5 October 2025 and is stated to remain in effect up to 21 November 2027. It moves the date from which the unstructured address format is no longer permitted to 15 November 2026.
- Scheme-specific rule2025 version 1.1 (EPC004-16)
2025 SEPA Instant Credit Transfer rulebook ↗ — European Payments Council
Version 1.1 replaced version 1.0 at publication on 5 October 2025 and is stated to remain in effect up to 21 November 2027. The EPC states it is compliant with Regulation (EU) 2024/886, the Instant Payments Regulation.
- Scheme-specific rule2025 v1.1 (EPC016-06)
2025 SEPA Direct Debit Core rulebook version 1.1 (EPC016-06) ↗ — European Payments Council
- Scheme-specific rule2025 v1.1 (EPC222-07)
2025 SEPA Direct Debit Business-to-Business rulebook version 1.1 (EPC222-07) ↗ — European Payments Council
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.