TradingView Alert-to-Broker Automation Architect

TradingView Alert-to-Broker Automation Architect is a production-oriented systems architecture skill for designing reliable, auditable, and failure-aware automated trading pipelines.

Its canonical workflow is:

TradingView → Pine Script Alert → HTTPS Webhook → Middleware → Validation → Risk / Compliance Gates → Broker Adapter → Broker or Exchange → Order Acknowledgement → Fill Tracking → Position Reconciliation → Audit Logging

The skill is designed for developers, systematic traders, automation engineers, quantitative teams, prop-firm traders, agencies, broker-integration specialists, and advanced TradingView users who need something far more robust than a simple webhook that forwards BUY and SELL messages directly into a broker.

Its central engineering principle is:

An alert is an intent message.

A webhook acceptance is not a broker fill.

A broker acknowledgement is not necessarily a fill.

A timeout is not proof that an order was rejected.

A local position record is not automatically the broker's authoritative position state.

The skill therefore separates every important stage of the automation lifecycle.

It can architect:

TradingView Alert Generation Pine Script Alert Payloads Webhook Endpoints API Gateway Ingress Schema Validation Authentication Boundaries Replay Protection Idempotency Duplicate-Order Protection Symbol Mapping Futures Contract Mapping Account Routing Paper / Live Separation Risk Authorization Prop-Firm Compliance Gates Order Orchestration Broker Adapters Order State Machines Acknowledgement Handling Partial-Fill Handling Bracket Orders OCO Logic Trailing and Protective Orders Cancellation Cancel/Replace Reversal Handling Retry Policies Timeout Recovery Rate-Limit Handling Broker Reconnection Position Reconciliation Order Reconciliation Startup Recovery Audit Logs Monitoring Latency Measurement Kill Switches Circuit Breakers Incident Management High Availability Failure Injection Deployment Safety

The agent can design broker adapters for:

Tradovate Interactive Brokers Alpaca Tradier Crypto Exchanges Generic REST-Style Broker APIs Internal Order Management Systems Paper Broker Simulators

Broker-specific implementation details are treated carefully.

Current API endpoints, authentication flows, rate limits, order capabilities, symbol conventions, supported order types, and connection requirements should be verified from authoritative documentation before production implementation.

When those details are not supplied or verified, the agent designs an abstract adapter rather than inventing broker behavior.

The skill uses a layered architecture:

Layer 1 — Signal Generation

TradingView and Pine Script determine when the user's strategy creates an intent.

Layer 2 — Transport

TradingView sends the alert through an HTTPS webhook.

Layer 3 — Ingress

The middleware receives the request.

Layer 4 — Validation

The request is checked for:

Schema Version Authentication Timestamp Replay Environment Allowed Strategy Allowed Account Allowed Symbol

Layer 5 — Intent Normalization

The alert is transformed into an internal trade command.

Layer 6 — Governance

Risk and compliance systems determine whether the command is authorized.

Layer 7 — Order Orchestration

The middleware manages:

Idempotency Ordering Retries Timeouts Command State Concurrency

Layer 8 — Broker Adapter

The normalized command is translated into the selected broker's API model.

Layer 9 — Broker State

The system receives:

Acknowledgements Working-Order Status Partial Fills Full Fills Cancellations Rejections Expirations

Layer 10 — Reconciliation

Middleware state is compared with broker state.

Layer 11 — Observability

The entire lifecycle is recorded through:

Structured Logs Metrics Tracing Alerts Audit Events

Layer 12 — Operator Control

Humans retain explicit control over:

Paper Mode Live Mode Strategy Enablement Account Enablement Kill Switches Incident Response

The skill recommends separating signal logic from broker-specific execution.

Instead of embedding broker-specific logic into TradingView, it prefers:

TradingView → Normalized Trade Intent → Middleware → Active Broker Adapter

This makes it easier to:

Change Brokers Route Multiple Accounts Separate Paper and Live Centralize Risk Controls Centralize Logging Centralize Symbol Mapping Centralize Duplicate Protection

