Business Guide GPP SEPA

User Manual: Pdf

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

Download
Open PDF In Browser	View PDF

Global PAYplus Version 4.6.6
Single Euro Payment Area (SEPA)
Business Guide

Single Euro Payment Area (SEPA)

Version Control

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

Global PAYplus Version 4.6.6 Business Guide

Page 2

Single Euro Payment Area (SEPA)

Version Control

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

•

2.0

Apr 2017

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

Added Stops and Permits Validations section within the SEPA Specific
Validations section

Global PAYplus Version 4.6.6 Business Guide

Page 3

Single Euro Payment Area (SEPA)

Table of Contents

Table of Contents
1

INTRODUCTION TO SEPA ......................................................................................................... 7
1.1
1.2
1.3
1.3.1
1.3.2
1.3.3
1.4
1.4.1
1.4.2
1.5
1.5.1
1.5.2
1.5.3

European Payments Council (EPC)...................................................................................... 7
Euro Banking Association (EBA) – STEP2 ........................................................................... 7
SEPA Message Types .......................................................................................................... 8
Supported in GPP ............................................................................................................. 8
Customer-to-Bank Messages .......................................................................................... 10
Inter-Bank Messages ...................................................................................................... 10
SEPA File Types ................................................................................................................. 10
SEPA Direct Debit Files .................................................................................................. 10
SEPA Credit Transfer Files ............................................................................................. 11
SEPA Processing ................................................................................................................ 12
SEPA Credit Transfer Files and Messages Workflow ..................................................... 12
SEPA Direct Debit Files and Messages Workflow – Flow Diagram ................................ 13
Files and Messages Process .......................................................................................... 14

GPP SEPA CREDIT TRANSFER (SCT) USE CASES ............................................................. 21
2.1
2.1.1
2.1.2
2.1.3
2.1.4
2.1.5
2.2
2.2.1
2.3
2.3.1
2.3.2
2.4
2.4.1
2.4.2
2.4.3
2.5
2.5.1
2.5.2
2.5.3
2.6
2.6.1
2.6.2
2.6.3
2.6.4
2.7
2.7.1
2.7.2
2.7.3
2.8
2.8.1

Outward SEPA Credit Transfer ........................................................................................... 21
Outward SEPA Credit Transfer via STEP2 ..................................................................... 22
Outward SEPA Credit Transfer is Warehoused .............................................................. 24
Outward SEPA Credit Transfer Fails Processing ............................................................ 24
Outward SEPA Credit Transfer with Incoming CVF ........................................................ 25
Outward SEPA Credit Transfer with Incoming CCF ........................................................ 26
Incoming SEPA Credit Transfer .......................................................................................... 27
Incoming SEPA Credit Transfer from STEP2 ................................................................. 28
Outward Payment Cancellation Request (PCR) ................................................................. 29
Outward PCR via STEP2 ................................................................................................ 29
Outward PCR with Incoming CVF ................................................................................... 32
Incoming Recall................................................................................................................... 33
Incoming Recall from STEP2 .......................................................................................... 33
Incoming Recall Unmatched ........................................................................................... 34
Original Payment Unqualified for Recall ......................................................................... 34
Outward Recall Reject ........................................................................................................ 35
Manual Generation of SEPA Recall-Reject ..................................................................... 35
Automatic generation of SEPA Recall Reject ................................................................. 36
Outward Recall Reject with Incoming CVF ..................................................................... 37
Outward Return ................................................................................................................... 37
Manual Generation of SEPA Recall Return .................................................................... 38
Manual Generation of SEPA Return ............................................................................... 40
Outward Return with Incoming CVF ................................................................................ 41
Outward Return with Incoming CCF ............................................................................... 42
Incoming Recall Reject ....................................................................................................... 42
Incoming Recall Reject from STEP2 ............................................................................... 42
Incoming Recall Reject Unmatched ................................................................................ 43
Incoming Recall Reject Matched a Pre-settlement Recall .............................................. 43
Incoming Return .................................................................................................................. 44
Incoming Return from STEP2 ......................................................................................... 44

Global PAYplus Version 4.6.6 Business Guide

Page 4

Single Euro Payment Area (SEPA)

GPP SDD (SEPA DIRECT DEBIT) USE CASES...................................................................... 46
3.1
3.1.1
3.1.2
3.1.3
3.1.4
3.1.5
3.2
3.2.1
3.2.2
3.3
3.3.1
3.3.2
3.3.3
3.3.4
3.3.5
3.3.6
3.4
3.4.1
3.4.2
3.4.3
3.4.4
3.4.5
3.5
3.5.1
3.5.2
3.5.3
3.5.4
3.5.5
3.6
3.6.1
3.6.2
3.7
3.7.1
3.7.2
3.7.3
3.7.4
3.7.5
3.8
3.8.1
3.9
3.9.1
3.9.2

Table of Contents

Outward SDD ...................................................................................................................... 46
Outward SDD via STEP2 ................................................................................................ 46
Outward SDD is Warehoused ......................................................................................... 49
Outward SDD Fails Processing ....................................................................................... 49
Outward SDD with Incoming DVF ................................................................................... 49
Outward SDD with Incoming RSF ................................................................................... 51
Incoming SDD ..................................................................................................................... 52
Incoming SDD from STEP2............................................................................................. 52
Incoming Result of Settlement File (RSF) ....................................................................... 56
Outward Request for Cancellation ...................................................................................... 58
Outward Request for Cancellation via STEP2 ................................................................ 58
Outward Request for Cancellation from Initiating Party .................................................. 60
Outward Reversal ............................................................................................................ 62
Outward Request for Cancellation/Reversal in Manual Queue or Rejected ................... 62
Outward Request for Cancellation/Reversal with Incoming DVF .................................... 64
Outward Reversal with Incoming DVF/RSF .................................................................... 64
Incoming Request for Cancellation ..................................................................................... 65
Incoming Request for Cancellation from STEP2............................................................. 65
Incoming Request for Cancellation Unmatched .............................................................. 67
Incoming Request for Cancellation Matches Collection in Manual Queue ..................... 67
Incoming Request for Cancellation Matches a Completed Collection ............................ 67
Incoming Request for Cancellation Fails Processing ...................................................... 68
Incoming Reversal .............................................................................................................. 69
Incoming Reversal from STEP2 ...................................................................................... 69
Incoming Reversal Reactivates Mandate ........................................................................ 71
Incoming Reversal Unmatched ....................................................................................... 71
Incoming Reversal Fails Processing ............................................................................... 72
Incoming Reversal with Incoming RSF ........................................................................... 73
Outward Reject ................................................................................................................... 73
Outward Reject via STEP2 .............................................................................................. 74
Outward Reject with Incoming DVF ................................................................................ 75
Outward Return/Refund ...................................................................................................... 76
Outward (Core) Return/Refund via STEP2 ..................................................................... 76
Outward B2B Return ....................................................................................................... 78
Outward B2B Refund Not Allowed .................................................................................. 79
Outward Return/Refund Reactivates Mandate ............................................................... 79
Outward Return/Refund with Incoming RSF ................................................................... 79
Incoming Reject .................................................................................................................. 80
Incoming Reject from STEP2 .......................................................................................... 80
Incoming Return/Refund ..................................................................................................... 82
Incoming Return/Refund from STEP2 ............................................................................. 82
Incoming Return/Refund with Incoming RSF .................................................................. 84

PROCESSING ........................................................................................................................... 85
4.1
SEPA – File Handling ......................................................................................................... 85
4.1.1
File Validation .................................................................................................................. 85
4.1.2
Incoming Files from STEP2............................................................................................. 85

