JP2003536167A - Structured anonymous trading system - Google Patents

Abstract

(57) Abstract Anonymous trading systems include computer trading platforms that can trade many different alternatives. The platform consists of a number of subsystems, each of which mediates a unique pluggable alternative. The subsystems include an order management subsystem that distributes and matches quotes, a transaction execution subsystem that confirms and records transactions, a market perspective subsystem that provides market prospects to traders, and a credit subsystem that manages credit usage. Including. Each subsystem can communicate with an appropriate plug-in that defines the rules for a given alternative.

Description

Detailed Description of the Invention

TECHNICAL FIELD OF THE INVENTION The present invention relates generally to tradable products such as foreign exchange and financial products.
The present invention relates to a computer trading system that provides electronic trading services. In particular, the present invention relates to a computer trading system having a plurality of order entry devices, such as network-connected trader terminals, for buy orders, trade offers, trade order submissions and matching.

BACKGROUND OF THE INVENTION Anonymous trading systems are, for example, European patent application 0,399,850 and European patent application 0,411 which disclose an automatic matching system for anonymous trading of foreign currencies (or other financial instruments). , 748. In this system, one host computer maintains a central database of all traded products available for trades, credit information, and buy and sell offers submitted through a computer network by terminals connected to the host. . The host computer uses the information in its central database to match buy orders, buy offers, and buy orders based on matching criteria, including trading partner credit limits.

Counterparty credit limits are set at each trading floor and stored in a host computer, which then establishes a total counterparty credit limit for each possible set of counterparties. The total trading partner credit limit is the minimum amount of credit remaining from the first party to the second party and from the second party to the first party. The terminals of various traders connected to the host computer hold and display only a limited portion of the information available to the host, such as best buy orders and buy and sell offers.

This system has been identified with the problem that the host computer uses only credit information to confirm that the transaction can proceed after admitting a possible match. Thus, a trader could not know if he had credit with a potential trading partner before attempting to trade. This problem was recognized and the solution provided in the system disclosed in US Pat. No. 5,375,055, the contents of which are hereby incorporated by reference.

In the system disclosed in US Pat. No. 5,375,055, a credit matrix table is derived and stored in a plurality of area nodes of a distributed network,
Each regional node distributes market information to a set of trader terminals to which the regional node is connected via an access node. Area nodes are known as market distributors and provide tradable price information to trader terminals connected through access nodes known as market access nodes.
The actual matching in buy orders, buy offers, buy and sell commands is provided by a separate node known as an arbitrator.

In the field of online trading systems, there are different systems that provide the capability to match and trade financial products, including foreign currency and futures products as well as stocks. In each case, there are specific requirements of the system to handle the varying nature of the goods traded. As a result, each existing system can only trade one category of merchandise. The inventor has acknowledged that this system has limitations in that a new system must be developed each time a new product is desired to be traded. Especially in the financial world, this can impede the development of new systems.

The inventor has acknowledged that a better approach is required. In particular, the inventor may be able to develop a trading platform to trade many different types of commodities, but requires that the structure be very different compared to existing trading system designs. I've admitted that I might do it.

SUMMARY OF THE INVENTION Accordingly, there is provided a computer trading platform adaptable to trade a plurality of different tradable commodities, comprising a plurality of subsystems, each subsystem being a tradable commodity. Matched by the order management system, which has an interface to the specific plug-in, the platform receives the quote, distributes it, and matches the quote with the order according to the criteria provided by the order management plug-in. A trade execution subsystem that identifies and records trades that have been made, a market prospect subsystem that provides market prospects to traders, and a credit subsystem that manages credit usage,
Each subsystem is in communication with an appropriate plug-in that defines the rules for matching, trade execution, market outlook, and credit, respectively, thereby creating a trading system.

[0009]   [Detailed Description of the Invention]   Examples of the invention will now be described by way of example only.