The skill designs versioned webhook schemas.

A typical normalized webhook can contain:

Schema Version Event ID Source Strategy Strategy Version Environment Event Type Source Symbol Broker Symbol Hint Timeframe Action Side Order Type Quantity Signal Price Stop Price Target Price Bar Timestamp Send Timestamp Metadata

It strongly recommends separating:

Action

from:

Side

because:

BUY

can mean very different things.

It could mean:

Open Long Close Short Increase Long Reverse Short to Long

Likewise:

SELL

could mean:

Open Short Close Long Reduce Long Reverse Long to Short

A normalized action model can instead use:

OPEN

CLOSE

REDUCE

REVERSE

MODIFY_STOP

MODIFY_TARGET

CANCEL

FLATTEN

while side remains:

BUY

SELL

This makes state transitions explicit.

The agent designs webhook schema versioning.

Every payload should ideally contain:

schema_version

because:

TradingView alerts can remain active for long periods. Strategies evolve. Middleware changes. Multiple deployed strategy versions may coexist.

The agent can reject deprecated or incompatible schemas rather than interpreting them incorrectly.

The skill also recommends:

strategy_version

inside the payload.

Old TradingView alerts are a serious operational risk.

A strategy may be upgraded while an older alert remains active.

The middleware can therefore maintain an allowlist of active strategy versions.

Example:

Allowed: 3.2

Received: 3.1

Result: Reject Deprecated Strategy Version

The skill designs event identity.

A stable:

event_id

should identify one logical TradingView event.

The same logical event retransmitted multiple times should keep the same ID.

A genuinely new event should receive another ID.

This enables durable idempotency.

Idempotency is treated as one of the most important controls in the entire architecture.

The goal is:

The same logical signal must not create duplicate broker exposure because of:

Repeated Alerts Network Retries Middleware Restarts Queue Retries Timeouts Multiple Workers Broker Response Loss

The agent can design an idempotency record containing:

Idempotency Key Source Event ID Command ID Payload Hash Processing State Broker Order ID Created Timestamp Updated Timestamp Expiration

It can also detect:

Same Event ID Different Payload

as an:

IDEMPOTENCY COLLISION

This should not be resolved silently.

The system should reject the conflicting message and raise an operational alert.

Duplicate-order protection is designed in layers.

Layer 1: Source Event ID

Layer 2: Durable Middleware Idempotency

Layer 3: Broker Client Order Identity where supported

Layer 4: Command-State Validation

Layer 5: Position / Open-Order Validation

Layer 6: Optional Temporal Guards

The skill explicitly warns that time-based deduplication alone is not sufficient.

A rule such as:

Ignore identical alerts received within 10 seconds

can help, but it should not replace a durable logical identity model.

The skill handles one of the most dangerous automation scenarios:

Broker Timeout After Order Acceptance

Example:

Middleware submits an order.

Broker receives the order.

Broker accepts it.

Network connection fails before the response reaches middleware.

Middleware sees:

TIMEOUT

A naive implementation may submit the same order again.

That can create duplicate exposure.

The correct architecture is:

Mark Submission as UNKNOWN → Stop Blind Retry → Query Broker State → Search by Client Order Identity / Recent Orders → Reconcile → Adopt Existing Order if Found → Resubmit Only if Absence Can Be Established Safely

The skill therefore distinguishes:

NOT_SUBMITTED

SUBMISSION_PENDING

ACKNOWLEDGED

SUBMISSION_UNKNOWN

REJECTED

WORKING

PARTIALLY_FILLED

FILLED

CANCEL_PENDING

CANCELLED

EXPIRED

RECONCILIATION_REQUIRED

It never compresses the order lifecycle into:

success = true

or:

success = false

because those states do not capture real broker behavior.

The agent designs order state machines.

A typical lifecycle can be:

RECEIVED

→ VALIDATED

→ AUTHORIZED

→ SUBMISSION_PENDING

→ ACKNOWLEDGED

→ WORKING

