Knowledge-based Exception Handling in Securities Transactions*

Proceedings of the 37th Hawaii International Conference on System Sciences - 2004

Knowledge-based Exception Handling in Securities Transactions* Minhong Wang, Huaiqing Wang, Kwok Kit Wan and Dongming Xu Department of Information Systems, City University of Hong Kong, Hong Kong {iswmh, iswang, iskk, isxu}@cityu.edu.hk Abstract* With rising trading volumes and increasing risks in securities transactions, the securities industry is making an effort to achieve straight through processing to shorten the trade lifecycle and minimize transaction risk. While attempting to shorten the settlement cycle, the trade information must be passed within the trade lifecycle in a timely and accurate fashion. Exception handling is critical to make sure trades that give rise to exceptions or trades containing errors need to be detected and reconciled in compressed timescales. In order for a knowledge level solution for exception handling, the technology of intelligent agents is applied in this research. Intelligent agents with their knowledge base and properties of autonomy, activity and proactivity are well suited for business exception handling. Based on analysis on exceptions occurred in securities transactions and process of exception reconciliation, several types of intelligent agents are proposed and a multi-agent framework is presented for exception handling in securities trading. Furthermore, business knowledge such as business rules and strategies are extracted from securities trading and settlement practice, and applied to the design of individual agents to make them act autonomously and collaboratively to fulfil the goal of exception reconciliation. By separating business logic from business model, such business rules approach can enhance the flexibility and adaptability of our agent-based exception handling system.

1. Introduction In today’s fast moving market the financial institutions are facing what many consider being its great challenge - the planned transition to shortened settlement cycle and much-desired capability for Straight Through Processing (STP) of securities trades [1]. However, the prospect of a compressed settlement cycle also has a fundamental impact on *

This research is supported by a Strategic Research Grant (7001309) from City University of Hong Kong.

operations risk management. This has led to some considerable attention not merely on the processing of fully automated trade and settlement cycle, but also on the automation of all processes required for identifying and fixing any exceptions reported in the cycle [2]. It requires participants to enable an exception-based process to achieve some level of STP, which embodies early identification of errors for timely resolution. Efforts are attempted to make in some STP systems to deliver operations risk management and competitive advantages as they seek to achieve shortened settlement cycle. However, the major issue of such risk management has not been adequately addressed, and the mechanism of automating exception handling is still under investigation. In this paper we focus on exception handling in securities transactions, which aims to automate the identification and resolution of exceptions to assist securities industry to gain quicker competitive advantage. With a view to providing a knowledgebased solution for exception handling in securities trading, we propose to apply the technology of intelligent agents to deal with the representative abnormal transactions throughout the trade lifecycle. Given specific knowledge and capabilities, intelligent agents are capable of dealing with complex problems and vast amounts of information collaboratively in dynamic and unpredictable environment. Moreover, based on previous research and experimental results, some properties of intelligent agents, such as reactive and proactive behaviors, are directly applicable for tracking abnormal transactions in a systematic and goal-driven manner [3, 4, 5]. After the analysis on possible exceptions in securities transactions and resolution to such problems, a society of intelligent agent is proposed for the STP environment. Data acquisition agents are responsible for collecting data of securities transactions. Based on such data, monitoring agents may keep track on the transaction processes. When an exception is detected, a diagnostic agent will be initiated and attempt to identify the problems. According to the output from the diagnostic agent, a resolution agent will take some initiatives to resolve problems. In order for a

0-7695-2056-1/04 $17.00 (C) 2004 IEEE

1


knowledge level resolution, such intelligent agents are developed with specific knowledge such as business rules and business strategies to reason about business actions for exception handling. Business rules are extracted from securities trading and settlement practice, and applied to the design of individual agents to make them act autonomously to fulfil the organizational goals. By separating business logic from business model, such business rules approach can enhance the flexibility and adaptability of our agent-based exception handling solution. The rest of the paper is organized as the follows. Section 2 briefly reviews the relevant literature on exception handling in securities trading, and some issues on intelligent agent theory. Section 3 conducts some analysis on exceptions that usually occur in securities transaction practice. Based on such analysis, the approach of applying intelligent agents into exception handling is investigated in section 4. Following this approach, we develop a multi-agent system framework for exception handling in section 5. In order to apply business rules to support knowledge based exception reconciliation, some issues about the development of rule-base agents are also illustrated. Finally, section 6 addresses some conclusions as well as the future work.

