1. Name of speaker Title Institution
Event name, location and date
SWIFT and TARGET2
Name of speaker
Title
Institution
TARGET2_implementation_2006_v9.ppt

2. Agenda Concept of TARGET2
A comprehensive set of SWIFTNet services & interfaces
TARGET2 Directory
SWIFT traffic pricing
SWIFT help & education

3. Why TARGET2 ?
Rationale for TARGET2: Strategic move to overcome drawbacks of TARGET1 and to be prepared for the future
User’s requests:
A more harmonised service level
Cost recovery problem
Adaptability problem
EU enlargement
Credibility of the Eurosystem

4. TARGET2 features and functionalities
« one single system »
More robust and resilient system
Harmonised interfaces to connect users
Same core service for all TARGET2 participants irrespective of their location
Single price structure for core service
Flexible liquidity management

5. SSP Concept of TARGET2 “Single platform” system
TARGET2 Indirect Participant
“Single platform” system
Concentration of domestic euro RTGSs
Direct & indirect participants
Full set of SWIFTNet services and Interfaces
MT, MX and XML standards
Automated or manual access
Live November 2007
SWIFTNet Services
TARGET2 Direct
Participant
TARGET2 Direct
Participant
SSP
NCBs
Ancillary Systems

6. Direct and indirect participation
Feature Direct participant Indirect participant
Submit/receive payments • using own SWIFT interface via direct participant
directly from SSP • via a service bureau
Own RTGS account in PM yes no
Liquidity provisioning on its RTGS account by direct participant
Liquidity control by itself by direct participant
Access to ICM yes no
Addressability directly by direct participant
BIC 8 or 11-digit published SWIFT 8 or 11-digit published BIC SWIFT or non- SWIFT BIC
Publication in BIC/ TARGET2 as direct participant (TGT) as indirect participant (TG+) directory
Direct participants will hold an account in the Payments Module (PM) of the Single Shared Platform (SSP)
i) submit/receive payments directly to/from the system and
ii) settle directly with their central bank.
Direct participants will be responsible for all payments sent or received on their account by any entity registered through them in TARGET2 (indirect participants,
multi-addressee access entities: direct participants will be able to authorise their branches and credit institutions belonging to their group, located in EEA countries, to channel payments through the direct participant’s main account without its involvement by submitting/receiving payments directly to/from the system.
addressable BICs: are not subject to any system rules. Any direct participant’s correspondent or branch that holds a BIC is eligible to be listed in the TARGET2 directory, irrespective of its place of establishment. From SWIFT’s point of view, these are indirect participants

7. Ancillary systems SSP provides services to AS via:
Retail payment systems
Large value payment systems
Foreign exchange systems
Money market systems
Clearing houses (CCP)
Securities Settlement systems (SSS)
SSP provides services to AS via:
Ancillary system interface (ASI)
Participant Interface (PI)
Proprietary Home Account (PHA) (4 years transition period)
Information & control Module (ICM)
The PM will allow the settlement through 2 major models
Integrated model : the final settlement takes place in the AS itself
Interfaced model : the final settlement takes place in the SSP
Based on those 2 models , 6 generic settlement procedures are provided by the PM via the Ancillary Systems Interface (ASI)

8. Central Banks
Responsibilities
In general
All contacts and provision of any kind of support to their participants (credit institutions and ancillary systems)
During migration
Responsible for planning and structuring the domestic migration process
In operation
Inclusion and exclusion of participants
Monitoring the activity of participants
Provision of intraday liquidity necessary for the smooth running of the system
Initiating payments on behalf of their own or on behalf of their participants
Billing to their participants
Handling of local contingency
Current role of Central Banks in TARGET remains in general terms unchanged. Each CB will remain fully responsible for the business relations vis-à-vis its participants.

9. Migration windows Migration Transition phase phase 2006 2007 2008 2012
Slovenia
Spain
Malta
Poland
Portugal
Luxembourg
contingency
Italy
Netherlands
Lithuania
For
Greece
Ireland
Latvia
Reserved
ECB
France
Germany
Estonia
Finland
Cyprus
Denmark
Belgium
Austria
Group 4
Group 3
Group 2
Group 1
2006
2007
2008
2012
Developments
Testing 1 2 3 4
15/09/2008
19/11/2007
18/02/2008
19/05/2008
Migration
phase
Transition
phase

10. Country migration models
National Big Bang Phased Approach
Cyprus Austria
Denmark Belgium
Estonia Germany
ECB Spain
Finland Lithuania
France Malta
Greece Poland
Italy Portugal
Ireland
Latvia
Luxembourg
Netherlands
Slovenia
“Phased Approach”
Some pieces of the current infrastructure co-exist with the SSP for a period of time, in order to allow for a smoother migration. Some RTGS transactions will be settled in the SSP from day one, while the rest of the business will continue to be settled on proprietary home accounts for an interim period lasting a maximum of four years (the “transition period”).
• “National Big Bang” All current systems will be dismantled the moment the central bank migrates to the TARGET2 single shared platform (SSP). All payment transactions will be included in the SSP from day one, meaning that all migration actors will have to be prepared to settle directly in the SSP from the very beginning.

11. Agenda Concept of TARGET2
A comprehensive set of SWIFTNet services & interfaces
TARGET2 Directory
SWIFT traffic pricing
SWIFT help & education

12. Single Shared Platform and its modules
SSP
Optional Services for Central Banks
Payments
Module
(PM)
Static Data
Standing
Management
Facilities
(SF)
Payments
processing
(SD)
PAPSS
TARGET
Participant
Ancillary
Home
Interface
systems
Accounting
Monitoring
Interlinking
Y-copy
For all
interface
Module (
HAM) (
Storage ,
Reserve
Contingency
Archiving ,
Management
Module
Files
for
(RM)
(CM)
CRSS
billing
calculation )
Standard
Interfaces
Information and
Control Module
For NCB
(ICM)
PAPSS (accessible by all FI) : Real-time update of data - Mostly data of the business day
CRSS (accessible by NCB only): No action on data ; Consultation of data of the previous day ; Batch processing
Optional services for NCBs: CRISP: Billing Optional Service -- CRAKS1: Query and Report optional services -- CRAKS2: Optional service of paper-based account statement --CRAKS3: Customer Relationship optional services (see UDFS book 3)
ICM: information and control options of ICM are setup as XML messages. Only data of current business day available. Access to : •Payments Module (PM) •Static Data (SD) and depending optional modules.
HAM: standardised Home Accounting Module (HAM). Choice for each CB. Not intended to offer real payment services must be via a DP. Used for :•Some banks may not be interested to participate directly in the RTGS system, but are subject to minimum reserve requirement. In addition, they may wish to directly manage cash withdrawals etc. Therefore, they need an account with the CB outside the RTGS system.
•Depending country, it may be preferable to have a second set of accounts. For specific operations of direct participants, which already have a RTGS account. Some ancillary systems might, for example, decide not to migrate from the start to the SSP, but maintain - for the time being - a local infrastructure.
Each CB is fully responsible for the execution of its home accounting business. In this context, each CB is also free to choose:
•Either to offer proprietary home accounting services or to rely only on TARGET2, if there is a need to offer such services.
•For what type of business the home accounting application is used.
“It is left to individual Central Banks to decide whether some payment transactions could be settled outside of the SSP, on a proprietary home accounting application (PHA).
After a maximum period of 4 years, transactions between market participants, stemming from ancillary system settlement or related to open market operations should be processed on the SSP.”
ASI: provides a range of services to support AS settlement. By using the ASI, an ancillary system can control the initiation of liquidity flows. The responsibility of the provision of the needed liquidity on the settlement bank’s RTGS account is up to each AS participant.
Also AS can be DP, may hold an account in the PM, if necessary for settlement purposes (eg with regard to the current settlement procedure of the EBA-EURO1 system).
ASI use specific procedures for the efficient settlement of their business. Using ASI, an ancillary systems manager may initiate:
•credit transfers on its own behalf (the amount is debited on its own account)
•credit transfers on behalf of the participants in the AS (mandated payment)
The ASI role is to control and convey the information pertaining to the settlement process.
ASI takes advantage of standardised : Messages (SWIFTNet standard messages)/ Network and services (SWIFTNet services) / Settlement processing (generic settlement procedures). Note: optional mechanisms can fine-tune the ASI to the AS already existing procedures.
Advantages: For AS :
• Broader accessibility of participants (also in a cross-border context)
• Broad range of streamlined functionality
For CI as participants to the ancillary systems:
• More efficient liquidity management (use of one RTGS account for several ancillary systems)
• Easier cross-border access to ancillary systems
• Integration with normal payment business
Interlinking:
In order to allow for a smooth migration it is foreseen to support the current Interlinking logic also at SSP level, until the last migration window is closed, in order to allow a gradual migration of countries in several waves. Thus, CBs will not have to migrate to the new environment "in one go". After the migration period is finished the Interlinking functionality will be removed.
Mandatory
NCBs
Credit
Ancillary
Internal accounting,
Collateral management,
Proprietary home accounts etc.
Optional
institutions
systems
PAPSS (Payment and Accounting Processing Services Systems)
CRSS (Customer Related Services System)

13. Full set of core SWIFT messaging services
TARGET2 Indirect Participants connected via TARGET2 direct participant
Non EU Bank
SWIFTNet FIN
payment message
Branch
TARGET Direct Participant
TARGET2 Direct Participant
settlement
request
authorisation/
refusal
Indirect
EU Bank
SWIFTNet FileAct
Real-time
Store & Forward
SWIFTNet FIN Copy
SWIFTNet Browse
On-line visualisation of information
SWIFTNet InterAct
Real-time
Ancillary
systems
NCBs

14. Full set of core SWIFT messaging services
SWIFT's core store-and-forward messaging service.
A secure, reliable, resilient, access controlled, structured store-and-forward messaging service.
SWIFTNet FIN
Secure browsing with standard internet technologies. Appropriate for data exchange in thin-client browser-based financial solutions. To be used with SWIFTNet InterAct and FileAct.
SWIFTNet Browse
SWIFTNet messaging
Secure, reliable, and STP-oriented. Appropriate for exchange of individual structured financial messages and short reports.
SWIFTNet InterAct
Secure, reliable, and flexible. Appropriate for exchange of files and batches of structured financial messages and large reports
SWIFTNet FileAct

15. SWIFTNet FIN & FIN-Copy: payment processing
order
SWIFTNet FIN
Y- Copy 1
Payment Instruction MT103, 103+, 202,204*) 1 4
Bank A
Bank B 2
Settlement request
(MT096) 2 5 3 5 3
Settlement response
(MT097)
SWIFT
Interface 4
Approved/Settled Payment Instruction received
SSP
Sender / receiver notification and reporting (Optional MT012, MT019,MT900, MT910, MT940, MT950 ) 5
Settlement
Application