Global PAYplus Version 4.6.6 Business Guide

Page 5

Single Euro Payment Area (SEPA)

Table of Contents

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

Global PAYplus Version 4.6.6 Business Guide

Page 6

Single Euro Payment Area (SEPA)

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-tobank 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

Global PAYplus Version 4.6.6 Business Guide

Page 7

Single Euro Payment Area (SEPA)

Introduction to SEPA

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 Rmessages, per scheme.
o

CORE
 11:00: COT for DD R-messages
 16:00: COT for DD

B2B
 12:00: COT for DD R-message
 15:00: COT for DD

•

1.3

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.

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

Global PAYplus Version 4.6.6 Business Guide

Page 8

Single Euro Payment Area (SEPA)

Message Type

Introduction to SEPA

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:

camt.056

•

the corrective action undertaken by the case assignee

•

information on the return where applicable

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).

Global PAYplus Version 4.6.6 Business Guide

Page 9

Single Euro Payment Area (SEPA)

1.3.2

Introduction to SEPA

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 Rmessages 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).

Global PAYplus Version 4.6.6 Business Guide

Page 10

Single Euro Payment Area (SEPA)

1.4.2

Introduction to SEPA

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.

Global PAYplus Version 4.6.6 Business Guide

Page 11

Single Euro Payment Area (SEPA)

1.5

Introduction to SEPA

SEPA Processing

1.5.1

SEPA Credit Transfer Files and Messages Workflow

Debtor

Debtor bank

csm

PAIN.001
PAIN.001
PAIN.001
PAIN.001
PAIN.001
PAIN.001
PAIN.001
PAIN.001
PAIN.001
PAIN.001
PAIN.001

PACS.008
PACS.008
PACS.008
PACS.008
PACS.008
PACS.008
PACS.008
PACS.008
PACS.008
PACS.008

PACS.008
PACS.008
PACS.008
PACS.008
PACS.008
PACS.008
PACS.008
PACS.008
PACS.008

Match

PAIN.002

Match

ICF

Creditor bank

GPP Validation
failure

PACS.002s2

CVF*

CAMT.056
CAMT.056

ICF

PACS.002s2

CVF*

PACS.002s2

CCF*

Validation
failure

CAMT.056

Match

Match
Match

Validation
failure

Settlement cycle 1

Settlement
failure

SCF
Manually
Generated
Recall
CAMT.056
CAMT.056

ICF

CAMT.056
CAMT.056

CAMT.029
PACS.004
PACS.004
PACS.004
PACS.004

Match

SCF

ICF

PACS.008
PACS.008
PACS.008
PACS.008
PACS.008
PACS.008
PACS.008
CAMT.056
CAMT.056

CAMT.029
PACS.004
PACS.004
PACS.004
PACS.004

Message
returned
Message
returned

Match
Negative
answer

Message
returned

Positive
answer
Message
returned

Match
Match

Validation
failure

Settlement
failure

CAMT.029
PACS.004
PACS.004

CVF*

PACS.002s2

CCF*

PACS.002s2

Settlement cycle 2

SCF

* 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

Global PAYplus Version 4.6.6 Business Guide

Page 12

Single Euro Payment Area (SEPA)

1.5.2

Introduction to SEPA

SEPA Direct Debit Files and Messages Workflow – Flow Diagram
Creditor

Creditor bank

PAIN.008
PAIN.008
PAIN.008
PAIN.008
PAIN.008
PAIN.008
PAIN.008
PAIN.008
PAIN.008
PAIN.008

PACS.003
PACS.003
PACS.003
PACS.003
PACS.003
PACS.003
PACS.003
PACS.003
PACS.003
Match

Match

PAIN.002

Match
Match

Match

Customer
Revokes
Collection

PAIN.007

csm

IDF

Debtor bank

DNF

GPP Validation
failure

PACS.003
PACS.003
PACS.003
PACS.003
PACS.003
PACS.003
PACS.003
PACS.003

Message
rejected
by bank

Validation
failure

PACS.002s2

DVF***

PACS.002

DNF

IDF

PACS.002

CAMT.056

IDF

DNF

CAMT.056

Settlement
Match
PACS.002s2

RSF***

Settlement
failure

Match
RSF***

PACS.002s2

Customer
Revokes
Collection *

PACS.007

IDF

PACS.004

PAIN.007

Customer
Revokes
Collection*

PACS.007

IDF

PACS.004

PAIN.002

Match

Settlement

PAIN.007

Match

Message
refused
by debtor

GPP Validation
failure

Message
returned
by debtor**
Message
returned
by debtor**
Match

Settlement
PACS.002s2

DVF/
RSF*
**

PACS.004

DNF

Settlement
Settlement/
Validation
failure

DVF/
RSF
** *

PACS.002s2

DNF

PACS.007

* Revocation can be initiated also in the GUI (either by Creditor or by creditor’s bank)
** Or debtor’s bank
*** DVF/RSF - On settlement failure, both parties will receive an RSF file with the failed transactions, given that the transactions were already passed to the counter-party ahead of settlement (only showing RSF to Sending Party in this diagram).
On validation failure, only the Sending Party will receive a DVF file back. Every message can receive a validation failure message back; only DD and post-settlement R-messages can receive a settlement failure message back.

Global PAYplus Version 4.6.6 Business Guide

Page 13

Single Euro Payment Area (SEPA)

1.5.3
1.5.3.1

Introduction to SEPA

Files and Messages Process
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

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

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

•

pain.008,
pacs.003

•
•

pacs.003,
pacs.002S2

•
•

pacs.003,
pacs.002

•
•

pacs.003,
pacs.004

•
•

pacs.003,
pain.007,
pain.002

•
•
•

Outward to CSM
(IDF)
Incoming from
CSM (presettlement) (DNF)

Outward
collection,
Incoming presettlement Reject
from Debtor

pacs.002
(as Reject)
from Debtor
Bank before
settlement

Outward to CSM
(IDF)
Incoming from
CSM (post settlement) (DNF)

Outward
collection,
Incoming postsettlement
Return/Refund
from Debtor

pacs.004
(as Return
or Refund)
from Debtor
Bank

Outward to CSM
(IDF)
Incoming
Cancellation from
customer
Reject back to
Customer

Incoming
Cancellation
Request/Reversal
fails preprocessing

N/A

Global PAYplus Version 4.6.6 Business Guide

•

•
•

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.
Match and link
between pacs.003
and pacs.002
Reverse
accounting for
Creditor.
Match and link
between pacs.003
and pacs.002
Reverse
accounting for
Creditor.

No accounting
performed against
creditor’s account

Page 14

Single Euro Payment Area (SEPA)

Introduction to SEPA

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

•

Outward
Cancellation
Request/Reversal
(IDF)
Incoming from
CSM (DVF/RSF)

Outward
Cancellation
Request/Reversal,
Incoming CSM
reject

•

pacs.007,
camt.056,
pacs.002S2

•

•
•

pacs.002S2
as validation
failure
(same day)
or as
settlement
failure (on
settlement
day) from
STEP2

•

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.
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 (presettlement) (IDF)

Outward Reject

N/A

•

•
•

pacs.003,
pacs.002,
pacs.002s2

•
•

•

Incoming from
CSM (DNF)
Outward from
Debtor (presettlement) (IDF)
Incoming from
CSM (DVF)

Outward Reject,
Incoming CSM
reject

Global PAYplus Version 4.6.6 Business Guide

pacs.002S2
as validation
failure
(same day)

•

