Abstract

A Computer apparatus configured to process transactions in fungible assets on behalf of account holders on a client controlled, order by order basis, via account controlled and configured private books of business and public books, as well as proactively route public orders to external venues based on analysis of account-specific best execution configurations including venue cost assignments and account-specific venue routing parameters.

Claims

The invention claimed is:

1. A Computer apparatus configured to process transactions in fungible assets on behalf of account holders on a client controlled, order by order basis, via account controlled and configured private books of business and public books, and to proactively route public orders to external venues based on analysis of account-specific best execution configurations including venue cost assignments and account-specific venue routing parameters, the apparatus being provided with a matching engine including an internalised matching utility for conducting transactions on account defined private books of business, in addition to public books of business, the computer apparatus comprising: operation files comprising configuration information including account holder rules and preferences, and wherein said rules comprise definitions of private book relationships defined in terms of eligible private book counterparties per account holder identity; an operation file configuration interface configured to establish private book relationships and define deal criteria applying between eligible private book counterparties; a volatile memory configured for receiving and holding in-memory book of business data, including private book data, market data from external venues, and other relevant data based on information in orders; a matching engine comprising an internalised matching utility processor configured to parse the private book data in the volatile memory according to account holder rules and preferences.

2. The apparatus according to claim 1, further comprising an account holder interface module configured to receive orders from a remote account holder computer with the ability to determine the originating account holder, order type, and eligibility for one or more of the following predetermined order scopes including: private book, public book, and proactive routing to external venue.

3. The apparatus according to claim 2, wherein the account holder interface couples to the operation file configuration interface enabling account holders to configure the operation files, at least in part.

4. The apparatus according to claim 3, further comprising an administration interface coupled to the operation file configuration interface enabling system administrators to configure the operation files, at least in part.

5. The apparatus according to claim 1, further comprising an order management module configured to determine eligible order scopes and pass order data to relevant components of the apparatus in dependence on the determination, the order management module comprising a set of order scope detectors, wherein the order is determined to be eligible as a private book order from account holder preferences and by detecting a private book flag among order scope detectors, the private book order is passed to the internalised matching utility (IMU) processor for handling.

6. The apparatus according to claim 1, further comprising a book manager module with access to an in-memory book datastore comprising private book configuration and account preference data per account holder, and operable to call book of business data, including where appropriate private book data, into the volatile memory for processing based on said configuration including the account holder identity and eligible private book counterparties information.

7. The apparatus according to claim 1, wherein the matching engine comprises a Multilateral Trading Facility (MTF) processor, such that if the order is not fully transacted by the IMU processor and is determined by the order management module specified in claim 5 to be eligible as a public book order from account holder preferences and by detecting a public book flag among order scope detectors, public book data from account holder in volatile memory is parsed by the MTF processor according to account holder rules and preferences in the operation files.

8. The apparatus according to claim 1, wherein a set of control functions are provided to determine criteria based on account holder input for which the exposure scope of an order exposed to only the private book can be changed to include exposure in the public book; and for which the exposure scope of a public order can be changed to remove exposure within the public book.

9. The apparatus according to claim 1, wherein the matching engine comprises a best execution routing processor such that if the public order is not fully transacted by the MTF processor and is determined by the order management module specified in claim 5 to be eligible for best execution routing from account holder preferences and by detecting a proactive route flag among order scope detectors, external venue data in the volatile memory is parsed by the best execution routing processor according to account holder rules and preferences in the operation files.

10. The apparatus according to claim 1, wherein the operation files additionally comprise configuration information by account holder relating to one or more of: speed of execution; likelihood of execution; likelihood of settlement; price; likelihood of price improvement; venue data; costs by venue; costs by transaction type; settlement data; settlement cost data; venue routing parameters; a combination of any of the aforementioned.

11. The apparatus according to claim 1, comprising a control function operable to generate relevant configuration information prior to and during a trading session and store it within the memory data store as well as the operation files.

12. The apparatus according to claim 1, wherein the order management module comprises a request processor configured to determine order type and order scope(s) and to provide order data to relevant components of the apparatus, and an order processor configured to provide order data to relevant components within or associated with the apparatus.

13. The apparatus according to claim 1, further comprising a best execution cost engine, capable of accessing orders of two or more eligible counterparties based on account configuration and cost information contained within the operation files.

14. The apparatus according to claim 13, comprising a best execution cost engine operable to determine a synthetic transaction value for a proposed transaction for an account holder, taking into consideration account holder costs relating to a particular counter-party and/or a particular venue based on account specific configuration data.

15. The apparatus according to claim 14, wherein a set of control functions are provided to determine criteria based on account holder input for which the exposure scope of an order exposed to only the public book and private book can be changed to include eligibility for proactive routing; and for which the exposure scope of an order eligible to be proactively routed can be changed to remove eligibility for proactive routing.

16. The apparatus according to claim 15, further comprising an integrator module configured to call operation files and to distribute information from within said operation files to components of the system.

17. The apparatus according to claim 16, comprising a settlement management module operable to administer charges to account holders for a private or public book transaction.

18. The apparatus according to claim 17, further comprising a disseminator module configured to publish particulars of transactions handled by the apparatus.

