WO2000058890A1

WO2000058890A1 - Computer network node for a financial trading network

Info

Publication number: WO2000058890A1
Application number: PCT/US2000/007739
Authority: WO
Inventors: John C. Weeks; Mehul A. Joshi
Original assignee: Omr Systems Corporation, Inc.
Priority date: 1999-03-26
Filing date: 2000-03-24
Publication date: 2000-10-05
Also published as: AU3914100A

Abstract

A computer network node (500) for a financial trading network, comprising a database (547) capable of storing trade data and a network interface (508) for connecting to a computer network. The computer network node includes a unique node identifier, an inbound trade processor (520) connected to the network interface (508) for receiving an inbound trade message and extracting inbound trade data and an outbound trade processor (533) for creating an outbound trade message and inserting a trade message into an appropriate communications protocol. The computer network node further includes a database processor (539) for controlling outputs from trades database (547) and creating and sending outbound trade data to the outbound trade data processor (533). Finally, the computer network node includes a background processor (529) connected to the trades database (547) and the network interface (508) for reconciling an ownership transfer message with an ownership status contained in the database.

Description

COMPUTER NETWORK NODE FOR A FINANCIAL TRADING NETWORK

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates generally to a financial trading network, and more particularly to a computer network node and node processes for implementing a financial trading network.

2. Description of the Background Art Financial trade activities are a common and often performed method of transacting business. There may be activities for buying or selling stocks, bonds, commodities, conducting banking activities, credit transactions, etc. Trade activities frequently are conducted at a distance, with no actual transfer of property or currency actually taking place, and commonly occur with only the transfer of data.

Trade activities conducted by only a data transfer can easily be performed by electronic means. There are many advantages to electronically conducted data trade activities, such as, for example, speed, convenience, lesser risk of theft, loss, or wasting, and the ability to transmit an electronic trade activity to any location on the globe.

Electronic trade activities conducted over a computer or digital data network are not hampered by the size or location of the transaction, and increasingly occur across international borders. Electronic networks also offer other advantages, such as, for example, the ability to transfer other data along with a trade activity, ability to transfer ownership, ability to add or modify other status types, ability to transmit status requests, ability to track information or trade activities, etc. With the advent of digital networks, such as the

Internet, trading networks have rapidly grown in size and use due to the advantages listed above. Typically, trading networks were designed for existing communications protocols and existing network hardware and software. Data could be transmitted between different nodes in such a network (a

"node" being any computer or device on the network) , but often a gateway or translator was needed to connect each node to the network.

Electronic trade activities have in the past been designed for specific network systems. Typically, small systems were set up for a small task that was later outgrown. Smaller systems were therefore often combined to form larger systems. Various computers, network hardware, and software were often combined in a single system or across communicating systems.

Several disadvantages exist in prior art networks and network nodes. First, the use of various network node software produced transactions that differed in content, organization, data storage protocols, and data transfer procedures. Second, the use of various communications protocols also produced systems having trading activities where the sending node and the receiving node were operating in a different manner. Third, networks were not designed and constructed with uniform application and future expandability in mind. Earlier remedies to these disadvantages have been attempted, such as a gateway between a node and the network, where the gateway can translate a trade activity between any number of communications protocols and data arrangements. A gateway does not eliminate, however, the multiple communication protocols, and must accommodate all data arrangements that may possibly be received. In addition, a gateway requires additional processing time, and may cause a slowdown in data traffic.

Organizations planning to regroup their support operations have also implemented a "hub and spoke" architecture in which a central support site (or hub) is dedicated to processing trades for a number of outposts (or spokes) . This approach, however, also has its limitations, the main drawback being that a bank may find itself locked into a rigid structure that proves difficult to adapt as business changes. If all trade information has been designed to flow between front and back offices, what happens when the bank decides to introduce a new function, such as global credit control, at one of its locations? In a hub and spoke scheme, providing the credit controller with essential and correct trade details may involve major alterations to the underlying technology.

What is needed therefore is a financial trading network having a standard computer network node and node processes for performing trade activities.

SUMMARY OF THE INVENTION A computer network node for a financial trading network is provided according to a first aspect of the invention. The network node includes a database capable of storing trade data, a network interface for connecting the network node to a computer network over which a trade message may be transmitted or received, a unique node identifier for the network node, an inbound trade processor connected to the network interface, with the inbound trade processor capable of receiving an inbound trade message and capable of extracting inbound trade data included in the trade message, an outbound trade processor connected to the network interface, with the outbound trade processor capable of creating an outbound trade message and capable of inserting a trade message into an appropriate network communications protocol including a financial trading network communications protocol and the node identifier and communicating the outbound trade message to the network interface, a database processor for controlling outputs from the database and capable of creating and sending an outbound trade message to the outbound trade processor, a background processor connected to the database and connected to the network interface, and capable of sending and receiving an ownership transfer message and reconciling the ownership transfer message with an ownership status contained in the database. The trade data in a trade message is organized by unique fields, including common data fields, product specific data fields, macro specific data fields, settlement instruction data fields, and audit data fields. These fields can include active trade activity data or static local data. A financial trading network node process for receiving inbound trade messages (said trade messages including active trade activity data and/or static local data) over a computer network is provided according to a second aspect of the invention. The financial trading network node process includes the steps of receiving an inbound trade message over a network at a first node, removing a financial trading network communications protocol from the inbound trade message, storing the trade data contained in the inbound trade message in a database, and sending an acknowledge message corresponding to receipt of the inbound trade message.

