Hey people - thanks for the amazing work.
I’m comparing Strata results (for simple swaps) to Bloomberg’s terminal - and I’m getting pretty close results in PV01 (there is some offset, but that’s probably mostly the market data differences).
My question is about DV01 - it doesn’t seem like it’s supported in SwapFunctionGroups and I haven’t seen an example addressing that, is there something I’m missing?
Thanks
Hi and welcome to Strata
Currently, we define PV01 as the sum of the bucketed 1bp shifts to the underlying curve. This definition is closer to Bloomberg’s DV01 definition. We don’t have a specific measure that is close to Bloomberg’s PV01.
More generally, this emphasises a piece of work we were planning anyway to provide longer measure names for additional clarity. It also looks like there may be more measures to add too.
Hope this helps, and feel free to let us know if this is a major issue for you, or your use case in more detail.
Hey, thanks.
There is definitely some confusion around the PV01/DV01 definitions, so additional clarity will be a blessing.
I’ve just looked into the implementation of your PV01 and it does seem (to me) closer to what I know as DV01.
Although from what I remember (this might be out of date), Bloomberg actually moves the curve 0.5bp down and 0.5bp up and uses those for deltas.
My use case is a delta-approximation implementation of historical VaR (Taylor series) which is pretty commonly used for quick estimations by clearing houses.
For that I need the ability to create delta ladders with DV01 calculation, which Strata seems great for.
I have an outdated in-house implementation of DV01 using bootstrapping with a single curve which I’d really like to replace.
Thanks for the additional context. This makes complete sense. We are using Strata for exactly the same use-case in our Margining product, in our replication of the major clearing house methodologies.
As you probably saw in the code, our sensitivity calculations use algorithmic differentiation to obtain the first derivative (rather than a finite difference method) so you won’t see any explicit curve shifts, but it’s equivalent to a 1 bp shift. As Stephen said, we intend to make our measure names much more explicit to clarify them (e.g. to distinguish between par and zero rate sensitivities), and we’ll definitely look into providing any missing measures as well.
Please let us know if you have any more questions.
Looks interesting.
Is it provided as additional libraries (like Strata), or packaged as a product (more like OG-Platform)?
I’d obviously like my team to focus more on the business logic and less on quantitative finance, but our firm is a big believer in “Hey how hard can it be?” 
I’m kind of curious as to how you’re building the bp shift matrix - we used to get ours directly from the clearing houses (and that took quite a bit of sweet-talk). There were also some of issues with formats (e.g. CME and log returns, LCH and the absolute shifts).
That’s why I think you’re doing a great move with Strata. I think I’ve actually seen the Margin product page before, but just like other products (clearing houses or others), you can’t really find anything about the actual implementation and you kind of skip on. Once I saw Strata on github and got to actually look into the code I knew I could use it in more than one application we have running here.
Thanks for the quick replies, have good weekend guys.
We offer OpenGamma Margining both as libraries like Strata, and as a hosted service. The shifts come from the daily clearing house scenario or returns files we take in, and the format differences you mention are exactly the sort of thing we take care of.
Thanks for the feedback about Strata. We’re really pleased you can see its potential. Let us know if you have any suggestions, or want to discuss production support or our future development plans.
Have a good weekend!