valuation of existing IR swap – example

Based on http://www.xavier.edu/williams/centers/trading-center/documents/research/edu_ppts/03_InterestRateSwaps.ppt (downloaded to C:\0x\88_xz_ref)

On P54 the “closing a swap position” discussion is … very relevant. Start at the example on P57.

On T+0, enter 5.5%/Libor swap as fixed payer.

On T+1Y, prevailing (par) swap rate drops to 5%. Bad for the fixed payer as she has commitment to pay 5.5%. She wants out, and she doesn’t need any more loan. You can assume she has cancelled her project altogether. So she would hedge out her floating exposure and realize any loss on the fixed leg.

Specifically, she enters a new swap as a fixed Receiver this time, receiving (the lower) 5%. The new floating leg perfectly cancels the existing floating leg, with identical payment dates.

As a result, for the next 4 semi-annual payments, she would receive 2.5% and pay 2.75% every time. This is the kind of loss she must accept when closing the swap in an unfavorable market. If you sum up the present value of these 4 negative cashflows, you see the (negative) present MV of the fixed position. (Note each swap deal has a $0 market value at inception.)

(The “fixed position” means the position of the fixed Payer.)

As of  T+1Y, the fixed position has a negative mark-to-market value given on P60, -$94,049 on a $10m notional.

It follows that to the original fixed Receiver, this existing swap deal now has a positive market value. Intuitively, this receiver is paying a below-market rate (5%/year) to receive the stream of floating coupons (i.e. the silver). The same stream is currently selling at 5.5%.

Yes it’s confusing! I feel the keys are
1) how to cancel out the floating leg exposure. You will then figure out that to close the swap, you need to take up a new fixed leg.
2) That would tell you the upcoming cashflows are positive or negative.
3) By summing up the PV of those cash flows you get the current MV.

Final MV formula is on P70.

HFT – some defining features

I learnt it from a seminar. I didn't do any research. Just some personal observations.

* HFT is different from a broker execution algo in terms of holding period. HFT never holds a position overnight.

* HFT is alpha-driven. In contrast, a sell-side trading engine is driven by customer flow.

** however, HFT doesn't use market orders as much as limit orders, so it may appear to be market-making.

* an HFT engine makes many, many trades in a day, but so does a broker execution algo.

* HFT usually makes no directional bet. In contrast, fundamental strategies have a view. I feel a sell-side often have a view and may hold inventory overnight.

I think the distinction can become unclear between HFT and execution algos.

slippage – several similar meanings

slippage = difference between 2 prices — the earlier quoted by an OTC dealer (FX, bond, swap…) vs the requote when you take that quote. In many quote-driven markets, all public quotes are always indicative.

slippage = difference between 2 prices – the EOD benchmark vwap vs your block order’s execution vwap, assuming order filled within a day.

slippage = difference between 2 prices – the price that triggered your trading signal vs execution price. see http://en.wikipedia.org/wiki/Implementation_shortfall

your compiler ^ the c++ standard

C++ has many compilers offering extensions.

Many developers write code based on the c++ standard. You could decide “if this operation fails, I would get this particular error according to the standard.”

Well, unless you are aiming for portability, you had better respect your local compiler more than the language standard. Your local compiler could add a “feature” and avoid raising that error. Side effect – you don't get “reminded” and you assume everything worked as expected – dangerous. There could be a compile-time warning but then it's often drowned in the noise. Poor signal/noise ratio.

My stance — know your compiler. Whenever the standard says some unusual condition should end in a certain way (or one of several ways), check your compiler's conformance.

It's also possible that the standard says this condition should return a null pointer or silently return, but a compiler adds a much-needed diagnostic feature to catch it. Sounds too good, but then the problem is, if you tweak some debug-build settings (or when you port your code to another compiler) you could lose the “reminders” that you depend on. Your code may appear to work in UAT but fail in production.

the "stream" concept in c++/c#/java

C had ascii/binary read/write functions. C++ introduced a family of “stream” classes as a complete replacement.

java and c# embraced and expanded the stream concepts and kissed goodby to the C legacy. I guess stream must be an immensely successful invention. Before we look at all the new stream classes like MemoryStream, GzipStream, StringStream… it’s good to understand the fundamental innovation. See http://www.cprogramming.com/tutorial/c++-iostreams.html.

I feel streams have become more versatile over the decades. Initially IO constructs for file and socket only. Then IPC. Then serialization. Then …

I particularly like the ostringstream — the “string builder” in c++.

Can we say the producer-consumer pattern is also stream-based? Probably not. Streams usually hold bytes or characters, not commands/tasks.