Introduction of
Large Value Payment System
October 2008

Table of Contents
Inter Bank Payment System
Real Time Settlement System • Explain basic concept of the
Inter Bank Payment System
Basic Concept of RTGS System • Explain on the basics of Real
Time Settlement System
Case I : State Bank of Vietnam • Payment system in Vietnam
Case II : Central Bank of Nigeria (CIFTS)
• Payment system in Nigeria
Current Trend of Large Value Payment System
• Current trend of the Large Value
Payment System using other
Case III : Hybrid LVPS in Other Countries settlement method
• RTGS in other countries
Basic Concept of Hybrid LVPS
• New Hybrid System
Conclusions

Inter Bank Payment System
(IBPS)

Inter Bank Payment System
Concept of IBPS
Legal Frame Work to move funds between
Concept of IBPS banks for the bank and customer.
To back up the Legal Frame Work,
computer system is used now a days.
Instruction Processing Authentication, Validation, Reconciliation
and Confirmation of Payment Instruction
Settlement Processing Settle the instruction between the
Settlement Accounts and give Finality and
Irrevocability of the settlement.
Interface with other systems
Able to connect other system that requires
a settlement such as Net Settlement
Systems (Check Clearing, EFT, Credit
Card, ATM, etc), Delivery verses Payment
Settlement Time Gross Settlement Net Settlement system, Discount House and Central Bank
banking system
Designated Time
Designated Time
Designated Time Net Settlement
Gross Settlement
(DTNS)
Real Time
Real Time Gross Settlement Not Applicable
(RTGS)

Inter Bank Payment System
Comparison
Comparison of two types of Settlement System
Risk reduction method employed for DTNS
Clarification RTGS DTNS in many countries
Type of Operation Credit Payment Credit Payment • Loss Sharing
Debit Payment Debit Payment - Loss shared amongst participating banks
Settlement Method Gross Settlement Net Settlement • Overall Limit Control
- Each participating bank has limit set
Settlement Time Real Time Designate Time
Targeted Transaction Large Value Small Value
Low Volume Large Volume
Settlement Risk No Risk Risk exist

Inter Bank Payment System
Risk Factor
Risks of Inter Bank Payment System
Risk Type Cause of risk Risk Management
RTGS DTNS
Credit Risk Replacement Cost Risk and None Risk exist
Principal Risk caused by
bankruptcy
Liquidity Risk Insufficiency of - No Settlement Risk - Debit Cap
Settlement Funds - Collateralization
- Loss Sharing
Systematic Risk Caused by Credit Risk and Reduce the Credit Risk and Liquidity Risk
Liquidity Risk cascading to
other Credit Institutions
Legal Risk Lack of Legal Framework Sound Legal Framework
BIS Core Principles
Operation Risk - Application System Failure - Well designed system
- Operator’s Understanding - Operator Training

Inter Bank Payment System
Risk Management
Net Settlement Risk Management Calculated based on Credit level, Collaterals, Low
value activities
By Application System (Overall Limit Control)
No payment instruction but can Receive
payments
Debit Cap (Limit)
Warning level Warning issued but keep continue Payment
activity
By Policy and Agreement (Loss Sharing among participants)
Loss Loss shared amongst the Participants
Total Default Prevent total collapse of the Financial System
Value Covered by
Collaterals

Real Time Gross Settlement
(RTGS)

Real Time Gross Settlement System
Concept of RTGS
A Payment system in which processing and
Real Time Gross Settlement settlement take place continuously in real
time (that is, without deferral) and gross
(I.E. Transaction by transaction)
Settlement of Credit Transfer Instruction
Settlement Processing will be done when there is sufficient
balance in the settlement account with the
Central Bank.
Settlement of Credit Transfer Instruction is
Finality and Irrevocability guarantied for it’s FINALITY and
IRREVOCABILITY. Thus it gives minimum
or free of Settlement Risk.

