Use case · Real estate finance
One lender requires a rate cap, the other doesn't. Which loan is actually cheaper?
Two term sheets for the construction facility. Lender A has the tighter margin but requires you to buy a two-year SOFR cap at a strike they choose. Lender B costs more over SOFR and asks for nothing. On the margins alone, A wins. But the cap is cash out of the door on day one, and B leaves you floating against whatever SOFR does next. You need the all-in cost of each offer, side by side, in a table the rest of the team can read without learning a pricing tool.
Last updated: October 2026 · Based on real workflows from BlueGamma customers
BlueGamma gives you both inputs the comparison needs: the live premium for the exact cap the lender requires (notional, term and strike) and the SOFR forward curve to project floating interest on each loan. Add the premium to the capped offer, run both offers under the forward curve and a few higher-rate scenarios, and the cheaper loan stops being a matter of opinion. Do it in the web app, in Excel, or have Claude build the table via the MCP connector. BlueGamma is an interest rate data and pricing platform used by 100+ financial institutions for swap rates, forward curves and cap pricing across 30+ currencies.
How the comparison usually gets done
Each of these gets you a number. None of them gets you the number the decision turns on.
Compare the margins
Lender A is 25bp tighter, so Lender A it is. Except the cap premium never made it into the comparison, and neither did the fact that Lender B's loan has no ceiling if SOFR moves the wrong way.
Assume SOFR stays where it is
A flat SOFR assumption across a multi-year construction loan ignores the forward curve. On a two- or three-year term, the curve's shape can move the answer by more than the margin gap you're trying to judge.
Wait for a cap quote
You ask a cap provider for a price at the strike in the term sheet. It arrives when it arrives, for one strike only, and you can't see what the strikes either side would cost when the lender asks what you'd accept instead.
Give the team a login
The people who sign off on the facility aren't going to price a cap. They need a table that says what each offer costs, not a calculator and instructions.
How it works
Two inputs from BlueGamma, one table at the end. Pin everything to the same valuation date so both offers see the same market.
Pull the terms out of both term sheets
Notional, term, margin over SOFR for each lender, and for the lender that requires a hedge, the cap's term, strike and notional. That's everything the comparison needs.
Price the cap the lender requires
Enter the notional, strike and term in the cap pricer for the upfront premium on that exact cap. Look at the strikes and tenors either side too: if a higher strike is much cheaper, that's a point to take back to the lender.
Project SOFR off the forward curve
Pull the SOFR forward curve, in the web app or straight into your model with the Excel add-in, as of the date the term sheets arrived. Project the floating interest on each loan period by period. Same curve, both offers.
Build the scenario table
One row per offer, one column per scenario: the forward curve, then the curve shifted up, say +100bp and +200bp. The capped loan's cost is margin plus SOFR up to the strike, plus the premium; the uncapped loan is margin plus SOFR, all the way up. In the base case the cap usually looks like money spent; in the shock columns it's the reason Lender A exists.
Deliver it, and keep it current
Connect the BlueGamma MCP connector to Claude (Settings → Connectors → add connector) and ask it to pull the curve and the cap premium and rebuild the table on a schedule, so the comparison moves with the market until you sign. Build in a check: if the data didn't refresh, the report doesn't go out and you get a message instead. A stale table sent to the whole team is worse than none.
"Say I have a lender that requires me to buy a cap… but another lender doesn't require me to buy that cap. I want to be able to compare the cost of the capital on an effective basis with the rate cap versus without it."
Head of finance at a US real-estate developer, October 2026
"You gotta deliver it to them… whether it's a sensitivity table or some kind of scenario analysis… that basically tells them what the cost is, not have them calculate it."
The same head of finance, on getting the answer to the team
For this job specifically: how the options compare
Just the job of comparing two loan offers when one comes with a hedge requirement, not a full vendor comparison.
| Margin-only comparison | Flat-SOFR spreadsheet | Cap quote from a provider | BlueGamma | |
|---|---|---|---|---|
| Includes the cap premium | No | Only if you get a quote | Yes, for one strike | Yes, that strike and the ones either side |
| Projects SOFR properly | No | No, one flat rate | Not its job | Yes, off the SOFR forward curve |
| Shows the higher-rate scenarios | No | If you build them | No | Shift the curve, rerun the table |
| Readable by the people signing off | Yes, and misleading | Depends who built it | A price, not a comparison | A scenario table, delivered where they read |
| Keeps up with the market until you sign | No | Only if someone updates it | Ask again | Refreshes from the curve via Excel or Claude |
Where this comes from
The pattern behind this guide, from a real borrower's workflow.
The head of finance at a US real-estate developer had already automated a morning rates report for their team: the SOFR forward curve, swap rates and historical series, interactive, sent to a distribution list, with a safeguard that holds the report back and alerts them if a data pull fails. He brought in the BlueGamma MCP connector so Claude could keep SOFR and Treasury data current in that report and in their models. The question that followed was the one on this page: when one lender requires a cap and another doesn't, what does each offer really cost? Their answer was that it belongs in the same brief, as a scenario table rather than a calculator.
FAQs
Compare all-in cost, not margin. For the loan that requires a cap, add the upfront cap premium to the interest you expect to pay: the margin plus the projected floating rate, capped at the strike. For the loan with no hedge requirement, project the margin plus the floating rate off the forward curve with nothing capping it. Then run both under a few rate scenarios above the forward curve, because that is where the cap earns its premium and the uncapped loan gets expensive.
It depends on where the strike sits against the SOFR forward curve, the notional, the term and market volatility on the day. A strike well above the forward curve is cheap; a strike near it is not. Lenders usually specify the strike and term in the term sheet, so the useful number is the live premium for that exact cap, and for the strikes either side, in case the lender will negotiate. BlueGamma's cap pricer gives both.
The premium is paid upfront, so spread it over the life of the cap to express it in basis points a year on the loan. As a quick check, divide the premium as a percentage of notional by the term in years: a 1% premium on a two-year cap is roughly 50bp a year. For a committee number, discount it properly against the curve. Add that to the capped loan's margin and you have a like-for-like figure against the uncapped offer.
Because the loan will not pay today's SOFR for its whole life. The forward curve is the market's projection of where SOFR fixes each period, and on a two- or three-year construction loan the difference between a flat assumption and the curve can be larger than the margin gap between the two lenders. Projecting both loans off the same forward curve, as of the same date, is what makes the comparison fair.
Yes. The people signing off need the answer, not the pricing tool. Build the scenario table in your own workbook with the Excel add-in, or connect the BlueGamma MCP connector to Claude and ask it to pull the forward curve and the cap premium and rebuild the table on a schedule. The output is a table or a short memo, delivered wherever your team already reads things.
End of day is enough for comparing term sheets: the decision turns on tens of basis points, not on the last tick. Pinning both offers to the previous close also means everyone is looking at the same curve. Live rates matter on the day you actually buy the cap. That is a different job, covered in the live rates at deal closing guide.
Put both term sheets through it before you pick one.
The 14-day trial includes the cap pricer, forward curves, the Excel add-in and the MCP connector. Price the cap your lender wants and see what each offer really costs.
What each step runs on
The features, calculators and live data each step above runs on.
Related use cases
Other jobs the same borrowers run on BlueGamma.