Swiss Finma Algorithmic Trading Expectations

When to Use

Use this skill when a firm runs algorithmic trading as an admitted participant of SIX Swiss Exchange, and you need to establish — or evidence to an auditor — that the controls the Swiss framework actually requires are in place.

Start from the duty chain, because it is the thing most Swiss algo-trading write-ups get wrong. FMIA (FinfraG, SR 958.1) does not mention algorithmic trading anywhere. The provision is Art. 31 of the ordinance, FMIO (FinfraV, SR 958.11), headed "Algorithmic trading and high-frequency trading" and issued under Art. 30 FMIA. Its addressee is the trading venue:

Art. 31 para. 1 — "The trading venue must be able to identify the following: a. orders generated by algorithmic trading; b. the different algorithms used for the creation of orders; c. the participants' dealers who initiated these orders in the trading facility."

Art. 31 para. 2 — "It shall require participants that pursue algorithmic trading to flag the orders generated in this manner, record all entered orders, including order cancellations, and in particular to possess effective precautions and risk controls that ensure that their systems: ..."

A participant is therefore bound by what its venue rulebook imposes under that mandate, plus FINMA's supervisory expectations for the institution itself (FINMA Circular 2013/8 mn 62–63). The engine encodes the SIX set: Trading Rules cl. 11.1.4 and 4.3.4, Directive 3 cl. 5.1.3 lit. h and cl. 10, and Directive 7 cl. 8. SIX Directive 3 in force 2 March 2026 restates FMIO Art. 31 para. 2 lit. a–e almost word for word — it differs only in addressing "the Exchange" rather than "the trading venue", and in writing "upper trading limits" for "upper limits" — so the venue text and the ordinance text are the same control set seen from two ends.

When NOT to Use

On a venue other than SIX. BX Swiss and SDX are separately authorised and publish their own participant rules; BX's published Participant Rules contain no algorithmic-trading clause at all. SwissFINMAComplianceEngine refuses any other venue rather than assuming the SIX obligations transfer. Read the venue's own rulebook.
As a source of numeric limits. Swiss law prescribes none — no message-rate cap, no price-collar percentage, no notional ceiling, no order-purge latency, no order-to-trade ratio. FMIO Art. 31 para. 2 lit. b says only "appropriate trading thresholds and upper limits"; lit. e no. 2 says only "slow down the flow of orders if there is a risk of the capacity of the system being reached". Every figure in a spec is the firm's own calibrated setting, recorded so the audit shows what was configured.
As a timestamp-precision requirement. There is no Swiss microsecond mandate. FMIA Art. 38, FMIO Art. 36 and FinfraV-FINMA (SR 958.111) Art. 1 para. 2 lit. b require the time of order receipt with no stated granularity. Microsecond granularity and the 100 µs UTC divergence bound come from MiFID II RTS 25, an EU instrument. Do not cite FINMA for them.
As the whole FMIA/FINMA obligation set. This is the algorithmic-trading control layer only. It does not perform transaction reporting (FMIA Art. 39, FinfraV-FINMA ch. 2), journal keeping (FinfraV-FINMA Art. 1), disclosure of shareholdings, derivatives reporting under FMIA Art. 104, or the FINMA Circ. 13/8 organisational duties on watch/restricted lists and the two-year retention of telephone and electronic records (mn 60–61).
As a substitute for a market-abuse surveillance system. FMIO Art. 31 para. 2 lit. d asks that systems be "effective for preventing violations of Articles 142 and 143 FMIA". This engine records that such controls exist; it does not detect spoofing or layering — see wash-trade-and-spoofing-self-detection.
Under MiFID II expectations. RTS 6 is materially more prescriptive than FMIO Art. 31 (annual self-assessment, kill functionality, pre-trade limits by article). A Swiss participant is not bound by RTS 6 by virtue of being Swiss. Use mifid-ii-algo-trading-compliance-eu for EU venues and do not merge the two control sets.

Prerequisites

Audit spec (AlgoTradingSystemAuditSpec): algo_id, strategy_version, governance_owner, venue; attestations flags_algo_generated_orders, reported_algo_trading_to_exchange, records_orders_including_cancellations, capacity_tested_for_peak_volume, has_pre_trade_thresholds, prevents_market_abuse_art_142_143, algorithms_and_controls_tested, limits_order_to_trade_ratio, can_throttle_order_flow, enforces_minimum_tick_size, provides_direct_electronic_access, can_delete_client_orders_on_demand; evidence pointers algorithm_identifier, initiating_trader_id, threshold_calibration_reference, strategy_documentation_reference; firm-calibrated settings max_order_to_trade_ratio, max_message_rate_per_sec.
Booleans must be actual booleans. A truthy "yes" or 1 would attest to a control nobody assessed, so the engine raises on it.
A per-algorithm identifier, not a per-firm one. SIX Trading Rules cl. 11.1.4 para. 1 requires "a separate identification for each algorithm". One identifier shared across a family of parameter variants does not satisfy it.
A calibration record for the thresholds. The provision requires them to be appropriate. has_pre_trade_thresholds=True with a blank threshold_calibration_reference fails, because appropriateness that is not written down cannot be demonstrated in an audit.
Strategy documentation aimed at a third party. FINMA Circ. 13/8 mn 63: "document the key features of their algorithmic trading strategies in a way that third parties can understand." Internal code comments are not that.
Threshold convention: a missing evidence pointer is a finding; a structurally invalid spec raises. The audit exists to surface the former and must never issue a verdict on the latter.