Real Time Gross Settlement System
Components of RTGS
Interface with the participants or other
Instruction Connectivity systems
Authentication, Validation, Reconciliation
Instruction Processing and Confirmation of Payment Instruction
Settle the instruction between the
Settlement Processing Settlement Accounts and give Finality and
Irrevocability of the settlement.
Sufficient Balance?
Yes No
Queue Management
Queue Mechanism: FIFO
Gridlock Resolution:
SA Queue • Bypass FIFO
• Reordering
• Cancellation

Real Time Gross Settlement System
Requirements of RTGS
Clearly Defined Rules and Regulation
As BIS recommended, the central bank must have clearly Central Bank need to have legal frame
work for the electronic payment system
defined Rules and Regulation, Operation Guide to operate in placed before the payment system in
production
Inter Bank Payment System to prevent System Risk and
collapse of Financial system of the country.
Intra Day Liquidity Facilities
Facilities are needed to resolve the short term liquidity Central Bank need to provide Intra Day
problem of participating bank. Facilities such as Overdraft, Liquidity Facilities as a last resort of
source of liquidity
Central Bank Loan, Money Market, etc. These facilities are
backed by collaterals such Gov Bonds to minimize Credit
Risk.

Real Time Gross Settlement System
Required Functionality
Queue Management
• Queuing Mechanism If the payment instruction cannot be
settled because of insufficiency of the
- Centrally Managed account balance, the instruction will be
queued for the convenience and flexibility
- First In First Out (FIFO) of the RTGS system.
• Gridlock Resolution Mechanism The Queuing principal is First In First Out
(FIFO) base.
- By Pass FIFO But because of this FIFO principal, there
- Reordering, Cancellation, etc could be locked situation occurred among
payment instruction even there’s sufficient
fund is available in the account.
• Queue Monitoring
To resolve the situation, Gridlock
• Settlement Account Monitoring resolution solutions should be provided
and monitoring function for the
• Queue Cancellation participants and the central bank is
required.
- by originated bank
- by Central Bank of the EOD

Real Time Gross Settlement System
Benefits
Benefits
• Remove Settlement Risk for the very important Large Value funds
transfers including Net Positions from the Retail Payment Systems
• Fast turnaround of the funds
• Immediate and Irrevocable Funds transfer
• Easy to execute the monetary policy of the central bank
• Boost economy activities of the country
• Reduce the Systematic Risk of the payment system of the country

Basic Concept of RTGS System

RTGS
Overview of PSC-RTGS
PSC-RTGS System has three (3) main components.
Modules of PSC-RTGS
• Participant End Workstation (TAD)
• RTGS Server
• RTGS Control Workstation (OCT) • Participant information
Participant • User & Approver Control
Workstation • Encryption/Decryption of Data
(TAD) • Transaction Entry
• Reports and Inquiries
Participant Central Bank
RTGS Server
TAD OCT
• Settlement of Payment instruction
• Participant Management
• Settlement Account management
RTGS
TAD Server OCT • Queue Management
Server • Billing
Application Application Application • Inquiry and Monitoring
• Audit Trail
RTGS • Management of the System
• Operation of the system
TAD Local RTGS Server Control
• Monitoring
Database Database Workstation • Parameter control
(OCT) • Participant Management

PSC-RTGS
RTGS Technical
Flow of Message Application Structure
Structured as V-Shaped Message flow Client/Server based configuration
• MS Windows Participant
Participant A Participant B • Participant End
• Visual Basic V 6.0 Workstation
(Sender) (Receiver) • Oracle DB
Application
(TAD)
• UNIX/Solaris
RTGS
• C and JAVA • Server Application
• Oracle DB Server
RTGS Server
Participant Interface
• MS Windows RTGS Control
• RTGS system
Settlement on A and B • Visual Basic V 6.0 Workstation control Application
• Oracle DB (OCT)
16

