<< Back to articles list

Every credit desk has the same quiet bottleneck. Not data — everyone drowns in data. The bottleneck is the distance between having an idea and knowing what it's worth.

A portfolio manager thinks: "What happens to my book if this name gaps 50 basis points? What if it jumps to default next week?" Answering that properly means a quant, a pricing library, and a few hours — or settling for a consensus mark you can look at but can't move. By the time the number comes back, the idea has gone cold.

We closed that distance to a sentence. Here's how it works — and why the part that matters most is the work the language model is deliberately not allowed to do.

What's under the hood

There's no bespoke black-box model here, and nothing is fine-tuned on your positions. The system is a large language model — Claude — running a Skill that OtcStreaming built. In Anthropic's framework, a Skill is a packaged bundle of instructions and domain knowledge that teaches the model how to carry out one specialized task — an idea now so effective that every major LLM has adopted the same pattern. Ours teaches Claude exactly one thing, and teaches it very precisely: how to turn a plain-English pricing request into a valid call to the OtcStreaming pricing pipeline.

Every request the platform serves hits a single endpoint — /api/v1/pipeline — carrying one request container (we call it the JCorr) and one of six processing stages. The Skill's job is to make three decisions from your sentence:

• The verb — which stage. valuation to price a book and read greeks, tick to convert a single quote into a full price set, latentModel to calibrate a curve from quotes, and so on.
• The nouns — which securities go in which JCorr slot. The portfolio to value, the raw quotes to calibrate from (rawTicks), the reference levels that price something else (marketcontextRawTicks).
• The modifiers — the patches and scenario records that express your "what if": a recovery override, a curve shock, a jump-to-default.

Claude or your alternative LLM emits that structured payload — and then it stops. From there, OtcStreaming orchestrates the computation: it identifies the security against reference data, applies the correct market conventions, calibrates the curve, runs the pricing model, and derives the greeks — each step governed by financial rules that are wrong the moment you improvise them. Claude reads the finished numbers back out of the response, but it performs none of those steps itself. The model handles language; the engine handles finance. That boundary isn't a limitation — it's the whole product, and the next section is why.

Price it

"Price 5-year CDS protection on IBM" becomes a call carrying a single cdsQuery — ticker plus a 5Y maturity — and the engine returns the calibrated ISDA spread, the upfront, and CS01, read straight from the response's computed price and greek fields. You don't specify a fixed coupon; the engine applies the standard coupon convention. One sentence in, a full price set out — every assumption behind it set by the engine, not guessed by the model.

That's the easy part. Plenty of tools hand you a price.

Test the idea

This is the move nothing else does — and it's worth seeing the mechanics.

"Widen IBM's curve 50 basis points and show me the P&L" becomes a scenario. Under the hood, the Skill builds a shock record — an additive spread shift on the survival-probability curve — bundles it into a scenario, and activates it on the security's grid. The engine reprices under the shock and returns the move as a difference against mid.

"What if IBM jumps to default tomorrow" is a different shock family entirely: a conditional survival-probability record that forces default and prices the loss net of recovery.

Two things make this more than a toy:

1. You can bring your own market. Feed your own quotes instead of the live curve and the Skill drops them into rawTicks. Because injected quotes are identified before pricing, calibration and valuation happen in the same call — you never calibrate a curve in one step and value against it in another.
2. The shocks are real curve operations. Multiply the default intensity by a term structure, shift it additively, or age it forward for carry-and-rolldown. These are genuine transformations of the calibrated curve, not a linear sensitivity bolted on after the fact.

You injected a view the market hasn't printed, the engine rebuilt the curve around it, and it repriced. A data feed can't do that — it gives you the market's mark and goes quiet the moment you ask "what if I'm right."

Value the book

"Value my credit book and show CS01 and jump-to-default per name" is a valuation stage over a portfolio slot. The per-name decomposition comes from what we call i-scenarios: instead of shocking the whole basket at once, the engine applies the shock to each constituent in turn and returns each member's impact on the book. That's precisely what per-name CS01 (iCS01) and jump-to-default (iJTD) are — and you get the entire vector back in one call, each entry tagged by the name that moved. Now you can see which single name is quietly driving your risk, and rebalance in the same window where you were just testing ideas.

A worked example: carry and roll across the whole curve

Here's the kind of question that separates a pricing engine from a data feed. A relative-value PM doesn't just want today's 5-year spread — they want to know where on the curve they're paid best to wait. So they ask:

"For IBM, show carry and rolldown across the whole CDS curve at 1-, 3- and 6-month horizons, and flag the best point per unit of risk."

Carry and roll is a horizon question. Carry is the premium a protection seller accrues over the horizon if nothing moves — survival-weighted, on the ISDA schedule. Roll (rolldown) is the mark-to-market that comes purely from time passing: as the trade ages, its remaining maturity shortens, and on an upward-sloping curve the fair spread at that shorter tenor is lower — so the position gains. Add them together and you have the return to simply holding the position with the curve unchanged.

