Ebacl Ips 20161130 Ips Functional Description v09 Draft PWG Clean

SEPA INSTANT CREDIT TRANSFER
Functional Description
The present document is a draft of the functional description for EBA CLEARING’s
future Pan-European Instant Payment Infrastructure Solution (“IPS”). The language
contained herein is still subject to changes and/or adjustments, e.g. to take into
account possible changes in the settlement mechanism as will be made available by
provider or the finalisation of the legal design. Particular attention is drawn to the
fact that the draft language herein is not intended to reflect the legal basis for the
future system and its settlement arrangements.
The contents hereof may not be disclosed and are confidential to the institutions
participating in the design of the solution and having access to the works of the
Instant Payment Project Working Group. This document and the contents hereof
may not be disclosed, copied or distributed by the recipient institutions to any other
person or entity.
Status: V0.9 DRAFT

Classification: Confidential
Document Release date: 30/11/2016
Effective date: 21 November 2017 08:00 CET
Copyright ©, 2016, EBA CLEARING

This document is the property of EBA CLEARING S.A.S
The information contained herein is confidential and proprietary.
Distribution of this document is restricted to permitted recipients having access to the works of
the Instant Payment Project Working Group only.
IPS Classification: Confidential
Functional description
HISTORY OF MODIFICATIONS
Version Date Authored by

0.1 V20160414 DRAFT EBA CLEARING First draft
0.2 V20160504 DRAFT EBA CLEARING Settlement mechanism added based discussions IP-
PWG and Settlement sub group
0.3 V20160606 DRAFT EBA CLEARING  Review IP-PWG
 Update with SCT Inst Rulebook V0.1 for public
consultation
 Review Legal & Compliance
0.4 V20160628 DRAFT EBA CLEARING Second review IP-PWG
 Change all transaction related messages to real-
time message processing
0.5 V20160721 DRAFT EBA CLEARING Draft for publication interested future users
0.6 V20161006 DRAFT EBA CLEARING Draft updated to SCT Inst Rulebook V0.3 and IP-PWG
decisions
0.7 V20161028 DRAFT EBA CLEARING Review and inclusion of ASI6 Real Time procedure
0.8 V20161114 DRAFT EBA CLEARING Workflows updated to SCT Inst Rulebook V0.8
0.9 V20161130 DRAFT EBA CLEARING Updates due to SCT Inst Rulebook V1.0
Table 0-1 Change History
V0.9 DRAFT, Updated 30/11/2016

2/59
CONTENTS
1 INTRODUCTION ................................................................................................ 6
1.1 Purpose and scope of document ...............................................................................................7
1.2 About this version .......................................................................................................................7
1.3 Overview .......................................................................................................................................7
1.4 References ...................................................................................................................................8
1.5 Glossary .......................................................................................................................................9
2 GENERAL CONCEPTS ................................................................................... 11

2.1 The Four Corner model ............................................................................................................ 11
2.2 Instant Payments Clearing ...................................................................................................... 13
2.3 R-messages .............................................................................................................................. 13
2.3.1 Pre-settlement R-messages ................................................................................................ 14
2.3.2 Post-settlement R-messages .............................................................................................. 14
2.4 Investigation messages ........................................................................................................... 14
2.5 Interbank Settlement Date ....................................................................................................... 15
2.6 Directories and Registers ........................................................................................................ 15
2.7 Transaction References ........................................................................................................... 15
2.8 Value Added Services .............................................................................................................. 16
3 IPS PROCESSING OVERVIEW ...................................................................... 17

3.1 Positive SCT Inst Message Workflow ..................................................................................... 18
3.2 Exceptional SCT Inst Message Workflows ............................................................................ 19
3.2.1 Rejections ............................................................................................................................ 19
3.2.2 Timeouts .............................................................................................................................. 21
3.2.3 Investigations ...................................................................................................................... 26
3.2.4 Special Events..................................................................................................................... 36
4 REAL-TIME MESSAGES................................................................................. 38
4.1 Message processing concepts ............................................................................................... 38
4.2 SCT Inst Messages ................................................................................................................... 38
4.2.1 SCT Inst Credit Transfer (pacs.008) ................................................................................... 38
4.2.2 Payment Status Report (pacs.002) ..................................................................................... 38
4.2.3 Recall Request (camt.056) .................................................................................................. 38
4.2.4 Positive Response to a Recall (pacs.004) .......................................................................... 39
4.2.5 Negative response to recall (camt.029) .............................................................................. 39
4.2.6 SCT Inst Status Inquiry Message (pacs.028) ..................................................................... 39
5 TRANSACTION VALIDATION AND ROUTING .............................................. 40

5.1 Timings ...................................................................................................................................... 40
5.2 Transaction Validation ............................................................................................................. 40

3/59
5.3 Processing at network level .................................................................................................... 40

5.4 Routing ...................................................................................................................................... 40
6 LIQUIDITY MANAGEMENT AND SETTLEMENT ........................................... 43

6.1 Summary ................................................................................................................................... 43
6.2 Dedicated technical account ................................................................................................... 43
6.3 Liquidity Adjustment Cycles ................................................................................................... 43
6.4 Settlement model ...................................................................................................................... 45
6.5 Remuneration policy ................................................................................................................ 46
6.6 Liquidity pooling ....................................................................................................................... 46
7 RECONCILIATION........................................................................................... 48
7.1 Transaction status .................................................................................................................... 48
7.2 Liquidity position ...................................................................................................................... 48
7.3 Mapping of T2I data in TARGET2 output ............................................................................... 48
7.3.1 Unstructured Remittance Information field .......................................................................... 49
7.3.2 MT900/MT910 messages ................................................................................................... 49
7.3.3 MT940/MT950 messages ................................................................................................... 49
7.3.4 Mapping of T2I data ............................................................................................................ 50
8 REPORTING AND OTHER EXCHANGES ...................................................... 52

8.1 Daily Reconciliation Report (DRR) ......................................................................................... 52
9 INTERFACES .................................................................................................. 54
9.1 Graphical User Interface .......................................................................................................... 54
9.1.1 General ................................................................................................................................ 54
9.1.2 Liquidity Management ......................................................................................................... 54
9.1.3 Inquiries ............................................................................................................................... 55
9.1.4 Configuration Management ................................................................................................. 55
9.1.5 System Events and Alerts ................................................................................................... 55
9.1.6 Dedicated Network Connection ........................................................................................... 55
9.2 Application Programming Interface ....................................................................................... 56
9.3 Networking Interface ................................................................................................................ 56
10 OTHER SERVICES .......................................................................................... 57

10.1 Testing Services ....................................................................................................................... 57
10.2 Helpdesk .................................................................................................................................... 57
11 APPENDIX A: IPS PARAMETERS.................................................................. 58

4/59
TABLE INDEX
Table 0-1 Change History ........................................................................................................................2

Table 1-1: Glossary ............................................................................................................................... 10
Table 7-1: MT940/950 Tag 61 breakdown ............................................................................................ 50
Table 7-2: Mapping T2I data to MT9xx messages ............................................................................... 50

5/59
1 Introduction
Rapidly evolving technology and new customer requirements have driven in the recent years a major
innovation thrust in the payments industry. At this stage, it is generally understood that new payment
services have to evolve towards immediate execution of payment orders followed by (near) real-time
availability of funds for the beneficiary.
As a result, various initiatives were taken around the world with the aim of improving the efficiency and
effectiveness of payment infrastructures, focusing mainly on enhanced speed, more transparency and
convenience for the end user as well as an extension to 24/7 availability, both at a domestic and at a
cross-border/global level.
On 12th November 2014, the ECB issued an input paper for the Euro Retail Payments Board (ERPB),
providing a definition of “instant payments” (24/7 availability, immediate reusability of funds and close to
immediate interbank clearing), expressing an expectation for at least one pan-European euro instant
payment infrastructure solution in the short-term. The paper further underlined the need to avoid the
emergence of incompatible and non-standardised solutions and the resulting fragmentation of the
payment services market in SEPA.
In its meeting on 1st December 2014, the ERPB acknowledged all of the above outlined ECB statements
and further described the offerings of e.g. person-to-person mobile payments in euro being significantly
depending on the availability of instant clearing services.
With its background as an infrastructure solutions provider to the European payments market, EBA
CLEARING has decided to work towards contributing to the creation of a pan-European solution for
instant payment processing.
It was notably decided to prepare for possible services to respond to demands in the infrastructure layer,
and to create a taskforce composed of user representatives to concentrate the work of EBA CLEARING
with the users on this matter
EBA CLEARING will offer an Instant Payment System (IPS) based on the SEPA Instant Credit Transfer
Scheme which is characterised by the following:
 EPC SCT Inst Rulebook compliant;
 24/7 Availability;
 A central system, validating, routing and storing payments;
 Certainty of settlement;
 Maximum level of straight-through processing;
 ISO20022 XML message support;
 TARGET2 Ancillary System Interface (ASI) compliant settlement interface;
 Graphical User Interface (GUI) and Application Programming Interface (API) support;
 Network independent architecture supporting SWIFTNet1, SIANet and EBICS2.
1 SWIFTNet is supported by the IPS network architecture but will be available after November 2017.
2
Feasibility study if and how EBICS could be best implemented is ongoing and is expected to be concluded by the end of 2016.

6/59
1.1 Purpose and scope of document

This document presents a functional description of the IPS designed by EBA CLEARING. Capitalised
terms not otherwise defined herein are further defined in the glossary (see 1.5).
Although it can be read in isolation, to fully understand this document the reader should be familiar with
the referenced documents (see 1.4).
The business principles expressed in this document are further developed in the SCT Inst Interface
Specifications. The SCT Inst Interface Specifications describes at a technical level the exchange of data
between the SCT Inst Participants and the SCT Inst System, allowing the SCT Inst Participants to
develop their internal systems to support the data exchange.
The SCT Inst System will be configured via a number of parameters. These are applicable at various
levels. Configuration parameters are listed for reference in Appendix A.
1.2 About this version

This version is a draft version of the functional description which is available to interested future users
of the IPS. The document was drafted together with the IP-PWG which includes the funding banks of
the IPS. The draft is made available to allow Participants to start the implementation of their interfaces
with IPS at an early stage.
It is expected that new versions of this document will emerge before the system will go live in November
2017. This version 0.8 specifically includes the following changes:
 The IPS will at all times be Rulebook compliant and therefore changes could be possible to align
with the latest version of the SCT Inst scheme after publication. This version is aligned with version
0.8 of the rulebook, which is the version that is expected to be approved by the EPC Board for
publication on 30-11-2016. In that respect this version of the functional description has changed
from a “no-news-is-good-news” to a “no-news-is-bad-news” message flow with an additional time-
out control at CSM level.
 A number of changes have been added at the request of the IP-PWG with regard to reconciliation
(additional information in the reports, reporting 7 days per week).
 In addition, the document has been aligned with terminology used in the legal documentation which
is currently being prepared.

 The ECB agreed to make available a new “ASI-6 real time” procedure for CSMs operating an instant
payment system. This decision has been positively acknowledged by EBA CLEARING and its
funding users as it avoids using cycles and sub-accounts and will facilitate interoperability. The first
live release will support the “ASI-6 real time” interface, to avoid Participants would have to change
to a different model later-on.
1.3 Overview
The Instant Payment System is a high volume, commercial and consumer Instant Payment processing
system based on a credit transfer mechanism capable of routing SCT Inst Transactions between SCT
Inst Participants. Payments are settling in real-time in the IPS based on a positive position Participants