RTGS
Block Diagram of RTGS System
Supported Types of Transaction
SA A. Inter Bank Fund Transfer
(including 3rd Party)
System Management System
B. Debit Transfer (Central Bank use
Settlement Account Management only)
C. Net Settlement
- Retail Payment Systems
D. Liquidity movement between
Settlement Engine with Current Account and Settlement
Queue Management & Account of a participants
Gridlock Resolution G. DvP
OCT H. PvP
Supported
Net Settlement
Local Simulation Multi Currency
Fund Transfer Multi Language
Function(RTGS) SWIFT Interface
DNS Function
Accounting
DvP Delivery Channel Subsystem System
(Banking)
Queue Management
A. Queuing: FIFO
Cheque B. Cancellation: by Bank & CBN
TAD TAD EFT
Bank 1 Bank N Clearing C. Reordering: by Bank
& etc Centers D. Gridlock Resolution
- Bypass FIFO

PSC-RTGS
Transaction Flow of PSC-RTGS System
Instruction Process Flow
Payment Payment instruction encrypted at TAD
Instruction Decryption Authentication and sent to RTGS server.
Instruction decrypted and
authenticated.
Validation Queue Validate instruction
Bypass FIFO,
FIFO Balance check for the settlement,
Cancellation
settled if the balance is sufficient or
Balance Gridlock queued if the balance is insufficient.
S.A. Queuing
Check Resolution
Result of the settlement is encrypted
and sent to the originator.
Journal is sent to the core banking
Settlement system (Accounting System) of the
central bank
Encryption Accounting
System
Payment
Notify
Order/Advice

PSC-RTGS
Authentication & Validation of Instruction
Authentication Validation
• TAD Key • Institution status
• IP Address • Message Format
• Approver Key • MAC check
• Connection Key
Approver Key control (PKI)
RTGS Server
SMS
Electronically Delivered (8bytes)
Participants
TAD • Key Generation
Key PRT • Key Management
Physically delivered ½ (8 bytes of 16 bytes)
of Approver Key in sealed envelop

PSC-RTGS
Account Structure
• Current Account is used for core
banking activities purpose
• Settlement Account is used for Inter
Central Bank Bank settlement purpose
• Settlement Account can be replenished
Bank’s Accounts at by the participant at the beginning of the
Core Banking System day and moved out to current account at
Bank’s Account at RTGS
Request / Ack the end of the day automatically.
CA • Separating the two account gives each
Response / Order Actual
Core Banking system process more independently and
Transaction create less traffic between two systems
SA SA
Journal LV Transaction
Mirror

PSC-RTGS
Settlement of Net Position (D+0)
The PSC-RTGS has the Simulation
Function of the Net Files that received
Notification to the Participant from Net Settlement system such as
Check Clearing system at each Net
Settlement Session.
Make Multi-Lateral Advice
Simulation At simulation, the notification will be
Net Position of Request Intraday sent to the participant(s) with
Settlement facility insufficient balance to settle the Net
Banks Settlement Request Position.
The participant(s) has 30 min (Central
Net Settlement Systems RTGS System Core Banking Bank can set the time) to replenish the
System settlement account. The time interval
between the Net Simulation and the
settlement can be changed by CBN.
NIBSS
Receive Net
files After the interval time, PSC-RTGS try to
CBN Br settle the Net Position. Each settlement
banks’ Net Position will be settled If the
Net balance is sufficient.
Notification
Simulation
30 Min If there is a participant who has
Interval insufficient balance, the Advice will be
time sent out to Core Banking System (or
Settlement T24 Accounting System) immediately for the
GSS required liquidity.

PSC-RTGS
Control of Process Scheduler
Parameterized Scheduler: Every Processes are parameterized for their start/end time and duration, And process sequence etc.
Automatic/Manual Operation: RTGS system can run Automatic or Manual mode.
Change of Operation Hours: Change of the specific operation process is done by changing the duration of the process

