Doc: EPC228_06 SEPA Testing Framework
(Version 2.3)
12 March 2009
SEPA Testing Framework
Version 2.3
Abstract
This document represents the SEPA Testing Framework (STF)
Document Reference
EPC228_06 SEPA Testing Framework
Issue
Version 2.3
Date of Issue
12 March 2009
Reason for Issue
Support the launch versions of the SDD Rulebooks (Core and B2B)
Reviewed by
EPC
Produced by
EPC
Authorised by
EPC
Circulation
Publicly available
EPC AISBL Secretariat – Av. de Tervueren 12 – B 1040 Brussels Tel: +32 2 733 35 33 Fax: +32 2 736 49 88
Enterprise N° 0873.268.927 www.europeanpaymentscouncil.eu secretariat@europeanpaymentscouncil.eu
TABLE OF CONTENTS
0
INTRODUCTION................................................................................................................................................ 4
0.1 REFERENCES ................................................................................................................................................... 4
0.2 CHANGE HISTORY .......................................................................................................................................... 4
0.3 EVOLUTION OF THE SEPA TESTING FRAMEWORK.......................................................................................... 4
0.4 EPC’S OBJECTIVES ......................................................................................................................................... 5
1
STF SCOPE AND APPROACH......................................................................................................................... 6
1.1 IN SCOPE FOR THE STF................................................................................................................................... 6
1.2 V-MODEL TEST LEVELS IN/OUT OF SCOPE ..................................................................................................... 6
1.3 OUT OF SCOPE FOR THE STF .......................................................................................................................... 7
1.4 APPROACH TO TESTING THE SEPA SCHEMES ................................................................................................. 7
2
ROLES AND RESPONSIBILITIES .................................................................................................................. 9
2.1 INTRODUCTION TO SCHEMES AND RULEBOOKS .............................................................................................. 9
2.2 EPC ROLE AND RESPONSIBILITIES ............................................................................................................... 11
2.3 SEPARATION OF THE SCHEME FROM THE INFRASTRUCTURE ......................................................................... 11
2.4 DEFINITION OF COMMUNITY ........................................................................................................................ 11
2.5 COMMUNITY’S ROLE AND RESPONSIBILITIES ............................................................................................... 11
2.6 PARTICIPANT ................................................................................................................................................ 12
2.7 CSMS, ACH AND PE-ACH .......................................................................................................................... 14
2.8 EUROSYSTEM / NCB ROLE ........................................................................................................................... 14
3
INTRODUCTION TO STF ACCEPTANCE CRITERIA AND TEST SCENARIOS ................................ 15
3.1 SEPA ACCEPTANCE CRITERIA ..................................................................................................................... 15
3.2 DEFINITION OF TEST SCENARIOS .................................................................................................................. 17
3.3 USING THE SEPA TEST SCENARIOS .............................................................................................................. 17
3.4 DERIVING THE TEST CASES .......................................................................................................................... 18
3.5 TEST PLAN AND STRATEGY .......................................................................................................................... 18
3.6 NAMING CONVENTIONS................................................................................................................................ 19
3.7 TEST MEASUREMENTS .................................................................................................................................. 20
4
OPERATIONAL READINESS FOR SEPA SCHEMES ............................................................................... 21
4.1 INTRODUCTION ............................................................................................................................................. 21
4.2 OVERVIEW OF REPORTING & INFORMATION FLOWS FOR OPERATIONAL READINESS ................................... 21
4.3 SELF-ASSESSMENT LEVELS FOR PARTICIPANTS ........................................................................................... 22
4.4 CRITERIA FOR OPERATIONAL READINESS..................................................................................................... 23
4.5 COMMUNITIES - SELF-ASSESSMENT AND READINESS DECLARATION ........................................................... 24
4.6 ACTIVITIES FOR SEPA SCHEMES’ READINESS: EPC, COMMUNITIES AND PARTICIPANTS ............................ 25
4.7 COMPLIANCE BY CSMS ................................................................................................................................ 28
4.8 OTHER ACTIVITIES TO ACHIEVE OPERATIONAL READINESS (BEST PRACTICE ADVICE)............................... 28
5
SEPA CREDIT TRANSFER ............................................................................................................................ 29
5.1 SCT ACCEPTANCE CRITERIA ........................................................................................................................ 29
5.2 SCT TESTING PRINCIPLES ............................................................................................................................ 33
EPC228_06 SEPA Testing Framework
Page 2
5.3 SCT TEST SCENARIOS .................................................................................................................................. 34
6
SEPA DIRECT DEBIT ..................................................................................................................................... 40
6.1 SDD ACCEPTANCE CRITERIA ....................................................................................................................... 40
6.2 SDD TESTING PRINCIPLES............................................................................................................................ 46
6.3 SDD TEST SCENARIOS ................................................................................................................................. 47
7
ANNEX 1: GENERIC SEPA TEST PLAN ..................................................................................................... 51
7.1 PURPOSE ....................................................................................................................................................... 51
7.2 OUTLINE ....................................................................................................................................................... 51
8
ANNEX 2: PARTICIPANT’S TEST SUMMARY REPORT ........................................................................ 56
8.1 PURPOSE ....................................................................................................................................................... 56
8.2 OUTLINE ....................................................................................................................................................... 56
9
GLOSSARY OF TERMS .................................................................................................................................. 58
EPC228_06 SEPA Testing Framework
Page 3
0
INTRODUCTION
The SEPA Testing Framework (STF) is issued by the European Payments Council (EPC) and
establishes the testing and implementation principles, common set of testing terminology,
approaches, and testing scenarios for the provision and operation of Single Euro Payments Area
(SEPA) payment Schemes, namely SEPA Direct Debit (SDD) – both Core and Business to Business and SEPA Credit Transfer (SCT). It is exclusively based on the SEPA Schemes Rulebooks, their
corresponding Implementation Guidelines, the SEPA Data Model and the UNIFI (ISO20022) XML
standard. The STF therefore creates the basis for a seamless interoperability between Participants and
any intermediary parties that join the SEPA Schemes.
The STF is not itself a legally binding document. It is based on the provisions of the Rulebooks
which when adhered to will be binding. Communities and/or Participants are expected to use the
provisions of the STF to build their own test programmes in order to become SEPA ready.
0.1
References
This section lists documents referred to in the STF. Electronic copies of the documents are available
for downloading from the EPC website www.europeanpaymentscouncil.eu
Document
Identification
Issued by:
EPC170 05
PE-ACH Framework
EPC
EPC016-06
SEPA Direct Debit Scheme Rulebook
EPC
EPC125-05
SEPA Credit Transfer Scheme Rulebook
EPC
EPC222-07
SEPA B2B Direct Debit Scheme Rulebook
EPC
PRES_EPC045_06
SEPA Testing Strategy v 1.0
EPC
0.2
Change History
Version
0.3
Title
Date(s)
Detail
v2.2
02.03.07
Published on EPC website to support development prior to launch of
SCT, compatible with SCT Rulebook version 2.2
v2.3
28.02.09
Aligned with SDD and B2B Rulebooks.
Evolution of the SEPA Testing Framework
The SEPA Testing Framework (the STF) is an operational document describing the framework for
the SEPA Scheme compliance by a Participant who would test bi-laterally and/or involving
CSMs/ACHs/PE-ACHs within and across the Communities.
The EPC itself will not conduct any tests since the major part of SEPA readiness testing is carried out
by Participants and reported to their respective Communities on the principle of ‘Self Assessment’.
The objective of the proposed STF is to resolve the following challenges that may arise during the
implementation of the SEPA Schemes:
The very wide scale of SEPA implementation (thousands of banks)
EPC228_06 SEPA Testing Framework
Page 4
The testing of both national (95%+) and SEPA-wide (2 - 5%) volumes
The challenge of operating in a decentralised environment
The need to resolve on-going test issues and problems (13+ Community test environments and
thousands of banks) as well as avoiding different interpretations of Rulebooks
The requirement to ensure that Participants test for Scheme compliance on an end-to-end basis
The involvement of the customer dimension in end-to-end testing, by either involving actual
customers or simulating customers
The provision of sufficient and comprehensive testing acceptance criteria and high-level
scenarios to ensure Participants may achieve SEPA Scheme compliance
The necessary process for Participant/Community readiness declarations
Effective information flow and communication between the actors
0.4
EPC’s Objectives
The EPC Plenary of 27 September 2006 discussed the need to address the following objectives for
SEPA testing and implementation. As a result, the EPC has set up a SEPA Testing project to achieve
the following:
Define the scope and overall approach for the SEPA Testing Framework (STF)
Define and clarify roles and responsibilities
Establish and maintain the acceptance criteria and test scenarios which form the core of the
SEPA Testing Framework
Make recommendations for a process to measure Scheme compliance by Participants
Engage with Communities to provide support, obtain feedback and monitor the achievement of
SEPA Scheme compliance
EPC228_06 SEPA Testing Framework
Page 5
1
STF SCOPE AND APPROACH
Chapter 1 presents the scope of the SEPA Testing Framework (the STF) and the approach taken in
producing the STF. The STF scope and approach underpin the process for planning and achieving the
objectives for SEPA testing and implementation as set out in this document.
1.1
In Scope for the STF
The STF is based upon the following SEPA Schemes:
SEPA Direct Debit Core Scheme (Rulebook and Implementation Guidelines)
SEPA Direct Debit B2B Scheme (Rulebook and Implementation Guidelines)
SEPA Credit Transfer Scheme (Rulebook and Implementation Guidelines)
Within the SEPA Testing Framework, the term ‘Rulebook’ should be understood to cover the
Scheme Rulebooks, i.e. either SDD Core Rulebook, SDD B2B Rulebook, or SCT Rulebook, the
corresponding Implementation Guidelines and the UNIFI (ISO20022) XML standard. When the term
‘Rulebooks’ is used it refers to all three Rulebooks. Where the term “SDD Rulebook” is used, it
refers to both the Core and B2B SDD Rulebooks.
Hereafter, the term ‘the SEPA Schemes’ should be understood to refer to (a combined set of) the
SEPA Direct Debit Core and B2B Schemes (Rulebook, Implementation Guidelines) and SEPA
Credit Transfer Scheme (Rulebook, Implementation Guidelines).
In scope for the SEPA Testing Framework are:
1. Strict compliance with the SEPA Schemes’ Rulebooks and the specified standards and
Implementation Guidelines
2. Deriving acceptance criteria and test scenarios from the Rulebooks and the Implementation
Guidelines
3. Functional interoperability between actors on a SEPA-wide basis
4. Functional testing only (not other quality characteristics)
5. Focus on implementation testing rather than testing migration of existing national volumes
6. Priority focus on Euro area Communities
7. Testing by Communities to ensure no negative impact on the SEPA Schemes by Additional
Optional Services (AOS)
1.2
V-Model Test Levels in/out of Scope
There are generally three levels of testing covered by a so-called V-Model (the model should be
approached from the top left section of the V-Model, follow all functional steps down and up again to
the top right section):
Acceptance Test level
Systems Test level that includes respective integration testing
Component Test level, also known as unit testing
The SEPA Testing Framework only covers testing at Acceptance Test level. As presented in Figure 1
the System Test and Component Test levels are out of scope for the STF.
EPC228_06 SEPA Testing Framework
Page 6
FIGURE 1: SCOPE OF STF RELATED TO THE V-MODEL OF TESTING
1.3
Out of Scope for the STF
The following SEPA instruments, activities and attributes are excluded from the SEPA Testing
Framework:
1.
SEPA Cards Framework which is handled by the EPC Cards Working Group
2.
SEPA Cash Framework which is handled by the EPC Cash Working Group
3. Guidance on testing infrastructure, methodology, tools, services, systems, channels of
communication, legal procedures and/or any bi-lateral arrangements
1.4
Approach to Testing the SEPA Schemes
The approach to producing the STF document, which underpins testing for SEPA Schemes
operational readiness, involved deriving Acceptance Criteria and Test Scenarios from the Rulebooks.
Subsequently, Communities and Participants use the EPC’s Acceptance Criteria and Test Scenarios
to derive core SEPA Test Cases in order to execute the tests. Further, based on the results of the tests
the Participants will assess (Self Assessment) and report (to their respective Communities) their
SEPA Schemes readiness.
Communities and/or Participants will need to expand the list of the Acceptance Criteria and Test
Scenarios to produce Test Cases that cater for testing of the following:
Community’s AOS and Usage Rules
Participant’s AOS for bilateral service arrangements
Proprietary services and products to other banks and corporates
Interoperability between SEPA specific systems and other systems (e.g. payments systems,
financial applications, CRM and ERP solutions, etc.)
Infrastructure and systems
The Rulebooks contain procedure flowcharts accompanied by the process description and field
characteristics. Based on these flowcharts and supporting information the STF project team created
Test Scenarios for each specific Business Process. Combined, the Test Scenarios cover all
Acceptance Criteria derived from the Rulebooks. Testing successfully for all of the Test Scenarios
implies SEPA Scheme compliance. Therefore all Test Scenarios, unless specified otherwise, are
priority category ‘Must Test’.
EPC228_06 SEPA Testing Framework
Page 7
The testing shall be done in a structured manner using systematic test design and execution thus
setting up an organised and controllable process. The testing shall result in a test summary report that
can be used by a Participant to decide whether it can declare itself as being ‘SEPA Scheme
compliant’. Test summary reports must be formally signed off by the authorised representative within
a Participant’s organisation.
Testing means both static testing (i.e. reviewing documents, processes and procedures) as well as
dynamic testing (i.e. execution of the software). A number of the Acceptance Criteria cannot be
tested dynamically therefore a mix of static and dynamic testing is required.
Defects uncovered during testing must be classified and recorded for the purpose of tracking and
fixing them (within the organisation of a Participant or within a Community). Participants and
especially Communities may publish the uncovered defects for the benefit of the other Participants,
with a view to improve the overall quality for SEPA testing and implementation.
To be able to check the results of testing the parties involved in the execution of a test (for example
an Originator Bank and a Beneficiary Bank) should amongst themselves agree a procedure for
exchanging test results (for example to check whether the data received at the destination corresponds
to the data sent at the source).
One of the EPC and the STF project team objectives is to instil an unambiguous communication of
the testing terminology between the Participants and within/between the Communities. The
terminology used in the STF is based on the glossary of the International Software Testing
Qualifications Board 1 which also refers to ISO9126 and IEEE 2 standards. The reference to the
international testing standards is used to establish a common set of terminology; Participants and/or
Communities may choose any testing standard to perform their own testing activities.
1
2
www.istqb.org
IEEE Std 829-1998, (Revision of IEEE Std 829-1983) and IEEE610.12-1990
EPC228_06 SEPA Testing Framework
Page 8
2
ROLES AND RESPONSIBILITIES
SEPA will be the area where citizens, companies and other economic actors will be able to make and
receive payments in Euro, within Europe (currently defined as consisting of the 27 European Union
(‘EU’) member states plus Iceland, Norway, Liechtenstein and Switzerland), whether across or within
national boundaries under the same basic conditions, rights and obligations, regardless of their
location 3.
2.1
Introduction to Schemes and Rulebooks
2.1.1 Binding Nature of the Rulebooks
The adherence process implies that Participants must always respect the provisions of Rulebooks and
the Implementation Guidelines. The Rulebooks and Implementation Guidelines are binding
documents.
The STF is not itself a legally binding document. It is based on the provisions of the Rulebooks
which when adhered to will be binding. Communities and/or Participants are expected to use the
provisions of the STF to build their own test programmes in order to become SEPA ready.
Participants are also free to choose between operating processes themselves, or use intermediaries
and/or outsource clearing and settlement (partially or completely) to third parties. However,
outsourcing or the use of intermediaries does not relieve a Participant of their responsibilities under
the Adherence Agreement.
The Rulebooks cover in depth the Bank-to-Bank (Bank-to-Bank (B2B) & Bank-CSM-Bank (BCSM-B)) clearing and settlement in the realm of the SEPA Schemes. For the relationships between a
Participant and its Customer (Customer-to-Bank (C2B) & Bank-to-Customer (B2C)), and/or
relationships between Creditor and Debtor / Originator and Beneficiary (Customer-to-Customer
(C2C)), the Rulebooks and the STF specify and/or impose minimum requirements. These
requirements by default stem out of the Bank-to-Bank & Bank-CSM-Bank space. To assist the
actors in understanding their respective responsibilities in testing for SEPA Schemes readiness the
STF presents a schematical flow in Figure 2.
3
Definition approved by the EPC’s Plenary on December 2004
EPC228_06 SEPA Testing Framework
Page 9
FIGURE 2: SEPA TESTING SCOPE BY ACTOR
The EPC’s recommendation is that a Participant should build and maintain an end-to-end SEPA
Schemes compliant data set, processes, procedures and infrastructure with Straight Through
Processing (STP) as a core functional characteristic.
The STF with its SEPA Scheme’s Acceptance Criteria and Test Scenarios provides an unambiguous
means to test for the compatibility with the Rulebooks, Data Model and the corresponding
Implementation Guidelines. It is the Community and/or Participants responsibility to derive and build
their own test cases based on the SEPA Scheme’s Acceptance Criteria and Test Scenarios provided
by the EPC.
Communities and/or Participants must build their own scenarios and test cases for products/services
to corporates and other financial institutions, Additional Optional Services (AOS) and infrastructure
models.
EPC228_06 SEPA Testing Framework
Page 10
2.2
EPC Role and Responsibilities
The EPC is the decision-making and coordination body of the European banking industry in relation
to payments whose declared purpose is to support and promote the creation of the Single Euro
Payments Area (SEPA).
The EPC considers that meeting the objectives of SEPA will be achieved in the first place by the
adoption by Participants of the SEPA Schemes and standards, resulting in the availability of products
and services based on the Schemes. In turn this will have an impact on clearing and settlement
activities involved, at the level of systems, processes and time cycles. In order to launch SEPA, the
key priority is the adjustment of such systems, processes and time cycles to the standards of the
SEPA Schemes.
The EPC has outlined its core responsibilities as the following:
Define acceptance criteria & scenarios to be used by each SEPA Community as a basis for
Community testing, and communicating these to the Communities
Define test stages and reporting process, but not conduct/manage any testing activities beyond its
own operational deliverables
Carry out the functions of Scheme Management (e.g. manage the adherence process and operate
a Help Desk for Communities)
Create and maintain the register of Participants. Register of Participants will be a simple database
for registering and storing the information supplied by the Participants in their adherence
agreements; the database will not feature any routing data for processing of payments.
Define Community reporting requirements and test measurements to be used to monitor progress
Monitor overall testing and compliance progress
Liaise with ECB
2.3
Separation of the Scheme from the Infrastructure
It is a key feature of the SEPA Schemes that they provide a single set of rules, practices and standards
which are then operated by individual Participants and potentially multiple infrastructure providers.
Infrastructure providers include clearing and settlement mechanisms (CSMs) of various types and the
technology platforms and networks that support them.
The result is that the direct debit and credit transfer instrument based on a single set of rules, practices
and standards is operated on a fully consistent basis by CSMs chosen by individual banks as the most
appropriate for their needs.
2.4
Definition of Community
For the purposes of this document, the term ‘Community’ should be understood to be either a
national banking community or the set of Participants using a particular SEPA Scheme-compliant
CSM, or another grouping of banks which has defined itself for the purposes of implementation of
the SEPA Schemes. All other terms relating to communities in this document include the above
definition.
2.5
Community’s Role and Responsibilities
EPC treats all Communities equally. A Community’s role and responsibilities are as follows:
Represent the Participants who have signed or plan to sign the Adherence Agreements to the
SEPA Schemes
May represent its Participants at the EPC's Programme Management Forum, SEPA Testing Task
Force and Working Groups
EPC228_06 SEPA Testing Framework
Page 11
Set up a PMO headed by a Programme Manager to organise testing, monitor the progress of
implementation and testing, provide help desk service, liaise with other SEPA Communities
and the EPC and report on the implementation and testing results
Design with its Participants the criteria for operational readiness, i.e. the ones against which its
Participants have to report the operational readiness. SDD Core and SCT (including STF) is a
minimum scope
May define, following the agreement between the relevant Participants, test cases based on the
Acceptance Criteria and Test Scenarios (EPC’s STF document) as a minimum for SEPA
Schemes compliance
May define acceptance criteria, test scenarios and test cases to cover the Community AOS and
ensure their acceptance by the Participants
Involve appropriate CSMs in testing where necessary
Define community test plans and the criteria for community readiness and communicate those to
the Participants and the EPC
Cooperate with other Communities in organising cross SEPA testing and achieving reachability
Coordinate and manage as appropriate community and SEPA-wide testing
Fulfil the EPC reporting requirements
Handle communications within the Community
Receive declarations of readiness from individual Participants
Report on the status of achievement of SEPA Schemes’ readiness to the EPC
If necessary carry out tests together with Participants, e.g. when acting as a national CSM
Report to the EPC on the Community’s Schemes operational readiness
2.6
Participant
In the SEPA Testing Framework (STF) the term ‘Participant’ means a Debtor Bank and/or Creditor
Bank with reference to the SDD Schemes or an Originator Bank and Beneficiary Bank with reference
to the SCT Scheme.
The SDD Scheme distinguishes between two types of Participants:
The Creditor Bank: is the bank where the Creditor's account is held and which has concluded an
agreement with the Creditor in regard to the rules and conditions of a product based on the
SDD Scheme. On the basis of this agreement it receives and executes instructions from the
Creditor to initiate the Direct Debit Transaction by forwarding the Collection to the Debtor
Bank in accordance with the SDD Rulebook.
The Debtor Bank: is the bank where the Debtor’s account to be debited is held and which has
concluded an agreement with the Debtor in regard to the rules and conditions of a product
based on the SDD Scheme. On the basis of this agreement, it executes each Collection of the
direct debit originated by the Creditor by debiting the Debtor’s account, in accordance with
the SDD Rulebook
The Debtor Bank and Creditor Bank may be one and the same Participant
The SCT Scheme distinguishes between two types of Participants:
EPC228_06 SEPA Testing Framework
Page 12
The Originator Bank: is the Participant that receives the Credit Transfer Instruction from the
Originator and acts on the payment instruction by making the payment to the Beneficiary
Bank in favour of the Beneficiary’s account according to the information provided in the
instruction and in accordance with the provisions of the SCT Scheme
The Beneficiary Bank: is the Participant that receives the Credit Transfer Instruction from the
Originator Bank and credits the account of the Beneficiary, according to the information
provided in the instruction and in accordance with the provisions of the SCT Scheme
The Originator Bank and Beneficiary Bank may be one and the same Participant
The operation of the SDD and SCT Schemes also involves other parties indirectly:
CSMs: Clearing and Settlement Mechanisms such as an automated clearing house or other
mechanisms such as intra-bank or intra-group arrangements and bilateral or multilateral
agreements between Participants. The term Clearing and Settlement Mechanism does not
necessarily denote one entity. For example, it is possible that the clearing function and the
Settlement functions will be conducted by separate actors.
Intermediary Banks (also referred to as ‘Agents’): Banks offering intermediary services to Debtor
Banks and/or Creditor Banks, for example in cases where they are not direct participants in a
CSM.
2.6.1 Participant’s Role and Responsibilities
Implement SEPA Scheme-compliant products and services
Either define own test cases or join with other Participants on the Community level to produce a
uniformed set of the test cases for a given Community based on the Acceptance Criteria and
Test Scenarios (STF document) produced by the EPC as a minimum for SEPA Schemes
compliance
Execute, at a minimum, the test cases based on the STF Acceptance Criteria and Test Scenarios
In the absence of the Community equivalent, define acceptance criteria, test scenarios and test
cases to cover, if applicable, the Community, CSM and proprietary AOS
Execute test cases to cover any AOS if applicable
Respect the Community’s test plan, acceptance criteria and test scenarios (if applicable)
Involve CSM(s) in testing where required
Carry out as a minimum testing as defined in Chapter 4.3. that includes the following mandatory
parameters:
ƒ
On every SAL testing with Customer-to-Bank / Bank-to-Customer layer, where
applicable, must be planned and executed
ƒ
CSM has to be involved in testing on at least two SALs: Bank-CSM and Bank-CSMBank
ƒ
UNIFI (ISO20022) XML is the mandatory standard for SEPA Schemes compliant
payment messages in the Bank-to-Bank/Bank-CSM-Bank layers. Therefore testing
tools and processes have to be built, configured and used respecting this standard.
UNIFI (ISO20022) XML standard is not mandatory in the Customer-to-Bank / Bankto-Customer layer but highly recommended for higher levels of STP. Participants are
free in their choice of tools and processes
Maintain internal communications within the Community
Report their SEPA compliance and operational readiness to their Community
EPC228_06 SEPA Testing Framework
Page 13
2.6.2 Participant’s Customer-to-Bank/Bank-to-Customer Tests
The STF project team would like to draw the Participant’s attention to a number of useful principles
for testing between and/or including Participants and their customers:
The STF is not prescriptive on how and when a Participant should carry out testing with their
customers (Customer-to-Bank/Bank-to-Customer) or simulate customers during testing.
Although it should be noted that certain data sets (DS) are mandated by default from the
Bank-to-Bank layer. The Acceptance Criteria in Chapters 5 and 6 are clearly marked as to
cover a particular or multiple functional layers, e.g. Bank-to-Bank (B2B) only or also
including Customer-to-Bank or Bank-to-Customer (C2B/B2C)
Participants need to adopt the notion of ‘end-to-end testing’ this implies that the Customer to
Bank / Bank to Customer layer should also be tested within an uninterrupted payment chain
for all types of scenarios. For example, ‘Reject’ can be initiated by a CSM, a Beneficiary
Bank (Bank to Bank / Bank-CSM-Bank layer) or by a customer (Customer to Bank / Bank to
Customer layer)
The Rulebook does not impose any requirement as to the Terms and Conditions between a
Participant and its Customer, but Participants must ensure that the Terms and Conditions are
effective so as to enable Participants to comply with their obligations under the SEPA
Schemes
It is not mandatory under the STF for Participants to involve actual customers in their testing.
However they should ensure that the customer (as account holder using SEPA Scheme
compliant instrument) role, profile and actions are tested in an end-to-end process either by
creating a simulated customer environment or involving actual customers in the end-to-end
testing.
2.7
CSMs, ACH and PE-ACH
2.7.1 PE-ACH/CSM Framework
The PE-ACH/CSM Framework document (EPC170-05) establishes the principles on which CSMs
will support the Schemes on the basis of separation between the Scheme and relevant CSMs. The
document provides an update and clarification of the PE-ACH concept, building on work already
completed by the EPC. The Roadmap 2004-2010 enshrined the principle that Scheme and
infrastructure should be separated and therefore the PE-ACH/CSM Framework forms an important
complementary document.
2.7.2 Testing and Compliance by CSMs
A CSM that participates in the Scheme as a SEPA compliant CSM in accordance with the conditions
set out in the PE-ACH/CSM Framework shall carry out a regular self-assessment, as required by the
evolution of SEPA specifications, to demonstrate its compliance with the PE-ACH/CSM Framework.
A CSM that complies with the PE-ACH/CSM Framework shall notify its users and owners of its
compliance in an appropriate manner.
A CSM that operates solely on a bi-lateral or internalised basis pursuant to paragraph 2.1 of the PEACH/CSM Framework is not obliged to carry out a self-assessment or notify the SEPA Management
Committee (SMC) of its compliance with the PE-ACH/CSM Framework in accordance with this
section.
2.8
Eurosystem / NCB Role
Eurosystem / NCBs perform a monitoring role.
Eurosystem / NCBs only become involved in active testing if they carry out an operational role, i.e.
act as a CSM or a Participant.
EPC228_06 SEPA Testing Framework
Page 14
3
INTRODUCTION TO STF ACCEPTANCE CRITERIA AND
TEST SCENARIOS
This chapter should be read in conjunction with its source documents: the UNIFI (ISO 20022) XML
message standards, SCT and SDD Implementation Guidelines and the Rulebooks. Whilst all efforts
have been made to ensure consistency between this document and its sources, the source documents
always take precedence.
3.1
SEPA Acceptance Criteria
The SEPA Testing Framework (STF) is aimed at Communities and Participants and stipulates the
STF Acceptance Criteria (the Acceptance Criteria) to facilitate testing and operational readiness for
the SEPA Schemes. The Acceptance Criteria are derived from the Rulebooks and constitute a
comprehensive set of testing criteria to ensure a minimum but sufficient readiness for the SEPA
Schemes. They state what dataset and functionality must be provided by the system (including
business processes) in order for a Participant to be able to state that it is SEPA Schemes ready.
Partial or complete quotes from the Rulebooks have been included in the STF. Whist all efforts have
been taken to keep the definitions close to the source documents, i.e. Rulebooks and the
Implementation Guidelines, the source documents always take precedence.
3.1.1 Definition of Acceptance Criteria
The definition of Acceptance Criteria is “The exit criteria that a (…) system must satisfy in order to
be accepted by an (…) authorized entity” 4.
3.1.2 Quality Characteristics of the STF Acceptance Criteria
Generally, Acceptance Criteria can be drawn up based on a number of quality characteristics 5. The
SEPA Testing Framework covers the following quality characteristics:
Functionality (tested as a whole). One of its sub-characteristics, Interoperability, specifically
relates to the capability of systems to work together and thus relates to the major SEPA
Schemes requirement – Reachability. Other sub-characteristics of Functionality are:
ƒ
Suitability
ƒ
Accuracy
ƒ
Security
ƒ
Functionality Compliance
Efficiency (tested partially): certain Acceptance Criteria relate to the capability of the systems
to execute transactions within specific timeframes. This capability relates to the subcharacteristic Time Behaviour of the quality characteristic Efficiency.
Out of scope for the STF are all other quality characteristics such as reliability, usability,
maintainability and portability. They have not been taken into consideration when designing the
Acceptance Criteria. However Communities and Participants may need to test for these quality
characteristics.
4
5
As defined in the IEEE610 and ISTQB glossary.
For complete list refer to ISO9126
EPC228_06 SEPA Testing Framework
Page 15
3.1.3 STF Testing Principles
Some Acceptance Criteria can not be tested using a Test Scenario; in these situations a so-called
Testing Principle is provided.
A Testing Principle is a general rule or guideline used when assessing the SEPA Schemes
compliance. Testing Principles can be implemented and tested using several test cases but also might
be tested in a static manner. Static testing is testing a system at specification level by reviewing
documentation instead of executing the software. The opposite of static testing is dynamic testing.
3.1.4 Using the STF Acceptance Criteria
The STF Acceptance Criteria are a minimum set that should be used by Participants for testing for the
SEPA Schemes readiness in the Bank-to-Bank and to some extent in the Customer to Bank /Bank to
Customer space. Some Participants depending on the complexity of their operations may need to
produce their own acceptance criteria for testing in the Customer to Bank /Bank to Customer,
Customer to Customer interoperability, AOS and infrastructure space.
A Participant approaching testing for the SEPA Schemes operational readiness should understand the
relationship between the source and derived documents. The relationship together with the
explanation of the responsibilities is presented in Figure 3.
FIGURE 3: RELATIONSHIP OF THE SOURCE AND DERIVED DOCUMENTS
The Acceptance Criteria are listed in the order in which they appear in the Rulebooks. For each
Acceptance Criterion there is a reference to the location in the Rulebook. In some cases a
recommendation is added to clarify the meaning of the Rulebook. However, these recommendations
are not an extension of the Rulebooks; the source documents always take precedence.
The Acceptance Criteria have been used for defining the STF Test Scenarios (the Test Scenarios).
For each Acceptance Criterion a reference is made to the Test Scenario(s) that it is used in.
EPC228_06 SEPA Testing Framework
Page 16
3.1.5 The STF Acceptance Criteria – Testing Bulk Messages
The UNIFI (ISO20022) XML and the Implementation Guidelines provide a complete data set for
handling the bulk payments. However, the Rulebooks state that bulk processing is out of scope.
Therefore no Acceptance Criteria, Testing Principles or Test Scenarios have been specified for
testing the operational readiness for bulk payments. Participants that process and originate bulk
payments should test that they operate correctly.
For a scenario specific test cases for both single payments and bulk payments should be made. Be
aware, especially for ‘R-transactions’, that variances for bulk and single payments may exist. As bulk
payments are a service often delivered by a CSM the Participant will have to check the handling of
bulk payments with its CSM. Participants should be aware that different CSMs may have different
ways of handling bulk payments.
3.2 Definition of Test Scenarios
The Test Scenarios are the operational procedural means to test whether the Acceptance Criteria are
met.
A Test Scenario describes a specific business process flow from end-to-end, i.e. from the Originator
to the Beneficiary in SCT and from the Creditor to the Debtor in the SDD. The STF covers the Bankto-Bank layer that includes partially the Customer-to-Bank and Bank-to-Customer layers. This way
the STF follows the setup of the Rulebooks and the Implementation Guidelines. There are no specific
Test Scenarios for the Customer-to-Bank and Bank-to-Customer layers.
3.3 Using the SEPA Test Scenarios
Participants and as applicable Communities of Participants will use the Test Scenarios to create Test
Cases for their specific operation to assess their SEPA Schemes readiness. For each Test Scenario
multiple Test Cases could be produced using testing techniques. When producing their Test Cases
Participants must use the UNIFI (ISO20022) XML standard and Implementation Guidelines. These
Test Cases do not have to be limited to the scope of the Rulebooks, STF Acceptance Criteria, STF
Testing Principles and/or STF Test Scenarios. Participants may develop additional Test Cases related
to the Participants’ AOS, Bank-to-Bank bi-lateral arrangements, Bank-to-CSM and Bank-to-CSM-toBank arrangements, Customer-to-Bank and Bank-to-Customer arrangements and infrastructure setup.
Guidance for these additional Test Cases is out of scope for this document.
Note that all examples shown in italics are only provided for purpose of clarification and are not an
extension to the rules from the Rulebooks. These examples and clarifications are provided on the best
practice advice basis; e.g. they may be used as advice on specific exceptional situations. Such
examples must be evaluated for correctness, completeness and applicability to a specific situation of a
Participant.
3.3.1 Presentation of the STF Test Scenarios
The following structure is used to present the STF Test Scenarios:
For the description of each Process Step in any Test Scenario please refer to the applicable
Rulebook
For certain Test Scenarios one or more sub-scenarios have been produced. The objective of these
sub-scenarios is to illustrate specific situations that require extra test cases
SEPA Test Scenarios always have a logical start and a logical end, they always describe a
transaction initiated by a customer and resulting in a message to a customer. This is based on
the principle of ‘valid testing’ (also known as ‘positive testing’) which means use input that
should be handled correctly by the system. In order to do a thorough assessment of the
quality of a system Participants will also need to conduct ‘invalid testing’ (also known as
‘negative testing’) to determine if exceptional situations are handled correctly. Examples:
EPC228_06 SEPA Testing Framework
Page 17
ƒ
Test to establish whether a dataset that holds unrecognisable data does not block the
whole transaction system
ƒ
Test for a situation where a transaction system becomes totally unavailable during the
processing of a transaction (for example by shutting of the power of the machine);
after making the system operational again the transaction should be processed and not
be lost
3.4 Deriving the Test Cases
In Chapter 3.4 the STF contains best practice advice (hints and tips) on deriving the Test Cases using
the EPC’s documents. This advice is not prescriptive and is provided to avoid possible pitfalls in
testing towards the SEPA Schemes readiness. Figure 4 presents the logical order in which the
industry and EPC’s documents should be used to derive the Test Cases.
UNIFI ISO20022 XML
Standard
SCT & SDD
Implementation
Guidelines
SCT & SDD
Rulebooks
FIGURE 4: ORDER OF THE EPC’S DOCUMENTS FOR TEST CASES
In-depth knowledge of the UNIFI (ISO20022) XML standard, the Implementation Guidelines and the
Rulebooks is required to derive the Test Cases. The UNIFI (ISO20022) XML standard is a
comprehensive document with all possible message elements and codes for financial transactions.
The Implementation Guidelines contain a ‘core SEPA service’ data set; the data set that constitutes
the minimum required functionality for the SEPA Schemes readiness. The Rulebooks support the
Implementation Guidelines with Data Sets (DS), Attributes (AT) and business flows.
In the process of specifying Test Cases different inputs could be used. In addition to the documents
mentioned above Participants may consider using their own requirements’ specifications and those of
the applicable Community (or Communities) that possibly contain various types of AOS. The STF
sets the minimum required set of adherence criteria and scenarios.
STF recommends that the specialists involved in test analysis and design gain an in-depth knowledge
of these documents through self-study and/or professional training.
3.5
Test Plan and Strategy
STF recommends that Participants produce a Test Plan that also comprises a Test Strategy to specify
and prioritise the Test Cases. Participants should also consider using the documentation mentioned in
Chapters 3.3 and 3.4. Figure 5 represents the STF test process and its necessary inputs and outputs as
the process steps. Note that Figure 5 does not present all possible relationships of processes and/or all
possible inputs and outputs; it only contains relationships relevant for the STF.
EPC228_06 SEPA Testing Framework
Page 18
UNIFI ISO20022
XML
SCT & SDD
RULEBOOKS
SCT & SDD
Implementation
Guidelines
SEPA Testing
Framework (STF)
Acceptance Criteria,
Test Scenarios &
Testing Principles
Test Planning &
Control
Test Analysis
& Design
Test
Plan
Test
Cases
Test Execution
Evaluate Exit
Criteria
& Reporting
Test Summary
Report
FIGURE 5: TEST PLAN AND STRATEGY
The actual actors involved in the execution of Test Cases may vary. The process steps for any process
role (e.g. Originator Bank, Beneficiary Bank, Creditor Bank or Debtor Bank) may be performed by
the same Participant. Many Test Cases will include a CSM. It is also possible that two or more
Participants may perform one or more process steps and together will cover the entire process based
on a Bank-to-Bank bi-lateral arrangement. If this is the case the Participants together must assess
whether their systems and procedures meet the STF Acceptance Criteria. Chapter 4.3 presents four
distinctive Self Assessment Levels (SAL) that cover possible cooperative ways of testing for SEPA
Schemes readiness.
3.6 Naming Conventions
All Acceptance Criteria, Testing Principles and Test Scenarios are uniquely identified.
The naming convention and identifications for the SEPA Credit Transfer Scheme are presented
below:
CTAc-01 means Credit Transfer Acceptance Criterion, with sequence number 1
CTTp-01 means Credit Transfer Testing Principle, with sequence number 1
CTSc-01 means Credit Transfer Test Scenario, with sequence number 1
CTSc-01a means the first sub-scenario of Credit Transfer test Scenario, number 1
The naming convention and identifications for the SEPA Direct Debit Scheme are presented below:
DDAc-01 means Direct Debit Acceptance Criterion, with sequence number 1
DDTp-01 means Direct Debit Testing Principle, with sequence number 1
DDSc-01 means Direct Debit Test Scenario, with sequence number 1
DDSc-01a means the first sub-scenario of Direct Debit test Scenario, number 1
EPC228_06 SEPA Testing Framework
Page 19
3.7 Test Measurements
The test measurements defined here represent a best practice recommendation. Participants and
Communities may use any form of mutually or bi-laterally agreed reporting.
Testing in general results in two outcomes:
Insight into the quality of the test object (demonstrated by the number of test cases successfully
executed versus the total number of test cases)
Insight into the remaining faults/defects at the moment of going live with the system (often called
“known errors”)
The results of the testing are reported in the Test Summary Report that is issued by the test manager
(or the project manager if there is no separate test manager).
Based on the Test Summary Report a Participant can decide whether or not it is SEPA Scheme
compliant. To be compliant no high-severity faults/defects can be unresolved.
The following list presents test measurements that would preferably be reported in the Test Summary
Report (ANNEX 2: Participant’s Test Summary Report). During the project the test manager may
also report these numbers in his status reports in order to demonstrate the progress of quality of the
test object and of the testing activities.
•
Number of Acceptance Criteria fulfilled vs. total number
•
Number of Test Scenarios tested vs. total number
•
Number of reviews performed vs. planned
•
Number of faults found during reviews
•
Number of faults fixed and re-reviewed
•
Number of faults solved vs. total number of faults (preferably grouped per severity)
•
Number of test cases specified vs. planned
•
Number of test cases executed vs. number specified
•
Number of test cases executed and correct vs. total number executed
•
Number of defects found
•
Number of defects fixed and retested
•
Number of defects solved vs. total number of defects (preferably grouped per severity)
•
Number of remaining faults and defects at the time of the Test Summary Report (i.e. endreport) (preferably grouped per severity)
•
Result of causal analysis (investigation of the origin of the faults/defects, e.g. fault in
functional specification, defect in program, fault in test case, problem in test environment
etc) to be used for process improvement.
Apart from the numbers about the quality of the test object the test manager may also want to include
numbers on the effort spent on testing (e.g. hours needed to specify test cases and to execute test
cases) but that is considered good test management practice and out of scope for the SEPA Testing
Framework.
Note: The ISTQB Glossary defines the terms “fault” and “defect” as synonyms, in the list above
however to make a distinction between the incidents found during reviewing (static testing) are
referred to as “faults” and the incidents found during test execution (dynamic testing) are referred to
as “defects”.
EPC228_06 SEPA Testing Framework
Page 20
4
4.1
OPERATIONAL READINESS FOR SEPA SCHEMES
Introduction
The SEPA Roadmap stipulates that SEPA implementation and testing is the responsibility of
Communities and Participants. During the implementation phase the EPC’s role is one of monitoring
and reporting progress on the implementation and testing by the Communities.
Chapter 4 is limited in scope to the operational readiness for the SEPA CT and DD Schemes,
excluding AOS. It does not cover the SEPA Cards and Cash Frameworks.
The basis for the pan-European SEPA compliance is the readiness of individual Participants. The
fulfilment of this principle is based on the readiness of Participants and CSMs.
4.2
Overview of Reporting & Information Flows for Operational Readiness
Chapter 4 provides an overview of reporting and information flows that a Participant may follow as
part of the adherence process and separately for reporting of their operational readiness for the SEPA
Schemes.
3. Independent
Industry DBs
2. Operational
1. Adherence
Readiness
Agreements
Reports & Info
Reporting & Information Flows – SEPA Schemes Operational Readiness
EPC
Participant
Send via agreed channel
Signs SDD & SCT
Adherence Agreements
Stores
Adherence Agreements
Participant
Carries out testing according
to agreed with their
Community Operational
Readiness criteria
Receives, acknowledges &
stores SDD & SCT
Community
Report
Receives, accepts/rejects,
acknowledges, stores and reports
on the Community readiness
EPC
Register of
Participants
$€
EPC
Report
Receives, acknowledges & reports
on ALL Communities readiness for
SDD & SCT Schemes
Report
EC & ECB
Participant 1
Participant
Registers its agreed set of
information (incl. BIC) on an
industry database to ensure
and indicate that it’s reachable
Register
Routing /
Reference DBs
Independent service
Provides information on demand on
agreed terms
Participant 2
Participant n
FIGURE 6: REPORTING & INFORMATION FOR SEPA SCHEMES OPERATIONAL READINESS
Figure 6 presents three major reporting and information flows for the adhering Participants:
1. Adherence agreements are sent from Participants to the Scheme Management Entity (SME) to
confirm that they will participate in the selected SEPA Schemes. The EPC acting as SME is
responsible for organising and maintaining the register for adhering Participants; it may chose to
outsource processing of data, database running and maintenance to a third party ensuring that the
commercial and competitive neutrality of the service is preserved
2. Information on the status and progress of testing and implementation is sent by Participants to
their Community(s). The Communities send consolidated information to the EPC. The EPC
forwards consolidated information to the European Commission and the ECB. The Communities
may also copy the readiness information and/or reports directly to EC and ECB
EPC228_06 SEPA Testing Framework
Page 21
3. As soon as a Participant is ready to process SEPA-compliant payments it registers all relevant
routing BICs, accompanied by supporting contact and operational information, in a register of
Participants that holds a complete record for each adhered and operationally ready Participant,
i.e. provides information on reachability. This service is provided on commercial basis by the
market parties and infrastructures. Although EPC strongly encourages the development and
provision of reference and verification databases (services), EPC is neither a provider nor the
governing body of such services.
In the remainder of Chapter 4 these reporting and information flows, responsibilities of the actors and
outcomes are presented in detail.
4.3
Self-Assessment Levels for Participants
A Participant will declare itself SEPA Scheme compliant when it successfully and sufficiently
completes the tests to satisfy the STF Test Scenarios and STF Testing Principles that by default cover
the Acceptance Criteria (Chapter 3).
The testing for the SEPA Schemes operational readiness should be performed at different test levels.
The STF prescribes the Acceptance Test based on four Self Assessment Levels (SALs) in Figure 7.
SAL I is mandatory for the self-assessment process of a Participant, SALs II, III and IV are optional
but strongly recommended as these levels can demonstrate whether the Participants payments
accounts are actually reachable.
Bank Ù CSM
IV
Ù Bank
Bank Ù CSM
Bank Ù Bank
III
II
(Bi-lateral)
Participant
Responsibility
Bank Internal
I
FIGURE 7: SELF ASSESSMENT LEVELS (SALS)
Self Assessment Levels (SALs):
1. SAL I – Bank Internal: At this level a Participant will perform testing within the limits of its
own organisation (e.g. group level); this may include testing cross-border when testing with
subsidiaries, but is still treated as the bank internal testing. It is expected that a Participant will
test at all internal operational levels along the financial transaction chain, i.e. Customer to Bank
and Bank to Customer, as well as internal infrastructure for the delivery of SEPA compliant
products and services
2. SAL II – Bank-to-Bank: At this level a Participant tests together with other Participant(s) on bilateral basis, i.e. not involving a CSM. If necessary testing on this level may be extended for
AOS. When a Participant does not have bi-lateral agreements SAL II is not relevant.
EPC228_06 SEPA Testing Framework
Page 22
3. SAL III – Bank-CSM(s) / CSM(s)-Bank: At this level a Participant and CSM(s) test
communication and data sets for being able to send compliant transactions and/or files to CSM(s)
as well as being able to receive compliant transactions and/or files from CSM(s). SAL III may be
performed on a community level as well as on the cross SEPA level. If necessary testing on this
level may be extended for AOS
4. SAL IV – Bank-CSM-Bank: It is expected that a Participant may test at all operational levels
along the financial transaction chain, i.e. Customer to Bank, Bank-to-Bank, Bank-CSM-Bank and
Bank to Customer. SAL IV can be performed on a community level, but the preference is to carry
out the cross SEPA testing. If necessary testing on this level may be extended for AOS
4.4
Criteria for Operational Readiness
The EPC’s strong recommendation is that Communities together with their Participants should
produce a set of Criteria for Operational Readiness. Participants will use these criteria for submitting
a Declaration on SEPA Scheme Operational Readiness to their Community(s).
4.4.1 Reporting Information by a Participant
The following list represents a recommended minimum set of reporting information supplied by a
participant per SEPA Scheme:
Name and legal address of the Participant. Participants may chose to report on the Group level
or by individual operation, e.g. Bank A in Germany, Bank A in the Netherlands and Bank A
in Belgium. In the case of reporting on the individual operation level, registered legal name
and address for the country of operation must be stated
BIC of the Participant. When reporting on the individual operation level Participants must use
the reference and/or routing BIC for that operation; they should not provide a reference BIC
of their Head Office
Community affiliation. The Declarations on SEPA Scheme Operational Readiness are
submitted on the community level, therefore a Participant may end up submitting more than
one declaration, e.g. one per SEPA Scheme to the EBA, one to the Belgian Community and
one to the SWIFT led Community
CSM(s). A Participant may potentially test with more than one CSM. The report should state the
name of all CSMs with which the Participant successfully tested per individual SEPA
Scheme
SEPA Scheme and Self Assessment Levels within it. Due to different requirements for the
adherence to the SEPA Schemes the EPC requests that the Participants submit separate
declarations per SEPA Scheme, i.e. one for the SCT Scheme and one for the SDD Scheme. It
is also important to see the level of operational readiness towards a particular SEPA Scheme
therefore Participants should clearly state their readiness per Self Assessment Level. The STF
advises that the Participants also submit additional Supporting Information together with the
Declaration on SEPA Scheme Operational Readiness. An indicative list of test measurements
and results, required per individual SEPA Scheme and its Self Assessment Levels, are
presented in Chapter 3.7. The Communities and Participants are free to expand the list to
make it community or operation specific. The reports should at least include the detailed
information for testing on each Self Assessment Level (SAL) as per Chapter 4.3.
Communities and Participants may extend the list of parameters for reporting
Communities and Participants must as a minimum report on the parameters and Self Assessment
Levels that are requested by the EPC in Chapters 4.4.2 and 4.4.3
EPC228_06 SEPA Testing Framework
Page 23
4.4.2 Self Assessment Levels for the SCT Scheme
It is mandatory for a Participant to carry out as a minimum testing on SAL I, and it is strongly
recommended to carry out at least one other SAL 6.
Being operationally ready indicates having successfully tested and being SCT Scheme ready in the
capacity of the Originator Bank and of the Beneficiary Bank
Successfully tested on Bank Internal SAL I
Successfully tested on Bank-to-Bank (bi-lateral) SAL II
Successfully tested on Bank to CSM(s) SAL III (cross Community or cross SEPA)
Successfully tested on Bank-CSM-Bank SAL IV (cross Community and cross SEPA)
4.4.3 SALs for the SDD Schemes
It is mandatory for a Participant to carry out as a minimum testing on SAL I, and it is strongly
recommended to carry out at least one other SAL 7 .
1. Successfully tested and SDD Schemes ready in the capacity of the Creditor Bank (Optional),
Successfully tested on Bank Internal SAL I
Successfully tested on Bank-to-Bank (bi-lateral) SAL II
Successfully tested on Bank to CSM(s) SAL III (cross Community or cross SEPA)
Successfully tested on Bank-CSM-Bank SAL IV (cross Community and cross SEPA)
2. Successfully tested for processing of the mandate in the Creditor Bank role as specified in the
SDD Rulebook (Optional)
3. Successfully tested and SDD Schemes ready in the capacity of the Debtor Bank (Mandatory)
Successfully tested on Bank Internal SAL I
Successfully tested on Bank-to-Bank (bi-lateral) SAL II
Successfully tested on Bank to CSM(s) SAL III (cross Community or cross SEPA)
Successfully tested on Bank-CSM-Bank SAL IV (cross Community and cross SEPA)
4. Successfully tested for processing of the mandate in the Debtor Bank role as specified in the
SDD Rulebooks
4.5
Communities - Self-Assessment and Readiness Declaration
A Community may declare itself SEPA Schemes operationally ready to EPC when its constituent
Participants achieve and report the SEPA Schemes operational readiness according to the pre-defined
set of criteria in Chapter 2.5.
EPC requests that Communities report as a minimum on the following set of parameters:
1. Total number of institutions, intending to participate in the SEPA Credit Transfer Scheme
2. Number (and also expressed as a percent of the overall number of Participants who signed the
Adherence Agreement) of Participants who successfully tested and are SCT Scheme ready
3. Total number of institutions, intending to participate in the SEPA Direct Debit Schemes
6
Where a Participant is part of a decentralised banking community and uses shared payment processing, SAL I
may be sufficient.
7
Where a Participant is part of a decentralised banking community and uses shared payment processing, SAL I
may be sufficient.
EPC228_06 SEPA Testing Framework
Page 24
4. Community Declaration on SEPA Schemes Operational Readiness (self defined document)
Additionally communities may also use transaction volumes as a parameter to measure their SEPA
readiness.
4.6
Activities for SEPA Schemes’ Readiness: EPC, Communities and Participants
Chapter 4.5 addresses the interaction and cooperation between the following actors:
A bank preparing to be a Participant in the SEPA Schemes
The community-level organisation of the Community to which the Participant belongs
The EPC PMO. The EPC is setting up the SEPA PMO (within the Secretariat) to support and
monitor Community implementations, and to define acceptance criteria by which
Communities will achieve SEPA Scheme compliance
Figure 8 represents a recommended process for achieving SEPA Schemes readiness.
FIGURE 8: REPORTING SEPA SCHEMES’ OPERATIONAL READINESS
4.6.1 Stage 1: Participants to the EPC - Adherence Agreements
Only eligible undertakings (banks) can become a Participant; eligibility principles are started in
Chapter 5.4 of the SCT and SDD Rulebooks.
According to Chapter 5.5 of the SCT and SDD Rulebooks to apply to become a Participant, an
undertaking shall submit to the EPC an executed and original Adherence Agreement and submit
Supporting Documentation to the EPC.
A Participant that signs a SEPA Scheme Adherence Agreement (there are separate agreements for the
Schemes) becomes a SEPA Scheme Participant and commits towards achieving a SEPA Scheme
readiness. This requires the Participant to comply fully with the SEPA Scheme Rulebooks and their
supporting documents/standards.
Any bank declaring SEPA SCT and/or SDD Schemes readiness must:
EPC228_06 SEPA Testing Framework
Page 25
Be reachable by any other bank within SEPA under the SEPA Schemes
Have access to one or more CSMs sufficient for its purposes as set out in the PE-ACH/CSM
Framework
4.6.2 Stage 2: Preparation and Testing for SEPA Schemes Readiness
To set up a unified standard and levelled implementation environment the EPC supplies the
Communities and Participants with a set of documents that must be used for testing; refer to Chapter
3 for detailed instructions on how to use the EPC documentation for testing on SEPA Schemes’
readiness. The documents are readily available to Communities and Participants through the normal
communication channels of the EPC.
The EPC established a Programme Management Office (PMO) with objectives to monitor, support
and facilitate the implementation and testing processes undertaken by Communities for SEPA
Schemes’ readiness. The major principle of the EPC PMO is that it interacts exclusively with the
Communities’ PMOs. Participants are expected to interact with their Communities on organisation,
consultation and reporting issues, and not directly with the EPC PMO. The only exception out of this
principle is that Participants submit the Adherence Agreements and other registration information
directly to the EPC Secretariat.
Implementation of SEPA is a joint responsibility of Communities and Participants that belong to a
given community. To coordinate and synchronise implementation and testing activities Communities
and Participants (some Participants may be members of multiple Communities) set up a joint
Programme Management Office (PMO) on a community level to undertake the following activities:
1. A Community liaises and provides to the EPC Secretariat the following information and reports
per SEPA Scheme:
Regular national implementation progress report, including status on banks and CSMs
The Criteria for Operational Readiness agreed on the Community level:
ƒ
Defined Criteria for Operational Readiness for the Community
ƒ
Defined Criteria for Operational Readiness for the Participants
A plan for Community testing, involving banks and CSMs
Declaration of community operational readiness, i.e. confirmation of successful implementation
and testing
Resolution of the implementation issues of common relevance to the Community
Identified risks and impediments to implementation and testing on the Community level
Participation in the EPC’s Programme Management Forum
2. A Community liaises and assists its Participants with the following activities:
Preparation of acceptance criteria, test scenarios, test cases and testing strategy (if there is an
operational necessity these may be produced beyond the scope of the STF)
Preparation of the Criteria for Operational Readiness
Milestones for implementation and for testing
Timetable for implementation and for testing
Solutions for implementation issues of common relevance to banking community with overall
support in the community
Monitoring of national implementation progress and in this context securing timely adherence
and timely implementation of all banks
Regular report on national implementation progress
Coordination of information flow between EPC bodies, national bodies and banks respectively
EPC228_06 SEPA Testing Framework
Page 26
Market- and risk-monitoring, provide information to banks (e.g. PSD, consumer and end user
acceptance)
Common national communication strategy
Organisation of community self certification
Monitoring of CSM progress in SEPA implementation
Report on implementation progress of CSM
3. The EPC Secretariat will coordinate and run under the Programme Management Forum (PMF)
directions (Chapter Error! Reference source not found.). Through the PMF, Communities’
PMOs may liaise with each other and meet on a regular basis to share experience and best
practise, and discuss implementation and testing issues. The EPC Secretariat assists the
Communities and Participants with the following services:
Commonly agreed milestones for the European banking industry
Implementation planning check list
Produce and provide STF Acceptance Criteria and Test Scenarios
Provide Help Desk service
Regular report on SEPA wide implementation progress, issues and risks
Market- and risk-monitoring on European level
SEPA wide implementation progress and appropriate report
Programme risk register
It is intended that the EPC deals primarily with SEPA implementation organisations for
Communities. Participants should always engage with their Community(s).
4. Participants will engage in the following activities:
Design and implement SEPA Schemes compliant product, services and solutions
Test for the SEPA Schemes operational readiness using the Acceptance Criteria and Test
Scenarios from Chapter 3 and according to the required SALs in Chapter 4.3
Participate in their Community(s) PMO activities (when applicable)
4.6.3 Stage 3: Reporting of SEPA Schemes Readiness
1. Actions of Participants:
Finalise testing according to the agreed with Community(s) Criteria for Operational Readiness
Submit Declarations on SEPA Scheme Operational Readiness to their Community(s)
2. Actions of Communities:
Collect and process the Participants’ Declarations on SEPA Scheme Operational Readiness
Submit Declarations on SEPA Scheme Operational Readiness to the EPC Secretariat
3. Actions of the EPC:
Collect and process the Communities’ Declarations on SEPA Scheme Operational Readiness
Report the status of the SEPA Schemes readiness to the European Commission and the European
Central Bank
Launch SEPA
EPC228_06 SEPA Testing Framework
Page 27
4.7
Compliance by CSMs
A CSM that participates in the Scheme as a SEPA compliant CSM in accordance with the conditions
set out in the PE-ACH/CSM Framework shall carry out a regular self-assessment to demonstrate its
compliance with the PE-ACH/CSM Framework.
A CSM that complies with the PE-ACH/CSM Framework shall notify its users and owners of its
compliance in an appropriate manner.
A CSM that operates solely on a bi-lateral or internalised basis pursuant to paragraph 2.1 of the PEACH/CSM Framework is not obliged to carry out a self-assessment or notify the SMC of its
compliance with the PE-ACH/CSM Framework in accordance with this section.
4.8
Other Activities to Achieve Operational Readiness (Best Practice Advice)
Operational readiness for SEPA Schemes means to be a SEPA Scheme compliant (either SCT or
SDD) and able to process SEPA payments according to the corresponding SEPA Scheme Rulebook.
Operational readiness means that Participants are able to offer their customers at least one SEPA
Scheme-compliant Customer to Bank-channel for each SEPA product that they intend to offer.
For an official declaration of operational readiness, Participants have to prove SEPA compliance.
They have to conduct tests at Community and cross SEPA levels with other Participants both on
bilateral basis and involving CSMs.
To achieve operational readiness Participants must adapt their internal and external systems and
interfaces. Adaptations are necessary in five main areas:
Internal systems and interfaces
External interfaces
Product design
Processes and procedures
Legal compliance
Participants must adapt their contractual basis in Customer to Bank space as well as in inter-bank
space and with CSMs, to comply with the SEPA Scheme Rulebooks and the Payment Service
Directive. Relevant legal areas are as follows:
Service Level Agreements with SEPA compliant CSMs. Banks must ensure adequate
arrangements for operational clearing and settlement with SEPA-compliant CSMs
General terms and conditions
Rules and conditions of SEPA products
Agreement with creditors about the rules and conditions of the collection of direct debits
Singed Adherence Agreements for each of the SEPA Schemes
EPC228_06 SEPA Testing Framework
Page 28
5
SEPA CREDIT TRANSFER
5.1 SCT Acceptance Criteria
ID
C2B 8
B2B 9
B2C 10
Acceptance Criteria for SEPA Credit Transfer
CTAc-01
x
x
x
CTAc-02
x
x
x
CTAc-03
x
x
x
CTAc-04
x
x
CTAc-05
x
x
CTAc-06
x
x
CTAc-07
x
Test Acceptance Criteria
Payments are made for the full Original Amount
Also refer to CTAc-24
The Originator and the Beneficiary are responsible for
their own charges
Full reachability of all Beneficiary payment accounts
held at the adhering SEPA Participant
On the Acceptance Date (D), the Originator Bank will
debit the account of the Originator. This will be
followed by the sending of the Credit Transfer
Instruction to ensure receipt by the Beneficiary Bank
via the selected CSM, at the earliest on day D and at
the latest on day D + 2, according to the rules of the
CSM.
The Beneficiary Bank will receive the credit transfer
message at the latest on the Settlement Date (D + 2
at the latest), check the credit transfer message, credit
the account of the Beneficiary, and make the
information of DS-04 available to the Beneficiary on
the basis agreed between the Beneficiary and his
bank. Such credit must occur by Settlement Date + 1
at the latest (day D+3 at the latest overall)
The Beneficiary Bank will (…) credit the account of the
Beneficiary (…) by Settlement Date + 1 at the latest
(day D+3 at the latest overall), except in the case that
legal constraints (…) have not been fulfilled , or if
day D+3 is not a Customer Banking Business Day. In
this latter case, the Beneficiary Bank must credit the
Beneficiary at the latest on the first following
Customer Banking Business Day.
A community AOS may not disturb the operation of, or
compromise in any way, the SEPA Scheme for
Participants who do not take part in the AOS
Also refer to CTAc-26 and CTAc-27
Ref to Rulebook
&
Implementation
Guidelines
Ref to
Scenarios
or
Principles
CT Rb s 1.7
CT Rb s 5.8
bullet 9
CTTp-01
CTSc-01c
CT Rb s 1.7
CTTp-02
CT Rb s 1.7
CTTp-03
CT Rb s 1.8
CT Rb s 4.2
CT Rb s 4.3
CTSc-01
CT Rb s 1.8
CT Rb s 4.2
CT Rb s 4.3
CTSc-01
CT Rb s 4.3
CTSc-01a
CT Rb s 2.3
CT IG s 1.3
CTTp-05
8
In Table 1 and Table 3 the ‘C2B’ abbreviation denotes a ‘Customer-to-Bank’ relationship.
In Table 1 and Table 3 the ‘B2B’ abbreviation denotes a ‘Bank-to-Bank’ relationship which may also involve
a CSM. Elsewhere in the text the term is spelt out in full.
10
In Table 1 and Table 3 the ‘B2C’ abbreviation denotes a ‘Bank-to-Customer’ relationship.
9
EPC228_06 SEPA Testing Framework
Page 29
CTAc-08
x
x
x
All transactions are in euro in all process stages,
including all exception handling, i.e. Rejects and
Returns.
The accounts of the Originator and of the Beneficiary
may be in euro or any other currency. Any currency
conversion is executed in the Originator Bank or
Beneficiary Bank and is not governed by this Scheme.
The SEPA Data Model has no data item for currency
code but the UNIFI (ISO20022) XML Standard does
have currency codes so it must be tested that always
EURO is used.
CTAc-09
x
x
x
The remittance data must be forwarded in full and
without alteration
B2B 9
Test Acceptance Criteria
ID
C2B 8
B2C 10
Acceptance Criteria for SEPA Credit Transfer
CTAc-10
x
x
CTAc-11
x
x
CTAc-12
x
x
CTAc-13
x
CTAc-14
x
CTAc-15
x
CTAc-16
x
x
CTAc-17
x
x
CTAc-18
x
CTAc-19
x
x
The data elements for the Credit Transfer Instruction
are as defined in the datasets DS01, DS02, DS03 and
DS04 and the Implementation Guidelines
The message elements indicated as yellow, white and
red in the Implementation Guideline must be used
accordingly.
The Originator Bank receives and checks if it has
sufficient information to execute a payment instruction
and that the instruction fulfils the conditions required
by its procedures as to execution of the instruction
including the authenticity of the instruction, and the
checking of the format and plausibility of the BIC and
the check-digits of the IBAN.
The Originator Bank checks the conformance of the
data elements according to the business requirements
for attributes specified in section 4.6.
One of the possibilities to verify the plausibility of the
BIC of a Beneficiary Bank is by checking in a
reference directory
Originator Bank ensures that the correct account and
amount is debited on the Acceptance Date (D)
CSM sends the credit transfer message to the
Beneficiary Bank and settles the amount at the latest
on the Acceptance Date + 2 Banking Business Days
A Reject must contain data as specified in DS-03,
including a reason code and relevant data for an audit
trail
'Reject' messages should be transmitted on a same
day basis and must at the latest be transmitted on the
next Banking Business Day.
The Originator Bank credits the Originator's account
after a Reject
If the Originator Bank is able and willing to repair a
rejected CT it must be resent within the execution time
A Return must contain data as specified in DS-03,
including a reason code and relevant data for an audit
trail
'Return' messages initiated by the Beneficiary Bank
must be transmitted to the Originator Bank within
three Banking Business Days after Settlement Date.
EPC228_06 SEPA Testing Framework
Ref to Rulebook
&
Implementation
Guidelines
Ref to
Scenarios
or
Principles
CT Rb s 2.4
CTSc-01
CTSc-02
CTSc-03
CT Rb s 2.8
CTSc-01
CTSc-02
CTSc-03
CT Rb s 4.3
CT-01 and
CT Rb s 4.5
CT IG s 1.1
CTTP-04
CT Rb s 4.3
CT-02
CT Rb s 4.6
CTSc-02
CT Rb s 4.3
CT-03
CTSc-01
CT Rb s 4.3
CT-04
CTSc-01
CT Rb s 4.4
CTSc-02
CT Rb s 4.4
CTSc-02
CT Rb s 4.4
CT-04R
CT Rb s 4.4
CT-04R
CTSc-02
CTSc-02a
CT Rb s 4.4
CTSc-03
CT Rb s 4.4
CTSc-03
Page 30
B2B 9
CTAc-20
x
x
CTAc-21
x
x
B2C 10
ID
C2B 8
Acceptance Criteria for SEPA Credit Transfer
CTAc-22
x
x
CTAc-23
x
x
CTAc-24
x
CTAc-25
x
CTAc-26
x
Test Acceptance Criteria
The Originator Bank credits the Originator's account
after a Return
Where an Originator has provided information in a
specific payment instruction relating to an optional
DS-02 field this will be populated in the Inter-Bank
message subject to any overriding legal/regulatory
requirements
In principle Participants must always copy information
supplied by the Originator in the Inter-Bank message.
Only when the legal environment of the Participant
allows so the Participant may not copy this
information.
Where any of the attributes of DS-04 are present in an
Inter-Bank payment message (DS-02) the contents
must be made available in full by the Beneficiary Bank
to the Beneficiary
If there is no agreement with the Beneficiary under
which the Beneficiary Bank may deduct its own fees
from the amount transferred, the Beneficiary Bank
shall credit the account of the Beneficiary with the full
amount of the payment in accordance with the time
cycle defined in Chapter 4 of the SCT Rulebook.
According to acceptance criterion CTAc-01 (full
original amount) and this acceptance criterion, the
Beneficiary Bank must separately charge the
customer without changing the original amount.
If there is an agreement with the Beneficiary under
which the Beneficiary Bank may deduct its own fees
from the amount transferred before crediting the
Beneficiary's account then the Beneficiary Bank
credits the account of the Beneficiary with the lesser
amount of the payment in accordance with the time
cycle defined in Chapter 4 of the SCT Rulebook.
Chapter 5.8 (bullet 9) of the SCT Rulebook defines
the obligation to carry the full original amount from the
Originator to the Beneficiary, but it also holds one
exception when a fee may be deducted from the
original amount.
Also refer to CTAc-01
Only days which are Banking Business Days in the
relevant jurisdictions for both the Originator Bank and
Beneficiary Bank shall be included in the computation
of any period of time under the Rulebook
It is the responsibility of the instructing bank to ensure
that AOS message elements are only included in
messages sent to AOS community members
Also refer to CTAc-07 and CTAc-27
EPC228_06 SEPA Testing Framework
Ref to Rulebook
&
Implementation
Guidelines
Ref to
Scenarios
or
Principles
CT Rb s 4.4
CT-05R
CTSc-03
CT Rb s 4.5.2
CTSc-01b
CT Rb s 4.5.4
CTSc-01
CT Rb s 4.5.4
CT Rb s 5.8
bullet 9
CTSc-01
CT Rb s 4.5.4
CT Rb s 5.8
bullet 9
CTSc-01d
CT Rb s 5.11
CTSc-01a
CT IG s 1.3
CTSc-01e
Page 31
CTAc-27
CTAc-28
B2C 10
B2B 9
ID
C2B 8
Acceptance Criteria for SEPA Credit Transfer
x
x
x
x
Test Acceptance Criteria
The instructed bank receiving a message containing
AOS-related message elements, but which is not a
member of the AOS community, may ignore the
information, that is, not use it for processing, nor
forward it to the next party in the chain. The instructed
bank, however, may reject the message for this
reason.
Participants have 2 options:
They may ignore and process only the ‘core SEPA
dataset, i.e. neither forward nor process the AOS set’
or they may reject messages with non-compliant (from
their processing position) information
Also refer to CTAc-07 and CTAc-26
Participants must be able to support the Latin
character set as described in the Implementation
Guidelines.
They may support character sets beyond it.
The IG states that there must be an agreement
between Participants before using additional character
sets.
Ref to Rulebook
&
Implementation
Guidelines
Ref to
Scenarios
or
Principles
CT IG s 1.3
CTSc-01f
CTSc-02b
CTSc-03a
CT IG s 1.5
CTSc-01g
CTSc-01h
(or any
other
Scenario)
Legend:
ID: CTAc-01 = Credit Transfer Acceptance criterion # 01
Ref to Rulebook and Implementation Guideline:
CT Rb s 4.3 = CT Rulebook section 4.3
CT IG s 1.3 = CT Implementation Guideline section 1.3
Category:
C2B: This acceptance criterion applies to the Customer-to-Bank communication
Bank-to-Bank: idem for Bank-to-Bank (incl. Bank-CSM-Bank)
B2C: idem for Bank-to-Customer
The category helps a Participant to select what acceptance criteria to test for. E.g. if the Participant only acts as Beneficiary
bank than only select acceptance criteria from columns Bank-to-Bank and B2C.
TABLE 1: SCT ACCEPTANCE CRITERIA
EPC228_06 SEPA Testing Framework
Page 32
5.2 SCT Testing Principles
The Testing Principles define the testing of Acceptance Criteria that can not be tested in a Test
Scenario.
1.
CTTp-01 - Payments are made for the full original amount
The basic idea of the Rulebook is that the amount the Originator specifies is paid to the Beneficiary
without deduction of any charges.
Because it is very difficult to design test cases to prove that something does not happen, it is
recommended that Participants should test for this principle statically, e.g. by reviewing
specifications or program-code, instead of dynamically.
This Testing Principle tests Acceptance Criterion CTAc-01.
2.
CTTp-02 - The Originator and the Beneficiary are responsible for their own charges
Since the full original amount must be paid, if a Bank agrees with a customer any charge then these
charges must be paid separately. Participants should test for this principle statically, e.g. by
reviewing specifications or program-code, instead of dynamically, since this principle relates to
business procedures rather than the functionality of a system/application.
This Testing Principle tests Acceptance Criterion CTAc-02.
3. CTTp-03 - Full reachability of all Beneficiary payment accounts held at the adhering SEPA
Participant
A Participant can only test for full reachability of the payment accounts of its own customers; it
would be practically unachievable to test full reachability of accounts of other Participants. The
assumption is that if all Participants achieve full reachability of their own accounts and also they test
some cases together with other Participants that will imply that all payment accounts in SEPA will be
reachable. The reachability between Participants can be tested by any of the Test Scenarios that
involve two or more Participants. There is no specific Test Scenario for this Acceptance Criterion.
The test between Participants can be carried out whilst testing on Self Assessment Levels SAL II and
SAL IV as recommended in Chapter 4 of the STF.
This Testing Principle tests Acceptance Criterion CTAc-03.
4. CTTp-04 - The data elements for Credit Transfer Instruction are as defined in datasets
DS01 - DS04
A basic generic Acceptance Criterion is that the data elements are as defined in the Rulebook. This
applies to all tests.
This Testing Principle tests Acceptance Criterion CTAc-10.
5. CTTp-05 – A community AOS may not disturb the operation of, or compromise in any
way, the SEPA Scheme for Participants who do not take part in the AOS
When a Community decides to create an AOS it must be done in compliance with the Implementation
Guidelines. The SEPA Participants that do not participate in the AOS arrangements should still be
able to use the SEPA Credit Transfer ignoring the AOS elements. Testing for this may typically
involve reviewing for verification purposes (also called static testing) of specifications.
Testing the AOS functionality is out of scope for the STF. However guidelines are provided CTAc-26
and CTAc-27.
This Testing Principle tests the Acceptance Criterion CTAc-07.
EPC228_06 SEPA Testing Framework
Page 33
5.3
SCT Test Scenarios
All SCT Test Scenarios are Mandatory for assessing SEPA Scheme compliance; some sub-scenarios
are optional as not all Participants will be subject to specified situations.
In Table 2 each Test Scenario has a reference to relevant Acceptance Criteria.
ID
Mandatory /
Optional
Test Scenarios for SEPA Credit Transfer
Test Scenario Name
Successful Credit
Transfer
CTSc-01
M
CTSc-01a
Successful Credit
Transfer with nonM
banking business days
(i.e. bank holidays)
CTSc-01b
CTSc-01c
CTSc-01d
CTSc-01e
CTSc-01f
O
O
Optional fields are
overridden due to legal
/ regulatory
requirements
Where there is no
explicit agreement
regarding the deduction
of charges the full
amount of the payment
is credited and charges
are separately made
clear to the Beneficiary.
O
Deduct a fee from the
Original Amount when
there’s an agreement
between the
Beneficiary Bank and
the Beneficiary
O
Ensure AOS message
elements are only sent
to AOS community
members
O
Ignore AOS message
elements when not an
AOS community
member
EPC228_06 SEPA Testing Framework
Ref to Rulebook
&
Implementation
Guidelines
Ref to
Acceptance
Criteria
Show that a normal Credit
Transfer transaction is processed
as defined
CT Rb s 4.3
CTAc-04
CTAc-05
CTAc-07
CTAc-08
CTAc-09
CTAc-12
CTAc-13
CTAc-22
Show that a Credit Transfer
transaction is processed as
defined when there are various
non-banking business days on
both sides
CT Rb s 4.3
CTAc-06
CTAc-25
Show that when the optional
fields are overridden due to
legal/regulatory requirements the
processing is still correct
CT Rb s 4.3
CTAc-21
Show that if no agreement on
deduction of charges exists the
full original amount is credited
and any applicable charges are
properly generated, and to show
that no charge is generated when
no agreement exists at all.
CT Rb s 4.3
CT Rb s 4.5.4
CT Rb s 5.8
bullet 9
CTAc-01
CTAc-23
CT Rb s 4.3
CT Rb s 4.5.4
CT Rb s 5.8
bullet 9
CTAc-24
CT IG s 1.3
CTAc-26
CT IG s 1.3
CTAc-27
Objective of the Scenario
Show that when there is an
agreement between the
Beneficiary Bank and the
Beneficiary the correct fee is
deducted from the original
amount and the remaining
amount is credited to the
Beneficiary’s account.
Show that if a Participant uses
AOS message elements these
are only sent to community
members and not to others.
Show that if a Participant receives
a message containing AOS
message elements for a
community they are not part of,
they are ignored, i.e. not use it for
processing nor forward it to the
next party in the chain.
Page 34
ID
CTSc-01g
CTSc-01h
CTSc-02
CTSc-02a
CTSc-02b
CTSc-03
CTSc-03a
Mandatory /
Optional
Test Scenarios for SEPA Credit Transfer
Test Scenario Name
Support the Latin
Character set as
M defined in the
Implementation
Guidelines
O
M
O
O
Only use other
character sets where
an agreement exists
Rejected Credit
Transfer
Rejected Credit
Transfer but Originator
Bank is willing to repair
and resend
For a Rejected Credit
Transfer Reject
messages when not an
AOS community
member
Ref to Rulebook
&
Implementation
Guidelines
Ref to
Acceptance
Criteria
Show that a Participant uses the
Latin character set specified in
the Implementation Guidelines
CT IG s 1.5
CTAc-28
Show that a Participant only uses
other character sets when there is
an agreement with the other
involved parties.
CT IG s 1.5
CTAc-28
Show that a Rejected Credit
Transfer transaction is processed
as defined.
CT Rb s 4.3
CTAc-08
CTAc-09
CTAc-11
CTAc-14
CTAc-15
CTAc-16
Show that a Rejected Credit
Transfer transaction which the
Originator Bank is able and willing
to repair is processed as defined.
CT Rb s 4.4
CT-04R
CTAc-17
Show that if a Participant receives
a message containing AOS
elements for a community they
are not part of, it may be rejected.
CT IG s 1.3
CTAc-27
CT Rb s 4.3
CTAc-08
CTAc-09
CTAc-18
CTAc-19
CTAc-20
CT IG s 1.3
CTAc-27
Objective of the Scenario
M
Returned Credit
Transfer
Show that a Returned Credit
Transfer transaction is processed
as defined.
O
For a Returned Credit
Transfer Reject
messages when not an
AOS community
member
Show that if a Participant receives
a message containing AOS
elements for a community they
are not part of, it may be rejected.
Legend:
ID:
CTSc-01 = Credit Transfer test Scenario number 01
CTSc-01a = Credit Transfer test Sub scenario a under Scenario number 01
Ref to Rulebook and Implementation Guideline:
CT Rb s 4.3 = CT Rulebook section 4.3
CT IG s 1.3 = CT Implementation Guideline section 1.3
TABLE 2: SCT TEST SCENARIOS
EPC228_06 SEPA Testing Framework
Page 35
5.3.1 CTSc-01 Successful Credit Transfer
The Test Scenario is used to demonstrate that a normal credit transfer will be processed as defined in
the Rulebook.
In this Test Scenario various acceptance criteria will be tested. Since this test scenario has the normal
flow many different test cases will have to be derived for it. The creation of the test cases is the
Participants responsibility and is not covered by the SEPA Testing Framework.
An example of a test case for this scenario would be to test for the full remittance information being
carried (CTAc-09). Also pay special attention to testing for the charges that have to be made
separately (see CTAc-23) if any charges are applicable and there is no agreement to deduct the
charges from the original amount.
Also test cases should be created based on legislation or regulation beyond the rulebook for example
for a boundary of € 50000,00 that is used in regulations for balance of payments reporting. Or test
cases should be created for testing the differences in handling transactions for accounts of residents
and non-residents.
Test Scenario 01 also covers eight sub-scenarios for specific exceptional situations as presented
below:
1. CTSc-01a - Successful Credit Transfer with non Banking Business Days (e.g. bank
holidays) involved
This is to show that a Credit Transfer transaction is processed within the proper timeframe as defined
in the Rulebook when non-banking business days are present within the execution cycle.
Example: A transaction from the Netherlands to France where the Acceptance Day is Friday 27
April 2007. For the calculation of the latest possible date on which the funds must be made available
to the Beneficiary 28 and 29 April are calculated as weekend-days. As 30 April 2007 is a national
holiday in the Netherlands and 1 May 2007 is a national holiday in France these dates should be
calculated as non Banking Business Days. Each Participant should check how these dates are treated
in their specific situations. Note that this example is only for explaining this particular sub-scenario;
it does not in any way add extra rules to the Rulebook. Also note that Netherlands banks use the
TARGET calendar).
2.
CTSc-01b - Optional fields are overridden due to legal / regulatory requirements
This sub-scenario shows that when the optional fields are overridden due to legal/regulatory
requirements the processing is still correct.
This scenario is only applicable to Participants that have applicable legal and/or regulatory
requirements.
According to the Rulebook there may be situations where optional fields are overridden. As the legal
and regulatory requirements may vary no specific example can be given. However, additional test
cases are needed to check whether the correct fields are overridden and no mandatory fields are
affected.
3. CTSc-01c - Where there is no explicit agreement regarding the deduction of charges the full
amount of payment is credited and charges are separately made clear to the Beneficiary.
This sub-scenario is to demonstrate that, if no agreement on deduction of charges exists between the
Beneficiary and the Beneficiary Bank, the full original amount is credited and any applicable charges
are properly generated. This Test Scenario is also used to demonstrate that no charge is generated in
the case where there is no charging agreement at all.
This scenario is optional as Participants may decide not to charge Beneficiaries.
The Rulebook states the general principle that payments are made for the full Original Amount (see
CTAc-01). Therefore even when a charge was agreed between the Beneficiary and the Beneficiary
Bank, the original amount should never be changed; With the only exception as covered by subscenario CTSc-01d.
EPC228_06 SEPA Testing Framework
Page 36
4. CTSc-01d - Deduct a fee from the Original Amount when there’s an agreement between the
Beneficiary Bank and the Beneficiary
This sub-scenario is to demonstrate that when an agreement exists between the Beneficiary Bank and
the Beneficiary the correct fee is deducted from the original amount and the remaining amount is
credited to the Beneficiary’s account
Chapter 5.8 (bullet 9) of the SCT Rulebook defines the obligation to carry the full original amount
from the Originator to the Beneficiary, but it also holds one exception when a fee may be deducted
from the original amount.
Note that the fee is deducted after the Interbank Settlement and after all checks were carried out to
establish that the Return procedure does not apply to this transaction.
This sub-scenario is optional as a Participant may choose not to have such an agreement with its
Beneficiaries.
5.
CTSc-01e - Ensure AOS message elements are only sent to AOS community members
This sub-scenario is to demonstrate that if a Participant uses AOS message elements these are only
sent to Community members and not to Participants outside the Community.
The Implementation Guidelines complement the Rulebook as stated in Acceptance Criterion CTAc07. This means that AOS message elements can only be used between members of the same
community. Participants therefore will most likely need to access a directory that gives information
on whether their counterparty is member of one or more of their communities. When multiple AOS
communities are involved this may result in a wide variety of test cases for various situations.
This scenario is optional as a Participant may not be a member of any AOS community.
6.
CTSc-01f - Ignore AOS message elements when not an AOS community member
This sub-scenario is to demonstrate that if a Participant receives a message containing AOS message
elements for a Community they are not part of, these data elements are ignored, that is not used for
processing, nor forwarded to the next party in the chain.
This only applies to Participants that have decided (in their business process) to ignore AOS message
elements, that is not use them for processing, nor forward them to the next party in the chain.
Therefore depending on the situation only test cases for ignoring message elements need to be
produced. Participants may also need to produce Test Cases for rejecting the messages per in subscenario CTSc-02b.
This sub-scenario is optional as a Participant may decide never to ignore message elements, but
always reject the message.
This sub-scenario is closely related to sub-scenarios CTSc-02b and CTSc-03a.
7.
CTSc-01g - Support Latin character set
This sub-scenario is to demonstrate that a Participant uses the Latin Character set that is specified in
the Implementation Guidelines.
Participants must use the Latin character set of the Implementation Guidelines for message elements
containing free text such as remittance information, and name and address. Other characters may
not be used except when there is a specific agreement. This agreement is NOT considered to be an
AOS.
This sub-scenario is mandatory.
8.
CTSc-01h - Only use other character sets when an agreement exists
This sub-scenario is to demonstrate that a Participant only uses other character sets when there is an
agreement with the other parties involved.
EPC228_06 SEPA Testing Framework
Page 37
In addition to the Latin character set Participants may have bilateral or multilateral agreements on
using additional character sets. For example, Participants in France may decide to also support
characters such as ç and ê. But a Participant must not use these additional character sets when
sending a message to a Participant with whom no such agreement exists.
This sub-scenario is optional since it only relates to Participants that will use additional character
sets.
5.3.2 CTSc-02 Rejected Credit Transfer
This test Scenario is used to test that a rejected Credit Transfer transaction is processed as defined in
the Rulebook. When a CSM detects that a Credit Transfer transaction is non-compliant with the
Rulebook it will reject the transaction. CSM may reject the transaction for a wide range of reasons
for each of which test cases should be made. A CSM should test for all possible situations. A
Participant that tests in the Originator Bank role may choose not to make test cases for all possible
situations but only for those situations that have different processing requirements.
Apart from the testing of the normal operation of a Rejected Credit Transfer this Test Scenario also
covers two sub-scenarios for exceptional situations as presented below:
1. CTSc-02a - Rejected Credit Transfer that Originator Bank is willing to repair and resend
This test scenario shows that a rejected Credit Transfer transaction which the Originator Bank is able
and willing to repair is processed as defined.
This sub-scenario is optional since not all Participants will choose to repair Rejects.
Note that after the repair the transaction will be processed according to Test Scenario CTSc-01, so in
fact this test involves two consecutive Test Scenarios. The Beneficiary Bank will not be able to see the
difference between a normal transaction and a transaction that has been rejected, repaired and
resent.
Option: instead of repairing the rejected transaction the Originator Bank may generate a new
transaction.
The reject for single transactions will differ from the reject for bulk messages, therefore specific test
cases to test both situations should be made for bulk messages where applicable.
2. CTSc-02b - Reject messages when not an AOS community member
This sub-scenario is to demonstrate that if a CSM receives a message, which contains AOS message
elements for a Community they are not part of, the message is rejected.
This only applies to CSMs that has a business process to reject AOS messages. Therefore depending
on the situation only test cases for rejecting messages need to be produced. Otherwise Participants
need to produce Test Cases for ignoring the AOS message elements as per sub-scenario CTSc-01f.
This sub-scenario is optional as a Participant may decide never to reject messages but to ignore and
remove message elements instead.
This sub-scenario is closely related to sub-scenarios CTSc-01f and CTSc-03a.
EPC228_06 SEPA Testing Framework
Page 38
5.3.3 CTSc-03 Returned Credit Transfer
This Test Scenario is used to test that a Returned Credit Transfer transaction is processed as defined
in the Rulebook.
When a Beneficiary Bank detects that a Credit Transfer transaction is non-compliant with the
Rulebook it will return the transaction. It may return the transition for a number of reasons covered
in the Rulebook; for each individual reason a Test Case should be produced. A Participant, in the
Beneficiary Bank role, should produce Test Cases for all possible situations, since all variations of
reasons for return shout be tested. Participants that test in the Originator Bank’s role may choose to
produce Test Cases only for the situations that have different processing requirements, since they
have to test whether the various processing flows of returns is correct but they may not have to be
aware of all possible different reasons that a Beneficiary Bank might have to return.
Option (not required by the Rulebook): a Beneficiary Bank may choose to check whether the returned
transaction matches the original Credit Transfer to detect possible mistakes or fraud.
Apart from the testing of the normal operation of a Returned Credit Transfer this Test Scenario also
covers one sub-scenario for an exceptional situation as presented below:
1. CTSc-03a - Reject messages when not an AOS community member
This sub-scenario is to demonstrate that if a Participant receives a message containing AOS message
elements for a community they are not part of, it is rejected.
This only applies to Participants that have a business process to reject AOS messages. Therefore
depending on the situation only Test Cases for rejecting messages need to be produced. Otherwise
Participants need to produce Test Cases for ignoring the AOS message elements, as per sub-scenario
CTSc-01f.
This sub-scenario is optional as a Participant may decide never to reject messages, but instead ignore
and remove message elements.
This sub-scenario is closely related to sub-scenarios CTSc-01f and CTSc-02b.
EPC228_06 SEPA Testing Framework
Page 39
6
6.1
SEPA DIRECT DEBIT
SDD Acceptance Criteria
Table 3 contains the SEPA Direct Debit Acceptance Criteria to be used for evaluating a Participant’s
SDD Scheme operational readiness and for producing of the Test Cases.
The table contains two columns ‘Core Scheme’ and ‘Business-to-Business’ to indicate Acceptance
Criteria applicable for the SDD Core and SDD B2B Schemes respectively.
C2B
B2B
B2C
DDAc-01
x
x
x
x
x
DDAc-02
x
x
DDAc-03
x
x
x
x
x
DDAc-04
x
x
x
x
x
DDAc-05
x
x
x
x
x
DDAc-06
x
x
x
x
ID
Core
Scheme
Business –
to- business
Acceptance Criteria for SEPA Direct Debit
x
EPC228_06 SEPA Testing Framework
Test Acceptance Criteria
Full reachability of all Debtor payment
accounts held at the adhering SEPA
Participant
AOS may be offered but the Participant
must ensure that it does not compromise in
any way the Scheme and roles,
responsibilities and liabilities of other
participants
Participants will have to create specific test
cases for this
The Scheme operates in euro.
All transactions will be in euro at the interbank level in all process stages, including
all exception handling, covering Rejects,
Returns,
Reversals,
Refunds
and
revocations.
The accounts of the Debtor and of the
Creditor may be in euro or any other
currency.
Any currency conversion is
executed in the Debtor Bank or Creditor
Bank.
Any such currency conversion,
including the related risks for banks, is not
governed by the Scheme.
All Returns, Reversals, Refunds and
Revocations must be based on the exact
Euro amount of the originating Direct Debit.
Dataset DS-04 (…) must be forwarded by
all actors up to the Debtor Bank.
The data elements for the Direct Debit
Collection are as defined in datasets DS-03,
DS-04, DS-05, DS-06 and DS-07 and the
Implementation Guidelines
The message elements indicated as yellow,
white and red in the Implementation
Guidelines must be used or not used as
specified
The Debtor has the right to request the
Debtor Bank to completely prohibit his bank
account from being debited for a Direct
Debit Collection
Ref to
Rulebook &
Implementation
Guidelines
Ref to
Scenarios
or
Principles
DD Rb s 2.7
DDTp-01
DD Rb s 2.4
DDSc-01
DD Rb s 2.5
DDSc-01
DDSc-02
DDSc-03
DD Rb s 2.5
DD Rb s
4.7.5
DDTp-02
DD Rb s 4.7
DD IG s 1.1
DDTp-03
DD Rb s 4.2
DDSc-04
Page 40
DDAc-07
x
x
x
DDAc-08
x
x
x
DDAc-09
DDAc-10
x
x
DDAc10a
DDAc-11
x
DDAc-13
x
x
x
x
x
x
x
x
DDAc12a
x
x
x
DDAc11a
DDAc-12
x
x
x
EPC228_06 SEPA Testing Framework
B2C
B2B
C2B
Business –
to- business
ID
Core
Scheme
Acceptance Criteria for SEPA Direct Debit
Test Acceptance Criteria
An Inter-Bank Business Day is a day on
which banks generally are open for InterBank business. The TARGET Days
Calendar is used.
A Customer Banking Business Day is a day
on which banks in the relevant jurisdiction
are generally open for business with
customers.
At Inter-Bank level a given Due Date may
never be changed
Participants are recommended to test this
statically (by reviewing specifications or
program-code) instead of dynamically
x
If the settlement date is a non-Banking
Business Day (e.g. bank holiday) in the
Debtor Bank's country then the Debit Date
will be the next Customer Banking Business
Day.
The Debtor Bank must receive a first or
one-off Collection from the Creditor Bank at
the latest 5 (five) Inter-Bank Business Days
before Due Date and not earlier than 14
calendar days before Due Date
The Debtor Bank must receive a first or
one-off Collection from the Creditor Bank at
the latest 1 Inter-Bank Business Days
before Due Date and not earlier than 14
calendar days before Due Date
The Debtor Bank must receive a
subsequent Collection from the Creditor
Bank at the latest two Inter-Bank Business
Days before Due Date and not earlier than
14 calendar days before Due Date
The Debtor Bank must receive a
subsequent Collection from the Creditor
Bank at the latest 1 Inter-Bank Business
Days before Due Date and not earlier than
14 calendar days before Due Date
The latest date for the settlement of Returns
is 5 (five) Inter-Bank Business Days after
the Settlement Date of the Collection
presented to the Debtor Bank
The latest date for the settlement of Returns
is 2 Inter-Bank Business Days after the
Settlement Date of the Collection presented
to the Debtor Bank
The latest Settlement Date of a Refund
request for an authorised transaction is 2
(two) Inter-Bank Business Days after 8
weeks after the debit date.
Ref to
Rulebook &
Implementation
Guidelines
Ref to
Scenarios
or
Principles
DDSc01a
DD Rb s 4.3
DD Rb
4.3.2
s
DD Rb
4.3.2
s
DD Rb
4.3.4
s
DDSc01b
DD Rb
4.3.4
s
DDSc01b
DD Rb
4.3.4
s
DDSc01c
DD Rb
4.3.4
s
DDSc01c
DD Rb
4.3.4
RB4.6
PT-04.09
s
DD Rb
4.3.4
s
DD Rb
4.3.4
s
DDTp-02
DDSc-01
DDSc-01
DDSc-06
DDSc-07
Page 41
DDAc-14
x
DDAc-15
x
DDAc-16
x
x
x
DDAc-18
x
DDAc-19
B2C
x
x
x
x
x
x
x
x
x
x
x
x
DDAc-20
x
x
x
x
DDAc-21
x
x
x
x
x
DDAc-22
x
x
x
x
DDAc-23
EPC228_06 SEPA Testing Framework
Test Acceptance Criteria
The latest Settlement Date of a Refund
request for an unauthorised transaction is 2
(two) Inter-Bank Business Days after 13
months after the debit date
Note: since the period of handling the
refund request may be up to 30 days in
practise the ultimate deadline for settlement
could be 13 months + 30 days + 2 days but
this is not explicitly stated in the rulebook
Reversals may only be processed after
settlement and within two Inter-Bank
Business Days following the Due Date
requested in the original Direct Debit
Collection
The Debtor Bank has the right to receive a
refund compensation from the Creditor
Bank (calculated according to the EONIA
rates published by the ECB)
Participants should test both for the
possibility of a refund compensation and for
the correct calculation of it
x
x
DDAc-17
B2B
C2B
Business –
to- business
ID
Core
Scheme
Acceptance Criteria for SEPA Direct Debit
The Creditor must issue a Direct Debit
respecting the time-cycle of the first Direct
Debit when the cause of the amendment is
that the Debtor decides to use another
account in another bank.
The Debtor may instruct the Debtor Bank to
refuse any future Collection (based on prenotification)
If the Debtor Bank agrees to handle the
refusal claim prior to inter-Bank settlement
the refusal results in a reject
If the Debtor Bank handles the refusal claim
on the day of inter-Bank settlement or later
the refusal results in a refund claim (and
handled as a return message)
The mandate-related information for new or
amended mandates must be sent as part of
all the Collections
In case of late presentment by the Creditor
the Creditor Bank must replace in
agreement with the Creditor the outdated
Due Date by a new Due Date
Ref to
Rulebook &
Implementation
Guidelines
DD Rb
4.3.4
PT-04.24
s
DD Rb
4.3.4
s
DD Rb s 4.4
DD Rb s
4.6.4
PT04.16
DD Rb s
4.6.4
PT04.24
DD Rb s
4.6.2
PT02.02
DD IG s 2.1.3
index 1.24
DD IG s 2.1.4
index 2.32
DD Rb s
4.6.4
PT04.02 bis
DD Rb s
4.6.4
PT04.02 bis
Ref to
Scenarios
or
Principles
DDSc-08
DDSc-10
DDSc-11
DDSc-06
DDSc-07
DDSc-08
DDSc-09
DDSc01b
DDSc04a
DDSc-04
DD Rb s
4.6.4
PT04.02 bis
DDSc-06
DD Rb s
4.6.4
PT04.03
DDSc-01
DD Rb s
4.6.4
PT04.05
DDSc01e
deleted
Page 42
B2C
B2B
C2B
Business –
to- business
ID
Core
Scheme
Acceptance Criteria for SEPA Direct Debit
Test Acceptance Criteria
Ref to
Rulebook &
Implementation
Guidelines
Ref to
Scenarios
or
Principles
DD Rb s
4.6.4
PT04.07
DDSc-01
DD Rb s
4.6.4
PT04.08
DDSc-03
DD Rb s
4.6.4
PT04.09
DDSc-01
DD Rb s
4.6.4
PT04.10
DD Rb s 4.8
AT-R3
DDSc-05
DD Rb s
4.6.4
PT04.11
DD Rb s
4.7.1 DS 05
DD Rb s 4.4
DDSc-05
DDAc-24
x
x
x
Collection Data is sent from CSM to the
Debtor Bank. The settlement resulting from
the Direct Debit Collections is executed on
day D by crediting the Creditor Bank and
debiting the Debtor Bank.
DDAc-25
x
x
x
The Debtor Bank will reject instructions for
reasons as described in attribute AT-R3
DDAc-26
DDAc-27
DDAc-28
x
x
x
x
x
x
DDAc-29
x
x
DDAc-30
x
x
DDAc-31
x
DDAc-32
x
x
x
x
The Debtor Bank cannot debit the account,
the instruction must be returned to the CSM
with the reasons for the Return
x
x
x
x
x
x
EPC228_06 SEPA Testing Framework
The Debtor Bank debits the account of the
Debtor for the amount of the instruction on
the Due Date
x
The CSM sends the (….) returned
Collection back to the Creditor Bank. The
Settlement takes place by debiting the
Creditor Bank and crediting the Debtor
Bank
By the SDD Rulebook definition: Returns
are Collections that are diverted from
normal
execution
after
inter-bank
Settlement and are initiated by the Debtor
Bank.
This DDAc only tests for the processing of
the Return and consecutive settlement, if
applicable
The CSM sends the rejected (….) Collection
back to the Creditor Bank.
By the SDD Rulebook definition: Rejects
are Collections that are diverted from
normal execution, prior to inter-bank
Settlement …..
This DDAc only tests for the processing of
the Reject (settlement is not applicable)
The Creditor Bank must debit the rejected
and returned Collections to the Creditor only
if the Creditor's account has already been
credited.
The Creditor Bank is not allowed to debit
the Debtor Bank for the unpaid
Reject/Return.
Participants are recommended to test this
statically
(by
reviewing
procedures,
manuals, system settings) instead of
dynamically
The Debtor may request a refund for an
authorised direct debit within 8 weeks after
the debit date.
DD Rb s
4.6.4
PT04.11
DD Rb s
4.7.1 DS 05
DD Rb s 4.4
DDSc-03
DDSc-04
DD Rb s
4.6.4
PT04.12
DDSc03a
DD Rb s
4.6.4
PT04.12
PT-04.26
DDSc03a
DD Rb s
4.6.4
PT04.15
DDSc-06
DDSc-07
Page 43
DDAc-33
DDAc-34
DDAc-35
x
x
x
B2C
B2B
C2B
Business –
to- business
ID
Core
Scheme
Acceptance Criteria for SEPA Direct Debit
x
x
The Debtor may request a refund for an
unauthorised Direct Debit within 13 months
after the debit date.
Within the initial 8 weeks there is no need to
treat
authorised
and
unauthorised
differently.
The settlement resulting from the refund is
executed before or on the debit date + 8
weeks + 2 Inter-Bank Business Days, by
debiting the Creditor Bank and crediting the
Debtor Bank.
x
x
Test Acceptance Criteria
x
The Creditor Bank must debit the account of
the Creditor for the amount of the
instructions received for refund.
The Debtor Bank must forward the refund
claim to the Creditor Bank (in the form of a
return message)
.
The Creditor Bank must forward the refund
claim to the Creditor(in the form of a return
message)
Ref to
Rulebook &
Implementation
Guidelines
Ref to
Scenarios
or
Principles
DD Rb s
4.6.4
PT04.20
DDSc-06
DDSc-07
DDSc-08
DDSc-09
DDSc-10
DD Rb s
4.6.4
PT04.17
DDSc-06
DDSc-07
DD Rb s
4.6.4
PT04.18
DD Rb s
4.6.4
PT04.26
DDSc-06
DDSc-07
DDSc-08
DDSc-09
DD Rb s
4.6.4
PT04.21
DDSc-08
DDSc-10
DD Rb s
4.6.4
PT04.22
DDSc-08
DDSc-10
DDAc-36
x
DDAc-37
x
x
x
DDAc-38
(only for
Core)
x
x
x
x
The Creditor must provide a copy of the
mandate through the Creditor Bank to the
Debtor Bank.
DD Rb s
4.6.4
PT04.23
DDSc-08
DDSc-10
x
x
x
The Creditor must provide a copy of the
mandate through the Creditor Bank to the
Debtor Bank.
DD Rb s
4.6.6
PT06.03
DDTp-04
DD Rb s
4.6.4
PT04.24
DDSc-08
DDSc-09
DD Rb s
4.6.4
PT04.25
DDSc-08
DDSc-09
DDAc-38a
(only for
B2B)
DDAc-39
x
x
x
x
x
If the copy of the signed Mandate is not
received within 30 calendar days the Debtor
Bank sends a refund message (in the form
of a return message) and credits the Debtor
account
The CSM sends the Refund instruction to
the Creditor Bank and settles by crediting
the Debtor Bank and debiting the Creditor
Bank
DDAc-40
x
DDAc-41
x
x
x
The Creditor Bank forwards
transactions to the CSM
DDAc-42
x
x
x
The CSM settles the Reversal by crediting
the Debtor Bank and debiting the Creditor
Bank
DDAc-43
x
x
x
x
EPC228_06 SEPA Testing Framework
x
Reversal
The Debtor Bank credits the Debtor account
in case of a Reversal
DD Rb s
4.6.4
PT05.02
DD Rb s
4.6.4
PT05.03
DD Rb s
4.6.4
PT05.04
DDSc-11
DDSc-11
DDSc-11
Page 44
DDAc-44
x
x
x
x
x
DDAc-46
x
x
x
DDAc-48
x
Test Acceptance Criteria
It is the responsibility of the instructing bank
to ensure that AOS message elements are
only included in messages sent to AOS
community members
The instructed bank receiving a message
containing AOS-related message elements,
but which is not a member of the AOS
community, may ignore the information, that
is, not use it for processing, nor forward it to
the next party in the chain. The instructed
bank, however, may reject the message for
this reason.
Participants have 2 options:
They may ignore and process the ‘core
SEPA’ dataset only, i.e. neither forward nor
process the AOS set, or they may reject
messages with non-compliant (from their
processing position) information
A community AOS may not disturb the
operation of, or compromise in any way, the
SEPA Scheme for Participants who do not
take part in the AOS
Also refer to DDAc-44 and DDAc-45
x
DDAc-45
DDAc-47
B2C
B2B
C2B
Business –
to- business
ID
Core
Scheme
Acceptance Criteria for SEPA Direct Debit
x
x
x
x
Participants must be able to support the
Latin character set as described in the
Implementation Guidelines.
They may support character sets beyond it.
The Implementation Guidelines state that
there must be an agreement between
Participants
before
using
additional
character sets.
x
x
x
x
The Debtor Bank should validate the data of
the Mandate as agreed with the Debtor for
each collection
Ref to
Rulebook &
Implementation
Guidelines
Ref to
Scenarios
or
Principles
DD IG s 1.3
DD IG s 1.3
DDSc02a
DDSc03b
DD IG s 1.3
DD Rb s
DDTp-04
DD IG s 1.5
DDSc01h
(or any
other
Scenario)
Rb s 4.1
RB4.6
PT-04.09
DDSc-12
Legend:
ID:
DDAc-01 = Direct Debit Acceptance criterion number 01
Ref to Rulebook and Implementation Guideline:
DD Rb s 4.1 = DD Rulebook section 4.1
DD IG s 1.3 = DD Implementation Guideline section 1.3
Category:
C2B: This acceptance criterion applies to the Customer-to-Bank communication
Bank-to-Bank: idem for Bank-to-Bank (incl. Bank-CSM-Bank)
B2C: idem for Bank-to-Customer
The category helps a Participant to select what acceptance criteria to test for. E.g. if the Participant only acts as Debtor bank
then only select acceptance criteria from columns Bank-to-Bank and B2C.
TABLE 3: SDD ACCEPTANCE CRITERIA
EPC228_06 SEPA Testing Framework
Page 45
6.2
SDD Testing Principles
The Testing Principles define the testing of Acceptance Criteria that can not be tested in a Test
Scenario.
1. DDTp-01 - Full reachability of all Debtor payment accounts held at the adhering SEPA
Participant
A Participant can only test for full reachability of the payment accounts of its own customers; it
would be practically unachievable to test full reachability of accounts of other Participants. The
assumption is that if all Participants achieve full reachability of their own accounts and also they test
some cases together with other Participants that will imply that all payment accounts in SEPA will be
reachable. The reachability between Participants can be tested by any of the Test Scenarios that
involve two or more Participants. There is no specific Test Scenario for this Acceptance Criterion.
The test between Participants can be carried out whilst testing on Self Assessment Levels SAL II and
SAL IV as recommended in Chapter 4 of the STF.
This Testing Principle tests Acceptance Criterion DDAc-01.
2. DDTp-02 - At inter-bank level a given Due Date may never be changed
Because checking something that does not happen is difficult, Participants should test this statically
instead of dynamically, i.e. by carrying out reviews of specifications and program code.
This Testing Principle tests Acceptance Criterion DDAc-08.
3. DDTp-03 - The data elements for the Direct Debit Collection are as defined in the datasets DS03
through DS07
A basic generic Acceptance Criterion is that the included data elements are as specified in the
Rulebook. This is a purpose for all tests.
This Testing Principle tests Acceptance Criterion DDAc-05.
4. DDTp-04 - The data elements for the request and the response for obtaining a copy of a Mandate
are as defined in the datasets DS-08 to DS-11.
A basic generic Acceptance Criterion is that the included data elements are as specified in the
Rulebook..
This Testing Principle tests Acceptance Criterion DDAc-38a.
EPC228_06 SEPA Testing Framework
Page 46
6.3
SDD Test Scenarios
Applicants applying to adhere to the Schemes should be able to demonstrate that the Test Scenarios
or equivalent tests have been carried out for achieving SEPA Scheme compliance. Some subscenarios are optional as they describe situations that may not be applicable to all Participants.
Each Test Scenario has a reference to relevant Acceptance Criteria.
ID
Mandatory/
Optional
Test Scenarios for SEPA Direct Debit
Test Scenario Name
Objective of the Scenario
Ref to Rulebook
&
Implementation
Guidelines
Ref to
Acceptance
Criteria
DDAc-02
DDAc-03
DDAc-12
(CORE)
DDAc-12a
(B2B)
DDAc-21
DDAc-24
DDAc-26
DDSc-01
M Successful Direct Debit
Show that a normal Direct Debit
transaction is processed as
defined.
Note: the Rulebook does not
specify the crediting of the
Creditors account, this process is
specific to the Creditor Bank.
DDSc-01a
Successful Direct Debit
with
non-Banking
M
Business Days (e.g.
bank holidays)
Show that a normal Direct Debit
transaction is processed as
defined when there are various
non-Banking Business Days on
both sides
DD Rb s 4.5.4:
PT-04
DDAc-07
Show that a first or one-off Direct
Debit collection is received by the
Debtor Bank at least 5 Inter-Bank
Business Days before Due Date
and no more than 14 Calendar
Days.
DD Rb s 4.3.4
DD Rb s 4.5.4:
PT-04
DDAc-10
DDAc-17
Show that a first or one-off Direct
Debit collection is received by the
Debtor Bank at least 1 Inter-Bank
Business Days before Due Date
and no more than 14 Calendar
Days.
DD Rb s 4.3.4
DD Rb s 4.5.4:
PT-04
DDAc-10a
DDAc-17
Show that a recurrent Direct Debit
collection is received by the
Debtor Bank at least 2 Inter-Bank
Business Days before Due Date
and no more than 14 Calendar
Days.
DD Rb s 4.5.4:
PT-04
Show that a recurrent Direct Debit
collection is received by the
Debtor Bank at least 1 Inter-Bank
Business Days before Due Date
and no more than 14 Calendar
Days.
DD Rb s 4.5.4:
PT-04
DDSc-01b
(only
applicable
to Core
Scheme)
M
DDSc-01b2b
(only
applicable M
to B2B
Scheme)
DDSc-01c
(only
applicable
to Core
Scheme)
M
DDSc-01c2B
(only
applicable M
to B2B
Scheme)
Successful Direct Debit
that is the first or a oneoff collection and is
received at least 5
Inter-Bank
Business
Days and no more than
14
Calendar
Days
before Due Date.
Successful Direct Debit
that is the first or a oneoff collection and is
received at least 1
Inter-Bank
Business
Days and no more than
14
Calendar
Days
before Due Date.
Successful Direct Debit
that is a recurrent
collection
and
is
received at least 2
Inter-Bank
Business
Days and no more than
14
Calendar
Days
before the Due Date.
Successful Direct Debit
that is a recurrent
collection
and
is
received at least 1
Inter-Bank
Business
Days and no more than
14
Calendar
Days
before the Due Date.
EPC228_06 SEPA Testing Framework
DD Rb s 4.5.4:
PT-04
DDAc-11
DDAc-11a
Page 47
ID
DDSc-01d
DDSc-01e
Mandatory/
Optional
Test Scenarios for SEPA Direct Debit
Test Scenario Name
Objective of the Scenario
Ref to Rulebook
&
Implementation
Guidelines
O
Successful Direct Debit
with changed Due Date
because
of
late
presentment
by
Creditor
Show that the Due Date is
correctly replaced in case of late
presentment by the Creditor
DD Rb s 4.6.4:
PT-04.05
DDAc-22
O
Successful Direct Debit
with changed value
date because of a non
Banking Business Day
Show
that
the
interbank
settlement date is correctly
replaced in case of a bank
holiday on the Due Date, only
when the Debtor Bank has
decided to do so.
DD Rb s 4.6.4:
PT-04.05
DDAc-09
DD IG s 1.5
DDAc-47
DD Rb s 4.6.4:
PT-04.06
DDAc-03
DDSc-01f
deleted
DDSc-01g
deleted
DDSc-01h
Support
the
Latin
Character set and only
M use other character
sets
where
an
agreement exists
DDSc-02
M
Collection Rejected by
CSM
DDSc-03
M
Collection Rejected by
Debtor Bank
O
No debiting of the
Creditor's account by
the Creditor Bank in
case
the
Creditors
account had not yet
been credited
DDSc-03a
Show that a Participant uses the
Latin character set and only uses
other character sets when there is
an agreement with other parties
involved.
Show that a Rejected collection of
a Direct Debit transaction by the
CSM is processed as defined.
Test cases should be made for
each possible reason for Reject
Show that a Rejected collection of
a Direct Debit transaction by the
Debtor Bank is processed as
defined.
Show that a Rejected or Returned
collection of a Direct Debit
transaction is only debited by the
Creditor Bank in case the
Creditor's account has already
been credited.
Ref to
Acceptance
Criteria
DD Rb s 4.6.4:
PT-04.08
DDAc-03
DDAc-25
DDAc-29
DD Rb s 4.6.4:
PT-04.12
DDAc-30
DDAc-31
DD Rb s 4.6.4:
PT-04.02 bis
DDAc-06
DDAc-19
DDAc-29
DDSc-04
M
Collection Rejected due
to early refusal
Show that a Rejected collection
due to refusal by the Debtor
based on the pre-notification prior
to Inter-Bank settlement is
processed as defined
DDSc-04a
Collection Rejected due
to instruction of the
M Debtor to the Debtor
Bank to refuse any
future collection
Show that a Rejected collection
due to refusal by the Debtor for all
future Direct Debit collections is
processed as defined
DD Rb s 4.6.4:
PT-04.02 bis
DDAc-18
DDSc-05
Collection Returned by
M
Debtor Bank
Show that a Returned collection
of a Direct Debit transaction by
the Debtor Bank is processed as
defined.
DD Rb s 4.6.4:
PT-04.10
DDAc-27
DDAc-28
DDAc-29
EPC228_06 SEPA Testing Framework
Page 48
ID
DDSc-06
(only
applicable
to Core
Scheme)
DDSc-07
(only
applicable
to Core
Scheme)
Mandatory/
Optional
Test Scenarios for SEPA Direct Debit
Test Scenario Name
Refund for collection
within
eight
weeks
M
based
on
prenotification
Request for Refund of
M Authorised Direct Debit.
Refund sent
Objective of the Scenario
Show that a Refund for a
collection of a Direct Debit that is
requested based on the prenotification
after
Inter-Bank
settlement but within eight weeks
(no matter whether it was an
authorised
or
unauthorised
transaction) is processed as
defined.
Show that a Refund for a
collection of a Direct Debit that is
requested based on the actual
debiting of the Debtor's account
within eight weeks (no matter
whether it was an authorised or
unauthorised
transaction)
is
processed as defined.
Show that the Refund process
functions as meant in the
rulebook in the situation that no
valid mandate was presented by
the Creditor upon request.
Ref to Rulebook
&
Implementation
Guidelines
Ref to
Acceptance
Criteria
DD Rb s 4.6.4:
PT-04.15
DD Rb s 4.6.4:
PT-04.20
DDAc-13
DDAc-16
DDAc-20
DDAc-32
DDAc-33
DDAc-34
DDAc-35
DD Rb s 4.6.4:
PT-04.15
DD Rb s 4.6.4:
PT-04.20
DDAc-13
DDAc-16
DDAc-32
DDAc-33
DDAc-34
DDAc-35
DD Rb s 4.6.4:
PT-04.20
DDAc-14
DDAc-16
DDAc-33
DDAc-35
DDAc-36
DDAc-37
DDAc-38
DDAc-39
DDAc-40
DD Rb s 4.6.4:
PT-04.20
DDAc-16
DDAc-33
DDAc-35
DDAc-39
DDAc-40
DD Rb s 4.6.4:
PT-04.20
DDAc-14
DDAc-33
DDAc-36
DDAc-37
DDAc-38
DDSc-08
(only
applicable
to Core
Scheme)
Request for Refund of
Unauthorised
Direct
M Debit – Creditor Bank
confirms ‘No authorized
Mandate’. Refund sent.
DDSc-09
(only
applicable
to Core
Scheme)
Request for Refund of
Unauthorised
Direct
M Debit – No response
from Creditor Bank in
30 days. Refund sent
DDSc-10
(only
applicable
to Core
Scheme)
Request for Refund of
Unauthorised
Direct
Debit – Creditor Bank
M
confirms
‘Authorised
Mandate’. No Refund
sent.
DDSc-11
Reversal of a Direct
M
Debit transaction
Check that when a Reversal is
sent this will be handled
according to the Rulebook.
DD Rb s 4.5.5:
PT-05
DDAc-15
DDAc-41
DDAc-42
DDAc-43
M Check data of collection
Debtor Bank should check the
first and subsequent collections
against the stored manadate data
and the related verification
instructions, if any, received from
the Debtor
DD Rb s 4.1
RB4.6
PT-04.09
DDAc-48
DDSc-12
(only
applicable
to B2B
Scheme)
EPC228_06 SEPA Testing Framework
Show that the Refund process
functions as meant in the
rulebook in the situation that
response to the request for a
mandate was NOT received
within the 30 days period.
Show that the Refund is not
granted in the situation that upon
the request for Refund the
Creditor does present a valid
mandate.
Page 49
ID
Mandatory/
Optional
Test Scenarios for SEPA Direct Debit
Test Scenario Name
Objective of the Scenario
Ref to Rulebook
&
Implementation
Guidelines
Ref to
Acceptance
Criteria
Legend:
ID:
DDSc-01 = Direct Debit test Scenario number 01
DDSc-01a = Direct Debit test Sub scenario a under Scenario number 01
Ref to Rulebook and Implementation Guideline:
DD Rb s 4.5.4: PR-04 = DD Rulebook section 4.5.4 which describes Process 04
DD IG s 1.3 = DD Implementation Guideline section 1.3
TABLE 4: SDD TEST SCENARIOS
EPC228_06 SEPA Testing Framework
Page 50
7
7.1
ANNEX 1: GENERIC SEPA TEST PLAN
Purpose
A test plan is designed to set the scope, approach, resources, and schedule of the testing activities. To
identify the items being tested, the features to be tested, the testing tasks to be performed, the
personnel responsible for each task, and the risks associated with this plan.
This generic SEPA test plan is based on the IEEE829-1998 standard. Below for each part of this
standard specific remarks for creating a SEPA test plan have been added. For the actual content
please refer to the IEEE829 standard and relevant books on software testing.
The test plan structure presented in this annex is only to define the content a test plan should hold. It
does not imply the structure of a SEPA test plan nor does it imply that other content might not be
added.
7.2
Outline
The test plan shall have the following content:
a) Test plan identifier;
b) Introduction;
c) Test items;
d) Features to be tested;
e) Features not to be tested;
f) Approach;
g) Item pass/fail criteria;
h) Suspension criteria and resumption requirements;
i) Test deliverables;
j) Testing tasks;
k) Environmental needs;
l) Responsibilities;
m) Staffing and training needs;
n) Schedule;
o) Risks and contingencies;
p) Approvals.
If some or all of the content of a section is in another document, then a reference to that material may
be listed in place of the corresponding content. The referenced material must be attached to the test
plan or be made available to users of the plan.
Details on the content of each section are contained in the following sub-clauses.
Be aware that there may be two levels of test plans where the highest level is the Project Test Plan or
Master Test Plan that describes the testing for the SEPA programme within a Participant, or even a
Community, scope. The lower level are the Detailed Test Plans that specify the information for a
single test level, a single self-assessment level or a logical group of testing activities.
All test plans together should contain the information described in the sections below.
EPC228_06 SEPA Testing Framework
Page 51
7.2.1 Test plan identifier
Specify the unique identifier assigned to this test plan. No SEPA specific content.
7.2.2 Introduction
Summarize the software items and software features to be tested. The need for each item and its
history may be included.
References to the following documents, when they exist, are required in the highest level test plan:
a) Project authorization;
b) Project plan;
c) Quality assurance plan;
d) Configuration management plan;
e) Relevant policies;
f) Relevant standards.
In multilevel test plans, each lower-level plan must reference the next higher-level plan.
For SEPA also specifically refer to the SEPA Testing Framework and to testing guidelines from the
communities if relevant.
7.2.3 Test items
Identify the test items including their version/revision level. Also specify characteristics of their
transmittal media that impact hardware requirements or indicate the need for logical or physical
transformations before testing can begin.
Supply references to the following test item documentation, if it exists:
a) Requirements specification;
b) Design specification;
c) Users guide;
d) Operations guide;
e) Installation guide.
Reference any incident reports relating to the test items.
Items that are to be specifically excluded from testing may be identified.
For SEPA refer to the Rulebooks, Data Model, Implementation Guidelines and ISO20022 XML
standard when appropriate.
7.2.4 Features to be tested
Identify all software features and combinations of software features to be tested. Identify the test
design specification associated with each feature and each combination of features.
When testing with other parties (like CSM’s or other Banks) the specific features of the system as a
whole (including data interchange) will be described here.
7.2.5 Features not to be tested
Identify all features and significant combinations of features that will not be tested and the reasons.
For SEPA the reasons not to test may be that some features do not relate to SEPA Scheme
compliancy.
EPC228_06 SEPA Testing Framework
Page 52
7.2.6 Approach
Describe the overall approach to testing. For each major group of features or feature combinations,
specify the approach that will ensure that these feature groups are adequately tested. Specify the
major activities, techniques, and tools that are used to test the designated groups of features.
The approach should be described in sufficient detail to permit identification of the major testing
tasks and estimation of the time required to do each one.
Specify the minimum degree of comprehensiveness desired. Identify the techniques that will be used
to judge the comprehensiveness of the testing effort (e.g., determining which statements have been
executed at least once). Specify any additional completion criteria (e.g., error frequency). The
techniques to be used to trace requirements should be specified.
Identify significant constraints on testing such as test item availability, testing resource availability,
and deadlines.
For SEPA testing the SEPA Testing Framework serves as a basis. The use of the Test Scenarios and
their relation to the test cases should be described here.
7.2.7 Item pass/fail criteria
Specify the criteria to be used to determine whether each test item has passed or failed testing.
For SEPA this includes the Acceptance Criteria as specified in the STF and the acceptance criteria
drawn up by the Participant itself or the Community.
7.2.8 Suspension criteria and resumption requirements
Specify the criteria used to suspend all or a portion of the testing activity on the test items associated
with this plan. Specify the testing activities that must be repeated, when testing is resumed.
For SEPA when testing with other Parties (e.g. when testing with a CSM) the suspension criteria and
resumption requirements should be agreed to prevent unnecessary delays when preparing and/or
executing testing.
7.2.9 Test deliverables
Identify the deliverable documents. The following documents should be included:
a) Test plan;
b) Test design specifications;
c) Test case specifications;
d) Test procedure specifications;
e) Test item transmittal reports;
f) Test logs;
g) Test incident reports;
h) Test summary reports.
Test input data and test output data should be identified as deliverables.
Test tools (e.g., module drivers and stubs) may also be included.
For SEPA testing the test summary report is the basis for the decision whether a Participant can
declare itself ‘SEPA Scheme compliant’.
EPC228_06 SEPA Testing Framework
Page 53
7.2.10Testing tasks
Identify the set of tasks necessary to prepare for and perform testing. Identify all inter-task
dependencies and any special skills required.
No specific SEPA points of interest.
7.2.11Environmental needs
Specify both the necessary and desired properties of the test environment. This specification should
contain the physical characteristics of the facilities including the hardware, the communications and
system software, the mode of usage (e.g., stand-alone), and any other software or supplies needed to
support the test.
Also specify the level of security that must be provided for the test facilities, system software, and
proprietary components such as software, data, and hardware.
Identify special test tools needed. Identify any other testing needs (e.g., publications or office space).
Identify the source for all needs that are not currently available to the test group.
For SEPA the requirements for test environments will especially need to elaborate on the information
interchange with other parties as well as the ways to communicate the results of testing amongst the
parties involved.
7.2.12Responsibilities
Identify the groups responsible for managing, designing, preparing, executing, witnessing, checking,
and resolving. In addition, identify the groups responsible for providing the test items identified in
4.2.3 and the environmental needs identified in 4.2.11.
These groups may include the developers, testers, operations staff, user representatives, technical
support staff, data administration staff, and quality support staff.
In addition to this section a reference to the roles and responsibilities in the STF can be made.
7.2.13Staffing and training needs
Specify test staffing needs by skill level. Identify training options for providing necessary skills.
SEPA will require knowledge of the Rulebooks and thus training may be needed.
7.2.14Schedule
Include test milestones identified in the software project schedule as well as all item transmittal
events.
Define any additional test milestones needed. Estimate the time required to do each testing task.
Specify the schedule for each testing task and test milestone. For each testing resource (i.e., facilities,
tools, and staff), specify its periods of use.
The SEPA timelines in the STF can be taken as a starting point for the schedule.
7.2.15Risks and contingencies
Identify the high-risk assumptions of the test plan. Specify contingency plans for each (e.g., delayed
delivery of test items might require increased night shift scheduling to meet the delivery date).
A major risk in the SEPA testing is the time available for testing since the end-date is strict.
EPC228_06 SEPA Testing Framework
Page 54
7.2.16Approvals
Specify the names and titles of all persons who must approve this plan. Provide space for the
signatures and dates.
No specific SEPA information.
EPC228_06 SEPA Testing Framework
Page 55
8
8.1
ANNEX 2: PARTICIPANT’S TEST SUMMARY REPORT
Purpose
The purpose of a test summary report is to summarize the results of the designated testing activities
and to provide evaluations based on these results.
This generic test summary report is based on the IEEE829-1998 standard. Below for each part of this
standard specific remarks for creating a SEPA test summary report have been added. For the actual
content please refer to the IEEE829 standard and relevant books on software testing.
The test summary report structure presented in this annex is only to define the content a test summary
report should hold. It does not imply the structure of a SEPA test summary report nor does it imply
that other content might not be added.
8.2
Outline
A test summary report shall have the following structure:
a) Test summary report identifier;
b) Summary;
c) Variances;
d) Comprehensive assessment;
e) Summary of results;
f) Evaluation;
g) Summary of activities;
h) Approvals.
The sections shall be ordered in the specified sequence. Additional sections may be included just
prior to Approvals. If some or all of the content of a section is in another document, then a reference
to that material may be listed in place of the corresponding content. The referenced material must be
attached to the test summary report or available to users of the summary report.
Details on the content of each section are contained in the following sub-clauses.
8.2.1 Test summary report identifier
Specify the unique identifier assigned to this test summary report. No SEPA specific content.
8.2.2 Summary
Summarize the evaluation of the test items. Identify the items tested, indicating their version/revision
level.
Indicate the environment in which the testing activities took place.
For each test item, supply references to the following documents if they exist: test plan, test design
specifications, test procedure specifications, test item transmittal reports, test logs, and test incident
reports.
When multiple parties have been involved in the testing (e.g. a CSM or another Participant) mention
these as well.
8.2.3 Variances
Report any variances of the test items from their design specifications. Indicate any variances from
the test plan, test designs, or test procedures. Specify the reason for each variance.
EPC228_06 SEPA Testing Framework
Page 56
Deviations from the plans are listed and the impact it had on the SEPA Scheme Compliance
evaluation.
8.2.4 Comprehensiveness assessment
Evaluate the comprehensiveness of the testing process against the comprehensiveness criteria
specified in the test plan (4.2.6) if the plan exists. Identify features or feature combinations that were
not sufficiently tested and explain the reasons. No content that relates to SEPA in particular.
8.2.5 Summary of results
Summarize the results of testing. Identify all resolved incidents and summarize their resolutions.
Identify all unresolved incidents.
Here an overview of the testing is given and the coverage of the Acceptance Criteria and Test
Scenarios is specified.
8.2.6 Evaluation
Provide an overall evaluation of each test item including its limitations. This evaluation shall be
based upon the test results and the item level pass/fail criteria. An estimate of failure risk may be
included.
Here a detailed overview of the test cases performed and the results of these tests is given. This
section holds the detailed information on which the SEPA Scheme Compliance declaration should be
based.
8.2.7 Summary of activities
Summarize the major testing activities and events. Summarize resource consumption data, e.g., total
staffing level, total machine time, and total elapsed time used for each of the major testing activities.
This section describes the testing project, thus is not specific for SEPA Scheme Compliance.
8.2.8 Approvals
Specify the names and titles of all persons who must approve this report. Provide space for the
signatures and dates.
EPC228_06 SEPA Testing Framework
Page 57
9
GLOSSARY OF TERMS
The SEPA Testing Framework is a derived document out of the SDD and SCT Rulebooks and the
corresponding Implementation Guidelines. The users are advised to use corresponding glossaries
from the SCT and SDD Rulebooks for the definitions related to the Schemes.
Terms introduced in the STF are contained in Table 5. Most of the testing terminology used in this
document is based on the glossary of the International Software Testing Qualifications Board (see
www.istqb.org). By using the ISTQB terminology the STF tries to use a worldwide accepted
terminology but the STF recognises that other standards may be used by Participants in their testing
process.
Definition / Explanation
Term
Acceptance criteria
Bank-to-Bank (B2B)
Bank-to-Customer
(B2C)
Customer-to-Bank
(C2B)
Dynamic testing
Invalid testing
Rulebook
SEPA Schemes
Static testing
Test case
Test data
Test level
The exit criteria that a (…) system must satisfy in order to be accepted by an
(…) authorized entity (ISTQB Glossary)
The rulebooks in principle only apply to the requirements for Participants (i.e.
Banks) to be SEPA Scheme compliant. That means only the Bank-to-Bank
communication is in scope.
The rulebooks in principle only apply to the requirements for Participants (i.e.
Banks) to be SEPA Scheme compliant. That means the Bank-to-Customer
communication is NOT in scope, however in some cases the rulebooks do hold
requirements for this space.
The rulebooks in principle only apply to the requirements for Participants (i.e.
Banks) to be SEPA Scheme compliant. That means the Customer-to-Bank
communication is NOT in scope, however in some cases the rulebooks do hold
requirements for this space.
Testing that involves the execution of the software (ISTQB Glossary)
Testing using input values that should be rejected by the system (ISTQB
Glossary).
Within this SEPA Testing Framework, the term ‘Rulebook’ should be
understood to cover the Scheme Rulebooks, i.e. either SDD Rulebook v 2.2
(EPC016-06) or SCT Rulebook v 2.2 (EPC125-05), the corresponding
Implementation Guidelines v 2.2, the SEPA Data Model and the UNIFI
(ISO20022) XML standard. When the term ‘Rulebooks’ is used it refers to both
SDD Rulebook v 2.2 (EPC016-06) and SCT Rulebook v 2.2 (EPC125-05).
The term ‘the SEPA Schemes’ should be understood to refer to both (a
combined set of) the SEPA Direct Debit Scheme (Rulebook, Implementation
Guidelines and Data Model) and SEPA Credit Transfer Scheme (Rulebook,
Implementation Guidelines and Data Model). When the STF project team refers
to a specific scheme it will be either SEPA Direct Debit Scheme (the SDD
Scheme) or SEPA Credit Transfer Scheme (the SCT Scheme)
Testing a system at specification or implementation level without execution of
that software, e.g. reviews (ISTQB Glossary)
A set of input values, execution preconditions, expected results and execution
post-conditions, developed for a particular objective or test condition, such as to
exercise a particular program path or to verify compliance with a specific
requirement (IEEE 610)
Data that exists (for example, in a database) before a test is executed, and that
affects or is affected by the component or system under test (ISTQB Glossary)
A group of test activities that are organized and managed together. A test level
is linked to the responsibilities in a project. Examples of test levels are
component test, system test and acceptance test (ISTQB Glossary)
EPC228_06 SEPA Testing Framework
Page 58
Definition / Explanation
Term
Test plan
Test Scenario
Test strategy
Test Summary Report
Testing
Testing Principle
Valid testing
A document describing the scope, approach, resources and schedule of intended
test activities. It identifies amongst others test items, the features to be tested,
the testing tasks, who will do each task, degree of tester independence, the test
environment, the test design techniques and entry and exit criteria to be used,
and the rationale for their choice, and any risks requiring contingency planning.
It is a record of the test planning process (IEEE 829)
Describes a specific business process flow from end-to-end, i.e. from the
Originator or Creditor to the Beneficiary or Debtor. (STF definition)
A high-level description of the test levels to be performed and the testing within
those levels for an organization or programme (one or more projects) (ISTQB
Glossary)
A document summarizing testing activities and results. It also contains an
evaluation of the corresponding test items against acceptance criteria. (based on
ISTQB Glossary)
The process consisting of all life cycle activities, both static and dynamic,
concerned with planning, preparation and execution of the evaluation of
software products and related work products to determine that they satisfy
specified requirements, to demonstrate that they are fit for purpose and to detect
defects. (based on ISTQB Glossary)
A general rule or guideline to be used when assessing the SEPA Scheme
Compliance which can be implemented in several test cases but also might be
tested in a static manner. (STF definition)
Testing using input values that should be accepted by the system (ISTQB
Glossary)
TABLE 5: GLOSSARY OF TERMS
EPC228_06 SEPA Testing Framework
Page 59