Business Guide GPP SEPA

User Manual: Pdf

Open the PDF directly: View PDF PDF.
Page Count: 87

Global PAYplus Version 4.6.6
Single Euro Payment Area (SEPA)
Business Guide
Single Euro Payment Area (SEPA) Version Control
Global PAYplus Version 4.6.6 Business Guide Page 2
Copyright
© 2019-2017 D+H Global Transaction Banking Solutions. All rights reserved. D+H is a trademark of D+H Limited
Partnership.
PROPRIETARY AND CONFIDENTIAL - This document contains information, which contains Confidential and
Know How property of D+H. Disclosure to or use by persons who are not expressly authorized in writing by D+H
is strictly prohibited.
D+H reserves the right to alter the specifications and descriptions in this publication without prior notice. No part
of this publication shall be deemed to be part of any contract or warranty unless specifically incorporated by
reference into such contract or warranty.
All brand or product names are the trademarks or registered trademarks of their respective holders.
The information contained herein is merely descriptive in nature, and does not constitute a binding offer for the
license of the product described herein.
Catalog ID: GPP4.6-00-B20-01-201706
Single Euro Payment Area (SEPA) Version Control
Global PAYplus Version 4.6.6 Business Guide Page 3
Version Control
Version Date Summary of Changes
1.0 Document Created
1.1 Updates:
• Remove restriction of generating Returns based on days, sections:
o Manual Generation of SEPA Recall Return
o Manual Generation of SEPA Return
• Alternate flows added for Outward Payment Cancellation Request
(PCR)
• Clarify that White Fields are not supported for STEP2.
• Remove 3rd bullet from section Automatic generation of SEPA
Recall Reject
2.0 Apr 2017 Added Stops and Permits Validations section within the SEPA Specific
Validations section
Single Euro Payment Area (SEPA) Table of Contents
Global PAYplus Version 4.6.6 Business Guide Page 4
Table of Contents
1 INTRODUCTION TO SEPA ......................................................................................................... 7
1.1 European Payments Council (EPC)...................................................................................... 7
1.2 Euro Banking Association (EBA) – STEP2 ........................................................................... 7
1.3 SEPA Message Types .......................................................................................................... 8
1.3.1 Supported in GPP ............................................................................................................. 8
1.3.2 Customer-to-Bank Messages .......................................................................................... 10
1.3.3 Inter-Bank Messages ...................................................................................................... 10
1.4 SEPA File Types ................................................................................................................. 10
1.4.1 SEPA Direct Debit Files .................................................................................................. 10
1.4.2 SEPA Credit Transfer Files ............................................................................................. 11
1.5 SEPA Processing ................................................................................................................ 12
1.5.1 SEPA Credit Transfer Files and Messages Workflow ..................................................... 12
1.5.2 SEPA Direct Debit Files and Messages Workflow – Flow Diagram ................................ 13
1.5.3 Files and Messages Process .......................................................................................... 14
2 GPP SEPA CREDIT TRANSFER (SCT) USE CASES ............................................................. 21
2.1 Outward SEPA Credit Transfer ........................................................................................... 21
2.1.1 Outward SEPA Credit Transfer via STEP2 ..................................................................... 22
2.1.2 Outward SEPA Credit Transfer is Warehoused .............................................................. 24
2.1.3 Outward SEPA Credit Transfer Fails Processing ............................................................ 24
2.1.4 Outward SEPA Credit Transfer with Incoming CVF ........................................................ 25
2.1.5 Outward SEPA Credit Transfer with Incoming CCF ........................................................ 26
2.2 Incoming SEPA Credit Transfer .......................................................................................... 27
2.2.1 Incoming SEPA Credit Transfer from STEP2 ................................................................. 28
2.3 Outward Payment Cancellation Request (PCR) ................................................................. 29
2.3.1 Outward PCR via STEP2 ................................................................................................ 29
2.3.2 Outward PCR with Incoming CVF ................................................................................... 32
2.4 Incoming Recall................................................................................................................... 33
2.4.1 Incoming Recall from STEP2 .......................................................................................... 33
2.4.2 Incoming Recall Unmatched ........................................................................................... 34
2.4.3 Original Payment Unqualified for Recall ......................................................................... 34
2.5 Outward Recall Reject ........................................................................................................ 35
2.5.1 Manual Generation of SEPA Recall-Reject ..................................................................... 35
2.5.2 Automatic generation of SEPA Recall Reject ................................................................. 36
2.5.3 Outward Recall Reject with Incoming CVF ..................................................................... 37
2.6 Outward Return ................................................................................................................... 37
2.6.1 Manual Generation of SEPA Recall Return .................................................................... 38
2.6.2 Manual Generation of SEPA Return ............................................................................... 40
2.6.3 Outward Return with Incoming CVF ................................................................................ 41
2.6.4 Outward Return with Incoming CCF ............................................................................... 42
2.7 Incoming Recall Reject ....................................................................................................... 42
2.7.1 Incoming Recall Reject from STEP2 ............................................................................... 42
2.7.2 Incoming Recall Reject Unmatched ................................................................................ 43
2.7.3 Incoming Recall Reject Matched a Pre-settlement Recall .............................................. 43
2.8 Incoming Return .................................................................................................................. 44
2.8.1 Incoming Return from STEP2 ......................................................................................... 44
Single Euro Payment Area (SEPA) Table of Contents
Global PAYplus Version 4.6.6 Business Guide Page 5
3 GPP SDD (SEPA DIRECT DEBIT) USE CASES ...................................................................... 46
3.1 Outward SDD ...................................................................................................................... 46
3.1.1 Outward SDD via STEP2 ................................................................................................ 46
3.1.2 Outward SDD is Warehoused ......................................................................................... 49
3.1.3 Outward SDD Fails Processing ....................................................................................... 49
3.1.4 Outward SDD with Incoming DVF ................................................................................... 49
3.1.5 Outward SDD with Incoming RSF ................................................................................... 51
3.2 Incoming SDD ..................................................................................................................... 52
3.2.1 Incoming SDD from STEP2 ............................................................................................. 52
3.2.2 Incoming Result of Settlement File (RSF) ....................................................................... 56
3.3 Outward Request for Cancellation ...................................................................................... 58
3.3.1 Outward Request for Cancellation via STEP2 ................................................................ 58
3.3.2 Outward Request for Cancellation from Initiating Party .................................................. 60
3.3.3 Outward Reversal ............................................................................................................ 62
3.3.4 Outward Request for Cancellation/Reversal in Manual Queue or Rejected ................... 62
3.3.5 Outward Request for Cancellation/Reversal with Incoming DVF .................................... 64
3.3.6 Outward Reversal with Incoming DVF/RSF .................................................................... 64
3.4 Incoming Request for Cancellation ..................................................................................... 65
3.4.1 Incoming Request for Cancellation from STEP2 ............................................................. 65
3.4.2 Incoming Request for Cancellation Unmatched .............................................................. 67
3.4.3 Incoming Request for Cancellation Matches Collection in Manual Queue ..................... 67
3.4.4 Incoming Request for Cancellation Matches a Completed Collection ............................ 67
3.4.5 Incoming Request for Cancellation Fails Processing ...................................................... 68
3.5 Incoming Reversal .............................................................................................................. 69
3.5.1 Incoming Reversal from STEP2 ...................................................................................... 69
3.5.2 Incoming Reversal Reactivates Mandate ........................................................................ 71
3.5.3 Incoming Reversal Unmatched ....................................................................................... 71
3.5.4 Incoming Reversal Fails Processing ............................................................................... 72
3.5.5 Incoming Reversal with Incoming RSF ........................................................................... 73
3.6 Outward Reject ................................................................................................................... 73
3.6.1 Outward Reject via STEP2 .............................................................................................. 74
3.6.2 Outward Reject with Incoming DVF ................................................................................ 75
3.7 Outward Return/Refund ...................................................................................................... 76
3.7.1 Outward (Core) Return/Refund via STEP2 ..................................................................... 76
3.7.2 Outward B2B Return ....................................................................................................... 78
3.7.3 Outward B2B Refund Not Allowed .................................................................................. 79
3.7.4 Outward Return/Refund Reactivates Mandate ............................................................... 79
3.7.5 Outward Return/Refund with Incoming RSF ................................................................... 79
3.8 Incoming Reject .................................................................................................................. 80
3.8.1 Incoming Reject from STEP2 .......................................................................................... 80
3.9 Incoming Return/Refund ..................................................................................................... 82
3.9.1 Incoming Return/Refund from STEP2 ............................................................................. 82
3.9.2 Incoming Return/Refund with Incoming RSF .................................................................. 84
4 PROCESSING ........................................................................................................................... 85
4.1 SEPA – File Handling ......................................................................................................... 85
4.1.1 File Validation .................................................................................................................. 85
4.1.2 Incoming Files from STEP2 ............................................................................................. 85
Single Euro Payment Area (SEPA) Table of Contents
Global PAYplus Version 4.6.6 Business Guide Page 6
4.2 SEPA General – Individual Handling .................................................................................. 85
4.2.1 Date Validation ................................................................................................................ 85
4.2.2 Warehousing ................................................................................................................... 86
4.2.3 End of Batch Reporting ................................................................................................... 86
APPENDIX A: GLOSSARY .................................................................................................................. 87
Single Euro Payment Area (SEPA) Introduction to SEPA
Global PAYplus Version 4.6.6 Business Guide Page 7
1 Introduction to SEPA
This business guide describes the processing of Single Euro Payments Area (SEPA) payments
certified by Global PAYplus (GPP).
1.1 European Payments Council (EPC)
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 SEPA. The purpose of
the EPC, representing payment service providers (PSPs), is to support and promote European
payments integration and development, notably the SEPA.
EPC develops the SEPA payment schemes, based on global technical standards made available by
international standards bodies, such as the International Organization for Standardization (ISO).
The EPC has created different schemes for Credit Transfer and Direct Debits:
• One scheme for Credit Transfer – SEPA Credit transfer scheme
• Two separate schemes for Direct Debits – a Core scheme and the B2B scheme
The processing rules and data elements between schemes are similar, although the timings differ.
Data exchanged in the interbank space is identified and segregated by the use of codes: Core for the
core scheme and B2B for the Business to Business Scheme.
The SEPA payment schemes, as defined in the SCT (SEPA Credit Transfer) and SDD (SEPA Direct
Debit) Rulebooks, contain sets of rules and standards for the execution of SEPA payment
transactions that have to be followed by scheme participants, which are PSPs that have formally
adhered to the schemes. These rulebooks can be regarded as instruction manuals which provide a
common understanding on how to move funds between payment accounts within SEPA. EPC is
responsible for the development and evolution of the SEPA Schemes and it publishes regularly
(usually once a year) new rulebooks and accompanying implementation guidelines as a definitive
source of information regarding the rules and obligations of the different schemes (SCT, SDD Core
and SDD B2B).
The Rulebook is primarily focused on stating the business requirements and inter-bank rules for the
operation of the Scheme. In addition to the Rulebook, EPC publishes also SEPA implementation
guides (per each scheme) which are separated in two complementary documents:
• The mandatory Guidelines regarding the inter-bank messages (SEPA inter-bank Implementation
Guidelines). These guidelines are further adjusted by EBA guidelines.
• The recommended Guidelines regarding the Customer-to-bank messages (SEPA Customer-to-
bank Implementation Guidelines).
1.2 Euro Banking Association (EBA) – STEP2
The EBA is an industry forum for the European payments industry with close to 200 member banks
and organizations from the European Union and across the world. It is aimed at fostering and driving
pan-European payment initiatives.
EBA CLEARING is a bank-owned provider of pan-European payment infrastructure solutions. EBA
CLEARING owns and operates STEP2, a Pan-European Automated Clearing House (PE-ACH) for
processing euro retail payments. STEP2 provides a processing engine, which is based on global
XML-based ISO standards and is fully compliant with the EPC SCT and SDD Scheme Implementation
Guidelines.
EBA provides concise overview documents that contain the details on the Interfaces between
participants and the STEP2 Services (per EPC schemes). Similarly to EPC, also EBA publishes
Single Euro Payment Area (SEPA) Introduction to SEPA
Global PAYplus Version 4.6.6 Business Guide Page 8
regularly SEPA implementation guides (per each service) that are compliant to the changes declared
by EPC.
The EPC Implementation Guidelines contain recommendations for using the ISO20022 fields for
SEPA messages. By taking all the fields within the rulebook, and all the Mandatory fields within the
ISO20022 messages, EPC have created a SEPA Data Set – a list of fields with a status, format and
specific validation rules. The STEP2 implementation of the ISO 20022 contains all the fields within the
SEPA Data Set and follows their recommendation on formats and validation where possible. In some
cases, additional fields that are not in the SEPA data set have been added where a strong business
need has been identified.
STEP2 supports a Credit Transfer service for the CT scheme and two Direct Debit services (Core and
B2B) to support the two DD schemes. Additionally, STEP2 supports an option in the Core Service to
allow direct debits to be sent (and received) at the latest one inter-bank business day before due date,
also known as COR1.
Additional information related to EBA-STEP2:
Value
Currency code EUR
Operating hours of
STEP2 Direct debits and credit transfers may be transmitted 24 hours a day on all
TARGET2 days.
Cutoff time (COT) • For SEPA Direct Debits there are different COT for collection and R-
messages, per scheme.
o CORE
11:00: COT for DD R-messages
16:00: COT for DD
o B2B
12:00: COT for DD R-message
15:00: COT for DD
• For SEPA Credit Transfers there are several cycles per day and each
cycle has its COT. 16:00 on D (due) date is the latest COT for files to be
settled on D.
1.3 SEPA Message Types
1.3.1 Supported in GPP
This is the list of SEPA Message Types supported in GPP.
1.3.1.1 Payment Initiation
Message Type Description
pain.001 Customer Credit Transfer Initiation (CustomerCreditTransferInitiation). This
message is sent by the initiating party to the forwarding agent or debtor
agent. It is used to request movement of funds from the debtor account to a
creditor. It can contain one or more customer credit transfer instructions.
pain.002 Customer Payment Status Report (CustomerPaymentStatusReport). This
message is sent by an instructed agent to the previous party in the payment
chain. It is used to inform this party about the positive or negative status of an
Single Euro Payment Area (SEPA) Introduction to SEPA
Global PAYplus Version 4.6.6 Business Guide Page 9
Message Type Description
instruction (either single or file). It is also used to report on a pending
instruction.
pain.007 Customer Payment Reversal (CustomerPaymentReversal). This message is
sent by the initiating party to the next party in the payment chain. It is used to
reverse a payment previously executed.
pain.008 Customer Direct Debit Initiation (CustomerDirectDebitInitiation). This
message is sent by the initiating party to the forwarding agent or creditor
agent. It is used to request single or bulk collection(s) of funds from one or
various debtor's account(s) for a creditor.
1.3.1.2 Payments Clearing and Settlement
Message Type Description
pacs.002 Financial Institution To Financial Institution Payment Status Report
(FIToFIPaymentStatusReport). This message is sent by an instructed agent
to the previous party in the payment chain. It is used to inform this party
about the positive or negative status of an instruction (either single or file). It
is also used to report on a pending instruction.
pacs.003 Financial Institution To Financial Institution Customer Direct Debit
(FIToFICustomerDirectDebit). This message is sent by the creditor agent to
the debtor agent, directly or through other agents and/or a payment clearing
and settlement system. It is used to collect funds from a debtor account for a
creditor.
pacs.004 Payment Return (PaymentReturn). This message is sent by an agent to the
previous agent in the payment chain to undo a payment previously settled.
pacs.007 Financial Institution To Financial Institution Payment Reversal
(FIToFIPaymentReversal). This message is sent by an agent to the next
party in the payment chain. It is used to reverse a payment previously
executed.
pacs.008 Financial Institution To Financial Institution Customer Credit Transfer
(FIToFICustomerCreditTransfer). This message is sent by the debtor agent to
the creditor agent, directly or through other agents and/or a payment clearing
and settlement system. It is used to move funds from a debtor account to a
creditor.
1.3.1.3 Exceptions and Investigations
Message Type Description
camt.029 Resolution Of Investigation (ResolutionOfInvestigation). This message is sent
by a case assignee to a case creator/case assigner. It is used to inform of the
resolution of a case, and optionally provides details about:
• the corrective action undertaken by the case assignee
• information on the return where applicable
camt.056 Financial Institution To Financial Institution Payment Cancellation Request
(FIToFIPaymentCancellationRequest). This message is sent by a case
creator/case assigner to a case assignee. It is used to request the
cancellation of an original payment instruction. It is exchanged between the
instructing agent and the instructed agent to request the cancellation of a
interbank payment message previously sent (such as
FIToFICustomerCreditTransfer or FIToFICustomerDirectDebit).
Single Euro Payment Area (SEPA) Introduction to SEPA
Global PAYplus Version 4.6.6 Business Guide Page 10
1.3.2 Customer-to-Bank Messages
GPP implementation of Customer-to-Bank messages is based on EPC guidelines regarding the
Customer-to-bank messages, as per color-coding and requirement instructions:
• Elements denoted with white shading are usually ignored by GPP, they are not mapped into or
from the GPP database.
• Elements denoted with red shading are not available for use in SEPA payments and therefore are
not mapped into or from the GPP database.
• Elements denoted with yellow shading are usually mapped into or from the GPP database,
depending on whether GPP requires these elements for processing and are required to be sent
out from GPP to the Clearing.
• Elements for which the instruction is Mandatory are mapped into and from the GPP database.
1.3.3 Inter-Bank Messages
GPP implementation of Inter-Bank messages is based on the EBA functional description and interface
specifications documents. EBA documentation does not contain any guidelines or references to the
usage of SEPA messages in the Customer-to-Bank domain.
As per the color-coding of EBA Specification, STEP2 will reject all fields that are not colored yellow in
the STEP2 Interface Specifications with error code: XT81.
Under certain conditions, as an additional service, STEP2 allows STEP2 Participants to exchange
additional data fields (the White fields) under the mutual agreement of STEP2 Participants that
subscribe to an Additional Optional Service (AOS).
Note: as per current AOS are not supported and thus white fields will not be sent out to STEP2.
1.4 SEPA File Types
This is the list of SEPA File Types supported in GPP.
1.4.1 SEPA Direct Debit Files
Message
Type Name Description
IDF Input Debit File Used to transmit transactions to the central system by the Direct
Participant’s systems.
DVF Debit Validation
File It is returned by the central system, per transmitted IDF, to the
sending Direct Participant, indicating the success or otherwise of
the validation process.
DNF Debit Notification
File Used to notify to the relevant counterparty accepted Direct Debits
transactions, pre-settlement and post-settlement R-messages.
RSF Results of
Settlement File It includes the status of DD collections and the post-settlement R-
messages which have been sent to the settlement system for the
relevant business date and is delivered to the relevant Direct
Participants, at the end of the settlement phase in a window
specified during the daily cycle. Each Direct Participant will
receive a single RSF notifying them of all the DD collections and
post-settlement R-messages for which they are either the
Instructed Agent or Instructing Agent (either debtor or creditor
DPs).
Single Euro Payment Area (SEPA) Introduction to SEPA
Global PAYplus Version 4.6.6 Business Guide Page 11
1.4.2 SEPA Credit Transfer Files
Message
Type Name Description
ICF Input Credit File Used to transmit transactions to the central system by the Direct
Participant’s systems.
CVF Credit Validation
File It is returned by the central system, per transmitted ICF, to the
sending Direct Participant, indicating the success or otherwise of
the validation process.
SCF Settled Credit File Used to deliver to the relevant counterparty settled transactions
after settlement of the transaction is completed.
CCF Cancelled Credit
File Used to notify originating Direct Participants of any cancelled
instructions at settlement level.
Single Euro Payment Area (SEPA) Introduction to SEPA
Global PAYplus Version 4.6.6 Business Guide Page 12
1.5 SEPA Processing
1.5.1 SEPA Credit Transfer Files and Messages Workflow
csmDebtor bank Creditor bank
ICF
PACS.008
PACS.008
PACS.008
PACS.008
PACS.008
PACS.008
SCF
PACS.008
PACS.008
PACS.008
CVF*
PACS.002s2
Settlement cycle 1
Message
returned
ICF
SCF
PACS.004
ICF
Validation
failure
PACS.008
PACS.008
Match
PACS.004
CAMT.056
PACS.008
PACS.008
CAMT.056
Validation
failure
CVF*
PACS.002s2
Match
PACS.008
PACS.008
PACS.008
PACS.008
PACS.008
PACS.008
PACS.008
CAMT.056
Settlement
failure
CCF*
PACS.002s2
Match
Match
PACS.004
Message
returned
Validation
failure
PACS.002s2
CVF*
PACS.004
PACS.004
PACS.004 PACS.004 Match
Message
returned
Settlement
failure
CCF*PACS.002s2
Match
CAMT.056
Manually
Generated
Recall
ICF CAMT.056 CAMT.056
SCF
Match
PACS.008 PACS.008
PACS.008
CAMT.056 CAMT.056 CAMT.056
PACS.004
CAMT.029
Negative
answer
Positive
answer
Message
returned
CAMT.029
PACS.004
PACS.004
CAMT.029
Match
Debtor
PAIN.001
PAIN.001
PAIN.001
PAIN.001
PAIN.001
PAIN.001
PAIN.001
PAIN.001
PAIN.001
PAIN.001
GPP Validation
failure
PAIN.002
Settlement cycle 2
Match
PAIN.001 PACS.008 PACS.008
PACS.008
* CVF/CCF - Every message can receive a validation failure message back in CCF file; only CT and Returns can receive a settlement failure message back. Not all possible cases are shown in the diagram
Single Euro Payment Area (SEPA) Introduction to SEPA
Global PAYplus Version 4.6.6 Business Guide Page 13
1.5.2 SEPA Direct Debit Files and Messages Workflow – Flow Diagram
Single Euro Payment Area (SEPA) Introduction to SEPA
Global PAYplus Version 4.6.6 Business Guide Page 14
1.5.3 Files and Messages Process
1.5.3.1 SEPA Direct Debit Files and Messages Process
Message
Type Outward/Inward Processing Flow STEP2
/Receiving
Bank
Response
Comments
pain.008 Incoming from
customer Incoming
collection received
ahead of
processing time
N/A Warehousing
pain.008,
pain.002
• Incoming from
customer
• Reject back to
Customer
Incoming
collection fails
pre-processing
N/A Message not included
in the sub-batch
accounting message
that credits the
Customer
pain.008,
pacs.003
• Incoming from
customer
• Outward to CSM
(IDF)
Outward
Collection to
Clearing
(pacs.003)
N/A Message included in
the sub-batch
accounting message
that credits the
Customer
pacs.003,
pacs.002S2
• Outward to CSM
(IDF)
• Incoming from
CSM (DVF/RSF)
Outward
collection,
Incoming CSM
reject
pacs.002S2
as validation
failure
(same day)
or as
settlement
failure (on
settlement
day) from
STEP2
• Match and link
between pacs.003
and pacs.002S2
• May require
‘enrichment’ of
pacs.002S2 when
Rejection is
received on
file/bulk level.
• Reverse
accounting for
Creditor.
pacs.003,
pacs.002
• Outward to CSM
(IDF)
• Incoming from
CSM (pre-
settlement) (DNF)
Outward
collection,
Incoming pre-
settlement Reject
from Debtor
pacs.002
(as Reject)
from Debtor
Bank before
settlement
• Match and link
between pacs.003
and pacs.002
• Reverse
accounting for
Creditor.
pacs.003,
pacs.004
• Outward to CSM
(IDF)
• Incoming from
CSM (post -
settlement) (DNF)
Outward
collection,
Incoming post-
settlement
Return/Refund
from Debtor
pacs.004
(as Return
or Refund)
from Debtor
Bank
• Match and link
between pacs.003
and pacs.002
• Reverse
accounting for
Creditor.
pacs.003,
pain.007,
pain.002
• Outward to CSM
(IDF)
• Incoming
Cancellation from
customer
• Reject back to
Customer
Incoming
Cancellation
Request/Reversal
fails pre-
processing
N/A No accounting
performed against
creditor’s account
Single Euro Payment Area (SEPA) Introduction to SEPA
Global PAYplus Version 4.6.6 Business Guide Page 15
Message
Type Outward/Inward Processing Flow STEP2
/Receiving
Bank
Response
Comments
pacs.003,
pain.007,
pacs.007,
camt.056
• Outward to CSM
(IDF)
• Incoming
Cancellation from
customer
• Outward
Cancellation
Request/Reversal
(IDF)
Outward
Cancellation
Request/Reversal
N/A • Match and link
between pacs.003
and pain.007
(camt.056 or
pacs.007)
• Reverse
accounting for
Creditor.
• Cancellation
Request/Reversal
can be initiated
manually (from
GPP GUI) and not
only triggered by
pain.007.
pacs.007,
camt.056,
pacs.002S2
• Outward
Cancellation
Request/Reversal
(IDF)
• Incoming from
CSM (DVF/RSF)
Outward
Cancellation
Request/Reversal,
Incoming CSM
reject
pacs.002S2
as validation
failure
(same day)
or as
settlement
failure (on
settlement
day) from
STEP2
• May require
‘enrichment’ of
pacs.002S2 when
Rejection is
received on
file/bulk level.
• No reverse
accounting on
receipt of CSM
reject
pacs.003 • Incoming from
CSM (DNF) Incoming
collection from
Clearing (sent by
Creditor)
N/A Must be received
ahead of settlement
(either 2 or 5 days as
per sequence type).
pacs.003,
pacs.002
• Incoming from
CSM (DNF)
• Outward from
Debtor (pre-
settlement) (IDF)
Outward Reject N/A • No accounting
posted to debtor
(neither debit nor
credit)
• Can be generated
manually or
automatically.
• Both A and S
messages are
generated.
pacs.003,
pacs.002,
pacs.002s2
• Incoming from
CSM (DNF)
• Outward from
Debtor (pre-
settlement) (IDF)
• Incoming from
CSM (DVF)
Outward Reject,
Incoming CSM
reject
pacs.002S2
as validation
failure
(same day)
• May require
‘enrichment’ of
pacs.002S2 when
Rejection is
received on
file/bulk level.
• No reverse
accounting on
receipt of CSM
reject.
Single Euro Payment Area (SEPA) Introduction to SEPA
Global PAYplus Version 4.6.6 Business Guide Page 16
Message
Type Outward/Inward Processing Flow STEP2
/Receiving
Bank
Response
Comments
pacs.003,
pacs.004
• Incoming from
CSM (DNF)
• Outward from
Debtor (post -
settlement) (IDF)
Outward
Return/Refund N/A • Reverse
accounting to
debtor
• Can be generated
manually or
automatically.
pacs.003,
pacs.004,
pacs.002s2
• Incoming from
CSM (DNF)
• Outward from
Debtor (post -
settlement) (IDF)
• Incoming from
CSM (DVF/RSF)
Outward
Return/Refund pacs.002S2
as validation
failure
(same day)
or as
settlement
failure (on
settlement
day) from
STEP2
• May require
‘enrichment’ of
pacs.002S2 when
Rejection is
received on
file/bulk level.
• No additional
accounting vs. the
debtor’s account.
pacs.003,
pacs.007,
camt.056
• Incoming from
CSM (DNF)
• Incoming from
CSM (DNF)
Incoming
Cancellation
Request/Reversal
from Clearing
N/A • Reverse
accounting to
debtor. If received
pre-settlement, no
accounting (neither
debit nor credit) is
done vs. the
debtor’s account.
• Note: if pacs.003 is
in a Manual queue,
it should be
cancelled by
incoming R-
message, no
accounting is done.
pacs.003,
pacs.002S2
• Incoming from
CSM (DNF)
• Incoming from
CSM (RSF)
Incoming
collection from
Clearing,
Incoming CSM
reject
pacs.002S2
as
settlement
failure (on
settlement
day) from
STEP2
• Match and link
between pacs.003
and pacs.002S2
• May require
‘enrichment’ of
pacs.002S2 when
Rejection is
received on
file/bulk level.
• Reverse
accounting for
Debtor.
pacs.004,
pacs.002S2
• Incoming from
CSM (post -
settlement) (DNF)
• Incoming from
CSM (RSF)
Incoming post-
settlement
Return/Refund
from Debtor,
Incoming CSM
reject
pacs.002S2
as
settlement
failure (on
settlement
day) from
STEP2
• Match and link
between pacs.004
and pacs.002S2
• May require
‘enrichment’ of
pacs.002S2 when
Rejection is
received on
file/bulk level.
Single Euro Payment Area (SEPA) Introduction to SEPA
Global PAYplus Version 4.6.6 Business Guide Page 17
Message
Type Outward/Inward Processing Flow STEP2
/Receiving
Bank
Response
Comments
• No additional
accounting vs. the
debtor’s account.
pacs.007,
pacs.002S2
• Incoming from
CSM (DNF)
• Incoming from
CSM (RSF)
Incoming
Reversal from
Clearing,
Incoming CSM
reject
pacs.002S2
as
settlement
failure (on
settlement
day) from
STEP2
• Match and link
between pacs.007
and pacs.002S2
• May require
‘enrichment’ of
pacs.002S2 when
Rejection is
received on
file/bulk level.
• No additional
accounting vs. the
debtor’s account.
1.5.3.2 SCT Files and Messages Process
Message
Type Outward/Inward Processing
Flow STEP2
/Receiving
Bank
Response
Comments
pain.001 Incoming from
customer Incoming
payment
received ahead
of processing
time
N/A Warehousing
pain.001,
pain.002
• Incoming from
customer
• Reject back to
customer
Incoming
payment fails
pre-processing
N/A Message not included in
the sub-batch
accounting message that
debits the Customer
pain.001,
pacs.008
• Incoming from
customer
• Outward to
CSM (ICF)
Outward
Payment to
Clearing
(pacs.008)
N/A Message included in the
sub-batch accounting
message that debits the
Customer
pacs.008,
pacs.002S2
• Outward to
CSM (ICF)
• Incoming from
CSM
(CVF/CCF)
Outward
payment,
Incoming CSM
reject
pacs.002S2
as validation
failure (same
day) or
settlement
failure (on
settlement
day) from
STEP2
• Match and link
between pacs.008
and pacs.002S2
• Reverse accounting
for Debtor
pacs.008,
camt.056
• Outward to
CSM (ICF)
• Outward
Recall (ICF)
Outward Recall N/A • Link between
pacs.008 and
camt.056
Single Euro Payment Area (SEPA) Introduction to SEPA
Global PAYplus Version 4.6.6 Business Guide Page 18
Message
Type Outward/Inward Processing
Flow STEP2
/Receiving
Bank
Response
Comments
• If pre-settlement,
reverse accounting
for Debtor.
pacs.008,
pacs.004
• Outward to
CSM (ICF)
• Incoming from
Debtor (SCF)
Outward
payment,
Incoming Return
from Creditor
pacs.004 as
Return from
Creditor
Bank
• Match and link
between pacs.008
and pacs.004
• Reverse accounting
for Debtor
pacs.008,
camt.056,
pacs.004
• Outward to
CSM (ICF)
• Incoming from
Debtor (SCF)
Outward Recall,
Incoming Return
from Creditor
pacs.004 as
Return from
Creditor
Bank
• Match and link
between pacs.008
and pacs.004
• Set camt.056 to
Complete
• Reverse accounting
for Debtor (if was not
performed before).
Amount returned
might differ from
amount sent.
camt.056,
camt.029
• Outward to
CSM (ICF)
• Incoming from
Debtor (SCF)
Outward Recall,
Incoming
Rejection from
Creditor
camt.029 as
Rejection
from Creditor
Bank
• Match and link
between camt.056
and camt.029
• No accounting done
vs. the Debtor
account
pacs.008 • Incoming from
CSM (SCF) Incoming
payment from
Clearing
N/A
pacs.008,
camt.056
• Incoming from
CSM (SCF)
• Incoming from
CSM (SCF)
Incoming Recall
from Clearing N/A • Match and link
between camt.056
and pacs.003
• No accounting done
vs. the Creditor
account
camt.056,
camt.029
• Incoming from
CSM (SCF)
• Outward
Recall
Rejection
(ICF)
Incoming Recall
from Clearing,
Outward Recall
Rejection
N/A No accounting done vs.
the Creditor account
camt.029,
pacs.002S2
• Outward to
CSM (ICF)
• Incoming from
CSM (CVF)
Outward Recall
Rejection,
Incoming CSM
reject
pacs.002S2
as validation
failure (same
day)
No accounting done vs.
the Creditor account
camt.056,
pacs.004
• Incoming from
CSM (SCF)
• Outward
Return (ICF)
Incoming Recall
from Clearing,
Outward Return
Recall
N/A Accounting might be
done vs. Creditor
account depending if
was done before for
pacs.008.
Single Euro Payment Area (SEPA) Introduction to SEPA
Global PAYplus Version 4.6.6 Business Guide Page 19
Message
Type Outward/Inward Processing
Flow STEP2
/Receiving
Bank
Response
Comments
pacs.004,
pacs.002S2
• Outward to
CSM (ICF)
• Incoming from
CSM (CVF)
Outward Return,
Incoming CSM
reject
pacs.002S2
as validation
failure (same
day)
No accounting done vs.
the Creditor account
1.5.3.3 Edge Case Scenarios
Scenarios requiring special or manual handling may occur in the following cases:
• Colliding R-messages: Usually occurs when incoming and outgoing R-messages are processed
against the same original payment or collection:
o When an incoming R-messages matches a collection previously rejected. The latest R-
message is sent to a specific queue for manual handling – see scenario Error! Reference
source not found..
o When the first R-message that has been matched to the original payment or collection, is not
yet completed – see scenario Error! Reference source not found..
• Receiving Recall for payment (CT): Occurs when the R-message is in a Manual queue, see
scenario Error! Reference source not found..
• Receiving CSM reject on an R-message: Occurs when the R-message needs to be sent to a
specific queue for manual handling (manual reverse accounting is expected).
Some possible scenarios:
1. Scenario 1: Colliding incoming and outgoing R-messages
o Message Types:
pacs.003
pacs.002
camt.056
o Message Status:
Rejected (pacs.003)
Complete (pacs.002)
RMSGREJ (camt.056)
RMSGREJ (pacs.002s2)
o Process:
i. Incoming pacs.003 received and fails processing before settlement so it is rejected.
ii. Generates pacs.002 and sends back to Clearing.
iii. Receives Incoming camt.056 (due to the Clearing first processing camt.056 from the
Creditor Side).
Expected result: Both pacs.003 and pacs.002 remain in their statuses, no reverse
accounting, no impact on the existing messages, and camt.056 routed to RMSGREJ.
iv. Receives pacs.002S2 for the outgoing pacs.002 (the Clearing first processed the
camt.056 and therefore when receiving the pacs.002 it is no longer valid so it returns it
back).
Single Euro Payment Area (SEPA) Introduction to SEPA
Global PAYplus Version 4.6.6 Business Guide Page 20
Expected result: Both pacs.003 and pacs.002 remain in their statuses, no reverse
accounting, no impact on the existing messages; and pacs.002S2 routed to RMSGREJ.
2. Scenario 2: Incoming R-message where outgoing R-message is in a manual queue
o Message Types:
pacs.003
pacs.002
camt.056
o Message Status:
Cancelled (pacs.003)
Rejected (pacs.002)
Completed (camt.056)
o Process:
i. Incoming pacs.003 received and fails processing before settlement so it is rejected.
ii. Generates pacs.002 back to Clearing, but pacs.002 fails to Manual queue.
iii. Receives Incoming camt.056, stops the processing of pacs.002 and routes it to Rejected.
- pacs.002 is Rejected
- pacs.003 is set to Cancelled
- camt.056 is processed to Complete
Note: this process only applies when first R-message is in Manual queue. Manual queue
should be distinct from Wait queue (for example OFAC). If an R-message is received and the
outgoing R-message is in Wait queue, the incoming message is routed to a manual queue
until the completion of the outgoing R-message.
3. Scenario 3: Incoming recall for CT which its R-message is in a wait manual queue
o Message Types:
pacs.008
pacs.004
camt.056
o Message Status:
None
o Process:
i. Incoming pacs.008 received and fails processing.
ii. pacs.004 is generated, awaits OFAC.
iii. camt.056 is received and waits until pacs.004 finishes processing:
- If pacs.004 is Completed, camt.029 is generated back with error 'CT already
rejected'.
- If pacs.004 is Rejected, camt.056 will continue to wait user decision.
Single Euro Payment Area (SEPA) GPP SEPA Credit Transfer (SCT) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 21
2 GPP SEPA Credit Transfer (SCT) Use Cases
SEPA payments use cases are based on the Mass Payment use cases with additional clearing
specifications.
Basic SEPA Use Case Alternate SEPA Use Case
Outward SEPA Credit Transfer via STEP2 Outward SEPA Credit Transfer is Warehoused
Outward SEPA Credit Transfer Fails Processing
Outward SEPA Credit Transfer with Incoming CVF
Outward SEPA Credit Transfer with Incoming CCF
Incoming SEPA Credit Transfer from
STEP2
Outward PCR via STEP2 Outward PCR with Incoming CVF
Incoming Recall from STEP2
Manual Generation of SEPA Recall-Reject Automatic generation of SEPA Recall Reject
Outward Recall Reject with Incoming CVF
Manual Generation of SEPA Recall Return Manual Generation of SEPA Return
Outward Return with Incoming CVF
Outward Return with Incoming CCF
Incoming Recall Reject from STEP2
Incoming Return from STEP2
2.1 Outward SEPA Credit Transfer
Use Case Name Outward SEPA Credit Transfer (SCT)
Actors Initiating party, User, Banks core systems, STEP2 Gateway.
Description This use case defines the outward SEPA Credit Transfer via STEP2
Trigger Either by:
• Initiating party (such as a bank customer), sends a file containing multiple
credit payment transactions, or
• User manually creates SCT, or
• SCT message is routed to Mass Payments flow from a different flow.
Pre-conditions Payment initiation is well-formatted and has mandatory information as defined
by EPC pain message (pain.001)
Post-conditions Payment is completed successfully.
ICF file is generated, formatted as per STEP2 specifications, and sent to
STEP2
Basic flow GPP receives a file containing multiple credit payment transactions and can
process it successfully to complete using SCT method of payment.
Alternate flows • CT is sent ahead of time and is warehoused
• CT cannot be processed (cannot derive BIC, sent too late)
• CT is rejected by STEP2 by CVF or CCF
Single Euro Payment Area (SEPA) GPP SEPA Credit Transfer (SCT) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 22
Use Case Name Outward SEPA Credit Transfer (SCT)
• + existing alternate flows as described in the Mass Payments Business
Guide, for use case Outward Credit Transfer
2.1.1 Outward SEPA Credit Transfer via STEP2
GPP receives and processes incoming files that contain transaction messages.
Processing begins upon the receipt of an SCT payment file, a file containing pain.001 messages.
GPP receives the file and starts File processing as described in the Mass Payments Business Guide.
After the file is parsed and validated successfully, GPP generates the individual transactions related
to the validated Payment Information and starts the pre-processing flow. During this step, GPP
checks whether the Creditor and Debtor agents are received.
This use case is based on the Mass Payments Outward Credit Transfer via Clearing use case but
with these STEP2 additions:
• BIC from IBAN Derivation
• Cycle Management
• Outgoing Input Credit File (ICF)
Single Euro Payment Area (SEPA) GPP SEPA Credit Transfer (SCT) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 23
2.1.1.1 Outward SEPA Credit Transfer via STEP2 Workflow
Outward SCT via STEP2
GPP User
Channel/
Initiating Party
Bank’s Core
Systems
GPP MP Processing STEP2
Gateway
GPP
Integration
GPP Clearing
Service
Pre-processing transactions
Execute individuals/bulk
Incoming
Customer
file
(pain.001)
File processing
Sub-batch
generation
Execution
Consolidated
Customer leg
Itemized
Customer leg
Clearing leg
Account Lookup
Compliance check
Balance Inquiry
FX Interface
Posting
Outward ICF
file
(Pacs.008)
Customer
Acknoledge
ment
(pain.002)
End
Individual tx
in Complete
Manual
Create
Other
GPP
flows
Route to
MP flow
Receipt file
Clearing
processing &
formatting
Send file
Creditor/Debtor
Agents received?
BIC from
IBAN
derivation
No
Pass
validation
Yes
Yes
Reject/
Manual
queue
No
Triggers acknowledgement
generation
STEP2 Cycle
determination
PD
<
D-3
Warehouse/
Reject
Yes
PD > D or
PD=D after COT Yes
No
No
After COT of last
Settlement Cycle
Roll
date
2.1.1.1.1 BIC from IBAN Derivation
Since SEPA regulation introduced the IBAN only rule, GPP checks if the BIC is received for
Debtor/Creditor Agent/Financial Institution Identification.
If no BIC is received, GPP triggers the BIC from IBAN derivation procedure for the counter party
(Creditor/Debtor Agent for CT/DD respectively); when the missing Agent is local office BIC
(Debtor/Creditor Agent for CT/DD respectively), GPP sets this agent as the local office BIC.
Single Euro Payment Area (SEPA) GPP SEPA Credit Transfer (SCT) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 24
For SEPA messages, it is expected that the value received in the Debtor/Creditor Agent/Financial
Institution Identification/Other/Identification XML tag is NOTPROVIDED when no BIC is received for
this identification.
2.1.1.1.2 Cycle Management
The STEP2 Credit service consists of a number of processing and settlement cycles per day. GPP
allows for the configuration of the cycles using a dedicated profile (MOP Cycle profile). While
processing the individual CT, GPP evaluates the relevant settlement cycle for each transaction
according to the MOP cycles configuration and the calculated value date.
If the calculated value date is the same as the business date, the transaction is applied with the next
available settlement cycle. GPP checks the assigned sending time against the MOP cycle profile and
applies the cycle with the Cycle closing time which is the closest to this sending time.
If the calculated value date is later than the business date (for example T-1) GPP assigns the first
cycle of the settlement date. GPP chooses the earliest cycle closing time, and applies it to the
transaction.
If the sending time is reached and the file has not been sent (for example Minimum number of
transaction condition from the Bulking profile was not met), the sending time is advanced to the next
sending time indicated in the Bulking profile. At this point the cycle should be re-calculated to assign a
new cycle based on the new sending time.
2.1.1.1.3 Outgoing Input Credit File (ICF)
GPP generates the outgoing file containing pacs.008 messages to STEP2 with File header of ICF as
expected by STEP2.
2.1.2 Outward SEPA Credit Transfer is Warehoused
STEP2 SCT Service allows credit transfer messages to be submitted up to three Business Days prior
to the due date (D Date). Credit transfer messages are not accepted by the STEP2 SCT Service prior
to this earliest Payment date and are warehoused in GPP as per setup.
For details of the flow, see 2.1.1.1Outward SEPA Credit Transfer via STEP2.
2.1.3 Outward SEPA Credit Transfer Fails Processing
An SCT transaction undergoes the same validations as a regular Mass Payments Credit Transfer and
these are the additional validations, which are specific for SEPA Credit Transfer handling:
• Credit Transfer messages received without either the Debtor or Creditor agents triggers a BIC
from IBAN derivation. If BIC cannot be derived, the transaction is rejected.
• For more information of the mass payments validations, see Outward CT (individual) in Manual
queue or Rejected use case in the GPP Business Guide Mass Payments.
For details of the flow, see 2.1.1.1Outward SEPA Credit Transfer via STEP2.
Note: The full list of available error codes for the Reject/Return message are detailed in the SCT
Interface Specification provided by EBA.
Single Euro Payment Area (SEPA) GPP SEPA Credit Transfer (SCT) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 25
2.1.4 Outward SEPA Credit Transfer with Incoming CVF
Irrespective of the result of the validation, only one Credit Validation File (CVF) is returned, per
transmitted Input Credit File (ICF), to the sending Direct Participant indicating the success or failure of
the validation process.
If the Direct Participant exceeds the maximum number of ICFs per Direct Participant per processing
cycle, enforced by the STEP2 Central System, STEP2 returns a single CVF with error code R24 when
the first file in excess of the limit is processed. Additional ICFs received from the Direct Participant in
the current processing cycle are also rejected, but the CVF is not produced by GPP.
The process of this CVF file is described in the GPP Business Guide Mass Payments, Incoming ACH-
Rejection use case.
2.1.4.1 Outward SEPA Credit Transfer with Incoming CVF Workflow
Incoming CVF
GPP User
Channel/
Initiating
Party
Bank’s Core
Systems
GPP MP Processing STEP2 Gateway
GPP
Integration
GPP Clearing
Service
Reject Handling File Processing
ACK Handling
Incoming CVF
(pacs.002S2)
Posting
End
Receipt file
File
Rejected
Pass parsing/
validation?
File Matching?
Yes No
No
Await ACK for
Posting?
ACK present
in File?
Match
with
original CT
Enrich from
original file
No
Yes
Customer
leg
Customer
Leg - Reverse
Original CT in
Complete
Trigger
CT to
Rejected
flow
Trigger
CT to ACK
flow
SEPA processing is
optimistic, not
awaiting ACK
Match with
original tx
Match with
original CT?
Yes
Yes
Manual
queue
No
No
No auto
handle as
NAK for R-
msg
Single Euro Payment Area (SEPA) GPP SEPA Credit Transfer (SCT) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 26
2.1.4.1.1 CVF File and Bulks Matching and Handling
The CVF indicates the validation of the ICF:
• CVFs indicating a positive validation of an ICF (FileRjctRsn = A00) do not contain any specific
rejected transactions and there is no need to take any further action for settlement.
• CVFs indicating a complete rejection of an ICF do not contain any rejected transactions (the CVF
may contain specific rejected credit transfer instructions only if all the credit transfers have been
rejected individually; under these circumstances, the rejected transactions in the CVF gives the
user information to enable diagnosis of the problem). GPP matches the CVF to the ICF by the
Original File Name, and triggers the CT to Rejected for all original transactions sent in the ICF, as
shown in the Outward SEPA Credit Transfer with Incoming CVF Workflow.
• CVFs indicating a partially positive validation of an ICF (FileRjctRsn = A01) contains one bulk for
every bulk received from that sender. Each bulk contains the total number and value of the
messages from the original bulk that were sent and passed validation. The bulk contains zero or
more transactions, one for each message from the original bulk that failed validation.
The group status indicating the status of the original bulk, is set with one of the allowed values:
• ACCP: Entire bulk valid. No further action is required.
• RJCT: Entire bulk rejected. The bulk contains bulk rejection reason code and might contain
transactions, depending on the bulk rejection reason. Regardless whether transaction are present
or not in the bulk, GPP matches the CVF bulk to the original ICF bulk by the original message ID
and triggers the CT to Rejected for all original transactions sent in the matched ICF bulk.
• PART: Partially valid. CVFs indicating partially positive validation of an ICF contains specific
rejected transactions. GPP matches the received rejected transaction against the original
transaction and triggers the CT to Rejected for the original transaction.
2.1.5 Outward SEPA Credit Transfer with Incoming CCF
Originating Direct Participants are notified of any cancelled instructions at settlement level via a
Cancelled Credit File (CCF). The CCF is being sent only after the last cycle of a business day.
Single Euro Payment Area (SEPA) GPP SEPA Credit Transfer (SCT) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 27
2.1.5.1 Outward SEPA Credit Transfer with Incoming CCF Workflow
Incoming CCF
GPP User
Channel/
Initiating
Party
Bank’s Core
Systems
GPP MP Processing STEP2
Gateway
GPP
Integration
GPP Clearing
Service
Reject Handling
File Processing
Incoming CCF
(pacs.002S2)
Posting
End
Receipt file
File
Rejected
Pass parsing/
validation?
Yes
No
No
Yes
Customer
Leg - Reverse
Trigger
CT to
Rejected
flow
Match with
original tx
Manual
queue
No
Yes
Match with
original CT No
Yes
Manual
queue
Bulk Matching?
2.1.5.1.1 CCF File and Bulks Matching and Handling
The Cancelled Credit File (CCF) contains bulks corresponding to the original Credit Transfer bulks in
the ICF.
The group status indicating the status of the original bulk, is set with one of the allowed values:
• RJCT: cancelled by the STEP2 External Settlement Mechanism (ESM). The bulk contains bulk
rejection reason code and might contain transactions, depending on the bulk rejection reason.
Regardless whether transaction are present or not in the bulk, GPP matches the CCF bulk to the
original ICF bulk by the original message ID and triggers the CT to Rejected for all original
transactions sent in the matched ICF bulk.
• PART: partially settled. CCFs indicating partially settled of an ICF contains specific rejected
transactions. GPP matches the received rejected transaction against the original transaction and
triggers the CT to Rejected for the original transaction.
2.2 Incoming SEPA Credit Transfer
Use Case Name Incoming SEPA Credit Transfer (SCT)
Actors User, Banks core systems, STEP2 Gateway.
Description This use case defines the incoming SEPA Credit Transfer from STEP2.
Trigger STEP2 sends an SCF (Settled Credit File) containing multiple SEPA credit
payment transactions.
Pre-conditions SCF file is received with pacs.008 transactions.
Single Euro Payment Area (SEPA) GPP SEPA Credit Transfer (SCT) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 28
Use Case Name Incoming SEPA Credit Transfer (SCT)
Post-conditions Payment is completed successfully
Basic flow GPP receives an SCF file containing multiple credit payment transactions and
can process it successfully to complete using BOOK method of payment.
Alternate flow Existing alternate flows as described in the Mass Payments Business Guide
for use case MPCT.2 (Incoming Credit Transfer)
2.2.1 Incoming SEPA Credit Transfer from STEP2
GPP receives and processes incoming files that contain transaction messages.
Processing begins upon the receipt of an SCF file from STEP2 containing pain.001 messages. GPP
receives the file and starts File processing as described in the GPP Business Guide Mass Payments.
After the file is parsed and validated successfully, GPP generates the individual transactions and
starts the pre-processing flow. During this step, the transactions are individually validated, repaired,
their parties are identified, and they are processed to completion, crediting the beneficiary.
This use case is based on the Mass Payments Incoming Credit Transfer from Clearing use case with
these STEP2 additions:
• Incoming Settled Credit File (SCF).
2.2.1.1 Incoming SEPA Credit Transfer from STEP2 Workflow
Incoming SCF
GPP User
Channel/
Initiating
Party
Bank’s Core
Systems
GPP MP Processing STEP2
Gateway
GPP
Integration
GPP Clearing
Service
Incoming SCF
(pacs.008)
File processing
End
Receipt file
Pre-Processing
Transactions
Sub-batch
generation
Execution &
Execute
Individual
Consolidated
Clearing leg
Itemized
Customer leg
Account Lookup
Compliance check
Balance Inquiry
FX Interface
Posting
2.2.1.1.1 Incoming Settled Credit File (SCF)
GPP receives incoming file containing pacs.008 messages from STEP2 with File header of SCF as
generated by STEP2.
Single Euro Payment Area (SEPA) GPP SEPA Credit Transfer (SCT) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 29
2.3 Outward Payment Cancellation Request (PCR)
Use Case Name Outward Payment Cancellation Request (PCR)
Actors Initiating party, User, Banks core systems, STEP2 Gateway.
Description This use case defines the outward recall from the Originating Bank via
STEP2.
Trigger Originating Bank initiates a recall request
Pre-conditions Original payment was successfully completed
Post-conditions Original Payment is Cancelled, Recall is completed successfully.
ICF file is generated, formatted as per STEP2 specifications, and sent to
STEP2.
Basic flow Originating Bank initiates a recall request which matches a previous payment
which is cancelled as a consequence.
Alternate flows • Recall is rejected by STEP2 by CVF (due to validation error)
• Attempt to generate Recall for already cancelled, recalled, rejected, or
returned CT.
• Consecutive Recall after previous was rejected (either by Clearing or by
incoming camt.029).
2.3.1 Outward PCR via STEP2
After an originating bank transmits a Credit Transfer to STEP2, the originating bank can initiate a
recall of the original payment message either before or after the settlement of the original payment.
Single Euro Payment Area (SEPA) GPP SEPA Credit Transfer (SCT) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 30
2.3.1.1 Outward PCR via STEP2 Workflow
Outward Recall (PCR)
GPP User
Channel/
Initiating Party
Bank’s Core
Systems
GPP MP Processing STEP2
Gateway
GPP
Integration
GPP Clearing
Service
Execution, Pre/Post-Settlement Determination
Execute
individuals/bulk
Itemized
Customer leg
Clearing leg
(subject to
Pre/Post determin.)
Compliance check
FX Interface
Posting
Outward ICF
(camt.056)
End
Individual tx
in Complete
Clearing
processing &
formatting
Recall Initiation,
display Recall
screen
Manual
Input &
Submit
Submit Recall
process
Pre-Settlement>
Yes
Execute as
Pre-
settlement
Execute as
Post-
settlement
Complete
(CT)
Recall
PD
>
D+10
Reject
2.3.1.1.1 Recall Initiation
A GPP user at the originating bank initiates a recall of a previously transmitted payment message,
such as a pacs.008.
A user can initiate a recall if the following conditions exist:
• The debit Method of Payment (MOP) of the original payment message is BOOK.
• The original payment message was transmitted. If the original payment message was not
transmitted, a user can cancel the payment using the cancellation functionality of the GPP UI
(Cancel button).
• The original payment message was not previously recalled.
• The original payment message was previously recalled and the receiving bank rejected the recall.
• The original payment was not rejected by the CSM or returned by the receiving bank.
GPP uses attributes from the original payment message to generate an outward recall message in the
relevant format. The GPP message matching service is used to generate an index for the outward
recall, which can be subsequently used to match the outward recall message with an incoming recall
reject message.
Single Euro Payment Area (SEPA) GPP SEPA Credit Transfer (SCT) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 31
2.3.1.1.2 Manual Input by User
• Recall Initiator: The initiator of the recall can be one of the following:
o Bank: The initiating bank’s BIC, which is the default value.
o Customer: The initiating customer’s name.
• Recall Reason: The reason for recalling the original payment, as per STEP2 specific reason
codes.
Note: The list of available error codes for the Recall message is detailed in the SCT Interface
Specification provided by EBA.
2.3.1.1.3 Outward Recall Process
GPP user clicks the Submit button to submit the outward recall message for processing.
Before transmitting the message, GPP verifies that the recall is within the allowed time limit. One of
the following occurs:
• If the recall occurs after the allowed time limit, GPP generates an error message, routes the recall
message to the Service Rejected queue, and stops processing the recall.
• If the recall occurs within the allowed time limit, GPP continues processing.
GPP determines if the recall is pre or post-settlement, see Pre-settlement Recall, and Post-settlement
Recall. The recall continues with the regular process of a Mass Payments message including sub-
batching, bulking and formatting as per the Mass Payments flow.
2.3.1.1.4 Pre-settlement Recall
If the recall is generated prior to the original payment message’s settlement date, GPP cancels the
original payment and routes the recall to the Service Complete queue as no response is expected
from the STEP2 for this recall.
If the original payment has been posted, GPP executes the required reverse posting for the original
payment message.
2.3.1.1.5 Post-settlement Recall
If the recall is generated after the original payment message is settled, GPP routes the recall to the
Service Wait queue. The recall message remains in this queue until one of the following responses is
received:
• Recall Reject: The receiving bank rejects the recall message.
• Recall Return: The receiving bank accepts the recall and returns the funds.
2.3.1.1.6 Recall Submission Date
The first date to submit a Request for Cancellation is the date of sending the related credit transfer
message. The STEP2 SCT Service validates credit transfer messages prior to R-Messages; this
ensures that if the credit transfer message and its related Request for Cancellation are sent in the
same file, the credit transfer message will be validated and stored before validating the Request for
Cancellation.
All Requests for Cancellation received after the Sending Cut-Off of the Processing Cycle on D are
processed as a Recall and are forwarded to the Instructed Agent according to the procedure set in the
EPC SCT Rulebook.
Single Euro Payment Area (SEPA) GPP SEPA Credit Transfer (SCT) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 32
According to the EPC SCT Rulebook, a Recall can be sent by the Instructing Agent up to ten (10)
Business Days following the settlement of the credit transfer message.
Note: This is not checked by the STEP2 SCT Service.
2.3.1.1.7 Outgoing Input Credit File (ICF)
GPP generates the outgoing file containing camt.056 messages to STEP2 with File header of ICF
(Input Credit File) as expected by STEP2.
2.3.2 Outward PCR with Incoming CVF
Irrespective of the result of the validation, one (and only one) Credit Validation File (CVF) is returned,
per transmitted Input Credit File (ICF) to the sending Direct Participant indicating the success or
failure of the validation process.
The process of this CVF file is described in the GPP Business Guide Mass Payments, Incoming ACH-
Rejection use case.
2.3.2.1 Outward PCR with Incoming CVF Workflow
Incoming CVF for R-msg
GPP User
Channel/
Initiating
Party
Bank’s Core
Systems
GPP MP Processing STEP2 Gateway
GPP
Integration
GPP Clearing
Service
File Processing
Incoming CVF
(pacs.002S2)
End
Receipt file
File
Rejected
Pass parsing/
validation?
File Matching?
Yes No
No
Match with
original tx
Yes
Manual
queue
No
Link with
original tx
Irrespective of the result of validation, only one Credit Validation File (CVF) is returned per transmitted
ICF to the sending Direct Participant indicating the success or otherwise of the validation process.
Validation failure can be received also for an outward R-message, in which case a process to handle
the original outward R-message that was rejected by STEP2, is conducted.
GPP identifies the failed outward PCR in the received CVF. On completion of this action, the outward
PCR is marked as handled, the original payment is reversed to its original status and funds related to
the PCR are reversed (if were credited when the PCR was sent).
See further details in section CVF File and Bulks Matching and Handling.
Single Euro Payment Area (SEPA) GPP SEPA Credit Transfer (SCT) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 33
2.4 Incoming Recall
Use Case Name Incoming SEPA Recall
Actors User, Banks core systems, STEP2 Gateway.
Description This use case defines the incoming SEPA Recall initiated by the Originating
Bank.
Trigger STEP2 sends a Settled Credit File (SCF) containing multiple SEPA Recall
transactions.
Pre-conditions SCF file is received with camt.056 transactions.
Post-conditions Recall is completed successfully
Basic flow GPP receives an SCF file containing multiple Recall transactions and can
process it successfully to complete matching it with an original payment.
Alternate flow • Incoming Recall unmatched
• Original payment unqualified for Recall
2.4.1 Incoming Recall from STEP2
GPP receives and processes incoming files that contain transaction messages.
Processing begins upon the receipt of an SCF file from STEP2 containing camt.056 messages. GPP
receives the file and starts File processing as described in the GPP Business Guide Mass Payments
for regular incoming Mass Payments transactions.
After the file is parsed and validated successfully, GPP generates the individual transactions and
starts the pre-processing flow of each transaction.
When identifying that the incoming transaction is a Recall, GPP attempts to match the incoming recall
message with the original payment message and performs validations on the received Recall.
Single Euro Payment Area (SEPA) GPP SEPA Credit Transfer (SCT) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 34
2.4.1.1 Incoming Recall from STEP2 Workflow
Incoming Recall from STEP2
GPP User
Channel/
Initiating
Party
Bank’s
Core
Systems
GPP MP Processing STEP2
Gateway
GPP
Integration
GPP Clearing
Service
Pre-processing transactions
Incoming SCF
(camt.056)
File processing
End
Receipt file
Match found?
Cancellation
Request Valid?
Service
Rejected
(Recall)
Generation of
Recall Reject
UC
No
No
Service
Wait
Approve
Recall
Approve
Reject
End
Yes
Yes
Triggered automatically
Generation of
Return UC
2.4.1.1.1 Incoming Settled Credit File (SCF)
GPP receives incoming file containing pacs.008 messages from STEP2 with File header of SCF as
generated by STEP2.
2.4.2 Incoming Recall Unmatched
For details of the flow, see 2.1.1.1Incoming Recall from STEP2 Workflow.
If GPP cannot successfully match the incoming recall message, GPP generates a recall reject
message with the relevant rejection reason code, and transmits it back to the originating bank, see
Automatic generation of SEPA Recall Reject.
2.4.3 Original Payment Unqualified for Recall
For details of the flow, see 2.1.1.1Incoming Recall from STEP2 Workflow.
The recall message fails validation due to the original payment being already cancelled or returned.
GPP generates a recall reject message with the relevant rejection reason code, and transmits it to the
originating bank, see section Automatic generation of SEPA Recall Reject.
Single Euro Payment Area (SEPA) GPP SEPA Credit Transfer (SCT) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 35
2.5 Outward Recall Reject
Use Case Name Outward Recall-Reject
Actors User, Banks core systems, STEP2 Gateway.
Description This use case defines the outward Recall Reject sent from the Receiving
Bank. The recall reject message indicates the receiving bank’s refusal of the
originating bank’s recall message.
Trigger User manually rejects the recall.
Pre-conditions Recall is received
Post-conditions Recall is rejected, original message remains in original status.
ICF file is generated, formatted as per STEP2 specifications, and sent to
STEP2
Basic flow User rejects the recall by Reject button
Alternate flows • Automatic generation of the Recall Reject by GPP (with specific SEPA
codes)
• Recall is rejected by STEP2 by CVF (due to validation error)
2.5.1 Manual Generation of SEPA Recall-Reject
GPP user initiates the outgoing recall reject flow using the GPP user interface. A user in the receiving
bank searches for, and navigates to an original payment message in the Approve Recall queue, and
initiates the recall rejection by clicking the Reject button. The user enters the reason for rejection, the
initiator of the recall reject, and submits the message. The status of the original payment message is
set to its status before the receipt of the recall message.
Single Euro Payment Area (SEPA) GPP SEPA Credit Transfer (SCT) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 36
2.5.1.1 Manual generation of SEPA Recall Reject Workflow
Outward Recall-Reject
GPP User
Channel/
Initiating Party
Bank’s
Core
Systems
GPP MP Processing STEP2
Gateway
GPP
Integration
GPP Clearing
Service
Execute
individuals/
bulk
Outward ICF
(camt.029)
End
CT in previous status,
Recall in Service Rejected
Clearing
processing &
formatting
Recall-Reject
Initiation,
display Recall-
Reject screen
Manual
Input &
Submit
Submit Recall-
Reject process
Approve
Recall
Reject
Execution
Includes only STEP2
error codes
PD <
Recall date
+ 10
Yes
Reject
CT and Recall remain in
their previous statuses.
2.5.1.1.1 Recall-Reject Submission Date
According to EPC Rule Book, for handling of the Recall, the Beneficiary Bank has 10 Banking
Business Days to provide the Originator Bank with an answer.
2.5.1.1.2 Recall-Reject Error Codes
When the user initiates the Recall-Reject, the reason for this negative answer must be accompanied
by a valid STEP2 error code.
Note: The list of available error codes for the Recall-Reject message is detailed in the SCT Interface
Specification provided by EBA.
2.5.1.1.3 Outgoing Input Credit File (ICF)
GPP generates the outgoing file containing camt.029 messages to STEP2 with File header of ICF as
expected by STEP2.
2.5.2 Automatic generation of SEPA Recall Reject
GPP automatically generates a Recall Reject for the incoming recall request under the following
circumstances:
• When no match is found (Recall Reject is generated with error code NOOR).
Single Euro Payment Area (SEPA) GPP SEPA Credit Transfer (SCT) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 37
• When the previously received SCT was already returned (Recall Reject is generated with error
code ARDT).
Note: The list of available error codes for the Recall-Reject message is detailed in the SCT Interface
Specification provided by EBA.
2.5.3 Outward Recall Reject with Incoming CVF
Irrespective of the result of the validation, only one Credit Validation File (CVF) is returned, per
transmitted Input Credit File (ICF) to the sending Direct Participant indicating the success or failure of
the validation process. Validation failure can be received also for an outward R-message, in which
case a process to handle the original outward R-message that was rejected by STEP2, is conducted.
2.5.3.1 Outward Recall Reject with Incoming CVF Workflow
Incoming CVF for R-msg
GPP User
Channel/
Initiating
Party
Bank’s Core
Systems
GPP MP Processing STEP2 Gateway
GPP
Integration
GPP Clearing
Service
File Processing
Incoming CVF
(pacs.002S2)
End
Receipt file
File
Rejected
Pass parsing/
validation?
File Matching?
Yes No
No
Match with
original tx
Yes
Manual
queue
No
Link with
original tx
GPP identifies the failed outward Recall Reject in the received CVF. Either a user or an automatic
process conducts corrective action on the outward Recall Reject and its related messages and
indicates when the action is completed. On completion of this action, the outward Recall Reject is
marked as handled, and both the original payment and the incoming Recall are reversed to their
original status.
See further details in section CVF File and Bulks Matching and Handling.
2.6 Outward Return
Use Case Name Outward Return
Actors User, Banks core systems, STEP2 Gateway.
Description This use case defines the outward Return sent from the Receiving Bank.
When received after a recall, the return message indicates the receiving
bank’s acceptance of the originating bank’s recall message and includes the
return of the funds.
Trigger User manually returns the payment.
Pre-conditions Payment is received, recall is received (optionally)
Single Euro Payment Area (SEPA) GPP SEPA Credit Transfer (SCT) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 38
Use Case Name Outward Return
Post-conditions Payment is returned.
ICF file is generated, formatted as per STEP2 specifications, and sent to
STEP2
Basic flow User returns the payment as a result of recall request
Alternate flow • User returns the payment (without any previous recall)
• Automatic generation of Return (reject) due to failure in processing of
incoming SCT
• Return is rejected by STEP2 by CVF (due to validation error)
• Return is rejected during settlement, rejection received in CCF
2.6.1 Manual Generation of SEPA Recall Return
GPP user initiates the outgoing recall return flow using the GPP UI. A user in the receiving bank
searches for and navigates to an original payment message in the Approve Recall queue, and
initiates the recall return by clicking the Approve button. GPP automatically assigns the reason for
return (Following Cancellation Request) and initiator and submits the message. The status of the
original payment message is set to Returned.
Single Euro Payment Area (SEPA) GPP SEPA Credit Transfer (SCT) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 39
2.6.1.1 Manual generation of SEPA Recall-Return Workflow
Outward Recall-Return
GPP User
Channel/
Initiating Party
Bank’s Core
Systems
GPP MP Processing STEP2
Gateway
GPP
Integration
GPP Clearing
Service
Recall-Return
Initiation
Submit Recall-
Return process
Approve
Recall
Approve
Reason code
assigned by GPP
Execute
individuals/
bulk
Outward
Return file
(pacs.004)
End
CT in Returned
Clearing
processing &
formatting
Execution
Compliance check
Balance Inquiry
FX Interface
Posting
Itemized
Customer leg
Clearing leg
Yes
PD <
Recall date
+ 10
Reject
CT and Recall remain in
their previous statuses.
No
Fee
Handling
Subject to bank decision
to implement restriction
2.6.1.1.1 Recall-Return Submission Date
According to EPC Rule Book, for handling of the Recall, the Beneficiary Bank has 10 Banking
Business Days to provide the Originator Bank with an answer.
Note: GPP will not restrict the generation of Return-Recall. This is subject to business rules setup (for
MOP, number of days and return reason code of FOCR).
2.6.1.1.2 Recall Fee Handling (AT-47)
Credit side fees (AT-47) can be defined for the returned message when the outward Return is a
Positive response for a Recall of a Credit Transfer. In this case, the returned amount can differ from
the original amount of the CT.
If credit-side fees had been deducted from the SCT, the customer is debited for the SCT principal
amount less the fee. If the credit-side fee had been posted as a separate fee, the credit customer is
debited for the full principal amount of the SCT.
Single Euro Payment Area (SEPA) GPP SEPA Credit Transfer (SCT) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 40
2.6.1.1.3 Recall-Return Error Codes
When the Return message is a positive answer to a Recall message, the error code (Code under
Return Reason Information) should specify FOCR.
2.6.1.1.4 Outgoing Input Credit File (ICF)
GPP generates the outgoing file containing pacs.004 messages to STEP2 with File header of ICF as
expected by STEP2.
2.6.2 Manual Generation of SEPA Return
GPP user initiates the outgoing return flow using the GPP user interface. A user in the receiving bank
searches for and navigates to an original payment message in a Manual queue (or in Complete) and
initiates the return by clicking the Return button. The user is requested to enter a return reason,
initiator, and submits the message. The status of the original payment message is set to Returned.
2.6.2.1 Manual Generation of SEPA Return Workflow
Outward Return
GPP User
Channel/
Initiating Party
Bank’s Core
Systems
GPP MP Processing STEP2
Gateway
GPP
Integration
GPP Clearing
Service
Execute
individuals/
bulk
Outward
Return file
(pacs.004)
End
CT in Returned
Clearing
processing &
formatting
Return
Initiation,
display Return-
screen
Submit Return
process
Yes
Manual/
Complete
queue
Return
Execution
Manual
Input &
Submit
Compliance check
Balance Inquiry
FX Interface
Posting
Itemized
Customer leg
Clearing leg
PD <
D
+ 3
Reject
CT remains in
previous statuses.
No
Subject to reason
(restrict Technical
Returns)
2.6.2.1.1 Return Submission Date
As per EPC, Return messages initiated by the Beneficiary Bank must be transmitted to the Originator
Bank within three Banking Business Days after Settlement Date. This applies to credit transfer
messages that cannot be processed due to technical reasons, for example, if the Creditor Agent
cannot apply the credit transfer message due to account closure.
Single Euro Payment Area (SEPA) GPP SEPA Credit Transfer (SCT) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 41
However, The STEP2 SCT Service does accept Returns indefinitely after Interbank Settlement Date
to give the Creditor Agent the time to examine statements and return those credit transfer messages
that were incorrectly credited.
Note1: The STEP2 SCT Service does not validate the timeframes for Returns. The Direct Participants
are responsible to comply with the timeframes set in the EPC SCT Rulebook. The list of available
error codes for the Return message is detailed in the SCT Interface Specification provided by EBA.
Note2: GPP will not restrict the generation of Return-Recall. This is subject to business rules setup
(for MOP, number of days and specific return reason codes).
2.6.2.1.2 Outgoing Input Credit File (ICF)
GPP generates the outgoing file containing pacs.004 messages to STEP2 with File header of ICF as
expected by STEP2.
2.6.3 Outward Return with Incoming CVF
Irrespective of the result of the validation, only one Credit Validation File (CVF) is returned, per
transmitted Input Credit File (ICF) to the sending Direct Participant indicating the success or failure of
the validation process.
2.6.3.1 Outward Return with Incoming CVF Workflow
Incoming CVF for R-msg
GPP User
Channel/
Initiating
Party
Bank’s Core
Systems
GPP MP Processing STEP2 Gateway
GPP
Integration
GPP Clearing
Service
File Processing
Incoming CVF
(pacs.002S2)
End
Receipt file
File
Rejected
Pass parsing/
validation?
File Matching?
Yes No
No
Match with
original tx
Yes
Manual
queue
No
Link with
original tx
GPP identifies the failed outward Return in the received CVF. Either a user or an automatic process
conducts corrective action on the outward Return and its related messages and indicates when the
action is completed. On completion of this action, the outward Return is marked as handled, and the
original payment is reversed to its original status. When the Return was a result of a Recall, also the
incoming Recall is reversed to its original status.
See further details in section CVF File and Bulks Matching and Handling.
Single Euro Payment Area (SEPA) GPP SEPA Credit Transfer (SCT) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 42
2.6.4 Outward Return with Incoming CCF
Originating Direct Participants are notified of any cancelled instructions at settlement level via a CCF
(Cancelled Credit File), including Returns cancelled during settlement. The CCF is being sent only
after the last cycle of a business day.
GPP identifies the failed outward Return in the received CCF. Either a user or an automatic process
conducts corrective action on the outward Return and its related messages and indicates when the
action is completed. On completion of this action, the outward Return is marked as handled, and the
original payment is reversed to its original status. When the Return was a result of a Recall, also the
incoming Recall is reversed to its original status.
For the processing of this file, see CCF File and Bulks Matching and Handling.
2.7 Incoming Recall Reject
Use Case Name Incoming Recall Reject
Actors User, Banks core systems, STEP2 Gateway.
Description This use case defines the incoming SEPA Recall Reject received from the
Receiving Bank. The recall reject message indicates the receiving bank’s
refusal of the originating bank’s recall message.
Trigger Incoming Recall-Reject from STEP2.
Pre-conditions Recall is sent.
Post-conditions Recall is rejected, no accounting is done vs. original payment
Basic flow Incoming Recall-reject matches the sent recall.
Alternate flow • Incoming Recall-reject not matched
• Original recall was regarded as pre-settlement
2.7.1 Incoming Recall Reject from STEP2
GPP receives and processes incoming files that contain transaction messages.
Processing begins upon the receipt of a mass payment file, which includes Recalls (such as a file
containing camt.029 messages). GPP is receiving the file and starts File processing.
After the file is parsed and validated successfully, GPP generates the individual transactions and
starts the pre-processing flow.
GPP attempts to match the incoming recall reject message with an outgoing recall message, and
routes the incoming recall reject message to the Service Release queue for review and release by an
authorized user. After a user clicks the Release action button, one of the following occurs:
• If GPP successfully matches the incoming recall reject message to an outgoing recall message, it:
o Links the recall reject message to the recall message
o Sets the incoming recall reject message status to Service Complete
o Sets the outgoing recall message status to Service Rejected
• If GPP cannot match the incoming recall reject message to an outgoing recall message, it sets
the incoming recall reject message status to Service Rejected.
Single Euro Payment Area (SEPA) GPP SEPA Credit Transfer (SCT) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 43
2.7.1.1 Incoming Recall Reject Workflow
Incoming Recall-Reject
GPP User
Channel/
Initiating
Party
Bank’s
Core
Systems
GPP MP Processing STEP2
Gateway
GPP
Integration
GPP Clearing
Service
Processing Reject-Recall
Incoming SCF
(camt.029)
File processing
End
Receipt file
Match found?
Recall is pre-
settlement?
Service
Rejected
(Recall-
Reject)
No
Yes
Yes
No
Pre-Processing
Transactions
Including Match and
link with a previously
sent Recall
Service
Release
Release
Recall-Reject in Service Complete
Recall in Service Rejected
2.7.1.1.1 Incoming Settled Credit File (SCF)
GPP receives incoming file containing camt.029 messages from STEP2 with File header of SCF as
generated by STEP2.
2.7.2 Incoming Recall Reject Unmatched
For details of the flow, see Incoming Recall Reject Workflow. 2.1.1.1
If GPP cannot match the incoming recall reject message to an outgoing recall message, it sets the
incoming recall reject message status to Service Rejected.
2.7.3 Incoming Recall Reject Matched a Pre-settlement Recall
For details of the flow, see Incoming Recall Reject Workflow. 2.1.1.1
If GPP match the incoming recall reject message to an outgoing recall message regarded as pre-
settlement, it sets the incoming recall reject message status to Service Rejected. Manual intervention
is required, as GPP already executed reverse posting for the original payment message, see Pre-
settlement Recall.
Single Euro Payment Area (SEPA) GPP SEPA Credit Transfer (SCT) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 44
2.8 Incoming Return
Use Case Name Incoming Return
Actors User, Banks core systems, STEP2 Gateway.
Description This use case defines the incoming Return received from the Receiving Bank.
The return message indicates the receiving bank’s acceptance of the
originating bank’s recall message and includes the return of the funds.
Trigger Incoming Return from STEP2.
Pre-conditions N/A
Post-conditions Return is completed successfully.
Basic flow GPP receives a file containing Return transaction and can complete it
successfully.
Alternate flow Existing alternate flows as described in the Mass Payments Business Guide
for use case MPCT.5 (Incoming Return)
2.8.1 Incoming Return from STEP2
GPP receives and processes incoming files that contain transaction messages.
Processing begins upon the receipt of a mass payment file, which includes Returns (such as a file
containing pacs.004 messages). GPP is receiving the file and starts File.
After the file is parsed and validated successfully, GPP generates the individual transactions and
starts the pre-processing flow.
This processing flow is based on the GPP incoming return business flow that processes all returns,
including those that are not specific to the recall flow.
GPP attempts to match the incoming return message to the corresponding original payment
message.
If GPP cannot successfully match the two messages, GPP routes the incoming return message to the
ROFi (Return of Funds Incoming) queue for manual handling by a GPP user.
This use case is entirely based on the MPCT.5 (Incoming Return) use case with these STEP2
additions:
• Recall Fee Handling (AT-47)
• Incoming Settled Credit File (SCF)
• Incoming Recall-Return
Single Euro Payment Area (SEPA) GPP SEPA Credit Transfer (SCT) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 45
2.8.1.1 Incoming Return from STEP2 Workflow
Incoming Return
GPP User
Channel/
Initiating
Party
Bank’s Core SystemsGPP MP Processing STEP2 Gateway
GPP
Integration
GPP Clearing
Service
Pre-processing
Incoming SCF
(pacs.004)
File processing
End
Receipt file
Including link with a
previously sent Recall, for
incoming Return-Recall
ROFi
Match
found?
Sub-batch
generation
Execution &
Execute
individual
No bulking/Outgoing
format
Incoming Return to Complete
Outward Recall to Service Complete
Outward CT to Returned
No
Processing
individual
Return Compliance check
FX Interface
Posting
Consolidated
Clearing leg
Itemized
Customer leg
Fee
Handling
2.8.1.1.1 Recall Fee Handling (AT-47)
Credit side fees (AT-47) can be defined for the returned message when the outward Return is a
Positive response for a Recall of a Credit Transfer. In this case, the returned amount can differ from
the original amount of the CT.
GPP accepts inward returns that include recall fees (AT-47) and the posting to the Customer/Recall
Suspense (subject to the initiator of the Recall) account, is for the interbank settlement amount, when
the charges have already been deducted.
2.8.1.1.2 Incoming Settled Credit File (SCF)
GPP receives incoming file containing pacs.004 messages from STEP2 with File header of SCF as
generated by STEP2.
2.8.1.1.3 Incoming Recall-Return
When GPP successfully matches the two messages following processing of the return message, GPP
does the following:
• Sets the incoming return message status to Complete
• Sets the outgoing recall message status to Service Complete
• Links the return message to the original payment message and sets the original payment
message status to Returned.
Single Euro Payment Area (SEPA) GPP SDD (SEPA Direct Debit) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 46
3 GPP SDD (SEPA Direct Debit) Use Cases
SEPA payments Use Cases are based on the MP (Mass Payment) use cases with additional clearing
specifications.
Basic SEPA Use Case Alternate SEPA Use Case
Outward SDD via STEP2 Outward SDD via STEP2 Workflow
Direct Debit Submission Dates
BIC from IBAN Derivation
Additional SEPA Specific Validations
Outgoing Input Debit File (IDF)
Outward SDD is Warehoused
Outward SDD Fails Processing
Outward SDD with Incoming DVF Outward SDD with Incoming DVF Workflow
• DVF File and Bulks Matching and Handling
Outward SDD with Incoming RSF Outward SDD with Incoming RSF Workflow
• RSF File and Bulks Matching and Handling (by the
Sender)
3.1 Outward SDD
Use Case Name Outward SEPA Direct Debit (SDD)
Actors Initiating party, User, Banks core systems, STEP2 Gateway.
Description This use case defines the outward SEPA Direct Debit via STEP2.
Trigger Either by:
• Initiating party (such as a bank customer), sends a file containing multiple
direct debit transactions, or
• Message is routed to Mass Payments flow from a different flow.
Pre-conditions Collection initiation is well-formatted and has mandatory information as
defined by EPC pain message (pain.008)
Post-conditions Collection is completed successfully.
IDF file is generated, formatted as per STEP2 specifications, and sent to
STEP2
Basic flow GPP receives a file containing multiple direct debit transactions and can
process it successfully to complete using SDD method of collection.
Alternate flows • DD is sent ahead of time and is warehoused
• DD cannot be processed (for example, cannot derive BIC, sent too late).
• DD is rejected by STEP2 by DVF or RSF
• plus existing alternate flows as described in the GPP Business Guide
Mass Payments, for use case Outward Direct Debit
3.1.1 Outward SDD via STEP2
GPP receives and processes incoming files that contain transaction messages.
Single Euro Payment Area (SEPA) GPP SDD (SEPA Direct Debit) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 47
Processing begins upon the receipt of a mass collection file, such as a file containing pain.008
messages. GPP is receiving the file and starts File processing.
After the file is parsed and validated successfully, GPP generates the individual transactions related
to the validated collection Information and starts the pre-processing.
This use case is based on the Mass Payments Outward Direct Debit via Clearing use case but with
these STEP2 additions:
• Direct Debit Submission Dates
• BIC from IBAN Derivation
• Additional SEPA Specific Validations
• Outgoing Input Debit File (IDF)
Single Euro Payment Area (SEPA) GPP SDD (SEPA Direct Debit) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 48
3.1.1.1 Outward SDD via STEP2 Workflow
Outward SDD via STEP2
GPP User
Channel/
Initiating Party
Bank’s Core
Systems
GPP MP Processing STEP2
Gateway
GPP Integration GPP Clearing
Service
Pre-processing transactions
Incoming
Customer
file
(pain.008)
File processing
Sub-batch
generation
Execution
Execute
individuals/
bulk
Consolidated
Customer leg
Itemized
Customer leg
Clearing leg
Account Lookup
Compliance check
Balance Inquiry
FX Interface
Posting
Outward
IDF
(Pacs.003)
Customer
Acknoledge
ment
(pain.002)
End
Other
GPP
flows
Route to
MP flow
Receipt file
Clearing
processing &
formatting
Send file
Creditor/Debtor
Agents received?
BIC from
IBAN
derivation
No
Yes
Reject/
Manual
queue
No
PD
<
D-14(C)
Warehouse/
Reject
Yes
PD >
D-1(T) Yes
No
SEPA
specific
validations
Pass
validation
Yes
No
3.1.1.1.1 Direct Debit Submission Dates
A direct debit can be submitted to STEP2 by the Creditor Agent 14 (calendar) days before the
Interbank Settlement Date of the direct debit.
Additionally, the latest date on which a direct debit can be submitted to STEP2 is at least one
TARGET day before the Interbank Settlement Date of the direct debit, irrelevant of its sequence type.
Single Euro Payment Area (SEPA) GPP SDD (SEPA Direct Debit) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 49
3.1.1.1.2 BIC from IBAN Derivation
See BIC from IBAN Derivation.
3.1.1.1.3 Additional SEPA Specific Validations
• Creditor ID and IBAN check digit validation: GPP ensures that the Creditor ID and IBAN (both
Debtor Account and Creditor Account) received in the collection are valid as per the MOD 97-10
Algorithm which validates the check digit as per the elements of the Creditor ID and the IBAN. For
SEPA Creditor IDs, the Creditor Business Code (characters 5-7) is ignored.
Note: Creditor ID is case and space insensitive.
• Allowed Scheme validation: When processing the collection, at the stage of deriving the
Creditor attributes, GPP validates that the requested scheme of the collection is consistent with
the allowed schemes of the creditor.
3.1.1.1.4 Outgoing Input Debit File (IDF)
GPP generates the outgoing file containing pacs.003 messages to STEP2 with File header of IDF as
expected by STEP2.
3.1.2 Outward SDD is Warehoused
STEP2 SDD Core & B2B Service allows direct debit messages to be submitted up to 14 Calendar
Days prior to the due date of the direct debit. Direct Debit messages are not accepted by the STEP2
SDD Core & B2B Service prior to this earliest Payment date, and are warehoused in GPP as per
setup.
For details of the flow, see Outward SDD via STEP2.
3.1.3 Outward SDD Fails Processing
An SDD transaction undergoes same validations as a regular Mass Payments Direct Debit and these
are the additional validations, which are specific for SEPA DD handling:
• Direct Debit messages received without either the Debtor or Creditor agents, triggers a BIC from
IBAN derivation. If BIC cannot be derived, the transaction is rejected.
• Last submission date for SEPA Direct Debits (for both Core and B2B schemes) is at least one
TARGET day ahead of the message’s due date (Interbank Business Day). If it is not, the
message cannot be sent to STEP2. The decision whether to reject the message back to the
customer, or to roll its due date, is subject to setup.
For details of the flow, see Outward SDD via STEP2.
Note: The list of available error codes for the Reject/Return message is detailed in the SDD Interface
Specification provided by EBA.
3.1.4 Outward SDD with Incoming DVF
Irrespective of the result of validation, only one Debit Validation File (DVF) is returned per transmitted
Input Debit File (IDF) to the sending Direct Participant, indicating the success or failure of the
validation process.
Note: If the Direct Participant exceeds the maximum number of IDFs per Direct Participant per
settlement cycle, enforced by the STEP2 Central System, STEP2 returns a single DVF with error
code R24. When the first file in excess of the limit is processed; additional IDFs received from the DP
in the current settlement cycle are also rejected, but the DVF is not sent.
Single Euro Payment Area (SEPA) GPP SDD (SEPA Direct Debit) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 50
The process of this DVF file is described in the GPP Business Guide Mass Payments, Incoming ACH-
Rejection use case.
3.1.4.1 Outward SDD with Incoming DVF Workflow
Incoming DVF
GPP User
Channel/
Initiating
Party
Bank’s Core
Systems
GPP MP Processing Clearing
Gateway
GPP
Integration
GPP Clearing
Service
Reject Handling File Processing
ACK Handling
Incoming DVF
(pacs.002S2)
Posting
End
Receipt file
File
Rejected
Pass parsing/
validation?
File Matching?
Yes
No
No
Await ACK for
Posting?
ACK present
in File?
Match
with
original DD
Enrich from
original file
No
Customer
leg
Customer
Leg - Reverse
Original DD in
Complete
Trigger
DD to
Rejected
flow
Trigger
DD to
ACK flow
SEPA processing is
optimistic, not
awaiting ACK
Match with
original tx
Yes
Manual
queue
No
Match with
original DD No
Yes
3.1.4.1.1 DVF File and Bulks Matching and Handling
DVF validates the IDF:
• DVFs indicating a positive validation of an IDF (FileRjctRsn = A00) do not contain any specific
rejected transactions and there is no need to take any further action for settlement.
• DVFs indicating a complete rejection of an IDF do not contain any rejected transaction (the DVF
may contain specific rejected debit instructions only if all the debits have been rejected; under
these circumstances, the rejected transactions in the DVF give the user information to enable
Single Euro Payment Area (SEPA) GPP SDD (SEPA Direct Debit) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 51
diagnosis of the problem). GPP matches the DVF to the IDF by the Original File Name, and
triggers the DD to Rejected for all original transactions sent in the IDF, as shown in the workflow.
• DVFs indicating a partially positive validation of an IDF (FileRjctRsn = A01) contains one bulk for
every bulk received from that sender. Each bulk contains the total number and value of the
messages from the original bulk that were sent and passed validation. The bulk contains zero or
more transactions, one for each message from the original bulk that failed validation.
The group status indicating the status of the original bulk, is set with one of the allowed values:
• ACCP: Entire bulk is valid. No further action is required.
• RJCT: Entire bulk is rejected. The bulk contains bulk rejection reason code and might contain
transactions, depending on the bulk rejection reason. Regardless whether transaction are present
or not in the bulk, GPP matches the DVF bulk to the original IDF bulk by the original message ID
and triggers the DD to Rejected for all original transactions sent in the matched IDF bulk.
• PART: Partially valid. DVFs indicating partially positive validation of an IDF contains specific
rejected transactions. GPP matches the received rejected transaction against the original
transaction and triggers the DD to Rejected for the original transaction.
3.1.5 Outward SDD with Incoming RSF
Originating Direct Participants are notified of any cancelled instructions at settlement level via a
Results of Settlement File (RSF). The RSF is delivered to the relevant Direct Participants during the
output phase of the daily cycle.
3.1.5.1 Outward SDD with Incoming RSF Workflow
Incoming RSF
GPP User
Channel/
Initiating
Party
Bank’s Core
Systems
GPP MP Processing STEP2
Gateway
GPP
Integration
GPP Clearing
Service
Reject Handling
File Processing
Incoming RSF
(pacs.002S2)
Posting
End
Receipt file
File
Rejected
Pass parsing/
validation?
Yes
No
Yes
Customer
Leg - Reverse
Trigger
DD to
Rejected
flow
Match with
original tx
Manual
queue
No
Yes
Match with
original DD No
Yes
No Manual
queue
Bulk Matching?
3.1.5.1.1 RSF File and Bulks Matching and Handling (by the Sender)
The RSF file contains bulks corresponding to the bulks received from the sender in an IDF.
Single Euro Payment Area (SEPA) GPP SDD (SEPA Direct Debit) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 52
The group status indicating the status of the original bulk, is set with one of the allowed values:
• ACSC: Accepted (settlement confirmed). No further action is required.
• RJCT: Cancelled by the STEP2 External Settlement Mechanism (ESM). The bulk contains bulk
rejection reason code and might contain transactions, depending on the bulk rejection reason.
Regardless whether transaction are present or not in the bulk, GPP matches the RSF bulk to the
original IDF bulk by the original message ID and triggers the DD to Rejected for all original
transactions sent in the matched IDF bulk.
• PART: Partially settled. RSFs indicating partially settled of an IDF contains specific rejected
transactions. GPP matches the received rejected transaction against the original transaction and
triggers the DD to Rejected for the original transaction.
3.2 Incoming SDD
Use Case Name Incoming SEPA Direct Debit
Actors User, Banks core systems, STEP2 Gateway.
Description This use case defines the incoming SEPA Direct Debit from STEP2.
Trigger The clearing sends a file containing multiple SEPA direct debit transactions.
Pre-conditions Collection has mandatory information as defined by SEPA pacs.003
message.
Post-conditions Collection is completed successfully.
Basic flow GPP receives a file containing multiple direct debit transactions and can
process it successfully to complete debiting the Debtors.
Alternate flow • DD is rejected by STEP2 by RSF
• plus existing alternate flows as described in the GPP Business Guide
Mass Payments, for use case Incoming Direct Debit
3.2.1 Incoming SDD from STEP2
GPP receives and processes incoming files that contain transaction messages.
Processing begins upon the receipt of a mass collection file, such as a file containing pacs.003
messages. GPP receives the file and starts File processing.
After the file is parsed and validated successfully, GPP generates the individual transactions and
starts the pre-processing flow. During this phase, the transactions are individually validated, repaired,
their parties are identified, and they are processed to completion, debiting the debtor customer.
Mandate validation is part of this process.
This use case is based on the Mass Payments Incoming Direct Debit from Clearing use case with
these STEP2 additions:
• SEPA Specific Validations
• Incoming Debit Notification File (DNF)
Single Euro Payment Area (SEPA) GPP SDD (SEPA Direct Debit) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 53
3.2.1.1 Incoming SDD from STEP2 Workflow
Incoming SDD
GPP User
Channel/
Initiating
Party
Bank’s Core
Systems
GPP MP Processing STEP2
Gateway
GPP
Integration
GPP Clearing
Service
Pre-processing transactions
Incoming DNF
(pacs.003)
File processing
End
Receipt file
Sub-batch
generation
Execution &
Execute
Individual
Consolidated
Clearing leg
Itemized
Customer leg
Account Lookup
Compliance check
Balance Inquiry
FX Interface
Posting
Reject/
Manual
queue
No
SEPA
specific
validations
Pass
validation
Yes
Debtor
Mandate
validations
Pass
validation
No
3.2.1.1.1 SEPA Specific Validations
• Creditor ID and IBAN check digit validation
GPP ensures that the Creditor ID and IBAN (both Debtor Account and Creditor Account) received
in the collection are valid as per the MOD 97-10 Algorithm which validates the check digit as per
the elements of the Creditor ID and the IBAN. For SEPA Creditor IDs, the Creditor Business Code
(characters 5-7) is ignored.
Note: Creditor ID is case and space insensitive.
• Stops and Permits Validations
GPP supports customer preferences for defining a list of stops or permits from debiting a payer
account. This is done by the use of the Stops and Permits profile. This profile is used by financial
institutions to define whether to Stop or permit any direct debits to the payer’s payment account or
to Stop or permit any direct debits initiated by one or more specified payees.
The list of profiles are evaluated after the invocation of the DD Stops and Permits mode rule. The
rules conditions determine the client preferences as to whether GPP checks for Permits or Stops.
The DD Stops and Permits profiles can be updated per client request manually, via GPP user
Single Euro Payment Area (SEPA) GPP SDD (SEPA Direct Debit) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 54
interface, or automatically, via ProfileActionsService where actions of Create, Update, and Delete
are available.
Every incoming DD transaction is evaluated by the DD Stops and Permits mode Rule, before
searching for a relevant Mandate (even if a Creditor appears in a Permit Profile for a specific
Account, this does not remove the need for a Mandate Profile). When a rule is matched, GPP
searches within the Stops and Permits profiles based on the rule action (stops or permits). When
the rules actions is:
o Stop - GPP filters the Stops and Permits profiles to the ones marked as ‘Stop’ and then
searches for a suited profile:
GPP searches the Stops and Permits table and looks for a Stop profile to match the
transaction attributes (Dr Account, Creditor ID, MOP and Scheme).
When no match is found, GPP searches the Stops and Permits table and looks for a Stop
profile to match only the Dr Account, Creditor ID and MOP payment attributes (scheme is
null).
When no match is found, GPP searches the Stops and Permits table and looks for a Stop
profile to match only the Dr Account and Creditor ID payment attributes (MOP and
Scheme are null).
When no match is found, GPP searches the Stops and Permits table and looks for a Stop
profile to match only Dr Account in the payment attribute (Creditor ID, MOP and Scheme
are null).
When a profile is found GPP continues to check if the transaction is cross border or
domestic according to the criteria defined in the profile. If the criteria matches the
transaction, GPP rejects the transaction back to clearing and logs an error.
If profile was found and the criteria does not match to the transaction or a profile was not
found, GPP will continue to process the transaction.
o Permit - GPP filters the Stops and Permits to the ones marked as ‘Permit’ and then searches
for a suited profile based on the incoming transaction.
When the account is available in the list, GPP searches the Stops and Permits table and
looks for a Permit profile to match the transaction attributes (debit account, creditor ID,
MOP and scheme).
When no profile is found, GPP searches the Stops and Permits table and looks for a
Permit profile to match only the debit account, creditor ID and MOP payment attributes
(scheme is null).
When no profile is found, GPP searches the Stops and Permits table and look for a
Permit profile to match only the debit account and creditor ID payment attributes (MOP
and scheme are null).
When no profile is found, GPP searches the Stops and Permits table and looks for a
Permit profile to match only debit account in the payment attributes (creditor ID, MOP and
scheme are null).
When a profile is found, GPP continues to check whether the transaction is cross border
or domestic, according to the criteria defined in the profile and continues message
processing when matched.
If profile was found and the criteria does not match to the transaction or a profile was not
found, GPP rejects the transaction back to clearing and logs an error.
Cross border check is done by comparing the first two characters of the Dr and Cr IBAN.
Skip - GPP does not search for any Stops and Permits profile and continues with processing.
• Debtor Mandate validations
Debtor mandate validations facilitated for SEPA direct debits include:
Single Euro Payment Area (SEPA) GPP SDD (SEPA Direct Debit) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 55
o Check mandate existence using the unique mandate reference (UMR) and Creditor ID
(excluding characters 5-7 of the Creditor ID
o Manual set-up of debtor mandates is available. This enables the financial institution to pre-
define limit checks, cancel a mandate and specify rejection of a collection before it is actually
received
o GPP provides means to limit the collections received against an account or an established
mandate and is validating the collection according to these limitations:
Prohibit the processing of collections against a Debtor account, and/or a Creditor ID,
and/or a scheme.
Prohibit the processing of collections against an established mandate for a defined
period.
o Fixed amount: if a fixed collection amount was set on the mandate, then GPP validates that
the collection’s amount equals the amount defined on the mandate.
o Total aggregated amount: if a limit was set on the total aggregate amount of collection against
the mandate, then GPP validates that current transaction does not exceed the total
aggregated amount.
o Periodicity: when mandate periodicity is defined on the mandate, GPP validates that the
collection meets the periodicity defined.
• B2B specific Mandate validation
Upon receipt of an incoming B2B message, GPP ensures that a mandate is already established
and it verifies the data of the collection vs. the data set on the mandate. For Core transaction,
when a mandate does not exist prior to the receipt of the transaction, GPP creates a mandate
profile upon receipt of an incoming Core message, as per the mandate data received in the
transaction.
• Existing Mandate data vs. collection mandate data
When a mandate is established prior to the receipt of the collection, GPP checks that:
o GPP validates that the Scheme Type of the mandate matches the Scheme of the Incoming
Direct Debit collection (both should be either B2B or Core).
o GPP validates that the Recurrence Type of the mandate matches with Sequence Type of the
collection:
If recurrence type is One-off, the sequence type in the direct debit collection must be
OOFF. If it does not match, the collection is considered invalid.
If recurrence type is Recurrent, the sequence type in the direct debit collection must be
either FRST, RCUR, or FNAL. If it does not match, the collection is considered invalid.
o GPP validates that the Debtor details as setup in the Mandate profile, matches the debtor
details received in the collection, specifically the Debtor bank BIC and Debtor account.
• Mandate Amendments
o If the UMR changed as per a mandate amendment in an incoming direct debit, the original
and previous UMR fields are also mapped to the Mandate profile. Similarly, if the Creditor ID
changed as per a mandate amendment in an inward direct debit, the original and previous
Creditor ID fields are mapped to the Mandate profile
o Amendment Indicator and related details:
When the amendment indicator is set to TRUE, GPP validates that at least one of the
amendment information details fields is included in the collection.
If an amendment information field is not included, the collection is considered invalid and
is rejected.
Single Euro Payment Area (SEPA) GPP SDD (SEPA Direct Debit) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 56
When the amendment indicator is set to FALSE, GPP validates none of the amendment
information details fields are included in the collection. If at least one of the amendment
information details field is included, the collection is considered invalid and is rejected.
o GPP validates that amendments in the amendment information details of the collection, are
amendments to the data that exist in the mandate profile. At the same time, GPP validates
that if an amendment occurred vs. existing mandate profile data, the amendment is
mentioned in the collection under the amendment information details. GPP validates these
attributes: Creditor Name, Debtor account and Debtor agent
If any of these attributes stored on the mandate do not match the corresponding attributes
as received in the collection, and the attribute is not listed in the amendment details of the
collection, the collection is considered invalid.
GPP checks that the mandate related attributes that are present in the amendment
information details of the collection (as original values) matches the mandate related
attributes in the same collection. When the amendment indicator on the collection is set to
TRUE, if any of the attributes declared as amended (populated as original attributes in the
amendment information details of the collection), is similar to the same attribute as
received in the collection, the collection is considered invalid.
3.2.1.1.2 Incoming Debit Notification File (DNF)
GPP receives incoming file containing pacs.003 messages from STEP2 with File header of DNF
(Debit Notification File) as generated by STEP2.
3.2.2 Incoming Result of Settlement File (RSF)
Each direct participant receives a single RSF notifying them of all the DD collections and post-
settlement R-messages for which they are either the Instructed Agent or Instructing Agent (either
debtor or creditor direct participant).
The process of this file on the Debtor Side is similar to the process of an RSF file received on the
Creditor Side, with the exception of matching against an incoming collection:
• When matched, the collection is cancelled. If the collection was already processed (rare scenario,
not expected to occur) and the debtor was debited, the incoming message is crediting the debited
amount back to the debtor.
• When not matched, the incoming message is routed to a manual queue for user to handle outside
of GPP.
Single Euro Payment Area (SEPA) GPP SDD (SEPA Direct Debit) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 57
3.2.2.1 Incoming RSF Workflow
Incoming RSF
GPP User
Channel/
Initiating
Party
Bank’s Core
Systems
GPP MP Processing STEP2
Gateway
GPP
Integration
GPP Clearing
Service
Reject Handling
File Processing
Incoming RSF
(pacs.002S2)
Posting
End
Receipt file
File
Rejected
Pass parsing/
validation?
Yes
No
Yes
Customer
Leg - Reverse
Trigger
DD to
Rejected
flow
Match with
original tx
Manual
queue
No
Yes
Match with
original DD No
Yes
No Manual
queue
Bulk Matching?
3.2.2.1.1 RSF File and Bulks matching and handling (by the receiver)
The RSF file contains bulks corresponding bulks sent to that receiver by the STEP2 in a DNF.
The group status indicating the status of the original bulk, is set with one of the allowed values:
• ACSC: Accepted (settlement confirmed). No further action is required.
• RJCT: Cancelled by the STEP2 External Settlement Mechanism (ESM). The bulk contains bulk
rejection reason code and might contain transactions, depending on the bulk rejection reason.
Regardless whether transaction are present or not in the bulk, GPP matches the RSF bulk to the
original DNF bulk by the original message ID and triggers the DD to Rejected for all original
transactions sent in the matched IDF bulk.
• PART: Partially settled. RSFs indicating partially settled of a DNF contains specific rejected
transactions. GPP matches the received rejected transaction against the original transaction and
triggers the DD to Rejected for the original transaction.
Single Euro Payment Area (SEPA) GPP SDD (SEPA Direct Debit) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 58
3.3 Outward Request for Cancellation
Use Case Name Outward Request for Cancellation
Use Case Name Outward Request for Cancellation
Actors Initiating party, User, Banks core systems, STEP2 Gateway.
Description This use case defines the outward request for Cancellation from the
Originating Bank via STEP2.
Trigger Either:
• Originating Bank initiates a request for cancellation or
• A request for cancellation is received from the Initiating party by a
pain.007 message
Pre-conditions Request for cancellation initiation is well-formatted and has mandatory
information as defined by EPC pain.007 incoming message
Post-conditions Original collection is cancelled, Request for cancellation is completed
successfully, funds are reversed if were already credited to the Creditor.
IDF file is generated, formatted as per STEP2 specifications, and sent to
STEP2
Basic flow Originating Bank initiates a Request for Cancellation that matches a
collection. The collection is cancelled as a consequence.
Alternate flows • Request for Cancellation is received from Initiating party.
• Reversal is sent (post-settlement)
• Reversal cannot be sent – too late to send out
• Request for Cancellation is rejected by STEP2 by DVF
• Reversal is rejected by STEP2 by DVF/RSF.
• plus existing alternate flows as described in the GPP Business Guide
Mass Payments, for use case Outward Request for Cancellation as
Revocation
3.3.1 Outward Request for Cancellation via STEP2
After the initiating party has transmitted a collection message, such as a pain.008, to the Bank, the
originating bank can initiate a Request for Cancellation of the original collection message either
before or after the settlement of the original payment.
Single Euro Payment Area (SEPA) GPP SDD (SEPA Direct Debit) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 59
3.3.1.1 Outward Request for Cancellation via STEP2 Workflow
Outward Request for Cancellation/Reversal
GPP User
Channel/
Initiating Party
Bank’s Core
Systems
GPP MP Processing STEP2
Gateway
GPP
Integration
GPP Clearing
Service
Execution, Pre/Post-Settlement Determination
Execute
individuals/
bulk
Itemized
Customer leg
Clearing leg
Compliance check
FX Interface
Posting
End
Clearing
processing &
formatting
Request for
Cancellation
Initiation,
display screen
Manual
Input &
Submit
Submit Request
for Cancellation
process
Pre-Settlement?
Yes
Execute as
Pre-
settlement
Execute as
Post-
settlement
No
Complete
(DD)
Recall
Balance Inquiry
Outward
IDF
(camt.056/
pacs.007)
PD >
D+5(T) Reject
3.3.1.1.1 Request for Cancellation Initiation
A GPP user at the originating bank initiates a Request for Cancellation of a previously transmitted
collection message, such as a pacs.003.
A user can initiate a Request for Cancellation if the following conditions exist:
• The credit Method of Payment (MOP) of the original payment message is BOOK.
• The original collection message was transmitted. If the original collection message was not
transmitted, a user can cancel the collection using the cancellation functionality in the GPP user
interface (Cancel button).
• The original collection message was not previously cancelled.
• The original collection was not rejected by the CSM or by the receiving bank.
GPP uses attributes from the original collection message to generate an outward Request for
Cancellation message in the relevant format.
3.3.1.1.2 Manual Input by User
• Request for Cancellation Initiator: The initiator of the Request for Cancellation can be one of the
following:
Single Euro Payment Area (SEPA) GPP SDD (SEPA Direct Debit) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 60
o Bank: The initiating bank’s BIC, which is the default value.
o Customer: The initiating customer’s name.
• Request for Cancellation Reason: The reason for recalling the original collection, as per STEP2
specific reason codes.
Note: The list of available error codes for the Request for Cancellation message is detailed in the
SDD Interface Specification provided by EBA.
3.3.1.1.3 Request for Cancellation Submission Dates
Request for Cancellation is a pre-settlement R-message that can be received until the Interbank
Settlement Date of the direct debit this message requests to cancel.
3.3.1.1.4 Outgoing Input Debit File (IDF)
GPP generates the outgoing file containing camt.056 messages to STEP2 with File header of IDF as
expected by STEP2.
3.3.2 Outward Request for Cancellation from Initiating Party
Processing begins upon the receipt of a mass collection file containing recall messages. GPP
receives the file and starts File processing.
After the file is parsed and validated successfully, GPP generates the individual transactions related
to the validated Payment Information and starts the pre-processing flow.
When identifying that the incoming transaction is a Request for Cancellation, GPP attempts to match
the incoming Request to an original collection. If a match is found, GPP continues to process the
incoming message.
Single Euro Payment Area (SEPA) GPP SDD (SEPA Direct Debit) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 61
3.3.2.1 Outward Request for Cancellation from Initiating Party via STEP2 Workflow
Outward Request for Cancellation – from Initiating Party
GPP User
Channel/
Initiating Party
Bank’s Core
Systems
GPP MP Processing STEP2
Gateway
GPP
Integration
GPP Clearing
Service
Pre/Post-Settlement Determination Pre-processing transactions
Execute
individuals/
bulk
Itemized
Customer leg
Clearing leg
Compliance check
FX Interface
Posting
Outward
IDF
(camt.056/
pacs.007)
End
Clearing
processing &
formatting
Pre-
Settlement?
Execute as
Pre-
settlement
Execute as
Post-
settlement
No
See separate
detailed flow
Incoming
Request for
Cancellation
file
(pain.007)
Receipt file File
processing
Match
found? No
Incoming
Request for
cancellation
process
Reject
Yes
DD
transmitted?
Yes
Yes
Cancelled
(DD)
No
PD >
D+5(T)
Balance Inquiry
Customer
Acknoledge
ment
(pain.002)
Send file
3.3.2.1.1 Outward Request for Cancellation/Reversal from Initiating Party
When matching pain.007 to pain.008, the Creditor ID (which is a criteria for matching an outward R-
message to an outward DD) is the full Creditor ID (including the Business code) as it is assumed that
the Creditor ID that originated the original collection will identify itself when coming to revoke the
collection (including the business code).
EBA STEP2 accepts both Requests for Cancellation and Reversals. The decision whether to create
the outward R-message as a Request for Cancellation (camt.056) or as a Reversal (pacs.007)
depends on whether the R-message is post or pre settlement vs. the original collection’s interbank
settlement date and COT.
3.3.2.1.2 Outgoing Input Debit File (IDF)
GPP generates the outgoing file containing either camt.056 or pacs.007 messages to STEP2 with File
header of IDF as expected by STEP2.
Single Euro Payment Area (SEPA) GPP SDD (SEPA Direct Debit) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 62
3.3.3 Outward Reversal
The initiation of a Reversal is similar to the initiation of Request for Cancellation use case, which can
be either initiated from the user interface or can be received in a file from the Initiating party, with the
exception of following:
• Original collection is expected to be transmitted and in a Final Complete status
• The outward message is formatted as a post-settlement message.
• Reverse of funds of the original credited funds from by the original collection.
Note: The list of available error codes for the Reversal message is detailed in the SDD Interface
Specification provided by EBA.
For details of the flow, see Outward Request for Cancellation via STEP2 Workflow.
3.3.3.1 Interchange Fee (AT-R8)
Subject to the SEPA Regulation, participants may have interchange fee arrangements. This is a fee
paid between the Debtor Bank and the Creditor Bank for direct debit transactions. For R-messages,
an Interchange Fee may be charged as part of the R-transaction, by providing attribute (AT-R8). This
attribute can be present in both CORE and B2B SDD Schemes for Rejects (pacs.002) Return/Refund
(pacs.004) and Reversals (pacs.007). When charges are present, the Reversed Interbank Settlement
Amount (in the R-message) is equal to the Original Interbank Settlement Amount (in the R-message)
+ Charges Amount (in the message).
3.3.3.2 Outgoing Input Debit File (IDF)
GPP generates the outgoing file containing pacs.007 messages to STEP2 with File header of IDF as
expected by STEP2.
3.3.4 Outward Request for Cancellation/Reversal in Manual Queue or Rejected
STEP2 SDD Core & B2B Service allows Request for Cancellation messages to be submitted up to 5
Target Days after the due date of the direct debit.
Single Euro Payment Area (SEPA) GPP SDD (SEPA Direct Debit) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 63
3.3.4.1 Outward Request for Cancellation/Reversal in Manual Queue or Rejected
Outward Request for Cancellation in Manual queue or Rejected
GPP User
Channel/
Initiating
Party
Bank’s Core
Systems
GPP MP Processing Clearing
Gateway
GPP
Integration
GPP
Clearing
Service
File processing
Execution (including
execution of
Individual/bulk)
End
Request for
Cancellation/
Reversal in
Complete
Pass parsing/
validation? No File
Rejected
Yes
Pass validation
Yes
Manual
queue
No
Pre-Processing
Transactions
Pass validation?
Reject/
Manual
queue
No
Incoming
Request for
Cancellation
file (pain.007)
Receipt file
Sub-batch
generation
Pass validation
Yes
No
Customer
Acknoledge
ment
(pain.002)
Send file
Triggers acknowledgement
generation
From file?
Yes
No
Request for
Cancellation
Initiation &Submit
Complete
(DD)
Recall
After the initiating party has transmitted a collection message, as a pain.008, to the Bank, either the
originating bank can initiate a Request for Cancellation of the original collection message, or a GPP
user can initiate such request.
The failure occurs in either one of the steps detailed in the processing of the transaction. For files
received from initiating party, the failure can also occur on the processing of the file.
Once a transaction requires manual handling, it is removed from the Sub batch and processed
individually. As a result of any failure, GPP can generate back to the Customer an acknowledgement
as pain.002 file.
Single Euro Payment Area (SEPA) GPP SDD (SEPA Direct Debit) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 64
For specific failures due to STEP2 regulations, see Outward Request for Cancellation via STEP2
Workflow
3.3.5 Outward Request for Cancellation/Reversal with Incoming DVF
Irrespective of the result of validation, only one Debit Validation File (DVF) is returned per transmitted
Input Debit File (IDF) to the sending Direct Participant indicating the success or failure of the
validation process.
Note: If the Direct Participant exceeds the maximum number of IDFs per Direct Participant per
settlement cycle, enforced by the STEP2 Central System, STEP2 returns a single DVF with error
code R24 when the first file in excess of the limit is processed; additional IDFs received from the DP
in the current settlement cycle are also rejected, but the DVF is not sent.
The process of this DVF file is described in the GPP Business Guide Mass Payments, Incoming ACH-
Rejection use case.
3.3.5.1 Outward Request for Cancellation with Incoming DVF Workflow
Incoming DVF for R-msg
GPP User
Channel/
Initiating
Party
Bank’s Core
Systems
GPP MP Processing STEP2 Gateway
GPP
Integration
GPP Clearing
Service
File Processing
Incoming DVF
(pacs.002S2)
End
Receipt file
File
Rejected
Pass parsing/
validation?
File Matching?
Yes No
No
Match with
original tx
Yes
Manual
queue
No
Link with
original tx
For details, see DVF File and Bulks Matching and Handling.
3.3.6 Outward Reversal with Incoming DVF/RSF
Irrespective of the result of validation, only one Debit Validation File (DVF) is returned per transmitted
Input Debit File (IDF) to the sending Direct Participant indicating the success or failure of the
validation process.
Note: If the Direct Participant exceeds the maximum number of IDFs per Direct Participant per
settlement cycle, enforced by the STEP2 Central System, STEP2 returns a single DVF with error
code R24 when the first file in excess of the limit is processed; additional IDFs received from the DP
in the current settlement cycle are also rejected, but the DVF is not sent.
The process of this DVF file is described in the GPP Business Guide Mass Payments, Incoming ACH-
Rejection use case.
Single Euro Payment Area (SEPA) GPP SDD (SEPA Direct Debit) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 65
Additionally, originating Direct Participants are notified of any cancelled instructions at settlement level
via a Results of Settlement File (RSF). The RSF is delivered to the relevant Direct Participants during
the output phase of the daily cycle.
3.3.6.1 Outward Reversal with Incoming RSF Workflow
Incoming RSF
GPP User
Channel/
Initiating
Party
Bank’s Core
Systems
GPP MP Processing STEP2
Gateway
GPP
Integration
GPP Clearing
Service
File Processing
Incoming RSF
(pacs.002S2)
Receipt file
File
Rejected
Pass parsing/
validation?
Yes
No
Yes
End
Match with
original tx
Yes
Manual
queue
No
Link with
original tx
No Manual
queue
Bulk Matching?
For details, see RSF File and Bulks Matching and Handling (by the Sender).
3.4 Incoming Request for Cancellation
Use Case Name Incoming Request for Cancellation
Actors User, Banks core systems, STEP2 Gateway.
Description This use case defines incoming Request for Cancellation initiated by the
Originating Bank, received from STEP2.
Trigger STEP2 sends a file containing Request(s) for Cancellation.
Pre-conditions Request for cancellation initiation is well-formatted and has mandatory
information as defined by SEPA camt.056 incoming message
Post-conditions Request for cancellation is matched to original DD, collection is cancelled and
the incoming Request for cancellation/Reversal message is completed
successfully. No funds are debited from the debtor
Basic flow GPP receives a file containing Request(s) for Cancellation and is can process
it successfully to complete, matching it with an original collection.
Alternate flows • Request for Cancellation is unmatched.
• Request for Cancellation cannot be processed
3.4.1 Incoming Request for Cancellation from STEP2
GPP receives and processes incoming files that contain transaction messages.
Single Euro Payment Area (SEPA) GPP SDD (SEPA Direct Debit) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 66
3.4.1.1 Incoming Request for Cancellation from STEP2 Workflow
Incoming Request for Cancellation
GPP User
Channel/
Initiating
Party
Bank’s Core
Systems
GPP MP Processing Clearing
Gateway
GPP
Integration
GPP Clearing
Service
Pre-processing
Incoming
DNF
(camt.056)
File processing
End
Receipt file
Including link with an
incoming collection
Service
Release
Match
found?
Sub-batch
generation
Execution &
Execute
individual
No bulking/Outgoing
format
No
Processing
individual
Request for
Cancellation
Yes
Compliance check
Posting
Consolidated
Clearing leg
Incoming
Request for
Cancellation
Processing begins upon the receipt of a mass payments file, which includes Requests for
Cancellation (camt.056 messages). GPP receives the file and starts File processing.
After the file is parsed and validated successfully, GPP generates the individual transactions and
starts the pre-processing flow.
When identifying that the incoming transaction is a Request for Cancellation, GPP attempts to match
the incoming message with the original collection message and then performs validations on the
received Request for Cancellation, as well as on the matched collection.
Some of the validations performed:
• For incoming Request for Cancellation, GPP may check:
o It was not received too late
• For the matched collection, GPP checks:
o The collection was not already cancelled/rejected.
o It is expected that the collection is in Scheduled queue (as the Request for Cancellation is a
pre-settlement message) and not already completed. If the collection is in a different manual
queue or awaiting interface, see Incoming Request for Cancellation Matches Collection in
Manual Queue.
When validations are completed successfully, the original DD is cancelled and the incoming request
message is set to Complete.
Note: Consolidated clearing leg depends on the accounting model performed (whether net or gross).
Single Euro Payment Area (SEPA) GPP SDD (SEPA Direct Debit) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 67
3.4.1.1.1 Incoming Debit Notification File (DNF)
GPP receives incoming file containing camt.056 messages from STEP2 with File header of DNF
(Debit Notification File) as generated by STEP2.
3.4.2 Incoming Request for Cancellation Unmatched
See Incoming Request for Cancellation from STEP2 Workflow.
When the incoming Request for cancellation is unmatched, the message is routed to Service Release
from which the user can review and investigate the message. From this queue, a user can perform
two actions to resolve the unmatched cancelation request/Reversals after investigation:
• Release (Release button): For an unmatched Request for Cancellation, the incoming Request for
Cancellation is routed to Service Complete, and no funds are credited to the debtor.
• Cancel (Cancel button): The incoming Request for Cancellation is routed to Service Cancelled.
The incoming message that is routed to a manual queue, is removed from the sub-batch. The sub-
batch accounting is adjusted outside of the GPP flow.
3.4.3 Incoming Request for Cancellation Matches Collection in Manual Queue
When the incoming Request for cancellation matches a collection in Manual queue (other than
Scheduled) or when it matches a collection that is awaiting answer from interface, the incoming
Request for Cancellation can either be routed to a manual queue for further review and investigation
by a user (subject to business rules setup), or it can continue its regular processing, cancelling the
collection.
3.4.4 Incoming Request for Cancellation Matches a Completed Collection
This rare occurrence may cause GPP to regard the Request for Cancellation as Reversal, or cancel
the incoming Request for Cancellation, subject to business rules setup.
Single Euro Payment Area (SEPA) GPP SDD (SEPA Direct Debit) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 68
3.4.5 Incoming Request for Cancellation Fails Processing
3.4.5.1 Incoming Request for Cancellation Fails Processing Workflow
Incoming Request for Cancellation – fails processing
GPP User
Channel/
Initiating
Party
Bank’s
Core
Systems
GPP MP Processing STEP2
Gateway
GPP
Integration
GPP
Clearing
Service
Execution
(including
execution of
Individual)
End
File
Rejected
Pass validation
Yes
Manual
queue
No
Pre-Processing
Transactions
Pass validation?
Reject/
Manual
queue
No
Sub-batch
generation
Yes
Pass validation
Yes
No
Incoming
DNF
(camt.056)
Receipt
file
File
processing
Pass parsing/
validation?
GPP receives and processes incoming files from STEP2 that contain transaction messages.
Processing begins upon the receipt of a mass payment file, containing camt.056 messages. GPP
receives the file and starts File processing.
The failure occurs in either one of the steps detailed in the processing of the transaction. As a result
of any failure, GPP does not automatically reverse any accounting or statuses, but the incoming
message is sent to a manual queue for user to investigate and take manual action, possibly outside of
GPP.
Additionally, an incoming message can be parked in a wait queue, awaiting answer from an external
interface.
Single Euro Payment Area (SEPA) GPP SDD (SEPA Direct Debit) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 69
3.5 Incoming Reversal
Use Case Name Incoming Reversal
Actors User, Banks core systems, STEP2 Gateway.
Description This use case defines incoming Reversal initiated by the Originating Bank,
received from STEP2.
Trigger STEP2 sends a file containing Reversals.
Pre-conditions Reversal initiation is well-formatted and has mandatory information as defined
by SEPA pacs.007 incoming message
Post-conditions Reversal is matched to original DD, collection is reversed, funds are credited
back to debtor and the Reversal incoming message is completed
successfully.
Basic flow GPP receives a file containing Reversals and is can process it successfully to
complete, matching it with an original collection.
Alternate flows • Reversal is unmatched.
• Reversal cannot be processed.
• Reversal re-activates mandate (for mandate cancelled by previous
collection).
• Incoming RSF for Incoming Reversal
3.5.1 Incoming Reversal from STEP2
GPP receives and processes incoming files that contain transaction messages.
Processing begins upon the receipt of a mass payment file, which includes Requests for Cancellation
(such as a file containing camt.056 messages). GPP receives the file and starts File processing.
After the file is parsed and validated successfully, GPP generates the individual transactions and
starts the pre-processing flow.
When identifying that the incoming transaction is a Reversal, GPP attempts to match the incoming
message with the original collection message and then performs validations on the received Reversal,
as well as on the matched collection.
Single Euro Payment Area (SEPA) GPP SDD (SEPA Direct Debit) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 70
3.5.1.1 Incoming Reversal from STEP2 Workflow
Incoming Reversal
GPP User
Channel/
Initiating
Party
Bank’s Core
Systems
GPP MP Processing STEP2
Gateway
GPP
Integration
GPP Clearing
Service
Pre-processing
Incoming
DNF
(pacs.007)
File processing
End
Receipt file
Including link with an
incoming collection
Service
Release
Match
found?
Sub-batch
generation
Execution &
Execute
individual
No bulking/Outgoing
format
No
Processing
individual
Reversal
Yes
Compliance check
Posting
Consolidated
Clearing leg
Incoming
Reversal
GPP receives and processes incoming files that contain transaction messages.
Processing begins upon the receipt of a mass payment file, which includes Requests for Cancellation
(file containing pacs.007 messages). GPP receives the file and starts File processing.
After the file is parsed and validated successfully, GPP generates the individual transactions and
starts the pre-processing flow.
When identifying that the incoming transaction is a Reversal, GPP attempts to match the incoming
message with the original collection message and then performs validations on the Reversal, as well
as on the matched collection.
Some of the validations performed:
• For incoming Reversal, GPP checks:
o It was not received too late
o Compliance check
• For the matched collection, GPP checks:
o The collection was not already cancelled, rejected or returned
o It is expected that the collection is in Complete
When validations are completed successfully, the original collection is cancelled and the incoming
request message is set to Complete.
Single Euro Payment Area (SEPA) GPP SDD (SEPA Direct Debit) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 71
3.5.1.1.1 Interchange Fee (AT-R8)
Subject to the SEPA Regulation, participants may have interchange fee arrangements. This is a fee
paid between the Debtor Bank and the Creditor Bank for direct debit transactions.
For R-messages, an Interchange Fee may be charged as part of the R-transaction, by providing
attribute (AT-R8). This attribute can be present in both CORE and B2B SDD Schemes for Rejects
(pacs.002) Return/Refund (pacs.004) and Reversals (pacs.007).
When charges are present, the Reversed Interbank Settlement Amount (in the R-message) is equal
to the Original Interbank Settlement Amount (in the R-message) + Charges Amount (in the message).
3.5.1.1.2 Incoming Debit Notification File (DNF)
GPP receives an incoming file containing pacs.007 messages from STEP2 with File header of DNF
(Debit Notification File) as generated by STEP2.
3.5.2 Incoming Reversal Reactivates Mandate
When the collection matched to the incoming Reversal has cancelled the mandate (for example, the
collection’s sequence type was FNAL), the processing of the Reversal triggers a mandate re-
activation use case.
3.5.3 Incoming Reversal Unmatched
See Incoming Reversal from STEP2 Workflow.
When the incoming Reversal is unmatched, the message is routed to Service Release from which the
user can review and investigate the message. From this queue, a user has these actions to resolve
the unmatched Reversals after investigation:
• Release (Release button): The incoming Reversal continue its processing as an incoming CT.
• Cancel (Cancel button): The incoming Reversal is routed to Service Cancelled, and no funds are
credited to the end customer.
Incoming message that is routed to manual queue, is removed from the sub-batch. The sub-batch
accounting is adjusted outside of the GPP flow.
Single Euro Payment Area (SEPA) GPP SDD (SEPA Direct Debit) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 72
3.5.4 Incoming Reversal Fails Processing
3.5.4.1 Incoming Reversal Fails Processing Workflow
Incoming Reversal – fails processing
GPP User
Channel/
Initiating
Party
Bank’s
Core
Systems
GPP MP Processing STEP2
Gateway
GPP
Integration
GPP
Clearing
Service
Execution
(including
execution of
Individual)
End
File
Rejected
Pass validation
Yes
Manual
queue
No
Pre-Processing
Transactions
Pass validation?
Reject/
Manual
queue
No
Sub-batch
generation
Yes
Pass validation
Yes
No
Incoming
DNF
(pacs.007)
Receipt
file
File
processing
Pass parsing/
validation?
GPP receives and processes incoming files from STEP2 that contain transaction messages.
Processing begins upon the receipt of a mass payment file, containing pacs.007 messages. GPP
receives the file and starts File processing.
The failure occurs in either one of the steps detailed in the processing of the transaction. As a result
of any failure, GPP does not automatically reverse any accounting or statuses, but the incoming
message is sent to a manual queue for the user to investigate and take manual action, possibly
outside of GPP.
Additionally, an incoming message can be parked in a wait queue, awaiting answer from an external
interface.
Single Euro Payment Area (SEPA) GPP SDD (SEPA Direct Debit) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 73
3.5.5 Incoming Reversal with Incoming RSF
Receiving Direct Participants are notified of any cancelled instructions at settlement level via a
Results of Settlement File (RSF). The RSF is delivered to the relevant Direct Participants during the
output phase of the daily cycle.
3.5.5.1 Outward Reversal with Incoming RSF Workflow
Incoming RSF
GPP User
Channel/
Initiating
Party
Bank’s Core
Systems
GPP MP Processing STEP2
Gateway
GPP
Integration
GPP Clearing
Service
File Processing
Incoming RSF
(pacs.002S2)
Receipt file
File
Rejected
Pass parsing/
validation?
Yes
No
Yes
End
Match with
original tx
Yes
Manual
queue
No
Link with
original tx
No Manual
queue
Bulk Matching?
For details, see RSF File and Bulks matching and handling (by the receiver).
3.6 Outward Reject
Use Case Name Outward Reject
Actors User, Banks core systems, STEP2 Gateway.
Description This use case defines the outward Reject sent from the Receiving Bank. The
reject message indicates the receiving bank’s rejection of the originating
bank’s collection (and does not include the return of the funds).
Trigger User manually rejects the collection.
Pre-conditions Collection is received, and is awaiting settlement
Post-conditions Collection is rejected.
IDF file is generated, formatted as per STEP2 specifications, and sent to
STEP2
Basic flow User rejects the collection
Alternate flow • Reject is rejected by STEP2 by DVF
• plus existing alternate flows as described in the GPP Business Guide
Mass Payments, for use case Outward Reject, Automatically Generated
Single Euro Payment Area (SEPA) GPP SDD (SEPA Direct Debit) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 74
3.6.1 Outward Reject via STEP2
GPP user initiates the outgoing reject flow using the GPP user interface.
A user in the receiving bank searches for and navigates to an original pre-settled collection message
in a manual queue, and initiates the rejection by clicking the Reject button.
3.6.1.1 Outward Reject via STEP2 Workflow
Outward Reject, pre-settlement
GPP User
Channel/
Initiating Party
Bank’s Core
Systems
GPP MP Processing STEP2
Gateway
GPP
Integration
GPP Clearing
Service
Execute
individuals/
bulk
Outward
IDF
(pacs.002)
End
DD is Rejected
Clearing
processing &
formatting
Reject
Initiation,
display Return-
screen
Submit Reject
process
Manual
queue
Reject
Execution
Manual
Input &
Submit
Compliance check
Posting
Clearing leg
Incoming DD
fails processing
UC
Generate
Reject flow
3.6.1.1.1 Manual Input by User
• Reject Initiator: The initiator of the Reject can be one of the following:
o Bank: The initiating bank’s BIC, which is the default value.
o Customer: The debtor customer’s name.
• Reject Reason: The reason for rejecting the collection, as per STEP2 specific reason codes.
Note: The list of available error codes for the Reject message is detailed in the SDD Interface
Specification provided by EBA.
3.6.1.1.2 Interchange Fee (AT-R8)
Subject to the SEPA Regulation, participants may have interchange fee arrangements. This is a fee
paid between the Debtor Bank and the Creditor Bank for direct debit transactions.
For R-messages, an Interchange Fee may be charged as part of the R-transaction, by providing
attribute (AT-R8). This attribute can be present in both CORE and B2B SDD Schemes for Rejects
(pacs.002) Return/Refund (pacs.004) and Reversals (pacs.007).
Single Euro Payment Area (SEPA) GPP SDD (SEPA Direct Debit) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 75
3.6.1.1.3 Outgoing Input Debit File (IDF)
GPP generates the outgoing file containing pacs.002 messages to STEP2 with File header of IDF as
expected by STEP2.
3.6.2 Outward Reject with Incoming DVF
Irrespective of the result of validation, only one Debit Validation File (DVF) is returned per transmitted
Input Debit File (IDF) to the sending Direct Participant indicating the success or failure of the
validation process.
Note: If the Direct Participant exceeds the maximum number of IDFs per Direct Participant per
settlement cycle, enforced by the STEP2 Central System, STEP2 returns a single DVF with error
code R24 when the first file in excess of the limit is processed; additional IDFs received from the DP
in the current settlement cycle are also rejected, but the DVF is not sent.
The process of this DVF file is described in the GPP Business Guide Mass Payments, Incoming ACH-
Rejection use case.
3.6.2.1 Outward Reject with Incoming DVF Workflow
Incoming DVF for R-msg
GPP User
Channel/
Initiating
Party
Bank’s Core
Systems
GPP MP Processing STEP2 Gateway
GPP
Integration
GPP Clearing
Service
File Processing
Incoming DVF
(pacs.002S2)
End
Receipt file
File
Rejected
Pass parsing/
validation?
File Matching?
Yes No
No
Match with
original tx
Yes
Manual
queue
No
Link with
original tx
For details, see DVF File and Bulks Matching and Handling.
Single Euro Payment Area (SEPA) GPP SDD (SEPA Direct Debit) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 76
3.7 Outward Return/Refund
Use Case Name Outward Return/Refund
Actors User, Banks core systems, STEP2 Gateway.
Description This use case defines the outward Return/Refund sent from the Receiving
Bank. This message indicates the receiving bank’s is reversing funds,
crediting back the debtor for the amount of the original collection (potentially
including compensation and charges).
Trigger User manually returns the collection.
Pre-conditions Collection is either during processing or already successfully completed.
Post-conditions Collection is returned, funds are reversed (if were already debited from the
customer),
IDF file is generated, formatted as per STEP2 specifications, and sent to
STEP2
Basic flow User returns/refunds the collection
Alternate flow • B2B Return (has a shorted cycle)
• B2B Refund is not allowed
• Return/Refund re-activates mandate (for mandate cancelled by previous
collection).
• plus existing alternate flows as described in the GPP Business Guide
Mass Payments, for use case Outward Return/Refund, Automatically
Generated.
3.7.1 Outward (Core) Return/Refund via STEP2
GPP user initiates the outgoing return flow using the GPP user interface.
A user in the receiving bank searches for and navigates to an original settled collection message in
Complete queue (or a collection which still resides in a manual queue after its interbank settlement
date), and initiates the return by clicking the Return button.
Single Euro Payment Area (SEPA) GPP SDD (SEPA Direct Debit) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 77
3.7.1.1 Outward Return/Refund via STEP2 Workflow
Outward Return
GPP User
Channel/
Initiating Party
Bank’s Core
Systems
GPP MP Processing STEP2
Gateway
GPP
Integration
GPP Clearing
Service
Execute
individuals/
bulk
Outward
IDF
(pacs.004)
End
DD in Returned
Clearing
processing &
formatting
Return
Initiation,
display Return-
screen
Submit Return
process
Manual
queue (or
Complete)
Return
Execution
Manual
Input &
Submit
Compliance check
Balance Inquiry
FX Interface
Posting
Itemized
Customer leg
Clearing leg
Incoming DD
fails processing
UC
Generate
Return flow
On settlement
date/after
Reject/
Manual
queue
PD
<
D+2(T)
Scheme (Core/
B2B)
Return/
Refund
Return/
Refund
B2B
Core
Refund
not
allowed
PD
<
D+5(T)
Return
No
Yes
Return
Yes
No
Authorized
PD
< D+
440(C)
PD
< D+
47(T)
Yes No
No
No Yes
Yes
3.7.1.1.1 Manual Input by User
After GPP generates an outward return message, using attributes from the original collection, the
GPP user must review the message and enter mandatory user-determined fields before submitting
the message:
• Initiator: The initiator of the return action, can be one of the following:
o Bank: The initiating bank’s BIC, which is the default value (the message will be regarded as
Return)
o Customer: The initiating customer’s name (the message will be regarded as a Refund).
• Reason: The reason for returning the collection message, as per STEP2 specific reason codes.
• Compensation: this is an optional field, allowed only for Refunds (initiated by Customer). For more
details, see Compensation (AT– R6)
Note: The list of available error codes for the Return/Refund message is detailed in the SDD Interface
Specification provided by EBA.
Single Euro Payment Area (SEPA) GPP SDD (SEPA Direct Debit) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 78
Before transmitting the message, GPP verifies that the return/refund is within the allowed time limit,
further details in section Return/Refund Submission Date. One of the following occurs:
• If the return occurs within the allowed time limit, GPP continues processing.
• If the return occurs after the allowed time limit, GPP generates an error message, routes the
return message to the Rejected queue, and stops processing the return.
3.7.1.1.2 Return/Refund Submission Date
The latest date on which a Return (initiated by Bank) can be submitted by the Debtor Agent after the
after the Interbank Settlement date (of the direct debit to be returned) is:
• For Core scheme – 5 TARGET days
• For B2B scheme – 2 TARGET days
The latest date which a Refund (initiated by customer) can be submitted by the Debtor Agent after the
after the Interbank Settlement date (of the direct debit to be returned) is:
• For an authorized Core Refund – 47 TARGET days
• For a non-authorized Core Refund – 440 calendar days
3.7.1.1.3 Interchange Fee (AT-R8)
Subject to the SEPA Regulation, participants may have interchange fee arrangements. This is a fee
paid between the Debtor Bank and the Creditor Bank for direct debit transactions. For R-messages,
an Interchange Fee may be charged as part of the R-transaction, by providing attribute (AT-R8). This
attribute can be present in both CORE and B2B SDD Schemes for Rejects (pacs.002) Return/Refund
(pacs.004) and Reversals (pacs.007).
For Refunds and Returns, the Returned Interbank Settlement Amount (in the R-message) is equal to
the Original Interbank Settlement Amount (in the R-message) + the Compensation Amount (in the R-
message) + Charges Amount (in the R-message).
3.7.1.1.4 Compensation (AT– R6)
The Debtor Bank has the right to receive compensation, called the Refund compensation, from the
Creditor Bank for the related interest loss incurred by the Debtor Bank. Compensation amount is
additional to the original interbank amount and it can be either credited to the Debtor bank or to a
debtor account. This amount is passed in the DD transaction using a dedicated XML element field.
The compensation amount is validated using EONIA rates. This is achieved by setting Interest Type
for EONIA in the Interest Types profile and the relevant rates for each month in the Interest Rates
profile.
On the debtor bank side, the compensation is calculated based on the relevant interest type, interest
rate, number of holding calendar days and the collection amount.
3.7.1.1.5 Outgoing Input Debit File (IDF)
GPP generates the outgoing file containing pacs.004 messages to STEP2 with File header of IDF as
expected by STEP2.
3.7.2 Outward B2B Return
For B2B scheme, a Return has a shorter cycle, i.e. the latest date on which a Return can be
submitted by the Debtor Agent is 2 TARGET days after the due date.
Single Euro Payment Area (SEPA) GPP SDD (SEPA Direct Debit) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 79
3.7.3 Outward B2B Refund Not Allowed
GPP prohibits the generation of outward Refund for the B2B scheme.
An exception handling of post settlement R-messages originated by Customer (Debtor) occurs on
Maturity Date (D day). EPC allows Refusals to be generated on Maturity Date (D day). If the Refusal
is processed on D day after cutoff (i.e. post-settlement), GPP regards it as a Return, therefore
clearing the Name of the Debtor from the customer originating this R-message and having the BIC of
the local office in the Party originating this R-message.
3.7.4 Outward Return/Refund Reactivates Mandate
When the collection matched to the outward Return/Refund has cancelled the mandate (for example,
the collection’s sequence type was FNAL), the processing of the Return/Refund triggers a mandate
reactivation Use Case.
3.7.5 Outward Return/Refund with Incoming RSF
Originating Direct Participants are notified of any cancelled instructions at settlement level via a
Results of Settlement File (RSF). The RSF is delivered to the relevant Direct Participants during the
output phase of the daily cycle.
3.7.5.1 Outward Return/Refund with Incoming RSF Workflow
Incoming RSF
GPP User
Channel/
Initiating
Party
Bank’s Core
Systems
GPP MP Processing STEP2
Gateway
GPP
Integration
GPP Clearing
Service
File Processing
Incoming RSF
(pacs.002S2)
Receipt file
File
Rejected
Pass parsing/
validation?
Yes
No
Yes
End
Match with
original tx
Yes
Manual
queue
No
Link with
original tx
No Manual
queue
Bulk Matching?
For details, see RSF File and Bulks Matching and Handling (by the Sender).
Single Euro Payment Area (SEPA) GPP SDD (SEPA Direct Debit) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 80
3.8 Incoming Reject
Use Case ID SDD.8
Use Case Name Incoming Reject
Actors User, Banks core systems, STEP2 Gateway.
Description This use case defines the incoming Reject sent from the Receiving Bank. The
reject message indicates the receiving bank’s rejection of the originating
bank’s collection (and does not includes the return of the funds).
Trigger STEP2 sends a file containing Reject(s).
Pre-conditions Collection was sent and is awaiting settlement
Post-conditions Collection is rejected, funds are either not credited to Creditor, or funds are
debited if previously credited (depending on accounting model and time of
processing)
Basic flow Reject message rejects the collection
Alternate flow Existing alternate flows as described in the GPP Business Guide Mass
Payments, for use case Incoming Reject.
3.8.1 Incoming Reject from STEP2
GPP receives and processes incoming files that contain transaction messages.
Processing begins upon the receipt of a mass payment file, which includes Rejects (such as a file
containing pacs.002 messages). GPP receives the file and starts File processing.
After the file is parsed and validated successfully, GPP generates the individual transactions and
starts the pre-processing flow.
When identifying that the incoming transaction as a Reject, GPP attempts to match the incoming
message with the original collection message and then performs validations on the received Reject,
as well as on the matched collection.
This use case is based on the Mass Payments Incoming Reject use case but with these STEP2
additions:
• Interchange Fee (AT-R8)
• Incoming Debit Notification File (DNF)
Single Euro Payment Area (SEPA) GPP SDD (SEPA Direct Debit) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 81
3.8.1.1 Incoming Reject from STEP2 Workflow
Incoming Reject
GPP User
Channel/
Initiating
Party
Bank’s Core
Systems
GPP MP Processing STEP2
Gateway
GPP
Integration
GPP Clearing
Service
Pre-processing
Incoming DNF
(pacs.002)
File processing
End
Receipt file
Including link with a
previously sent collection
ROFi
Match
found?
Sub-batch
generation
Execution &
Execute
individual
No bulking/Outgoing
format
No
Processing
individual
Reject Compliance check
FX Interface
Posting
Consolidated
Clearing leg
Itemized
Customer leg
Balance Inquiry
3.8.1.1.1 Interchange Fee (AT-R8)
Subject to the SEPA Regulation, participants may have interchange fee arrangements. This is a fee
paid between the Debtor Bank and the Creditor Bank for direct debit transactions.
For R-messages, an Interchange Fee may be charged as part of the R-transaction, by providing
attribute (AT-R8). This attribute can be present in both CORE and B2B SDD Schemes for Rejects
(pacs.002) Return/Refund (pacs.004) and Reversals (pacs.007).
3.8.1.1.2 Incoming Debit Notification File (DNF)
GPP receives incoming file containing pacs.002 messages from STEP2 with File header of DNF
(Debit Notification File) as generated by STEP2.
Single Euro Payment Area (SEPA) GPP SDD (SEPA Direct Debit) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 82
3.9 Incoming Return/Refund
Use Case Name Incoming Return/Refund
Actors User, Banks core systems, STEP2 Gateway.
Description This use case defines the incoming Return/Refund sent from the Receiving
Bank. This message indicates the receiving bank’s is reversing the funds,
crediting back the debtor for the amount of the original collection (potentially
including compensation).
Trigger The clearing sends a file containing Return(s)/Refund(s).
Pre-conditions Collection was sent and settled
Post-conditions Collection is returned, funds are reversed against the Creditor
Basic flow The Return/Refund message sets the collection’s status to Return
Alternate flow Existing alternate flows as described in the GPP Business Guide Mass
Payments, for use case Incoming Return/Refund.
3.9.1 Incoming Return/Refund from STEP2
GPP receives and processes incoming files that contain transaction messages.
Processing begins upon the receipt of a mass payment file, which includes Returns/Refunds (such as
a file containing pacs.004 messages). GPP receives the file and starts File processing.
After the file is parsed and validated successfully, GPP generates the individual transactions and
starts the pre-processing flow.
When identifying that the incoming transaction is a Return/Refund, GPP attempts to match the
incoming message with the original collection message and then performs validations on the received
Return/Refund, as well as on the matched collection.
This use case is based on the Mass Payments Incoming Return/Refund use case but with these
STEP2 additions:
• Interchange Fee (AT-R8)
• Compensation (AT– R6)
• Incoming Debit Notification File (DNF)
Single Euro Payment Area (SEPA) GPP SDD (SEPA Direct Debit) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 83
3.9.1.1 Incoming Return/Refund from STEP2 Workflow
Incoming Return/Refund
GPP User
Channel/
Initiating
Party
Bank’s Core
Systems
GPP MP Processing STEP2
Gateway
GPP
Integration
GPP Clearing
Service
Pre-processing
Incoming DNF
(pacs.004)
File processing
End
Receipt file
Including link with a
previously sent collection
ROFi
Match
found?
Sub-batch
generation
Execution &
Execute
individual
No bulking/Outgoing
format
No
Processing
individual
Return Compliance check
FX Interface
Posting
Consolidated
Clearing leg
Itemized
Customer leg
Balance Inquiry
3.9.1.1.1 Interchange Fee (AT-R8)
Subject to the SEPA Regulation, participants may have interchange fee arrangements. This is a fee
paid between the Debtor Bank and the Creditor Bank for direct debit transactions.
For R-messages, an Interchange Fee may be charged as part of the R-transaction, by providing
attribute (AT-R8). This attribute can be present in both CORE and B2B SDD Schemes for Rejects
(pacs.002) Return/Refund (pacs.004) and Reversals (pacs.007).
For Refunds and Returns, the Returned Interbank Settlement Amount (in the R-message) is equal to
the Original Interbank Settlement Amount (in the R-message) + the Compensation Amount (in the R-
message) + Charges Amount (in the R-message).
3.9.1.1.2 Compensation (AT– R6)
The Debtor Bank has the right to receive compensation, called the Refund compensation, from the
Creditor Bank for the related interest loss incurred by the Debtor Bank. Compensation amount is
additional to the original interbank amount and it can be either credited to the Debtor bank or to a
debtor account. This amount is passed in the DD transaction using a dedicated XML element field.
The compensation amount is validated using EONIA rates. This is achieved by setting Interest Type
for EONIA in the Interest Types profile and the relevant rates for each month in the Interest Rates
profile.
Single Euro Payment Area (SEPA) GPP SDD (SEPA Direct Debit) Use Cases
Global PAYplus Version 4.6.6 Business Guide Page 84
On the creditor bank side:
• If the amount is not within the allowed tolerance range, the incoming R-message is sent to a
manual queue where a user may either approve the amount or reject the R-message.
• GPP allows the creditor to specify an account to be used for compensation postings
3.9.1.1.3 Incoming Debit Notification File (DNF)
GPP receives an incoming file containing pacs.002 messages from STEP2 with File header of DNF
(Debit Notification File) as generated by STEP2.
3.9.2 Incoming Return/Refund with Incoming RSF
Receiving Direct Participants are notified of any cancelled instructions at settlement level via a
Results of Settlement File (RSF). The RSF is delivered to the relevant Direct Participants during the
output phase of the daily cycle.
3.9.2.1 Outward Reversal with Incoming RSF Workflow
Incoming RSF
GPP User
Channel/
Initiating
Party
Bank’s Core
Systems
GPP MP Processing STEP2
Gateway
GPP
Integration
GPP Clearing
Service
File Processing
Incoming RSF
(pacs.002S2)
Receipt file
File
Rejected
Pass parsing/
validation?
Yes
No
Yes
End
Match with
original tx
Yes
Manual
queue
No
Link with
original tx
No Manual
queue
Bulk Matching?
For details, see RSF File and Bulks matching and handling (by the receiver).
Single Euro Payment Area (SEPA) Processing
Global PAYplus Version 4.6.6 Business Guide Page 85
4 Processing
SEPA payments processing is based on the Mass Payments process which includes the following
processes:
• Incoming and Outgoing File: GPP processes incoming and outgoing credit and debit message
files and R-messages.
• Credit Transfer Recall - Debtor Bank: The GPP process begins when an originating (debtor) bank
receives a file containing groups of recall requests, such as a pain.007 messages, from an
initiating bank customer.
• Validation and Cancellation File Handling: GPP processes incoming validation and cancellation
files.
These processes, including the workflows, are details in the GPP Business Guide Mass Payments.
The specific services and functional components within the general Mass Payments flow, that are
relevant to SCT and SDD schemes requirements, and are on top of the existing validations and
processing performed on Mass Payments messages, are detailed in this business guide.
4.1 SEPA – File Handling
4.1.1 File Validation
GPP validates the file integrity and content for example, header, trailer, field lengths
For each file received, GPP performs a duplicate check against previously received files.
The validations are performed as per the specifications and the parameters defined as identification
and matching criteria of SEPA files.
4.1.2 Incoming Files from STEP2
Processing report files that arrived from STEP2 (DVF/CVF, RSF and CDF/CCF) may cause
performance issues due to the need to process a large quantity of additional transactions. In addition,
in certain cases users may decide not to process such a file and, instead, resend the original file (this
applies only to DVF/CVF).
For these reasons, it is possible to determine whether to immediately process a file or to wait for user
decision based on business rules to route the file.
4.2 SEPA General – Individual Handling
4.2.1 Date Validation
Value date rules and calendars allow GPP to ensure the value/settlement date is correct and
determine the correct processing date. Transactions received from originating customers can be sent
to STEP2 according to flexible parameters.
Different rules can be defined for transactions as per their scheme (SDD Core/B2B and SCT) and
also based on the transaction sequence type. For example, a first-time Core SDD message can be
sent to STEP2 14 days prior to settlement or can be warehoused on GPP until the last possible day,
which is five days prior to settlement.
Single Euro Payment Area (SEPA) Processing
Global PAYplus Version 4.6.6 Business Guide Page 86
4.2.2 Warehousing
GPP holds transactions in the Scheduled queue when the issuing of the payments or collections does
not need to be done on the receipt date, or if the value/settlement date for an inward transaction is in
the future.
GPP allows a flexible setup of required timelines for credit transfers, direct debits and R-messages
per scheme (MOP).
4.2.3 End of Batch Reporting
After all of the transactions in a customer file have been pre-processed, a file containing the status
messages can be generated and sent back to the channel or transformation layer for reformatting and
delivery to the originating customer. This service is provided for customers who are set up for this
type of advising.
This data file is in pain.002 format and provides information about each transaction that was rejected
during pre-processing.
Single Euro Payment Area (SEPA) Appendix A: Glossary
Global PAYplus Version 4.6.6 Business Guide Page 87
Appendix A: Glossary
This table provides definitions of terms used in this document.
Term Description
GPP Global PAYplus
SEPA Single Euro Payments Area. A European financial infrastructure that creates a
zone in which Euro payments (or any other agreed upon currency) are
considered domestic.
MT Message Type

Navigation menu