7/59
have which is created based on liquidity ring-fenced from these Participants in central bank money via
an ancillary system interface with TARGET2.
Account Servicing PSPs may subscribe to the SCT Inst Service as SCT Inst Participants. Alternatively,
an entity may connect through an existing SCT Inst Participant which will require the inclusion of the
entity in the SCT Inst Routing Table as an Addressable PSP.
SCT Inst Participants may send via the SCT Inst Service (i) SCT Inst Messages, (ii) Confirmation
Messages and Rejection Messages, (iii) Status Inquiry Messages, as well as (iv) Recall Messages and
Positive and Negative Result of Investigation Messages, formatted in accordance with ISO20022 XML
standards over secure network connections. The format of the messages must comply with the IPS SCT
Inst Interface Specifications [1].
In line with the SCT Inst Rulebook, the IPS does not allow SCT Inst Participants to send (pre-settlement)
cancellation messages in connection with individual SCT Inst Transaction. In order to cancel the effects
of an SCT Inst Message, the Originator SCT Inst Participant can submit a Recall message within the
prescribed number of days following the Interbank Settlement Date.
SCT Inst and Positive responses to a Recall Messages can be accepted for processing provided that
sufficient liquidity is available and ring fenced. The IPS will update the liquidity position for each
participant in real time. The liquidity position in the IPS is guaranteed by central bank money placed on
a dedicated technical account managed by the IPS system. Participants can fund and defund their
position by requesting to ring fence additional, or release excess liquidity. Funding and defunding of the
Participant’s position will be managed by moving funds between the IPS’s technical account linked to
the “ASI-6 real time” procedure in TARGET2 and the settlement (RTGS) account of the participant..
The IPS will regularly make available reports to each participant to provide reconciliation information as
well as management reporting.
SCT Inst Participants also have access to interactive services through the IPS-PWS and through APIs.
These interfaces provide real-time information about the Participant’s position, the status of its
transactions in the IPS. These interfaces also allow to do inquiries, request reports and routing table
information and allows the Participant to manage its configuration in the system.
1.4 References
The following documents provide additional information on the SCT Inst Service.
Title Issued by
[1] EBA CLEARING SCT Inst Interface Specifications EBA CLEARING
[2] SCT Inst Implementation Guidelines (not yet available) EPC
[3] SCT Inst Rulebook V0.8 EPC
[4] IPS SCT Inst IPS-WS User manual EBA CLEARING
[5] IPS SCT Inst User Manual (not yet available) EBA CLEARING
[6] IPS SCT Inst API specifications EBA CLEARING

8/59
1.5 Glossary
Term Meaning
ACH Short notation for “Automated Clearing House”;
An entity which, based on its bilateral contractual relationship to a Participant,
may send to and receive electronic files from a Participant outside the scope
Addressable PSP or AP
of a given SCT Inst Service, which will be listed in the SCT Inst routing tables
as reachable via its Participant.
AOS Additional Optional Service
API Application Programming Interface
ASI Ancillary System Interface
BB Beneficiary Bank. The account servicing PSP that holds the account of the
Beneficiary
Bank Identification Code. SWIFT standard for identification of banks within
BIC
payment instructions.
Central System (CS) Processing engine used to perform all IPS processing activities.
Daily Reconciliation Report Report transmitted daily to every Participant by the Central System for a
(DRR) Settlement Date that includes summary information to assist reconciliation.
Short notation for “End Of Day”;
EOD
Indicates the end of the business day;
ERPB Euro Retail Payments Board
System(s) external to the SCT Inst Service used by the Central System to
External Settlement
process the settlement obligations arising from the clearing of payment
Mechanism (ESM)
instructions.
GUI Graphic User Interface
IPLM Instant Payment Liquidity Module
IPS Instant Payment System: the Central System
IPTM Instant Payment Transaction Module
LAC Liquidity Adjustment Cycle
LAF Liquidity Adjustment File
Entity admitted to participate in EBA CLEARINGS IPS, authorised to directly
Liquidity Serviced
sending and receiving messages but relying on an entity with a Participant
Participant or LSP
status or Settlement Bank / Agent for settlement
Report can be (optionally) transmitted to a Participant by the Central System
Monthly Statistics Report
following the completion of the last LAC of the last Settlement Date for a
(MSR)
calendar month that includes statistical information to assist charging.
OB Originator Bank. The account servicing PSP that holds the account of the
Originator.
Entity admitted to participate in EBA CLEARINGS IPS, authorised to directly
Participant
send and receive messages and having a direct access to settlement.
PSP Payment Service Provider
Report transmitted by the Central System to Participants at the end of the
input phase of each Settlement Cycle for a Settlement Date and including
Pre-Settlement Report (PSR)
information on the amounts which are going to be settled in that Settlement
Cycle, crediting or debiting the receiving Participant

9/59
Term Meaning
The Originator Bank requests a Recall of a previously settled SCT Inst
transaction sending a Payment Cancellation Request (camt.056) message to
Recall Procedure
the Beneficiary Bank, which could answer with a Positive Response to a Recall
(pacs.004) or a Negative Response to a Recall (camt.029)
NRR Negative Response to a Recall of a SCT Inst transaction
PRR Positive Response to a Recall of a SCT Inst transaction
Routing The process of selecting a Receiver for a payment instruction.
The sender of a message is the Participant or Liquidity Serviced Participant
from whom the Central System directly receives the message (and whose BIC
Sender is the in the Sending Institution field of the message header).
The sender of a payment instruction within a message is the sender of the
message within which the payment instruction is contained.
Sender’s File Reference Unique reference allocated to every file.
A processing facility offered by the Instant Payment Service, e.g. €-
Service
denominated, cross border SEPA Instant Credit Transfers.
A standard file of payment instructions that have been successfully processed
Settled Credit File (SCF)
by the Central System and are transmitted to the receiving Participant.
Settlement BIC The BIC by which a Participant is known in an ESM.
T2I IPS TARGET2 Interface
Trans-European Automated Real-time Gross settlement Express Transfer
TARGET2 or T2 system. TARGET2 is the real-time gross settlement (RTGS) system owned
and operated by the Eurosystem.
Extensible Mark-up Language. Language that is used to specify information
XML
exchange formats.
Table 1-1: Glossary

10/59
2 General Concepts
This section intends to provide a helpful background of the IPS setup.
2.1 The Four Corner model

The Four Corner Model describes the contractual relationships that bind the main actors, i.e. Originator
and Beneficiary; Originator Bank and Beneficiary Bank. The Originator Bank and the Beneficiary Bank
exchange transactions via a Clearing and Settlement Mechanism (EBA CLEARING’s IPS in this case).
Originator Beneficiary
$ $
IPS
Originator Beneficiary
Bank Bank
Scheme
Figure 2-1: The four corner model
PSPs may be represented (from the perspective of the IPS as a CSM) as an SCT Inst Participant that
exchanges data directly with the system, or as an Addressable PSP that exchanges data via an SCT
Inst Participant.
The IPS acts in the inter-PSP space only, and does not deal with processing between PSP and their
customers.
SCT Inst Messages are submitted to the IPS by the Originator Bank either directly (as an SCT Inst
Participant) or indirectly (as an Addressable PSP, via an SCT Inst Participant). Similarly, the Beneficiary
Bank may receive SCT Inst Messages from the IPS either directly (as SCT Inst Participant) or indirectly
(as Addressable PSP, via an SCT Inst Participant).

11/59
Figure 2-2: IPS eco-system
SCT Inst Participants can manage their own position through TARGET2 or could manage their position
through another Participant in which case they are referred to as Liquidity Services Participants (LSP).
Liquidity Serviced Participants have an agreement with a Participant to provide access to the settlement
mechanism (i.e. the Participant ring fences liquidity for the Liquidity Serviced Participant to allow the
Liquidity Serviced Participant to have a position in the IPS and process transactions).
Each Participant can have direct technical access to the platform, or can choose to connect through a
Technical Service Provider (TSP)3.
SCT Inst Participants are registered in the IPS Routing Tables as 8 character BICs (BIC8) while SCT
Inst Addressable PSPs are registered as 11 character BICs (BIC11). SCT Inst Addressable PSPs may
be branches of the SCT Inst Participants, subsidiaries, affiliated banks, or other PSPs that have agreed
to use the services of the SCT Inst Participant to exchange payments with other SCT Inst Participants
or SCT Inst Addressable PSPs.
The IPS sorts out the BIC of the SCT Inst Message’s addressee, finds a match among the SCT Inst
Participants and delivers the SCT Inst Message to the relevant SCT Inst Participant. The relevant SCT
Inst Participant will settle all transactions with their Addressable PSPs bilaterally.
For PSPs with a large number of branches sharing the same BIC8, Addressable PSPs can be registered
with ‘XXX’ in the 9th to 11th characters of the BIC to signify that any of the branch codes are addressable.
SCT Inst Messages sent to that BIC8 or any BIC11 sharing the first 8 characters will be routed to the
SCT Inst Participant.
The IPS never changes the value of the BIC in the message.
The SCT Inst Participant is responsible for providing EBA CLEARING with the relevant information about
their Addressable PSPs for inclusion in the IPS Routing Tables.
3
The positioning of the TSP in the legal framework is currently under discussion.

12/59
2.2 Instant Payments Clearing

Clearing is defined by the EPC as “The process of transmitting, reconciling and, in some cases,
confirming payment orders prior to Settlement, possibly including the netting of instructions and the
establishment of final positions for Settlement.”
The Instant Payment System is designed to perform clearing and settlement for the SCT Inst
Transactions. SCT Inst Transactions can be accepted for processing provided that sufficient liquidity is
available and ring fenced. The Participants’ positions in the IPS are guaranteed at all times by an
equivalent amount of central bank money placed on a dedicated account in TARGET2.
Upon reception of an SCT Inst Transaction, IPS will block the funds on the sending SCT Inst Participant’s
position and will forward the message to the receiving SCT Inst Participant which will forward it to the
Beneficiary Bank whenever appropriate. When the positive confirmation from the Beneficiary Bank is
received by IPS the liquidity position for each participant is updated in real time. Funds blocked on the
sending participant’s position are deducted and the position of the receiving SCT Inst Participant is
increased with the same amount. At this moment, the SCT Inst transaction is final in accordance with
the principles of the Settlement Finality Directive.
The liquidity positions in IPS can be adjusted by the SCT Inst Participants manually or via the API as
well as by pre-configured automatic liquidity adjustments set by the Participant. Liquidity adjustments in
IPS trigger a transfer of central bank money in TARGET2 between the TARGET2 account of the SCT
Inst Participant and the TARGET2 technical account of IPS where central bank money is ring fenced.
The interface with TARGET2 will be based on ASI-6 real time procedure.
2.3 R-messages
The different types of R-messages described in the SCT Inst Interface specification are: Payment Status
message (as Positive or Negative confirmation), Recall message, Recall response message (as Positive
Response to a Recall - PRR or Negative Response to a Recall - NRR) (collectively known as R-
messages).
These message types can be used by the Originator Bank or the Beneficiary Bank. All R-messages are
exchanged through IPS in real-time as single messages. This does not imply that a positive or negative
response to a Recall message has to be sent in seconds after the Recall was delivered. But when the
recall or recall response is sent to the central system, it is delivered to the next party in the chain within
seconds later.
The diagram below displays the timeline (Pre or post settlement of the referred SCT Inst Transaction)
and the instructing party of each specific R-message (sender can be the Originator Bank or the
Beneficiary Bank depending on the message type):