A financial trading network node process for generating outbound trade messages (said trade messages including active trade activity data and/or static local data) over a computer network is provided according to a third aspect of the invention. The financial trading network node process includes the steps of receiving in a first financial trading network node a signal to transmit a trade message to a second financial trading network node, creating a trade message by obtaining the trade data from a database in the first financial trading network node, retrieving a target node location from a node location database and placing the target node location in the trade message, inserting the trade message into a financial trading network communications protocol, inserting the trade message and the financial trading network communications protocol into a network communications protocol, transmitting a message including the trade message, the financial trading network communications protocol, and the network communications protocol over the computer network, and receiving an acknowledge message corresponding to transmission of the trade message. An ownership transfer process for arbitrating trade ownership messages over a computer network is provided according to a fourth aspect of the invention. The ownership transfer process includes the steps of: 1) sending an ownership transfer request message from a requestor node to the owning node; 2) determining whether the ownership transfer request message was received by the owning node; 3) if the transfer request message was received by the owning node, determining whether the ownership transfer request can be granted, and sending an ownership granted message to the requestor node if the request can be granted, and sending an ownership denied message to the requestor node if the request cannot be granted; 4) if the transfer request message was not received by the owning node, determining if the owning node crashed and redelivering the ownership transfer request message to the owning node if the ownership transfer request was not received by the owning node and the owning node had crashed; 5) manually resending the ownership transfer request message if the ownership transfer request was not received by the owning node and the owning node did not crash; and 6) sending a second ownership transfer message from the owning node to the requester node if a second ownership transfer request message is received by the owning node before the ownership transfer message is sent by the owning node. The trade ownership process of the present invention eliminates the dependencies of the financial trading nodes on each other (i.e. , there is no central resource) , thereby improving usability and efficiency of the financial trading network.

The present invention thus provides an electronic environment enabling all types of financial trades globally and at maximum operating efficiency and effectiveness. The above and other features and advantages of the present invention will be further understood from the following description of the preferred embodiments thereof, taken in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 shows a simplified network configuration; Fig. 2 shows an overview of a financial trading network in accordance with the invention;

Figs. 3A-3B show exemplary trade entry screens that may be used for creating a trade activity message; Figs. 4A-4B show a general data organization of a financial trading network communications message of the present invention;

Fig. 5 shows a block diagram of a financial trading network node of the present invention; Fig. 6 shows representative trade ownership transfers;

Fig. 7A-7D show representative display screens available through a network node of the present invention;

Fig. 8 shows a flowchart illustrating an inbound trade activity message receiving process in accordance with the present invention;

Fig. 9 shows a flowchart illustrating an outbound trade activity message transmitting process in accordance with the present invention; and

Fig. 10 shows a flowchart illustrating a representative trade ownership transfer method in accordance with the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Trade activity may be generated in a number of ways. Generally, trade activity may be any form of financial or business transaction. For purposes of this description, trade activity is defined as any trade activity taking place over an electronic network such as a computer network, for example the Internet. Many other applicable networks exist, such as an intranet, local area networks (LANs) , wide area networks (WANs), etc.

Trade activities are generally originated at a front office, where a trade activity may be initiated by a purchase, sale, or other transaction. After being generated, a trade activity may be transmitted to a financial trading network node (if the front office trade activity generator is not a network node), or transmitted to other nodes. During the life of the transaction, the trade activity may be passed between nodes and may change ownership multiple times.

Examples of trade activities that may be accommodated by the present invention are money market transactions, derivative transactions, securities transactions, bullion transactions, and foreign exchange transactions. Money market transactions may include deposits, rollovers/renewals, fiduciary deposits, call and notice deposits, complex deposits, structured deals, certificates of deposit (CDs), BAs, commercial paper, and treasury bills. Derivative transactions may include futures, OTC options, exchange options, FRAs, FXAs, interest rate swaps, and caps, collars and floors. Securities transactions may include equities, fixed income, private loans, custody, borrowing/lending, repo ' s/reverses, floating rate notes, and mortgaged backed securities/CMOs . Bullion transactions may include purchases, sales, arbitrage (physicals and futures), loans, consignments, depository balances and transfers, and custody processing. Foreign exchange transactions may include spot exchanges, outright exchanges, and swap exchanges.

