DEV Community: Agent Risk Desk

Your options agent will get assigned on a Friday it didn't plan for

Agent Risk Desk — Sat, 31 Oct 2026 19:42:24 +0000

Most trading agents treat an option like a stock with a funny price. Brokers don't. Three things catch agents out:

Dividend early assignment. If your agent is short an in-the-money call and the time value left in it is less than the next dividend, the holder will usually exercise the day before ex-dividend. Your agent then delivers the shares and gives up the dividend (or owes it, if it ends up short the stock).
Pin risk. If the stock closes within about 1% of a short strike on expiration day, nobody knows until after the close whether you'll be assigned. That's an unplanned position over the weekend.
Auto-exercise. The OCC exercises expiring longs that are $0.01 or more in the money unless you opt out. A cash account that can't pay for 100 shares per contract gets a margin call or a forced sale on Monday.

Then there's the margin side. A naked short put or call needs the FINRA Rule 4210 requirement: the premium plus the greater of 20% of the underlying minus the out-of-the-money amount, or 10%. Your broker's options approval level also has to allow the strategy at all.

options_risk_check checks all of this before your agent sends the order: margin requirement, approval level, dividend assignment, pin risk, auto-exercise cash and net Greeks. It costs $0.01 per call, with 25 free calls a day on a free key (the get_api_key MCP tool gets you one in-session).

MCP: agent-financial-advisor.agent-financial-advisor.workers.dev/mcp?src=devto2
Examples: github.com/mytomclinic/agent-financial-advisor/tree/main/examples

Add a pre-trade check to an Alpaca agent in about 20 lines

Agent Risk Desk — Fri, 30 Oct 2026 14:09:43 +0000

If you let an agent place orders on Alpaca, the agent decides the size. Alpaca will reject an order you can't pay for. It won't tell you that one order puts 60% of the account in one stock, or that the stop is so far away a bad day costs 5% of equity.

So I put a check in front of submit_order. The agent builds the order, the check looks at the account and the order, and only an approved order goes out.

The function

This uses alpaca-py for the account and positions and my Agent Financial Advisor API for the check. It works on paper keys.

import os, requests

AFA = "https://agent-financial-advisor.agent-financial-advisor.workers.dev/v1/tools/pre_trade_check"

def checked_order(trading, symbol, side, qty, stop=None, last_price=None):
    acct = trading.get_account()
    positions = [{"symbol": p.symbol, "quantity": float(p.qty), "market_price": float(p.current_price),
                  "avg_cost": float(p.avg_entry_price)} for p in trading.get_all_positions()]
    body = {
        "account": {"type": "margin" if float(acct.multiplier) > 1 else "cash", "equity": float(acct.equity),
                    "cash": float(acct.cash), "buying_power": float(acct.buying_power), "positions": positions},
        "order": {"symbol": symbol, "side": side, "quantity": qty, "order_type": "market",
                  **({"stop_loss_price": stop} if stop else {})},
        **({"market": {"last_price": last_price}} if last_price else {}),
    }
    key = os.environ.get("AFA_API_KEY")
    r = requests.post(AFA, json=body, headers={"authorization": f"Bearer {key}"} if key else {}, timeout=10)
    r.raise_for_status()
    result = r.json()
    for c in result["checks"]:
        if c["status"] != "pass":
            print(f"{c['status']}: {c['id']}: {c['message']}")
    return result

trading is a normal TradingClient(key, secret, paper=True). The multiplier tells you cash or margin. Alpaca reports 1 for a cash account.

Using it

result = checked_order(trading, "NVDA", "buy", 40, stop=170, last_price=185)
if result["decision"] != "reject":
    trading.submit_order(MarketOrderRequest(symbol="NVDA", qty=40, side=OrderSide.BUY,
                                            time_in_force=TimeInForce.DAY))

decision is approve, approve_with_warnings or reject. I let warnings through and log them. You could be stricter.

What it caught

I ran it against a small test account: cash account, $12,000 equity, $3,000 cash, 30 shares of AAPL. The agent wants 40 NVDA at $185 with a stop at $170. Here's what came back (trimmed):

