buy-side vs sell-side trader — real diff

buy-side (asset manager incl HF) vs sell-side trader — real diff

Both bet “house money” and keep Positions. See my acid test in http://bigblog.tanbin.com/2009/09/adp1-acid-test-for-brokerdealerpropflow.html. What’s the real difference between both? Many friends gave me similar answers — strict hedging (though how strict is questionable — See Barings).

Sell-side trader must delta-hedge her positions. When market moves against her, her bank must be protected by the hedges. Sell-side is part of the “infrastructure” and the financial “services” (buy-side being the service-consumer). Therefore it needs more stability and less risk-taking.

In a volatile environment, a bank is supposed to /survive/ longer than a buy-side. A bank failure triggers deeper /repercussions/ and leads to larger /domino-effects/.

The best-known measure to enforce stability (and reduce risk-taking) on a sell-side trader is a strict policy of hedging. Upper management and regulators want to see VaR numbers and stress test results, periodically.

Effect of hedging should be obvious — risk should be much lower and profit also lower.

Barings didn’t hedge as market makers should. Nick Leeson hated to cut losses when market moved against him. He was acting like a buy-side and his firm failed like a buy-side.

clever use of enum(char?) in demanding c++ app

class Der: public Base {…..}

Requirement — we need to down cast a Base pointer. dynamic_cast has overhead.

Der* returnVal = static_cast (new Base) // will compile but is potentially disastrous, because the returnVal can be a partially wild pointer.

Q: without incurring the overhead of vtbl lookup, how do I decide if a pointer to Base given to me actually points to a Base or Der instance?

%%A: type_info still uses vtbl.
%%A: use a Base field to indicate the type. Both ctor will set the field, so the Der ctor will overwrite.
A: enum. If sizeof(aBase) is a tiny 2 bytes, then adding an enum field adds just 1 byte. Adding vptr would add 4 bytes. Big difference if we instantiate billions of this class. I guess enum can be configured to take 1 byte, but you can also use a char, which is always 1 byte.

custom logger to show src line num, caller, parent caller and grandparent caller