Fig. 1 shows a typical electronic network 100, having a communications link 110 extending between a plurality of computers or devices 120, 130, 140, and 150. Each of the computers 120-150 can send and receive data over the communications link 110. This is a simplified example of a network. In reality, computer networks possess many complex and often troublesome features that may hamper data transactions. First, the communications link 110 may be composed of multiple segments, such as telephone lines, fiber optic cables, dedicated data lines, etc. Therefore, each segment may have its own characteristics, and potentially may have individual data transmission protocols governing the data format. Second, each device connected to the communications link 110, such as the computers 120-150, may each have a distinct internal data format and may be using any one of a multitude of network connectivity mechanisms. As a result, communications between individual computers or nodes (any computer or device on the network) is not always successful. These variations in network hardware and software may lead to failures to establish communication, loss of established communication, erratic communication (including slow communication), loss of data, etc. Ideally, all computers and devices in a network should be able to communicate without errors, but in reality the large variety of hardware and software types mean that no singular standard governs electronic data transmission, and as a result errors may occur.

Data communications standards and protocols exist and are widely used. Examples are Transmission Control Protocol/Internet Protocol (TCP/IP), Internet Protocol (IP), UDP/IP Protocol, Fiber Channel, X.25, Frame Relay, etc. While these protocols generally ensure reliable data communications, they are typically employed in conjunction with a wide variety of data-generating software. The data therefore may not be in a format usable by both the sending and receiving devices. The present invention addresses this problem by providing a financial trading network node having standardized software. The financial trading network node software of the present invention operates each node in an identical fashion, thereby eliminating the differences in data at the sending and receiving devices. The financial trading network communications protocol thus ensures that data sent between nodes conforms to a known and expected form. This is a need and purpose behind the present invention.

Fig. 2 shows an embodiment of a financial trading network of the present invention employing a general network 155. The financial trading network of the present invention is a plurality of nodes 163 on the general network 155 that communicate to accomplish a task or tasks.

The financial trading network of this invention allows a trade to be modified in multiple locations (e.g. , by several different network nodes), without causing or creating multiple versions of the trade. As is described in more detail below, this trade modification is achieved by using the concept of trade ownership (i.e. , a node "owns" a trade) . Thus, the present invention permits a trade activity to be created at a Singapore node 161, and subsequently transferred to a London node 164 for further processing (London and Singapore are examples, and not necessarily actual nodes); or a static local data activity to be created at the Singapore node 161, transferred to and stored in a node designated as the centralized static data repository node 166, and later transferred to a compliance and audit node 169 for audit processing - all with efficiency and accuracy. Thus different functions are permitted to be seamlessly split across locations and time zones, and scaled to meet each location's business requirements.

In short, the present invention, therefore, permits each trading support site to publish and subscribe to the information it needs to fulfill its role, whatever that role may be. When a sales desk publishes a trade, for example, several sites (nodes) can be listening out for the trade details, each with a different task to perform after acquiring "ownership" of the trade.

A typical computer network, such as the Internet, for example, has what is called a stratified architecture. A typical network architecture employs, for example, a TCP/IP message communications protocol having multiple transport layers. The TCP/IP protocol is designed to transmit data across packet-switched networks. In order to prevent large messages from unnecessarily congesting packet networks, messages are broken into multiple small pieces, called packets, transmitted across the network, and then re-assembled at the destination. A packet is a block of data that contains within it the necessary addressing and transmission information so that the message data can be delivered to a desired destination. A packet-switched network uses the addressing information to switch the packet from network to network as the packet moves toward its destination.

According to a preferred embodiment of the invention, the message data and therefore the user-generated data layer are formed substantially of a financial trading network deal record. A trade deal record will consist of all the details concerning the trade (trade data) . This trade data is used to form a trade message. Figs. 3A and 3B show representative trade entry screens that may be used to enter data to form a trade message. A trade message that is sent between nodes contains the data that exactly describe the transaction. The trade data which forms the trade message can include both active (dynamic) trade activity data and/or static local data. In creating a trade message to be used in the network node processes of the present invention, the active trade activity data is obtained from a trade database in a node, whereas the static data is obtained from a local (or supporting) database in the node. The trade data which forms the trade message is organized into unique fields - these can include trade activity fields and/or static data fields. The fields are grouped in several different categories; some of the overall categories are (but not limited to) Common Data, Product Specific, Macro Specific, Settlement Instruction, and Audit fields. The Common Data category contains fields common to all products, for example, System Number, Counterparty and Dealer. The Product Specific category includes fields unique to a product, for example, the Principal field is a field in this category for a Spot trade, but not for a Deposit. The Macro Specific category includes fields unique to a linked group of trades, such as Contract Number, FOMAC CCY1, and FOMAC CCY1 to CCY2 Spot rate. The Settlement Instruction category comprises one or more groups of fields that identifies what to when the trade settles, e.g. , PAY TO Location, PAY FROM Location, REC AT Location. The audit fields category is used to trace changes to the trade, and contains fields such as Created By, Enriched By, Released By and Activity Indicator.

Some examples of trade activity fields (comprising active trade activity data) are:

Common Data

System Number NA123456

Counterparty CHASE/NYC

Dealer PERSONA Product Specific

Principal 25,000,000.00

Quantity 10,000 Macro Specific

Contract Number RT-00001281

FOMAC CCY1 DEM

FUMAC CCY1 to CCY2 Spot rate 2.341 Settlement Instruction

PAY to location CHASE/LDN

PAY from location BARCLAYS/LDN

REC at location BARCLAYS/NYC Audit

