← Glossary

Devancore Post-Trade Glossary

Portfolio Risk Controls

Portfolio risk controls turn exposures, limits, liquidity, counterparty, collateral, and settlement signals into governed post-trade checks, exceptions, approvals, and evidence.

Definition

Portfolio risk controls are the workflows that convert risk signals into governed post-trade state. They connect exposure, liquidity, counterparty, collateral, settlement, and investment guideline checks to the records that operations can accept, investigate, approve, correct, and evidence.

A portfolio risk number has limited operating value by itself. The control value comes from the record around it: which positions, prices, FX rates, cash balances, collateral records, and settlement events were used; which limit version applied; whether the result passed or breached; who owned the exception; and how the issue was closed.

Risk systems often consume the same data that post-trade systems validate. If positions are stale, prices are unapproved, cash is unreconciled, collateral is missing, or a settlement fail is not reflected in the operating view, the risk signal can look precise while resting on a weak record. Portfolio risk to post-trade controls is the discipline of making those signals operationally usable.

Risk signal to control record

Risk signal to control record

Risk controls depend on the same post-trade records that operations validate.

Risk area Post-trade data Control question
Exposure Position, price, issuer, sector, currency, fund, and account Does the portfolio remain within concentration, mandate, or factor limits?
Counterparty Broker, custodian, clearing venue, and settlement exposure Can the counterparty receive the trade, hold the position, or settle the cash leg?
Liquidity Holding size, market depth, cash, settlement date, and redemption profile Can the position or cash requirement be handled within the operating window?
Collateral Margin call, pledge, eligibility, haircut, and valuation Does the collateral state support the exposure and required movement?
Settlement SSI, fail status, cash projection, security leg, and finality event Does the settlement state increase portfolio or operational risk?
Guideline Mandate rule, restricted list, override, and approval trail Is the exception permitted, documented, and time-bounded?

Portfolio risk controls sit between analytical risk management and institutional operations. A risk model may calculate VaR, duration, DV01, sector exposure, liquidity stress, concentration, counterparty exposure, or margin sensitivity. The post-trade control process determines whether that signal should create a workflow item, block a downstream action, require approval, feed reporting, or remain available for monitoring.

The distinction between pre-trade and post-trade checks matters. A pre-trade check reviews an intended order before execution. A post-trade check reviews the actual portfolio after execution, allocation, price movement, cash movement, collateral change, corporate action, settlement update, or manual correction. Passive breaches can arise without a new trade. A price move, rating change, corporate action, FX shift, or collateral haircut can move a portfolio outside a limit after the original order passed.

How it works

A portfolio risk control workflow starts with source state. The system needs a current view of orders, executions, allocations, positions, cash, prices, FX, security reference data, counterparty records, collateral balances, and settlement status. The stronger the source state, the more credible the risk signal.

The risk signal is then calculated or received. It may come from a dedicated risk engine, a portfolio management system, a compliance engine, a collateral system, a treasury workflow, or a data warehouse. The operating question is whether the signal can be linked back to the record that produced it.

The control engine checks the signal against a rule. That rule may be a client mandate, portfolio limit, internal risk tolerance, investment guideline, liquidity threshold, collateral policy, counterparty limit, restricted list, or supervisory policy. The result should become state: passed, breached, stale, pending review, corrected, approved exception, or closed.

Breach handling is where weak operating models usually show. A breach should have an owner, reason code, severity, open date, aging, required action, escalation path, and evidence. A passive breach caused by market movement should be separated from an active breach caused by trading. An intentional override should be separated from an unresolved exception. A timing item should not be treated the same as a policy breach.

Portfolio risk control workflow

Portfolio risk control workflow

A risk signal becomes useful when it becomes owned workflow state.

Step Record checked Evidence
Ingest state Trades, allocations, positions, cash, prices, FX, collateral, and settlement events Source timestamp and record lineage
Calculate signal Exposure, liquidity, counterparty, margin, guideline, or concentration measure Calculation version and input set
Check limit Mandate, portfolio rule, counterparty threshold, collateral policy, or operating tolerance Limit version and pass or breach result
Classify issue Active breach, passive breach, stale input, timing item, override request, or operational exception Reason code, owner, aging, and severity
Approve or resolve Maker-checker decision, correction, hedge, collateral movement, cash movement, or documented exception Approval, comment, attachment, and close state
Report state IBOR, ABOR, PBOR, compliance report, audit trail, or management dashboard Current status and retained evidence package

Portfolio risk controls also connect to cash and collateral. A change in volatility, exposure, or counterparty risk may increase margin requirements, change eligible collateral, create a cash movement, or alter settlement readiness. An automated margin call workflow based on portfolio risk depends on the same operating facts that support cash reconciliation, position reconciliation, collateral records, and settlement status.

Liquidity risk monitoring for post-trade operations has a similar dependency. A portfolio may be within investment limits while still creating operational pressure: cash may be needed before settlement, securities may be hard to deliver, FX may settle on a different calendar, or a fail may affect the next day operating state. A risk control process should show whether liquidity pressure is analytical, operational, or both.

The audit trail should preserve more than the final answer. It should preserve the input set, calculation time, limit version, breach classification, approval trail, remediation record, and reporting output. Investment guideline compliance reporting evidence depends on that chain. Without it, a firm may know that a breach was resolved while struggling to prove how it was detected, approved, corrected, and closed.

In Devancore™

Devancore should be framed as the post-trade operating record and control layer around portfolio risk signals. It supports the workflow state behind positions, cash, settlement events, collateral records, reconciliations, exceptions, approvals, and reporting evidence.

In a Devancore-style workflow, risk signals do not sit apart from operations. A portfolio exposure, guideline result, liquidity pressure point, margin movement, or counterparty limit check can be connected to the trade, position, cash, collateral, and settlement records that explain it. The platform can help teams see whether the issue is a stale input, a timing difference, a real breach, an approved exception, or an unresolved control item.

Devancore does not replace the portfolio manager, risk model, adviser, custodian, broker, fund administrator, accounting system, or compliance judgment. Its role is to help preserve the operating record, workflow status, evidence, and cross-team context that make portfolio risk controls usable.

That matters for conversational finance as well. A user asking, "show open sector breaches with no approval," or "which collateral calls are tied to risk changes," should receive an answer grounded in controlled records, not a loose summary. The answer should point back to source positions, cash, risk signal, control state, owner, timestamp, and evidence.