PSC-RTGS
Participant Workstation (TAD)
To RTGS Server To RTGS Server
• Single TAD or multiple TAD can be
used as the participant’s requirement
Communication TAD
TAD
S • The participant can have interface
with their Core Banking package for the
LAN
• Communication Straight Through Processing using XML
• Entry file format.
• Approve XML
TAD TAD Core
C C Banking
Instruction manual entry and Approve
To RTGS Server Functions of TAD
- Payment Entry
TAD - Payment Approval
- Receive Advice
Enter - Receive Reconciliation Data
Authorization - Make Inquires
Instruction
- Make Monitoring
- User Management
Approver approve the - Encryption / Decryption
Instruction that entered. - Reporting
Manual Instruction entry The instruction then
or by interface encrypted with Approver Key

Case Study

Case I :State Bank of Vietnam

State Bank of Vietnam
Overview of IBPS in Vietnam
IBPS in Vietnam Modules of IBPS in Vietnam
The Vietnamese Inter Bank Payment System (IBPS) is
• Terminal Access Device (TAD)
divided into 2 sectors, RTGS and RPS (Retail Payment • Client Application for Participants
System). Participant
• Transaction Entry and Posting
Workstation • Net Settlement Data
Unlike other IBPS in other countries, Vietnamese IBPS is • Reports and Inquiries
Distributed processing systems. They have provincial
level of IBPS for the intra provincial transaction and
national level of IBPS for the inter provincial transactions
• High Value payment
for both high-value and low-value payments via TAD. RTGS
• Settlement of Net Positions
Server • Queue Management
Modules of Vietnam IBPS
• Clearing of Low Value payments
RPS
• Netting of Low Value payments
• RTGS and Retail Payment (Net Settlement Server • Debit Cap control
System) Server for Province center and for
National center
- Processes High Value Payment instruction
- Clearing and Netting of Low Value Payment instruction • Operation Control Terminal (OCT)
Central • Management and control of the
Workstation system
• Terminal Access Device (TAD) For CBN • Monitoring
- Participant Workstation • Operation of the system
• Operation Control Terminal (OCT)
- Central Workstation for Central Bank Use ONLY

State Bank of Vietnam
Overall Structure
Basic Transaction Flow Transaction Flow
IBPS National-wide Transaction
NPSC: Headquarter of SBV
RTGS RPS (National Payment System Center)
Low Value &
High Value Trx
Regional Transaction Regional Transaction
SBV
Extranet
PPC 1: Branch of SBV PPC 2: Branch of SBV
(Provincial Payment Center) (Provincial Payment Center)
TAD TAD TAD TAD TAD TAD TAD TAD TAD
Bank 1 Bank 2 Bank N Bank 1 Bank 2 Bank N Bank 1 Bank 2 Bank N

Case II : Central Bank of Nigeria
(CIFTS)

Central Bank of Nigeria (CIFTS)
Overview of CIFTS
CIFTS in Nigeria Modules of CIFTS
The Real Time Gross Settlement System (RTGS) is • Transaction Entry and Posting
the center of all payment systems in Nigeria. The • Message Encryption/Decryption
Participant
participants are connected using Central Bank of Nigeria • User Management
Workstation
(CBN) Extranet using TAD, the participant end • Reports and Inquiries
(TAD) • Reconciliation
workstation.
• Multi User capability
Electronic Fund Transfer system, Clearing Houses and
Securities systems are connected to CIFTS for the
• Settlement of High Value payment
settlement of the Net Position • Settlement of Net Positions from
Ancillary systems
RTGS
• Settlement Account management
Server • Participant management
• Billing, Reports and Inquiries
Modules of CIFTS • Audit Trail
• RTGS Server
Central • Management of RTGS
• Terminal Access Device (TAD) Workstation • Operation of RTGS
- Participant Workstation For CBN • Operation Monitoring
• Operation Control Terminal (OCT) (OCT) • Transactions Monitoring
- Central Workstation for Central Bank Use ONLY

Central Bank of Nigeria (CIFTS)
Overall Structure
CIFTS
T24
RTGS Core Banking
System
-Journals
High Value Trx -Intraday Facilities
-Liquidity transfer (SA <-> CA)
CBN
Extranet
TAD NIBSS CBN CSCS
TAD
Discount (Low Value Clearing Securities
Participants
Houses System) Houses Settlement