{
  "decision": "reject",
  "summary": "REJECT: 3 failed, 0 warning(s), 2 passed.",
  "suggested_quantity": 12,
  "checks": [
    {"id": "market_hours", "status": "pass", "message": "Regular trading session."},
    {"id": "buying_power", "status": "fail", "message": "Cost $7400 exceeds cash $3000."},
    {"id": "leverage", "status": "pass", "message": "Gross exposure after trade 1.19x equity."},
    {"id": "concentration", "status": "fail", "message": "NVDA would be 61.7% of equity (limit 20%). Max additional quantity: 12."},
    {"id": "risk_per_trade", "status": "fail", "message": "Risk to stop $600 = 5% of equity (limit 2%). Quantity for limit: 16."}
  ]
}

Three problems in one order. Alpaca would have caught the first one. The other two would have gone through.

It also suggests a size, 12 shares. I don't send that blindly. I run the check again with 12:

{
  "decision": "approve",
  "summary": "APPROVE: 0 failed, 0 warning(s), 5 passed.",
  "checks": [
    {"id": "buying_power", "status": "pass", "message": "Cost $2220 within settled cash $3000."},
    {"id": "concentration", "status": "pass", "message": "NVDA would be 18.5% of equity."},
    {"id": "risk_per_trade", "status": "pass", "message": "Risk to stop $180 = 1.5% of equity."}
  ]
}

That one goes out.

Why bother

A model doesnt hold an account's state in its head between turns. It will size a trade off whatever number it last saw, or off nothing. A check like this reads the live account every time and gives a yes or no with reasons, so the agent can't talk itself past it.

Same inputs give the same answer, and every check says which rule it applied. That makes the logs easy to read when you go back and ask why an order didn't go out.

Limits and setup

No signup for the first 5 calls a day. POST /v1/keys gives a free key with 25 calls a day. Put it in AFA_API_KEY.
The limits above (20% concentration, 2% risk to stop) are defaults. Pass a policy object to change them, for example {"max_position_pct": 0.1}.
It doesn't replace the broker's own checks. It runs before them.
It's rule-based analysis for software, not investment advice.

The full script, with argument parsing and the submit step, is in the repo: alpaca_pre_trade_guard.py. If your agent talks MCP instead, the server is at https://agent-financial-advisor.agent-financial-advisor.workers.dev/mcp and the tool is pre_trade_check.

Disclosure: I built this. If there's a check you want your agent to run that isn't in there, tell me in the comments.

Wash sales and tax lots: what a trading agent gets wrong when it sells

Agent Risk Desk — Mon, 26 Oct 2026 14:07:33 +0000

Ask a trading agent to sell 50 shares and it will usually just send the order. The broker then picks which shares you sold, and by default that's first in, first out. That one default can be the difference between owing tax and booking a loss.

There's also the wash sale rule, which most agents don't track at all.

Here's what goes wrong and how to check it before the order goes out.

Which shares did you sell

If you bought the same stock at different times and prices, each buy is a separate tax lot. When you sell part of the position, the lot you sell sets your gain or loss.

Say an agent holds 100 shares of XYZ in two lots and the price is now $100:

Lot A: 50 shares at $80, bought 2025-11-05
Lot B: 50 shares at $120, bought 2026-02-10

Sell 50 shares with FIFO and you sell lot A. That's a $1,000 short-term gain. Sell lot B instead and it's a $1,000 short-term loss. Same order, same price, a $2,000 swing in taxable income.

Most brokers let you pick lots (specific identification), but someone has to tell them. If the agent doesn't, you get the default.

Short-term vs long-term

Lots held more than a year are taxed as long-term gains, which is usually a much lower rate. So the date on each lot matters too. Selling a gaining lot a few days before it turns long-term can cost real money for no reason.

The wash sale rule

If you sell at a loss and buy substantially identical shares within 30 days before or after the sale, the loss is disallowed for now. It gets added to the basis of the replacement shares instead. The rule is 26 U.S.C. 1091.

Agents trip on this all the time. They sell a loser, then their strategy buys the same ticker back a week later. Or they bought more 2 weeks ago and then sell an older lot at a loss. Either way the loss they planned on doesn't count this year.

Checking it with one call

I built a service called Agent Financial Advisor and one of its tools is tax_lot_plan. You give it the lots, the sale, and recent buys. It compares FIFO, LIFO, HIFO and a minimum-tax pick, splits short-term and long-term, and checks the wash sale window.

Here's the example above. I'm using 32% short-term and 15% long-term rates:

curl -X POST https://agent-financial-advisor.agent-financial-advisor.workers.dev/v1/tools/tax_lot_plan \
  -H "content-type: application/json" \
  -d '{
    "mode": "sell",
    "symbol": "XYZ",
    "lots": [
      {"lot_id": "A", "symbol": "XYZ", "quantity": 50, "cost_basis_per_share": 80, "acquired_date": "2025-11-05"},
      {"lot_id": "B", "symbol": "XYZ", "quantity": 50, "cost_basis_per_share": 120, "acquired_date": "2026-02-10"}
    ],
    "sell": {"quantity": 50, "price": 100, "date": "2026-10-26"},
    "recent_transactions": [],
    "tax_rates": {"short_term": 0.32, "long_term": 0.15}
  }'

Response, trimmed:

{
  "recommended": {
    "method": "lifo",
    "lots": [{"lot_id": "B", "quantity": 50, "term": "short", "gain": -1000, "est_tax": -320}],
    "est_tax": -320
  },
  "savings_vs_fifo": 640,
  "comparisons": [
    {"method": "fifo", "short_term_gain": 1000, "long_term_gain": 0, "est_tax": 320},
    {"method": "lifo", "short_term_gain": -1000, "long_term_gain": 0, "est_tax": -320},
    {"method": "hifo", "short_term_gain": -1000, "long_term_gain": 0, "est_tax": -320},
    {"method": "min_tax", "short_term_gain": -1000, "long_term_gain": 0, "est_tax": -320}
  ],
  "wash_sale": {
    "loss": -1000,
    "replacement_buys_in_window": [],
    "likely_wash_sale": false,
    "avoid_buying_until": "2026-11-26"
  },
  "lots_turning_long_term_soon": [
    {"lot_id": "A", "long_term_on": "2026-11-06", "days_away": 11}
  ]
}

FIFO would owe about $320. Picking lot B gives a loss worth about $320 the other way, so $640 apart. It also says lot A turns long-term in 11 days, which is worth knowing before anything sells it. And it gives a date: don't buy XYZ back before 2026-11-26 or the loss gets washed.

Now add a recent buy

Same position, but the agent also bought another 50 shares at $105 on 2026-10-12, two weeks ago. That's lot C. I changed lot A to an older date too, so it's already long-term. The sale is the same:

curl -X POST https://agent-financial-advisor.agent-financial-advisor.workers.dev/v1/tools/tax_lot_plan \
  -H "content-type: application/json" \
  -d '{
    "mode": "sell",
    "symbol": "XYZ",
    "lots": [
      {"lot_id": "A", "symbol": "XYZ", "quantity": 50, "cost_basis_per_share": 80, "acquired_date": "2025-03-14"},
      {"lot_id": "B", "symbol": "XYZ", "quantity": 50, "cost_basis_per_share": 120, "acquired_date": "2026-02-10"},
      {"lot_id": "C", "symbol": "XYZ", "quantity": 50, "cost_basis_per_share": 105, "acquired_date": "2026-10-12"}
    ],
    "sell": {"quantity": 50, "price": 100, "date": "2026-10-26"},
    "recent_transactions": [{"symbol": "XYZ", "side": "buy", "date": "2026-10-12", "quantity": 50}],
    "tax_rates": {"short_term": 0.32, "long_term": 0.15}
  }'

Trimmed:

{
  "recommended": {
    "method": "hifo",
    "lots": [{"lot_id": "B", "quantity": 50, "term": "short", "gain": -1000, "est_tax": -320}]
  },
  "savings_vs_fifo": 470,
  "wash_sale": {
    "loss": -1000,
    "replacement_buys_in_window": [{"symbol": "XYZ", "side": "buy", "date": "2026-10-12", "quantity": 50}],
    "likely_wash_sale": true,
    "avoid_buying_until": "2026-11-26",
    "note": "Purchases within 30 days of this loss sale make some or all of the loss nondeductible now; it shifts into the replacement shares' basis. Lots bought in the window and being sold now do not count as replacements."
  }
}

The lot pick still looks best on paper, but likely_wash_sale is now true. The $1,000 loss won't count this year because of the buy on 2026-10-12. The agent that planned on a $320 tax benefit gets nothing for now.

How I'd wire it into an agent

Before any sell order:

Pull lots and the last 30 days of buys from the broker.
Call tax_lot_plan with the sale.
If likely_wash_sale is true, stop and decide if the loss matters. If it does, sell a different lot or wait.
Send the order with the recommended lot IDs as specific identification, and confirm them with the broker by settlement.
Save avoid_buying_until and block buys of that ticker untill then. That includes IRAs and dividend reinvestment, which agents forget about.

