NASDAQ’s Securing Security Transaction
🌐 International Buyers — Pay via PayPal
Details
ITSY013
8
2002
YES
300
Nasdaq Stock Market
Financial Services
US
Systems Design ,Systems Thinking, Technology in Capital Markets
Abstract
The case explains why Nasdaq needed an SDR system. This study also examines the stock exchange’s decision to utilize solutions from three different companies, Unisys, Plural and Microsoft. The software development procedure adopted for the system is studied in detail.
Learning Objectives
The case is structured to achieve the following Learning Objectives:
- High quality technology infrastructure for an electronic stock exchange.
Contents
“Nasdaq’s new Surveillance Delivery Real-time system is an alert detection and presentation system that is unmatched in its speed and ability by any other financial market in the world.”
- Gregor S. Bailar, Executive VP and Chief Information Officer, NASD, in September 1999.
The story of the second largest US stock market, the National Association of Securities Dealers Automated Quotation System (Nasdaq), dates back to the 1960s, when a study was conducted by the Security and Exchange Commission (SEC)1 for improving the functioning of the over-the- counter (OTC) market. The study recommended that the SEC automate the market. The responsibility for automating the market was handed over to the National Association of Security Dealers (NASD).
Nasdaq was established as a subsidiary of NASD for the above purpose. The exchange started trading operations by 1971 and soon established its identity as the world’s first and largest electronic market. The exchange’s computerized system facilitated securities trading by providing traders with current bid and ask price quotes on OTC stocks and some listed stocks. It was rated among the world’s best- regulated stock markets as it employed very sophisticated surveillance systems and regulatory specialists for ensuring investor protection and a competitive trading environment.
Nasdaq introduced many innovative measures for the benefit of the investors and for ensuring the stability of the markets. In 1984, it introduced the ‘Small Order Execution System’ (SOES) to execute small orders automatically against the best quotations. This resulted in greater volume and trade efficiency. In 1990, it introduced SelectNet, an online negotiation mechanism for finding and executing transactions at the best prices.
By 1994, Nasdaq surpassed the New York Stock Exchange (NYSE) in annual share volume of business transactions. In 1997, it completed the implementation of Order Handling Rules. In 1998, it entered into a partnership with the Stock Exchange of Hong Kong for providing investors information about both US and Hong Kong markets on a joint Internet web service. By 1999, it had become the largest stock market in the US in terms of dollar volume. In the same year, it entered into an agreement with Softbank Corporation to form Nasdaq Japan. This marked the beginning of its initiatives to link Asian markets with European and American markets. In the late 1990s, the growing popularity of online securities trading radically transformed the role of stock exchanges. Technological improvements, electronic commerce and increased availability of high-speed Internet access had led to radical changes in the corporate environment. According to NASD, Internet trading had grown to 20% of Nasdaq’s total shares traded. Online trading was significantly different from the traditional method of trading.
Moreover, Nasdaq was finding it tedious to handle the increasing volume of data using the existing Tandem K200006 application for monitoring. This was because the infrastructure was reportedly not robust enough to handle the increasing volumes. As Nasdaq was fully electronic and completed complicated financial transactions in minutes, even a small transactional error had more chances of having immediate and far-reaching ill effects. In order to achieve stability and integrity in the market, Nasdaq wanted to implement an application which would aid in:
Analyzing Nasdaq’s markets every day Identifying unusual market movements and delivering appropriate alerts to the analysts within two seconds of the arrival of information. Supplying all relevant alert related data to the analysts. Ensuring security and enabling the audit of information collected and delivered to the analysts.
To ensure stability and integrity of the market in the Internet era, Nasdaq’s market watch department decided to add additional automated alerts which would help it monitor the market more efficiently. According to Nasdaq sources, the exchange would also benefit from the integration of data into a single tracking system. Nasdaq also wanted to redesign the whole process of monitoring to become much more flexible and responsive to dynamic market conditions. It therefore decided to implement the Surveillance Delivery Real-time system (SDR).
The user groups identified by Nasdaq for the new system were StockWatch users, TradeWatch analysts, MarketWatch operations managers and MarketWatch management groups. The Request For Proposal7 (RFP) for the new system was released in 1997, and the design work began in April 1998.
The exchange already had clearly defined network management and maintenance procedures in place. Keeping in mind this well-defined existing infrastructure and expertise, the RFP recommended a platform solution that utilized either Windows or UNIX. Nasdaq decided to select a Windows-based solution, as the Component Object Model (COM), Microsoft Transaction Server (MTS) and Microsoft Message Queue (MSMQ) running on it were reportedly more reliable, operationally flexible, secure and scalable.
The software development process was begun with the help of three IT firms: Unisys Corporation, Plural, and Microsoft. Unisys Corporation, which had been associated with Nasdaq for over 25 years, had extensive knowledge of operating environments and mission-critical enterprise systems. It was involved in the SDR project very early on, when the SDR architecture was being defined. Plural was an eSolutions consulting firm and had been named Microsoft’s Solution Provider Partner of the Year in 1999.
The expertise and extensive knowledge of the financial services industry helped the firm develop customized coding for the SDR project. Since Nasdaq had standardized its Local Area Network (LAN) environment on the Windows NT platform, Plural and Unisys designed and executed a benchmark system to test the capability of the Windows NT server to effectively handle a large number of transactions. The server not only managed to pass this test, it also:
- Provided accurate information by examining more than two million transactions for each trading day, and delivered alerts to analysts within two seconds.
- Provided reliable information and extensive recovery procedures.
- Eliminated the need for rewriting the code through the use of larger processors.
- Accommodated changes in logic, filters, rules and various other programmed modules without changing the software.
Nasdaq adopted the client-server architecture for the SDR.11 The server platform comprised 11 Unisys QR/2 servers using technologies such as a 100 MHz System Management Bus, Intel 500 MHz Pentium III Xeon processors with 2 MB cache memory, address space of 8 GB and multiprocessing support for around four processors (supported by clustering technologies). The client was operated on a standard Intel desktop with minimum configurations as all quality control testing was performed on desktops. The client platform configuration comprised a 266 MHz Pentium processor, 128 MB RAM and 2.1 GB hard drive.
The development life cycle of the SDR application was classified into four stages: design, development, quality control and production (Refer Table I). The SDR architecture was made up of three tiers: application tier, database tier, and client presentation tier. The three-tiered architecture had the following advantages (for the development team):
- Allowed the replication of application components across various machines, thus enabling higher availability, scalability, and performance.
- Reduced the total number of sessions that needed database server support, thereby improving the performance
- Centralized the security of all components. This in turn allowed granting or denying of access on a component-by-component, thus simplifying the administration
Table I
Development Life Cycle
| Stage | Activities |
| Design | Design was started in July 1998. Developers identified the high-level application design which was treated as benchmark for the detailed design. |
| Development | During November 1998-April 1999, the program code was created, documented, assembled and tested. |
| Quality Control |
All elements of the SDR, such as functionality, user acceptance, disaster recovery and logical errors, were tested. Code modifications were done during this stage. No software coding was done. If any tests demonstrated problems with any subsystem, the project was returned to the development stage. This stage lasted until August 1999, after which the application was introduced into the production environment. |
| Production | Begun August 1999. Final testing and adjustments to the parameters were done without taking any risks with alerts. Once completed, the SDR was implemented planned phases to prevent any interruption of work. |
Source: IBS Center for Management Research
Every tier in the system had components for specific activities. The database tier was used primarily for archiving the information of alerts generated by the alert engine. The fault tolerance for the database servers was provided by a combination of mirrored drives. The application tier was made up of 3 primary components, viz., Line Handler, the Alert Engine, and the Alert Dispatcher (Refer Table II).
Table II
Application Tier Servers
| Servers | Activities |
| Line Handler Server |
It receives input data from various dissemination servers and organizes data to single stream into a common format. It transfers the information to the Alert Engine and delivers quote-related data to the SQL database server for additional support data to the Alert Dispatcher server. It also does gap detection for the MarketWatch department by finding out he correct sequence of the data. The gap detection function is essential for ensuring the accuracy of the information. |
| Alert Engine | It analyzes data received from the Line Handler Server and compares it with the established criteria through the alert administration process. It also determines when an alert should be generated and dispatched to MarketWatch analysts. This component operates with two-second processing requirement. |
| Alert Dispatcher |
This server is responsible for sending alerts the alert generation to the analysts’ workstations. The alert information is sent to the SQL server database to be archived. An interval of two seconds was allowed between the receiving of data from the dissemination servers and dispatch of an alert, to the workstation. |
| Analyst Server |
This server performs the dual role of a network layer component. It supplies Analyst Client alert related information and also provides history and detail to the database server. |
Source: IBS Center for Management Research
The surveillance and reporting responsibilities required by the SDR system for meeting pre-determined performance standards were distributed across various servers. Server clustering was implemented within the SDR database environment to ensure the availability and reliability of information (Refer Figure I for the MarketWatch process).
Figure I
| Marketwatch System at Nasdaq |
![]() |
Source: www.microsoft.com
The development process was started in November 1998 and Phase I was completed in April 1999, marking the implementation of the software developed. The client presentation tier comprised the analyst client software and system support interface utilities. As the primary features of this tier were the presentation features user friendly interface screens were provided. The client side application was installed on each computer for controlling customized graphical alert screens and other output. In August 1999, quality control was completed and introduced in the production environment in parallel with the existing system. The application became the system of record in September 1999, and Nasdaq completed the implementation by the end of 2000.
According to analysts, the SDR made Nasdaq’s transactions more secure and reliable. They felt that investor confidence increased as a result of the automated surveillance system, which safeguarded the integrity of the markets. The SDR ensured that trading was done properly by scanning transaction data from various sources and analyzing each transaction to detect unusual market movements. SDR also increased the scalability levels of Nasdaq, thus enabling Nasdaq to handle varying workload levels in a consistent manner.
According to Nasdaq sources, on an average, one billion shares were traded per day on Nasdaq. This translated to approximately two million electronic transactions per day. SDR was benchmarked to operate double the number of transactions and handle up to four billion shares daily. After the successful implementation of SDR, Nasdaq decided to implement the new SEC-approved trading system, SuperMontage, on a global scale. SuperMontage would display the total amount of trading interest in Nasdaq at the best bid price and at the best offer price and also two trading increments away from those prices. According to Nasdaq sources, it would provide greater information about the market and help investors make better trading decisions.
1. Explain why Nasdaq decided to implement the SDR system. Also comment on Nasdaq’s decision to adopt a three-tier architecture for the software.
2. Study the system architecture implemented during the deployment of SDR at Nasdaq. Critically comment on how the exchange derived the initiative’s benefits.
Keywords
Nasdaq, SDR, system, stock exchange, decision, utilize, solutions, Unisys, Plural, Microsoft, software, development, procedure, system
Related Case Studies
| Case Title | Details | Price | Add to Cart |
|---|---|---|---|
|
Case Title Automation at TeslaCase Code: ITSY104 |
Details | 500 | Add to Cart |
|
Case Title Transforming GE through Industrial InternetCase Code: ITSY079 |
Details | 500 | Add to Cart |
|
Case Title The Making of Boeing 777Case Code: OPER044 |
Details | 600 | Add to Cart |
|
Case Title Maruti Udyog: Using Technology in LogisticsCase Code: CLSDM036 |
Details | 200 | Add to Cart |
|
Case Title Cemex and its Technology InitiativesCase Code: CLSDM025 |
Details | 200 | Add to Cart |
