Use case · Rates data for product teams
How do I get a licensed rates feed for my product?
Your product shows interest rates. The forward-curve feed behind it was a scrape of a free web page — and this morning they changed the page. Your charts are flatlining, your engineers are reverse-engineering someone else's HTML at 9am, and a customer who pays you tens of thousands a year has just asked, in writing, where your data comes from.
You can't answer honestly. Neither can the teams re-keying rates from free websites into their platform every morning, the ones with the benchmark hard-coded into the database, or the ones running "I don't know, ten different APIs and scrapers" to keep the product fed. That's the moment this page is about.
Last updated: July 2026
Replace the scrape with a licensed JSON API. BlueGamma provides forward curves, fixings, swap curves and FX over a REST API, with redistribution and derived-data rights written into the contract up-front and flat platform pricing that doesn't scale with your end-customer count. BlueGamma is an interest rate data and pricing platform used by 80+ financial institutions for swap rates, forward curves and cap pricing across 30+ currencies.
How you're probably doing it now
Every platform that embeds rates goes through the same five failure modes. These are real accounts from product and engineering leads at fintechs, treasury-management systems, loan-valuation and securitisation platforms, ALM and mortgage-software vendors, index providers and lenders we've spoken with — teams embedding everything from SOFR and EURIBOR to BBSW, CORRA, NIBOR, STIBOR and SARON.
Scraping a free page — or re-keying it by hand
Free sources have no SLA, no licence for commercial use — and no obligation to keep the page the same. And when it isn't a scraper, it's a person: rates copied from "various different websites" into the platform every morning, or once a week into an Excel that gets uploaded.
"We're just like… scraping the web page. And it turns out that they changed the web page and… our data started fading."
— Head of product at a European treasury-management platform
"Historically someone's just going and, like, grabbing this table and then populating this… I don't want a person to do it. The rest of our model is kind of built — the delimiter was getting this curve into [our CRM]."
— Lender at a North American equipment-finance company, on the free forward-curve page his team re-keys
"When customers who pay… a few hundred or thousand euros per year ask us [who our] data provider is, it's hard for the customer service team to keep a straight face."
— The same head of product, on their previous no-name data source
The incumbents won't play
The terminal vendors' redistribution model is usage-based and generally requires your end-customers to be licensed data customers themselves. If your customers pay you a few hundred a month, the maths never works.
"They had a distribution model that was based on the usage and that generally required the customers to actually be… customers of [the terminal vendor]… It became clear to us it was completely… out of the question for those customers to pay these kind of things."
— Head of product at a European treasury-management platform, on why talks with the incumbents went nowhere
"We tried with [the terminal vendor], but there we face some licensing issues… you can't really create a product based on such terms. It's made for end users — not for businesses that want to build something on top with data."
— Product lead at a Swiss debt-financing platform, after years of trying — "you're just too small. They don't care about you."
"[The terminal vendor] is a very hard partner to work with. We are not partnered with them… The thing that we have some trouble sourcing are… forward curves."
— Engineer at a leveraged-loan analytics platform, whose partnership approach the terminal vendor flatly refused
Re-priced after you integrate
Legacy vendors that do sign redistribution deals often price on usage — so the bill moves after you've built on them. One index provider reported roughly $14k a year for each additional currency; a US bank's term-rate feed "just rolled out a pretty major price increase the other day." We know the trap first-hand: BlueGamma used to source from a legacy data vendor whose usage-based charging is why we replaced them with a broker feed on fixed terms.
"I've had them monitor how much data I've taken off, and I've had a phone call from them to say: you've taken 20% extra data out of our systems. What was that for? Can we actually see what you're doing with it, and where does it go?"
— Head of private-markets solutions at a global investment-management technology provider
"Each time we wanted something, it was like: yeah, but you're going to resell it. No — we're not making a competitor of [the legacy vendors]. We use your data and we need to be able to provide it to the people who need it, in relation to what we provide them."
— Architect at a French treasury-software vendor, on why every feature request became a licensing negotiation
Legacy vendors, legacy APIs — and stale data
The mid-tier data vendors will quote you — but the developer experience tells you what the next five years of support will feel like. Teams that switched reported Friday's data arriving the following Monday, and "term" rates that turned out to be futures prices they corrected by hand every day.
"Just going onto their website, you kind of get the idea of the type of company that it is… it just feels weird, legacy, and… we're an API-first company and… we want to work with modern APIs and… good support… just easy-to-work-with tools."
— Product lead at a Stockholm-based treasury platform, on evaluating legacy market-data vendors
"An intermediary who actually can't tell me the timestamps of his data, or the origin, in which time zone they were created… that was just horrible. We lost so much time."
— Chief product officer at a Swiss lending platform, on a prior data intermediary
"Their swap rates, when I spot-check them, are usually a day and a half delayed. We have clients that wanna make decisions on data — if I'm providing them something that's a day or two old, that's just not gonna cut it."
— Founder (a former bank derivatives trader) of a Canadian rates advisory with a client-facing platform
Buying the firehose for fifty tickers
The premium terminal's data licence is all-or-nothing: you pay for the full package to use a sliver of it, the fees are hard to trace — "we're getting nickel and dimed in fees that we can't really trace back" — and small platforms have no negotiating leverage.
"We pay so much money to [the terminal vendor] — they don't often give you some subset of data, it's all or nothing. So we have to get whatever they give us."
— CTO of a structured-credit hedge fund
"You can buy 1,000 tickers. We don't need 1,000 tickers… we need less than 50. We don't need to drink from the fire hose."
— An ex-rates trader (30 years at major banks) at an FX technology firm
And underneath all four sits the structural problem, from someone who has lived on both sides of it:
"[The free rates site]'s free data is great. But if you are building a product on the back of it, it's a bit scary to do that on the back of free data. You know, you're at the mercy of [the free rates site] — that they change the website, the scraper breaks, or there is some issue in the data."
— BlueGamma's founder (formerly at the firm behind a widely-used free rates website), to an AI fixed-income platform validating its SOFR curves against free sources
How teams describe this
Verbatim, from product leads, founders and engineers who came to us mid-scramble — lightly trimmed, names removed.
"Right now, someone wakes up every morning and, like, types them into the computer. And they gotta get the file from a certain person. And that person's on vacation — it's a whole all-hands-on-deck situation."
Data lead at a US regional bank, on how benchmark rates reach their loan system today
"We started to build our own APIs, grabbers, whatever… Currently I have, I don't know, ten different APIs and scrapers."
Chief product officer at a Swiss lending platform
"[The terminal vendor] will turn around and say, oh no, you can't use it on your system. You're another system — you now need to double the fee. And the client will turn around and say no, that's a bit of a ridiculous situation."
Head of private-markets solutions at a global investment-management technology provider
"The open secret in the market is everyone violates their [terminal] licence."
The same head of private-markets solutions
"I went through nine data providers… the price was competitive and they have solid infrastructure. And then they came back saying, this is maybe not allowed by the use case. I was like, what are you talking about?"
Quant lead at a derivatives index provider, on being re-scoped by a legacy vendor after signing
"We were all at dinner last night and I said I had a call with you guys this morning — we just wish we found you off the jump. We're trying to run things pretty lean, and these guys got us in for 20K US a year for data."
Founder of a Canadian agri-lending platform, locked into a two-year legacy-vendor contract
How the licensed feed works
Pull the data over a JSON API
One REST API covers the rates data a product typically embeds: get_forward_curve (specify the benchmark and tenor — 1M, 3M, 6M — and get the full bootstrapped curve in one call), get_fixing for overnight and benchmark rates with ~5 years of history, get_swap_curve / get_swap_rate out to 50 years, and FX spot and forward endpoints. Coverage runs well past the majors: teams have integrated for BBSW, CORRA, NIBOR and NOWA, STIBOR, WIBOR, SARON, SAIBOR, EIBOR, BKBM and BBSY alongside SOFR, EURIBOR, SONIA and ESTR. Pricing endpoints (swap MtM, swap-rate-from-a-notional-schedule, cap pricing) sit on the same API if your roadmap gets there.
Most product integrations pull the end-of-day close once a day — a loan-valuation platform pinging "once a day for close-of-business time to get the curves" is the typical shape — while the 30-second live feed is there for platforms that genuinely price in real time. Every curve takes an as-of date, which matters more than it sounds:
"What I would so hate is: we work with one client, they have two analysts working on the same deal — one runs it day one, the other looks at it day two, and they get different results just because one is based on the forward curve of day one and the other one forward curve of day two."
— Product owner at a private-credit software company, on why as-of-date pinning and frozen curve snapshots matter for 20–30-year cash-flow runs
// GET /forward_curve?index=EURIBOR&tenor=3M { "index": "EURIBOR_3M", "as_of": "2026-07-06", "curve": [ { "date": "2026-10-06", "rate": 0.02114 }, { "date": "2027-01-06", "rate": 0.02087 }, …out to 50 years ] }
Most teams have the first curve rendering in their own product within a day or two of getting a trial key.
Define redistribution and derived-data use in the contract — before you integrate
This is the part the incumbents get wrong. The licence states, in plain terms and up-front: derived data (values your product computes from the curves — interest-cost projections, Z-spreads, payment notices, MtM checks) is permitted; displaying rates inside your product's business logic is permitted; a raw curve page with a bulk download button is the one thing a standard licence excludes. You know the boundary before your engineers write a line of code, so mentioning "redistribution" later doesn't triple the price mid-relationship.
Pay flat platform pricing that doesn't cliff with your user count
Because BlueGamma's own upstream broker agreements are not usage-based, yours isn't either. The licence is scoped by what you access — which endpoints, which currencies, which tier — not by how many end-customers see the outputs. Going from 200 to 2,000 customers changes your revenue, not your data bill. Growth conversations happen when you add data sets, not when you succeed.
Validate on a trial key, then ship
Trial API keys let your team cross-reference BlueGamma's numbers against your current source before any contract. Structured proof-of-concepts (a few months, agreed scope) are available for larger platform integrations. Integration is deliberately boring: plain JSON over REST, and teams have shipped it from Node, Python, Salesforce and Azure stacks — one risk-analytics provider that replaced a legacy market-data feed reported the integration took "less than a day and a half". Historical endpoints support backfilling roughly five years of fixings and swap rates, so you can rebuild your time series on one source instead of stitching old vendor and new. Support is one address, answered by the team that builds the product — and new endpoints get added with customers, the same way you build for yours.
Internal use vs display vs redistribution
Three tiers. The distinction is what happens to the raw data, not what your product computes from it.
Internal use
The data feeds your calculations; only the results ever reach a user.
- Curve drives an IRR, interest-cost or valuation calc
- Only the computed output is shown or stored
- The standard, lowest-cost licence
Display
Rates and curves are visible in your UI as part of business logic.
- Show the fixing on a loan schedule, chart a reference curve
- Explain a payment notice, evidence a Z-spread
- No bulk export of the raw curve
Redistribution
Your end-users can extract, download or store the raw data itself.
- Downloadable curves, data-lake storage at the client's end
- Priced and scoped separately — agreed before you build
- Still flat-fee, never per-end-user
A rule of thumb from our contracts: as long as the data is in use within core business logic, it's a permitted use case. The thing a standard licence rules out is an interest-rate page with a big download button that simply re-exports the curve.
Two more things the structure gets right. First, one contract covers your whole platform — your end-customers never have to paper their own agreement with the data originator, which is the dealbreaker several platforms hit elsewhere:
"What doesn't work for me is that my clients need to sign a contract with you… They will never sign a contract. They don't even understand it properly. I need a one-stop shop."
— Product lead at a Swiss debt-financing platform, on a legacy vendor's per-client sign-off model
Second, the licence is priced so it doesn't break your product's economics — the failure mode that kills embedded-data business models before they launch:
"If I come with a simple system with an affordable price and then double the price due to the data, then it's not viable… I try to tell them: you don't need a [terminal] data licence, which will kill you."
— Founder of a Swiss ALM-software vendor for small and mid-size banks
Your options for embedding rates data, compared
| Scraping a free page | Premium terminal vendors | Legacy data vendors | BlueGamma | |
|---|---|---|---|---|
| Licence to embed in your product | None — commercial use of free data is unlicensed | Usage-based; end-customers generally need their own licence | Negotiable, but redistribution talk typically multiplies the price | Display / redistribution tiers written into the contract up-front |
| Will they partner with a growing platform? | Not applicable — they don't know you exist | Refused partnerships reported by smaller platforms; "aware they are wasting their time talking to us" | Yes, but re-pricing after integration is the known risk (usage-model creep) | Product partnerships are the core business; roadmap built with partners |
| Pricing model | Free — until the page changes | ~$2–3k/mo per terminal + per-security / usage fees | Usage-based or opaque; quotes move with your growth | Flat platform fee; no cliff from 200 → 2,000 end-customers |
| API & developer experience | Your scraper is the API | Legacy enterprise integration | "Weird, legacy" websites and integrations, per teams that evaluated them | Modern JSON REST API; docs public; trial keys in days |
| Data freshness | Whatever the free page shows — often delayed a day or more, changes silently | Real-time — at terminal prices | "A day and a half delayed" swap rates; Friday's data arriving Monday, per teams that switched | 30-second in-app refresh; same-day fixings; daily EOD curve endpoints |
| Adding a currency or data set later | Another scraper to babysit | All-or-nothing packaging — "we have to get whatever they give us" | ~$14k/yr per extra currency reported; new paperwork per index | À-la-carte per data set; add endpoints as your roadmap ships |
| Forward curves (the hard part) | Sparse tenors, no history, breaks silently | Yes — if you can license them | Patchy; often the gap platforms can't fill | Bootstrapped curves, 30+ currencies, configurable tenor, as-of-date history |
| What you tell customers who ask where the data comes from | "…it's hard for the customer service team to keep a straight face" | A credible answer, at an incredible price | A credible answer, with contract risk attached | A named, licensed provider sourcing from interdealer brokers |
Teams that made the switch
A Nordic treasury-management platform went from scraping free pages, to BlueGamma's API, to consolidating all of its rates and market data onto the one endpoint — it evaluated moving "up" to a terminal vendor as it grew and concluded it didn't need to. An AI platform for leveraged-loan investors signed for the forward curves it couldn't source anywhere else after the premium terminal vendor declined to partner, using them to power the Z-spread calculations inside its product.
A Canadian agri-lending platform walked away from a two-year legacy-vendor contract after discovering the vendor's "term" rates were futures prices its team had been correcting by hand every day — its co-founder's verdict on the switch: "without your data, nothing's really possible here." An Australian securitisation platform stopped hard-coding the BBSW fixing into its database from the exchange's day-delayed tables ("seeing pricing from [the exchange] is enough to turn anyone away"). And a European risk-analytics provider replaced a legacy market-data vendor's feed outright:
"The API integration was very smooth — I'd say we spent less than a day and a half on it… you can put on the list: we've got customers, we've integrated BlueGamma in less than two days, and within a week the other data we needed."
Founder of a European risk-analytics provider serving asset managers, on replacing a legacy market-data vendor's feed"The rigidness of the license implies that I have to pay a lot to get even some of the basic stuff… I have to pass on cost to the clients that are significantly higher."
Product lead at a global investment-management technology provider, on why they began a proof-of-concept with BlueGamma after procurement rounds with the premium terminal vendor and a legacy data vendor"Easy-to-understand pricing. It can be so convoluted with this market data — to just know exactly what it costs up front, that's really nice. So we can also plan for that."
Co-founder of a Danish fixed-income analytics startup, formerly in market data at a Nordic bank — where the terminal vendor was "squeezing us all the time" even at a large regional bankFAQs
Yes — with a display licence. BlueGamma permits showing rates, curves and chart views in your interface as long as the data sits inside your product's business logic: a loan schedule, a Z-spread calculation, an interest-cost forecast, a reference-rates view your customers use to understand your outputs. What isn't permitted on a standard licence is a raw rates page with a bulk download button that simply re-exports the curve — that's redistribution, a separate tier agreed up-front.
No. That usage-based model — where every end-customer must themselves be a licensed customer of the data originator — is exactly what makes the terminal vendors unworkable for products whose customers pay a few hundred to a few thousand a month. BlueGamma licenses your platform, not your user count.
Nothing automatic. The licence is scoped by what you access — endpoints, currencies, tier — not by how many end-customers see the outputs. Pricing conversations happen when you add data sets or move from display to redistribution, not because your user count crossed a threshold.
That's the redistribution tier — letting end-users extract, download or store the raw curves (including storage in a client-side data lake). It's priced and scoped separately, defined in the contract before you integrate. Derived data — values your product computes from the curves, like a projected interest cost or an IRR — is permitted on standard licences and treated as one use case, not metered per calculation.
Honest answer: some benchmark fixings are controlled by their administrators, and consuming or redistributing them can require a licence from the administrator itself — STIBOR, NIBOR and Danish CIBOR are the usual examples, and term SOFR and term CORRA sit with their benchmark administrator too. BlueGamma flags these up-front and will connect you with the relevant authority when you need that licence, rather than letting you find out in an audit. In the meantime, risk-free-rate alternatives (ESTR, SWESTR, SONIA, SOFR) and compounded overnight-derived term proxies cover most product use cases without it.
For interest rates, the source category is the same: BlueGamma buys from interdealer brokers, the originators the terminals also rely on, and customers who benchmarked our curves against bank tables found them to tie out closely. Where the premium terminals genuinely have unmatched breadth — bond quote depth, for instance — we say so plainly. For rates and forward curves specifically, you're not trading down.
Yes, and that's the typical path: start with historical fixings for a debt module, add forward curves when you build forecasting, add derivative valuation endpoints (swap MtM, FX forwards) when your customers' derivative books become a feature. Licences are structured per data set, so you pay for what you use now and add as you ship.
This comparison happens on almost every evaluation — as one Swiss platform lead put it, "the market compares the data always to [the terminal]… they define the standard to some extent. You can't be 20–30 basis points off all the time." That team ran the test formally across USD, GBP, SEK, EUR and CHF curves and found BlueGamma within roughly 2 basis points of the terminal — while a legacy vendor was up to 30bp off on the same data. The reason is the source: BlueGamma buys from a leading regulated interdealer broker, the same source the major terminals use, so run the comparison yourself on a trial key.
Days, not months. The API is plain JSON over REST — teams have integrated it from Node, Python, Salesforce and Azure stacks, and one risk-analytics provider reported the whole integration took "less than a day and a half". For history, fixing and swap-rate endpoints support backfilling roughly five years, so teams switching vendors can rebuild their time series on one source (one Canadian platform backfilled from 2020 to replace its previous vendor's table entirely).
Yes. Trial API keys let your engineers hit the real endpoints, check the response formats and cross-validate the numbers against your current source before contracts are drawn up. Platform trials run 14 days; structured multi-month proof-of-concepts are available for larger platform integrations.
Retire the scraper
Get a trial API key, pull your first forward curve today, and see the licence terms in writing before your engineers commit a line of code.
Related situations
More scenario guides from the same desk.
.png){kind=logo}