I guess I'm just not the target, but anyway... I think the website could communicate whatever it is you are doing better.
What pain point does your API solve? Who is your target audience? Can you show us a simple example (or a few)?
Is it closed-source? How are you planning to monetize it? This is a very important issue for any api-as-a-service project which yours seems to be. If you don't have any strategy, then I will not bet my business on you sticking around...
It basically wraps some functionalities of quantlib library into an API. Main reason of it is that I think part of the target of the library is people that not need to know about programming, and an API opens it to future user friendly interfaces (such as the google sheets addon).
Examples, the add-on uses it and you can find the source code in the repository. Close source, yes now, it's been just a side project. Not thinking about monetize it now.
In your doc, is your sample getIbors meant to be complete? Don't show that to a finance professional if it is. I don't see Libor, you have Eonia, Sonia but no Fed's fund, I am not sure what Euribor Act/365 is.
Also I am a bit confused by what your curves return. The coefficients seem to be rates. I would expect a curve (once built) to be a compibination of discount factors and some interpolation function.
Haven't looked at the details so perhaps this feedback is irrelevant. But from the look of it it looks like all your curves are self discounting curves. You need to be careful as the market moved away from these curves 6-7y ago.
Agree, not all ibor indexes are defined in Quantlib, so now just euribors can be used for forward rates.
About Euribor 365:
Euribor rate adjusted for the mismatch between the actual/360 convention used for Euribor and the actual/365 convention previously used by a few pre-EUR currencies
I'm not sure what you mean with self discounting curves, but you can use different curves for discount and forward rates. I will add OIS discounting too in the future, if that is what you mean.
On self discounting, it has more to do with how you define your curve. They seem to be defined as a single list of instruments, like a self discounting curve. Whereas with multiple curves (OIS / Libor 1m / Libor 3m, etc), you would need to provide the instruments that define the inter-dependency of the curves (like 1m-3m basis swaps, etc) and you kind of need to build them all at once, since they are interdependent (swap rates vs 3m are using both the 3m and the OIS curve).
Anyway, I have never looked at Quantlib myself, so all of this may be limitations of the underlying library. But if you present a yield curve product to an interest rate professional, the question will come up.
On index names, I think it should be data more than hard-coded enums. There is nothing in the calculation that should explicitly refer to the name of an index. It should be all about daycount fractions, calendars, and other conventions.
I can imagine people or companies can use this API to check their own functions in test cases. Example - you have tons of deals and at the end of the day it would be interesting to doublecheck daily P&L. But I believe this business doesn't trust anybody but well-known players or experts. Also the time is essential so they will prefer a local library. And again, the security can prohibit external APIs.
I don't discourage your work though, perhaps it is a step to your personal success, who knows.
Thanks for your comment. I agree with most of what you said:
"I can imagine people or companies can use this API to check their own functions in test cases"
Testing is one good application.
"But I believe this business doesn't trust anybody but well-known players or experts"
Take a look to the community mantaining quantlib.
"Also the time is essential so they will prefer a local library"
How long does it take to financial institutions to test all valuations for each modification to "local libraries"? Using external services could avoid that. This is not going to be the one, but it would be just a matter of resources to improve performance(ie big data platform for risk simulations)
"And again, the security can prohibit external APIs"
Why do banks rely on RSA for payment transactions but don't do it for other purposes?
"I don't discourage your work though, perhaps it is a step to your personal success, who knows"
As someone who works in a bank, if I sent trading data off to an external service I'd be fired almost immediately. Even things like pretty printing services are monitored and blocked.
Totally agree, but they would not fire you if you price a bond in Bloomberg. I guess is more something about who the banks trust, which is a closed set of actors that does not seem to change (again, I'm not saying anyone has to trust with this, but maybe something will change some day)
First time I am seeing Slate (https://github.com/lord/slate) a static documentation theme. Really beautiful, seems like they "borrowed" some ideas from Stripe.
The documentation suggests that this currently only supports single-currency IRS, and it's also BYO market data.
To my knowledge there isn't anything like a RESTful pricing/valuation service in the market, let alone one with integrated market data, so there might be an opportunity there. Existing services also tend to only have "enterprise" sales/pricing structures, which is a pain if you just want to try something out.
That's right, it just prices IRS and Bonds (with no optionalities). Next steps could be adding equity options, swaptions, caps and floors or bond options, but it's just a side project I used to learn something about quantlib. Anyone willing to contribute will be welcome though :). It is entirely done with C++ (C++ quantlib, crow and rapidjson).
About market data, I think that is a big gap to fill in this industry. Hopefully some day it will exist an open source of data, but IMHO that's not something is likely going to happen in the near future.
You might want to think about cross-currency IRS and FX products as next steps, because they're more common hedge instruments for corporates (your likely market, if you ever want to go in that direction) compared with options.
To monetize the API I guess your only option would be to partner with an exchange (or something like that) to get access to the necessary market data. A decent API for valuations and pricing would really be a breath of fresh air.
Companies using this library may have access to bloomberg or reuters so an API to interact with the bloomberg or reuters API may be enough. Otherwise you would probably need to charge for access to market data.
But to offer this commercially, you will need to support quite a few currencies, market conventions, customised terms, formats for the trade representation, etc.
I really liked how you presented the API, both docs and the Chrome Extension for Google Sheets.
I have to say it was a little bit unclear at the beginning, I suggest you to make it more clear in the landing page or in the extension description. I agree with other comments regarding target audience and what problem you're solving or potentially the API can solve (examples are a charm).
What is this? I think it needs a more clear and accessible demo; I don't know what it is, and I don't want to install a google sheets add-on to find out.
How does this compare to tools like Quantopian's? Is it targeting a less sophisticated user, hence the Google Sheets?
Thanks for the comment! About what is it, I already answered in another comment but I guess landing page needs more info.
It mostly gives finance products pricing capabilities, not trading algorithms like quantopian.
I thought a google sheets addon would be a good way to show what it does, and actually a real good application for it. There already exists an excel wrap for it (http://quantlib.org/quantlibxl/ much much better than this though) but you need Microsoft Excel :)
What pain point does your API solve? Who is your target audience? Can you show us a simple example (or a few)?
Is it closed-source? How are you planning to monetize it? This is a very important issue for any api-as-a-service project which yours seems to be. If you don't have any strategy, then I will not bet my business on you sticking around...