One action, two results. Aging forward is the mechanic; carry and rolldown are what fall out of it. Roll the clock ahead by your horizon so the trade's remaining life shortens, reprice it, then split the P&L: the part from time passing and premium accruing is carry — the rent you earned — and the part from the now-shorter trade landing at a cheaper point on the curve is rolldown — the gain from drifting down the hill as it ages. Together they're your return to simply holding, if the market doesn't move. (On an inverted name the trade ages uphill, so rolldown flips negative — waiting costs you.)

Under the hood the Skill turns this into one structured request, and the engine does the work: it takes today's calibrated hazard-rate curve, advances the pricing date by each horizon while holding that curve static, reprices every benchmark tenor at its now-shortened maturity, and decomposes the change into carry and roll — survival probabilities, accrual conventions and interpolation all handled exactly as they are on every other call. What comes back is a matrix across the whole term structure (illustrative numbers below; protection-seller view, in basis points of spread-equivalent earned over the horizon):

Tenor	Spread (bp)	CS01	C+R · 1M	C+R · 3M	C+R · 6M
1Y	10	0.95	1.6	4.6	7.6
2Y	20	1.91	1.7	4.8	8.9
3Y	30	2.84	1.8	5.1	9.7
4Y	40	3.71	1.8 ✅	5.3 ✅	10.1 ✅
5Y	50	4.54	1.7	5.0	9.8
7Y	65	6.03	1.4	4.2	8.4
10Y	77	7.94	1.1	3.2	6.3

The belly, here around the 3-to-5-year, delivers the most carry and roll in absolute term and per unit of spread duration. The 4 year is the best point. That's the sweet spot an upward-sloping curve is offering, and it's the entire reason to look at the curve at once rather than at a single tenor. (Point the same request at an inverted name and the roll comes back negative — you'd be paying to wait, which is exactly what you want to know before you put the trade on.)

Notice the division of labor one more time. The model recognized "carry and roll across the curve at these horizons," assembled the request, and laid the answer out as a grid. It computed none of it — not one accrual, survival probability, or interpolation. The engine aged the curve and did the finance; the language model asked the question and read back the numbers.

The finance lives in the engine — not the model

This is the part worth dwelling on, because it's exactly where most "AI for finance" tools quietly go wrong.

It is tempting to let a capable language model just do the finance — convert an upfront to a running spread, roll a maturity to the next IMM date, bootstrap a hazard-rate curve, pick the right recovery and day-count. A model will happily produce all of it, fluently and with total confidence. And it will be subtly, expensively wrong. Converting a CDS upfront to a spread isn't arithmetic; it's the ISDA Standard Model, with a specific coupon, accrual convention, IMM-dated schedule, and recovery assumption, applied in a specific order. Miss any one and you get a number that looks entirely reasonable and is off by enough to lose money on. Scenario shocks are the same: multiply-then-shift a curve is not shift-then-multiply, and only one of them is the risk you meant to measure.

None of that judgment lives in the language model, and none of it should. It lives in OtcStreaming's engine — encoded once, correctly, by people who do this for a living, and applied deterministically on every call: the same conventions, the same calibration, the same greek definitions, whether it's the first request of the day or the ten-thousandth. The engine orchestrates the entire chain — identification, convention, calibration, pricing, risk — in the right order under the right rules. The model's only job is to say what you want computed. The engine decides how, and owns every assumption behind the answer.

That division is the real advantage, not a caveat. The failure mode everyone rightly fears — a chatbot that "knows" finance and states a plausible, wrong number — is impossible here by construction, because the component that talks never computes. Every spread, P&L, and greek you see is produced by the engine and traces back to a specific call you could replay by hand. The model removes the syntax. The engine owns the finance. Neither does the other's job.

Where this sits

Three kinds of tools already live on a credit desk, and each does something real. Consensus and evaluated data gives you trusted, validated marks with deep history — but hands you the number; you can't inject your own quote and reprice against it. Quant pricing libraries give you the rigor, at the cost of a quant desk and an integration project to operate them. Terminal-based AI assistants are arriving fast and are genuinely useful for research and discovery — but summarizing what the market said is a different job from recalibrating a curve to your view and repricing your book.

Our wedge is the space none of them fill: a credit-specialized pricing engine you drive by talking to it, where you bring your own quotes and scenarios, self-serve, without a quant desk — at the footprint of an API call rather than a terminal fleet or an enterprise install.

The point

A mark tells you where the market is. That's necessary, and not enough. The edge on a credit desk has always come from testing a view before the market catches up — and until now, that test was slow, gated, and expensive.

Price your idea. Shock it. Value the book. Plain English on top, a real pricing engine underneath, and a hard line between the two.

That's the loop. The rest is just typing.

<< Back to articles list