16. FIN Interbank transfers - between HAM accounts
Bank A
Bank B
SWIFT interface
Internal
payment system
SWIFT interface
Internal
payment system
SWIFTNet FIN 4 1 3 4 1
MT202 “simplified” 2
Booking
HAM
Participant interface 3
MT202 “simplified” 2
MT900 to sender
MT910 to receiver 4
Payment processing
Optional messages

17. SWIFTNet Browse overview
Service user
Service provider
SWIFTNet
Workstation
(running SWIFTAlliance WebStation and a standard Browser)
Web Server and
SWIFTNet Link*
SWIFTNet Browse enables secure browser-based access (over SIPN) from an operator using a standard browser and SWIFTAlliance WebStation to a service provider’s web server
* Typically used in conjunction with SWIFTAlliance Gateway

18. SWIFTNet Browse overview SWIFTNet Browse transparently combines two communication mechanisms
HTTP-S channel only authenticates the system of the end user
Service user
Service provider
Using non-managed Web certificates
HTTP-S
SWIFTNet
Web Server +SNL
InterAct/FileAct
Using managed SWIFTNet PKI certificates
Workstation
InterAct / FileAct channel authenticates the end user
SWIFTNet Browse allows to initiate InterAct or FileAct exchanges via a secure browser link. By doing so sensitive data can be exchanged with all the security and reliability inherent to the SWIFTNet platform, while preserving the benefits of a browser-based environment.

