RELATED APPLICATIONS This application is a continuation of U.S. patent application Ser. No. 10/741,735, filed Dec. 18, 2003, which is a divisional of U.S. patent application Ser. No. 10/005,609, filed Nov. 7, 2001 and is also related to and claims priority upon U.S. provisional patent application Ser. No. 60/249,796 filed Nov. 17, 2000 and U.S. provisional patent application Ser. No. 60/288,310 filed May 2, 2001, all of which patent applications are hereby incorporated by reference in their entireties into the present patent application.
TECHNICAL FIELD This invention pertains to the field of global electronic trading of commodities and financial instruments.
BACKGROUND ART Wright, Ben, “Unlocking the C2C forex riddle”, euromoney.com, Jul. 25, 2001, U.K., provides a general discussion of some of the business aspects of the present invention.
Morris, Jennifer, “Forex goes into future shock”,Euromoney, October 2001, gives a general description of several computerized foreign exchange platforms, including one described in the present patent application.
Ahuja, R. K., Magnanti, T. L., and Orlin, J. B.,Network Flows, Theory, Algorithms, and Applications,Chapters 7 and 9 (Prentice-Hall, Inc. 1993), U.S.A., sets forth some algorithms that may be useful in implementing the present invention.
U.S. Pat. No. 5,375,055 discloses a relatively simple trading system that is capable of implementing only single-hop trades. On the other hand, the present invention can accommodate multi-hop trades. Further, in U.S. Pat. No. 5,375,055, the user is given information that suggests to him that he can take a trade when he may not have enough credit to take the whole trade. In the present invention, on the other hand, if only part of a trade can be executed, that information is given to the user; the user knows that he has enough credit to execute at least the best bid and best offer that are displayed on his computer.
An even simpler trading system is disclosed inEuropean patent application 0 411 748 A2 and in grantedEuropean patents 0 399 850 B1 and 0 407 026 B1, all three of which are assigned to Reuters Limited. These Reuters documents describe a system in which information concerning a potential trade is displayed even if the user can't execute it at all. In the present invention, such a potential trade would not be displayed at all. Furthermore, the only credit limits that can be accommodated in the Reuters system are volume limits for the purposes of limiting settlement risk. In the present invention, any agent may set credit limits in multiple ways so as to limit not only settlement risk (measured both by individual instrument volumes and by notional absolute values) but also exposure risk. Furthermore, the Reuters keystations require a human operator. In the present invention, on the other hand, an API (application programming interface) enables any participant to develop programs which partially or fully automate the trading process.
DISCLOSURE OF INVENTION Methods, systems, and computer readable media for facilitating trading two items (L,Q) from the group of items comprising commodities and financial instruments. At least two agents (2) want to trade some instrument L at some price quoted in terms of another instrument Q. The exchange of L and Q is itself a financial instrument, which is referred to as a traded instrument. A trading channel (3) between the two agents (2) allows for the execution of trades. Associated with each channel (3) are trading limits configured by the two agents (2) in order to limit risk. A central computer (1) coupled to the two agents (2) is adapted to convey to each agent (2) current tradable prices and available volumes for the exchange of L for Q and for the exchange of Q for L, taking into account the channel (3) trading limits. The central computer (1) facilitates trades that occur across a single trading channel (3) and trades that require the utilization of multiple trading channels (3).
BRIEF DESCRIPTION OF THE DRAWINGS These and other more detailed and specific objects and features of the present invention are more fully disclosed in the following specification, reference being had to the accompanying drawings, in which:
FIG. 1 is a block diagram illustrating a “type zero” trading system embodiment of the present invention.
FIG. 2 is a block diagram illustrating a “type 1” trading system embodiment of the present invention.
FIG. 3 is a block diagram illustrating a “type 2” trading system embodiment of the present invention.
FIG. 4 is a block diagram illustrating a “type 2” back-to-back trade using the present invention.
FIG. 5 is a block diagram illustrating an interlocking network oftype 1 andtype 2 atomic units.
FIG. 6 is a schematic diagram illustrating trading limits for a traded instrument being traded between fouragents4,5 using threetrading channels3.
FIG. 7 is a block diagram illustrating various ways thatagents2 can be connected to enable them to use the present invention.
FIG. 8 is a timeline illustrating an embodiment of the matching process used in the present invention.
FIGS. 9A and 9B are a block diagram illustrating an embodiment of the border outpost process of the present invention.
FIG. 10 is a deal fulfillment graph.
FIG. 11 is a flow diagram illustrating the sequence of screen shots appearing on the computer of anagent2 using the present invention.
FIG. 12 illustrates a log-inscreen21 of the computer of anagent2.
FIG. 13 illustrates a custom limit order book overview window24 (multiple traded instruments).
FIG. 14 illustrates a custom limit order book window25 (single traded instrument).
FIG. 15 illustrates anet exposure monitor35.
FIG. 16 illustrates abalance sheet window36.
FIG. 17 illustrates an open order overview andmanagement window33.
FIG. 18 illustrates a bidcreation dialog box28.
FIG. 19 illustrates an offercreation dialog box29.
FIG. 20 illustrates a buy (immediate execution bid)dialog box30.
FIG. 21 illustrates a sell (immediate execution offer)dialog box31.
FIG. 22 is a flow diagram illustrating the computation of a customlimit order book24,25.
FIG. 23 is a flow diagram illustrating the computation of multi-hop flow limits for a single traded instrument among all accounts.
FIG. 24 is a flow diagram illustrating computation of a directed graph of single-hop flow limits for a single traded instrument among all accounts.
FIGS. 25A and 25B are a flow diagram illustrating computation of minimum and maximum excursions for a single account A and a single traded instrument.
FIG. 26 is a flow diagram illustrating computation of a position limit for a lot instrument L.
FIG. 27 is a flow diagram illustrating computation of a position limit for a quoted instrument Q.
FIG. 28 is a flow diagram illustrating computation of a volume limit for a lot instrument L.
FIG. 29 is a flow diagram illustrating computation of a volume limit for a quoted instrument Q.
FIG. 30 is a flow diagram illustrating computation of a notional position limit.
FIG. 31 is a flow diagram illustrating computation of a notional volume limit.
FIG. 32 is a flow diagram illustrating computation of a traded instrument L:Q position limit.
FIG. 33 is a flow diagram illustrating computation of a traded instrument L:Q volume limit.
FIG. 34 is a flow diagram illustrating reporting bycomputer1 of a single-hop trade.
FIG. 35 is a flow diagram illustrating reporting bycomputer1 of a multi-hop trade.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The present invention enables an arbitrary number ofagents2 of arbitrary type (such as corporate treasuries, hedge funds, mutual funds and other collective investment schemes, banks and other financial institutions, and other institutions or persons) to trade commodities and financial instrument pairs directly amongst each other (thus facilitating client-to-client, or C2C trading) by making orders to their peers to buy and sell the traded instrument pairs over “credit atomic units” and “credit molecules”.
By way of example, the application highlighted most often herein is the spot foreign exchange (spot FX) market, but it must be understood that the present invention has applicability to trading in any type of over-the-counter commodity or financial instrument, including physical commodities, energy products (oil, gas, electricity), insurance and reinsurance products, debt instruments, other foreign exchange products (swaps), and compound instruments and other derivatives composed or derived from these instruments.
A trade is the exchange of a lot of instrument L for a quoted instrument Q. The lot instrument L is traded in an integral multiple of a fixed quantity refered to as the lot size. The quoted instrument Q is traded in a quantity determined by the quantity of the lot instrument L and the price. The price is expressed as Q per L. In a spot FX trade, the lot instrument L and the quoted instrument Q are implicit contracts for delivery of a currency on the “spot” date (typically two business days after the trade date).
In the present specification and claims, entities that wish to trade with each other are referred to as “agents”2.Agents2 that extend credit toother agents2 are referred to as credit-extendingagents5.Agents2 that do not extend credit toother agents2 are referred to asclients4 or non-credit-extendingagents4.
Twoagents2 may havedirect trading channels3 between them, where thetrading channels3 correspond to credit extended from one credit-extending agent5 (typically a bank, financial institution, or any clearing entity) to theother agent2.Trading channels3 are typically secured via placement of collateral (margin) or other form of trust by anagent2 with the credit-extendingagent5. Typically,trading channels3 amongst credit-extendingagents5 and non-credit-extendingagents4 already exist. In the spot FX market, thesetrading channels3 are refered to as trading accounts. In the case that two credit-extendingagents5 have atrading channel3 between them, only oneagent2 acts in a credit-extending capacity with regards to thattrading channel3.
Credit-extendingagents5 that allow thecentral computer1 to utilize a portion of theirtrading channels3 to allowother agents2 to trade with each other are refered to as “credit-bridging agents”5. In a preferred implementation of the present system, existing banks, financial institutions, and clearing entities are credit-bridgingagents5 as well as credit-extendingagents5; and existing trading customers of thoseinstitutions5 areclients4.
Compared with prior art systems, the present invention gives a relative advantage toclients4 compared to credit-extendingagents5, by enabling one-way or two-way orders from anyagent2 to be instantly displayed to all subscribingagents2, enabling a trade to take place at a better price, with high likelihood, than the price available toclients4 under prior art systems. The present invention brings togetherclients4 who may be naturally on opposing sides of a trade, without conventional spreads historically charged to them 4 by credit-extendingagents5 for their 5 service as middlemen. Of course, credit-extendingagents5 also benefit on occasions when they are natural sellers or buyers.
Unlike prior art systems, the present invention arranges multi-hop deals to match orders between natural buyers and sellers who need not have a direct trading relationship. For the application to spot FX trading, a multi-hop deal can be realized through real or virtual back-to-back trades by one or more credit-bridgingagents5. In terms of the underlying transfers of financial instruments, a multi-hop deal is similar to the existing practice of trade “give-ups” from one broker to another.
Unlike prior art systems, the present invention computes trading limits from not only cumulative volume but also from net position limits, where both volume and position limits may be set in terms of the traded instrument (instrument L for instrument Q), in terms of any underlying instruments to be exchanged (delivered) upon settlement (such as L individually, Q individually, or other instruments), or in terms of the notional valuations of such instruments. This allows allagents2, especially credit-bridgingagents5, to control risk far more flexibly. Limiting traded or delivered instruments' cumulative volume helps to manage settlement risk. Limiting a traded instrument's net position (net L:Q position) helps to manage market risk. Limiting a delivered underlying instrument's net position (total net L, total net Q, or some other underlying instrument's position) helps manage market and credit risk by reflecting the ultimate effect of any trade on any account's future balance sheet. The cumulative volume limits allowed by prior art systems are able to address only settlement risk concerns.
The present invention has a natural symmetry; in the preferred implementation, not only are credit-bridging agents5 (financial institutions) able to operate as market makers and post one-way (just a bid or ask) and two-way (both bid and ask) prices toagents2, butclients4 may post one-way and two-way prices to credit-bridgingagents5 andother clients4 of any other credit extending orcredit bridging agent5. This symmetry is not present in prior art trading systems.
The present invention uses acentral computer1 to calculate trading limits, to prepare customlimit order books24,25, and to match orders, but all post-trade bookkeeping and settlement is handled in a de-centralized manner by thecounterparties2 involved in each trade. Thecentral computer1 is a network of at least one physical computer acting in a closely coordinated fashion.
Everyagent2 subscribing to a system employing the present invention can be thought of as anode2 in an undirected graph (FIGS. 1-5,10). Theundirected edges3 of such graphs indicate the existence of a trading channel3 (account) between twonodes2, typically an arrangement of trading privileges and limits based on the extension of credit from onenode2 to another2 and likely backed by collateral placed by onenode2 with the other2. Somenodes5 in the graph, corresponding to credit-bridgingagents5, allow credit to be bridged, whileother nodes4 areclients4 who permanently or temporarily forbid credit bridging. For the application to spot FX trading, a credit-bridgingagent5 authorizes thecentral computer1 to initiate back-to-back spot trades, where simultaneous trades in opposite directions at the same price are made between thecredit bridging agent5 and two or moredifferent agents2, such that the net position effect to thecredit bridging agent5 is exactly zero.
For each trading channel (account)3, thecentral computer1 maintains a set of limits set by the credit-extendingagent5 and a set of limits set by the non-credit-extendingagent2. Either of these sets of limits may be empty. These limits specify maximums of cumulative volume of each traded instrument L:Q, maximum cumulative volume of an underlying instrument (e.g. L, Q, or other), maximum cumulative notional value (e.g. U.S. dollar equivalent), maximum positive or negative net position of each traded instrument L:Q, maximum positive or negative net position of the underlying instrument (e.g. L, Q, or other), and maximum absolute net notional position (e.g., U.S. dollar equivalent) value total.
For each trading channel (account)3, thecentral computer1 maintains information sufficient to compute the current value of all the quantities upon which limits may be placed. The cumulative volume values are reset to zero with some period, typically one business day, at such a time as is agreeable to both agents. It is illustrative to note that the cumulative volume values always increase toward their limit with each trade, while the net position values may be decreased back to zero or near zero and may change in sign.
Anagent2 may add, remove, or adjust any of the elements of the set of limits specified by thatagent2 at any time.
Since trading is permitted or denied based on these limit-related values, thecentral computer1 provides a way for theagents2 that are parties to an account to inform thecentral computer1 of any external activity that would affect these values, such as odd-lot trades and trades made through existing trading devices, or to simply reset all limit-related values to a predefined state.
Based on the current values of all these limit-related quantities, thecentral computer1 computes for each traded instrument L:Q a directed graph (FIG. 6) of maximum excursions. In the directed graph for each traded instrument L:Q, each directededge3 from anode2 to anothernode2 has a value that indicates, based on the current position, how many of the traded instrument L:Q may be bought by thefirst node2 from thesecond node2. There are typically directededges3 in both directions between any pair ofnodes2, since the instrument L:Q may be bought or sold. The trading limit values (maximum excursions) of these buying and sellingedges3 between twonodes2 vary from moment to moment as trades are made and/or credit limits are adjusted by eithernode2.
For all traded instruments L:Q and for allnodes2 that trade L:Q and for allother nodes2 that trade L:Q, thecentral computer1 uses the directed graph of maximum excursions (FIG. 7) to compute the maximum flow from thefirst node2 to thesecond node2. Note that this means that each pair ofnodes2 that trade L:Q will have the maximum flow between them 2 calculated in both directions.
The prior art systems could be simulated by the present invention by first eliminating the ability of anynode2 to be a credit-bridgingagent5 so that the “single-pair maximum flow” is merely the flow enabled by directededges3 connecting the pair ofnodes2 directly. Second, all trading limits by non-credit-extendingagents4 would be disabled and only cumulative volume limits on underlying instruments would be allowed for credit-extendingagents5, corresponding to limits only on settlement risk.
For purposes of illustrating the present invention, consider, for example, an agent A extending credit to agent B for the purposes of trading spot FX using the present invention, and between the U.S. dollar (USD), Euro (EUR), and Japanese Yen (JPY) in particular. Suppose agent B buys 1 lot of EUR:USD at 0.9250, then sells 1 lot of EUR:JPY at 110.25, with both trades having agent A ascounterparty2. The first trade will upon settlement result in 1,000,000 EUR received by agent B and 925,000 USD paid by agent B, while the second trade will result in 1,000,000 EUR paid by agent B and 110,250,000 JPY received by agent B. From the perspective of agent B, the account stands +1M EUR toward the EUR:USD cumulative volume limit, +1M EUR toward the EUR:USD net position limit, +1M EUR toward the EUR:JPY cumulative volume limit, −1M EUR toward the EUR:JPY net position limit, +2M EUR toward the EUR cumulative volume limit, +925,000 USD toward the USD cumulative volume limit, +110,250,000 JPY toward the JPY cumulative volume limit, ZERO with respect to the EUR net position limit, −925,000 USD toward the USD net position limit, and +110,250,000 JPY toward the JPY net position limit. Further supposing that the instrument valuations in agent B's home currency of USD are 0.9200 EUR:USD and 0.009090 JPY:USD, then the account stands (2M×0.9200+925,000+110,250,000×0.009090=) 3,767,172.50 USD toward the notional USD cumulative volume limit (useful for limiting settlement risk), and (0×0.9200+925,000+110,250,000×0.009090=) 1,927,172.34 USD toward the absolute notional net position total.
Now suppose agent B buys 1 lot of USD:JPY at 121.50, which upon settlement will result in 1,000,000 USD received and 121,500,000 JPY paid. The net single-instrument positions are now 0 EUR, 75,000 USD, and −10,250,000 JPY. Rather than delivering JPY at settlement (which will entail carrying a JPY debit balance in the account), agent B will probably choose to arrange an odd-lot deal with agent A to buy 10,250,000 JPY at a rate of, for instance, 121.40 USD:JPY, at a cost of 84,431.63 USD, resulting in final account position values of 0 EUR, −9,431.63 USD, and 0 JPY. In other words, agent B has lost 9,431.63 USD in its account with agent A once all the settlements occur.
Alternatively, agent B may choose to “roll forward” any EUR or JPY net position from the spot date to the next value date, or to any forward date by buying or selling an appropriate FX swap instrument from or to agent A.
Odd-lot spot, odd-lot forward, odd-lot swap, and deals with aspecific counterparty2 are not amenable to trading via the “limit-order book” matching system, but instead may be facilitated by thecentral computer1 through a request-for-quote mechanism. Since thecentral computer1 knows the net positions of all the accounts, it may further recommend such deals on a periodic basis, such as a particular time that bothagents2 consider to be the end of the business day for the account in question.
For the application of the present invention to markets other than spot FX, triangular interactions between traded instrument pairs are not as much a concern. The limits set by credit-extendingagents5 are handled the same way, where the limits on commodity holdings or currency payments are translated by thecentral computer1 into excursion limits (how many lots anagent2 may buy or sell) in real-time.
The present invention can be implemented in a combination of hardware, firmware, and/or software. The software can be written in any computer language, such as C, C++, Java, etc., or in a combination of computer languages. The hardware, firmware, and software provide three levels of content: a) trade screens, b) post-trade content for back offices and clearing units, and c) real-time credit management content. Through an API (application programming interface)38,agents2 can securely monitor and change in real time the credit limits they have specified for eachtrading channel3 in which they participate. (Note that the maximum flow across atrading channel3 is the minimum of the trading limits specified by the twoagents2 associated with thechannel3, so a non-credit-extendingagent4 can only further reduce the credit limits assigned by the credit-extendingagent5.)
The link between theagents2 and thecentral computer1 can be any telecommunications link—wired, wireless, Internet, private, etc.Computer1 can be located anywhere in the world. It can be mirrored for purposes of data backup, to increase throughput, or for other reasons; in that case, there is a second central computer1(2). The backup central computer1(2) is a network of at least one physical computer operating in a closely coordinated fashion. Such a backup computer1(2) is shown inFIG. 7, and insures that there will be no interruption of service with hardware, software, ornetwork6,7 failures (neither during the failure nor during the needed repairs); and further insures that the present invention has the ability to recover from a disaster event.
Since the present invention operates on a global scale, said operation has to satisfy local laws and regulations to enable the services of the present invention to be provided. The present invention is therefore designed to enable such accommodations to be made.
The present invention supports purpose-specific “atomic units” enabling trading between specific types ofagents2. The basic atomic units are “type 0”, “type 1”, and “type 2”, where a “type 0 unit” involves a single pair ofagents2 where one extends credit to the other, a “type 1 unit” involves asingle client4 trading with a collection of credit-extendingagents5, and a “type 2 unit” involves a single credit-bridgingagent5 enabling a collection of itsclients4 to trade with itself5 and with each other4.
FIG. 1 illustrates the simplest atomic unit,type 0. A first agent2(1) and a second agent2(2) wish to trade at any given time some number of round lots of instrument L in exchange for a quantity of another item Q, which we refer to as the quoted instrument or quoted currency. A trading channel3 (account) between the twoagents2 allows for the execution of the trades and settlement of the underlying instruments. Inherent in thetrading channel3 are flow limits (trading limits) on the items L,Q being traded and limits on any underlying instruments exchanged upon settlement of the L,Q trade. Acentral computer1, under control of the operator or owner of the system, is coupled to the twoagents2. Thecomputer1 is adapted to convey to eachagent2 current bid orders and offer orders originating from the other participatingagent2. The current set of tradable bid and offered prices and sizes is constrained by the trading channel's trading limits, and is preferably conveyed in the form of a customlimit order book24,25 for eachagent2, as will be more fully described below. The customlimit order book24,25 is a chart, typically displayed on the agent's computer, of a preselected number of bids and offers for the instrument pair L,Q in order of price, and within price, by date and time (oldest first).
Typically, but not necessarily, eachagent2 is coupled to thecentral computer1 when theagents2 are trading. The identification of one of the twoagents2 as the “credit-extendingagent5” is necessary only for the creation of atrading channel3, since eitheragent2 may post orders (making the market) in the same way.
FIG. 2 illustrates thetype 1 atomic unit: aclient agent4 is looking to trade with several credit-extendingagents5 with whom it 4 has a credit relationship. Note that because each credit-extendingagent5 participates in only a single trading channel3 (with which thecentral computer1 is aware), there is no opportunity for the credit-extendingagents5 to act as credit-bridigng agents5. Thetype 1 scenario involves theclient4 placing a one-way or a two-way order viacomputer1.Computer1 insures that everyinstitution5 with which theclient4 has a credit relationship sees the order instantaneously. If none of theinstitutions5 wish to deal at the client's current price, they5 may post their own counter-offers that then appear on the client's customlimit order book24,25, but not on those of theother institutions5. Theclient4 may then choose to modify or cancel its 4 order to deal at the best price possible, while theinstitutions5 benefit by seeing this client's4 possible interest in buying or selling.
Theinstitutions5 may also supply viacomputer1 tradable bid and offered prices to theclient4 that will not be seen by theother institutions5.
The solid lines inFIG. 2 represent credit relationships betweenclient4 and credit-extendingagents5. The credit-extendingagents5 may have credit relationships outside the scope of the present invention, but only those tradingchannels3 whose credit limits are maintained by thecentral computer1 are illustrated or discussed. The dashed lines inFIG. 2 represent communication links between the agents (4,5) and thecentral computer1.
As a sub-species oftype 1, there can bemultiple clients4, as long as allsuch clients4 have credit relationships with the same credit-extendingagents5, and theclients4 are not allowed to trade with each other4.
Computer1 provides several post-trade capabilities to theclient4 and to the financial institution's5 trading desk as well as to its 5 back office and credit desk, all in real-time.
The clearing of the trade is done by conventional means. The operator ofcomputer1, though it could, does not need to act as a clearing agent and does not need to hold as collateral or in trust any financial or other instruments. Theclient4 can direct that all clearing is to be handled by a certain credit-extendingagent5. The clearing procedures are dependent upon the instruments traded and any netting agreements or special commodity delivery procedures required for those instruments.
Thetype 2 atomic unit is illustrated inFIG. 3.Type 2 enablesclient4 toclient4 dealing among theclients4 of a particular credit-bridgingagent5, as well as enablingclient4 to credit-extendingagent5 trading. As usual, the anonymous order-matching process is triggered whenever an order to buy is made at a price equal to or higher than the lowest outstanding offer to sell, or vice versa. If the match is between aclient4 and the credit-bridgingagent5, then a single deal is booked between those twoparties2. However, if the match is between twoclients4, then two back-to-back deals are booked, one between theseller client4 and the credit-bridgingagent5, and the other between thebuyer client4 and the credit-bridgingagent5. This is akin to creating virtual trading channels between theclients4. Aclient4 who has a credit relationship with the credit-bridgingagent5 is able to post its one-way or two-way order viacomputer1, which causes the order to be instantly displayed to allother clients4 and to the credit-bridgingagent5 itself if the existing credit limits between the postingclient4, the credit-bridgingagent5, and the receivingclient4 would allow a portion of the order to be executed.
This “mini-exchange” has the liquidity of the natural supply and demand of theentire client5 base, combined with the market-making liquidity that the credit-bridgingagent5 would be supplying to itsclients4 ordinarily. It is certainly expected, and beneficial to the overall liquidity, that the credit-bridgingagent5 will be able to realize arbitrage profits between the prices posted by itsclients4 and the prices available to the credit-bridgingagent5 through other sources of liquidity. In fact, there may be instances in some markets whereclients4 are also able to arbitrage against other trading systems.
Again,computer1 provides several post-trade capabilities to theclient4 and to the trading desk, the back office, and the credit desk of the credit-bridgingagent5, all in real-time, as intype 1.
A pair of back-to-back trades is illustrated inFIG. 4, showing that agents4(2) and4(4) are the ultimate buyer and seller of the deal, but they each deal only with the credit-bridgingagent5 as theirimmediate counterparty2.
As with all the various atomic units,central computer1 updates the current tradable information after each trade, and causes this information to be displayed on the computers associated with all of thesubscriber agents2.
Again,computer1 provides several post-trade capabilities to theclients4, as well as to the credit-bridging agent's5 trading desk, its 5 back office, and its 5 credit desk, all in real-time. The credit-bridgingagent5 acts as a clearing agent for this trade, and is able to monitor the client-to-client exposure, in real time.
Thus is created a price-discovery mechanism for end-users2 with direct transparency betweenentities2 wishing to take opposite sides in the market for a particular instrument. The present invention encompasses decentralized operation of an arbitrary number of separate, type-1 and type-2 atomic units. Efficient price discovery is provided to theend user2 in a decentralized liquidity rich auction environment, leveraging existing relationships, and co-existing with and indeed benefiting from traditional trading methodologies.
Furthermore, an arbitrary number ofdifferent type 0,type 1, andtype 2 atomic units may be interconnected, bottom-up, as illustrated inFIG. 5, to provide, at all times, a liquidity rich efficient price-discovery mechanism to the subscribingagents2, enabling more andmore agents2, across different atomic types, to conduct efficient direct auctions with each other directly. The various atomic units may be interconnected into a molecular credit-network.
InFIG. 5, which may be considered to illustrate a “type 3” scenario, shaded circles represent credit-bridgingagents5 and un-shaded circles representclients4.
For purposes of simplicity,central computer1 is not shown onFIG. 5, but is in fact coupled to allnodes2. Eachnode2 has proprietary client software on a computer associated with saidnode2, enabling saidnode2 to communicate withcentral computer1. Such software may take the form of a Web browser. The diameters of the arrow-headedlines3 represent instrument excursion limits deduced from each trading channel's various types of credit limits. A “shortest weighted paths” algorithm or other minimum cost flow algorithm is used to calculate the minimal path between twoagents2 subject to credit flows to enable a trade between theagents2. Thetrading agents2 may be arbitrarily removed from one another, both in geographic terms as well as by type of business activity in which they2 are involved.
Each connected piece ofFIG. 5 maintains full transparency of orders posted oncomputer1 to allfinancial institutions5 andclients4 who are on anyunexhausted credit path3 to theposting entity2. Each of theentities2 who are able to see the posted order are in effect competing, through the reverse auction, for that particular deal, enabling further efficient price-discovery to theposting entity2.
Prior to each trade,computer1 internally computes the values that define one of theseFIG. 5 graphs for each pair of instruments being traded. From the graph,computer1 creates a table of multi-hop trading limits showing the trading limits between each pair ofnodes2. From the table of multi-hop trading limits,computer1 prepares a customlimit order book24,25 for eachnode2 for each traded instrument pair. After every trade,computer1 recalculates the trading limits3, thus leading to a new graph (FIG. 5) for that instrument pair. Recalculating the trading limits3 for a given traded instrument pair can affect the topology (trading limits3) of other graphs (FIG. 5) for other traded instrument pairs. This can occur, for example, when the trading limits are notional trading limits.
OnFIG. 5, if anagent2 has imposed its own internal limits that are smaller than the trading limits that have been imposed by a credit-extendingagent5 that is extending it 2 credit,computer1 uses the smaller of the two limits when it createsFIG. 5.
Eachtrading channel3 represents an account between a credit-extending agent and aclient agent4. In the preferred implementation of this invention, all credit-extending agents are credit-bridgingagents5. Even when twoadjacent nodes2 are fully qualified to be credit-extendingagents5, one acts as the credit-extendingagent5 in the transaction and the other acts as theclient agent4 in the transaction. The accounts that exist between credit-extendingagents5 andclient agents4 comprise specified input credit limits, balance holdings, and collateral;computer1 calculates trading limits from this information.
The operator ofcomputer1 typically has, in its standard agreement with a subscribingagent2, language stating that if theagent2 has entered into a written subscription agreement with the operator ofcomputer1 and saidagent2 trades outside of thenetwork6,7 operated by the operator ofcomputer1, thatagent2 is obligated to notify the operator ofcomputer1 about such outside trades, so thatcomputer1 can recalculate the trading limits as necessary.
FIG. 5 can be thought of as an n-hop credit network, where n is an arbitrary positive integer. In any transaction, the instrument flow can fan out from onesource node2 and then collapse to thedestination node2; the instrument flow does not have to stay together as it flows from thesource2 to thedestination2. SeeFIG. 10 for an example of this phenomenon. In calculating the maximum capacity of thenetwork6,7,computer1 uses a maximum flow algorithm such as one described inchapter7 of the Ahuja reference cited previously. In determining the actual flow used to complete the trade,computer1 uses a minimum cost flow algorithm such as one described inchapter9 of said Ahuja reference, where the cost to be minimized is a function of the actual cost to execute the trade and other factors, such as projected settlement costs, flow balancing heuristics, and a randomizing component.
Thenetwork6,7 ofFIG. 5 is a non-disjointed network. By that is meant that everynode2 in thenetwork6,7 is coupled to at least oneother node2, and at least one of theagents2 associated with eachtrading channel3 is a credit-bridgingagent5. Theindividual trading limits3 thatcomputer1 computes for eachagent2 pair are dependent upon the topology of thenetwork6,7.Computer1 essentially transforms thenetwork6,7 into a virtually cliqued networked. A “cliqued network” is one in which everynode2 is connected to everyother node2. A “virtually cliqued network” is one in which everynode2 has a capability to trade with everyother node2, but not necessarily directly. In order to preserve the desired feature of anonymity, eachnode2 knows the identities of only itsimmediate trading partners2, and does not necessarily know whom2 it is actually trading with.
As a trading system that leverages the existing relationships in the market for the traded instrument, the present invention provides all market players2 (typically banks, financial institutions, clearing entities, hedge funds, and any corporations or other entities) the ability to trade directly with each other through a customlimit order book24,25. Theseagents2 may already be connected together with credit relationships, but prior art systems allow trading only between two parties that have an explicit credit arrangement. The present invention analyzes the credit-worthiness of apotentional counterparty2 at a higher level, performing this analysis in real time, and providing eachparty2 with alimit order book24,25 customized to its 2 current credit availability.
For example, inFIG. 6 we consider a small network of foreign exchange players: banks5(B) and5(C), which have a credit relationship with each other, and clients4(A) and4(D), who have margin placed with banks5(B) and5(C), respectively (we leave the margin currency and traded instrument unspecified). The specified input credit limits are specified as traded instrument L:Q credit limits Oust one way of specifying input credit limits out of eight possible ways enumerated in the present patent application). Client4(A)'s margin allows it to trade +/−10M with5(B),5(B)'s relationship allows it to trade +/−50M with5(C), and5(D)'s margin allows it to trade +/−5M with5(C). This information is supplied tocomputer1, which drawsFIG. 6 from said information.
FIG. 6 illustrates a
simplified type 3 network in which there are two
client agents4 and two credit-extending
agents5 which are also credit-bridging
agents5.
FIG. 6 also illustrates the trading limits between each pair of coupled
agents4,
5. Table 1 shows the maximum multi-hop credit limits that are then calculated by
computer1 for the simplified
| A | infinity | 10 M | 10 M | 5 M |
| B | 10 M | infinity | 50 M | 5 M |
| C | 10 M | 50 M | infinity | 5 M |
| D | 5 M | 5 M | 5 M | infinity |
|
Computer1 then uses the information contained in Table 1 to create a customlimit order book24,25 for each agent A, B, C, D, and causes the customlimit order book24,25 to be displayed on the computer screen of the respective agent A, B, C, D. The filtered bids and offers in the customlimit order book24,25 are for volumes that are an integral multiple of the lot size even if the computed Table 1 amounts contain values which are not integral multiples of the lot size, with non-integral multiples rounded toward 0.
If client A posts a bid for 10M,computer1 causes the full bid to appear on the customlimit order books24,25 of banks B and C, andcomputer1 causes a filtered bid for 5M to appear on the customlimit order book24,25 of client D, because the maximum credit (implicit or explicit) available between A and D is +/−$5M. If there is no implicit or explicit credit available between twonodes2, they2 are not allowed to see each other's bids and offers at all on their customlimit order books24,25.
Thenetwork6,7 of the present invention is preferably built using the Internet Protocol (IP) (because of its ubiquity), and may reside on the Internet itself or other public IP network7 (FIG. 7).
It is also possible to locate part or all of thenetwork6,7 on aprivate fiber backbone6, so that information bound for theInternet7 can traverse most of the distance to its destination on the presumably higher speedprivate network6. The slowerpublic Internet7 is then used for just the last segment of travel. It is also possible to provideclients2 with dedicated bandwidth throughprivate IP networks6 in order to provide additional levels of quality and service. A singlededicated connection6 may be backed up by anInternet connection7, or multipleprivate connections6 can be used to avoid thepublic network7 entirely.
OnFIG. 7, the three illustratedagents2 can be three separate companies, three computers within the same company, or a hybrid of the above.
Thenetwork6,7 interfaces with both people and automated systems (computers), so it provides three access methods:
- human—Graphical User Interface (standalone or browser-based application) for trading, interactive queries, and account management;
- human/computer—HTTP reports interface (HTML, XML, PDF, or Excel) for queries only;
- computer—Application Programming Interface38 (available in Java and COBRA with bridges to FIX, JMS, SOAP, and ebXML) for trading, queries, and account management.
An agent's2 software can be launched from the agent's2 browser but run as a standalone application for better performance and stability.
The computer of eachagent2 can have associated therewith an application programming interface (API)38. TheAPI38 is a standard interface exposed by thecentral computer1 that enables theuser2 to write customized instructions enabling two-way communication betweencentral computer1 and theuser2. In the case where theuser2 is acredit extending agent5, theAPI38 can be used to update the agent's backoffice information. Theagent2 can program hisAPI38 to make and cancel orders (bids and/or offers). Theagent2 can use hisAPI38 to receive and reformat customlimit order books24,25 for any instruments. Theagent2 can use hisAPI38 to set trading limits, with the understanding that the actual trading limits are the minimum of the trading limits specified by the twoagents4,5 associated with an account. TheAPI38 can be programmed to estimate how much it would cost anagent2 to liquidate his position in an instrument. TheAPI38 can be programmed to estimate that agent's profit/loss amount for each instrument being traded; this information can be combined with the agent's customlimit order book24,25. Anything that can be achieved by the GUI (graphical user interface) (FIGS. 12-21) can be achieved via theAPI38.
Any and all features of theAPI38 can be programmed to operate automatically, including automatic bidding, offering, buying, and selling. Automatedprocesses accessing computer1 viaapplication programming interface38 or a bridge use the same cryptographic protocols as for ahuman agent2 inputting instructions via his computer's GUI. Whether anAPI38 or a GUI is used, an agent's private key for computerized access tocomputer1 can be stored in the agent's computer, provided said computer has sufficient security safeguards.
Privacy, authentication, and non-repudiation are achieved in the present invention via the use of cryptography in a variety of different forms. The cryptographic techniques can comprise symmetric key and/or asymmetric key (public key) cryptography. All data streams are encrypted, e.g., by using SSL (Secure Socket Layer) connections or a combination of SSL encryption with additional authentication and encryption. Authentication can be required betweencomputer1 and anagent2 at any and all times thesedevices1,2 communicate with each other. This authentication can be achieved through the use of digital certificates. Revalidation of credentials can be required at the time a trade is consummated.
Eachagent2 may store its private key on a tamper-resistant hardware device such as a smartcard, protected by a password. The combination of a physical token (the card) with a logical token (the password) ensures two levels of security. The hardware token may contain a small CPU that allows it to perform the necessary cryptographic operations internally, so that the agent's private key never leaves the smartcard. In a preferred embodiment,computer1 handles bulk encryption/decryption using symmetric key cryptography after the slower public key cryptography has been used to exchange a session key betweenagent2 andcomputer1.
While trading in the present invention is peer-to-peer, order matching for any particular instrument is done at acentralized location1 to maintain transactional integrity.FIG. 8 illustrates the order matching process. Instep8, the first agent2(1) places a bid via its software tocomputer1, which accepts the bid atstep9.Computer1 then calculates changes to the customlimit order books24,25 of agents2(1) and2(2) atsteps10 and11, respectively, taking into account appropriate trading limits3. Atstep12, the second agent2(2) takes the bid.Step12 occurs right beforestep13, in which a third agent2(3) (not illustrated) posts a new offer (bid or offer) for the traded instrument L:Q. At step14,computer1 makes the match between the first agent2(1) and the second agent2(2).
Reporting of the trade is described below in conjunction withFIGS. 35 and 36.
Anetwork6,7 implementing the present invention can span the entire world, which means that there may be time differences for a message sent bydifferent agents2 tocomputer1. Assuming anetwork6,7 that sends signals at the speed of light but that cannot transmit through the Earth, a message sent to the other side of the Earth would have a round-trip time of at least 130 milliseconds. On existing IP networks, it is observed that if thecentral computer1 were located in New York, the maximum average round-trip communication time between thecentral computer1 and a computer in any of the major financial centers is less than 300 milliseconds.
We want to ensure that allagents2 have a level playing field in accessingcomputer1, regardless of where theseagents2 are situated around the world. Determining the latency for eachagent2 and then introducing an individual delay on an agent-by-agent basis to try to equalize time-of-arrival atcomputer1 would be very difficult (due to short term fluctuations innetwork6,7 lag), and could have the undesired effect of overcompensating. Amalicious agent2 could also falsify itsnetwork6,7 delay, unfairly obtaining early access tocomputer1.
In order to compensate for the various time lags in sending messages betweenagents2 andcomputer1 on a global basis, the present invention transmits information as rapidly as possible while flagging the order of messages to compensate for latency. The flagging is done by means of border outpost computers16 (FIG. 9).
Foragents2 remote fromcomputer1, aborder outpost computer16 is inserted into thenetwork6,7, typically where the agent's data enters theprivate backbone6 that connects tocomputer1. Eachborder outpost computer16 comprises aCPU18, a trustedtime source17, and an input/output port19.Time source17, which may comprise a GPS clock accurate to a millionth of a second, is used to generate a digital time stamp that is added to each data packet before it is forwarded tocomputer1. The GPS clocks17 of all theborder outpost computers16 are synchronized with each other to a high degree of accuracy (typically one microsecond). The time stamp may be placed onto the packet without theborder outpost computer16 having to understand the packet or have access to its contents. At thecomputer1 site, the time stamp is stripped off before the packet is processed, and then reassociated with the data after it is decrypted and parsed into a command.Computer1 then sorts the messages into a queue by time order. After a fixed time delay, the message that is at the front of the queue is serviced bycomputer1. The fixed time delay is chosen so that with a high degree of certainty a message from the remotest agent's2 computer will arrive atcomputer1 within the fixed time delay. The purpose of the fixed time delay is to allow all messages that might be the first-originated message to have a chance to arrive atcomputer1 before execution of any messages takes place. The time stamp may be encrypted using either a symmetric or assymetric cipher, to prevent its modification or falsification.
FIG. 10 is a deal fulfillment (flow) graph, illustrating the flow in the lot instrument. The lot instrument L is the portion of the traded instrument that has to be traded in a round lot, typically a multiple of a million. The quoted instrument Q is that portion of the instrument being traded that is expressed as the lot instrument times a price. In this example, agent4(2) buys 10M Euros using U.S. dollars at an exchange rate of 0.9250 from agent4(1). Since the Euro is the lot currency in this example, it has to be specified in a round lot (multiple of 1 million Euros). F(L), the lot size (volume), is 10 million and F(Q), the quoted volume, is 9,250,000. In this example, there are three intermediaries (middlemen): agents5(1),5(2), and5(3). Only credit-bridgingagents5 can be middlemen. For purposes of simplification, we show onFIG. 10 the flow of just the lot instrument L. There is also a counterflow in the quoted instrument Q, which can be derived from the lot flow and the traded price. For example, on theedge3 between node5(1) and4(2,) 2M represents the flow of 2 million Euros from agent5(1) to agent4(2), as well as the counterflow of 1,850,000 U.S. dollars from agent4(2) to agent5(1).
FIG. 11, a simplified focus change diagram, illustrates the sequence of screen shots appearing on the display of a computer of anagent2 who is coupled tocentral computer1.Agent2 first encounters a log-indialog box21, then amenu bar22 where he can select from an accountmanagement dialog box23, anet exposure screen35, abalance sheet36, or his customlimit order book24,25. From custom limit orderbook overview screen24,agent2 can navigate to one of N order book detail screens25, or to anactivity dialog screen27, which can take the form of abid dialog box28, anoffer dialog box29, abuy dialog box30, asell dialog box31, or a market order screen32. As shown inFIG. 11, various of these screens can segue into a bid/offer canceldialog box33 or aconfirmation dialog box34.
FIGS. 12-21 illustrate most of the above screens. The login screen is shown (FIG. 12), followed by two shots of the main desktop (FIGS. 13 and 14) showing the custom limit orderbook overview window24 and the custom limit orderbook detail window25. The remaining screen shots (FIGS. 15-21) are of dialog boxes that can be activated from either theoverview window24 ordetail order windows25.
FIG. 12 illustrates log-indialog box21.Field41 allowsagent2 to type in his name, thus identifying the account and trader.Field42 is an optional challenge field, provided for security purposes. An appropriate response from theagent2 to meet the challenge might include presentation of a password, key, or digital certificate via a hardware token.Field43 is whereagent2 enters his password.Field44 is whereagent2 enters the address ofcentral computer1. In the case of an Internet connection, the URL ofcomputer1 is specified here. The data exchange betweenagent2 andcentral computer1 is encrypted, e.g., by a SSL (Secure Socket Layer) connection.Field45 is a scrolling message log showing status and notification of errors during the log-in process.
FIG. 13 illustrates the main custom limitorder book screen24.Field51 specifies the current account.Field52 is a summary of the custom limit order book for each permissioned traded instrument. In this sample, where the instruments are pairs of currencies, the traded instruments are identified by icons representing the flags of the countries issuing the currencies. There are fivefields52 illustrated, representing five permissioned instruments. Thesecond field52 from the top (Great Britain pounds for U.S. dollars) is exploded, indicating the traded instrument currently activated byagent2.
Field53 displays the top (best) orders from the point of view of theagent2.Field54 displays the best bid price for anyagent2 coupled to thenetwork6,7.Field55 displays the last two digits (“84”) of the best available bid price.Field56 displays the size at the best bid price.Field57displays agent2's available liquidity for additional selling.Field58 providesagent2 with a mouse-clickable area (the big figure) enabling theagent2 to jump to the buy or1sell dialog screen30 or31, with amounts already filled in.Field59 is a mouse-clickable numeric keypad allowing theagent2 to create and cancel orders.Field60 gives balance sheet values showing live valuations at market price and the profit that was banked byagent2 for a certain period of time, such as the current day.Field61 is a pop-up console allowing for the display of application messages, connection failure/retry messages, and broadcast messages fromcentral computer1.Field62 displays the time since theagent2 has logged in tocomputer1.Field63 displays the best available offer; in this case, four digits of the available offer are used to warnagent2 that his best available offer is far from the overall best, due to a credit bottleneck.Field64 shows this agent's orders in red.Field65 shows this agent's current net position in the instrument being traded.Field66 shows a summary of this agent's offers.Field67 is a mouse-clickable area (tab9) enabling theagent2 to quickly cancel the top offer.
FIG. 14 illustrates a custom limit orderbook depth window25. There are N of thesewindows25 for each instrument, where N is any preselected positive integer. Typically, N is equal to five. TheN windows25 display the N best bids and offers in order of price, and within price, in order of date and time, with the oldest presented first.Field71 shows bid and offer information, with the last two digits of the bid and offer (“99” and “02”, respectively) displayed in large numerals for readability.Field72 shows visible (to that agent2) bids and offers truncated by current credit availability, individually or aggregated by price (configurable). Bids and offers from this agent's account are shown in pink.Field73 is a mouse-clickablefield allowing agent2 to navigate to screen33 (FIG. 17).Field74 is a set of four mouse-clickableareas enabling agent2 to open buy, sell, bid, and offer dialog boxes (30,31,28, and29, respectively), with price and size information pre-loaded from the current market.
FIG. 15 illustrates net exposure monitor35. Eachentry81 gives the current exposure for each account, broken down by traded instrument. Field82 (“min” and “max”) shows asymmetric net position limits on a per-instrument basis. Field83 (“current”) shows a real-time update of net position.Field84 shows a graphical representation of net position.
FIG. 16 illustratesbalance sheet window36.Field91 shows payables and receivables, valued using the current market price. Total net position and net position for eachcounterparty2 are given.Field91 is organized as a tree hierarchy, and allows navigation to individual balance sheet transfers. Field94 shows underlying flows; they have been sent to the agent's computer in an encrypted form, and are decrypted at the agent's computer. The decryption can be done automatically, as long as theagent2 is logged in to thenetwork6,7. In field94, one line represents each trade thisagent2 has made, or each trade for which thisagent2 was anintermediary5. All values are live. This currency-basedbalance sheet36 is capable of handling triangular instrument swaps.
FIG. 17 illustrates the open order overview andmanagement window33.Field101 shows orders (bids and offers) currently placed by that agent summarized by traded instrument.Field102 shows individual orders.Field103 is a mouse-clickable area enabling theagent2 to remove the order from the agent's customlimit order book24,25. All values are updated immediately if their value has changed. Inscreen33, an update procedure can be implemented in which the first offer is not cancelled until a new offer is posted. This is sometimes referred to as OCO (one cancels the other). In any event, it is never possible for anagent2 to cancel an order after it has been taken by acounterparty2.
FIG. 18 illustrates bidcreation dialog box28.Field111 is a group of icons, typically in various colors to provide visual context to reduce errors. Note that the word “Bid” is highlighted.Field112 comprises three mouse-clickable areas allowing for quick up or down adjustment of price and direct entry of price, respectively, with initial value taken from the current market.Field113 comprises three mouse-clickable areas allowing for quick up or down adjustment of size, and direct entry of size, with initial value configurable based upon the desires of theparticular agent2.Field114 is a mouse-clickable area allowing theagent2 to submit the bid, and has an optional confirmation dialog box associated therewith. Anagent2 can post his bid for just a short period of time and then withdraw it. He 2 can post multiple bids at multiple prices. When acounterparty2 takes part or all of his bid,computer1 recalculates the trading limits.Agent2 can make his bid limited to “only if it is available now” or as an offer to buy.
FIG. 19 illustrates offercreation dialog box29.Field121 comprises a set of icons, typically colored to provide visual context to reduce errors. Note that the word “Offer” is highlighted.Field122 comprises three mouse-clickableareas allowing agent2 to quickly achieve up or down adjustment of price and direct entry of price, with initial value taken from the current market.Field123 comprises three mouse-clickable areas providing a quick means foragent2 to achieve up or down adjustment of size and direct entry of size, with initial value configurable on a peruser2 basis.Field124 is a mouse-clickablearea allowing agent2 to post the offer, and has an optional confirmation dialog box associated therewith.
FIG. 20 illustrates buy (immediate execution bid)dialog box30.Field131 comprises a set of icons, typically colored to provide visual context to reduce errors. Note that the word “Buy” is highlighted.Field132 comprises three mouse-clickable areas, providing a quick means for up or down adjustment of price and direct entry of price, with initial value taken from the current market.Field133 is a mouse-clickable button allowing for a partial execution of a trade. This allowsagent2 to buy either as much of the size as possible, or nothing if he cannot buy the entire size.Field134 comprises three mouse-clickable areas providing a quick means for up or down adjustment of size and direct entry of size, with initial value configurable on a peruser2 basis.Field135 is a mouse-clickablearea allowing agent2 to execute the buy, and has an optional confirmation dialog box associated therewith.
FIG. 21 illustrates sell (immediate execution offer)dialog box31.Field141 is a set of icons, typically colored to provide visual context to reduce errors. Note that the word “Sell” is highlighted.Field142 comprises three mouse-clickable areas providing a quick means foragent2 to achieve up or down adjustment of price and direct entry of price, with initial value taken from the current market.Field143 is a mouse-clickable area allowing partial execution. This allowsagent2 the choice of the sell being either to fill as much of the size as possible, or to not sell if he 2 cannot sell the entire size.Field144 comprises three mouse-clickable areas providing for a quick means for up or down adjustment of size and direct entry of size, with initial value configurable on a peruser2 basis.Field145 is a mouse-clickable area allowing the sell to be executed, and has an optional confirmation dialog box associated therewith.
FIG. 22 is a flow diagram illustrating the method steps by whichcomputer1 computes a customlimit order book24,25 for asingle agent2 for a single traded instrument. Evenintermediate agents5 get a customlimit order book24,25. For the left hand side ofFIG. 22, source S is thatnode2 for which this custom limit order book is being prepared; and sink T is thatnode2 that has posted the bid. For the right hand side ofFIG. 22, source S is thatnode2 that posted the offer; and sink T is thatnode2 for which this custom limit order book is being prepared. “Source” and “sink” are standard network terminologies; see, e.g., the Ahuja reference previously cited. These concepts are used internally bycomputer1, but are not disclosed to allagents2 for reasons of preserving the desired anonymity. For example, theactual poster2 of the offer does not appear on the screen of thecounterparty2.
The method starts atstep151. Instep152,computer1 asks whether there have been any trades made since the last multi-hop credit computation. This is meant to avoid unnecessary computation. If the answer to the question is “yes”, then step153 is executed. Atstep153, multi-hop credit limits are computed, as illustrated inFIG. 23. If the answer to the question raised instep152 is “no”,step154 is executed. Atstep154, the bid side of the book is cleared, i.e., variable B becomes the null set; the offer side of the book is cleared, i.e., variable A becomes the null set; and the credit used (U as a function of S and T) is cleared. In this context, “used” applies only for this particular customlimit order book24,25 for thisparticular agent2. Step155 is then executed, where it is asked whether enough bids have been found. “Enough” is a pre-established limit, e.g., five, and corresponds to N as discussed above in conjunction with custom limit orderbook detail window25. N may be infinity, in which case the method always proceeds fromstep155 to step156. If enough bids have been found, the method proceeds to step161. If enough bids have not been found, the method proceeds to step156, where it is asked whether there are more unprocessed bids, i.e., if the number of bids that have been processed is less that the pre-established limit. If the answer is “no”,step161 is executed; otherwise, the method proceeds to step157, where the highest priced oldest unprocessed bid is fetched. The hierarchy is according to highest bid. If there is a tie as to two or more highest bids, then the bids are ordered by time. It is forced that there not be a time-tie at this point; time collisions have already been resolved by locking using sequence numbers.
Step158 is then executed. X is defined as the flow limit (trading limit) between S and T minus the credit U between S and T that has already been used up. Y is then set to be the minimum of X and the bid size. In other words, Y is what we have to work with. Step159 is executed, where it is asked whether Y is greater than 0. If not, the method cycles back tostep155. If “yes”,step160 is executed. Instep160, the set of bids B is augmented by the current bid we are working with fromstep157. Also instep160, the credit used U is augmented by Y.
Atstep161, it is asked whether enough offers have been found. Again, “enough” is a pre-established limit e.g., five, corresponding to N as before. If the answer to this is “yes”, the method stops atstep167. If the answer is “no”,step162 is executed. Atstep162, it is asked whether there are more unprocessed offers. If not, the method ends atstep167. If “yes”,step163 is executed, where the lowest priced, oldest unprocessed offer is fetched. Then, step164 is executed, where X is set to be the trading limit between S and T minus the unused credit U. Y is then set to be the minimum of X and the offer size. Step165 is then executed. Atstep165, it is asked whether Y is greater than 0. If not, control is passed back tostep161. If “yes”,step166 is executed, where the current offer price being worked on frombox163 is added to the set of offers A; and the credit used U is augmented by Y. Control then passes back to step161.
FIG. 23 illustrates howcomputer1 calculates multi-hop trading limits for each pair ofagents2 for a single traded instrument L:Q, i.e., howcomputer1 performsstep153 onFIG. 22. This is akin to compiling a table like Table 1 shown above. This procedure starts atstep171. Atstep172, a directed graph is computed for the traded instrument L:Q, in which the arrow corresponds to the direction of flow of the lot instrument L. Individual trading limits are introduced at this point. Step172 is the subject ofFIG. 24. Atstep173, anarbitrary network node2 is selected to be the first node worked upon by the process and is given the designation source S. Atstep174, sink T is also set to be saidfirst network node2. Atstep175, it is asked whether S is equal to T. If so (which, of course, is the case initially), the procedure moves to step176, where the maximum flow limit between S and T is set to be infinity. This is simply another way of saying that anagent2 is allowed to have an infinite flow with himself 2. Then, atstep182, it is asked whether T is the last network node that needs to be processed. If “yes”, control is passed to step184; if “no”, control is passed to step183, where T is advanced to the next network node; and control is passed back tostep175. “Next” can be anything, because the order of processing is of no import.
If S is found not to be equal to T atstep175, control is passed to step177, which disablesedges3 where theedge origin2 is not acredit bridge5 and theedge origin2 is not equal toS. An edge3 may be disabled internally by adjusting its maximum capacity to 0 or by removing it from the set ofedges3 that comprise the graph. The “edge origin” is thatnode2 from which the lot instrument L flows.Steps177 and178 eliminateagents2 who have not agreed in advance to be intermediaries, i.e., “credit bridges”. An intermediary (credit bridge) is anagent5 that allows twoother agents2 to do back-to-back trades through theintermediary agent5. Step178 disablesedges3 where theedge destination2 is not acredit bridge5 and theedge destination2 is not equal to T. An “edge destination” is anode2 that receives the flow of the lot instrument L.
Atstep179, the maximal flow from S to T is computed using a maximal flow algorithm such as one of the algorithms disclosed inChapter 7 of the Ahuja reference previously cited. Atstep180, the multi-hop credit limit between S and T, LIM(S,T), is set to be equal to the maximum flow obtained fromstep179. Atstep181, theedges3 that were disabled insteps177 and178 are re-enabled. Step184 asks whether S is the last network node to be processed. If “yes”, the procedure concludes atstep186. If “no”, the process moves to step185, where S is advanced to the next network node. Again, “next” is arbitrary and simply refers to any otherunprocessed node2. Afterstep185, the method re-executes steps174.
FIG. 24 illustrates howcomputer1 calculates a directed graph for the traded instrument L:Q, i.e., howcomputer1 performs step172 ofFIG. 23. This is akin to producing a graph such as that shown inFIG. 5, with arrows as inFIG. 10. The operation commences atstep191. Atstep192, theedge3 set G is nulled out. Atstep193,computer1 searches its records for any account A that it has not yet processed. The order of selection of unprocessed accounts is irrelevant. Account A is any pre-existing trading (credit) relationship between twoneighboring agents2 that has been previously conveyed to the operator ofcomputer1 in writing in conjunction with theseagents2 subscribing to the trading system operated by the operator ofcomputer1.
Step194 asks whether there is any such unprocessed account A. If “not”, this process stops atstep198. If there is an unprocessed account A, the process executesstep195, where the minimum and maximum excursions for account A are calculated. Step195 is the subject ofFIG. 25. These minimum and maximum excursions are defined in terms of the lot instrument L, and are calculated from one or more of eight possible ways of specifying input credit limits. The maximum and minimum excursions are excursions from current position. The input credit limits are specified as part of each account A. Instep196, the set of edges G is augmented with anedge3 from A'slender2 to A'sborrower2, with the capacity of theedge3 being set to the maximum excursion. L is the lot instrument and Q is the quoted instrument. Instep197, the set of edges G is augmented with anedge3 from A'sborrower2 to A'slender2, with the capacity of theedge3 being set to the negative of the minimum excursion. The process thenre-executes step193.
FIG. 25 shows howcomputer1 calculates the minimum and maximum excursions for a single account A and a single traded instrument L:Q, i.e., howcomputer1 executes step195 ofFIG. 25. This computation takes into account up to eight different ways a guaranteeingagent5 may specify input credit limits in an account A. The operation commences atstep201. Atstep202, the maximum excursion is set to be infinity and the minimum excursion is set to be minus infinity, because at this point there are no trading limits.
Step203 asks whether position limits have been defined for the lot instrument. If yes, step204 is executed. Atstep204, the lot instrument position limits' effects on the maximum and minimum excursions are calculated. This is the subject ofFIG. 26. Atstep205, it is asked whether volume limits have been specified for the lot instrument. If so,step206 is executed. Atstep206, the lot limit volume limits' effects on the maximum and minimum excursions are calculated. This is the subject ofFIG. 28. Atstep207, it is asked whether position limits have been specified for the quoted instrument. If so,step208 is executed. Atstep208, the quoted instrument position limits' effects on the maximum and minimum excursions are calculated. This is the subject ofFIG. 27. Atstep209, it is asked whether volume limits have been specified for the quoted instrument. If so,step210 is executed. Atstep210, the quoted instrument volume limits' effects on the maximum and minimum excursions are calculated. This is the subject ofFIG. 29. Atstep211, it is asked whether notional position limits have been specified. If so,step212 is executed. Atstep212, the notional position limits' effects on the maximum and minimum excursions are calculated. This is the subject ofFIG. 30. Atstep213, it is asked whether notional volume limits have been specified. If so,step214 is executed. Atstep214, the notional volume limits' effects on the maximum and minimum excursions are calculated. This is the subject ofFIG. 31. Atstep215, it is asked whether position limits have been specified for the traded instrument L:Q. If so,step216 is executed. Atstep216, the traded instrument L:Q position limits' effects on the maximum and minimum excursions are calculated. This is the subject ofFIG. 32. Atstep217, it is asked whether volume limits have been specified for the traded instrument L:Q. If so,step218 is executed. Atstep218, the traded instrument L:Q volume limits' effects on the maximum and minimum excursions are calculated. This is the subject ofFIG. 33.
Then step219 is executed, where the maximum excursion is set to be equal to the maximum of 0 and the current value of the maximum excursion. This is done because we don't want to have a negative maximum excursion. At step220, the minimum excursion is set to be the minimum of 0 and the current value of the minimum excursion. This is done because we do not want to have a positive minimum excursion. Then, the method ends atstep221.
It is important to note that the order of taking into account the effects of the eight types of specified input credit limits is irrelevant, because each of the eight can only constrict an excursion more, not expand it. Therefore, the ultimate limit is the most restrictive one. All of the eight trading limits described herein are recalculated after each trade affecting that limit.
As used herein, a “trading limit” is something calculated bycomputer1, and a “credit limit” is something specified by a guaranteeingagent5.
Conventional mathematical shortcuts can be used to speed the calculations without necessarily having to repeat all the method steps in all but the first time a particular method is executed. All of the steps ofFIG. 25 get executed the first time a method shown inFIGS. 26 through 33 is executed.
FIG. 26 shows howcomputer1 calculates the position limit for the lot instrument, i.e., howcomputer1 performs step204 ofFIG. 25. A position limit is a net limit in the instrument being traded. The method starts atstep231. Atstep232,computer1 retrieves the specified input maximum position credit limit for instrument L, PMAX(L), and the specified input minimum position credit limit for instrument L, PMIN(L). Normally, PMIN(L) is the negative of PMAX(L), but that doesn't necessarily have to be true. Also instep232, the net position, POS, is zeroed out.
Instep233,computer1 looks for another unsettled flow of instrument L in account A. “Another” is arbitrary. Atstep234, it is asked whether such another unsettled flow exists. If not, control passes to step238. If the answer is “yes”,step235 is executed, wherein it is asked whether the flow is to account A'sborrower2. A “flow” is a transfer of a single instrument along asingle edge3. This is the same as asking whether the flow is to other than a guaranteeingagent5, because the lender is the guaranteeingagent5. If the answer is yes, step236 is executed, during which POS is augmented by the flow amount, and control passes back to step233. This inner loop233-236 constitutes calculation of the net position, and is performed for each Q matching that L.
If the answer to the question posed instep235 is “no”,step237 is executed, wherein POS is decremented by the flow amount, and control is passed back tostep233. Atstep238, X is set to be equal to PMAX(L) minus POS, and Y is set equal to PMIN(L) minus POS. X is the maximum excursion from this flowchart and Y is the minimum excursion from this flowchart. Atstep239, the maximum excursion for the traded instrument L:Q is set to be equal to the minimum of the current value of this maximum excursion and X; and the minimum excursion for the traded instrument L:Q is set to be equal to the maximum of the minimum of the current value of the minimum excursion and Y. In other words, the set of maximum and minimum excursions is updated based upon the results of this flowchart. The method ends atstep240.
FIG. 27 illustrates howcomputer1 calculates the position limit for the quoted instrument, i.e., howcomputer1 performs step208 ofFIG. 25. Other than the fact that Q is substituted for L, the method described inFIG. 27 is identical to that described inFIG. 26, with one exception: in step259 (analogous to step239 ofFIG. 26), we convert from the quoted instrument to the lot instrument, because we want everything expressed in terms of the lot instrument once we get to the higher level flowchart (FIG. 25). Therefore, instep259, X and Y are each multiplied by a “fixed rate Q:L” (exchange rate). This exchange rate is fixed for a certain period of time, e.g., one hour or one day, and may be different for different accounts at the same moment in time.
FIG. 28 illustrates howcomputer1 calculates the volume limit for the lot instrument, i.e., howcomputer1 performs step206 ofFIG. 25. A volume limit is a gross limit in the instrument being traded. The method starts atstep271. Instep272,computer1 retrieves the specified input maximum permissible volume credit limit for instrument L, VMAX(L); and clears a variable field VOL representing total volume. Instep273,computer1 looks for another unsettled flow of instrument L in account A. “Another” is arbitrary. Atstep274, it is asked whether such another unsettled flow has been found. If “yes”, atstep275, VOL is augmented with the flow amount. It doesn't matter whether the flow is in or out to aparticular node2; it counts towards the volume limit the same in each case.
Control is then passed back tostep273. If the answer posed instep274 is “no”,step276 is executed, wherein X is set equal to VMAX(L) minus VOL, and Y is set equal to minus X, because of the definition of “volume”. Again, X and Y are the partial limits as calculated by this particular flowchart. Then instep277, the maximum excursion is set equal to the minimum of the previous value of the maximum excursion and X; in the minimum excursion is set equal to the maximum of the previous value of the minimum excursion and minus X. In other words, the overall excursions are updated based upon the results of this flowchart. The method then ends atstep278.
FIG. 29 illustrates howcomputer1 calculates the volume limit for the quoted instrument, i.e., howcomputer1 performs step210 ofFIG. 25. Other than the fact that Q is substituted for L, the method steps ofFIG. 29 are identical to those ofFIG. 28, with one exception: in step287 (analogous to step277 ofFIG. 28), X and minus X are each multiplied by “fixed rate Q:L” for the same reason that this factor was introduced inFIG. 27.
FIG. 30 illustrates howcomputer1 calculates the notional position limit, i.e., howcomputer1 performs step212 ofFIG. 25. The notional position limit protects the guaranteeingagent5 against rate excursions aggregated over the positions in all of the instruments. “Notional” means we are changing the notation; the concept implies that there is a conversion from one instrument to another, and that the conversion is done at a certain rate that has been agreed upon. The rate is set periodically, e.g., daily. This conversion from one instrument to another is used to convert all values into a single currency for the purpose of aggregation into a single value.
The method commences atstep291. Atstep292,computer1 retrieves the maximum notional position credit limit PMAXN, where N is the notional instrument, i.e, the instrument in which the limit is presented. Instep292, the notional position, NPOS, is also zeroed out. Instep293,computer1 looks for another instrument C with flows in account A. C is an index designating the instrument for which we are executing the loop293-301. The order of selecting the instruments is immaterial. Step294 asks whether such another instrument C has been found. If not, control passes to step302. If the answer is yes, step295 is executed, wherein the instrument position, POS(C), is zeroed out. Atstep296,computer1 looks for another unsettled flow of instrument C in account A.
Step297 asks whether such another unsettled flow has been found. If not, control passes to step301. If the answer is “yes”,step298 is executed, where it is asked whether the flow is to account A'sborrower2. If “yes”, POS(C) is augmented with the flow amount atstep299. If not, POS(C) is decremented by the flow amount atstep300. In either case, control is returned to step296. Note that the inner loop296-300 is analogous to the loops inFIGS. 26 and 27. Atstep301, NPOS is augmented by the absolute value of POS(C) multiplied by “fixed rate C:N”, which converts to the notional instrument. The absolute value of POS(C) is used, because a negative position presents the same risk to the guaranteeingagent5 as a positive position.
Before we describestep302, let us define A and B, as those terms are used instep302. Note that “A” instep302 is not the same as “account A”. A is the position of L, POS(L), multiplied by “fixed rate L:N”, which converts this position to the notional instrument. B is the position of Q, POS(Q), multiplied by “fixed rate Q:N”, which converts this to the notional instrument. The positions of L and Q are as calculated in the above loop294-301; if L and Q were not subject to these notional limits, then A and B would be 0.
Instep302,computer1 finds the minimum and maximum roots of F(X), where F(X) is defined instep302. The term “root” is that of conventional mathematical literature, i.e., a value of X that makes F(X) equal to 0. Let us define E to be equal to the absolute value of A plus B, plus NPOS, minus the absolute value of A, minus the absolute value of B, minus PMAXN. If E is greater than 0, then there are no roots. In that eventuality, we set the maximum excursion of the traded instrument L:Q, MAXEXC(L,Q), and the minimum excursion of the traded instrument L:Q, MINEXC(L,Q), to be equal to 0. If E is less than or equal to 0, the maximum root is the maximum of minus A and B, minus E/2; and the minimum root is the minimum of minus A and B, plus E/2. Now we are ready to go tostep303.
Atstep303, the maximum excursion of the traded instrument L:Q is set equal to the minimum of the previous version of the maximum excursion of the traded instrument L:Q and the maximum root multiplied by “fixed rate N:L”, which converts it to the lot instrument. Similarly, the minimum excursion of the traded instrument L:Q is set equal to the maximum of the previous version of the minimum excursion of the traded instrument L:Q and the minimum root multiplied by the same conversion factor, “fixed rate N:L”. The method terminates atstep304.
FIG. 31 illustrates howcomputer1 calculates the notional volume limit, i.e., howcomputer1 performs step214 ofFIG. 25. The method starts atstep311. Atstep312,computer1 retrieves the specified input maximum notional volume credit limit, VMAXN. This is a limit across all instruments in the account. Atstep312, the total volume, VOL, is also zeroed out. Atstep313,computer1 looks for another unsettled flow of any instrument C in account A. Again, “another” is arbitrary. Atstep314, it is asked whether such another unsettled flow has been found. If “yes”,step315 is executed; if “no”,step316 is executed.
Let R be the conversion factor “fixed rate C:N”, where C is the instrument that we are looping through currently. Then, step315 sets VOL to be the previous VOL plus the quantity R times the flow amount. Step313 is then entered into. Atstep316, X is set equal to VMAXN minus VOL. Again, X is the limit from just this flowchart. Atstep317, the maximum excursion of the traded instrument L:Q is set equal to the minimum of the previous value of the maximum excursion of the traded instrument L:Q and X times “fixed rate N:L”, i.e., we are converting from the notional instrument to the lot instrument. Similarly, the minimum excursion of the traded instrument L:Q is set equal to the maximum of the previous version of the minimum excursion of the traded instrument L:Q and minus X times the same conversion factor. The method ends atstep318.
FIG. 32 illustrates howcomputer1 calculates an instrument position limit, i.e., howcomputer1 performs step216 ofFIG. 25. This type of position limit differs from the previous position limit flowcharts (FIGS. 26 and 27) in that the guaranteeingagent5 is specifying that anotheragent2 cannot trade any more than j L for Q, rather than theother agent2 can trade no more than jL orjQ. This type of input credit limit is not as common as the ones described inFIGS. 26 and 27. If noagent2 has specified this type of input credit limit, thisflowchart33 does not have to be executed. (Similarly, if noagent2 has specified a certain other type of input credit limit, the flowchart corresponding to that credit limit does not have to be executed.) Both the L and the Q have to match in order for thisflowchart33 to be executed, unlike the flowcharts described inFIGS. 26 and 27.
The method starts atstep321. Atstep322,computer1 looks up the specified maximum position credit limit for the traded instrument L:Q, PMAX(L,Q), and the specified minimum position credit limit for the traded instrument L:Q, PMIN(L,Q). Instep322, the total position, POS, is also zeroed out. Instep323,computer1 looks for another unsettled flow pair with lot instrument L, quoted instrument Q, and account A. Again, “another” is arbitrary. Atstep324, it is asked whether such another unsettled flow pair has been found. If “no”, control passes to step328. If “yes”, control passes to step325, where it is asked whether the lot instrument flows to account A'sborrower2. In other words, the calculation is done in terms of the lot instrument to begin with, so that we do not have to convert to the lot instrument at the end of the calculation. If the answer to this question is “yes”,step326 is executed, where POS is incremented with the lot instrument flow amount. Control then passes to step323. If the answer to the question posed instep325 is “no”,step327 is executed, where POS is decremented by the lot instrument flow amount. Again, control then passes to step323. Atstep328, X is set equal to PMAX(L,Q) minus POS, and Y is set equal to PMIN(L,Q) minus POS. Atstep329, the maximum excursion of the traded instrument L:Q is set equal to the minimum of the previous version of the maximum excursion of the traded instrument L:Q and X; and the minimum excursion of the traded instrument L:Q is set equal to the maximum of the previous value of the minimum excursion of the traded instrument L:Q and Y. The method ends atstep330.
FIG. 33 illustrates howcomputer1 calculates a traded instrument volume limit, i.e., howcomputer1 performs step218 ofFIG. 25. This method is similar to the method described inFIGS. 28 and 29, except the limit is on the volume traded of L for Q, not a limit on the volume of L or Q individually. The method starts atstep341. Instep342,computer1 retrieves the specified maximum volume input credit limit for the traded instrument L:Q, VMAX(L,Q). Also instep342, the total volume VOL is zeroed out. Instep343,computer1 looks for another unsettled flow pair with lot instrument L, quoted instrument Q, and account A. Again, “another” is arbitrary.
Atstep344, it is asked whether such another unsettled flow pair has been found. If “no”, control passes to step346. If “yes”, control passes to step345, where VOL is augmented by the lot instrument flow amount. The calculation is done in the lot instrument, so that we do not have to convert to the lot instrument at the end; and it makes the calculation more stable, because we don't have to worry about fluctuating rates. Control is then passed to step343. Atstep346, X is set equal to VMAX(L,Q) minus VOL. Atstep347, the maximum excursion of the traded instrument L:Q is set equal to the minimum of the previous version of the maximum excursion of the traded instrument L:Q and X. Similarly, the minimum excursion of the traded instrument L:Q is set equal to the maximum of the previous value of the minimum excursion of the traded instrument L:Q and minus X. The method stops atstep348.
FIG. 34 illustrates the reporting bycomputer1 of single-hop trades. This method is executed after a match has been made, i.e., after a bid or offer has been taken by acounterparty2. The method ofFIG. 34 can be done either in real time or in batch mode (i.e., combined with the reporting of other trades). InFIG. 34, L is the lot instrument, Q is the quoted instrument, B is theagent2 who is buying L, S is theagent2 who is selling L, P is the trade price, FLis the amount of L bought and sold, FQis P times FL, i.e., the counter-amount in terms of instrument Q, and T is the settlement date and time.
The method starts atstep351. Atstep352,central computer1 issues anelectronic deal ticket353 to an auditor. The auditor is a trusted third party, e.g., an accounting firm.Ticket353 has a plaintext portion and an encrypted portion. The plaintext gives the ticket ID, and the time and date that theticket353 is generated. The encrypted portion states that agent B bought FLfor FQfrom agent S for settlement atT. Deal ticket353 is digitally signed bycentral computer1 for authentication purposes, and encrypted bycentral computer1 in a way that the auditor can decrypt the message butcentral computer1 cannot decrypt the message. This is done for reasons of privacy, and can be accomplished bycomputer1 encrypting the message using the public key of the auditor in a scheme using public key cryptography.
Atstep354,computer1 issues an “in”flow ticket355 to buyer B and to the auditor.Flow ticket355 contains a plaintext portion and an encrypted portion. The plaintext gives the ticket ID, the time and date theticket355 is generated, and the name of agent B. The encrypted portion states that you, agent B, bought FLfor FQfrom counterparty S for settlement atT. Ticket355 is digitally signed bycomputer1 and encrypted in such a way that it may be decrypted only by agent B and by the auditor, not bycomputer1. Two different encryptions are done, one for agent B and one for the auditor.
Atstep356,computer1 issues an “out”flow ticket357 to seller S and to the auditor. Outflow ticket357 contains a plaintext portion and an encrypted portion. The plaintext gives the ticket ID, the time and date of issuance, and the name of agent S. The encrypted portion states that you, agent S, sold FLfor FQto counterparty B for settlement atT. Ticket357 is digitally signed bycomputer1 and encrypted only to agent S and to the auditor, not tocomputer1. Two different encryptions are used, one to agent S and one to the auditor.
Tickets353,355, and357 can include the digital identity of the individual within theagent2 whose smartcard was plugged into the agent's computer when the transaction was made. The method ends atstep358.
FIG. 35 illustrates howcomputer1 electronically reports a multi-hop deal. This method is performed after the match has been made and can be done either in real time or in batch mode. Agents B and S do not know each other, as they know the identities of just their nearestneighboring agents2. The notation for this flowchart is identical to that forFIG. 35, except that B is the ultimate buyer of L and S is the ultimate seller of L.
The method begins atstep361. At step362,computer1 issues dealticket363 to the auditor.Ticket363 contains a plaintext portion and an encrypted portion.Ticket363 is digitally signed bycomputer1 and encrypted only to the auditor. The encrypted portion states that agent B bought FLfor FQfrom agent S for settlement at T, and that the deal was fulfilled by multiple direct trades in D, the directed deal fulfillment graph, i.e., the type of graph that is illustrated inFIG. 10. In other words, the auditor knows everyagent2 in the chain.
Atstep364,computer1 looks for the next unprocessed agent V in graph D. Again, “next” is arbitrary. Atstep365, it is asked whether such an unprocessed agent V has been found. If not, the method stops atstep366. If the answer is “yes”,node loop370 is entered into. For agent V, this node loop examines the set EVof directededges3 in D which have agent V as either a source or destination. Eachedge3 has an amount F that is greater than zero and less than or equal to FL. Note that this verification process is for illustration only; there would not be a match if these constraints were not satisfied. Atstep367, it is asked whether agent V is the ultimate buyer B of the deal. If “no”, control is passed to step368. If “yes”, control is passed to step371.
Atstep368, it is asked whether agent V is the ultimate seller S of the deal. If “no”, control is passed to step369. If “yes”, control is passed to step372. Atstep369,computer1 concludes that agent V is an incidental participant in the deal, i.e., amiddleman5. Control is then passed to step373, which verifies that the sum of theedge3 amounts having agent V as a source equals the sum of the edge amounts 3 having agent V as a destination. Sums are used because thatagent5 could haveseveral edges3 in and out. Therefore, it is known that agent V has no net market position change. Control is then passed to step376. At step372, it is verified that agent V is the source node2 (as opposed to the destination node) of alledges3 in EV. In step375, it is verified thatedge3 amounts in EVsum to FL, the net amount sold. Control is then passed to step376.
Instep371, it is verified that agent V is the destination node2 (as opposed to the source node) of alledges3 in EV. Atstep374, it is verified thatedge3 amounts in EVsum to FL, the net amount bought. Control is then passed to step376, wherecomputer1 looks for the next unprocessed edge in EVcorresponding to account A. Steps376-382 constitute an edge loop. Account A is any account held by or extended to counterparty X. Counterparty X is thecounterparty2 to agent V for thatedge3. Theedge3 has to have some amount F, where F is greater than 0 and less than or equal to FL, and an implicit counter-amount F times P; otherwise, there would be no way to clear the trade. Again, “next” instep376 is arbitrary. Control is then passed to step382.
Atstep382, it is asked whether such a nextunprocessed edge3 has been found. If not, control is passed to step364. If “yes”, control is passed to step381, where it is asked whether agent V is thedestination node2 for thisedge3. If “yes”, then step380 is executed. If “no”, then by definition, agent V is thesource node2 for thisedge3, and step379 is executed. Control is passed to step376 after either ofstep379 or380 is executed.
Atstep380,computer1 reports an “in”flow ticket377 to agent V, because the lot currency is flowing in to agentV. Flow ticket377 contains a plaintext portion and an encrypted portion. The plaintext includes the ticket ID, the time and date of issuance, and the name of agent V. The encrypted portion states that you, agent V, bought F of L for F times P of Q from counterparty X for settlement at T. In this case, counterparty X is just theimmediate neighbor2 to agent V, preserving anonymity.Ticket377 is digitally signed bycomputer1 and encrypted bycomputer1 only to agent V and to the auditor, not tocomputer1. Two encryptions are performed, one to agent V and one to the auditor.
Atstep379,computer1 generates an “out”flow ticket378 toagent V. Ticket378 contains a plaintext portion and an encrypted portion. The plaintext includes the ticket ID, the time and date of issuance, and the name of agent V. The encrypted portion states that you, agent V, sold F of L for F times P of Q to counterparty X for settlement at T. Again, counterparty X is just theimmediate neighbor2 to agent V, preserving anonymity.Flow ticket378 is digitally signed bycomputer1 and encrypted bycomputer1 only to agent V and to the auditor, not tocomputer1. Two encryptions are performed, one to agent V and one to the auditor.
Tickets363,377, and378 can include the digital identity of the individual withinagent2 whose smartcard was plugged into the agent's terminal when the transaction was made.
The above description is included to illustrate the operation of the preferred embodiments and is not meant to limit the scope of the invention. The scope of the invention is to be limited only by the following claims. From the above discussion, many variations will be apparent to one skilled in the art that would yet be encompassed by the spirit and scope of the present invention.