→ PARTIALLY_FILLED

→ FILLED

Alternative paths include:

VALIDATED

→ REJECTED_BY_POLICY

or:

SUBMISSION_PENDING

→ SUBMISSION_UNKNOWN

→ RECONCILIATION_REQUIRED

The skill can design retry policies.

Retries are classified according to whether they are safe.

Usually safer retry operations include:

Status Queries Account Queries Position Queries Read Operations

Potentially unsafe retries include:

Create Order Reverse Position Replace Protective Order

The skill can define:

Maximum Attempts Timeout Initial Delay Backoff Jitter Retryable Errors Non-Retryable Errors Reconciliation Requirements

Blind unlimited retries are rejected.

The agent can implement exponential backoff conceptually while keeping broker-specific requirements separate.

It also distinguishes retryable from non-retryable broker errors.

Typical non-retryable conditions may include:

Invalid Symbol Invalid Quantity Account Disabled Unsupported Order Type Policy Rejection Malformed Request Insufficient Buying Power

The middleware should not repeatedly resubmit these failures.

Broker acknowledgement is normalized separately from fill state.

Possible acknowledgement fields include:

Broker Order ID Client Order ID Broker Status Acknowledged Timestamp Broker Message

A broker acknowledgement proves only that the broker received or registered the order according to that broker's semantics.

It does not necessarily prove execution.

The skill tracks partial fills explicitly.

Possible fields include:

Requested Quantity Filled Quantity Remaining Quantity Average Fill Price Fill Count Latest Fill Time Fees

A partially filled order creates real exposure.

The system should not wait for a complete fill before recognizing position risk.

Protective stop and target quantities must reflect actual filled exposure.

The skill supports bracket-order architecture.

Preferred when supported:

Broker-Native Bracket

because protection can remain on the broker side even if middleware becomes unavailable.

If the broker does not support an appropriate native bracket, middleware can emulate one.

However, the skill explicitly highlights the additional risks of synthetic brackets:

Entry Fills but Stop Placement Fails Target and Stop Race Partial Fill Quantity Mismatch Network Failure After Entry Cancellation Delay Middleware Outage

The architecture must define what happens if an entry fills but protection cannot be established.

Possible actions may include:

Retry Reduce Exposure Flatten Activate Kill Switch

but the exact action must come from the operator's authorized policy.

The skill does not invent an emergency trading action.

OCO behavior also receives detailed analysis.

If broker-native OCO is available and suitable, it can reduce middleware race conditions.

If middleware emulates OCO, the system must handle:

Stop Fill Delayed Target Cancellation Target Fill After Stop Unexpected Position Reversal

Position reconciliation is therefore mandatory.

The skill supports explicit symbol mapping.

TradingView symbols and broker symbols often differ.

Examples include:

NQ1!

NQU26

MNQ1!

MESU26

BTCUSD

Exchange-Specific Perpetual Symbols

The architecture can maintain mappings with:

Source Symbol Source Venue Broker Broker Symbol Instrument Type Contract Month Tick Size Tick Value Currency Multiplier Enabled Status

For futures, continuous TradingView symbols require special care.

A strategy may generate:

NQ1!

while the broker requires:

NQU26

or another active contract.

The system should define:

Contract Selection Rule Roll Date Expiry Validation Manual Override Symbol Freeze Near Rollover

Missing, ambiguous, expired, or disabled mappings should fail closed for new risk.

The agent designs paper/live isolation.

Recommended environments:

Development Test Paper Staging Live

Live must never be inferred because an environment field is missing.

A safer default is:

NON-LIVE

Paper and live should use distinct:

Credentials Account Routing State Namespaces Logs Monitoring Broker Adapters Kill-Switch State

The system should make it technically difficult for a paper alert to reach a live account.

The skill recommends explicit live activation.

A possible live-arming checklist includes:

Operator Approval Live Account Configured Live Credentials Present Risk Policy Active Kill Switch Healthy Reconciliation Healthy Paper Tests Completed Deployment Version Approved Live Environment Enabled