No accounting
posted to debtor
(neither debit nor
credit)
Can be generated
manually or
automatically.
Both A and S
messages are
generated.
May require
‘enrichment’ of
pacs.002S2 when
Rejection is
received on
file/bulk level.
No reverse
accounting on
receipt of CSM
reject.

Page 15

Single Euro Payment Area (SEPA)

Introduction to SEPA

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

•

Incoming from
CSM (DNF)
Outward from
Debtor (post settlement) (IDF)
Incoming from
CSM (DVF/RSF)

Outward
Return/Refund

Incoming from
CSM (DNF)
Incoming from
CSM (DNF)

Incoming
Cancellation
Request/Reversal
from Clearing

•

pacs.003,
pacs.004,
pacs.002s2

•
•

•

pacs.003,
pacs.007,
camt.056

•
•

•

pacs.002S2
as validation
failure
(same day)
or as
settlement
failure (on
settlement
day) from
STEP2
N/A

•

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

•
•

•

pacs.004,
pacs.002S2

•

Incoming from
CSM (post settlement) (DNF)
Incoming from
CSM (RSF)

Incoming postsettlement
Return/Refund
from Debtor,
Incoming CSM
reject

Global PAYplus Version 4.6.6 Business Guide

pacs.002S2
as
settlement
failure (on
settlement
day) from
STEP2

•

Reverse
accounting to
debtor
Can be generated
manually or
automatically.
May require
‘enrichment’ of
pacs.002S2 when
Rejection is
received on
file/bulk level.
No additional
accounting vs. the
debtor’s account.
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 Rmessage, no
accounting is done.
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.
Match and link
between pacs.004
and pacs.002S2
May require
‘enrichment’ of
pacs.002S2 when
Rejection is
received on
file/bulk level.

Page 16

Single Euro Payment Area (SEPA)

Message
Type

pacs.007,
pacs.002S2

Outward/Inward

•

Incoming from
CSM (DNF)
Incoming from
CSM (RSF)

•

Introduction to SEPA

Processing Flow

Incoming
Reversal from
Clearing,
Incoming CSM
reject

STEP2
/Receiving
Bank
Response

Comments

pacs.002S2
as
settlement
failure (on
settlement
day) from
STEP2

•

No additional
accounting vs. the
debtor’s account.

•

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

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

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

•

Outward to
CSM (ICF)
Outward
Recall (ICF)

Outward Recall

N/A

•
pain.001,
pacs.008

•
•

pacs.008,
pacs.002S2

•
•

pacs.008,
camt.056

•
•

Global PAYplus Version 4.6.6 Business Guide

•

Match and link
between pacs.008
and pacs.002S2
Reverse accounting
for Debtor

Link between
pacs.008 and
camt.056

Page 17

Single Euro Payment Area (SEPA)

Message
Type

pacs.008,
pacs.004

Outward/Inward

•
•

pacs.008,
camt.056,
pacs.004

•
•

Introduction to SEPA

Processing
Flow

STEP2
/Receiving
Bank
Response

Outward to
CSM (ICF)
Incoming from
Debtor (SCF)

Outward
payment,
Incoming Return
from Creditor

pacs.004 as
Return from
Creditor
Bank

Outward to
CSM (ICF)
Incoming from
Debtor (SCF)

Outward Recall,
Incoming Return
from Creditor

pacs.004 as
Return from
Creditor
Bank

Comments

•

If pre-settlement,
reverse accounting
for Debtor.

•

Match and link
between pacs.008
and pacs.004
Reverse accounting
for Debtor

•
•
•
•

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 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.
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

Incoming from
CSM (SCF)
Outward
Recall
Rejection
(ICF)

Incoming Recall
from Clearing,
Outward Recall
Rejection

N/A

No accounting done vs.
the Creditor account

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

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.

•

camt.056,
camt.029

•
•

camt.029,
pacs.002S2

•
•

camt.056,
pacs.004

•
•

•

Global PAYplus Version 4.6.6 Business Guide

Match and link
between camt.056
and pacs.003
No accounting done
vs. the Creditor
account

Page 18

Single Euro Payment Area (SEPA)

Introduction to SEPA

Message
Type

Outward/Inward

Processing
Flow

STEP2
/Receiving
Bank
Response

Comments

pacs.004,
pacs.002S2

•

Outward Return,
Incoming CSM
reject

pacs.002S2
as validation
failure (same
day)

No accounting done vs.
the Creditor account

•

1.5.3.3

Outward to
CSM (ICF)
Incoming from
CSM (CVF)

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 Rmessage is sent to a specific queue for manual handling – see scenario Error! Reference
source not found..

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

Message Status:
 Rejected (pacs.003)
 Complete (pacs.002)
 RMSGREJ (camt.056)
 RMSGREJ (pacs.002s2)

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).

Global PAYplus Version 4.6.6 Business Guide

Page 19

Single Euro Payment Area (SEPA)

Introduction to SEPA

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

Message Status:
 Cancelled (pacs.003)
 Rejected (pacs.002)
 Completed (camt.056)

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

Message Status:
 None

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.

Global PAYplus Version 4.6.6 Business Guide

Page 20

Single Euro Payment Area (SEPA)

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

Global PAYplus Version 4.6.6 Business Guide

Page 21

Single Euro Payment Area (SEPA)

Use Case Name

Outward SEPA Credit Transfer (SCT)
•

2.1.1

GPP SEPA Credit Transfer (SCT) Use Cases

+ existing alternate flows as described in the Mass Payments Business
Guide, for use case Outward Credit Transfer

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)

Global PAYplus Version 4.6.6 Business Guide

Page 22

Single Euro Payment Area (SEPA)

2.1.1.1

GPP SEPA Credit Transfer (SCT) Use Cases

Outward SEPA Credit Transfer via STEP2 Workflow

Outward SCT via STEP2
Channel/
Initiating Party

Incoming
Customer
file
(pain.001)

GPP
Integration

GPP MP Processing

GPP User

Bank’s Core
Systems

GPP Clearing
Service

STEP2
Gateway

Clearing
processing &
formatting

Outward ICF
file
(Pacs.008)

Other
GPP
flows
Receipt file
File processing

Triggers acknowledgement
generation
Creditor/Debtor
Agents received?

Account Lookup

Compliance check

No
Yes

BIC from
IBAN
derivation

Send file

Pre-processing transactions

Customer
Acknoledge
ment
(pain.002)

Reject/
Manual
queue

Pass
validation
Yes
PD
<
D-3

Warehouse/
Reject

Yes

No
PD > D or
PD=D after COT Yes
No

After COT of last
Settlement Cycle

Roll
date

Balance Inquiry
Sub-batch
generation

Route to
MP flow

FX Interface

Consolidated
Itemized
Customer
leg leg
Customer

Posting

Execution
Clearing leg

Execute individuals/bulk

Manual
Create
STEP2 Cycle
determination

Individual tx
in Complete
End

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.

Global PAYplus Version 4.6.6 Business Guide

Page 23

Single Euro Payment Area (SEPA)

GPP SEPA Credit Transfer (SCT) Use Cases

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.

Global PAYplus Version 4.6.6 Business Guide

Page 24

Single Euro Payment Area (SEPA)

2.1.4

GPP SEPA Credit Transfer (SCT) Use Cases

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 ACHRejection use case.
2.1.4.1

Outward SEPA Credit Transfer with Incoming CVF Workflow

Incoming CVF

GPP
Integration

GPP MP Processing

File Processing

Channel/
Initiating
Party

GPP User

Bank’s Core
Systems

GPP Clearing
Service

STEP2 Gateway

Receipt file

Incoming CVF
(pacs.002S2)

Pass parsing/
validation?
No

Yes

File Matching?

File
Rejected

Match with
original tx