2. Background 2.1. Securities transactions and exception handling 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. While every industry undergoes an occasional major change in the methods it employs to satisfy customer and market demands, the financial services industry is presently in the throes of STP to achieve the end-toend automation of security trading process from order to settlement [1]. However, while attempting to achieve full automation of trade throughput, care must be taken to ensure that exceptional trades that give rise to risk, or trades containing errors, are detected and reconciled at the earliest opportunity, preferably prior to communicating details to the outside world [2].

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 four fifths of back-office overhead [6]. STP is only achievable when the trade information is passed within the trade lifecycle in a timely and accurate fashion. A business case study commissioned by the U.S. Securities Industry Association (SIA) and prepared by the Capital Markets Company and Accenture has suggested the securities industry to apply automated exception processing and risk management in securities transactions [7]. Furthermore, a compressed settlement cycle in cross-border trades has a fundamental impact on operations risk management. If something goes wrong with a transaction, back office will have limited time to identify, research, mend, and reprocess it before settlement. Yet, because exceptions frequently result from internal mistakes or other causes, they can often be identified and rectified before counterparty or client is aware of their existence. This has led to automating the management and reprocessing of problem transactions as they arise. Business knowledge about exception monitoring and reconciliation extracted from securities trading and settlement practice will play a critical role in achieve such kind of automation of exception handling. However, in recent years, the major issue of risk management in securities transactions has not been adequately addressed. “The market gets confused when they talk about exception management because they are usually talking about people being involved in the resolution [8].” Some exception management systems simply takes a faulty trade which has been kicked out of the STP flow and route it to an operations professional for examination and repair. Some of the more sophisticated products on the market will have a list of remedies which correspond to each of the likely failures. “As those things get automated and more reliable, exception resolution will more quickly move from humans to software (Guerra 2002).” Nowadays a number of players in the securities markets have explored STP systems as well as delivered risk management to achieve efficient transactions and shortened settlement cycle, such as Omgeo (www.omgeo.com), SmartStream (www.smartstream-md.com), SunGard (www.epic.sungard.com), and etc. Though such companies have delivered exception solutions in their STP products, the mechanism of how to diagnose and resolve exceptions in securities transactions has not

0-7695-2056-1/04 $17.00 (C) 2004 IEEE

2


been clearly investigated. Moreover, since exceptional situations are usually very complicated, more consideration towards business knowledge and business strategy from trading and settlement practice is needed to be taken in their approaches. Furthermore, their approaches lack collaborative decision-making in the exception reconciliation process, crucial for the exception handling as a kind of collaborative process within financial institutions involved in the trade lifecycle.

2.2. Intelligent agents Intelligent agents are used to denote a softwarebased system that enjoys such properties as autonomy, co-operativity, reactivity, pro-activity and mobility [9]. Actually, an agent is a computer system that is situated in some environment, and that is capable of autonomous action in order to meet its design objectives [10]. A generic agent has a set of goals (intensions), certain capabilities to perform actions, and some knowledge (or beliefs) about its environment. 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. A multi-agent system consists of a group of agents, interacting with one another to collectively achieve their goals. By drawing on other agents’ knowledge and capabilities, agents can overcome their inherent bounds of intelligence. The concept of intelligent agents has increasingly become important in artificial intelligence, computer science, and e-commerce. In recent years, there has been considerable growth of interest in the design of a distributed, intelligent society of agents capable of dealing with complex problems and vast amounts of information collaboratively. Since agent technology provides flexible, distributed, and intelligent solutions for business process management, researchers have proposed to design and develop numerous intelligent-agents based systems to support business processes management in dynamic and unpredictable environment. It is proposed to use intelligent agents for business data monitoring, in which intelligent agents are deployed with specific domain knowledge and intermediate on behalf of business analysts by being able to perform limitless, error-free routine calculations and interpretation rapidly to the precise requirements of business managers [3, 4, 5]. Compared with other knowledgebased systems, intelligent agents are more capable of reactive, proactive behaviour, and equipped with social ability in the sense of cooperation, coordination and negotiation. In order to be more

