DEV Community: Agent Risk Desk

Logging every pre-trade check so you can audit an agent's trades later

Agent Risk Desk — Mon, 09 Nov 2026 15:02:25 +0000

An agent places an order on Tuesday. On Friday you want to know why it bought 12 shares and not 40, or why a different order never went out. If all you kept is the broker's order list, you can't answer that. The broker only knows what was sent.

So I store the result of every pre-trade check in a table, next to the order. Approved orders and rejected ones both get a row. This post has the code.

The table

SQLite is enough for one agent. The same columns work in Postgres.

import json, os, sqlite3, time, requests

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

db = sqlite3.connect("audit.db")
db.execute("""create table if not exists order_audit (
  id integer primary key, ts text, symbol text, side text, qty real,
  decision text, failed text, request text, response text,
  broker_order_id text)""")

request and response hold the full JSON. decision and failed are copies of two fields so you can filter without parsing JSON.

Check, then log

def check_and_log(body):
    key = os.environ.get("AFA_API_KEY")
    headers = {"authorization": f"Bearer {key}"} if key else {}
    r = requests.post(AFA, json=body, headers=headers, timeout=10)
    r.raise_for_status()
    result = r.json()
    o = body["order"]
    failed = [c["id"] for c in result["checks"] if c["status"] == "fail"]
    cur = db.execute(
        "insert into order_audit (ts, symbol, side, qty, decision, failed, request, response) "
        "values (?,?,?,?,?,?,?,?)",
        (time.strftime("%Y-%m-%dT%H:%M:%S%z"), o["symbol"], o["side"], o["quantity"],
         result["decision"], ",".join(failed), json.dumps(body), json.dumps(result)))
    db.commit()
    return result, cur.lastrowid

def record_order_id(row_id, broker_order_id):
    db.execute("update order_audit set broker_order_id=? where id=?", (broker_order_id, row_id))
    db.commit()

The row is written before anything goes to the broker. If the submit call crashes, you still have the check. After a successful submit, record_order_id fills in the broker's id so the two sides join.

The request body is worth keeping. It has the equity, cash and positions the check saw at that moment. You can't rebuild that from the account later.

Using it

result, row_id = check_and_log(body)
if result["decision"] != "reject":
    order = trading.submit_order(MarketOrderRequest(symbol="NVDA", qty=12, side=OrderSide.BUY,
                                                    time_in_force=TimeInForce.DAY))
    record_order_id(row_id, str(order.id))

body is built the same way as in my earlier post on the Alpaca check: account, positions, the order, and a last price.

Reading it back

I ran two orders through this on a test cash account: $12,000 equity, $3,000 cash, 30 shares of AAPL. The first was 40 NVDA at $185 with a stop at $170. The second was 12 shares. The table afterward:

(1, 'NVDA', 40.0, 'reject',  'buying_power,concentration,risk_per_trade', None)
(2, 'NVDA', 12.0, 'approve', '', 'fake-order-id-123')

The order id there is a placeholder, since I didn't send anything to a broker. Now the Friday question, why didn't order 1 go out:

row = db.execute("select response from order_audit where id = 1").fetchone()
for c in json.loads(row[0])["checks"]:
    if c["status"] != "pass":
        print(c["id"], c["message"])

buying_power Cost $7400 exceeds cash $3000.
concentration NVDA would be 61.7% of equity (limit 20%). Max additional quantity: 12.
risk_per_trade Risk to stop $600 = 5% of equity (limit 2%). Quantity for limit: 16.

That is the whole answer. Three rules failed, each with the number it used. Nobody has to guess what the model was thinking.

The response also carries rules_version, which was 2026-10-18 on this run. I'd keep it with the row. If a rule changes later, you can tell which version judged an old order.

Queries I actually use

-- how often does each check fail
select failed, count(*) from order_audit where decision = 'reject' group by failed;

-- orders that were approved but have no broker id (the submit step failed)
select id, ts, symbol from order_audit where decision != 'reject' and broker_order_id is null;

The second one catches a bug in your own code, which is a good reason to have the table. If the same check fails over and over, the agent is sizing orders wrong and the prompt needs work.

Limits

The first 5 calls a day need no signup. POST /v1/keys gives a free key with 25 calls a day. Put it in AFA_API_KEY.
The table is only as good as the inputs. If your agent passes a stale price, the log records the stale price. That is still useful, because you can see it.
Don't put API keys or account numbers in request. The body I send has none, but check yours before you add fields.
It's rule-based analysis for software, not investment advice.

The product is the Agent Financial Advisor API. There is also an MCP server at /mcp on the same host, and the tool is pre_trade_check.

Disclosure: I built this. If you log something else per order that I should add to the response, tell me in the comments. I realy would like to know what people keep.

Check an options agent for early assignment and pin risk

Agent Risk Desk — Mon, 02 Nov 2026 15:12:58 +0000

If your agent sells covered calls and put spreads, the order check at entry is the easy part. The two problems I care about show up later, while the position sits there: early assignment before an ex-dividend date, and pin risk on expiration day.

Both are about the calendar. A covered call that looked fine when it was sold can get assigned the night before the stock goes ex-dividend. A short put that closes a few cents from its strike on Friday can turn into stock you only find out about on Saturday.