Created by PERSONB

Enriched by PERSONC

Released by PERSOND

Activity indicator 9

Some examples of static data fields are: INSTRUMENT - TYPE FX INSTRUMENT - CODE CAD

INSTRUMENT - DESCRIPTION Canadian Dollars

INSTRUMENT - SF - SHIFT - DECIMAL 2

Example data fields for a particular Spot type trade, one of the many product types supported by the present invention, could include: Trade Date, Instrument, Value Date, Trade Rate, and System Number (a unique number assigned to each trade) . It should be understood that the data fields may be deleted from or added to as necessary, and the data may change as needed.

In a preferred embodiment of the present invention, the TCP/IP and UDP/IP communications protocols are employed, but alternatively other communications protocols such as SNA, X.25 or Frame Relay may be used. The data layer employs the FINANCIAL TRADING NETWORK™ communications protocol available from OMR Systems Corporation, Skillman, New Jersey 08558. The modular architecture of the financial trading network processes, however, allows use of any third party middleware software which can provide a reliable transport mechanism over a standard TCP/IP interface with minimum modifications.

Fig. 4A illustrates a general data organization of a financial trading network communications message. The financial trading network communications message has a header 410 and a message body 420. The header 410 contains a message length field (the length of the complete message) , a message type field, a data buffer length field (size of the trade data) , and an acknowledgment (ACK) buffer length field. The message body 420 contains the trade data that is being transmitted. The data arrangement of the header 410 will be recognized by any financial trading network node on the financial trading network. The financial trading network communication message therefore allows each node to receive data in an expected form.

Fig. 4B illustrates a general data organization of a financial trading network acknowledgment (ACK) message. The ACK message is used to acknowledge the receipt of a trade message. The ACK message therefore insures communications reliability by finalizing a communications transaction. The ACK message contains an ACK message header 460 and an ACK record buffer 470. The ACK message header 460 contains an ACK message length field, an ACK message type field, and an ACK length field.

Fig. 5 shows a financial trading network node 500 of the present invention. As indicated above, the financial trading network nodes of this invention perform inbound and outbound processing on both active trade activity data and static local data. For simplicity of description, the network node of Fig. 5 shows the inbound and outbound processing elements in terms of processing active trade activity data. The invention is, however, not limited to processing active trade activity data, but also includes the node's separate processing of static local data. The interconnection and processing steps described below in terms of trade activity data processing are substantially the same for static local data processing and should be viewed in that context.

The computer network node 500 of Fig. 5 includes a network interface 508, a network monitor 511, a message activity file 514, an inbound trade activity processor 520, an event flag 525, a background processor 529, an outbound trade activity processor 533, a checkpoint file 536, a trades database processor 539, a node identifier 541, an authorization file 544, a trades database 547, a trades ownership database 552, a nodes location database 556 and a collision queue 557. (It can be seen that if the node of Fig. 5 was processing static local data, the inbound and outbound processors (520, 533) would be termed inbound and outbound static local data processors; and trade database 541 would instead be a local database accessed by a local database processor. )

In Figure 5, the network interface 508 is connected to a network 503. The network 503 may be a TCP/IP based network or any type of general purpose network, such as, for example, the Internet, a telephone line, an intranet, a local area network (LAN), a wide area network (WAN), etc. The network monitor 511 is connected to the network interface 508, and is further connected to the message activity log 514. Message activity log 514 is also connected to background processor 529 and will contain information about the trade activity over the financial trading network and the relevant protocol information. Inbound trade activity processor 520 is connected to network interface 508, outbound/inbound state 527, and trades database processor 539. Inbound trade activity processor 520 is also connected to event flag 525 (connection not shown) , to the extent that said processor thereby receives a signal instructing a shut down. Background processor 529 is connected to network interface 508 and is further connected to outbound/inbound state 527 and trades database 547. The outbound trade activity processor 533 is connected to network interface 508 and is further connected to checkpoint file 536, trades database processor 539, event flag 525 and message activity log 514. The trades database processor 539 is further connected to the node identifier 541, authorization file 544, trades database 547, and event flag 525. The trades database 547 includes trades ownership database 552 and nodes location database 556.

The trades database 547 stores all trade activity information for each trade activity message received by the node and each trade activity owned by the node. In addition, the trades database 547 in one embodiment includes the nodes location database 556 and the trades ownership database 552, but alternatively the nodes location database 556 and the trades ownership database 552 may be separate databases. The nodes location database 556 contains node identifiers of substantially all of the other nodes in the financial trading network, and provides a node location as needed when generating or receiving a trade activity message.

The trades ownership database 552 may be used to store the ownership status of any trade activity that the node has participated in. The trades ownership database 552 may be used to obtain the next owner of any trade activity during processing .

The network interface 508 connects to the network 503 and transmits and receives messages therefrom. In the preferred embodiment, the network interface 508 is a hardware/software combination that is capable of autonomously handling network communications over a computer network employing, for example, a TCP/IP network communications protocol. In an alternate embodiment, an external network interface may be employed. The message activity log 514 contains a log of all messages sent or received by a network node as well as updated acknowledgment information for each transmission of a message. The message activity log 514 may be used to investigate transmission errors, to manually resend a transmission if the transmission was not successful, to audit message traffic or trade activity, or to create a paper record of all transactions occurring on the network node 500.

