quantlib-users — QuantLib users discussion list

[Quantlib-users] AADC Tracer for QuantLib, and a question to try it on

[Natalija K. <nat...@ma...>]

Hi all,

Dmitri Goloubentsev presented the AADC Tracer at the WBS Quant Finance
Conference in Valletta this month. It records a QuantLib calculation and
links each input, constant and executed branch to the source line that used
it, so you can see what actually produced a number. It is built on AADC,
our AAD compiler, which is in production at major banks.

Here is a small question to try it on. A 25-line pricer for a European
swaption, Hull-White model, Jamshidian engine: how many hard-coded
constants reach its price? Make a guess from the code first, then run
(Linux x86-64 or macOS on Apple silicon, Python 3.10 to 3.14; on Windows,
the product page below has a browser version):

python3 -m venv tracer && . tracer/bin/activate
pip install "aadc==2.25.2" "aadc-quantlib-tracing==1.41.4"
curl -O https://matlogica.com/downloads/swaption.py -O
https://matlogica.com/downloads/swaption_trace.py
python swaption_trace.py

It records one pricing and prints the price, the number of constant sites
and the number of branches the run fixed. f.traced_leaves() then gives each
constant with its file and line.

The Tracer is free for non-commercial and academic use; details are on
the product
page
<https://matlogica.com/products/aadc-tracer/?utm_campaign=crm&utm_source=email&utm_medium=direct&tid=quantlib-users-list-2026-10-23-01>
.

If you try it on your own pricing code, I'd like to hear what you traced.
Thanks again to Luigi for adding the Tracer to the QuantLib extensions page.

Best regards,
Natalija,
MatLogica

*About AADC: it turns object-oriented C++ and Python code into optimised
machine code at run time, with an adjoint factor below 1, so all
first-order Greeks cost less than one extra pricing. An AAD-enabled
QuantLib is on PyPI (pip install aadc-quantlib), and AADC also accelerates
ORE. Recent recognition: Celent Technology Standout 2027, Global BankTech
Awards 2026 winner, and Chartis Category Leader in AAD every year since
2023.*

[Quantlib-users] quantlib-takt: QuantLib 1.43 Python wheel with faster European Monte Carlo, identical results

[Dmitry (TAKT) <he...@ta...>]

Hello all,

Luigi kindly suggested I write here about a package we published on PyPI, quantlib-takt. I run TAKT, a small company, so please read this as a note from a vendor. TAKT is not affiliated with or endorsed by the QuantLib project.

What it is: the official QuantLib 1.43 Python wheel with only the bundled C++ library replaced by our build. `import QuantLib` and the API are unchanged. On the same machine every result is identical to the official wheel, bit for bit.

What is faster in the free package: European options priced by Monte Carlo, including Sobol paths and Greeks by bumping. End to end from Python (the whole process, interpreter start included), our test cases run roughly 4x to 18x faster in wall time; the largest gain is on Greeks by bumping. Everything else (Asian, American LSM, barrier, basket, Heston, local volatility, and all non-Monte-Carlo engines) runs the original code at the original speed. A commercial licence covers those engines and the C++ library; the free package has no time limit.

How we checked: 867 printed results from a C++ driver and 270 through Python, compared at 17 significant digits and as hex floats; QuantLib's C++ test suite (1,339 cases) and the QuantLib-SWIG Python tests also pass with our library.

Limits: Linux x86-64 only, Python 3.9 to 3.13, and it is still QuantLib 1.43, not 1.44.
To try it: pip uninstall -y QuantLib && pip install quantlib-takt

One observation that may be useful regardless of our package: the official 1.43 build itself prints slightly different last digits on different glibc versions (205 of 840 printed numbers differ between glibc 2.28 and 2.39), because the results go through the system maths library. Notes: https://taktcycles.com/notes/quantlib-glibc-last-digits.html

Measurements and scripts: https://taktcycles.com/showcase/quantlib-mc/README.html
Package: https://pypi.org/project/quantlib-takt/

Questions and criticism are welcome, here or at he...@ta....

Dmitry
TAKT (ABX DEVELOPMENT LLP, Edinburgh) 

Re: [Quantlib-users] Release candidate for QuantLib 1.44

[Dirk E. <ed...@de...>]

On 14 October 2026 at 21:59, Luigi Ballabio wrote:
| Yes, same problem, I guess.  Are you necessarily getting the sources from
| git, or is there any chance you can use the released tarball at <
| https://github.com/lballabio/QuantLib-SWIG/releases/download/v1.44/QuantLib-SWIG-1.44.tar.gz
| >?

Ah, that explains it. In short: "too clever by half".  I use the Debian tool
uscan as a watch, it operates with a small config file part of my debian/
directory -- and it was looking at _tags_ rather than releases and hence
likely freshing taring up and compressing something ... that was not the
.tar.gz you provide. 

So entirely my error.  Will try to remember for next time.

Dirk

| 
| On Wed, Oct 14, 2026 at 7:26 PM Dirk Eddelbuettel <ed...@de...> wrote:
| 
| >
| > On 12 October 2026 at 06:15, Dirk Eddelbuettel wrote:
| > |
| > | On 12 October 2026 at 08:22, Luigi Ballabio wrote:
| > | | Hi Dirk, I suspect it's because 26.04 still carries swig 4.4.0.  We're
| > | | currently using the latest, 4.5.1.  I'm not sure how to solve the
| > problem
| > | | of versions lagging behind, other than relying on our tarballs (that
| > | | already contain the generated wrapper, but that I haven't provided for
| > the
| > | | pre-release; I might do that next time though).
| > |
| > | That explains perfectly why it all built for Debian unstable/testing :)
| > Not
| > | to worry, I keep that in mind for next time. There was a reason I didn't
| > | usually bothered with the SWIG rc builds...
| >
| > Sadly the same thing happened with 1.44 at launchpad:
| >
| >
| > https://launchpadlibrarian.net/880972573/buildlog_ubuntu-resolute-amd64.quantlib-swig_1.44-0.2604.0_BUILDING.txt.gz
| >
| > I appear to have skipped 1.43 there but 1.42 did build.
| >
| > Dirk
| >
| > --
| > dirk.eddelbuettel.com | @eddelbuettel | ed...@de...
| >

-- 
dirk.eddelbuettel.com | @eddelbuettel | ed...@de...

Re: [Quantlib-users] Release candidate for QuantLib 1.44

[Luigi B. <lui...@gm...>]

Yes, same problem, I guess.  Are you necessarily getting the sources from
git, or is there any chance you can use the released tarball at <
https://github.com/lballabio/QuantLib-SWIG/releases/download/v1.44/QuantLib-SWIG-1.44.tar.gz
>?

