# Kronos X, Statement on Netting Semantics and the Venue-Initiated Flow Version 1.4, 10 September 2026. Technical statement issued by the venue operator for member due diligence. This document states what the matching engine actually does. Version 1.1 adds the venue-initiated flow of RFQ markets and barrier (knock-out) contracts. Version 1.2 updates sections 1 and 4 for the RTS 22 client identity surface (member reference section 6d): the venue can now hold member-submitted identification data for transaction-reporting purposes, outside the matching engine and outside risk. Version 1.3 adds the trade reversal mechanism (section 3, now six mechanisms, updated 12 August 2026) and aligns terminology: entries on the member account are called LEDGER entries throughout, matching the API's ledger surface; the `wallet` WebSocket channel name is a wire identifier and is unchanged. Version 1.4 adds the price-banded tranche wording to section 3 item 2, aligned with the Rulebook V1.3 section 20 text and Section 7.1 of the perpetual contract specifications; states in section 3 that an auto-deleveraging close is fee-free in both of its cases (the venue has never charged a fee on either leg of an ADL execution, and the statement now says so for the classic case as well as the RFQ-market case); states the restoration standard and the fee rule of a trade reversal (section 3, mechanism 5), the mechanism itself unchanged; corrects the rulebook section reference of the reversal power in section 3 item 5 to section 27 (section 26 is the Company's power to reject or cancel orders or quotes); and adds section 6, Record and reproduction: how the venue keeps its sequenced transaction record and how a calculation is reproduced from it. Section 6 describes the mechanism only; the contractual effect of the record is a matter for the Rules. Version 1.4 also states, in section 3 item 3, the auto-deleveraging consumption order in full and the ADL ranking basis by cross reference to the Member API. It is designed to be attached to, or referenced from, the written confirmation a member's onboarding requires. Legal review of the surrounding contractual language sits with the venue's Head of Legal. ## 1. Scope of terms "Member" is the venue's direct counterparty (the entity holding the trading account, margin and API keys). "End client" is a member's underlying client, identified to the venue only by the member-chosen opaque reporting identifier `clientUid`. The matching engine, margin, and every risk path read nothing but that identifier: no name, KYC or PII data enters any trading decision. One carve-out exists outside the engine: where the venue owes transaction reports under MiFIR Article 26(5) (members that are not MiFID II investment firms), the member submits the client identification RTS 22 requires against its `clientUid`s through a dedicated reference-data surface (member reference section 6d). That data is held solely for the venue's own regulatory reporting, is never read by matching or risk, and trading is never blocked on it. ## 2. Netting: what the venue does and does not do 1. **Order execution never nets across end clients.** Every order carries exactly one `clientUid`. A fill affects exactly the sub-position of that `clientUid`. The venue never offsets one end client's open interest against another end client's, and never aggregates two end clients' orders into one execution. 2. **A client's own open nets against their own close.** Sub-positions are kept per `(member, clientUid, instrument)`. A buy for a `clientUid` with an existing short reduces that short exactly; realized profit and loss is computed on that sub-position's own cost basis, to exact integer arithmetic. 3. **Risk is computed at member level.** Initial margin, maintenance margin, position limits, the reduce-only budget and the ADL quintile are computed on the member's net position, not per end client. Sub-positions are reporting objects: they are exact, they are durable, and they are never read by the risk engine. Three consequences a member must engineer for: - The member's margin requirement reflects its NET exposure. Two end clients long and short the same size net to zero member exposure. - A reduce-only order is admitted against the member's net position, so one end client's reduce-only order can be admitted because another end client holds the opposite exposure. - **Per-end-client leverage limits are the member's responsibility.** The venue margins the member on its published tier ladder and does not model, check or enforce a leverage limit per end client. A member offering its clients a fixed leverage (for example flat 10x) enforces that on its own side before submitting the order. The optional order-level `leverage` assertion exists so a member can DETECT a mismatch between its assumption and the venue's actual margin schedule (the venue rejects a false assertion); it never changes the margin applied. A stricter member-wide margin profile can be configured by the venue on request; it applies to that member only and is visible on that member's own account data. 4. **Same-member crossing is permitted by default.** Self-trade prevention is scoped to the end client (`stpScope = END_CLIENT`): two orders of the same member with different `clientUid` values match normally, and the venue treats this as legitimate agency flow. Orders of the same member with the SAME `clientUid` never trade with each other; the member's configured STP policy (cancel resting by default) is applied instead. A member may opt into strict member-level prevention (`stpScope = MEMBER`) through venue administration. ## 3. The venue-initiated (unsolicited) flow The venue can initiate activity on a member's account without a member request. There are exactly six mechanisms. Everything below is observable on the API, and every venue-generated execution carries a venue-generated reference in the reserved `KX-` namespace so it is mechanically distinguishable from member flow. 1. **Order cancellation.** The venue cancels member orders on: liquidation start, member suspension, instrument halt or delisting where configured, and self-trade prevention. Each cancel is delivered on the `order` channel with the order's own `clOrdId`, its `clientUid`, and a specific machine-readable `cancelReason`. **Blast radius, stated plainly:** when a liquidation episode opens against a member, the venue cancels that member's ENTIRE order book, venue-wide, across all instruments including spot, before closing positions; the member's open requests for quotes are cancelled and its outstanding RFQ quotes withdrawn in the same step. A member whose systems have no unsolicited-cancel concept must build one before go-live. 2. **Book liquidation.** If a member's equity falls below maintenance margin, the venue generates closing orders against the market. Each closing order is a market order for the tranche size published for the market as a Trading Parameter, never below the published minimum tranche and never more than the remaining position, price banded around the current mark by the published band in the interest of orderly execution (submitted as an immediate-or-cancel limit at the mark plus or minus the band); any part not executed within the band is cancelled and the next tranche is sized from the remaining position at the next liquidation check. Slices are allocated across the member's end clients pro-rata to sub-position size, one synthetic order per end client, so every liquidation fill names the `clientUid` it reduced and a venue reference of the form `KX-LQ-{orderId}`. On a market that trades by request for quote there is no order book to slice into: the liquidated member's position on such a market is closed in one step at the CURRENT MARK against opposite-side holders, delivered exactly like the ADL mechanism below. 3. **Auto-deleveraging (ADL).** Two cases reach counterparty members. First, the classic case: if the book cannot absorb a liquidation close at or above the bankruptcy price, the venue tears up matching exposure against counterparty members at the bankruptcy price. Second, the RFQ-market case: a liquidated member's position on a market that trades by request for quote is closed against counterparty members at the CURRENT MARK, in the same selection order, WITHOUT any bankruptcy having occurred; the print is at fair current value. In BOTH cases the close is fee-free on both legs: the venue charges no maker, taker or other fee on an ADL execution, and the only ledger entry an ADL execution books on either side is the realized profit or loss (ledger kind `ADLSETTLEMENT`). **Mutualisation, stated plainly:** in both cases selection is by member-level quintile ranking (the ranking basis, unrealized profit ratio multiplied by account leverage, highest first, is stated in the Member API, section 7, beside `GET /v1/adl/indicator`); profitable positions are closed first in that order and, only where they cannot absorb the whole position, the remaining opposite-side positions, including positions not in profit, at the same price; within an affected member, the closed quantity is allocated pro-rata across ALL of that member's end clients holding the same-direction position in that instrument. A specific end client's ADL close is therefore not caused by that end client's own conduct. This is the one mechanism where the venue's member-level risk model produces an effect a member cannot attribute to the behaviour of the affected end client, and members should represent it to their clients accordingly. Every ADL execution carries the affected `clientUid`, the instrument, decimal price and quantity, and the reference `KX-ADL-{tradeId}`. 4. **Barrier contract settlement.** Markets of kind `BARRIER` trade bilateral knock-out contracts by request for quote. The venue settles these contracts without a member instruction in four cases: knock-out (the mark touches the barrier; the contract terminates AT the barrier price, the guaranteed stop), expiry (settlement at the mark on the first price tick at or past the contract's expiry), liquidation tear-up (either party enters liquidation; the contract closes at the mark, never beyond the barrier), and final settlement of a delisted barrier market at an operator-determined price, likewise never beyond the barrier. Every settlement books zero-sum profit and loss between holder and writer as ledger entries of kind `BARRIERSETTLE`, is fee-free, and is delivered to both parties on the `barriers` channel with the settlement price and a typed reason. **Stated plainly:** a barrier contract can be closed by the venue because of the OTHER party's failure, not the member's own conduct. The holder's realised loss can never exceed the entry-to-barrier distance margined at entry, whatever the settlement cause. 5. **Trade reversal.** The venue may reverse an erroneous trade under its rulebook reversal power (rulebook section 27): it books ONE equal-and-opposite compensating trade at the ORIGINAL price between the SAME two members. The original trade record is never edited or deleted. The compensating execution carries flag `REVERSAL`, the reference `KX-RV-{originalTradeId}` on both legs, and the same `clientUid` values as the original legs; it is fee-free, does not move the last-trade print, never triggers conditional orders, and is excluded from order-to-trade ratios. One reversal per trade, enforced by the engine. **Stated plainly:** a reversal UNDOES the original trade's effect, so its `positionEffect` is the opposite of the original's. Reversing a trade that opened a position closes it; reversing a trade that CLOSED a position RE-ESTABLISHES it. A reversal is therefore the one venue-initiated execution that can carry `positionEffect` `OPEN` or `INCREASE`; liquidation and ADL executions always reduce. Reconciliation must key on the stamped `positionEffect`, never on an assumption that venue flow only closes. **Restoration standard, stated plainly:** the compensating trade restores the parties so far as reasonably practicable. It settles realised profit and loss against the sub-position's cost basis at the time of the reversal, and the venue does not unwind any funding settlement, liquidation, auto-deleveraging or other event that occurred between the original trade and the reversal; a re-established position is margined from the moment of the reversal like any other. **Fees and funding:** the compensating trade itself is fee-free. Where the venue initiated the reversal, venue operations refund the trading fees charged on the original trade to both parties and, where the reversed lots paid or received funding between the two trades, compensate the net funding attributable to those lots; each such amount is a separate ledger entry of kind `MANUALADJUST` (the venue's manual adjustment kind, served on the ledger surface since it existed and first named in this version; `refId` 0, no reference on the entry itself), delivered on the `wallet` channel and readable on `GET /v1/account/ledger`, and the venue's written notice of the reversal names the reversed trade, the compensating trade and the entries. Where both parties requested the reversal, the original fees are retained and no such entry is booked. 6. **Trading-state changes.** The venue halts, resumes, restricts or delists instruments (circuit breakers, stale marks, administrative action). These are published with a typed reason on the venue-events channel and on `GET /v1/status`. ## 4. Confidentiality of end-client identifiers A member's `clientUid` values are visible only to that member. On every surface, including liquidation and ADL reporting, a member sees `clientUid` values only for its own end clients; allocations attributed to other members are reported without their identifiers. The optional regulatory fields block (`reg`) on an order can carry an LEI or national identifier for transaction-reporting purposes; it is never required by the venue for order acceptance, is recorded verbatim, and is disclosed only through the venue's own regulatory reporting, never to another member. The same confidentiality applies to the RTS 22 client identity records of section 1: a member reads back only its own records, every revision is retained for audit, and the data is disclosed only through the venue's own regulatory reporting, never to another member. ## 5. What the venue asks the member to confirm in return 1. The member operates a handler for unsolicited order cancels and unsolicited executions (liquidation and ADL), keyed on the `KX-` reference namespace and the `LIQUIDATION`/`ADL` execution flags, and, where the member trades barrier markets, a handler for venue-initiated contract settlements on the `barriers` channel. 2. The member understands that risk, margin and ADL ranking are member-level, and that the venue's per-end-client records are reporting data, not risk data. 3. The member's own client-facing allocation of funding, fees and forced closes is the member's responsibility; the venue provides per-end-client attribution data sufficient to perform it. ## 6. Record and reproduction 1. Every state change on the venue is the effect of exactly one sequenced command carrying a UTC timestamp at nanosecond resolution, written to an append-only journal; no acknowledgement is sent before the covering write is durable. 2. The matching engine is deterministic: a reproduction of the record from the verified period-end snapshot with the binary version that produced it reproduces every calculation exactly, to the micro (the venue's replay invariant I-6): profit and loss on open and closed positions, funding, fees, collateral, margin, liquidation and ADL allocations and barrier settlements alike. 3. Every event the engine emits is folded into a sealed rolling hash of the event stream, and the engine state hash is verified against the snapshot record at nightly anchors. 4. The monthly statement PDF carries a SHA-256 shown in the member portal so a downloaded copy can be verified. Where the venue has configured annex signing (the portal states whether it has), the monthly IFR data annex carries a detached Ed25519 signature over the exact annex bytes, verifiable against the venue's published verification key (Member API revision 3.31).