19. The apparatus according to claim 18, wherein said operation files configuration interface is configured to assist a user in entering rules and/or preferences relating to one or more of: account holder speed of execution preferences; account holder likelihood of execution preferences; venue preferences; account holder costs by venue; account holder costs by transaction type; account holder response to price improvement indications; settlement cost information; account holder settlement preferences; a combination of any of the aforementioned.

20. A method of operating a computer apparatus configured to process transactions in fungible assets on behalf of account holders via private and public books of business, as well as proactively route orders to external venues based on best execution analysis for the account holder and account holder configuration, the apparatus being provided with a matching engine including an internalised matching utility for conducting transactions on private books of business, in addition to public books business, the method comprising: receiving an order from a remote account holder computer with the ability to determine the originating account holder and eligibility for one or more of a number of predetermined order scopes including a private book type of order, public book type of order, and proactive routing to external venue; determining order type and order scope(s) and providing order data to relevant components of the apparatus in dependence on the determination, in the case of the order being eligible as a private book the order passing the order to an internalised matching utility processor for handling; loading book of business data including, where appropriate, private book data and market data from external venues into a volatile memory for processing based on configuration information maintained in operation files, said information including account holder identity and eligible private book counterparties per account holder; and operating a matching engine comprising an internalised matching utility processor to parse private book data in the volatile memory according to account holder rules and preferences in said operational files; and operating a matching engine comprising a best execution analysis processor to parse eligible proactive route orders and route to determined external venues based on account holder rules and preferences in said operational files; and conducting a transaction pursuant to the received order.

21. A computer readable medium encoded with computer code, which, when loaded onto a computer, causes the computer to become capable of processing transactions in fungible assets on behalf of account holders via private and public books of business, as well as proactively route orders to external venues based on best execution analysis for an account holder based on account preferences and order data, the computer code encoding a matching engine including an internalised matching utility for conducting transactions on private books of business, in addition to public books business, the code comprising code to cause the computer to: receive an order from a remote account holder computer with the ability to determine the originating account holder and eligibility for one or more of a number of predetermined order scopes including a private book type of order, public book type of order, and proactive routing to external venue; determine order type and order scopes and pass order data to relevant components of the apparatus in dependence on the determination, in the case of the order being a private book order passing the order to an internalised matching utility processor for handling; load book of business data including, where appropriate, private book data and market data from external venues into a volatile memory for processing based on configuration information in operation files, said information including account holder identity and eligible private book counterparties per account holder; and operate a matching engine comprising an internalised matching utility processor to parse private book data in the volatile memory according to account holder rules and preferences in said operational files; and operate a matching engine comprising a best execution analysis processor to parse eligible proactive route orders and route to determined external venues based on account holder rules and preferences in said operational files; and conduct a transaction pursuant to the order.

22. An alternative trading system, utilizing the code of claim 21, said alternate trading system capable of processing internalised transactions conducted in private on behalf of account holders, public transactions conducted via a multilateral trading facility, and proactively route public orders to external venues based best execution analysis in accordance to account holder configuration and preferences, the trading system comprising: a matching engine comprising an internalised matching utility processor, a multilateral trading facility processor, and a best execution router processor; an order management module operable to receive and decode orders from account holders with the ability to determine the originating account holder and eligibility for one or more of a number of predetermined order scopes: private, public, and proactive, said order management module being further operative to supply order data to an appropriate one or more of the processors of the matching engine in dependence on said decoding; said matching engine being configured to parse book data and/or venue data in the volatile memory according to account holder rules and preferences, such that private orders are processed by the internalised matching utility from among possible transactions within private books of eligible private counterparties, public orders are processed by the multilateral trade facility from among possible transactions within public books available via the multilateral trade facility, and proactive orders are processed by the best execution router processor from among all available external venue data.

Description

FIELD OF THE INVENTION

The present invention relates to a computer system for facilitating transactions involving fungible assets, particularly types of financial instruments, such as shares (or equities), bonds, warrants and other financial products, and more particularly to transactions involving equities and equity options.

BACKGROUND OF THE INVENTION

Exchange of goods or services by way of introducing buyers and sellers is the function of markets. The participants within markets exchange goods or services for economical benefit. Initially markets operated using the model of in person, human to human communication of buy and sell orders. With the evolution of computer systems, communication of buy and sell orders have increasingly been implemented using the computer system. This new type of market is commonly, but not exclusively, referred to as electronic trading.

Electronic trading methods use various types of computer systems to facilitate transactions between a buyer and a seller. In principal each transaction is effected by participants with authorised access to the computer system. The methods, and therefore the computer system, define the scope of actions the participants can employ to match buy and sell orders.

No previously known technology has afforded participants full control and the ability to create new controls, in a concurrent holistic manner, over their counterparties, economic interest and information distribution when performing trade executions.

The apparatus and methods disclosed herein constitute an improved transaction computer system for facilitating transactions of financial instruments. In particular, the embodiments of the invention provide a client-specific configurable Internal Matching Utility (IMU) affording a client the ability to define and manage control over counterparties, economic interest and information distribution.

SUMMARY OF THE INVENTION

According to embodiments of the present invention, there are provided several apparatus, methods and computer readable media as set out in the description and appended claims.

