DERIVSOURCE: Applying Agentic AI in Portfolio Risk Analysis and Derivatives

Applying Agentic AI in Portfolio Risk Analysis and Derivatives: Why Legacy Platforms Aren’t Fit for Purpose

By Prashant Panjwani, Associate Director of Product Management, Publicis Sapient

Introduction & Context

Portfolio risk management is a critical part of the investment process. It involves identifying and measuring risk, then taking action to keep portfolio exposure within target ranges. Effective risk management requires continuous exposure monitoring and timely adjustments when conditions change.

The execution of risk management transactions to manage market or financial risk is therefore an important and a distinct step in the portfolio risk management process. Derivatives particularly play an important role for institutional PMs to manage portfolio risk or take tactical views.

For Fixed Income portfolios, Interest Rate and Credit Derivatives are generally the preferred choice and are increasingly becoming the workhorse for Fixed Income risk management with around $650 trillion and $10 trillion in notional outstanding respectively, both growing at double-digit rates year-on-year.

For Equity oriented portfolios, exchange traded derivatives are generally the first choice; however, buy side participants are increasingly turning to bespoke OTC Equity derivatives to meet their portfolio needs, particularly Equity swaps and over the counter Equity options.

The process of execution of risk management transactions involves 3 key steps:

1. Trade Identification 
2. Pricing
3. Execution

Identifying the right derivative trade or set of trades to hedge a complex portfolio or take a tactical view is often an involved process and generally lives within PM’s spreadsheets, python notebooks, market data tools like Bloomberg or simply experience and judgement.

As an illustration, consider a scenario where Fixed Income portfolio manager wants to adjust its portfolio duration and achieve a specific DV01 profile using Interest Rate swaps.

The simplest strategy could be to choose IRS tenor closest to portfolio duration and calculate notional size based on target portfolio duration. A more robust strategy would be to compare di erent IRS tenors, model different notional sizes and calculate cost of carry for each trade and select the most suitable trade/s accordingly.

Trade Identification is therefore the most important step in the process as choosing the wrong trade may not produce the desired results; yet current derivatives platforms fall short of supporting complex & on-demand portfolio analysis and identifying the right trades to manage the portfolio risk.

Why Legacy Platforms Fall Short

This is because legacy platforms that support derivatives are designed and built for trade capture and execution, not trade identification. They assume the terms of the trade are already identified, and treat the trade as ready to be captured, priced and executed on those terms.

The result is a workflow that splits cleanly along the line these platforms draw. Everything to the right of trade identification — capture, pricing, execution, confirmation, settlement — lives inside the enterprise stack and is well supported. Everything to the left of it — the scenario analysis that decides which trade to do — lives outside it, in the PM’s spreadsheet, a Python notebook, a Bloomberg screen, or simply judgement. The platform only engages once a human has already done the hard part and arrived at a set of terms. Exhibit 1 contrasts that linear, terms-already-known pipe with the loop an agentic workflow actually requires.

Exhibit 1: Current state representation  

Closing the Loop with Agentic AI

Agentic AI closes this loop by bringing trade identification inside the system. A PM states an objective — model a target DV01, hedge a credit exposure, take a tactical view — and agents construct candidate trades, resolve reference terms, price them, score them against portfolio constraints, rank them, and then keep monitoring the position and rerunning as conditions change. The pre-trade analysis that used to live in a spreadsheet becomes a repeatable, governed capability — which is what makes on-demand scenario analysis and continuous risk management practical at the speed a portfolio actually demands.

What Has to Change — and Why It’s Hard

Plugging current platforms into an agentic workflow requires a fundamental shift in how derivatives are modelled and priced, before and after trade execution. It should be recognized that modelling a derivative to support portfolio analysis is a separate process from capturing it for execution: it requires constructing hypothesized trades from standardized or pre-modelled terms and pricing them independently before any execution decision. This holds whether the instrument is exchange-traded or OTC — only the weight shifts. The principles below are simple to state and hard to build; each carries the constraint that explains why this is challenging.

