OpenClaw Finance Quickstart

What you're building

A finance-grade AI companion that can research markets, monitor positions, and surface trade opportunities — with every execution action protected by hard, deterministic guardrails.

The model is one sentence: research runs freely; money moves only with permission.

OpenClaw drives the agent intelligence. Veto sits between the agent and your finance tools, enforcing the rules you configure exactly once. The agent cannot bypass them, cannot negotiate around them, and never knows they exist — it simply receives an allow, a block, or a request to wait for your approval.

Before you start

• OpenClaw installed — openclaw --version should return cleanly
• openclaw-veto installed — covered in Step 1
• Approval mode decision made — local approvals via OpenClaw, or cloud-backed approvals via the Veto dashboard. Both are described in Step 3.

On scope. Veto enforces the guardrails you define: leverage caps, position size limits, session budgets, and approval gates. It validates actions against rules — it does not predict market behavior or protect you from losses on allowed trades. Configure it as accountability infrastructure, not as financial advice.

Step 1 — Install the plugin

openclaw plugins install openclaw-veto

openclaw-veto is the bridge between OpenClaw's agent loop and Veto's policy engine. Once installed, OpenClaw gains the ability to:

• Run veto agent commands on your behalf during guided setup
• Attach the Veto policy layer to every finance tool you connect
• Route approval requests natively to your configured OpenClaw channel
• Surface blocked-action explanations in the agent's own interface

Verify the install:

openclaw plugins list
# openclaw-veto  ✓  active

Step 2 — Initialize Veto with the trading pack

veto init --pack crypto-trading

This generates a veto/ directory in your working folder:

veto/
├── veto.config.yaml          core configuration
└── rules/
    └── defaults.yaml         pack rules — leverage caps, budgets, approval gates

What the pack gives you out of the box

These numbers are starting points. You will customize them in Step 4.

Your veto.config.yaml after init is a minimal standard config — mode, logging, and where to find rules:

version: "1.0"
mode: "strict"
logging:
  level: "info"
rules:
  directory: "./rules"

The pack rules and economic policy live in your rules file, which extends the pack:

version: "1.0"
extends: "@veto/crypto-trading"

# Override or extend pack rules here.
# Use the same rule id to replace a pack rule entirely.
# Add a new id to append a rule alongside the pack.
rules: []

Everything in @veto/crypto-trading — leverage caps, approval gates, withdrawal blocks, session budget, research-before-action rules — is active from this single extends line.

Step 3 — Pick your approval mode

When the agent proposes an action above your approval threshold, it needs a way to ask you. Approval mode is a plugin-level setting configured through OpenClaw, not in veto.config.yaml.

openclaw-native (default)

Approvals route through OpenClaw's built-in interface — Telegram, the desktop notification panel, or whichever surface you use as your primary OpenClaw channel. No account setup required. This is the default — if you do not set approvalMode in the plugin config, openclaw-native is used.

Best for: solo users who want the simplest possible setup with no external dependencies.

veto-cloud

Approvals route through the Veto dashboard at veto.so. Every decision is logged, searchable, and attributable. You can add teammates as reviewers, configure webhook alerts to Slack or PagerDuty, and export a full audit trail.

To switch to cloud approvals, set approvalMode in the openclaw-veto plugin configuration. The plugin reads this value at startup from OpenClaw's plugin config system:

approvalMode: veto-cloud

For cloud mode, Veto also needs your API key. Add it to veto.config.yaml or set the VETO_API_KEY environment variable:

veto cloud login          # one-time device auth

version: "1.0"
mode: "strict"
logging:
  level: "info"
rules:
  directory: "./rules"
cloud:
  apiKey: ${VETO_API_KEY}

Best for: anyone who needs persistent decision history, multi-person review workflows, or integration with external alerting systems.

Where to start. Begin with openclaw-native. There is no account to set up and approval requests appear in the same place you already interact with OpenClaw. Move to veto-cloud when you want a permanent audit log, a second reviewer, or webhook-driven alerts — none of which require reconfiguring the agent or rewriting rules.

Step 4 — Let OpenClaw customize your limits

This is the step that matters most. You do not need to edit YAML manually. Describe your preferences in natural language and OpenClaw configures the policy layer on your behalf.

Open OpenClaw and start a setup conversation:

You:  I want to trade on Binance. My session budget for today is $500.
      Keep any single order under $300. No leverage — spot only.
      I want to review anything above $50 before it executes.

OpenClaw: Understood. Configuring your Veto guardrails now.

  Setting session budget .................. $500
  Setting approval threshold .............. $50
  Capping single trade notional ........... $300
  Blocking leverage above 1× .............. spot only
  Scanning tool schema for Binance ........ done

  Your guardrails are active. Connect your Binance tools when ready.

What OpenClaw runs behind the scenes

OpenClaw uses the veto agent compatibility commands, which accept natural language and generate the corresponding YAML rules:

# Initialize Veto in agent mode
veto agent init

# Set session budget and approval threshold
veto agent policy add "set session budget to $500"
veto agent policy add "auto-allow trades up to $50"

# Block single trades above $300
veto agent policy add "block orders above $300 quote quantity"