Step 5 is the one that matters most. Most wash sales come from the buy after the sale, not before.

There's also mode: "harvest", which takes positions plus current prices and lists losses worth harvesting. Same wash sale checks.

Try it

Tool list and schemas are at https://agent-financial-advisor.agent-financial-advisor.workers.dev/llms.txt. There's an MCP endpoint at /mcp too. You get 5 free calls a day per IP, or 25 a day with a free key. The rules_digest tool is free and returns the current wash sale, holding period and settlement rules with sources.

Outputs are automated checks, not tax advice. Talk to an actual tax person before relying on any of this with real money.

Is your trading agent's backtest overfit? Checking the Deflated Sharpe Ratio with one API call

Agent Risk Desk — Fri, 23 Oct 2026 14:11:36 +0000

If you let an agent search for a trading strategy, it will find one with a great Sharpe ratio. That part is easy. The hard part is knowing if the edge is real or if the agent just tried enough variants that one of them got lucky.

Here is how to check it with one API call.

Why agents overfit

An agent that tunes a strategy usually loops. Change the lookback. Change the stop. Add a filter. Run the backtest again. Keep the best one.

Each run is a trial. If you run 200 trials on noise, the best one will still look good. The Sharpe you report is the max of 200 draws, and the max of 200 draws is always higher than a typical draw. Your agent doesn't know that unless you tell it.

The usual Sharpe ratio ignores all of this. It also assumes returns are roughly normal and that you have plenty of data. Short backtests with fat tails or negative skew make it look better than it is.

What the Deflated Sharpe Ratio does

The Deflated Sharpe Ratio comes from David Bailey and Marcos Lopez de Prado (2014). It starts from the Probabilistic Sharpe Ratio, which is the probability that the true Sharpe is above some benchmark, given your sample length, skew and kurtosis.

The deflated version raises that benchmark. The more trials you ran, the higher the Sharpe you would expect from luck alone. DSR asks how likely it is that your Sharpe beats that luck hurdle.

So it adjusts for four things:

how many strategy variants you tried
skew of the returns
kurtosis (fat tails)
how many periods of data you have

The output is a probability between 0 and 1. A common cutoff is 0.95.

The API call

I built a service called Agent Financial Advisor, and one of its tools is strategy_audit. If you send it an empty body it tells you what it needs:

curl -X POST https://agent-financial-advisor.agent-financial-advisor.workers.dev/v1/tools/strategy_audit \
  -H "content-type: application/json" -d '{}'

Provide trades (with pnl) or at least 2 periodic returns.

The input schema (from GET /v1/tools) takes trades (each with pnl or return_pct), or returns as decimals, plus periods_per_year, n_trials, an optional trial_sharpe_variance and starting_equity.

Here are 24 monthly returns from a made-up strategy. First I say it was the only thing I tested:

curl -X POST https://agent-financial-advisor.agent-financial-advisor.workers.dev/v1/tools/strategy_audit \
  -H "content-type: application/json" \
  -d '{"returns": [0.021,-0.012,0.034,0.008,-0.025,0.041,0.015,-0.006,0.027,0.011,-0.031,0.038,0.019,0.004,-0.014,0.029,0.022,-0.009,0.012,0.035,-0.018,0.024,0.007,0.016], "periods_per_year": 12, "n_trials": 1}'

The response (trimmed to the relevant fields):

{
  "red_flags": [],
  "return_stats": {
    "periods": 24,
    "annual_return_cagr": 0.1286,
    "annual_volatility": 0.0708,
    "sharpe": 1.751,
    "sortino": 3.604,
    "max_drawdown": 0.031,
    "skew": -0.411,
    "kurtosis": 2.169,
    "probabilistic_sharpe_ratio": 0.9838,
    "deflated_sharpe_ratio": 0.9838,
    "sharpe_hurdle_annualized": 0,
    "n_trials": 1
  },
  "verdict": "robust"
}

A Sharpe of 1.75 and a PSR of 0.98. With one trial the DSR equals the PSR. Looks great.

Now tell it the truth

Say the agent actually tried 200 parameter combos before it picked this one. Same returns, only n_trials changes. Response trimmed again:

curl -X POST https://agent-financial-advisor.agent-financial-advisor.workers.dev/v1/tools/strategy_audit \
  -H "content-type: application/json" \
  -d '{"returns": [0.021,-0.012,0.034,0.008,-0.025,0.041,0.015,-0.006,0.027,0.011,-0.031,0.038,0.019,0.004,-0.014,0.029,0.022,-0.009,0.012,0.035,-0.018,0.024,0.007,0.016], "periods_per_year": 12, "n_trials": 200}'