19. Key characteristics of SWIFTNet Browse (when used with SWIFTNet InterAct/FileAct)
Highly secure & reliable
Integration with SWIFTNet InterAct / FileAct for security sensitive data
HTTP-S exchanges secured with web-certificates for non-sensitive / un-structured exchanges
Closed User Group control
SIPN
Standard technologies
Client uses standard browser to navigate
HTTP-S for screens and InterAct for transactions or FileAct for file transfers
Thin client
Service provider does not install software at client side
Re-utilisation of existing SWIFTNet infrastructure
Single Window

20. SWIFTNet InterAct is used in real-time mode query & response
Used either in the context of person-to-application solutions (with SAB) or application-to-application (with SAG)
Real-time
query & response
SWIFTNet InterAct Q& R: real-time exchange of information
XML messages for SWIFTNet InterAct: Cash Management Standards
Access to the SSP (mandatory and optional modules) through SWIFTNet InterAct:
Payments queue management
Liquidity management
Management of reservation and limits
etc…

21. Key characteristics of SWIFTNet InterAct
Highly secure
Secured with SWIFTNet PKI (managed certificates)
Encryption, authentication and integrity control
Non-repudiation
Closed user group control
SIPN
Highly reliable
Highly available operations
Store-and-forward (not planned in TARGET2)
Delivery notification (not planned in TARGET2)
Message validation (not planned in TARGET2)
XML-based
STP oriented
Short messages (max 100 K; recommended < 20 K for RT)
Higher priority vs. SWIFTNet FileAct
Flexible central routing
Real-time messaging requires 64K lines minimum
Other