The described embodiment is a brokering platform adaptable for providing a trading system for many different products. A tradable instrument is any instrument that can be tradable, including but not limited to foreign currencies and financial instruments such as stocks and commodities.

The purpose of separating the broking platform into application and core is
This allows the core to be developed as a stable and reusable framework that can be used to create applications more easily. Maintenance efforts are reduced because many of the systems are contained in reusable packages that are kept as one effort for all applications. Application-specific business functions are put into small, well-defined components that can be analyzed, understood, and retained. Dividing the core and application into components, in turn, allows for the parallel design, development, and testing of critical parts of a broking platform that provides stronger and more maintainable products with reduced delivery times. . Another advantage of this effort is that it separates the core from the application by a well-defined interface so that the application may be designed and configured in parallel with the core development efforts of the broking platform.

First, an example is described in terms of one possible physical architecture before considering the key aspects of a modular design. The physical architecture of the broking platform is shown in FIG.

The computer trading system embodying the present invention is a distributed system.
In this document, distributed is understood to mean that the function performed by the network is distributed among multiple nodes. A key aspect of the example network is that each of the nodes performs an equivalent function in both the price distribution service and the order matching service.

The purpose of the exemplary system is to allow traders to enter matching quotes and orders within the system. The system shall include at least: It provides a platform to trade financial market options, metals, current debt, government bonds, and other short-term interest rate products. These are all called financial instruments.

First, a brief overview of an exemplary network is provided with reference to FIG. 1, followed by a more detailed discussion of embodiments with reference to the subsequent figures. The computer trading system of FIG. 1 includes a plurality of trading agents 10 each connected to at least one of a plurality of broker nodes 12. Broker node 12 is [a type of computer and software discussed briefly]. Trading agent 1
0 is [type of computer and software discussed briefly]. Each trading agent is a means for traders to access the trading system.

Broker node 12 provides basic order matching and price distribution services. Brokers are arranged in a structure called a clique tree that allows for faster communication routing, following very clear but simple rules. A clique tree is a network structure where individual nodes are grouped into cliques, and cliques are arranged in a tree structure. Each broker is logically linked to many brokers, called its neighbors. Communication between brokers is at a comparable level in the network, with no "upward" or "downward" direction.

A trading agent node provides services for a particular trading floor or group of traders. A trading agent node is a node that provides an interface to the trading floor. Each trading agent is connected to at least one broker accessing the network. Any number of trading agents can be connected to one or more brokers in the network.
There are no "root" or "leaf" brokers. All brokers are equal,
Accept trading agent connections. A plurality of trader terminals are connected to each trader agent.

Although trading agents must be connected to at least one broker, they themselves remain outside the structure rather than members of the clique tree. Trading agents connected to multiple brokers are likely to receive multiple sets of market prices. Even if the price information from different brokers may be substantially the same, they may receive that information at different intervals. A trading agent will only send orders for a given trade to one broker.

Brokers are mutually equivalent and perform the same function. Network placement,
That is, their position in the network is transparent to the broker. They only need to know about their neighbors. Each broker has knowledge of all orders in the market and can match orders as soon as they are submitted. Each broker also keeps a good list of orders in the market and can therefore customize the market outlook needed by trading agents, and as soon as market information is received, it responds to that market information faster. can do.

The modular nature of the exemplary system will now be described with reference to FIG. 2 with respect to various subsystems that provide key aspects of the design. Subsystems are components that reside within an embodiment that encompass the major areas of functionality where services are exposed by one or more interfaces. Each interface is provided by the subsystem's agent and called directly by a local procedure or method call. The agent
The services provided by the subsystems may be implemented, and may also serve as a proxy to agents using the implementations of the subsystems outside, or the subsystems distributed across the network. Subsystems are customized for specific applications via plugins. The term plug-in means a functional component that can be added to the underlying platform to provide the specific functionality required for the selected tradable instrument.

