Cooperative Brokerage Integration for Transaction Capacity Sharing: A Case Study in Hong Kong

Cooperative Brokerage Integration for Transaction Capacity Sharing: A Case Study in Hong Kong Anthony C. Y. Lam 1 and Dickson K.W. Chiu 2, Senior Member, IEEE 1 Department of Computer Science, Hong Kong University of Science and Technology 2 Dickson Computer Systems, Hong Kong email: yuenchi@ust.hk, dicksonchiu@ieee.org Abstract Although today s brokerage trading platforms designed by software vendors fulfill the basic functionalities, the brokerage industry still has difficulties to face emerging problems such as the gradual increase of trading volume that cannot be handled because of the limitation of the current system architecture and throughput. Based on our consultation experience, we explain some of such constraints in Hong Kong from the business viewpoint of medium size brokerages. We introduce how a cooperative Transaction Capacity Sharing System (TCSS) among brokerages could help improve the situation by sharing their transaction capacity. In such business-to-business (B2B) system integration, we adopt asynchronous Web services and explain how they can work together to overcome these constraints in a real-time brokerage trading environment. We also detail the TCSS architecture and protocols for the integration which orchestrates the new cooperative trading process in our Web service based solution. 1. Introduction Since the Hong Kong Exchange and Clearing Limited (HKEX) introduced the new Order Routing System (ORS) with the Third Generation Automatic Order Matching and Execution System (AMS/3) on 23 rd February 2001, more than 100 brokerages have expressed their interest in connecting their trading system to the ORS [1]. Because AMS/3 is an open system, many stock trading system developers integrate their flagship solutions such as the Broker Supplied System (BSS) for brokerages and financial institutions to connect to HKEX. This allows online trading rather than over the phone and therefore improves the efficiency and effectiveness. Although the integration of BSS to AMS/3 solution has become common in the brokerage industry nowadays, it cannot fulfill more advanced and emerging requirements. Most of the trading systems running in brokerages are independent. In other words, a brokerage cannot achieve the maximum benefit in the financial industry using the automated trading system only for internal uses because of the very expensive trading capacity cost. To overcome these problems, we introduce a cooperative Transaction Capacity Sharing System (TCSS) among brokerage partners to help improve the situation. From a technical perspective, in order to expedite the trading process and minimize costs, some of the trading platform solutions provide Application Programming Interface (API) that allows in-house trading systems to communicate with one another. Many products in today s competitive market may achieve this but they have some common problems as described below: Communications among partners have no common standard of message protocols. No intelligent mechanisms have been or could possibly be integrated with the trading system for capacity sharing. It is hard to manage the security issues using different kinds of encryption techniques. For most integration architecture, extended Markup Language (XML) plays a role of trivializing the exchange of business data among companies by providing cross-platform approach in the areas of data encoding and data formatting. For example, Simple Object Access Protocol (SOAP), built on XML, defines a simple way to package information for exchange across system boundaries. By adopting standardized technologies, not only do we get interoperability for the customers, but we can also use our multi-platform approach to provide better solutions that help the financial industry accomplish their transactions more efficiently and profitably. Therefore, we propose the TCSS operate on a Web service platform using SOAP protocol. The TCSS aims at helping brokerages act more quickly and more efficiently by integrating the business logic, reducing the processing time, increasing the efficiency of order transaction, and therefore gaining competitive advantage in the industry. The major contribution of this paper is to 0-7695-2507-5/06/$20.00 (C) 2006 IEEE 1