On Wed, Oct 14, 2026 at 7:26 PM Dirk Eddelbuettel <ed...@de...> wrote:

>
> On 12 October 2026 at 06:15, Dirk Eddelbuettel wrote:
> |
> | On 12 October 2026 at 08:22, Luigi Ballabio wrote:
> | | Hi Dirk, I suspect it's because 26.04 still carries swig 4.4.0.  We're
> | | currently using the latest, 4.5.1.  I'm not sure how to solve the
> problem
> | | of versions lagging behind, other than relying on our tarballs (that
> | | already contain the generated wrapper, but that I haven't provided for
> the
> | | pre-release; I might do that next time though).
> |
> | That explains perfectly why it all built for Debian unstable/testing :)
> Not
> | to worry, I keep that in mind for next time. There was a reason I didn't
> | usually bothered with the SWIG rc builds...
>
> Sadly the same thing happened with 1.44 at launchpad:
>
>
> https://launchpadlibrarian.net/880972573/buildlog_ubuntu-resolute-amd64.quantlib-swig_1.44-0.2604.0_BUILDING.txt.gz
>
> I appear to have skipped 1.43 there but 1.42 did build.
>
> Dirk
>
> --
> dirk.eddelbuettel.com | @eddelbuettel | ed...@de...
>

Re: [Quantlib-users] Release candidate for QuantLib 1.44

[Dirk E. <ed...@de...>]

On 12 October 2026 at 06:15, Dirk Eddelbuettel wrote:
| 
| On 12 October 2026 at 08:22, Luigi Ballabio wrote:
| | Hi Dirk, I suspect it's because 26.04 still carries swig 4.4.0.  We're
| | currently using the latest, 4.5.1.  I'm not sure how to solve the problem
| | of versions lagging behind, other than relying on our tarballs (that
| | already contain the generated wrapper, but that I haven't provided for the
| | pre-release; I might do that next time though).
| 
| That explains perfectly why it all built for Debian unstable/testing :)  Not
| to worry, I keep that in mind for next time. There was a reason I didn't
| usually bothered with the SWIG rc builds...

Sadly the same thing happened with 1.44 at launchpad:

https://launchpadlibrarian.net/880972573/buildlog_ubuntu-resolute-amd64.quantlib-swig_1.44-0.2604.0_BUILDING.txt.gz

I appear to have skipped 1.43 there but 1.42 did build.

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | ed...@de...

[Quantlib-users] QuantLib 1.44 released

[Luigi B. <lui...@gm...>]

QuantLib 1.44 is now available for download at <
https://www.quantlib.org/download.shtml>; precompiled binaries are also
available from PyPI and NuGet for Python and C# respectively.

The list of changes for this release is at <
https://github.com/lballabio/QuantLib/releases/tag/v1.44>.

If you have any problems with this release, please report them here on the
QuantLib mailing list (<qua...@li...>) or open a
GitHub issue at <https://github.com/lballabio/quantlib/issues>.

[Quantlib-users] QuantLib and ORE birthdays

[Peter C. <pca...@gm...>]

Dear all,

QuantLib was first released over 25 years ago and 10 years ago we released
our extension library ORE. We want to celebrate this in Frankfurt on
November 5:

https://solutions.lseg.com/ORE_10Years_Anniversary

Registration is free. Looking forward to seeing you there.

Best
Peter

Re: [Quantlib-users] Release candidate for QuantLib 1.44

[Dirk E. <ed...@de...>]

On 12 October 2026 at 08:22, Luigi Ballabio wrote:
| Hi Dirk, I suspect it's because 26.04 still carries swig 4.4.0.  We're
| currently using the latest, 4.5.1.  I'm not sure how to solve the problem
| of versions lagging behind, other than relying on our tarballs (that
| already contain the generated wrapper, but that I haven't provided for the
| pre-release; I might do that next time though).

That explains perfectly why it all built for Debian unstable/testing :)  Not
to worry, I keep that in mind for next time. There was a reason I didn't
usually bothered with the SWIG rc builds...

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | ed...@de...

Re: [Quantlib-users] Release candidate for QuantLib 1.44

[Luigi B. <lui...@gm...>]

Hi Dirk, I suspect it's because 26.04 still carries swig 4.4.0.  We're
currently using the latest, 4.5.1.  I'm not sure how to solve the problem
of versions lagging behind, other than relying on our tarballs (that
already contain the generated wrapper, but that I haven't provided for the
pre-release; I might do that next time though).


On Sun, Oct 11, 2026 at 12:18 AM Dirk Eddelbuettel <ed...@de...> wrote:

>
> On 9 October 2026 at 09:29, Dirk Eddelbuettel wrote:
> |
> | On 9 October 2026 at 09:12, Dirk Eddelbuettel wrote:
> | | No SWIG release candidate this time?
> |
> | Never mind. I once again fell for 'tagged but no (pre-)release'.  Built
> and
> | uploaded too.
>
> quantlib-swig failed at launchpad.net for 26.04 for both amd64 and arm64.
> Log
> for the former is at
>
>
> https://launchpadlibrarian.net/880333797/buildlog_ubuntu-resolute-amd64.quantlib-swig_1.43.99-0.2604.0_BUILDING.txt.gz
>
> and contains this
>
> src/QuantLib/quantlib_wrap.cpp: In function ‘PyObject*
> SWIG_runtime_data_module()’:
> src/QuantLib/quantlib_wrap.cpp:1455:39: error: ‘PyImport_AddModuleRef’ was
> not declared in this scope; did you mean ‘PyImport_AddModule’?
>  1455 |     Swig_runtime_data_module_global =
> PyImport_AddModuleRef(SWIG_RUNTIME_MODULE);
>       |                                       ^~~~~~~~~~~~~~~~~~~~~
>       |                                       PyImport_AddModule
> src/QuantLib/quantlib_wrap.cpp: In function ‘int
> SwigPyObject_Check(PyObject*)’:
> src/QuantLib/quantlib_wrap.cpp:1057:44: error:
> ‘PyType_GetFullyQualifiedName’ was not declared in this scope; did you mean
> ‘SWIG_PyType_GetFullyQualifiedName’?
>  1057 | # define SWIG_PyType_GetFullyQualifiedName
> PyType_GetFullyQualifiedName
>       |
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
> src/QuantLib/quantlib_wrap.cpp:2127:24: note: in expansion of macro
> ‘SWIG_PyType_GetFullyQualifiedName’
>  2127 |     PyObject *tpname = SWIG_PyType_GetFullyQualifiedName(op_type);
>       |                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> src/QuantLib/quantlib_wrap.cpp: In function ‘int
> SwigPyPacked_Check(PyObject*)’:
> src/QuantLib/quantlib_wrap.cpp:1057:44: error:
> ‘PyType_GetFullyQualifiedName’ was not declared in this scope; did you mean
> ‘SWIG_PyType_GetFullyQualifiedName’?
>  1057 | # define SWIG_PyType_GetFullyQualifiedName
> PyType_GetFullyQualifiedName
>       |
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
> src/QuantLib/quantlib_wrap.cpp:2544:24: note: in expansion of macro
> ‘SWIG_PyType_GetFullyQualifiedName’
>  2544 |     PyObject *tpname = SWIG_PyType_GetFullyQualifiedName(op_type);
>       |                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> src/QuantLib/quantlib_wrap.cpp: In function ‘swig_type_info*
> SWIG_Python_TypeQuery(const char*)’:
> src/QuantLib/quantlib_wrap.cpp:1114:39: error: ‘PyDict_GetItemStringRef’
> was not declared in this scope; did you mean ‘PyDict_GetItemString’?
>  1114 | # define SWIG_PyDict_GetItemStringRef PyDict_GetItemStringRef
>       |                                       ^~~~~~~~~~~~~~~~~~~~~~~
> src/QuantLib/quantlib_wrap.cpp:3277:3: note: in expansion of macro
> ‘SWIG_PyDict_GetItemStringRef’
>  3277 |   SWIG_PyDict_GetItemStringRef(cache, type, &obj);
>       |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
> src/QuantLib/quantlib_wrap.cpp: In function ‘MatrixRow
> Matrix___getitem__(QuantLib::Matrix*, QuantLib::Integer)’:
> src/QuantLib/quantlib_wrap.cpp:10411:29: warning: comparison of integer
> expressions of different signedness: ‘QuantLib::Integer’ {aka ‘int’} and
> ‘QuantLib::Size’ {aka ‘long unsigned int’} [-Wsign-compare]
> 10411 |             if (i >= 0 && i < self->rows())
>       |                           ~~^~~~~~~~~~~~~~
> In file included from /usr/include/ql/patterns/observable.hpp:32,
>                  from /usr/include/ql/event.hpp:29,
>                  from /usr/include/ql/cashflow.hpp:28,
>                  from /usr/include/ql/quantlib.hpp:11,
>                  from src/QuantLib/quantlib_wrap.cpp:6559:
> src/QuantLib/quantlib_wrap.cpp: In member function ‘const
> std::vector<double> OdeFct::operator()(QuantLib::Real, const
> std::vector<double>&) const’:
> src/QuantLib/quantlib_wrap.cpp:19453:73: warning: comparison of integer
> expressions of different signedness: ‘Py_ssize_t’ {aka ‘long int’} and
> ‘std::vector<double>::size_type’ {aka ‘long unsigned int’} [-Wsign-compare]
> 19453 |             PyList_Check(pyResult.get()) &&
> PyList_Size(pyResult.get()) == y.size(),
>       |
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
> error: command '/usr/bin/x86_64-linux-gnu-g++' failed with exit code 1
> E: pybuild pybuild:485: build: plugin distutils failed with: exit code=1:
> /usr/bin/python3 setup.py build
>
> which looks like a Python / SWIG issue?  Luigi, any idea about this?
>
> Dirk
>
> --
> dirk.eddelbuettel.com | @eddelbuettel | ed...@de...
>

Re: [Quantlib-users] Release candidate for QuantLib 1.44

[Dirk E. <ed...@de...>]

On 9 October 2026 at 09:29, Dirk Eddelbuettel wrote:
| 
| On 9 October 2026 at 09:12, Dirk Eddelbuettel wrote:
| | No SWIG release candidate this time?
| 
| Never mind. I once again fell for 'tagged but no (pre-)release'.  Built and
| uploaded too.

quantlib-swig failed at launchpad.net for 26.04 for both amd64 and arm64. Log
for the former is at

https://launchpadlibrarian.net/880333797/buildlog_ubuntu-resolute-amd64.quantlib-swig_1.43.99-0.2604.0_BUILDING.txt.gz

and contains this

src/QuantLib/quantlib_wrap.cpp: In function ‘PyObject* SWIG_runtime_data_module()’:
src/QuantLib/quantlib_wrap.cpp:1455:39: error: ‘PyImport_AddModuleRef’ was not declared in this scope; did you mean ‘PyImport_AddModule’?
 1455 |     Swig_runtime_data_module_global = PyImport_AddModuleRef(SWIG_RUNTIME_MODULE);
      |                                       ^~~~~~~~~~~~~~~~~~~~~
      |                                       PyImport_AddModule
src/QuantLib/quantlib_wrap.cpp: In function ‘int SwigPyObject_Check(PyObject*)’:
src/QuantLib/quantlib_wrap.cpp:1057:44: error: ‘PyType_GetFullyQualifiedName’ was not declared in this scope; did you mean ‘SWIG_PyType_GetFullyQualifiedName’?
 1057 | # define SWIG_PyType_GetFullyQualifiedName PyType_GetFullyQualifiedName
      |                                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/QuantLib/quantlib_wrap.cpp:2127:24: note: in expansion of macro ‘SWIG_PyType_GetFullyQualifiedName’
 2127 |     PyObject *tpname = SWIG_PyType_GetFullyQualifiedName(op_type);
      |                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/QuantLib/quantlib_wrap.cpp: In function ‘int SwigPyPacked_Check(PyObject*)’:
src/QuantLib/quantlib_wrap.cpp:1057:44: error: ‘PyType_GetFullyQualifiedName’ was not declared in this scope; did you mean ‘SWIG_PyType_GetFullyQualifiedName’?
 1057 | # define SWIG_PyType_GetFullyQualifiedName PyType_GetFullyQualifiedName
      |                                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/QuantLib/quantlib_wrap.cpp:2544:24: note: in expansion of macro ‘SWIG_PyType_GetFullyQualifiedName’
 2544 |     PyObject *tpname = SWIG_PyType_GetFullyQualifiedName(op_type);
      |                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/QuantLib/quantlib_wrap.cpp: In function ‘swig_type_info* SWIG_Python_TypeQuery(const char*)’:
src/QuantLib/quantlib_wrap.cpp:1114:39: error: ‘PyDict_GetItemStringRef’ was not declared in this scope; did you mean ‘PyDict_GetItemString’?
 1114 | # define SWIG_PyDict_GetItemStringRef PyDict_GetItemStringRef
      |                                       ^~~~~~~~~~~~~~~~~~~~~~~
src/QuantLib/quantlib_wrap.cpp:3277:3: note: in expansion of macro ‘SWIG_PyDict_GetItemStringRef’
 3277 |   SWIG_PyDict_GetItemStringRef(cache, type, &obj);
      |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/QuantLib/quantlib_wrap.cpp: In function ‘MatrixRow Matrix___getitem__(QuantLib::Matrix*, QuantLib::Integer)’:
src/QuantLib/quantlib_wrap.cpp:10411:29: warning: comparison of integer expressions of different signedness: ‘QuantLib::Integer’ {aka ‘int’} and ‘QuantLib::Size’ {aka ‘long unsigned int’} [-Wsign-compare]
10411 |             if (i >= 0 && i < self->rows())
      |                           ~~^~~~~~~~~~~~~~
In file included from /usr/include/ql/patterns/observable.hpp:32,
                 from /usr/include/ql/event.hpp:29,
                 from /usr/include/ql/cashflow.hpp:28,
                 from /usr/include/ql/quantlib.hpp:11,
                 from src/QuantLib/quantlib_wrap.cpp:6559:
src/QuantLib/quantlib_wrap.cpp: In member function ‘const std::vector<double> OdeFct::operator()(QuantLib::Real, const std::vector<double>&) const’:
src/QuantLib/quantlib_wrap.cpp:19453:73: warning: comparison of integer expressions of different signedness: ‘Py_ssize_t’ {aka ‘long int’} and ‘std::vector<double>::size_type’ {aka ‘long unsigned int’} [-Wsign-compare]
19453 |             PyList_Check(pyResult.get()) && PyList_Size(pyResult.get()) == y.size(),
      |                                             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
error: command '/usr/bin/x86_64-linux-gnu-g++' failed with exit code 1
E: pybuild pybuild:485: build: plugin distutils failed with: exit code=1: /usr/bin/python3 setup.py build 

which looks like a Python / SWIG issue?  Luigi, any idea about this?

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | ed...@de...

Re: [Quantlib-users] Release candidate for QuantLib 1.44

[Dirk E. <ed...@de...>]

On 9 October 2026 at 09:12, Dirk Eddelbuettel wrote:
| No SWIG release candidate this time?

Never mind. I once again fell for 'tagged but no (pre-)release'.  Built and
uploaded too.

Cheers, Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | ed...@de...

Re: [Quantlib-users] Release candidate for QuantLib 1.44

[Dirk E. <ed...@de...>]

Hi Luigi,

Was away last weekend and then got distracted but Debian builds are up, and
look good, see  https://buildd.debian.org/status/package.php?p=quantlib

My PPA also has an Ubuntu 26.04 build I used with RQuantLib where adjusted to
two deprecations.

No SWIG release candidate this time?

Cheers, Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | ed...@de...

[Quantlib-users] Release candidate for QuantLib 1.44

[Luigi B. <lui...@gm...>]

Hi all,
   a release candidate for QuantLib 1.44 is available at <
https://github.com/lballabio/QuantLib/releases/tag/v1.44-rc>.  Python
wheels are also available at <
https://test.pypi.org/project/QuantLib/1.44rc0/>, and a C# NuGet package is
at <https://int.nugettest.org/packages/QuantLib/1.44.0-rc>.  If you have
some time, please try it out and report any issues on GitHub (or here on
the mailing list).  Thanks!

  Luigi

[Quantlib-users] QuantLibAddin 1.42.0 Released

[Eric E. <eri...@re...>]

We have released QuantLibAddin (including QuantLibXL, ObjectHandler, and 
gensrc) version 1.42.0.

Compiled XLLs, example spreadsheets, and documentation are available for 
download at this link:

https://github.com/eehlers/QuantLibAddIn/releases/tag/v1.42.0

Instructions for compiling from source code are available at this link:

https://github.com/eehlers/QuantLibAddIn

The pages for the four projects have been updated:

https://quantlibxl.org
https://quantlibaddin.org
https://objecthandler.org
https://gensrc.org

[Quantlib-users] C++ vs. Python: American Options Pricing in a Distributed Environment

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

Hi QuantLib Community,

I’d like to share the results of an experiment comparing C++ and Python for pricing American options in a distributed environment.

Both implementations run as microservices across two hosts in a Docker Swarm, using multithreaded C++ and asynchronous Python with CPU-matched workers.

Using a fire-and-forget model, I compared both approaches under the same workload in terms of throughput and latency.
I thought the results might be interesting, so I wanted to share them with you.

https://github.com/mkipnis/ql_rest/tree/master/experimental/options

Best Regards,
Mike

Re: [Quantlib-users] ConstNotionalCrossCurrencyBasisSwapRateHelper with Different Payment Frequencies on Each Leg

[Quant <qua...@gm...>]

Hi Luigi,

Noted and thanks. This helps a lot.

Regards,
Nk


On Tue, 28 Jul 2026 at 17:11, Luigi Ballabio <lui...@gm...>
wrote:

> Hi, the MtM swaps are in progress, see
> https://github.com/lballabio/QuantLib/pull/2642 .  Hopefully they'll be
> in next release but they're a lot more complex than the const-notional
> swaps and we might have to iron them out.  A workaround for MtM swaps is
> documented at https://www.quantlibguide.com/Cross-currency%20swaps.html
> but with caveats (also documented).
>
> Hope this helps,
>     Luigi
>
>
> On Tue, Jul 28, 2026 at 4:10 PM Quant <qua...@gm...> wrote:
>
>> Hi Luigi,
>>
>> Thank you for your feedback on my earlier email regarding bootstrapping a
>> cross-currency basis-adjusted discount curve using
>> ConstNotionalCrossCurrencyBasisSwapRateHelper and
>> MtMCrossCurrencyBasisSwapRateHelper, particularly in relation to the
>> support for asymmetric payment frequency conventions introduced in the
>> QuantLib 1.43 release.
>>
>> I noticed that QuantLib 1.43 now includes the following instruments:
>>
>>    - ql.ConstNotionalCrossCurrencyBasisSwap()
>>    - ql.ConstNotionalCrossCurrencySwap()
>>    - ql.ConstNotionalCrossCurrencyFixedVsFloatingSwap()
>>
>> I wanted to check whether the mark-to-market (MtM) equivalents of these
>> instruments have not yet been implemented, or whether there is an
>> alternative or recommended workaround for modeling MtM cross-currency swaps
>> using the constant notional implementations above.
>>
>> I would appreciate any guidance you can provide.
>>
>> Thanks and regards,
>>
>> Nk
>>
>> On Thu, Jun 18, 2026 at 9:09 AM Luigi Ballabio <lui...@gm...>
>> wrote:
>>
>>> Hi, this was added recently — see
>>> https://github.com/lballabio/QuantLib/pull/2528.  It will be available
>>> in release 1.43 out next month.
>>>
>>> Regards,
>>>     Luigi
>>>
>>>
>>> On Wed, Jun 17, 2026 at 5:30 PM Quant <qua...@gm...> wrote:
>>>
>>>> Dear QuantLib users,
>>>>
>>>> I am currently bootstrapping a cross-currency basis-adjusted discount
>>>> curve using ConstNotionalCrossCurrencyBasisSwapRateHelper and have a
>>>> question regarding payment frequency conventions.
>>>>
>>>> The helper accepts a single paymentFrequency parameter, which appears
>>>> to be applied to both legs of the underlying cross-currency basis swap:
>>>>
>>>> ccbs_helpers = [
>>>>     ql.ConstNotionalCrossCurrencyBasisSwapRateHelper(
>>>>         ql.QuoteHandle(ql.SimpleQuote(basis / 10000)),
>>>>         ql.Period(*tenor),
>>>>         2,
>>>>         calendar,
>>>>         ql.Following,
>>>>         False,
>>>>         sonia,
>>>>         sofr,
>>>>         sonia_ts,
>>>>         True,
>>>>         False,
>>>>         paymentFrequency=ql.Quarterly
>>>>     )
>>>>     for basis, tenor in ...
>>>> ]
>>>>
>>>> My question is: how should one handle market instruments where the two
>>>> floating legs have different payment frequencies? For example when I
>>>> inquired with my market data provider, they indicated that for their quotes:
>>>>
>>>>    -
>>>>
>>>>    SONIA leg pays annually
>>>>    -
>>>>
>>>>    SOFR leg pays quarterly
>>>>
>>>> Is there a way to specify separate payment frequencies for each leg
>>>> when using ConstNotionalCrossCurrencyBasisSwapRateHelper or
>>>> MtMCrossCurrencyBasisSwapRateHelper, or is the helper designed under
>>>> the assumption that both legs share the same payment schedule?
>>>>
>>>> If different frequencies are required, is the recommended approach to:
>>>>
>>>>    1.
>>>>
>>>>    Build a custom cross-currency swap instrument with separate
>>>>    schedules for each leg and create a custom RateHelper; or
>>>>    2.
>>>>
>>>>    Approximate the market convention using a common frequency for both
>>>>    legs?
>>>>
>>>> I would appreciate any guidance on how QuantLib intends such
>>>> instruments to be handled and whether there are examples of bootstrapping a
>>>> CCS basis curve when the two legs have different payment frequencies.
>>>>
>>>> Thank you for your help.
>>>>
>>>> Kind regards,
>>>>
>>>> Nk
>>>> _______________________________________________
>>>> QuantLib-users mailing list
>>>> Qua...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>>
>>>

Re: [Quantlib-users] ConstNotionalCrossCurrencyBasisSwapRateHelper with Different Payment Frequencies on Each Leg

[Luigi B. <lui...@gm...>]

Hi, the MtM swaps are in progress, see
https://github.com/lballabio/QuantLib/pull/2642 .  Hopefully they'll be in
next release but they're a lot more complex than the const-notional swaps
and we might have to iron them out.  A workaround for MtM swaps is
documented at https://www.quantlibguide.com/Cross-currency%20swaps.html but
with caveats (also documented).

Hope this helps,
    Luigi


On Tue, Jul 28, 2026 at 4:10 PM Quant <qua...@gm...> wrote:

> Hi Luigi,
>
> Thank you for your feedback on my earlier email regarding bootstrapping a
> cross-currency basis-adjusted discount curve using
> ConstNotionalCrossCurrencyBasisSwapRateHelper and
> MtMCrossCurrencyBasisSwapRateHelper, particularly in relation to the
> support for asymmetric payment frequency conventions introduced in the
> QuantLib 1.43 release.
>
> I noticed that QuantLib 1.43 now includes the following instruments:
>
>    - ql.ConstNotionalCrossCurrencyBasisSwap()
>    - ql.ConstNotionalCrossCurrencySwap()
>    - ql.ConstNotionalCrossCurrencyFixedVsFloatingSwap()
>
> I wanted to check whether the mark-to-market (MtM) equivalents of these
> instruments have not yet been implemented, or whether there is an
> alternative or recommended workaround for modeling MtM cross-currency swaps
> using the constant notional implementations above.
>
> I would appreciate any guidance you can provide.
>
> Thanks and regards,
>
> Nk
>
> On Thu, Jun 18, 2026 at 9:09 AM Luigi Ballabio <lui...@gm...>
> wrote:
>
>> Hi, this was added recently — see
>> https://github.com/lballabio/QuantLib/pull/2528.  It will be available
>> in release 1.43 out next month.
>>
>> Regards,
>>     Luigi
>>
>>
>> On Wed, Jun 17, 2026 at 5:30 PM Quant <qua...@gm...> wrote:
>>
>>> Dear QuantLib users,
>>>
>>> I am currently bootstrapping a cross-currency basis-adjusted discount
>>> curve using ConstNotionalCrossCurrencyBasisSwapRateHelper and have a
>>> question regarding payment frequency conventions.
>>>
>>> The helper accepts a single paymentFrequency parameter, which appears
>>> to be applied to both legs of the underlying cross-currency basis swap:
>>>
>>> ccbs_helpers = [
>>>     ql.ConstNotionalCrossCurrencyBasisSwapRateHelper(
>>>         ql.QuoteHandle(ql.SimpleQuote(basis / 10000)),
>>>         ql.Period(*tenor),
>>>         2,
>>>         calendar,
>>>         ql.Following,
>>>         False,
>>>         sonia,
>>>         sofr,
>>>         sonia_ts,
>>>         True,
>>>         False,
>>>         paymentFrequency=ql.Quarterly
>>>     )
>>>     for basis, tenor in ...
>>> ]
>>>
>>> My question is: how should one handle market instruments where the two
>>> floating legs have different payment frequencies? For example when I
>>> inquired with my market data provider, they indicated that for their quotes:
>>>
>>>    -
>>>
>>>    SONIA leg pays annually
>>>    -
>>>
>>>    SOFR leg pays quarterly
>>>
>>> Is there a way to specify separate payment frequencies for each leg when
>>> using ConstNotionalCrossCurrencyBasisSwapRateHelper or
>>> MtMCrossCurrencyBasisSwapRateHelper, or is the helper designed under
>>> the assumption that both legs share the same payment schedule?
>>>
>>> If different frequencies are required, is the recommended approach to:
>>>
>>>    1.
>>>
>>>    Build a custom cross-currency swap instrument with separate
>>>    schedules for each leg and create a custom RateHelper; or
>>>    2.
>>>
>>>    Approximate the market convention using a common frequency for both
>>>    legs?
>>>
>>> I would appreciate any guidance on how QuantLib intends such instruments
>>> to be handled and whether there are examples of bootstrapping a CCS basis
>>> curve when the two legs have different payment frequencies.
>>>
>>> Thank you for your help.
>>>
>>> Kind regards,
>>>
>>> Nk
>>> _______________________________________________
>>> QuantLib-users mailing list
>>> Qua...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>
>>