22. The SWIFT XML Cash Management standards
Advice Statement
GetAccount & ReturnAccount
GetTransaction & ReturnTransaction
ModifyTransaction
CancelTransaction
GetLimit & Return Limit
ModifyLimit
DeleteLimit
GetReservation & ReturnReservation
ModifyReservation
DeleteReservation
GetMember & ReturnMember
ModifyMember
GetBusinessDayInformation & ReturnBusinessDayInformation
GetCurrencyExchangeRate & ReturnCurrencyExchangeRate
GetGeneralBusinessInformation & ReturnGeneralBusinessInformation
LiquidityCreditTransfer
LiquidityDebitTransfer
BackUpPayment
ModifyStandingOrder
Receipt 21
messages

23. SWIFTNet FileAct: real-time and store-and-forward
FileAct RT and SnF used for:
Reporting
Directory distribution
Store-and-forward file transfer
Typically used to reach
a large number of counterparties
Store & Forward: TARGET2 sender of files (TARGET2 Directory updates)
Typically used in the context of person-to-application solutions (with SWIFTNet Browse)
Real-time
file download
Used by TARGET2 participants to pull TARGET2 directory

24. Key characteristics of SWIFTNet FileAct
Highly secure
Secured with SWIFTNet PKI (managed certificates)
Encryption, authentication and integrity control
Non-repudiation
Closed user group control
SIPN
Highly reliable
Highly available operations
Store-and-forward
Delivery notification
Highly reliable file transfer protocol
Any file content (structure and character set)
Files size up to 250 Mb
Flexible
4MB files with Store and Forward
Other
Lower priority vs. SWIFTNet InterAct / SWIFTNet FIN
Flexible central routing
Real-time file transfer requires 64K lines minimum

25. Application-to-Application
Two different technical modes for accessing the Information and Control module (ICM)
User-to-Application
SWIFTNet InterAct
SWIFTNet Browse
(SWIFTNet FileAct)
Allows direct communication between a participant’s users and ICM.
access to data of the current business day only, which are available through "pull mode".
The information is displayed in a browser running on a PC system (SWIFTAlliance Webstation)
Participants do not need to develop a special application.
Application-to-Application
SWIFTNet InterAct
SWIFTNet FileAct
Information and messages are transferred between the SSP and participants’ internal application
A2A interface for the management of XML message flows
Therefore the participant must:
Develop own application
Adapt existing application or
Purchase an appropriate solution