show from this case study, how business-to-business (B2B) integration with contemporary technologies can help in this competitive digital economy. This paper is organized as follows. Section 2 discusses the background of Hong Kong s brokerage industry, the limitations of the current systems that affect the industry, and some related work. Section 3 presents the TCSS capacity sharing mechanisms. Section 4 discusses our design of the system architecture, integration protocol, and security based on Web services. The discussion and summary will be given at the end of this paper with future work direction. 2. Background and Related Work The previous Automatic Order Matching and Execution System (i.e., AMS/2) is an order-driven electronic trading system which supports on-floor and off-floor trading. Figure 1 depicts an overview of AMS/3, in which all the existing functionality such as order entry and automatic matching are maintained. In AMS/3, brokerages are allowed to access the market through the Trading Terminal or the Open Gateway (OG). OG is a new AMS/3 feature implemented to enhance the market capability of accessing the Order Routing System (ORS) to facilitate the electronically collection of clients order inputs. The OG is designed to support two different forms of trading facilities, namely the Multi-Workstation System (MWS) developed by HKEX and the brokerage s own front office trading system (termed as Broker Supplied System, BSS) [1]. Further, a BSS can either be a customized system or a commercial packaged product. By connecting a BSS to the OG, brokerages can design their trading processes and user interfaces to meet their own business and operational requirements. The Open gateway (OG) is a Windows NT-based device, located in the brokerage, to provide the connection between a BSS with the AMS/3 Host and Order Routing System through an IP-based Wide Area Network (WAN). For trading facilities, it supports an incoming Transmission Control Protocol (TCP) connection from either kinds of BSSs [2]. Figure 2 illustrates the information flow between BSS and the Host as well as ORS. Figure 1. System architecture of AMS/3 Figure 2. OG Connection Point Figure 3. Client placing a request A channel is provided for transaction flows between the AMS/3 Host and BSS, while another channel facilitates the control communication 2

between the ORS and BSS. Brokerages can choose to operate the OG and BSS on a 24-hour basis to collect client orders when HKEX operates the ORS on a round the clock basis. Figure 3 shows how typically a client can easily place an order request through an online broker [1]. Although the brokerages can leverage these new facilities to improve operational efficiency significantly and provide trading economies for their clients, there are still some constraints and limitations as explained below. Throttle rate control The OG will issue a throttle invitation to the BSS to solicit the submission of transactions [2]. The BSS may only send a transaction to the AMS/3 Host for each invitation received; otherwise such transactions will normally be rejected. As the OG allows brokerages to develop connections with the AMS/3 Trading Host, this mechanism is used to ensure a fair and orderly operation of the market. In addition, it ensures that the OG-Host traffic flow will not exceed the capacity of AMS/3. The throttle rate under AMS/3 is defined as 1 second per transaction per trading right. This means that the brokerage can have one or more trading right so that the BSS under such arrangement can send multiple transactions to the Host at the same time via the use of multiple throttle pipes. However, such throttle rate control also causes some drawbacks highlighted as follows: Additional trading right subscription is very expensive. Buying additional throttle rate is less expensive but on a monthly-fee basis. The basic throttle rate of only one order per second per trading right also means a slow response when the trading volume is high. Recently, the Hong Kong trading market data and statistics has indicated an exponential growth of the total value from the past 3 years as well as a potential increase of the trading value or volume by 2005 [3]. The throttle rate control is a major limitation of the transaction throughput. Medium size brokerages are unable to handle huge transactions volumes using the current BSS. Unless the brokerage is willing to buy expensive additional throttle rate as a short term solution, all the transactions must be queued on OG until the AMS/3 Host grants an invitation. Hardware failure is a major problem, especially for the financial industry. Nowadays, the OG has two technical configurations for choices, namely, Single Node Configuration and Active-standby Cluster Configuration. Medium to large brokerage enterprises tend to choose the latter configuration. With a primary and a secondary gateway installed at the brokerage, the secondary gateway will automatically takes over all the shared resources and performs as a primary gateway upon the failure of the primary gateway. However, in case of any abnormal situation that caused a long outage, both configurations are inadequate to handle. Based on the clients point of view, they cannot accept any kind of failures that affects heavily on the trading. Business integration and extensibility - Different trading systems often have proprietary message protocols and most of them are running in the brokerages independently. It is very time consuming and unreliable to understand or hack different interoperation protocols. Further, medium size brokerages often have several different applications. For example, credit controllers use the credit monitor application to approve or reject the clients who have inadequate balance to buy the commodities. Settlement officers use the back-office system to mange the clients portfolio and positions. In order to achieve system integration, each of them has to link with the trading system in order to obtain the realtime information. Often, a brokerage is forced to purchase a complete solution rather than spend the time in the integration or develop its own customized solution. Thus, an open standard for integration is called for. Reuters [13], one of the leading financial market information distributors, indicates that Web services are of strategic importance for Reuters and its clients. From Reuter s perspective, the concept of Web services appears to be ambitious, innovative, and more importantly an achievable approach to clarify, simplify, and resolve the ongoing system development of Reuters. Technical reports from other software vendors (such as [14]) indicate that they have the planning to develop Web services in order to extend their current system to other trading markets. Consequently, the software vendors in the financial market will be very competitive. There have been few technical papers on brokers applications. For example, McLeod [17] presents a study of broker desktop applications, which focuses on smoothing the workflow of brokers in a brokerage. Brokerages like Merrill Lynch have implemented such applications for their brokers since 1996 [16]. A current trend of application development is to focus on the collaboration with a brokerage s web presence. For example, the Trusted Global Advisory (TGA) system of Merrill Lynch started collaboration with its web presence Merrill Lynch Online in 1999 [18]. Chiu et al. [15] describe the stock trading environment in Hong Kong and proposes an event- 3