According to an aspect of the present invention, there is provided computer apparatus configured to process transactions in fungible assets on behalf of account holders on a client controlled, order by order basis, via account controlled and configured private books of business and public books, and to proactively route public orders to external venues based on analysis of account specific best execution configurations. The apparatus being provided with a matching engine including an internalised matching utility for conducting transactions on account defined private books of business, in addition to public books of business, the computer apparatus comprising: operation files comprising configuration information including account holder rules and preferences, and wherein said rules comprise definitions of private book relationships defined in terms of eligible private book counterparties per account holder identity; an operation file configuration interface configured to establish private book relationships and define deal criteria applying between eligible private book counterparties; a volatile memory configured for receiving and holding in-memory book of business data, including private book data, market data from external venues, and other relevant data based on information within orders; a matching engine comprising an internalised matching utility processor configured to parse the private book data in the volatile memory according to account holder rules and preferences.

Other aspects of the invention are set out in claims 2-22.

According to one aspect of the disclosed systems and methods, users are empowered with the ability to configure private books of business on an end-to-end level. Hence, within each user-configurable private pool of liquidity, each client is able to list and administrate transaction preferences relating to, for example, priority among eligible counterparties.

According to another aspect, the herein provided systems and methods enable clients to specify transaction path preferences to external venues. For example, clients are able to designate interim entities, in varying degrees of preference, for transactions routed to external venues such as banks, MTFs, ATSs and ECNs.

Certain embodiments of the invention are advantageous in that they are not database driven. Implementation as a core in-memory book with key elements running as separate threads capable of reading and writing to the various files and other in-memory data has technical advantages, for example in terms of speed and data recovery.

Certain disclosed embodiments have an order book in memory and certain predetermined operating files may be preloaded. Selecting which files (if any) are preloaded is a configurable part of the system and may vary from one application to another. Separate threads may include for example: orders in and staging thereof; backup and recovery; outgoing messages; price dissemination. In use of one embodiment, operating files or portions of operating files defining one or more of: eligible contra parties by account holder; eligible IMU contra parties by account holder; contra party preferences by account holder; account-based cost preferences for various types of trade; account-based cost preferences for various counter parties; account-based cost preferences for various venues; venue-based preferences; default eligibility to trade on IMU; default eligibility to trade on MTF; and default eligibility to trade on external venues with venue-based best execution cost preferences.

According to other apparatus and methods embodying the present invention, in use, data on one or more the following are preloaded into memory during a trading session: eligible contra parties by account holder; eligible IMU contra parties by account holder; contra party preferences by account holder; account-based cost preferences for various types of trade; account-based cost preferences for various counter parties; account-based cost preferences for various venues; venue-based preferences; default eligibility to trade on IMU; default eligibility to trade on MTF; and default eligibility to trade on external venues with venue-based best execution cost preferences.

According to other apparatus and methods embodying the present invention, in use, data on one or more the following are called into memory during a trading session in dependence on an order to be processed: eligible contra parties by account holder; eligible IMU contra parties by account holder; contra party preferences by account holder; account-based cost preferences for various types of trade; account-based cost preferences for various counter parties; account-based cost preferences for various venues; venue-based preferences; default eligibility to trade on IMU; default eligibility to trade on MTF; and default eligibility to trade on external venues with venue-based best execution cost preferences.

The various embodiments of the present invention provide an integrated solution to sophisticated transaction processing involving different types of trading relationships, reducing the need for separate, secure platforms between private counterparties. The various embodiments of the present invention also minimise network transactions, making the processes involved more efficient. Furthermore, the various embodiments of the present invention entitle a given user access to the best available execution mode over a combination of live markets over time.

Certain embodiments facilitate trades, particularly internalised trades between counterparties, that would not otherwise be possible whilst at the same time mitigating unnecessary processing and message traffic within the system and wider network.

Disclosed computerised trading apparatus and methods support selective transaction scope across (i) internalised counterparty relationships, (ii) a multilateral trade facility, and the (iii) best execution external venue taking into consideration account external venues based on account holder's configured relationships and network parameters. Embodiments of the invention support trades and combinations of different types of trades across internalised pending orders that are not possible outside the system, ensuring price optimisation, reducing the number of processing steps and minimising message traffic.

Certain embodiments disclosed introduce an internalised matching utility (IMU) and control system configurable to define allowed internalised counterparty relationships. Preferred embodiments define multiple permitted counterparties by account so that a relatively complex network of permitted trades (particularly internalised trades) can be defined. For example, Account A may be permitted to trade with Accounts B and C, whereas Account C may only be permitted to trade with Account A but not with Account B.

In use, one embodiment maintains a book in-memory. New orders are represented with price and entry time. Each order has a flag indicating at least one of the following apply: IMU eligible; MTF eligible; and best execution router eligible. One or more of these flags can be set individually within an order, alternatively, or in addition, one more of the flags can take a account-based default value stored in an operation file. In general, flags set by order override flags set by default whilst not allowing an order scope broader than what is permitted by the Account flags.

In general, orders are sorted by limit price such that higher prices are matched first for sell orders, and lower prices matched first for buy orders.

In one embodiment, where flags of an order indicate multiple eligibility as between two or more of IMU, MTF and best execution routing to external venues, internalised orders are matched first. Potential contras for internalised orders are filtered based on internalised group eligibility, specifically to establish counterparties belonging to internalised groups including the account placing the order. If multiple internalised counterparties exist at the same price, the system references the operation file and determines the internalised transaction preferences of the account holder. If that does not yield a suitable match, orders may be matched on a first-in first-out basis.