26. Accessing TARGET2 Application-to-Application User-to-Application
ICM access
mode
ICM
user profile
Any user *
SWIFTAlliance WebStation or
SWIFTAlliance Gateway
WebStation concentration
SWIFTAlliance
Gateway
Single Window
SAA/E
users
Connecting through a service bureau can be done in different ways, depending on the way the service bureau has implemented its configuration for their customers.
SWIFTAlliance Starter Set
* It is assumed user is already a SWIFTNet FIN user

27. SWIFTAlliance Gateway – Licensing & pricing ‘An easy step approach’
Profile 1 :
“WebStation Concentration”
Benefits :
-Flexible SAB deployment
From 5 till 320 concurrent users
Price :
Starts at 7,500$ (5 users)
Profile 2 :
“Automated “
-Off-the-shelf application
integration using Agents
(FTA or TDA for < 200 InterAct or FileAct per day)
-Flexible SAB deployment
From 1 till 320 concurrent users
Starts at 14,000$ (1 User,
1 Agent)
Profile 3:
“Single Window”
-Can reside in DMZ
-Scalability & resource
optimisation
Resilience
Off-the-shelf application integration using Agents
(FTA or TDA)
Price:
Starts at 30,000$ (5 Users, 1 Agent, 1 Host Adapter) +
Traffic licence
SWIFTAlliance
Starter Set
-FileAct out-of-the box
1 concurrent user
6,500$
16,000$

28. Agenda Concept of TARGET2
A comprehensive set of SWIFTNet services & interfaces
TARGET2 Directory
SWIFT traffic pricing
SWIFT help & education

29. TARGET2 directory contents
Overall view of all institutions able to receive payments via the PM directly or indirectly
Main purpose: information for automating and routing of payments
Weekly updates based on the content of the up-to-date BIC directory (BIC directory updated monthly)
During migration, the TARGET2 directory also contains routing information on non-migrated participants. Current TARGET Directory will exist until end of migration, mid 2008

30. TARGET2 Directory Distribution
provided electronically in a structured form via FileAct
set up in addition to SWIFT’s BIC directory to support the specific needs of the SSP and its users

31. Distribution TARGET2 Directory
Only via FileAct. No other distribution or publication allowed
Only to direct members
Push mode: each Thursday after close of operational day, SSP sends to all registered users a file containing changes vs. previous version of the directory
Pull mode: at any time during service hours full content of the last version can be downloaded
Registration
Form available from the User Helpdesk at the responsible national central bank
Payment Order
Payment Processing
Chain
BIC
address
TARGET2 Directory
Name or
BIC or
National Code
Beneficiary
Bank
Regular
Updates

32. Agenda Concept of TARGET2
A comprehensive set of SWIFTNet services & interfaces
TARGET2 Directory
SWIFT traffic pricing
SWIFT help & education

33. SWIFT Traffic Pricing for TARGET2
FIN User-to-user pricing
Global tier of sender
Sender pays (standard billing)
Non reporting / reporting
Domestic / International
FIN Copy pricing
T-copy, Y-copy
Volume of daily copies of MI
Decentralized (billed to participants)
SWIFTNet InterAct or FileAct
Global tier of sender
Domestic / International
Standard, centralized or decentralized billing
SN Browse
FIN from and to Market Infrastructure
Number of service end-users
Centralized or decentralized billing
Fee independent from global tier
Non reporting / reporting
Standard, centralized or decentralized billing

34. Agenda Concept of TARGET2
A comprehensive set of SWIFTNet services & interfaces
TARGET2 Directory
SWIFT traffic pricing
SWIFT help & education

35. Where to find help ?
Contact details of Network Providers and Business Partners
SWIFT on-line support and FAQ’s
Updates on vendor initiatives, activities and status

36. SWIFT Training solutions
Two different modules specific to your role and requirements:
Overview of SWIFT in TARGET2
SWIFT infrastructure for TARGET2
Technical training courses on the SWIFTAlliance interfaces
Different training modules about the business and technical implications of this new payment clearing system in relation to SWIFT
See

37. uestions
&
Answers