driven customer relationship management system for small brokerages. However, most of these studies relate more to the front office of the brokerage operations. There are even fewer work on the backend business logic as this is probably highly sensitive and valuable in the brokerage industry. These background and related work motivate our case study and provided some key requirements for designing the TCSS. 3. TCSS Capacity Sharing Mechanism Based on the requirements as discussed above, we highlight an overview of our TCSS and discuss its key mechanisms for capacity sharing. 3.1. TCSS Overview HKEX Trading Host Router Hub Open Gateway (OG) ` Workstation ibss ` Workstation RAS with SOAP / Http Figure 4. TCSS overview SOAP / Http SOAP / Http Local Brokerage Partner with Global Brokerage Partner with Local Brokerage Partner with According to the requirements discussed in the previous section, Figure 4 depicts an overview of our TCSS. The TCSS is one of the server-side applications running on an internal network within a brokerage. In order to exchange the order information with partners in an open platform, we choose to use Web services with SOAP protocol for this B2B integration Although most of the basic business logics have been implemented in common BSS such as margin calculation for order request, etc., our objective is to enhance it through integration with partner brokerages. Regarding to the huge transaction queuing on OG, capacity sharing mechanism plays the major role in TCSS System. Let us first explain the traditional mechanism with the following example. Suppose the client wants to place a 50K quantity with the price of 18 dollars using a user front-end trading system. Upon confirmation, the request is directly delivered over TCP/IP connection to the BSS backend application. The BSS takes this request and performs various verifications, such as whether the client has enough balance to buy the stock. After the verification process, the validated order is placed into the order queue (as shown in Figure 5), waiting to be sent out the HKEX host. As mentioned before, the HKEX host only accepts the order request packed with throttle control. All the orders will be marked as invalid if the packet message has no throttle control. Therefore, the order queue increases gradually when many clients are making the request at the same time. 1 2 3 3 4 5 6 Figure 5. Order Queue... 19 20 Now let us explain the capacity sharing of TCSS. To improve the turnaround time for each order request, we maintain the maximum length of order queue, as this example, 20 is the maximum buffer size of the order queue. If the queue if full or reach a certain threshold, the BSS will route the request to TCSS in order to forward it to partner brokerages. Each brokerage has its own broker ID, which is saved with the order. This enables TCSS to identify these forwarded orders with its partners as well as the dealer to have the clear picture about the order flows. After the forwarded transactions are executed with the notification sent back to TCSS, the relevant order can be matched, updated, and logged accordingly. As a result, the client also receives the acknowledgement promptly 1. All the forwarded orders are sent to the destination via Web services while TCSS asynchronously tracks for the completion acknowledgement. An asynchronous implementation is essential because TCSS has to handle many outstanding orders simultaneously while the time when the orders can be fulfilled is unpredictable. The order number and the partner ID is saved in the database so that it identifies all the pieces sent to the partners. Then the TCSS will send the forwarding information as well as any matching results back to the front-end application, so that both the dealers and the clients know clearly the full progress of the trade. Hence, the forwarded orders and B2B integration can be fully automated. 1 In Hong Kong, a client must accept a partial order in correct lot size if the price criterion is met. 4

