Advertisement

Sosialisasi BI-RTGS & BI-SSSS Gen II - 10 November 2011.pptx

Mar. 30, 2023
Advertisement

More Related Content

Advertisement

Sosialisasi BI-RTGS & BI-SSSS Gen II - 10 November 2011.pptx

  1. 10 November 2011 Pengembangan Sistem BI-RTGS/SSSS Generasi II Sosialisasi kepada Peserta BI-RTGS dan BI-SSSS
  2. 2 Outline 1. Perkembangan & Rencana Proyek 2. Kebijakan Penggunaan Jaringan Komunikasi 3. Persiapan Infrastruktur TI Peserta
  3. 3 Perkembangan & Rencana Proyek
  4. 4 Tahun Kegiatan 2008  Penyusunan Grand Design  Kebutuhan Bisnis (Business Requirements)  Prognosa Market Liquidity dan Financial Market Deepening 2009  Penyusunan Request For Proposal (RFP)  Evaluasi Produk Aplikasi RTGS-SSS Generasi II  Proses Pengadaan 2010  Proses Pengadaan  Sosialisasi kepada Peserta dan stakeholders lainnya  Penyusunan Ketentuan 2011  Penyusunan Functional Specifications dan Design Specifications  Development (Product Customization)  Sosialisasi kepada Peserta dan stakeholders lainnya  Penyusunan Ketentuan (PBI dan SE) 2012  Ujicoba (Unit Test, SIT, UAT, UIT, Simulation/Industrial Test)  Sosialisasi kepada Peserta dan stakeholders lainnya  Penyusunan Ketentuan (PBI, SE, SOP, juklak, juknis) & Bye Laws  Pelatihan kepada Peserta  Persiapan implementasi  Implementasi Project Milestones
  5. 5 Progress 2008 2009 2010 2011  Market Consultation (dengan WG Perbankan)  Workshop & Benchmarking  Penyusunan Grand Design  Penyusunan Business Requirements  Penyusunan Request for Proposal (RFP)  Evaluasi Produk- Produk Aplikasi RTGS dan SSSS  Persiapan Pengadaan  Proses Pengadaan  Sosialisasi kepada Peserta dan stakeholders lainnya  Proses Pengadaan Selesai  Penyusunan Functional & Design Specification  Sosialisasi kepada WG dan seluruh Peserta  Development 2012  Ujicoba  Sosialisasi kepada Peserta dan stakeholders lainnya  Penyusunan Ketentuan  Pelatihan kepada Peserta  Implementasi
  6. 6 Project Plan 1 Project Initiation 2 Participants Briefing (Sosialisasi) 3 Infrastructure Design 4 Infrastructure Procurement 5 Analysis Phase & System Design 6 Procedures, Rules & Regulations 7 Customisation & Development 8 Installation 9 BI + WG Training 10 UAT 11 Participants Training 12 Deployment 13 Industrial Testing 14 Preparation to Go-Live 15 System Cut Over No Project Milestone & Activities 2012 Mar Apr May Jun Jul Apr Mar Feb 2011 May Jun Jul Aug Sep Oct Nov Dec Jan Aug Sep Oct
  7. 7 Project Plan
  8. 8 Project Plan 30 Mei – 26 Juni 2012 16 Juli – 5 Oktober 2012
  9. 9 Project Plan 9 Juli – 14 September 2012 Rabu, 17 Oktober 2012
  10. 10 Kebijakan Penggunaan Jaringan Komunikasi
  11. 11 Kebijakan Jaringan Komunikasi  Fully BI-Ekstranet  Protokol Komunikasi TCP-IP  Enhance Existing BI-Ekstranet (SKN, SID, LBU, LHBU)  Enhanced Features  Managed Service  Secured Leased Line  Bandwidth Allocation  Bandwidth Optimization  Dual Line
  12. 12 Persiapan Infrastruktur Teknologi Informasi Peserta
  13. 13 1. System Description 2. Application Requirement 3. Communication Requirement 4. Security Requirement 5. Participant Platform 6. Participant Things To Do Infrastructure Guidelines
  14. 14 System Description
  15. 15 System Description (1)
  16. 16 System Description (2)  Compliance with Standard and Certification Programs (BIS Core, CPSS/IOSCO)  Distributed architecture with a Central Node at BI site  All system components are open to allow adaptable and easy integration, and centrally managed  Access rights management is role-based  Messages Oriented System  Web Based Application Technology  Two Factor Authentications (2FA) using Token and/or HSM
  17. 17 Application Requirement
  18. 18  Guidance in preparation of Bank Internal System  Explanation of the transaction flow between the Participant and the Central Node (Host)  Message Oriented System  Message Handling Logic  Details of information and transaction formats Application Requirement Overview
  19. 19 Application Requirement Message Oriented System (1/2)  Messages Oriented System  One incoming message can produce one /several outgoing messages  Messages will be stored in the hosts database and will be automatically sent to the participant when connects to the system RTS/X DEPO/X TRAD/X Request Reply 1 Reply 2 Reply N …
  20. 20 Application Requirement Message Oriented System (2/2)  SWIFT Message Structure (MT and MX)  Message Flow : V-Shape Scheme  Message Exchange between Central Node and Participants using XML Format V-Shape Central Node BI- EXTRANET DP-A DP-B
  21. 21 Application Requirement Message Handling Logic Provided in participant guideline for each type of transactions, consist of:  Message Flow Diagram  Message Flow Description  Message Sequence and Message Type  Message Type Structure and Field Description
  22. 22 Application Requirement Transfer from one DP to another DP Transfer from one Direct Participant to another Direct Participant RTS/X DPB DPA 5: Transfer 6: Credit confirmation 7: Cancellation notification OK 4: Debit confirmation 1: Transfer 2: Validation error notification 3: Settlement delay notification KO  OK OK KO OK KO Validation KO OK OK Possible to settle now? KO Waiting for settlement  Settle or reject mode? OK KO End-of-day or timeout cancellation Flow Diagram
  23. 23 Application Requirement Transfer from one DP to another DP Flow Description  DP A sends payment order to CN (Message 1: MT102 or MT202 or MT103).  CN validates this message and notifies DP A in case of rejection of the order due to errors found during validation procedure (Message 2: MT296 or MT196)  CN tries to settle this order and notifies DP A in case of the order is queued or suspended (Message 3: MT296 or MT196). This message is sent to DP A only if this participant has the “Queue notification” flag switched “on” in the database. The payment order is queued if the priority set for this payment order has no “settle-or-reject” flag. Otherwise, this payment order is rejected immediately if settlement is not possible.  After settlement of the payment order DP A receives Debit Confirmation (Message 4: MT900). This message is sent to DP A only if this participant has the “MT900” flag switched “on” in the database.  DP B receives a copy of the payment order (Message 5: MT202 MT103 or MT102).  DP B receives Credit Confirmation (Message 6: MT910). This message is sent to DP B only if this participant has “MT910” flag switched “on” in the database.  If this payment order remains queued or suspended at the end-of-day it is rejected by CN automatically. DPA receives Cancellation notification (Message 7: MT296 or MT196)
  24. 24 Application Requirement Transfer from one DP to another DP Message Sequence and Message Type Sequential Number of Message in the Diagram SWIFT Message Type Name of Message at Diagram 1 MT102 or MT103 or MT202 Transfer 2 MTn96 Validation error notification 3 MTn96 Settlement delay notification (optional) 4 MT900 Debit confirmation (optional) 5 MT102 or MT103 or MT202 Transfer 6 MT910 Credit Confirmation 7 MTn96 Cancellation Notification
  25. 25 Application Requirement Transfer from one DP to another DP Message Type Structure & Field Description Tag Field Name Predefined Value Comment Sender BIC of DP-A Receiver BIC of the System 113 Payment priority Refer to “Priority management scheme” 20 File reference Contains a reference of MT102. This reference should unique in the system in conjunction with Sender’s BIC and value date of the MT102 23 Bank Operation Code This field should contain a value ‘CREDIT’ 26T Transaction Type Code These transaction codes should be agreed between Participants and CB. This field should be presented either in this block or in the repetitive sequence 77B Regulatory reporting 3*35x Information agreed between Participants of the system and CB. This field should be presented either in this block or in the repetitive sequence … … …
  26. 26 A web-based application with Graphical User Interface (GUI) Provides :  Manual input of payments data;  Construction of batches from individual payments data;  Manual import of batches in RTS/X format;  Up to 4-steps in payment capturing/authorization procedure;  Receiving of batches with payments from the system;  Manual export of batches received from the system Central Node in RTS/X format;  Full-functional online monitoring facilities. Application Requirement Payment Gateway as Participant Platform (1/2)
  27. 27  Transactional interface of PG provides exchange with RTS/X Central Node via messages in SWIFT-like format, Examples :  Batch files with payment instructions;  Batches with rejects or returns of payments;  Request and text messages;  Reports on replies and unsolicited reports.  Accounts and Positions;  Files/batches status and processing history;  Details of each instruction and status…etc;  No SWIFT-like messages are used in monitoring interface, dedicated internal data exchange mechanism is used.  One Participant can open only one transactional connection to the system simultaneously. Application Requirement Payment Gateway as Participant Platform (2/2)
  28. 28 Communication Requirement
  29. 29 Communication Requirement
  30. 30  Leased Line connectivity to BI Ekstranet  Upgrade existing connectivity using Managed Services Communication Requirement Number of Message / Day Required Bandwidth Recommended Bandwidth < 1000 128 kbps 256 kbps > 1000 256 kbps 512 kbps > 20000 > 512 kbps  Connectivity should be Established as with Primary as with Backup site  Besarnya bandwidth disesuaikan dengan kebutuhan Bank
  31. 31 Security Requirement
  32. 32  Comply with Two Factor Authentication (2FA) Policy  Participant should be equipped with Token (provided by BI)  Token will handle security task up to End-User Level, i.e. message signing and encrypting  To achieve High Performance goal, HSM (Hardware Security Module) should be provided by Participant on their own  In order to ensure compatibility, Participant should comply HSM specification. (Spec will be released by BI)  HSM Product Info  Brand: SafeNet  Type: Luna PCI Express 7000 (embedded), Luna CA4 (Network Attached) Security Requirement
  33. 33 Participant Platform
  34. 34 Participant Platform Hardware & Software Requirement (Server) < 500 Connections 500 up to 1000 Connections 1000 up to 2000 Connections Processor One quad-core Intel Xeon 3 Ghz or similar One six-core Intel Xeon or similar Two six-core Intel Xeon or similar RAM 6 GB or higher 16 GB or higher 16 GB or higher Hard Disk 2 x 146 GB (RAID1) 2 x 146 GB (RAID1) 2 x 256 GB (RAID1) Operating System Win 2003 or 2008 R2 Server x64 (64-bit) Standard Edition Win 2003 or 2008 R2 Server x64 (64-bit) Standard Edition Win2003 or 2008 R2 Server x64 (64-bit) Standard Edition RDBMS software Oracle 11gR2 is recommended. The following editions can be used:  Oracle XE  Oracle One  Oracle Standard edition  Oracle Enterprise edition Oracle 11gR2 is recommended. The following editions can be used:  Oracle One  Oracle Standard edition  Oracle Enterprise edition Oracle 11gR2 is recommended. The following editions can be used:  Oracle One  Oracle Standard edition  Oracle Enterprise edition Web server software Tomcat (will be provided as a part of installation pack) Tomcat (will be provided as a part of installation pack) Tomcat (will be provided as a part of installation pack) Other software Java 6 Java 6 Java 6
  35. 35 Participant Platform Hardware & Software Requirement (Workstation) Processor Intel Pentium IV or better RAM 1GB Hard Disk 2 GB spare disk capacity, at least doubled size of the RAM for stable and reliable function of the operating system Monitor Minimum is 15” monitor that supports 1024x768; 20” LCD is recommended for supervisors. Operating System Microsoft Windows 7 with latest service packs installed Internet Browser Microsoft Internet Explorer 6.0 or later, with latest security updates installed Another software PKI installer (will be provided as a part of installation pack) Antivirus software is recommended for each workstation that is used for communication with the system
  36. 36 Participant Platform Installation Configuration : Standalone RTS/X server Stand-Alone Payment Gateway Participant workstation RTS/X Interface RTS/X Central Node RTS/X Participant Node
  37. 37 Participant Platform Installation Configuration : Shared RTS/X server Local Shared Payment Gateway Participant workstation … RTS/X Interface Local Bank Node RTS/X Participant Node Participant workstation … Participant workstation …
  38. 38 Participant Things To Do Items Things To Do Timeline Availability Application  Application Enhancement July 2012 Communication (Network)  Provide Leased Line with minimum bandwidth requirement  Upgrade connectivity with Managed Services (QoS) June - Agt 2012 Platform  Hardware and Software Procurement (New/Upgrade) June – Agt 2012 Security  HSM Procurement June 2012 Testing Preparation  Environment  Personel April 2012 (WG) June 2012 (Others)
  39. 39 TERIMA KASIH
  40. 40 DASP  Jultarda Hutagalung (jultarda@bi.go.id - 3818769)  M. Latif (latif@bi.go.id - 3818781)  Diki Tedriana (diki_t@bi.go.id - 3817375)  Ahmad Arifin (ahmad_arifin@bi.go.id - 2310108 ext. 4033) DPM  Nefia Epsilartini (nefia@bi.go.id - 3817421)  Feri Noor (feri_noor@bi.go.id - 2310108 ext 4017) DPSI  Budi Adrianto (badrianto@bi.go.id - 3817568) Contact Person BI
Advertisement