Manual
queue

Yes

Await ACK for
Posting?

SEPA processing is
optimistic, not
awaiting ACK

Yes

ACK Handling

ACK present
in File?

Match
with
original CT
Posting
Customer
leg

Enrich from
original file
Trigger
CT to ACK
flow

Reject Handling

Original CT in
Complete

Match with
original CT?
Yes

No auto No
handle as
NAK for Rmsg

Customer
Leg - Reverse

Trigger
CT to
Rejected
flow

End

Global PAYplus Version 4.6.6 Business Guide

Page 25

Single Euro Payment Area (SEPA)

2.1.4.1.1

GPP SEPA Credit Transfer (SCT) Use Cases

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.

Global PAYplus Version 4.6.6 Business Guide

Page 26

Single Euro Payment Area (SEPA)

2.1.5.1

GPP SEPA Credit Transfer (SCT) Use Cases

Outward SEPA Credit Transfer with Incoming CCF Workflow

Incoming CCF

Channel/
Initiating
Party

GPP MP Processing

File Processing

GPP
Integration

Pass parsing/
validation?

GPP User

File
Rejected

Manual
queue

Bank’s Core
Systems

GPP Clearing
Service

STEP2
Gateway

Receipt file

Incoming CCF
(pacs.002S2)

Yes

Bulk Matching?
Yes

Match with
original tx

Manual
queue

Reject Handling

Yes

Match with
original CT

Yes
Trigger
CT to
Rejected
flow

Customer
Leg - Reverse
Posting

End

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.

Global PAYplus Version 4.6.6 Business Guide

Page 27

Single Euro Payment Area (SEPA)

GPP SEPA Credit Transfer (SCT) Use Cases

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
Channel/
Initiating
Party

GPP
Integration

GPP MP Processing

GPP User

Bank’s Core
Systems

File processing

GPP Clearing
Service

STEP2
Gateway

Receipt file

Incoming SCF
(pacs.008)

Account Lookup

Pre-Processing
Transactions

Compliance check

Sub-batch
generation
Consolidated
Clearing leg
Execution &
Execute
Individual

Balance Inquiry
FX Interface

Itemized
Customer leg

Posting

End

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.

Global PAYplus Version 4.6.6 Business Guide

Page 28

Single Euro Payment Area (SEPA)

2.3

GPP SEPA Credit Transfer (SCT) Use Cases

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.

Global PAYplus Version 4.6.6 Business Guide

Page 29

Single Euro Payment Area (SEPA)

2.3.1.1

GPP SEPA Credit Transfer (SCT) Use Cases

Outward PCR via STEP2 Workflow

Outward Recall (PCR)

Channel/
Initiating Party

GPP
Integration

GPP MP Processing

GPP User

Bank’s Core
Systems

GPP Clearing
Service

STEP2
Gateway

Clearing
processing &
formatting

Outward ICF
(camt.056)

Recall

Recall Initiation,
display Recall
screen

Submit Recall
process

Complete
(CT)

Manual
Input &
Submit

Execution, Pre/Post-Settlement Determination

Compliance check
Pre-Settlement>
Yes
Execute as
Presettlement
PD
>
D+10

Itemized
Customer leg

FX Interface
Posting

Reject

Execute as
Postsettlement

Clearing leg
(subject to
Pre/Post determin.)
Execute
individuals/bulk

End

2.3.1.1.1

Individual tx
in Complete

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.

Global PAYplus Version 4.6.6 Business Guide

Page 30

Single Euro Payment Area (SEPA)

2.3.1.1.2

•

GPP SEPA Credit Transfer (SCT) Use Cases

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.

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 subbatching, 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.

Global PAYplus Version 4.6.6 Business Guide

Page 31

Single Euro Payment Area (SEPA)

GPP SEPA Credit Transfer (SCT) Use Cases

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 ACHRejection use case.
2.3.2.1

Outward PCR with Incoming CVF Workflow

Incoming CVF for R-msg

GPP
Integration

GPP MP Processing

File Processing

Channel/
Initiating
Party

GPP User

Bank’s Core
Systems

GPP Clearing
Service

STEP2 Gateway

Receipt file

Incoming CVF
(pacs.002S2)

Pass parsing/
validation?
Yes

File Matching?

Match with
original tx

No
File
Rejected

Manual
queue

Yes
Link with
original tx

End

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.

Global PAYplus Version 4.6.6 Business Guide

Page 32

Single Euro Payment Area (SEPA)

2.4

GPP SEPA Credit Transfer (SCT) Use Cases

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

•
•

2.4.1

Incoming Recall unmatched
Original payment unqualified for Recall

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.

Global PAYplus Version 4.6.6 Business Guide

Page 33

Single Euro Payment Area (SEPA)

2.4.1.1

GPP SEPA Credit Transfer (SCT) Use Cases

Incoming Recall from STEP2 Workflow

Incoming Recall from STEP2
Channel/
Initiating
Party

GPP
Integration

GPP MP Processing

GPP User

Bank’s
Core
Systems

Pre-processing transactions

File processing

GPP Clearing
Service

STEP2
Gateway

Receipt file

Incoming SCF
(camt.056)

Match found?

Yes

Service
Rejected
(Recall)

No
No

Cancellation
Request Valid?

Triggered automatically
Generation of
Recall Reject
UC
Reject

End

Yes

Approve

Approve
Recall

Service
Wait
Generation of
Return UC

End

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.

Global PAYplus Version 4.6.6 Business Guide

Page 34

Single Euro Payment Area (SEPA)

2.5

GPP SEPA Credit Transfer (SCT) Use Cases

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

•
•

2.5.1

Automatic generation of the Recall Reject by GPP (with specific SEPA
codes)
Recall is rejected by STEP2 by CVF (due to validation error)

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.

Global PAYplus Version 4.6.6 Business Guide

Page 35

Single Euro Payment Area (SEPA)

2.5.1.1

GPP SEPA Credit Transfer (SCT) Use Cases

Manual generation of SEPA Recall Reject Workflow

Outward Recall-Reject

Channel/
Initiating Party

GPP
Integration

GPP MP Processing

Recall-Reject
Initiation,
display RecallReject screen

Submit RecallReject process

PD <
Recall date
+ 10

GPP User

Bank’s
Core
Systems

GPP Clearing
Service

STEP2
Gateway

Reject

Approve
Recall

Manual
Input &
Submit

Reject

Includes only STEP2
error codes

CT and Recall remain in
their previous statuses.

Yes

Execution

Execute
individuals/
bulk

End

2.5.1.1.1

Clearing
processing &
formatting

Outward ICF
(camt.029)

CT in previous status,
Recall in Service Rejected

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).

Global PAYplus Version 4.6.6 Business Guide

Page 36

Single Euro Payment Area (SEPA)

•

GPP SEPA Credit Transfer (SCT) Use Cases

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
Integration

GPP MP Processing

File Processing

Channel/
Initiating
Party

GPP User

Bank’s Core
Systems

GPP Clearing
Service

STEP2 Gateway

Receipt file

Incoming CVF
(pacs.002S2)

Pass parsing/
validation?
Yes

File Matching?

Match with
original tx

File
Rejected

Manual
queue

Yes
Link with
original tx

End

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)

Global PAYplus Version 4.6.6 Business Guide

Page 37

Single Euro Payment Area (SEPA)

GPP SEPA Credit Transfer (SCT) Use Cases

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.

Global PAYplus Version 4.6.6 Business Guide

Page 38

Single Euro Payment Area (SEPA)

2.6.1.1

GPP SEPA Credit Transfer (SCT) Use Cases

Manual generation of SEPA Recall-Return Workflow

