October 18, 2006
Are there ever sound reasons for deliberately making a user interface unintuitive and inconsistent ? For deliberately making life difficult for the user ? I know I’m drifting off topic here, but the thought crossed my mind as I used our corporate web based expense reporting system to file a claim for a conference I went to earlier this month.
This expenses system is terrible. The help is cryptic, and the workflow seems wilfully obscure. Is it just bad design, or should an expenses system be designed like that to cut down on employee claims ?
At another bank in the late 90s we all used a timesheet system called Agresso. It had an appallingly clunky Windows GUI that violated every possible expectation you might have about the interface – like TAB going to the next field. It was infuriating. Take a look at Agresso‘s stupid raging bull logo. No doubt it’s designed to appeal to alpha male senior managers. Ironically, it perfectly captures the mental state of a user after sustained exposure to its late 90s GUI. I guess that’s what happens when there’s a disconnect between purchasers and users. If we foisted crap like that on our traders, by golly we’d know about it pretty quick. They insist on minimal and intuitive keystrokes and mouse gestures.
October 14, 2006
One of the differences between order driven and quote driven markets is that all liquidity is supplied by dealers on quote driven markets. When you trade on a quote driven market like Bloomberg, you must trade with a dealer. By contrast, on an order driven market like Liffe or Eurex, any participant can trade with any other. All that is necessary is that orders from opposite sides of the market match.
This article discusses the role of designated market makers in order driven markets for stocks, futures and options. The DMMs role is to stop the screen going dark, to be the liquidity provider of last resort when no one else is trading. This is especially important for ETOs – exchange traded options. Unlike a futures market, there isn’t natural interest on both sides. Sellers protect themselves from future price drops, and buyers from rises in the underlying. The analogous hedges with options are to buy puts to hedge against price drops in the underlying, and to buy calls to hedge against rises. Selling puts and calls isn’t a natural hedge on the underlying. But an options exchange needs sellers, hence the importance of designated market makers.
October 12, 2006
…thanks to Holky for the good news on MiFID. Guess we won’t be reengineering that tiering system after all😉
October 9, 2006
Looks like Aleksey Vayner is the new Lucy Gao. I strongly recommend you watch the video on YouTube – it’s utterly hilarious.
October 7, 2006
Marc asks what banks are planning to do with their MFC apps. The code base for our etrading system is 600KLOC of C++, with some Java and C#. The GUI tier is mostly C++ MFC/Win32. Some of the newer stuff is C#. We have no plans to spend a year rewriting C++ MFC code in C# Winforms.
Let’s imagine you wrote an MFC GUI back in 97. If you’d bought the claims of each new wave of GUI technology since, how may times would you have rewritten it ? Once each for Java AWT, Java Swing, C# WinForms ? And would you be going for AJAX, Flash or Vista now. Any tech manager in a bank who buys in to vendor claims to the extent of rewriting production apps just to be on whatever platform the vendors are hyping this week needs their head examining. Or needs firing.
Maybe I’m too busy with my head down in the front office trenches, but I’m unaware of any MS announcement withdrawing support from MFC. Even if they did, I wouldn’t worry til MS released a version of Office based on something other than C++ MFC & Win32. As ever in etrading, low latency and high thoughput are key. Our pricing blotter runs on many desktops, and has to keep up with hundreds of bonds and swaps that tick several times a second – updating price, yield, DV01, duration, convexity etc every time. So we’ll be sticking with C++ MFC Win32 for some time. And I’ve no doubt that MS will persist with that approach for their own desktop apps for some time too.
October 3, 2006
Remember that UB40 tune from the early 80s recession ? Or, to put the question another way, how much can we automate ? Mostly’s recent post about only 10% of traders surviving growing computerisation made me think again about the automation of fixed income market making. Of course, the IBM paper he refers to is somewhat self serving: IBM think you need to select a strategic technology partner to meet the challenges of the next 10 year. I wonder who they could be thinking of ?
A lot of the market making job has been automated in the last few years…
- Pricing: calc engines driven by depth ticks from Eurex or Liffe constantly reprice bonds
- Quoting: autoquoting systems driven by the pricing engines crank out bid and ask with sizes to multiple ECNs
- Auto RFQ: on quote driven markets a dealers trading system will handle the negotiation with clients raising RFQs. Mostly alluded to this in an earlier post when he mentioned tiering.
- STP: most bond trades flow straight through to settlement with no manual intervention
So what remains to be automated ? To me it seems that the big ones are inventory management, and the pricing of liquidity. If we can do those, we make a lot of traders redundant, and maybe us techies can collect their bonuses ;) But how do we get the turkeys to vote for Christmas ?