Current Trend of
Large Value Payment System (LVPS)

Current Trend of LVPS
Raised Issues Against RTGS as LVPS
Since the RTGS settlement method is
Required Huge amount of liquidity for Gross base, each participant required
the participants every day to satisfy huge amount needed a day to cover the
payment instructions. And it becomes
the settlement the burden of the participants.
It is tendency of the financial institution
Most of the payment instructions are that they use fund as much as they can
to earn earnings of the fund. It create
entered into the RTGS at last minute the situation that the payment
instructions are entered into the system
before the closing of the system. It
requires system more efficient (larger
system) and the payment system might
exposed at Liquidity Risk because the
lack of time to get liquidity to settle.
Needs are arose to resolve the issues
Hybrid method is for the Liquidity
HYBRID Savings for the participants with Low
For Liquidity Saving Risk Factor

Current Trend of LVPS
Payment Entry by time (Sample)
Statistical Report: BOK-WIRE per 10 Min Statistical Report: Hourly Settlement Rate
Unit: Billion KRW against Total amount of Daily Transaction
Amount of Trx
Number of Trx
Time (Hr)
Ref: Payment System Operation Report of 2007 by Bank Of Korea (BOK)
33

Current Trend of LVPS
Migration from RTGS to Hybrid LVPS
To save the liquidity that needed by
participants and promote the
instruction entry time, the Hybrid
Method of the RTGS function and DTNS
RTGS Hybrid function are employed for the LVPS
recently. For example, Germany
developed RTGS Plus system that
employed RTGS and DTNS function into
RTGS + Net (Offset) the system. Now the TARGET II system
2000 will be the Single Platform for the LVPS
for the EU countries. TARGET II is
hybrid system.
Name of Live Run of
Country
Product Hybrid System
Germany RTGS Plus 2001. 11
Not many countries are planning or
Italy New BI_REL 2003. 6 started the project to convert their
Singapore MEPS+ 2006. 12 RTGS to hybrid system yet.
EU Target2 2008. 7
Japan RTGS-XG 2008. 8
Korea BOL-WIRE 2009. 9

Current Trend of LVPS
Risk Factor of Hybrid LVPS
RTGS system has no Settlement Risk but
the Efficiency of Liquidity is low
High DTNS
DTNS has high Liquidity efficiency and
high settlement risk factor
Settlement
Risk Factor
Hybrid System has no Settlement
Risk factor and high Efficiency of
Liquidity .
RTGS Hybrid
Low
Low High
Efficiency of Liquidity

Current Trend of LVPS
Concept of Hybrid LVPS – TARGET2
Types of Payment Instruction Used
 Express payment: Time critical payment requires RTGS function (FIFO)
 Limit payment: Not so time critical payment that can be offset. Participant can set limit of
this type of payment. The limit can be set bilaterally and multilaterally.
Offsetting Conditions
 Bilateral offsetting take place continuously (Bypass FIFO)
 Multilateral offsetting take place with a time interval (i.e., every 10 min)
and at the end of day (Bypass FIFO)
 New payment instruction entered
 Settlement Account balance increase
 Limit is increased
Others
 Participants can move liquidity to their other account overnight
 Participants can monitor either Outgoing queue or Incoming queue
 Participant can change payment type from express to limit

Current Trend of LVPS
Concept of Hybrid LVPS
Express Instruction:
Time critical payment instruction
Express
Instruction
Settlement Engine Module Limit Instruction:
Not that Time critical instruction that can
be offset.
SA
RTGS Bilateral Offsetting:
When new Limit Instruction entered, it
triggers offsetting between the
Business Queue
Originator and Receiver .
Module Offsetting Multilateral Offsetting:
(Call At a time that setup, Multilateral
(amongst all the participants) offsetting
DvP OTC, Bilateral is processed
Ordinary) Offsetting B Limit
Bilateral Limit:
Limit can be set for the counter party.
Multilateral This limit is used when bilateral
offsetting process.
Offsetting
M Limit Multilateral Limit:
Limit This limit is for total limit.
Limits are set by the participant to
Instruction prevent over drawn their settlement
account for the Express Instruction or to
control their liquidity.