The network monitor 511 monitors all inbound and outbound message traffic of the network node 500 and can request statistics from any node on the logical financial trading network. The network monitor 511, when used in conjunction with a display device, such as, for example, a computer monitor, can display global views of all network nodes or specific views of individual network nodes. The network monitor may display, for example, information in the form of text, tables, graphs, maps, etc.

The inbound trade activity processor 520 receives trade activity messages from the network interface 508, removes the financial trading network communications protocol, and passes the trade activity data to the trades database processor 539. To complete the inbound trade activity message transaction, the acknowledgment message is returned to the sender.

The outbound trade activity processor 533, in response to an activity event flag signal (which in the preferred embodiment is asynchronous) , receives trade activity information from the trades database processor 539 and prepares an outbound trade activity message containing the trade activity information. The outbound trade activity processor 533 determines whether an acknowledgment message has been received and puts a copy of each outbound trade activity message into message activity log 514 and updates message activity log 514 with respect to whether an acknowledgment message was received. The outbound trade activity processor 533 also puts the latest successfully processed trade information into the checkpoint file 536. The checkpoint file 536 therefore contains the information about the last successfully processed deal by the outbound trade activity processor 533. The checkpoint file 536 may be used by the network node 500 for configuration purposes during system startup or for crash recovery. It should be recognized that although the above processes are described as event-driven, the invention also contemplates real-time operation, including both event-driven and batch-driven operation.

The trades database processor 539 regulates all trade activities entering or leaving the network node 500. The trades database processor 539 receives inbound trade activity messages from the inbound trade activity processor 520, compares the node identifier in the received message to the nodes location database 556 to identify the source of the message, and stores the associated trade activity data in the trades database 547. The trades database processor 539 may access the collision queue 557 to check whether a collision has occurred or transaction may be performed.

The authorization file 544 regulates where a trade activity will be performed (on which nodes), for which products it will be performed (i.e. , which type of trading instrument such as spot, deposit, security, bullion, interest rate swap, etc.), and for which customers or clients it will be performed. Each network node 500 will have an authorization file 544.

The trades database processor 539 may generate an outbound message in response to several events (the inbound trade activity processor 520 having produced the message to be sent as a data response to a received message) . These events can include a manual input by an operator, an internal condition such as a need for information from another node, or an ownership transfer need. When the trades database processor 539 is required to send a trade activity message, the trade activity data is retrieved from the trades database 547 and passed to the outbound trade activity processor 533. The node identifier 541 is also communicated to the outbound trade activity processor 533.

The background processor 529 has several functions. First, the background processor 529 oversees ownership transfers between nodes. Second, the background processor 529 generates and transmits node statistics for the network node 500. The statistics may be sent to a specific node or all nodes, and may be sent periodically or on demand. Such statistics may include, for example, information concerning which nodes are currently online and functioning, traffic levels, etc. The background processor 529 also oversees trade ownership and trade ownership transfers.

The network node 500 as described above implements a uniform and scalable financial trading network that facilitates robust operations and allows for easy expansion. The network node 500 also allows the use of industry standard software elements. This may be accomplished without the need for hardware to be uniform within the financial trading network.

One standard software application that may be used in a network node 500 is the TRADING ASSISTANT® software, which performs a variety of trade activity functions. The TRADING ASSISTANT® is available from OMR Systems Corporation, Skillman, New Jersey, 08558.

Representative trade activity functions performed by TRADING ASSISTANT® include, for example, trade processing, deal control, accounting interface, advice control, balance updates, cash flow control, corporate action control, static database updates, data feeds, pre end-of-day, daily operations, and file maintenance. Representative trade processing functions include add, enrich, release, Change/cancel, confirm match, inquire, swap unwind, close fails, exercise/assign options, renew deposits, input FRA/FXA fixings, CNT revision, and phone confirmation operations. Representative deal control functions include deal receiver, trade generation, and auto-trade release operations. Representative accounting interface functions include UI and live UI operations. Representative advice control functions include auto, custom interface, fax, mail, S.W.I.F.T. messages (developed by Society for Worldwide Interbank Financial Telecommunications S.C., Belgium), and Telex operations. Representative balance update functions include FX, Nosrro, currency, position, and securities operations. Representative cash flow control functions include cash flow generation and rate settings and log operations. Representative data feed functions include corporate action events and customer information operations. Representative pre end-of-day functions include pre end-of-day validation, specify purge criteria, and restore to before pre end-of-day operations. Representative daily operations functions include pre new day, new day, and end of day operations. Representative file maintenance operations include restore to before new day, restore to before last end-of-day, purges and condenses, and recreation of balance records operations.