Over the weekend I posted a short rundown of these risks. This one has the code and the actual responses.

I run every open options position through options_risk_check each morning, and again on expiration day.

The function

import os, requests

AFA = "https://agent-financial-advisor.agent-financial-advisor.workers.dev/v1/tools/options_risk_check"
ACT_ON = {"early_assignment_dividend", "pin_risk"}

def options_check(account, underlying, legs, as_of=None):
    body = {"account": account, "underlying": underlying, "legs": legs}
    if as_of:
        body["as_of"] = as_of
    key = os.environ.get("AFA_API_KEY")
    headers = {"authorization": f"Bearer {key}"} if key else {}
    r = requests.post(AFA, json=body, headers=headers, timeout=10)
    r.raise_for_status()
    result = r.json()
    flags = [c for c in result["checks"] if c["status"] != "pass" and c["check"] in ACT_ON]
    return result, flags

as_of defaults to today in New York. I pass it here so the examples below are reproducible.

One thing to watch if you used my pre-trade check post: this tool names its fields check and detail. pre_trade_check uses id and message.

Early assignment before a dividend

Test account: margin, $40,000 equity, 200 shares of KO, short 2 KO Nov 20 70 calls. KO is at $72.40 and the call trades at $2.55. For the test I set the ex-dividend date to Nov 13 with a $0.53 dividend. Use the real date from your data feed.

result, flags = options_check(
    account={"type": "margin", "equity": 40000, "cash": 8000, "options_level": 2, "shares_held": 200},
    underlying={"symbol": "KO", "price": 72.40, "ex_dividend_date": "2026-11-13", "dividend": 0.53},
    legs=[{"type": "call", "side": "short", "strike": 70, "expiry": "2026-11-20", "quantity": 2, "premium": 2.55}],
    as_of="2026-11-02",
)

Here's what came back (trimmed):

{
  "decision": "approve_with_warnings",
  "summary": "APPROVE_WITH_WARNINGS: 0 failed, 1 warning(s), 4 passed.",
  "margin_requirement_usd": 0,
  "max_loss_usd": 0,
  "required_options_level": 1,
  "structures": [
    {"kind": "covered_call", "quantity": 2, "legs": ["short 2 KO 2026-11-20 70 calls"], "requirement_usd": 0}
  ],
  "checks": [
    {
      "check": "early_assignment_dividend",
      "status": "warn",
      "detail": "Short 70 call is in the money with $0.15 time value, less than the $0.53 dividend going ex on 2026-11-13. Expect assignment the day before; close or roll it if you don't want to deliver 200 shares and owe the dividend.",
      "source": "OCC Rule 805(d); OCC Characteristics and Risks of Standardized Options"
    }
  ]
}

The math is simple. The call is $2.40 in the money, so only $0.15 of the $2.55 is time value. Whoever owns that call gets more from exercising and collecting the $0.53 dividend than from holding it. The position is still covered and the margin requirement is $0. Nothing is wrong with the trade itself. The agent just has to decide by the close on Nov 12 whether it wants to give up the shares.

Pin risk on expiration day

Second test account: margin, $25,000 equity, level 3. The position is a put spread on SPY, short 3 Nov 6 580 puts and long 3 Nov 6 575 puts. SPY is at $580.20.

I ran the same legs twice. With as_of set to Wednesday, Nov 4, it came back approve with 4 checks passed. Max loss $1,155, requirement $1,500. There was no pin warning.

With as_of set to Friday, Nov 6, the expiration day, it added this:

{
  "check": "pin_risk",
  "status": "warn",
  "detail": "Short 580 put expires 2026-11-06 with the stock within 1% of the strike. Whether you're assigned won't be known until after the close; close it to avoid an unplanned position over the weekend or overnight.",
  "source": "OCC Rule 805(d); OCC Characteristics and Risks of Standardized Options"
}

This is the one that worries me with agents. The spread caps the loss at $1,155 only if both legs behave. If SPY closes at $579.90, the 575 long expires worthless and the 580 short can be assigned. That's 300 shares of SPY, about $174,000, in a $25,000 account over the weekend. An agent that only looks at max loss isnt going to see it coming.

So on expiration morning the loop is short:

for pos in open_positions:
    result, flags = options_check(pos["account"], pos["underlying"], pos["legs"])
    for c in flags:
        print(f"{pos['underlying']['symbol']} {c['check']}: {c['detail']}")
        close_or_roll(pos)

open_positions and close_or_roll are yours. I'd hand flagged positions to the agent with the detail text and let it pick between closing and rolling. A stricter setup would close them outright.

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.
It only knows what you send. The ex-dividend date and dividend come from your data, and so do the prices.
The 1% pin band is a default. Pass pin_band_pct in the policy object to change it.
Greeks come back as null unless you send delta, gamma, theta and vega on every leg.
It's rule-based analysis for software, not investment advice.

The same call also does margin under FINRA Rule 4210, cash-account limits, required options level and auto-exercise of expiring in-the-money longs. The docs and examples are in the repo: agent-financial-advisor. Over MCP the server is at https://agent-financial-advisor.agent-financial-advisor.workers.dev/mcp and the tool is options_risk_check.

Disclosure: I built this. If your agent trades options and keeps getting surprised by something else, tell me in the comments.

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.