Current Trend of LVPS
Offsetting Mechanism of Hybrid LVPS
Bilateral offset is between the originator
Bilateral Offsetting of the new payment instruction and the
counter party (receiver) of the
instruction.
A B Entry of a new Limit Payment Instruction
triggers the offsetting between two
participants
Multilateral Offsetting Multilateral offsetting is triggered by the
Timer. The interval time can be setup by
the central bank.
Multilateral offsetting involves all the
A queued instruction including Express and
Limit instruction from all the
participants.
B C
D E

Current Trend of LVPS
Settlement Process of Hybrid LVPS
Event Driven
Express RTGS
Instruction Successful Bilateral Offsetting Algorithm will
run when one of the following event
Test Bilateral occurs:
Limit
Instruction Offsetting Successful 3.Submission of new payment
Event Driven instruction
4.Increase of the Settlement
Centralized Settle Account, Limit,
Queue
Monitoring, 5.Settlement, Reordering or
Reordering, Cancellation of first queued
Cancellation Unsuccessful
instruction.
Unsuccessful Time Driven
Successful Multilateral Offsetting Algorithm will
Test Multilateral
Offsetting run at designated time or time
interval of the day. And it will also
Time Driven run at the end of day process.

Current Trend of LVPS
Rules of Settlements
Strict First-In First-Out (FIFO) Principle
Payment
RTGS Hybrid
Priority
Highly Urgent FIFO FIFO
Urgent FIFO FIFO
FIFO can be
Normal FIFO
breached

Current Trend of LVPS
Use of the Limits
In general, limits determine the payment amount (priority = normal) a participant is willing to
pay to another participant (bilateral) or to the other participants (multilateral - towards which
no bilateral limit is defined), without having received payments (that are credits) first.
It is possible to set the following types of limits:
• Bilateral limit
• Multilateral limit
The limits are debit limits and not credit limits.
The setting of these limits enables the direct participant:
• to prevent unbalanced dissipation of liquidity with regard to other direct
participants.
• to avoid free-riding on the liquidity of a direct participant by another participant.
• to synchronize the payment flow with other direct participants and to promote its
early submission.

Current Trend of LVPS
Bilateral Limits
Bank A Bank B Bilateral position
The bilateral position from Bank A
Normal Liquidity for Normal towards Bank B is defined as the
Payments Settling normal Payments sum of payments received from
to Bank B Payments to Bank A Bank B (credits for Bank A),
minus the sum of payments made
to Bank B (debits for Bank A).
This means if the result is
negative, the bilateral limit will be
utilized with this amount.
Effect of bilateral limit
With the bilateral limit, the direct
participant restricts the use of
liquidity when submitting normal
payments for another direct
Bilateral limit participant.
Usable liquidity
of Bank A for settlement
vis-à-vis Bank B with Bank B
Usable liquidity
for settlement
with Bank B

Current Trend of LVPS
Multilateral Limits
Bank A Bank C,D,E… Multilateral position
The multilateral position from
Normal Liquidity for Normal Bank A is defined as the sum of
Payments Settling normal Payments payments (credits for Bank A)
to Bank C,D,E… Payments to Bank A received from all direct PM
participants towards which no
bilateral limit has been defined,
minus the sum of payments
(debits for Bank A) made to these
direct PM participants. This
means if the result is negative,
the multilateral limit is utilized
with this amount.
Effect of multilateral limit
With the multilateral limit, the
Bilateral limit direct PM participant restricts the
Usable liquidity
of Bank A use of liquidity, when submitting
for settlement
vis-à-vis normal payments for any other
with Bank C,D,E…
Bank C,D,E… direct PM participant for which a
bilateral limit has not been set.
Usable liquidity
for settlement
with Bank C,D,E…