Other features may be incorporated into each network node 500, such as, for example, data encryption, certified message delivery, etc. Fig. 6 illustrates trade ownership transfers. The first ownership transfer 610 is a single ownership transfer request, including an ownership transfer request and a granting of ownership by the current owner. The second ownership transfer 620 shows how multiple ownership requests receive multiple acknowledgments. The third ownership transfer 630 shows an automatic recovery process conducted when the ownership request is not successfully completed. The fourth ownership transfer 640 shows a manual recovery process conducted when the ownership request is not successfully completed. The fourth ownership transfer 640 includes a manually resent ownership request that is prompted by a lack of response to the original ownership transfer request.

In the present invention, as mentioned above, a trade may be modified by several different financial trading network nodes. This is referred to as distributed trade modification. The distributed trade modification is achieved by using the concept of trade ownership (discussed further in conjunction with Fig. 10 below) . A trade can only be changed on the financial trading network node that owns it. If another node wants to change a trade, it must first become the owner. To get trade ownership, a request must be made to the node that owns the trade. The request will either be granted or denied. Once a node becomes the owner, the trade is then changed and the trade activity processor 533 updates the other nodes. The request will be denied if either the owning node is unreachable or the owning node has already transferred ownership to another node. Only two nodes participate in the ownership transferal process. This reduces the dependencies of nodes on each other (no centralized resource) and improves the usability of the system.

The modification of trades is optimized by automatically transferring trade ownership during trade processing. In a preferred embodiment, network nodes are configured to perform specific business functions. For instance, a first node may add trades while a second node may enrich and release trades. The trades database processor 539 of a node determines which node is the next trade owner by using ownership database 552. Therefore, when a first node adds a trade, a second node may automatically become the owning node. This streamlines processing because the majority of modifications will occur on the node with trade ownership. Only the exceptions to this scheme will require ownership transferal.

Fig. 7A shows a global map monitor screen feature of the network monitor 511, illustrating a network nodes display for the financial trading network. Fig. 7B shows a nodes statistics monitor screen feature of the network monitor 511, illustrating an operating statistics display for the financial trading network. Fig. 7C shows a local node statistics screen feature in bar graph form, illustrating another embodiment of the operating statistics display. Fig. 7D shows a tabular data embodiment of the operating statistics display.

Fig. 8 shows a flowchart 800 of the present invention illustrating a trade activity message receiving process. (Again, for simplicity of description this inbound message processing is described in terms of active trade activity data in a trade message; however, essentially the same process is also performed on static local data contained in trade messages, employing a local database and database processor.) In step 810, the method determines whether a trade activity message has been received. If a trade activity message has been received, the method proceeds to step 820, else it branches back to step 810 until a message is received. In step 820, network communications headers are removed from the inbound trade activity message. Although this is shown as a step in the inbound process, it should be understood that removal is automatically performed by a network communications handler. In the present invention, this may be accomplished by the network interface 508 (Fig. 5) or alternatively by a separate hardware/software combination external to the financial trading network node 500.

In step 830, the financial trading network message header is removed from the inbound trade activity message.

In step 840, the trade activity contained within the trade activity message is stored in the trades database 547.

In step 850, an acknowledgment message is transmitted to the financial trading network node that sent the trade activity message. The acknowledgment message informs the sending node that the message was properly received. If the sending node does not receive an acknowledgment message, the sending node may optionally resend the original message or log an error. In addition, an operator may manually resend the message.

A further feature of the trade activity message receiving process of Fig. 8 is a collision detection capability (not shown) . Collisions are defined as changes to data applied out of sequence. In order to guarantee correctness of the trade database on each network node, all updates to trades must be applied in the same progression. There are situations that will occur, for example, due to network latency between nodes, which can cause the updates to be applied out of order. The collision detection senses this and the collisions can be automatically resolved. In a preferred embodiment, collision detection consists of comparing current audit fields of an incoming trade with the previous audit fields of the trade database. If the two audit fields do not match, a collision is detected. A collision is held in a collision queue 557 until it is resolved (as described below) .

In a preferred embodiment, the inbound trade activity processor 520 may attempt to resolve a collision by performing the following steps after each inbound trade is successfully processed. The inbound trade activity processor 520 looks in the collision queue 557 for a trade that has a system number and current audit fields that match the system number and previous audit fields of the trade that was just successfully processed. If found, the trade activity is processed into the trades database to resolve the collision. Multiple collisions are resolved by repetitively applying the comparison logic and processing matches until all of the collisions have been resolved.

In a first alternate embodiment, collisions may be prevented by not allowing predetermined trade activity functions to operate on a trade activity except for one owning node. This embodiment eliminates collisions because functions that may cause collisions are never shared across nodes. In a second alternate embodiment, a trade activity function will only be processed if the record is in synch with what is termed the financial trading network approved version. The financial trading network approved version will be locked when a change is being made in a node. The change made by the locking node will then become the financial trading network approved version. Fig. 9 shows a flowchart 900 of the present invention illustrating a trade activity message transmitting process. (As discussed above in connection with Fig. 5 and Fig. 8, the same process described is applied to static local data in trade messages.) In step 910, the method determines whether a signal for generating an outbound trade activity message has been received. As discussed in conjunction with Fig. 5, the signal may be generated due to several different occurrences and by different sources. A message generation signal may be due to a manual input by an operator, due to local trading activity, due to an internal condition such as a need for information from another node, or an ownership transfer need. Therefore, if a signal is received, the method proceeds to step 920, else it branches to step 980.

