2007年-ECB欧洲央行_TARGET2-Securities_-_Technical_feasiblity_14页_211kb

T2S Technical Feasibility Summary

Core Content

This document outlines the technical feasibility of implementing the TARGET2-Securities (T2S) platform on the existing TARGET2 Single Shared Platform (SSP) infrastructure. It highlights the benefits of reusing existing components and infrastructure, as well as the assumptions and design considerations for the T2S system.

Main Viewpoints

1. Synergies with TARGET2

• Architectural Integration: T2S will be fully integrated into the TARGET2 architecture (two regions and four sites), enhancing resilience and organisational efficiency.
• Technical Infrastructure Reuse: The production, test, and training environments of TARGET2 will be leveraged, with potential scaling through existing or new components.
• Tools and Systems: Existing tools for change management, trouble management, and technical monitoring will be reused.
• Internal Network: The T2 internal network (3CBNet) will be used for data exchange, with bandwidth adjusted as needed.
• Segregation Flexibility: The segregation level between T2S and TARGET2 can be optimised to balance functional synergies and system resilience.
• Load Balancing: Differences in peak hours (daytime for payments, nighttime for securities) allow for load balancing.
• Archiving Enhancements: Existing archiving functionality on TARGET2 will be enhanced for T2S, enabling long-term storage of data.

2. Functional Assumptions

• T2S involves a higher number of message types (16:10 ratio) and more complex processes than TARGET2.
• MT5xx message types are more complex than those currently used in TARGET2.
• Matching procedures depend on various instruction types and business cases.
• Complex matching rules and a high number of instruction types (>40) require detailed parameterisation.
• A large number of market rules must be supported throughout the lifecycle.
• Real-time and batch optimisation will require more algorithms than TARGET2.
• Multi-currency settlement may be necessary.
• ICM must support more items per function than TARGET2.
• A wide variety of static data (CSDs, ISINs, accounts, rules, access rights) is essential for system operation.
• Static data changes must be activated in real time or delayed for the next business day.

3. Workload Assumptions

• Average Daily Transactions: 2.1 million T2S transactions (about 4 million settlement instructions).
• Peak Day Capacity: The system can handle up to 4 million transactions (8 million settlement instructions) using capacity-on-demand.
• Batch Processing: 70% of transactions are processed in batch mode at night (1.47 million transactions).
• Real-Time Processing: 30% of transactions are processed in real-time during the day (0.63 million transactions).
• Peak Hour Load: Real-time peak hour workload is estimated at 189,000 transactions, with the worst-case scenario reaching 294,000 transactions due to overlapping with TARGET2's peak.
• Message-to-Transaction Ratio: Approximately 1:6.

High-Level Application Design

3.1 Application Architecture

• The T2S application is structured into independent, loosely coupled modules.
• Communication between modules uses standardised protocols.
• Key modules include:
  • Instruction Validation: Validates instructions against global and local rules.
  • Instruction Matching: Matches instructions using global or local criteria, with parameter-based tolerance.
  • Pre-settlement and Settlement: Manages liquidity forecasts, optimisation algorithms, and securities/cash booking.
  • Additional Accounting Services: Handles account management and non-standard operations.
  • Other Services: Includes archiving and billing, with periodic user reports.
  • Static Data Management: Provides a single point for static data creation, modification, and deletion, with versioning and emergency procedures.
  • Interfaces: Supervises traffic flow, performs syntax, data format, and authorisation checks. Interfaces will use SWIFT FIN, FileAct, InterAct, and other A2A/U2A methods.

3.2 Application Scalability

• The architecture supports horizontal and vertical scalability.
• Concurrency Control: Ensures database efficiency by splitting complex tasks into "light" asynchronous processes.
• Database Design: Prioritises isolation of critical data and predefined access paths.
• Uncommitted Read Access: Allows reading of non-definitive data, with consistency checks and process restart capabilities.
• Pipeline Processing: Enables parallel scheduling of modules for increased throughput.
• Database Load Management: Ensures that only essential processes access the database, avoiding contention.

Infrastructure Design

4.1 Environments

• T2S requires multiple independent processing environments to support development, testing, and live operations.
• The number of environments aligns with the application development lifecycle.

4.2 Technical Operation

• High automation is expected to reduce human error and simplify infrastructure management.
• The system ensures confidentiality, integrity, auditability, identification/authentication, and access rights.
• Mainframe-based operations alternate between two regions.

4.3 Security

• T2S will be fully compliant with TARGET2 Security Requirements and Controls (T2SRC).
• Security is managed at both system and network levels, using firewall systems for perimeter defence.

4.4 External Network Connection

• Flexible Connectivity: CSDs may use different connection solutions based on their volume and batch/individual message ratio.
• SWIFTNet: Will be used for dedicated connections, with T2S supporting a single message format for all sources.
• Provider Responsibility: The Eurosystem will define the connection solutions and specify providers and equipment.

4.5 Internal Network Connection

• T2S will use the same internal network (3CBNet) as TARGET2, with high-bandwidth fibre-optic channels (DWDM) for intra-region and inter-region communication.
• Bandwidth details include:
  • Region 1 SITE A - Region 2 SITE D: 1 Gbit/sec
  • Region 1 SITE B - Region 2 SITE C: 1 Gbit/sec
  • Region 1 SITE A - Region 1 SITE B: 2 Gbit/sec
  • Region 2 SITE C - Region 2 SITE D: 2 Gbit/sec

4.6 Technical Monitoring

• Technical monitoring aims to detect and resolve issues before service interruption.
• Key objectives include:
  • Monitoring availability of critical resources.
  • Managing specific events (errors, hardware faults).
  • Measuring system throughput and response time.
  • Reacting to resource utilisation thresholds.
• Automation reduces operational costs and human error.

4.7 Business Continuity

• The T2S infrastructure is designed for high resilience and business continuity.
• The system is based on the TARGET2 SSP architecture (two regions, four sites).
• Intra-region Recovery: Synchronous remote copy ensures recovery within a region.
• Inter-region Recovery: Asynchronous remote copy enables recovery between regions.
• Out-of-region Arrangements: Required for regional disasters, with no dependency on the same infrastructure or staff.
• Rotation Process: Periodic live environment swaps ensure staff readiness and system alignment.
• System Availability: Ensured in both regions to support uninterrupted operations.

Conclusion

The study concludes that there are no technical obstacles to implementing T2S on the TARGET2 platform. The T2S on T2 concept offers significant cost savings and operational benefits, supported by a robust and scalable infrastructure. The design includes comprehensive business continuity measures, ensuring high availability and resilience in both normal and abnormal scenarios.