EP1421532A2 - Systeme d'echanges interactif - Google Patents

Systeme d'echanges interactif

Info

Publication number
EP1421532A2
EP1421532A2 EP02756763A EP02756763A EP1421532A2 EP 1421532 A2 EP1421532 A2 EP 1421532A2 EP 02756763 A EP02756763 A EP 02756763A EP 02756763 A EP02756763 A EP 02756763A EP 1421532 A2 EP1421532 A2 EP 1421532A2
Authority
EP
European Patent Office
Prior art keywords
deal
conversational
quote
trader
parser
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP02756763A
Other languages
German (de)
English (en)
Other versions
EP1421532A4 (fr
Inventor
Rajiv Ajitsaria
Dunayev Kirill
Andrew P. Foray
Peter Richard Horsfall
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
EBS Group Ltd
Original Assignee
Electronic Broking Services Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Electronic Broking Services Ltd filed Critical Electronic Broking Services Ltd
Publication of EP1421532A2 publication Critical patent/EP1421532A2/fr
Publication of EP1421532A4 publication Critical patent/EP1421532A4/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/75—Indicating network or usage conditions on the user display
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Definitions

  • 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.
  • Reuters pic operates a conversational dealing system under the trademark REUTERS DEALING 2000/1.
  • 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.
  • 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.
  • a first aspect of the invention resides in the use of parsing to detect terms in conversation which indicate a change in deal status. More specifically, there is provided a conversational dealing system for trading instruments between counterparties, comprising: a pluraUty 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 pluraUty 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.
  • Embodiments of this aspect of the invention have the advantage that parsing of conversations is greatly simplified.
  • the parser needs to detect changes in status between one of only a few possible deal statuses.
  • a change of status has been detected there is only a Umited number of terms of deal related information that are relevant to that status making parsing very simple.
  • 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
  • DOC counterparties comprising: a pluraUty 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.
  • 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.
  • a third aspect of the invention enables the user to view and alter parsed messages before they are sent to the counterparty.
  • a conversational dealing system for trading instruments between counterparties comprising: a pluraUty 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.
  • 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.
  • a conversational dealing system for trading instruments between counterparties comprising: a pluraUty 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.
  • 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
  • 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.
  • conversational dealing system for trading instruments between counterparties, comprising: a pluraUty 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; whereiri 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.
  • 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.
  • a level of filtering of parsed messages is introduced between trader terminals. This aUows parsed messages to
  • T4F01I DOC be checked to ensure that they conform to the business or operating rules of the system.
  • a conversational dealing system for trading instruments between counterparties comprising: a pluraUty 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 acceptabiUty 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.
  • This aspect of the invention has the advantage that iUegal deals can be filtered out without a deal being agreed on by the parties.
  • 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. If the parsed message is rejected as unaUowable, 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.
  • a conversational dealing system for trading instruments between counterparties comprising: a pluraUty 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.
  • 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.
  • warning messages, error or danger messages are each shown in a further colour.
  • This aspect of the invention has the advantage of making the user display much more intelUgible. 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.
  • FIG. 37743 v1 T4F011 DOC Figure 3 is a view of the user interface of a trader Terminal, according to a first embodiment of the invention.
  • Figure 4 is a sirr ⁇ lar view to figure 3 showing a number of conversation panels
  • Figure 5 is a view of a deal stack within the user interface and showing the deal detail panel
  • Figure 6 is a further view of the deal stack and deal detaU panel with a different deal highUghted in the deal detail panel from figure 5;
  • Figure 7 is a further view of the deal stack showing a deal detail panel for a completed Forwards deal
  • Figure 8 is a further view of the deal stack showing the deal detail panel displaying an error box
  • Figure 9 is a stiU further view of the deal stack showing the deal detaU panel displaying potentiaUy modifiable fields highUghted;
  • Figure 10 shows the deal stack with the deal detail panel showing a completed F/X Spot deal including the value of the done deal;
  • Figure 11 shows the deal stack with the deal detail panel showing a forward deal with a Spot Rate Query message
  • Figure 12 shows how the Spot rate query message of figure 11 appears at the counterparty's deal detaU panel as a warning message.
  • Figure 13 is a flow chart showing an overview of the parsing process
  • Figure 14a and 14b are flow charts showing the parsing process in more detaU;
  • Figure 15 is a screen shot of a second embodiment of the user interface showing a parsed message entered by the maker
  • Figure 16 shows the screen of Figure 15 when d e parsed message has been sent but not picked up;
  • Figure 17 shows the taker's interface when die parsed message is received
  • Figure 18 shows the taker's interface when the system is waiting for the taker to quote
  • Figure 22 shows a further example of warning messages.
  • the system iUustrated schematicaUy in figure 1 is a conversational dealing system for trading a variety of financial instruments. Instruments which may be traded include, but are not Umited to, foreign exchange (F/X) spot, forwards, and outrights. Although the foUowing description wiU concentrate on F/X spot and forwards, it is to be understood that this is purely for the purposes of iUustrating the invention and that the invention is not Umited to any particular financial instruments or even to financial instruments. It is equaUy appUcable to the trading of any other fungible such as commodities, metals, etc.
  • F/X foreign exchange
  • the iUustrative 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 automaticaUy 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.
  • d e system also aUows users to deal by a simple exchange of deal content data which is non-conversational and by a mixture of the two methods.
  • the foUowing 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 d e invention.
  • the invention is not Umited to any particular trading system but is applicable to any system in which a trader is trading multiple instruments. Such
  • T4F01l DOC a system may be internet based or operate on a conventional pubUc or private network. It may use a distributed architecture or operate using a central host or may be configured in any other manner.
  • a trading system 10 disclosed is based on a pluraUty 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 directiy by the trader or through parsed conversation exchanged between traders, as wiU be described. Parsing takes place at the trader terminals.
  • FIG. 2 shows the user terminals 16, as weU as one server farm, schematicaUy.
  • Each cUent terminal 16 has three logical components: a user interface 20, a communications module 22 and a parser 24.
  • the cUent terminals are typicaUy 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.
  • 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 Figure 1.
  • the communications module may, for example, be a modem at the trader terminal or client local area network, or some other suitable device.
  • the parser 24 performs an analysis of conversations exchanged between trader terminal and extracts deal related information from those conversational
  • the functional components of the system are preferably downloaded to the trader terminals as an applet each time a trader logs on to the system. This means that the cUent terminal does not have to store any software in order to access and run the system, aU 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.
  • the system is intended to trade very large amounts of currency and currency products, as weU as other fungibles, and, in practice, is restricted to banks and other institutions of proven credit worthiness. Nevertheless, the portabiUty and flexibility of the system is advantageous to traders and is not ava able in prior art conversational dealing systems in which access is limited to a proprietary network.
  • the sever 26 includes a deal server 28 and a chat server 30. These form a part of the server farm of figure 1.
  • the deal server acts to verify the details of proposed deals against business and banking rules and aUows 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 abiUty to settle the trade they are proposing.
  • the chat server 60 handles the exchange of conversations between cUents on the network. As wiU be discussed, conversational messages, which may or may not contain deal related information, are passed between cUents via the chat server. A cUent can participate in several conversations at any given time and can conduct several different conversations with a particular other different cUent simultaneously, aUowing two parties to have two or more deals under negotiation at die same time.
  • Figure 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 d e display 100 includes
  • T4F01I DOC 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.
  • the upper container only displays panels which require the fuU 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.
  • a deal stack 110 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 mcoming conversations panel 114 in which incoming conversational messages are displayed.
  • the mcoming messages include conversations in which the trader is not yet participating, and may never, participate.
  • the optional panels which the trader may choose to display include: A Trader Deal panel (not shown), assigned a priority 1 and showing aU the deals done by the trader and which may be displayed in either of the two lower containers;
  • An Overview panel (not shown), assigned a priority 1 and positioned in either of the two lower containers;
  • 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 d e current trading rates on the system for various currency pairs and which is assigned a priority 2;
  • a Conversation Archive (not shown) positioned in one of the lower containers and which has a priority 2.
  • T4F01I DOC As can be seen from figure 4, some of the panels include a button bar along their lower edge. The various functions of the buttons wiU be discussed below.
  • the conversation panels button bars include a float button. CUcking 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 cUent 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 wiU be appreciated that this is an arbitrary number which may be varied.
  • the mcoming conversations panel Usts only incoming conversational messages. In the example of figure 3, there is a single conversation displayed.
  • the cUent 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.
  • 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
  • Message which is the latest message line in the conversation.
  • 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.
  • a Deallnfo 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 Deallnfo structure also includes the current status of the deal. Central to the manner in which conversations are parsed is the concept of a deal be g in one of a number of states indicating how far d e deal has progressed. In essence, d ese states begin with No State, which relates to conversation with no deal related information; RFQ which is die state in which a request for a quote has been identified by die parser; Quote, in which a quote has been identified by the parser in response to
  • T4F01I DOC the RFQ; and Buy/SeU in which the deal is completed by one party agreeing to buy or seU at the price quoted.
  • the Incoming Conversations panel is a button bar with buttons marked 'Pick Up', 'Clear', 'Transfer' and 'Chat'.
  • the cUent dicks on the conversations line, which wiU 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).
  • the cUent clicks on the 'Pick Up' button a Conversation panel is opened in the bottom left container 104 for the selected conversation (Fig. 4).
  • the system causes aU other parties to whom the conversational message has been sent to display the message 'username has joined the conversation'.
  • a party joins a conversation they see that conversation only from the point at which they joined it.
  • a first person has picked up an invitation to chat to a deal code, that invitation wiU be withdrawn from aU other parties to which the invitation was sent.
  • the 'Clear' button when cUcked, causes the selected conversation to be cleared from the display.
  • the conversation initiator wiU receive a 'Conversation declined by username' in their own Conversations panel.
  • the 'Transfer' button is only enabled if a conversation is bUateral. If cUcked, the conversation wiU be transferred to the trader or Deal Code specified in the Transfer Conversation dialog. Rules may be estabUshed defining to whom, if anyone, a given trader may transfer a conversation.
  • the 'Chat' button invokes die launching of a conversation session and also opens a conversation panel in the conversation area. Multiple conversations may be opened with die same person, aldiough a warning box will preferably be displayed to notify the cUent if he is attempting to open a second or subsequent conversation wid the same person.
  • T4F01I DOC AU the functionaUty of the button bar may be displayed, alternatively, as a drop down menu to enable operation by keyboard only.
  • the Deal stack 130 shows a Ust of deals in which the trader is involved in and which are pending or completed.
  • the Deal Stack 130 comprises the foUowing major components:
  • the deal Ust 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 Ust 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 a ows the deal stack to be presented to the cUent in a very simple manner, with the minimum amount of information and in a manner which is easUy assirrnlated by the trader.
  • Deal information may be submitted to the system in one of two ways: direct deal put or parsing of conversations. Parsing of conversations wiU be discussed in greater detaU 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 Ust.
  • 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 d e deal list in figure 3 shows an RFQ.
  • the trader has put a request out to d e market to trade $2.5 MiUion in the US$/Canadian doUar market.
  • no bid or offer prices are given and there is no indication whedier 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.
  • 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.
  • the system determines the text that wiU be displayed in the deal Ust. This wiU either be a transUteration of the direct RFQ or a representation of the parsed, indirect RFQ.
  • 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.
  • deal statuses for F/X Spot are as foUows:
  • the Deal Strings and Status Strings associated with some of the above are as foUows: 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.
  • the RFQ wiU have originated from a conversation. In others it wiU 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 specificaUy requested by the trader.
  • 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 wiU parse and produce the same action on the deal.
  • the Message wiU be in a form that reflects the best conversational practice from the point of view of parsing.
  • the Deal List displays aU Uve RFQs that the trader is involved with. He may see other RFQs if the appropriate options are set.
  • the Trader wiU preferably have the option of clearing completed deals automaticaUy as tiiey are completed.
  • the Trader wiU preferably have the option of seeing aU RFQs that have been auto-forwarded from his account. Auto-forwarded RFQs shaU be cleared from the Deal List by the Clear function.
  • the Deal List is wholly independent of the instrument being traded.
  • the Deal List only displays five columns: Status,
  • the Deal column contains an instrument/status specific string that is generated by the system to describe the deal.
  • the Deal DetaU Panel 134 at the bottom of the Deal List has an instrument specific format and reflects full detaUs of the deal that is currentiy selected in the Ust.
  • the selected deal does not change. If focus is in the Deal List, the currendy selected item does not change when a new deal is added to the Ust. If a new deal is added to the Deal Stack such that the Deal Stack would have to be scroUed to view the deal, then the scroUbar's background flashes, for example red, until the deal is made visible by scrolling.
  • the Deal Detail panel may contain buttons and other controls that relate to instrument specific functionaUty which is not avaUable through the standard Deal Stack buttons.
  • a deal is in a modifiable state the modification is done via edit controls in the Deal Detail panel.
  • These potentiaUy modifiable fields shaU have a different colour, for example, cyan, background to the rest of the deal Detail panel.
  • the deal detaU panel itself may be a different colour, for example yeUow, than d e deal list.
  • the fields When the fields are editable they may be distinguished, for example by a white background with a black border.
  • the Deal DetaU panel 134 includes aU the information in the Deal Ust 132 except that instead of the deal Ust 132 it contains the information which, when entered and then parsed, wiU result in that deal Ust 132.
  • the Deal DetaU panel includes Amount, Currency Pair, Value Date, Bid and Offer prices and Dealt.
  • 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 Ust 132.
  • the deal highUghted is the third in the Ust 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 milUon Japanese Yen. As the amount and the prices can both be edited, they appear in the Deal DetaU panel as black text on a white background.
  • Figure 7 shows the Deal DetaU panel for a Forward deal.
  • the panel Usts both near and far amounts, the currency, the nature of both the near and far deals, riieir value dates, the left and right hand sides, spot ( Figure 5) amounts, all in amounts and deal amounts.
  • die panel relates to the fourth deal in the list which is a completed deal.
  • aU die fields in the deal detaU panel are populated and none is modifiable.
  • 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 Ust for every error or warning condition associated wid
  • Figure 8 shows an example of the error box.
  • the highUghted deal is the third in the deal Ust. 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.
  • the Quote? Status string is highUghted in red and the bid and offer fields which would normaUy be shown white.
  • Figure 9 shows the deal detaU panel for a deal that is waiting acceptance.
  • 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 detaUs are highlighted to indicate that they can be modified.
  • the Status, Time, Trader/Bank, and Instrument column entries are positioned on the Deal DetaU panel exacdy beneath their respective columns in the Deal List. If the columns are resized, their relative positions wUl also change.
  • the Error/Warning combo box and its associated count label wUl preferably automaticaUy have its width set to that of the Status, Time, Trader/Bank and Instrument columns combined.
  • the instrument specific fields beneadi the Deal column wUl resize and position themselves proportionally to the widtii of die Deal column.
  • T4F01' DOC The amount field is initiaUy read only and displays the amount of the RFQ in miUions. When the deal reaches the pre quote-maker stage (figure 6), the field becomes editable.
  • 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
  • the currency pair field simply shows the currency pair being traded.
  • 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.
  • 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 figure 6. If a big figure, that is the most significant digits of the price is avaUable 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 cUent may choose to display.
  • the final field is the dealt price field which shows the price at which the deal was done. As can be seen from figure 10, this reflects the side (buy or seU) on which the deal was done. In figure 10, the dealt price is the bid price.
  • 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.
  • 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 seU/buy or buy/seU at a given rate) status. In edit mode, the field is pre- populated with a middle rate between the bid and offer market rates.
  • the deal detaU panel includes a Spot button on which the cUent can cUck 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.
  • the dialog box includes send and cancel buttons. The send button closes the
  • DOC box transmits the message and changes the deal status to I S/B awaiting rate or I B/S awaiting rate.
  • AU 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 aU in rate.
  • Dealt Rate This is the final field in the deal detaU panel and is a read only field. When the taker has Buy/SeU or SeU/Buy, the field reflects the price from the side of the market dealt on.
  • the fields for the deal detaU panel when the instruments is an outright are not shown as they are the same as for a spot deal referred to above.
  • the deal column displays different status dependent strings for each instrument. Some of these, for spot, were discussed earUer.
  • the strings are not hard coded into the system but are configurable centraUy by the system administrator. The traders preferably do not have control over the strings.
  • the status definitions comprise tokens, deUmited by tildes ( ⁇ ) representing the underlying values for the deal.
  • the third part of d e deal stack 130 is the button bar 136 which is beneath d e deal list 132 and the deal detaU 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 wiU depend on d e deal which is selected in the deal stack. Some options wUl not be avaUable to a trader at certain stages of die deal as wiU be explained.
  • buttons are not displayed in bold, indicating that they are not avaUable. In some cases, buttons are substituted. As examples of the latter, the pickup button in figure 5 is replaced by a quote button in figure 6. The cancel button of figure 5 is replaced by the None button in figure 6.
  • the button bar provides the trader with an alternative, but equaUy va d 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 Ust deal field.
  • buttons avaUable to traders are as foUows:
  • 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 wiU be removed from the deal Usts of aU other recipients. Quote (e.g. fig 6).
  • the system transmits to the taker the makers bid and/or offer together with an amount.
  • the system transmits to the taker the maker's LHS points and/or RHS points together with near and far amounts.
  • the first button in the button bar combines aU default actions.
  • d e button wiU revert to pickup but be grayed out for deal statuses otiier than those mentioned above. For forwards, more options are available.
  • the button 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)
  • the button is displayed as a spot button which aUows the Taker to accept the makers proposed spot rate. Chat.
  • This button which is only avaUable 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 wiU show a deparsed version of conversation that would have led to that deal state.
  • 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 wUl 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.
  • SeU This button is only enabled for instruments such as Spot or Outrights. It provides a means for a taker to SeU at the Makers bid price and so is only enabled in the Pre BuySeU status when there is a bid from the maker. RFQ. This button enables a Maker to put out a request for a quote to the market. When this button is pressed, die maker has to supply the amount
  • the RFQ button converts to the caption FLX when the RFQ has been initiated by conversational parsing on the Taker side and is awaiting confirmation for accuracy by the taker
  • This button enables a trader to initiate a caUout.
  • This button is only enabled when a selected deal for an instrument such as a Spot or an Outright is in the Pre Buy/SeU - 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.
  • Cancel This is a mmtifunction button whose caption wUl depend on the deal status and the instrument being traded in the selected deal. It is used for aU negative functions.
  • the functions wiU vary from instrument to instrument but for Spot are as foUows:
  • the cancel action cancels the existing deal stage, reverting it to a preceding deal stage.
  • the None 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.
  • the system provides a set up pop up menus which provide the same functionaUty as the button bar but which can aU be invoked from the keyboard.
  • Each function can be invoked by the same keyboard character in each menu. Examples of the characters that can be assigned to functions are:
  • 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, aU 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 foUowing description wiU consider the foreign exchange markets and, in particular, the three instruments discussed above: FX Spot, FX Outrights and FX Futures.
  • die parser monitors the conversations looking for an RFQ (Request for a Quote).
  • RFQ Request for a Quote
  • DOC RFQ alerts the parser that a new deal is being initiated.
  • the parser wiU 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.
  • a new conversation has been initiated by a cUent referred to as CUent 1 and shown in figure 15 as kdunay@EBSN.
  • This user has typed a message into his Chat panel and hit the return key.
  • This causes the User Interface ( Figure 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.
  • the parser has detected an RFQ in the line of chat. That line, although not shown may have been T 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 DoUars/Japanese Yen, and the amount, here 1 MiUion.
  • the Parser returns the parsed conversation to the User Interface in the form of the Deallnfo structure referred to earUer and which contains the Deal Status and the deal related information.
  • Figure 15 shows the situation were the Deallnfo 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 canceUed 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 die conversation so that it is reparsed.
  • the Status of the Une in the deal stack is preferably shown in a representative colour, for example green.
  • the button 206 on d e 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
  • T4F01' DOC representative colour, for example red, to show that it is system generated text.
  • a system message 'Submit?' is also displayed, in red, in the conversation panel.
  • the deal stack of figure 15 differs from that of the earUer example in that it includes a strip 210 above the button bar which displays to the user, significant information about a highUghted deal.
  • 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 seU rates. These latter rates are displayed in boxes 212, 214 which are unfiUed in figure 15 as no rate has yet been quoted in this deal.
  • the Une of conversation parsed resulted in a detected deal status.
  • the Une 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 stiU send a response to the User Interface to indicate that a Une of conversation had been parsed, but no dealing information had been found.
  • the parser parses the conversation Une by Une 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 Une by Une 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 d e market, or simply to correct errors, without disclosing his hand to the counte ⁇ arty 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. Second, the parser plays no part in die deal making process and retains no
  • the parser merely looks at the line of conversation for information relating to the deal status. It returns the Deallnfo structure to the User Interface and does not retain any knowledge of the deal. This makes the parser very simple.
  • 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/SeU although these are elaborated as wUl 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.
  • the conversation parsed by the parser contained both a change in deal status and aU the information that is required to accompany that detected status (instrument, currency pair, etc.).
  • the parser wiU recognize as indicating a change in status. For example, if the new conversation includes a request for a quote, the parser wiU look for information which indicates a quote. It wiU parse the entire Une and, for a given status wiU look to fill a predetermined number of information fields. These will vary depending on the status.
  • the parser when the parser is expecting a change in status from RFQ to Quote, it will look to see whether tiiere 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 d e currency, in the case of an FX spot trade.
  • the states of the deals and the fields required will vary depending on the instrument
  • the parser returns to the user interface one of three possibiUties: a) there is nothing in the conversation that is parseable. This wiU be the case is the conversation does not include any deal related information; b) an update in the deal structure which includes the new deal status and the fields found; 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. Reverting back to the parsed conversation message. From the cUent'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.
  • This abiUty to conceal faUed deals is advantageous as a user wiU often not want a counte ⁇ arty to know that he has tried to deal with him but faUed. He wiU also not want that counte ⁇ arty to know the detaUs of the attempted deal as it wiU disclose to him valuable information about his intentions and his reading of the market. This advantage stems from the manner in which d e system parses conversations on a line by Une basis rather tiian in real time as d ey are typed in character by character.
  • the parsed message is sent to die 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
  • FIG. 16 shows the user interface after the RFQ has been sent to the counte ⁇ arty.
  • 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 counte ⁇ arty has picked up the deal from his incoming conversations panel.
  • the cUent's conversation is now shown in a representative colour, for example green, to show that the message originated from the cUent.
  • FIG 17 there is shown the user interface of the cUent to whom the RFQ described in figure 14 has been sent.
  • the cUent is identified as test@EBSN.
  • the RFQ message has been passed by the deal server and relayed to cUent test@EBSN.
  • the sending cUent User Interface has also been notified that the message has been sent.
  • the incoming message wiU first appear in the cUent's incoming messages panel.
  • cUent test@EBSN has doubled cUcked 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 counte ⁇ arty, kdunay@EBSN identified.
  • the system indicates in the conversation panel that cUent test@EBSN has joined the conversation and displays the parsed message in the deal stack.
  • the message is identified as Quote 1 mU JPY usd/JPY? which is an embeUished version of the parsed message displayed in the maker cUent's deal stack.
  • the original version of the message is shown in d e 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.
  • d e status of the deal is shown as 'pickup' and coloured green indicating diat action is required by the client.
  • the client has to respond to the RFQ.
  • the second cUent, test@EBSN then types in his response to the RFQ in
  • T4F01' DOC the chat Une 220 of the conversation panel and hits the send button 222.
  • this causes the User Interface to send the complete line of text to the parser which again parses the text and sends back the Deallnfo 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 counte ⁇ arty.
  • the parser for cUent kdunay@EBSN only parses conversation entered by that cUent and the parser at cUent test@EBSN only parses conversation entered by that cUent.
  • Figure 18 shows the counte ⁇ arty cUent 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 foUowed by a question mark.
  • the chat Une of the conversation panel invites the user to proceed.
  • 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 unavaUable'. In this case d e message is false and was generated as the rates panel was disabled but serves to iUustrate how warnings can be shown.
  • Figure 19 shows cUent kdunay@EBSN's user interface when the response is received.
  • CUent test@EBSN has submitted a quote in response to the RFQ shown as 123.33/123.45.
  • These figures are the buy/seU 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 cUent's own conversation. This is shown in a representative colour, for example green.
  • the deal stack shows the change in Status to Buy/SeU, highUghting the status in green. This shows that action is required by the cUent and that the next phase of the deal is either an agreement to buy and seU at the offer price or a denial.
  • the parser No matter what the status of a deal, the parser always looks for new RFQs and, if one is detected, opens a new conversation.
  • the cUent kdunay@EBSN could have put in a new request such as T want 1 mU gpb' indicating that he wants to buy one milUon £SterUng 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 abiUty 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 counte ⁇ arties, for example 10. This should not be confused with the abUity to have a number of conversations open with different counte ⁇ arties at the same time which is known in the art and also possible with the system embodying the invention.
  • the above discussion Ulustrates how the system handles a conversation input by die user. In the course of a deal there will be several lines of conversation, with each handled in d e manner discussed. As soon as a parser has passed on the deal structure and d e 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.
  • Figures 21 and 22 illustrate two furdier aspects of die parser.
  • figure 21 it can be seen d at 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.
  • the two conversations are shown at 224 and 226 in the deal stack and as conversations 1 and 2 in the conversation panel.
  • Figure 22 gives another example of the warning message.
  • the situation iUustrated is a development of the second conversation of figure 21.
  • a quote amount has now been entered but the system is again indicating that the big figure is unavaUable and so highUghts the status in orange.
  • the second deal Une in the deal stack is also showing a warning as the deal has been withdrawn by one of the parties.
  • Figure 13 shows an overview of the process described.
  • 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®.
  • 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 d e message. If it cannot be parsed, the conversational message is sent to the chat server at 430 and then to
  • a message that cannot be parsed is one that has no deal related content.
  • 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.
  • step 470 the parser determines whether or not parsing is complete. If it is not, the cUent is asked to complete the information at step 480.
  • step 490 the deal information file is updated and, at step 500, the parsing results are displayed at the user interface.
  • the trader must then decide whether or not they want to proceed and send the parsed message to the counte ⁇ arty (at 510).
  • the confirmation stage is performed by the proceed, edit and cancel buttons on the deal panel described previously.
  • the edit function is not shown. If the trader does not want to proceed, the deal is canceUed at step 520 without having been shown to the counte ⁇ arty. If the trader does want to proceed, at 530 the parsed message is sent to the deal se ver 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 counte ⁇ arty 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.
  • a general FX terminology module provides an indication of d e common terminology used by dealers to deal FX via the Chat panel on the Trader platform.
  • the system monitors all conversations conducted via d e chat panel and mterprets text from the conversations into a fixed format withm the deal stack,
  • 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 seU, and any notice of special settlement instructions.
  • the system can distinguish terms within a conversation that could lead to ambiguity as to deal detaUs or whether a deal is in progress at aU. For instance, dealers may be discussing a previous trade or providing indicative quotes internaUy.
  • Chat Terminology - Common Deal Terms provides the Ust of terms and variables that are direcdy pertinent to an FX deal being completed and should be parsed by the system.
  • T4F01I DOC Chat-Terminology - Unrecognized Terms describes how the system should treat terms/phrases it does not recognize within the chat conversation.
  • the system can recognize aU 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 deUver the data to the corresponding fields within the deal stack.
  • 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.
  • 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:
  • NZD NZD/USD
  • GBP GBP/USD
  • the system permits d e user to enter a complete currency pair, i.e. reference to bod currencies, in the foUowing formats:
  • the system shaU inte ⁇ ret the amount as being expressed in millions. For example:
  • CHF in 20 USD/CHF for 20 miUion USD
  • GBP in 500k GBP/USD for 500,000 GBP
  • the system permits the user to specify a two-way quote in any of the foUowing formats: bid quote/offer quote bid quote-offer quote bid quote offer quote bid quote* offer quote
  • the user may specify a one-way bid quote in any of the foUowing formats:
  • the user may specify a one-way offer quote in any of the following formats:
  • 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 diat indicate diat the current conversation in which the dealers are engaged, does not pertain to a deal.
  • the dealer first 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
  • the chat panel is used for a variety of casual conversations that have no bearing on the dealing process. The system will ignore aU terms that do not conform to requirements of the Deal Use Case.
  • FX SPOT PARSING The FX Spot module provides the user with the abiUty to deal the FX
  • 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 Ust of terms and variables that are direcdy pertinent to a deal being completed and should be parsed by the system.
  • An FX Spot request for quote is sent by a taker to his maker(s).
  • the maker can either: provide a two way quote (bid and offer) in response to the RFQ - d is is only if an amount was indicated in the
  • DOC 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.
  • the taker receives a quote. In response he can either: indicate he wants to buy and confirm the deal; indicate he wants to seU and confirm the deal; or cancel the deal if the taker does not like the quote.
  • 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 currendy 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 foUowing terms that indicate a request for quote has been initiated within a chat panel conversation: An indication of the instrument type (FX Spot)
  • a request for quote includes at least an indication of the currency pair. Some examples are as foUows: hihi CHF pis - The taker is requesting a quote for USD/CHF hi CHF in 10 pis - The taker is requesting a quote for USD/CHF for 10 million USD
  • Hihi SPOT STG in 10 pis - The taker is requesting a quote for GBP/USD for 10 million GBP
  • the system parses aU variables indicated as part of an RFQ from the conversation to the appropriate field in the Deal stack.
  • the system monitors the chat panel for indications of a response to the request for quote.
  • the system watches for the foUowing terms within the chat 0 panel that indicate a response to the request for quote: indication of a bid quote indication of an offer quote indication of a refusal to quote an indication of an amount 5 an indication of the currency of the amount
  • a response to a request for quote includes an amount if one is not suppUed in the RFQ, together with at least one of the foUowing: a bid quote an offer quote » OR a refusal to quote
  • the maker provides a two way quote bid/offer 5 96/00 - the maker provides a two way quote bid/offer
  • the currency pair The amount
  • a bid and/or an offer A bid and/or an offer
  • 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.
  • the system watches for the following terms within the chat panel diat indicate a response to the quote: an indication to buy at the offer price an indication to sell at the bid price
  • a response to a quote includes at least one of the foUowing: an indication to buy at the offer price an indication to seU at the bid price an indication of a canceUation of the deal
  • the system can recognize all phrases and terms used within a conversation d at are pertinent to the completion of the deal.
  • 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.
  • the system permits the user to enter the term "spot" to indicate that the deal is a FX Spot deal. For example:
  • 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:
  • CHF for 20 FX Spot deal for USD/CHF, amount is 20 miUion USD
  • the system permits the user to specify an amount of currency to buy or sell. For example:
  • the system permits the user to enter a quote without the big figure, i.e. only the pips of the quote. For example:
  • the system warns the user if there is no big figure avaUable.
  • the system permits the user to indicate his preference to buy the stated amount of currency by using the foUowing terms:
  • the system permits the user to indicate his preference to seU die stated amount of currency by using the foUowing terms:
  • the system permits the taker to indicate his intention to buy or seU. For example:
  • FX OUTRIGHTS The parsing requirements for FX outrights are simUar to those described for FX Spot.
  • the foUowing is a description of the process foUowed to complete an FX Outright deal
  • An FX Outright request for quote is sent by a taker to his maker(s).
  • 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 die RFQ - this is only if an amount was indicated in the RFQ; provide a quote for a particular amount in response to die RFQ; or indicate that he does not want to supply a quote, no deal takes place.
  • T4F01I.DOC The taker receives a quote. In response he can either: indicate he wants to buy and confirms the deal; indicate he wants to seU and confirms the deal; cancel the deal B the taker does not like the quote.
  • the deal is now complete.
  • 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 currendy in progress within a chat panel, the system monitors the chat panel for indications of a request for quote. The foUowing terms that indicate a request for quote has been initiated within a chat panel conversation are watched for:
  • a request for quote should include at least the foUowing:
  • Some examples of a request for quote hihi Outrite 3 m CHF pis -
  • the taker is requesting a quote for an FX Outright for USD/CHF maturing in 3 months * ⁇ hi Out 10 mio CHF 6m pis -
  • the taker is requesting a quote for an FX Outright in USD/CHF for 10 million USD maturing in 6 months
  • the system parses aU 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. 0 The foUowing terms within the chat panel that indicate a response to the request for quote are watched for: indication of a bid quote indication of an offer quote indication of a refusal to quote 5 an indication of an amount
  • a response to a request for quote includes an amount (if not suppUed in the RFQ) together with at least one of the foUowing: a bid quote an offer quote ° OR a refusal to quote
  • the maker provides a two way quote bid/offer 5 0.87563-62 - the maker provides a two way quote bid/offer
  • AU 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.
  • the system concludes that the deal has been canceUed, and the monitoring process is restarted, looking for a request for quote within the conversation.
  • the system ensures that the foUowing variables have been parsed from the conversation to the deal stack prior to permit the taker to indicate his intention to buy or seU:
  • a bid and/or an offer A bid and/or an offer
  • 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 d e chat panel for a response to die quote. The following terms are watched for witiiin the chat panel that indicate a response to the quote: an indication to buy an indication to sell
  • a response to a quote includes at least one of the foUowing: an indication to buy an indication to seU an indication of a canceUation of the deal
  • a canceUation 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.
  • the system requires the user to enter one of the foUowing terms to indicate that the deal is a FX Outright deal:
  • the user is permitted to specify an amount of currency to buy or seU, for example:
  • the system shaU permit the user to express a maturity date (the terms "value date” or "setdement 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 direcdy to represent die offer quote for an FX Outright.
  • the user may
  • bid quote 121.43/53
  • offer quote 121.43
  • the user may enter a quote without the big figure, i.e. only the pips of the quote. For example:
  • the user is warned by the system if there is no big figure avaUable.
  • the user may indicate his preference to buy the stated amount of currency at the forward date by using the foUowing terms:
  • the user can indicate his preference to seU the stated amount of currency at the forward date by usmg the following terms:
  • the system permits the taker to indicate his intention to buy or seU. For example:
  • Y User seUs previously indicated amount in previously indicated currency.
  • the foUowing is a description of the process foUowed to complete an FX Forward deal:
  • An FX Forward request for quote is sent by a taker to his maker(s)
  • 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 mdicated 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.
  • the taker receives a quote. In response he can either: indicate he wants to seU at near date/buy at far date and confirms the deal; indicate he wants to buy at near date/seU at far date and confirms the deal; or cancel the deal B the taker does not like the quote.
  • the maker (maker of the deal) receives notification of the taker's intent.
  • the taker receives the Spot rate. In response he can either: confirm the deal; or query 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.
  • 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 wiU ever get a satisfactory (only avaUable if queried once already) . Once the Taker confirms the Deal it is now complete.
  • 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 currendy in progress within a chat panel, the system monitors the chat panel for indications of a request for quote. The system watches for the foUowing terms that indicate a request for quote has been initiated within a chat panel conversation:
  • An indication of an amount for the near period An indication of an amount for the far period
  • An indication of duration/forward date for maturity date should include at least the foUowing: an indication of the currency pair An indication of the instrument type
  • Some examples of a request for quote are as foUows: hihi Fwd 3m CHF pis -
  • the taker is requesting a quote for an FX Forward for USD/CHF Value date is Spot date maturing in 3 months hi Swap 10 mio CHF s/n pis -
  • 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)
  • Hihi Forward cable in 10 maturity 5 Jan 01 pis - 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 th of fanuary 2001
  • 37743 V1 T4F01I DOC 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 foUowing terms within the chat panel that indicate a response to the request for quote:
  • a response to a request for quote includes an amount (if not suppUed in the RFQ) together with at least one of the foUowing: a bid quote an offer quote
  • the maker provides a two way quote, bid/offer
  • the maker provides a two way quote bid/offer 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.
  • the system parses all variables indicated by the maker in the response to a request for quote, from die conversation to d e appropriate fields in d e Deal
  • 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 canceUed. 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 foUowing variables have been parsed from the conversation to the deal stack prior to permitting the taker to indicate his intention to buy or seU:
  • the currency pair A Near amount
  • a bid and/or an offer A bid and/or an offer
  • the system requests that d e 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.
  • the system watches for the foUowing terms within the chat panel that indicate a response to the quote: an mdication to buy/seU (base currency) at the LHS (Left Hand Side) price an indication to seU/buy (base currency) at the RHS (Right Hand Side) price an indication to buy/seU (foreign currency) at the RHS price an indication to sell/buy (foreign currency) at d e LHS price
  • a response to a quote shaU include at least one of the foUowing: an indication to buy/seU an indication to seU/buy
  • the system If the system has identified a provision of spot rate, and the rate has been sent to the taker, the system shaU monitor the chat panel for response to the Spot Rate.
  • the system watches for the foUowing terms within the chat panel that indicate a response to the Spot Rate: an indication of deal confirmation an indication of querying the Spot rate an indication of a canceUation of the deal (only if at least one rate has previously been provided)
  • Some examples of a querying the Spot rate are as foUows: check spot - terse minimum query check spot seems high - qualified query
  • the system shall return the entire Une that includes the querying of the Spot rate and use it as the text to a Spot Rate Query warning to the maker:
  • deal is complete 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, die
  • T4F01 I DOC system confirms the deal in the deal stack and re-starts its monitoring process and looks for a request for quote within the conversation.
  • the system requires the user to enter one of the foUowing terms to indicate that the deal is a FX Forward deal. Swap
  • the system permits the user to specify an amount of currency to buy or sell, for example:
  • the system inte ⁇ rets the amount to represent the amount in the base currency of the currency pair. For example:
  • 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 foUowing formats:
  • the system permits the user to express a duration for the deal as part of d e request for quote, and permits the user to express a maturity date in Ueu 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 d e two quotes as the offer quote.
  • 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.
  • 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 seU base currency on the first leg (near date) of the FX Forward.
  • 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 seU 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 wiU 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.
  • 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, die forward rate for d e currency pair is more d an then the near rate.
  • the system subtracts the offer quote points (on the
  • This rate represents the rate at which you seU 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. 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 seU 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.
  • 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.
  • 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. If neid er of die two legs of d e swap fall on Spot date, the system permits d e user to enter a value date bid quote in association with d e FX Forward and to enter a value date offer quote in association with d e FX Forward.
  • the system shaU inte ⁇ ret 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.
  • the user can indicate his preference to Buy the stated amount of currency at the near date and seU the stated amount of currency at the far date by using the foUowing terms: buy/seU buy seU b/s b s
  • the user can indicate his preference to seU the stated amount of currency at the near date and buy the stated amount of currency at the far date, by using the foUowing terms: seU/buy
  • the user can indicate his intention to buy/seU or seU/buy. For example:
  • the system permits the maker to supply the rate without the big figure.
  • the system warns the user if there is no market rate avaUable from which to derive the big figure.
  • 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 inte ⁇ ret 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 aU instruments from information specific to a deal in any particular instrument it is possible to present a deal Ust which is simple and easy to view.
  • the deal detaU 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.
  • the trader When trading on the system described, the trader has the choice of entering deal information dirough conversational chat which is parsed by the system or direcdy preferably us g buttons on the user interface or keyboard driven menus.
  • the trader can switch between die two during the progress of a
  • deal This flexibiUty 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.
  • AU 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 functionaUty of the buttons on the button bar and the keyboard menus which are aU deal status dependent.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Strategic Management (AREA)
  • Technology Law (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Machine Translation (AREA)

Abstract

L'invention concerne un système d'échanges interactif permettant à une pluralité d'instruments, par exemple des instruments financiers tels que des produits en devises étrangères, d'être échangés depuis une interface utilisateur unique. L'interface comprend un ensemble transaction composé d'une liste des transactions, d'un tableau de détail des transactions et d'une barre d'outils. La liste des transactions présente des informations relatives aux transactions, telles que leur état, la partie, l'instrument, ainsi qu'une chaîne relative à l'instrument et à l'état, sous une forme commune à tous les instruments. Lors de la détection de chaque nouvelle demande de proposition de prix, un nouveau dialogue est entamé. Ce dernier peut se faire avec la même partie qu'un dialogue existant. Le dialogue est analysé ligne par ligne, et l'utilisateur peut le modifier avant de l'envoyer à l'autre partie. L'analyseur ne conserve aucune sauvegarde de la transaction, et peut, à l'instar de l'interface, être téléchargé sous forme d'applet.
EP02756763A 2001-07-30 2002-07-30 Systeme d'echanges interactif Withdrawn EP1421532A4 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US30861801P 2001-07-30 2001-07-30
US308618P 2001-07-30
PCT/US2002/024021 WO2003012588A2 (fr) 2001-07-30 2002-07-30 Systeme d'echanges interactif

Publications (2)

Publication Number Publication Date
EP1421532A2 true EP1421532A2 (fr) 2004-05-26
EP1421532A4 EP1421532A4 (fr) 2009-11-18

Family

ID=23194696

Family Applications (1)

Application Number Title Priority Date Filing Date
EP02756763A Withdrawn EP1421532A4 (fr) 2001-07-30 2002-07-30 Systeme d'echanges interactif

Country Status (5)

Country Link
EP (1) EP1421532A4 (fr)
JP (1) JP2004537797A (fr)
DE (1) DE10296837T5 (fr)
GB (1) GB2387698A (fr)
WO (1) WO2003012588A2 (fr)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1697816A4 (fr) * 2003-11-26 2008-12-17 Fx Alliance Llc Systeme et procedes de negociation d'elements actifs independants du protocole
US20050228739A1 (en) * 2004-04-08 2005-10-13 Hotspot Fx Inc. Financial instrument trading system, method and computer program product
US7567928B1 (en) 2005-09-12 2009-07-28 Jpmorgan Chase Bank, N.A. Total fair value swap
US9830634B2 (en) 2006-02-23 2017-11-28 International Business Machines Corporation Performing secure financial transactions in an instant messaging environment
US7620578B1 (en) 2006-05-01 2009-11-17 Jpmorgan Chase Bank, N.A. Volatility derivative financial product
US9811868B1 (en) 2006-08-29 2017-11-07 Jpmorgan Chase Bank, N.A. Systems and methods for integrating a deal process
US8751403B2 (en) 2006-12-21 2014-06-10 Yellowjacket, Inc. Method and system for collecting and using market data from various sources
US11010767B2 (en) 2006-12-21 2021-05-18 Ice Data, Lp Method and system for collecting and parsing market data from various sources
WO2008083375A1 (fr) 2006-12-30 2008-07-10 Cfph, Llc Procédés et systèmes de gestion des relations clients
KR102281996B1 (ko) * 2019-05-16 2021-07-27 한국과학기술원 Sns를 통한 개인간 거래에서 상대방의 신뢰도를 측정하는 방법 및 시스템
JP6957816B1 (ja) * 2021-01-06 2021-11-02 アウル株式会社 プログラム、方法、情報処理装置、システム

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1997043727A1 (fr) * 1996-05-15 1997-11-20 Crossmar, Inc. Procede et systeme permettant d'executer des transactions financieres automatiques en devises etrangeres
WO1998056024A1 (fr) * 1997-06-05 1998-12-10 Crossmar, Inc. Traduction de messages du ou dans le format de securite swift
US5870745A (en) * 1996-09-26 1999-02-09 Mciworldcom, Inc. Automated system and method for processing and tracking requests and responses required for repetitive tasks
WO2001042971A2 (fr) * 1999-12-06 2001-06-14 Truexchange, Inc. Procede et appareil permettant d'effectuer des transactions sur le marche libre

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5003473A (en) * 1988-10-24 1991-03-26 Reuters Limited Trading ticket output system
US5258908A (en) * 1990-11-02 1993-11-02 Foreign Exchange Transaction Services, Inc. Detection and prevention of duplicate trading transactions over a communications network
WO2001045007A1 (fr) * 1999-12-06 2001-06-21 Bios Group Inc. Procede et systeme permettant de decouvrir des marches entre des parties

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1997043727A1 (fr) * 1996-05-15 1997-11-20 Crossmar, Inc. Procede et systeme permettant d'executer des transactions financieres automatiques en devises etrangeres
US5870745A (en) * 1996-09-26 1999-02-09 Mciworldcom, Inc. Automated system and method for processing and tracking requests and responses required for repetitive tasks
WO1998056024A1 (fr) * 1997-06-05 1998-12-10 Crossmar, Inc. Traduction de messages du ou dans le format de securite swift
WO2001042971A2 (fr) * 1999-12-06 2001-06-14 Truexchange, Inc. Procede et appareil permettant d'effectuer des transactions sur le marche libre

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of WO03012588A2 *

Also Published As

Publication number Publication date
GB2387698A (en) 2003-10-22
WO2003012588A2 (fr) 2003-02-13
WO2003012588A3 (fr) 2004-03-25
GB0317232D0 (en) 2003-08-27
EP1421532A4 (fr) 2009-11-18
DE10296837T5 (de) 2004-07-29
JP2004537797A (ja) 2004-12-16

Similar Documents

Publication Publication Date Title
US20030061149A1 (en) Conversational dealing system
US7269793B2 (en) Conversational dealing system
US7475046B1 (en) Electronic trading system supporting anonymous negotiation and indications of interest
AU2005330042B2 (en) System and method for managing trading using alert messages for outlying trading orders
US7024387B1 (en) Automated system for conditional order transactions in securities or other items in commerce
US20090076945A1 (en) Quick-filling customer asset trading system for booking orders with multiple providers
US20060184447A1 (en) Automated system for conditional order transactions in securities or other items in commerce
US20030088501A1 (en) Systems and methods for trading in an exclusive market
US8401951B2 (en) Electronic trading system supporting anonymous negotiation and indicators of interest
US20210142410A1 (en) Trading system with price improvement
EP1421532A2 (fr) Systeme d'echanges interactif
US8374950B1 (en) User interfaces for efficient trade entry and management
CA2971774A1 (fr) Systemes et methode d'amelioration de prix neutre
US20020143684A1 (en) Conversational dealing system
AU2002322749A1 (en) Conversational dealing system
WO2001009699A2 (fr) Systeme, procede et article de fabrication destines a l'estimation du prix d'un ordre a cours limite
WO2001009700A2 (fr) Systeme, procede, et article manufacture d'estimation d'un temps

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20040216

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LI LU MC NL PT SE SK TR

AX Request for extension of the european patent

Extension state: AL LT LV MK RO SI

RIN1 Information on inventor provided before grant (corrected)

Inventor name: HORSFALL, PETER, RICHARD

Inventor name: FORAY, ANDREW, P.

Inventor name: KIRILL, DUNAYEV

Inventor name: AJITSARIA, RAJIV

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: EBS GROUP LIMITED

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: EBS GROUP LIMITED

A4 Supplementary search report drawn up and despatched

Effective date: 20091021

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20100120