# To re-value? Or to approximate? That is the question 🎭 *Whether 'tis better in the UI to lag
The peaks and troughs of stochastic processes,
Or to differentiate against a sea of functions,
And with Taylor's expansion approximate them:
To tick, to lag no more* 🎭 I recently built a [trade blotter using client-side python](https://experimetal-swap-blotter.vercel.app). In it we are able to use all the financial abstractions provided by rateslib and other python libraries, without incurring server latency. This is made possible with client-side python which I wrote about [here](https://ex.periment.in/blog/rethinking-the-microservice). But aside from access to high level financial abstractions, UI code can also benefit from fast C-layer linear algebra numpy operations. In this post I wanted to discuss the numerical computations behind the real-time pricing aspects of this app. ## It all starts with Algorithmic Differentiation Modern pricing libraries include auto-diffing capabilities to track the derivatives of key financial operations. E.g. if an abstraction within the library represents a discounted value, then it will most likely be tracking its exposure to discount factors. [Rateslib](https://rateslib.com), the rates-focused pricing library I am using for these posts, uses a familiar Dual class to track real values along with their partial derivatives with respect to functions. Its API is typical of auto-diff libraries but completely embedded in a financial framework, giving you tools to propagate exposures through your model parameters and onto the source market data. And on top of this, Rateslib lets you write expressive, sometimes symbolic code to do all of this. ## Accurate Pricing VS Intuitive Sensitivities In my view pricing is as much about sensitivity as it is about valuation. There is always a tradeoff: the more accurate the valuation, the more parametrized the model often becomes, and the more convoluted the relationship between the instrument you are valuing and the parameters that play a role in its value. Stated more simply: the more accurate the price, the less intuitive its sensitivities become. To give an example, it is easier to think of the sensitivity of a swap’s valuation to the amount of convexity in a futures contract than the sensitivity of the swap to a Hull-White mean reversion parameter. However, from a pricing perspective, a curve built with hard-coded convexity assumptions is not as structurally sound as one built using even a simplistic process for the yield curve, but it is much more intuitive nonetheless. Ultimately, for a real-time application, a tradeoff must be made that seeks to maintain accuracy but also maximize the exposures to liquid market observables, so as to minimize the impact of static and unobservable valuation parameters on the price. For the purpose of this post, let’s use this feed as our sole model parametrization: In a real-time application we may need to re-price thousands of securities, multiple times per second. This operation might simply be impossible regardless of problem size, if model calibration exceeds the desired pricing interval. And it often does. This is one reason we may want to approximate our valuations. ## Approximate, but to what order? Ultimately any derivative price will have some curvature in its valuation. We can always separate the expectation value of the derivative, which depends on the modeled evolution of the market, from the deterministic function that discounts it. The latter will always contribute convexity. If we approximate its value to the first order given changes in rates that are also used in its discounting, we are certain to encounter approximation errors. Whereas if we extend a Taylor expansion to the second order, we can capture most of the local curvature for statically hedged instruments. Let’s have a look at one such instrument, a swap, priced off the feed above using an initial valuation with subsequent approximations to the first order: ### First Order This next graph is plotted against the fully revalued price of the swap described above under parallel shifts to the market data. You can see below how its delta-approximated price, plotted in green, holds to the linear function tangential to the value function at the expansion point. #### Error This next plot is the error adjusted for the swap's total risk, its DV01. By adjusting for DV01 we effectively create a map between the market data vector and the parallel-shift space of our visualization. I like this visualization because it captures risk more intuitively by asking the question: "How many basis points can our market data be off by before we call our pricing inaccurate?" The answer to this question can be applied here as a threshold to trigger full revaluations. ### Second Order Let's now go over the analysis so far using second order gamma approximations. Here is the same swap above, with each market data tick updating the valuation via a second order Taylor expansion. Delta approximations require us to multiply vectors of instrument sensitivities by the market data change vector. This required us to store per-swap sensitivity rows in our database. To capture our second-order change in valuation, we need to retrieve a matrix, what we call our cross gamma exposures. These are the partial derivatives of every partial derivative to each other. It is a symmetric matrix that we can compress by storing only a triangular component, but we are still left with a lot of additional data that needs to be managed in a scalable manner. It is possible to scale this to the trade level, but storage size grows by an order of magnitude. Using Taylor expansions our error can be arbitrarily small so long as we can tolerate our space complexity growing exponentially with each additional term. The benefit, of course, is a much improved approximation with greater accuracy between full revaluations, as you can see in this next chart which plots the valuation using gamma approximations. Or price is no longer bound to a tangential line but curves as we would expect of the real pricing function. #### Error Our error now is much smaller and, this time, cubic. The error is always a function dominated by the highest-order term we decided to ignore in our expansion. ## In Conclusion There will always be a next term, and it will always be possible to incorporate it, so long as we can accommodate an order of magnitude increase in: 1. original calculation time and process memory 2. database storage 3. transaction payload size Given the cost, it is sensible to apply a delta approximation in some situations and a gamma approximation in others. ### When to delta-approximate 1. Per-trade first order risk can frequently be stored with ease and then used for approximations or other purposes. Traders often want to see deltas, and they come in handy in call kinds of calculations as well. 2. Showing a trade-level breakdown of a portfolio likely benefits from ticking valuation updates on the first order. Clicking on one for example expresses intent and need for greater accuracy, a single trade can easily be fully revalued at that point. ### When to gamma-approximate 1. Cross-gamma risk can be stored at an aggregate level that is dependent on risk buckets important to your organization 2. You can track exposures to counterparties, portfolios, countries, etc by calculating second order sensitivities and accumulating them into their respective buckets of interest. ## Fully revaluing the book For the purposes of a real-time blotter, a full revaluation is beneficial when market data has moved beyond a certain threshold. What that threshold is, is itself an interesting question because its answer ultimately requires non-linear information about the current state of the market. A coarse-grained estimator usually plays a role here to quickly provide current error information, a subject I may be coming back to in a later post. A full revaluation need not be an EOD process. It is simply a question of cost and how aggressive your parallelization of the problem can be. There is the overhead of spinning up an environment, which incidentally this post has done in your device. Hitting refresh will show you it takes about 30 seconds to download the high-level financial libraries (rateslib) and all its C-level dependencies, (however that is not representative of anything other than your own local machine and the requirements of this post's analytics). Then there is the matter of loading market data and calibrating it. Depending on the number of market state variables (currencies, equities, vol surfaces, etc.), this can range from a few seconds to a few minutes. The most aggressive parallelization strategy would price the maximum number of trades and push to a database such that the overhead time expense is only marginally increased. The one aspect that cannot be parallelized is the time to calibrate, as every trade valuation depends on the calibration result. You can rely on the previous curve to provide the solver with a good guess for its next calibration, and you can parallelize the calibration of different curves if they do not depend on each other but are still required to value the portfolio. But there is no way to avoid paying whatever the price to calibrate is. When a price update is required but a recalibration cannot happen quickly enough, an approximation can provide the update. When an update is required and cashflow generation, not calibration, is the bottleneck, then an approximation must also be used. In this latter case we are likely talking about an aggregation of trades where it may be economical to store higher-order sensitivities so that a gamma approximation can be provided.