Betfair Automation Rules and Triggers Explained

Why every bot uses the same model

This sub sits inside the Betfair Automation and Bots pillar. Every retail Betfair automation tool — Bet Angel Guardian, Cymatic Trader, Fairbot, BetTrader, BF Bot Manager — uses some version of the same conceptual model: triggers are conditions that fire actions, sometimes gated by conditions, and rules can enable or disable other rules so that complex strategies become state machines.

The model is dominant because it's the cleanest way to describe a strategy a machine can execute. The terminology varies between tools — Bet Angel calls them "rules" with "conditions" and "actions"; Cymatic calls them "scripts" with "events" and "handlers"; in Python you'd write a loop with if-statements — but the shape is the same. Learn the model and you can move between tools.

For the per-tool implementations: Bet Angel Guardian guide, best bots ranking, and the Python equivalent in building a Betfair bot with Python.

Anatomy of a rule

A rule has three parts:

1. Trigger — the condition that, when first true, fires the rule. Usually a comparison: LTP < 3.50, volume_30s > 2000, match_minute = 80.
2. Gating conditions — additional checks that must also be true. market_is_in_play = true, P&L > 0, my_open_bets < 3.
3. Action — what happens. Place a back order. Place a lay. Cancel orders. Green up. Toggle another rule.

Plus three properties that determine how the rule behaves over time:

• Scope. Per-market, per-selection, per-event, or global.
• Frequency. Once-only (fires once), repeat (fires every time the trigger transitions from false to true), or continuous (fires every evaluation while the trigger is true — rarely what you want).
• Enabled state. The rule is currently watching, or currently dormant.

Trigger types you'll actually use

You can list dozens of trigger types but seven cover 90% of working strategies:

• Price triggers. LTP, best back, best lay. The most common. "LTP < 3.50", "best lay <= 4.20".
• Time triggers. Time to off, time elapsed in market, match minute. "Within 60 seconds of off", "match minute > 80".
• Volume triggers. Matched volume in last N seconds, cumulative matched. "Last 30s volume > £2,000". Used to distinguish real moves from quote noise.
• Movement triggers. Price change over time window. "LTP dropped 2 ticks in last 30s". Catches steamers and drifters — see steam and drift.
• Event triggers. Goal scored, set won, point won, runner removed. Sport-specific and powerful when you have them — most useful for football and tennis.
• P&L triggers. Open P&L crosses ±£X. The basis of every stop-loss and take-profit.
• External triggers. Value in a linked Excel cell or a value pulled from a URL. The hook that lets you bring in your own data — ratings, weather, sentiment, ML output.

Tool-specific naming aside, every Betfair bot exposes these seven categories. If a tool doesn't, it's not flexible enough to run a meaningful strategy.

Conditions and gating

A trigger says "when". A condition says "only if". The two combined produce strategies that don't fire in inappropriate situations.

Common gating conditions:

• Liquidity gate. "Only if matched volume in this market > £25,000". Stops you trading dead markets.
• Time-of-day gate. "Only between 13:00 and 19:00". Avoids overnight illiquid markets unless that's the strategy.
• Position gate. "Only if I have no open bets on this selection". Stops re-entry.
• Bankroll gate. "Only if open liability across all markets < £500". Prevents over-exposure.
• Loss-limit gate. "Only if today's net P&L > -£100". The daily kill-switch.
• Sanity-of-price gate. "Only if entry price between 1.50 and 20.00". Refuses to back 1000.0 on a thin-book glitch.

You'll find that 80% of a working bot is gates, not triggers. The trigger is the strategy. The gates are the survival kit.

Action types

Standard action vocabulary:

• Place BACK / LAY. With price (absolute or relative — LTP, best back, LTP+N ticks), size, persistence (LAPSE, PERSIST, SP).
• Cancel orders. By selection, by market, all.
• Green up. Calculate the offsetting bet that levels P&L across all runners and place it. Maths in green up explained.
• Close position. Close at market — back if currently lay, lay if currently back.
• Enable / disable another rule. The state-machine building block.
• Send alert. Sound, popup, email. Use when you want notification, not execution.

Choice of persistence is non-trivial. LAPSE cancels at the off — right for pre-off-only rules. PERSIST keeps the unmatched order into in-play — right for in-play strategies and SP plays. Get this wrong and a pre-off lay at 3.35 sits there into in-play, matches at 8.0 when the favourite drifts, and you've lost £45.85 instead of £0.

Chains and state machines

The interesting power of the rule system isn't a single rule — it's chains of rules that toggle each other. Example: a rule watches for entry conditions and places the entry; on success, it disables itself and enables an exit-watch rule; the exit-watch rule either fires on take-profit or on stop-loss; either way, it then re-enables the entry-watch rule for the next market.

This is a state machine. The market goes through states: WATCHING → ENTRY_PLACED → IN_TRADE → EXIT_PLACED → CLOSED, and the rule that's active at any time depends on the state. Once you see the pattern you'll see it in every working bot.

A complete worked example

Strategy in plain English: in the last 5 minutes before a UK horse race off, if the favourite ticks down 2 ticks on £2,000+ volume in 30 seconds, back £20 at LTP. Take-profit at LTP+1 tick; stop-loss at LTP-2 ticks after 90 seconds. Don't enter if today's P&L is below -£60.

Three rules. Cleanly chained. Self-resetting. Today's P&L gate stops the bot bleeding on bad days. This is the shape of every working Betfair bot. The full Python equivalent is in building a Betfair bot in Python; for the strategy mechanics see scalping on Betfair.

Debugging rules that don't fire

When a rule doesn't behave as expected, the debug checklist:

1. Is the rule enabled? Sounds trivial. It's the #1 cause.
2. Is the trigger expression evaluating? Most tools have a "test rule" or "log evaluation" mode. Turn it on and watch what the values are.
3. Are the conditions all true at the same time? AND-chains fail silently when one condition is just slightly off. Log each condition.
4. Did the trigger transition? If the trigger is "LTP < 3.50" and LTP was already < 3.50 when the rule was enabled, "repeat-on-transition" semantics mean it never fires until LTP rises above 3.50 first.
5. Was the rule already on cooldown? Once-only rules don't re-fire until reset.
6. Did the previous rule actually re-enable this one? State-machine bugs often live in the toggle action of the rule before.

Common mistakes

• No volume gate on momentum triggers. Rule fires on a 2-tick LTP move that was actually a £5 trade in a dead market.
• Wrong persistence. Covered above.
• Forgetting to re-enable rules. The chain stops at the exit and never re-arms for the next market.
• Continuous-fire instead of once-fire. Multiple back bets at incrementally worse prices.
• Hardcoded prices instead of tick-relative. Strategy that works on 3.40-favourite markets doesn't work on 2.20-favourite markets because the same +/-N ticks is a different % move.
• No daily kill-switch. Bot bleeds £150 in two hours and the trader doesn't notice until evening.

FAQ

Are rules and triggers the same in every Betfair bot?

The conceptual model is the same — triggers fire actions, gated by conditions, rules can toggle other rules. The implementation varies: Bet Angel Guardian uses a visual builder, Cymatic uses CT Script, Python uses code. Skills transfer between them.

What's the difference between a trigger and a condition?

A trigger is the event that wakes the rule up. A condition is an extra check before the action fires. In practice many tools collapse both into "conditions" — Bet Angel Guardian is one of them.

How many rules should a working bot have?

For a single strategy, three to six rules is normal: entry, take-profit, stop-loss, optional time-stop, optional re-arm, optional kill-switch. Beyond ten, the state machine becomes hard to reason about.

Can I share rule files between traders?

Yes for Bet Angel Guardian (.bagf files) and BF Bot Manager. The Bet Angel community forum has thousands of shared rules. Paper-trade any downloaded rule before going live.

Where do I learn the per-tool implementation?

The Bet Angel Guardian complete guide and the no-code options guide cover the visual tools. Building a Betfair bot in Python covers the code version.

Five design principles for rules that survive contact with reality

Beyond mechanics, working rule design follows five principles that experienced bot traders converge on:

• Make every rule once-only by default. Add repeat behaviour only when you explicitly need it. Defaults stop more bugs than they cause.
• Gate every entry on liquidity. Markets below £25,000 matched are usually wrong to trade unless you have a niche edge. A liquidity gate kills more bad trades than any other single gate.
• Always pair an exit with an entry. Never write a rule that places a bet without a matched rule that closes the position. The exit can be take-profit, stop-loss or time-out — but it has to exist.
• Stake by intention, not by formula. Hardcode stakes at the start. Add formula-based stakes only after 90 days of clean fixed-stake results.
• Re-arm explicitly. When a rule chain finishes, the state machine should re-arm itself for the next market via a dedicated re-arm rule, not by leaving rules permanently enabled.

Each of these principles costs a few minutes to apply and prevents an incident type that has separately cost retail traders meaningful money. They're cheap; apply them by default.

The same model across Bet Angel, Cymatic, Fairbot and Python

The terminology varies by tool but the model is identical:

Once you can think in terms of the four primitives — trigger, gate, action, state — you can pick up any Betfair automation tool inside a weekend. The hard part isn't tool-specific syntax; it's understanding which triggers and gates actually produce profitable behaviour. That part is strategy, not tool.

How often should each trigger fire?

Trigger evaluation frequency is the tuning parameter most beginners miss. Triggers fire on a polling clock — every 100ms, every 500ms, every second, on-event. Wrong choice burns CPU or misses opportunities:

• Price triggers. Evaluate every 200–500ms. Faster wastes CPU; slower misses 1-tick moves on volatile markets.
• Time triggers. Evaluate every 1–2s. Time changes slowly; no need for sub-second polling.
• Volume triggers. Every 500ms is fine. Volume is cumulative and doesn't need fine resolution.
• In-play events. Push-based, not polled — the tool delivers them on the event tick.
• P&L triggers. Recompute every 200–500ms. Avoid computing P&L every poll on every rule — it's expensive.
• External triggers (Excel). Every 1–2s. Excel-as-bridge is slow.

Bet Angel and Geeks Toy expose these clocks in their settings. The defaults are sensible but worth understanding before you wonder why a strategy fires "later than expected".

Testing rules before risking money

Rules in any Betfair tool can be tested four ways, from cheapest to most rigorous:

1. Dry run (no bets placed). Most tools have a "log only" mode where the rule fires but doesn't actually place orders. Catches major logic bugs.
2. Historical replay. Bet Angel's Historic Data integration lets you replay months of markets through a rule set and observe what would have happened. The closest thing to a backtest in no-code automation.
3. Paper trade. Run the rules live on real markets with zero stake. Catches latency, partial fill and state bugs that dry runs miss.
4. Live small stake. £1–£5 stakes for 30 days. Real money but small. The final filter before scaling.

Skip any of these and you'll pay tuition. Skip step 3 and you'll pay heavily — paper-trade is where most rules reveal the gap between the trader's mental model and how the tool actually behaves.

When the rules system is the wrong abstraction

Visual rule systems have limits. Three concrete cases where the rules paradigm itself becomes the bottleneck:

• Strategies that need ML output every tick. A scoring model that takes market state and returns a probability is awkward to express as visual rules. You can fa