Statement of Objectives
Iraq Stock Exchange
for an Electronic Trading and Settlement system Technical Specifications Table of Contents
TOC \o "1-3" TECHNICAL SPECIFICATIONS PAGEREF _TOC74189521 \H 1 I. BACKGROUND PAGEREF _TOC74189522 \H 1 A. OBJECTIVES OF THE PROPOSED SYSTEM PAGEREF _TOC74189523 \H 1 B. TECHNOLOGY OBJECTIVES PAGEREF _TOC74189524 \H 1 C. STATEMENT OF WORK PAGEREF _TOC74189525 \H 1 D. DESIGN OF THE PROPOSED SYSTEM PAGEREF _TOC74189526 \H 2 E. IDENTIFICATION OF MANDATORY AND PREFERRED CRITERIA PAGEREF _TOC74189527 \H 2 II. CAPITAL MARKETS APPLICATION SOFTWARE (AS) REQUIREMENTS PAGEREF _TOC74189528 \H 2 A. CORE FUNCTIONS PAGEREF _TOC74189529 \H 2 B. SCREEN-BASED TRADING SYSTEM PAGEREF _TOC74189530 \H 3 C. INSTRUMENTS PAGEREF _TOC74189531 \H 3 D. ORDER BOOKS PAGEREF _TOC74189532 \H 3
1. Public Order Book PAGEREF _Toc74189533 \h 4
2. Block Order Book PAGEREF _Toc74189534 \h 4
3. Odd-Lot Order Book PAGEREF _Toc74189535 \h 4
4. Member Order Book PAGEREF _Toc74189536 \h 4 E. MARKET SEGMENTS PAGEREF _TOC74189537 \H 5 F. TRADING ENVIRONMENT PAGEREF _TOC74189538 \H 5
1. Trading Floor PAGEREF _Toc74189539 \h 5
2. Trading Floor Displays PAGEREF _Toc74189540 \h 6 G. AUTOMATED TRADING PAGEREF _TOC74189541 \H 6
1. Order Entry PAGEREF _Toc74189542 \h 6
2. Order Types PAGEREF _Toc74189543 \h 6
3. Order Deletion and Correction PAGEREF _Toc74189544 \h 7
4. Order Validation PAGEREF _Toc74189545 \h 7
5. Trade Execution PAGEREF _Toc74189546 \h 7
6. Trade Reporting PAGEREF _Toc74189547 \h 8
7. Maintaining Liquidity PAGEREF _Toc74189548 \h 8 H. MANUAL TRADING PAGEREF _TOC74189549 \H 8 I. MARKET INFORMATION PAGEREF _TOC74189550 \H 8
1. Objectives and Requirements PAGEREF _Toc74189551 \h 8
2. Data Types PAGEREF _Toc74189552 \h 9
3. Internal Data Distribution PAGEREF _Toc74189553 \h 10
4. Data Presentation and Usage PAGEREF _Toc74189554 \h 10
5. Billing PAGEREF _Toc74189555 \h 10 J. MEMBER SERVICES PAGEREF _TOC74189556 \H 10 K. INQUIRIES AND REPORTS PAGEREF _TOC74189557 \H 11 L. SURVEILLANCE PAGEREF _TOC74189558 \H 11
1. Basic Tools PAGEREF _Toc74189559 \h 11
2. Stock Watch Alerts PAGEREF _Toc74189560 \h 12
3. Audit Trail PAGEREF _Toc74189561 \h 12
4. Market Reconstruction PAGEREF _Toc74189562 \h 12 M. CLEARING AND SETTLEMENT PAGEREF _TOC74189563 \H 12 N. TRADE ENTRY /CAPTURE PAGEREF _TOC74189564 \H 12 O. INPUT OF SETTLEMENT INSTRUCTIONS PAGEREF _TOC74189565 \H 13 P. TRADE COMPARISON/AFFIRMATION PAGEREF _TOC74189566 \H 13 Q. SETTLEMENT PAGEREF _TOC74189567 \H 13
1. Delivery Versus Payment PAGEREF _Toc74189568 \h 13
2. Settlement Period PAGEREF _Toc74189569 \h 14
3. Trade for Trade Settlement PAGEREF _Toc74189570 \h 14
4. “Good Delivery” Rule PAGEREF _Toc74189571 \h 14
5. Payment PAGEREF _Toc74189572 \h 14 R. REPORTS PAGEREF _TOC74189573 \H 14 S. CENTRAL SECURITIES DEPOSITORY (CSD) PAGEREF _TOC74189574 \H 15
1. Introduction PAGEREF _Toc74189575 \h 15
1. Dematerialization of Depository Holdings PAGEREF _Toc74189576 \h 15
2. Instruments PAGEREF _Toc74189577 \h 15
3. Participants PAGEREF _Toc74189578 \h 16
4. Transaction Entry /Capture PAGEREF _Toc74189579 \h 16
5. Account Types PAGEREF _Toc74189580 \h 16
6. Accounting PAGEREF _Toc74189581 \h 16
7. Settlement Instructions PAGEREF _Toc74189582 \h 17
8. Lost and Stolen securities PAGEREF _Toc74189583 \h 17
9. Securities Lending /Borrowing PAGEREF _Toc74189584 \h 17
10. Corporate Actions PAGEREF _Toc74189585 \h 17
11. Account Reconciliation PAGEREF _Toc74189586 \h 17
12. Risk Management PAGEREF _Toc74189587 \h 18 III. COMPUTER HARDWARE (HW) REQUIREMENTS PAGEREF _TOC74189588 \H 18 A. TECHNOLOGY PLATFORM PAGEREF _TOC74189589 \H 18
1. Hardware and Software Generation PAGEREF _Toc74189590 \h 18 B. HARDWARE RELIABILITY PAGEREF _TOC74189591 \H 19
1. Back-up Capabilities PAGEREF _Toc74189592 \h 19
2. Power Conditioning PAGEREF _Toc74189593 \h 20 IV. COMMUNICATIONS (CM) REQUIREMENT PAGEREF _TOC74189594 \H 20 A. NETWORK STANDARDS PAGEREF _TOC74189595 \H 21 B. NETWORK EXPANDABILITY /MANAGEMENT PAGEREF _TOC74189596 \H 21 C. NETWORK SECURITY PAGEREF _TOC74189597 \H 21 V. SYSTEM SOFTWARE AND TOOLS (SS) REQUIREMENTS PAGEREF _TOC74189598 \H 21 A. OPERATING SYSTEM AND UTILITY REQUIREMENTS PAGEREF _TOC74189599 \H 21 B. STANDARDS PAGEREF _TOC74189600 \H 21 C. SECURITY PROVISIONS PAGEREF _TOC74189601 \H 21
1. Language PAGEREF _Toc74189602 \h 22
2. Training PAGEREF _Toc74189603 \h 22 D. APPLICATION SOFTWARE PAGEREF _TOC74189604 \H 22 E. HARDWARE PAGEREF _TOC74189605 \H 22
1. Central Server PAGEREF _Toc74189606 \h 22
2. Member Equipment PAGEREF _Toc74189607 \h 23 F. SYSTEM SOFTWARE PAGEREF _TOC74189608 \H 23 G. TELECOMMUNICATIONS PAGEREF _TOC74189609 \H 23 H. SECURITY PAGEREF _TOC74189610 \H 23 VI. SOFTWARE DEVELOPMENT (SD) REQUIREMENTS PAGEREF _TOC74189611 \H 24 A. RELATIONAL DATABASE MANAGEMENT SYSTEM PAGEREF _TOC74189612 \H 24 B. PROGRAMMING TOOLS PAGEREF _TOC74189613 \H 24 C. DOCUMENTATION PAGEREF _TOC74189614 \H 25 VII. TURNKEY MANAGEMENT (TM) REQUIREMENTS PAGEREF _TOC74189615 \H 25 A. PRIOR EXPERIENCE OF SIMILAR PROJECTS BY EACH CONTRACTOR PAGEREF _TOC74189616 \H 25 B. EXPERIENCE AND QUALIFICATIONS OF PROJECT DIRECTOR PAGEREF _TOC74189617 \H 25 C. STAFFING PAGEREF _TOC74189618 \H 25 D. SYSTEMS ACCEPTANCE AND PROJECT SCHEDULE PAGEREF _TOC74189619 \H 25 E. PROJECT PLAN PAGEREF _TOC74189620 \H 25 F. ACCEPTANCE TESTING PAGEREF _TOC74189621 \H 26 G. CHANGE NOTICE PROCEDURE PAGEREF _TOC74189622 \H 26 VIII. TRAINING AND DOCUMENTATION (TG) REQUIREMENTS PAGEREF _TOC74189623 \H 26 A. TRAINING CLASS DESCRIPTIONS PAGEREF _TOC74189624 \H 26 B. APPLICATION TRAINING DATABASE PAGEREF _TOC74189625 \H 27 IX. SUPPLIER REFERENCES AND PRODUCT PERFORMANCE (SP) PAGEREF _TOC74189626 \H 27 A. CAPACITY PLANS AND PROJECTIONS PAGEREF _TOC74189627 \H 27 X. MAINTENANCE AND SUPPORT (MS) REQUIREMENTS PAGEREF _TOC74189628 \H 28 A. MAINTENANCE PLAN PAGEREF _TOC74189629 \H 28 B. SUPPLIER MAINTENANCE SUPPORT FACILITIES PAGEREF _TOC74189630 \H 28 XI. BID EVALUATION METHODOLOGY PAGEREF _TOC74189631 \H 28 A. EVALUATION ALGORITHM PAGEREF _TOC74189632 \H 28 B. LIST OF MANDATORY CRITERIA PAGEREF _TOC74189633 \H 29
1. Application Software (AS) PAGEREF _Toc74189634 \h 29
2. Computer Hardware (HW) PAGEREF _Toc74189635 \h 31
3. Communications Equipment /Software (CM) PAGEREF _Toc74189636 \h 31
4. System Software and Tools (SS) PAGEREF _Toc74189637 \h 31
5. Software Development (SD) PAGEREF _Toc74189638 \h 32
6. Turnkey Management (TM) PAGEREF _Toc74189639 \h 32
7. Training (TG) PAGEREF _Toc74189640 \h 32
8. Supplier References and Product Performance (SP) PAGEREF _Toc74189641 \h 32
9. Maintenance and Support (MS) PAGEREF _Toc74189642 \h 32 XII. MANDATORY BID FORMAT PAGEREF _TOC74189643 \H 32 A. EXECUTIVE SUMMARY PAGEREF _TOC74189644 \H 32 B. MANDATORY TECHNICAL CRITERIA PAGEREF _TOC74189645 \H 32 C. APPLICATION SOFTWARE (AS) PAGEREF _TOC74189646 \H 33 D. COMPUTER HARDWARE (HW) PAGEREF _TOC74189647 \H 33 E. COMMUNICATIONS EQUIPMENT /SOFTWARE (CM) PAGEREF _TOC74189648 \H 34 F. SYSTEM SOFTWARE AND TOOLS (SS) PAGEREF _TOC74189649 \H 34 G. SOFTWARE DEVELOPMENT (SD) PAGEREF _TOC74189650 \H 35 H. TURNKEY MANAGEMENT /SYSTEMS INTEGRATION (TM) PAGEREF _TOC74189651 \H 36 I. TRAINING AND DOCUMENTATION (TG) PAGEREF _TOC74189652 \H 36 J. SUPPLIER REFERENCES AND PRODUCT PERFORMANCE (SP) PAGEREF _TOC74189653 \H 37 K. MAINTENANCE AND SUPPORT (MS) PAGEREF _TOC74189654 \H 38 L. DELIVERABLES PAGEREF _TOC74189655 \H 38 M. BROCHURES AND PRODUCT LITERATURE PAGEREF _TOC74189656 \H 38 XIII. COST PROPOSAL PAGEREF _TOC74189657 \H 38
Iraq Stock Exchange – Request for Proposals for an Electronic Trading and Settlement system Technical Specifications BACKGROUND The Iraq Stock Exchange (ISX) formerly the Baghdad Stock Exchange is working to become one of the core financial centers in the Middle East through adoption of leading edge technology and provision of superior service levels to investors, issuers and their intermediaries. The key objectives are to:
Eliminate the manual trading floor;
Conduct trading from its member offices;
Dematerialize traded securities; and Establish a Central Securities Depository and Central Share Registry that settles trades in accordance with international standards and best practices.
This section contains the Technical Specifications of the system being sought by this RFP.
Objectives of the proposed system ISX's goal is to establish itself as a "World-Class" market. ISX seeks to:
Establish a reputation, domestically and internationally as fair, liquid and efficient.
Minimize the risks associated with clearing and settling securities transactions.
Instill public and investor confidence in the exchange and its procedures.
Reduce trading and settlement costs.
Enable brokers to trade from their offices rather than a Manual Trading Floor.
Strengthen international competitiveness.
Attract both local and international investors.
Accommodate high trading volumes.
Technology Objectives
Efficient automation is essential to meeting ISX goals. Its automation goals are to:
Accommodate trading growth in an affordable manner without straining staff or market operations.
Reduce the paper and labor-intensive nature of trading and settlement.
Provide ISX members an efficient, inexpensive means of trading and settlement.
Enable the exchange to be self-supporting and cost-effective irrespective of transaction volumes.
Integrate trading, settlement and member operations into a smooth seamless chain with minimal manual steps between processes.
Develop a skilled staff able to maintain and enhance its automated systems.
Statement of Work
The ISX seeks to automate the securities market life cycle. This will include primary issuance, secondary market trading, clearing, settlement and depository and registry operations. The vendor selected under this RFP will be obligated to deliver a fully functioning system that meets the mandatory requirements stated in this document.
Design of the proposed system The proposed system architecture will take advantage of distributed processing, use of servers and personal computers, and integrate “off-the-shelf” software where possible. The systems should conform to open systems standards. This is to reduce dependence on a single hardware supplier, protect against rapid obsolescence, minimize maintenance costs and ensure interoperability of all system modules.
Identification of Mandatory and Preferred Criteria The remainder of this section defines the mandatory and preferred technical requirements and specifications of the automated trading, clearing, settlement and depository system equipment, software and services being procured through this tender.
Predefined (Mandatory and Preferred) Evaluation Criteria are associated with each system requirement.
<M> Mandatory requirements must be satisfied in their entirety for a bid to be considered responsive and to be evaluated.
<P> Preferred specifications define functions that are desired but not required.
If a criteria mark (either M or P) appears after a section heading or before a paragraph, it pertains to the entire section or paragraph.
If a criteria mark appears after a sentence, then it pertains to the sentence only.
If criteria marks appear for both a paragraph/section and a sentence within that section, the criteria mark for the sentence takes precedence over the mark for the paragraph/section.
CAPITAL MARKETS APPLICATION SOFTWARE (AS) REQUIREMENTS
Core Functions
The Iraq Stock Exchange requires a packaged system (the trading system may be bid separately from the settlement system) that supports the following core functions:
Screen-Based Trading: Both automated Order-Driven and manual trading support is required. The system must support multiple instrument types including Equities, Corporate Debt instruments, Government Bonds and Treasury-Bills. The trading system must provide for the dissemination of market data to data vendors, news services, ISX members and other interested parties. It must also calculate statistical data such as the day's opening, high and low prices and market indices.
Automated Clearing and Settlement: The system must enable the ISX to comply with the recommendations of the International Securities Services Association.
Central Securities Depository (CSD): It is the intent of the ISX that all shares lodged with the depository be dematerialized as required by Iraqi law. Settlement of all transactions (both certificated and dematerialized) will be through the depository. The depository will maintain the identity of the beneficial owner of all securities registered in its books.
Electronic Interface: The system must provide direct electronic interfaces to all ISX participants. Broker /Dealers will be provided on-line, real-time access. Custodians and Company Registrar /Transfer Agents will access the system via dial-up communications.
Electronic Surveillance: Automated market surveillance is required. It must provide alerts of potentially suspicious activity and must have the ability to reconstruct the market as it existed at any point in time.
Member Services: The system must provide basic support services to all trading /broker members. It must capture and make available at member workstations price quotations (bids and offers) and other market data. ISX Broker /Dealer members will execute their trades via the system from their offices.
Management Information System: The system must provide Management Information System (MIS) support for the ISX and its depository.
Screen-based trading system The first element of the system is a screen-based order-driven trading system to manage ISX trading. Its key functions are:
Provide market participants the information needed for trading.
Accept orders from broker workstations and/or systems.
Validate the orders.
Execute orders when buy and sell orders match.
Store orders in an electronic file in time within price sequence.
Report executed orders to trading counterparties.
Report locked-in trades to settlement.
<P:AS-1> Preference will be given to technically advanced and proven systems.
<P:AS-2> A quote-driven capability (i.e. accommodate dealers) would be a plus.
Instruments
The system must support the trading of stocks, warrants, rights, bonds, debentures, Treasury Bills (T-Bills) and other debt instruments. Any security listed on the exchange must be tradable from any authorized workstation.
<P:AS:3> The trading of Mutual Funds, Options, Futures and other instruments may be added in the future. Therefore, preference will be given to a system that also accommodates derivatives and other non-equity, non-debt instruments. The trading of asset-based securities would also be a plus.
Order Books
Three categories of trading shall be supported; Regular, Odd-lot and Large Parcel (Blocks) Order Books. The difference between these order books is in the number of shares per order in the Order Books. The books must show market depth. Individual orders may be viewed only by the member firm that entered them (and by surveillance personnel). All ISX listed securities will be eligible for automated trading and settlement.
Public Order Book
The Public Order Book must hold open orders and quotes from all members. The Public Order Book display must consolidate orders by security, limit price, and side of the market (Buy/Sell).
Block Order Book
Institutional Investors as opposed to retail investors generally trade large Parcels or Blocks. These are often traded away from the market (i.e. at a different price). The amount by which a block's execution price may vary from the last sale or current bid and offer shall be strictly limited. The amount of this variation shall be a settable parameter. Block size shall also be a settable parameter.
<P:AS:4> Large Parcel Trading: The Large Parcel Board shall make provision for both Crossing and Bulletin Board trading. A mechanism for negotiating large blocks shall be provided. The Bulletin Board service should enable the advertising of large parcels available for trading or to indicate an interest in trading in size.
Processing Negotiated and Crossed Trades: Negotiated trades are trades negotiated between the buyer and seller. Crossed trades are trades in which the same broker represents both the buyer and the seller. Both trade types are reported through the system manually. The system must support both single-sided and two-sided input. In single-sided input, the system would accept a trade report from one party. It would report the transaction to the counterparty. That counterparty would be required to affirm or deny the trade. In two-sided input, both buyer and seller report the trade and the system matches the trade reports and confirms or rejects the transaction.
Undisclosed Order Quantity: An undisclosed order quantity feature is required. Sellers and buyers in quantity generally do not want to expose their intentions lest that knowledge affect the market price. The system must therefore enable submission of orders with only a partial quantity shown in the public order book with the balance of the order held as undisclosed. The disclosed portion would be stored in the file in time within price sequence. The undisclosed amounts would “drip-fed” to the book whenever the disclosed quantity was executed. Any undisclosed portion would be behind all open (disclosed) orders at the same price. The priority of newly disclosed orders would be based on the date and time of the disclosure.
Odd-Lot Order Book
<P:AS:5> The Odd-lot Board shall cater to the trading of parcels of shares that are smaller than 1 Board Lot (usually 100 shares). Board lot shall be a settable parameter on both a book and individual security basis. Odd-lot trades can execute at prices that are a modest percentage away from the market. The amount of this variation shall be a settable parameter.
Member Order Book
<P:AS:6> The Member Order Book will contain orders that a member holds but has not yet released to the market. The system shall enable easy and immediate release of an order or group of orders from the Member book to any of the other books.
Market Segments
The system will operate six hours per day. The market will be broken into multiple segments. The time of day each segment operates shall be configurable. The segments are:
Pre-Open: traders enter orders for participation in the opening and/or inclusion in the book. No trading takes place. At a specified time before the opening, The system will calculate the anticipated opening price, the number of shares that would execute at that price and the buy or sell imbalance; and then disseminate an order imbalance message to show potential investors the state of the market’s pre-opening <P:AS:7>.
Market Open: The Opening is a pure, single-price auction. All buy and all sell orders are compared. Orders are executed at the Equilibrium price (the price at which the largest number of shares would trade). If more than one price meets this criterion, the price closest to the previous closing price will be used. If more than one price meets this second criterion, the higher price shall prevail. If a Market Order is submitted and no corresponding order exists on the contra side or if the resulting price exceeds a pre-specified amount from the previous closing price, the Market Order will be rejected back to its originator as unexecutable.
Continuous Trading: Participants enter orders for immediate execution or for inclusion in the book. Automatic matching and execution takes place based on best price /first-in, first out trading rules. The system captures details of trades executed and reports them via Contract Notes and other reports.
Market Close: Closing time shall be a settable parameter. Immediately after the close, the closing prices for all securities will be calculated and disseminated to market participants. To prevent price manipulation at the close, an average of the last several trades or last half hours trades will be used. If Market on Close orders are supported, these would be executed at this time <P:AS:8>.
Post Closing: Day orders and other orders whose term has expired are cancelled and returned to their originators.
Primary Issuance: While not a requirement of the automated trading system, the exchange seeks an ability to allocate Initial Public Offerings (IPO) among potential subscribers <P:AS:9>.
Trading Environment
Trading Floor
The system must be able to function without a trading floor. ISX seeks to automate as much of the trading process as practical while retaining the human element of trade negotiation. A dependable and secure Wide Area Network (WAN) must be provided to enable members to enter orders and to execute trades from their offices.
The ISX will provide alternative facilities for member use in the event of a failure of their computer or communications systems.
Trading Floor Displays
<P:AS:10> The exchange may want to install an electronic market information display facility such as a Data Wall or Video Wall to provide dramatic visible evidence of a functioning exchange to visitors. This will be part of a public visitor’s gallery that would be used to promote the exchange with foreign institutional investors and other visitors, local school groups and anyone else interested in the market and its workings. A Trading Floor display device, if offered, must be separately described and priced as an optional extra (in the financial proposal).
Automated Trading
Order Entry
All order entry will be on-line. Exchange members will enter, change, and cancel orders through workstations on the floor or in their offices. Only authorized traders at authorized workstations will be permitted to enter orders. The size of order and order type permitted each level will be a settable parameter. The system must assign a unique order number to every order entered.
<P:AS:11> Three levels of trade authorization shall be provided. These are trader, supervisor and trading manager. These shall be controlled at order entry time.
All transactions (orders, reports, etc.) must be time-stamped at each major stage in their processing (e.g. upon acceptance, at execution or cancellation. Each order entered (if validated) will be matched against orders in the book or placed in the order book.
The system must be capable of identifying the underlying customer, the customer type and country of residence or incorporation.
Order Types
Both Market Orders and Limit Orders must be supported.
Day and GTC Orders: The Limit Orders submitted may be Day or GTC. A Day order expires, if unexecuted, at the end of the trading day. A Good Till Cancelled (GTC) order has an extended lifetime. The permitted time period for GTC orders must be settable.
<P:AS:12> Other Order Types: The system must support Immediate Or Cancel (IOC), Fill Or Kill (FOK), All or None (AON) and Opening Only orders. IOC is an order to buy or sell, wholly or in part, as soon as bidding starts. The part of the order that is not executed is cancelled. FOK is an order to buy or sell a particular security immediately. If the order is not executed at once, it must be treated as cancelled. AON orders must be executed in their entirety. An Opening Only order is an order that is included in the opening. Any part of the order that is not executed is cancelled.
Order Deletion and Correction The system must enable the easy deletion of orders that have not yet been executed. It must also enable the correction /modification of unexecuted orders. Modified orders take their place in the queue base on the time of order modification.
Order Validation
Transaction Edit Checks: All orders must undergo the usual data validation checks and reasonableness checks. Client ID will be provided with most orders. The system must assign each order its own unique transaction number.
Price Disparity: If a Market Order on the electronic book is more than a certain settable percentage away from the last sale price, it must be rejected as extreme under the assumption that its submitter should positively accept the wide disparity in price.
The system will have a minimum price increment. This shall be a settable system parameter.
<P:AS:13> Trade restrictions: There are two restrictions to trading. Short selling is prohibited. On certain securities (generally bank shares) foreign ownership is restricted. In both cases, it would be desirable to inquire against the depository database to determine whether these restrictions apply. Foreign ownership shall be checked pre-trade. The system should reject trades that would cause this limitation to be exceeded. The percentage must be an adjustable parameter that is settable by security or by sector.
Trade Execution
Orders must be matched and executed in time within best price sequence.
Public Limit Orders will form the basis for price discovery. The system shall therefore provide a mechanism for easy and fast entry and withdrawal of open orders.
During trading hours, Market orders will be executed immediately against the best bids or offers extant in the system. To execute a market order, the member will select a corresponding bid or offer from the book, enter the desired quantity and execute the trade.
If a Limit Order is submitted whose bid is higher than the best offer on the book or whose offer is less than the best bid on the book, that order shall be treated as a Market Order and executed at the Book price(s). If the Limit Order's volume is greater than the posted volume, a trade will be executed at the volume in the book and the remainder will be entered in the book.
Circuit breakers will be used to curb excessive volatility. The daily price fluctuation shall be limited to plus or minus a specified percentage (settable parameter). When the price of a security exceeds the fluctuation limit, a circuit breaker would kick in and trading in that security would be halted for a specified period of time.
Trade Reporting
A trade ‘Confirmation’ must be produced for each trade immediately following its execution. Confirmations must be available via hardcopy and computer-to-computer transmission. Each user must be able to customize its own confirmation reports. Each trade must be reported electronically to all participants in the trade, to the depository system for settlement, to the market data broadcast system and to the trading system's internal data dissemination system.
Maintaining Liquidity
<P:AS:14> Liquidity is defined as the ease with which securities can be traded at prices that are reasonable in relation to the underlying supply and demand conditions. Related to liquidity is price stability. The system's treatment of its order flow should be designed to provide some level of protection to the suppliers of liquidity.
<P:AS:15> Special provision should be taken to protect Limit Orders from abusive trading practices. Limit Orders have been described as a free trading option that becomes "in the money" when adverse information becomes available to traders and "stale limit orders" are outstanding on the book. When new information comes to the market, the equilibrium price (price reflecting overall supply and demand) may need to be revised (i.e. the limit order price may need to be bid up or down accordingly). This would require continual checking of market conditions. Limit order positioners place their orders to avoid the requirement of constant market monitoring. They are ill placed to perform that function. Therefore, mechanisms for the protection of limit orders should be devised.
<P:AS:16> More sophisticated protection can be devised such as providing brokers with special commands to remove orders quickly under certain special market conditions for which the investor has provided pre-arranged instructions.
Manual Trading
The system must support manual trading (trades executed away from the exchange). The buyer and seller will each key their understanding of the trade into the system. The system will then attempt to match the buy report against the sell report. If the trade matches, it is reported as a locked-in trade. Unmatched reports must be rejected back to their originators.
Market Information
Objectives and Requirements The ISX seeks to provide its members, their clients, the media, market data vendors and other subscribers accurate real-time market information. Therefore the system must publish last sale and best bid and offer data (including volumes) on a real-time basis.
Two methods of data delivery are required, via broadcast and via the trading system network. To the extent feasible, the system should observe ISO International Standard Message Formats. The system must have a special message capability (e.g. publish opening imbalances, total shares available for purchase by foreigners).
Data Types
Two primary data types will be collected by the exchange:
System Generated: This is real-time market information generated by or through the trading system. This includes bids, offers, last sale data (i.e. most recent trade price and volume), administrative notices, market statistics, etc. It may also be desirable to publish a consolidated anonymous order book. The system must generate market indices on a real-time basis. It must publish statistical information including Price Earnings Ratio (PER) and Price to Book Value (PBV) on request. Trade reports and related statistics must be prepared at the end of each trading day. Provision must be made for faxing or electronically transmitting selected reports to local newspaper offices and other interested parties.
<P:AS:17> Company News: ISX collects from its listed companies a number of corporate and financial reports (e.g. dividend announcements, notices of rights offerings, news releases, etc.). At present, ISX publishes these data in paper form. It would be a plus if the proposed system were able to publish these data electronically via the ISX Web Site.
Publication of Indices: The system must periodically calculate and publish a ISX All-Share Index and /or ISX Sector and /or other indices. These should follow the IFC (international Finance Corporation) formula for calculating indexes.
The system must be able to disseminate prices in real-time. It must also be able to display the price (bids, offers, last sale and volumes) of a stock or a select group of stocks on demand through a workstation. Trading party ID would be excluded from the broadcast. ISX seeks the widest possible coverage at the lowest possible cost. Ideally the broadcast will be available countrywide.
<P:AS:18> Some alternatives are listed below.
Radio-based Data Broadcast: In this approach, ISX would broadcast its electronic ticker via radio signal. This could be direct or by piggybacking on the guard-band of an existing FM broadcast (the key factors would be how wide an area would be covered by the signal, licensing and cost). ISX members need this information available country-wide. The range of a radio broadcast may be limited to greater Baghdad.
Two-way VSAT Technology: Satellite broadcast would have the benefit of equal cost regardless of location but may be too expensive overall. Using the telephone network requires dedicated lines from the ISX to every remote location although a common trunk could serve multiple sites in the same general location.
Television: One technology worth investigating may be piggybacking on a television broadcast. This can be done with no effect on the television picture. The data would be transmitted in the Vertical Blanking Interval (VBI) which is the interval between one television frame and the next.
Internal Data Distribution All data contained within the system must be available to any authorized user on the system. The system must be able to restrict access on a user ID level and a firm level. The system must provide members with full access to the book and show book depth. The book display would profile the limit order book showing the volume of shares bid and offered at each price with cumulative totals.
The trading system's network must have a messaging capability. It must provide the means to easily send messages to any particular workstation, firm or operator (or to all destinations) on the network. This capability would be used to publish trade advisories and confirmations. It would also be used to send special alerts and administrative messages.
Data Presentation and Usage The proposed system must provide a market data broadcast and the software to use it. The broadcast and software will be used in a number of ways. It will enable members to install visual displays and market monitors in their customer trading rooms. It will provide other services such as historical inquiry, portfolio management, limit order alerts, dramatic price change alerts, real-time position valuation, broker sales tools, etc. The system must include receiver electronics (e.g. antennae, modems, etc.). These would be used to deliver the broadcast to a PC or other computer /server in the member's office. The system should provide the facilities through which member firms can provide customer oriented displays. These would include rolling tickers, scrolling tickers, video displays, electronic wallboards, market monitors, printers etc. The software must provide software exits or links which enable users to customize the system to meet their own individual needs. Members will be responsible for acquiring and implementing their own displays.
Billing
ISX will charge a small fee to non-member subscribers of its data. A billing module is required.
Member Services
The system must provide ISX members facilities that would enable them to access the trading, settlement and depository services from their offices. Those facilities can be in the form of a PC workstation. Those workstations would appear as client devices on the exchange server. They could, in turn, act as server computers on the member’s own network.
These facilities must provide access to all market information for which the user is authorized. It must provide access to the various limit order books. It must accept orders and produce execution reports. It must enable access to clearing and settlement services and to the depository. One of the goals of this service is to eliminate redundant keying. The system must support multi-site brokers with multiple sites.
<P:AS:19> The trading system must be capable of allowing each user to program a number of price and volume alerts. These alerts would operate in a windows-type environment.
The local broker system must maintain a real-time market information database. Brokers need access to real-time information for multiple purposes (gallery displays, portfolio pricing, analytics, etc). A local database capability must be provided. This will relieve the load on the exchange’s computers and enable members to operate more efficiently. The system should include a research capability to enable members to research both their local database and the exchange’s central database.
<P:AS:20> The system should provide some type of online charting or analytic capability for trading day activity. The ability to extend this capability to historical data would also be useful. In addition, members should have an ability to configure their own reports.
Two configurations must be provided; multi-user and standalone. The multi-user configuration must enable an exchange member to operate multiple workstations. These would be connected together via LAN (Local Area Network). The LAN would connect to the exchange computer via WAN (Wide Area Network). Either configuration would maintain a database consisting of information generated by trading and settlement. The single-user configuration would be used to support small brokers and those brokers who wished to create their own systems.
Inquiries and Reports
As part of its End of Day (EOD) trade processing, the system must produce "Contract Notes" (Bought and Sold Notes) for each trade. Buy and Sell contracts (contracts between brokers) and numerous other reports are also produced at this time including a Daily Client Listing showing client holdings as of the end of the trading day.
A trade history for the current day, including time of sale, price and volume must be produced. A full set of reports must be provided. This include trade confirmations (Contract Notes); Market Daily; Weekly, Monthly, Biannual and Annual Activity Reports. It must include Daily Trade Listings for each broker.
A report generation tool with formatting and statistical capabilities such as averaging, multi-level sub-totaling, percent change comparisons, standard mathematical operations and financial calculations is required.
<P:AS:21> The application should possess an Executive Information System capability that provides concise business activity indicators for different levels of management. It should have a simple menu and/or command interface. A management user from his workstation should be able to access a series of pre-selected screens, graphs and queries derived from the central database system.
Surveillance
Basic Tools
The system must provide a full range of surveillance tools. It must enable surveillance staff to monitor member trading activity including the ability to set and reset intra-day trading limits by security or broker or across the exchange. Among the facilities being sought is:
Real-time price, volume and other Alerts.
Online, real-time reviews of the various order books. This must include an ability to review all activity including order entry, execution, modification and deletion. Date and time information for each activity and step must be included.
Online access to current and historical market activity. This must include an ability to replay (reconstruct) the market for any time period.
Monitoring of participant market positions and risk exposure.
Online and offline access to the system’s audit trail.
Monitoring of user logons, including invalid password attempts Stock Watch Alerts Each security must be continuously monitored for statistically unusual movements in its price or volume. Any suspicious activity must generate alert messages to surveillance personnel for review and possible investigation. Surveillance personnel must be able to monitor the market on a real-time basis. They must have real-time access (read only) to all orders and transactions in the system. They must have on-call access to all historical files. Surveillance officials must be able to set surveillance and market control parameters (e.g. price movement limits) on demand.
Audit Trail
The system must log all transactions (with date and time appended to each step) having any bearing on market operation. An audit trail of all orders, quotes and trades must be maintained. All audit trails for a specified period must be available online. At the end of each day, these files and the operating system logs must be written to non-erasable media.
Market Reconstruction
<P:AS:22> Surveillance personnel should be provided tools that enable them to reconstruct the market (by security, by sector or by market) as it existed at any point in time. They should be able to trace the flow of trading (including trader identification) over any period of time and at any level of detail. All of these tools should be available to Securities and Exchange personnel as well to ISX Surveillance. Member firms should have access to the audit trails of those trades in which they participated.
Clearing and settlement
All settlements of trades in depository eligible securities will occur through the depository. Settlement will be on a trade-for-trade basis. Initially, settlement will occur on T+5 (the long-term goal is to settle on T+3). T-Bill transactions will settle on T+1.
Persons holding physical shares must dematerialize their securities and lodge them with the depository (through their broker) prior to selling those shares. The depository will deliver the deposited shares to the relevant Registrar /Transfer Agent (RTA) on the next business day. The RTA will immediately verify or reject the deposit. Securities that are dematerialized will remain on the depository’s register.
Trade Entry /Capture
<P:AS:23> Trades executed by the automated trading system should be reported on a real-time basis to the clearing and settlement process. These trades are considered “locked-in” and will be assumed to be correct. However, the two trading parties will have until T+1 to make any corrections. The system must also provide a manual trade reporting facility Input of Settlement Instructions The new system will provide the means to input, capture, match, amend and cancel Settlement Instructions (SI). The following SI types must be supported:
Against payment for future delivery Free of payment for future delivery Pledging of securities Free of payment for immediate delivery.
Unmatched SIs must be reported to the submitter. The system must also support the modification and cancellation of unmatched SIs.
Trade Comparison/Affirmation Manually reported trades will go through a trade comparison process. Both single-sided and two-sided trade reporting must be supported. Single-sided entry will be used to support institutional trades. Two-sided entry will be used to report broker-to-broker off-market trades.
<P:AS:24> “Trades” (deliveries) between ISX members and non-member Institutional Investors (II) will be reported to the system by the executing member. The ISX member will submit the trade details to the system. It will store the trade details in its database and forward a trade report to the investor’s custodian (as identified by the submitting broker). The custodian will affirm (or decline) the details as entered. The custodian through the depository will settle affirmed trades.
For Positive Affirmations, the counterparty Participant to the trade identifies and affirms the trades. The Clearing system will then process these trades. The exchange may decide to cancel trades that have not been affirmed by the end of the trading day.
For Negative Affirmations, counterparty Participants identify the trades with which they are in disagreement. These trades are canceled from the database. Trades that remain at the end of the day (or after the cut-off time) are automatically affirmed.
A Trade Amendment capability must also be supported.
Settlement
Settlement performs the task of moving shares and money to ensure complete and final settlement of trades. On T+n the system will attempt to settle all trades that have been marked for settlement on that date. Book entry transfer will move shares between the Participant’s Settlement Accounts.
The system must be able to support Electronic Funds Transfer, Memorandum Accounts or Cash Netting.
The system must provide notification of failed settlements.
Delivery Versus Payment
Delivery versus Payment (DVP) is a G30 recommendation that must be met. It requires both Electronic Book Entry transfer of securities and a good funds payment mechanism. The cash payment mechanism to be used by ISX members has not yet been established. The system must therefore support funds payments by either memorandum accounts provided by the system and backed by a guarantee or by providing an EFT interface to the banking system.
Settlement Period
ISX will begin with T+5 rolling settlement and move to T+3 as soon as practical. The settlement period must be a settable parameter.
Trade for Trade Settlement Securities settlement will be on a trade for trade basis and payments will be on a multi-lateral net basis. Security settlement will be accomplished by debiting and crediting participants’ (and client) book based holdings of securities in the depository. If insufficient holdings are present in the seller’s depository account, the individual transaction will “fail” and special procedures will be invoked to deal with this infraction of the rules.
“Good Delivery” Rule
ISX’s “Good Delivery” rule will state that any trade (in depository eligible securities) executed between members of the ISX must be completed in book entry form using the ISX’s clearing and settlement service (i.e. the depository).
Payment
The net amount (the net of an entire day’s settlements) of money owed to or from each participant will be calculated for each day’s settlements. Each participant will either pay or receive this net amount to or from the ISX.
Reports
At a minimum, the following reports are required:
Settlement Statement listing all trades to be settled on a given day.
Interim Settlement Statement including all Next Day Settlement deliveries from the previous settlement day and all Same Day Settlement deliveries.
Final Settlement Statement.
Net Cash Settlement
Buy-ins Report
Monthly Turnover by security.
Market Capitalization
Index Membership Report - Monthly report on trade volumes and market capitalization for deciding on membership of different Index etc.
Block Trade Report - There is a daily report to list all trades worth more than a specified amount (parameter driven).
Central Securities Depository (CSD) Introduction The Depository subsystem will perform all of the functions necessary for the settlement of ISX trades. It is an account based electronic book-entry system for transfer of share ownership. The basic operations to be performed by the depository are:
Accept deposits of securities – physical certificates (Free transfer).
Record deposit of new issues directly from the issuer to the depository Ensure the safe custody of deposited securities.
Maintain a ledger of the depository’s holdings. The ledger must identify the participant and the beneficial owner of each holding.
Maintain individual safekeeping accounts for Beneficial Owners. Instructions to trade or transfer these holdings must be carried out through an authorized Depository Participant with whom the owner has established a formal relationship by transferring his holdings to the sub-account in his name within that institution.
Process book entry transfers of ownership of securities in exchange for payment to settle a trading transaction (Value transfer).
Enable book entry movement of securities without associated cash movement (Free transfer).
Movement of cash only from one depository participant to another (cash only movement) Process withdrawal requests.
Produce and deliver Confirmations of Trades to indirect participants (i.e. custodians for institutional investors).
Accept affirmations of trades from custodians.
Process deposits of new issues directly from the issuer.
Process Pledge and Release of securities that have been hypothecated.
Provide stock borrowing and lending via the free transfer or money transfer mechanisms.
Dematerialization of Depository Holdings The ISX’s holdings will be be dematerialized and appear as uncertificated accounts in the Company Register. Investors whose holdings are not in the depository may continue to hold certificates. The new system must therefore be able to function in a partially dematerialized environment.
Instruments
Initially the depository will concentrate on listed stocks and bonds, Treasury Bills and other government debt. Eventually all securities traded in Iraq must be cleared and settled through the CSD.
The system must support the ISO 6166 Securities Numbering (ISIN) standard. It must also support short name symbols.
Participants
Licensed Broker Members will be direct participants in the depository. Custodians for Institutional Investors will be indirect participants in the depository. Both will be known as Depository Participants (DPs). Both will be given access to the depository through Participant workstations. Through these workstations, DPs will receive confirmations of trades made on behalf of their clients.
<P:AS:25> It would be desirable if the system were also able to receive affirmations (agreement that trade details as reported are correct) from its Indirect Participants (Custodians). With an online affirmation capability, custodians would be able to affirm or decline trades via the same workstation. Once affirmed, the custodians would settle their trades directly with the depository. This methodology would enable brokers to transfer responsibility for settlement directly to their clients on settlement day. Thus all parties benefit, the custodians settle on a Delivery versus Payment (DVP) basis and the brokers avoid the necessity of financing the delivery of shares purchased for their institutional clients.
Transaction Entry /Capture <P:AS:26> Integrated CSD: The proposed system shall be run on (or be directly connected to) the trading system computer. At a minimum, peer-to-peer linkage is visualized. Under this approach, the trading system would report trade details to the CSD system on a real-time basis. Each member firm will need linkage to both the CSD and the trading system.
Account Types
The account structure will provide for both Depository Participants as well as Individual Investors. All Accounts can be used to maintain both securities and a cash position of the Account Holder.
The depository module must provide a facility to lockout (and release) a set of shares in a depository Ledger Account to cater for cases where shares have been offered as collateral/security to a lending institution. As an Account could have shares locked out in respect of more than one lending body, a mechanism to maintain this breakup is provided.
Accounting
Accounting. The system must provide double-sided book entry facilities for securities and cash. It must provide an on-line interface with the payment bank.
Depository Participant Accounts The system must provide Depository Participants with a set of accounts to record holdings of securities and separate accounts for holding balances of funds movements. The DP will use the accounts held for it by the depository to represent its aggregate holdings of securities with the depository including those held in its own name not beneficially owned by its clients. The system must enable the DP to structure its accounts to suit its business needs. Potential account types include: Free account, sub-accounts, Segregated awaiting approval account, Deposit pending account, Withdrawal pending account and Pledged account.
Individual Investor Sub-Accounts Individual investors will have their holdings of securities recorded in sub-accounts that will be linked to a Depository Participant. The sub-accounts for its clients must be well segregated from the accounts of its own holdings.
Settlement Instructions
The system must support the use of “Standing Instructions” and individual trade based settlement instructions.
Attach Billing: Depending on the trade and participant, billing information may be generated and appended to the settlement records.
<P:AS:27> Attach Commissions: Depending on the trade and participant, commission data may be attached to the trade and appended to the settlement records.
Lost and Stolen securities <P:AS:28> The system should maintain records of Lost and Stolen Share Certificates and verify all new (share) deposits against this data set before acceptance.
Securities Lending /Borrowing A securities lending and borrowing system must be available within the system although that process is not an immediate requirement. Lending will be performed on a fully collateralized basis.
Corporate Actions
Initially, all corporate actions will be processed through the Registrar for the respective security. However, the system must have the ability to process standard corporate actions.
Deposits
The system must provide a Deposit facility to transfer shares from a scrip based client holding into a Participant’s (broker) Settlement Account.
The client will deliver certificates and a signed transfer form to their broker who electronically inputs data from those documents into the system. Details of the transfer and the client’s certificates are transmitted to the Share Registry. The transfer may be executed immediately, moving the securities from the client’s name into the broker’s Settlement Account, or the procedures may require the documents to be delivered to the Transfer Agent for verification prior to transfer.
Account Reconciliation
The system must provide the means to carry out daily reconciliation of its records. It must reconcile its records with those maintained by all depository participants including licensed broker members, custodians and Registrars.
Risk Management
Monitoring of Risks
While a key reason for establishing a depository is to reduce risk, the activity of a depository inevitably involves exposure to liabilities. These may result from, among other causes, failure to detect invalid securities that have been deposited, failure of a participant to make good payment or through errors of both a human and computer nature.
<P:AS:29> The CSD will employ a number of risk management techniques to apportion these liabilities to the participants. The system should provide automated support for these techniques. These would include, for example, credit rings, credit limits, net debit caps, letters of credit, mark to market payments are common methods of transferring liability to participants. A credit ring is used to collect a proportional amount of funds from each participant to cover a shortfall in funds that is caused, for example, by the payment default of another participant.
Failure to Deliver
If the delivery failure cannot be handled through securities lending a Buy-ins procedure will be invoked. The ISX will follow pre-established rules to determine when a Buy-in must be executed in order to ensure ultimate delivery to the buyer.
Settlement Guarantee Fund
A Settlement Guarantee Fund (SGF) will be established to complete settlements that failed due to failed delivery of securities or payments. The system must have the means for accounting for contributions and assessments to the fund. Each participant, through assessments on each transaction and the use of guarantees could fund the SGF through contributions of money or liquid securities.
Risk Containment
The system must provide the ISX and the depository tools that can be used to monitor and control risk. It must include calculation of minimum collateral. Preference will be given to systems which actively monitor Participation Standards (e.g. minimum capital levels, liquidity requirements and operational capabilities), Collateral, Liquidity facilities and Net Debit Caps <P:AS:27>.
The system must include the necessary operational safeguards (controls) to enable the CSD to avoid or minimize the risk of disruption or destruction of the settlement process. This must include facilities to prevent and discover fraud, error or theft.
COMPUTER HARDWARE (HW) REQUIREMENTS
Technology Platform
Hardware and Software Generation It is critical that this new trading platform be based on the current generation of hardware and software. Respondents must provide a detailed description of the hardware components being proposed to ISX. This must include a full schedule of the model, configuration and quantity of items to be provided. All equipment required to support the proposed system must be identified. Technical data sheets relating to each component must be supplied. This must include processor, memory, disk storage, printers, peripherals, workstations and communications.
Bidders for this system must identify those vendors in Iraq who can support the proposed configuration. The vendor must describe their ability to diagnose problems at the hardware, software and applications level online. The exchange must have rights of access to the applications source code.
The system must be able to handle the transaction levels shown in Section IX. Supplier References and Product Performance without a hardware or software upgrade. Additional capacity must be obtainable on a modular basis by adding hardware and reconfiguring the software without requiring the rewriting of any software.
<P:HW:1> The system must be scaleable. Respondents should describe how the system would be upgraded to accommodate increases in transaction volumes. They should define the maximum memory, maximum processor speeds and numbers of processors, maximum disk storage, etc. that is supported by the system. The Pricing Proposal should detail the costs of such upgrades.
The system must be able to support 100 simultaneous workstations. A response time of 2 seconds or less is required.
<P:HW:2> Respondents should provide industry standard benchmark information such as TPC-A, B and C for the proposed configuration. They should provide the results from any independently audited industry benchmark tests that were performed on similar configurations.
Hardware Reliability
All of the systems provided by the vendor must be capable of running the specified application, system, or developmental software and transferring data on all ports at the same time without performance degradation. The degree of hardware reliability must guarantee 99% up time at both the central site and user sites.
Data on hardware and application MTBF (Mean Time Between Failures) and MTTR (Mean Time To Repair) must be provided.
Expansion and upgrade options must be described for all proposed configurations.
Back-up Capabilities
It is the intent of the ISX that, to the degree practical, that trading continue without interruption. Warm application restart must be a demonstrated capability. A remote back-up system must be provided to ensure disaster recovery.
Back-up communications facilities must be included in the design but priced separately as they may not be included in the initial installation.
The system must enable the exchange to service brokers who have lost access to the system through fire or other calamity. This will be accomplished by the exchange maintaining broker back-up facilities.
Data back-up facilities must be provided. Respondents must define the capacity of the proposed data back-up facilities. They must detail how long it takes to back-up the proposed system using this device.
Power Conditioning
All processors, disks and communications equipment require computer grade Automatic Voltage Regulators providing:
220 volt, 50 Hertz power supply Automatic shutdown circuits in case of unit failure Maximum 1 nanosecond response time Respondents must define the power requirements for all equipment to be supplied. This must include voltage and voltage tolerance requirements; total power consumption, electrical grounding requirements, conductor sizes and any other special requirements. The number of power outlets required at the central site and at participant offices must also be provided.
COMMUNICATIONS (CM) REQUIREMENT
A communication network connecting all users and participants to the trading and settlement systems is required. The Local Area Network (LAN) and Wide Area Network (WAN) must be capable of supporting the transaction volumes generated by the application software. This would be based on the trading and settlement volumes noted in Section IX. Supplier References and Product Performance.
Respondents must describe the communications services that are being proposed. They must state how their proposed network software will provide the organizational and end-user services required. They must state the protocols used. Licensed Broker members and Custodians must be linked to the system over a wide-area network.
The system must be designed to continue to operate even if communications links become unavailable.
The proposed communications equipment must have been approved for network connection by the relevant authorities in Iraq.
<P:CM:1> The network proposed should permit any end-user in any office to access the trading and settlement systems as well as permit the transmission of electronic mail to any registered user on the network.
<P:CM:2> The equipment must be capable of being switched over to a back-up data communications link using dial-up telephone lines. Respondents must define the maximum data throughput between all major sub-systems and components. Both the local area (LAN) and wide area (WAN) throughput should be defined.
<P:CM:4> A Network Management System should be provided. It should cover the entire network and provide line loading, performance, and error and throughput measurement with continuous aggregate figures on data throughput between all nodes so that potential difficulties can be predicted and preventive maintenance performed.
Network Standards
The proposed network must observe international standards. These must be defined in the respondent’s proposal.
Network Expandability /Management <P:CM:3> The network should be capable of expanding to accommodate future growth. It should enable the addition of extra communications links, the addition of extra processing power for network nodes and the addition of new network nodes and relocation or expansion of existing nodes. It should be capable of accommodating additional participants and greater transaction volumes without requiring software changes.
Network Security
Data transmissions on the internal and external networks must support authentication of network terminals and workstations and prevention of unauthorized monitoring of network transmissions <P:CM:5> Data transmissions on the internal and external networks should support encryption /decryption techniques (either hardware or software based).
<P:CM:6> The file transfer system should provide error free transfer between systems, with logging of file transfer requests, actions and failures. An international file transfer protocol should be used.
SYSTEM SOFTWARE AND TOOLS (SS) REQUIREMENTS
Operating System and Utility Requirements All systems are required to be multi-processing, virtual memory operating systems supporting the proposed Relational Database Management, file transfer, compiler and other software packages.
A Graphic User Interface is required.
Standards
<P:SS:1> The operating system software for each server processor should conform to Open systems standards and permit communications with other processors on the network. It is important that the operating system software observe existing international standards such as POSIX, X/Open, etc. In their proposal, respondents should clearly indicate the standards observed.
Security Provisions
The system must provide file security and network security facilities. It must provide a robust login password protection system with break-in protection and password encryption. It must have facilities for virus detection and removal.
The system must have mechanisms for ensuring the integrity of file structures following system crashes and abnormal process termination, including back-up and remote configuration Language The screen displays and system reports are to be provided in Arabic and English.
Training
It is important that any potential vendor transfer the knowledge necessary to operate the system and maintain the application software to exchange personnel so that the exchange can achieve operational self-sufficiency after the vendor’s warranty period expires. The vendor must identify the nearest office from which support can be provided.
Application Software
An existing proven real-time automated trading, clearing, settlement and depository system is required. Respondents must identify where the system is installed so that exchange personnel can visit existing installation sites as part of the procurement process. Some requirements are:
A company license for the software.
A complete copy of the source code is a plus.
ISX prefers ‘Open’ System architecture.
Geographically distributed broker trading workstations Very fast response time It would be desirable to have the means to change trading rules and parameters without requiring software changes. The system must be parameter driven to the extent reasonable.
The application software must execute in an integrated fashion across all hardware platforms /levels and communicate with each other and the peripheral devices via the system network.
The automated trading and electronic settlement software will perform processes at three levels: 1) central database, 2) local user databases, and end-user data entry /display workstations. The central database will be the repository for aggregated information. Copies of pertinent information will be kept at user workstations /servers.
The application must be capable of processing specific transactions (e.g. enter orders, execute trades, etc.) from any authorized device within a 3 second period. All beneficial Owner information must be accessible through a unique client account number.
The application must be capable of processing transactions and queries from the trading floor and from multiple remote workstations.
The application software must be table driven to enable modifications to logic rules.
Hardware
Central Server
The Central Server must be able to accommodate the volume levels noted earlier in this document. It must be fault tolerant to the extent that no single component’s failure will render the exchange unable to function. All data must be mirrored. The system must be able to recover from a hardware failure and restart operations within one hour.
The hardware platforms and peripheral devices (e.g. printers, etc.) must be connected through an industry standard network. The network may consist of individual LANs connected through a WAN.
Member Equipment
Workstations: In its initial configuration, the system shall provide one local and one remote workstation for each of its brokers. The local workstations will be located on the trading floor and the remote devices will be located in the individual broker's central office (located in metropolitan Baghdad). These devices shall provide the full range of functionality allowed member firms. Access shall be controlled by password. It must be possible to restrict specific functions to either the floor or remote workstation.
The system must enable entry of orders from the floor and/or from member offices. Each broker workstation shall be uniquely identified. The system shall maintain control over which workstation and which user ID is permitted those functions.
The system shall be capable of supporting 60 brokers without change, except for the adding of 2 workstations (one local and one remote) per broker. It must also be easily upgraded to meet the targets specified System Software A relational database is required.
Telecommunications
The platform for the new system must support both dedicated and dial-up lines. The system must offer some type of security for communication over and above passwords (i.e. authentication, encryption or other data security methods).
<P:SS:3> Network connections should include TCP/IP router, FTP and STMP mail connectivity, etc. Vendors should describe the full set of connectivity options included with the proposed system.
Security
An access Security and Control facility is needed to manage system security and restrict access to authorized users. It must also control what tasks each user may perform.
SOFTWARE DEVELOPMENT (SD) REQUIREMENTS
A homogenous application software development environment must be provided to ensure portability of application software. The software development environment must employ SQL, 4GL and other recognized development tools. The tools provided with the system must be the same as those used to develop the system and clearly defined.
Relational Database Management System One full version of the relational DBMS is required for development. It must possess the following features:
100% portability and functionality across all server platforms;
Interactive “C++” (or whatever language was used to develop the application) pre-compiler for development;
On-line archiving and retrieval;
Control and locking mechanisms that enable concurrent access and manipulation of data;
C2 level security;
Multiple indices for stored entities;
Trace facilities for problem diagnosis;
ANSI Structured Query Language (SQL) facility;
ODBC /OLE support;
Incremental back-up;
Support for remote database access over common network protocols (e.g. TCP/IP);
Automatic maintenance of Audit trails;
Support for Client-Server architecture;
Support for integrity checking of indices and regenerating indices;
Facilities for data import and export to /from at least two major DBMSs’, spreadsheets and word processors;
Capable of handling 3 GB logical tables and 50 GB databases;
Capable of handling 100 simultaneous end-users;
Support for Graphical User Interface (GUI) front-ends and Forms /Queries /Reports;
Multi-threaded database engine; and Advanced Mathematical and Statistical functions.
Programming Tools
The application must be designed to permit the establishment of three separate environments simultaneously: 1) training, 2) development and test, and 3) production. Only authorized staff should be permitted to make changes to the application and database files. Facilities must be provided to facilitate the transfer of new or replacement programs to user workstations or remote servers over the network in a centralized manner.
The documentation should include program and source manuals, detailed users guides, acceptance specifications, etc. Comprehensive context-sensitive on-line “Help” facilities would be a plus. Respondents should clearly describe the full range of documentation that will be provided.
TURNKEY MANAGEMENT (TM) REQUIREMENTS
Contractor and Subcontractor experience The ISX seeks a single point-of-contact (i.e. a Prime Contractor) to oversee implementation of this project. Implementation and on-going technical support must be provided by the developer or owner of the automated trading and settlement system being proposed. Local hardware, software and communications support must be provided. The qualifications of the prime contractor and all subcontractors must supplied and will be used by the ISX to assess the bidder’s ability to successfully implement this project.
<P:TM-1> The system will ultimately be operated, supported and managed to the greatest degree possible by Iraq Stock Exchange personnel. Because of the complexity of this integrated system, the Supplier’s project team should include local specialists with relevant experience for future project sustainability, technology transfer, language and minimization of costs.
Experience and qualifications of Project Director <P:TM-2> A Project Director must be identified. The Project Director is required to have a responsible and authoritative role. A clear definition of the Project Director’s role must be provided. It must cover the following activities: 1) authority for technical decisions including modifications and change orders; 2) interface between the ISX and the supplier organizations; 3) financial administration and authorization; 4) quality assurance; and, 5) contract management authority over other sub-contractors. The Project Director must have ten years experience in successfully integrating hardware and software products. The relationship between the Project Director and the supplier organization must be explained.
Staffing
<P:TM-3> The Project Team must include team members who are responsible for each of the modules and functions described above. The number of staff, their resumes, and time devoted to the project over the course of the contract period should be provided. A detailed phase-over (continual on-job training and replacement of technical /operational personnel by ISX staff) must be specified. ISX staff must be trained as members of the Project Team and used for both development and operations support.
Systems Acceptance and Project Schedule Suppliers must complete installation and acceptance of the system within three (3) months of contract signing. Preference may be given to vendors who offer earlier implementation.
Project Plan
<P:TM-4> A high-level project plan must be submitted with the bid. This plan will be assessed for completeness against the tasks to be performed and the capabilities of the proposed project teams. The following processes should be included: 1) task time estimates, 2) project planning, 3) resource allocation, 4) system specification and sign-off, 5) progress tracking and monitoring, and 6) reporting to ISX.
The Project Plan must clearly identify which parties are responsible for which detailed tasks, the resources required, the external dependencies, and the “critical Path” milestone events. The Project Plan must include installation, training and acceptance testing in a comprehensive manner.
Acceptance Testing
The supplier is responsible for testing all products installed and for ensuring successful operation. Upon completion of this task, the Supplier’s Representative shall notify the ISX Project Manager in writing about each completed installation. ISX will perform performance tests on the installed systems to verify their conformance with Contract requirements and an Acceptance Test Plan drafted by the supplier and refined jointly with the ISX. The Acceptance Test must verify the functionality and performance of each functional module and of the overall system. The entire network must be tested.
After completion of the Acceptance Tests, the ISX Project Manager shall inform the Supplier’s Representative of the results and list the deficiencies (if any) to be corrected. The Supplier shall make all reasonable and necessary efforts to promptly correct the listed defects, following which the tests will be repeated as necessary, in accordance with the Acceptance Test Plan.
Change Notice Procedure
<P:TM-5> Explanations of the following should be provided: 1) Version control, delivery control, status management and item tracking for all products associated with the project; 2) Contract Change Management; 3) Specification Change Management; 4) Problem Reporting and Corrective Action; 5) Document Update and Distribution Control; and 6) Project Library Management.
TRAINING AND DOCUMENTATION (TG) REQUIREMENTS
During the contract period, formal training must be provided for all categories of users and support staff. A reasonably detailed Training Plan must be included in the proposal. The plan must indicate user staffing and training periods by category, location and type of training. Due to security considerations, training may be conducted in Amman, Jordan or at the vendor’s home office.
<P:TG-1> ISX and Depository staff will need specially tailored classroom and “hands-on” instruction on hardware and software operation and support. This training excludes technical training conveyed on an informal basis while installing or demonstrating the system. A training facility staffed by ISX personnel will be established to maintain on-going training for newly recruited staff and user personnel.
Training Class Descriptions Training is required in two main areas: 1) Technical Support Staff, and 2) System Users. Training for the Technical Support Staff must include the following (as it applies to the delivered system):
System Development Methodology;
Database design;
Operating System(s);
Programming Languages used;
Hardware Operations;
Network Operations;
System Tuning; and
System Audit Techniques;
<P:TG-2> There are three distinct types of system users who should be accommodated. They are customer support personnel, middle managers and senior management. Training should be provided for all categories of users including Licensed Broker Members, Depository Clearing Members, Custodians, Registrars, etc.
<P:TG-3> All training programs, materials, equipment and facilities are to be oriented to the needs of the ISX users’ and staff skill levels. On-line tutorials would be a plus.
Application Training Database To support “hands-on” training, training databases and training systems are required. These must be separate from the production system and databases and must reflect live operations. The training process must not adversely impact operation of the live system.
SUPPLIER REFERENCES AND PRODUCT PERFORMANCE (SP)
<P:SP-1> Respondents should provide ISX with references from projects of a similar nature and scope. These will be checked by the ISX to ensure that the vendor has the necessary capability to complete an international project of this type.
Capacity Plans and Projections It is difficult to estimate the activity levels that the system will encounter in its first year or two of operation. The following numbers therefore represent the minimum transaction levels that the system must be capable of handling at start of operations:
Listed main board companies 200 Second-tier market companies 50 Corporate debt issues 100 Government debt issues (national and local) 50 Stock brokerage firms 60 Government debt broker/dealers 20 Shareholders (Depository clients) 700,000 Daily trades on the main board 2,000 Daily trades on the second-tier market 500 Daily Settlement transactions 5,000 Daily trades on the corporate debt market 100 Daily trades on the government debt market 100 Response time is defined as the time elapsed between when a workstation operator enters a transaction to the time when a response from the central system appears on that workstation. ISX requires a response time of less than 3.5 seconds for 95% of all transactions during normal trading hours and less than 5 seconds for all transactions during the 30 minute opening and the 30 minute pre-closing peak periods.
<P:SP-2> The Performance claims of the proposed system and/or individual components will be evaluated on the basis of the following:
Benchmarking or demonstrations of similar systems and/or components in existing production environments outside supplier offices, and reviews published in technical journals;
Interviews with existing users of similar, fully operational systems; and Evaluation by ISX user groups of functionality and user friendliness.
<P:SP-3> ISX intends to send an evaluation to the short-listed vendors’ reference sites.
MAINTENANCE AND SUPPORT (MS) REQUIREMENTS
All equipment, software, and facilities supplied through the contract must be installed and maintained by the supplier for 3 years from contract date.
Maintenance Plan
<P:MS-1> The maintenance plan must include identification of procedures for on-site and off-site maintenance during normal hours of operation. It must describe the vendor’s on-site and remote fault diagnostic techniques and their fault escalation procedures. It must also describe the Maintenance Log and its usage.
Respondents must define the mean time to repair (MTTR) of the proposed system’s major system components. They must provide their preventative hardware maintenance and software update schedule. They must provide a list of the spare parts that will be held on site.
Supplier Maintenance Support Facilities Potential suppliers must provide a guaranteed response time of 2 hours with a MTTR of 8 hours for hardware engineering support.
Suppliers must provide a guaranteed response within 24 hours of being informed officially of an error in the application software within the contractual period, and to effectively repair the fault within two weeks of notification.
<P:MS-2> Respondents should describe how an effective “Hot Line Telephone and Support Desk” will be established.
BID EVALUATION METHODOLOGY
Fulfillment of each of the mandatory criteria is necessary for a proposal to be considered responsive. All responses to this RFP will be evaluated on a best value basis. The Contracting Officer will award a contract resulting from this solicitation to the responsible offeror whose offer conforming to the solicitation will be most advantageous to the contracting activity, price and other factors considered. The following factors shall be used to evaluate offers.
First Level:
Local support
Ease of modification
Trading functionality
Ease of use
Broker support (i.e. analytics, graphing, local database, etc.) Straight-through processing Scalability Efficient registration of ownership Second level:
Delivery schedule
One time cost
Ongoing costs (i.e. maintenance options) Software fault tolerant Network coverage and cost Prime vendor and subcontractor past performance Third level:
Training
Adherence to international Clearing and Settlement Standards Equipment quality Documentation Efficient market data dissemination Surveillance analytics Trade and settle other instruments in addition to equities and debt
The Criteria for evaluating responses to the attached RFP includes the following:
Ease of use
Ease of modification
Delivery schedule
Equipment quality
The First Level evaluation criteria is most important and are equally weighted. The Second Level Criteria are less important than those of the First Level and are equally weighted . The Third level criterial are less important than those of the First Level and are equally weighted.
Past Performance: Offeror must include information including relevant contracts, for the same or similar work and other references, points of contact with telephone numbers and other relevant information.
MANDATORY BID FORMAT
Suppliers must structure their bids in a standard form. It is important that respondents clearly explain how their proposed system satisfies the Preferred Technical Criteria. These explanations must form the basic outline of the respondent’s proposal. Respondents offering both trading and settlement /depository systems must price those systems separately as the ISX reserves the right to implement those systems independently of one another. Respondents must identify areas where their proposal exceeds the Preferred Technical Criteria. This will enable the Evaluation Committee to accurately assess that proposal. Responses must include the following technical sections:
Executive Summary
This section must contain a summary of the proposed system and technical overview. It should define the qualifications of the vendor and the vendor’s subcontractor or staff in Iraq.
Mandatory Technical Criteria Respondents must list the Mandatory Technical Criteria and confirm that their proposed system meets those criteria. They must explain any items that appear to vary from a strict literal interpretation of the criteria.
Application Software (AS)
Respondents must provide an overview of the architecture of the system. This must include a functional description (capabilities, reports, analysis, archiving) of each software package included with the system. It must define the extent and complexity of any customization that is needed in order to meet ISX’s functional requirements.
The proposal must describe how the various users would interact with the system. It must contain sufficient detail as to enable reviewers to determine the ease of use and friendliness of the system.
The proposal must describe the data update and file database /maintenance process. It must define the maximum number of concurrent activities that can be processed as well as the number of records /files that can be accommodated by the proposed configuration.
Respondents must describe their system from the perspective of the sequence of events and procedures that occur during the day. This must include all aspects including pre-trading, trading, clearing and settlement, depository and registry operations. It must include a sample daily operations timetable. The timetable must include the activities of all participants (e.g. brokers, clearing members, custodians, payment banks, registrars, etc.). It must outline the ISX’s staffing requirements. It must define the operational tasks required of the ISX to operate the proposed system The full set of reports normally associated with automated trading and settlement must be provided. Respondents must provide a list of those reports and related inquiry facilities that are provided by the system.
Respondents should provide full details of all software items that will be supplied as part of this application. They should also indicate whether the software operates on the central system or the user workstation.
Respondents must describe their software license policy. Respondents must provide an unlimited user license for the workstation software. They should state whether the source code for the entire application is provided within the sale price. Full source code is preferred. If this is not available an escrow arrangement must be provided. Respondents must also confirm that they have the right to supply the software without restriction.
Computer Hardware (HW)
This section must describe precisely the complete hardware configuration of the proposed system. All computer equipment must be defined including workstations, communications equipment, power conditioning equipment, spare processors, etc. The performance capabilities of the system and its level of scalability should be clearly defined. This section should define how the system would be expanded and the system’s overall growth potential. The Mean Time Between Failures (MTBF) and Mean Time To Repair (MTTR) of all primary equipment should be provided. Respondents should certify that the proposed configuration has the capacity to handle the projected volumes.
The proposal should provide industry standard benchmarks for all key hardware items. The benchmarks should include (to the extent practical) TPC-A, TPC-B, TPC-C, AIM benchmark suite, Dhrystone MIPS, SPEC 92 or 95 (et al), MFLOPS, etc.
The proposal must define the Site /environment specifications of the proposed hardware. The primary computer facilities will be installed on ISX premises. Respondents must define the site preparation requirements that are ISX’s responsibility. The required square footage, electrical power and cooling requirements of the proposed computer and communications facilities must be defined. This should include the number of power outlets required at the production site as well as those required at a typical participant’s office. The system’s dust and humidity control and environmental requirements must be detailed. This includes the equipment’s operating temperature (in Celsius) range and humidity limits. The heat output of each piece of equipment should be defined.
ISX will perform basic site preparation (i.e. construct walls and raised floors if required and provide power outlets and air conditioning). The successful vendor will be responsible for installation and setup of the computer and communications hardware including cabling, UPS /stabilizers, etc. Respondents should define and confirm that all tasks and activities necessary to install the hardware and services have been specified and that all such activities and installation procedures are included in the Cost Proposal.
Respondents must include in their Project Plan a full description of the sequence and duration of all hardware installation and commissioning tasks. They should provide a suggested layout for the production computer and communications equipment.
Vendors must specify the tasks that ISX must perform in order to install the proposed system. The nature and sequence of the work should be explicitly detailed.
Communications Equipment /Software (CM) The selected vendor will be responsible for establishing the Wide Area Network (WAN) that will support the system.
All trade and post-trade activity will be performed using intelligent workstations (with a GUI interface) located on broker premises. Inquiry functions and post-trade functions will be accessible from the broker offices.
Respondents must outline the architecture of the proposed communications network. They must provide sizing estimates to demonstrate that the proposed network is sufficient to handle the anticipated data traffic. They should define the capabilities, security, network management, encoding schemes and related details of the proposed network. They should define the communications protocols that will be used.
System Software and Tools (SS) All system software used in the construction and operation of the system and all of its constituent parts must be described.
Respondents must define the full schedule of the version, configuration and quantity of the items to be provided under their proposal. They should define the international standards observed by the system software (e.g. POSIX, X/OPEN, etc.), the current level and status of the operating system and define the system recovery facilities provided.
The development tools and database system provided with the application must be defined.
Respondents should define how the interception or tapping of data is prevented. They should describe how end to end security is provided. They should their data authentication and virus detection procedures. If encryption techniques are used, these should be described.
Data must be received from identified and authorized sources. This should include efficient password control and administration procedures as well as secure terminal control procedures. Respondents should define the back-up procedures provided by the proposed system. They should describe how the production and development /test environments are segregated. They should define the procedures used to minimize the risk of accidental or purposeful destruction of data and services. They should define how the system prevents delivery of data and service to unauthorized persons The system should provide Logs of all violations, of changes of operator and other procedures. The logs should be tamper-proof with read-only access. They should provide full audit reports. These should include records of operator actions, user group maintenance procedures, The logs should include traffic and error statistics, Respondents should describe how these features are provided by the proposed system.
A C2 level of security is required. The proposal should define both operator access and user access procedures. It should describe the security features provided by the system, including the central system, the network and the user facilities. It should describe how Internet security would be provided.
Software Development (SD)
This section must define how the proposed software development process satisfies the Preferred Technical Criteria. In addition, it must include the following detail:
Respondents should describe their application software development methodology, their development plan and schedule. They should identify the customization activities that are needed to fully meet the requirements stated in this RFP. A project schedule (see next section) for those enhancements should be provided. It should state the numbers and types of locally based staff that will be participating in the software enhancement work.
Respondents should describe how it will develop the user and business requirements and how it will ensure that the requirements are fully implemented in the production system.
A high level overview of the proposed system must be provided. It must illustrate the hardware and software features of the proposed system. It must include a description of the overall system architecture. It must describe the configuration of the host system, the workstations and the communications network. It must define the normal and fall-back processing configuration.
The proposed system must be scalable to provide the needed processing capability, modular so that incremental components can be added without major software changes and expandable to accommodate additional participants and volume. The system must be resilient so that a fault within the system would not cause a failure of the entire system. The system must be able to recover from a failure automatically without loss of data. Respondents must describe how their software development methodology helps satisfy these requirements.
Turnkey Management /Systems Integration (TM) This section must define how the proposed turnkey management and systems integration process satisfies the Preferred Technical Criteria. In addition, it must include the following detail:
details of services,
transfer of responsibilities A Project Plan must be provided. It should identify and describe all key activities and the person or party responsible for that activity. For each activity it should show duration, location and start /end dates and precedent activities and resource requirements. The plan should detail mutual obligations and milestone events. A Project Gantt Chart showing the complete project time schedule must be provided.
A complete implementation schedule is required. This must include the projected training programs, system installation and acceptance test requirements.
Respondents must provide details of the staffing levels proposed for this project. They must also identify the number of employees that will be available to provide local support for maintenance and enhancement. This must include the numbers and types of personnel available for maintenance and support for hardware, communications, system software and application software.
Training and Documentation (TG) This section must define how the proposed training and documentation satisfies the Preferred Technical Criteria. In addition, it should include the following detail:
number of staff and brokers and custodians Training for ISX staff, brokers, and other participants must cover trading operations as well as clearing, settlement and depository operations. This would include the staffs from up to 25 brokerage firms, 5 custody banks, 2 payment banks and the staffs of the ISX and Depository.
This training must cover all categories of participants including brokers, custodians, payment banks, registrars /transfer agents and ISX officials. Ultimately, the ISX must be in a position to conduct its own training of users. Therefore a “Train the Trainers” approach should be supported for this category of training.
Training must also be provided for support personnel. This must include the following categories of training:
Systems operations and hardware and software tuning, Operating system and software utilities including development tools, and Design and modification of the application software.
Respondents must describe each course that will be provided. This description should define each course’s content, duration, type and numbers and qualifications of participants. The location of each course (internal and external) must also be defined.
Respondents must provide a full list and description of the documentation that will be provided with the system. This should include User and technical documentation with upgrading methodology. It should include an Architectural Overview and design documentation sufficient to enable trained ISX personnel to support the system. It should include an Error Messages guide. It should include a context-sensitive on-line “Help” facility.
Application documentation must be provided in hard copy and recorded on magnetic or optical media. Detailed “User Guides” for Participants and Systems support personnel must be provided.
The Cost Proposal must state what training is included within the budgeted figures and the costs of any additional training. If there is a cost associated with the documentation, that cost must be detailed in the Cost Proposal.
Supplier References and Product Performance (SP) This section must define how the proposed supplier references and product performance satisfies the Preferred Technical Criteria. In addition, it should include the following detail:
Respondents must provide details of the contractual and business associations they propose for this project. Details should be provided for each entity involved. If the primary respondent is a subsidiary of a larger organization, that relationship should be detailed. Respondents should provide an outline of their organizational structure. They must state the geographical location of development, quality control, customer support, back-up stores, etc.
Respondents must state the identity and location of the office(s) from which they intend to perform the various tasks associated with the project. This should include the following: business requirements analysis; system design, development and customization; coding; testing; integration and implementation.
This section must contain a brief description of similar systems used in the respondent’s reference sites. It must include the customer name, address, telephone and fax numbers for the main operational reference sites. The configuration details for the reference site’s system should be provided.
Respondents should provide the last three years full audited financial results for each contractor, sub-contractor and partner that has been proposed.
Respondents must supply details of the performance of their proposed system. They must estimate the number of trades, orders and inquiries the system can handle per peak hour and per peak minute. Respondents must state the performance achieved by using the system in a operating exchange. They must also state the maximum performance levels that have been achieved during volume and stress tests. Details of the tests must be provided.
It is essential that the proposed system provide a very high level of availability. At a minimum, the system must provide 99% availability during normal operating hours. Respondents must describe in detail how the proposed system would meet these requirements.
They must also provide MTBF (mean time between failures) information for the hardware and telecommunications components of the proposed system.
Maintenance and Support (MS) This section must define how the proposed maintenance and support satisfies the Preferred Technical Criteria. In addition, it should include the following detail:
Respondents must describe their hardware spares supply and stocking scheme, how their maintenance and technical support team functions. They must describe their software maintenance and upgrade scheme.
Respondents must describe they intend will provide support to the ISX for the application and system software. They must describe their telephone “Hot Line” assistance procedures. This must include information as to what support is provided locally and what support will be provided remotely as well as the location of that support. The vendor’s escalation procedures must also be defined.
Deliverables
Respondents are required to provide a complete and detailed list of deliverables to be supplied under this RFP. The list must include the following major activities: computer hardware, system software and tools, applications software, communications equipment, communications software, training, documentation, Project Team, and other items or services.
Brochures and Product Literature All attachments and product brochures should be placed in this section.
COST PROPOSAL
This must provide detailed pricing of all items, products and services included under this proposal.
Respondents must provide costs and configurations for the UPS, Power Conditioners and standby generators that are necessary to support the full equipment that will be installed on ISX premises. A similar costing /configuration must be provided for broker premises equipment.
ISSA Recommendations 2000, refer to HYPERLINK "http://www.issanet.org" www.issanet.org.
Copies of the law (in English and Arabic) may be found on the ISX Web Site HYPERLINK "http://www.isx-iq-net" http://www.isx-iq-net.
HYPERLINK "http://www.isx-iq.net" http://www.isx-iq.net http://www.winnetmag.com/Articles/Index.cfm?ArticleID=2293
ISX Automated Trading and Electronic Settlement W914NS-04-R-0162 June 2004
Iraq Stock Exchange – Request for Proposals Page PAGE ii
Iraq Stock Exchange – Request for Proposals Page PAGE i
الرئيسية / العقود والمناقصات / BUS-9ebc13f6
العقود والمناقصات
Statement of Objectives — Iraq Stock Exchange
- التاريخ
- غير معروف
- الفئة
- العقود والمناقصات
- النص متوفر
- الإنكليزية
- عدد الملفات
- 1
تظليل نتائج البحث عن: