Expert Systems with Applications 27 (2004) 439–450 www.elsevier.com/locate/eswa
A web-service agent-based decision support system for securities exception management Minhong Wang, Huaiqing Wang*, Dongming Xu, Kwok Kit Wan, Doug Vogel Department of Information Systems, City University of Hong Kong, Kowloon, Hong Kong, China
Abstract With rising trading volumes and increasing risks in securities transactions, the securities industry is making an effort to shorten the trade lifecycle and minimize transaction risks. While attempting to achieve this, exception management is crucial to pass trade information within the trade lifecycle in a timely and accurate fashion. For a competitive solution to exception management, a web-service-agent-based decision support system is developed in this paper. Agent technology is applied to deal with the dynamic, complex, and distributed processes in exception management; web services techniques are proposed for more scalability and interoperability in network-based business environment. By integrating agent technology with web services to make use of the advantages from both, this approach leads to more intelligence, flexibility and collaboration in business exception management. The effectiveness of this approach is evaluated through a use case and demonstration feedback. q 2004 Elsevier Ltd. All rights reserved. Keywords: Intelligent agents; Web services; Decision support systems; Exception management; Securities trading
1. Introduction With rising trading volumes and increasing risks in securities1 transactions, the securities industry is making an effort to achieve Straight Through Processing (STP) to shorten the trade lifecycle and minimize transaction risks. While attempting to achieve this, exception management is critical to pass trade information within the trade lifecycle in a timely and accurate fashion. However, the major issue of such risk management has not been adequately addressed, and the mechanism of automating exception management is still under investigation. Though a number of companies have delivered exception solutions in their STP products, the mechanism of how to diagnose and resolve exceptions in securities transactions has not been clearly investigated. Moreover, their approaches lack knowledge orientation and collaborative decision-making in exception reconciliation process, which is crucial for strategic and collaborative exception management within financial institutions involved in the trade lifecycle. This research aims to * Corresponding author. Tel.: þ 852-2788-8491; fax: þ 852-2788-8535. E-mail address:
[email protected] (H. Wang). 1 Securities are financial instruments that may be purchased and sold, the most common forms of which are equities and bonds. 0957-4174/$ - see front matter q 2004 Elsevier Ltd. All rights reserved. doi:10.1016/j.eswa.2004.05.014
automate the identification and resolution of exceptions to assist securities industry to gain quicker competitive advantage. Exception management is a kind of complex and dynamic process. Most efforts to handle exceptions in business process have utilized workflow technology to include conditional branches in workflow model or redesign business systems to deal with anticipated exceptions. Such approaches offer limited support for flexibility and collaboration during process management (Jennings, Faratin, Norman, O’Brien, & Odgers, 2000; Klein & Dellarocas, 2000), and may cost a lot on business redesign or reconstruction. Therefore an agent-based approach is proposed in this research. By analyzing, designing, and implementing complex processes as a collection of interacting and autonomous components, agent-oriented techniques are well appropriate for business exception management. Given specific knowledge and capabilities, intelligent agents are capable of dealing with complex problems and vast amounts of information collaboratively in dynamic and unpredictable environments (Wang, Wang, Wan & Xu, 2004). Moreover, as Decision Support Systems (DSS) environments are rapidly changing from centralized and closed to distributed and open in Internet computing, web services are adopted as promising technology to support open and distributed decision making for exception management. In our research, we try to
440
M. Wang et al. / Expert Systems with Applications 27 (2004) 439–450
integrate agent technology with web services to make use of the advantages from both. The rest of the paper is organized as follows. Section 2 briefly reviews the relevant literature on exception management in securities trading, intelligent agents-based decision support systems and web service issues, and related work in securities exception management. After analyzing the exceptions occurring in securities transaction practice in Section 3, we design a web-service agent-based decision support system for exception management, and elaborate on the agent hierarchy, agent structure and their communication based on web services standards in Section 4. The implementation of this prototype system is described in Section 5. In order to evaluate our system in Section 6, a use case is created to illustrate the effectiveness of the system, and a demonstration is designed and consummated to gather user feedback and satisfaction. Results are presented. Finally, Section 7 concludes with some advantages from our approach to exception management systems.
2. Background 2.1. Securities trading and exception management The financial services industry is undergoing rapid changes on a global basis. With rising trading volumes in domestic and cross-border security transactions, risks faced by global financial firms and markets are increasing. Significant inefficiencies in cross-border transactions caused by data re-entry, lack of standards, delays, frequent manual intervention, and other breaks in the security transaction workflow have led to high failure rates, high costs and operational risks in such trades. The financial services industry is presently to achieve the end-to-end automation of security trading process from order to settlement (US Securities and Exchange Commission, 2001). While attempting to achieve this, care must be taken to ensure that trades containing errors are detected and reconciled at the earliest opportunity, preferably prior to communicating details to the outside world (Kumar & David, 2000; Simmons, 2001). Exceptions in securities transactions may increase processing costs and damage service reputations. Based on the 80– 20 rule, the 80% of transactions that passed straight through without a problem consumed only one fifth of back-office costs, while the 20% of transactions which hit a problem consumed a disproportionate fourth of back-office overhead (Wall Street and Technology Online, 2000). However, the major issue of risk management in securities transactions has not been adequately investigated. “The market gets confused when they talk about exception management because they are usually talking about people being involved in the resolution” (Guerra, 2002). Some exception-management systems simply take a faulty
trade which has been kicked out of the STP flow and route it to an operations professional for examination and repair. Though a number of players in the securities markets have tried to provide exception management service in STP systems, exceptional situations are quite complicated and the mechanism of exception reconciliation is still under investigation. More work is needed to investigate the mechanism of exception management, especially at the strategic and tactical levels with respect to knowledge-based technology. 2.2. Intelligent agents—a DSS perspective Intelligent agents are used to denote a software-based system that is situated in some environment, and that is capable of autonomous action in order to meet its design objectives (Wooldridge, 2002; Wooldridge & Jennings, 1995). To achieve its goals, an agent needs to use its knowledge to reason about its environment (as well as behaviors of other agents), to generate plans and to execute these plans. Since agent technology provides flexible, distributed, and intelligent solutions to business applications, researchers have proposed to design and develop numerous intelligent-agents based systems to support business exception management in dynamic and unpredictable environments (Wang, Mylopoulos & Liao, 2002; Wang & Wang, 1997, 2002). Decision Support Systems (DSSs) are computermediated tools that assist managerial decision making by presenting information and interpretations for various alternatives. The DSS environment is changing into a distributed, open, interoperable, and scalable environment in conjunction with parallel changes in Internet computing. Recent research has attempted to apply agent technology to DSS development to support organizations characterized by distributed, enterprise-wide, heterogeneous information systems (Wang, 1997; Pinson, Louca & Moraitis 1997; Paulson & Kim, 1999). We contend that Internet-based DSS is a special form of cooperative information systems, characterized by cooperating agents, either human or non-human actors/users. In such cooperative DSS, intelligent agents offer tremendous potential in supporting well-defined tasks, such as data conversation, information filtering, and data mining (Bui & Lee, 1999), as well as supporting ill-structured tasks in dynamic cooperation (Orwig, Chen, Vogel & Nunamaker, 1996). 2.3. Web services Web services are currently one of the trends in networkbased business services, which offer a new paradigm for distributed computing. Web services are self-contained and modular business process applications based on open standards; they enable integration models for facilitating program-to-program interactions. As DSS environments are rapidly changing from centralized and closed to distributed
M. Wang et al. / Expert Systems with Applications 27 (2004) 439–450
and open mainly by virtue of the proliferation of WWW, scalability and interoperability features are getting more crucial to DSS development. Conventional web technologies have enabled DSS to be openly used on the Internet, in spite of some limitations, such as pre-defined specific input/output formats and lack of machine-understandable semantics in the current web pages. Fortunately, current emerging technologies give us a clue to resolving these problems. Among those technologies, web services are promising for open web-based DSS and hence adopted in this paper. Typical agent architectures have many same features as web services, and extend web services in several ways. Web services, unlike agents, are not designed to use and reconcile ontologies. A web service knows only about itself, while agents often have awareness of other agents and their capabilities as interactions among the agents occur. Agents are inherently communicative, whereas web services are passive until invoked. Agents are cooperative, and by forming teams and coalitions can provide high-level and more comprehensive service, while current standards for web services do not provide for composing functionalities (Byung, 2003; Huhns, 2002). In this paper, we try to integrate agent technology with web services with the purpose of overcoming such limitations. By so doing we seek to take advantage of the flexibility, inter-operability and extensibility of web services to illustrate feasibility in communicating with multiple legacy systems. 2.4. Related work In recent years, there have been a number of players in the securities markets to develop STP systems as well as deliver risk management and other competitive advantages. Omgeo has developed the solutions to identify trade components or trade sides that have been in a particular status for a defined period of time and provide appropriate resolutions (www.omgeo.com). SmartStream has enabled unique integration of matching and exception management for multi-product types (www.smartstream-md.com). SunGard offers exception management automation throughout the lifecycle of a transaction. Though such companies have delivered exception solutions in their STP products, the mechanism of how to detect and resolve exceptions in securities transactions has not been clearly investigated. Furthermore, most approaches lack collaborative decision-making in the exception reconciliation process, which is crucial to exception management as a kind of collaborative process within financial institutions involved in the trade lifecycle.
3. Exception analysis
traded and the market through which securities are traded. The vast majority of securities are traded on one of the major exchanges and cleared through the Central Securities Depository (CSD). For the purpose of simplifying the discussion, we focus on the transactions of securities clearing through the CSD. The general lifecycle of securities transactions consists of several steps described in Table 1. Based on the investigation off possible exceptions that occur in securities transactions (Simmons, 2001; Wang, Wang, Wan & Xu, 2003), it is found most problems are related to trade details, trade agreements, and settlement instructions (SIs), the details of which are described in Sections 3.1 – 3.3. Accordingly, we initiate our exception management solution from the monitoring of the three points in the trade lifecycle, as outlined in Fig. 1. For ease of understanding, the description is from the perspective of the securities trading organizations (STO), which is a collective term describing those who reside within the securities marketplace, namely traders and market makers, who sell or buy securities from investors, agents or other STOs. 3.1. Exceptions in trade details Some operational risks can arise as a result of trading error and trade recording error. For instance, a trader deals a trade at a price that is significantly different from the market price, or a trade has been captured with some unusual components (e.g. value date on a public holiday, incorrect calculation of trade cash value, missing custodian details). Trade recording error usually occurs by the trader when entering trade details to the trade system or when writing the details of a trade, or by middle or back office personnel inputting trades manually into the settlement system. The consequence of failing to identify, investigate and resolve such errors early in the trade lifecycle may mean that resolution may well take considerably longer and risks increase.
Table 1 General steps in securities transaction Order placement
The investor places an order via the broker to buy or sell some specific securities Trade execution The trader or market maker executes the order Trade agreement The trade parties review and confirm the trade details Trade clearance The clearing company defines net settlement obligation and assigns responsibility for effecting settlement Settlement instruction The trade parties send settlement instructions (SIs) to their custodiansa Payment & delivery The trade is settled by exchanging securities and cashes between the trade parties a
Trading of securities is a regulated process. The process can be different depending on the type of security being
441
A custodian is an organization that specialises in holding securities and (usually) cash and effecting movements of securities and cash on behalf of its account holders, e.g. CSD.
442
M. Wang et al. / Expert Systems with Applications 27 (2004) 439–450
Fig. 1. Trade lifecycle with monitoring points.
3.2. Exceptions in trade agreements
4.1. Deployment of intelligent agents
Trade agreement is to gain agreement of the trade details between the parties to a trade as soon as possible after the trade is executed. In modern settlement systems, the issuance of trade confirmation can usually be automated. However, this does not necessarily result in the issuer (e.g. the STO) being certain that the trade has been agreed with the counterparty. On the one hand, the issuer of the trade confirmation hopes that the recipient will check the detail upon receipt; however, it is not always the case. Sometimes the counterparty cannot recognize the trade due to language problems or disordered characters, or has not acted upon matching advice in a reasonable timeframe, or has failed to receive or reply to the agreement due to a transmission error (GSCS Benchmarks, 2002).
Before applying multi-agent technology into exception resolution, we need to decompose the process of exception management into several autonomous stages, where each agent is delegated a particular task to exhibit its goal-oriented and reactive behavior, and cooperate with others to pursue their goals. The process of exception management usually consists of the stages of data collection, exception identification, exception diagnosis, and exception resolution. Accordingly, the agent hierarchy for exception management is outlined in Fig. 2. The details of these agents are described below. The Interaction agents, such as trading interaction agent and settlement interaction agent, work as a bridge between our exception management system and the existing securities transaction systems, such as the trading system and settlement system. They convert legacy trade data into web service messages and convert web service messages into legacy messages when feeding back. Several kinds of trade data related to possible exceptions are required to collect for monitoring activities, e.g. trade details, trade agreement status, SI matching status, and so on. Moreover, such interaction agents also act as an effective bridge between the user and the system. They enable the managers to view the current status of monitoring processes, receive alert messages, read resolution advices, and take automatic resolution actions. Task agents are deployed to perform data monitoring and exception repair activities. The monitoring agents, such as trade details monitoring agent and trade status monitoring agent, are proposed to monitor securities transactions on a trade-by-trade basis. The trade details monitoring agent is to detect any error contained within the details of each trade. If an unusual component in a trade is captured, the trade will be sent to the diagnostic agent for further investigation. The trade status monitoring agent is applied to keep watch on the status of securities transactions. Those un-agreed confirmations, outstanding confirmations, and denied confirmations will be transmitted to the diagnostic agent for further investigation. When receiving the output from monitoring agents, the diagnostic agent will start its diagnosing process to investigate the nature of problems. This agent may conduct analysis on exception reports from monitoring agents
3.3. Exceptions in settlement instructions The matching of seller’s and buyer’s trade details is, in many cases, effected through two routes, namely trade agreement and settlement instruction (SI) matching. These two exercises are similar, but typically the time may be different. Trade agreement is necessary immediately after trade execution, and SI matching is effected between trade execution and value date. The possible exceptions related to SI matching are similar with the exceptions occurring in trade agreements. In order to avoid settlement failures, it is vitally important to timely identify abnormal SIs, such as unmatched instructions, pending instructions, and instruction advisories.
4. System design for exception management The analysis and design of a novel agent-based business exception management system is described in this section. The complex exception management is delegated to a society of autonomous problem solving agents, which behave on behalf of users involved in exception management. These agents are wrapped as web services, and communicate with each other as well as interact with legacy business systems for necessary data exchange.
M. Wang et al. / Expert Systems with Applications 27 (2004) 439–450
443
Fig. 2. Agent hierarchy for exception management.
and require additional information, if necessary, to examine the problems. Based on the report from the diagnostic agent, the resolution agent may take some initiatives to resolve the problem. Of course, we can only automate the solutions for those exceptions that occur with a high degree of frequency. While automation is the key to ‘de-risking’ the process, skilled human input still remains vital. If human intervention is required, the resolution agent will send a message to an operation-specialist’s desktop. The repository agent plays an important role in our system. Although there is no need for centralized storage of all knowledge regarding exception management, there could be one consistent knowledge repository that maintains and integrates all information related to the monitoring and analysis tasks. In this way, the various agents that make up the system can exchange knowledge regarding entities involved. In our approach, the repository agent may contain and manage several kinds of information, e.g. real time trade data for monitoring, reports for exceptions that have been detected, exception reconciliation status, etc. Such shared information about securities transactions and exceptions may form an important base for agents’ collaboration in exception management. 4.2. System architecture Exception-management in securities transactions is to track the predictable events of processing a trade throughout its lifecycle, and identify and subsequently resolve errors. We can reengineer existing trading and settlement systems to support exception management functions, or develop an independent exception management system to link with existing applications through which a trade would pass during its lifecycle. The existing applications are distributed in various companies, e.g. trading company and clearing company. Our work is to fundamentally use internal resources to build software capabilities to interact with
legacy systems. Relevant data are extracted from existing trading and settlement systems into the exception management system to perform monitoring of securities transactions; the resolutions for identified exceptions will be sent back to trading and settlement systems to repair such exceptions. Based on the deployment of intelligent agents in Section 4.1, we outline the architecture of our web-service agent based exception management system in Fig. 3, in which a society of intelligent agents wrapped as web services is proposed to provide a set of services for exception management in securities trading. As related before, all these web-service agents work autonomously and collaboratively via the Internet. Each agent focuses on its particular task such as data communication, exception monitoring, diagnosing, and resolution, without inventions from outside. When a monitoring agent captures a possible exception, the exception report will be issued to the diagnostic agent for further diagnosis and subsequent reconciliation by the resolution agent. By drawing on other agents’ knowledge and capabilities, agents can overcome their inherent bounds of intelligence and work collaboratively to pursue their goals. Interaction among web-service agents is set up on lower-level data communication, as well as control information with semantic and knowledge. The most popular language for agent communication is Knowledge Query and Manipulation Language (KQML). Recent research has focused on the use of XML (Extensible Markup Language) in agent communication (Glushko, Tenenbaum & Meltzer, 1999). Web services use the popular Internet standard technologies, such as XML, Simple Object Access Protocol (SOAP) and HTTP, to increase compatibility of the system. SOAP is the most common network communication protocol between software services. SOAP messages are represented by using XML, and can be sent over a transport layer, such as HTTP
444
M. Wang et al. / Expert Systems with Applications 27 (2004) 439–450
Fig. 3. System architecture.
and SMTP. Furthermore, STPML is adopted as the information model to represent securities transaction data. STPML is the Straight Through Processing Markup Language. It is an XML message specification designed for the financial securities trading industry to meet the requirements of STP (Financial Models Company, 2003). STPML schema enables software agents to understand the contents of messages correctly and consistently. 4.3. Agent structure The behaviour of an agent is based on an internal model of the agent consisting of a knowledge base, operational facilities, and a correspondence between the external application domains. Generally, developing of an agent considers an agent knowledge base, its operational facilities and its external interface. Knowledge is required by each agent to perform its internal and external activities. It consists of knowledge for particular tasks, resource status, information about other agents, etc. The operational facilities execute different functions and provide collaboration with other agents; they are the central control and action part of an agent. A rule engine is usually an important operational facility, which provides a means for applying simple, rules-based reasoning to emergence of new facts in the agent’s world and for using this reasoning capability to decide what the agent should do next. The external interface envelopes an agent and provides access to it via a well-defined interface, and it is also the primary conduit for communication between agents.
In a multi-agent system, it is essential to design a set of autonomous type of behaviours for the agent class, including reactive, proactive, and cooperative behaviour. Both autonomous and semi-autonomous agents rely on knowledge or data, which is the agent’s perception or awareness of its environment and knowledge for problem solving. Various kinds of intelligence are supported by this kind of data. It usually concerns rules, which are the user’s expression of preference of policies followed by the agent to complete its task (Caglayan & Harrison, 1997). These rules may form an important part of knowledge base for software agents to perform delegated tasks on the user’s behalf (Liu, Sun, Dix & Narasipuram, 2001). The approach to manipulate business rules is illustrated through an example about capturing rules related to pending trade agreements. Pending trade agreements are those trade agreements that have been issued by STOs but not replied to or confirmed by the counterparty within a reasonable timeframe. Pending trade agreements usually arise from: (1) the trade agreement message has not been issued to the counterparty, (2) the trade agreement has been sent out but not received by the counterparty due to a transmission problem, and (3) the counterparty did not act upon confirming the trade agreement after they received it. In more details, the transmission problem may be caused by an incorrect address of the counterparty or system error in issuing the agreement message. The counterparty may ignore the trade agreement because they cannot recognize it or they forget to reply to it timely. Based on this analysis, we capture the rules for intelligent agents to monitor,
M. Wang et al. / Expert Systems with Applications 27 (2004) 439–450
diagnose and resolve exceptions arising from pending trade agreement; a part of rules in this example is listed below. IF a trade agreement has not been responded within a predefined timeframe THEN the trade agreement is recorded as pending exception IF a trade agreement is pending THEN check the transmission record of this trade agreement IF a trade agreement is pending AND recorded as transmission failure THEN check the transmission failure report IF a trade agreement is pending AND recorded as transmission failure due to system error THEN report to the manager AND send the trade agreement again IF a trade agreement is pending AND recorded as transmission failure due to incorrect address THEN check the address AND send the trade agreement again
5. System implementation Our web-service agents provide exception management services on the Internet. The web-service agents have been developed using Java Web Services Development Package (JWSDP) (Java.sun.com, 2003). JWSDP brings together a set of Java APIs for XML-based Java applications by supporting key XML standards such as SOAP, WSDL and UDDI. These APIs and their reference implements are bundled together with a set of runtime tools to form a JWSDP. As we described before, the communication among Table 2 Sample code: sending and receiving SOAP object by JAXM … SOAPConnectionFactory scf ¼ SOAPConnectionFactory.newInstance( ); Con ¼ scf.createConnection( ); MessageFactory mf ¼ MessageFactory.newInstance( ); //Create a message from the message factory. SOAPMessage msg ¼ mf.createMessage( ); //required part of the message as per the SOAP 1.1 specification. SOAPPart sp ¼ msg.getSOAPPart( ); //retrieve the envelope from the soap part to start building the soap message. SOAPEnvelope envelope ¼ sp.getEnvelope( ); Create_XML( ); StreamSource ssrc ¼ new StreamSource(new FileInputStream(xml_path)); sp.setContent(ssrc); msg.saveChanges( ); URL urlEndpoint ¼ new URL(to); //Send the message to the provider using the connection and receive the response. SOAPMessage reply ¼ con.call(msg, urlEndpoint); …
445
Table 3 Sample code: a JESS rule … (defrule check_missing_item (trade (trade_id ?n) (security_id ?m) (price ?p) (quantity ?q) (custodian_id ?c) (trade_date ?t ?t1) (value_date ?v ?v1)) ¼. (if (or (eq ?m nil) (eq ?p nil) (eq ?q nil) (eq ?c nil) (eq ?t nil) (eq ?t1 nil) (eq ?v nil) (eq?v1 nil)) then (assert (item_missing ?n)) ) ) …
agents are through SOAP, which is done by Java API for XML Messaging (JAXM). Such JAXM messages follow SOAP standards, which prescribe the format for messages and specify the things that are required, optional, or not allowed. Table 2 shows the sample code for sending messages and receiving responses by JAXM. Our web-service agents are able to detect exceptions and generate error reports and resolution reports by JESS rules. Java Expert system Shell and Scripting language (JESS) is a rule engine and scripting environment written entirely in Java language (JESS, 2003). In our system, each agent contains a JESS rule set for reasoning. Table 3 shows an example of JESS rule and Table 4 is a sample code to show how to load a JESS rule set into an agent. The reasoning results are asserted JESS facts. An agent can send such facts to other agents, by wrapping them to XML and SOAP messages. Table 5 is a sample code for marshalling XML instance documents by Java Architecture for XML Binding (JAXB). This XML file will be sent by JAXM. After our web-service agents have been set up, they should be published on the Web. The Web Services Description Language (WSDL) specification is used to describe and publish web-service agents in a standard way. Table 6 is an example of the WSDL for an agent. The universal description, discovery and integration (UDDI) is used to create and to implement a directory of the webservice agents. Table 7 illustrates a sample using UDDI. Fig. 4 below shows an interface screen of the prototype. The background window is a clearing Table 4 Sample code: calling a JESS rule import jess.*; … try{ Rete rete ¼ new Rete( ); rete.executeCommand(“(batch d:/jess_rule_ex/rd-1.clp)”); } catch (JessException re) { Re.printStackTrace( ); }…
446
M. Wang et al. / Expert Systems with Applications 27 (2004) 439–450
Table 5 Sample code: marshalling XML instance documents by JAXB
Table 6 WSDL
… //JAXBContext instance is created for handling classes generated in monitoring_agent. JAXBContext jc ¼ JAXBContext.newInstance(“monitoring_agent”); ObjectFactory objFactory ¼ new ObjectFactory( ); ExceptionReporter ¼ objFactory.createExceptionReport ( ); Er.setExceptionReport(exception_detail); Er.setExceptionDate(Calendar.getInstance( )); Items items ¼ objFactory.createItems( ); //get a reference to the ItemType list List itemList ¼ items.getItem( ); itemList.add(createItemType(objFactory, tradeID, securityID, custodianID, currency, New BigInteger(Integer.toString(quantity)), New BigDecimal(price), New BigDecimal(netValue), Calendar.getInstance( ), Calendar.getInstance( )); … public static Items.ItemType createItemType(ObjectFactory objFactory, String tradeID, String securityID, … String partNum) … //create an empty ItemType object Items.ItemType itemType ¼ objFactory.createItemsItemType(); //set properties on it itemType.setTradeId(tradeID); itemType.setSecurityId(securityID); … return itemType; }
, ?xml version ¼ ’1.0’ encoding ¼ ’UTF-8’? . ,definitions name ¼ ’MonitoringAgent’ targetNamespace ¼ ’MonitoringAgent’ xmlns ¼ ’http://schema.xmlsoap.org/wsdl/’ xmlns:SOAP-ENC ¼ ’http://schemas.xmlsoap.org/soap/encoding/’ xmlns:soap ¼ ’http://schemas.xmlsoap.org/wsdl/soap/’ xmlns:tns ¼ ’ MonitoringAgent’ xmlns:xsd ¼ ’http://www.w3.org/2001/XMLSchema’ xmlns:xsdl ¼ ’MonitoringAgent-xsd’ xmlns:xsi ¼ ’http://www.w3.org/2001/XMLSchema-instance’ . ,types . , schema targetNamespace ¼ ’MonitoringAgent-xsd’ xmlns ¼ ’http://www.w3.org/2001/XMLSchema’ xmlns:wsdl ¼ ’http://schema.xmlsoap.org/wsdl/’ . , complexType name ¼ ’TradeDetail’ . , all . , element name ¼ ’tradeID’ type ¼ ’xsd:string’/. , element name ¼ ’tradeDate’ type ¼ ’xsd:date’/. , element name ¼ ’security_id’ type ¼ ’xsd:string’/. , element name ¼ ’quantities’ type ¼ ’xsd:positiveInteger’/. , element name ¼ ’prices’ type ¼ ’xsd:decimal’/. … , /all . , /complexType . … *** , /schema . , /types . , message name ¼ ’request’ . ,part name ¼ ’order’ type ¼ ’xsdl:TradeDetail’/. , /message . …
company’s regular interface window. We did not put any additional artifact into such existing interfaces. When an exception is detected, an additional window (the small window at the left hand side) will pop up to display the exception report. The user can read the resolution advice by clicking the ‘Resolution Advice’ button in the exception report window. A ‘Resolution Advice’ window will pop up, which is shown in the right hand. As to resolution advice, the user may accept it and take automatic repair action by clicking ‘Yes’, or ignore it and take action through other ways.
Table 7 UDDI
6. System evaluation In this section the evaluation of a prototype system is demonstrated. We developed a use case and subsequently demonstrated the system to potential system users. Both quantitative and qualitative measures were applied to judge user satisfaction and elicit feedback.
, businessList generic ¼ ’2.0’ operator ¼ ’uddi.sourceOperator’ truncated ¼ ’false’ xmlns: ¼ ’urn:uddi-org:api_v2’ . , businessInfos . , businessInfo businessKey ¼ ’C0213213-777D…’ . , name . CityU IS , /name . , description . City University of Hong Kong ,/description . , serviceInfos . , serviceInfo serviceKey ¼ ’D900123-777D…’ . , name . MonitoringAgent , /name . , description . It is used to detect error… , /description . , identifierBag . … , /identifierBag . , /serviceInfo . , serviceInfo serviceKey ¼ ’D900125-777D…’ . , name . ResolutionAgent , /name . , description . … , /description . , identifierBag . … , /identifierBag . , /serviceInfo . … , /serviceInfos . , /businessInfo . , /businessInfos . ,/businessList .
M. Wang et al. / Expert Systems with Applications 27 (2004) 439–450
447
Fig. 4. Prototype.
6.1. Use case In order to demonstrate the effectiveness of our approach and illustrate how these agents work together to reach the goal of exception management, the process of their collaboration in the system is
illustrated in the following case. As illustrated in Fig. 5, the settlement interaction agent receives trade data from the settlement system, converts such data to the web service messages, and passes them to the destination web service based on the UDDI (step 1). Such autonomous activity is directed by the goal of this agent to
Fig. 5. Collaboration within web-service agents.
448
M. Wang et al. / Expert Systems with Applications 27 (2004) 439–450
communicate data for exception monitoring. The received data will be stored into a central repository, and will be released after this monitoring session is finished. When new data arrive, a notice will be sent to the monitoring agent to activate its monitoring activities (step 2). In this case, the trade status monitoring agent detects an pending trade agreement, i.e. a trade that has not been agreed by trade parties in a predefined time frame, and an exception report is issued to the manager (step 3) as well as to the diagnostic agent (step 4). At the same time, this trade exception is also sent to the central repository for further attention (step 5). Upon receiving the exception report from the monitoring agent, the diagnostic agent is activated to examine the problem. Data related to this trade are obtained from the central repository (step 6). Based on its diagnosing knowledge, the diagnostic agent decides to check the details of the agreement process of this trade, e.g. transmission record of the trade agreement (step 7, 8). It is found that the trade agreement has been sent out successfully, but no response from the counterparty in a predefined time. According to such diagnostic report from the diagnostic agent (step 9), the resolution agent may advise the settlement manager to send a reminder message to the counterparty (step 11), as shown in Fig. 5. If the resolution advice is validated by the manager (step 12), this repair action will be taken as soon as possible to settle the problem, and a resolution report will be generated subsequently (step 13). Of course, if an exception has been detected unresolved for a period of time or the trade in exceptions is closing to the value date, a warning message will be directly sent to the manager for instant repair. This kind of behaviour is supported by the capability of agents to continuously perceive the environment and react to changes from the environment. During the reconciliation process, exception related information, such as exception reports, diagnostic reports, and resolution reports, will be stored into the central repository for further analysis and evaluation (step 5, 10, 13).
6.2. Demonstration feedback End-user satisfaction is one of several relevant measures of information systems success (Doll & Torkzadeh, 1988). A successful interaction with the information system can be measured in terms of user satisfaction (Delone & McLean, 1992). User satisfaction is probably the most studied construct in information systems research. Despite over two decades of research, reported results have been inconclusive and sometimes contradictory, and the relationship between user satisfaction and information systems success remains elusive (Rai, Lang & Welker, 2002). A demonstration was conducted to elicit end-user satisfaction regarding our exception management prototype. User satisfaction with the prototype system was measured using the 12-item instrument developed by (Doll & Torkzadeh, 1988) that has subsequently been applied in numerous studies (Etezadiamoli & Farhoomand, 1991; Marsden, Pakath, & Wibowo, 2002; Raymond & Bergeron, 1992; Whyte, Bytheway & Edwards, 1997). Targeted for an end user computing environment, their instrument identifies five components of user satisfaction: (1) content, (2) accuracy, (3) format, (4) ease of use, and (5) timeliness. Subjects were asked to rank their satisfaction on a scale from 1 to 5, where 1 represents Strongly Disagree, 3 is the neutral point and 5 represents Strongly Agree. The demonstration was conducted in August 2003 for 36 subjects (14 female and 22 male) who were undergraduate students from the Faculty of Business in a major university in Hong Kong. During the demonstration, the subjects were introduced to prototype capabilities relating to exception management in security trading. Prototype system simulations were demonstrated. At the conclusion of the demonstration, subject feedback was collected. Questionnaires elicited demographic data, basic knowledge on security trading and security trading process, satisfaction and usage intentions. The reliability of the 12-item instrument of user satisfaction was 0.89. The reliability (alpha) of each
Fig. 6. User satisfaction.
M. Wang et al. / Expert Systems with Applications 27 (2004) 439–450
449
Table 8 User feedback Answer
User friendly
Credibility
Professional advice
Efficiency
Stability
Expectation
If you have a chance to use a system with the features similar to our prototype, would you like to use it? YES (32 subjects) NO (4 subjects)
Making system easy to understand and use. The information provided is quite clear.
Providing accurate and timely data can fulfill users’ needs in terms of security information.
The professional advice for errors can help users to reduce data loss.
Improve the efficiency of security trading
Providing stable system functions for the end-user.
For future expectation of exception handling.
þ 28 23
þ 16 23
þ21 22
þ9 22
þ6 21
þ3 0
þ , Positive comment; 2, negative comment.
individual construct was above 0.70. Fully 89 and 83% of the subjects reported that they had basic knowledge about security trading and security trading processes, respectively. However, their previous knowledge about security trading and security trading processes did not affect their perceptions regarding satisfaction ðP . 0:5Þ: The mean of overall satisfaction and the five constructs are all above 3.3. The details are illustrated in Fig. 6. We also collected subjects’ perceptions based on the question, If you have a chance to use a system with the features similar to our prototype, would you like to use it? (Please indicate YES or NO, and give at least three reasons). In total, 63 positive comments were received from the subjects who answered YES to the question and 11 negative comments were received from the subjects who said NO. The comments were categorized into six constructs: User Friendly, Credibility, Professional Advice, Efficiency, Stability and Expectation. Results are presented in Table 8. In conclusion, the data collected show very positive results. They illustrate satisfaction with our prototype system capabilities regarding intelligent exception management in security trading. Most of the subjects would like to use a system with the prototype features. They think that the system’s exception management facilities are able to give professional advice for detecting errors and reduce data loss as well as provide accurate and timely data fulfilling users’ security information needs to overall improve the efficiency of security trading. Those who answered ‘No’ expressed that either they lacked interest in security trading or that the human-computer interface was deficient, which was outside the scope of our research.
advantages for exception management systems: † System integration: Through the interaction agents with web service standards, the exception management system is able to integrate with legacy business applications. † Intelligence: Complex business problems can be identified and diagnosed by a number of intelligent agents through their properties, such as autonomy, reactivity, proactivity, and social ability. † Scalability: It is easy to add more business functionalities into our system by adding more web-service agents. † Reusability: The proposed architecture and web-service agents are reusable by other business applications. Through the initial evaluation studies, the developed system is found to be able to provide effective services for exception management in securities trading, and users appreciate provided features. Although the prototype does not precisely reflect real-world situations, the results of this work reveal the success in using web-service-agent-based decision support systems for exception management in business activities.
Acknowledgements This research is supported by a UGC CERG research grant (No.9040823) from the Hong Kong SAR Government.
References 7. Conclusions This paper illustrates the benefits offered through intelligent web-service agents with decision support systems for exception management in securities trading. By integrating agent technology with web services to make use of the advantages from both, this approach leads to more intelligence, flexibility and collaboration in business exception management. In sum, our approach has several
Bui, T., & Lee, J. (1999). An agent-based framework for building decision support systems. Decision Support Systems, 25(3), 225–237. Byung, K. O. (2003). Meta web service: building web-based open decision support system based on web services. Expert Systems with Applications, 24, 375–389. Caglayan, A., & Harrison, C. (1997). Agent sourcebook: a complete guide to desktop, internet, and intranet agents. New York: Wiley. Delone, W. H., & McLean, E. R. (1992). Information Systems Success: The Quest for the Dependent Variable. Information Systems Research, 3(1), 60–85.
450
M. Wang et al. / Expert Systems with Applications 27 (2004) 439–450
Doll, W. J., & Torkzadeh, G. (1988). The measurement of end-user computing satisfaction. MIS Quarterly, 12(2), 259–274. Etezadiamoli, J., & Farhoomand, A. F. (1991). On end-user computing satisfaction. MIS Quarterly, 15(1), 1–4. Financial Models Company (2003). What is STPML? http://www.stpml. org. Glushko, R. J., Tenenbaum, J. M., & Meltzer, B. (1999). An XML framework for agent-based e-commerce. Communications of the ACM, 42, 106 –114. GSCS Benchmarks, (2002). Corporate actions: dangerous events. The 2002 Review of Major Markets, 20– 24. Guerra, A (2002). Exception management: The safety net you’ve been looking for? Wall Street and Technology Online, URL: http://www. wallstreetandtech.com. Huhns, M. N. (2002). Agents as Web services. IEEE Internet computing, 6(4), 93–95. Java.sun.com (2003). Java Web Services Developer Pack 1.2, http://java. sun.com/webservices/webservicespack.html Jennings, N. R., Faratin, P., Norman, T. J., O’Brien, P., & Odgers, B. (2000). Autonomous agents for business process management. International Journal of Applied Artificial Intelligence, 14(2), 145– 189. JESS (2003). The rule engine for the Javae platform. http://herzberg.ca. sandia.gov/jess. Klein, M., & Dellarocas, C. (2000). A knowledge-based approach to handling exceptions in workflow systems. Computer Supported Cooperative Work, 9(3–4), 399 –412. Kumar, V., & David, G. (2000). Global straight through processing. The Evolution Continues, Electronic Data Systems Publication. Liu, K., Sun, L., Dix, A., & Narasipuram, M. (2001). Norm based agency for designing collaborative information systems. Information Systems Journal, 11(3), 229–247. Marsden, J. R., Pakath, R., & Wibowo, K. (2002). Decision making under time pressure with different information sources and performancebased financial incentives—Part 1. Decision Support Systems, 34(1), 75–97. Orwig, R., Chen, H., Vogel, D., & Nunamaker, J. (1996). A multi-agent view of strategic planning using group support systems and artificial intelligence. Group Decision and Negotiation, 5(1), 37–59. Paulson, B., Kim, K (1999). http://www.stanford.edu/group/CIFE/ cifeprojectsummary.html, http://www.stanford.edu/group/CIFE/ cifeprojectsummary.html
Pinson, S. D., Louca, J. A., & Moraitis, P. (1997). A distributed decision support system for strategic planning. Decision Support Systems, 20(1), 35 –51. Rai, A., Lang, S. S., & Welker, R. B. (2002). Assessing the validity of IS success models: An empirical test and theoretical analysis. Information Systems Research, 13(1), 50 –69. Raymond, L., Bergeron, F., & Personal, D. S. S. (1992). Success in small enterprises. Information Management, 22(5), 301– 308. Simmons, M. (2001). Securities operations: a guide to trade and position management. New York: Wiley. US Securities and Exchange Commission (2001). Settling securities trades in one day, T þ 1, http://www.sec.gov. Wall Street and Technology Online, (2000). Wall Street and Technology Online Automating exception management in securities, http://www. wallstreetandtech.com. Wang, H. (1997). Intelligent agent-assisted decision support systems: integration of knowledge discovery, knowledge analysis, and group decision support. Expert Systems with Applications, 12(3), 323 –335. Wang, H., Mylopoulos, J., & Liao, S. (2002). Intelligent agents and financial risk monitoring systems. Communications of the ACM, 45(3), 83 –88. Wang, H., & Wang, C. (1997). Intelligent agents in the nuclear industry. IEEE Computer, 30(11), 28–34. Wang, M., & Wang, H. (2002). Intelligent agent supported flexible workflow monitoring system. Lecture Notes in Computer Science, 2348, 787–791. Wang, M., Wang, H., Wan, K. K., & Xu, D. (2003). The design of intelligent agents for exception management in securities trading. Proceeding of Americas Conference on Information Systems (AMCIS 2003), Tempa, US. Wang, M., Wang, H., Wan, K. K., & Xu, D. (2004). Knowledge-based exception handling in securities transactions. Proceeding of Hawaii International Conference on System Science (HICSS-37), Hawaii, US. Whyte, G., Bytheway, A., & Edwards, C. (1997). Understanding user perceptions of information systems success. Journal of Strategic Information Systems, 6(1), 35–68. Wooldridge, M. (2002). An introduction to multiagent systems. Chichester: Wiley. Wooldridge, M., & Jennings, N. (1995). Intelligent agents: theory and practice. The Knowledge Engineering Review, 10(2), 115– 152.