In step 920, a trade activity is obtained from the trades database 547. In addition, other information may be incorporated into the outbound trade activity message, such as, for example, the node identifier and the ownership status of the trade activity.

In step 930, the location of a target node or nodes is retrieved from the nodes location database 556. In step 940, the trade activity is inserted into a financial trading network communications header to form a trade activity message.

In step 950, the trade activity message and the financial trading network communications header are further inserted into one or more network communications headers. As previously discussed in conjunction with Fig. 5, various type communications headers may be used as appropriate. Although this is shown as a step in the outbound process, it should be understood that addition of network communications headers is automatically performed by a network communications handler. In the present invention, this may be accomplished by the network interface 508 or alternatively by a separate hardware/software combination external to the financial trading network node 500. In step 960, the trade activity message or the trade activity information within the trade activity message may be stored in the checkpoint file 536. This information is a record of the most recent transaction, and is stored for system startup or crash recovery. In step 970, the outbound trade activity message created in steps 920-950 is transmitted over the network 503 to all of the other subscribing financial trading network nodes defined in node location database 556 (Fig. 5).

In step 980, the method determines whether an acknowledgment message has been received from the other nodes. If so, then step 990 updates the message activity log 514 (Fig. 5), else it branches back to step 910.

Fig. 10 shows a flowchart 1000 of the present invention illustrating an ownership transfer method of the financial trading network. The flowchart 1000 may be viewed in conjunction with the ownership transfer protocol diagram of Fig. 6.

In step 1010, a requester node sends an ownership transfer request message to an owning node (i.e. , the node that owns the desired trade activity) . In step 1020, the method determines whether the ownership transfer request message was received by the owning node. If it was received, the method branches to step 1030, else it branches to step 1060.

In step 1030, the method determines whether the ownership transfer request can be granted. If ownership can be transferred, the method proceeds to step 1050, else the method branches to step 1040.

In step 1050, the owning node sends an ownership granted message to the requester node. The ownership granted message transfers the ownership of a trade activity from the owning node to the requester node. In step 1040, the owning node sends an ownership denied message to the requester node. The ownership denied message prevents the requestor node from changing the trade.

In step 1060, the method, in the case of a failure to receive the ownership transfer request message, determines if the failure is due to a crash by the owning node. If a crash has occurred, the method proceeds to step 1070, else it branches to step 1080.

In step 1070, the ownership transfer request message is re-delivered to the owning node. This may be done by the network interface 508. After step 1070, the method branches back to step 1020.

In step 1080, a new ownership transfer request message is sent by the requester node to the owning node. This may be performed by a human operator in conjunction with the network monitor 511. After step 1080, the method branches back to step 1020.

While the invention has been described in detail above, the invention is not intended to be limited to the specific embodiments as described. It is evident that those skilled in the art may now make numerous uses and modifications of and departures from the specific embodiments described herein without departing from the inventive concepts.

Claims

What is claimed is: 1. A computer network node for a financial trading network, comprising: a database capable of storing trade data; a network interface for connecting said network node to a computer network over which a trade message may be transmitted or received; a unique node identifier for said network node; an inbound trade processor connected to said network interface, with said inbound trade processor capable of receiving an inbound trade message and capable of extracting inbound trade data included in said trade message; an outbound trade processor connected to said network interface, with said outbound trade processor capable of creating an outbound trade message, and capable of inserting a trade message into an appropriate network communications protocol including a financial trading network communications protocol and said node identifier and communicating said outbound trade message to said network interface; a database processor for controlling outputs from said database and capable of creating and sending an outbound trade message to said outbound trade processor; a background processor connected to said database, and connected to said network interface, being capable of sending and receiving an ownership transfer message and reconciling said ownership transfer message with an ownership status contained in said database.

2. The network node of claim 1, wherein a network monitor is connected to said network and capable of obtaining and displaying information on a status of similar nodes on said financial trading network;

3. The network node of claim 2, wherein said network monitor further includes a message activity log for logging an inbound or an outbound trade message.

4. The network node of claim 1, wherein said financial trading network protocol comprises: a message header comprising a message length data, a message type data, a data buffer length data, and an acknowledge buffer length data; and a message body comprising a trade data buffer and an acknowledge buffer.

5. The network node of claim 4, wherein a network node that is not a financial trading network node can communicate with said network node using said financial trading network protocol.

6. The network node of claim 4, wherein said financial trading network protocol can be nested in a general network protocol.

7. The network node of claim 4, wherein said financial trading network protocol can be nested in a general network protocol.

8. The network node of claim 1, wherein said network node sends an acknowledgment message in response to a successful receipt of said inbound trade message.

9. The network node of claim 1, wherein said database further contains a nodes location database.

10. The network node of claim 1, wherein said database further contains a trades ownership database.

11. The network node of claim 1, wherein said network node further includes a checkpoint file connected to said outbound trade processor, with said checkpoint file being capable of storing trade information about a last successfully processed deal by said outbound trade processor.