3.2. TCSS Intelligence and Heuristics The forwarding process takes the following three criteria into consideration. 1. Outstanding backlog and forwarding threshold 2. Forwarding limit and cost of different brokerages 3. Number of partner brokerages The most important heuristic is that if the OG is not queued fully or reach a certain forwarding threshold, the system may not perform the forwarding process. This is because the turnaround time of the transaction may not be better compared with the turnaround time using the internal BSS system. For example, if the brokerage has one trading right and the order queue size was 10, it takes 10 seconds to complete the order request. If the orders are routed to TCSS for forwarding, the time consumed during the forwarding process added with the queuing time at the partner may possibly be longer. Another criterion is the forwarding limit imposed by a partner. This is because the throttle rate is a very valuable and limited resource to a brokerage. They can offer only a limited portion of their capacity to partners so that such service does not affect that of their own. In addition, they can impose a cost on it because the trading right is very expensive. In addition, a TCSS can adjust its forwarding threshold and forwarding limit dynamically according to its current queue length to achieve an effective flow control. This information as well as the current queue length can be sent piggy-back with acknowledgements or broadcasted to partners if necessary. Other partner TCSSs can use such information for choosing an appropriate target of the next forwarded order. Therefore, a TCSS also have to observe and honor this limiting of partners in order to maintain a good relationship. So, outstanding backlog orders have to be delayed until the next round when any partners can then accept them. Therefore, the more partner brokerages join together, the more chance are there to have a partner with a short or empty queue. So, with more partners, it is possible to set the forwarding threshold lower. As every brokerage have at least one trading right, small brokerages with less transactions may consider to team up with medium size ones in order to recover some costs from sharing of the expensive trading rights. 4. TCSS Design and Implementation In this section, we present the design and implementation of our TCSS, highlighting the system architecture, protocol, and security. 4.1. System Architecture Partner Brokerage with TCSS / BSS SOAP Internet SOAP Transaction Web Services Interface Service Dispatching and Aggregation Adaptation Manager TCSS Process Manager TCP/IP ODBC Figure 5. TCSS architecture BSS Application Database As shown in Figure 5, the TCSS has three main components, namely, the main TCSS Process Manager, the Adaptation Manager, and the Web Services Interface. The Adaptation Manager is the key connector of the TCSS. It transforms the messages among the inhouse BSS, TCSS Process Manager, and the Web Services Interfaces into the correct format and calling conventions. For example, it accepts outgoing order requests from the BSS Application and incoming order requests from partners via the Interface. Here, the required protocol transformation is among SOAP and TCP/IP [4][5]. It also dispatches outgoing orders from the TCSS Process Manager and routes completion acknowledgements back. Moreover, it routes information messages to the BSS so that the relevant clients and dealers know the trade progress. The TCSS Process Manager controls and monitors the execution of the main typical trading processes including Add Order, Amend Order, and Delete Order. It contains the intelligent logic for deciding the forwarding of outgoing order. It also validates if incoming orders from partners meets the mutually imposed limits. Whenever completion acknowledgements are obtained from the asynchronous Web service via the Adaptation Manager, this triggers the TCSS Process Manager to update the transaction trading status. 5

The Interface is invoked with a SOAP call that it binds data such as stock code, order price to the XML response template. Once the Adaptation Manager sends the request to the Transaction Web services, it dynamically binds the data such as the lot size and the price to input XML template [4] and send the request directly to the destination partner. When an acknowledgement is sent back from a partner, it binds the live data with the response XML template and sends it back to Adaptation manager. 4.2. TCSS Protocol After evaluations, we choose the Microsoft.Net framework [6] to implement Web services with a standard protocol called Financial Information exchange (FIX), which is developed specifically for real-time electronic exchange of securities transactions [7]. Before sending the request to the partners, the Adaptation Manager translates the message as FIX Markup Language (FIXML) using the FIX protocol [7][8]. The FIX protocol consists of: A Standard Header; A set of Tag = Value fields separated by field delimiters; and A Standard Trailer Using the symbol ; as a separator, the format of a FIX message looks like: 35=D;55=0001.HK;54=2;38=1000;40=1 As the tags are numeric values so it is not very readable, we turn it into pseudo English and yield: Symbol=1000.HK;Side=Sell; OrderQty=1000;OrdType= Market For example, a complete FIX message looks like: 8=FIX.4.2;9=199;35=D;34=10;49=VENDOR;115=CUS TOMER;144=BOSTONEQ;56=BROKER; 57=DOT;143=NY;52=20000907-09:25:28;11=ORD_1;21=2;110=1000;55=EK;22=1; 48=277461109;54=1;60=20000907.09:25:56;38=500 0;40=2;44=62.5; 15=HKD;47=A;10=165; When the highlighted body of the message is translated into FIXML, this becomes: <FIXML> <FIXML Message> <Header>...</Header> <ApplicationMessage> <Order> <CIOrdID>ORD_1</CIOrdID> <HandInst Value="2" /> <MinQty>1000</MinQty> <Instrument> <Symbol>EK</Symbol> <IDSource>1</IDSource> <SecurityID>277461109</SecurityID> </Instrument> <Side Value="1" /> <TransactTime>20000907.09:25:56</TransactTime> <OrderQuantity> <OrderQty>5000</OrderQty> </OrderQuantity> <OrderType> <LimitOrder Value="2"> <Price>62.5</Price> </LimitOrder> </OrderType> <Currency Value="HKD" /> <Rule80A Value="A" /> </Order> <ApplicationMessage> </FIXMLMessage> </FIXML> The following example shows the data encoded into SOAP message: <?xml version= 1.0 encoding= UTF-8?> <SOAP-ENV:Envelope xmlns:soap-env= http://schemas.xmlsoap.org/soap/envelope/ xmlns:soap-enc= http://schemas.xmlsoap.org/soap/encoding/ xmlns:xsi= http://www.w3.org/2001/xmlschema-instance <SOAP-ENV:Body SOAP- ENV:encodingStyle= http://schemas.xmlsoap.org/soap/encoding/ > <sendmessage> <FIXMLMessage> <Header> <Sender> <CompID>Hopgood</CompID> </Sender> <Target> <CompID>Lloyds</CompID> </Target> </Header> <ApplicationMessage> <Indication> <IOIid>41926</IOIid> <Instrument> <Security> <Symbol>IBM</Symbol> </Security> </Instrument> <IOISide Value="1"/> <IOIShares>2000</IOIShares> <Price>30.00</Price> <Currency Value="GBP"/> <ValidUntilTime>22:50</ValidUntilTime> </Indication> </ApplicationMessage> </FIXMLMessage></sendMessage> </SOAP-ENV:Body> </SOAP-ENV:Envelope> One of our designs is to make use of asynchronous Web service calls as explained in Section 3. Asynchronous calls return immediately and 6

