W3C home > Mailing lists > Public > public-ws-chor@w3.org > May 2003

Financial Services Use Case

From: Steve Ross-Talbot <steve@enigmatec.net>
Date: Mon, 5 May 2003 17:59:51 +0100
To: public-ws-chor@w3.org
Message-Id: <FCDCB6F6-7F1A-11D7-9BEB-000393AD2AA6@enigmatec.net>
Background
Financial Service, at least wholesale banking (investment banking), 
differs from most other web service domain in that it is much much more 
dynamic. Dynamic in this sense means that the act of deciding who to 
trade with depends on information that is dynamic. Prices tend to 
predominate in this domain but they may be seen as serving to guide as 
to what one might do. So for example if the price exceeds a certain 
threshold you might do one thing. If the rate of change exceeds a 
threshold you might do something else.

Of course any trading situation that is price driven (commodity, 
energy, derivatives and so on) markets. So this problem will apply to 
Elf, BP, Shell, Total, and of course any US based energy markets as 
well as the futures markets attached to them and the commodity markets 
are the same.

Description of how it is done today
Today Joe Trader (JT) simply doesn't do it. Sophisticated Trader does. 
ST looks at all sorts of market indicators and decides what strategy to 
employ. That strategy might be to place trades with specific execution 
venues. An execution venue is some place (represented by a company i.e. 
TradeWeb, Instinet, MTS, EuroMTS etc etc) at which buyers and sellers 
meet up. because there are several venues for different types of 
financial instrument ST needs to keep in their head what the different 
contracts are for each venue. So one venue might allow immediate price 
change, another might say only for order above a certain value and 
another might simply restrict it to prices changes every 5 minutes 
(from the point of view of whoever places that price).

Because only ST can have a hope of managing the situation the general 
case put financial service inititutions at risk. They might offer a US 
treasury bond at one price for 10 million units but over multiple 
venues. They want to sell 10 million. But the venues increase their 
risk to the number of venues times the units.  Only ST, at best, can 
manage this. IT support is needed.

Description of what would be desirable tomorrow
What they would like to do is on a per trade basis indicate how the 
trade should be placed. So JT (let alone ST) might want to place a 10 
million units deal across several venues based on some business rule 
that minimizes their exposure.  On the other hand JT might want to 
indicate the price of a deal right now, with the intention of changing 
the price pretty soon while a bigger deal, that may change the price 
anyway is being pursued. Obviously JT (as well as ST) want to ask each 
venue what their contract allows in order to place the trade in the 
optimal way.	

What does this have to do with Choreography
I thought I'd add this to make the relevance clear. The impact on 
choreography is that the very contract that a choreogaphy (the external 
observable behaviour ) represents may provide attributes that form part 
of a query or constraint that is part of a strategy employed by a JT or 
an ST to do their job.

Without necessarily lifting a skirt on a venue, a venue could be a web 
service, a JT or an ST could be interacting with another web service. 
What they both want to do is examine the potential venues (web 
services) so as to correctly place their trade with those venue based 
on some behavioural attributes.

This is late binding of web services based on choreography as well as 
impacting other possible aspects of web services such as UDDI etc etc.

Closing note
I'd be happy to add more to this if required to do so.
Received on Monday, 5 May 2003 13:00:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:00:17 GMT