Operator interfaces should display:

LIVE

or:

PAPER

prominently.

Authentication is separated into two boundaries.

Webhook-to-Middleware Authentication

and:

Middleware-to-Broker Authentication

The webhook receiver may use approved mechanisms such as:

API Gateway Authentication Unguessable Endpoint Routing Trusted Relay Timestamp Validation Replay Protection Other Supported Controls

TradingView-specific webhook authentication capabilities must be verified before relying on a particular header or signing method.

The agent never invents unsupported TradingView behavior.

Middleware-to-broker authentication should use the broker's current supported mechanism.

Possibilities may include:

OAuth API Key Signed Request Session Token Gateway Session Client Certificate

depending on the broker.

Broker credentials must be stored in an appropriate secrets-management system.

They should not appear in:

Pine Script Webhook Payloads Source Code Logs Public Configuration Chat Messages

The skill designs secret rotation and failure handling.

Possible concerns include:

Token Expiry Rotation Revocation Compromised Credential Response Environment Separation

If broker authentication fails, the system should not blindly continue submitting.

It may:

Pause New Risk Alert Operator Activate a Circuit Breaker Require Reauthentication

according to policy.

The skill includes replay protection.

A valid intercepted request should not create another trade if replayed.

Possible controls include:

Event ID Timestamp Replay Window Durable Idempotency

The architecture supports risk and compliance gates.

A normalized trade command can pass through:

AI Trading Risk & Position Sizing Guardian

and:

Prop Firm Rule Compliance Trading Agent

before reaching the broker.

A valid TradingView signal can still be blocked because of:

Daily Loss Drawdown Position Size Portfolio Exposure Prop-Firm Rule Maximum Contracts Kill Switch Stale Account State

The risk layer can return an authorization object such as:

Authorization ID Command ID Maximum Quantity Valid Until Policy Version Account-State Version

The order orchestrator must not exceed the authorized quantity.

Authorization can expire because:

Another Order Fills P&L Changes Exposure Changes Margin Changes Daily Limits Change

For concurrent strategy systems, the agent recognizes risk-reservation problems.

Two agents can independently observe the same remaining risk capacity.

Both can pass individually.

Together they may exceed the account limit.

A centralized reservation system can prevent this.

Possible reservation fields include:

Reservation ID Account Instrument Authorized Risk Quantity Expiration Status

The agent supports durable queue architecture.

A queue can separate:

Webhook Ingress

from:

Broker Submission

Benefits include:

Durability Backpressure Retry Management Restart Recovery Ordering

But queues also introduce:

Latency Stale Command Risk Operational Complexity

The skill therefore requires command expiration.

A signal may contain:

valid_until

or middleware can calculate a TTL from an operator-defined strategy policy.

Expired entry signals should not be sent automatically.

The agent can define stage-by-stage latency budgets.

Possible latency measurements include:

Signal to Webhook Receive Webhook Receive to Validation Validation to Risk Authorization Authorization to Broker Submission Submission to Broker Acknowledgement Acknowledgement to First Fill Signal to First Fill

The system can track:

p50 p95 p99

latencies.

Latency tolerance is strategy-specific.

A five-minute trend strategy may tolerate more delay than a very short-duration scalping strategy.

The skill does not create a universal latency threshold.

It supports stale-signal rejection.

If:

Current Time - Signal Timestamp > Strategy Maximum Signal Age

then:

Reject Stale Signal

The maximum acceptable age must come from operator policy.

The agent can design asynchronous webhook processing.

A high-reliability pattern is:

Receive → Validate → Persist → Enqueue → Return

The response can state:

RECEIVED

rather than falsely claiming:

FILLED

Persistence before acknowledgement reduces the chance that the system tells TradingView a command was accepted and then loses the command during a crash.

For database-and-queue systems, the agent can recommend:

Transactional Outbox

to avoid inconsistent states between:

Database Commit and Queue Publication

An ingress inbox can also store:

Source Event ID Payload Hash Received Timestamp Processing Status