Outward Recall-Return

Channel/
Initiating Party

GPP
Integration

GPP MP Processing

GPP User

Bank’s Core
Systems

GPP Clearing
Service

STEP2
Gateway

Clearing
processing &
formatting

Outward
Return file
(pacs.004)

Approve

Recall-Return
Initiation

Approve
Recall

Reason code
assigned by GPP
Submit RecallReturn process
Subject to bank decision
to implement restriction
CT and Recall remain in
their previous statuses.

PD <
Recall date
+ 10

Reject

Yes

Fee
Handling
Compliance check

Execution

Balance Inquiry

FX Interface
Clearing leg

Execute
individuals/
bulk

Itemized
Customer leg

CT in Returned

Posting

End

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.

Global PAYplus Version 4.6.6 Business Guide

Page 39

Single Euro Payment Area (SEPA)

2.6.1.1.3

GPP SEPA Credit Transfer (SCT) Use Cases

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

Channel/
Initiating Party

GPP
Integration

GPP MP Processing

GPP User

GPP Clearing
Service

STEP2
Gateway

Clearing
processing &
formatting

Outward
Return file
(pacs.004)

Return

Return
Initiation,
display Returnscreen

Manual/
Complete
queue

Manual
Input &
Submit

Submit Return
process

PD <
D
+3

Bank’s Core
Systems

Subject to reason
(restrict Technical
Returns)
Reject

Yes

CT remains in
previous statuses.

Compliance check

Execution

Balance Inquiry

FX Interface
Itemized
Customer leg
Execute
individuals/
bulk

Clearing leg

Posting

CT in Returned
End

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.

Global PAYplus Version 4.6.6 Business Guide

Page 40

Single Euro Payment Area (SEPA)

GPP SEPA Credit Transfer (SCT) Use Cases

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

Outward Return with Incoming CVF Workflow

Incoming CVF for R-msg

GPP
Integration

GPP MP Processing

File Processing

Channel/
Initiating
Party

GPP User

Bank’s Core
Systems

GPP Clearing
Service

STEP2 Gateway

Receipt file

Incoming CVF
(pacs.002S2)

Pass parsing/
validation?
Yes

File Matching?

Match with
original tx

No
File
Rejected

Manual
queue

Yes
Link with
original tx

End

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.

Global PAYplus Version 4.6.6 Business Guide

Page 41

Single Euro Payment Area (SEPA)

2.6.4

GPP SEPA Credit Transfer (SCT) Use Cases

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

•
•

2.7.1

Incoming Recall-reject not matched
Original recall was regarded as pre-settlement

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

Sets the incoming recall reject message status to Service Complete

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.

Global PAYplus Version 4.6.6 Business Guide

Page 42

Single Euro Payment Area (SEPA)

2.7.1.1

GPP SEPA Credit Transfer (SCT) Use Cases

Incoming Recall Reject Workflow

Incoming Recall-Reject
Channel/
Initiating
Party

GPP
Integration

GPP MP Processing

GPP User

Bank’s
Core
Systems

GPP Clearing
Service

Receipt file

File processing

STEP2
Gateway
Incoming SCF
(camt.029)

Including Match and
link with a previously
sent Recall

Pre-Processing
Transactions

Release

Processing Reject-Recall

Service
Release
Match found?
Service
Rejected
(RecallReject)

No
Yes

Recall is presettlement?

Yes

Recall-Reject in Service Complete
Recall in Service Rejected

End

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 presettlement, 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 Presettlement Recall.

Global PAYplus Version 4.6.6 Business Guide

Page 43

Single Euro Payment Area (SEPA)

2.8

GPP SEPA Credit Transfer (SCT) Use Cases

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

Global PAYplus Version 4.6.6 Business Guide

Page 44

Single Euro Payment Area (SEPA)

2.8.1.1

GPP SEPA Credit Transfer (SCT) Use Cases

Incoming Return from STEP2 Workflow

Incoming Return
Channel/
Initiating
Party

GPP
Integration

GPP MP Processing

GPP User

Bank’s Core Systems

File processing

Pre-processing

Match
found?

Processing
individual
Return

GPP Clearing
Service

Receipt file

STEP2 Gateway

Incoming SCF
(pacs.004)

ROFi

Including link with a
previously sent Recall, for
incoming Return-Recall

Compliance check

Fee
Handling

FX Interface

Sub-batch
generation

Consolidated
Clearing leg

Posting

No bulking/Outgoing
format
Execution &
Execute
individual

Itemized
Customer leg
Incoming Return to Complete
Outward Recall to Service Complete
Outward CT to Returned

End

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.

Global PAYplus Version 4.6.6 Business Guide

Page 45

Single Euro Payment Area (SEPA)

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

•
•
•
•

3.1.1

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

Outward SDD via STEP2

GPP receives and processes incoming files that contain transaction messages.

Global PAYplus Version 4.6.6 Business Guide

Page 46

Single Euro Payment Area (SEPA)

GPP SDD (SEPA Direct Debit) Use Cases

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)

Global PAYplus Version 4.6.6 Business Guide

Page 47

Single Euro Payment Area (SEPA)

3.1.1.1

GPP SDD (SEPA Direct Debit) Use Cases

Outward SDD via STEP2 Workflow

Outward SDD via STEP2
Channel/
GPP Integration
Initiating Party

GPP MP Processing

GPP User

Bank’s Core
Systems

GPP Clearing
Service

STEP2
Gateway

Clearing
processing &
formatting

Outward
IDF
(Pacs.003)

Other
GPP
flows

Incoming
Customer
file
(pain.008)

Receipt file
File processing

Customer
Acknoledge
ment
(pain.002)

Account Lookup
Send file
Compliance check
Creditor/Debtor
Agents received?
Yes

Pre-processing transactions

BIC from
IBAN
derivation

Reject/
Manual
queue

SEPA
specific
validations

Pass
validation

Yes
PD
<
D-14(C)

Yes

Warehouse/
Reject

No
PD >
D-1(T)

Yes

Route to
MP flow

Balance Inquiry
Sub-batch
generation

FX Interface

Consolidated
Itemized
Customer
leg
Customer leg

Posting

Execution
Clearing leg

Execute
individuals/
bulk

End

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.

Global PAYplus Version 4.6.6 Business Guide

Page 48

Single Euro Payment Area (SEPA)

3.1.1.1.2

GPP SDD (SEPA Direct Debit) Use Cases

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.

Global PAYplus Version 4.6.6 Business Guide

Page 49

Single Euro Payment Area (SEPA)

GPP SDD (SEPA Direct Debit) Use Cases

The process of this DVF file is described in the GPP Business Guide Mass Payments, Incoming ACHRejection use case.
3.1.4.1

Outward SDD with Incoming DVF Workflow

Incoming DVF

GPP
Integration

GPP MP Processing

File Processing

Channel/
Initiating
Party

GPP User

Bank’s Core
Systems

GPP Clearing
Service

Clearing
Gateway

Receipt file

Incoming DVF
(pacs.002S2)

Pass parsing/
validation?
No

Yes

File Matching?

File
Rejected

Match with
original tx

Manual
queue

Yes

ACK present
in File?

ACK Handling

SEPA processing is
optimistic, not
awaiting ACK

Await ACK for
Posting?

Match
with
original DD
Posting
Customer
leg

Enrich from
original file
Trigger
DD to
ACK flow

Reject Handling

Original DD in
Complete

Match with
original DD

Customer
Leg - Reverse

Yes
Trigger
DD to
Rejected
flow

End

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

Global PAYplus Version 4.6.6 Business Guide

Page 50

Single Euro Payment Area (SEPA)

