E Payment System Introduction Of Large Value Payment System

Introduction of Large Value Payment System October 2008

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

Inter Bank Payment System (IBPS)

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

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

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

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

Real Time Gross Settlement (RTGS)

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

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

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

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

Real Time Gross Settlement System 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 Benefits

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

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

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

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

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

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

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

PSC-RTGS 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 Control of Process Scheduler

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

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

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

Case II : Central Bank of Nigeria (CIFTS)

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

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

Current Trend of Large Value Payment System (LVPS)

Required Huge amount of liquidity for the participants every day to satisfy the settlement Most of the payment instructions are entered into the RTGS at last minute Needs are arose to resolve the issues Since the RTGS settlement method is Gross base, each participant required huge amount needed a day to cover the payment instructions. And it becomes the burden of the participants. It is tendency of the financial institution that they use fund as much as they can to earn earnings of the fund. It create 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. Hybrid method is for the Liquidity Savings for the participants with Low Risk Factor HYBRID For Liquidity Saving Current Trend of LVPS Raised Issues Against RTGS as LVPS

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

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

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

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 – TARGET2

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

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

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

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

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 Use of the Limits

Bilateral position The bilateral position from Bank A towards Bank B is defined as the sum of payments received from 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. Bank A Bank B Normal Payments to Bank B Normal Payments to Bank A Liquidity for Settling normal Payments Bilateral limit of Bank A vis-à-vis Bank B Usable liquidity for settlement with Bank B Usable liquidity for settlement with Bank B Current Trend of LVPS Effect of bilateral limit With the bilateral limit, the direct participant restricts the use of liquidity when submitting normal payments for another direct participant. Bilateral Limits

Bank A Bank C,D,E… Normal Payments to Bank C,D,E… Normal Payments to Bank A Liquidity for Settling normal Payments Bilateral limit of Bank A vis-à-vis Bank C,D,E… Usable liquidity for settlement with Bank C,D,E… Usable liquidity for settlement with Bank C,D,E… Current Trend of LVPS Multilateral position The multilateral position from Bank A is defined as the sum of payments (credits for 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 direct PM participant restricts the use of liquidity, when submitting normal payments for any other direct PM participant for which a bilateral limit has not been set. Multilateral Limits

Current Trend of LVPS 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 Achievement of the Hybrid System

Case III : Hybrid LVPS in Other Countries – EU

Hybrid LVPS in European Union 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 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. Target 2 in EU Central Bank

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

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

LVPS in European Union Module Functions Home Accounting Module (HAM) 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 HAM accounts, according to the specific situation of each 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 Contingency Module (CM) The use of the CM is only envisaged for the processing of critical and very critical payments in specific situations. These are: • Unavailability or inaccessibility of the SSP components. • The time needed for the activation of the alternate site/region lasts too long. Information and Control Module (ICM) Participants (credit institutions, ancillary systems, other participants and CBs) with comprehensive online information tools and easy-to-use control measures appropriate to their different business needs. Modules of Target 2 System

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

Case IV : Hybrid LVPS in Other Countries - Korea

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 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 of Server-to-Server interface is to facilitate straight through processing of the payment instruction. Current web enabled client lacks direct interface with core banking system of the participant Current web enabled client will be still used for the participant who don’t want to have direct connection with payment system. Information Monitoring Participant can access the information from IM module. Bank of Korea RTGS Web Server Web PC Web PC Bank A Bank B Hybrid LVPS Middleware for Server to Server Server Server Banking System A Banking System B IM Web Server Bank Web PC Hybrid System for BOK

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

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

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

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

Conclusions Implementation of LVPS Items Description Legal Framework Well defined legal framework is necessary 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 Workstation Standalone workstation application for the central bank’s own network or SWIFT Terminal for the usage of SWIFT financial network

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

E Payment System Introduction Of Large Value Payment System

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to E Payment System Introduction Of Large Value Payment System (20)

Recently uploaded (20)

E Payment System Introduction Of Large Value Payment System

Editor's Notes