useful in complex real world domains, the agents need to be flexible in terms of their problem solving skills, communication capabilities, and utilization of internal knowledge and data.

3. Exception analysis An exception is anything that translates into stopping the behavior of normal business processes. Exception handling, at its most basic level, is about repairing what is broken. In order to effectively manage risk exposure, the spotlight is increasingly focused on the rapid identification and resolution of failed trades. An exception-management system is one that can track the predictable events of processing a trade throughout its lifecycle, and only when a system knows what is supposed to happen to a trade can it identify errors and subsequently resolved errors. In the following sections we are to analyze the exceptions that usually occur in securities trading and settlement practice and may cause transaction failures. Based on such analysis we will develop a knowledge based exception resolution, in which a society of intelligent agents is deployed with business rules for the automation of exception reconciliation in securities transactions. Trading of securities is a regulated process. The process can be different depending on the type of security being traded and the market through which securities are traded. The vast majority of securities are traded on one of the major exchanges and clear through the Central Securities Depository (CSD). For purpose of simplifying the discussion, we will focus on the transactions of securities clearing through the CSD. The general lifecycle of securities transactions consist of several steps described in Table 1 [2]. The large proportion of exceptions in securities trades is generated in-house by processing mistakes, human error or system-to-system inconsistencies between front and back office [6]. After investigating possible exceptions which may result in failures of securities transactions, we find most problems are related to trade details, trade agreements, and settlement instructions (SIs) described in section 3.1, 3.2, 3.3. In order for easy understanding, the description is from the perspective of the securities trading organizations (STO), which is a collective term that describes those who reside within the securities marketplace, namely traders and market makers, who sell or buy securities from investors, agents or other STOs.

0-7695-2056-1/04 $17.00 (C) 2004 IEEE

3


Table 1. General steps in securities trading Order Placement Trade Execution Trade Agreement Trade Clearance

Settlement Instruction Payment Delivery

&

The investor places an order via the broker to buy or sell some specific securities. The trader or market maker executes the order. The trade parties review and confirm the trade details. The clearing company defines net settlement obligation and assigns responsibility for effecting settlement. The trade parties send settlement instructions (SIs) to their custodians (e.g. CSD). The trade is settled by exchanging securities and cashes between the trade parties.

3.1. Exceptions in trade details Some operational risks can arise as a result of trading error, trade recording error and trade enrichment error. For instance, the 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, such as value date on a public holiday, incorrect calculation of trade cash value, missing custodian details, and so on. Trade recording error usually can occur 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. Though many STOs have adopted this kind of trade validation, this activity is usually executed manually. It is suggested that performing extensive trade validation is only achievable by use of intelligent and efficient systems [2]. By a final check of data contained within a fully enriched trade, we can reduce the possibility of erroneous information being sent to the outside world.

3.2. Exceptions in trade agreements 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 problem or disordered characters, or did not act upon matching advice in a reasonable timeframe, or failed to receive or reply the agreement due to a transmission error [2, 11]. On the other hand, the sheer volume of trading usually precludes STOs from positively investigating whether the counterparty to each trade agrees or disagrees with the trade details. The risk of financial loss cannot be eliminated on trades where it is unknown whether the trade parties agree the trade or trade details.

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. Settlement instructions may be alleged by a counterparty who does not subscribe to a trade agreement mechanism. The possible exceptions related to SI matching have some similarity with exceptions occur in trade agreement. In order to avoid settlement failures, it is vitally important to timely identify abnormal SIs, such as unmatched instructions, pending instructions, and instruction advisories. The instruction advisory may come about in the situation that only the counterparty has issued a SI while no SI issued from the STO to the counterparty.