Workflow

Fix the venue first. Construct the engine for SIX_SWISS_EXCHANGE; anything else raises.
- Decision point — do not port the SIX control set to another Swiss venue. The obligations are imposed by each venue under FMIO Art. 31 para. 2, not by FMIA directly. BX Swiss's published Participant Rules have no algorithmic-trading clause, so auditing a BX connection against cl. 11.1.4 invents an obligation and an auditor will say so.
Identification and notification — SIX Trading Rules cl. 11.1.4 para. 1, Directive 3 cl. 5.1.3 lit. h, FMIO Art. 31 paras. 1–2. Confirm algo-generated orders are flagged, each algorithm carries its own identification, the initiating trader is indicated, and the operation of algorithmic trading has been reported to the Exchange.
- Decision point — the flag is an order attribute, not a system setting. Directive 3 cl. 5.1.3 lit. h makes it one of the attributes an order "must be recorded with", alongside side, trading capacity, ISIN and validity. It is enforced per order at entry, so a gateway that sets it for some order paths and not others is non-compliant on the paths that miss it.
- Decision point — whitespace is not an identifier. " " is truthy in Python; a naive if algorithm_identifier: reports the control satisfied on a blank field.
Order records — SIX Trading Rules cl. 11.1.4 para. 2, FMIO Art. 31 para. 2. Confirm sent orders including cancellations are kept on file.
- Decision point — cancellations are named explicitly, and they are the ones most often dropped. A pipeline that persists only fills and working orders loses exactly the record that evidences an order-to-trade ratio and that a manipulation investigation under Art. 143 FMIA would ask for.
Risk controls — FMIO Art. 31 para. 2 lit. a–e, restated in Directive 3 cl. 10 para. 1. Peak-volume capacity (lit. a); trading thresholds and upper limits with their calibration basis (lit. b); market-abuse prevention for Arts. 142/143 FMIA (lit. d); testing of algorithms and control mechanisms (lit. e), including an order-to-trade ratio limit (e no. 1), the ability to slow order flow when capacity is at risk (e no. 2) and minimum tick size enforcement (e no. 3).
- Decision point — record the configured value, never score it against an invented ceiling. The engine requires that a rate and a ratio be configured; it does not judge their magnitude, because no Swiss provision states one. Lit. c, "do not cause or contribute to any disruptions in the trading venue", is the outcome these controls serve, not a separate checkbox — an attestation to it would be unfalsifiable.
Supervisory documentation — FINMA Circ. 13/8 mn 62–63. Confirm a strategy description a third party can follow, and a named accountable owner.
Sponsored access and DEA — conditional. Only if provides_direct_electronic_access is set: SIX Trading Rules cl. 4.3.4 para. 2 requires the participant to be "authorised and able at any time to delete DEA client orders from the order book on instruction of the Exchange", and Directive 7 cl. 8 paras. 2–4 make the Exchange's pre-/at-trade controls mandatory and provide the Sponsoring Participant a "kill switch" over its Sponsored User's flow.
- Decision point — this is where the Swiss kill switch actually lives, and it is narrow. It is an Exchange-provided facility over client flow under sponsored access, activated by the Sponsoring Participant or, on request, by the Exchange. It is not a general obligation on every algorithmic participant, and FMIO Art. 31 does not mention one. A proprietary-only firm is outside it; the engine drops the control from the applicable set rather than manufacturing a breach.
Read the record, not the percentage. Act on is_compliant and failed_controls, each finding carrying its citation. Persist the record for the audit trail.

Full procedure: see references/workflows.md. Provision-by-provision regulatory map with source links: see references/standards.md. Printable pre-flight checklist: see assets/checklist.md.

Common Pitfalls