13/59
Pre-Settlement
Beneficiary Bank
Originator Bank
Positive or
Negative
Confirmation
Positive or
Negative
Recall answer to a
Recall
Post-Settlement
Figure 2-3: R-messages processed by IPS
2.3.1 Pre-settlement R-messages

A ‘Reject’ occurs when an SCT Inst Transaction is not accepted for normal processing by CSM or the
Beneficiary Bank (Negative confirmation).
The effect of the negative confirmation from the Beneficiary PSP is that the reservation on the position
of the Participant representing the Originator Bank will be removed and the funds transfer will not be
executed.
2.3.2 Post-settlement R-messages

A ‘Recall’ occurs when the Originator Bank requests to cancel a settled SCT Inst Transaction, while a
Positive Response to a Recall is a positive answer of the Beneficiary Bank to a ‘Recall’. Within the IPS
a ‘Recall’ is known as a Payment Cancellation Request (camt.056)Error! Reference source not found.
and a Positive Response to a Recall is known as a Positive Response to a Recall (pacs.004).
Post-settlement R-messages are processed in the IPS without performing any matching with the original
SCT Inst Message.
The possible answers to a ‘Recall’ message can be either a Positive Response to a Recall (pacs.004)
or a Negative response to recall (camt.029).
2.4 Investigation messages

The Originator Bank can send an Investigation Message (to be confirmed by the EPC Implementation
Guidelines: pacs.028) in case it has not received a reply to an SCT Inst Transaction after a period of
time defined by the SCT Inst Rulebook of the EPC. The IPS will verify the status of the transaction

14/59
subject to the inquiry. In case the SCT Inst Transaction triggering the Investigation Message is unknown
to the IPS, the IPS will report the non-delivery of this SCT Inst Transaction to the Participant representing
the Originator Bank. In case this SCT Inst Transaction and its status (accepted/rejected) are known to
the IPS, the IPS will (re-)send the confirmation / rejection of the original message. In case the SCT Inst
Transaction was forwarded and the status is unknown to the IPS (i.e. “pending” status), the IPS will
forward the Investigation message to the next party in the chain.
2.5 Interbank Settlement Date

The Interbank Settlement Date of an SCT Inst Transaction Message as well as a Positive Response to
a Recall Message is specified by the Originating Bank in the Message. Each of these messages will
settle immediately in the IPS after it has been confirmed that the message can be processed by the
Beneficiary Bank. It is the date on which the funds are made available to the Beneficiary Bank. After the
transaction has been executed and the positions of both Participants have been updated, the Participant
action on behalf of the Beneficiary Bank has immediately access to its funds in IPS.
Settlement of the SCT Inst Message in IPS takes place when the positive confirmation from the
Beneficiary Bank is received by IPS. In some rare cases, the SCT Inst Transaction forwarded to the
Beneficiary Bank shortly before midnight will be confirmed and final settlement will occur on the next
calendar day (i.e. seconds later). Nevertheless, IPS will not change the Interbank Settlement Date set
by the Originating Bank.
2.6 Directories and Registers

EBA CLEARING publishes a list of the BICs that are reachable in the SCT Inst Service in the IPS Routing
Tables through a machine readable interface as well as through the IPS-PWS. SCT Inst Participants
and Addressable PSPs each are listed in a separate Routing Table. The Routing Tables are used for
the distribution of both SCT Inst Messages and R-Messages.
Organisations independent from EBA CLEARING may publish reference data that attempts to
consolidate information found in the IPS Routing Table. This is a commercial service between the
provider and any banks that subscribe. This is out of the scope of the IPS.
2.7 Transaction References

Transaction references across the multiple layers involved in the payment flow are managed according
to the ISO20022 standard and use a referencing model including end to end references and point to
point references. The relationships between references across layers are summarised below:

15/59
End-to-End Reference
Instruction Reference
C1 B1 B2 B3 B4 C2
Transaction Reference
Figure 2-4: System Reference fields
Legend:
 C1 and C2 are customers (Originator and Beneficiary);
 B1, B2, B3 and B4 are banks;
 B1 is the bank of the Originator,
 B2 and B3 are intermediary banks in the chain (i.e. Participant Banks) and
 B4 is the bank of the Beneficiary.
In the IPS, B2 and/or B3 are optional in the case that the Originator Bank and/or Beneficiary Bank are
Participant Banks and not Addressable PSPs.
The ISO20022 Standard provides for three reference fields:
 The “End-to-End Reference” is carried through the IPS and identifies the Originator’s reference
for the transaction with the Beneficiary.
 The “Transaction Reference” is unique within the Originator Bank. It is set by the first bank in the
chain and identifies the message until it reaches the last bank in the chain. Either or both of these
banks can be Addressable PSPs. The IPS uses this field as part of the unique key identifying SCT
Inst Transactions and R-messages.
 The “Instruction Reference” is unique within the Originator Bank only. It identifies the message
as it passes between individual parties and changes each time it is transmitted.
A combination of the Originator Bank BIC, Transaction Reference and the Acceptance Date &
Time as provided to the IPS in the SCT Inst Transaction Messages, identifies the transactions
uniquely throughout the whole chain. The IPS checks that any reference used are unique on a
particular business day.
2.8 Value Added Services

During the second half of 2016 the IP-PWG will evaluate which Value Added Services will be required
to be added to the IPS.

16/59
3 IPS Processing Overview
Each Participant can exchange messages with other Participants in the IPS 24x7x365.
The scope of the IPS is only on the interaction between the CSM and its Participants (potentially acting
on behalf of the Originator Bank and Beneficiary Bank). All interaction with the Originator or Beneficiary
are out of the scope and are the responsibility of their respective PSP’s.
Processing of the messages between the CSM and its Participants are guaranteed to be done in 1.5
seconds. The diagram below gives a graphical overview of the relevant steps.
Figure 3-1: IPS Processing overview
The IPS supports both the technical acknowledgement and the formal notification as mentioned in the
EPC Rulebook 4 as a means of informing the Beneficiary Bank of receipt of the confirmation message.
The technical message is based on the ACK message that is automatically sent by the network upon
receipt of the confirmation message from the Beneficiary Bank while the formal notification is based on
the Payment Status Report (pacs.002) and is detailed in [2]. The IPS sends the formal notification by
default and SCT Inst Participants have the possibility to opt-out of this message.
For each Addressable PSP that a Participant manages it can indicate, by means of a “time-out” flag, if
the IPS should handle the time-out or that it will handle the time-out itself. This “time-out flag” will
determine the behaviour of the IPS in the case that no confirmation has been received before the time-
out period has passed. If the flag is “YES”, the IPS will reject the related SCT Inst Transaction once it
has passed the time-out deadline. If the flag is “NO”, the IPS will change the status of the SCT Inst
Transaction from “in flight” to “pending” and will go into a wait state until it receives a response from the
Beneficiary Bank.
In the following paragraphs you will find details regarding the positive workflow as well as possible
exceptions.
4
See chapter 1.4 (“Conceptual work flow of an SCT Inst”) in [3] for more details

17/59
3.1 Positive SCT Inst Message Workflow

1. Positive SCT Inst Message Workflow
Originator Originator Bank IPS Beneficiary Bank Beneficiary
1. Initiate IP order
2. Validate and
send IP message
3. Validate, block
OB and forward 4. Validate, make
funds available,
informs B
(optional)
5. Generate and
send positive
confirmation
6. Validate, debit
OB, credit BB and
8. Receives
forward
confirmation and
informs O 7. Receives
9. Notification of (optional) confirmation,
final status makes funds
available to B
7a. Funds are
available
Time
Figure 3-2 EPC Workflow - Scenario 1
1. The Originator initiates an SCT Inst Instruction,

2. The Originator Bank 5 receives the SCT Inst Instruction, creates an SCT Inst Transaction
Message and forwards it to the IPS,
3. The IPS positively validates the message, blocks the position of the Participant representing
the Originator Bank for the amount of the transaction and forwards it to the Participant
representing the Beneficiary Bank,
4. The Beneficiary Bank receives the SCT Inst Transaction Message and positively validates it,
5. The Beneficiary Bank creates a positive confirmation and sends this confirmation to the IPS
6. The IPS receives the positive confirmation, debits the position of the Participant representing
the Originator Bank, credits the position of the Participant representing the Beneficiary Bank
and forwards the confirmation to the Originator Bank,
7. The Beneficiary Bank makes the funds available to the Beneficiary Bank after receiving either
the technical acknowledgement message or the formal notification and makes the funds
available to the Beneficiary,
a. Funds are made available to the Beneficiary,
5
The word “Bank” is used as per the rulebook definitions.

18/59
8. The Originator Bank receives the positive confirmation and (optionally) sends a notification to
the Originator,
9. The Originator is notified of the final status of the SCT Inst Transaction.
3.2 Exceptional SCT Inst Message Workflows
3.2.1 Rejections
Rejection Messages are used when the SCT Inst Transaction cannot be processed by a party in the
chain and thus funds have not been made available to the Beneficiary. A Rejection can be initiated by
the IPS and by the Participant representing the Beneficiary Bank. Only scheme compliant reason codes
can be used, as specified in the IPS Interface Specifications [1].
The following paragraphs detail the possible rejection scenarios that the IPS can handle.
3.2.1.1 Rejection by Beneficiary Bank
In this scenario the Beneficiary Bank rejects an SCT Inst Transaction, for example because the
Beneficiary is unknown.
2. RejectIon by Beneficiary Bank
1. Instant payment
order initiation
2. Validate and
send IP message
3. Validation and
forward 4. Negative
Validation
5. Negative
confirmation
6. Receive generation
confirmation and
forward
7. Receive
confirmation and
forward
8. Notification on
the final status
Time
Figure 3-3 EPC Workflow Scenario 2

2. The Originator Bank receives the SCT Inst Instruction, creates an SCT Inst Transaction and
the Participant representing the Originator Bank forwards it to the IPS,

19/59
the Originator Bank for the amount of the transaction and forwards the SCT Inst Transaction
to the Participant representing the Beneficiary Bank,
4. The Beneficiary Bank receives the SCT Inst Transaction and rejects it,
5. The Beneficiary Bank creates a Rejection and the Participant representing the Beneficiary
Bank sends it to the IPS,
6. The IPS receives the Rejection, removes the block on the position of the Participant
representing the Originator Bank and forwards the Rejection to the Participant representing
the Originator Bank,
7. The Originator Bank receives the Rejection and sends a notification to the Originator,
8. The Originator is notified of the final status of the SCT Inst Instruction.
3.2.1.2 Rejection by IPS

In this scenario the IPS rejects an SCT Inst Transaction, for example because the Beneficiary Bank is
unknown.
3. RejectIon by IPS
1. Instant payment
order initiation
2. Validate and
send IP message
3. Negative
validation
4. Create and
forward negative
5. Receive confirmation
confirmation and
6. Notification on forward
the final status
Time
Figure 3-4 EPC Workflow Scenario 3