Preferably, orders eligible for MTF processing are matched second. If multiple contra orders exist at the same price within the MTF, orders are matched on a first-in first-out basis.

In the disclosed embodiment best execution exchange orders are matched last. If multiple contra orders exist at the same price at different venues, the best execution processor uses account-specific venue cost preference data applying in respect of the relevant account to determine the order in which external venue orders are matched.

Various embodiments of the invention provide several advantages over previously known technology, for instance, providing participants with the ability to wholly define and regulate participation within their own IMUs between approved trading counter-parties, ability to simultaneous gain exposure to multiple matching opportunities via other participant's or groups of participants' IMUs, and ability to perform controlled executions against previously restricted market participants disallowed due to regulatory or an account holder's compliance constraints.

The apparatus and methods disclosed herein provide privileged interaction groups each defined and controlled in a multifaceted manner by each participant as per their demands on interaction relationships. The nature of interaction is based on, but not exclusively, counterparties, economic interest and information distribution. It is the ability to create an unbounded number of relationships, with each other participant having the same ability, thus creating a dynamic matrix in one continuous market.

In addition, the embodiments of the invention provide account holders previously unavailable levels of control on an order by order basis over cost and routing preference attributes when routing orders exposed to the other transaction environments.

In electronic transactions involving financial instruments such as shares (or equities), bonds, warrants, synthetics, derivatives, and other financial products, the computer systems for matching buyers and sellers are provided by traditional stock exchanges and new non-traditional trading environments often referred to, but not exclusively, as Alternative Trading Systems (ATSs), Electronic Communications Networks (ECNs) or Multilateral Trade Facilities (MTFs). One of the most marked changes has been in the Equities markets where, through provision of competitive value propositions, ATSs/ECN's/MTF's have gained an increasing share of transaction volume.

Collectively, traditional exchanges, ECNs, MTFs, and ATSs are referred to herein as trading "venues". In other words, a trading venue is an electronic system that brings buyers and sellers together for the electronic execution of trades.

Asset administrators, stock brokers or investment bankers with access to venues capable of buying/selling instruments are referred to collectively herein as "brokers".

Additional advantages and novel features of the invention will be set forth in part in the description which follows, and in part will become apparent to those skilled in the art upon examination of the following and accompanying drawings or may be learned by practice of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

For a better understanding of the invention and as to how the same may be carried into effect reference will now be made, by way of example only, to the accompanying drawings, in which:

FIG. 1 shows a trading computer system according to an embodiment of the present invention;

FIG. 2 shows an example of a typical "Account Matrix" used according to embodiments of the present invention for processing client orders;

FIG. 2A shows more detail of an account setup table according to embodiments of the present invention;

FIG. 2B shows an IMU Setup Table according to embodiments of the present invention;

FIG. 2C shows more detail of an account destination setup table according to embodiments of the present invention;

FIG. 2D shows more detail of an account cost matrix setup table according to embodiments of the present invention;

FIG. 3 shows an example of a typical Venue Setup file according to embodiments of the present invention;

FIG. 4 shows and example of an "Instrument Master File" according to embodiments of the present invention;

FIG. 5 shows an example of the Currency Exchange Rate Setup File according to an embodiment of the present invention;

FIG. 6 shows a typical process carried out by the IMU processor according to embodiments of the present invention;

FIG. 7 shows another embodiment of the transaction computer system of the present invention, with the inclusion of among other processors, an MTF processor;

FIG. 8 shows a typical process carried out by the MTF processor according to an embodiment of the present invention;

FIG. 9 shows another embodiment of the present invention, with the inclusion of among other processors, a BX Router processor;

FIG. 10 shows a process carried out by the BX Router according to an embodiment of the present invention;

FIG. 11 shows an example of the IMU setup for a controlling account with one IMU for all permissioned counter-parties;

FIG. 12 shows an example of the IMU setup for a controlling account with two IMUs creating two separate entities for permissioned counter-parties;

FIG. 13 shows an example of the IMU setup for a controlling account with two IMUs creating two separate entities with permission for one counter-party to access both IMUs;

FIG. 14 shows an example of a more complex IMU setup for a controlling account with multiple IMUs;

FIG. 15 shows a typical process carried out by the central server according to embodiments of the present invention when a trade order is received; and

FIG. 16 shows a typical process carried out when the system receives a market price according to embodiments of the present invention.

Like reference numerals appearing in the appended drawings are to be interpreted as representing functionally equivalent features described throughout this specification, unless otherwise stated.

GLOBAL DEFINITIONS

TABLE-US-00001 OrderValueEUR = Quantity * Price * ConvRateToEUR OrderValueGBP = Quantity * Price * ConvRateToGBP OrderValueSEK = Quantity * Price * ConvRateToSEK ConvRateToXXX - End Of Day value to convert from currency equity is traded to XXX MinMax( val, min, max ) if val < min min if val > max max else val Cap( val, max ) if val > max max else val

Exchange Calculations

London Stock Exchange

Total Trade Fee=(0.01+MinMax(OrderValueGBP*0.001*FeeRate, MinFee, MaxFee))*FX Conversion Rate to EUR

FeeRate, MinFee and MaxFee are Static Daily Values set by the user within Account Cost Matrix Setup as V1, V2, and V3.

Stockholm Stock Exchange (Nordic Exchange)