# Block leverage above 1× (spot only)
veto agent policy add "block leverage above 1x"

# Scan connected tools for naming or schema gaps
veto agent scan

# Review the complete active policy set
veto agent policy list

Each veto agent policy add call generates a YAML rule file in veto/rules/ and writes the result as JSON. If you prefer to author rules directly, you can add them to rules/defaults.yaml instead — for example, to tighten the pack's default trade cap:

version: "1.0"
extends: "@veto/crypto-trading"

rules:
  # Override the pack default: block orders above $300 (pack default: $2,000)
  - id: crypto-max-position
    name: Maximum single position size
    enabled: true
    severity: critical
    action: block
    tools: [place_order, create_order, submit_order, open_position]
    conditions:
      - field: arguments.quote_quantity
        operator: greater_than
        value: 300

The veto agent scan step is worth watching. It matches tool names from your connected venue against the rule definitions and reports any mismatches — for example, if your Binance integration calls orders create_order while a pack rule targets place_order. Better to surface that gap during setup than after an order goes unguarded.

Step 5 — Connect finance tools after the guardrails exist

Connect your exchange or prediction market tools only after the policy layer is fully initialized. The order is intentional.

The moment a tool is connected and callable, the agent can attempt to use it. Adding guardrails afterward leaves a window of unprotected access, however brief. Configuring Veto first closes that window entirely.

You: Connect Binance.

OpenClaw links the Binance integration through the openclaw-veto bridge. From this point, every tool call flows through Veto before reaching the exchange.

The same pattern applies to prediction markets like Polymarket. Price queries, market research, and position reads pass through freely. Any tool that submits a position or moves funds is checked against the policies you set in Step 4.

You do not need to write integration-specific configuration for each venue. The pack's rules operate on standard argument fields (quote_quantity, leverage, amount). If your venue uses different field names, veto agent scan will surface them and you can override the relevant rules in rules/defaults.yaml.

What happens during a real trade

Here is the complete sequence from the agent's research signal to order execution:

1. Research phase The agent reads market data, checks order books, and queries positions. These calls are explicitly allow-listed by the crypto-allow-reads rule and pass through Veto without any approval requirement.

2. Proposal The agent decides to place an order and calls place_order (or the equivalent for your venue).

3. Veto evaluates Before the call reaches the exchange, Veto runs your rules in sequence:

• Is the quote_quantity within the per-trade cap?
• Did the agent call get_price and get_portfolio first (research-before-action rule)?
• Is leverage within bounds?
• Does the quote_quantity cross the auto-allow threshold or the approval gate?

This evaluation is local and sub-millisecond. No network call to Veto Cloud is required for the deterministic check.

4. Small trade — passes automatically If the quote_quantity is at or below your auto-allow threshold (e.g., $50 in the example above), and all hard rules are satisfied, the order executes without interruption.

5. Medium trade — approval required If the quote_quantity exceeds your approval threshold, Veto pauses execution and routes a request to your configured mode. The agent waits. You review the proposed order parameters and approve or reject. On approval, execution resumes. On rejection, the agent receives a structured denial.

6. Hard block If a trade violates a cap rule — over the per-trade limit, over the leverage ceiling, or targeting a blocked tool like withdraw — it is rejected immediately with no approval step. The agent receives the block reason and can surface it directly.

What is automatic vs what still needs tuning

Handled automatically from day one

• Session budget enforcement and spend tracking
• Per-trade and per-bet size caps
• Leverage ceiling
• Approval gates at your configured threshold
• Hard blocks on all withdrawal and margin-borrow tools
• Research-before-action enforcement (price + portfolio lookup required before orders)
• No leveraged trades midnight–6am UTC
• Decision logging (local or cloud-backed)

Areas that may need attention later

Tool name mismatches. Different exchange SDKs use different naming conventions. The pack targets place_order, create_order, submit_order, and open_position — but your venue may use something else. Run veto agent scan after each tool connection to detect gaps. Override field paths or rule tool lists in rules/defaults.yaml using the same rule id as the pack.

Venue-specific argument schemas. Polymarket positions are sized with amount; the pack has dedicated bet rules for this. Binance spot and futures use quote_quantity. Confirm that the field names Veto checks match what your venue actually sends before your first live session.

Semantic LLM policies. Hard rules cover quantitative limits well. For qualitative constraints — blocking a trade unless the agent provides documented research reasoning, or rejecting a prediction market bet without a calculated edge — add a cloud LLM policy via POST /v1/policies. See the packages/sdk/examples/crypto-trading/README.md for ready-to-use policy payloads.

Cloud team workflows. If you want a second approver, Slack alerts on every block, or a searchable decision log beyond local storage, configure veto-cloud and add event webhooks. See Event Webhooks.

Recommended first-run defaults

These tiers come directly from the # Adjust: comments in @veto/crypto-trading and the pack's onboarding playbook. Override any value in rules/defaults.yaml or with veto agent policy add.

If you are new to agent-assisted trading, start with Conservative. The low auto-allow threshold keeps small research-correlated micro-actions frictionless while surfacing anything with real financial weight for your explicit review. Raise the numbers once you have a session or two of decision history to calibrate against.

Next steps