Participant representing the Originator Bank forwards it to the IPS,
3. The IPS cannot validate the SCT Inst Transaction (valid reasons for rejection as defined in the
IPS Interface Specifications [1], including: invalid message, beneficiary bank not included in
the reach tables, insufficient funds Participant representing originator bank, etc.) (accordingly
positions of Participants do not change).
4. The IPS creates a Rejection and sends it to the Participant representing the Originator Bank,

20/59
5. The Originator Bank receives the Rejection and sends a notification to the Originator,
3.2.2 Timeouts
Timeouts result from messages which are not being able to be processed within the timeout deadline.
The IPS has three timeout controls:
 When receiving an SCT Inst Transaction, the IPS will validate that the message has been
received within the SCT Inst Scheme time-out deadline (i.e. timestamp plus 20 seconds). If this
is not the case, a rejection will be sent to the Participant representing the Originator Bank;
 When forwarding an SCT Inst Transaction, the IPS will validate that the message is delivered
within the SCT Inst Scheme time-out deadline (i.e. timestamp plus 20 seconds). If the message
cannot be delivered in time, the IPS will reject the message to the Participant representing the
Originator Bank;
 For each Addressable PSP that a Participant manages it can indicate, by means of a “time-out”
flag, if the IPS should handle the time-out or that it will handle the time-out itself. This “time-out
flag” will determine the behaviour of the IPS in the case that no confirmation has been received
before the time-out period has passed. If the flag is “YES”, the IPS will reject the related SCT
Inst Transaction once it has passed the time-out deadline. If the flag is “NO”, the IPS will change
the status of the SCT Inst Transaction from “in flight” to “pending” and will go into a wait state
until it receives a response from the Beneficiary Bank. In case the Beneficiary Bank is a
Participant in the system, IPS will always time-out once it has passed the time-out deadline.

The following paragraphs detail the possible timeout scenarios that the IPS can handle.
3.2.2.1 Originator Bank cannot reach IPS
In this scenario the Originator Bank rejects an SCT Inst Transaction because it has not managed to
forward the SCT Inst Transaction in time to the IPS.

21/59
4. Originator Bank cannot reach IPS

EPC Timeout Limit
1. Instant
payment order
initiation 2. Validate and 2a. IP message
send IP message not received
3. No response
4. Notification on
the final status
Time
Figure 3-5 - EPC Workflow - Scenario 4

the Participant representing the Originator Bank sends it to the IPS,
a. The IPS does not receive the SCT Inst Transaction and no positions are updated,
3. The Originator Bank does not receive a response within the time limit,
3.2.2.2 IPS receives SCT Inst Transaction after the SCT Inst time-out deadline from
Originator Bank
In this scenario the IPS rejects an SCT Inst Transaction because it has received the SCT Inst
Transaction after the SCT Inst time-out deadline from the Participant representing the Originator Bank.

22/59
5. IPS receives SCT Inst Transaction too late from Originator Bank

EPC Timeout Limit
1. Instant payment
order initiation 2. Validate and
send IP message
3. Rejection due to
Timeout
4. Receive and
forward
5. Notification on
the final status
Time
Figure 3-6 - EPC Workflow - Scenario 5
1. The Originator initiates a SCT Inst Instruction,

2. The Originator Bank receives the SCT Inst Instruction, creates an SCT Inst Transaction which
is sent by the Participant representing the Originator Bank to the IPS,
3. The IPS receives the SCT Inst Transaction after the SCT Inst time-out deadline, creates a
negative confirmation (reject due to timeout) and sends it to the Participant representing to
Originator Bank,
4. The Originator Bank receives the negative confirmation and sends a notification to the
Originator,
3.2.2.3 Rejection by IPS (Beneficiary Bank temporary unavailable)

In this scenario the IPS rejects an SCT Inst Transaction because it has not managed to forward the SCT
Inst Transaction in time to the Participant representing the Beneficiary Bank.

23/59
6. Rejection by IPS (Beneficiary Bank temporary unavailable)
1. Instant payment
order initiation
2. Validate and
send IP message 3. Validation and
forward, BB
unavailable
4. Forward
negative
5. Receive confirmation
confirmation and
6. Notification on forward
the final status
Time

Participant representing the Originator Bank forwards it to the IPS,
3. The IPS positively validates the SCT Inst Transaction, blocks the position of the Participant
representing the Originator Bank for the amount of the transaction and tries to forwards the
SCT Inst Transaction to the Participant representing the Beneficiary Bank, but the message
cannot be delivered to this Participant. IPS will retry to deliver the message.
4. After the SCT Inst time-out deadline, the IPS removes the block on the position of the
Participant representing the Originator Bank, creates a negative confirmation and send it to
the Participant representing the Originator Bank,
5. The Originator Bank receives the negative confirmation and sends a notification to the
Originator,
3.2.2.4 IPS receives confirmation from Beneficiary Bank after the SCT Inst time-out
deadline
In this scenario the IPS changes an SCT Inst Transaction from “in-flight” to “pending” status because it
has not received a confirmation from the Participant representing the Beneficiary Bank within after the
SCT Inst time-out deadline (20 + 5 seconds) . After the deadline a confirmation is received.

24/59
7. IPS receives confirmation too late from Beneficiary Bank
1. Instant
payment order
initiation 2. Validate and
send IP message
EPC Timeout Limit
3. Validate, block
4. Validate, make
OB and forward
funds available,
informs B
(optional)
5. Generate and
send positive
confirmation
6. Receive and
validate
7. Receives
8. Time-out confirmation,
flag “YES”? makes funds
available to B
No 7a. Funds are
available
9. Txn status
updated to
Pending
Yes
10. Process
positive
confirmation 11. Receives
12. Receive confirmation,
confirmation and makes funds
13. Notification
forward available to B
on the final
status
11a. Funds are
14. Rejection due available
to timeout
16. Receive
15. Receive
17. Notification confirmation and
rejection
on the final forward
status
Time


25/59
3. The IPS positively validates the message, blocks the position of the Participant of the
Originator Bank for the amount of the transaction and forwards the SCT Inst Transaction to
the Participant representing the Beneficiary Bank,
4. The Beneficiary Bank receives the SCT Inst Transaction and positively validates it,
5. The Beneficiary Bank creates a positive confirmation and sends it to the IPS,
6. The IPS receives the confirmation from the Participant representing the Beneficiary Bank after
the SCTinst time-out deadline and validates it,
7. The Participant representing the Beneficiary Bank receives the technical acknowledgement
message and can optionally decide the make the funds available,
8. The IPS verifies the value of the time-out flag for the Beneficiary Bank and determines the
next step; step 9 for “No”, step 14 for “Yes”,
In case the time-out flag is set to NO
9. The IPS has not received a confirmation from the Participant representing the Beneficiary
Bank within the SCT Inst time-out deadline and sets the status of the SCT Inst Transaction to
‘Pending’,
10. The IPS processes the positive confirmation, debits the position of the Participant representing
the Originator Bank, credits the position of the Participant representing the Beneficiary Bank
and forwards the confirmation to the Participant representing the Originator Bank,
11. The Beneficiary Bank receives the formal notification and makes the funds available to the
Beneficiary,
the Originator,
13. The Originator is notified of the final status of the SCT Inst Instruction,
In case the time-out flag is set to YES
Bank within a pre-defined period of time and rejects the SCT Inst Transaction,
15. The Beneficiary Bank receives the rejection,
16. The Originator Bank receives the negative confirmation and (optionally) sends a notification to
the Originator,
3.2.3 Investigations
The EPC Rulebook allows an Originator Bank to start an investigation procedure in the case that it did
not receive a confirmation from the IPS after the time-out deadline expired. When the IPS receives an
SCT Inst Status Inquiry Message it will always send back the current status of the original SCT Inst
Transaction. In the case that the final status of this SCT Inst Transaction has not been reached, the IPS
will forward the SCT Inst Status Inquiry Message to the next party in the chain.
3.2.3.1 Double Confirmations
Double confirmations result from a delay in the network where the IPS receives a positive confirmation
after the timeout deadline and can only occur when the Beneficiary Bank has the time-out flag set to
“No”.

26/59
The first scenario (A) explains a case where the original positive confirmation sent by the Beneficiary
Bank has not been received by the IPS due to network delay. The Beneficiary Bank resends the original
positive confirmation after receiving the SCT Inst Inquiry Message and this second confirmation arrives
before the original confirmation.
The second scenario (B) explains a case where the original positive confirmation sent by the Beneficiary
Bank has not been received by the IPS due to network delay. The Beneficiary Bank resends the original
positive confirmation after receiving the SCT Inst Inquiry Message and the original second confirmation
arrives before the second confirmation.
The IPS can’t distinguish between the two confirmations because the content of each is the exact same.
The IPS will only validate and process the first confirmation it receives, the second confirmation will be
marked as duplicate and will be forwarded to the Participant representing the Originator Bank.
Scenario A

27/59
8. IPS receives double confirmation – Scenario A
1. Instant
payment order 2. Validate and
EPC Timeout Limit
initiation send IP 3. Receive,

message validate and
forward 4. Positive
validation
5. Generate and
send positive
confirmation
7. Send an 6. Txn status

Investigation updated to
pending
8. Receive the
8a. Confirmation 9. Receive
investigation and
from IPS Investigation
forward
Investigation
10. Receive
12. Receive positive reply
Investigation and forward
13. Notification response and 11. Receives
on the final forward confirmation,
status
makes funds
available to B
11a. Funds are
available
14. Receive the

positive
confirmation
Time
Figure 3-9 EPC Workflow - Scenario 8A


28/59
Bank within the SCT Inst time-out deadline and sets the status of the SCT Inst Transaction to
‘Pending’,
7. The Originator Bank creates an SCT Inst Inquiry Message and the Participant representing
the Originator Bank forwards it to the IPS,
8. The IPS receives the SCT Inst Inquiry Message and forwards it to the Participant representing
the Beneficiary Bank,
a. The IPS sends an information message to the Participant representing the Originator
Bank with the current status of the transaction (‘Pending”),
9. The Beneficiary Bank receives the SCT Inst Inquiry Message and re-sends the positive
confirmation to the IPS,
10. The IPS receives the positive confirmation of the SCT Inst Inquiry Message, debits the
Originator Bank’s position, credits the position of the Participant representing the Beneficiary
Bank’s position, updates the SCT Inst Transaction status and forwards the confirmation to the
Participants representing the Originator Bank and the Beneficiary Bank,
Beneficiary,
the Originator,
14. The IPS receives the positive confirmation of the original SCT Inst Transaction, determines
that it is a duplicate and stores it for future reference.

29/59
Scenario B
8. IPS receives double confirmation – Scenario B
1. Instant
EPC Timeout Limit
initiation send IP 3. Receive,

message validate and
forward 4. Positive
validation
5. Generate and
send positive
confirmation
7. Send an 6. Txn status

Investigation updated to
pending
8. Receive the
investigation and
8a. Confirmation 9. Receive
Investigation
forward
from IPS Investigation
10. Receive
12. Receive positive reply
Investigation and forward 11. Receives
13. Notification response and confirmation,
on the final forward makes funds
status 11a. Funds are
available to B
available
14. Receive the

positive
confirmation
Time
Figure 3-10 EPC Workflow - Scenario 8B