{
  "red_flags": [
    "Deflated Sharpe Ratio 0.266 is below 0.95: after accounting for 200 trial(s), the Sharpe is not convincingly above what luck would produce."
  ],
  "return_stats": {
    "periods": 24,
    "sharpe": 1.751,
    "skew": -0.411,
    "kurtosis": 2.169,
    "probabilistic_sharpe_ratio": 0.9838,
    "deflated_sharpe_ratio": 0.2658,
    "sharpe_hurdle_annualized": 2.262,
    "n_trials": 200
  },
  "verdict": "promising_but_unproven",
  "recommendations": [
    "Validate out of sample (walk-forward or a held-out period) before adding capital.",
    "Model commissions, spread and slippage explicitly; small edges disappear first."
  ]
}

The Sharpe didn't move. The hurdle did. After 200 tries you would expect a Sharpe around 2.26 from luck alone, and 1.75 is under that. The DSR drops from 0.98 to 0.27.

That is the whole point. Same backtest, very different confidence, and the only change was being honest about how many things were tried.

How I use it in an agent

The important part is counting trials. I have the agent keep a counter every time it runs a backtest on a new variant, and it passes that number as n_trials. If it has the Sharpe of every trial, it can pass their variance as trial_sharpe_variance too.

Then the rule is simple. If deflated_sharpe_ratio is under 0.95 or red_flags is not empty, the strategy doesn't get capital. It goes to an out of sample test first. That step is realy cheap compared to losing money on a fluke.

24 months is also short. More data helps the PSR a lot, so if you have daily returns, send those with periods_per_year set to 252.

Try it

The tool list and schemas are at https://agent-financial-advisor.agent-financial-advisor.workers.dev/llms.txt. There is also an MCP endpoint at /mcp if your agent speaks MCP. You get 5 free calls a day per IP, or 25 a day with a free key.

Outputs are automated checks, not investment advice.

Your trading agent still thinks the PDT rule exists

Agent Risk Desk — Mon, 19 Oct 2026 14:24:17 +0000

Ask most LLMs about day trading and they will tell you about the Pattern Day Trader rule: four day trades in five business days, and you need $25,000 in the account.

That rule is gone. FINRA Regulatory Notice 26-10 replaced it on June 4, 2026 with an intraday margin standard. A margin account now builds an intraday margin deficit when it buys or sells short. The trader must meet that deficit promptly. Leaving deficits unmet past the 5th business day as a practice triggers a 90-day restriction. Brokers may keep the old PDT rule until October 20, 2027, so your agent also needs to know which regime its broker uses.

This matters if you run an agent against a real broker. An agent that believes the old rule will refuse trades it could make. An agent that ignores both rules will get its account restricted.

Check the current rules from your agent

I built a small service that returns the current rules with effective dates and sources. The rules endpoint is free:

curl -X POST https://agent-financial-advisor.agent-financial-advisor.workers.dev/v1/tools/rules_digest \
  -H "content-type: application/json" -d '{}'

Check an order before you send it

The pre_trade_check tool runs an order past a compliance and risk review. It checks buying power, settlement violations, intraday margin, Reg SHO, wash sales, concentration and fat-finger prices. It returns approve, approve_with_warnings or reject, with reasons.

Size a position

curl -X POST https://agent-financial-advisor.agent-financial-advisor.workers.dev/v1/tools/position_size \
  -H "content-type: application/json" \
  -d '{"equity":50000,"entry_price":100,"stop_price":95,"method":"fixed_fractional"}'

That call sizes a position to risk 1% of equity to the stop: 100 shares, $500 at risk.

Use it as an MCP server

Point any MCP client at https://agent-financial-advisor.agent-financial-advisor.workers.dev/mcp?src=devto. The agent sees 8 tools, including position sizing, tax-lot planning and a backtest audit that computes the Deflated Sharpe Ratio.

Pricing

The rules digest is free. Each IP gets 5 free calls a day, and a free API key gets 25. After that, calls cost 1 to 10 cents in USDC via the x402 protocol, so an agent can pay for itself without a human signing up.

Free key in-session: call the get_api_key MCP tool. Examples: github.com/mytomclinic/agent-financial-advisor/…/examples

The outputs are automated rule checks, not investment advice. Verify broker-specific rules before you rely on them.