4. Intelligent agents supported exception handling As noted in section 2.2, intelligent agents equipped with specific domain knowledge and their properties of autonomy, reactivity, pro-activity and social ability are well suited to business monitoring applications that perform limitless, error-free routine calculations and interpretation rapidly to the precise requirements of business managers. In this section, we will illustrate how to apply intelligent agents into securities trading and settlement environment to realize knowledge based solution for exception handling.

0-7695-2056-1/04 $17.00 (C) 2004 IEEE

4


4.1. Knowledge based intelligent agents In a multi-agent system, software agents are proposed to perform some tasks autonomously on the user’s behalf, which means that they can act independently of humans. It is essential to design a set of autonomous type of behaviours for the agent class, including reactive, proactive, and cooperative behavior. Both autonomous and semi-autonomous agents rely on knowledge or data which is the agent’s perception or awareness of its environment. 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 [12]. In order to fulfill the organizational goals and objectives, business rules to conduct business activities play an essential role in governing peoples’ behaviour. These business rules may form an important part of knowledge base for software agents to perform delegated tasks on the user’s behalf [13]. Once the rules are understood, captured and represented in form of logic, they will serve as a basis for building intelligent agents to perform rational activities. Business rules are a formal expression of knowledge or preference. If-then rules have become the most popular form of declarative knowledge representation used in artificial intelligence applications [14]. Knowledge represented as if-then rules is easily understandable, in contrast to knowledge represented in predicate logic. Rules are declarations of the type if then , that means if the is true then the should be executed. The execution control of these rules is done through a separate inference mechanism which tests each rule against existing facts in a working memory, generating new facts in it—or executing some procedural code associated with the rule— when a matching occurs. This process is repeated recursively until a specific goal is reached or there are not any more rules in the rule database that can be triggered.

4.2. Business rules capture Rules statements are a key element in defining the intentions and the needs of the business, as well as an important type of presentation of business knowledge. The difficult thing is how we can capture the business logic in the forms of rules from business practice. Based on the exception analysis on settlement practice described in section 3, we may use fishbone diagrams [15] to capture and identify

rule sets for exception monitoring, analysis and resolution. When completed, the diagram will show the overall result of a rule set at the head and factors contributing to the result as a serious of ribs leading off from a backbone. Each rib may have successive levels of smaller bones, depending on the levels of decomposition needed. Each branch of the structure represents a potential rule, showing how the input values, which are at the tip of the subsidiary bones, are combined to reach the final conclusion. In this research, we may use this kind of fishbone model to identify the possible problems which may lead to exceptions in securities transactions. The approach is illustrated through an example about capturing business rules related to pending trade agreements in Figure 1. Pending trade agreements are those trade agreements that have been issued by STOs but not replied or confirmed by the counterparty within a reasonable timeframe. As outlined in Figure 1, 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, 3) the counterparty did not act upon confirming the trade agreement after they received it. 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 forget to reply it timely. Based on this diagram, we can capture some rules for intelligent agents to monitor, diagnose and resolve exceptions arising from pending trade agreement; a part of rules related to 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

0-7695-2056-1/04 $17.00 (C) 2004 IEEE

5


may be more strategic to submit such exceptions to an operation-specialist to seek human intervention and resolution.

Trade agreement transmission failure

Trade agreement not issued

System error

4.4. Dynamic business rules

Incorrect address Pending trade agreement Trade agreement unrecognizable Trade agreement sent to an incorrect counterparty

Forget to reply Trade agreement not replied

Figure 1. Fishbone diagram: factors for pending trade agreement