30/59
Bank within a pre-defined period of time and sets the status of the SCT Inst Transaction to
‘Pending’,
9. The Beneficiary Bank receives the SCT Inst Inquiry Message and re-sends the positive
10. The IPS receives the positive confirmation of the original SCT Inst Transaction, debits the
position of the Participant representing the Originator Bank, credits the position of the
Participant representing the Beneficiary Bank, updates the SCT Inst Transaction status and
forwards the confirmation to the Participant representing the Originator Bank,
Beneficiary,
the Originator,
14. The IPS receives the positive confirmation for the SCT Inst Inquiry Message, determines that
it is a duplicate and stores it for future reference.
3.2.3.2 Delayed Confirmations

Delayed confirmation result from a delay in the network where the IPS receives a negative confirmation
after the SCT Inst timeout deadline.
Scenario 8 describes the case where the negative confirmation is received by the IPS after the timeout
deadline but before the IPS receives the SCT Inst Inquiry Message. from the Participant representing
the Originator Bank.
Scenarios 9 and 10 describe the case where the negative confirmation is received by the IPS after the
timeout deadline and after the SCT Inst Inquiry Message (or not received at all) in case the Addressable
PSP was configured with the time-out flag set to NO.
The IPS can’t distinguish between the two confirmations because the content of each is the exact same.
The IPS will only validate and process the first confirmation it receives, the second confirmation will be
marked as duplicate and will be forwarded to the Participant representing the Originator Bank.

31/59
9. IPS receives a delayed negative confirmation
1. Instant
initiation send IP
EPC Timeout Limit
3. Receive,
message
validate and 4. Negative
forward validation
5. Generate and
send negative
confirmation
6. Txn status
updated to
Pending
7. Receive,
8. Receive remove block
confirmation and forward
9. Notification
and forward
on the final
status
10. Send an
Investigation
11. Receive
Investigation
investigation
and reply
12. Receive
Investigation
response


32/59
4. The Beneficiary Bank receives the SCT Inst Transaction and negatively validates (rejects) it,
5. The Beneficiary Bank creates a negative confirmation and the Participant representing het
Beneficiary Bank forwards it to the IPS,
Bank within a pre-defined period of time and set the status of the SCT Inst Transaction to
‘Pending’ ,
7. The IPS receives the negative confirmation, removes the block on the position of the
Participant representing the Originator Bank and forwards the confirmation to the Participant
representing the Originator Bank,
the Originator,
11. The IPS receives and validates the SCT Inst Inquiry Message and re-sends the negative
confirmation to the Participant representing the Originator Bank,
12. The Originator Bank receives the negative confirmation.

33/59
10. IPS receives an investigation and then a delayed negative confirmation from BB
1. Instant
initiation
EPC Timeout Limit
send IP message 3. Receive,

validate and 4. Negative
forward validation
5. Generate and
send negative
confirmation
6. Txn status
7. Send an updated to
Investigation pending
8. Receive the
investigation
9. Receive
Investigation
8a. Confirmation and forward

from IPS investigation
10. Receive,
11. Receive remove block
12. Notification Investigation and forward
on the final response and
status forward
13. Receive the

negative
confirmation
Figure 3-3-12 EPC Workflow - Scenario 10

4. The Beneficiary Bank receives the SCT Inst Transaction and negatively validates (rejects) it,
5. The Beneficiary Bank creates a negative confirmation and the Participant representing het
Beneficiary Bank forwards it to the IPS,

34/59
Bank within a pre-defined period of time and set the status of the SCT Inst Transaction to
‘Pending’,
9. The Beneficiary Bank receives the SCT Inst Inquiry Message and re-sends the negative
10. The IPS receives the negative confirmation of the SCT Inst Inquiry Message, removes the
block on the position of the Participant representing the Originator Bank and forwards the
confirmation to the Participant representing the Originator Bank,
the Originator,
13. The IPS receives the negative confirmation of the original SCT Inst Transaction, notices that is
a duplicate confirmation and forwards it to the Participant representing the Originator Bank,

35/59
3.2.4 Special Events

3.2.4.1 Participant Withdraws from IPS
13. Participant withdraws from IPS
1. Instant payment
order initiation 2. Validate and 3. Receive,
send IP message validate and
forward 4. No response
back
5. Txn status
updated to
pending
6. Send an
Investigation 7. Receive the
investigation and
forward
investigation
8. Receive the
7a. Confirmation investigation
from IPS
End of Business Day
9. Participant ends
validity
10. Participant is
suspended instead of
removed
Time


36/59
4. The Beneficiary Bank receives the SCT Inst Transaction but does not provide a confirmation,
Bank within a pre-defined period of time and sets the status of the SCT Inst Transaction to
‘Pending’,
6. The Originator Bank creates an SCT Inquiry Message and the Participant representing the
Originator Bank forwards it to the IPS,
8. The Beneficiary Bank receives the SCT Inst Inquiry Message but does not provide a
confirmation,
9. The daily operations end and the IPS changes to the next business date. No responses have
been received from the Participant representing the Beneficiary Bank and no actions have
been performed by an EBA CLEARING Operator.
10. If one of the two counterparts is supposed to be removed from the system during the next
business date, instead of removing the participant it is put in suspended status until an EBA
CLEARING Operator manually changes the status of all pending transactions.
Please note that in the case of a Participant leaving the system, no transactions with status
‘Pending” are expected after the last ‘active’ day of the Participant in the system. The final status
of these transactions will be determined on a case by case basis but it can be expected that they
will be rejected.

37/59
4 Real-time Messages
4.1 Message processing concepts

All messages sent from an SCT Inst Participant to the IPS are part of the ISO 20022 XML standard.
Below is a summary of the ISO 20022 message types that are supported by the IPS and their function
within the system workflow.
A full description of the messages can be found in the IPS Interface Specifications [1].
Each message that cannot be processed by the IPS is rejected with a negative Payment Status Report
reply (pacs.002) with a reason code.
If a message is positively validated, it is processed and forwarded to the next party in the chain. The
only exception is the SCT Inst Status Inquiry Message (pacs.028). This message is only forwarded to
the next party in chain in case the final status of the original transaction is unknown (i.e. “pending’ status).
In case the status is known, the Payment Status Report (pacs.002) that was sent as a reply to the
original SCT Inst Credit Transfer (pacs.008) is resubmitted to the previous party in the chain.
4.2 SCT Inst Messages
4.2.1 SCT Inst Credit Transfer (pacs.008)

The SCT Inst Credit Transfer (pacs.008) is sent by a Participant representing the Originator Bank to the
IPS and from the IPS to the Participant representing the Beneficiary Bank in order to transfer funds from
an Originator to a Beneficiary. In IPS, the settlement of an SCT Inst Credit Transfer takes place in real
time when the instant payment is positively confirmed.
4.2.2 Payment Status Report (pacs.002)

The Payment Status Report (pacs.002) is sent by a Participant representing the Beneficiary Bank to the
IPS and from the IPS to
 the Participant representing the Originator Bank (mandatory):
- to confirm acceptance or rejection of an SCT Inst Credit Transfer that was initiated by the
Originator Bank as a positive or negative response to an SCT Inst Status Inquiry Message that
was initiated by the Originator Bank.
 the Participant representing the Beneficiary Bank (on optional basis as formal notification) to:
- inform the Beneficiary Bank about the receipt of the confirmation message
The Payment Status Report (pacs.002) is also sent by the IPS as a reply to any type of message in
case the IPS is not able to process the message (cannot be routed, invalid format, one of the validations
as specified in the IPS Interface Specifications [1] failed).
4.2.3 Recall Request (camt.056)

The Recall Request (camt.056) is sent by a Participant representing the Originator Bank to a Participant
representing the Beneficiary Bank to request the Recall of an SCT Inst Credit Transfer that has been
settled.

38/59
4.2.4 Positive Response to a Recall (pacs.004)

The Positive Response to a Recall (pacs.004) is sent by a Participant representing the Beneficiary Bank
to a the IPS and from the IPS to the Participant representing the Originator Bank as a positive response
to a Recall it has received from an Originator Bank related to an SCT Inst Credit Transfer that has been
settled. In IPS, the settlement of Positive Response to a Recall messages takes place in real-time.
4.2.5 Negative response to recall (camt.029)

The Negative response to recall is sent by a Participant representing the Beneficiary Bank to the IPS
and from the IPS to a Participant representing the Originator Bank as a negative response to a Recall it
has received from an Originator Bank related to an SCT Inst Credit Transfer that has been settled.
4.2.6 SCT Inst Status Inquiry Message (pacs.028)

The SCT Inst Status Inquiry Message (pacs.028) is sent by a Participant representing the Originator
Bank to the IPS and from the IPS to the Participant representing the Beneficiary Bank after the timeout
limit for a response to an SCT Inst Credit Transfer has passed, to inquire if the funds have been made
available to the Beneficiary.
In case the original SCT Inst Credit Transfer was already accepted or rejected by the Participant
representing the Beneficiary Bank and this status is known to the IPS, IPS will reply to a SCT Inst Status
Inquiry Message with the Payment Status Report that was originally sent to the Participant representing
In case the status of the SCT Inst Credit Transfer is pending, the IPS will reply to the Participant
representing the Originator Bank with a Payment Status Report to indicate that the SCT Inst Credit
Transfer is pending, and the SCT Inst Status Inquiry Message will be forwarded to the Participant
representing the Beneficiary Bank. Once a reply (Payment Status Report) is received from the
Participant representing the Beneficiary Bank, this reply will be forwarded to the Participant representing

39/59
5 Transaction Validation and Routing
5.1 Timings
SCT Inst Participants can send SCT Inst Transactions to the IPS 24 hours a day on all days of the year.
The IPS will validate each message individually. If the message is accepted, it is forwarded in real time
to the receiving SCT Inst participant. If it is rejected, the result of the validation process is sent to the
sending SCT Inst Participant in real time.
The results of the validation process may contain
 the acknowledgement of a valid transaction, or
 the reporting of invalid data on transaction level.
5.2 Transaction Validation

The IPS will process individual messages in real-time for the following transaction types:
 SCT Inst Messages (pacs.008)
 Positive and negative responses (pacs.002)
 Investigation messages (pacs.028)
 Recall Request (camt.056)
 Positive Response to a Recall (pacs.004)
 Negative Response to Recall (camt.029)
 Alerts for Liquidity Management (camt.052)
The following validations are performed on each Message:
 Security validation,
 Format validation,
 BIC validation,
 Duplicate validation,
 Business rules validation.
The validation rules that apply to each Message are defined in the IPS Interface Specifications [1].
5.3 Processing at network level

Immediately upon receipt of a message by the IPS the network returns an acknowledgement of receipt
(ACK) to the sending SCT Inst Participant’s system. Receipt of this acknowledgement signals to the
SCT Inst Participant that the message has been received and will be processed. The specifications of
this ACK/NACK exchange differ per supported network.
5.4 Routing
IPS will route all the valid messages it receives to the counterparty, which is determined by the system
according to the contents of its routing tables. This counterparty is referred to as the Instructed Agent.
The Instructed Agent BIC is found using the receiving side BIC (Creditor) and searching in the System
Routing tables for the Participant associated to it in case of an Addressable PSP.