Re: [Quantlib-users] ConstNotionalCrossCurrencyBasisSwapRateHelper with Different Payment Frequencies on Each Leg

[Quant <qua...@gm...>]

Hi Luigi,

Thank you for your feedback on my earlier email regarding bootstrapping a
cross-currency basis-adjusted discount curve using
ConstNotionalCrossCurrencyBasisSwapRateHelper and
MtMCrossCurrencyBasisSwapRateHelper, particularly in relation to the
support for asymmetric payment frequency conventions introduced in the
QuantLib 1.43 release.

I noticed that QuantLib 1.43 now includes the following instruments:

   - ql.ConstNotionalCrossCurrencyBasisSwap()
   - ql.ConstNotionalCrossCurrencySwap()
   - ql.ConstNotionalCrossCurrencyFixedVsFloatingSwap()

I wanted to check whether the mark-to-market (MtM) equivalents of these
instruments have not yet been implemented, or whether there is an
alternative or recommended workaround for modeling MtM cross-currency swaps
using the constant notional implementations above.

I would appreciate any guidance you can provide.

Thanks and regards,

Nk

On Thu, Jun 18, 2026 at 9:09 AM Luigi Ballabio <lui...@gm...>
wrote:

> Hi, this was added recently — see
> https://github.com/lballabio/QuantLib/pull/2528.  It will be available in
> release 1.43 out next month.
>
> Regards,
>     Luigi
>
>
> On Wed, Jun 17, 2026 at 5:30 PM Quant <qua...@gm...> wrote:
>
>> Dear QuantLib users,
>>
>> I am currently bootstrapping a cross-currency basis-adjusted discount
>> curve using ConstNotionalCrossCurrencyBasisSwapRateHelper and have a
>> question regarding payment frequency conventions.
>>
>> The helper accepts a single paymentFrequency parameter, which appears to
>> be applied to both legs of the underlying cross-currency basis swap:
>>
>> ccbs_helpers = [
>>     ql.ConstNotionalCrossCurrencyBasisSwapRateHelper(
>>         ql.QuoteHandle(ql.SimpleQuote(basis / 10000)),
>>         ql.Period(*tenor),
>>         2,
>>         calendar,
>>         ql.Following,
>>         False,
>>         sonia,
>>         sofr,
>>         sonia_ts,
>>         True,
>>         False,
>>         paymentFrequency=ql.Quarterly
>>     )
>>     for basis, tenor in ...
>> ]
>>
>> My question is: how should one handle market instruments where the two
>> floating legs have different payment frequencies? For example when I
>> inquired with my market data provider, they indicated that for their quotes:
>>
>>    -
>>
>>    SONIA leg pays annually
>>    -
>>
>>    SOFR leg pays quarterly
>>
>> Is there a way to specify separate payment frequencies for each leg when
>> using ConstNotionalCrossCurrencyBasisSwapRateHelper or
>> MtMCrossCurrencyBasisSwapRateHelper, or is the helper designed under the
>> assumption that both legs share the same payment schedule?
>>
>> If different frequencies are required, is the recommended approach to:
>>
>>    1.
>>
>>    Build a custom cross-currency swap instrument with separate schedules
>>    for each leg and create a custom RateHelper; or
>>    2.
>>
>>    Approximate the market convention using a common frequency for both
>>    legs?
>>
>> I would appreciate any guidance on how QuantLib intends such instruments
>> to be handled and whether there are examples of bootstrapping a CCS basis
>> curve when the two legs have different payment frequencies.
>>
>> Thank you for your help.
>>
>> Kind regards,
>>
>> Nk
>> _______________________________________________
>> QuantLib-users mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>
>

[Quantlib-users] QuantLibXlOil Version 0.41.0 released

[<seb...@sc...>]

Hi all,

I am happy to share the first "official" release of the QuantLib/Excel
interface QuantLibXlOil as Version v0.41.0:

https://github.com/frame-consulting/QuantLibXlOil

A few milestones reached:

- Coverage of many important functions, in particular, yield curve
calibration, swap and European/Bermudan swaption pricing, option pricing
using various models.
- Comprehensive automated testing framework in Python and Excel.
- Automation of API documentation, version tagging and pypi publishing.

Next steps:

- Set up an automated process to upgrade from one QuantLib version to the
next QuantLib version. We are currently experimenting with Copilot and
Mistral Vibe.
- Further automate interface code generation via AI to increase coverage.
Ultimately (or hopefully), the project should be maintained by agents some
time.

If anyone has experience in setting up AI agents for similar tasks, we would
appreciate hints, examples or advise!

I would say, the project is in a state to be used in practice.

Installation can be done via pip. Plenty of example spread sheets are here:

https://github.com/frame-consulting/QuantLibXlOil/tree/main/tests/workbookte
sts/workbooks

Please get in touch in case of questions or issues.

Thanks

Sebastian



-----Original Message-----
From: seb...@sc... <seb...@sc...> 
Sent: Sonntag, 31. Mai 2026 11:43
To: 'Eric Ehlers' <eri...@re...>
Cc: qua...@li...
Subject: Re: [Quantlib-users] New aprroach for a QuantLib/Excel add-in

Hi Eric,

Thanks for your interest in the project and for adding the link in the
README.

Regarding your questions:

1/ Backward compatibility with existing QuantLibXL spreadsheets:

No, unfortunately not (at the moment). There is one key distinction between
xloil and QuantLibXL from a user perspective. With xlOil you do not specify
an ObjectId. Instead, an ObjectId (or reference) is created automatically.

Here is the link to the documentation section:
https://xloil.readthedocs.io/en/stable/xlOil_Python/TypeConversion.html#cach
ed-objects

Maybe, one could work around that by adding a dummy ObjectId argument and/or
by managing cached object strings in the wrapper code. But I am not sure if
this adds other complications.

2/ xlOil interface to Excel

To be honest, I have not figured out the details myself. But there is also a
documentation section on that point:
https://xloil.readthedocs.io/en/stable/Introduction.html#why-xloil-was-creat
ed

3/ xlOil performance

I have not compared performance with QuantLibXL. Other people reported some
tests for xlOil which indicate that it is not too bad:
https://github.com/lukedays/excel-benchmarks


Please let me know if you encounter any questions or issues when trying out
the approach.

Thanks

Sebastian



-----Original Message-----
From: Eric Ehlers <eri...@re...>
Sent: Samstag, 30. Mai 2026 19:48
To: seb...@sc...
Cc: qua...@li...
Subject: Re: [Quantlib-users] New aprroach for a QuantLib/Excel add-in

Hi Sebastian,