Citing "FinfraG Art. 31" or "FMIA" for an algorithmic-trading duty. The Act is silent on algorithmic trading. The provision is FMIO/FinfraV Art. 31, and it binds the trading venue, which then imposes the duties on participants through its rulebook. Getting the instrument wrong undermines every downstream claim in a compliance file.
Presenting "≤ 100 messages/second" as a Swiss requirement. No such cap exists anywhere in FMIA, FMIO, the SIX Trading Rules or Directive 3. Lit. e no. 2 requires the ability to slow the flow when capacity is at risk, and says nothing about a rate. A hard-coded cap rejects a legitimately faster participant while citing a rule that does not exist.
Presenting a ±5% price collar or a CHF notional ceiling as a Swiss requirement. Lit. b says "appropriate trading thresholds and upper limits" and stops there. FMIO Art. 30 para. 2 lit. d, which does speak of "pre-determined volume and price thresholds", is a duty on the venue's trading facility, not on the participant's gateway.
Claiming FINMA requires microsecond timestamps. It does not. That is MiFID II RTS 25. FinfraV-FINMA Art. 1 para. 2 lit. b asks for the time of order receipt with no precision stated. SIX's platform happens to publish microsecond timestamps; a vendor capability is not a legal requirement.
Treating a mandatory kill switch as a general FinfraG expectation. The only kill switch in the SIX rulebook is Directive 7 cl. 8 para. 4, scoped to Sponsored Access. Building one is good engineering — see execution-algorithm-kill-switch-integration — but do not book it as an FMIO Art. 31 obligation, and do not attach an invented purge-latency figure to it.
Registering the firm's algorithms in an internal inventory and calling cl. 11.1.4 satisfied. The clause has an outward limb: the participant "must report the operation of algorithmic trading to the Exchange". An internal registry alone does not discharge it.
One algorithm identifier for a family of parameter variants. "A separate identification for each algorithm" is what makes a specific algorithm reconstructable from the order record. Deploying variants under a shared id defeats the identification the venue must be able to perform under Art. 31 para. 1 lit. b.
Reading a partial score as partial compliance. Neither FINMA nor SIX publishes a compliance percentage. A participant that cannot identify its algorithms is in breach of cl. 11.1.4 at any score. finma_score_pct is a remediation progress indicator and is documented as such in the record's own notes.
Scoring a proprietary-only firm against the DEA control. It is not an addressee of cl. 4.3.4 or Directive 7. A fabricated breach in an audit file is as damaging as a missed one.
A truthy attestation. has_pre_trade_thresholds="yes" or =1 would sail through a boolean check while recording an assessment nobody made. So would a True message rate — True > 100 is False, which is how a boolean silently satisfies a numeric ceiling.
Assuming the framework is static. The EFD's FinfraG-Review (30 September 2022) proposes defining algorithmic trading and high-frequency trading in the Act or the ordinance — neither is defined today — and tightening the flagging obligation toward the EU model. The consultation on the FMIA amendment ran 19 June to 11 October 2024. Check the current status before relying on the present drafting.

Verification

Fully evidenced SIX participant with no DEA $\implies$ is_compliant=True, failed_controls=[], finma_score_pct=100.0, and exactly 13 applicable controls.
No invented ceiling: max_message_rate_per_sec of 101, 150, 5 000 and 250 000 must all remain compliant; a high max_order_to_trade_ratio must be recorded, not penalised. The engine's own notes must contain none of "100 msg", "CHF 500", "5%" or "microsecond".
Each control fires alone: clearing any single attestation or evidence pointer must produce exactly one finding, carrying its citation in trailing brackets.
Evidence-pointer semantics: has_pre_trade_thresholds=True with a blank calibration reference fails, and so does the reverse; limits_order_to_trade_ratio=True with max_order_to_trade_ratio=None fails; can_throttle_order_flow=True with max_message_rate_per_sec=None fails; " " must not count as an algorithm identifier, trader id, documentation reference or owner.
Conditional DEA control: absent DEA, CH_ALGO_14_DEA_ORDER_DELETION must not appear in applicable_controls and must not affect the score; with DEA, the denominator becomes 14 and a missing deletion capability is the sole finding.
Fail-closed legacy path (regression): ComplianceChecker.check_compliance("T1") must return is_compliant=False with a "NOT ASSESSED" note and score 0.0 — never True with a note such as "Compliant with Swiss FINMA FinfraG regulations." for any string. batch_check must be fail-closed for every identifier, and "", " ", None and 17 must not raise.
Mis-specification raises: a non-AlgoTradingSystemAuditSpec argument; a blank, whitespace or non-string algo_id; any of the twelve boolean fields set to "true", 1, 0, [] or None; any evidence field set to a non-string; max_message_rate_per_sec or max_order_to_trade_ratio of NaN, infinity, -1, 0, True or "400"; a venue of BX_SWISS, SDX, "", None or 3.
Citations: every declared control has a non-blank citation, and none attributes an algorithmic-trading duty to "FMIA Art. 31" — the Act has no such provision.
Run python -m unittest discover -s skills/swiss-finma-algorithmic-trading-expectations/scripts and confirm all tests pass.

Swiss Finma Algorithmic Trading Expectations

When to Use

When NOT to Use

Prerequisites

Workflow

Common Pitfalls

Verification

Hands off to 7

Handed off from 0

When to Use

When NOT to Use

Prerequisites

Workflow

Common Pitfalls

Verification

Related Skills

Hands off to 7

Handed off from 0