40/59
Routing
Table
2 3 4
Instructing Instructed
Payment
IPS Payment
Agent Agent
1 1 5 5
1– The payment is sent by the Instructing Agent to the IPS

2– Check on the Instructing Agent BIC
3– Search for the Instructed Agent BIC associated to the Creditor Agent
4– Retrieve the Instructed Agent BIC
5– Forward the Payment to the Instructed Agent BIC
Figure 5-1: IPS routing process
The Routing of SCT Inst Transactions, payment statuses, status inquiries, PRRs, Payments
Cancellation Requests and NRRs is a step of the validation process which establishes the Participant
to which transactions will be routed, and which will be credited (in case of a SCT Inst Transaction or
PRR) for this instruction.
The routing process for SCT Inst Transactions payment statuses, status inquiries, and R-messages is
performed as follows:
1. The Participant routing table of the service being processed is consulted. If a matching for the
Creditor Agent BIC(8) of the instruction being routed is found within this table then:
 If the Participant is a Technical BIC, the look-up process must continue with step 2 (search
in the AP routing table);
Otherwise (if the Participant is not a Technical BIC):
 Transaction Routing is set to “DIR”;
 Instructed Agent is stored and equals the Creditor Agent of the transaction;
 The look-up has been successfully completed.
2. The Addressable PSP routing table of the service being processed is consulted. If a matching
for the Creditor Agent BIC of the transaction being routed is found within this table then:
 Transaction Routing is set to “IND”,
 Instructed Agent is stored and equals the Participant associated to the Creditor Agent of the
transaction;
 The look-up has been successfully completed.

41/59
3. If a match for the Creditor Agent BIC is not found within the AP routing table, while a match
was found with a Technical BIC in the Participants routing table, the transaction is rejected with
error code XT90 (Invalid use of a Technical BIC); otherwise, the transaction is rejected with
error code PY01 (Unknown BIC in routing table).
The process will follow the SWIFT rules for matching BIC(11) with “XXX” as the last three characters.
For example, if the Creditor Agent is a BIC(11) and no exact match at BIC(11) is found in the
Addressable PSP table but a matching BIC(8) (or BIC(8)+”XXX”) is found then scenario 2 will apply and
the transaction will be routed to the Participant serving the matched Addressable PSP.

42/59
6 Liquidity Management and Settlement
6.1 Summary
The IPS provides certainty of settlement for SCT Inst Participants. The IPS will update the positions of
the participants in real time with SCT Inst Messages sent and received and positively confirmed during
the business day. SCT Inst Participants must have a positive position in the IPS at all times; an SCT
Inst Message that would bring the position of the sending SCT Inst Participant below zero shall be
rejected.
The IPS will provide certainty of settlement for SCT Inst Participants by using ring fenced liquidity only
from Target2 for settlement. The positions of SCT Inst Participants in the IPS are guaranteed by Central
Bank money made available on a specific TARGET2 account dedicated for that purpose.
IPS will interact with TARGET2 via the Ancillary System Interface using the ASI-6 Real-time procedure
becoming available in November 2017.
The current model has to cope with the fact that TARGET2 is not available 24/7.
6.2 Dedicated technical account

The IPS will be an Ancillary System in TARGET2 separated from the other systems operated by EBA
CLEARING. The IPS will use the Ancillary System Interface settlement procedure 6 real-time by
leveraging liquidity made available by participants on a dedicated technical account managed by the
IPS.
The SCT Inst Participants can settle directly (direct participation) or via another SCT Inst Participant
(liquidity serviced participation). SCT Inst Participants settling directly must a RTGS account in
TARGET2. All instructions to fund or to defund the Participant’s position in IPS are executed against the
RTGS account of the Direct Participant.
6.3 Liquidity Adjustment Cycles

The IPS provides features to support the liquidity management for SCT Inst Participants. The IPS runs
a certain number of Liquidity Adjustment Cycles (LAC) throughout the business day. Each SCT Inst
Participant has the possibility to set three different thresholds for each LAC and for each business day:
 The LAC Upper limit;
 The LAC Base position;
 The LAC Lower limit.
The three thresholds can be set as default values per week days, e.g. default per Mondays etc.
During the LAC, the IPS will generate alerts each time a certain limit is reached; i.e. each time the
position of the participant goes above the set upper limit or below the set lower limit for the LAC. The
SCT Inst Participant receiving those alerts may then trigger an action to adjust liquidity accordingly:
 Transfer liquidity from its RTGS account to increase its position in the IPS (funding)

43/59
 Transfer the excess of liquidity in the IPS to its RTGS account (de-funding)
These actions are available through a Graphical User Interface (GUI) as well as via an Application
Programming Interface (API) provided by IPS so that SCT Inst Participants can automate their liquidity
management for the IPS within their own Back Office applications.
Each LAC has an opening time, a cut-off time and a settlement time. Between the LAC Opening time
and the LAC cut-off time IPS only generates alerts. At the end of each LAC, IPS automatically generates
liquidity adjustments for some participants, as described below.
At LAC cut-off time, the IPS will apply the limits set by the SCT Inst Participants for the next LAC and
adjust the positions of the SCT Inst Participants that are not within their limits. The amount of the liquidity
adjustment to be executed by the IPS is calculated with reference to the LAC Base position that the SCT
Inst Participants have defined for the next LAC.
D-1 TARGET2 business day D D+1

18:00
19:30
22:00
01:00
07:00
18:00
day end of day / night technical night day end of day / night
time start of d ay time maintenance time time start of day time
24x7 ring fenced liquidity on IPS Prefunding accou nt
LAC LAC LAC LAC LAC LAC LAC LAC LAC LAC LAC
PSR PSR PSR PSR PSR PSR

RSF RSF RSF RSF RSF RSF
Figure 6-1 – Liquidity Adjustment Cycles and Output Files
After each LAC, IPS sends the following reports to the SCT Inst Participants:
- Pre-settlement report (PSR): After each LAC related to Real-Time Messages, the IPS creates
and sends a Pre-Settlement Report (PSR) to the settlement BIC related to the SCT Inst Direct
and Liquidity Serviced Participants with the information regarding the liquidity position during
the LAC
- Result of Settlement File (RSF): After each LAC related to Real-Time Messages, the IPS
creates and sends a Result of Settlement file (RSF) to the Originator Bank and the Beneficiary
Bank with the status of the processed Instant Payments and Positive Responses to a Recall.
The RSF is an optional file that a SCT Inst Participant needs to register for.
There is a period of time between the LAC cut-off time and the LAC settlement time to allow participant
to process the PSR before the settlement instructions are sent to TARGET2 for processing. In case of
a debit instruction (corresponding to an attempt to increase the position in IPS), IPS will instruct
TARGET2 to debit the RTGS account of the participant. The PSR shall be used by the Participants to
make sufficient funds available on RTGS account before IPS sends the instruction to TARGET2 for
settlement.
A LAC could also end (and a new LAC could start) while TARGET2 ASI-6 real-time is not open. In this
case the RSF and PSR are sent to the Participant for reconciliation purposes, therefore settlement
instructions will not be sent to TARGET2.

44/59
The structure and content of the reports are described in details in the SCT Inst Interface Specifications
[1].
6.4 Settlement model

The IPS provides certainty of settlement for SCT Inst Participants. SCT Inst Participants in the IPS will
not be allowed to have a negative position at any point in time. SCT Inst Messages can be accepted for
processing only if the sender of the SCT Inst Message (the participant representing the Originator Bank)
has sufficient liquidity available in the IPS when the transaction is received and validated.
If there is sufficient liquidity available, the amount of the SCT Inst transaction is reserved on the position
of the sending SCT Inst Participant and the SCT Inst Message is sent to the receiving SCT Inst
Participant (representing the Beneficiary Bank). The receiving SCT Inst Participant must send a
response within a certain number of seconds as prescribed in the SCT Inst Rulebook [3].
In case of a positive answer from the receiving SCT Inst Participant, the position of the receiving SCT
Inst Participant is credited, the position of the sending SCT Inst Participant is debited and the status of
the transaction is set to its final status. In case of negative answer from the receiving SCT Inst Participant
the SCT Inst Message is cancelled and the reservation on the sending SCT Inst Participant’s position is
removed.
SCT Inst Messages that have been processed in the IPS are irrevocable and final. The SCT Inst
Participants’ position in the IPS are guaranteed by Central Bank money ring-fenced on a technical
account in TARGET2 managed by EBA CLEARING as System Operator for the IPS.
SCT Inst Participants must make sure that their position is sufficient in the IPS to avoid the rejection of
SCT Inst Messages. The IPS will provide liquidity management features to facilitate the liquidity
management for its participants:
 Sending alert (camt.052) when a certain limit is reached (in case of Liquidity Serviced
Participants, both the Indirect Participant and its Direct Participant will receive the alert);
 Liquidity Transfer via GUI / API possible during the LAC;
 Automatic Liquidity Adjustment at the end of each LAC.
At the end of each LAC, the IPS will generate a Liquidity Adjustment File (LAF) with the liquidity
adjustments that were calculated by the IPS (see 6.3). A liquidity adjustment is calculated when the SCT
Inst Participant’s position at the end of a LAC is not within the limits set by the SCT Inst Participant for
the next LAC. The Base position is used as reference to calculate the amount of the liquidity adjustment.
Therefore, the LAF may contain:
 Credit instructions in TARGET2 for the SCT Inst Participants whose position is above the
maximum limit set for the next LAC (de-funding); or
 Debit instructions in TARGET2 for the SCT Inst Participants whose position is below the
minimum limit set for the next LAC (funding).
The position of the SCT Inst Participants that are above the maximum limit is decreased immediately to
the base position set for the next LAC. This calculated amount will be credited to the RTGS account
during the next cycle (LAC settlement time).
The position of the SCT Inst Participants that are below the minimum limit is not increased immediately.
The amount of the liquidity adjustment is calculated with reference to the base position set for the next
LAC. This amount will be first debited from the RTGS account during the next cycle. Therefore, the

45/59
increase of the participant’s position is contingent on sufficient liquidity being available on the pertaining
RTGS account.
The IPS will send the LAF file to the TARGET2 Interface (T2I). The T2I will then prepare the file for
TARGET2 following the ASI-6 procedure. The T2I will first check the liquidity available on the RTGS
account to verify that all the debit instructions can be processed. If there is not sufficient liquidity available
to execute the liquidity adjustment calculated by the IPS, the T2I will debit the RTGS account with the
available amount.
Each settlement instruction (debit and credit) is processed against the AS Technical account that is
managed by the IPS. Credits for SCT Inst Participants (de-funding) are debited from the IPS technical
account. Debits for SCT Inst Participants (funding) are credited on the IPS technical account. There is
no netting between the instructions.
The IPS technical account in TARGET2 is used to ring-fence the liquidity used in IPS to accept SCT
Inst Messages. The amount of liquidity on the IPS technical account equals the sum of all SCT Inst
Participants’ positions in the IPS at all times and constitute a settlement guarantee for all SCT Inst
Messages processed and accepted.
Following the execution of the ASI-6 procedure, the T2I will report back to the IPS the result of the LAC.
Positions are increased for the amount that was debited on the RTGS account in TARGET2 which can
be:
 The calculated amount of the liquidity adjustment if sufficient liquidity was available on the RTGS
account;
 Any smaller amount if sufficient liquidity was not available on the RTGS account.
