You: H.A.L.?
H.A.L.: Yeah?
You: Buy me a Credit Default Swap on Ford Motor Company to expire next year! (replace CDS with your favorite purchase that does not require visual liking; Broad band connection, mobile phone contract, airline ticket etc. )
H.A.L.: You forgot the magic word.
You: Please?
H.A.L.: Only because you asked so nicely...
We are not quite there yet, natural language processing and all those bots are not mature enough to carry out a meaningful task reliably. So what do we do instead?
We create tasteless, over crowded GUI forms. There is a fundamental problem in our understanding of Graphical User Interfaces. We just assume that they are simple and user friendly. They are not. May be they are to a new user for the first 3 days. After that, your user becomes an experienced user and clicking 12 drop downs and the next button 4 times becomes a burden.
Simply typing into the system what you are trying to do in a specific language is a lot faster for an experienced user. Anyone who watched an airline reservation operator using ALCS terminal would understand what I am talking about. It is a dumb text based terminal from 70s but it is immensely fast. Operators check tens of flights, do bookings etc. in a very short amount of time;
To display the avaliabilty for Delta Airline on 28 October between New York and Los Angeles, type something like:
AN28OCTNYCLAX/ADLSo how about the below to book a CDS;
define buy CDS "20090409001"
from 03-Apr-2010 effectiveDate 09-Apr-2010 to 03-Oct-2010 {
in LehmanHedge by Ozgur through BankOfAmerica
} notional of 3000000.0
on Ford
coupons E30_360 {
from 03-Apr-2010 to 03-Oct-2010
pay on 03-Oct-2010 rate 0.15
};
Liking the general idea here but, a lot of context is possible to default and without that, it makes the language look over complicated. There are only a few fields that are required to book a CDS and picking from your example, I reckon they are:
ReplyDeleteTrade expansion (i.e. the sytem defaulting certain fields) could figure out:
- the actual dates
- day count conventions
=> cashflows of the trade
- who the trader is
- what book the trade should be in (by rules the trader set's up)
A system I once looked after in FX didn't even mind which order the fields were in and required no words around them to clarify context because it knew that each field was derived from an enumeration or some basic rule i.e:
- a notional is a number
- a rate is too but the notional will be bigger
- a cpty is a valid entry in the cpty table
- a book is a valid entry in the book table
- a ccy pair is a valid ccy pair or, a valid ccy pair convention as the USD is missing
so a trade could be entered as:
EURUSD BookA Lehman +10m 1.234
or:
Lehman +10m EUR 1.234 BookA
What about post-trade processing? When you open a trade, you want to see the maturity date and so on as quickly as possible.
ReplyDelete