• Decouple reference terms from pricing. Resolving a trade’s terms must be a separate step from pricing it — a reference agent solves for candidates (tenors, strikes, contracts) and returns standardized terms, which the pricing step then consumes. The hard part: terms aren’t static or universal. Day-count, business-day adjustment, fixing lags, calendars and roll conventions vary by currency, index and clearing venue, and they change — a SOFR swap cleared at LCH doesn’t carry the same conventions as one at CME. So, terms have to be a governed, versioned asset, not something an agent infers. For listed derivatives this step is lighter, since contract specs are published, but the discipline is the same.
• Price candidates in batch, in one call. The pricing agent should price many hypothesized trades in a single pass so the orchestrator can loop, compare and rank. The hard part: scenario analysis is combinatorial — tenors, notionals, strikes, instrument types — and an engine that prices one slow call at a time won’t survive a PM who wants an answer before the market moves. Pricing must be batchable, cheap and reproducible, with every call pinned to one timestamped market view, or the comparison is meaningless. Whether you build this engine or buy a third-party pricing service is a real decision — coverage, scalability and integration cost all matter — but either way the batched, governed contract is the same.
• Keep the LLM out of every deterministic calculation. The LLM’s job is to parse intent, invoke tools, apply guardrails, run general analysis and present — never to compute a price or a sensitivity. The hard part: that doesn’t remove model risk, it relocates it into a pricing engine that is still a model, and now needs validation, versioning and a stamp on every output so risk and compliance can sign off on what the agent suggests.
• Score against the portfolio constraints. A good hedge isn’t simply the best-priced one — it should clear liquidity, eligibility and collateral or margin footprint, checked by a separate process. The hard part: this only works if the underlying infrastructure exposes those constraints. Where it doesn’t, scoring is post-MVP, not a first product build — better to ship a smaller honest loop than iteratively build on it.
• Everything reads from the governed stack — starting with IBOR. No agent assumes a data point; positions, exposures, prices and terms all come from governed enterprise sources. The hard part: this is regulated capital, so auditability is table stakes — every suggested trade must be reconstructable (what data, which terms, which engine version, which constraints, which agent decided what). And none of it is seamless without a reliable, performant IBOR as the source of truth for positions and exposures — the starting point for any portfolio analysis, not an afterthought.

None of these is a reason not to build. Together they are the specifications for what you have to build first.

What the Solution Looks Like 

The way through is to stop treating “model the derivative” as a single step and build the governed layers the principles depend on. Each layer answers one of the problems above.

• Portfolio positions and exposures from IBOR. None of the layers below produces a meaningful hedge without a reliable, governed book of record. The IBOR is the source of truth for what the portfolio holds and is exposed to — the starting point every agent reads from before it hypothesizes a single trade.
• Derivatives Reference Terms registry. Derivatives reference terms become a firstclass, governed asset rather than something an agent guesses. Seed it from authoritative sources — ISDA definitions, the CCP rulebooks, market conventions — and version it, so that any trade the system hypothesizes is built from a known, dated, venue-specific set of conventions. The reference terms should be owned & governed by relevant operations teams. When LCH changes a rule, the registry changes, and every downstream price knows which version it uses. This is what makes the reference agent trustworthy: it isn’t reasoning about conventions; it’s resolving them against a source of truth.
• A live market-data layer. Beneath the pricing agents sits a unified, as-of view of the market — curves, fixings, spreads, prices — assembled from market data feeds. What it assembles differs by instrument class: for OTC trades it gathers the curves, fixings and spreads needed to construct a price; for exchange-traded instruments it ingests observed exchange data directly — settlement prices, quotes and the listed option surface — so the system consumes prices rather than building them. The critical property is not freshness alone but reproducibility: every pricing call references a specific, time-stamped snapshot, so comparisons across candidates are consistent and any single result can be reconstructed later.
• A deterministic pricing engine under model governance. The math lives here, in tested, versioned code — never in the LLM. The engine takes resolved conventions and a market data snapshot and returns a price, with the engine version stamped on the output. Its weight also shifts by instrument class: for OTC the engine derives the price itself from terms and market data, whereas for exchange-traded instruments the mark is already observable, so the engine narrows to analytics and scenario work — revaluing candidate hedges under shifts, computing sensitivities and exchange margin. Same governed, versioned engine; for listed instruments it answers, “what does this do to my risk and margin” rather than “what is this worth”. It is validated and governed like any front-o ice pricing model, which is what lets risk and compliance sign o on agent-suggested trades.
• Orchestrating agents that decompose the problem. On top of these layers the multivariate problem becomes tractable: a reference agent resolves conventions, a pricing agent prices candidates in batch against the snapshot, and further agents score each candidate on the constraints that bind — margin and collateral footprint, liquidity, eligibility — before ranking and presenting. The LLM orchestrates, guards and explains; it never computes. Because each step reads from a governed layer and writes a stamped, traceable output, the chain is reproducible and auditable by construction.

Put together, this turns trade identification from something that happens in a PM’s head and spreadsheet into a first-class, governed capability inside the enterprise — exactly the step legacy platforms skipped.

Exhibit 2: Target Agentic Future State Solution 

About the Author

Prashant Panjwani, CFA, is an Associate Director of Product Management at Publicis Sapient with 20+ years at the intersection of investment management and enterprise technology. He currently leads the trading workstream for a front-to-back transformation at a $2.3T global asset manager, and has delivered portfolio, trading, and OTC derivatives platforms at firms including Wellington Management and Invesco. His current focus is how agentic AI is reshaping the asset management industry and its workflows.