GPP SDD (SEPA Direct Debit) Use Cases

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
Integration

GPP MP Processing

File Processing

Channel/
Initiating
Party

Pass parsing/
validation?

GPP User

Bank’s Core
Systems

GPP Clearing
Service

STEP2
Gateway

Receipt file

Incoming RSF
(pacs.002S2)

File
Rejected

Yes

Bulk Matching?

Manual
queue

Yes

Match with
original tx

Manual
queue

Reject Handling

Yes

Match with
original DD

Yes
Trigger
DD to
Rejected
flow

Customer
Leg - Reverse
Posting

End

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.

Global PAYplus Version 4.6.6 Business Guide

Page 51

Single Euro Payment Area (SEPA)

GPP SDD (SEPA Direct Debit) Use Cases

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

•
•

3.2.1

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

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)

Global PAYplus Version 4.6.6 Business Guide

Page 52

Single Euro Payment Area (SEPA)

3.2.1.1

GPP SDD (SEPA Direct Debit) Use Cases

Incoming SDD from STEP2 Workflow

Incoming SDD
Channel/
Initiating
Party

GPP
Integration

GPP MP Processing

GPP User

Bank’s Core
Systems

File processing

Pre-processing transactions

STEP2
Gateway

Receipt file

Incoming DNF
(pacs.003)

Account Lookup

SEPA
specific
validations

Pass
validation

GPP Clearing
Service

Compliance check

No
Reject/
Manual
queue

Yes
Debtor
Mandate
validations
No
Pass
validation

Sub-batch
generation
Consolidated
Clearing leg
Execution &
Execute
Individual

Balance Inquiry
FX Interface

Itemized
Customer leg

Posting

End

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

Global PAYplus Version 4.6.6 Business Guide

Page 53

Single Euro Payment Area (SEPA)

GPP SDD (SEPA Direct Debit) Use Cases

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.

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:

Global PAYplus Version 4.6.6 Business Guide

Page 54

Single Euro Payment Area (SEPA)

GPP SDD (SEPA Direct Debit) Use Cases

Check mandate existence using the unique mandate reference (UMR) and Creditor ID
(excluding characters 5-7 of the Creditor ID

Manual set-up of debtor mandates is available. This enables the financial institution to predefine limit checks, cancel a mandate and specify rejection of a collection before it is actually
received

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.

•

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.

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.

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).

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

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.

Global PAYplus Version 4.6.6 Business Guide

Page 55

Single Euro Payment Area (SEPA)

GPP SDD (SEPA Direct Debit) Use Cases

 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 postsettlement 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.

Global PAYplus Version 4.6.6 Business Guide

Page 56

Single Euro Payment Area (SEPA)

3.2.2.1

GPP SDD (SEPA Direct Debit) Use Cases

Incoming RSF Workflow

Incoming RSF

GPP
Integration

GPP MP Processing

File Processing

Channel/
Initiating
Party

Pass parsing/
validation?

GPP User

Bank’s Core
Systems

GPP Clearing
Service

STEP2
Gateway

Receipt file

Incoming RSF
(pacs.002S2)

File
Rejected

Yes

Bulk Matching?

Manual
queue

Yes

Match with
original tx

Manual
queue

Reject Handling

Yes

Match with
original DD

Yes
Trigger
DD to
Rejected
flow

Customer
Leg - Reverse
Posting

End

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.

Global PAYplus Version 4.6.6 Business Guide

Page 57

Single Euro Payment Area (SEPA)

3.3

GPP SDD (SEPA Direct Debit) Use Cases

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

•
•
•
•
•
•

3.3.1

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

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.

Global PAYplus Version 4.6.6 Business Guide

Page 58

Single Euro Payment Area (SEPA)

3.3.1.1

GPP SDD (SEPA Direct Debit) Use Cases

Outward Request for Cancellation via STEP2 Workflow

Outward Request for Cancellation/Reversal

Channel/
Initiating Party

GPP
Integration

GPP MP Processing

Request for
Cancellation
Initiation,
display screen

Submit Request
for Cancellation
process

GPP User

Bank’s Core
Systems

GPP Clearing
Service

STEP2
Gateway

Clearing
processing &
formatting

Outward
IDF
(camt.056/
pacs.007)

Recall

Complete
(DD)

Manual
Input &
Submit

Compliance check

Execution, Pre/Post-Settlement Determination

Pre-Settlement?
Balance Inquiry
Yes

Execute as
Presettlement

PD >
D+5(T)

FX Interface
Itemized
Customer leg

Posting

Reject

Execute as
Postsettlement

Execute
individuals/
bulk

Clearing leg

End

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:

Global PAYplus Version 4.6.6 Business Guide

Page 59

Single Euro Payment Area (SEPA)

•

GPP SDD (SEPA Direct Debit) Use Cases

Bank: The initiating bank’s BIC, which is the default value.

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.

Global PAYplus Version 4.6.6 Business Guide

Page 60

Single Euro Payment Area (SEPA)

3.3.2.1

GPP SDD (SEPA Direct Debit) Use Cases

Outward Request for Cancellation from Initiating Party via STEP2 Workflow

Outward Request for Cancellation – from Initiating Party

GPP
Integration

Incoming
Request for
Cancellation
file
(pain.007)

Receipt file

Customer
Acknoledge
ment
(pain.002)

Send file

GPP MP Processing

GPP User

Bank’s Core
Systems

GPP Clearing
Service

STEP2
Gateway

Clearing
processing &
formatting

Outward
IDF
(camt.056/
pacs.007)

File
processing

Pre-processing transactions

Channel/
Initiating Party

Match
found?

Yes

Reject

See separate
detailed flow

Incoming
Request for
cancellation
process

Cancelled
(DD)
PreSettlement?

No
Compliance check

Pre/Post-Settlement Determination

Yes
Balance Inquiry

DD
transmitted?
No

FX Interface

Yes
Execute as
Presettlement

Itemized
Customer leg

Posting

PD >
D+5(T)

Execute as
Postsettlement

Clearing leg
Execute
individuals/
bulk

End

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 Rmessage 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.

Global PAYplus Version 4.6.6 Business Guide

Page 61

Single Euro Payment Area (SEPA)

3.3.3

GPP SDD (SEPA Direct Debit) Use Cases

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.

Global PAYplus Version 4.6.6 Business Guide

Page 62

Single Euro Payment Area (SEPA)

3.3.4.1

GPP SDD (SEPA Direct Debit) Use Cases

Outward Request for Cancellation/Reversal in Manual Queue or Rejected

Outward Request for Cancellation in Manual queue or Rejected

Channel/
Initiating
Party
Incoming
Request for
Cancellation
file (pain.007)

GPP
Integration

GPP MP Processing

Receipt file

File processing

GPP User

Pass parsing/
validation?

GPP
Bank’s Core
Clearing
Systems
Service

Clearing
Gateway

File
Rejected

Yes
Pre-Processing
Transactions
Recall

Complete
(DD)

Request for
Cancellation
Initiation &Submit

Customer
Acknoledge
ment
(pain.002)

Triggers acknowledgement
generation
Send file
Pass validation?

Reject/
Manual
queue

Manual
queue

From file?

Yes
Sub-batch
generation

No
Pass validation
Yes
Execution (including
execution of
Individual/bulk)

Pass validation
Yes
End

Request for
Cancellation/
Reversal in
Complete

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.

Global PAYplus Version 4.6.6 Business Guide

Page 63

Single Euro Payment Area (SEPA)

GPP SDD (SEPA Direct Debit) Use Cases

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 ACHRejection use case.
3.3.5.1