Total Trade Fee=5.30 SEK+(Cap(OrderValueSEK*0.000046, 440 SEK)*DiscountPercent)*FX Conversion Rate to EUR

DiscountPercent is a Static Daily Value set by the user (e.g. 0.20 for 20%) within Account Cost Matrix Setup as V1

DETAILED DESCRIPTION

Those skilled in the art will appreciate that while this disclosure describes what is considered to be the best mode and, where appropriate, other modes of performing the invention, the invention should not be limited to the specific configurations and methods disclosed in this description of the preferred embodiment.

FIG. 1 shows a trading computer system according to an embodiment of the present invention 100. The trading computer system 100 comprises a central server 102 and at least one client terminal 103 in communication with the server 102. According to an embodiment of the invention, the central server 102 is configured as an application service provider (ASP) for transactions involving financial instruments. According to other embodiments, however, it may be configured for transactions involving other fungible assets. More specifically, the central server 102 comprises the following server elements: a client interface 104, a matching processor 106, an internalised matching utility (IMU) processor 108, a book manager 110, an integrator 114, a main database 116, a disseminator 118, a best execution cost engine 120, a main memory 121 comprising an in-memory book datastore 112, and a dynamic order management module (DOMM) 123.

The main database 116 holds a plurality of user accounts belonging to clients. These clients are termed "account holders", and, according to certain embodiments, are clients wishing to carry out transactions of financial instruments. Account holders will generally be brokers, banks or other regulated firms. Once a client account has been created, e.g. through a web-interface or other input means, a client can log into their account using an appropriate access device such as a personal computer, thin client terminal, mobile handset, or otherwise, and place transaction orders with the server 102. The client is usually verified before being granted access to their account. According to one embodiment, client identity is verified using a username/password combination, for example, through a web or other user interface. According to another embodiment, a physical security measure such as a digital token is used to verify a client. However, other verification means and methods may be used as required.

The client interface 104 is operable to receive client-initiated orders. These orders (also termed "trade orders") may be, for example, order to buy instruments, sell instruments, cancel a previously submitted order, replace a previously submitted order, or a combination of these. These are often termed collectively as a "trading session".

The interface 104 is configured to receive trade orders encoded in the Financial Information exchange (FIX) protocol, the industry standard for the exchange of information related to financial instruments such as securities transactions. However, although the FIX protocol is convenient and preferable in many instances, the embodiments of the present invention are not specifically limited to the FIX protocol and other protocols may also be used alternatively or in addition, as appropriate for the tradable assets in question.

The interface 104 further comprises a translator 105, where necessary, for translating FIX (or other message protocols where applicable) encoded orders into another format for internal use within the server 102.

The client interface 104 is operable to connect to one or more client terminals 103 by a suitable communication link, e.g. via the internet or by some other network infrastructure, thus enabling communication between a client situated at the client terminal and the server 102. According to one embodiment, data is sent by clients to the interface 104 through special-purpose client software provided by vendors of software certified to interact electronically with system 100 running on client terminal 103. According to another embodiment, there is no requirement for software integration on the client terminal and data can be sent from a client to the interface 104 through a web interface using, for instance, secure HTTP (HTTPS), or otherwise.

The at least one client terminal is, according to one embodiment, a personal computer located at a site remote from the server 102. Preferably, however, the terminal is an order management system configured specifically for order entry and processing. The terminal may alternatively be a wireless device such as a PDA or other electronic computer equipped with a suitable interface. In any event, the terminal 103 is used by clients, in whatever capacity, to enter information concerning a proposed transaction. The client software, or web interface, running on terminal 103 is capable of initiating generation of order messages, typically in FIX format, in response to client inputs. This information may include, but is not limited to, indicators of the following: the instrument being traded; whether it is a buy/sell transaction; the number of instruments involved; price conditions; timing and/or duration of the order (including desired trade date and settlement date); the type of order; a set of flags, or other indicators, indicating the scope(s) of the order; a desired execution venue; account details for settlement; and client identity.

According to one embodiment of the invention, the client interface 104 is further operable to receive client configuration instructions for populating one or more operation files 140. The operation files 140, and the various methods by which they are generated according to embodiments of the invention, are described in more detail below.

The matching processor 106 is an intelligent computer processor with multi-parameter capabilities, configurable to reflect one or more pre-defined setup and configuration parameters, in this case stored at least in part in operation files 140. Broadly, the matching processor is operable to ensure rapid and accurate matching of buyers and sellers in order to conclude a transaction/trade session. The matching processor is capable of handling the matching of large numbers of bids and offers between market participants, or optionally routing orders to an external venue, such as an exchange, ECN, or alternate ATS, if deemed as the most competitive alternative based on best execution criterion. In this context, therefore, the process of matching refers to the process of computing suitable or most desirable destinations for transaction orders.

The matching processor 106 operates on a set of matching configurations that are either (i) statically specified in advance (static), e.g. by an account holder or by the system administrators and stored in one or more operation files 140, or (ii) dynamically generated in response to outputs of other system processes and stored in in-memory data store 112, or (iii) a combination of both. According to one example, matching parameters may be specified on the individual order, overriding any static defaults specified in advance.