4.3. Business strategies in business rules Business rules specify a serious of clear statement about the logic underlying a business, each of which represents a small unit of knowledge. At a high level, business rules could be classified under one or more concerns, such as controlling workflow, reducing business risk, making efficient use of resources and improve customer service [15]. Accordingly, while designing rules for intelligent agents to perform exception handling activities, we may not merely focus on those rules to control monitoring, diagnosing and resolution activities, but also consider some business strategies to improve the efficiency of exception handling. For instance, while the trade details monitoring agent executes validation on trade details, it is not quite efficient to go over all the components in each trade details to ensure that trade details are correct before being communicated externally. Instead, this monitoring agent may focus on the validation of several critical components such as securities ID, price, execution date, value data, custodian, counterparty, and etc. Furthermore, sometimes a STO may need to take specific care of special types of trades that need more attention or more likely contain errors. We may consider provide additional validation on some kinds of trades such as, trades with cash value at or above a certain figure, trades with a special transaction type, trades with a special counterparty, trades in a special market, trades due to settled at a special custodian, and etc. As another example, consider some emergent trade exceptions. If a problematic trade is scheduled to be valued in a short time or a trade subject to exception reconciliation has been under repair for a long time, it

Most agents rely on knowledge about the environment that has been built by the designer. Furthermore, due to the increased complexity and uncertainty in today’s environment of organizations and markets, the agent needs to be able to adapt to the dynamic world. In rule-based agents, it usually implies the agent’s ability to automatically modify the rule base in some way, so called dynamic business rules. Agents can derive rules from the user and environment, and then incorporate the new rules into their behaviours. Such agents need access to historical databases or logs of events, which can be analyzed for emerging trends or correlations. For example, some trade details errors are related to one specific counterparty or one specific custodian or one specific trade market, which may be caused respectively by a new counterparty or a changed custodian, or a new market or securities group. The trade details monitoring agent may find this kind of correlation after data analysis on error history, and accordingly adjust its monitoring policy to pay more attention to the trades related to this specific counterparty, custodian, or trade market. Another example, some investor prefer make trade agreement over telephone after trade execution, and such kind of activity are usually not recorded into the settlement system timely. The diagnostic agent may find this kind of error usually happen around several specific investors, and will remind the manager to input trade agreement information for the trades related to these investors.

5. Multi-agent framework for exception handling After the above discussion on the application of intelligent agents for the knowledge-based exception resolution, we develop a multi-agent framework of exception handling in securities transactions with a view to make a clear map of our approach.

5.1. Deployment of intelligent agents Before applying multi-agent technology into exception resolution, we need to decompose the process of exception handling into several autonomous stages, in which each agent is delegated a particular task to exhibit its goal-oriented and

0-7695-2056-1/04 $17.00 (C) 2004 IEEE

6


reactive behavior, and cooperate with others to pursue their goals. The process of exception handling usually consists of several key stages. Firstly, the relevant data are collected for the observation on securities transactions. Secondly, problem or outstanding transactions are highlighted as possible exceptions. Identifying exceptions as soon as possible after a transaction has been set in motion will deliver considerable benefits. Thirdly, the nature of the problem is identified to determine exactly what is wrong with the individual transaction and whether it can be automatically mitigated. Fourthly, actions, e.g. automated messaging, take place in an attempt to repair the problem. Thus, the exception resolution process is decomposed into autonomous tasks, and multi-agent technology can be applied to perform exception handling activities. Agent

Task Agent

User Agent

Data Acquisition Agent

Repository Agent

Diagnostic Agent

Monitoring Agent

Trade Details Monitoring Agent

Resolution Agent

Trade Status Monitoring Agent