Outward Request for Cancellation with Incoming DVF Workflow

Incoming DVF for R-msg

GPP
Integration

GPP MP Processing

File Processing

Channel/
Initiating
Party

GPP User

Bank’s Core
Systems

GPP Clearing
Service

STEP2 Gateway

Receipt file

Incoming DVF
(pacs.002S2)

Pass parsing/
validation?
Yes

File Matching?

Match with
original tx

No
File
Rejected

Manual
queue

Yes
Link with
original tx

End

For details, see DVF File and Bulks Matching and Handling.

3.3.6

Outward Reversal with Incoming DVF/RSF

Global PAYplus Version 4.6.6 Business Guide

Page 64

Single Euro Payment Area (SEPA)

GPP SDD (SEPA Direct Debit) Use Cases

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
Integration

GPP MP Processing

File Processing

Channel/
Initiating
Party

Pass parsing/
validation?

GPP User

Bank’s Core
Systems

GPP Clearing
Service

STEP2
Gateway

Receipt file

Incoming RSF
(pacs.002S2)

File
Rejected

Yes

Bulk Matching?

Manual
queue

Yes

Match with
original tx

Manual
queue

Yes
Link with
original tx

End

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

•
•

3.4.1

Request for Cancellation is unmatched.
Request for Cancellation cannot be processed

Incoming Request for Cancellation from STEP2

GPP receives and processes incoming files that contain transaction messages.

Global PAYplus Version 4.6.6 Business Guide

Page 65

Single Euro Payment Area (SEPA)

3.4.1.1

GPP SDD (SEPA Direct Debit) Use Cases

Incoming Request for Cancellation from STEP2 Workflow

Incoming Request for Cancellation
Channel/
Initiating
Party

GPP
Integration

GPP MP Processing

GPP User

Bank’s Core
Systems

Pre-processing

File processing

Match
found?

GPP Clearing
Service

Receipt file

Service
Release

Clearing
Gateway
Incoming
DNF
(camt.056)

Incoming
Request for
Cancellation

Including link with an
incoming collection

Yes
Processing
individual
Request for
Cancellation

Compliance check

Sub-batch
generation

Consolidated
Clearing leg

Posting

No bulking/Outgoing
format
Execution &
Execute
individual

End

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.

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).

Global PAYplus Version 4.6.6 Business Guide

Page 66

Single Euro Payment Area (SEPA)

3.4.1.1.1

GPP SDD (SEPA Direct Debit) Use Cases

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 subbatch 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.

Global PAYplus Version 4.6.6 Business Guide

Page 67

Single Euro Payment Area (SEPA)

3.4.5

GPP SDD (SEPA Direct Debit) Use Cases

Incoming Request for Cancellation Fails Processing

3.4.5.1

Incoming Request for Cancellation Fails Processing Workflow

Incoming Request for Cancellation – fails processing
Channel/
Initiating
Party

GPP
Integration

GPP MP Processing

Bank’s
Core
Systems

GPP User

GPP
Clearing
Service
Receipt
file

File
processing

Pass parsing/
validation?

STEP2
Gateway
Incoming
DNF
(camt.056)

File
Rejected

Pre-Processing
Transactions

Pass validation?

Reject/
Manual
queue

Manual
queue

Yes
Sub-batch
generation

Pass validation
Yes
Execution
(including
execution of
Individual)

Pass validation
Yes
End

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.

Global PAYplus Version 4.6.6 Business Guide

Page 68

Single Euro Payment Area (SEPA)

3.5

GPP SDD (SEPA Direct Debit) Use Cases

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

•
•
•
•

3.5.1

Reversal is unmatched.
Reversal cannot be processed.
Reversal re-activates mandate (for mandate cancelled by previous
collection).
Incoming RSF for Incoming Reversal

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.

Global PAYplus Version 4.6.6 Business Guide

Page 69

Single Euro Payment Area (SEPA)

3.5.1.1

GPP SDD (SEPA Direct Debit) Use Cases

Incoming Reversal from STEP2 Workflow

Incoming Reversal
Channel/
Initiating
Party

GPP
Integration

GPP MP Processing

GPP User

Bank’s Core
Systems

File processing

GPP Clearing
Service

Receipt file

STEP2
Gateway
Incoming
DNF
(pacs.007)

Pre-processing

Incoming
Reversal
Match
found?

Service
Release

Including link with an
incoming collection

Yes
Processing
individual
Reversal

Compliance check

Sub-batch
generation

Consolidated
Clearing leg

Posting

No bulking/Outgoing
format
Execution &
Execute
individual

End

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

Compliance check

For the matched collection, GPP checks:
o

The collection was not already cancelled, rejected or returned

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.

Global PAYplus Version 4.6.6 Business Guide

Page 70

Single Euro Payment Area (SEPA)

3.5.1.1.1

GPP SDD (SEPA Direct Debit) Use Cases

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 reactivation 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.

Global PAYplus Version 4.6.6 Business Guide

Page 71

Single Euro Payment Area (SEPA)

3.5.4

GPP SDD (SEPA Direct Debit) Use Cases

Incoming Reversal Fails Processing

3.5.4.1

Incoming Reversal Fails Processing Workflow

Incoming Reversal – fails processing
Channel/
Initiating
Party

GPP
Integration

GPP MP Processing

Bank’s
Core
Systems

GPP User

GPP
Clearing
Service
Receipt
file

File
processing

Pass parsing/
validation?

STEP2
Gateway
Incoming
DNF
(pacs.007)

File
Rejected

Pre-Processing
Transactions

Pass validation?

Reject/
Manual
queue

Manual
queue

Yes
Sub-batch
generation

Pass validation
Yes
Execution
(including
execution of
Individual)

Pass validation
Yes
End

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.

Global PAYplus Version 4.6.6 Business Guide

Page 72

Single Euro Payment Area (SEPA)

3.5.5

GPP SDD (SEPA Direct Debit) Use Cases

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
Integration

GPP MP Processing

File Processing

Channel/
Initiating
Party

Pass parsing/
validation?

GPP User

Bank’s Core
Systems

GPP Clearing
Service

STEP2
Gateway

Receipt file

Incoming RSF
(pacs.002S2)

File
Rejected

Yes

Bulk Matching?

Manual
queue

Yes

Match with
original tx

Manual
queue

Yes
Link with
original tx

End

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

Global PAYplus Version 4.6.6 Business Guide

Page 73

Single Euro Payment Area (SEPA)

3.6.1

GPP SDD (SEPA Direct Debit) Use Cases

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

Channel/
Initiating Party

GPP
Integration

GPP MP Processing

GPP User

Bank’s Core
Systems

GPP Clearing
Service

STEP2
Gateway

Clearing
processing &
formatting

Outward
IDF
(pacs.002)

Incoming DD
fails processing
UC

Generate
Reject flow
Reject

Reject
Initiation,
display Returnscreen

Manual
queue

Manual
Input &
Submit

Submit Reject
process

Compliance check
Execution

Execute
individuals/
bulk

Clearing leg

Posting

DD is Rejected
End

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.

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)

Global PAYplus Version 4.6.6 Business Guide

Page 74

Single Euro Payment Area (SEPA)

3.6.1.1.3

GPP SDD (SEPA Direct Debit) Use Cases

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

Outward Reject with Incoming DVF Workflow

Incoming DVF for R-msg

GPP
Integration

GPP MP Processing

File Processing

Channel/
Initiating
Party

GPP User

Bank’s Core
Systems

GPP Clearing
Service

STEP2 Gateway

Receipt file

Incoming DVF
(pacs.002S2)

Pass parsing/
validation?
Yes

File Matching?