According to one embodiment, the matching parameters are determined, at least in part, from data contained within operation files 140. The static parameters used by the matching processor 106 for matching of orders can be based on any number of factors, as will be evident from the detailed description of the operation files 140 below. Dynamically generated runtime parameters may take into consideration analysis performed on present or historical market conditions, outputs of previous transactions and/or any other calculated data.

The matching processor 106 is logically linked to an algorithm library 107, preferably existing as in-memory application code, but may also exist in some other datastore. The algorithm library comprises a suite of proprietary algorithms suitable for matching transactions. Each algorithm comprises a set of well-defined instructions for completing a matching task when given an initial set of values and parameters, usually reflecting a most desirable outcome of a transaction. The matching processor 106 is also operable to modify one or more of the algorithms based on information contained in a client order message and/or on client-specified setup parameters contained in the operation files 140.

The dynamic order management module (DOMM) 123 facilitates and manages order executions. The DOMM 123 comprises a request processor 124 for capturing input orders from interface 104 and an order processor 125 for routing said orders to pre-established destinations within server 102. The DOMM has access to main memory 121.

One use of the memory 121 is to store the one or more operation files 140, as well as real-time market data and book data, enabling rapid processing of transaction requests by matching processor 106 or routing processor 1004 (see FIG. 9). Most typically, memory 121 is a volatile memory such as a Random Access Memory (RAM) however other types of memory may be used where appropriate.

In operation, the request processor 124 validates and appropriately packages an order by identifying the account holder identity and transaction type from the order message, e.g. from data contained within the FIX order message as received at the interface 104. In response to the identified order type, the request processor 124 generates an instruction enabling the order processor 125 to route an offer or bid to a predetermined destination within server 102, i.e. to the relevant sub-process (also referred to as a "plug-in"). According to preferred embodiments, this routing is done with a consideration of one or more attributes stored in operation files 140 specified at least in part by account holders.

However, according to an embodiment of the invention, the transaction type may not be specified within the order message and instead may be pre-defined by an account holder and/or the system administrators as a default and stored in the one or more operation files 140 (e.g. see FIGS. 2-5). In which case, the request processor 124 looks up the operation file from main memory 121 when the client places an order, by cross-referencing the account ID contained within the order message with the account ID in the relevant operation file, and instructs the order processor 125 to route the order to the correct sub-process according to the default.

There are several transaction or order types used according to embodiments of the present invention. Generally transaction types are categorised into one or more of the following types: "proactive", "passive", "dark" and "displayed". However, these are only provided as examples of transaction types and it will be clear to the skilled person that other categories of transactions may be defined as required.

Taking the above examples, a proactive order, according to embodiments of the present invention, is one which stipulates the client wishes to execute an order by the best execution means available, and therefore wishes for the central server 102 to proactively fulfil the order utilising all available resources. In this example best execution may take into account one or more of: price; expected speed of execution; likelihood of execution; various types of cost; and the like.

A passive order, by contrast, may be limited entirely to a specific location or sub-process. For example, a client may specify that a certain order should be transacted using only certain IMUs or MTFs and, if these are not available for order execution, that the order is cancelled or queued as a standing order for future processing.

A dark order is one which is not publicly displayed, or the amount/type of data concerning the order made available to others is limited in some way.

A displayed order is publicly displayed with information relevant to the transaction, e.g. the client, the amount of equities traded, and other related information. Published information includes both pre- and post-execution with regards to orders requested and/or executed.

Although these types of orders are provided by way of example, other types of orders may also be specified, or the account holder may define additional order attributes. For example, the order may be an "Immediate Or Cancel Order" (IOC), i.e. an order requiring that all or part of the order be executed immediately after it has been brought to the market, and a "Fill or Kill" (FOK), i.e. an order to fill a transaction immediately and completely or not at all.

The order processor 125 manages the "book". In the context of embodiments of the present invention, the book is a real-time record of orders and, where applicable, the details of the orders kept over a period of time, for instance one day, several hours etc., held in a suitable format. According to a preferred embodiment, the book resides in an in-memory datastore 112. However, according to alternative embodiments the book may reside in another, separately maintained, datastore. The details of a trade typically include such things as the time, price, order size and a specification of whether it is a buy or sell order. In addition, such records may be archived, for example, in main database 116 and kept indefinitely, or deleted after a certain amount of time. This archive of records may be utilised for several purposes, including data analysis of orders over a given period of time.

When an order is successfully executed through the server 102, the order processor 125 updates the book and typically sends an execution report to the initiating account holder, and/or the fulfilling party. The order processor 125 may additionally comprise means for generating reports which contain data from the book, including detail on all open orders and on previously completed orders, which can be viewed by account holders, for instance, using a personal computer equipped with a web browser and/or terminal 103. Additionally, the order processor 125 is linked to a disseminator 118 by a suitable data connection so that orders from the book can be published once completed, where necessary (i.e. where the order is a displayed order). In effect, therefore, the disseminator 118 is a data relay means operable to publish data regarding transactions and displayed orders standing within IMUs and/or MTF of the embodiments of the present invention to one or more subscribers 812.

According to embodiments of the invention, various elements of the server 102 are driven, in part or in full, by one or more operation files 140. Each of the operation files is populated with data stored in the main database 116 and is loaded into main memory 121 as required during a trade session. Examples of the overall contents and function of each of the operation files is described below, and the operational purpose of each file will become evident having regard to the description of the various server 102 elements, which follows.