Figure 2. Agent hierarchy for exception handling Based on above analysis on exception handling process, the agent hierarchy for exception handling is outlined in Figure 2, in which several classes of intelligent agent are applied to provide a set of functionalities for exception handling in securities trading. The details of these agents are described followed. Three task agents are deployed to perform data monitoring and exception repair activities. The data acquisition agent is charged to capture real-time trade data from existing settlement systems for the track on securities transactions. Several kinds of trade data related to possible exceptions are required to collect for monitoring activities, such as trade details, trade agreement status, SI matching status, and so on. Two kinds of monitoring agent including 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, e.g. value date on a public holiday, undistinguished counterparty, irrational quantity, the trade will be sent to the diagnostic agent for further investigation. Trade status monitoring agent is applied to keep detection 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. Similarly, those un-matched SIs, outstanding SIs, denied SIs, and SI advisories will also be reported for further investigation and resolution. 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 and require additional information if necessary to examine the problems and create diagnostic reports. Based on the report from the diagnostic agent, the resolution agent will take some initiatives to resolve problems. Of course, we can only automate the solutions for those exceptions that occur with a high degree of frequency. While automation is key to “de-risking” the process, skilled human input still remains vital. In case where human intervention is required, the resolution agent will send a message to an operationspecialist’s desktop. The user agent acts as an effective bridge between the user and the computer. It can make the human-computer interface more intuitive and encourage types of interactions that might be difficult to evoke with a conventional interface. In our system, this agent enables the user to view current status of monitoring processes, validate resolution advice, receive alert messages, and even allow the user to adjust the behavior of other agents by editing their reasoning rules. The repository agent plays an important role in our approach. Although there is no need for centralized storage of all knowledge regarding exception handling, 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 and deal with exceptions in a collaborative manner. In our approach, the repository agent may contain and manage several kind of information, e.g. real time trade data for monitoring, reports for exceptions that have been detected, exception reconciliation status, and etc. Such shared information about securities transactions and exceptions may form an important base for agents’ collaboration in exception handling.

0-7695-2056-1/04 $17.00 (C) 2004 IEEE

7


pass during its lifecycle. In this research, we try 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 handling system to perform monitoring activities on securities transactions, and resolutions for identified exceptions will be sent back to trading and settlement systems to repair such exceptions.

5.2. Multi-agent system architecture An exception-management system is one that can track the predictable events of processing a trade throughout its lifecycle, and can identify errors and subsequently resolved errors. We can reengineer current trading and settlement applications to support exception handling functions, or develop an independent exception handling system to link with existing applications through which a trade would