then use some other mechanisms for indicating when the call actually completes. This is essential because the completion time of a transaction is unpredictable. Microsoft.Net Framework provides support for making asynchronous Web service calls over HTTP [9]. For example, the SoapHttpClientProtocol class also has a method called BeginInvoke, which is the mechanism used to start an asynchronous request. The code is shown as below: Public Function BeginDelayedResponse( _ ByVal waitperiod As Integer, _ ByVal callback As System.AsyncCallback, _ ByVal asyncstate As Object) As System.IAsyncResult Return Me.BeginInvoke("DelayedResponse", _ New Object() {waitperiod}, _ callback, _ asyncstate) End Function 4.3. Security in Asynchronous Web services When choosing Web services for business applications, security is one of the important issues that have to be addressed. At the InfoWorld Next- Generation Web services Conference in January 2002 [10], more than half of the attendants considered security as one of their major concerns when implementing Web services. In order to build a secure Web services architecture, security issues of all layers of the Web services stack should be carefully tackled, as vulnerability will invite malicious attackers to penetrate the system. The basic security requirements on information systems also apply to Web services messaging. They include: Confidentiality Web services messages should only be read by the intended recipients. Integrity Web services messages should not be modified by any unauthorized party accidentally or deliberately during transmission. Authentication Web services messages should be transmitted by a properly identified sender. This is a prerequisite for applying authorization to access Web services. Authorization Only authorized senders can send messages. Non-repudiation Message senders cannot deny that they did send the message. Here we discuss how contemporary security technologies for Web service helps. As shown in the previous sub-section, SOAP messages play an important role in the proposed system. Hence, to make sure the message protocol is well protected, we apply WS-Security for the communication. WS- Security describes how to use the existing W3C security specifications, XML Signature, and XML Encryption, to ensure the integrity and confidentiality of SOAP messages. Together with WS-License, it describes how existing digital credentials and their associated trust semantics can be securely associated with SOAP messages. Together, these specifications form the bottom layer of comprehensive modular security architecture for XML Web services. Future security specifications will build on these basic capabilities to provide mechanisms for credential exchange, trust management, revocation, and other higher-level capabilities [11][12]. Figure 6. Embedded XML encryption WS-Security defines a SOAP Header element to carry security-related data. If XML Signature is used, this header can contain the information defined by XML Signature that conveys how the message was signed, the key that was used, and the resulting signature value. Similarly, if an element within the message is encrypted, the encryption information such as that conveyed by XML Encryption can be contained within the WS-Security header. WS- Security does not specify the format of the signature or encryption. Instead, it specifies how one would embed the security information laid out by other 7