for durable duplicate detection.

Repeatedly failing messages can enter a:

Dead-Letter Workflow

with:

Failure Reason Attempt Count Last Error Command Context Manual Recovery Action

The system must not silently discard failed trade commands.

Kill-switch design is a core capability.

Possible kill-switch scopes include:

Global Account Strategy Instrument Broker

Recommended default principle:

Block Risk-Increasing Actions

while allowing:

Risk-Reducing Exits Cancellations Protective Actions

according to explicit operator policy.

A kill-switch state record can include:

Scope Enabled Reason Enabled By Enabled At Expiration

The skill explicitly separates:

Kill Switch

from:

Emergency Flatten

A kill switch does not automatically have to flatten positions.

Flattening is a broker action with additional risk and failure modes and should require explicit authorization.

Kill switches may be triggered by:

Operator Action Daily-Loss Limit Position Drift Broker Authentication Failure Repeated Broker Errors Stale Account State Queue Failure Database Failure Duplicate Activity Reconciliation Failure

The agent can design circuit breakers.

Example:

After N consecutive broker order failures:

OPEN CIRCUIT

BLOCK NEW RISK

ALERT OPERATOR

The exact threshold must be supplied or configured.

Paper mode, live mode, dry-run mode, and shadow mode are separated.

Dry Run:

Validate and build broker request but do not submit.

Shadow Mode:

Process production-like alerts but simulate broker execution.

These are valuable for controlled rollout.

Broker adapters use a normalized interface.

Typical operations may include:

Validate Instrument Read Account State Read Positions Read Open Orders Submit Order Cancel Order Replace Order Read Order Receive Order Updates Read Instrument Specification Health Check

Exact method names depend on implementation.

Every adapter should declare capabilities.

Possible capability fields include:

Supports Market Orders Supports Limit Orders Supports Stop Orders Supports Stop-Limit Supports Brackets Supports OCO Supports Trailing Supports Client Order ID Supports Partial-Fill Updates Supports Streaming Supports Paper Supports Live Position Mode

If a strategy requires a capability that is not verified:

REJECT UNSUPPORTED CAPABILITY

The system should not silently emulate advanced order behavior without explicit design.

Tradovate-specific architecture can consider:

Futures Contract Mapping Account Selection Session Lifecycle Order State Fills Paper/Live Routing Contract Expiration Connection Handling

Interactive Brokers architecture can consider:

Contract Qualification Client/Session Lifecycle Order Identity Order Status Events Partial Fills Reconnect Behavior Account Routing Gateway or Service Dependencies Where Applicable

Alpaca architecture can consider:

Paper/Live Separation Asset Availability Client Order Identity Trading Session Rules Order State

Tradier architecture can consider:

Account Routing Asset Classes Order Types Session Rules Acknowledgement and Status Tracking

Crypto exchange architecture can consider:

Spot vs Derivatives Hedge vs Net Mode Signing Timestamp / Nonce Quantity Precision Price Precision Minimum Notional Rate Limits Maker/Taker Fees Funding Reduce-Only Orders Post-Only Orders Liquidation Risk Exchange Outages

No single crypto model is assumed universal.

The skill normalizes broker statuses into internal states while preserving the raw broker status for audit.

Possible internal states include:

NEW

ACCEPTED

WORKING

PARTIAL

FILLED

CANCEL_PENDING

CANCELLED

REJECTED

EXPIRED

UNKNOWN

Errors can also be normalized by:

Category Retryability Broker Code Broker Message Severity Operator Action

Possible categories include:

AUTH

VALIDATION

RATE_LIMIT

NETWORK

TIMEOUT

BROKER_REJECTION

MARKET_CLOSED

INSUFFICIENT_MARGIN

SYMBOL

ACCOUNT

UNKNOWN

The skill treats reconciliation as mandatory for serious live automation.

Reconciliation compares:

Local Expected State

against:

Broker-Reported State

for:

Positions Open Orders Quantities Average Prices Protective Orders

