Market Data in SAP Treasury

Market data is the external reference SAP TRM values everything on — FX rates, reference interest rates and yield curves, security prices, and indexes — and every valuation and risk number the system produces is only as good as the data feeding it. That's the honest one-line version. After eighteen years in SAP FI and TRM, here's what I've learned that the documentation never says out loud: market data is treated as plumbing, quietly essential and badly under-owned, right up until a period-end valuation comes out wrong and everyone discovers a rate that never loaded. The Market Risk Analyzer gets the attention because it produces the numbers. This is the article about what those numbers are made of.

What market data actually is here

In TRM, "market data" means the external, market-observed reference values that a valuation applies to a position. It isn't your deals and it isn't your positions — those come from the Transaction Manager. It's the other half of the calculation: the prices and rates from outside the company that turn a contract into a value. In practice that's four families of data:

• FX / exchange rates — the rate at which one currency converts to another, used everywhere from translating a foreign-currency position to valuing an FX deal.
• Reference interest rates and yield curves — the reference rates, and the curves built from them, that discounting and interest calculations run on.
• Security prices — the market prices of the securities a treasury holds.
• Indexes — the reference indexes that certain instruments and calculations point at.

None of this is exotic. It's the standard external reference data any treasury system consumes. What's easy to underestimate is how much of TRM's output is really just this data, applied.

How it gets in

Two routes, and most implementations use both.

For small volumes, market data can be entered manually — a few exchange rates keyed in to close a period, a price captured by hand. That's fine at low scale and dangerous as a habit, because manual entry is exactly where a typo becomes a valuation.

For anything real, market data comes through a market-data / datafeed interface that imports rates, curves and prices automatically from an external provider. Automation isn't just about volume; it's about consistency and timing — the same rates, on the same schedule, without a human deciding which ones to type today.

Underneath both routes sits the concept of the rate type: SAP lets the same currency pair or reference rate be held under different rate types for different purposes, so you can distinguish, say, a rate used for one calculation from the one designated as the official rate used for valuation. That distinction is not bureaucracy. It's how you make sure the number that hits the accounts is the number you chose for that job, not whichever one happened to be lying around.

The right rate, at the right time

Here's the whole discipline in one sentence: valuation and risk inherit whatever rate they're handed, and they never argue.

"

The same instrument, valued on the wrong rate or the wrong date, gives a wrong number that looks exactly as confident as the right one — and it flows straight to the accounts and the risk figures without ever raising an error.

That's what makes market data unforgiving. A position valued on yesterday's curve, or on a rate under the wrong rate type, or on a date that's off by one, doesn't fail loudly. It produces a precise, plausible, wrong result. The valuation run doesn't know the rate was stale — it only knows what it was given. Getting the right rate, under the right type, on the right date is not a nicety layered on top of valuation; it is the valuation, half of it, and it's the half nobody watches.

Governance and control

Because the data is so consequential and so quiet, it needs governance that matches:

• One authoritative source. When two feeds or two rate types can each answer "what's the rate," calculations stop reconciling and nobody can say which number is the number. Decide the source of truth and make everything defer to it.
• Controlled updates. Who can change a rate, when, and on what schedule — market data changed casually is market data you can't trust at close.
• Completeness. This is the one that bites. A missing yield-curve point, a price that didn't come through, a rate that never loaded — none of these throw an error. They just quietly corrupt whatever they touch. Completeness has to be checked, not assumed, because the system won't volunteer the gap.

Where it feeds

Everything downstream drinks from this well. The Analyzers — market risk, credit risk and portfolio — all compute on market data. Position valuation discounts and marks against these curves and prices. Risk measures, sensitivities and scenarios are all just this data, moved and re-applied. So the reach of a single bad rate is enormous: it isn't one wrong figure, it's every calculation that touched that figure, all wrong the same way.

The part the docs leave out

The documentation describes market data cleanly — enter it or import it, assign the rate types, run the valuation. What it doesn't tell you is the organisational truth: market data is under-owned. It sits between the treasury team who assume "the system has the rates" and IT who assume "the business checks them," and in that gap a feed quietly stops one day and nobody notices until the numbers are already wrong. On more than one project the fix wasn't technical at all — it was giving the data an owner, a checklist, and a completeness check before the valuation run, not after.

Market data is the least glamorous thing in SAP Treasury and one of the most decisive. Treat it as plumbing and it will behave like plumbing — invisible until it floods. Treat it as the input product that every valuation and risk number is built from, give it one source, control its updates, and check it's complete, and everything downstream gets to be right for the right reason.

Part of the SAP Treasury & Cash Management guide. See also the SAP Market Risk Analyzer and what is SAP Treasury and Risk Management. The newsletter sends one finance-systems pattern every two weeks.