12. The network node of claim 11, wherein said trade information contained in said checkpoint file can be used during startup of said network node.

13. The network node of claim 11, wherein said trade information contained in said checkpoint file can be used for crash recovery.

14. The network node of claim 1, wherein said background processor is further capable of comparing an ownership status of an inbound trade message and an ownership status contained in said database and thereupon transmitting an ownership transfer message over said network if said inbound trade message and said database contain different ownerships.

15. The network node of claim 1, wherein said trade message comprises common data fields, product specific data fields, macro specific data fields, settlement instruction data fields, and audit data fields.

16. The network node of claim 1, wherein said trade message comprises both active trade activity data fields and static local data fields.

17. The network node of claim 1, wherein said trade message includes active trade activity data, said inbound trade message includes inbound active trade activity data, said database is a trades database, and said outbound trade message includes outbound active trade activity data.

18. The network node of claim 1, which includes a first database capable of storing active trade activity data and a second database capable of storing static local data, and wherein said trade messages include both active trade activity data and static local data, and wherein said database processor is capable of controlling outputs from said first and second databases; and said background processor is connected to said first and second databases and is capable of sending and receiving an ownership transfer message and reconciling said ownership transfer message with an ownership status contained in said first database.

19. A financial trading network node process for receiving inbound trade messages over a computer network, comprising the steps of: receiving an inbound trade message over a network at a first node; removing a financial trading network communications protocol from said inbound trade message; storing a trade activity contained in said inbound trade activity message in a database; and sending an acknowledge message corresponding to receipt of said inbound trade message.

20. The financial trading network node process of claim 19, wherein each said financial trading network node has a unique identifier.

21. The financial trading network node process of claim 19, wherein collisions between messages on said financial trading network are detected.

22. The financial trading network node process of claim 21, wherein a financial trading network node adds to a collision resolution queue of said inbound trade message if a collision is detected.

23. The financial trading network node process of claim 22, wherein the adds to said collision resolution queue are checked after every trade message is processed, and any collisions for said trade message are then resolved.

24. A financial trading network node process for generating outbound financial trade messages over a computer network, comprising the steps of: receiving in a first financial trading network node a signal to transmit a trade message to a second financial trading network node; creating a trade message by obtaining trade data from a database in said first financial trading network node; retrieving a target node location or locations from a nodes location database and placing said target node location or locations in said trade message; inserting said trade message into a financial trading network communications protocol; inserting said trade message and said financial trading network communications protocol into a network communications protocol; transmitting a message including said trade message, said financial trading network communications protocol, and said network communications protocol over said computer network, and receiving in a first financial trading network node an acknowledgment message.

25. The financial trading network node process of claim 24, wherein during the transmitting step the outbound trade message is stored in a message activity log file and the message activity log is updated with the acknowledgment message.

26. The financial trading network node process of claim 24, wherein during the transmitting step the latest trade message is stored in a checkpoint file.

27. The financial trading network node process of claim 24, wherein said checkpoint file may be used for startup of said financial trading network node.

28. The financial trading network node process of claim 24, wherein said checkpoint file may be used for crash recovery of said financial trading network node.

29. The financial trading network node process of claim 24, wherein said signal of said receiving step is an event flag.

30. The financial trading network node process of claim 24, wherein each said financial trading network node has a unique identifier.

31. The financial trading network node process of claim 24, wherein an operator can manually resend an outbound financial trade message.

32. The financial trading network node process of claim 24, wherein trade ownership can only be changed by a node that owns said trade ownership.

33. The financial trading network node process of claim 24, wherein a message activity log file containing copies of all outbound trade messages can be used to monitor financial trading network message traffic.

34. The financial trading network node process of claim 24, which includes trade ownership status transactions and wherein said ownership status transactions are serialized to facilitate ownership resolution when multiple transactions occur for a trade.

35. The financial trading network node process of claim 24, wherein said signal to transmit a trade message is a signal to transmit the trade message to all other nodes in the financial trading network, and wherein the transmitting step transmits the message to all of said other nodes, and wherein the acknowledgment message received in the first financial trading network node is received from all other financial trading network nodes.

36. An ownership transfer process for a financial trading network, comprising the steps of: sending an ownership transfer request message from a requestor node to an owning node; determining if the ownership transfer request message from the requestor node was received by the owning node; if the ownership transfer request message was received by the owning node, determining whether the request can be granted and sending an ownership granted message to the requestor node if the request can be granted, and sending an ownership denied message to the requestor node if the request cannot be granted; if said ownership transfer request message was not received by said owning node, determining if said owning node crashed; re-delivering said ownership transfer request message to said owning node if said ownership transfer was not received by said owning node and said owning node had crashed; manually resending said ownership transfer request message if said ownership transfer was not received by said owning node and said owning node did not crash; and sending a second ownership transfer message from said owning node to said requester node if a second ownership transfer request message is received by said owning node before said ownership transfer message is sent by said owning node.

37. The ownership transfer process of claim 36, wherein said re-delivering step is performed by a network interface.

38. The ownership transfer process of claim 36, wherein said manually resending step is performed by a human operator.