Current Trend of LVPS
Achievement of the Hybrid System
Achievements
• Liquidity Saving for the participants
• Low Settlement Risk and High efficiency of the Liquidity
• Make the participants for early entry of the payment instructions

Case III : Hybrid LVPS in Other
Countries – EU

Hybrid LVPS in European Union
Target 2 in EU Central Bank
The TARGET2 is Single Shared Platform
(SSP) that supports all the participants
in EU and will be completed in 2008.
Once the TARGET2 completed, all the
RTGS systems in each member countries
will not be used.
• Standardization: to support all the
member countries
• Neutrality: Neutrality of difference of
the market and infrastructure that each
member countries hast
• Common platform and Single Share
Platform (SSP): All the participants in
EU use singly system
• Single Price structure: Has single cost
structure with in TARGET2
• Enhance the liquidity management:
support liquidity management function
to all the participant, Liquidity reserve
function by Highly urgent, Urgent and
Normal
• Transparency of Queue monitoring
• Interbank direct debits
• Future maturity date payment
instruction: within 5 business day

LVPS in European Union
Target 2 in EU Central Bank
TARGET2 Hybrid System
Standing Static Data
Payment Module (PM) Facilities Management
(SF) (SM)
Payment Processing Home Accounting
Module Monitoring
(HAM)
Participant Ancillary
Target
Interface Systems Reserve Contingency
Interlinking
(Y-Copy) Interface Management Module
(RM) (CM)
Standard
Information and Control Module (ICM)
Interface
Credit Ancillary
Internal
Institution Systems
Accounting
(CI) (AS)

LVPS in European Union
Modules of Target 2 System
Module Functions
- Payment Processing
- TARTGE Interface
Payment Module (PM) - Participant Interface (SWIFT Y copy)
- Ancillary Systems Interface (ASI)
- Interface with Accounting System of the central bank
Standard Interface (SI) - Collateral Management
- Overnight Deposit Accounts
Standing Facilities (SF) * - Marginal Lending Accounts
Static Data Management (SM) - Parameter control module
Monitoring - Monitoring of the system
The Reserve Management Module (RM) enables the CBs to
Reserve Management (RM) * perform some not full functionality for the reserve
requirements management.
* Optional for each Central Bank

LVPS in European Union
Modules of Target 2 System
Module Functions
Home Accounting Module (HAM) manages accounts that can be
held by two different kinds of users:
- Banks and other entities, according to the rules defined by the respective CB
- CB customers (correspondents and others) not allowed, according to the
TARGET Guideline, to open accounts in the PM
Home Accounting
HAM accounts, according to the specific situation of each
Module (HAM)
individual country, can be held by:
-banks not direct PM participant, but subject to minimum reserve requirements
and wishing to manage cash withdrawals, deposits, etc. directly.
- banks which are direct PM participant, but need to have a second set of
accounts in order to settle specific operations
The use of the CM is only envisaged for the processing of critical
Contingency Module and very critical payments in specific situations. These are:
(CM) • Unavailability or inaccessibility of the SSP components.
• The time needed for the activation of the alternate site/region lasts too long.
Participants (credit institutions, ancillary systems, other
Information and participants and CBs) with comprehensive online information tools
Control Module (ICM) and easy-to-use control measures appropriate to their different
business needs.

LVPS in European Union
Transfer Mechanism using SWIFT net
TARGET2 Hybrid System
PM ICM
SWIFTnet SWIFTnet
FIN Y copy InterAct & FileAct
SWIFTnet
SWIFT Alliance 3rd Party Solution
Separately purchased
Participant application

Case IV : Hybrid LVPS in Other
Countries - Korea