Match with
original tx

No
File
Rejected

Manual
queue

Yes
Link with
original tx

End

For details, see DVF File and Bulks Matching and Handling.

Global PAYplus Version 4.6.6 Business Guide

Page 75

Single Euro Payment Area (SEPA)

3.7

GPP SDD (SEPA Direct Debit) Use Cases

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

•
•
•
•

3.7.1

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.

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.

Global PAYplus Version 4.6.6 Business Guide

Page 76

Single Euro Payment Area (SEPA)

3.7.1.1

GPP SDD (SEPA Direct Debit) Use Cases

Outward Return/Refund via STEP2 Workflow

Outward Return

Channel/
Initiating Party

GPP
Integration

GPP User

GPP MP Processing

Bank’s Core
Systems

GPP Clearing
Service

STEP2
Gateway

Clearing
processing &
formatting

Outward
IDF
(pacs.004)

On settlement
date/after

Incoming DD
fails processing
UC

Generate
Return flow
Return

Return
Initiation,
display Returnscreen

Manual
queue (or
Complete)

Manual
Input &
Submit

Submit Return
process

Scheme (Core/
B2B)

Core

Return/
Refund

B2B

Return/
Refund

Return

Reject/
Manual
queue

Refund
not
allowed

Return
Authorized
No

Yes

PD
<
D+5(T)

PD
<
D+2(T)
Yes

Yes
PD
< D+
47(T)
Yes

PD
< D+
440(C)

Yes

Compliance check
Balance Inquiry
Execution
FX Interface
Itemized
Customer leg
Execute
individuals/
bulk

Clearing leg

Posting

DD in Returned
End

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)

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.

Global PAYplus Version 4.6.6 Business Guide

Page 77

Single Euro Payment Area (SEPA)

GPP SDD (SEPA Direct Debit) Use Cases

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 Rmessage) + 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.

Global PAYplus Version 4.6.6 Business Guide

Page 78

Single Euro Payment Area (SEPA)

3.7.3

GPP SDD (SEPA Direct Debit) Use Cases

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

Outward Return/Refund with Incoming RSF Workflow

Incoming RSF

GPP
Integration

GPP MP Processing

File Processing

Channel/
Initiating
Party

Pass parsing/
validation?

GPP User

Bank’s Core
Systems

GPP Clearing
Service

STEP2
Gateway

Receipt file

Incoming RSF
(pacs.002S2)

File
Rejected

Yes

Bulk Matching?

Manual
queue

Yes

Match with
original tx

Manual
queue

Yes
Link with
original tx

End

For details, see RSF File and Bulks Matching and Handling (by the Sender).

Global PAYplus Version 4.6.6 Business Guide

Page 79

Single Euro Payment Area (SEPA)

3.8

GPP SDD (SEPA Direct Debit) Use Cases

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)

Global PAYplus Version 4.6.6 Business Guide

Page 80

Single Euro Payment Area (SEPA)

3.8.1.1

GPP SDD (SEPA Direct Debit) Use Cases

Incoming Reject from STEP2 Workflow

Incoming Reject
Channel/
Initiating
Party

GPP
Integration

GPP MP Processing

GPP User

Bank’s Core
Systems

Pre-processing

File processing

Match
found?

GPP Clearing
Service

STEP2
Gateway

Receipt file

Incoming DNF
(pacs.002)

ROFi

Including link with a
previously sent collection
Processing
individual
Reject

Compliance check

Balance Inquiry
Sub-batch
generation

FX Interface
Consolidated
Clearing leg
No bulking/Outgoing
format

Execution &
Execute
individual

Posting

Itemized
Customer leg

End

3.8.1.1.1

Interchange Fee (AT-R8)

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.

Global PAYplus Version 4.6.6 Business Guide

Page 81

Single Euro Payment Area (SEPA)

3.9

GPP SDD (SEPA Direct Debit) Use Cases

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)

Global PAYplus Version 4.6.6 Business Guide

Page 82

Single Euro Payment Area (SEPA)

3.9.1.1

GPP SDD (SEPA Direct Debit) Use Cases

Incoming Return/Refund from STEP2 Workflow

Incoming Return/Refund
Channel/
Initiating
Party

GPP
Integration

GPP MP Processing

GPP User

Bank’s Core
Systems

File processing

Pre-processing

Match
found?

GPP Clearing
Service

STEP2
Gateway

Receipt file

Incoming DNF
(pacs.004)

ROFi

Including link with a
previously sent collection
Processing
individual
Return

Compliance check
Balance Inquiry
FX Interface

Sub-batch
generation

Consolidated
Clearing leg

Posting

No bulking/Outgoing
format
Execution &
Execute
individual

Itemized
Customer leg

End

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 Rmessage) + Charges Amount (in the R-message).
3.9.1.1.2

Compensation (AT– R6)

Global PAYplus Version 4.6.6 Business Guide

Page 83

Single Euro Payment Area (SEPA)

GPP SDD (SEPA Direct Debit) Use Cases

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

Outward Reversal with Incoming RSF Workflow

Incoming RSF

GPP
Integration

GPP MP Processing

File Processing

Channel/
Initiating
Party

Pass parsing/
validation?

GPP User

Bank’s Core
Systems

GPP Clearing
Service

STEP2
Gateway

Receipt file

Incoming RSF
(pacs.002S2)

File
Rejected

Yes

Bulk Matching?

Manual
queue

Yes

Match with
original tx

Manual
queue

Yes
Link with
original tx

End

For details, see RSF File and Bulks matching and handling (by the receiver).

Global PAYplus Version 4.6.6 Business Guide

Page 84

Single Euro Payment Area (SEPA)

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
4.1.1

SEPA – File Handling
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
4.2.1

SEPA General – Individual Handling
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.

Global PAYplus Version 4.6.6 Business Guide

Page 85

Single Euro Payment Area (SEPA)

4.2.2

Processing

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.

Global PAYplus Version 4.6.6 Business Guide

Page 86

Single Euro Payment Area (SEPA)

Appendix A: Glossary

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.

Message Type

Global PAYplus Version 4.6.6 Business Guide

Page 87

Source Exif Data:

File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.5
Linearized                      : No
Author                          : admin
Category                        : Global PAYplus
Comments                        : 
Company                         : COMMERCIAL IN CONFIDENCE
Content Type Id                 : 0x01010037BB9CACCC7A0843BC34289099ED0E6E
Create Date                     : 2017:06:16 08:28:58-04:00
Keywords                        : Global, PAYplus, Version, 4.6.6
Modify Date                     : 2017:06:16 08:29:38-04:00
Source Modified                 : 
Subject                         : Single Euro Payment Area (SEPA)
Language                        : EN-US
Tagged PDF                      : Yes
XMP Toolkit                     : Adobe XMP Core 5.6-c015 84.159810, 2016/09/10-02:41:30
Metadata Date                   : 2017:06:16 08:29:38-04:00
Creator Tool                    : Acrobat PDFMaker 15 for Word
Document ID                     : uuid:ab7ee304-fd93-4120-bda2-0d94487d4105
Instance ID                     : uuid:67bb0be7-980b-4439-9dc2-39d563301ddf
Format                          : application/pdf
Title                           : Business Guide
Description                     : Single Euro Payment Area (SEPA)
Creator                         : admin
Producer                        : Adobe PDF Library 15.0
Headline                        : Single Euro Payment Area (SEPA)
Page Layout                     : OneColumn
Page Mode                       : UseOutlines
Page Count                      : 87

EXIF Metadata provided by EXIF.tools

Business Guide GPP SEPA

Navigation menu

Versions of this User Manual:

Views

Navigation