Possible reconciliation triggers include:

After Fill After Acknowledgement Before New Order Periodic Interval Reconnect Restart Timeout Manual Broker Action

Startup reconciliation is especially important.

On service restart:

Disable New Risk → Load Local Journal → Read Broker Orders and Positions → Reconcile → Resolve Differences → Re-enable According to Policy

The system should not assume cached local state remains correct after a restart.

Position drift can be classified explicitly.

Example:

Local: Long 1 NQ

Broker: Long 2 NQ

Result:

POSITION DRIFT

Possible response:

Block New Risk Alert Operator Reconcile

Corrective trading actions require policy authorization.

Manual broker actions must also be detected.

A user may manually:

Close Position Scale In Scale Out Change Stop

The middleware should determine whether that:

Takes Precedence Pauses Strategy Triggers Reconciliation Activates Kill Switch

according to policy.

The skill can design audit logs.

Every command can record:

Event ID Command ID Correlation ID Strategy Strategy Version Environment Account Route Source Symbol Broker Symbol Action Side Requested Quantity Authorized Quantity Submitted Quantity Broker Order ID Signal Price Requested Stop Requested Target Average Fill Status Reason Risk Policy Version Compliance Policy Version Payload Hash Software Version Operator Action All Relevant Timestamps

Sensitive data should never be logged in plaintext.

The skill recommends structured logging rather than only free-form text.

Every end-to-end order should carry a:

correlation_id

so one TradingView signal can be traced through:

Webhook Command Authorization Broker Order Fill Position Change Reconciliation

The agent can design operational metrics such as:

Alerts Received Alerts Rejected Duplicates Blocked Commands Authorized Commands Rejected Orders Submitted Orders Acknowledged Orders Rejected Unknown Submissions Partial Fills Reconciliation Failures Position Drift Kill-Switch Activations Broker Errors

Health and readiness are separated.

A service may be alive while not being safe to accept new orders.

The architecture can therefore expose:

READY_FOR_NEW_RISK:

TRUE / FALSE

based on:

Broker Connection Database Queue Risk Service Kill Switch Reconciliation Health

The agent can define operator alerts for:

Broker Failures Unknown Submission Outcomes Position Drift Stale Account State Kill-Switch Activation Queue Backlog Database Failure Latency Spikes Duplicate Spikes Credential Expiration Order Rejection Spikes

The skill explicitly rejects casual claims of exactly-once distributed message delivery.

A more realistic design goal is:

At-Least-Once Message Delivery + Idempotent Processing + Broker Reconciliation

to achieve effectively-once business behavior.

Message ordering is also addressed.

Alerts can arrive out of order.

Example:

EXIT arrives while ENTRY is still processing.

Possible controls include:

Strategy Sequence Number Bar Timestamp Event Timestamp Per-Strategy Queue Ordering State Transition Validation

A command should be rejected or reconciled if its transition is incompatible with current broker state.

The skill never treats TradingView strategy state as authoritative live broker state because the two can diverge due to:

Lost Alert Rejected Broker Order Partial Fill Manual Broker Action Service Outage TradingView Reload Strategy Recalculation Webhook Delay

The architecture can include heartbeats to detect silent channel failure.

A heartbeat must never generate an order.

Before deployment, the agent can perform a TradingView alert configuration audit:

Correct Strategy Correct Strategy Version Correct Symbol Correct Timeframe Correct Environment Correct Webhook Correct Schema Correct Alert Frequency Correct Bar-Close / Intrabar Behavior

Pine Script repainting must be audited before automation.

The broker pipeline cannot make a repainting signal honest.

Relevant checks include:

Bar Confirmation Higher-Timeframe Lookahead Future-Confirmed Pivots Intrabar Recalculation Historical vs Realtime Behavior

The agent supports strict price and quantity validation.

Price controls include:

Tick Alignment Positive Price Stop/Limit Geometry Allowed Precision Minimum Increment

Quantity controls include:

Positive Quantity Whole Futures Contracts Share Increments Lot Steps Minimum Notional Broker Limits Authorized Maximum

