Early cancellation, risk limits and the three presets

Early cancellation lets a customer close a binary contract before it expires and get part of their stake back. It is a refund path with a configurable penalty, and the penalty is the whole product decision: leave it at zero and you have handed every trader a free option — enter, watch, exit for nothing when the price moves the wrong way, and keep the wins.

The other half of this page is the Risk Management tab, which contains two fields that look like safety nets and are not.

Both live on Admin → Finance → Binary Options → Binary Settings (/admin/finance/binary/settings), on the Cancellation, Risk Management and Presets tabs. Reading the console needs access.binary.settings; saving needs edit.binary.settings.

The two switches above every rule

cancellation.enabled is the global one. With it off, the cancel route refuses everything with 400 "Order cancellation is disabled", whatever the per-type rules say.

Under it, each of the five order types has its own CancellationRule, and each carries its own enabled. A type whose rule is off is refused with 400 "Cancellation is not available for <TYPE> orders".

What a rule contains

Some tiers can never fire

minTimeBeforeExpirySeconds is enforced before the tier is chosen, so a cutoff at or above a tier boundary makes the tiers below it unreachable. On the shipped defaults:

Call/Put is the clearest case: a 60-second cutoff means every permitted cancel happens with more than 60 seconds left, so above60Seconds is the answer every time and the other three numbers on the card are noise.

If you want the graduated penalties to actually grade, the cutoff has to be below 30 seconds.

The shipped rules

Touch/No Touch and Turbo ship disabled because both can be gamed: a Touch contract whose barrier has already been hit is a certain win the customer would otherwise cancel out of, and a Turbo contract is too short for an early exit to mean anything.

What the server checks, in order

cancelExpirationBuffer does not do what its name suggests

global.cancelExpirationBuffer (default 60) is published to the trading page through the public binary settings endpoint. That is the entire extent of it:

• Nothing on the server reads it. The only cutoff the cancel route enforces is the per-type minTimeBeforeExpirySeconds.
• Nothing on the trading page reads it either. The customer's cancel button is enabled while more than 10 seconds remain, hard-coded; the cash-out button needs 30 seconds since entry and 10 to expiry, also hard-coded.

So on a default install a customer sees a live cancel button from 30 seconds down to 10 seconds before expiry and gets an error if they press it, because the RISE_FALL cutoff is 30 seconds. Two ways to make the screen and the server agree:

• set minTimeBeforeExpirySeconds to 10 or less for every enabled type, so the button and the server refuse at the same moment; or
• accept the error and keep the wider cutoff, which is the safer commercial choice — a contract cancelled 11 seconds before expiry is very close to a free look at the outcome.

Set cancelExpirationBuffer to match whichever you choose anyway. It costs nothing and a future release may start honouring it.

Demo contracts never move money

Every wallet operation in the binary order service sits behind if (!isDemo). A practice contract is cancelled, refunded and settled entirely on paper — no wallet is read, no transaction row is written, no penalty is taken. Cancellation rules still apply to demo orders in every other respect, so practice is a safe place to check that a rule behaves the way you expect.

Risk Management

Two fields, on their own tab.

The field label also disagrees with itself: it is titled "(trades)" and described as a loss limit. Since nothing reads it, the ambiguity has no consequence today, but it means you cannot infer the intended unit from the screen.

The three presets

The Presets tab offers three complete configurations. Each is returned by its own endpoint with a human-written description, a feature list, a risk level and its own validation result.

Conservative — riskLevel: low

Described as: only RISE_FALL enabled, tight barrier distances (0.1%–0.3%), lower max amounts ($10–$500), a 50–70% profit range, a 5-second cooldown, and a daily loss limit enabled.

What it actually sets, for this page's subjects:

Balanced — riskLevel: medium, and the shipped default

Described as: only RISE_FALL, moderate barriers (0.1%–0.5%), standard amounts ($1–$1,000), a 65–85% profit range, no cooldown, configurable risk limits.

Aggressive — riskLevel: high

Described as: RISE_FALL and HIGHER_LOWER enabled, wider barriers (0.1%–1%), higher max amounts ($1–$10,000), a 55–90% profit range, no cooldown, relaxed risk limits, extended durations.

Applying one replaces everything

The Presets tab does setSettings(preset.settings) — the whole settings document is swapped, including every payout, every barrier ladder, the duration rungs, the cancellation rules and the risk fields. It is not a merge and it does not preserve anything you had configured.

Like the optimizer, it stages the change: the floating unsaved-changes bar appears and nothing is written until you press Save. Discard restores what was loaded.

Two metadata fields ride along on the object:

• _preset — the preset name, which is what the tab reads back to show which one is currently applied. An install that has never saved reports balanced, because the defaults are the balanced preset.
• _lastModified — an ISO timestamp. The PUT overwrites it with the moment of the save, so on a saved row it is the last time anybody pressed Save, not when the preset was authored.

The validation object

Both the GET and the PUT return validation: { valid, errors, warnings }, and the presets endpoint returns one per preset — so you can see a preset's warnings before applying it.

Errors block the save. The PUT answers 400 and writes nothing. Warnings do not block anything; each is an object:

The ones you will meet on this page's settings:

The full list, including the barrier-distance and average-payout warnings, is on Binary options: switching it on.

Deciding a cancellation policy

Related: Barriers, strikes and the payout optimizer, Order types, durations and payouts, and The binary order desk for reading a cancelled contract after the fact.