Effective Rate Factor is not an expression used in practice. Someone might even consider it wrong because it is no an effective rate. Below I give alternatives terms used in practice.

Accumulation Factor is the accumulated capital at some future time obtained from investing 1 monetary unit today. This is the terminology most found on the Internet. All actuaries use this term. Although less often, some finance professionals also use it, although many of them work mainly with discount factors. I think Accumulation Factors are more intuitive to work with because you multiply to get a usually bigger value in the future and divide to get a present value.

Compounding is used as the opposite of Discounting. In particular, Compounding is used in the documentation of InterestRates.jl. Accordingly, Compound Factor is the natural inverse of the Discount Factor. However, I have seen Compouding Factor use much more often.

Future Value Factor would be more descriptive and transparent. The only drawback is that this name may not be ideal for a Forward Accumulation Factor because you compound/accumulate from one future time to another.

Overall, I think Accumulation Factor is the best choice because it has a totally precise meaning and is used more often than the alternatives.

Hi,
it seems that whenever I try to buffer a CurveMap, I always get the original non-mapped zero rates.

For instance, in those tests bellow:

@testset "Buffered CurveMap" begin
    
    flat_curve = InterestRates.IRCurve(
        "flat", InterestRates.Actual360(), InterestRates.SimpleCompounding(), InterestRates.StepFunction(),
        Date(2021,1,1), [1], [0.1]
    )
    @test InterestRates.zero_rate(flat_curve, Date(2022,1,1)) ≈ 0.1

    map_curve = InterestRates.CurveMap("mapped", (r,m) -> r+0.05, flat_curve)
    @test InterestRates.zero_rate(map_curve, Date(2022,1,1)) ≈ 0.15

    buffered_curve = InterestRates.BufferedIRCurve(map_curve)
    @test InterestRates.zero_rate(buffered_curve, Date(2022,1,1)) ≈ 0.15

end

... last test fails.

Buffered CurveMap: Test Failed at /home/InterestRates/test/runtests.jl:646
  Expression: InterestRates.zero_rate(buffered_curve, Date(2022, 1, 1)) ≈ 0.15
   Evaluated: 0.1 ≈ 0.15

IRCurve constructor for Term Structure models (currently Svensson and NelsonSiegel) could apply an optimization routine to calibrate parameters on a given set of yield points. The original data could be stored on IRCurve.dict, or we could create a separate vector for yields and parameters.

When loading a database of historical curves, Cubic Spline curves spends a lot of time running splinefit function. The bottleneck seems to be A \ b calculation.

Maybe there's a way to optimize this, since we have information about the structure of this linear system.

Ref: http://www.math.ntnu.no/emner/TMA4215/2008h/cubicsplines.pdf

Why is FlatForward so slow ?

Running perftests...
InterestRates.Linear()
  0.002381 seconds (100 allocations: 1.160 MiB)
  0.017299 seconds (699.10 k allocations: 12.984 MiB)
  0.022000 seconds (699.10 k allocations: 12.984 MiB, 8.02% gc time)
InterestRates.FlatForward()
  0.050725 seconds (1.35 M allocations: 21.759 MiB, 5.55% gc time)
  0.067870 seconds (2.05 M allocations: 33.583 MiB, 7.09% gc time)
  0.060739 seconds (2.05 M allocations: 33.583 MiB, 1.30% gc time)
InterestRates.NelsonSiegel()
  0.014168 seconds (450.10 k allocations: 8.026 MiB, 16.89% gc time)
  0.029529 seconds (1.15 M allocations: 19.850 MiB, 5.20% gc time)
  0.026849 seconds (1.15 M allocations: 19.850 MiB, 5.51% gc time)
InterestRates.Svensson()
  0.011758 seconds (450.10 k allocations: 8.026 MiB)
  0.028876 seconds (1.15 M allocations: 19.850 MiB, 8.81% gc time)
  0.029962 seconds (1.15 M allocations: 19.850 MiB, 6.26% gc time)
InterestRates.CubicSplineOnRates()
  0.005921 seconds (249.00 k allocations: 4.958 MiB)
  0.022034 seconds (948.00 k allocations: 16.782 MiB, 8.80% gc time)
  0.020766 seconds (948.00 k allocations: 16.782 MiB)
InterestRates.CubicSplineOnDiscountFactors()
  0.010648 seconds (450.30 k allocations: 10.345 MiB)
  0.028654 seconds (1.15 M allocations: 22.169 MiB, 7.54% gc time)
  0.029212 seconds (1.15 M allocations: 22.169 MiB, 6.21% gc time)
InterestRates.StepFunction()
  0.001689 seconds (100 allocations: 1.160 MiB)
  0.015189 seconds (699.10 k allocations: 12.984 MiB)
  0.017640 seconds (699.10 k allocations: 12.984 MiB, 11.24% gc time)
Perftests end

First of all, thanks for sharing this nice package!

I'm a bit confused by the parametric and interpolation methods in a single final type. The parameter_id and parameter_values fields can have different meanings dependent on the curve method, is that correct? From my little experience many years ago, I remember some interpolation methods required extra parameters, such as the minimum length or minimum tension splines. I don't see how that fits in the current IRCurve type, maybe a parameters dictionary would be more general?

Anyway, I remember a nice curve method that constructs a yield curve by taking a linear combination of functions on several levels. So on a first level you would make a combination of functions that pass through, say, the 2Y, 5Y and 10Y (the most liquid ones). A second level would then add the combination of function to also match points on, say, 1Y, 3Y, 7Y and 30Y and a third level any remaining liquid points.
The choice of level maturities could be based on experience or a PCA on rate changes for each maturity. The functions could be a normal, decaying exponential, sigmoid, logistic, constant, sqrt, etc. The choice of functions per level and calibration of the function parameters should be optimized once based on historical/expert sensitivities between different maturities. The linear combination however needs to be solved for every curve.

If you're interested, I could see to add this curve method. I would not some historical data for testing though.

Hi @felipenoris 👋

Over the years, I built a private repo for interest rates, but now I've left the company and left the repo behind, which is a shame. I'd like to start doing some more work on interest rate modelling / projections and this package looks like a great place to start. I am just curious, forgive me if I am presumptious, but would you consider forming / joining JuliaFinance (as an admin) and move this repo to that organization? Absolutely no problem if you don't want to. Just thinking if I am to build some commercial code based on this, it might be better in an organization than an individual.

Currently, we just have Currencies.jl, but we should also have a Countries.jl etc. I'm thinking we could start building up a decent warchest for financial engineering. What do you think?

Should also include the code to create IRCurve instances by reading the database