The subsystems in this embodiment are an order management subsystem 14, a trade execution subsystem 16, a market forecast subsystem 18, a market inventory subsystem 20, a credit subsystem 22, and a market definition subsystem 24. Each of these will be discussed further below.

The trading platform includes those subsystems and associated plug-ins, as well as regular objects, application-specific objects, and system services.

Plug-ins are used to provide application-specific functionality to subsystems. This is accomplished through the application's implementation of the plug-in's interface, which is defined as part of the subsystem's specification. Plug-ins may use any service provided by the plug-in's associated subsystems, or all other subsystems required through the subsystem's agents. Plug-ins may use the services of the system.

A normal object consists of a set of all objects used in the definition of the interface of a subsystem service. A broking platform defines a regular object type, but may either implement it or extend it as required by the application through inheritance as provided by the specification of the components in a regular object. Good. Regular objects may include one or more application-specific objects.

Application-specific objects include the state and behavior required for an application in a given trading system. Such objects can be either by clients of the brokering platform or by plugins.
Created. The broking platform provides application specific object transfer and delivery via ordinary objects. Application-specific objects can also be used directly by the subsystem agent interface.

The services of the system provide general services to subsystems, ordinary objects, and plugins. System services are distinguished from subsystems because they do not have all of the application-specific behavior (no plugins) and are fully provided by the brokering platform. The services of the system are generally not related to specific business functions,
It typically provides services of a technical nature. The services of the system are classified into groups of similar services.

The interaction of the key components in the exemplary embodiment is shown in FIG. The example shows two subsystems, subsystem A30 and subsystem B32. The plug-in 34 for subsystem B provides application-specific services to subsystem B32. In addition, subsystem B32 utilizes the services of subsystem A30 via a local instance of subsystem A's agent 36. The application-specific functionality contained in the subsystem B plug-in also uses subsystem A services through the agent 40. The services of subsystem A are invoked through a method interface that uses ordinary objects 38 and 42, including application-specific objects that are communicated between A and B. Subsystems and plug-ins for those subsystems, as well as ordinary objects, call the system's services 44 as required to provide common services such as network forwarding or event logging services. Good.

Therefore, to create a trading system, a set of plug-ins is selected, along with the subsystem shown in FIG. 2, along with the functions chosen for the interface. Plug-ins use agents and objects as described to interact with various subsystems.

In addition to the six main subsystems shown in FIG. 2, a further subsystem called the Brokering Platform Client provides application clients access to key services provided by other subsystems or system services. It provides a set of services called the King Platform API.

The brokering platform client subsystem, also referred to as the BPC, provides the core services of the brokering platform to application clients. The collection of services provided through BPC is called the Brokering Platform API (Application Programmer Interface). By using BPC, application clients can utilize core services with a simple and well-defined interface.

The brokering platform's client subsystem provides the service of submitting orders specified by order parameters. Subsequent changes in the status of the order or the trades executed against the order are communicated via the interface. The order identifier for the newly submitted order is returned. Services are provided to allow the client to confirm or deny the offered trades and suspend the order, and to allow the client to establish a session with the BP core. . The trader's identity is indicated by a trader ID that is qualified to be included in the identity. BPC also allows clients to request product element information based on product element data. BPC also provides services that allow clients to request subscriptions to market prospects for a given product. Market outlook is provided to clients via an interface.

The client subsystem is also an object that allows the application client to provide application-specific order submission details,
Objects that allow application clients to provide details of application-specific market-view criteria to identify the composition and delivery of market-views, and product-specific details for each product. Provides application-specific objects within the client subsystem, including objects provided to application clients.

Order management subsystem 14 provides brokering services to traders. The system provides matching orders to apply for trades for ordering and distribution. The new transaction is submitted to the transaction execution subsystem for completion of the transaction. The order management subsystem, when applicable, is responsible for manipulating orders based on market events. The entire life cycle of an order is managed by the order management subsystem based on the trading rules of the subsystem and the characteristics of the order.

