SEPA / Learning brief
SEPA Additional Optional Services: what sits beyond the core scheme
Your notes
In simple terms / 01
What this means in plain language
Two euro transfers can both follow the SEPA Credit Transfer rulebook and still carry different local additions. Those additions are useful only when every participant in the route understands them.
Complete lesson / 02
Understand the full idea, step by step
The SEPA Credit Transfer scheme creates a common floor: participants can exchange a euro credit transfer under one core rulebook. Communities may build additional services around that floor, but an addition works only across the routes and participants that agreed to support it.
Additional Optional Service — AOS
An AOS is an additional service offered by a community or group of participants around a SEPA scheme. It can extend customer features, local data or operational handling without changing the scheme's common core for participants that do not use it. Its scope, governance, reachability and data rules come from the AOS documentation, not from the name alone.
Questions to answer before using an AOS
- Purpose
- What customer or operational need does the service add beyond core SCT?
- Governance
- Which community or operator owns the rules and change process?
- Reachability
- Which debtor PSPs, creditor PSPs and intermediaries support it?
- Data
- Which ISO 20022 elements, character rules or companion messages carry the addition?
- Fallback
- Can the core SCT continue if the optional data or service is unavailable?
- Lifecycle
- How are rejects, returns, recalls, investigations and reporting handled?
- Currency and geography
- Which countries, currencies, products or customer groups are in scope?
- Current status
- Is the service active, changed, replaced or historical, and when was that confirmed?
| Dimension | Core SCT | AOS |
|---|---|---|
| Obligation | Applies to scheme participants within the rulebook scope | Applies only under the additional service's participation and rules |
| Reachability assumption | Established through the scheme and chosen CSM route | Must be checked for the optional capability as well |
| Message usage | Controlled by the applicable EPC implementation guideline | May add community-specific use within permitted boundaries |
| Failure handling | Follows core SCT processes | Needs a defined fallback or separate handling without corrupting the core payment |
Assessing the richer-remittance request
- INSTRUCTION
Capture the core payment and the optional customer request as separate capabilities.
- VALIDATION
Check whether Bank Alfa's product, the selected route and every required participant support the AOS.
- MESSAGE
Apply the current AOS data rules only when the support and version checks pass.
- VALIDATION
If the AOS is unavailable, apply the documented fallback: continue core SCT, request correction or reject the optional service—not an invented mixture.
- NOTIFICATION
Tell Asha Traders which capability was accepted and preserve the AOS version and route evidence.
COMMON CONFUSION
“If an AOS exists in one SEPA country, every SEPA bank must support it.”
The common scheme and the optional community service have different reachability. A participant can support core SCT without supporting a particular AOS.
STRICTLY SPEAKING
Strictly speaking, country-specific examples age quickly. A service name found in an older book proves that it existed in that context, not that it is active today. Payments Signal should list a named AOS as current only with an operator or community source, scope and review date.
FOR NOW, REMEMBER
- An AOS adds capability around the core SCT scheme; it does not silently redefine the common core.
- Support must be checked across the product, route and participating institutions.
- Optional data needs a documented fallback when the service is unavailable.
- Named national examples require a current operator source and review date before being presented as active.
TRY IT YOURSELF
Bank Alfa supports an AOS, but the selected indirect route does not. What is the sound conclusion?
An optional service makes the document hierarchy matter even more. Next, learn where the core rule stops and the implementation or community rule begins.
KEEP GOINGKey takeaways / 03
Three things to remember
- 01
Name the scheme, payment instrument, parties, and clearing path before reading the messages.
- 02
Separate pre-settlement rejection from post-settlement return and recall handling.
- 03
Verify timing, reachability, and exception rules in the current EPC material.
Evidence & review / 07
Evidence & review
Conceptual guide to Additional Optional Services around SEPA Credit Transfer. The availability, governance and message usage of a particular AOS must be confirmed with its current community documentation and participating PSPs.
What this brief simplifies: Groups national and community additions by purpose instead of cataloguing every service. Historical examples are not presented as current unless an operator source confirms them.
Sources for this brief3
- Scheme-specific rule2025 version 1.1 (EPC125-05)
2025 SEPA Credit Transfer rulebook ↗ — European Payments Council · Core SCT scheme scope and participant obligations
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.0 (EPC115-06)
SEPA Credit Transfer Inter-PSP Implementation Guidelines ↗ — European Payments Council · SEPA ISO 20022 usage rules
Based on version 1.1 of the 2025 SCT rulebook. Companion Customer-to-PSP guidelines cover the pain.001 initiation leg.
- 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.