Bank of Korea
Hybrid System for BOK
Current System Future System Current System
BOK’s current Large Value Payment
System is RTGS base. Web enabled
client terminal for the participants
Future System
RTGS Hybrid LVPS IM BOK’s future Large Value Payment
System will be Hybrid base system.
The future system will have Server-to-
Server interface with the core banking
system at participant bank. The purpose
Web Server Middleware for Web of Server-to-Server interface is to
facilitate straight through processing of
Server to Server Server the payment instruction. Current web
enabled client lacks direct interface with
core banking system of the participant
Current web enabled client will be still
Web Web Web used for the participant who don’t want
Server Server to have direct connection with payment
PC PC PC
system.
Bank A Bank B Banking Banking Bank Information Monitoring
System A System B Participant can access the information
from IM module.

Bank of Korea
BOK System – New Hybrid
Settlement Engine
Settlement Engine with Queue
Settlement Queue
Engine Management Management
G/L This Module settle the instruction from
Business Module each Business module
Management CLS PvP
Information Business Module
Module KRW Fund
Transfer DvP Call Business modules for each different
type of business
Interface Module
AS Web Host to Web Application Server
Interface Interface Host
Presentation layer
Ancillary Web Bank C’s
Systems Server Core
Banking
System
BOK Web Terminal
Extranet
Participant’s Terminal
Participant ‘A’ Participant ‘B’
Web Terminal Web Terminal

Basic Concept of Hybrid LVPS

Hybrid LVPS
Application Structure
SWIFT
TAD Alliance
Standard Supplied
Optional
application by SWIFT
Central
SWIFT
Bank
Net
ExtraNet
Provided Provided
by CB by SWIFT Note: Using SWIFT Net is optional
and supported message type is
only for the financial messages.
HELPS® For Reports, Inquiries and other
Standard messages needs to be purchased
application separately.

Hybrid LVPS
Client (Participant End) Workstation
FOR THE LARGE VALUE PAYMENT
Client/Server base Participant End Workstation SYSTEM, CLOSED USER GROUP
NETWORK IS STRONGLY
RECOMMENDED.
• for Financial instructions processing (Payments)
• for Control instructions processing Participant End Workstation
• for Information monitoring This Participant End Workstation is for
the central bank who prefer to utilize
own network for the intra country funds
movement rather than using third party
network, such as SWIFT.
SWIFT Interface (Optional)
This web client is complete system to
transact the Large Value payments
• for Financial instructions processing (Payments)
SWIFT Interface
• other function than financial instruction needs to be
built separately by third party vendor SWIFT Interface is for the central bank
who prefer to utilize SWIFT network for
the intra country funds movement rather
than using own network.

PSC Hybrid LVPS
Application Configuration
Participant Module: Participant Module:
Terminal Access Device (TAD) SWIFT Alliance
Participant Participant Participant Participant
TAD TAD Alliance Alliance
Full Copy Full Copy Full Copy Full Copy
CB SWIFT
Network Net
Payment instruction is
reassembled at SWIFT
CB Alliance
Settlement Settlement
Module Module
For information and control purpose, other SWIFT
TAD has COMPLETE SETS of required functions
Network and special application is needed.

Conclusions
Implementation of LVPS
Items Description
• Well defined legal framework is necessary
Legal Framework
• Well defined Rules and Regulation
Requirements • Well defined requirements
Communication network • Between the participants and the central bank (SWIFT or
own network)
• Interface with other systems such as the retail payment
systems
Intra Day Liquidity • Liquidity facilities needed from the central bank as a last
resort to the participants

Conclusions
LVPS Application Solution
Items Description
Proven solution • Proven system that operates in other central banks
Settlement Method • Hybrid System recommended for the liquidity saving
Interface • Interface with Accounting System
• Interface with Retail Payment Systems
• Interface with other systems
Participant End • Standalone workstation application for the central bank’s
Workstation
own network or
• SWIFT Terminal for the usage of SWIFT financial network

Conclusions
Hardware Systems
Items Description
Main processing system • Open platform
Database • Relational Database Management System
Communication protocol • TCP/IP base
Workstations • PC
User Interface • Graphical User Interface

THANK YOU

Q and A