FIG. 2 shows an example of a typical "Account Matrix" 200 used according to embodiments of the present invention for processing client orders. The Account Matrix comprises an Account Setup Table 202, IMU Setup Table 204, Account Cost Matrix Setup Table 206 and Account Destination Setup Table 208.

FIG. 2A shows more detail of the account setup table 202. Upon registration with the central server 102, each client is assigned a unique account code which is stored in the account setup table 202 and used within server 102 to identify clients, define relationships between clients and route client orders. The account setup table contains a list of all eligible accounts residing on server 102, and associates the unique account code (AccountID) with various attributes including, but not limited to: whether the account can participate in IMU, MTF and/or BX router transactions; Price attributes; FillRate; TimeRate; and destination. Those skilled in the art will appreciate that while this disclosure has described what is considered to be the best mode additional criterion may be available as available. All of these are described in more detail below.

FIG. 2B shows the IMU Setup Table 204. The IMU Setup Table governs the associations between one or more Account IDs, and thus between one or more account holders. The associations between them form one or more internalized matching utilities (IMUs). The functionality of IMUs is described throughout but, broadly, an IMU constitutes a "private book of business". In financial terms, a book of business is a portfolio of financial instruments held by an account holder, such as a brokerage or bank. According to the embodiments of the present invention, private books represent a private pool of liquidity for which an account holder and/or system administrator can define, control access and organize in terms of configurable attributes. Liquidity, in this context, refers to the fact that an asset or security can be bought or sold in the market without affecting the asset's price. Each private book allows, for example, internalised order flow configurable among a plurality of entities, for instance between multiple divisions within the same firm, sponsored firms, and/or firms between which there exists a strategic relationship. As will become evident, the private books according to embodiments of the present invention may be defined and configured in any number of ways, often with complex interrelations between them.

The pool of liquidity represented in a private book can also be termed a "dark pool of liquidity" or simply "dark pool". These terms are well-known in the art, and refer generally to trades of instruments which are carried out away from central exchanges and are not fully disseminated to the public. In the context of the present invention, "dark" orders or transactions thus refer to transactions where the nature of the transaction and/or the identity of the trading client are not disseminated through the disseminator 118 and remain fully internalised.

As will become evident from the description which follows, the systems and methods of the present invention enable account holders to specify order type/attributes on an order-by-order basis. However, typically only orders exposed to the IMU or MTF processors can stipulate whether the order is displayed or not displayed (dark).

Thus, an IMU utilised according to embodiments of the present invention is an electronic "pool of liquidity" containing fungible instruments that is exclusively shared between multiple account holders who, in agreement, consent to participate in the exchange of fungible instruments between themselves, prior to the order being made available to the general marketplace. In this regard, the order is said to be fully internalised. Once the agreement between the account holders is validated, the central server 102 may provide an initial preferential priority between the account holders when determining a suitable counter-party to an order request received. However, thereafter, interactions between the account holder and defined counterparties are fully configurable by the account holder. According to one embodiment of the invention, preference will be given to transactions carried out through private books using the IMU before being routed for further processing at other venues.

As shown in the exemplary IMU Setup Table in FIG. 2B, the table comprises the following fields: IMU ID, which identifies the IMU(s); and Access Rules which associate one or more Account IDs with other counter-party Account IDs, within a single IMU. In other words, each internal matching utility, defined with an IMU ID (e.g. IMUA1, IMUA2 etc.), uniquely identifies the private IMU group defined by the associations between account ID and counter-party account ID.

Broadly, the relationships defined in the IMU Setup Table 204 constitute access permissions for internally matching trades of financial instruments. Each IMU identified by an IMU ID is in essence a separate, private liquidity pool comprising plurality of account holders, controlled (in terms of access and configuration) by one or more of the account holders and/or system administrators. Thus, each IMU contains a plurality of account IDs grouped together such that they are representative of different relationships, e.g. these relationships may represent divisions within the same firm, sponsored firms, and/or firms between which there exists a strategic relationship. Although these are provided as simple illustrative examples, more complex relationships may be built up using the configurable IMUs utilising the system and methods of the present invention.

Each client identified by a unique account ID (see table 202) has a book of business representing fungible assets. Hence, upon creation, each account ID is logically associated with a book of business of the relevant account holder. By grouping related account IDs into one or more separate IMUs, for example in the manner shown in table 204, each of the client books associated with these account IDs is effectively pooled into a single book. This constitutes a private book in which, for example, orders can be matched according to priority on an independent and neutral platform outside a firm's "Chinese wall", maintaining order integrity and ensuring compliance with order conflict policies/procedures, for instance those instituted under MiFID.

According to one embodiment of the invention, the IMU Setup Table, and thus the permissions defined by the IMU(s), is fully configurable by account holding clients (account holders) based on preference. However, the attributes of the IMUs may also be defined by the system administrators, at least in part.