SCT Inst Participants can also use the functionalities in the IPS (GUI and APIs) to transfer liquidity both
ways (from IPS to TARGET2 or from TARGET2 to IPS) at their own initiative. Liquidity transfers initiated
by SCT Inst Participants follow the exact same process as above with the difference that the amount of
the liquidity adjustment is the one specified by the participant instead of being calculated by IPS. The
IPS will generate a LAF with a single settlement instruction. The T2I will process the instruction following
the ASI-6 real time procedure. The Participant will receive a debit or a credit on its RTGS account and
will see its position updated in the IPS accordingly.
The liquidity adjustment function in the IPS (GUI and APIs) will be disabled when TARGET2 is closed.
IPS Participants shall use the functions provided by IPS (GUI and APIs) to execute the funding and
defunding operations. IPS Participants shall not use the standing order and current order in TARGET2
to send funds directly on the IPS technical account. Fund transfers sent to the IPS technical account
which have not been initiated in IPS but in TARGET2 will be reversed to the sender and the position in
IPS will not be updated.
6.5 Remuneration policy

The remuneration policy for ring-fenced liquidity will be clarified and defined by the Eurosystem. Once
clarified, potentially functions will be implemented to support the Participants in their obligations.
6.6 Liquidity pooling

SCT Inst Participants from the same banking group will have the option to form a Liquidity Pool in the
IPS (under certain conditions) in order to share the liquidity amongst each other. SCT Inst Participants
that will be part of a Liquidity Pool will be entitled to use the liquidity of the entire pool.

46/59
The individual positions which will be included in a Liquidity Pool will be entitled to be negative as long
as the sum of all the positions included in the same Liquidity Pool remain positive. SCT Inst Messages
sent by SCT Inst Participants which are part of a Liquidity Pool will be validated against the available
liquidity in the Liquidity Pool, and not against the liquidity of each individual participant.
However, the IPS will continue to manage the position of each participant included in a Liquidity Pool.
Each participant will have to configure its thresholds for the LAC (Minimum, Base, Maximum). The IPS
will send alerts when a limit is breached during an LAC and at the end of an LAC, the participant’s
position will be adjusted if it is not within the defined limits.
One SCT Inst Participant will be designated as the ‘owner’ of the Liquidity Pool and the other SCT Inst
Participants will be designed as ‘members’. SCT Inst Participant can be a member of only one Liquidity
pool. The legal conditions for Liquidity pool membership will have to be defined. The owner of the
Liquidity Pool will have the following functionalities available:
 Include SCT Inst Participants in the Liquidity Pool;
 Remove SCT Inst Participants from the Liquidity Pool;
 Transfer Liquidity from one position to another position inside the Liquidity Pool.

47/59
7 Reconciliation
This chapter describes how transactions can be reconciled. The first part focuses on reconciliation
based on post settlement information and the second part on reconciliation based on information
provided by TARGET2.
7.1 Transaction status

IPS forwards the individual transactions once processed to the receiving Participant. After each LAC,
IPS sends the Result of Settlement File (RSF) to the SCT Inst Participants. The RSF contains a status
message (pacs.002) for each SCT Inst transaction and Positive Responses to a Recall processed during
the LAC and its status at the LAC cut-off time.
The status message contains the relevant information to help participants to reconcile:
 The transaction ID of the original transaction
 Acceptance Date and Time of the original transaction
 The Interbank Settlement date of the original transaction
 The Original Debtor Agent
 The Original Creditor Agent
The detailed structure of the RSF is defined in the IPS Interface Specifications [1].
7.2 Liquidity position

After each LAC the IPS creates and sends a Pre-Settlement Report (PSR) to the settlement BIC related
to the SCT Inst Participants and Liquidity Services Participants with the information regarding the
liquidity position during the LAC:
 Funding requests credited
 De-funding requests debited
 SCT Inst transactions credited
 SCT Inst transactions debited
 PRR credited
 PRR debited
In case the PSR is sent to a Participant, the PSR will include also the positions related to all Liquidity
Serviced Participants correlated to the same Settlement BIC. Liquidity Serviced Participants only receive
a PSR with their own positions.
7.3 Mapping of T2I data in TARGET2 output

The EndToEndID field is the field that identifies on the T2I side the payment order that is requested to
be executed by TARGET2. It is generated by the T2I of IPS and is carried through to the optional
MT900/MT910 as well as the MT940/950 messages that are sent to the IPS Settlement Participants.
IPS settlement participants must have a Participant status in IPS. IPS Liquidity Serviced Participants

48/59
hold a position in IPS but liquidity is provided via an IPS Participant through the settlement BIC of that
Participant.
The EndToEndId is a 16-character field and is constructed as follows:
 Character: 1234567890123456
 Value: AAAAGRAAXXXSSSCC
Where:
 AAAAGRAAXXX is the BIC(11) of the settlement BIC
 SSS is the service code (IPS) – matching the service identifier in the LAF
 CC is the LAC number – matching the LAC number in the LAF
The EndToEndId will be mapped unchanged onto Tag 21 of the MT900/910.

It will also be mapped onto the MT940/950 in tag 61 (statement line) which consists of subfields. Subfield
8 should be used to carry the EndToEndID unchanged.
7.3.1 Unstructured Remittance Information field

The EndToEndId will also be put in the Unstructured Remittance Information field of the message sent
by T2I to TARGET2. This field is then mapped to Tag 72 of the MT900/910.
7.3.2 MT900/MT910 messages

The MT900 is an optional Confirmation of Debit message. It is sent to a TARGET2 Direct participant by
TARGET2, when a debit order is executed against the T2DP’s RTGS account. The T2DP can choose
whether or not to receive this message from TARGET2.
The MT910 is an optional Confirmation of Credit message. It is sent to a TARGET2 Direct participant
by TARGET2, when a Credit transfer is executed against the T2DP’s RTGS account or sub-account.
The T2DP can choose whether or not to receive this message from TARGET2.
7.3.3 MT940/MT950 messages

The MT940/950 is an optional Statement of Account message. It is sent at the end of the settlement
business day to the corresponding RTGS account BIC. The T2DP can choose whether or not to receive
this message from TARGET2.
The MT940/950 lists one statement line that corresponds to each payment order executed against the
particular RTGS account concerned. The statement line is tag (field) 61 within the MT940/950 and there
is one occurrence of tag 61 for each statement line. Tag 61 is made up of multiple sub-fields:
Subfield Name Notes
1 Value Date YYMMDD
2 Entry date MMDD (optional field)
3 Debit/credit mark C Credit
D Debit
4 Funds Code Optional field

5 Amount 15 digits includes decimal comma

49/59
6 Transaction Type S followed by 900 or 910

Identification (corresponding to the MT900 or 910)
Code
7 Reference for the The EndToEndId generated by the
Account Owner T2I of IPS
8 Account Reference generated by TARGET2
Servicing
Institution's
Reference
9 Supplementary Free text
Details
Table 7-1: MT940/950 Tag 61 breakdown
7.3.4 Mapping of T2I data

The T2I data will be mapped as follows:
T2I data MT900 MT910 MT940/950
Tag 61 subfield 9
IPS BIC Followed by time of
Tag 52 Tag 52
(IPSTFRPP) settlement in T2
IPSTFRPP/HHMMSS
Credit / Debit
Tag 25 (Receiver) Tag 25 Tag 25
account
EndToEndId Tag 21 Tag 21 Tag 61 subfield 7
Tag 72: Tag 72:
/ASINF/[EndToEndId] /ASINF/[EndToEndId]
IPS Participant
Tag 72: Tag 72:
Settlement Included in EndToEndId
/ASDEBT/[BIC]++ /ASCRED/[BIC]++
BIC
Table 7-2: Mapping T2I data to MT9xx messages
Notes:
 The value of the IPS BIC is: IPSTFRPP. This BIC will be used by the T2I to communicate with the
ASI of TARGET2. All settlement instructions sent by the T2I to TARGET2 will be sent from this
BIC.
 ‘Receiver’ in the above table means that the message is sent to the holder of the relevant account.
This applies to all the messages.
 The IPS Participant Settlement BIC is included in the EndToEndId and thus appears twice in the
MT900/MT910.
 In the MT900/910 Tag 72 fields the BIC of the IPS settlement BIC is followed by two plus signs.
For example, /ASDEBT/AAAACCXX++

Liquidity can be transferred from the RTGS account to the IPS Technical Account using a specific type
of MT 202 (during daytime business only):
- sent to a specific TARGET2 BIC as Receiver:

50/59
- with ‘highly urgent’ priority

- with reference to the IPS Technical Account BIC in field 57A.
- with reference to the IPS Participant BIC in field 58A.
Note: the settlement bank of the MT 202 does not receive a debit notification (MT 900) for the debit on
the RTGS account in this case.
Sending Address T2 Settlement BIC

Receiving Address TRGTXEPMASI
57A: IPS Technical Account
58A:
IPS Participant BIC
Notification to the AS ASTransferNotice
Figure 7-1 - Liquidity Transfer via MT202
Liquidity can also be transferred from the RTGS account to the IPS Technical Account using the
Information Control Module (ICM) or with an XML (Application-to-Application) message:
SBTransferInitiation.
Sending Address Settlement Bank DN
Receiving Address PAPSS DN
Debtor BIC BIC of the ordering institution
Shall be mapped to the ASTransferNotice
and to the MT 900 with code-word /ASDEBT/
First Agent BIC RTGS Account debited
Creditor BIC BIC of the final beneficiary

Shall be mapped to the ASTransferNotice
Final Agent BIC BIC of the AS Technical Account
which must be authorized for the First Agent
Notification to the AS ASTransferNotice

51/59
8 Reporting and other exchanges
Full details regarding the format of the reporting are provided in the IPS Interface Specifications [1].
8.1 Daily Reconciliation Report (DRR)

The Daily Reconciliation Report (DRR) is an optional report and includes data that will allow SCT Inst
Participants to reconcile transactions sent and received and the amounts that were debited and credited
for the relevant processing date. This report will be sent to SCT Inst Participants after midnight of each
business day, including non-TARGET days and the weekends (after 00:00:00 A.M.).
The DRR summarizes the following details:
 Summary of all SCT Inst Messages (including R-messages) sent by the SCT Inst Participant,
 Summary of all SCT Inst Messages (including R-messages) received by the SCT Inst
Participant,
Frequency: Once per day.
8.1.1.1 Monthly Statistics Report (MSR)
The Monthly Statistics Report (MSR) is an optional report and includes data that will allow SCT Inst
Participants to reconcile SCT Inst Messages sent and received. The report will be sent to SCT Inst
Participants on the first Target day of each month.
The MSR summarizes the following details:
 One entry for each counterpart (SCT Inst Participants only) receiving transactions from the SCT
Inst Participant,
 One entry for each counterpart (SCT Inst Participants only) sending transactions to the SCT
Inst Participant,
Frequency: Once per month.
8.1.1.2 Results of Settlement File (RSF)
After each LAC cycle on any calendar day, the IPS creates and sends a Result of Settlement (RSF) file
to the Originator Bank and the Beneficiary Bank with the status of the transactions related to the Instant
Payments processed. The RSF is an optional file that a SCT Inst Participant needs to register for.
Frequency: Once for each LAC.

