U.S. patent application number 10/206617 was filed with the patent office on 2003-03-27 for conversational dealing system.
Invention is credited to Ajitsaria, Rajiv, Foray, Andrew P., Horsfall, Peter Richard, Kirill, Dunayev.
Application Number | 20030061149 10/206617 |
Document ID | / |
Family ID | 25032789 |
Filed Date | 2003-03-27 |
United States Patent
Application |
20030061149 |
Kind Code |
A1 |
Ajitsaria, Rajiv ; et
al. |
March 27, 2003 |
Conversational dealing system
Abstract
A conversational trading system allows a plurality of
instruments, for example financial instruments such as foreign
exchange products, to be traded from a single user interface. The
interface includes a deal stack comprising a deal list, a deal
detail panel and a button bar. The deal list displays deal related
information such as status, party, instrument and an instrument and
status related string in a form common to all instruments. Whenever
a new quote request is detected, a new conversation is started.
This may be with the same party as an existing conversation. The
conversation is parsed line by line and the user can edit it before
it is sent to the counterparty. The parser does not store any
record of the deal and, along with the interface, may be downloaded
as an Applet.
Inventors: |
Ajitsaria, Rajiv;
(Parsippany, NJ) ; Kirill, Dunayev; (West Orange,
NJ) ; Foray, Andrew P.; (Wayne, NJ) ;
Horsfall, Peter Richard; (Morristown, NJ) |
Correspondence
Address: |
Steven S. Rubin
DICKSTEIN SHAPIRO MORIN & OSHINSKY LLP
41st Floor
1177 Avenue of the Americas
New York
NY
10036-2714
US
|
Family ID: |
25032789 |
Appl. No.: |
10/206617 |
Filed: |
July 29, 2002 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10206617 |
Jul 29, 2002 |
|
|
|
09753940 |
Jan 3, 2001 |
|
|
|
60308618 |
Jul 30, 2001 |
|
|
|
Current U.S.
Class: |
705/37 |
Current CPC
Class: |
H04L 67/14 20130101;
H04L 9/40 20220501; G06Q 40/04 20130101; H04L 69/329 20130101; G06Q
40/00 20130101; H04L 67/75 20220501; G06Q 20/10 20130101 |
Class at
Publication: |
705/37 |
International
Class: |
G06F 017/60 |
Claims
1. A conversational dealing system for trading instruments between
counterparties, comprising: a plurality of trader terminals each
having a user interface for inputting and displaying to a trader
conversational messages including deal related information, the
trader terminals communicating with each other via a communications
network, the trader terminals each further comprising a parser for
parsing said inputted conversational messages, said parser
comprising: means for analyzing the conversational messages to
detect a status of a deal, the deal having a plurality of possible
statuses; means for analyzing the conversational messages to detect
deal related information relevant to the detected status of the
deal; and means for returning a parsed message comprising the deal
status and the deal related information to the user interface.
2. A conversational dealing system according to claim 1, wherein
the parser parses completed conversational messages provided from
the user interface.
3. A conversational dealing system according to claim 1, wherein
the parser includes means for monitoring all conversational
messages received from the user interface to identify a new deal
regardless of the deal status of a current deal.
4. A conversational dealing system according to claim 3, wherein
the user interface includes means for initiating a new conversation
between counterparties having at least one existing conversation
when the new deal is identified.
5. A conversational dealing system according to claim 3, wherein
the parser monitors the conversational messages to identify a
request for a quote (RFQ).
6. A conversational dealing system according to claim 1, wherein
the possible deal statuses include no deal pending, request for a
quote, quote, and buy/sell.
7. A conversational dealing system according to claim 1, wherein
said means for returning the parsed messages comprise means for
returning a deal information structure to the user interface.
8. A conversational dealing system according to claim 1, wherein
the user interface displays a parsed message received from the
parser and includes means for accepting or declining the parsed
message prior to a communication of the parsed message to a
counterparty.
9. A conversational dealing system according to claim 8, wherein
the user interface further includes means for editing the parsed
message prior to communication to a counterparty.
10. A conversational dealing system according to claim 8, wherein
the means for accepting or declining the parsed message comprises
at least one button on the user interface display operable by a
pointing device.
11. A conversational dealing system according to claim 9, wherein
the means for editing the parsed message comprises at least one
button on the user interface display operable by a pointing
device.
12. A conversational dealing system according to claim 1, further
comprising a deal server, the deal server acting to check an
acceptability of the parsed message from a first couterparty and to
reject the parsed message without informing another counterparty
when the parsed message is unacceptable.
13. A conversational dealing system according to claim 1, further
comprising a chat server for handling non-deal related
conversation, wherein a conversational message in which the parser
does not detect any deal related information is sent to a
destination trader via the chat server.
14. A conversational dealing system according to claim 1, wherein
the parser is downloaded to the trader terminal when the trader
terminal logs on to the conversational dealing system.
15. A conversational dealing system according to claim 14, wherein
the parser is an applet.
16. A trader terminal for a conversational dealing system having a
plurality of trader terminals communicating with each other via a
communications network, the trader terminal comprising: a user
interface for inputting and displaying to a trader conversational
messages including deal related information; and a parser for
parsing said inputted conversational messages; wherein said parser
includes: means for analysing the conversational messages to detect
a status of a deal, the deal having a plurality of possible
statuses; means for analyzing the conversational messages to detect
deal related information relevant to the detected status of the
deal; and means for forming and returning to the user interface a
parsed message comprising the deal status and the deal related
information
17. A trader terminal according to claim 16, wherein the parser
parses completed conversational messages provided from the user
interface.
18. A trader terminal according to claim 16, wherein the parser
includes means for monitoring all conversational messages received
from the user interface to identify a new deal regardless of the
deal status of a current deal.
19. A trader terminal according to claim 18, wherein the user
interface includes means for initiating a new conversation between
a counterparties having at least one existing conversation when the
new deal is identified.
20. A trader terminal according to claim 18, wherein the parser
monitors the conversational messages to identify a request for a
quote (RFQ).
21. A trader terminal according to claim 16, wherein the possible
deal statuses include no deal pending, request for a quote, quote,
and buy/sell.
22. A trader terminal according to claim 16, wherein said means for
returning the parsed messages comprises means for returning a deal
information structure to the user interface.
23. A trader terminal according to claim 16, wherein the user
interface displays a parsed message received from the parser and
includes means for accepting or declining the parsed message prior
to a communication of the parsed message to a counterparty.
24. A trader terminal according to claim 23, wherein the user
interface further includes means for editing the parsed message
prior to communication to a counterparty.
25. A trader terminal according to claim 23, wherein the means for
accepting or declining the parsed message comprises at least one
button on the user interface display operable by a pointing
device.
26. A trader terminal according to claim 24, wherein the means for
editing the parsed message comprises at least one button on the
user interface display operable by a pointing device.
27. A trader terminal according to claim 16, further comprising a
deal server, the deal server acting to check an acceptability of
the parsed message from a first counterparty and to reject the
parsed message without informing another counterparty when the
parsed message is unacceptable.
28. A trader terminal according to claim 16, further comprising a
chat server for handling non-deal related conversation, wherein a
conversational message in which the parser does not detect any deal
related information is sent to a destination trader via the chat
server.
29. A trader terminal according to claim 16 wherein the parser is
downloaded to the trader terminal when the trader terminal logs on
to the trader terminal.
30. A trader terminal according to claim 29, wherein the parser is
an applet.
31. A method of trading instruments between counterparties in a
conversational trading system in which the counterparties
communicate with each other via a communications network, the
method comprising the steps of: inputting conversational messages
including deal related information to the system; analyzing the
conversational messages to detect a status of a deal, the deal
having a plurality of possible statuses; detecting deal related
information relevant to the detected status of the deal; and
forming a parsed message including the deal status and at least
part of the deal related information.
32. A method according to claim 31, wherein the conversational
messages are provided from a user interface.
33. A method according to claim 31, further comprising parsing all
conversational messages received to identify a new deal regardless
of the deal status of a current deal.
34. A method according to claim 33, further comprising initiating a
new conversation between counterparties having at least one
existing conversation when the new deal is identified.
35. A method according to claim 33, further comprising monitoring
the conversational messages to identify a request for a quote
(RFQ).
36. A method according to claim 31, wherein the possible deal
statuses include no deal pending, request for a quote, quote, and
buy/sell.
37. A method according to claim 31, further comprising returning
the deal related information to a user interface.
38. A method according to claim 31, further comprising: displaying
the parsed message; and allowing one of the counterparties to
accept or decline the parsed message prior to communicating the
parsed message to the other counterparts.
39. A method according to claim 38, further comprising allowing the
first party to edit the parsed message prior to communicating the
parsed message to the other counterparty.
40. A method according to claim 31, comprising checking an
acceptability of the parsed message from a first counterparty; and
rejecting the parsed message without informing another counterparty
when the parsed message is unacceptable.
41. A method according to claim 40, wherein the checking includes
checking whether the counterparties have sufficient bilateral
credit for a proposed deal in the parsed message.
42. A method according to claim 40, wherein the checking includes
checking that the deal related information conforms to business
rules of the conversational dealing system.
43. A method according to claim 31, further comprising sending
conversational messages with no deal related information to one of
the counterparties via a chat server.
44. A method according to claim 31, wherein if, on detection of a
change of the status, insufficient deal related information is
detected relevant to the status, an error message is sent to a user
interface.
45. A method according to claim 44, wherein the error message is
displayed in an area of the user interface dedicated to the deal in
progress.
46. A method according to claim 45, wherein the error message
identifies missing deal related information.
47. The conversational dealing system as recited in claim 3,
wherein the deal related information of the current deal includes a
first request for a quote; and the new deal is identified when the
parser detects a second request for a quote.
48. The conversational dealing system as recited in claim 18,
wherein the deal related information of the current deal includes a
first request for a quote; and the new deal is identified when the
parser detects a second request for a quote.
49. The conversational dealing system as recited in claim 33,
wherein the deal related information of the current deal includes a
first request for a quote; and the new deal is identified when the
parser detects a second request for a quote.
50. The conversational dealing system as recited in claim 1,
wherein the parser retains no record of the passed message.
51. The conversational dealing system as recited in claim 16,
wherein the parser retains no record of the passed message.
52. The conversational dealing system as recited in claim 31,
wherein the parser retains no record of the passed message.
53. A conversational dealing system for trading instruments between
counterparties, comprising: a plurality of trader terminals each
having a user interface for inputting and displaying to a trader
conversational messages including deal related information, the
trader terminals communicating with each other via a communications
network, wherein the conversational messages are displayed in a
colour coded form to indicate to the user an origin of the
conversational messages.
54. A conversational dealing system according to claim 53, wherein
messages received from a counterparty trader terminal are displayed
in a first colour and messages generated at the user interface are
displayed in a second colour.
55. A conversational dealing system according to claim 54, wherein
each trader terminal includes a parser for parsing conversational
messages input into the terminal to extract deal related
information and generate parsed messages, wherein parsed messages
are displayed in a third colour.
56. A conversational dealing system according to claim 54, wherein
warning messages are displayed in a fourth colour.
57. A conversational dealing system according to claim 54, wherein
error messages are displayed in a fourth colour.
58. A conversational dealing system for trading instruments between
traders, the system comprising: a plurality of trader terminals
coupled together to form a network, each trader terminal including
a user interface and a parser; wherein the user interface receives
and displays conversational messages including deal related
information related to deals between traders; and the parser
analyzes the conversational messages to detect a status of a
current deal between traders, the parser further analyzes the
conversational messages to detect the deal related information
related to the status of the current deal, and the parser produces
a parsed message including the status of the current deal and at
least part of the deal related information.
59. The system as recited in claim 58, wherein the parser
identifies a new deal regardless of the status of the current
deal.
60. The system as recited in claim 59, wherein: the deal related
information of the current deal includes a first request for a
quote; and the new deal is identified when the parser detects a
second request for a quote.
61. The system as recited in claim 59, wherein the user interface
initiates a second conversation between traders having a first
conversation when the new deal is identified.
62. The system as recited in claim 58, wherein the parser displays
the parsed message to a trader and allows the trader to edit the
parsed message before sending the parsed message to another
trader.
63. The system as recited in claim 58, wherein the parser displays
the parsed message to a trader and allows the trader to decline to
send the parsed message to another trader.
64. The system as recited in claim 58, further comprising: a deal
server coupled to the trader terminals, the deal server receives
the parsed message from the parser and determines whether the
parsed message is acceptable based on the current status of the
current deal; and when the deal server determines that the parsed
message is not acceptable, the deal server does not send the parsed
message to another trader terminal.
65. The system as recited in claim 58, further comprising: a chat
server coupled to the trader terminals; wherein the parser sends
the conversational messages to the chat server when there is no
deal related information in the conversational messages.
66. The system as recited in claim 58, wherein the parser is
downloaded to a respective trader terminal when the respective
trader terminal accesses the system.
67. The system as recited in claim 66, wherein the parser is an
applet.
68. A computer readable storage medium including computer
executable software for performing the steps of: receiving
conversation messages including deal related information; analyzing
the conversational messages to detect a status of a deal between
traders; analyzing the conversational messages to detect deal
related information related to the status of the deal; and
producing a parsed message including the deal status and at least
part of the deal related information.
69. The storage medium as recited in claim 68, wherein the software
further performs the step of identifying a new deal regardless of
the status of the current deal.
70. The storage medium as recited in claim 69, wherein: the deal
related information of the current deal includes a first request
for a quote; and the new deal is identified upon detection of a
second request for a quote.
71. The storage medium as recited in claim 69, wherein the software
further performs the step of initiating a second conversation
between traders having a first conversation when the new deal is
identified.
72. The storage medium as recited in claim 68, wherein the software
further performs the steps of displaying the parsed message to a
trader and allowing the trader to edit the parsed message before
sending the parsed message to another trader.
73. The storage medium as recited in claim 68, wherein the software
further performs the steps of displaying the parsed message to a
trader and allowing the trader to decline to send the parsed
message to another trader.
74. The storage medium as recited in claim 68, wherein the software
further performs the steps of: determining whether the parsed
message is acceptable based on the current status of the current
deal; and when the parsed message is not acceptable, inhibiting the
parsed message from being sent to another trader terminal.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] This application claims priority to U.S. application Ser.
No. 09/753,940 filed Jan. 3, 2001 and U.S. Provisional Application
Serial No. 60/308,618 filed Jul. 30, 2001. The entirety of these
applications are hereby incorporated by reference.
FIELD OF THE INVENTION
[0002] This invention relates to dealing systems and in particular
to conversational dealing or trading system dealing in instruments
between parties. It is particularly, but not exclusively, related
to financial trading and dealing systems which trade various
financial instruments. The invention is particularly concerned with
the parsing of conversational messages input into the system by
traders.
BACKGROUND OF THE INVENTION
[0003] It has become commonplace to trade financial instruments
using computer systems. These have, to a large extent, replaced
open outcry trading methods in which traders traded face to face on
trading floors. Various computerised trading systems have evolved
for trading different instruments such as foreign exchange spot (FX
Spot), forward rate agreement (FRAs) and other instruments. Some
systems are anonymous, in that the counterparties to a trade do not
know the identity of other counterparties in the market until a
deal has been done. Successful anonymous trading systems have bee
operated for a number of years by EBS Dealing Resources, Inc. and
by Reuters plc. The latter company has also run a conversational
dealing system known as Reuters 2000/1 which computerises the
conversational exchange between traders in reaching a deal allowing
deal negotiation between traders.
[0004] Existing dealing systems have tended to support traders
trading a single instrument. In large institutions, where a given
trader only trades a single instrument this does not cause any
difficulties. However, in smaller institutions, a foreign exchange
trader, for example, may trade several types of instruments for one
or more currency pairs. It is inconvenient for such a trader to
have to use several different trading systems or to have to use a
mix of computerised systems and traditional trading methods such as
voice brokers.
[0005] There is, therefore, a need for a system which integrates
trading of a number of instruments on a single platform to simplify
trading, particularly for traders in smaller institutions.
[0006] Financial markets such as foreign exchange markets can
operate at extreme speed. Dealers are required to react to market
activity nearly instantaneously to avoid losing potential deals. As
a result, the trader terminal must be visually very simple and easy
for the trader to assimilate new or changing information. The
ability to trade a number of different instruments from a single
terminal adds to the complexity and can lead to more information
being presented to the trader.
[0007] At any one time, a trader may be involved in many deals,
some which will mature into done deals and others which will be
cancelled at some stage prior to completion. These deals may be in
a variety of instruments. Each of these deals will have instrument
specific information which the trader must be able to see to enable
him to make the deal. However, displaying all this information on
the screen makes the screen visually hard to interpret for the
trader and is, therefore, not desirable.
[0008] Reuters plc operates a conversational dealing system under
the trademark REUTERS DEALING 2000/1. In this system, traders type
conversation text into the terminals which relates to deals they
want to execute. The conversation text may have no deal related
content or may include information related to the deal. The system
passes the conversation as it entered into the system, on a
character by character basis. When a deal is completed the parties
are asked to confirm the deal and may renegotiate the deal
terms.
[0009] Although the Reuters 2000/1 system has operated successfully
for a number of years, we have appreciated that the approach taken
to parsing has a number of disadvantages. The present invention, in
its various aspects, aims to overcome those disadvantages and to
provide improved parsing in a conversational dealing system and, in
turn, to improve the usefulness and acceptability of such a system
to traders and institutions.
SUMMARY OF THE INVENTION
[0010] A first aspect of the invention resides in the use of
parsing to detect terms in conversation which indicate a change in
deal status.
[0011] More specifically, there is provided a conversational
dealing system for trading instruments between counterparties,
comprising: a plurality of trader terminals each having a user
interface for inputting and displaying to the trader conversational
messages including deal related information, the trader terminals
communicating with each other via a communications network, the
trader terminals each further comprising a parser for parsing said
inputted conversational messages, said parser comprising: means for
analysing the conversational messages to detect a change in the
status of a deal, the deal having a plurality of possible statuses;
means for analysing the conversational messages to detect deal
related information relevant to said detected status of the deal;
and means for returning a parsed message comprising the deal status
and relevant deal related information to the user interface.
[0012] Embodiments of this aspect of the invention have the
advantage that parsing of conversations is greatly simplified. In
the first instance the parser needs to detect changes in status
between one of only a few possible deal statuses. When a change of
status has been detected there is only a limited number of terms of
deal related information that are relevant to that status making
parsing very simple.
[0013] A second aspect of the invention performs parsing on
complete conversational messages provided from the terminal. More
specifically, there is provided a conversational dealing system for
trading instruments between counterparties, comprising: a plurality
of trader terminals each having a user interface for inputting and
displaying to the trader deal related information as conversational
messages, the trader terminals communicating with each other via a
communications network, the trader terminals each further
comprising a parser for parsing said inputted conversational
message, wherein said parser includes: means for receiving complete
conversational messages from the user interface and for analysing
the complete messages to detect deal related information and form a
parsed message; and means for returning the parsed message to the
user interface.
[0014] Parsing complete lines of conversation is highly
advantageous as it enables a structured approach to parsing to be
adopted in which the message can be parsed to look for a first
function, such as change in deal status, and then parsed in a
manner dictated by the first function. This is not possible in
prior art systems which parse character by character.
[0015] A third aspect of the invention enables the user to view and
alter parsed messages before they are sent to the counterparty.
[0016] More specifically, there is provided a conversational
dealing system for trading instruments between counterparties,
comprising: a plurality of terminals each having a user interface
for inputting and displaying to the trader deal related information
as conversational messages, the trader terminals communicating with
each other via a communications network, the trader terminals each
further comprising a parser for parsing said inputted
conversational message, wherein said parser includes: means for
analysing conversational messages from the user interface to detect
deal related information and form a parsed message; means for
returning the parsed message to the user interface and displaying
the parsed message; and means for confirming or altering the parsed
message content prior to transmission of message to a counterparty
trader terminal.
[0017] Once a parsed message has been formed, the user may accept
it, edit it or cancel it. The counterparty will only see the final
message that is sent, if any. Thus, if a trader makes a mistake,
changes his mind, or the market conditions suddenly change, the
trader can change or delete a message that would otherwise have
been sent. Not only is this convenient to the trader, it is highly
advantageous to the trader's market position as he does not have to
reveal his trading position and his thought processes until he is
happy with his position. In prior art systems, in which
conversations are parsed as they are typed in, this is not
possible. Although either party can cancel or try to amend the
terms of a deal once it has been completed, they have, by then,
revealed their hand to the counterparty, which is undesirable.
[0018] A further aspect of the invention enables more that one
conversation to be current with the same counterparty at any one
time. If the parser detects information relating to a new deal at
any time, regardless of the status of the present deal, it notifies
the user interface and a new conversation, or deal, is
initiated.
[0019] More specifically, there is provided a conversational
dealing system for trading instruments between counterparties,
comprising: a plurality of trader terminals each having a user
interface for inputting and displaying to the trader deal related
information as conversational messages, the trader terminals
communicating with each other via a communications network, the
trader terminals each further comprising a parser for parsing said
inputted conversational messages, wherein said parser includes:
means for analysing conversational messages from the user interface
to detect deal related information and form a parsed message; and
means for returning the parsed message to the user interface and
displaying the parsed message; wherein the system further
comprises: means for initiating a deal with a counterparty on
request from a trader; and means for initiating a further deal with
the same counterparty on detection by the parser of deal related
information relating to a deal additional to a current deal.
[0020] A system embodying this aspect of the invention has the
advantage of being highly flexible and reacts to the way in which
traders work and think. If a trader, at any stage of negotiating a
deal with a counterparty, asks for a quote on an unrelated deal,
the system will detect that quote request and initiate a new deal.
Both deals, and any further new deals can progress together but
completely independently of each other. Prior art systems only
enable a single conversation to be held within a given counterparty
at any one time.
[0021] In a further aspect of the invention, a parser is dumb in
that it retains no knowledge of the deal making process. The parser
parses a line of conversation and returns a file comprising the
deal status and related deal information.
[0022] More specifically, there is provided conversational dealing
system for trading instruments between counterparties, comprising:
a plurality of trader terminals each having a user interface for
inputting and displaying to the trader deal related information as
conversational messages, the trader terminals communicating with
each other via a communications network, the trader terminals each
further comprising a parser for parsing said inputted
conversational messages, wherein said parser includes: means for
analyzing conversational messages from the user interface to detect
deal related information and form a parsed message; and means for
returning the parsed message to the user interface and displaying
the parsed message; wherein on returning the parsed message to the
user interface, the parser retains no record of the parsed message
or the deal to which it relates.
[0023] Embodiments of this aspect of the invention have the
advantage that the parser is very simple. Furthermore, as the
parser stores no historical information it is easy to download it
to the user, for example as an Applet, each time the user logs on
to the system. This makes the system suitable for use in an
Internet environment and makes it very easy for traders to access
the system as they not have to load the parser onto their
workstations themselves. It also reduces the overheads on IT
support in user organisations such as banks or other financial
organisations.
[0024] In a further aspect of the invention, a level of filtering
of parsed messages is introduced between trader terminals. This
allows parsed messages to be checked to ensure that they conform to
the business or operating rules of the system.
[0025] More specifically, there is provided a conversational
dealing system for trading instruments between counterparties,
comprising: a plurality of trader terminals each having a user
interface for inputting and displaying to the trader deal related
information as conversational messages, the trader terminals
communicating with each other via a communications network, the
trader terminals each further comprising a parser for parsing said
inputted conversational messages, wherein said parser includes:
means for analyzing conversational messages from the user interface
to detect deal related information and form a parsed message; and
means for returning the parsed message to the user interface and
displaying the parsed message; wherein the system further
comprises: a server for receiving parsed messages including deal
related information from trader terminals and distributing the
parsed messages to destination terminals, the server including
means for check the acceptability of parsed messages sent from a
trader terminal prior to communication to a destination trader
terminal and for rejecting unacceptable parsed messages without
passing the rejected message to the destination trader
terminal.
[0026] This aspect of the invention has the advantage that illegal
deals can be filtered out without a deal being agreed on by the
parties. Moreover, the filtering may include a credit check to
ensure that each party has sufficient resources to complete the
deal. A credit check may be integrated into an institutional credit
system which typically set limits on the trades that can be
completed with any counterparty over a set period of time.
[0027] If the parsed message is rejected as unallowable, the
intended recipient has no knowledge that the message was ever sent.
This is advantageous as the trader does not disclose information as
to his dealing position except when trades are possible.
[0028] This aspect of the invention is also advantageous as it
prevents traders wasting time, often in a very volatile and fast
moving market, on trades which would otherwise be rejected as
unallowable once they had been concluded.
[0029] In a further aspect of the invention, messages displayed at
the user interface are colour coded according to origin.
[0030] More specifically, there is provided a conversational
dealing system for trading instruments between counterparties,
comprising: a plurality of trader terminals each having a user
interface for inputting and displaying to the trader conversational
messages including deal related information, the trader terminals
communicating with each other via a communications network, wherein
the conversational message are displayed in a colour coded form to
indicate to the user the origin of the conversational messages.
[0031] In one preferred embodiment, messages generated by the user
are shown in a first colour, messages generated by a counterparty
in a second colour, and messages generated by the system, in a
third colour. System messages may include parsed messages based on
user or counterparty input conversational messages.
[0032] Preferably, warning messages, error or danger messages are
each shown in a further colour.
[0033] This aspect of the invention has the advantage of making the
user display much more intelligible. This is very important in a
fast moving market in which a trader may have many deals pending at
any time and in which he is required to analyse deal information
very quickly.
BRIEF DESCRIPTION OF THE DRAWINGS
[0034] Embodiments of the invention will now be described, by way
of example only, and with reference to the accompanying drawings,
in which:
[0035] FIG. 1 is a schematic diagram of a trading system;
[0036] FIG. 2 is a further schematic diagram showing the main
functional components of a trader terminal;
[0037] FIG. 3 is a view of the user interface of a trader Terminal,
according to a first embodiment of the invention;
[0038] FIG. 4 is a similar view to FIG. 3 showing a number of
conversation panels;
[0039] FIG. 5 is a view of a deal stack within the user interface
and showing the deal detail panel;
[0040] FIG. 6 is a further view of the deal stack and deal detail
panel with a different deal highlighted in the deal detail panel
from FIG. 5;
[0041] FIG. 7 is a further view of the deal stack showing a deal
detail panel for a completed Forwards deal;
[0042] FIG. 8 is a further view of the deal stack showing the deal
detail panel displaying an error box;
[0043] FIG. 9 is a still further view of the deal stack showing the
deal detail panel displaying potentially modifiable fields
highlighted;
[0044] FIG. 10 shows the deal stack with the deal detail panel
showing a completed F/X Spot deal including the value of the done
deal;
[0045] FIG. 11 shows the deal stack with the deal detail panel
showing a forward deal with a Spot Rate Query message; and
[0046] FIG. 12 shows how the Spot rate query message of FIG. 11
appears at the counterparty's deal detail panel as a warning
message.
[0047] FIG. 13 is a flow chart showing an overview of the parsing
process;
[0048] FIG. 14a and 14b are flow charts showing the parsing process
in more detail;
[0049] FIG. 15 is a screen shot of a second embodiment of the user
interface showing a parsed message entered by the maker;
[0050] FIG. 16 shows the screen of FIG. 15 when the parsed message
has been sent but not picked up;
[0051] FIG. 17 shows the taker's interface when the parsed message
is received;
[0052] FIG. 18 shows the taker's interface when the system is
waiting for the taker to quote;
[0053] FIG. 19 shows the maker's screen when a quote is
received;
[0054] FIG. 20 shows the maker's screen when a deal has been
finalised;
[0055] FIG. 21 shows an example of a warning message and an error
message together with a second conversation being initiated out of
the first conversation; and
[0056] FIG. 22 shows a further example of warning messages.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
[0057] The system illustrated schematically in FIG. 1 is a
conversational dealing system for trading a variety of financial
instruments. Instruments which may be traded include, but are not
limited to, foreign exchange (F/X) spot, forwards, and outrights.
Although the following description will concentrate on F/X spot and
forwards, it is to be understood that this is purely for the
purposes of illustrating the invention and that the invention is
not limited to any particular financial instruments or even to
financial instruments. It is equally applicable to the trading of
any other fungible such as commodities, metals, etc.
[0058] The illustrative system is preferably an internet based
system in which traders communicate with other traders from trader
terminals across the internet. Trades are agreed upon by an
exchange of messages between traders. The message content is
automatically parsed by the system to identify deal related content
for processing. Once the parsing has detected a deal status change,
the remainder of the deal processing is handled by the deal stack.
Deal status change need not be entered by conversation but may be
directly input from the traders terminal, for example by using on
screen function buttons or keyboard driven menus. Thus, the system
also allows users to deal by a simple exchange of deal content data
which is non-conversational and by a mixture of the two
methods.
[0059] The following description gives an overview of the trading
system within which the user interface is used by traders to
execute deals. However, it is to be understood that this is only
one example of a trading system suitable for use with the
invention. The invention is not limited to any particular trading
system but is applicable to any system in which a trader is trading
multiple instruments. Such a system may be internet based or
operate on a conventional public or private network. It may use a
distributed architecture or operate using a central host or may be
configured in any other manner.
[0060] Referring now to FIG. 1, a trading system 10 disclosed is
based on a plurality of server farms 12 connected through a system
intranet 14. The server farms 12 communicate with trader terminals
16 at bank trading floors through a communications network, here
the Internet 14, and local bank intranets 18. The majority of deal
processing takes place at trader terminals 16 with deal messages
being passed by the server farms 12 to counterparty trader
terminals 16. The server farms also pass done deal information to
bank back office systems (not shown) to enable deal tickets to be
produced and trades to be settled. The deals are input into the
system 16 either directly by the trader or through parsed
conversation exchanged between traders, as will be described.
Parsing takes place at the trader terminals.
[0061] FIG. 2 shows the user terminals 16, as well as one server
farm, schematically. A plurality of trader terminals 16, two of
whom are shown, communicate with each other, and with other
terminals (not shown) by exchanging conversational messages via a
system server forming part of the server farm. Each client terminal
16 has three logical components: a user interface 20, a
communications module 22 and a parser 24. The client terminals are
typically a suitable computer such as a PC or workstation having
conventional components such as input devices including a keyboard
and a mouse, and a monitor, which presents the user interface to a
trader.
[0062] The trader terminals 16 and the server 26 communicate via a
communications network which may be a private network or a public
network such as the Internet, for example via the World Wide Web,
as shown in FIG. 1. The communications module may, for example, be
a modem at the trader terminal or client local area network, or
some other suitable device.
[0063] The parser 24 performs an analysis of conversations
exchanged between trader terminal and extracts deal related
information from those conversational exchanges as will be
described in detail. The functional components of the system: the
parser 24, the user interface 20 and the communications software
for the communication module 22 are preferably downloaded to the
trader terminals as an applet each time a trader logs on to the
system. This means that the client terminal does not have to store
any software in order to access and run the system, all of which
may be done by accessing a suitable site on the World Wide Web. The
system 10 may be used by a trader no matter where he or she is
located. However, as will be seen, the system is intended to trade
very large amounts of currency and currency products, as well as
other fungibles, and, in practice, is restricted to banks and other
institutions of proven credit worthiness. Nevertheless, the
portability and flexibility of the system is advantageous to
traders and is not available in prior art conversational dealing
systems in which access is limited to a proprietary network.
[0064] In the preferred embodiment, the sever 26 includes a deal
server 28 and a chat server 30. These form a part of the server
farm of FIG. 1. The deal server acts to verify the details of
proposed deals against business and banking rules and allows other
checks to be made before a proposed deal is made visible to a
potential counterparty. This may include the deal maker's
creditworthiness; that is their ability to settle the trade they
are proposing. The chat server 60 handles the exchange of
conversations between clients on the network. As will be discussed,
conversational messages, which may or may not contain deal related
information, are passed between clients via the chat server. A
client can participate in several conversations at any given time
and can conduct several different conversations with a particular
other different client simultaneously, allowing two parties to have
two or more deals under negotiation at the same time.
[0065] FIG. 3 shows the user interface which is displayed at each
trader terminal. The display comprises a number panels. To an
extent the panels displayed are configurable by each trader
according to his or her preferences although some of the panels are
permanent. In essence the display 100 includes three notional
containers 102, 104 and 106. Container 102 is the upper of the
three containers and extends across the width of the display,
beneath the upper container is a lower left container 104 and a
lower right container 106. To the left of the containers is a
configurable icon display 108.
[0066] The upper container only displays panels which require the
full width of the traders display area. Each of the panels which
can be displayed is assigned one of two priorities. A panel with
priority 1 may not be obscured. A panel with priority 2 may be
covered or given zero height. In either circumstance the panel data
model is maintained when the panel is invisible allowing the data
contained to be displayed when they become visible again.
[0067] There are three permanent panels each of which have priority
1. These are shown in FIGS. 3 and 4. In the upper container 102 is
displayed a deal stack 110, in the lower left container 104 is
displayed a conversations area 112 containing a number of
conversations in which the trader is participating, and in the
lower right container is displayed an incoming conversations panel
114 in which incoming conversational messages are displayed. The
incoming messages include conversations in which the trader is not
yet participating, and may never, participate.
[0068] The optional panels which the trader may choose to display
include:
[0069] A Trader Deal panel (not shown), assigned a priority 1 and
showing all the deals done by the trader and which may be displayed
in either of the two lower containers;
[0070] An Overview panel (not shown), assigned a priority 1 and
positioned in either of the two lower containers;
[0071] A Deal Log panel (not shown) having a priority 2 and showing
deals logged by the system and displayed in the upper container
102; A Rates Area 116 which displays the current trading rates on
the system for various currency pairs and which is assigned a
priority 2; and
[0072] A Conversation Archive (not shown) positioned in one of the
lower containers and which has a priority 2.
[0073] As can be seen from FIG. 4, some of the panels include a
button bar along their lower edge. The various functions of the
buttons will be discussed below. The conversation panels button
bars include a float button. Clicking on this button enables the
position of the panel to be varied around the screen, even outside
the window in which the entire system is displayed. This may be
useful, for example, when the client wants to display several
optional panels or there are a larger number of conversations open.
In the embodiment described up to ten conversations may be ongoing
at one time, although it will be appreciated that this is an
arbitrary number which may be varied.
[0074] The incoming conversations panel lists only incoming
conversational messages. In the example of FIG. 3, there is a
single conversation displayed. At this time, the client is not a
party to the conversation. The conversation is displayed under four
headings: ID, which is the unique conversation identity number;
Time, which is the time at which the conversation was initiated by
the counterparty; From, which is the identity of the counterparty
initiating the conversation; and Message, which is the latest
message line in the conversation. In the FIG. 3 example, the
message A Conversation started by peter@CITQ' has been sent by a
trader identified as Peter at the institution having the identifier
CITQ. The conversation was initiated at 13.34.54 and has the ID No.
1791. Each new conversation is identified with an ID No. It is also
associated with a DealInfo file which is a set of deal related
information including the deal type: Spot FX, FX Outrights,
Forwards etc.; the deal amount, the deal direction (maker, taker)
and other necessary information. A DealInfo structure also includes
the current status of the deal. Central to the manner in which
conversations are parsed is the concept of a deal being in one of a
number of states indicating how far the deal has progressed. In
essence, these states begin with No State, which relates to
conversation with no deal related information; RFQ which is the
state in which a request for a quote has been identified by the
parser; Quote, in which a quote has been identified by the parser
in response to the RFQ; and Buy/Sell in which the deal is completed
by one party agreeing to buy or sell at the price quoted.
[0075] Underneath the Incoming Conversations panel is a button bar
with buttons marked `Pick Up`, `Clear`, `Transfer` and `Chat`. To
select a conversation for action the client clicks on the
conversations line, which will cause that conversation line to be
displayed in a different colour from any other conversations in the
panel (in the present case it is the only conversation). If the
client clicks on the `Pick Up` button, a Conversation panel is
opened in the bottom left container 104 for the selected
conversation (FIG. 4). At this point the system causes all other
parties to whom the conversational message has been sent to display
the message `username has joined the conversation`. When a party
joins a conversation they see that conversation only from the point
at which they joined it. Once a first person has picked up an
invitation to chat to a deal code, that invitation will be
withdrawn from all other parties to which the invitation was
sent.
[0076] Once a trader picks up a conversation, the conversation is
removed from his Incoming Conversations panel.
[0077] The `Clear` button, when clicked, causes the selected
conversation to be cleared from the display. When a conversation is
cleared, the conversation initiator will receive a `Conversation
declined by username` in their own Conversations panel.
[0078] The `Transfer` button is only enabled if a conversation is
bilateral. If clicked, the conversation will be transferred to the
trader or Deal Code specified in the Transfer Conversation dialog.
Rules may be established defining to whom, if anyone, a given
trader may transfer a conversation.
[0079] The `Chat` button invokes the launching of a conversation
session and also opens a conversation panel in the conversation
area. Multiple conversations may be opened with the same person,
although a warning box will preferably be displayed to notify the
client if he is attempting to open a second or subsequent
conversation with the same person.
[0080] All the functionality of the button bar may be displayed,
alternatively, as a drop down menu to enable operation by keyboard
only.
[0081] Referring now additionally to FIGS. 5 to 7, the deal stack
shows a list of deals in which the trader is involved in and which
are pending or completed.
[0082] The Deal Stack 130 comprises the following major components:
A Deal List 132, a Deal Detail Panel 134, and a Button Bar 136. The
deal list presents information about a deal under four headings:
the deal Status 120, the Time 122, the Counterparty (Trader/Bank)
124, the Instrument which is being traded 126 and the Deal 126 that
is being made. The information presented in the deal list 132 is
independent of the instrument being traded. This is achieved by the
use of the deal detail panel and is extremely advantageous as it
allows the deal stack to be presented to the client in a very
simple manner, with the minimum amount of information and in a
manner which is easily assimilated by the trader.
[0083] To understand the text of the Deal field 126 it must first
be appreciated how deal related information can be put into the
system and how the system understands that information as relating
to a deal. Deal information may be submitted to the system in one
of two ways: direct deal input or parsing of conversations. Parsing
of conversations will be discussed in greater detail later. At this
stage it is sufficient to appreciate that parsing involves the
system analysing conversational messages to determine whether they
contain any deal related content. If they do, then the deal is
displayed in the deal list.
[0084] A deal is commenced by a `Request For a Quote` (RFQ) input
into the system by a trader. An RFQ is an indication by a trader
that he is interested in trading. The first line of the deal list
in FIG. 3 shows an RFQ. Here, the trader has put a request out to
the market to trade $2.5 Million in the US$/Canadian dollar market.
At this stage no bid or offer prices are given and there is no
indication whether trader wishes to buy or sell. The RFQ could have
been input into the system as a conversational message or by the
trader making a direct input, in which case he hits the RFQ button
in the deal button bar. This will display a panel asking for the
instrument, the currency pair and the amount.
[0085] Thus a deal may be initiated either by the entry into the
system of a direct quote request or by the detection of a quote
request by the parsing of conversations. For convenience the latter
may be referred to as an indirect quote request.
[0086] When an RFQ is received or detected, the system determines
the text that will be displayed in the deal list. This will either
be a transliteration of the direct RFQ or a representation of the
parsed, indirect RFQ.
[0087] A number of deal statuses are defined for each instrument.
Each of these has an associated status string which is displayed in
the Status field, a deal string which is the text displayed in the
deal field and an understood description.
[0088] Some examples of deal statuses for F/X Spot are as
follows:
1 Taker Maker Description Pre Submit-Taker RFQ is being transmitted
to server. Pre Pickup-Taker Pre Pickup-Maker RFG has reached
maker's screen. Pre Pickup-Taker Pre Pickup To Deal RFQ sent to a
Deal Code Code-Maker has reached a member of the Deal Code's
screen. Pre Quote-Taker Pre Quote-Maker Maker has picked up Pre
BuySell-Taker Pre BuySell-Maker Maker has submitted quote Pre
Re-quote-Taker Pre Re-quote-Maker Maker has interrupted a quote
from "Pre BuySell- Maker" Terminal Status Sold-Taker Bought-Maker
Taker has bought Bought-Taker Sold-Maker Taker has sold No Traders
RFQ to deal code where no Available-Taker traders are logged in
Taker Cancelled Taker has cancelled from "Pre Submit-Taker" Taker
Cancelled Pre Taker Cancelled Pre Taker has cancelled from
Pickup-Taker Pickup-Maker "Pre Pickup-Taker" Taker Cancelled Pre
Taker Cancelled Pre Taker has cancelled from Quote-Taker
Quote-Maker "Pre Quote-Taker" Maker Cancelled Maker Cancelled Pre
Maker cancelled from "Pre Pre Pickup-Taker Pickup-Maker
Pickup-Maker" Maker Cancelled Maker Cancelled Pre Maker cancelled
from "Pre Pre Quote-Taker Quote-Maker Quote-Maker" Taker Cancelled
Pre Taker Cancelled Pre Taker cancelled from "Pre BuySell-Taker
BuySell-Maker BuySell-Taker"?
[0089] The Deal Strings and Status Strings associated with some of
the above are as follows: It should be appreciated that the deal
string is the conversational text which is substituted by the
system for the actual conversation entered by the trader or the
substituted when the trader enters deal information either using
the button bar on the deal stack or equivalent keyboard menus.
2 Status Status String Deal String Pre submit-Taker Submitting I
request .about.AMT.about..about.CCYPAIR.about. Pre pickup-Taker
Contacting I request .about.AMT.about..about.CCYP- AIR.about. Pre
Pickup-Maker Can I quote .about.AMT.about..about.CCY- PAIR.about.?
Pickup? Pre Pickup-Taker Contacting I request
.about.AMT.about..about.CCYPAIR.about. Pre Pick-up Pickup? Can I
quote .about.AMT.about..about.CCYPAIR.about.? to Deal Code Maker
Pre Quote-Taker Accepted Cpty quoting my
.about.AMT.about..about.CCYPAIR.about. Pre Quote-Maker Quote? Can I
quote .about.AMT.about..about.CCYPAIR.about.? Pre BuySell-Taker
Buy/Sell? Cpty quoted .about.BIDOFR.about. for
.about.AMT.about..about.CCY PAIR.about. Pre BuySell-Maker Waiting
Accept I quoted .about.BIDOFR.about. for
.about.AMT.about..about.CCY PAIR.about. Pre Requote-Taker
Re-quoting I request .about.AMT .about.CCYPAIR.about. Pre
Requote-Maker Re-quote? Can I quote .about.AMT.about..about.CCYP-
AIR.about.? Sold-Taker I sell I sell at .about.AMT.about.
.about.CCYPAIR.about.@.about.BID.about. Bought-Maker I buy I sell
at .about.AMT.about. .about.CCYPAIR.about.@.about.OFR.about.
Bought-Taker I buy I buy at .about.AMT.about.
.about.CCYPAIR.about.@.about.BID.about. Sold-Maker I sell I buy at
.about.AMT.about. .about.CCYPAIR.about.@.about.OFR.about.
[0090] The following is an example of the deal statuses where the
instrument is a Forward deal:
3 Taker Maker Description Pre Pickup-Taker RFQ is being transmitted
to server. Pre Pickup-Taker Pre Pickup-Maker RFQ has reached
maker's screen. Pre Pickup-Taker Pre Pickup To Deal RFQ sent to a
Deal Code Code-Maker has reached a member of the Deal Code's
screen. Pre Quote-Taker Pre Quote-Maker Maker has picked up Pre
BuySell-Taker Pre BuySell-Maker Maker has submitted quote Pre
Re-quote-Taker Pre Re-quote-Maker Maker has interrupted a quote
from "Pre BuySell- Maker" S/B Pre Rate-Taker B/S Pre Rate-Maker
Taker has Sold/Bought and is waiting for Taker to enter spot rate
B/S Pre Rate-Taker S/B Pre Rate-Maker Taker has Bought/Sold or
Queried the Spot Rate and is waiting for Taker to enter spot rate
S/B Pre Confirm-Taker B/S Pre Confirm-Maker Taker has Sold/Bought
and Maker has entered spot rate B/S Pre Confirm-Taker S/B Pre
Confirm-Maker Taker has Bought/Sold and Maker has entered spot rate
S/B Pre Rate 2-Taker B/S Pre Rate 2-Maker Taker has Sold/Bought,
queried the Spot Rate and is waiting for Taker to enter a spot rate
a second time B/S Pre Rate 2-Taker S/B Pre Rate 2-Maker Taker has
Bought/Sold, queried the Spot Rate and is waiting for Taker to
enter a spot rate a second time S/B Pre Confirm 2-Taker B/S Pre
Confirm 2-Maker Taker has Sold/Bought and Maker has entered spot
rate a second time Terminal Statuses Sold/Bought-Taker
Bought/Sold-Maker Taker has Sold/Bought and Confirmed spot rate
Bought/Sold-Taker Sold/Bought-Maker Taker has Bought/Sold and
Confirmed spot rate No Traders Available- RFQ to deal code where no
Taker traders are logged in Taker Cancelled Pre Taker Cancelled Pre
Taker has cancelled from Submit-Taker Submit-Maker "Pre
Submit-Taker" Taker Cancelled Pre Taker Cancelled Pre Taker has
cancelled from Pickup-Taker Pickup-Maker "Pre Pickup-Taker" Taker
Cancelled Pre Taker Cancelled Pre Taker has cancelled from
Quote-Taker Quote-Maker "Pre Quote-Taker" Maker Cancelled Pre Maker
Cancelled Pre Maker cancelled from "Pre Pickup-Taker Pickup-Maker
Pickup-Maker" Maker Cancelled Pre Maker Cancelled Pre Maker
cancelled from "Pre Quote-Taker Quote-Maker Quote-Maker" Taker
Cancelled Pre Taker Cancelled Pre Taker cancelled from "Pre
BuySell-Taker BuySell-Maker BuySell-Taker" Maker Cancelled S/B Pre
Maker Cancelled B/S Pre Maker cancelled from "S/B Rate 2-Taker Rate
2-Maker Pre Rate 2-Taker" Maker Cancelled B/S Pre Maker Cancelled
S/B Pre Maker cancelled from "B/S Rate 2-Taker Rate 2-Maker Pre
Rare 2-Taker" Taker Cancelled S/B Pre Taker Cancelled B/S Taker
cancelled from "S/B Confirm 2-Taker Confirm 2-Maker Pre Confirm
2-Taker Take Cancelled B/S Pre Taker Cancelled S/B Pre Taker
cancelled from "B/S Confirm-B Taker Confirm 2-Maker Pre Confirm
2-Taker"
[0091] For every deal in the deal stack there is a corresponding
conversation session. In some cases, the RFQ will have originated
from a conversation. In others it will have not. In the latter
case, a direct quote, a conversation is created but a conversation
panel is only opened, that is, the conversation is exposed, if
specifically requested by the trader.
[0092] Thus, whenever the system performs an action on a deal in
response to a Trader action, a message line is included in the
conversation session indicating the nature of this action. This
message line is in a form where if the Trader had exposed the
underlying conversation and typed in the message text it will parse
and produce the same action on the deal. The Message will be in a
form that reflects the best conversational practice from the point
of view of parsing.
[0093] The Deal List displays all live RFQs that the trader is
involved with. He may see other RFQs if the appropriate options are
set. The Trader will preferably have the option of clearing
completed deals automatically as they are completed. The Trader
will preferably have the option of seeing all RFQs that have been
auto-forwarded from his account. Auto-forwarded RFQs shall be
cleared from the Deal List by the Clear function.
[0094] As mentioned above, the Deal List is wholly independent of
the instrument being traded. Thus, the Deal List only displays five
columns: Status, Time, Trader/Bank, Instrument, and Deal. The Deal
column contains an instrument/status specific string that is
generated by the system to describe the deal.
[0095] To balance the independence of the deal list 132, the Deal
Detail Panel 134 at the bottom of the Deal List has an instrument
specific format and reflects full details of the deal that is
currently selected in the list.
[0096] When a new Deal is added to the Deal List it is inserted at
the bottom of the list regardless of the currently selected sort
order (a re-sort is used to position the deal correctly in the sort
order). When a deal is added to the Deal List, as a result of the
trader's actions (RFQ or Chat), the item last added to the table
becomes the selected item. The list is scrolled so that the
selected item is visible to the trader.
[0097] If the new deal is initiated by a Counterparty the selected
deal does not change. If focus is in the Deal List, the currently
selected item does not change when a new deal is added to the list.
If a new deal is added to the Deal Stack such that the Deal Stack
would have to be scrolled to view the deal, then the scrollbar's
background flashes, for example red, until the deal is made visible
by scrolling.
[0098] The Deal Detail panel may contain buttons and other controls
that relate to instrument specific functionality which is not
available through the standard Deal Stack buttons. When a deal is
in a modifiable state the modification is done via edit controls in
the Deal Detail panel. These potentially modifiable fields shall
have a different colour, for example, cyan, background to the rest
of the deal Detail panel. The deal detail panel itself may be a
different colour, for example yellow, than the deal list. When the
fields are editable they may be distinguished, for example by a
white background with a black border.
[0099] The Format of the Deal Detail panel is specific to the
instrument of the deal. Every implementation of the panel has
certain common fields and controls that are always in the same
place: Status, Time, Trader/Bank, Instrument & Error/Warning
Combo Box. FIG. 5,6,8 and 9 illustrate the Deal Detail panel for
F/X Spot in various stages of a deal and FIG. 7 illustrates the
Deal Detail panel for F/X forwards at a certain stage of the deal
process.
[0100] Thus, the Deal Detail panel 134 includes all the information
in the Deal list 132 except that instead of the deal list 132 it
contains the information which, when entered and then parsed, will
result in that deal list 132. Thus, for F/X Spot (FIG. 5), the Deal
Detail panel includes Amount, Currency Pair, Value Date, Bid and
Offer prices and Dealt. In FIG. 5, the deal detail panel is shown
for the first deal in the stack. This is a deal which has only just
commenced and where the RFQ has been issued. As there are not yet
any bid or offer prices, the only fields that are populated are the
amount, the currency pair and the value date. When parsed this
results in `I request 2,5 Mil USD.cad` as shown in the top of deal
list 132.
[0101] In FIG. 6, the deal highlighted is the third in the list
and, the status of the deal is pre quote B maker, indicating that
the maker has picked up the takers quote and is quoting bid and
offer prices for 3,200 million Japanese Yen. As the amount and the
prices can both be edited, they appear in the Deal Detail panel as
black text on a white background.
[0102] FIG. 7 shows the Deal Detail panel for a Forward deal. Here,
the panel lists both near and far amounts, the currency, the nature
of both the near and far deals, their value dates, the left and
right hand sides, spot (FIG. 5) amounts, all in amounts and deal
amounts. In the example shown, the panel relates to the fourth deal
in the list which is a completed deal. Thus, all the fields in the
deal detail panel are populated and none is modifiable. In order
that traders can be notified of unallowable entries or mistakes,
there is an Error/Warning combo box in the lower left side of the
detail panel. This combo box preferably has an entry in its drop
down list for every error or warning condition associated with the
deal. When an error or warning is selected in the combo box, the
field to which the error or warning pertains will be highlighted in
a very obvious manner, for example with a red (error) or orange
background (warning). Errors and warnings are listed in the order
of their priority. This combo box has an associated label to its
right which indicates the number of errors or warnings that the
combo box contains. When an alarm or warning condition is changed
in the list, the highest priority item is the selected item.
[0103] FIG. 8 shows an example of the error box. Here, the
highlighted deal is the third in the deal list. This requires both
an amount and bid and offer prices. The trader has not entered bid
and offer prices and the error box shows that a bid or offer price
is required. In addition, the Quote? Status string is highlighted
in red and the bid and offer fields which would normally be shown
white.
[0104] The presence of an error in the combo box shall disable keys
and menu items, which allow the deal to proceed forwards, until the
error condition is corrected.
[0105] FIG. 9 shows the deal detail panel for a deal that is
waiting acceptance. Here, the maker has submitted a quote and the
deal is now waiting for an acceptance or refusal from the taker.
The amount, bid and offer details are highlighted to indicate that
they can be modified.
[0106] The Status, Time, Trader/Bank, and Instrument column entries
are positioned on the Deal Detail panel exactly beneath their
respective columns in the Deal List. If the columns are resized,
their relative positions will also change. The Error/Warning combo
box and its associated count label will preferably automatically
have its width set to that of the Status, Time, Trader/Bank and
Instrument columns combined. The instrument specific fields beneath
the Deal column will resize and position themselves proportionally
to the width of the Deal column.
[0107] The instrument specific fields will now be described in more
detail for the two example instruments. It is to be understood that
the invention is applicable to any instruments and the fields will
vary from instrument to instrument.
[0108] The amount field is initially read only and displays the
amount of the RFQ in millions. When the deal reaches the pre
quote-maker stage (FIG. 6), the field becomes editable.
[0109] The `on` currency field is to the right of the amount field
and is the currency in which the RFQ is expressed. If it is not the
base currency it is displayed, if it is, then it is not displayed.
It is not editable until the pre quote B maker stage at which point
it becomes editable
[0110] The currency pair field simply shows the currency pair being
traded.
[0111] The value date indicates the value date for the deal and
cannot be change by the parties. It is a regular date for the
instrument unless indicated otherwise, for example by an
asterisk.
[0112] The bid and quote fields display bids and quotes where these
exist. They are read only except in the pre quote B maker and Pre
re-quote maker stages of the deal when they can be edited, as
described in relation to FIG. 6. If a big figure, that is the most
significant digits of the price is available from the market feed
into the trading system, that figure is used. If an arbitrage
situation is present the market feed rate, the big figure from the
system best offer is used. This can be seen in the system rates
panel which the client may choose to display.
[0113] The final field is the dealt price field which shows the
price at which the deal was done. As can be seen from FIG. 10, this
reflects the side (buy or sell) on which the deal was done. In FIG.
10, the dealt price is the bid price.
[0114] The forwards specific fields shown in the deal detail panel
are as follows;
[0115] Near and Far Amounts. These function in the same manner as
the Amount field in the Spot example.
[0116] On Currency. This functions in the same manner as the Amount
field in the Spot example.
[0117] Currency Pair. This functions in the same manner as the
Amount field in the Spot example.
[0118] Near and Far Periods. If these periods conform to standard
periods, for example one month, they will be shown as such. If they
do not, they will be shown as broken.
[0119] Near and Far Dates. This shows the near and far value
dates.
[0120] Left and Right Hand Side Prices. Where a LHS or a RHS exists
it will be displayed in this field. It is a read only field except
then the deal status is in pre quote B maker or pre requote B maker
status. When in edit mode this field is pre-populated with the
market rate, if available for the bid. If the LHS or the RHS is
left blank by the trader, then a one sided price without a bid or
offer, respectively, is quoted
[0121] Premium and Discount. If the LHS is less than the RHS, the
system assumes that the base currency is at a premium to the local
currency. If the trader does not enter minuses and the RHS is less
than the LHS, the system assumes that the base currency is at a
discount to the local currency. Where a discount is detected, the
system inserts A-A signs before each value and displays the bid and
offer with them. A trader can enter negative amounts for a
discount.
[0122] Spot Rate. Where a spot rate exists, the Spot Rate Bid field
displays it. It is a read only field except when the deal is in I
B/S-Rate or I S/B-Rate (I sell/buy or buy/sell at a given rate)
status. In edit mode, the field is pre-populated with a middle rate
between the bid and offer market rates.
[0123] Spot Button. As can be seen from FIG. 11, the deal detail
panel includes a Spot button on which the client can click to
display a spot rate query dialog window. The spot button is only
visible to the trader when the deal is in I B/S B Confirm or I
S/B-Confirm stages. The spot rate query dialog window includes an
edit box, allowing the trader to enter text of up to 30 characters
having been pre-populated with the text `Check Rate`. This enables
the trader to check the spot rate before committing to a deal. As
can be seen from FIG. 11, the dialog box includes send and cancel
buttons. The send button closes the box, transmits the message and
changes the deal status to I S/B awaiting rate or I B/S awaiting
rate.
[0124] When a maker deal receives a Spot Rate Query message against
it the message appears as a warning in the error/warning combo box.
This is illustrated in FIG. 12.
[0125] All In Rate. This field is read only and, when the maker has
submitted a spot rate, reflects the aggregate of the dealt rate and
the spot rate. For Overnight or Tomorrow-Next periods, the sign of
the forward bid or offer is reversed to calculate the all in
rate.
[0126] Dealt Rate. This is the final field in the deal detail panel
and is a read only field. When the taker has Buy/Sell or Sell/Buy,
the field reflects the price from the side of the market dealt on.
Outrights. The fields for the deal detail panel when the
instruments is an outright are not shown as they are the same as
for a spot deal referred to above.
[0127] The deal column displays different status dependent strings
for each instrument. Some of these, for spot, were discussed
earlier. The strings are not hard coded into the system but are
configurable centrally by the system administrator. The traders
preferably do not have control over the strings. As seen before,
the status definitions comprise tokens, delimited by tildes
(.about.) representing the underlying values for the deal.
[0128] The tokens for spot and outrights are as follows:
[0129] Token Value Format
4 Token Value Format .about.TIME.about. Deal Time "hh:mm:ss"
.about.TRADER.about. Trader As Deal Stack .about.BANK.about. Cpty
bank .about.INST.about. Instrument As per deal stack
.about.AMT.about. Amount "9,999.9" + " " + ONCC.gamma.(if not base
ccy) + "mil" .about.CCYPAIR.about. Ccy pair BASE.local (On currency
shall be in upper case.) .about.VALDAT.about. Value Date "dd mm yy"
.about.BID.about. Bid As per the Ccy pair specific format
.about.OFR.about. Offer As per the Ccy pair specific format
.about.BIDOFR.about. Bid and If Bid & Offer exist: Bid-OfferIf
Bid Offer only: Bid If Offer only: Offer (Bid & Offer As per
the Ccy pair specific format) .about.DEALT.about. Dealt Price As
per the Ccy pair specific format
[0130] The tokens for forwards deals are as follows:
5 Token Value Format .about.TIME.about. Deal Time "hh:mm:ss"
.about.TRADER.about. Trader As Deal Stack .about.BANK.about. Cpty
bank .about.INST.about. Instrument As per deal stack
.about.AMT.about. Amount "9,999.9" + " " + ONCC.gamma.(if not base
ccy) + "mil" .about.HEDGE.about. Spot "9,999.9" + " " +
ONCC.gamma.(if not base Hedge ccy) + "mil" .about.CCYPAIR.about.
Ccy pair BASE.local (On currency shall be in upper case.)
.about.NEAR.about. Near As per deal detail panel Period or Date
.about.FAR.about. Far Period As per deal detail panel or Date
.about.VALDAT.about. Value "dd mm yy" Date .about.BID.about. LHS As
per the Ccy pair specific format Points .about.OFR.about. RHS As
per the Ccy pair specific format Points .about.BIDOFR.about. LHS
and If LHS & RHS exist: LHS-RHS If RHS LHS only: LHS Points If
RHS only: RHS (LHS & RHS As per the Ccy pair specific format)
.about.SPOT.about. Spot Rate As per the Ccy pair specific format
.about.ALLIN.about. All In rate As per the Ccy pair specific format
.about.DEALT.about. Dealt As per the Ccy pair specific format
points
[0131] The third part of the deal stack 130 is the button bar 136
which is beneath the deal list 132 and the deal detail panel 134.
The button bar gives the trader various options for progressing or
cancelling a deal. The button bar is specific to each deal. That
is, the button bar displayed will depend on the deal which is
selected in the deal stack. Some options will not be available to a
trader at certain stages of the deal as will be explained.
[0132] Referring back to FIGS. 5 to 8, it will be seen that the
button bar differs from figure to figure depending on the status of
the deal highlighted in the deal list. In some cases, buttons are
not displayed in bold, indicating that they are not available. In
some cases, buttons are substituted. As examples of the latter, the
pickup button in FIG. 5 is replaced by a quote button in FIG. 6.
The cancel button of FIG. 5 is replaced by the Nothing button in
FIG. 6.
[0133] The button bar provides the trader with an alternative, but
equally valid method of trading to conversational exchanges with
counterparties using the conversation panels. The system operates
by converting deal instructions entered via the buttons into parsed
text in the same manner as it parses conversational text to produce
parsed text for the deal list deal field.
[0134] The buttons available to traders are as follows:
[0135] Pickup (e.g. FIG. 5). This enables a trader to `pickup` an
RFQ entered into the system by a taker. As a result the pickup
button is only available to the maker and then only when the deal
is in the Pre Pickup B Maker status. By pressing pickup the maker
indicates that he is interested in quoting on the RFQ. The RFQ may
be sent by the taker to one or a number of traders. If it has been
sent a deal code (that is a trading floor or floors), on receipt of
a pick up, the RFQ will be removed from the deal lists of all other
recipients.
[0136] Quote (e.g. FIG. 6). This enables a trader to enter a quote
and so is only enabled on the maker side when a deal is in the pre
quote B maker status. The action of the quote will vary from
instrument. For a spot or outright deal, the system transmits to
the taker the makers bid and/or offer together with an amount. For
a forward deal the system transmits to the taker the maker's LHS
points and/or RHS points together with near and far amounts.
[0137] The first button in the button bar combines all default
actions. For the spot example, the button will revert to pickup but
be grayed out for deal statuses other than those mentioned above.
For forwards, more options are available. When the deal is in the
status S/B or B/S Pre Rate-Maker or S/B or B/S Pre Rate 2/-Taker,
the button will be displayed as a Rate Button (not shown) enabling
the maker to transmit to the system the makers spot rate. When the
forward deal is in the status S/B or B/S Pre Confirm-Taker or S/B
or B/S Preconfirm 2-Taker, the button is displayed as a spot button
which allows the Taker to accept the makers proposed spot rate.
[0138] Chat. This button, which is only available when a single
deal is selected causes the conversational panel opened for the
deal to be displayed in the bottom left container. Even if the deal
has been conducted in a direct not conversational form, the system
will show a deparsed version of conversation that would have led to
that deal state. This is possible as each deal has a conversation
with it regardless of how the deal is being conducted, whether by
conversation or direct entry using the button bars. The trader can
switch to conversation at any time to continue the deal. The system
will parse that conversation and will not distinguish between
direct and indirect deal entry methods. In this respect the system
is transparent.
[0139] Hold. This button is only enabled when a selected deal is in
Pre Quote-Maker status. It causes the selected deal to be put back
into Pre Pickup-Taker and Pre Pickup-Maker statuses and, if the
original RFQ was sent to a deal code, causes the RFQ again to be
displayed to all those parties.
[0140] Transfer. This button is only enabled when selected deals
are in Pre Quote Maker Status. It enables a trader to transfer the
deal to another trader within the limits of a preset authority.
Pressing the button will cause a dialog box to be displayed into
which the trader can enter the code of the trader to which the deal
is to be transferred. A message to this effect is displayed on the
originator's deal stack so he knows he is now dealing with a
different counterparty.
[0141] Sell. This button is only enabled for instruments such as
Spot or Outrights. It provides a means for a taker to Sell at the
Makers bid price and so is only enabled in the Pre BuySell status
when there is a bid from the maker.
[0142] RFQ. This button enables a Maker to put out a request for a
quote to the market. When this button is pressed, the maker has to
supply the amount and the currency pair. On receipt of the RFQ by
the system, a new conversation is associated with the deal.
[0143] The RFQ button converts to the caption FIX when the RFQ has
been initiated by conversational parsing on the Taker side and is
awaiting confirmation for accuracy by the taker Callout. This
button enables a trader to initiate a callout.
[0144] Buy. This button is only enabled when a selected deal for an
instrument such as a Spot or an Outright is in the Pre
Buy/Sell-Taker status where there is an offer from the maker. By
hitting the button, the taker indicates to the system that he
wishes to buy at the maker's offer price.
[0145] Cancel. This is a multifunction button whose caption will
depend on the deal status and the instrument being traded in the
selected deal. It is used for all negative functions. The functions
will vary from instrument to instrument but for Spot are as
follows:
6 Caption/Action Taker Status Maker Status Cancel Pre Submit-Taker
Pre Pickup-Taker Pre Quote-Taker Pre Re-quote-Taker Nothing Pre
BuySell-Taker Pre Pickup-Maker Pre Pickup To Deal Code-Maker Pre
Quote-Maker Pre Re-quote-Make Interrupt Pre BuySell-Maker Clear Any
Deal in Terminal Status Any Deal in terminal Status Clear (grayed)
If none of the above apply If none of the above apply The negative
actions for forwards are as follows: Cancel Pre Submit-Taker Pre
Pickup-Taker Pre Quote-Taker Pre Re-quote-Taker Nothing Pre BuySell
2-Taker Pre Pickup-Maker S/B Pre Confirm 2-Taker Pre Pickup To Deal
B/S Pre Confirm 2-Taker Code-Maker S/B Pre Rate 2-Taker Pre
Quote-Maker B/S Pre Rate 2-Taker Pre Re-quote-Maker B/S Pre Rate
2-Maker S/B Pre Rate 2-Maker Interrupt Pre BuySell-Maker Clear Any
Deal in terminal Status Any Deal in terminal Status Clear (grayed)
If none of the above apply If none of the above apply
[0146] Of the various actions mentioned above, the cancel action
cancels the existing deal stage, reverting it to a preceding deal
stage. The Nothing action indicates that the taker is not
interested in a proposed deal. The interrupt action removes the
deal from the deal stack and is only enabled when a deal reaches a
terminal status, that is it is a completed deal.
[0147] Clear All. This button clears all eligible deals from the
deal stack.
[0148] Off All. This button withdraws all deals that are in an
appropriate form from the market.
[0149] The foregoing section has described the trading actions that
are available to a trader from the button bar. It is desirable that
the trader can perform all available functions without using a
pointing device such as a mouse.
[0150] Accordingly, the system provides a set up pop up menus which
provide the same functionality as the button bar but which can all
be invoked from the keyboard. Each function can be invoked by the
same keyboard character in each menu.
[0151] Examples of the characters that can be assigned to functions
are:
7 Mnemonic Action A Clear All B Add Trader to Contact Book C Chat F
Fix H Hold L Add Trader to Callout List M Contact Management O Off
All P Pickup Q Quote R RFQ S Sell T Transfer U Callout X Cancel,
Nothing, Interrupt & Clear Y Spot Rate Query Z Sort
[0152] An example of a possible menu for a deal status is as
follows:
8 Status Menu "Pre Pickup- c. Chat F4 Taker" f. Fix (No Default) t.
Transfer x. Cancel Esc a. Clear All F11 (Only if deals to clear) o.
Off All F12 m. Contact Management (incoming only) r. RFQ F6 u.
Callout F7 z. Sort
Parsing
[0153] The description above has been concerned with the traders
interface with the dealing system. It has been mentioned that deals
can be entered into the system directly through the deal stack
button bar or equivalent keyboard strokes, or that deals can be
entered conversationally, which conversation is parsed by the
system to extract the deal related information. The next section
examines the parsing mechanism.
[0154] Parsing within trading systems is, itself, known. Parsing is
used in the Reuters Dealing 2000/1 system referred to in the
introduction. However, in that system, all deal transactions are
through conversation. The trader does not have the option of using
direct deal entry as described above. As a result there is no
requirements for the system to be able to deparse deal information.
Because of this, and for various other reasons, the parsing
requirements of the present system differ markedly from those of
the prior art. The following description will consider the foreign
exchange markets and, in particular, the three instruments
discussed above: FX Spot, FX Outrights and FX Futures. First, the
manner in which the parser operates will be described by discussing
how a conversational deal is executed with reference to the flow
diagrams of FIGS. 13, 14a, 14b and the various shots of the user
interface of FIGS. 1S to 22. It should first be noted that FIGS. 15
to 22 show a different embodiment of the User Interface from that
previously described.
[0155] At all stages in the exchange of chat, the parser monitors
the conversations looking for an RFQ (Request for a Quote). The
presence of an RFQ alerts the parser that a new deal is being
initiated. Thus if two traders are exchanging pleasantries
unrelated to a deal, the parser will monitor the conversation for
an RFQ. The user's parser is responsible for parsing the user's
conversation but plays no part in the parsing of conversation
received from the other party to a conversation.
[0156] In the following example, a new conversation has been
initiated by a client referred to as Client 1 and shown in FIG. 15
as kdunay@EBSN. This user has typed a message into his Chat panel
and hit the return key. This causes the User Interface (FIG. 2) to
send the line of chat to the parser regardless of content. The
parser parses the conversation looking for a change of status and
for other deal related information. In the present case, the parser
has detected an RFQ in the line of chat. That line, although not
shown may have been `I want 1 Yen`. The parser detects this as an
RFQ and then looks for other deal related information which
includes the instrument traded, here identified as FX Spot, the
currency pair, here US Dollars/Japanese Yen, and the amount, here 1
Million. The Parser returns the parsed conversation to the User
Interface in the form of the DealInfo structure referred to earlier
and which contains the Deal Status and the deal related
information.
[0157] FIG. 15 shows the situation were the DealInfo structure has
been returned to the User Interface. The RFQ has not yet been
entered into the system and is displayed as a parsed line 200 in
the deal stack 202. The parsed line can either be cancelled by the
user, kdunay@EBSN, by hitting the Red Cancel button 204 or edited,
for example to change the amount or the currency if the trader has
made a mistake, changes his mind or is reacting to a change in the
market conditions. Editing is performed by pressing the `Fix`
button 208. Alternatively, the user may re-enter the conversation
so that it is reparsed. To indicate to the user that action is
required, the Status of the line in the deal stack is preferably
shown in a representative colour, for example green. The button 206
on the button bar that the user has to press for the RFQ to be sent
is also shown in Green. The parsed conversation is shown in the
deal stack in a representative colour, for example red, to show
that it is system generated text. At this point, a system message
`Submit?` is also displayed, in red, in the conversation panel.
[0158] It will be seen that the deal stack of FIG. 15 differs from
that of the earlier example in that it includes a strip 210 above
the button bar which displays to the user, significant information
about a highlighted deal. Thus the strip includes the deal status
201, the trader 203, the instrument (spot) 205, the currency pair
207, the amount with the base currency indicated and the buy and
sell rates. These latter rates are displayed in boxes 212, 214
which are unfilled in FIG. 15 as no rate has yet been quoted in
this deal.
[0159] In the example, the line of conversation parsed resulted in
a detected deal status. The line of text could simply have said
something like `Hi, how are you`. The parser would not have
detected any deal related information but it would still send a
response to the User Interface to indicate that a line of
conversation had been parsed, but no dealing information had been
found.
[0160] When the user is satisfied with the parsed line as it
appears in the deal stack, he presses the `Proceed` button 206.
This causes the parsed conversation to be sent to the client's
communications module 22 (FIG. 2) and then to the deal server
28.
[0161] At this point there are a number of features of the parsing
which should be emphasized. First, the parser parses the
conversation line by line and parsing does not take place until the
user has finished typing and hit the send button 216. This
contrasts with the system used in the Reuters 2000/1 system
referred to earlier which parses conversations line by line as they
are being typed by the user. The system described here is
advantageous in that the user can change what he has typed, for
example to react to changes in the market, or simply to correct
errors, without disclosing his hand to the counterparty trader.
Giving the counterparty trader knowledge about a view of the market
is highly undesirable as it may affect the bid or offer he
makes.
[0162] Second, the parser plays no part in the deal making process
and retains no knowledge of the deal. The parser merely looks at
the fine of conversation for information relating to the deal
status. It returns the DealInfo structure to the User Interface and
does not retain any knowledge of the deal. This makes the parser
very simple.
[0163] Third, the parsing is based on a deal status structure with
the emphasis on detecting status movements. The deal status are
very simple: None, RFQ, Quote, Buy/Sell although these are
elaborated as will be discussed. In each of the statuses, there are
a number of deal related terms that the parser looks out for. This
makes parsing very simple and accurate. Firstly because there are
not many terms to look for and secondly because there is less
chance of confusion arising resulting in misparsing. This could
occur, for example, if a line of conversation referred to a
historical deal between the parties. By separating the deal process
into a number of statuses each of which have a limited number or
parseable terms, it is relatively easy for the parser to avoid such
misparsings. The details of the statuses and deal related terms for
each status will be discussed in detail later.
[0164] In the example given, the conversation parsed by the parser
contained both a change in deal status and all the information that
is required to accompany that detected status (instrument, currency
pair, etc.). For each of the possible deal statuses there are only
a number of permitted transitions and for each deal status there is
a limited number of expressions that the parser will recognize as
indicating a change in status. For example, if the new conversation
includes a request for a quote, the parser will look for
information which indicates a quote. It will parse the entire line
and, for a given status will look to fill a predetermined number of
information fields. These will vary depending on the status. As an
example, when the parser is expecting a change in status from RFQ
to Quote, it will look to see whether there is an indication of a
bid quote and/or an offer quote, or a refusal to quote. If there is
a bid/offer quote it also looks for an indication of the currency,
in the case of an FX spot trade. The states of the deals and the
fields required will vary depending on the instrument being
traded.
[0165] Once the conversation input from the user has been parsed,
the parser returns to the user interface one of three
possibilities:
[0166] a) there is nothing in the conversation that is parseable.
This will be the case is the conversation does not include any deal
related information;
[0167] b) an update in the deal structure which includes the new
deal status and the fields found;
[0168] c) an error message where there is an ambiguity and it
cannot resolve the status change. In this case, the error is
displayed in the chat stack and the deal is not changed.
[0169] Reverting back to the parsed conversation message. From the
client's communications module 22 the message is sent to the deal
server 28 at which point it is checked to ensure that it conforms
with system regulations, banking regulation and business related
rules. It may also enable credit checks to be made, for example by
linking in the deal details to the user bank's global credit
checking mechanisms. If the deal cannot proceed a failure message
is displayed at the user terminal but the counterparty is not made
aware of that fact. As far as the counterparty is concerned, the
RFQ that he put out is simply not answered. This ability to conceal
failed deals is advantageous as a user will often not want a
counterparty to know that he has tried to deal with him but failed.
He will also not want that counterparty to know the details of the
attempted deal as it will disclose to him valuable information
about his intentions and his reading of the market. This advantage
stems from the manner in which the system parses conversations on a
line by line basis rather than in real time as they are typed in
character by character.
[0170] Assuming that the deal server 28 does not reject the RFQ,
the parsed message is sent to the destination User Interface via
the destination client's communication module. It should be noted
that the system is arranged such that the deal server handles all
deal related, parsed traffic and the conversation server handles
all conversations carrying unparsed conversation; that is
conversations which the parser has not found to contain a change in
deal status. This dual server arrangement is convenient but is not
essential and could be replaced by a single server or some other
server configuration.
[0171] FIG. 16 shows the user interface after the RFQ has been sent
to the counterparty. The status of the deal in the deal stack is
shown as `waiting pick up` meaning that the User Interface has not
been notified that that the counterparty has picked up the deal
from his incoming conversations panel. In the conversation panel
for the deal, the client's conversation is now shown in a
representative colour, for example green, to show that the message
originated from the client.
[0172] Referring now to FIG. 17, there is shown the user interface
of the client to whom the RFQ described in FIG. 14 has been sent.
The client is identified as test@EBSN. The RFQ message has been
passed by the deal server and relayed to client test@EBSN. The
sending client User Interface has also been notified that the
message has been sent. The incoming message will first appear in
the client's incoming messages panel. In FIG. 15, client test@EBSN
has doubled clicked that message to open up a new conversation in
the active conversation panel. In the figure this is identified as
conversation with the name of the counterparty, kdunay@EBSN
identified. The system indicates in the conversation panel that
client test@EBSN has joined the conversation and displays the
parsed message in the deal stack. Note that the message is
identified as Quote 1 mil JPY usd/JPY? which is an embellished
version of the parsed message displayed in the maker client's deal
stack. The original version of the message is shown in the
conversation panel. The message is shown in the conversation panel
in a representative colour, for example blue, to indicate that it
is an incoming message. In the deal stack, the status of the deal
is shown as `pickup` and coloured green indicating that action is
required by the client. In this case the client has to respond to
the RFQ.
[0173] The second client, test@EBS then types in his response to
the RFQ in the chat line 220 of the conversation panel and hits the
send button 222. In the same manner as the RFQ line, this causes
the User Interface to send the complete line of text to the parser
which again parses the text and sends back the DealInfo structure
to the User Interface. The parsed text, if it contains a change of
status and the necessary deal related information is sent via the
deal server to the counterparty. It should be noted that the parser
for client kdunay@EBSN only parses conversation entered by that
client and the parser at client test@EBSN only parses conversation
entered by that client.
[0174] FIG. 18 shows the counterparty client test@EBSN when a quote
has been entered by the user and parsed by the parser but not
confirmed by the user. The status in the deal stack shows Quote?
and the conversation panel indicates the quote as parsed by the
parser followed by a question mark. The chat line of the
conversation panel invites the user to proceed. In FIG. 18, the
status in the deal panel is preferably shown in a representative
colour showing a warning, in this case orange. The system displays
a message in the conversation panel `Big figure unavailable`. In
this case the message is false and was generated as the rates panel
was disabled but serves to illustrate how warnings can be
shown.
[0175] FIG. 19 shows client kdunay@EBSN's user interface when the
response is received. Client test@EBSN has submitted a quote in
response to the RFQ shown as 123.33/123.45. These figures are the
buy/sell spread. This is shown in the conversation panel in e.g.,
blue as it is an incoming message. Note that the previous entry in
the panel is the client's own conversation. This is shown in a
representative colour, for example green. The deal stack shows the
change in Status to Buy/Sell, highlighting the status in green.
This shows that action is required by the client and that the next
phase of the deal is either an agreement to buy and sell at the
offer price or a denial. It can be seen that the deal information
line shows the offer prices, the amount and the currency pair and
that the large boxes on the bottom strip 212, 214 now include the
buy/sell prices.
[0176] FIG. 20 shows the first client's interface after that client
has replied to the quote by agreeing to sell at the offer price.
The status has changed to I sell and the deal line now reads `I
sell 1 mil JPY usd/JPY @123.33. The last line in the conversation
panel shows, in green that the client has sold and is preceded by a
system prompt, in red, Sell? This prompt appears when the user
types in `Sell` and the change in status to sell is detected by the
parser and returned to the User Interface but before the client has
confirmed the sell by hitting the proceed button.
[0177] No matter what the status of a deal, the parser always looks
for new RFQs and, if one is detected, opens a new conversation.
Thus, in the previous example, instead of agreeing to sell, the
client kdunay@EBSN could have put in a new request such as `I want
1 mil gpb` indicating that he wants to buy one million .English
Pound.Sterling against $US. The parser detects this RFQ and opens a
new conversation but does not terminate the existing conversation.
Then there are now two conversations between the same two parties.
The ability to run several conversations between the same two
counteparties simultaneously is highly desirable. The system can
support a large number of simultaneous conversations between the
same two counterparties, for example 10. This should not be
confused with the ability to have a number of conversations open
with different counterparties at the same time which is known in
the art and also possible with the system embodying the
invention.
[0178] The above discussion illustrates how the system handles a
conversation input by the user. In the course of a deal there will
be several lines of conversation, with each handled in the manner
discussed. As soon as a parser has passed on the deal structure and
the fields detected to the user interface, the information is lost
from the parser. The parser preferably has no capacity or
requirement to retain information regarding the history of the
conversation.
[0179] FIGS. 21 and 22 illustrate two further aspects of the
parser. In FIG. 21 it can be seen that there are two separate
conversations between test@EBSN and kdunay@EBSN. The two
conversations are shown at 224 and 226 in the deal stack and as
conversations 1 and 2 in the conversation panel. In FIG. 21, the
second conversation is active. This is the top line of the deal
stack. The system is returning an error message as the quote has
been input without an amount. The quote status is indicated in a
representative colour, e.g., pink, in the deal stack and an error
message is displayed in red above the button bar telling the user
the source of the problem. In this case it says `must have amount`.
The error is also reflected in the conversation panel which has a
series of error messages `Amount required` 228 followed by a
further, more emphatic, message `must have amount` 230
[0180] FIG. 22 gives another example of the warning message. The
situation illustrated is a development of the second conversation
of FIG. 21. A quote amount has now been entered but the system is
again indicating that the big figure is unavailable and so
highlights the status in orange. The second deal line in the deal
stack is also showing a warning as the deal has been withdrawn by
one of the parties.
[0181] Turning back now to FIGS. 13 and 14. FIG. 13 shows an
overview of the process described. At step 300, the parser looks to
see if there is an identification number for a given conversation.
If there is not, at step 302 it creates a new deal info structure
and, at step 304, sets the status of the deal to Ano deal@. If
there is an ID, it looks up the deal status at step 306 from the
previous parse. However, this status is not held at the parser but
is provided from the user interface. At step 308 the current deal
status is set to the next stage in the deal and at step 310
definitions are applied to the message according to the current
deal status. These determine which terms in the conversation the
parser will acknowledge as being deal related information.
[0182] In FIG. 14A and 14B, the trader inputs a message to the user
interface at step 400. This message is sent by the user interface
to the parser where it is received at 410. At 420 the parser
attempts to parse the message. If it cannot be parsed, the
conversational message is sent to the chat server at 430 and then
to the intended recipient at 440. A message that cannot be parsed
is one that has no deal related content.
[0183] If the parser can detect deal related information, at step
450 it determines whether or not there is an error. If an error is
detected an error message is sent to the trader at 460.
[0184] If there is no error, at step 470 the parser determines
whether or not parsing is complete. If it is not, the client is
asked to complete the information at step 480.
[0185] If parsing is completed successfully, at step 490, the deal
information file is updated and, at step 500, the parsing results
are displayed at the user interface.
[0186] The trader must then decide whether or not they want to
proceed and send the parsed message to the counterparty (at 510).
The confirmation stage is performed by the proceed, edit and cancel
buttons on the deal panel described previously. In the simplified
diagram of FIG. 14B, the edit function is not shown. If the trader
does not want to proceed, the deal is cancelled at step 520 without
having been shown to the counterparty. If the trader does want to
proceed, at 530 the parsed message is sent to the deal server and
at 540 the deal server tries to confirm the parsed message against
the system business rules. If it cannot confirm the deal at step
550 the trader is informed but the counterparty trader receives no
indication that the message was ever sent. If the deal is confirmed
then a confirmation message is sent to the trader at 560 and also
to the chat server at 570 and onto the recipient at 440.
[0187] The manner in which parsing takes place will now be
described in more detail.
[0188] A general FX terminology module provides an indication of
the common terminology used by dealers to deal FX via the Chat
panel on the Trader platform.
[0189] The system monitors all conversations conducted via the chat
panel and interprets text from the conversations into a fixed
format within the deal stack, thus standardizing the deal details
and enabling the system to construct a formal deal ticket for each
FX deal.
[0190] The system can distinguish the important terms within a
conversation that relate to the completion of the deal. This
includes terms related to requesting a quote, responding with a
quote, confirmation of buy or sell, and any notice of special
settlement instructions.
[0191] The system can distinguish terms within a conversation that
could lead to ambiguity as to deal details or whether a deal is in
progress at all. For instance, dealers may be discussing a previous
trade or providing indicative quotes internally.
[0192] The system can ignore terms that are not pertinent to the
completion of a deal. That is, friendly formalities such as
discussions regarding the weather or particular news stories, will
be overlooked by the system, no matter at what point in the deal
process, they occur.
[0193] Functional Components of the General FX Terminology
Requirements are:
[0194] Chat Terminology--Common Deal Terms
[0195] Chat Terminology--Negative Terms
[0196] Chat Terminology--Unrecognized Terms
[0197] The interaction between components is:
[0198] Chat Terminology--Common Deal Terms provides the list of
terms and variables that are directly pertinent to an FX deal being
completed and should be parsed by the system.
[0199] Chat Terminology--Negative Terms provides the list of
negative terms that the system should be aware of that would
indicate that preceding/proceeding terms/phrases are not pertinent
to a deal in progress.
[0200] Chat-Terminology--Unrecognized Terms describes how the
system should treat terms/phrases it does not recognize within the
chat conversation.
Chat Terminology--Common Deal Terms
[0201] The system can recognize all common phrases and terms used
within a conversation that are pertinent to the completion of the
deal. Specific terms within the conversation provide values for the
variables that are necessary for a deal to be concluded. The system
should be able to pick up these terms and to deliver the data to
the corresponding fields within the deal stack.
[0202] Dealers use a variety of different ways/shortcuts to
communicate the same thing within a conversation. The system can
pick up on market conventions in relation to the key variables
required for the deal stack.
[0203] As part of a request for quote, the system permits the user
to enter a single ISO currency code `CurrX` or its pseudonym to
represent the currency pair USD/CurrX. For example:
CHF=USD/CHF
NZD=NZD/USD
GBP=GBP/USD
Cable=GBP/USD
Peso=USD/MXP
[0204] The system permits the user to enter a complete currency
pair, i.e. reference to both currencies, in the following
formats:
Currency1/currency2
Currency1 Currency2
Currency1 Currency2
Currency1-Currency2
[0205] The system permits the user to specify an amount with a
label to denote magnitude. For example:
10 mio=10 million
500k=500 thousand
1bio=1 Billion
[0206] If the user specifies an amount without a label that denotes
the magnitude, the system shall interpret the amount as being
expressed in millions. For example:
10=10 million
CHF in 20=USD/CHF for 20 million USD
GBP in 500k=GBP/USD for 500,000 GBP
[0207] The system permits the user to specify a two-way quote in
any of the following formats:
bid quote/offer quote
bid quote-offer quote
bid quote offer quote
bid quote*offer quote
[0208] The user may specify a one-way bid quote in any of the
following formats:
Bid quote/-
buy at [Bid quote]
Bid at [Bid quote]
[0209] The user may specify a one-way offer quote in any of the
following formats:
-/Offer quote
sell at [Offer quote]
Offer at [Offer quote]
[0210] The user may confirm a deal with the following terms:
[0211] ok
[0212] done
[0213] confirmed
[0214] conf
[0215] agreed
[0216] agree
[0217] The system permits the user to cancel a deal using any of
the following terms:
[0218] Cancel
[0219] Canc
[0220] Nothing
[0221] Nothing
[0222] Nthing
[0223] Nthng
[0224] NT
[0225] No Thanks
[0226] No thks
[0227] If the user cancels the deal in the conversation, the system
automatically cancels the appropriate deal entry in the Deal
Stack.
Chat Terminology--Negative Terms
[0228] The system takes into account that dealers on the system may
discuss previously completed deals via the chat panel, but are not
attempting to complete a deal. The system will recognize terms that
indicate that the current conversation in which the dealers are
engaged, does not pertain to a deal.
[0229] The system does not attempt to parse any variables from the
chat panel if the variables are preceded by the following phrases
within the same line of input/sentence, that indicate a past event
(substitute any characters for . . . )
9 . . . did . . . [deal variables] . . . dealt . . . [deal
variables] . . . completed . . . [deal variables] . . . made . . .
[deal variables] . . . quoted . . . [deal variables] . . . bought .
. . [deal variables] . . . sold . . . [deal variables]
[0230] Some examples of the incidence of the above terms are as
follows:
[0231] We did 10 mio EUR ystd--The dealer is referring to a
historical deal
[0232] We dealt cable in 10 last week--The dealer is referring to a
historical deal
[0233] I completed the stg deal--The dealer is referring to a
historical deal
[0234] He made me stg at 67/70 B The dealer is referring to a
historical quote
[0235] I have done a deal for Swiss in 20--The dealer is referring
to a historical deal
[0236] He quoted 67/70--The dealer is referring to a historical
quote
[0237] If the user has input phrases/terms pertaining to a past
event the system continues its monitoring process of the chat panel
immediately after the input has been sent to the counterparty. For
example:
[0238] We did Eur yesterday
[0239] I want 20 CHF today--the dealer first refers to a historical
deal, which is ignored by the system based on the rules above. The
second sentence is an RFQfrr USD/CHF, 20 million USD that will be
parsed by the system.
[0240] I did not quote you CHF at 50/57
[0241] Its 60/57--The dealerfirst refers to a historical quote (or
a mistaken quote in this case) which is ignored by the system based
on the rules above. The second sentence is a quote for USD/CHF that
will be parsed by the system.
Chat Terminology--Unrecognised Terms
[0242] The chat panel is used for a variety of casual conversations
that have no bearing on the dealing process. The system will ignore
all terms that do not conform to requirements of the Deal Use
Case.
FX Spot Parsing
[0243] The FX Spot module provides the user with the ability to
deal the FX Spot instrument type via the Chat panel on the EBS
Trader platform.
[0244] The Functional Components of the FX Spot Parsing
Requirements are the Deal Use Case and the Chat Terminology--Deal
Terms. The Deal Use Case describes the process of completing a deal
and enables the system to actively `watch` for particular
terms/phrases it is expecting to see within a conversation that are
pertinent to an actual deal. Chat Terminology--Deal Terms provides
the list of terms and variables that are directly pertinent to a
deal being completed and should be parsed by the system.
Deal Use Case
[0245] In order to complete an FX spot deal, the following must
take place: An FX Spot request for quote is sent by a taker to his
maker(s).
[0246] In response, the maker can either: provide a two way quote
(bid and offer) in response to the RFQ--this is only if an amount
was indicated in the RFQ; provide a one way quote (bid or offer) in
response to the RFQ--this is only if an amount as indicated in the
RFQ; provide a quote for a particular amount in response to the
RFQ; or indicate that he does not want to supply a quote, so no
deal takes place.
[0247] The taker receives a quote. In response he can either:
indicate he wants to buy and confirm the deal; indicate he wants to
sell and confirm the deal; or cancel the deal if the taker does not
like the quote.
[0248] The deal is now complete.
[0249] The system recognizes the stage at which an FX Spot deal is
at within the dealing process. The system watches for particular
phrases pertinent to the particular stage of the deal process. If
no deal is currently in progress within a chat panel, the system
monitors the chat panel for indications of a request for quote. In
particular, the system watches for the following terms that
indicate a request for quote has been initiated within a chat panel
conversation:
[0250] An indication of the instrument type (FX Spot)
[0251] An indication of a currency pair
[0252] An indication of an amount
[0253] An indication of the currency of the amount
[0254] A request for quote includes at least an indication of the
currency pair. Some examples are as follows:
[0255] hihi CHF pls--The taker is requesting a quote for
USD/CHF
[0256] hi CHF in 10
[0257] pls--The taker is requesting a quote for USD/CHF for 10
million USD
[0258] Hihi SPOT STG in 10 pls--The taker is requesting a quote for
GBP/USD for 10 million GBP
[0259] Hi frd GBP/EUR pls--the taker is requesting a quote for
GBP/EUR
[0260] Welly for 20 pls--the taker is requesting a quote for
NZD/USD for 20 million NZD
[0261] The system parses all variables indicated as part of an RFQ
from the conversation to the appropriate field in the Deal
stack.
[0262] If the system has identified a request for quote, and it has
been sent to the maker, the system monitors the chat panel for
indications of a response to the request for quote. The system
watches for the following terms within the chat panel that indicate
a response to the request for quote:
[0263] indication of a bid quote
[0264] indication of an offer quote
[0265] indication of a refusal to quote
[0266] an indication of an amount
[0267] an indication of the currency of the amount
[0268] A response to a request for quote includes an amount if one
is not supplied in the RFQ, together with at least one of the
following:
[0269] a bid quote
[0270] an offer quote
[0271] OR
[0272] a refusal to quote
[0273] Some examples of a response to a request for quote:
[0274] 1.4696/4700--The maker provides a two way quote,
bid/offer
[0275] 4696/4700--The maker provides a two way quote bid/offer
[0276] 96/00--the maker provides a two way quote bid/offer
[0277] 56-60 up to 10--the maker provides a two way quote,
bid/offer, and an indication of amount, 10 million
[0278] I buy at 60--the maker provides a one-way quote; the offer
quote.
[0279] Nothing-Maker refuses to quote
[0280] The system parses all variables indicated by the maker in
the response to a request for quote from the conversation to the
appropriate fields in the Deal Stack. A refusal to quote is
indicated if the maker inputs this intention into the chat panel or
cancels the deal through the deal stack. If the maker refuses to
quote, the system shall conclude that the deal has been cancelled.
If the maker refuses to quote, the system re-starts its monitoring
process and looks for a request for quote within the conversation.
The system ensures that the following variables have been parsed
from the conversation to the deal stack prior to permit the taker
to indicate his intention to buy or sell:
[0281] The currency pair
[0282] The amount
[0283] The currency of the amount
[0284] A bid and/or an offer
[0285] If the above variables have not all been successfully parsed
to the deal stack, the system requests that the maker input the
missing variables prior to indicating his intention to send. For
example, the system could raise an alarm. If the system has
identified a response to a request for quote, and the response has
been sent to the taker, the system monitors the chat panel for a
response to the quote.
[0286] The system watches for the following terms within the chat
panel that indicate a response to the quote:
[0287] an indication to buy at the offer price
[0288] an indication to sell at the bid price
[0289] an indication of a cancellation of the deal
[0290] A response to a quote includes at least one of the
following:
[0291] an indication to buy at the offer price
[0292] an indication to sell at the bid price
[0293] an indication of a cancellation of the deal
[0294] Some examples of a response to quote are:
[0295] Ok, I buy--the taker is happy with quote and agrees to buy
at offer price
[0296] Ok, mine in 10--the taker is happy with quote and agrees to
buy at offer price for an amount of 10 million, the amount "10" is
ignored by the system, the whole available amount is bought
[0297] Yours--the taker is happy with quote and agrees to sell at
the bid price
[0298] Ok I sell--the taker agrees to sell.
[0299] Nothing thks--the taker does not like the quote and does not
wish to deal.
[0300] A cancellation of the deal indicated if the taker inputs his
intention to cancel (he does not like the price) or the taker
cancels the deal within the deal stack. If the taker cancels the
deal, the system shall re-start its monitoring process and look for
a request for quote within the conversation. If the system has
identified a response to quote the system confirms the deal in the
deal stack and re-starts its monitoring process and look for a
request for quote within the conversation.
Chat Terminology B Deal Terms
[0301] The system can recognize all phrases and terms used within a
conversation that are pertinent to the completion of the deal.
[0302] Specific terms within the conversation provide values for
the variables that are necessary for a deal to be concluded. The
system is able to pick up these terms and to deliver the data to
the corresponding fields within the deal stack.
[0303] Dealers use a variety of different ways/shortcuts to
communicate the same thing within a conversation. The system can
pick up on market conventions in relation to the key variables
required for the deal stack.
[0304] As part of a request for quote, the system permits the user
to enter the term "spot" to indicate that the deal is a FX Spot
deal. For example:
SPOT Swiss please=FX Spot deal for USD/CHF
[0305] As part of the request for quote, the system permits the
user to specify a currency pair with or without an amount, to
indicate that the deal is a FX Spot deal. For example:
Stg pls=FX Spot deal for GBP/USD
EUR pls=FX Spot deal for EUR/USD
Eur in 10 pls=FX Spot deal for EUR/USD, amount is 10 million
EUR
CHF for 20=FX Spot deal for USD/CHF, amount is 20 million USD
[0306] The system permits the user to specify an amount of currency
to buy or sell. For example:
10 mio GBP against USD pls=USD/GBP, 10 million GBP
Eur pls, 10 million US=EUR/USD, 10 million USD
[0307] If the user does not specifically indicate the currency of
the amount, the system shall interpret the amount to represent the
amount in the base currency of the currency pair. For example:
eur in 10 pls=EUR/USD 10 million EUR
chf for 10=USD/CHF, 10 million USD
50 mio Welly pls=NZD/USD, 50 million NZD
[0308] The system permits the user to enter the big figure only
once as part of the first part of the quote, be it bid or offer.
For example:
1.4567/70=>bid quote=1.4567, offer quote=1.4570
121.43/53=>bid quote=121.43, offer quote=121.43
[0309] The system permits the user to enter a quote without the big
figure, i.e. only the pips of the quote. For example:
67/70=>GBP/USD quote, bid quote=1.4567, offer quote=1.4570
43/53=>GBP/JPY quote, bid quote=121.43, offer quote=121.53
[0310] The system warns the user if there is no big figure
available. The system permits the user to indicate his preference
to buy the stated amount of currency by using the following
terms:
[0311] Buy
[0312] Mine
[0313] M
[0314] B
[0315] Take
[0316] T
[0317] At [Offer Price]
[0318] [Offer Price]
[0319] The system permits the user to indicate his preference to
sell the stated amount of currency by using the following
terms:
[0320] sell
[0321] Yours
[0322] give
[0323] G
[0324] At [Bid Price]
[0325] [Bid Price]
[0326] The system permits the taker to indicate his intention to
buy or sell. For example:
[0327] I sell CHF=User sells previously indicated amount of CHF
[0328] Y=User sells previously indicated amount in previously
indicated currency
FX Outrights
[0329] The parsing requirements for FX outrights are similar to
those described for FX Spot.
[0330] The following is a description of the process followed to
complete an FX Outright deal
[0331] An FX Outright request for quote is sent by a taker to his
maker(s).
[0332] In response, the maker can either: provide a two way quote
(bid and offer) in response to the RFQ--this is only if an amount
was indicated in the RFQ; provide a one way quote (bid or offer) in
response to the RFQ--this is only if an amount was indicated in the
RFQ; provide a quote for a particular amount in response to the
RFQ; or indicate that he does not want to supply a quote, no deal
takes place.
[0333] The taker receives a quote. In response he can either:
indicate he wants to buy and confirms the deal; indicate he wants
to sell and confirms the deal; cancel the deal B the taker does not
like the quote.
[0334] The deal is now complete.
[0335] The system recognizes the stage at which a deal is at within
the dealing process and watches for particular phrases pertinent to
the particular stage of the deal process. If no deal is currently
in progress within a chat panel, the system monitors the chat panel
for indications of a request for quote. The following terms that
indicate a request for quote has been initiated within a chat panel
conversation are watched for:
[0336] An indication of the instrument type (FX Outright)
[0337] An indication of a currency pair
[0338] An indication of an amount
[0339] An indication of the currency of the amount
[0340] An indication of a duration/forward date
[0341] A request for quote should include at least the
following:
[0342] An indication of the currency pair
[0343] An indication of the instrument type
[0344] An indication of a duration/forward date
[0345] Some examples of a request for quote:
[0346] hihi Outrite 3m CHF pls--The taker is requesting a quote for
an FX Outright for USD/CHF maturing in 3 months
[0347] hi Out 10 mio CHF 6m pls--The taker is requesting a quote
for an FX Outright in USD/CHF for 10 million USD maturing in 6
months
[0348] Hihi o/r cable in 10 maturity 5 Jan 01 pls--The taker is
requesting a quote for an FX Outright in GBP/USD for 10 million GBP
maturing on the 5.sup.th of January 2001
[0349] Hi frd Outrite GBP/EUR 1yr pls--the taker is requesting a
quote for an FX Outright in GBP/EUR maturing in 1 years time
[0350] The system parses all variables indicated as part of an RFQ
from the conversation to the appropriate field in the Deal stack.
If the system has identified a request for quote, and the RFQ has
been sent to the maker, it monitors the chat panel for indications
of a response to the request for quote.
[0351] The following terms within the chat panel that indicate a
response to the request for quote are watched for:
[0352] indication of a bid quote
[0353] indication of an offer quote
[0354] indication of a refusal to quote
[0355] an indication of an amount
[0356] A response to a request for quote includes an amount (if not
supplied in the RFQ) together with at least one of the
following:
[0357] a bid quote
[0358] an offer quote
[0359] OR
[0360] a refusal to quote Some examples of a response to a request
for quote:
[0361] 1.4301/08--The maker provides a two way quote, bid/offer
[0362] 4696/4700--The maker provides a two way quote bid/offer
[0363] 0.87563-62--the maker provides a two way quote bid/offer
[0364] [106.70 90 Spot 107.00 03--the maker provides a two way
quote, bid/offer, and the spot split, 107.00/107.03]
[0365] Nothing--Maker refuses to quote
[0366] All variables indicated by the maker in the response to a
request for quote are parsed, from the conversation to the
appropriate fields in the Deal Stack. A refusal to quote is
indicated if the maker inputs this intention into the chat panel or
the maker cancels the deal in the deal stack.
[0367] If the maker refuses to quote, the system concludes that the
deal has been cancelled, and the monitoring process is restarted,
looking for a request for quote within the conversation.
[0368] The system ensures that the following variables have been
parsed from the conversation to the deal stack prior to permit the
taker to indicate his intention to buy or sell:
[0369] An indication of a duration/forward date
[0370] The currency pair
[0371] The amount
[0372] The currency of the amount
[0373] A bid and/or an offer
[0374] If the above variables have not all been successfully parsed
to the deal stack, the system requests that the maker input the
missing variables prior to indicating his intention to send. If the
system has identified a response to a request for quote, and the
response has been sent to the taker, it monitors the chat panel for
a response to the quote. The following terms are watched for within
the chat panel that indicate a response to the quote:
[0375] an indication to buy
[0376] an indication to sell
[0377] an indication of a cancellation of the deal
[0378] A response to a quote includes at least one of the
following:
[0379] an indication to buy
[0380] an indication to sell
[0381] an indication of a cancellation of the deal
[0382] Some examples of a response to quote:
[0383] Ok, I buy--the taker is happy with quote and agrees to buy
at offer price
[0384] Nothing thks--the taker does not like the quote and does not
wish to deal
[0385] A cancellation of the deal is indicated if the taker inputs
his intention to cancel (he does not like the price) or the taker
cancels the deal in the deal stack. If the taker cancels the deal,
the system re-starts its monitoring process and looks for a request
for quote within the conversation. If the system has identified a
response to quote the system confirms the deal in the deal stack
and re-starts its monitoring process looking for a request for
quote within the conversation.
[0386] As part of a request for quote, the system requires the user
to enter one of the following terms to indicate that the deal is a
FX Outright deal:
[0387] Outright
[0388] Outrite
[0389] Out
[0390] O/r
[0391] As part of the request for quote, the system requires the
user to specify a currency pair. For example:
[0392] Outright 6m Stg pls=FX Outright 6 months for GBP/USD
[0393] Out 3m EUR pls=FX Outright, 3 months for EUR/USD
[0394] O/r 23/01 Eur in 10 pls=FX Outright for EUR/USD, amount is
10 million EUR, maturity is 23/01/01
[0395] Outrite 9mth CHF for 20=FX Outright, 9 months for USD/CHF,
amount is 20 million USD
[0396] The user is permitted to specify an amount of currency to
buy or sell, for example:
[0397] Outrite 10 mio GBP against USD 6m pls=GBP/USD, 10 million
GBP, 6 months duration
[0398] Outrite Eur pls, 10 million US 6m=EUR/USD, 10 million USD, 6
months duration
[0399] If the user does not specifically indicate the currency of
the amount, the system interprets the amount to represent the
amount in the base currency of the currency pair, for example:
[0400] Out eur 10mio 3m pls=EUR/USD 10 million EUR, 3 months
[0401] Out chf for 10 months, 20 mio=USD/CHF, 10 months, 20 million
USD
[0402] 50 mio Welly out pls, 3m=NZD/USD, 50 million NZD, 3
months
[0403] The system requires the user to express a duration for the
deal as part of the request for quote.
[0404] The system shall permit the user to express a maturity date
(the terms "value date" or "settlement date" can be used) in lieu
of a duration as part of the request for quote. The maker may enter
the forward bid rate directly to represent the bid quote for an FX
Outright. The maker may enter the forward offer rate directly to
represent the offer quote for an FX Outright. The user may enter
the big figure only once as part of the first part of the quote, be
it bid or offer. For example:
1.4567/70=>bid quote=1.4567, offer quote=1.4570
121.43/53=>bid quote=121.43, offer quote=121.43
[0405] The user may enter a quote without the big figure, i.e. only
the pips of the quote. For example:
67/70=>GBP/USD quote, bid quote=1.4567, offer quote=1.4570
43/53=>GBP/JPY quote, bid quote=121.43, offer quote=121.53
[0406] The user is warned by the system if there is no big figure
available. The user may indicate his preference to buy the stated
amount of currency at the forward date by using the following
terms:
[0407] Buy
[0408] Mine
[0409] M
[0410] B
[0411] Take
[0412] T
[0413] At [Offer Price]
[0414] [Offer Price]
[0415] The user can indicate his preference to sell the stated
amount of currency at the forward date by using the following
terms:
[0416] Sell
[0417] Yours
[0418] By
[0419] S
[0420] Give
[0421] G
[0422] At [Bid Price]
[0423] [Bid Price]
[0424] The system permits the taker to indicate his intention to
buy or sell. For example:
[0425] I sell CHF=User sells previously indicated amount of CHF
[0426] Y=User sells previously indicated amount in previously
indicated currency.
FX Forwards Parsing
Deal Use Case
[0427] The following is a description of the process followed to
complete an FX Forward deal:
[0428] An FX Forward request for quote is sent by a taker to his
maker(s)
[0429] In response, the maker can either: provide a two way quote
in response to the RFQ--this is only if an amount was indicated in
the RFQ; provide a one way quote in response to the RFQ--this is
only if an amount was indicated in the RFQ; provide a quote for a
particular amount in response to the RFQ; or indicate that he does
not want to supply a quote, in which case no deal takes place.
[0430] The taker (taker of the deal) receives a quote. In response
he can either: indicate he wants to sell at near date/buy at far
date and confirms the deal; indicate he wants to buy at near
date/sell at far date and confirms the deal; or cancel the deal B
the taker does not like the quote.
[0431] The maker (maker of the deal) receives notification of the
taker's intent. In response he must supply a Spot Rate.
[0432] The taker receives the Spot rate. In response he can either:
confirm the deal; or query the Spot Rate.
[0433] If the Taker queries the Spot rate, the maker receives
notification of the query. In response he can either: supply a new
Spot Rate or cancel the deal if the Maker is not happy with any
other rate.
[0434] The taker receives the new Spot rate. In response he can
either: confirm the deal; query the Spot Rate again; or cancel the
deal if the Taker is not happy that he will ever get a satisfactory
(only available if queried once already) .
[0435] Once the Taker confirms the Deal it is now complete.
[0436] The system recognizes the stage at which a deal is at within
the dealing process, and watches for particular phrases pertinent
to the particular stage of the deal process. If no deal is
currently in progress within a chat panel, the system monitors the
chat panel for indications of a request for quote. The system
watches for the following terms that indicate a request for quote
has been initiated within a chat panel conversation:
[0437] An indication of the instrument type (FX Forward)
[0438] An indication of a currency pair
[0439] An indication of an amount for the near period
[0440] An indication of an amount for the far period
[0441] An indication of the currency of the amounts
[0442] An indication of a duration/forward date for value date
[0443] An indication of duration/forward date for maturity date
[0444] A request for quote should include at least the
following:
[0445] an indication of the currency pair
[0446] An indication of the instrument type
[0447] An indication of a duration/forward date
[0448] Some examples of a request for quote are as follows:
[0449] hihi Fwd 3m CHF pls--The taker is requesting a quote for an
FX Forward for USD/CHF Value date is Spot date maturing in 3
months
[0450] hi Swap 10 mio CHF s/n pls--The taker is requesting a quote
for an FX Forward in USD/CHF for 10 million USD spot next (Value
date is Spot date, maturity date is day after spot date)
[0451] Hihi Forward cable in 10 maturity 5 Jan 01 pls--The taker is
requesting a quote for an FX Forward in GBP/USD for 10 million GBP
value on Spot date maturing on the 5.sup.th of January 2001
[0452] Hi frd Fwd-Fwd GBP/EUR 6 months v 1yr pls--the taker is
requesting a quote for an FX Forward in GBP/EUR value date in 6
months maturing in 1 years time
[0453] Hi swp CHF, 6 mths 10mio at near end 10,500,000 at far--the
taker is requesting a quote for a USD/CHF FX Forward, 10 million
USD exchanged at spot date and 10,500,000 USD at maturity date (6
months)
[0454] The system parses all variables indicated as part of an RFQ
from the conversation to the appropriate field in the Deal stack.
If the system has identified a request for quote, and the RFQ has
been sent to the maker, it monitors the chat panel for indications
of a response to the request for quote. The system watches for the
following terms within the chat panel that indicate a response to
the request for quote:
[0455] Indication of a spot bid quote
[0456] Indication of a spot offer quote
[0457] Indication of a forward quote for value date
[0458] indication of a refusal to quote
[0459] an indication of an amount
[0460] A response to a request for quote includes an amount (if not
supplied in the RFQ) together with at least one of the
following:
[0461] a bid quote
[0462] an offer quote
[0463] OR
[0464] a refusal to quote
[0465] Some examples of a response to a request for quote:
[0466] 60/56--The maker provides a two way quote, bid/offer
[0467] 4696/4700--The maker provides a two way quote bid/offer
[0468] 38/30--the maker provides a two way quote bid/offer
[0469] 56-60 upto 10--the maker provides a two way quote,
bid/offer, and an indication of amount, 10 million, the "upto" is
ignored by the system.
[0470] Nothing--Maker refuses to quote
[0471] The system parses all variables indicated by the maker in
the response to a request for quote, from the conversation to the
appropriate fields in the Deal Stack. A refusal to quote is
indicated if the maker inputs this intention into the chat panel or
the maker cancels the deal in the deal stack. If the maker refuses
to quote, the system concludes that the deal has been cancelled. If
the maker refuses to quote, the system re-starts its monitoring
process and look for a request for quote within the conversation.
The system ensures that the following variables have been parsed
from the conversation to the deal stack prior to permitting the
taker to indicate his intention to buy or sell:
[0472] An indication of a duration/forward date
[0473] The currency pair
[0474] A Near amount
[0475] A Far amount
[0476] The currency of the amount
[0477] A bid and/or an offer
[0478] If the above variables have not all been successfully parsed
to the deal stack, the system requests that the maker input the
missing variables prior to indicating his intention to send. If the
system has identified a response to a request for quote, and the
response has been sent to the taker, the system monitors the chat
panel for a response to the quote.
[0479] The system watches for the following terms within the chat
panel that indicate a response to the quote:
[0480] an indication to buy/sell (base currency) at the LHS (Left
Hand Side) price
[0481] an indication to sell/buy (base currency) at the RHS (Right
Hand Side) price
[0482] an indication to buy/sell (foreign currency) at the RHS
price
[0483] an indication to sell/buy (foreign currency) at the LHS
price
[0484] an indication of a cancellation of the deal
[0485] A response to a quote shall include at least one of the
following:
[0486] an indication to buy/sell
[0487] an indication to sell/buy
[0488] an indication of a cancellation of the deal
[0489] Some examples of a response to quote:
[0490] Ok, I buy/sell--the taker is happy with quote and agrees to
buy local currency on spot date and sell local currency at maturity
at the PHS price
[0491] Ok, I s/b--the taker is happy with quote and agrees to sell
local currency on spot date and buy local currency at maturity at
the LHS price
[0492] Nothing thks.--the taker does not like the quote and does
not wish to deal
[0493] A cancellation of the deal is indicated if the taker inputs
his intention to cancel (he does not like the price) or the taker
cancels the deal in the deal stack. If the taker cancels the deal,
the system re-starts its monitoring process and looks for a request
for quote within the conversation. If the system has identified a
response to quote, and the response to quote has been sent to the
maker, the system monitors the chat panel for provision of Spot
Rate. The system watches for the following terms within the chat
panel that indicate a provision of Spot Rate:
[0494] a provision of Spot Rate
[0495] an indication of a cancellation of the deal (only if Spot
rate has already been queried
[0496] Some examples of a provision of Spot Rate:
[0497] 1.4350 B the maker is willing to use a Spot Rate of
1.435
[0498] If the system has identified a provision of spot rate, and
the rate has been sent to the taker, the system shall monitor the
chat panel for response to the Spot Rate.
[0499] The system watches for the following terms within the chat
panel that indicate a response to the Spot Rate:
[0500] an indication of deal confirmation
[0501] an indication of querying the Spot rate
[0502] an indication of a cancellation of the deal (only if at
least one rate has previously been provided)
[0503] Some examples of a querying the Spot rate are as
follows:
[0504] check spot--terse minimum query
[0505] check spot seems high--qualified query
[0506] The system shall return the entire line that includes the
querying of the Spot rate and use it as the text to a Spot Rate
Query warning to the maker:
[0507] Some examples of a Deal Confirmation are:
[0508] Ok--confirmation, deal is complete
[0509] Confirm--confirmation, deal is complete
[0510] Done B Confirmation, deal is complete
[0511] If the maker confirms the deal within the conversation, the
system confirms the related deal entry within the Deal Stack. A
cancellation of the deal is indicated if the maker inputs his
intention to cancel (he does not like something) or the maker
cancels the deal in the deal stack. If the maker or taker cancels
the deal, the system re-starts its monitoring process and look for
a request for quote within the conversation. Once the taker has
confirmed the deal, the system confirms the deal in the deal stack
and re-starts its monitoring process and looks for a request for
quote within the conversation.
[0512] As part of a request for quote, the system requires the user
to enter one of the following terms to indicate that the deal is a
FX Forward deal.
[0513] Swap
[0514] Swp
[0515] Fwd
[0516] Forward
[0517] Fwd-fwd
[0518] Fwd fwd
[0519] Fwdfwd
[0520] Fwd/fwd
[0521] As part of the request for quote, the system requires the
user to specify a currency pair. For example:
[0522] Swap 6m Stg pls=FX Forward 6 months for GBP/USD
[0523] Swp 3m EUR pls=FX Forward, 3 months for EUR/USD
[0524] Fwd 23/01 Eur in 10 pls=FX Forward for EUR/USD, amount is 10
million EUR, maturity is 23/01/01
[0525] Forward 9mth CHF for 20=FX Forward, 9 months for USD/CHF,
amount is 20 million USD
[0526] The system permits the user to specify an amount of currency
to buy or sell, for example:
[0527] Swp 10 mio GBP against USD 6m pls=GBP/USD, 10 million GBP, 6
months duration
[0528] Swap Eur pls, 10 million US 6m=EUR/USD, 10 million USD, 6
months duration
[0529] If the user does not specifically indicate the currency of
the amount, the system interprets the amount to represent the
amount in the base currency of the currency pair. For example:
[0530] Out cur 10mio 3m pls=EUR/USD 10 million EUR, 3 months
[0531] Out chf for 10 months, 20 mio=USD/CHF, 10 months, 20 million
USD
[0532] 50 mio Welly out pls, 3m=NZD/USD, 50 million NZD, 3
months
[0533] The system permits the user to enter a second amount to
represent the amount far end (maturity date) of the FX Forward. The
system permits the user to indicate the amount at the far end of
the FX Forward in the following formats:
[0534] [Amount] at far end/leg
[0535] split amount (at far end/leg) [Amount]
[0536] [Amount] split amount (at far end/leg)
[0537] Cock amount (at far end/leg) [Amount]
[0538] [Amount] cock amount (at far end/leg)
[0539] The system permits the user to express a duration for the
deal as part of the request for quote, and permits the user to
express a maturity date in lieu of a duration as part of the
request for quote. The user can express a period to represent the
value date, and can express a date to represent the value date in
lieu of a period. The user may enter points to represent the bid
quote for an FX Forward Deal and to represent the offer quote for
an FX Forward Deal. If the user enters both a bid and offer quote
in points, the system interprets and parses the first value (on the
left) of the two quotes as the bid quote, and interprets and parses
the second value (on the right) of the two quotes as the offer
quote. In this case, and the bid quote is higher than the offer
quote and the value date is prior to spot date (e.g. tomorrow), the
system adds the bid quote points (on the left) to the spot bid rate
to calculate the forward bid rate. This rate represents the rate at
which you buy base currency on the first leg (near date) of the FX
Forward. In this situation, the forward rate for the currency pair
is less than then the near rate. If, the bid quote is higher than
the offer quote and the value date is prior to spot date (e.g.
tomorrow), the system adds the offer quote points (on the right) to
the spot offer rate to calculate the forward offer rate. This rate
represents the rate at which you sell base currency on the first
leg (near date) of the FX Forward. In this situation, the forward
rate for the currency pair is less than then the near rate. If the
bid quote is higher than the offer quote and the maturity date is
after the spot date (e.g. 1 week), the system subtracts the bid
quote points (on the left) from the spot bid rate to calculate the
forward bid rate. This rate represents the rate at which you sell
base currency on the second leg (far date) of the FX Forward. In
this situation, the forward rate for the currency pair is less than
then the near rate. If the bid quote is higher than the offer quote
and the maturity date is prior to spot date (e.g. tomorrow), the
system subtracts the offer quote points (on the right) to the spot
offer rate to calculate the forward offer rate. This rate will
represent the rate at which you buy base currency on the second leg
(far date) of the FX Forward. In this situation, the forward rate
for the currency pair is less than then the near rate.
[0540] If the bid quote is lower than the offer quote and the value
date is prior to spot date (e.g. tomorrow), the system shall
subtract the bid quote points (on the left) from the spot bid rate
to calculate the forward bid rate. This rate represents the rate at
which you buy base currency on the first leg (near date) of the FX
Forward. In this situation, the forward rate for the currency pair
is more than then the near rate.
[0541] If the bid quote is lower than the offer quote and the value
date is prior to spot date (e.g. tomorrow), the system subtracts
the offer quote points (on the right) from the spot offer rate to
calculate the forward offer rate. This rate represents the rate at
which you sell base currency on the first leg (near date) of the FX
Forward. In this situation, the forward rate for the currency pair
is more than then the near rate.
[0542] If the bid quote is lower than the offer quote and the
maturity date is after the spot date (e.g. 1 week), the system adds
the bid quote points (on the left) to the spot bid rate to
calculate the forward bid rate. This rate represents the rate at
which you sell base currency on the second leg (far date) of the FX
Forward. In this situation, the forward rate for the currency pair
is more than then the near rate.
[0543] If the bid quote is higher than the offer quote and the
maturity date is prior to spot date (e.g. tomorrow), the system
adds the offer quote points (on the right) to the spot offer rate
to calculate the forward offer rate. This rate represents the rate
at which you buy base currency on the second leg (far date) of the
FX Forward. In this situation, the forward rate for the currency
pair is more than then the near rate.
[0544] The user can enter a spot bid quote in association with the
FX Forward to represent the spot bid rate and can enter a spot
offer quote in association with the FX Forward to represent the
spot offer rate. If the user has not entered a spot bid quote in
association with the FX Forward, the system uses the spot market
mid rate of the particular currency pair to represent the spot bid
rate. If the user has not entered a spot bid quote in association
with the FX Forward, the system uses the spot market mid rate of
the particular currency pair to represent the spot offer rate.
[0545] If neither of the two legs of the swap fall on Spot date,
the system permits the user to enter a value date bid quote in
association with the FX Forward and to enter a value date offer
quote in association with the FX Forward.
[0546] The user can enter the forward bid or offer rate directly to
represent the bid quote for an FX Forward.
[0547] If the user is quoting using the forward rates, the system
shall interpret the first of the rates (on the left) as the bid
quote and the second of the rates (on the right) as the offer
quote.
[0548] The user can indicate is preference to Buy the stated amount
of currency at the near date and sell the stated amount of currency
at the far date by using the following terms:
[0549] buy/sell
[0550] buy sell
[0551] b/s
[0552] b s
[0553] I buy [amount] [currency] on [value date]
[0554] The user can indicate his preference to sell the stated
amount of currency at the near date and buy the stated amount of
currency at the far date, by using the following terms:
[0555] sell/buy
[0556] Sell buy
[0557] sell&buy
[0558] s/b
[0559] s b
[0560] I sell [amount] [currency] on [value date]
[0561] The user can indicate his intention to buy/sell or sell/buy.
For example:
[0562] I sell/buy CHF=User sells/buys previously indicated amount
of CHF
[0563] S/b=User sells/buys previously indicated amount in
previously indicated currency
[0564] In the case of an FX Forward deal where the taker is
selling/buying, the system permits the maker to confirm the deal
with the following additional terms:
[0565] buy/sell
[0566] buy sell
[0567] buy&sell
[0568] b/s
[0569] bs
[0570] In the case of an FX Forward deal where the maker is
supplying a Spot Rate, the system permits the maker to supply the
rate without the big figure. The system warns the user if there is
no market rate available from which to derive the big figure.
[0571] It will be appreciated from the above that the invention
provides a highly advantageous interface to the user in which the
deal stack is presented to the user in a manner which is easy to
interpret by the dealer who has to assimilate a lot of information,
often in a very short space of time. By separating out information
which is common to all instruments from information specific to a
deal in any particular instrument, it is possible to present a deal
list which is simple and easy to view. However, as the deal detail
panel includes information related to a selected deal, the trader
is never left without essential information relating to the deal on
which he is working.
[0572] When trading on the system described, the trader has the
choice of entering deal information through conversational chat
which is parsed by the system or directly preferably using buttons
on the user interface or keyboard driven menus. The trader can
switch between the two during the progress of a deal. This
flexibility is possible as the deal related information input,
whether it is parsed conversation or direct input only conveys to
the deal stack that there has been a change of deal status. All
other deal related activities are performed by the deal stack and
include sending necessary messages to the rest of the system, for
example to other trader terminal or to back office systems to
produce deal tickets. The deal stack is also responsible for
changing the functionality of the buttons on the button bar and the
keyboard menus which are all deal status dependent.
[0573] It will be noted from the above that the activity of the
parser in the deal process is limited to detecting changes in deal
status. This enables the system to be more flexible. This contrasts
with prior art systems which operate by a rigid exchange of
conversational messages in which only one trader can "own" the
cursor to a conversation at any one time. In the system described
any party to a deal can enter conversations into the system at any
time. However, if the conversation does not include terms which the
parser is pre-programmed to recognise a deal related in that deal
status, the conversation will not affect the deal process. Thus,
the conversation does not have to ping pong from one party to the
other. At any stage in the deal making process, the last party to
send a conversational message can send a further message. If this
does not contain content relevant to the deal in its present status
it will be ignored by the parser and will not affect the deal.
[0574] Many modifications to the system described are possible
within the scope of the invention. In particular the invention is
not limited to any particular type of instruments, not to any type
of trading system architecture beyond the limitations of the claims
appended hereto.
* * * * *