According to one embodiment of the present invention, the system and methods provided are particularly advantageous over previously known technologies and methods in that account holders are given full control over their IMUs, and hence how orders are executed against eligible counterparties. This includes, for instance, giving the account holder the ability to wholly define and regulate participation within their own IMUs between approved trading counter-parties. An example of how this participation works is shown in FIG. 11. According to this example, Firm A controls one IMU (ABC), with Firms B and C as approved counter-parties. The IMU (ABC) is setup and controlled by Firm A, typically through a client interface e.g. a web interface presented when the account holder securely logs into their account, performed by a System Administrator based on the authorized approval provided by the Account holder, or by some other suitable means. Firm A then specifies Firms B and C as eligible counterparties and gives these parties access to the IMU accordingly. With the IMU and access permissions defined and agreed, Firm A can execute orders against Firms B and C. Likewise, Firm B may be given permission to execute orders against Firm C. In this regard, the interaction between parties making up an individual IMU are fully configurable by the account holder.

According to one embodiment, by participating in an IMU, all participants can execute against all other parties within the IMU and there are no further restrictions among this subset, other than the ability to assign a priority to each. According to one example, the priority set high, ultimately minimizing the possibility of execution but there could still be an opportunity for an execution against any other account with access into the IMU.

In addition, according to embodiments of the present invention, account holders are able to setup their accounts so that they can simultaneously participate in multiple IMUs, providing a completely flexible control matrix of approved trading counter-parties. An example of this is shown in FIG. 12, in which Firm A controls two separate IMUs: the first controlling participation between Firms B and C (ABC) as in FIG. 11; and the second controlling participation between Firms D and E (ADE). In the example shown, each defined IMU is an isolated entity (a separate pool of liquidity) where the account holder defines access independently. Hence, any order entered by an account holder will be accessible in all IMUs in which the account holder participates. For example, while Firm A can execute against Firms B and C, or D and E, it is not possible for Firm D to execute against Firm B.

Extending the example shown in FIG. 11, for instance, it is also possible for Firm A to introduce another degree of participation from a partner firm. In FIG. 13, this type of relationship is shown with the introduction of partner Firm G. According to this example, Firm A configures its IMU such that Firm G is given access to participate in both IMUs (ABCG and ADEG). In this regard, Firm G can execute against the same Firms as Firm A, however, may be given restricted access permissions in terms of configuring the IMU itself, e.g. adding/removing eligible counterparties, defining configurable attributes and such like.

As will be evident to the skilled person, the configurability of the IMUs, according to embodiments of the present invention, therefore enable complex IMU matrices to be defined by multiple parties, where any party may be an account holder having control of one or more IMUs and may also be a member of an IMU to which they have no control but are able to participate in internalised transaction orders. An example of such a complex matrix is shown in FIG. 14.

In addition to the account holder being able to define and control IMU participation, the account holder is also able to define and manage various preference attributes associated with each defined IMU. These preferences are utilized to determine a preferred execution path when multiple, otherwise identical, opportunities exist. For example, it may be the case that for a given account holder, several IMUs may be available that satisfy the order criteria. In this case, the account holder may specify one or more criteria which prioritize the route of execution. These criteria are stored in the account holder's operation files 140. Prioritizing in this regard may be dependent on any number of factors including but not limited to: cost of execution, bias toward a certain counter-party in the form of assigning account level priority, or any other factors required.

According to embodiments of the invention, the account holder also has the ability to define and manage various cost and preference attributes associated with executing a trade with a specific counter-party. Again, these attributes are stored in the operation files 140 and are also utilized to determine preferred execution path when multiple, otherwise identical, opportunities exist.

Furthermore, the embodiments of the invention also enable the account holder to define and manage various cost and preference attributes associated with executing a trade at a specific external market. These attributes, stored in the operation files 140, are utilised in calculations to determine the best execution alternative when otherwise identical opportunities exist within multiple external markets. In practice, determination of eligible opportunities is based on the original order price, specified in the order message, with the best execution calculation used to determine the optimum execution route. When orders are sent to the external market, they are configured to reflect the original (or improved) order price specification (rather than a calculated synthetic price) to maximize likelihood of execution based on the external market's published liquidity.

According to embodiments of the invention, each configurable attribute that can be maintained or calculated by the matching processor 106, or the central server 102 as a whole, is available to be assigned a level of importance by the account holder. These are termed "criterion importance levels". Importance may be defined according to various levels, for example, "Normal" (1), "Important" (2), and "Preferred" (3). Additional levels of importance may be introduced as needed for instance to increase the degree of granularity in identifying importance.

Throughout any transaction/trading session, the central server 102 according to embodiments of the present invention maintains various real-time statistics regarding communication performance and transactional success for a specific account holder interacting with an external market centre. Through the embodiments of the present invention, the account holder is empowered the ability to assign a level of importance to each of these factors, providing control over how the central server 102, and more specifically, matching processor 106, determines the most overall cost effective opportunity available to the account holder. These values can be maintained and modified by the account holder at any time to be reflective in all future transaction/trading sessions. This data is held in one or more operation files 140 associated with each account holder.

The Criterion Importance Levels are represented within the Account Setup information (see for instance FIG. 2A) available to the matching processor 106 and its sub processes. The criterion may be selected from one or more of the following, non-limited examples:

Price--This represents the resulting best execution price calculation performed by the matching processor 106. This calculation is performed when appropriate and may be unique for each possible external venue. According to one example, the best execution cost engine instructs the routing processor 1004 (see FIG. 9) to select the venue that is offering prices that are equal to or better than alternate reporting venues based on current published market data [Note that price, according to preferred embodiments of the invention, is only an initial determining criteria--if multiple potential counter-parties are identified at the same price level, the best execution engine determines the most cost-effective alternative from thes

Back to patents