8.1.1.3 Pre-settlement Report (PSR)
The Pre-Settlement Report (PSR) is an optional report and includes all Liquidity operations performed
of the previous LAC as well as the planned liquidity operations for the new LAC based on the threshold
settings of the Participant. This includes liquidity operations within the system as well as those with the
T2I.
The PSR summarizes the following details:
 One entry for each liquidity pre-funding, de-funding or transfer action performed for the
Participant,

52/59
 One entry for each liquidity pre-funding, de-funding or transfer action performed for a Liquidity
Pool managed by the Participant.
In both cases, the PSR will also report the request for prefunding and release that will be processed in
order to adjust the current participant liquidity position for the next LAC
The PSR is sent to all the IPS Participants. In case of liquidity serviced participation, the information
related to the Liquidity Services Participant is also included in the PSR sent to the respective Participant.
Frequency: Once for each LAC.

8.1.1.4 Routing Table File (RTF)
The Routing Table File (RTF) will be delivered to SCT Inst Participants via FileAct each time the Routing
Table is updated. RTFs will be sent to all SCT Inst Participants before each change date and will be
effectuated at the start of the change date (as of 00:00:00 A.M.). Change dates occur on a weekly basis.
There are two RTFs that will be distributed to the SCT Inst Participants, one related to Participants and
one related to Addressable PSPs.
Frequency: Once per week.

53/59
9 Interfaces
There are different interfaces available to SCT Inst Participants that will allow them to connect to and
interact with the IPS. The next paragraphs give an overview of the functionalities that are available to
the SCT Inst Participants.
9.1 Graphical User Interface

The Participant WorkStation (IPS-PWS) interface provides the operational staff of SCT Inst Participants
with a Graphical User Interface (GUI) that allows them to interact with the IPS. Supported functionalities
are described below. For some of the functionalities the four-eyes principle is applied where a second
level of authorisation is required to execute a command.
A detailed description of the GUI is available in the user manual for the IPS-PWS [4].
9.1.1 General
The IPS-PWS provides Participants with a number general functions that allow them to access, use and
view common functionality.
The following functions are available:
 Login/Logout,
 View Inbox,
 View alerts and messages,
 View user,
 View network status.
9.1.2 Liquidity Management

The SCT Inst Participant has the possibility to see and manage the liquidity within the IPS for itself and
for Participants that it manages the liquidity for (SCT Inst Liquidity Serviced Participants and members
of Liquidity pool).
 View current, historic and forecasted position in the IPS,
 Add funds to IPS position from Settlement account,
 Authorize funds request,
 Release funds from IPS position to Settlement account,
 Authorize funds release,
 Set/Authorize default values for LAC position bandwidth*,
 Set/Authorize custom values for LAC position bandwidth up to one year in the future.
* Position bandwidth is determined by base position, minimum position and maximum position and can
be set per LAC.

54/59
9.1.3 Inquiries
The IPS provides functions to the SCT Inst Participant that allow it to monitor information related to
settled Instant Payment transactions and R-messages.
 Search transactions,
 List transaction details,
 Download results.
9.1.4 Configuration Management

The IPS provides the Participants with the ability to view their configuration within the system and to
request changes.
 View configuration,
 Upload Addressable PSPs,
 Request/authorize/reject/submit configuration changes,
 Search Participant/Addressable PSP,
 View details (only RTF related details visible),
 Download Participant details.
9.1.5 System Events and Alerts

Participants have the ability to change the way they would like to be alerted about system events and
alerts in the IPS.
 List preferences,
 Change delivery type,
 Restore to default.
9.1.6 Dedicated Network Connection

The PWS interface is reachable by using a web browser that is connected to the SCT Inst System via
an EBICS (to be confirmed) or SIANet connection.

55/59
Browse
supported
network
SCTinst IPS-PWS
IPS
Participant
Figure 9-1: – Physical Implementation of the PWS
9.2 Application Programming Interface

The Application Programming Interface (API) provides SCT Inst Participants with a machine interface
that allows them to interact with the SCT Inst System. The API supports most of the functionalities as
the ones for the IPS-WS. IPS-WS functions that require authorization from another user are assumed
authorized when they are submitted via the API.
All available API functions are available in the IPS SCT API Inst Interface Specifications [6].
9.3 Networking Interface

The Networking Interface gives SCT Inst Participants the ability to connect their payment systems or
Middleware solutions to the IPS and allows them to send and receive messages and files.
Details about the Networking Interface are available in the IPS SCT Inst Interface Specifications [1].

56/59
10 Other Services
10.1 Testing Services

SCT Inst Participants have access to the SCT Inst Test environment.
This environment is available to all IPS SCT Inst Participants intending to join or already participating in
the system, and contains a copy of the system used in production, with minor modifications to timings
and performances to fit in with a test schedule.
EBA CLEARING also runs a joining program for new SCT Inst Participants including a testing program
made up of:
A. Connectivity Testing
SCT Inst Participants confirm their ability to communicate with the system and to exchange data
within the expected timeframe.
B. Scripted testing
SCT Inst Participants test with each other to simulate live environment conditions following a set of
scripts provided by EBA CLEARING. The purpose of this exercise is to have SCT Inst Participants
perform the minimum set of scenarios and cases needed for live operations.
C. Free testing
SCT Inst Participants test among themselves without guidance from EBA CLEARING to check the
ability of their software to perform specific cases that may not be part of scripted testing.
Documentation related to testing activities are provided separately.
10.2 Helpdesk
An English-speaking helpdesk is provided to assist SCT Inst Participants with operational and technical
enquiries.

57/59
11 Appendix A: IPS Parameters

The configuration of the service defines the behaviour of the service as seen by the banks.
System Configuration Parameters
Parameters Description Value
TBD
Service Configuration Parameters
Parameters Description IPS SCT Inst

Number of seconds within which the transaction should be received
DefaultTimeOutIncoming from the moment of the timestamp of the transaction in the default 20
processing (i.e. no closed user group configured)
Number of seconds within which the transaction should be delivered
to the next party in the chain from the moment of the timestamp of
DefaultTimeOutOutgoing 20
the transaction in the default processing (i.e. no closed user group
configured)
Number of seconds within which the transaction should have
received a response from the counter party from the moment of the
DefaultTimeOutPending 20
timestamp of the transaction in the default processing (i.e. no closed
user group configured)
Maximum amount in Euro (€) allowed per individual transaction in the

DefaultMaximumAmount 15.000
default processing (i.e. no closed user group configured)
Liquidity Adjustment Cycle Configuration Parameters

LAC From Till Settlement TARGET2 Status
time
LAC#1 07.00 10.00 10.15 OPEN [Daytime]
Business day D
LAC#2 10.00 13.00 13.15 OPEN [Daytime]
Business day D
LAC#3 13.00 16.00 16.15 OPEN [Daytime]
Business day D
LAC#4 16.00 17.30 17.45 OPEN [Daytime]
Business day D
LAC#5 17.30 19.30 19.45 CLOSED [End of Day 18.00 > 19.30]
Business day D
LAC#6 19.30 21.30 21.45 OPEN [Night-time]
Business day D+1
LAC#7 21.30 01.00 01.15 CLOSED [Maintenance 22.00 > 01.00]
Business day D+1
Business day D+1

58/59
Test and Training Configuration

LAC From Till Settlement TARGET2 Status
time
LAC#1 07.00 10.00 10.15 OPEN [Daytime]
Business day D
LAC#2 10.00 13.00 13.15 OPEN [Daytime]
Business day D
LAC#3 13.00 16.00 16.15 OPEN [Daytime]
Business day D
LAC#4 16.00 17.30 17.45 OPEN [Daytime]
Business day D
LAC#5 17.30 19.30 19.45 CLOSED [End of Day 18.00 > 19.30]
Business day D
Business day D+1
LAC#7 21.30 01.00 01.15 CLOSED [Maintenance 22.00 > 01.00]
Business day D+1
Business day D+1
IPS SCT Inst Product Configuration Parameters
Parameters Description IPS
End of document.

59/59

Ebacl Ips 20161130 Ips Functional Description v09 Draft PWG Clean

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ebacl Ips 20161130 Ips Functional Description v09 Draft PWG Clean

Uploaded by

Copyright:

Available Formats

SEPA INSTANT CREDIT TRANSFER

Status: V0.9 DRAFT

Copyright ©, 2016, EBA CLEARING

Version Date Authored by

Table 0-1 Change History

V0.9 DRAFT, Updated 30/11/2016

2 GENERAL CONCEPTS ................................................................................... 11

3 IPS PROCESSING OVERVIEW ...................................................................... 17

5 TRANSACTION VALIDATION AND ROUTING .............................................. 40

V0.9 DRAFT, Updated 30/11/2016

5.3 Processing at network level .................................................................................................... 40

6 LIQUIDITY MANAGEMENT AND SETTLEMENT ........................................... 43

8 REPORTING AND OTHER EXCHANGES ...................................................... 52

10 OTHER SERVICES .......................................................................................... 57

11 APPENDIX A: IPS PARAMETERS.................................................................. 58

V0.9 DRAFT, Updated 30/11/2016

Table 0-1 Change History ........................................................................................................................2

V0.9 DRAFT, Updated 30/11/2016

V0.9 DRAFT, Updated 30/11/2016

1.1 Purpose and scope of document

1.2 About this version

V0.9 DRAFT, Updated 30/11/2016

[1] EBA CLEARING SCT Inst Interface Specifications EBA CLEARING

[2] SCT Inst Implementation Guidelines (not yet available) EPC

[3] SCT Inst Rulebook V0.8 EPC

[4] IPS SCT Inst IPS-WS User manual EBA CLEARING

[6] IPS SCT Inst API specifications EBA CLEARING

V0.9 DRAFT, Updated 30/11/2016

V0.9 DRAFT, Updated 30/11/2016

Table 1-1: Glossary

V0.9 DRAFT, Updated 30/11/2016

This section intends to provide a helpful background of the IPS setup.

2.1 The Four Corner model

Figure 2-1: The four corner model

V0.9 DRAFT, Updated 30/11/2016

Figure 2-2: IPS eco-system

V0.9 DRAFT, Updated 30/11/2016

2.2 Instant Payments Clearing

V0.9 DRAFT, Updated 30/11/2016

2.3.1 Pre-settlement R-messages

2.3.2 Post-settlement R-messages

2.4 Investigation messages

V0.9 DRAFT, Updated 30/11/2016

2.5 Interbank Settlement Date

2.6 Directories and Registers

2.7 Transaction References

V0.9 DRAFT, Updated 30/11/2016

Figure 2-4: System Reference fields

2.8 Value Added Services

V0.9 DRAFT, Updated 30/11/2016

3 IPS Processing Overview

Figure 3-1: IPS Processing overview

V0.9 DRAFT, Updated 30/11/2016

3.1 Positive SCT Inst Message Workflow

Originator Originator Bank IPS Beneficiary Bank Beneficiary

Figure 3-2 EPC Workflow - Scenario 1

1. The Originator initiates an SCT Inst Instruction,

V0.9 DRAFT, Updated 30/11/2016

3.2 Exceptional SCT Inst Message Workflows

2. RejectIon by Beneficiary Bank

Originator Originator Bank IPS Beneficiary Bank Beneficiary

Figure 3-3 EPC Workflow Scenario 2

1. The Originator initiates an SCT Inst Instruction,