([FHSWLRQ5HSRUW Diagnostic Agent

Monitoring Agents

Repository Agent

'DWD$UULYDO 1RWLFH

'LDJQRVWLF 5HSRUW

User Agent

Data Acquisition Agent

Resolution Agent 5HVROXWLRQ5HSRUW $OHUW0HVVDJH

7UDGH 'DWD

Exception Management System

([FHSWLRQ 6ROXWLRQV

Trading and Settlement Applications

Figure 3. Multi-agent framework for exception handling Based on the deployment of intelligent agents in section 5.1, we outline the framework of our multiagent based exception handling system in Figure 3, in which a society of intelligent agents is applied to provide a set of functionalities for exception handling in securities trading. As related before, all these agents work autonomously and collaboratively in the multi-agent environment. Each agent focuses on its particular task such as data acquisition, 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 diagnosing and subsequently reconciled 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. 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 domain. 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, information about other agents, and 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, rulesbased 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 envelops an agent and provides access to it via a well-defined interface, and it is also the primary conduit for communication between agents.

0-7695-2056-1/04 $17.00 (C) 2004 IEEE

8


Interaction among agents, an important aspect on research of multi-agent system, is set up on lowerlevel 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) [16]. Recently, there are some researches focusing on the use of XML (Extensible Markup Language) in agent communication [17]. XML is a meta-language, that is, a language used to describe a language. It enables the definition of customized markup languages for different classes of documents. Furthermore, we will adopt STPML 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 Straight Through Processing [18]. STPML schema enables software agents to understand the contents of messages correctly and consistently.

environment written entirely in Sun's Java language by Ernest Friedman-Hill at Sandia National Laboratories in Livermore, CA [20]. By using Jess, we can build Java applets and applications that have the capacity to "reason" using knowledge which supply in the form of declarative rules. Thus, our agents are able to detect exceptions and generate error reports and resolution reports by JESS rules. After the implementation, some simulation and evaluation will be performed on this prototype to test its performance and usability.

7. Acknowledgement The authors want to thank Chen Wang from Merrill Lynch and Bob Currie from GSCS Benchmarks for their professional advice and support on our research.

References [1] U.S. Securities and Exchange Commission, Settling securities trades in one day, T+1, http://www.sec.gov, Oct. 2001.

6. Conclusions This paper explores the approach of applying intelligent agents for knowledge-based exception handling in securities trading. A conceptual framework of multi-agent system is developed, in which various classes of intelligent agents are proposed to provide a set of functionalities for exception handling in securities trading. In order to make software agents to act autonomously and collaboratively to fulfill the organizational goals and objectives, business knowledge such as business rules and business strategies are extracted from securities trading and settlement practice, and applied to the design of individual agents. A generic structure for rule-based agents is also outlined, in which business logic is separated from business model with a view to enhance the flexibility and adaptability of such kind of rule-based system. Following this framework, we have started to build a prototype in Java so that agents can run on heterogeneous platforms and make use of lightweight applets as temporary agents. The Java Web Services Developer Pack (Java WSDP) (Java.sun.com 2003) will be used in our system. The Java Web Services Developer Pack (Java WSDP) is a free integrated toolkit that allows Java developers to build, test and deploy XML applications, Web services, and Web applications with the latest Web services technologies and standards implementations. Besides the java package, we adopt Jess [19] as our business rule engine. Jess is a rule engine and scripting

[2] M. Simmons, Securities operations: a guide to trade and position management, John Wiley & Sons, New York, 2001. [3] H. Wang, J. Mylopoulos and S. Liao, Intelligent Agents and Financial Risk Monitoring Systems, Communications of the ACM, Vol. 45, No. 3, March 2002, pp.83-88. [4] M. Wang and H. Wang, Intelligent Agent Supported Flexible Workflow Monitoring System, Lecture Notes in Computer Science, 2002, Volume 2348, pp.787791. [5] H. Wang and C. Wang, Intelligent Agents in the Nuclear Industry, IEEE Computer, Vol. 30, No. 11; November 1997; pp.28-34. [6] Wall Street & Technology Online, Automating exception management in securities, http://www.wallstreetandtech.com, Nov. 14, 2000. [7] A. Guerra, Exception Management: The Safety Net You've Been Looking For? Wall Street & Technology Online, Sep 4, 2002, URL: http://www.wallstreetandtech.com [8] V. Kumar and G. David, Global Straight Through Processing. The Evolution Continues. Elec-tronic Data Systems Publication, December 2000.

0-7695-2056-1/04 $17.00 (C) 2004 IEEE

9


[9] M. Woodridge and N. Jennings, Intelligent agents: theory and practice, The Knowledge Engineering Review, 10(2), 115-152. [10] N. Jennings and M. Wooldridge, Applications of intelligent agents: Theory and Practice, The knowledge engineering review, vol.10, no.2, pp.115152, 1995. [11] GSCS Benchmarks, Corporate actions: Dangerous events, The 2002 Review of Major Markets, 2002, pp.20-24. [12] A. Caglayan and C. Harrison, Agent sourcebook: a complete guide to desktop, internet, and intranet agent, John Wiley & Sons, New York, 1997. [13] K. Liu, L. Sun, A. Dix and M. Narasipuram, Norm Based Agency for Designing Collaborative Information Systems, Information Systems Journal, 11, 229-247. [14] J. Giarratano and G. Riley, Expert systems—Principles and programming, Boston, MA: PWS Publishing Company. [15] T. Morgan, Business rules and information systems, Addison-Wesley, New York, 2002. [16] T. Finin, R. Fritzson, D. McKay, and R. McEntire, KQML as an agent communication language, Proceedings of the third international conference on Information and knowledge management, ACM Press, Nov.1994. [17] R. J. Glushko, J. M. TENENBAUM, and B. MELTZER, An XML framework for agent-based ecommerce. Communications of the ACM (42), 1999, pp.106-114. [18] Financial Models Company, What is STPML? http://www.stpml.org, 2003. [19] Java.sun.com, Java Web Services Developer Pack1.2, http://java.sun.com/webservices/webservicespack.html [20] E. J. Friedman-Hill, JESS – the rule engine for the JavaTM platform, http://herzberg.ca.sandia.gov/jess

0-7695-2056-1/04 $17.00 (C) 2004 IEEE

10