The order plug-in interface provides management system product-specific operations for manipulating order submissions, allowing applications to perform validation on newly submitted orders. Create a new deal, given a new order. If no matching is available, the order must be inserted into the order book, activated for a fixed price distribution as required, and distributed to other brokers. The order management system application-specific object contains all details of an application-specific order submission.

The transaction execution subsystem 16 is as follows. The trade execution subsystem is responsible for locating and returning pending trades through the system and returning them to the original trader's workstation to allow confirmation of the order. New trades are served by and executed by the order management subsystem. This subsystem is responsible for market updates, credit checks, order confirmations, order recordings, ticket printing, and all other activities resulting from execution or completion of trades in all passive brokers. This subsystem works with the order management subsystem to get the appropriate response interface to allow notification of the correct client.

The Transaction Execution Subsystem is responsible for creating the objects for the transaction to initiate the execution of the transaction, and for performing all application-specific initiation activities. The application specific object contains all the details of the application specific order submission. This information originates from the request for the originally submitted order by the client. Other objects may be used by various plug-in methods that provide application-specific behavior.

The credit subsystem 22 is responsible for managing usage for credit allocation. This subsystem is responsible for notifying the credit observer whenever the credit allocation changes state between the out-of-credit status and the available credit status. This subsystem is responsible for verifying and / or adjusting the trading volume based on the credits available. Credit subsystems, such as enabling the operation of credit allocation and credit dividends,
It also has a predetermined operation function.

The credit subsystem interface provides a service responsible for verifying credit suitability for two counterparties to two orders.
If the other party is not credit-compliant, then false is returned and the transaction volume is zero. If the opponent is credit compliant, then the desired amount is used to calculate the amount of credit. Given that the total desired amount exceeds the available credits, the trading volume based on the available credits is calculated. If this quantity is less than the minimum trade volume, then these counterparties are considered credit non-conforming for these two orders and a false value is returned with a trade volume of zero. Else, true is returned and the transaction volume reflects the volume prepared for a new transaction.

The credit subsystem plug-in interface is responsible for calculating the amount of credit based on the traded volume that was submitted, the original order in which the trade may be made. A return quantity of zero means that the counterparty is not credit fit for the given order. The interface is also responsible for calculating the trading volume based on the credit volume. The trade volume returned is based on the two orders that may be traded. A return quantity of zero means that the counterparty is not credit fit for the given order.

The credit subsystem application-specific objects include all of the application-specific order submission details and may be used by various plug-in methods that provide application-specific behavior. provide.

The market inventory 20 subsystem manages orders and trades for merchandise. Orders and trades for different product elements are organized in order books and trade books. Market inventory consists of a collection of order books and trade books for various products. This subsystem is responsible for maintaining a collection of order books and providing controlled and reserved access to order books and transaction books to other subsystems.

The interface of the market inventory subsystem includes methods that allow other subsystems to add orders to the order book for a particular item. Calling this method calls the ordering plugin to position the orders in the order book in the correct order and handle the pre-order and post-order inserts. A further method computes the set of orders for the particular product element and adds the trade to the trade book for the particular product.

[0043]   The Market Inventory Subsystem plugin interface is:   1. Work with order   2. Discover position (order book ordering)   3. Insert before order (order, order book)   4. Insert an order inactive   5. Insert after order I do.

These functions are application-specific as the rules for orderbook ordering, and the pre-order insert and post-order insert processing may differ between applications.

The market definition subsystem 24 provides the functionality to access and operate all market, product, product, and product element data. The burden includes providing a means for the user to enter information, modify data, and provide information to the system of the broking platform. The system defines what products and product elements are traded, the trading method used (corresponding order type, corresponding order operation type, trading initiation and execution rules, etc.), market level and product level. Define the rules for trading and who can trade (public entity / trading floor). The system defines and operates all market data and market operations such as open, close, pause, enable, etc.