<![CDATA[ /** based on http://javablog.co.uk/2008/07/12/logging-with-javautillogging/* Class name is mentioned in C:\Program Files\Java\jre1.6.0_06\lib\logging.properties */ public class JDKLoggingForamtter extends SimpleFormatter { private final String lineSeparator; public JDKLoggingForamtter(){ lineSeparator = java.security.AccessController.doPrivileged( new sun.security.action.GetPropertyAction(“line.separator”)); } @Override public synchronized String format(LogRecord record) { String sb = super.format(record); String lineNum = getEclipseFormat(); return sb.replaceFirst(lineSeparator, ” ” + lineNum + lineSeparator); } /** * Returns caller location information in eclipse format eg (Filename.java:23) * WARNING Generating caller location information is extremely slow. * It's use should be avoided unless execution speed is not an issue. * * @return the eclipse format */ private static String getEclipseFormat() { // getStackTrace can be expensive StackTraceElement[] stackTrace = Thread.currentThread().getStackTrace(); String upstairs = “”; int lineNumber = 0; //StringBuilder sb = new StringBuilder(); // Here is an example of the typical stack trace we get back. // level 0 (Thread.java:1436) getStackTrace // level 1 (CustomFormatter.java:139) getFileLineNumber // level 2 (CustomFormatter.java:128) format // level 3 (StreamHandler.java:179) publish // level 4 (ConsoleHandler.java:88) publish // level 5 (Logger.java:458) log // level 6 (Logger.java:480) doLog // level 7 (Logger.java:503) log // level 8 (YourCodeHere.java:26) someMethod if (stackTrace.length >= 9) { String fileName = stackTrace[8].getFileName(); lineNumber = stackTrace[8].getLineNumber(); // Each of these calls back into logger.logp with the appropriate // level and message. This adds one extra level to the stack trace // logger.finest(“finest message”); // logger.finer(“finer message”); // logger.fine(“fine message”); // logger.info(“info message”); // logger.warning(“warning message”); // logger.severe(“severe message”); // logger.entering(“SomeClass”, “aMethod”); // logger.exiting(“SomeClass”, “aMethod”); // logger.exiting(“SomeClass”, “aMethod”, “returnval”); // logger.config(“config message”); // // Here is an example stack trace from a call to exiting // level 0 (Thread.java:1436) getStackTrace // level 1 (CustomFormatter.java:139) getFileLineNumber // level 2 (CustomFormatter.java:128) format // level 3 (StreamHandler.java:179) publish // level 4 (ConsoleHandler.java:88) publish // level 5 (Logger.java:458) log // level 6 (Logger.java:480) doLog // level 7 (Logger.java:623) logp // level 8 (Logger.java:938) exiting // level 9 (YourCodeHere.java:27) someMethod // // We could check the name of the method we are in and only go one level deeper // if it is one of “finest”, “finer”, “fine”, “info”, “warning”, // “severe”, “config”, “entering” or “exiting” but that would be too much trouble. // If the stack is in Logger.java and we can go one level deeper – do it. if (stackTrace.length >= 10 && “Logger.java”.equals(fileName)) { fileName = stackTrace[9].getFileName(); lineNumber = stackTrace[9].getLineNumber(); } if (stackTrace.length >= 10){ upstairs = ” = 11){ upstairs += “

%%broad GTD value-add compared to a 3-year younger java programmer

 (Written in 2009)
– i managed difficult teams and difficult customers for years
– real AR experience with perl
– 5 years of Unix system admin experience
– i took part in AR decisions of many projects. 1st-hand AR experience
– I dealt with more diverse challenges of trouble-shooting and problem-solving
– In small projects, I was usually the customer-facing single point of
contact, not working behind the interface person. i was the only one
to negotiate with customer.
– Over the same 3 years, i dealt with many small customers rather than
1 or 2 big customers
– since i took part in more prj over the same 3 years, i witnessed
more failed prj
– i witnessed 1st-hand the “decline” of many technologies — rare xp

computing delta value from BS formula – unrealistic

Delta is the option-valuation change due to a small change in underlier. We are asking “using the BS formula as a prediction of real market, if there’s a $.01 change in underlier, what’s the change in bid/ask of this listed option?”

Assumption — all the bid/ask quoters in the option market use roughly the same BS formula. Obviously unrealistic. I don’t feel this assumption would help make delta a random variable.

Assumption — large number of bid/ask quoters responding to the underlier change. Realistic? I doubt it. Many quotes may ignore the spot change. I guess a small number of dealers/funds might _concentrate_ on a sector and are responsible for a disproportional part of the order book on that option. If they ignore the spot change, then bid/ask will stay constant and delta is 0!

Assumption — no change in i-vol when underlier changes. I feel real players in the market are emotional and may respond emotionally to whatever event causing the $.01 change. These emotional reactions can /effect/ a change in i-vol. I think some trend recognition machines may recognize this small change as part of a trend. I don’t feel such a market response is random.

What if the change is not $.01 but a 2% change?

Assumption — underlier price change is fairly slow and small. Obviously unrealistic. Therefore the change in option bid/ask in response to underlier change doesn’t always follow math model.

More important factor — An option is often held along with an underlier position as part of a strategy. When underlier moves, the holder may want to adjust her option position. One choice is adjusting her option quotes (limit orders). If she is a powerful market maker, then her new quote can move the best bid/ask. Therefore option valuation as measured by mid price may not move according to any math model.

"increase in volatility" can mean 1 of 2 things

An “increase in volatility” actually can mean 2 different things.

@ increase in “historical volatility”, which actually means increase in recent, observed volatility on the Cash market.[1] I feel this is what “increase in volatility” usually means.
@ increase in implied volatility, reflected in higher bid/ask “insurance” premiums on the Options market.

I-vol is forward-looking and refers to predicted future volatility of an underlier (like SPX) over the next 30 days (or 90, or 365 … days). So an increase there reflects people’s anticipation of market volatility.

H-vol is backward-looking and refers to recorded, realized volatility of an underlier (like GBP) over the past few days. When people talk about increase in h-volatility, I believe it’s usually over the Recent past.

[1] if you have an option on futures, then it’s not the Cash market but the futures market, but in this context it’s better to remove this kind of noise and focus on simple concepts.