specifications within a SOAP message. WS-Security is primarily a specification for an XML-based security metadata container. Figure 6 (extracted from the Knowledge Base at Microsoft) shows a WS-Securitybased message with embedded XML Encryption information [11][12]. As such, security among TCSS partners can be ensured. 5. Discussion and Summary In this paper, we have presented our proposed TCSS, a system which can decrease the queuing time in the OG during peak transaction volumes by sharing transaction capacities among partner brokerages. We have explained the background business practices and how the routing of orders help. In particular, this helps them avoid significant costs of buying extra trading rights, which is very expensive. Such improvement helps them to group together against large brokerages that have much better facilities and trading capacities, as better trading services and performance is the key to customer relationships [15]. Further, upon hardware failure of the OG, orders can be routed to partner brokerages through the TCSS. Therefore the cost of implementing the TCSS is justified for its benefits. We have also presented a pragmatic system architecture for the TCSS together with its major components. We illustrate how Web services technologies can be used effectively and efficiently in the B2B integration, supporting adequate communications and security features, even for realtime financial services with stringent requirements. The TCSS Process Manager can incorporate customizable intelligent business logic and augment the current Broker Trading System (BSS) platform as a separate system, so that it can be developed and maintained separately. This allows for the coexistence of the legacy BSS, which is a key software component of the brokerages for their current daily operations. So, this helps decrease the development time and effort as well as facilitate testing and finetuning. Another advantage is the automation and transparency of the TCSS, which does not increase the regular operation overheads for the dealers. One might imagine the security and management issues as well as the management s worry involved in such operations that involve a large transaction amount. However, in Hong Kong, many small and medium size brokerages have multiple broker licenses (i.e., different broker IDs for trading at HKEX), they can deploy the TCSS integration within their enterprise or within their group, where they have adequate security, governance, and trust. Instead of manual diverting clients to other offices or trading hot-lines within an enterprise, the TCSS provides such automation in a fully transparent manner and therefore has no legal issues or conflict with HKEX regulations. For the alliance of different brokerages, we identify legal and regulatory issues as one important direction for future research. In addition, inter-brokerage charging policies and schemes constitute another important direction for future research. Although the proposed system obviously increases the transaction volume and improves the queuing time, how detail heuristics could be best formulated is still a major research problem. We are investigating in simulations to experiment various parameters. Order processing and turnaround time are also important parameters to be measured and affects the choice of parameters. After obtaining the statistical data, we have to make some adjustments on the current system and parameters. On the other hand, we would like to introduce priority management in the routing for valued customers as well as for transactions that involve a large amount. References [1] Hong Kong Exchanges and Clearing Limited: AMS/3, http://www.hkex.com.hk/infra/ams3/ams3_ov.pdf [2] Hong Kong Exchanges and Clearing Limited: OG http://www.hkex.com.hk/infra/ams3/ams3_og.pdf [3] Hong Kong Exchanges and Clearing Limited: Data and Statistics http://www.hkex.com.hk/data/securitiesmarket.htm [4] Microsoft: Web service Basic, http://msdn.microsoft.com/webservices/understanding/ webservicebasics/default.aspx [5] Microsoft: Understand SOAP, http://msdn.microsoft.com/webservices/understanding/ webservicebasics/default.aspx?pull=/library/enus//dnsoap/html/understandsoap.asp [6] Creating and Using Web services with.net framework http://www.westwind.com/presentations/dotnetwebservices/dotnetweb Services.asp [7] Financial Information Exchange protocol http://www.fixprotocol.org/ [8] FIXML Resources for FIX 4.4 Specification http://www.fixprotocol.org/specifications/fix4.4fixml [9] Microsoft: Asynchronous Web services call over HTTP with.net Framework http://msdn.microsoft.com/library/default.asp?url=/libr ary/en-us/dnservice/html/service09032002.asp [10] InfoWorld Next-Generation Web services Conference, http://www.infoworld.com/features/fenextgen.html 8

[11] Microsoft: Understand WS-Security, http://msdn.microsoft.com/library/default.asp?url=/libr ary/e-us/dnwssecur/html/understw.asp [12] Microsoft: Web services Security Specification Index Page http://msdn.microsoft.com/webservices/understanding/ specs/default.aspx?pull=/library/enus/dnglobspec/html/wssecurspecindex.asp [13] Position paper for W3C Workshop http://www.w3.org/2001/03/wsws-popa/paper03 [14] ebroker System Limited http://www.ebrokernet.com/eng_index.htm [15] D.K.W. Chiu, Wesley C. W. Chan, Gary K. W. Lam, S. C. Cheung, and Franklin T. Luk. An Event Driven Approach to Customer Relationship Management in an e-brokerage Environment, in Proc HICSS36, 10 pages, CDROM, Jan 2003. [16] S. Hopper, Real World Design in the Corporate Environment: Designing an Interface for the Technically Challenged, In Proceedings of the Conference on Human Factors in Computing Systems, Vancouver, British Columbia, Canada, April 1996. Online at: http://www.acm.org/sigchi/chi96/proceedings/desbrief/ Hopper/Hwh_txt.html [17] J. McLeod. The Broker Desktop. The Future of Trading Has Arrived, in J. Keyes (ed), Financial Services Information Systems, 2nd edition, Auerbach, 2000. [18] J. L. Steffens. The Role of Online Advice, In Proceedings of the Forrester Conference Princeton, New Jersey, 1999. 9