The subsystem's interface in the Market Definition Subsystem contains methods that result in the validation of orders submitted into the brokering platform's system. The interface then calls the application's plug-in, as the order validation provisions may differ for different applications. The Market Definition Subsystem plug-in interface validates orders against applications and based on validation rules as defined per application.

In order to understand where the market is, the trader must have a market perspective. The Market Outlook 18 subsystem provides the trader with this information. The Market Outlook Subsystem is responsible for providing the ability to subscribe to the Market Outlook, create the Market Outlook, and subscribe to the Market Outlook, distributed to subscribers. Methods are provided that allow subsystems to request subscriptions to market perspectives.
Since the market outlook is inherently application specific, this method calls the application's market outlook plugin to create the initial market outlook.

[Brief description of drawings]

[Figure 1]   FIG. 3 is a diagram of the major components of the physical architecture of a trading system.

[Fig. 2]   FIG. 6 is a diagram of the components of the main functions of a broker node.

[Figure 3]   FIG. 6 is a diagram of the interrelationship of subsystems and plug-ins.

─────────────────────────────────────────────────── ─── Continued front page    (81) Designated countries EP (AT, BE, CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, I T, LU, MC, NL, PT, SE, TR), OA (BF , BJ, CF, CG, CI, CM, GA, GN, GW, ML, MR, NE, SN, TD, TG), AP (GH, G M, KE, LS, MW, MZ, SD, SL, SZ, TZ , UG, ZW), EA (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), AE, AG, AL, AM, AT, AU, AZ, BA, BB, BG, BR, BY, B Z, CA, CH, CN, CO, CR, CU, CZ, DE , DK, DM, DZ, EE, ES, FI, GB, GD, GE, GH, GM, HR, HU, ID, IL, IN, I S, JP, KE, KG, KP, KR, KZ, LC, LK , LR, LS, LT, LU, LV, MA, MD, MG, MK, MN, MW, MX, MZ, NO, NZ, PL, P T, RO, RU, SD, SE, SG, SI, SK, SL , TJ, TM, TR, TT, TZ, UA, UG, UZ, VN, YU, ZA, ZW (72) Inventor Iaceo, Stephen             New Jersey, United States             07035 Lincoln Park West             William Street 41 (72) Inventor Jane Nina             New Jersey, United States             07080 South Plainfield             Victory Street 3756 (72) Inventor Shoo, James             New Jersey, United States             07936 East Hanover Till             Den Drive 42 (72) Inventor Hawolka, Edward Earl             New Jersey, United States             07950 Morris Plains Gates Co             2043

Claims (6)

[Claims] 1. A computer trading platform adaptable to trade a plurality of different tradable products, comprising a plurality of subsystems, each subsystem providing an interface to a plug-in specific to the tradable product. The platform includes an order management subsystem that receives and distributes quotes and matches quotes and orders according to criteria provided by an order management plug-in, and confirms transactions that are matched by the order management subsystem. Provides a trade execution subsystem that records, a market outlook subsystem that provides a market outlook to a trader, and a credit subsystem that manages the use of credits, each subsystem including matching, trade execution, and market execution. Forecasts and credit rules By being capable of transmitting an appropriate plug and information defining, respectively, a computer trading platform to create a trading system. 2. The computer trading platform of claim 1, wherein the order management subsystem includes means for matching orders based on criteria specific to tradable products. 3. The computer trading platform of claim 1 or 2, wherein the order management subsystem includes an interface that receives criteria specific to tradable products. 4. The computer trading platform according to claim 1, wherein the order management subsystem holds an order book of quotes. 5. The computer trading platform of claim 1, wherein the credit subsystem includes means for verifying the suitability of the other party's credit for possible matching. 6. The computer trading platform according to claim 5, wherein the means for confirming the suitability of the credit includes an interface for passing the applied transaction volume to the credit plug-in and receiving the use of the credit from the credit plug-in. .