Re: [Quantlib-users] QuantLibXL Addin

[Mike K. <mik...@gm...>]

Hi Eric,

It’s much simpler than that.

Here is an example of an option pricer in C++ with C like syntax that is not compiled against QuantLib directly, but instead uses the Python distribution of QuantLib. 

https://github.com/mkipnis/QuantLibAddin-Old/blob/pybind_experimental/QuantLibAddin/experimental/options.cpp

Essentially, I am calling the QuantLib from C++ the same way I would from the Python interpreter.
Notice that it uses a combination of QuantLib function calls and Python functions from the “/qlo/” directory.

With this approach, ObjectHandler remains, GenSrc is updated to replace the current QLO calls with pybind calls like those in the sample code above, and QuantLibAddin/qlo goes away because its functionality is replaced by SWIG.
 
This approach should preserve backward compatibility and simplify the build process, since there is no separate QLO compilation step that requires the QuantLib. It also avoids rebuilds for new QuantLib releases unless function signatures change, and it opens the door to the broader Python ecosystem.

See the build instructions: https://github.com/mkipnis/QuantLibAddin-Old/blob/pybind_experimental/QuantLibAddin/experimental/README.md

Once backward compatibility is addressed and Python can be called from the library, users can leverage JSON serialization of Python data structures.
For example, a proxy pricer could take a curve as input, send it to a Python-based mid-curve pricer, and have the pricer return the results as JSON. The workflow is simple: the user creates a JSON request in VBA, sends it to Python through the add-in, receives JSON results back, and displays them in Excel.

https://github.com/mkipnis/QuantLibAddin-Old/blob/pybind_experimental/QuantLibAddin/experimental/proxy_pricer.cpp
https://github.com/mkipnis/QuantLibAddin-Old/tree/pybind_experimental/QuantLibAddin/experimental/pricers
https://github.com/vba-tools/vba-json

Since more development and analysis is happening in Python than in VBA, while Excel remains the shared interface, this capability can be useful and may attract attention.
Beyond QuantLib integration, this approach could also be used to connect with other APIs for pulling market data, accessing databases, and integrating with LLM services.

And as a bonus, I would add an Excel ribbon similar to the ones in Bloomberg or YieldBook. These are easy to implement and users generally like them.
The ribbon could include sections such as Rates, Credit, Instruments, etc.  For example, the user could click “Curve” under Rates, and the sheet would automatically create a curve with default settings for the selected index. Then, under Instruments, the user could select “OIS” to price a swap at par against that curve.
This would remove much of the guesswork around which functions to call for curve bootstrapping and swap pricing. Although, this would probably be a separate project on its own.

To conclude, I think this project can be revived, as long as it positions itself as a bridge between Excel and Python, with QuantLib as its centerpiece.


Best Regards,
Mike


> On May 7, 2026, at 4:05 AM, Eric Ehlers <eri...@re...> wrote:
> 
> Hi Mike,
> 
> I took a closer look at pybind, I struggle to follow.
> - The C++ code in qlo, you would replace that with python?
> - Instead of autogenerating that code in C++, gensrc would autogenerate it in python?
> 
> And you would leave the rest of the build - ObjectHandler, the bindings to the Excel C API, etc. - unchanged?  So the motivation would be that coders extending QuantLibXL could look at python instead of C++?
> 
> That seems like a lot of pain for not much gain.  The fact that people who want to extend QuantLibXL need to know C++, this does not strike me as much of a barrier.  And the task of adding new QuantLib functions to QuantLibXL is probably much easier now using agents.
> 
> Regards,
> Eric
> 
> On 5/7/26 2:02 AM, Mike Kipnis wrote:
>> Hi Eric,
>> Yes — backward compatibility would be fully maintained.
>> The idea is to keep the existing QuantLibXL interface unchanged and only replace the internals: replace QuantLib/C++ calls in QuantLibAddin/qlo with QuantLib/Python calls, and replace the C++ bindings in gensrc with pybind.
>> From the Excel/user perspective nothing changes, so existing spreadsheets should continue to work as-is.
>> I will put together some pybind/C++ examples over the weekend to show how this would work in practice.
>> Regards,
>> Mike
>>> On May 6, 2026, at 5:05 AM, Eric Ehlers <eri...@re...> wrote:
>>> 
>>> Hi Mike,
>>> 
>>> Many thanks for your recommendations.  There is no doubt that the design of QuantLibXL could be improved.  One advantage of the existing design is that it uses the Excel C API, last time I checked, there was still no faster way to interface with Excel.  Even if we were to stick with the Excel C API, there are probably better ways to go about it, and I also think that you could make a case for migrating to pybind.
>>> 
>>> One goal that I have always had for QuantLibXL is to maintain backward compatibility.  Your proposed approach, would it maintain the same interface?  Otherwise I would consider it a new project, something that could live alongside the existing QuantLibXL.
>>> 
>>> Regards,
>>> Eric
>