Intro of Large Value Payment system

Information about Intro of Large Value Payment system

Published on May 24, 2009

Author: vuquyhai



Slide 1: Introduction of Large Value Payment System October 2008 Slide 2: 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 Slide 3: Inter Bank Payment System (IBPS) Slide 4: 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. Slide 5: 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 Slide 6: Risks of Inter Bank Payment System Inter Bank Payment System Slide 7: 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 Slide 8: Real Time Gross Settlement (RTGS) Slide 9: 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. Slide 10: 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 Slide 11: 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 Slide 12: 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 Slide 13: Real Time Gross Settlement System Slide 14: Basic Concept of RTGS System Slide 15: 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 Slide 16: Flow of Message 16 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 Slide 17: 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 3rd 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 Slide 18: 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 Slide 19: 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 Slide 20: 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 Slide 21: 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 Slide 22: 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 Slide 23: 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 Slide 24: Case Study Slide 25: Case I :State Bank of Vietnam Slide 26: 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 Slide 27:  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 Slide 28: Case II : Central Bank of Nigeria (CIFTS) Slide 29: 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 Slide 30:  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) Slide 31: Current Trend of Large Value Payment System (LVPS) Slide 32: 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 Slide 33: 33 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 Slide 34: 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 Slide 35: 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 Slide 36: 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 Slide 37:  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 Slide 38: 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 Slide 39: 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 Slide 40: Current Trend of LVPS Strict First-In First-Out (FIFO) Principle Slide 41: 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 Slide 42: 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. Slide 43: 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. Slide 44: Current Trend of LVPS Slide 45: Case III : Hybrid LVPS in Other Countries – EU Slide 46: 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. Slide 47: 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 Slide 48: * Optional for each Central Bank LVPS in European Union Slide 49: LVPS in European Union Slide 50: 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 Slide 51: Case IV : Hybrid LVPS in Other Countries - Korea Slide 52: 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 Slide 53:  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 Slide 54: Basic Concept of Hybrid LVPS Slide 55: 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 Slide 56: 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 Slide 57: 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 Slide 58: Conclusions Slide 59: Conclusions Slide 60: Conclusions Slide 61: THANK YOU Slide 62: Q and A

Related presentations

Other presentations created by vuquyhai

Marketing Management summary
18. 10. 2009

Marketing Management summary