Tuesday, September 17, 2013

quant trend - more stats, less theory or complex model

I see increasing evidence (though anecdotal) that real world quant roles now require less math theory, and more programming.

A Barcap friend told me many (mostly buy-side) pricing systems basically take market quotes as the most reliable price, rather than computing a theoretical price from a complicated model. Why hire so many math wizards to build a model when the output is ... questionable in the face of live price on the market? You can tune (based on market data!) your model to output a price, but I feel it has to be consistent with market prices. When they become inconsistent, either your model is imperfect or it has "discovered" a mispriced security or some rare trading opportunity like a stat arb. Well, I feel the chance of "discovery" is higher the simpler your model is. Further, how do you know this "opportunity" (if true) can't be discovered by a simple analysis without a model? If you are after such opportunities, then the faster you process market data, the earlier you catch the opportunity. That means simpler math. Complicated model is harder to program right, i.e. more bugs.

A Danske quant shared how important programming is to a quant. Ultimately, the quants are hired to help traders make decisions. Every Trader loves usable soft market data they can play with. Whatever great idea you have, you've got to put it into a computer, otherwise no one will use it.

My young quant friends in Barcap and MS shared that in the first few years as a quant, programming is probably the most important skill.

For a buy-side quant (usually in eq and FX), stats know-how is probably more relevant than stoch or volatility. I think a high frequency shop won't trade a lot of options, since liquidity is much lower. I guess many buy-sides do trade options, largely for hedging or to earn the premium.

On the other hand, there's still a demand for the deep theoretical knowledge. I feel the math jargon is still an entry requirement for any quant role. Otherwise you don't know what people are talking about. These jargon terms require a hell lot of background knowledge, probably taking a few years. Even the basic BS model can easily throw a curve ball. I bet you can't catch unless you did a few months of "home work".

Now a much bigger curve ball -- Interest rate derivatives are the most math-intensive. (Danske is actually an IRD sell-side.) I was told credit derivatives add additional complexity, but I'd guess bulk of the math complexity is in the IR stoch vol. There are even more complicated products (MBS?) out there but the total profit in that market must be big enough to justify hiring quants. Structured derivatives market probably qualify as such a market.

Structured derivatives (aka exotics) are more math-intensive than vanilla derivatives. The vendor (sell-side) must price it carefully to protect himself. Overpriced, no client wants it and it's a waste of vendor's effort [1]. Under-priced, vendor himself is under-protected. Therefore pricing requires deep math -- risk, modelling, embedded optionality, back testing... This is a prime example of high-touch (relationship-based) trading. Unfortunately, I feel technology (and other market factors) is driving the other direction -- low touch (i.e. automated), high volume flow trading. Just one simple example -- in recent years I see more FX option products offered electronically -- A high touch product going low-touch?

[1] I was a client for some of these simple structured products. I found the price too high. I could see the vendor spent time selling it and finally withdrawing it. Such unattractive, hard-to-sell products in the structured product marketplace are common -- lower revenue, higher cost, lower margin for the vendor, and lower salary.

No comments:

Total Pageviews

my favorite topics (labels)

_fuxi (302) _misLabel (13) _orig? (3) _rm (2) _vague (2) clarified (58) cpp (39) cpp_const (22) cpp_real (76) cpp/java/c# (101) cppBig4 (54) cppSmartPtr (35) cppSTL (33) cppSTL_itr (27) cppSTL_real (26) cppTemplate (28) creditMkt (14) db (65) db_sybase (43) deepUnder (31) dotnet (20) ECN (27) econ/bank` (36) fin/sys_misc (43) finGreek (34) finReal (45) finRisk (30) finTechDesign (46) finTechMisc (32) finVol (66) FixedIncom (28) fMath (7) fMathOption (33) fMathStoch (67) forex (39) gr8IV_Q (46) GTD_skill (15) GUI_event (30) inMemDB (42) intuit_math (41) intuitFinance (57) javaMisc (68) javaServerSide (13) lambda/delegate (22) marketData (28) math (10) mathStat (55) memIssue (8) memMgmt (66) metaProgram` (6) OO_Design (84) original_content (749) polymorphic/vptr (40) productive (21) ptr/ref (48) py (28) reflect (8) script`/unix (82) socket/stream (39) subquery/join (30) subvert (13) swing/wpf (9) sysProgram` (16) thread (164) thread_CAS (15) thread_cpp (28) Thread* (22) timeSaver (80) transactional (23) tune (24) tuneDB (40) tuneLatency (30) z_ajax (9) z_algoDataStruct (41) z_arch (26) z_arch_job (27) z_automateTest (17) z_autoTrad` (19) z_bestPractice (39) z_bold (83) z_bondMath (35) z_book (18) z_boost (19) z_byRef^Val (32) z_c#GUI (43) z_c#misc (80) z_cast/convert (28) z_container (67) z_cStr/arr (39) z_Favorite* (8) z_FIX (15) z_forex (48) z_fwd_Deal (18) z_gz=job (33) z_gzBig20 (13) z_gzMgr (13) z_gzPain (20) z_gzThreat (19) z_hib (19) z_IDE (52) z_ikm (5) z_IR_misc (36) z_IRS (26) z_javaWeb (28) z_jdbc (10) z_jobFinTech (46) z_jobHunt (20) z_jobRealXp (10) z_jobStrength (15) z_jobUS^asia (27) z_letter (42) z_linq (10) z_memberHid` (11) z_MOM (54) z_nestedClass (5) z_oq (24) z_PCP (12) z_pearl (1) z_php (20) z_prodSupport (7) z_py (31) z_quant (14) z_regex (8) z_rv (38) z_skillist (48) z_slic`Problem (6) z_SOA (14) z_spring (25) z_src_code (8) z_swingMisc (50) z_swingTable (26) z_unpublish (2) z_VBA/Excel (8) z_windoz (17) z_wpfCommand (9)

About Me

New York (Time Square), NY, United States