You are currently browsing the category archive for the ‘Risk’ category.
Business Insider, And Now JP Morgan’s $2 Billion Trading Loss Is Already $3 Billion (And Counting), here. Ok so the reported losses are growing.
Jamie Dimon said it could get worse… and it is.
The JP Morgan trading loss that was $2 billion four days ago is now $3 billion, report Nelson Schwartz and Jessica Silver-Greenberg in the New York Times.
Why?
Because every hedge fund in the world knows JP Morgan is stuck in a position so big that it can’t unwind it… and they’re betting against it.
Zerohedge, Jamie Dimon “Invited” To Testify Before Senate, here. And there will be compelling TV on its way.
Update: JPMORGAN SAYS DIMON TO AGREE TO TESTIFY TO SENATE. Ummmm, there was an option?
As everyone (or at least Zero Hedge) long expected, JPM’s prop trading debacle just got political and senators are about to demonstrate to the world just how little they understand about modern IG9-tranche pair trades. Expect to hear much more about JPM’s “shitty” prop deal.
Zerohedge, So How Are JPM’s Prop “Counterparties” Faring? here. But Bluecrest and Blue Mountain are not reporting like they are Party B. There are reports that Boaz Weinstein/Saba is Party B but no actual P&L numbers being whispered. Odd?
Now one thing we know is that when it comes to reporting one’s results to an aggregator: when you have a profit you never under-represent it. And in this special case, since the funds are likely eager to recruit more like-minded hedge funds to their side of the trade, the best way to do it is by showing profits.
Which, for the early part of May, when the bulk of the JPM losses took place, are oddly missing for the two biggest players across from JPM…
So: where are the profits really going?
Lisa Pollack, Alphaville, Recap and tranche primer, here; and The high yield tranche piece, here. Pollack going to get the book deal for the London Whale, clearly. Once she nails down the positions maybe we will get to the Gaussian Copula substory. Chances seem to be improving that this story is about a bunch of smart guys who tried to resurrect a dead quant model. Maybe it would be better to recast the story as a Zombie Quant model or go with the J Depp/Dark Shadows/Vampire Quant model. But even though this story has massive potential to connect with loads of people, Pollack is not locating Party B P&L nor has anyone else. It’s a problem if you cannot get that puzzle piece. Plus there is way more premeditation here than just Keystone Cops stuff started to happen on 6 Apr. Maybe there is some offshore vehicle hole getting filled up whose reference entity name cannot be spoken? That would change the story’s complexion, right? Maybe the London Whale is a red herring?
Coverage of the
$2bn$3bn loss emanating from JPMorgan’s Chief Investment Office on its synthetic credit portfolio continues a pace, and FT Alphaville’s tour continues too.The desire to understand what the trade was and the rationale behind it continues to bug us and many others. Interestingly, some of the discussion of late has come full circle. Bloomberg kicked off the London Whale saga on April 6th, and their follow-up on April 9th contained a detail that has now come back into the narrative. This time, though, it’s more than a mere sidenote — more on this in a minute.
While these more recent explanations are satisfying, we’re still scratching our heads a bit.
The challenge remains: to find trades that have managed to deteriorate with the speed that CEO Jamie Dimon has claimed they have — small in the first quarter, $2bn “all in the second quarter”, and “it kind of grew as the quarter went on”.
Now, credit tranches, which are leveraged positions on credit indices that themselves already involve a lot of leverage, could do this if the model used to determine hedge ratios wasn’t up to the task or if the trades were just outright foolish.
Lisa Pollack, Alphaville, Two billion dollar ‘hedge’, here. Looks like Pollack and Zerohedge conclude the London Whale position is in CDX tranches. One other thing if I could, JPM spent 3 years getting it’s 8 hour overnight Gaussian Copula batch into an award winning FPGA supercomputer (see JP Morgan’s London Whale needs Maxeler’s FPGA Supercomputer to run Risk?) that runs in 238 seconds; is that right, Sir? And then there’s this, Recipe for Disaster: The Formula That Killed Wall Street. Now, I’m not Lt. Columbo or anything but help me out here, wouldn’t some people call that means, motive, and … opportunity.
Concerning how one can make a $2bn loss on this, we have become convinced that it’d only be possible if the above was also done with tranches, which would seriously lever up any such position. Several FT Alphaville commenters have alluded to this already — thank you, guys. Even then, a $2bn loss is a lot to chalk up. But if it isn’t that, what else could it be?
Zerohedge, Is The Pain Over For Bruno Iksil? here.
Today, for the first time since the advent of the JPM prop trading fiasco last Thursday, the IG9-10 Year skew has diverged, dipping from -3 bps to -5 bps as the index remained flattish while the intrinsics widened by about 2 bps. While hardly earthshattering, this move likely means that either JPM’s CIO trading desk is playing possum and is no longer unwinding its original pair trade exposure (either because it no longer has anything to unwind, or because it can’t take the pain any more and is out of the market entirely), or the hedge fund consortium has had enough of pushing IG 9 wider in hopes that max pain would force JPM to cover its synthetic leg. As a reminder, this is where last Thursday we said the time to push JPM would likely end. As for the question of how much additional P&L loss JPM has sustained from Friday through today is a different matter entirely, and we are confident the next announcement from JPM will come momentarily, coupled with the announcement that Bruno Iksil, the last remnant of the CIO desk, and now having completed his duty of unwinding the trade that brought so much pain for Jamie Dimon, has been retired.
The Awl, Roman Emperors, Up To AD 476 And Not Including Usurpers, In Order Of How Hardcore Their Deaths Were, here.
53. Tiberius (37): His entourage thought he died of old age, announced his death, then smothered him in a panic when he suddenly regained consciousness.
Admati, Fallacies, Irrelevant Facts, and Myths in the Discussion of Capital Regulation: Why Bank Equity is Not Expensive, here. Looks like a good collection of material on Accounting, Economics, and Finance from Stanford Business School. Also Huffington Post, What Jamie Dimon Won’t Tell You, here.
Baseline Scenario, Simon Johnson, JP Morgan Debacle Reveals Fatal Flaw In Federal Reserve Thinking, here.
Experienced Wall Street executives and traders concede, in private, that Bank of America is not well run and that Citigroup has long been a recipe for disaster. But they always insist that attempts to re-regulate Wall Street are misguided because risk-management has become more sophisticated – everyone, in this view, has become more like Jamie Dimon, head of JP Morgan Chase, with his legendary attention to detail and concern about quantifying the downside.
NYT, Red Flags Said to Go Unheeded by Chase Bosses, here. Times gets statements from former JPM employees Re: London Whale’s positions. Wonder how that worked out?
In the years leading up to JPMorgan Chase’s $2 billion trading loss, risk managers and some senior investment bankers raised concerns that the bank was making increasingly large investments involving complex trades that were hard to understand. But even as the size of the bets climbed steadily, these former employees say, their concerns about the dangers were ignored or dismissed.
Zerohedge, The “Fail-Whale” Fallout Begins: Three JPM Execs To Leave Prop-Trading, Pardon, Hedging Bank, here.
William Buiter, Chief Economist Citigroup, homepage, here. See also, A Greek Exit from the Euro Area: A Disaster for Greece, a Crisis for the World, Sep 11, here.
The prospect of Greece exiting the euro area is seldom viewed with the proper degree of fear and trepidation, in our view. Some commentators indeed believe that exit will be beneficial for Greece. The introduction of a new currency, the New Drachma (ND), and a prompt sharp reduction in its external value relative to the euro is considered a necessary, sometimes even a sufficient, condition for the restoration of Greece’s economic fortunes. Even when Greece’s exit is viewed as costly, possibly disastrous, for Greece, it is often considered a minor issue of the remaining 16 euro area member states, the rest of the EU and the world at large. A Greek exit is indeed often viewed as ‘euro-positive’ in the narrow sense of likely to be associated with a strengthening of the effective exchange rate of the euro – mainly because it eliminates the prospect that a sovereign default in Greece would entail the risk of part-monetisation of Greek government debt by the ECB.
Noahpinion, Cyclicalists should start talking about structural issues too, here.
I could count on my fingers the number of times Paul Krugman has obviously been wrong about something, and still have enough fingers left to type 60 words per minute. But if there’s one thing I’ve learned in my years of arguing with people, it’s that if you’re not in math or the natural sciences, being right on the merits is never good enough to win an argument. You have got to win hearts and minds.
Al Pacino, Any Given Sunday, here; or Clint Eastwood, here. Now we are going to have to endure a seemingly endless stream of Taleb’s gloating i-have-been-warning-you-about-VaR-for-years interviews; the FinQuant equivalent of the Icky Shuffle. Look Team Firm Risk, you all have seen It’s a Wonderful Life, right? Well every time a bank gets their bell rung, Taleb gets another Fox and Friends interview.
Naked Capitalism, JP Morgan Loss Bomb Confirms That It’s Time to Kill VaR, here.
One of the amusing bits of the hastily arranged JP Morgan conference call on its $2 billion and growing “hedge” losses and related first quarter earning release was the way the heretofore loud and proud bank was revealed to have feet of clay on the risk management front. Jamie Dimon said that the bank had determined that its value at risk model was “inadequate” and it would be using an older model. And no wonder. The Financial Times report contained this bombshell:
JPMorgan also restated its “value at risk”, a measure of maximum possible daily losses, of the CIO [the unit that executed the trading strategy that blew up] in the first quarter from $67m to $129m.
Lisa Pollack, ft.com/alphaville, Too Big To Hedge, here; and What Position Transparency, here.
“Synthetic credit portfolio”. That’s the book where the $2bn in mark-to-market losses took place for JP Morgan, according to an announcement made on Thursday. A result which has now cost them a their AA- rating from Fitch and landed them on negative outlook with S&P, as announced late on Friday.
FT Alphaville has analysed the credit trades that might be in that portfolio, in an attempt to reason through what may have gone on. The fact, however, remains that we know precious little. Why is that? Is this acceptable that after the financial crisis that this can happen to a bank, let alone a systemically important one like JP Morgan?
Got a buck that says you cannot find a Firm Risk person on 13 May 2012 who knows substantially more about the positions than Lisa Pollack.
Zerohedge, Double or Nothing: How Wall Street is Destroying Itself, here.
This fragile business model is in fact descended from the Martingale roulette betting system. Martingale is the perfect example of the failure of theory, because in theory, Martingale is a system of guaranteed profit, which I think is probably what makes these kinds of practices so attractive to the arbitrageurs of Wall Street (and of course Wall Street often selects for this by recruiting and promoting the most wild-eyed and risk-hungry). Martingale works by betting, and then doubling your bet until you win. This — in theory, and given enough capital — delivers a profit of your initial stake every time. Historically, the problem has been that bettors run out of capital eventually, simply because they don’t have an infinite stock (of course, thanks to Ben Bernanke, that is no longer a problem). The key feature of this system— and the attribute which many institutions have copied — is that it delivers frequent small-to-moderate profits, and occasional huge losses (when the bettor runs out of money).
Khan Academy, website, here. Khan’s 2011 TED talk, here. This guy is good, don’t know why it took me so long to look at his work. Got 5 badges this morning. Love the part in the TED talk when we speculate on whether Newton would have been a good Calculus teacher, we don’t really know do we?
DeLong, THIS TIME, IT IS DIFFERENT: CUTTING EDGE MACRO FINANCE FROM THE 1870S FOR THE 2010S, here. Whole panel is good. I was struck at 9:30 DeLong talking about how banks didn’t know what the subprime exposure was between 2007 to late 2008. That was very similar to the Lehman experience, first there’s a $50bn hole, then it might be much larger, then its smaller, but there is never a date by which the shortfall is going to be nailed down and even whispered. So, subprime liquidity puts (and assorted other contract provisions) destabilize management decision making sufficiently to cause the Fed to say no thanks to funding as a last resort, really? No objections if someone calls shenanigans here.
MIT Tech Review, Microsoft’s New Lab Hunts for Value in User Data, here. Microsoft Research opening NYC lab for data analysis.
A new research lab that opens in New York City today brings together researchers studying such questions as how to identify the most influential users of a social network and how to measure the sway they hold over other users.
The lab will not be tasked with solving the problems facing Microsoft as a business. However, the program of research in New York could help the company come up with ways to extract revenue from a vast, largely untapped resource—the large quantities of data generated by people as they use Microsoft products to interact with others.
“We have all these implicit social networks in Hotmail, Outlook, Xbox Live [Microsoft's service that connects users of its games console], and Skype,” says Jennifer Chayes, who is managing director of the new lab and was already in charge of Microsoft’s New England research lab in Cambridge, Massachusetts.
Ritholtz/Saluzzi/Arnuk, Happy 2nd Anniversary, Flash Crash of 2010! here.
This Sunday will mark the 2nd anniversary of the May 6th Flash Crash of 2010. As we all trade in this extremely low-volume environment, it is fitting that we recap where we stand today.
Listening to NYSE Euronext’s 1st quarter conference call yesterday, we shook our heads in dismay as management described a trading environment where volumes fell to a four and one half year low – the lowest levels since Reg NMS was implemented in late 2007, in fact.
NYSE’s Duncan Niederauer explained his 44% profit decline was due largely to a 25% decline in revenues from transactions from a year earlier. The culprit: An unfriendly environment for high frequency trading firms. From his point of view, regulators and folks in the media hyped the HFT bogey man too much, creating uncertainty, causing an HFT migration into other asset classes and geographies.
Niederauer doesn’t get it. He is mistaking the symptoms for the underlying problem. HFT volumes are down because investor volumes are down. Investor volumes are down because traditional retail and institutional buyers and sellers of stock have been steadily waking up to the dangers of drinking at the increasingly dangerous ”stock market watering hole.”
Reminds me of old Navin Johnson, who eventually gets it, given enough evidence, here.
Softtalk Blog, New Intel chips will be able to decide whether to lock data or not, here. Pretty sure upfront this is an Intel blog. The point is interesting if the ICC compiler is going to do something clever with the transactional memory in Haswell. See also ISTEP 2012: Get some good advice from Intel, here.
Intel Advisor XE is a design tool that helps you to transform serial code to run well on multicore hardware by forecasting what might happen if the code executes in parallel. It helps to identify where parallelisation gives the biggest returns, predicts scalability and overheads, and also helps predict data races. As with many of the Intel parallel programming tools, it uses highly visual graphs to help you identify hotspots and assess the potential performance of your parallel annotations.
Interesting, but I’m not sure how much I buy this until I see it work on something I know something about.
Bloomberg, JPMorgan Trader Iksil Fuels Prop-Trading Debate With Bets, here. London Whale needs some P from Series 9 Investment Grade CDX. Can Bloomberg and some prominent officials help fix the situation?
Zerohedge, From Bruno Iksil’s Personal Profile: Enjoys “Walking Over Water” And Being “Humble”, here. Oh, so the London Whale is shorting tranches of series 9 CDX in $100bn quantities.That starts to make sense given all the hysteria. So they make the purchases at the corporate-level to hedge SCDO exposure that is not actively traded by the desk. Maybe Bruno is the one who needs the the Maxeler FPGA Supercomputer Credit batch at JPM (see Credit Derivatives, Flynn’s Architectural Case for Maxeler in 2012?, and Street FP Due Diligence 3: Epic Yet?) to run in 238 seconds. How do you tag that? London Whale needs Mammoth Supercomputer to Stay Afloat? Too much, right? I still suspect that the entire JPM credit batch (as described) completes in less than a minute on a low-end Mac Pro even with the Gaussian Copula positions. Sort of more like “Bruno uses iPhone to Track Purchases.” (see Business Insider, Financial Post, Wall Street Journal blog, Sober Look, New York Times Dealbook, Financial Times Alphaville, blogrunner)
Zerohedge, 31 Dec 2011 Notional Amt. of Derivative Contracts Top 25 Comm. Banks, here. Didn’t MS carry derivative inventory in the past?
The first step to getting a better estimate on the off-the-shelf runtime for credit curve cooking is to get a sense of how long the valuation of a quoted SNAC CDS (standardized default swaps, no custom cashflows) requires. Getting a SNAC CDS valuation runtime estimate is the subject of this post. The outline of the argument is to take the SNAC valuation runtime estimate and cook the credit curve (bootstrap the hazard rate term structure) from the quoted SNAC default swaps with terms 1Y, 3Y, and 5Y (see O’Kane and Turnbull pgs 12-14). Once we have a cooked credit curve we can run valuation and risk for the default swap inventory dependent on the given cooked credit curve. For a given credit, the serial computation runtime for a single CDS position valuation is an order of magnitude smaller than the credit curve cooking computation. Take a look at O’Kane and Turnbull pgs5-10 to review the Jarrow-Turnbull reduced form model for valuing the contingent leg and the fee leg. See the FINCAD document describing the modeling assumptions behind the ISDA CDS Standard Model, here. Recognize also that the ISDA code doesn’t have all the calendars and currency convention data you would expect in a complete production Credit P&L but it’s OK as a proxy code for getting estimates.
Vanilla default swaps have two legs a Premium Leg and a Contingent Leg, the default swap PV (present value) is the difference between the Premium Leg PV and the Contingent Leg PV. If counterparty A is long protection in a default swap they are paying premium to get the protection of the contingent leg, as well as being short the credit. We will assume the average maturity of a default swap is 5Y. We will proceed purely with static analysis of the code with no peeking at the underlying mathematics for better optimizations – nothing but the code.
Valuing the Premium Leg
The basic computational task with the Premium Leg is to discount each of the scheduled premium cash flows off the risky curve accounting for both the time value of money and the probability that the premium may never be paid due to termination of the default swap. Typically the main computational part of valuing the Premium Leg is valuing the accrual on default. The actual discounting of the premium cashflows to be paid on the quarterly paydates is straightforward and computationally inexpensive. Accruing on default is a standard convention and refers to the portion of the premium owed by the protection buyer in the event that a default occurs between premium paydates ( as oppose to default arriving exactly on a paydate). The protection buyer owes the premium accrued up to the date that the relevant default is officially recognized. For computational efficiency we are going to push the accrued on default computation over to the Contingent Leg computation, because they are so similar. This leaves about 20-30 cycles of computation for a 5Y default swap plus an IOU to account for the more computationally expensive accrual on default valuation. Here is the relevant code from ISDA from inside a loop for each paydate:
amount = notional * couponRate * accTime;
survival = JpmcdsForwardZeroPrice(spreadCurve, today, accEndDate + obsOffset);
discount = JpmcdsForwardZeroPrice(discCurve, today, payDate);
myPv = amount * survival * discount;
Notice that the variables notional, couponRate, and n-1 of n assignments of accTime are known at compile time. The calls to the function JpmcdsForwardZeroPrice() for the spreadCurve and this discCurve are simply interpolations from the cooked curves where the interpolation parameters (at least n-1 out of n) are known at compile time. Price them as assignments and assume that the cache size will not be swamped with 20 or so doubles for the quarterly paying CDS. The product survival * discount per paydate is known at curve cooking time. The trade off is between consuming a cycle per paydate versus adding to the cache load. Let’s put it in the cache for now and assume the curve cooker will compute the product survival*discount. So there is slightly more than a cycle (call it 1.5 cycles) per quarterly paydate w. no cache pressure or wait state penalties. We will call it 30 cycles for a 5Y quarterly paying average default swap.
Valuing the Contingent Leg
We need to account for the clock cycles required to:
- PV the default swap payout given the expected default arrival over the term of the CDS contract.
- PV the accrued premium owed by the protection buyer to the protection seller in the event the default arrives between premium cash flow paydates (IOU from the payleg).
Again static code analysis only, no peeking at the mathematics. Here is the relevant ISDA code for 1. integrating the value of the terminal CDS contingent payoff over the term of the CDS contract.
s1 = JpmcdsForwardZeroPrice(spreadCurve, today, startDate);
df1 = JpmcdsForwardZeroPrice(discCurve, today, MAX(today, startDate));
loss = 1.0 – recoveryRate;
for (i = 1; i < tl->fNumItems; ++i)
{
double lambda;
double fwdRate;
double thisPv;
s0 = s1;
df0 = df1;
s1 = JpmcdsForwardZeroPrice(spreadCurve, today, tl->fArray[i]);
df1 = JpmcdsForwardZeroPrice(discCurve, today, tl->fArray[i]);
t = (double)(tl->fArray[i] – tl->fArray[i-1])/365.0;
lambda = log(s0/s1)/t;
fwdRate = log(df0/df1)/t;
thisPv = loss * lambda / (lambda + fwdRate) *
(1.0 – exp(-(lambda + fwdRate) * t)) * s0 * df0;
myPv += thisPv;
}
Again, as in the case of the pay leg, all the calls to JpmcdsForwardZeroPrice() are interpolations known at credit curve cooking time so we will account for them as variable assignments and assign the computational cost of interpolation to the curve cooker. The time consuming computation here and in the code below (for accrued on default) depends on the resolution of the time grid (fNumItems) to get the discrete summation to converge to the continuous integral value. If the integration time grid has M points and r is the 5Y swap rate (the risk free rate USD currently 114 bps 19Jan12) then O’Kane and Turnbull (pg10) show the percentage error in the discreet approximation is:
r/2*M
In production P&L batches I have seen M=26 (biweekly integration grid points) but based on current levels M=4 (quarterly cashflow paydates) would bring the error to within the bid ask spread. Let’s assume M=26 worst cast and M=4 expected case for performance approximations.
Notice that the expensive floating point operations in these loops are the math.h functions log() and exp() and divides. We will push the log and exp calls to the curve cooker since the grid points for the integration as well as all the interpolations are known at curve cooking time. The variable lambda is known at credit curve cooking time and the variable fwdRate is known at Libor curve cooking time. Similarly all the values of t are known at compile time so we are not even going to multiply by the reciprocal of 365 inside the loop. We will also book the computational cost of the reciprocal 1.0/(lambda + fwdRate) to the curve cooker. So, no divides and no math.h calls in the loop we cost it at 4 fused add multiply cycles after vectorizing, loop unrolling, and optimization. In the expected case, loop 1 cost us 4 cycles * (4*5) grid points or 80 cycles. In the worst case, loop 1 cost us 4 cycles * (26*5) grid points or 520 clock cycles.
Here is the relevant ISDA code for 2, a very similar loop compared to the PV of the contingent payoff loop, right?
for (i = 1; i < tl->fNumItems; ++i)
{
double lambda;
double fwdRate;
double thisPv;
double t0;
double t1;
double lambdafwdRate;
if(tl->fArray[i] <= stepinDate) continue;
s1 = JpmcdsForwardZeroPrice(spreadCurve, today, tl->fArray[i]);
df1 = JpmcdsForwardZeroPrice(discCurve, today, tl->fArray[i]);
t0 = (double)(subStartDate + 0.5 – startDate)/365.0;
t1 = (double)(tl->fArray[i] + 0.5- startDate)/365.0;
t = t1-t0;
lambda = log(s0/s1)/t;
fwdRate = log(df0/df1)/t;
lambdafwdRate = lambda + fwdRate + 1.0e-50;
thisPv = lambda * accRate * s0 * df0 * (
(t0 + 1.0/(lambdafwdRate))/(lambdafwdRate) -
(t1 + 1.0/(lambdafwdRate))/(lambdafwdRate) *
s1/s0 * df1/df0);
myPv += thisPv;
s0 = s1;
df0 = df1;
subStartDate = tl->fArray[i];
}
We will treat both the loops simultaneously assume that the loops will be fused. The same analysis applies to this loop: laqmbda, fwdRate, lambdafwdRate, and all the interpolations and ratios are known at curve cooking time so they will be accounted for in the curve cooker not in the CDS valuation. Net, 2 fused multiply cycles will get the accrued on default value per grid point. Expected case = 40 cycles, worst case an additional 260 cycles.
CDS valuation estimates are then as follows
Expected case = 30 + 80 + 40 = 150 clock cycles, 42 ns, 23MM valuations /second
Worst case = 30 + 520 + 260 = 810 clock cycles, 225 ns, 4.5 MM valuations/second
In another post we will go through the curve cooking accounting and deal with the cache traffic we are creating with allocating computation to the curve cooker. Informally, we think cooking is an order of magnitude more expensive than valuation so we are kind of thinking under 10 – 20 microseconds to cook a curve on a single off-the-shelf core in either expected or worst case. 50K curves cooked per second seems plausible – let’s see how it goes the cache penalties/fp pipeline bubbles could catch up with us.
ISDA and Markit offer the CDS JPM CDS code here for open source download since about 2009.
James Zucker ported the code to an iPhone and recounted the tale in My First iPhone App. You can get the App from iTunes for free its called …iCDS from iJAZ Software.
Dominic O’Kane has/had his own web based calculator based on his 2008 book Modeling Single-name and Multi-name Credit Derivatives which is in turn based on a very good Lehman research report O’Kane published with Stuart Turnbull in 2003, Valuation of Credit Default Swaps.
Hull and White 2003 on Valuation of a CDO and an nth to Default CDS Without Monte Carlo Simulation. If there is a broker dealer running a PDE solver on their Credit Derivative inventory for daily P&L, find out who the head of quantitative research is there and bow before that guy because he has achieved Steve Jobs-level marketing skills.
Matlab CDS pricer, here.
BionicTurtle has a YouTube video of how to run a CDS valuation on a spreadsheet, here. Appears to be the tip of iceberg of You Tube videos explaining Credit Derivatives
1654 Pascal/Fermat solve Pacioli’s puzzle via Probability
1703 Bernoulli Law of Large Numbers – Statistical sampling
1712 Taylor’s Theorem: Polynomial approximation for any sufficiently smooth function
1730 de Moivre Normal Distribution; Standard Deviation; Law of Averages
1754 Bayes Theorem
1875 Galton Regression to the Mean
1952 Markowitz Portfolio Theory – Value of Diversification
1988 Basel 1;
1997 Jorion: Value At Risk;
2004 Basel 2;
2007 Taleb: Black Swan;
Pink Iguana
Functions take inputs, do something, and then provide outputs. A particular example of a function, a Black Swan detection function, takes inputs, does something, and then outputs one of two outputs 1 (it is a Black Swan) or 0 (it is not a Black Swan). A simple Black Swan detection function take two inputs – say, the results of two coin tosses converted to inputs 0 and 1 through the table (lets call it one of the Back Office Tables, just to give it a name)
| tails | 0 |
| heads | 1 |
Table A
| 1 | Black Swan |
| 0 | No Black Swan |
Table B
Figure Back Office Tables
and then detects a Black Swan by computing the logical “and” of the two inputs (lets call this the Front Office Analytics computation, just to give it a name)
| Input 1 | Input2 | Output |
| 0 | 0 | 0 |
| 1 | 0 | 0 |
| 0 | 1 | 0 |
| 1 | 1 | 1 |
Figure: Front Office Analytics Computation
The the front office analytics folks use the back office table B to look up the 1 or 0 to indicate it is or is not a Black Swan.
Almost ready but we need one more thing, someone (lets call them trading assistants, just to give them a name) has to flip the coins and feed the results to the Back Office tables to start this function evaluation going for Day 1. The trading assistants flip two coins one comes up heads the other tails; they record the results in XL for the traders and then send the output to Back Office; BO translates the inputs to ones and zeros and sends it off to FO Analytics; FO Analytics executes the Black Swan Detection function and translates the output through BO table B and records the output
Day 1: No Black Swan.
Admittedly, the simplicity of this Black Swan detection function outweighs its usefulness in detecting real Black Swans, but if I understand even a small portion of Taleb’s arguments, this one is at least of competitive utility with all the other VAR’s in production on the Street today.
So Day 2, a Black Swan arrives, trading assistants do their job normally but when it comes time to kick off the Black Swan detection function they flip one coin, Heads, forgetting there was a second coin and that they flipped it on Day 1. That forgotten coin, its a Pink Iguana. BO translates the Heads to a 1 and sends it off to FO Analytics; FO Analytics see they only have one input, its late they call the trading assistants to verify they flipped all the coins, the trading assistants are busy of course dealing with the Black Swan, and Analytics uses the Day 1 input 0 (since they cannot just make up inputs) and compute 0, translates it, and record it
Day 2: No Black Swan.
Oh, the trading assistant fixes the XL sheet for the trader that was missing an input because if that doesn’t get fixed and some trade gets printed using bad information they don’t get paid.
There is nothing special about the trading assistant with respect to the Pink Iguana. Forgotten inputs, transposed tables, missing/old translation tables, old versions of the Black Swan function, coins that have heads on both sides, miscommunication between Front Office and Back Office they are all Pink Iguanas. The simple Black Swan detection function presented here could be replaced with the “always perfect Black Swan forecasting function” and it cannot be expected to produce accurate output if it doesn’t get the right inputs at every step of the workflow.
