Regional Payment and Settlement System An Overview

Transcription

1 Regional Payment and Settlement System n Overview General information COMES community, being an association of 20 s in frica has mandated the COMES Clearing House (CCH) to implement a system to facilitate cross-border payment and settlement between s in the COMES region. In order to achieve the above, COMES approved the implementation of a multilateral netting system, named REgional Payment and Settlement System (REPSS). Mandatory requirements formulated for REPSS established a set of principles that REPSS should follow. In particular, REPSS should: e compliant with international best practices and standards; chieve finality and irrevocability in the payments/settlements environment; Speed up overall payment process; llow efficient liquidity management for s and s; Reduce transaction costs; Reduce all types of risks; Provide monitoring facilities for all banks and s; Provide efficient centralized environment for intra-regional payments; Provide statistical information and analysis for COMES community; Provide centralized OFC filtering. short overview of REPSS system features and architecture design is presented below. System Components The following REPSS components are shown at the diagram:

2 REPSS Core and REPSS gateway, or Node of REPSS system, is installed at COMES sites. REPSS Core is based on PIE technology and provides services for integration of COMES systems and other applications with REPSS. Node provides: Message exchange with s via SWIFT network or VPN; Routing of answers and other messages to s; Processing of messages received from s; Exchange rates management in the area of responsibility of CCH; General accounting in terms of functionality necessary to fulfil CCH functions; Calculation and managing of positions; Control of limits (Debit, Credit, Country limits); Maintenance of participant directory and static data; Interaction with Settlement for settlement of Clearing results; Interaction with COMES internal systems; Calculation of fees, charges etc. Report generation; Enquiries processing; ccess rights and security control; Online monitoring; Event processing; udit and archiving; Others. REPSS dministrative and Monitoring workplaces provide COMES users with Graphic User Interface that allows them to perform all monitoring, administration and maintenance functions. REPSS monitoring ( ) provides users with online monitoring capabilities via Graphic User Interface. Monitoring is provided on real-time basis and includes all information related to a particular including its trades, its limits, collaterals, crosscurrency rates, business day schedule, and other financial information. This workplace is based on thin client technology and may work via Secure Extranet (VPN) or using SWIFTNet rowse/interact service. REPSS monitoring ( ) provides users with online monitoring capabilities via Graphic User Interface. Monitoring is provided on real-time basis and includes all information related to a particular including its trades, cross-currency rates, business day schedule, and other financial information. This workplace is based on thin client technology and may work via Secure Extranet (VPN) or using SWIFTNet rowse/interact service. This component is supposed to be introduced at the second stage of a project. Payment system is a National payment system that is currently used by bank for processing of domestic payments (usually RTGS system). ccounting system is a system that is used by for payment processing.

3 Payment exchange schemes REPSS supports a set of payment flow scenarios that allows s and COMES to use a scenario that is most appropriate for every case. ll of these scenarios are based on a common payment exchange scheme that is presented below. Settlement REPSS Customer _ Customer of needs to pay Customer of Customer 1. Debit Leg at a National level Customer-Payer present a payment order to ; sends to National payment system (RTGS) with as a Credit Party (V-Shape or Y-Copy); Payment is settled in NPS with a mark that it should be processed in REPSS. Nota bene: Upon bilateral agreements may present to National Payment System (NPS) 202 sending directly to -Receiver. 2. Processing in REPSS sends to REPSS (V-Shape with Y-Copy as an option for future use); REPSS includes this payment into clearing, settles Session results through a Settlement ; REPSS routes a payment to Receiving. Nota bene: Upon agreements between s and COMES, may present to REPSS 202 sending directly to -Receiver. 3. Credit Leg at a National level receives a payment from REPSS (and, possibly, from corresponding ); Payment is settled in NPS and routed to Receiver (V-Shape or Y- Copy); receives and distributes it to a Customer.

4 Nota bene: Upon bilateral agreements may receive 202 from NPS and directly from -Sender. Drawings below demonstrate possible payment flow scenarios in REPSS. These scenarios may be used together. Settlement REPSS Customer _ Customer Settlement 202 REPSS 202 Customer _ Customer

5 Transaction Processing Principles REPSS supports the following transaction processing principles: TODY Processing with T+n Settlement date. Currently it is assumed settlement will be done on T+0, T+1 or T+2 basis. Online Clearing of individual transactions with immediate Settlement through a Settlement is an option as well; Country Holiday management: o transactions from s with a Holiday on Processing and/or Settlement date is not allowed; o transactions to s with a Holiday on Processing and/or Settlement date is not allowed; o transactions with a Holiday on Settlement date at Settlement is not allowed; REPSS processes payments in USD and EUR. Value in USD/EUR may be specified by Customer, or even (an option). Every payment processed through REPSS should contain: o Value of transaction in USD or EUR (field 32a) plus (optionally) o Value in local currency (field 33a) REPSS maintains a list of National currency rates and calculates cross-currency rates. s should update their local currency rates periodically or online as per regulations established. REPSS issues alerts if value of transaction in local currency doesn t correspond to a value in Settlement currency (USD or EUR) according to crosscurrency rates defined. REPSS supports Net Debit Limits (Debit Caps) per and controls that position of doesn t exceed a Net Debit limit set; Net Debit Limits values are defined by CCH administration;

6 REPSS supports ilateral Debit and Credit Limits playing a role of bilateral agreements between s. pplication architecture The backbone of the architecture is its multi-layer structure. Such architecture provides a highly secure, reliable and high performance solution together with comprehensive monitoring and control possibilities and dedicated integration bus for existing systems, if any. The pplication and usiness Layers represent the core of COMES CCH. User Interface Layer The User Interface Layer, implemented as HTTP server, provides users with a graphic user interface. This layer enables COMES users and authorized users to monitor financial and other information using secure HTTPS protocol either via LN, VPN or SWIFTNet rowse/interact respectively (as shown at the figure). pplication Layer The pplication Layer is where the user request is first processed. This processing includes user authorization, standard request validation and transformation to XML message format. Reports and other high-volume information are also delivered to users by the pplication Layer. usiness Layer This Layer is responsible for performing of all functions as Clearing, alancing, Settlement, Exchange Rate management, etc.

7 n approach to implement business logic is based on a business process driven model. It is the layer where all message processing logic is implemented, from managing standard business processes such as interaction with SWIFT services to providing for local regulations and business requirements. Depending on the type of incoming request, the business layer component automatically invokes the corresponding business process. s there is a wide range of existing parameters (collected over multiple implementations in many countries) from which to choose, it is easy to adjust the COMES business processes to meet specific local requirements. For example, it is possible to add supplemental validation procedures for selected incoming messages. s for business rules, new parameters may be added without any changes in the middle-tier software. The logic in this layer is implemented in the form of UML activity diagrams. The usiness Layer uses the Oracle database for permanent storage of business process management, control and monitoring. Integration us The Integration us provides intelligent and flexible interaction with external systems via different protocols and data formats. This provides excellent possibilities for evolution through integration with other systems without the need for software modification. The Integration us layer includes functionality for message exchange with external systems. Its major function is to provide message transformation to match the requirements of the integrated systems, whether host-based, SWIFTbased or another proprietary protocol. Dedicated application exchange rules, message transformation rules, request/reply reconciliation, etc. are supported in the adapter developed specifically for each integrated system. This layer provides smooth and intelligent interaction facilities with other COMES systems.