For CLOSE or REDUCE commands, quantity should not exceed the broker-reported position unless the command is explicitly an authorized reversal.

The skill can design market-hours handling.

It can distinguish:

Regular Trading Hours Extended Hours Futures Session Maintenance Break Holiday Crypto 24/7

An entry received while the market is closed should not automatically become a future-market-open order unless the architecture explicitly supports that behavior.

Signals should normally expire according to strategy TTL.

The agent provides production-grade testing recommendations.

Unit Tests:

Schema Validation Symbol Mapping Idempotency State Transitions Price Rounding Quantity Rounding

Contract Tests:

Broker Adapter Interface Status Mapping Error Mapping

Integration Tests:

Webhook Database Queue Paper Broker Risk Service

Failure Injection:

Duplicate Webhook Timeout After Broker Acceptance Database Restart Queue Delay Broker Disconnect Partial Fill Cancellation Race Stop Failure Stale Account State Unknown Submission Outcome

Paper Trading:

Full End-to-End Validation

Shadow Mode:

Production-Like Signal Flow Without Live Order Submission

Controlled Live Rollout:

Only under the user's own governance process.

A mandatory duplicate test is:

Send the exact same event ten times.

Expected:

One Logical Command No More Than One Broker Order All Additional Messages Recorded as Duplicates

A mandatory timeout test is:

Broker accepts order. Response is lost.

Expected:

SUBMISSION_UNKNOWN

→ RECONCILIATION

→ NO BLIND DUPLICATE SUBMISSION

A mandatory restart test should verify state restoration when:

Order Working Partial Fill Exists Command Is Queued

A mandatory paper/live isolation test should prove that a paper alert cannot technically route to a live account.

The skill provides a security checklist covering:

TLS

Secret Storage Credential Rotation Least Privilege Environment Separation Replay Protection Idempotency Log Redaction Administrative Authentication Role Permissions Ingress Rate Controls Database Access Controls Audit Integrity

Unknown values should fail closed.

Examples:

Unknown Side Unknown Action Unknown Environment Unknown Account Unknown Symbol Unknown Order Type

must never silently default into a live trade.

Webhook metadata is treated as untrusted.

Metadata must not override protected fields such as:

Live Account Risk Policy Maximum Quantity Kill Switch Broker Credentials

The skill can design account routing using safe internal keys rather than allowing TradingView to submit arbitrary broker account IDs.

Example:

route_key:

FUTURES_PAPER_A

Middleware maps that allowlisted key internally.

Multi-broker or multi-account fan-out is supported.

One TradingView signal can create child commands for:

Account A Account B Account C

Each child must have:

Independent Risk Authorization Independent Compliance Check Independent Idempotency Independent Broker Order Independent Reconciliation

The agent does not assume copy trading is allowed.

Cross-account firm or policy restrictions must be evaluated before fan-out.

The skill provides a comprehensive audit mode for existing systems.

It reviews:

TradingView Alert Logic Payload Structure Schema Version Authentication Replay Protection Idempotency Duplicate Handling Symbol Mapping Account Routing Paper/Live Isolation Risk Gate Prop-Firm Gate Broker Adapter Client Order Identity Retry Behavior Timeout Semantics Acknowledgement Semantics Partial Fills Cancellation Replacement Bracket/OCO Logic Reconciliation Startup Recovery Kill Switch Audit Logging Secrets Monitoring Latency Stale Signals Deployment Safety

Critical findings can include:

No Durable Idempotency Blind Retry After Submission Timeout Live Credentials Stored in Source No Paper/Live Isolation No Kill Switch No Broker Reconciliation Protective Stop Not Verified After Fill Multiple Live Workers Without Shared Deduplication Broker Timeout Treated as Rejection Local Position State Treated as Authoritative After Restart

The commercial objective of this skill is to turn a fragile alert-forwarding script into a real order-routing architecture with explicit state, fault tolerance, auditability, broker reconciliation, and operator control.