We are curious about this project and I will take a closer look at it when I
can.  Do you provide backward compatibility with existing QuantLibXL
spreadsheets?  Under the hood, how does xloil interface with Excel?  I took
a quick look at the documents, the answer to my question was not immediately
obvious to me.  It seems like it does not use the Excel C API.  Do you know
how your build compares to QuantLibXL performance wise?

I updated the QuantLibAddin readme to include a link to your project:

https://github.com/eehlers/QuantLibAddin-Old/blob/master/README.md

Regards,
Eric

On 5/29/26 4:32 PM, seb...@sc... wrote:
> Dear community,
> 
> I would like to announce a project for a new QuantLib/Excel add-in:
> 
> https://github.com/frame-consulting/QuantLibXlOil <https://github.com/ 
> frame-consulting/QuantLibXlOil>
> 
> We use QuantLib-Python with xlOil (https://github.com/cunnane/xloil 
> <https://github.com/cunnane/xloil> ).
> 
> The interface code is fairly trivial and can easily be generated semi- 
> automatically using e.g. Copilot or similar tools.
> 
> The project is still in early stage. But I think, it already acts as a 
> nice proof-of-concept. Using Python also opens the door to extend 
> QuantLib functions with other tools like Numpy or Pandas, e.g., for 
> cash flow analysis.
> 
> We would like the project to be a community effort. If you like the 
> idea and have some time to spare please contribute.
> 
> If you have any questions or run into problems when trying it out 
> please let us know.
> 
> Thanks
> 
> Sebastian
> 
> 
> 
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users




_______________________________________________
QuantLib-users mailing list
Qua...@li...
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Quantlib-users] QuantLib 1.43 released

[Luigi B. <lui...@gm...>]

QuantLib 1.43 is now available for download at <
https://www.quantlib.org/download.shtml>; precompiled binaries are also
available from PyPI and NuGet for Python and C# respectively.

The list of changes for this release is at <
https://github.com/lballabio/QuantLib/releases/tag/v1.43>.

If you have any problems with this release, please report them here on the
QuantLib mailing list (<qua...@li...>) or open a
GitHub issue at <https://github.com/lballabio/quantlib/issues>.

[Quantlib-users] Release candidate for QuantLib 1.43

[Luigi B. <lui...@gm...>]

Hi all,
   a release candidate for QuantLib 1.43 is available at <
https://github.com/lballabio/QuantLib/releases/tag/v1.43-rc>.  Python
wheels are also available at <
https://test.pypi.org/project/QuantLib/1.43rc0/>, and a C# NuGet package is
at <https://int.nugettest.org/packages/QuantLib/1.43.0-rc>.  If you have
some time, please try it out and report any issues on GitHub (or here on
the mailing list).  Thanks!

Luigi

Re: [Quantlib-users] ConstNotionalCrossCurrencyBasisSwapRateHelper with Different Payment Frequencies on Each Leg

[Quant <qua...@gm...>]

Hi Luigi,

Noted and thanks.

Regards,
Nk

On Thu, Jun 18, 2026 at 9:09 AM Luigi Ballabio <lui...@gm...>
wrote:

> Hi, this was added recently — see
> https://github.com/lballabio/QuantLib/pull/2528.  It will be available in
> release 1.43 out next month.
>
> Regards,
>     Luigi
>
>
> On Wed, Jun 17, 2026 at 5:30 PM Quant <qua...@gm...> wrote:
>
>> Dear QuantLib users,
>>
>> I am currently bootstrapping a cross-currency basis-adjusted discount
>> curve using ConstNotionalCrossCurrencyBasisSwapRateHelper and have a
>> question regarding payment frequency conventions.
>>
>> The helper accepts a single paymentFrequency parameter, which appears to
>> be applied to both legs of the underlying cross-currency basis swap:
>>
>> ccbs_helpers = [
>>     ql.ConstNotionalCrossCurrencyBasisSwapRateHelper(
>>         ql.QuoteHandle(ql.SimpleQuote(basis / 10000)),
>>         ql.Period(*tenor),
>>         2,
>>         calendar,
>>         ql.Following,
>>         False,
>>         sonia,
>>         sofr,
>>         sonia_ts,
>>         True,
>>         False,
>>         paymentFrequency=ql.Quarterly
>>     )
>>     for basis, tenor in ...
>> ]
>>
>> My question is: how should one handle market instruments where the two
>> floating legs have different payment frequencies? For example when I
>> inquired with my market data provider, they indicated that for their quotes:
>>
>>    -
>>
>>    SONIA leg pays annually
>>    -
>>
>>    SOFR leg pays quarterly
>>
>> Is there a way to specify separate payment frequencies for each leg when
>> using ConstNotionalCrossCurrencyBasisSwapRateHelper or
>> MtMCrossCurrencyBasisSwapRateHelper, or is the helper designed under the
>> assumption that both legs share the same payment schedule?
>>
>> If different frequencies are required, is the recommended approach to:
>>
>>    1.
>>
>>    Build a custom cross-currency swap instrument with separate schedules
>>    for each leg and create a custom RateHelper; or
>>    2.
>>
>>    Approximate the market convention using a common frequency for both
>>    legs?
>>
>> I would appreciate any guidance on how QuantLib intends such instruments
>> to be handled and whether there are examples of bootstrapping a CCS basis
>> curve when the two legs have different payment frequencies.
>>
>> Thank you for your help.
>>
>> Kind regards,
>>
>> Nk
>> _______________________________________________
>> QuantLib-users mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>
>

Re: [Quantlib-users] ConstNotionalCrossCurrencyBasisSwapRateHelper with Different Payment Frequencies on Each Leg

[Luigi B. <lui...@gm...>]

Hi, this was added recently — see
https://github.com/lballabio/QuantLib/pull/2528.  It will be available in
release 1.43 out next month.

Regards,
    Luigi


On Wed, Jun 17, 2026 at 5:30 PM Quant <qua...@gm...> wrote:

> Dear QuantLib users,
>
> I am currently bootstrapping a cross-currency basis-adjusted discount
> curve using ConstNotionalCrossCurrencyBasisSwapRateHelper and have a
> question regarding payment frequency conventions.
>
> The helper accepts a single paymentFrequency parameter, which appears to
> be applied to both legs of the underlying cross-currency basis swap:
>
> ccbs_helpers = [
>     ql.ConstNotionalCrossCurrencyBasisSwapRateHelper(
>         ql.QuoteHandle(ql.SimpleQuote(basis / 10000)),
>         ql.Period(*tenor),
>         2,
>         calendar,
>         ql.Following,
>         False,
>         sonia,
>         sofr,
>         sonia_ts,
>         True,
>         False,
>         paymentFrequency=ql.Quarterly
>     )
>     for basis, tenor in ...
> ]
>
> My question is: how should one handle market instruments where the two
> floating legs have different payment frequencies? For example when I
> inquired with my market data provider, they indicated that for their quotes:
>
>    -
>
>    SONIA leg pays annually
>    -
>
>    SOFR leg pays quarterly
>
> Is there a way to specify separate payment frequencies for each leg when
> using ConstNotionalCrossCurrencyBasisSwapRateHelper or
> MtMCrossCurrencyBasisSwapRateHelper, or is the helper designed under the
> assumption that both legs share the same payment schedule?
>
> If different frequencies are required, is the recommended approach to:
>
>    1.
>
>    Build a custom cross-currency swap instrument with separate schedules
>    for each leg and create a custom RateHelper; or
>    2.
>
>    Approximate the market convention using a common frequency for both
>    legs?
>
> I would appreciate any guidance on how QuantLib intends such instruments
> to be handled and whether there are examples of bootstrapping a CCS basis
> curve when the two legs have different payment frequencies.
>
> Thank you for your help.
>
> Kind regards,
>
> Nk
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

[Quantlib-users] ConstNotionalCrossCurrencyBasisSwapRateHelper with Different Payment Frequencies on Each Leg

[Quant <qua...@gm...>]

Dear QuantLib users,

I am currently bootstrapping a cross-currency basis-adjusted discount curve
using ConstNotionalCrossCurrencyBasisSwapRateHelper and have a question
regarding payment frequency conventions.

The helper accepts a single paymentFrequency parameter, which appears to be
applied to both legs of the underlying cross-currency basis swap:

ccbs_helpers = [
    ql.ConstNotionalCrossCurrencyBasisSwapRateHelper(
        ql.QuoteHandle(ql.SimpleQuote(basis / 10000)),
        ql.Period(*tenor),
        2,
        calendar,
        ql.Following,
        False,
        sonia,
        sofr,
        sonia_ts,
        True,
        False,
        paymentFrequency=ql.Quarterly
    )
    for basis, tenor in ...
]

My question is: how should one handle market instruments where the two
floating legs have different payment frequencies? For example when I
inquired with my market data provider, they indicated that for their quotes:

   -

   SONIA leg pays annually
   -

   SOFR leg pays quarterly

Is there a way to specify separate payment frequencies for each leg when
using ConstNotionalCrossCurrencyBasisSwapRateHelper or
MtMCrossCurrencyBasisSwapRateHelper, or is the helper designed under the
assumption that both legs share the same payment schedule?

If different frequencies are required, is the recommended approach to:

   1.

   Build a custom cross-currency swap instrument with separate schedules
   for each leg and create a custom RateHelper; or
   2.

   Approximate the market convention using a common frequency for both legs?

I would appreciate any guidance on how QuantLib intends such instruments to
be handled and whether there are examples of bootstrapping a CCS basis
curve when the two legs have different payment frequencies.

Thank you for your help.

Kind regards,

Nk

Re: [Quantlib-users] QuantLibXL Addin

[m s. <msc...@ho...>]

Hello Eric,

Thank you for the update.
I don't know why you're getting an error.  I do seem to be getting your emails.
Please let me know if you (or anyone) find any errors, or items that are missing or need to be exposed.
I'm happy to keep it up to date.

Best,
Mike



________________________________
From: Eric Ehlers <eri...@re...>
Sent: Saturday, May 30, 2026 1:47 PM
To: m scaturo <msc...@ho...>
Cc: Chirag Desai <chi...@ya...>; qua...@li... <qua...@li...>
Subject: Re: [Quantlib-users] QuantLibXL Addin

Hi Mike,

Many thanks for putting this together.  I updated the QuantLibAddin
readme to include a link to your project:

https://github.com/eehlers/QuantLibAddin-Old/blob/master/README.md

We migrated the QuantLibAddin repo into the ORE project.  The new repo
is private for now, it will be made public later this year.  I processed
all of the merge requests that have been received.  The next build will
use the latest version of the compiler and of (the ORE fork of) QuantLib.

My messages to your email address bounce back with an error.

Regards,
Eric

On 5/26/26 1:41 AM, m scaturo wrote:
> Hello Chirag,
>
> I have created a fork and a merge request to Eric Ehlers code with my
> updates.
> Since the pull request is still pending, you can use the code directly
> from my fork.
> You can find it here:
> https://github.com/mscaturo/QuantLibAddin-Old <https://github.com/
> mscaturo/QuantLibAddin-Old>
> It uses the 1.42.1 version of QuantLib, the 1_90_0 version of the Boost
> library, the 1.6.1 version of lib4cxx
> And is compiled using Visual Studio 2022.
> It compiles and creates the addin for me without errors.  I've created a
> few spreadsheets and verified the results against Bloomberg.
> I'm happy to take a look if you find any errors with it.
>
> Regards,
> Mike
>
>
> ------------------------------------------------------------------------
> *From:* Chirag Desai <chi...@ya...>
> *Sent:* Thursday, May 21, 2026 10:38 PM
> *To:* qua...@li... <quantlib-
> us...@li...>; m scaturo <msc...@ho...>
> *Subject:* Re: [Quantlib-users] QuantLibXL Addin
> Hi Miike
>
> Thank you for the below. Can I kindly ask if you can send me the Github
> repo of the below please ?
>
> I used the instructions below with VS 2022, Quantlib 1.22 with Boost
> 1.87 but there are far too many errors as most of the older Boost
> functions have been deprecated.
>
> _QuantLibAddin: Build QuantLibXL From Source Code_ <https://
> www.quantlib.org/quantlibaddin/build_qlxl.html><http://www.quantlib.org/quantlibaddin/build_qlxl.html>>
>
>
>
>
>
>
>     QuantLibAddin: Build QuantLibXL From Source Code <https://
>     www.quantlib.org/quantlibaddin/build_qlxl.html><http://www.quantlib.org/quantlibaddin/build_qlxl.html>>
>
>   in
>
>
>
> On Tuesday, May 5, 2026 at 09:15:28 AM GMT+8, m scaturo
> <msc...@ho...> wrote:
>
>
> Hello Everyone,
>
> I have built the QuantLibXL addin with version 1.42.1 of quantlib using
> Microsoft visual studio 2022, boost 1_90_0, and lib4cxx 1.6.1
>
> I have exposed the FXForward functions but I haven't fully tested them yet.
>
> If there's an interest, I'd be happy to contribute this code back to the
> project.
>
> Thanks,
> Mike
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li... <mailto:QuantLib-
> us...@li...>
> https://lists.sourceforge.net/lists/listinfo/quantlib-users <https://
> lists.sourceforge.net/lists/listinfo/quantlib-users>
>
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users