U.S. patent application number 09/898305 was filed with the patent office on 2002-07-25 for credit handling in an anonymous trading system.
This patent application is currently assigned to Electronic Broking Services Limited. Invention is credited to Crane, Alastair G., Ginsberg, Paul M., Krishnasami, Srivathsan, McPherson, Roy S., Mills, Gregory D., Walder, Robert.
Application Number | 20020099641 09/898305 |
Document ID | / |
Family ID | 24415758 |
Filed Date | 2002-07-25 |
United States Patent
Application |
20020099641 |
Kind Code |
A1 |
Mills, Gregory D. ; et
al. |
July 25, 2002 |
Credit handling in an anonymous trading system
Abstract
In an anonymous trading system, credit between counterparties is
effectively increased by netting buy and sell trades to reflect the
true risk to which each party is exposed. Credit limits are
adjusted by calculating the exposure in each currency at the
relevant time and then converted into the credit limit currency
equivalent. The credit limits are adjusted accordingly. The
resulting credit limits may be different for bids and offers by or
from a given counterparty.
Inventors: |
Mills, Gregory D.;
(Flanders, NJ) ; Walder, Robert; (Oradell, NJ)
; Crane, Alastair G.; (London, GB) ; Krishnasami,
Srivathsan; (New York, NY) ; McPherson, Roy S.;
(Essex, GB) ; Ginsberg, Paul M.; (Stamford,
CT) |
Correspondence
Address: |
OSTROLENK FABER GERB & SOFFEN
1180 AVENUE OF THE AMERICAS
NEW YORK
NY
100368403
|
Assignee: |
Electronic Broking Services
Limited
|
Family ID: |
24415758 |
Appl. No.: |
09/898305 |
Filed: |
June 29, 2001 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
09898305 |
Jun 29, 2001 |
|
|
|
09603514 |
Jun 23, 2000 |
|
|
|
Current U.S.
Class: |
705/37 ;
705/39 |
Current CPC
Class: |
G06Q 40/00 20130101;
G06Q 40/025 20130101; G06Q 40/04 20130101; G06Q 20/10 20130101;
G06Q 40/08 20130101 |
Class at
Publication: |
705/37 ;
705/39 |
International
Class: |
G06F 017/60 |
Claims
What is claimed is:
1. An anonymous trading system for trading instruments between
trading parties; comprising: a communications network for
transmitting electronic messages; a plurality of order input
devices connected to the communications network each for generating
electronic order including bid and/or offer orders and for
communication to a trader order information received from others of
said plurality of order input devices over the network; at least
one matching engine connected to the network for matching bid and
offer orders input into the system from the order input devices and
for executing deals where prices is are matched; market
distribution means connected to the network for distributing order
price messages to the trader terminals, the market distribution
means being responsive to the order messages and the matching
engine; credit limit storage means for storing credit limits
available for trades between each trader or group of traders and
possible counterparty traders or groups of traders; and credit
adjustment means for adjusting the credit available between a given
party and a counterparty following a trade with that counterparty,
the credit adjustment means calculating the change in exposure to
the party resulting from the trade and adjusting the credit
available accordingly, whereby trades between a given party and
each counterparty are netted.
2. An anonymous trading system according to claim 1, wherein the
order input devices for a given trading floor are connected to a
trading agent node connected to the communications network, wherein
the credit limit storage means and the credit adjustment means for
a given trading floor are resident at the trading agent node to
which the trading floor is attached.
3. An anonymous trading system according to claim 1, wherein the
order input devices for a given trading floor are connected to a
trading agent node connected to the communications network, and the
credit limit storage means and the credit adjustment means for a
given trading floor are resident at a further trading agent
node.
4. An anonymous trading system according to claim 3, wherein the
trading agent node for a given trading floor comprises a means for
sending to the separate trading node on which the credit limit
storage means and credit adjustment means for that trading floor
resides, a credit enquiry message (DealCreditMaker,
DealCreditTaker) when a deal with a given counterparty is
proposed.
5. An anonymous trading system according to any of claims 1 to 4,
wherein the credit limit storage means is at least partially
resident at the matching engine.
6. An anonymous trading system according to claim 5, wherein the
matching engine includes a subset of the credit limits
available.
7. An anonymous trading system according to any previous claims,
wherein the credit adjustment means and the credit limit storage
means together store the credit limit between the trading floor and
each possible counterparty, and for each counterparty the amount of
credit utilised, the amount of each deal, whether each deal is a
buy or sell and the amount of credit available for further
trades.
8. An anonymous trading system according to any previous claim,
wherein the matching engine and the market distribution means
together form a single broking node of the communications network,
the network comprising a plurality of broking nodes.
9. An anonymous trading system according to claim 8, wherein each
broking node stores a subset of the credit limit information for
each trading floor connected to the system.
10. An anonymous trading system according to claim 9, wherein the
system trades foreign exchange spot (F/X spot) and the subset of
credit limit information stored by each broking node comprises an
identification of whether or not credit exists between each party
and each possible counterparty.
11. An anonymous trading system according to claim 10, wherein the
subset of credit information is a yes/no matrix.
12. An anonymous trading system according to claim 1 wherein the
instrument traded includes two or more currency value and the
credit adjustment means includes means for calculating the currency
exposure in each currency.
13. An anonymous trading system according to claim 12, wherein the
credit adjustment means includes means for converting the
calculated currency exposures into a credit limit base currency
equivalent.
14. An anonymous trading system according to claim 12, wherein the
credit adjustment means includes means of calculating exposure at
settlement date.
15. An anonymous trading system according to claim 12, wherein the
credit adjustment means includes means for calculating exposure
within a pre-defined time bucket.
16. An anonymous trading system according to claim 12, wherein the
credit adjustment means calculates the currency exposure in each
currency for a plurality of financial instruments.
17. An anonymous trading system according to claim 16, wherein the
credit adjustment means includes means for calculating exposure at
settlement date.
18. An anonymous trading system according to claim 16, wherein the
credit adjustment means includes means for calculating exposure
within a pre-defined time bucket.
19. An electronic broking system for trading financial instruments
between trading parties; comprising a communications network for
transmitting electronic messages and including a plurality of
broking nodes and a plurality of trading agent nodes, each trading
agent being connected to a broking node; a plurality of order input
devices, the trading terminals of a trading floor being connected
to a trading agent node; each order input device generating
electronic order messages including bid and/or offer orders and for
communicating order price information received from others of said
plurality of order input devices from the trading agent node;
wherein each broking node comprises means for matching bid and
offer orders input into the system from the order input devices,
means for executing deals where prices are matched and means for
distributing to the order input devices order price messages, the
distributing means being responsive to the order price messages and
the matching means; the system further comprising credit limit
storage means for storing credit limits available for trades
between each trader or group of traders and possible counterparty
traders or groups of traders; and credit adjustment means for
adjusting the credit available between a given party and a
counterparty following a trade with that counterparty, the credit
adjustment means determining the change in exposure to the party
resulting from the trade and adjusting the credit available
accordingly, whereby trades between a given trader and each
counterparty are netted.
20. An anonymous trading system according to claim 19, wherein the
instrument traded includes two or more currency value, and the
credit adjustment means includes means for calculating the currency
exposure in each currency.
21. An anonymous trading system according to claim 20, wherein the
credit adjustment means includes means for converting the
calculated currency exposures into a credit limit base currency
equivalent.
22. An anonymous trading system according to claim 20, wherein the
credit adjustment means includes means for calculating exposure at
settlement date.
23. An anonymous trading system according to claim 20, wherein the
credit adjustment means includes means for calculating exposure
within a pre-defined time bucket.
24. An anonymous trading system according to claim 20, wherein the
credit adjustment means calculates the currency exposure in each
currency for a plurality of financial instruments.
25. An anonymous trading system according to claim 24, wherein the
credit adjustment means includes means for calculating exposure at
settlement date.
26. An anonymous trading system according to claim 24, wherein the
credit adjustment means includes means for calculating exposure
within a pre-defined time bucket.
27. An electronic broking system for trading financial instruments
between trading parties; comprising a communications network for
transmitting electronic messages and including a plurality of
broking nodes and a plurality of trading agent nodes, each trading
agent being connected to a broking node; a plurality of order input
devices, the order input devices of a trading floor being connected
to a trading agent node; each order input device generating
electronic order quotation messages including bid and/or offer
orders and communicating order price information received from
others of said plurality of order input devices from the trading
agent node; wherein each broking node comprises means for matching
bid and offer orders input into the system from the order input
devices, means for executing deals where orders are matched and
means for distributing to the trader terminals order price
messages, the distributing means being responsive to the order
price messages and the matching means; and wherein at least some of
the trading agent nodes comprise credit limit storage means for
storing credit limits available for trades between each trader or
group of traders and possible counterparty traders or groups of
traders; and further comprise credit adjustment means for adjusting
the credit available between a given party and a counterparty
following a trade with that counterparty, the credit adjustment
means adjusting the credit available by determining the change in
exposure to the party resulting from the trade and adjusting the
available credit accordingly, whereby trades between a given party
and each counterparty are netted.
28. An electronic broking system according to claim 27, wherein the
credit limit storage means and credit limit adjustment means for a
given trading floor are located at the trading agent node to which
the order input devices of said trading floor are connected.
29. An electronic broking system according to claim 27, wherein the
credit limit storage means and credit limit adjustment means for a
given trading floor are located at a trading agent node to which
the order input devices of the trading floor are not directly
connected.
30. An anonymous trading system according to claim 29, wherein the
instrument traded includes two or more currency value, and the
credit adjustment means includes means for calculating the currency
exposure in each currency.
31. An anonymous trading system according to claim 30, wherein the
credit adjustment means includes means for converting the
calculated currency exposures into a credit limit base currency
equivalent.
32. An anonymous trading system according to claim 30, wherein the
credit adjustment means includes means for calculating exposure at
settlement date.
33. An anonymous trading system according to claim 30, wherein the
credit adjustment means includes means for calculating exposure
within a pre-defined time bucket.
34. An anonymous trading system according to claim 13, wherein the
credit adjustment means calculates the currency exposure in each
currency for a plurality of financial instruments.
35. An anonymous trading system according to claim 34, wherein the
credit adjustment means includes means for calculating exposure at
settlement date.
36. An anonymous trading system according to claim 34, wherein the
credit adjustment means includes means for calculating exposure
within a pre-defined time bucket.
Description
RELATED APPLICATION
[0001] This is a continuation-in-part of U.S. patent application
Ser. No. 09/603,514, filed Jun. 23, 2000, priority of which is
claimed under 35 U.S. .sctn.120.
FIELD OF THE INVENTION
[0002] This invention relates to electronic brokerage systems and
in particular to systems in which counterparties trade anonymously
within fixed credit limits. Such systems may trade financial
instruments such as foreign exchange and forward rate agreements.
The invention is particularly concerned with the handling of credit
limits.
BACKGROUND TO THE INVENTION
[0003] A number of anonymous trading systems are known in the art.
EP-A-0,399,850, EP-A-0,406,026 and EP-A-0,411,748 all assigned to
Reuters Ltd disclose aspects of an automated matching system in
which a host computer maintains a central database of bids and
offers submitted by terminals connected to the host via a network.
The host also maintains records of credit limits between each
trading bank and the possible counterparties with which it is
willing to trade. The host computer uses information in its central
database to match bids and offers and buy and sell orders based on
matching criteria which include the counter party credit
limits.
[0004] Generally, counterparty credit limits are set for each bank
or each trading floor and the host computer establishes a gross
counter party credit limit for each possible pair of
counterparties. The gross counter party credit limit is the minimum
amount of remaining credit between two counterparties.
[0005] A trader's terminal will display a subset of the trading
book, typically the best few bids and offers. These will be updated
periodically to ensure that the trader sees the true state of the
market.
[0006] A problem with the system outlined above is that the trader
sees the bids and offers irrespective of whether he has sufficient
credit with the counter party submitting that bid or offer to
trade. As a result, a trader can attempt to trade when there is no
available credit. As the system is anonymous the trader has no
knowledge of the counterparty until a trade as been completed and
so, when he hits a bid or offer, has no idea as to whether it is
likely to be accepted or rejected for lack of credit. This is
extremely frustrating for a trader, particularly in a fast moving
is market in which trading opportunities can easily be lost.
[0007] The problem arises as the host computer only checks
available credit after a deal has been proposed and a potential
match identified.
[0008] This problem was solved in WO93/15467 now assigned to EBS
Dealing Resources inc. Instead of displaying the actual trading
book, or a part of it, to each trader, a different market view is
shown to each trader in which bids and offers from counterparties
which whom they have insufficient or no credit are screened out.
Thus, the trader only sees prices with which he knows he can
deal.
[0009] The architecture of the system of WO93/15467 is very
different from the of the Reuters system and is based on a
distributed network with a number of arbitrators which perform
matching. Actual credit limits are stored at local bank nodes to
which each of a bank's trading terminals are connected ensuring
that sensitive credit data does not leave the bank's physical site.
The actual trading book is sent by the arbitrators to the market
distributor. The market distributor forms a market view specific to
a given trading floor and sends it to the relevant bank node. A
different market view may be formed for each trading floor
depending on credit criteria. Thus, the market view which is
distributed to each of the bank nodes is the complete market view
with credit screening taking place, the market distributor to
filter out any prices with which the bank, or a given trading floor
within the bank, has insufficient credit.
[0010] In addition, the market distributers also have limited
credit information, maintaining a credit matrix which may store a
simple "yes-no" credit indicator for given counterparties. When a
match is made, the prices having already been screened for credit,
the bank node will make a second credit check using the credit
matrix to see whether any previously extended credit has already
been exhausted.
[0011] While both the above systems have been used successfully in
the financial trading markets for a number of years, they both
suffer from the disadvantage that they require banks to tie up
large amounts of credit in one area of their trading activities. A
typical bank will be trading a number of financial instruments and
a number of different markets and will want to trade up to its
credit limits in each trading day. If one particular market is
quiet it will want to be able to divert the credit assigned to that
market to a different field. Similarly, if a particular market is
very active it will want to be able to take advantage of that
activity. It is desirable therefore, to minimise the amount of
credit tied up and for it to reflect the actual exposure of the
invention.
SUMMARY OF THE INVENTION
[0012] The invention aims to overcome this disadvantage by reducing
the amount of credit that need be maintained in the anonymous
trading system. and in its broadest form provides for the netting
of trades between counterparties. Thus, if a party sells an amount
to a counterparty and later buys from the same counterparty, the
available credit of each party with the other is decremented only
by the difference between the trades or the net trade.
[0013] The invention provides an anonymous trading system for
trading financial instruments between traders for storing credit
limits available for trades between each trader or group of traders
and possible counterparty traders or groups of traders and credit
adjustment means for adjusting the credit available between a given
party and a counterparty following a trade with that counterparty,
the credit adjustment means calculating the change in exposure to
the party resulting from the trade and adjusting the credit limits
accordingly, whereby trades between a given trader and each
counterparty are netted.
[0014] Embodiments of the invention have the advantage that the
amount of credit that must be allocated specifically to an
anonymous trading system by a bank may be reduced without reducing
the dealing capacity. This means that more credit is available to
the bank for allocation to other trading areas as so the overall
trading capacity can be increased without varying credit
limits.
[0015] Embodiments of the invention also have the advantage that
the netting of credit more closely resembles the actual risk to
which a bank is exposed. In the prior art, a sale of $A followed by
a purchase of $B from the same counterparty would have reduced the
credit available with that counterparty by $A-B which equals the
actual amount of risk to which one party is exposed if the other
should default.
[0016] Preferably, the order input means, for example trader
terminals for a given trading floor are connected to a Trading
Agent node connected to the communications network, wherein the
credit limit storage means and the credit adjustment means for a
given trading floor are resident at the trading agent node to which
the trading floor is attached.
[0017] In each embodiment of the invention, one of a number of
netting regimes may be adopted. A given party may designate a given
counterparty or counterparties as netting credit groups. Netting
may be performed on a per instrument basis or on a cross instrument
basis.
[0018] Netting may be by settlement date, by time bucket or by
total credit exposure.
[0019] In one embodiment of the invention, netting is by settlement
date. Each netted currency exposure is calculated and then
converted into the credit limit base currency equivalent if
necessary. If the exposure is negative, meaning that the party owes
the currency, then the exposure is considered to be zero if netting
is on a per instrument basis. Positive credit limit currency
equivalent amounts are added together to give the total credit
utilisation for that value date for that instrument.
[0020] In a further preferred embodiment, settlement date netting
is applied on a cross instrument basis. Exposures are calculated in
the same manner as the per instrument basis above but a negative
exposure is only considered to be zero if the sum of all the
exposures across all the instruments is negative.
[0021] Instead of netting on the basis of a specific settlement day
when there is a delivery of currency for value on that date,
netting may be performed within a specific floor-defined time
bucket. Any trade performed within that bucket is included in the
currency exposure calculations. Netting by time bucket may be
formed on a cross instrument basis.
[0022] In one preferred embodiment of the invention netting is
performed irrespective of trade date according to the total credit
exposure. This may be performed either on a per instrument or cross
instrument basis.
BRIEF DESCRIPTION OF THE DRAWINGS
[0023] An embodiment of the invention will now be described, by way
of example only, and with reference to the accompanying drawings,
in which:
[0024] FIG. 1 is an overview of a trading system embodying the
invention;
[0025] FIG. 2 shows the flow of messages when a new quote is
submitted in the system;
[0026] FIG. 3 depicts the production of a market view to
traders;
[0027] FIG. 4 shows the flow of messages when a trader submits a
buy or sell order;
[0028] FIG. 5 shows the flow of messages to update broker nodes
following a buy or sell order;
[0029] FIG. 6 shows the flow of messages when a broker updates a
quote;
[0030] FIG. 7 shows the deal execution process;
[0031] FIG. 8 shows the message flow in a global credit
environment;
[0032] FIG. 9 is a simple example of how credit exposure is
calculated according to the invention;
[0033] FIG. 10 is a more complex example of how credit exposure is
calculated according to the present invention
[0034] FIG. 11 is an example of how price distribution is varied as
a result of netted trades;
[0035] FIG. 12 shows the effect on credit limits of the trades of
FIG. 9 calculated by the prior art method;
[0036] FIG. 13 illustrates netting between different levels in bank
hierarchies;
[0037] FIG. 14 illustrates a parent or hypothetical parent for a
bank, Bank B and;
[0038] FIG. 15 illustrates a parent or hypothetical parent for a
second bank, Bank A;
DESCRIPTION OF PREFERRED EMBODIMENT
[0039] The present invention will be described with reference to
the dealing architecture illustrated in FIGS. 1 to 6 and which will
be hereinafter described. However, it should be understood that the
invention is not limited to that architecture but could be
implemented in any anonymous trading system. For example, it could
be implemented on either of the Reuters and EBS Dealing Resources
prior art systems known in the art and referred to earlier.
[0040] The electronic brokerage system to be described provides a
platform for trading at least the following instruments: FX
(Foreign Exchange) Spot, FRA's, and Forwards and also FX Forwards,
CFDs, short-dated government and/or central bank paper, commercial
bills, CDs, inter-bank deposits, commercial paper, repos,
interest-rate futures, swaps, options and a miscellany of
tailor-made variants on these basic products. These are all
referred to as financial instruments. It may also be used for
trading non-financial products such as commodities.
[0041] Traders at trader terminals are connected to a
communications network which allows electronic messages to be
passed between terminals, submit quotes and hits which are then
passed on to each of a plurality of broker nodes throughout the
system. A quote is a bid or offer order submitted by a trader to
"make a market" and is distributed to other traders as part of a
market view. Quotes are thus orders visible to other traders. A hit
is a buy or sell order submitted by a trader wishing to create a
deal on the basis of a price displayed on his market view derived
from one or more quotes. Hits are orders which are invisible to
other traders.
[0042] The computer trading system of FIG. 1 comprises a plurality
of trading agents 10 each connected to at least one of a plurality
of broker nodes 12. Each trading agent is the means by which the
trader terminals access the trading system with a given trader
terminal being attached to one or more trading agents.
[0043] Trader terminals (not shown) may be workstations or other
computer terminals configured to generate and submit electronic
price quotation messages including bid and/or offer prices, quotes
and orders (usually through use of a specialised key pad) and to
communicate market view data, including price and amount available,
for financial instruments to be traded. The communication is
usually by display but could also be by printing the information,
voice synthesis or otherwise. The trader terminals are one example
of order input devices. Orders may be input manually by traders or
automatically, for example by pre-programmed instruction to submit
an order for when the market reaches a certain condition.
[0044] Traders are typically grouped as part of a financial
institution, such as a bank, which arranges traders as part of a
trading floor. A trading floor is a group of traders is under
common control of a trading floor administrator who allocates
credit lines for the trading floor against other trading floors.
The market view for a trader, or group of traders, is the market
information (price, volume, etc.) That the traders can see that
reflect the market. The market views are preferably pre-screened
for credit compatibility, as described in WO/93/15467. Thus,
traders only see displayed quotes with which they can trade. As
well as extending credit to a trading floor, credit may be extended
to a bank as a whole (many banks have several trading floors
indifferent locations), or to groups of trading floors.
[0045] The system is an anonymous trading system in which the
market views produced by the brokers comprise price and amount
information without identifying the source of the price. The prices
displayed for available bids and offers and the amounts available
at those prices, are thus aggregates of one or more quotes. Only
the quotes of parties satisfying the pre-screen credit criteria are
included in the aggregate price displayed. The market views
produced by the broker nodes thus differ from one trading floor to
another depending on the credit allocation.
[0046] The trading agent node provides services to a specific
trading floor or group of traders. These services include providing
access to the network for each trading work station, completing
deals, producing deal tickets and maintaining historical dealing
information for traders. Each trading agent node must connect to at
least one broker node to access the trading system. A group of
trader terminals thus connects to a trading agent 10 to access the
system.
[0047] Each Broker node 12 provides the basic order matching and
price distribution services. The Broker nodes are arranged in a
structure called a Clique Tree which enables faster communications
routing, following very specific but simple rules. The Clique Tree
is a network structure where individual nodes are grouped into
Cliques, and the Cliques are then arranged into a tree structure.
Each Broker can be linked logically to a number of Brokers, which
are referred to as its neighbor Brokers. Communication between
Brokers is on an equal level, with no "up" or "down" direction in
the network.
[0048] In the embodiment of FIG. 1, there are three Cliques: that
formed by brokers 12a, 12b and 12c, that formed by brokers 12b,
12d, 12e and 12f and that formed by brokers 12e and 12f. It will be
seen that brokers 12b and 12e are both in two Cliques.
[0049] While Trading Agents must be connected to at least one
Broker node, they are not members of the Clique Tree, but remain
outside the structure. A Trading Agent connected to multiple Broker
nodes will receive multiple sets of market prices. Even though the
price information from different Broker nodes can be substantially
the same, the information may be received at different intervals. A
Trading Agent will send a given trading order to only one Broker
node.
[0050] The term Broker node is used to describe a computer arranged
as a physical or logical node in a computer network providing a
broking function. The basic broking function is the storing of
quotes, providing the quotes to traders in the form of a market
view and matching quotes and orders. The Broker nodes in the
described embodiment also perform further functions, but these are
not essential features of what is defined as a Broker node.
[0051] Thus, the broker nodes each provide a matching engine which
is connected to the network for matching submitted bids and offers
and, when a match is made, for executing deals. They also perform
the function of market distributors distributing price messages to
the trader terminals in response to the price quotation messages
and the matching engine. Thus, brokers distribute prices to create
market views which are aggregations of quotes in the order book.
Within the context of the present invention it is preferred that
the matching and market distribution functions are amalgamated in
the broking node but the invention is equally applicable to systems
in which the functions are separate and performed at geographically
and/or logically separate locations. An example of such a system is
WO93/15467 referred to earlier.
[0052] The Broker nodes are equal to each other, and perform the
same functions. The arrangement of the network or their position in
it is transparent to the broker nodes. They only need to know about
their neighbours. Each Broker node has knowledge of all orders in
the market, and is able to match orders as soon as they are
submitted. As each Broker node maintains a full list of orders in
the market, it is therefore able to customize market views as
needed by the Trading Agents and is able to react faster to market
information as soon as it is received.
[0053] To understand the purpose of the distributed broker node
arrangement, price distribution and deal execution will now be
described with reference to FIG. 2.
[0054] The deal process begins with one or more traders submitting
orders into trader terminals. An order is a dealing request from a
trader, with instructions to buy or sell with specific
restrictions, such as price and amount. A quote is a persistent
order that remains available in the system and is distributed as
part of the market price information. Quotes are used to "make the
market", and are known to traders as bids or offers. A hit is an
order that has "invisible" and "fill or kill"
properties("invisible"). Hits are not distributed as part of the
market price. A hit does not remain in the system; if it can not be
dealt when entered, it is removed.
[0055] An Order Book is a list of all the available orders in the
market. Since the Quotes are the only available orders, the book
consists of a list of Quotes. The Quotes are arranged in a queue in
the correct dealing order. The sort order of the queue may vary for
different trading instruments. The default sort order is by price
and time. In the system, each Broker node maintains a complete list
of all available quotes. In a system such as foreign exchange there
will, effectively, be two books, one showing orders to buy and the
other showing orders to sell.
[0056] The message flow in the system is described by named
messages, each carrying appropriate parameters throughout the
network. The process of submitting a quote (persistent order)
begins when a Trading Agent receives information from a trader
workstation that a trader has issued a bid or offer. The Trading
Agent then starts the quote submission process. When the Trading
Agent receives the quote information from the trader workstation,
it will create and maintain a context for the quote. It will then
send a Quote Submit message to the Broker node that it is connected
to. The Broker node will validate the quote and accept it if valid.
This first Broker node that receives the quote becomes the "owner"
Broker node for this quote. In example shown in FIG. 2 this is
Broker node 5. This is the only Broker node that can commit the
quote to a deal. The Broker node will create a context or "quote
object" and sort it into its queue for the correct tradable
instrument.
[0057] After the quote is placed into its queue, the owner Broker
node will then distribute the quote throughout the network by
sending QuoteAvailable messages to other Broker nodes. In this
example, Broker node 5 sends the QuoteAvailable message to Broker
nodes 2 and 6. As each Broker node receives the message, it creates
a context (quote object) and sorts it into its queue (order book).
It notes in the context which Broker node had sent it the message.
After placing it into the queue, the Broker node then sends the
QuoteAvailable message on, using broadcast routing rules, to all
neighbours except those in the same clique as the broker who sent
the message. Therefore, Broker node 2 sends it to 1, 3 and 4.
Broker node 4 then sends it to Broker node 7. At this point, all
Broker nodes know about the quote, and update their order books
accordingly.
[0058] The broadcast routing rules are applied to ensure that
network traffic is handled in an efficient manner and to reduce any
duplication of message flow.
[0059] The broadcast rules are:
[0060] 1. The Broker node originating information will send it to
all of its neighbour Broker nodes.
[0061] 2. A Broker node receiving the information will send it to
all of its neighbours Broker nodes except those in the same clique
as the Broker node that sent the information.
[0062] 3. If a message contains persistent information, such as a
quote, the information will be stored with the identifier of the
Broker node from which the information was received.
[0063] Note that these rules refer to the information, not the
message that contains it. For example, information about a quote
may be sent to one Broker node in a ProposeDeal message and to
another Broker node in a MarketUpdate message. However, the same
information is sent to both Broker nodes, and so the above rules
apply.
[0064] Price distribution is the process of providing market
information to the traders at the trader terminals. This
information is created by the Broker nodes and sent to the Trading
Agents for distribution to the traders. This process is shown in
FIG. 3.
[0065] Each Broker node will examine its queue of quotes (order
book) and calculate a view of the market for each Trading Agent
connected to it. This view is built specifically for the trading
floor that the agent represents. Views may be different based on
credit or other factors. The exact process for determining a market
view will vary based on the trading instrument. The view
information is sent to the Trading Agent in a MarketView message.
It follows, therefore, that each of the brokers holds information
about the credit relationships between all parties and
counterparties.
[0066] Hitting a quote is the basic process of creating a deal
between two traders. A hit from one trader is matched to a quote
from another trader. This process is shown in the FIG. 4. The
Trading Agent of the trader terminal hitting a price shown on his
market view display sends a HitSubmit message to the Broker node.
This message targets a price, not a specific quote. The Broker node
will scan its queue and find the first quote in the queue that can
be matched with the hit. The matching rules may vary based on the
trading instrument.
[0067] When the hit is matched to a quote, the Broker node will
modify its context for the quote, moving the amount matched from
"available" to "reserved pending deal". This will prevent the same
amount of the quote to be matched with another hit. The Broker node
will then send a ProposeDeal message to the Broker node from which
it received the quote. This message will target the specific quote.
In this example, the hit comes from a trader connected to a trading
agent connected to broker 7. Broker 7 will send the message to
Broker 4.
[0068] As each Broker node receives the ProposeDeal message, it
checks the quote in its queue. If the amount of the proposed deal
is still available in the queue, the Broker node performs a similar
process as the matching Broker node. The amount of the proposed
deal is moved from "available" to "reserved pending deal". The
ProposeDeal message is then sent to the Broker node from which it
received the quote. In the example, Broker node 4 sends it to
Broker node 2. Broker node 2 will then send it to Broker node
5.
[0069] The routing of a ProposeDeal message follows targeted
routing rules. Targeted routing is used to deliver information to a
specific Broker node. Since knowledge of specific Broker nodes is
not built into the system, the target is not a specific Broker
node, but is the Broker node from which the information originated.
For example, a message is not sent to "Broker node 714", but is
sent as to "the Broker node originating quote 42". The targeted
rules are:
[0070] 1. A Broker node originating a message about a specific
piece of information will send the message to the Broker node from
which it received the original information.
[0071] 2. A Broker node receiving a message about a specific piece
of information that it did not originate, will send the message to
the Broker node from which it received the original
information.
[0072] The message will thus follow the path of the original
information back to its source. In the example this is from Broker
node 7, to Broker node 5, via Broker nodes 4 and 2.
[0073] When the Broker node that originally created the quote
receives the ProposeDeal message, it performs the same checks and
amount reservation as the other brokers. Since this Broker node
owns the quote, it has the authority to commit the quote to a deal.
The ProposeDeal message represents the authority to commit the hit
to the deal. The Broker node will then initiate the deal process by
sending a HitAmount message to the Trading Agent that submitted the
quote. The deal execution process is described later.
[0074] As the deal matching process takes place, it is necessary
that the list of quotes maintained at each Broker node be keep up
to date. This is accomplished by each Broker node notifying others
when it makes a change to a quote, as shown in FIG. 5.
[0075] As each Broker node changes a quote in its queue, it
notifies all neighbour Broker nodes except those in the clique from
which it received the change. In the example above, Broker node 4
received notice of a change in a quote from Broker node 7 in a
ProposeDeal message. It notifies Broker node 2 by sending the
ProposeDeal message. Broker node 4 must now notify Broker nodes 1
and 3. This is done by sending a MarketUpdate message to these
Broker nodes.
[0076] Following the normal routing rules, the information about
the quote is distributed to each Broker node in the network. Any
Broker node receiving the MarketUpdate message will pass it to all
neighbours not in the clique from which it is received. Note that a
Broker node sending a ProposeDeal message should not also send a
MarketUpdate message to the same Broker node. This would result in
duplicate information being received and the deal amount being
reserved twice.
[0077] When the deal matching process is completed, as described
above, the deal execution process begins. This process completes
the deal and commits the traders to a deal. The process is shown in
FIG. 6. As matches are made and deals initiated, information is
made available for traders. This information can be used to inform
a trader that a deal is pending. Any given trading application can
decide if the trader should be informed. In any case, the
information is available.
[0078] The Taker's Trading Agent will be notified as soon as the
initial match is made and the ProposeDeal message is sent. This
agent can notify the traders workstation at this time. This pending
deal information may change as the deal confirmation continues. The
maker workstation is notified of the pending deal when the maker's
Trading Agent checks credit and sends the DealStatusMaker
message.
[0079] The deal execution process begins when the maker's Trading
Agent receives a HitAmount message from its Broker node. This
message informs the Agent that a match was made for one of its
quotes. The message identifies the quote as well as the amount of
the hit, counterparty and the identity of the hit. The Agent will
check with the trader workstation to make sure that the quote is
still available. The Agent will send a HitAmountwS message to the
workstation. The workstation will reply with a HitAmountWK message
to show that the workstation is still working and that the trader
did not interrupt the quote. At this point, the trader can no
longer interrupt the deal.
[0080] The Trading Agent will next check for available credit with
the counterparty. The credit check may allow the deal, reduce the
amount of the deal or disallow the deal. The Agent will then reduce
the available credit by the amount needed for the deal. This
reduction in available credit may affect future deals. The maker's
Trading Agent will now inform the taker's Trading Agent of the deal
by sending a DealStatusMaker message to its Broker node. The
message is targeted to the identity of the hit. The network Broker
nodes will route the message to the owner Broker node of the hit,
and that Broker node will deliver it to the taker's Agent. Once
this message is sent, the maker's Agent knows is that a deal may
have been done, but the deal is in doubt pending a reply. The
taker's Trading Agent completes the deal execution process. This
part of the process takes place when the Agent receives the
DealStatusMaker message from the maker. If the message shows a
valid deal, the process continues.
[0081] The taker's Trading Agent will next check for available
credit with the counterparty in a similar manner as the maker. The
credit check may allow the deal, reduce the amount of the deal or
disallow the deal. The Agent will then reduce the available credit
by the amount needed for the deal. This reduction in available
credit may affect future deals. It should be remembered that deals
are unlikely to be rejected at this stage as prices shown to
traders are pre-screened for credit. The taker's Trading Agent will
now log the deal to its disk. As soon as the information is
committed to persistent storage, the deal is done. Any checks on
the deal status will now show a binding deal. The agent will now
notify the trader, print a deal ticket and perform any other post
deal processing. At this point, the deal is done but the maker
doesn't yet know. As soon as the deal is done, the taker's Trading
Agent will notify the maker by sending a DealStatusTaker message to
its Broker node. This message is targeted to the quote and will be
routed to the maker's Agent.
[0082] The DealStatusTaker message contains final information about
the deal, and therefore the final changes to the quote. This
information is used by the network Broker nodes and the Trading
Agent. As the DealStatusTaker message is routed through the Broker
nodes, each routing Broker node will use the information to update
its quote context. The amount of the deal is moved from "reserved"
to "complete". The portion not done is moved from "reserved" to
"available" if the quote is still active. It will then notify other
Broker nodes of the changes and of the deal by sending a
MarketUpdate message to all other Broker nodes using network
routing rules.
[0083] When the DealStatusTaker message gets to the owner Broker
node of the quote, it will send it to the Trading Agent. The Agent
will record the deal to disk. At this point the deal is no longer
in doubt. The Agent will notify the trader, print a ticket and
perform any other processing that is required. Some trading
instruments may require additional information to be exchanged for
a deal. An example of this is the settlement instructions for EBS
spot FIX. This type of information is sent in a DealInformation
message. After the deal is processed, the Agents can develop this
information. The DealInformation message is sent to the Broker
node. The network Broker nodes will then route the message to the
other Agent where the information is processed as required by the
instrument. A deal is thus completed.
[0084] Once the deal is complete, the two parties will know the
identity of their respective counterparty for the first time. The
identity will be displayed on their terminal screen and shown, for
example, in a listing of deals performed in that trading session as
well as printed on the deal ticket and logged to disk. Each of
these comprises a means for identifying to each of the parties to
an executed deal the counterparty to the deal.
[0085] The manner in which credit is handled in the system
described will now be considered in more detail.
[0086] As mentioned previously, the system screens prices and deals
matching using credit, as a result of which all prices shown to a
deal should be available for trading. It will be understood from
the foregoing description that this requires each broker to have
sufficient credit information to be able to make credit decisions.
This is because the brokers are responsible for forming the market
view which is distributed to communicating trading agents. The
actual credit data is very complex and can vary by product and
institution. For example, the concept of credit in an F/X trading
system is straightforward as it is a spot market. However, for a
product such as FRA's it is more complex as deals are done over a
variety of time periods. Some banks may prefer to assign credit to
a counterparty over the whole of the range of their trading
activities whereas some banks will prefer to assign credit to
counterparties for a given financial instrument.
[0087] The system uses a single numeric value for each combination
of trading floor, counterparty trading floor and tradable element.
The purpose of the numerical value is to determine whether the two
floors have credit to deal in a particular element. The meaning of
the numerical value is specific to the instrument being traded. For
example, spot F/X uses the value as a yes/no flag (1 or 0) whereas
in Forward Rate Agreements (FRA) the value is used as a bit mask
for FRABBDA/ISDA decisions. Other instruments will have other
meanings. The credit is bi-lateral. Credit must exist between two
floors for any dealing activity to take place. The credit check is
made for a given trading element or pattern of trading elements as
determined by the instrument. As the system is bilateral the broker
will compare two credit values; that given by the first floor to
the second and that given by the second floor to the first. If the
values are compatible, the dealing operation is allowed. The
meaning of compatible will be determined by the instrument. In
terms of spot F/X if the amount proposed for the trade is lower or
equal to the lowest of the two credit values the deal can proceed.
Even if the deal is greater than the lowest credit value it may
still proceed but only for a part of the proposed deal amount equal
to the lowest credit value.
[0088] The full credit information for a credit floor is originated
for a trading agent that has credit authority for a trading floor.
This agent only has part of the total information; that relating to
its own trading floor although it is possible that more that one
trading floor is connected to a Trading Agent. When the credit
information changes, the Trading Agent will sent a CreditUpdate
message to its broker. The broker will combine the information from
the Agent into its total credit matrix and pass the message to
neighbour brokers as a broadcast message following the rules set
out earlier. Each broker will also store a record of from where the
credit information for a given floor came from.
[0089] In the prior art system described in WO93/15467 the bank
node holds the credit authority for a floor and is also responsible
for dealing activity for the floor. The deal execution process
described earlier is based on this credit model which is known as
local credit.
[0090] During the deal execution the Trading Agent is presented
with a potential deal. The Agent will examine the details of the
deal and determine how much credit is required to complete the
deal. It will check the available credit and, if it is insufficient
the Agent may reduce the amount of the deal or disallow the deal.
The amount of credit actually needed (the whole or reduced amount)
is reserved from the pool of available credit. This credit is not
available for other deals. If this reduces the available credit for
other deals below the dealing threshold the Agent will send a
CreditUpdate message to notify the broker that credit is no longer
available.
[0091] When the deal is completed, the maker's Agent will be
notified with a DealStatusTaker message. The Taker's Agent will
then be aware of the completed deal. The Agent will then determine
the credit that was actually used by the deal. This credit will be
removed from the credit pool as consumed credit. Any remaining
amount from the original reservation will be returned to the
original pool.
[0092] As an alternative to local credit, a bank may adopt a Global
Credit Model in which the Trading Agent that holds the credit
authority for a floor is not the same Agent that performs the
dealing activity for that floor. The Agent with credit authority
may, but does not have to, perform dealing activity for a floor.
This arrangement allows all the floors of an institution to share a
common pool of credit and the creation of separated credit nodes
within the network for some floors. The deal execution process for
this type of credit arrangement is more complicated than for the
local credit example described earlier.
[0093] FIG. 8 shows the credit message flow during deal execution
with global credit.
[0094] The credit distribution process is the same as in the local
credit example in that credit information is still distributed to
all brokers. Each broker knows where the information came from and
can route a message back to the Trading Agent with credit
authority.
[0095] In the example of FIG. 7, the Maker and Taker Trading Agents
100, 110 do not have credit authority for their floors. Credit must
therefore be confirmed by the two Trading Agents 120, 130 which do
have that authority and which may be referred to as Maker and Taker
Credit Agents.
[0096] When the Maker Trading Agent 100 processes a deal it will
first check that the quote is still available in the manner
described previously and it notifies the dealer of the pending
deal. However, it cannot check the credit position itself and so
does not send the DealStatusMaker message itself. Instead, a
DealCreditMaker message 140 is sent to the broker 150 to which the
Trading Agent is attached. The broker 150 routes the
DealCreditMaker message 140 to the Maker Credit Agent 120, which is
the source of credit information for the trading floor to which the
Trading Agent 100 is performing the dealing activity. Once the
Maker Credit Agent 120 has performed the credit check as described
previously, it sends the DealStatusMaker message 160 to broker
170.
[0097] The DealStatusMaker message 160 is routed by the broker 170
not to the Taker Trading Agent but to the source of credit for the
taker, in this case the two are not the same and the
DealStatusMaker message is routed to the Taker Credit Agent 130.
The Taker Credit Agent 130 then performs credit checking as
described previously and sends a DealCreditTaker message 180 to the
broker 190 to which the Taker Credit Agent is connected. Of course,
if the Taker Trading Agent has credit information for the trading
floor the DealCreditTaker message 180 is not necessary.
[0098] The DealCreditTaker message 180 is routed by the broker
network to the source of the original hit using the targeted
routing rules described previously.
[0099] When the Trading Agent 110 that originally proposed the deal
received the DealCreditTaker message 180 the deal is done and
logged at the Taker Trading Agent and the deal execution process
carries on as described earlier with respect to FIG. 6.
[0100] The Maker and Taker Credit Agents 120, 130 perform credit
reservation in the same manner as described in the local credit
example. The Maker Credit Agent reserves credit when it receives
the DealCreditMaker message and the Taker Credit Agent reserves the
credit when it receives the DealStatusMaker message 160. Credit
consumption is then performed when the Maker and Taker Credit
Agents 120, 130 receive the DealStatusTaker message 200 from the
Taker Trading Agent 110.
[0101] It may be desired for more that one Trading Agent to hold
the credit authority for a floor to increase reliability and
performance. In such a case, any one such Credit Agent may confirm
a deal. It is the responsibility of those Agents to communicate and
keep the credit pool correct between themselves. This process is
specific to an instrument or institution. Each broker will receive
multiple CreditUpdate messages for the same floor. The brokers must
decide which message to accept. The broker will examine a "hop
count" in the message to determine which message came from the
closest source. The message with the higher hop count is not
processed and is not routed.
[0102] The Credit Agent for a floor or institution has to maintain
the pool of available credit and adjust the credit information as
credit is used and restored. The manner in which this is done is
specific both to the institution and the instrument being
traded.
[0103] One reason for a bank adopting a global approach to credit
is to increase the flexibility available in trading. If a bank
comprises several floors each of which have a preassigned amount of
credit with various counterparties, a situation can arise in which
some of the floors trade up to their credit limits but others do
not. Those floors which went up to their limits would have liked
access to the unused credit on the other floors to maximise trading
within the banks overall trading limit with a given party. That
overall trading limit may not be confined to a single trading
instrument but cover the range of the bank's activities, some of
which may be traded on anonymous electronic systems and others of
which may not.
[0104] Whichever of the global or local credit models is used it is
undesirable and inflexible to tie up more credit in the electronic
broking system than is absolutely necessary. The credit adjustment
made in prior art systems on completion of a trade is completely
independent of any other trading activities that has taken place.
Thus, if bank A sells $10M to bank B and then buys $9M from bank B,
both parties' credit will be drawn down by $19M, the combined value
of the two transaction. However, this is not a fair representation
of the risk undertaken by wither party as the net exposure is $1M.
This is undesirable as the main purpose of credit limits is to
limit the exposure of a bank. However, in this example the exposure
is far within the exposure the bank considers acceptable and the
effect is to prevent the bank from trading up to a level of risk is
considers appropriate.
[0105] In an embodiment of the invention this problem is overcome
by netting when adjusting utilised credit after deal execution.
Under this arrangement the sense of the deal with a counterparty,
that is whether it is a but or a sell is taken into account when
adjusting utilised credit. This has the advantage of better
reflecting the time level of risk to which the bank is exposed and
allows more trading to be undertaken within the confines of the set
credit limits.
[0106] Within the trading system described, institutions may decide
whether or not to net with other institutions. This, a given
institution may define netting credit groups. The trading system
described may trade a number of different instruments, such as spot
FX, FRA's etc. Netting may be on a per instrument basis or on a
cross instrument basis. Where an institution defines netting as
being on a cross instrument basis it may designate which
instruments are to be included for netting calculation
purposes.
[0107] In considering which trades may be netted, the settlement
date of the trade is also an issue. An institution may net by
settlement date, by time bucket or by total credit exposure. Each
of these may be on a per instrument or cross instrument basis and
each will now be briefly considered.
[0108] FIG. 9 illustrates a simple example of netting by settlement
date on a per instrument basis. Whenever an instrument is traded
such that there is a delivery of currency or value on a specific
date, the settlement date, it is possible for that delivery of
currency to be netting against a receipt of that same currency for
value on the same specific date with the same counterparty.
[0109] In the FIG. 9 example, Bank A buys EUR 10 million v USD of a
rate of 1.07 (selling USD 10, 700, 000) for value Aug. 3, 2000 from
Bank B. Later on, Bank A sells EUR 10, million v USD at a rate of
1.08 (buying USD 10, 800,000) for value Aug. 3, 2000, from Bank
B.
[0110] If the two parties have a netting agreement, there will be
no EUR payment as the net result of the two EUR transactions is
+10M-10M=0 . The net result of the two USD transactions is a
payment from Bank B to Bank A of USD 100,000 representing the
difference between the USD sale and purchase. Thus, the amount of
credit utilised or the total exposure to Bank A is USD 100,000.
This assumes that USD are the credit limit currency. If not, the
exposure amount is converted into the credit limit currency at a
credit limit currency conversion rate which is stored within the
trading system.
[0111] FIG. 10 shows a more complex example. In this example, Bank
A buys the same EUR 10M v USD as in the FIG. 9 example. However,
instead of selling the EUR 10M v USD, the sale is v JPY (Japanese
Yen) at a rate of 125, buying JPY 1,250M again for value Aug. 3,
2000 from Bank B. The net result of the two transactions if the
banks have a netting agreement, from Bank A's perspective is as
follows:
[0112] USD exposure=0
[0113] Bank A has only sold US dollars and therefore has no USD
credit exposure.
[0114] EUR exposure=0
[0115] Bank A has bought and sold EUR 10M and the total exposure is
therefore zero.
[0116] JPY exposure=JPY1,250M
[0117] This is the amount owed to Bank A by Bank B and so the
amount of credit exposure.
[0118] Thus, the amount of credit used by bank A is the JPY
exposure amount converted into USD, assuming that USD is the credit
limit currency. If one were to assume a rate of JPY/USD=118 then
the exposure is USD 10,593,220. Thus, each netted currency exposure
is calculated for each value date and then converted into the
credit limit base currency equivalent. If the exposure is negative,
in which cased Bank A owes the currency, then this is considered to
be zero. The is the case if there is no cross instrument netting.
The positive credit limit currency equivalent amounts are added
together and this is the total credit utilisation for that value
date for that instrument.
[0119] In the trading system described, prices shown to traders are
pre-screened for credit. Thus, if an order has been put into the
system and there is insufficient credit with the owner of that
order, the quote is not displayed to the trader. Netting affects
the pre-screening for credit. Considering a single sided example
for simplicity, if Institution A has a limit for trades with
Institution B of USD 10M and buys USD 1M, there is no credit left
with that Institution and offers from that counterparty must be
screened out and not shown to Bank A's traders. However, as Banks A
and B have a netting agreement, bids from Bank B must be shown. If
Bank B were now to bid USD 11M, offering to buy 10M from Bank A,
conclusion of the transaction would reduce Bank A's exposure to
Bank B to zero.
[0120] FIG. 11 shows how this works for the two currency pair of
example of FIG. 10. Assume first, that the Institution gave a
credit limit of USD 11M to the credit group. The first trade, of
USD 10.7M has used all but USD 300,000 of this credit which is
below the permitted minimum deal size. The system must only show
bids of JPY v any other currency. Any selling of JPY up to JPY
1,250M v any currency other that USD would result in, at worse, the
same net exposure. The selling of JPY 2,500M v USD would result in
a reduction in exposure.
[0121] The examples given above have used spot FX as the
instrument. The system will work with any single instrument.
[0122] The examples given above related only to netting by
settlement date on a per instrument basis, explicitly addressing
spot FX. Netting can be done cross instrument provided that the
settlement date of the delivery of the currency is the same. The
general rule of cross instrument netting by settlement date is the
same as that for the per instrument example. Each netted currency
exposure is calculated for each value date and is then converted
into the credit limit currency equivalent. The different is that in
addition to spot FX, other designated instruments are included in
this calculation. If the exposure is negative, so that Bank A owes
the currency, then the amount is considered to be zero. The
positive credit limit currency equivalent amounts are added
together and this is the total credit utilisation for that value
date.
[0123] Instead of netting by settlement date, instruments may be
traded such that there is a delivery of currency for a value on a
date within a specific floor-timed window, often referred to as a
time bucket. Delivery of currency may be netted against a receipt
of that same currency for value on another, or the same, date
within that same specific floor-defined time bucket with the same
counterparty.
[0124] By way of example, Bank A may establish a series of
three-month time buckets. Assuming that the date is Apr. 26, 2000
and the spot date is Apr. 28, 2000. The three month time buckets
will end on Jul. 28, 2000, Oct. 28, 2000, Jan. 28, 2001 etc. Going
back to the example of FIG. 9, Bank A buys EUR 10M v USD at a rate
of 10.07 (selling USD 10.7M) for value Aug. 3, 2000 from Bank B.
Later Bank A sells EUR 10M v USD at a rate of 1.08 (buying USD
10.8M) for value Aug. 10, 2000 from Bank B. In the netting
settlement date example, there would be no netting possible.
However, as both value dates are within the 28 July-28 October time
bucket netting is possible. The net result of the transaction is,
as in the FIG. 9 example, no EUR expose using USD 100,000 of credit
within that time bucket.
[0125] As with the settlement date example, netting by time bucket
may be on a cross instrument basis. Thus, whenever instruments are
traded as such that there is a delivery of currency for value on a
date within a specific floor-defined time bucket, it is possible
for that delivery of currency to be netted against the receipt of
the same currency for value on another (or the same) date within
that same specific floor-defined time bucket with the same
counterparty. Again, the general rule is the same as in the
settlement date cross instrument example except that trades falling
within the same time bucket are eligible for netting.
[0126] In all the examples given above, netting has been determined
by the value date of the trade. In another alternative, netting may
be on the basis of total credit exposure. Thus, whenever an
instrument is traded, regardless of the value date, the delivery of
currency associated with that instrument may be netted against the
receipt of that same currency with the same counterparty. As in
previous examples, each currency exposure is calculated and then
converted into the credit limit currency equivalent. If that total
exposure is negative, the exposure is considered to be zero. If it
is positive, then this is the total credit utilisation.
[0127] The total credit exposure example may be extended on a cross
instrument basis such that whenever multiple instruments are
traded, regardless of value date, the delivery of currency
associated with those instruments is netted against receipts of
that same currency with the same counterparty. Each currency
exposure, per instrument, is calculated and totalled. This total is
then converted into the credit limit currency equivalent. If that
total exposure is negative it is considered to be zero. If it is
positive, then this is the total credit utilisation.
[0128] Thus, it can be seen that by netting trades between banks
the credit available can effectively be increased greatly under
some circumstances, correctly reflecting the actual exposure
entered into by the bank and enabling more trading in a given
trading day than was previously allowable.
[0129] FIG. 12 shows how the credit limits would have been adjusted
if the trades of FIG. 9 had been applied without netting was
performed by prior art systems. Here, each of the two trades would
result in the credit limits being decreased by the USD value of the
trade such that the total reduction in credit for the two trades
would be USD21.5M. Thus, the arrangement of the present invention
frees up over USD21M of credit available for further trades
compared to the prior art. In turn, institutions need not assign so
much credit to the anonymous trading system freeing up further
credit for use in other trading activities.
[0130] Thus, it can be seen that by netting trades between the
credit available can effectively be increased greatly under some
circumstances, correctly reflecting the actual exposure entered
into by the bank and enabling more trading in a given trading day
than was previously allowable.
[0131] In the context of the system described, netting will be
performed by the Maker and Taker Trading Agents whether local
credit is employed and by the Maker and Taker Credit Agents where
global credit is employed or a combination of these two models may
be in use.
[0132] Whether or not netting can be performed between two
counterparties will depend upon whether there is a netting
agreement between the parties.
[0133] The user defines a set of criteria for the eligibility of
Deals to be netted within the system. The criteria include:
[0134] the Instrument types to which the agreement applies to;
[0135] the Currencies to which the agreement applies to;
[0136] the maximum and minimum deal duration that is eligible to be
netted under an agreement; and
[0137] identifying whether the agreement is an agreement to net to
the parent.
[0138] The user then can associate Credit Lines with a Net
agreement.
[0139] The netting arrangement described above is a type of
pre-settlement netting. If an agreement includes pre-settlement
netting, the user can define whether the pre-settlement netting
takes the form of Novation or Close-Out netting.
[0140] The system uses the criteria and the credit line information
to distinguish the nettable deals form those that are non-nettable.
This means that the user can accurately represent the terms of
their netting agreement and its effects on Exposure.
[0141] Netting need not be between trading floors having similar
status in a bank's hierarchy. Any particular net agreement may
apply to many relationships between a user branch structure and
various counterparty branches. A particular user branch may be
party to the same net agreement with various counterparty
branches.
[0142] The user can associate as many credit lines as he chooses
with a particular net agreement, as long as no two credit lines
contain a counterparty branch from the same counterparty hierarchy.
This is to simplify the calculation process. An example of this is
shown in FIG. 13. Assuming that Bank B is the user hierarchy and
Bank A and Bank C are two counterparty hierarchies in FIG. 13, the
user could have the credit lines between Bank B London and Bank A
London as well as Bank B Paris and Bank C Frankfurt associated with
the same net agreement. (Represented as Netting agreements 1 and 2
in FIG. 13).
[0143] However, the user could not have Bank B London and Bank A
London as well as Bank B Paris and Bank A Paris associated with the
same net agreement, (represented by Netting Agreements 1 and 7 in
FIG. 13).
[0144] In all, the following combinations of credit lines from the
diagram can be associated with the same particular net
agreement:
[0145] 1&2 or 1&4 or 1&6 or 1&8 or
[0146] 3&2 or 3&4 or 3&6 or 3&8 or
[0147] 5&2 or 5&4 or 5&6 or 5&8 or
[0148] 7&2 or 7&4 or 7&6 or 7&8.
[0149] The system will not permit any other combinations, such as
1&3 or 1&2&3, to be associated with a particular net
agreement.
[0150] The user can set up as many net agreements as he wishes with
the same currencies, instrument groups, minimum number of days and
maximum number of days.
[0151] In some cases, a net agreement is enforced between parent
level branches. For example, if the user's organisation has a
single back office that handles all the payments for several child
branches. Then the payments due for transactions conducted at the
child branches will be netted at this parent level, rather than at
the individual child branch level.
[0152] Referring to FIGS. 14 and 15, Bank B Europe is the parent
and could be a hypothetical parent purely for the purpose of
aggregating exposures of Bank B London, Bank B Paris and Bank B
Frankfurt. An agreement could be established with a counterparty,
Bank A London, that nets between Bank B London and Bank B Paris,
and Bank A London, at the level of Bank B Europe. E.g. Bank B
Europe makes the payments to Bank A London for all netted
currencies (and probably un-netted payments too) and receives all
netted payments from Bank A London due to Bank B Paris and Bank B
London. Therefore the net exposure for these payments would be
conceived at Bank B Europe and not the individual child branches.
This applies also to the netting of credit.
[0153] A similar example can be given where a single user branch
nets across several counterparty branches at a parent level.
Referring to FIGS. 14 and 15, the user can establish a net to
parent agreement between Bank B Frankfurt and Bank A Europe,
including the children Bank A London and Bank Frankfurt as part of
the agreement.
[0154] Finally, both the counterparty and the user branch can net
at the parent level. Consider FIGS. 14 and 15. Assuming that the
user hierarchy is Bank B and the counterparty is Bank A, a net
agreement can be in operation between Bank B London and Bank B
Paris, and Bank A London and Bank A Frankfurt, can be netted at the
respective parent levels. So, Bank B Europe can net credit for
deals done between the following credit lines:
[0155] Bank B Europe--Bank A Europe
[0156] Bank B Europe--Bank A Frankfurt
[0157] Bank B Europe--Bank A London
[0158] Bank B Paris--Bank A Europe
[0159] Bank B Paris--Bank A Frankfurt
[0160] Bank B Paris--Bank A London
[0161] Bank B London--Bank A Europe
[0162] Bank B London--Bank A Frankfurt
[0163] Bank B London--Bank A London
[0164] There are two types of pre-settlement netting, Novation
netting and Close-out netting. Novation netting is only applicable
to FX Deal types. Contracts that meet the definitions and rules of
the agreement, that are settling on the same date, in the same
currency pair, are legally replaced bty a single contract that
represents the netted obligation due/owed on that respective day.
As a result of this agreement, if either of the counterparties
within the contract was to default on his obligations, the other
party would only stand to lose the Replacement Cost of each of the
netted contracts, rather that the total of the Replacement Cost of
each individual deal. Hence, under this type of particular
agreement, the system must provide the user with the functionality
to net both the Replacement Cost on the basis of same currency
pair, same settlement date, and the Potential Future Exposure
(add-on) for these deals.
[0165] Close-out netting can be applied to all deal types that
generate a pre-settlement exposure. Contracts included within the
agreement, are legally replaced by a single contractual obligation,
such that a bank would have either a claim to receive or obligation
to pay only the net sum of the positive and negative mark to market
values of included transactions in the event a counterparty
defaults as a result of bankruptcy, liquidation or similar
circumstances. Hence, under this type of agreement, the system must
provide the user with the functionality to net both the Replacement
Cost, and the Potential Future Exposure (add-on) for included deals
across all dates and instrument types.
[0166] Through the use of a Pre-Settlement Netting agreement, the
user bank has the opportunity to mitigate substantial credit risk,
associated with its credit lines. This will enable the user bank to
carry out more trading, without overstepping its capital adequacy
requirements. This has been discussed above.
[0167] Options and the like, the methodology will be generalised to
be applicable to all the instrument types traded through the
BrokerNet system.
[0168] The system provides functionality for the user to define the
criteria that makes a deal eligible for Pre-Settlement netting. The
user will be able to define the set of Instrument Types that are
eligible the Pre-Settlement netting, as well as the currencies that
can be netted.
[0169] The system will provide the user with functionality to net
Pre-Settlement exposure at parent level. That is, the user can
define which child branches in tis own and the counterparty's
organisation are eligible for netting, and the exposure will be
netted at the parent level for the transactions between the
eligible children.
[0170] Considering Novation netting further, based upon the netting
rules that have been defined within the netting agreements, the
system will calculate the appropriate netted pre-settlement
exposure for any credit line that is assigned a net agreement with
Novation netting if a credit line has been associated with a
Novation net agreement, the system will net the pre-settlement
exposure for deals that are instrument types that have been
associated with the net agreement and are denominated in currency
pairs derived from the currencies that are associated with the net
agreement.
[0171] The system will net the Replacement Cost for all deals
settling on the same date for the same currency pair; the Potential
Future Exposure (add-on) for all deals settling on the same date
for the same currency pair; and multi-branch exposures at an
aggregate, parent level for those parent associated with "net to
parent" net agreements.
[0172] The net Novation pre-settlement exposure calculations will
be applied to all credit lines that contain any deal that is
eligible for netting. That is, the netting eligible deal
contributes to the calculation of pre-settlement exposure for that
particular credit line. This will include Credit lines where the
credit entity is a country, country group or ad-hoc group.
[0173] The system recalculates net Novation pre-settlement
exposures on a daily basis until the exposure matures, and permits
the user to retrieve Novation Netting associated attributes for at
least 6 months after the date associated with the net settlement
exposure value. Users require this historic data to analyse trends
in exposure distribution.
[0174] Considering Close-out netting further, based upon the
netting rules that have been defined within the netting agreements,
the system will calculate the appropriate netted pre-settlement
exposure for any credit line that is assigned a net agreement with
Close-out. Fi a credit line has been associated with a Close-out
net agreement, the system will net the pre-settlement exposure for
deals that are instrument types that have been associated with the
net agreement and are denominated in currency pairs derived from
the currencies that are associated with the net agreement.
[0175] The system nets the Replacement Cost for all deals settling
within the same timeband in the same credit line within the same
instrument group that are eligible for the same net agreement;
[0176] the Potential Future Exposure (add-on) for all deals
settling within the same timeband in the same credit line within
the same instrument group that are eligible for the same net
agreement; and
[0177] net multi-branch exposure at an aggregate, parent level for
those parents associated with "net to parent" net agreements.
[0178] The net Close-out pre-settlement exposure calculations will
be applied to all credit lines that contain any deal that is
eligible for netting. That is, the netting eligible deal
contributes to the calculation of pre-selected exposure for that
particular credit line. This will include Credit lines where the
credit entity is a country, country group or ad-hoc group.
[0179] In order to aid the calculation process, the system
classifies each particular combination of net agreement short name,
net agreement currencies, net agreement instrument types, net
agreement maximum number of days, net agreement minimum number of
days and credit line as a unique net agreement.
[0180] The system recalculates net close-out pre-settlement
exposures on a daily basis until the exposure matures; and
[0181] permits the user to retrieve Close-out Netting associated
attributes for at least 6 months after the date associated with the
net settlement exposure value. Users require this historic data to
analyse trends in exposure distribution.
* * * * *