# Vercy AI instruction - YAML 1.2 (JSON-compatible) { "vercy": "1.0-draft", "publication": { "status": "published", "adjudicationStatus": "reviewable-draft", "publishableCanonical": false, "generatedAt": "2026-09-05T16:29:21Z", "synthesisSha256": "c4025908977e2787a786fbc429052834f1b942259d85c652eaa88707df6fe064", "providerMode": "dual-provider", "providers": [ "Claude", "Grok" ], "waivedProviders": [] }, "metaModel": { "id": "WM-ECO-001", "registryId": "vr.wm-eco-001", "name": "Market / Exchange", "version": "0.3.0-research.1", "previousVersions": [], "entryKind": "aggregate", "family": "World Models", "category": "Society, people and institutions", "industry": [ "Cross-industry" ], "domain": [ "SOC.ECO.MKT" ], "tags": [ "market", "exchange", "soc.eco.mkt" ], "status": "published" }, "canonicalUrl": "https://ver.cy/models/wm-eco-001-market-exchange/", "sourceUrl": "https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-eco-001", "model": { "registry_id": "vr.wm-eco-001", "model_id": "WM-ECO-001", "name": "Market / Exchange", "entry_kind": "aggregate", "purpose": "Give an agent the governed context needed to identify, describe, operate and audit an organised market or exchange: venue and segments, rulebook, admitted scope, participants and access, order and quote intake, matching and price formation, published transparency, and the disciplined handoff of matched trades to clearing, settlement and oversight models that own those semantics.", "scope_statement": "WM-ECO-001 models an organised market place: a multilateral venue bringing together multiple third-party buying and selling interests in a defined class of tradable objects under published rules. It is an aggregate because venue identity, segment and order-book structure, rulebook version, participant admission, order and quote records, trading phases, matching rules and executed-trade events share one consistency boundary under a single operator's authority. The model owns the venue's own assertions and its own market-event records. It does not own the objects traded, the legal entities that trade, the infrastructures that clear and settle, the contracts that arise, or the supervisory processes that investigate and enforce. Storage and interface formats are projections, not semantics.", "in_scope": [ "Venue identity and operating structure: operating and segment market identifier codes, operator legal-entity reference, market category, country and city, and the operating-to-segment whole-part hierarchy.", "Regulatory standing: authorisation or designation class (regulated market, MTF, OTF, designated contract market, organised market place), competent or designating authority, and status transitions.", "Rulebook version, governance and conflicts disclosure, and the venue's declared market model.", "Participant admission, membership categories, eligibility evidence, access channels, entitlements and liquidity-provision commitments.", "Admission of tradable objects to trading on the venue, and the trading parameters attached to that admission.", "Order, quote and request-for-quote intake records, their attributes, event sequence, status and order-book priority.", "Trading calendar and phases, matching algorithm and priority rules, volatility controls and halts.", "Official and indicative prices produced by the venue's own price-formation process, and pre- and post-trade transparency publications with waiver and deferral flags.", "Executed-trade events recorded by the venue, and their correction, cancellation and supersession.", "Conduct rules applicable on the venue, declared surveillance arrangements, referral pointers, record-retention parameters and clock-traceability evidence." ], "out_of_scope": [ "The economic or competition-law construct of a 'relevant market' defined by substitutability and the hypothetical-monopolist test; that is an analytical construct, not a venue.", "Mastering of financial instrument or product reference data (ISIN, CFI, UPI, notional currency, issuer); this model carries only the admission binding.", "Legal-entity mastering, LEI issuance, validation and renewal, and ownership hierarchies.", "Clearing and settlement semantics: novation, netting, margin, collateral, default management, settlement finality, money settlement and physical delivery execution.", "Contract formation terms, obligations, performance and remedies arising from an executed trade.", "Surveillance alert generation, investigation, case adjudication, sanctions and enforcement, and the evidentiary audit-trail semantics of those processes.", "Regulatory report submission lifecycle and its acceptance, rejection and correction states.", "Benchmark or index administration and the governance of derived indices.", "Position, custody and portfolio accounting.", "Governance audit trails of who read or changed a record in this model; that belongs to the adopting Dimension's audit model.", "Physical facilities, data-centre and colocation hardware." ], "boundary_notes": [ { "neighbor": "Economic 'relevant market' in competition analysis", "distinction": "A relevant market is an analytical construct delimited by product and geographic substitutability using the SSNIP test; it has no operator, rulebook, membership or order book. WM-ECO-001 models an institution with an authoritative identifier, not an analytical delimitation. Name collision only.", "source_refs": [ "SRC-013" ] }, { "neighbor": "Financial instrument / tradable product model", "distinction": "The peer model masters the object's identity and terms. This model records only which objects are admitted to trading here, on which segment, from when, and with which venue-specific trading parameters.", "source_refs": [ "SRC-006", "SRC-008" ] }, { "neighbor": "Legal entity / organisation model", "distinction": "Operator, participants and issuers are referenced by governed identifiers such as the ISO 17442 LEI or an ACER registration code. Entity reference data, validation and renewal remain with the peer registry.", "source_refs": [ "SRC-010", "SRC-007" ] }, { "neighbor": "Financial market infrastructure model (CCP, CSD, securities settlement system, payment system)", "distinction": "PFMI assigns settlement finality, netting, margin, collateral, participant-default rules, segregation and portability to the FMI. This model records only the clearing arrangement binding and the settlement terms asserted at execution, plus downstream status as an observation.", "source_refs": [ "SRC-001" ] }, { "neighbor": "Contract / agreement model", "distinction": "The venue records that a match occurred and its economic terms as a market event. The resulting legal contract, its obligations and its performance lifecycle are peer-owned.", "source_refs": [ "SRC-006" ] }, { "neighbor": "Market abuse surveillance and enforcement case model", "distinction": "IOSCO, MiFIR, REMIT and CFTC core principles require monitoring and disciplinary procedures. This model carries the declared arrangement, its parameters and a referral pointer; alert evaluation, investigation, adjudication, sanctions and audit-trail semantics stay with the peer model.", "source_refs": [ "SRC-002", "SRC-007", "SRC-009" ] }, { "neighbor": "Regulatory reporting submission model", "distinction": "MiFIR Article 26 and the REMIT implementing regulation define submission obligations. This model records the supply binding (which data, to which authority, under which legal basis); the submission lifecycle, acknowledgement and rejection states are peer-owned.", "source_refs": [ "SRC-006", "SRC-008" ] }, { "neighbor": "Benchmark or index administration model", "distinction": "Official closing and settlement prices produced here may feed a benchmark. Benchmark methodology, governance and publication are peer-owned; this model owns only the venue's own price observation and its method reference.", "source_refs": [ "SRC-002" ] }, { "neighbor": "Bilateral over-the-counter execution and systematic internalisation", "distinction": "A systematic internaliser deals on own account against client orders and is not a multilateral venue. Recognition test: multiple third-party interests interacting under the operator's non-discretionary or disclosed rules. Bilateral execution is out of scope.", "source_refs": [ "SRC-006" ] }, { "neighbor": "Adopting-Dimension audit and access-log model", "distinction": "The venue's order-event log is this model's own operational market record required by RTS 24. It is distinct from the governance audit trail of reads and writes against this model, which the adopting Dimension owns.", "source_refs": [ "SRC-004" ] } ] }, "sources": [ { "id": "SRC-001", "title": "Principles for Financial Market Infrastructures (PFMI)", "organization": "Committee on Payments and Market Infrastructures (BIS) and IOSCO", "url": "https://www.bis.org/cpmi/info_pfmi.htm", "version_or_date": "April 2012 (24 principles, 5 responsibilities)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T12:00:00Z", "relevance": "Defines the FMI boundary: settlement finality, participant-default rules, access and participation requirements, tiered participation, FMI links, communication procedures and standards, and disclosure of rules and market data. Used to keep clearing and settlement semantics outside this model." }, { "id": "SRC-002", "title": "Objectives and Principles of Securities Regulation", "organization": "International Organization of Securities Commissions (compendium record hosted by the Financial Stability Board)", "url": "https://www.fsb.org/2017/05/cos_100601/", "version_or_date": "31 May 2017", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T12:00:00Z", "relevance": "Principles 33-37 subject secondary and other markets to authorisation and ongoing oversight, and require fair, transparent and equitable trading rules. Anchors the venue-authorisation, transparency and integrity bundles." }, { "id": "SRC-003", "title": "ISO 10383 Market Identifier Codes (MIC) registry and registration procedures", "organization": "ISO 10383 Registration Authority, S.W.I.F.T. SC (La Hulpe, Belgium)", "url": "https://www.iso20022.org/market-identifier-codes", "version_or_date": "Registry list published 10 August 2026; monthly cycle, second Monday", "source_type": "registry", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T12:00:00Z", "relevance": "Authoritative registry for operating and segment MICs, market name, legal entity name and LEI, market category code, country, city, website, status and validation dates. Primary identity source for the venue." }, { "id": "SRC-004", "title": "Commission Delegated Regulation (EU) 2017/580 - regulatory technical standards for the maintenance of relevant data relating to orders in financial instruments", "organization": "European Commission (EUR-Lex)", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32017R0580", "version_or_date": "24 June 2016; OJ L 87, 31 March 2017", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T12:00:00Z", "relevance": "Table 2 enumerates the order record fields trading venues must keep: segment MIC, order book code, instrument ISIN, order identification, event sequence number, priority timestamp and size, validity period, order type and classification, prices, quantities, trading capacity, liquidity provision, passive/aggressive, self-execution prevention, strategy links and trading phase." }, { "id": "SRC-005", "title": "Commission Delegated Regulation (EU) 2017/574 - regulatory technical standards for the level of accuracy of business clocks", "organization": "European Commission (EUR-Lex)", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32017R0574", "version_or_date": "7 June 2016; OJ L 87, 31 March 2017", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T12:00:00Z", "relevance": "Requires traceability to UTC from BIPM-listed timing centres, with maximum divergence of 1 millisecond (or 100 microseconds where gateway-to-gateway latency is at or below 1 millisecond) and timestamp granularity of 1 millisecond or 1 microsecond. Grounds the timestamp rule and clock-traceability finding." }, { "id": "SRC-006", "title": "Regulation (EU) No 600/2014 on markets in financial instruments (MiFIR)", "organization": "European Parliament and Council (EUR-Lex)", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32014R0600", "version_or_date": "15 May 2014, as amended", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T12:00:00Z", "relevance": "Defines trading venue, regulated market, MTF, OTF and systematic internaliser; sets pre-trade transparency and waivers (Articles 3-4), post-trade transparency and deferrals (Articles 6-7), non-equity transparency (Articles 8-11), market data on reasonable commercial terms (Articles 12-13), record-keeping (Article 25), transaction reporting (Article 26) and instrument reference data supply (Article 27)." }, { "id": "SRC-007", "title": "Regulation (EU) No 1227/2011 on wholesale energy market integrity and transparency (REMIT)", "organization": "European Parliament and Council (EUR-Lex)", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32011R1227", "version_or_date": "25 October 2011, as amended", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T12:00:00Z", "relevance": "Extends the organised-market-place concept beyond securities: insider-dealing and manipulation prohibitions (Articles 3-5), publication of inside information (Article 4), records of transactions and orders to trade (Article 8) and registration of market participants with unique identifiers (Article 9)." }, { "id": "SRC-008", "title": "Commission Implementing Regulation (EU) No 1348/2014 on data reporting implementing Article 8(2) and 8(6) of Regulation (EU) No 1227/2011", "organization": "European Commission (EUR-Lex)", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32014R1348", "version_or_date": "17 December 2014", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T12:00:00Z", "relevance": "Specifies reportable order and contract details at organised market places: participant identification (ACER code, LEI, BIC, EIC, GLN), order and contract identifiers, order type, condition and status, price, quantity and unit, delivery point or zone EIC, delivery period, and transaction timestamp in UTC. Also requires venues to supply product reference data before trading." }, { "id": "SRC-009", "title": "Designated Contract Markets (DCMs) - 23 Core Principles under Section 5(d) of the Commodity Exchange Act, 17 CFR Part 38", "organization": "U.S. Commodity Futures Trading Commission", "url": "https://www.cftc.gov/IndustryOversight/TradingOrganizations/DCMs/index.htm", "version_or_date": "Current core-principle list as published by the CFTC", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T12:00:00Z", "relevance": "Independent non-EU corroboration of venue obligations: contracts not readily subject to manipulation, prevention of market disruption, position limits, emergency authority, availability of general information, daily publication of trading information, execution of transactions, trade information, financial integrity, disciplinary procedures, dispute resolution, conflicts of interest, recordkeeping and system safeguards." }, { "id": "SRC-010", "title": "ISO 17442 - the LEI code structure", "organization": "Global Legal Entity Identifier Foundation (GLEIF)", "url": "https://www.gleif.org/en/about-lei/iso-17442-the-lei-code-structure", "version_or_date": "ISO 17442-1 (2012 basis), ISO 17442-2 published 2019", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T12:00:00Z", "relevance": "Twenty-character governed global identifier for the operating legal entity, participants and issuers, with Level 1 'who is who' and Level 2 'who owns whom' reference data, registration status and renewal. Sets the second tier of the identity priority." }, { "id": "SRC-011", "title": "Form ATS-N Filings and Information (Rule 304 of Regulation ATS, 17 CFR 242.304)", "organization": "U.S. Securities and Exchange Commission, Division of Trading and Markets", "url": "https://www.sec.gov/about/divisions-offices/division-trading-markets/alternative-trading-systems/form-ats-n-filings-information", "version_or_date": "Page updated 30 March 2026; rule adopted 18 July 2018", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T12:00:00Z", "relevance": "Requires public disclosure of the manner of operation of an NMS stock alternative trading system - order types and attributes, how orders interact, match and execute, segmentation, hours, fees, market data and operator conflicts - plus initial, amendment and cessation filings. Anchors rulebook, matching and governance-disclosure findings." }, { "id": "SRC-012", "title": "FIX Latest Order State Changes (as of EP284)", "organization": "FIX Trading Community / FIX Protocol Ltd", "url": "https://www.fixtrading.org/wp-content/uploads/download-manager-files/FIX-Latest-as-of-EP284-Order-State-Changes.pdf", "version_or_date": "FIX Latest, Extension Pack 284; copyright 2011-2023", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-05T12:00:00Z", "relevance": "De facto industry order state model: OrdStatus conveys the current order state after an event while ExecType conveys the reason for the execution report, with defined transitions for new, partially filled, filled, replaced, cancelled, rejected, expired, done-for-day and pending states." }, { "id": "SRC-013", "title": "Market Definition - OECD Roundtables on Competition Policy Papers No. 130", "organization": "Organisation for Economic Co-operation and Development, Competition Committee", "url": "https://www.oecd.org/content/dam/oecd/en/publications/reports/2012/10/market-definition_e54deedd/62f0f46c-en.pdf", "version_or_date": "2012", "source_type": "public-authority", "primary_source": false, "authority_tier": 2, "accessed_at": "2026-09-05T12:00:00Z", "relevance": "Establishes that the competition-law 'relevant market' is an analytical construct with product and geographic dimensions assessed by the hypothetical-monopolist (SSNIP) test. Used only to exclude that concept from this model's boundary." }, { "id": "SRC-014", "title": "IOSCO Principles - Executive Summary (FSI Connect)", "organization": "Financial Stability Institute, Bank for International Settlements", "url": "https://bis.org/fsi/fsisummaries/iosco_principles.htm", "version_or_date": "29 June 2023", "source_type": "secondary", "primary_source": false, "authority_tier": 2, "accessed_at": "2026-09-05T12:00:00Z", "relevance": "Confirms that Principles 33-37 require secondary and other markets to be subject to regulatory authorisation and oversight, and that integrity and transparency of trading be maintained through rules fair and equitable to all participants. Used as corroboration where the IOSCO PDF was not directly retrievable." }, { "id": "SRC-015", "title": "Commission Delegated Regulation (EU) 2017/587 - regulatory technical standards on transparency requirements for trading venues and investment firms in respect of shares and similar instruments", "organization": "European Commission (EUR-Lex)", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32017R0587", "version_or_date": "14 July 2016; OJ 31 March 2017; applied 3 January 2018", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T12:00:00Z", "relevance": "Annex I defines post-trade publication fields (trading date and time, instrument code, price, price currency, quantity, venue of execution, publication date and time, transaction identification code) and flags including BENC, ACTX, NPFT, NLIQ, SDIV, LRGS, CANC and AMND. Grounds the transparency and trade-correction findings." }, { "id": "SRC-016", "title": "ISO 10383:2012 Securities and related financial instruments - Codes for exchanges and market identification (MIC)", "organization": "International Organization for Standardization", "url": "https://www.iso.org/standard/61067.html", "version_or_date": "Edition 3, 2012-10; confirmed 2023-06-14 (stage 90.93)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T18:30:00Z", "relevance": "Normative definition of MIC purpose, operating-level versus market-segment MIC, and use as place of official listing, place of trade and trade-reporting facility." }, { "id": "SRC-017", "title": "Directive 2014/65/EU of the European Parliament and of the Council of 15 May 2014 on markets in financial instruments (MiFID II)", "organization": "European Union", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32014L0065", "version_or_date": "OJ L 173, 12.6.2014; current consolidated version 06/06/2026", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T18:00:00Z", "relevance": "Binding EU definitions of multilateral system, market operator, regulated market, MTF, OTF, trading venue, systematic internaliser, access, algorithmic trading obligations of venues, and exclusion of CCPs from OTF." }, { "id": "SRC-018", "title": "Securities Exchange Act of 1934, section 3(a) definitions of exchange, facility and member", "organization": "United States Congress", "url": "https://www.govinfo.gov/content/pkg/COMPS-1885/pdf/COMPS-1885.pdf", "version_or_date": "As amended through P.L. 119-60, enacted 18 December 2025", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T18:00:00Z", "relevance": "US statutory definition of exchange as an organisation that constitutes, maintains or provides a marketplace or facilities for bringing together purchasers and sellers of securities, including the marketplace and facilities maintained by such exchange." }, { "id": "SRC-019", "title": "FIBO Markets Ontology (FBC FunctionalEntities Markets)", "organization": "EDM Association dba EDM Council, Inc. / Object Management Group", "url": "https://spec.edmcouncil.org/fibo/ontology/FBC/FunctionalEntities/Markets/", "version_or_date": "versionIRI 20260701; ontology modified through 2015-2026", "source_type": "ontology", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-05T18:00:00Z", "relevance": "Formal classes for Exchange, operating-level and segment-level markets, MIC status, ISO 10383 market category classifiers, ATS, RM, MTF, OTF, DCM, SEF, SI, TRF, DRSP, CASP, auction and quote-driven markets, and exchange participant." }, { "id": "SRC-020", "title": "Principles for financial market infrastructures", "organization": "Committee on Payments and Market Infrastructures and International Organization of Securities Commissions (BIS)", "url": "https://www.bis.org/cpmi/publ/d101.htm", "version_or_date": "Issued 16 April 2012; FSI Executive Summary 27 July 2023", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T18:00:00Z", "relevance": "Defines FMIs as payment systems, CSDs, SSS, CCPs and trade repositories. Used to keep trading-venue semantics out of FMI lifecycle, evaluation, recovery and audit ownership." }, { "id": "SRC-021", "title": "Regulation (EU) 2023/1114 on markets in crypto-assets (MiCA)", "organization": "European Union", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32023R1114", "version_or_date": "31 May 2023, OJ L 150, 9.6.2023; crypto-asset service rules applicable 30 December 2024", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T18:00:00Z", "relevance": "Defines operation of a trading platform for crypto-assets as management of multilateral systems that bring together multiple third-party purchasing and selling interests in crypto-assets in accordance with rules, resulting in a contract." }, { "id": "SRC-022", "title": "FAQ ISO 10383 January 2023", "organization": "SWIFT SC as ISO 10383 Registration Authority", "url": "https://www.iso20022.org/sites/default/files/media/file/FAQ_ISO_10383_January2023.pdf", "version_or_date": "January 2023", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-05T18:00:00Z", "relevance": "Registration-authority rules: four-character non-intelligent MIC, immutability of an allocated code, operating versus segment MIC, applicant eligibility, and publication versus effective dates." }, { "id": "SRC-023", "title": "ISO 10383 Market Identifier Codes - Release 2.0 Factsheet", "organization": "SWIFT SC as ISO 10383 Registration Authority", "url": "https://www.iso20022.org/sites/default/files/media/file/ISO10383_MIC_Release_2_0_Factsheet_v2.pdf", "version_or_date": "Release 2.0 factsheet v2 (dataset structure used by the live 2026 register)", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-05T18:00:00Z", "relevance": "Field inventory and datatypes for MIC, operating MIC, OPRT/SGMT, names, LEI, market category, status ACTIVE/UPDATED/EXPIRED, expiry date, last update date, country, city, website and acronym." } ], "structure": { "bundles": [ { "id": "b-venue-and-scope", "name": "Market Venue and Scope", "description": "The identity, regulatory standing, internal structure, rulebook and governance of the venue itself - the facts that make one organised market place distinguishable from another and from adjacent classes.", "rationale": "Every downstream record (membership, order, trade, publication) is scoped by a specific segment of a specific venue. The MIC registry supplies an authoritative identifier and the venue's authorisation class determines which obligations apply, so venue identity must be settled before anything else is modelled.", "source_refs": [ "SRC-003", "SRC-006", "SRC-002", "SRC-011" ], "layers": [ { "id": "l-venue-identity-and-authorisation", "name": "Venue Identity and Authorisation", "description": "Authoritative identification of the venue and its legal and regulatory standing, including the class of authorisation and the authority that granted it.", "source_refs": [ "SRC-003", "SRC-006", "SRC-009", "SRC-002" ], "findings": [ { "id": "f-venue-identity-codes", "name": "Venue identity and registry codes", "description": "The authoritative identification of the venue: operating and segment market identifier codes from the ISO 10383 registry, the operator's governed legal-entity identifier, registered market and legal entity names, acronym, country and city.", "source_refs": [ "SRC-003", "SRC-010" ], "questions": [ { "id": "q-vic-1", "text": "Which registry-assigned code is the authoritative master identifier for this venue, and is it an operating or a segment code?", "kind": "identity", "answer_data": [ "ISO 10383 MIC value", "operating-or-segment indicator", "operating MIC of the parent where the code is a segment code", "registration authority reference" ] }, { "id": "q-vic-2", "text": "Which governed global identifier resolves the legal entity that operates the venue, and how is it kept current?", "kind": "ownership", "answer_data": [ "ISO 17442 LEI of the operating entity", "registered legal entity name", "LEI registration status and next renewal date as an external reference" ] }, { "id": "q-vic-3", "text": "In which country and city does the venue operate for registry purposes, and how does that differ from where its matching engine runs?", "kind": "spatial", "answer_data": [ "ISO country code", "city of registration", "declared location of the matching facility where disclosed", "distinction flag between registry location and operational location" ] }, { "id": "q-vic-4", "text": "What registry status does the code carry, and on which dates was it created, last updated and last validated?", "kind": "provenance", "answer_data": [ "registry status value (active, updated, expired)", "creation date", "last update date", "last validation date", "expiry date where applicable" ] } ], "data_elements": [ { "id": "de-mic", "name": "Market identifier code", "description": "Four-character ISO 10383 code identifying the venue or one of its segments, assigned and maintained by the registration authority.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-003" ] }, { "id": "de-operating-mic", "name": "Operating market identifier code", "description": "The parent operating code when the record identifies a market segment rather than a whole market operator.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-operator-lei", "name": "Operator legal entity identifier", "description": "ISO 17442 twenty-character identifier of the legal entity operating the venue; a reference to the peer entity registry, not a copy of its reference data.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010", "SRC-003" ] }, { "id": "de-registry-status", "name": "Registry status and validation dates", "description": "Status value plus creation, last update, last validation and expiry dates as published by the registration authority.", "value_kind": "object", "cardinality": "1", "required": true, "source_refs": [ "SRC-003" ] } ], "artifacts": [ { "id": "a-venue-identity-record", "name": "Venue identity record", "description": "The governed record binding the venue to its registry code, operator entity reference, names, location and registry status, with the registry publication it was derived from.", "media_or_form": [ "structured record", "tabular registry extract" ], "serial": false, "identity_strategy": "Primary key is the ISO 10383 operating or segment MIC as authoritative master-system identifier; the operator LEI is carried as a governed global reference; an adopting-Dimension ULID is minted only for venues with no registry code and is retired in favour of the MIC once assigned.", "source_refs": [ "SRC-003", "SRC-010" ] } ], "inline_only_rationale": null }, { "id": "f-venue-authorisation-status", "name": "Venue authorisation class and status", "description": "The class under which the venue is authorised, designated or registered, the authority responsible, and the dated transitions of that standing including suspension and withdrawal.", "source_refs": [ "SRC-006", "SRC-009", "SRC-002", "SRC-007" ], "questions": [ { "id": "q-vas-1", "text": "Under which authorisation class does the venue operate, and which authority granted or designated it?", "kind": "authority", "answer_data": [ "authorisation class value (regulated market, MTF, OTF, designated contract market, organised market place, other)", "competent or designating authority reference", "authorisation or designation reference number" ] }, { "id": "q-vas-2", "text": "What authorisation states are valid for this venue, and which evidenced event moves it between them?", "kind": "lifecycle", "answer_data": [ "state set (applied, authorised, operating, suspended, restricted, withdrawn, ceased)", "triggering event type per transition", "evidence document reference per transition" ] }, { "id": "q-vas-3", "text": "From which instant is each authorisation state effective, and when was that fact observed by this model?", "kind": "temporal", "answer_data": [ "effective-from timestamp", "effective-to timestamp where bounded", "observation or ingestion timestamp", "source publication reference" ] }, { "id": "q-vas-4", "text": "Which jurisdictions recognise this venue for their own regulatory purposes, and on what basis?", "kind": "interoperability", "answer_data": [ "recognising jurisdiction code", "recognition instrument reference", "recognition validity interval" ] } ], "data_elements": [ { "id": "de-authorisation-class", "name": "Authorisation class", "description": "Versioned code for the regulatory class under which the venue operates, qualified by the scheme and jurisdiction that defines it.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-006", "SRC-009", "SRC-007" ] }, { "id": "de-competent-authority", "name": "Competent or designating authority", "description": "Reference to the authority that authorised, designated or registered the venue; identity of that authority is peer-owned.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-006", "SRC-009" ] }, { "id": "de-authorisation-state", "name": "Authorisation state with validity interval", "description": "Current state and its effective interval, recorded separately from the instant this model observed the change.", "value_kind": "object", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-002", "SRC-006" ] } ], "artifacts": [ { "id": "a-authorisation-status-record", "name": "Authorisation status record", "description": "Dated record of authorisation class, granting authority, state and validity interval, with a pointer to the authority's published register entry as evidence.", "media_or_form": [ "structured record", "authority register extract" ], "serial": true, "identity_strategy": "Composite of the venue MIC and the authority's authorisation reference number as authoritative master-system identifiers, with a monotonic version sequence per transition; no trading-day or date component is used as the identifier.", "source_refs": [ "SRC-006", "SRC-009" ] } ], "inline_only_rationale": null }, { "id": "f-multilateral-recognition-criteria", "name": "Multilateral recognition criteria", "description": "A trading venue is recognised by the presence of a multilateral system in which multiple third-party buying and selling interests interact under rules in a way that results in a contract. SEA 1934 instead emphasises an organisation that provides a marketplace or facilities for bringing together purchasers and sellers of securities. Discretionary matching distinguishes an OTF from RM/MTF. These are logical tests, not a stored document type.", "source_refs": [ "SRC-017", "SRC-018", "SRC-019", "SRC-021" ], "questions": [ { "id": "f-multilateral-recognition-criteria-q01", "text": "Does this facility operate a multilateral system in which multiple third-party buying and selling interests can interact in the system under its rules so that a contract can result?", "kind": "classification", "answer_data": [ "value_type: boolean", "Boolean plus a short evidence note citing rulebook or authorisation findings." ] }, { "id": "f-multilateral-recognition-criteria-q02", "text": "Are interests matched under non-discretionary rules (RM or MTF) or may the operator use discretion (OTF), and is own-account matching of third-party interests prohibited in the way a venue is prohibited from acting as an SI?", "kind": "constraint", "answer_data": [ "value_type: object", "matching_rule_type in {non-discretionary, discretionary, bilateral-own-account, mixed} and prohibition notes." ] }, { "id": "f-multilateral-recognition-criteria-q03", "text": "What observations, with method, time and confidence, distinguish this facility from an adjacent class such as broker crossing, bulletin board, e-commerce catalogue, CCP, or DRSP?", "kind": "evidence", "answer_data": [ "value_type: object", "Observation object: method, event_time, observation_time, confidence, adjacent_class_rejected, evidence_refs." ] }, { "id": "f-multilateral-recognition-criteria-q04", "text": "If the US Exchange Act definition applies, which premises, property rights, communication systems and reporting facilities are included as facilities of this exchange?", "kind": "composition", "answer_data": [ "value_type: array", "Array of facility-component descriptions without physical measurements unless a referenced physical-site model supplies them." ] } ], "data_elements": [ { "id": "f-multilateral-recognition-criteria-data01", "name": "Is multilateral system", "description": "Whether multiple third-party interests interact in-system.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017", "SRC-021" ] }, { "id": "f-multilateral-recognition-criteria-data02", "name": "Matching rule type", "description": "Non-discretionary, discretionary or bilateral.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017" ] }, { "id": "f-multilateral-recognition-criteria-data03", "name": "Recognition confidence", "description": "Agent confidence in class membership with method and times.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017", "SRC-018", "SRC-019", "SRC-021" ] }, { "id": "f-multilateral-recognition-criteria-data04", "name": "Exchange Act facility components", "description": "Premises, property rights and communication systems treated as exchange facilities.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-018" ] } ], "artifacts": [], "inline_only_rationale": "Recognition is a set of statutory and ontological tests (multilateral system, non-discretionary versus discretionary rules, bringing together purchasers and sellers, resulting in a contract). The answers are boolean and coded fields plus citations to the authorisation and rulebook artifacts owned by other findings, not a separate stored artefact type." }, { "id": "f-mic-code-lifecycle-and-dormancy", "name": "MIC lifecycle and operational dormancy", "description": "An allocated MIC is never altered and is not removed from the published list; it moves among ACTIVE, UPDATED and EXPIRED. Publication occurs on the second Monday of the month and modifications become effective on the fourth Monday. Separately, a CFTC DCM with no trading for twelve consecutive calendar months is dormant and must reinstate designation; newly designated DCMs have a 36-month grace period; vacated exchanges must reapply. These paths are not the same event.", "source_refs": [ "SRC-003", "SRC-009", "SRC-022", "SRC-023" ], "questions": [ { "id": "f-mic-code-lifecycle-and-dormancy-q01", "text": "What MIC-status transition is being recorded (creation, update of details, deactivation/expiry), who was entitled to request it, and what are the RA publication date and modification implementation date?", "kind": "lifecycle", "answer_data": [ "value_type: object", "transition_type, requester_role, publication_time, implementation_time as RFC 3339 with seconds and offset." ] }, { "id": "f-mic-code-lifecycle-and-dormancy-q02", "text": "Has trading occurred on this designated contract market in the last twelve consecutive calendar months, is the 36-month new-market grace still running, or has designation been vacated, and at what event-times?", "kind": "temporal", "answer_data": [ "value_type: object", "Booleans dormant, in_grace, vacated with last_trade_event_time, observation_time and supporting register URL." ] }, { "id": "f-mic-code-lifecycle-and-dormancy-q03", "text": "If this Dimension record is retired, will the MIC be tombstoned rather than hard-deleted, and which adopting-Dimension retention policy executes destruction of any extra local attributes?", "kind": "process", "answer_data": [ "value_type: object", "disposition in {tombstone, expire-in-register, retain}, policy_owner, retain_until." ] } ], "data_elements": [ { "id": "f-mic-code-lifecycle-and-dormancy-data01", "name": "MIC transition type", "description": "creation, update or deactivation.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003", "SRC-022" ] }, { "id": "f-mic-code-lifecycle-and-dormancy-data02", "name": "RA publication time", "description": "When the MIC list containing the change was published.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003", "SRC-022" ] }, { "id": "f-mic-code-lifecycle-and-dormancy-data03", "name": "Modification implementation time", "description": "When the MIC change becomes effective.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003", "SRC-022" ] }, { "id": "f-mic-code-lifecycle-and-dormancy-data04", "name": "Dormant or vacated flag", "description": "CFTC dormancy or vacation state.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] } ], "artifacts": [], "inline_only_rationale": "MIC status and dormancy are coded lifecycle fields on the register record and designation status. They are not independent document types; supporting notices are captured under authorisation artifacts and the MIC register extract." } ] }, { "id": "l-structure-rulebook-and-governance", "name": "Venue Structure, Rulebook and Governance", "description": "How the venue decomposes into segments and order books, which rulebook version governs it, and who holds operating authority, ownership and stewardship over the record.", "source_refs": [ "SRC-003", "SRC-011", "SRC-001", "SRC-009" ], "findings": [ { "id": "f-segment-and-order-book-hierarchy", "name": "Segment and order book hierarchy", "description": "The whole-part decomposition of the venue: operating market to market segments to order books, and the market-category classification attached at each level.", "source_refs": [ "SRC-003", "SRC-004", "SRC-011" ], "questions": [ { "id": "q-soh-1", "text": "Which segments and order books compose this venue, and which identifier is authoritative at each level?", "kind": "composition", "answer_data": [ "segment MIC list", "order book code list per segment", "level indicator (operating, segment, order book)" ] }, { "id": "q-soh-2", "text": "Which market-category classification applies to each segment, and under which scheme version?", "kind": "classification", "answer_data": [ "market category code", "classification scheme name and version", "jurisdiction or profile in which the classification is authoritative" ] }, { "id": "q-soh-3", "text": "How does an agent distinguish a segment of this venue from a separate venue operated by the same entity?", "kind": "definition", "answer_data": [ "operating-versus-segment test", "shared rulebook indicator", "separate authorisation indicator", "distinct order book indicator" ] } ], "data_elements": [ { "id": "de-segment-list", "name": "Segment membership", "description": "Ordered set of segment codes belonging to the operating market, each with its own category and status.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-order-book-code", "name": "Order book code", "description": "Venue-assigned code for an individual order book within a segment, used to scope order and trade records.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-market-category", "name": "Market category code", "description": "Registry-published category of the market or segment, carried with its scheme version.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [], "inline_only_rationale": "The hierarchy is pure structural reference data: a set of registry-assigned codes and their parent-child links, already carried by the venue identity artifact and the registry publication. Materialising a separate artifact would duplicate the ISO 10383 registry extract and create a second, divergent copy of codes whose assignment and retirement the registration authority owns." }, { "id": "f-rulebook-version-and-governance", "name": "Rulebook version, governance and conflicts disclosure", "description": "The governing rulebook and its version and effectivity, together with the venue's published governance arrangements, ownership and operator conflicts of interest.", "source_refs": [ "SRC-011", "SRC-009", "SRC-001", "SRC-002" ], "questions": [ { "id": "q-rvg-1", "text": "Which rulebook version governs trading at a given instant, and what was the immediately preceding version?", "kind": "temporal", "answer_data": [ "rulebook version identifier", "effective-from and effective-to timestamps", "superseded version reference", "change summary reference" ] }, { "id": "q-rvg-2", "text": "Which document or filing is the authoritative published statement of how this venue operates?", "kind": "evidence", "answer_data": [ "rulebook document reference", "public filing reference such as a Form ATS-N submission", "publication location", "publisher assertion" ] }, { "id": "q-rvg-3", "text": "Who owns the venue, who operates it, and which conflicts of interest are disclosed between operator, affiliates and participants?", "kind": "ownership", "answer_data": [ "owning entity reference", "operating entity reference", "affiliate list as references", "disclosed conflict statements", "mitigation measures declared" ] }, { "id": "q-rvg-4", "text": "Which role holds authority to change the rulebook, and which role merely stewards this model's record of it?", "kind": "authority", "answer_data": [ "rule-change authority role", "approval or non-objection body", "record steward role", "separation statement between rule authority and record stewardship" ] } ], "data_elements": [ { "id": "de-rulebook-version", "name": "Rulebook version identifier", "description": "Operator-assigned version label for the governing rulebook, with effectivity interval and supersession pointer.", "value_kind": "identifier", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-011", "SRC-009" ] }, { "id": "de-governance-disclosure", "name": "Governance and conflicts disclosure", "description": "Structured statement of ownership, governing board arrangements, affiliate activities and declared conflicts with mitigations.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011", "SRC-009", "SRC-001" ] }, { "id": "de-rule-change-authority", "name": "Rule-change authority", "description": "Role or body empowered to adopt or amend the rulebook, distinguished from the steward of this model's record.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-009", "SRC-002" ] } ], "artifacts": [ { "id": "a-rulebook-version", "name": "Rulebook version and governance disclosure", "description": "The versioned rulebook text plus the published operations and conflicts disclosure, retained as issued with its publication metadata and integrity digest.", "media_or_form": [ "versioned document", "public regulatory filing", "structured disclosure record" ], "serial": true, "identity_strategy": "Operator-assigned rulebook version label or the regulator's filing accession number as authoritative master-system identifier, with a monotonic version sequence; where neither exists an adopting-Dimension ULID is minted and the version label recorded as a descriptive qualifier.", "source_refs": [ "SRC-011", "SRC-009" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "b-participants-and-eligibility", "name": "Participants and Eligibility", "description": "Who may interact with the venue, on what criteria they were admitted, through which access channels they connect, what they are entitled to do, and what obligations they carry.", "rationale": "PFMI Principle 18 requires objective, risk-based and publicly disclosed participation criteria, and Principle 19 addresses tiered participation. MiFIR, REMIT and CFTC core principles each attach obligations to admitted participants. Admission is therefore an owned decision record of the venue, distinct from the participants' own entity identity.", "source_refs": [ "SRC-001", "SRC-006", "SRC-007", "SRC-009" ], "layers": [ { "id": "l-admission-and-membership", "name": "Admission and Membership", "description": "The participant's membership record, the eligibility criteria and admission decision that created it, and the states through which membership moves.", "source_refs": [ "SRC-001", "SRC-006", "SRC-007", "SRC-009" ], "findings": [ { "id": "f-participant-membership-record", "name": "Participant membership record", "description": "The venue's own record of an admitted participant: venue-assigned member code, category, trading capacities permitted, and the external identifiers that resolve the participant entity.", "source_refs": [ "SRC-004", "SRC-007", "SRC-010", "SRC-001" ], "questions": [ { "id": "q-pmr-1", "text": "Which venue-assigned code identifies this participant, and which external identifiers resolve the same party?", "kind": "identity", "answer_data": [ "venue member or participant code", "ISO 17442 LEI reference", "ACER registration code or other sector registration reference", "identifier precedence statement" ] }, { "id": "q-pmr-2", "text": "Which membership category and trading capacities does the participant hold on this venue?", "kind": "classification", "answer_data": [ "membership category code with scheme version", "permitted trading capacity values (dealing on own account, matched principal, any other capacity)", "clearing status (self-clearing, client of a clearing member, non-clearing)" ] }, { "id": "q-pmr-3", "text": "Which participants access the venue indirectly through another member, and how is that tier recorded?", "kind": "relationship", "answer_data": [ "sponsoring or general clearing member reference", "tier indicator", "direct electronic access flag", "underlying client identification where required" ] } ], "data_elements": [ { "id": "de-member-code", "name": "Venue member code", "description": "Identifier assigned by the venue to a participant, used to scope order, quote and trade records.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-004" ] }, { "id": "de-participant-entity-ref", "name": "Participant entity reference", "description": "Governed external identifier resolving the participant legal entity; reference data itself remains peer-owned.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-010", "SRC-007" ] }, { "id": "de-membership-category", "name": "Membership category and capacity", "description": "Category of membership and the trading capacities the participant may use, with the scheme version that defines them.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-004", "SRC-001" ] } ], "artifacts": [ { "id": "a-membership-record", "name": "Participant membership record", "description": "Governed record of a participant's standing on the venue, its category, capacities, tier relationships and external identifier references.", "media_or_form": [ "structured record" ], "serial": false, "identity_strategy": "Composite of the venue MIC and the venue-assigned member code as authoritative master-system identifiers; the participant LEI or sector registration code is carried as a governed global reference and never substituted for the venue code.", "source_refs": [ "SRC-004", "SRC-010" ] } ], "inline_only_rationale": null }, { "id": "f-eligibility-and-admission-decision", "name": "Eligibility criteria and admission decision", "description": "The published participation criteria, the evidence assessed, the admission or refusal decision, and the states through which membership subsequently moves including restriction, suspension and termination.", "source_refs": [ "SRC-001", "SRC-009", "SRC-002", "SRC-006" ], "questions": [ { "id": "q-ead-1", "text": "Which participation criteria applied at the time of the decision, and were they objective, risk-based and publicly disclosed?", "kind": "requirement", "answer_data": [ "criteria set reference with rulebook version", "criterion category (financial, operational, conduct, regulatory standing)", "public disclosure location" ] }, { "id": "q-ead-2", "text": "What decision was reached, by which role, on which evidence, and what recourse exists against it?", "kind": "decision", "answer_data": [ "decision outcome (admitted, refused, admitted with conditions)", "deciding role reference", "evidence item references", "appeal or review route reference" ] }, { "id": "q-ead-3", "text": "Which membership states are valid, and which evidenced event moves the participant between them?", "kind": "lifecycle", "answer_data": [ "state set (applied, admitted, active, restricted, suspended, terminated, resigned)", "transition event type", "effective timestamp and observation timestamp", "authorising role" ] }, { "id": "q-ead-4", "text": "Under what conditions may access be withdrawn immediately, and what safe state applies while the decision is pending?", "kind": "exception", "answer_data": [ "emergency withdrawal grounds", "interim measure applied (order cancellation, quote suspension, read-only access)", "notification obligations", "reinstatement conditions" ] } ], "data_elements": [ { "id": "de-eligibility-criterion", "name": "Eligibility criterion", "description": "A single published participation requirement with its category, source rulebook version and assessment outcome.", "value_kind": "object", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-001", "SRC-009" ] }, { "id": "de-admission-decision", "name": "Admission decision", "description": "Outcome, deciding role, effective interval and conditions attached to the participation decision.", "value_kind": "object", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-009" ] }, { "id": "de-membership-state", "name": "Membership state transition", "description": "Recorded transition between membership states with event time, observation time and triggering evidence reference.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-006" ] } ], "artifacts": [ { "id": "a-admission-decision-record", "name": "Admission and membership decision record", "description": "Dated record of criteria applied, evidence assessed, decision, conditions and subsequent state transitions, retained without destructive overwrite.", "media_or_form": [ "structured record", "decision document" ], "serial": true, "identity_strategy": "Venue-assigned application or decision reference as authoritative master-system identifier, sequenced per member code; superseded decisions are retained and linked rather than replaced.", "source_refs": [ "SRC-001", "SRC-009" ] } ], "inline_only_rationale": null } ] }, { "id": "l-access-and-obligations", "name": "Access Channels and Participant Obligations", "description": "The technical and contractual routes by which a participant reaches the venue, what each route is entitled to do, and the standing commitments the participant has accepted.", "source_refs": [ "SRC-004", "SRC-011", "SRC-006", "SRC-001" ], "findings": [ { "id": "f-access-channel-and-entitlements", "name": "Access channel and trading entitlements", "description": "The means of entry a participant uses - gateways, sessions, direct electronic access, sponsored access, colocation - and the segment, product and order-type entitlements attached to each.", "source_refs": [ "SRC-004", "SRC-011", "SRC-006" ], "questions": [ { "id": "q-ace-1", "text": "Through which access channels does this participant reach the venue, and which of them are sponsored or direct electronic access?", "kind": "access", "answer_data": [ "channel identifier (session, port, gateway)", "channel type (direct member, direct electronic access, sponsored access)", "colocation indicator", "sponsoring member reference" ] }, { "id": "q-ace-2", "text": "Which segments, order books, products and order types is each channel entitled to use?", "kind": "constraint", "answer_data": [ "entitled segment and order book codes", "entitled product scope reference", "permitted order types", "pre-trade risk limits applied at the channel" ] }, { "id": "q-ace-3", "text": "How is an order traced from the access channel back to the accountable member and decision maker?", "kind": "provenance", "answer_data": [ "submitting member code", "client identification code", "investment decision maker identifier", "execution decision maker identifier including algorithm identifier" ] }, { "id": "q-ace-4", "text": "What controls protect the venue when a channel misbehaves, and how is the intervention recorded?", "kind": "security", "answer_data": [ "throttle or message-rate control", "kill-switch or disconnect action", "order-cancellation-on-disconnect setting", "intervention event record reference" ] } ], "data_elements": [ { "id": "de-access-channel", "name": "Access channel", "description": "Identified route by which a participant submits instructions, with its type, sponsor and colocation status.", "value_kind": "object", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-004", "SRC-011" ] }, { "id": "de-entitlement-scope", "name": "Entitlement scope", "description": "The segments, order books, products and order types a channel or member may use, with any pre-trade limits.", "value_kind": "object", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-011", "SRC-006" ] }, { "id": "de-decision-maker-ref", "name": "Decision maker reference", "description": "Identifier of the person or algorithm responsible for the investment or execution decision, carried as a reference for attribution.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004" ] } ], "artifacts": [ { "id": "a-entitlement-profile", "name": "Access and entitlement profile", "description": "Versioned profile binding a participant's access channels to entitled scope, limits and protective controls, with effectivity intervals.", "media_or_form": [ "structured record", "configuration extract" ], "serial": true, "identity_strategy": "Composite of venue MIC, member code and venue-assigned channel identifier as authoritative master-system identifiers, with a monotonic revision sequence; effectivity intervals are attributes, not identifiers.", "source_refs": [ "SRC-004", "SRC-011" ] } ], "inline_only_rationale": null }, { "id": "f-liquidity-provision-commitments", "name": "Liquidity provision and market-making commitments", "description": "Standing obligations a participant has accepted - quoting presence, spread and size commitments, incentive schemes - and the terms under which they may be relieved.", "source_refs": [ "SRC-006", "SRC-004", "SRC-009", "SRC-011" ], "questions": [ { "id": "q-lpc-1", "text": "Which standing quoting obligations has this participant accepted, and for which instruments and phases?", "kind": "requirement", "answer_data": [ "scheme name and rulebook version", "instrument or class scope reference", "phases covered", "presence percentage, maximum spread and minimum size commitments" ] }, { "id": "q-lpc-2", "text": "How is compliance with the commitment measured, over what window, and against which threshold?", "kind": "measurement", "answer_data": [ "measurement method reference", "observation window", "measured value with unit", "threshold and pass or fail outcome" ] }, { "id": "q-lpc-3", "text": "Under which exceptional market conditions is the obligation suspended, and how is that declared?", "kind": "exception", "answer_data": [ "exceptional-circumstance definition reference", "declaration event with event time and observation time", "scope of relief", "end-of-relief event" ] }, { "id": "q-lpc-4", "text": "Which flag marks an order or trade as submitted under a liquidity provision activity?", "kind": "interoperability", "answer_data": [ "liquidity provision activity flag value", "field mapping to the venue's order record", "mapping to external reporting field" ] } ], "data_elements": [ { "id": "de-liquidity-commitment", "name": "Liquidity provision commitment", "description": "Structured statement of presence, spread and size obligations with the scheme and rulebook version that defines them.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006", "SRC-009" ] }, { "id": "de-liquidity-flag", "name": "Liquidity provision activity flag", "description": "Boolean marker indicating that an order or quote was entered under a liquidity provision obligation.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-commitment-measurement", "name": "Commitment compliance measurement", "description": "Observed compliance value with method, window, unit and confidence, recorded as an observation rather than an assertion of fact.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] } ], "artifacts": [ { "id": "a-liquidity-commitment-record", "name": "Liquidity provision commitment record", "description": "Record of the agreement or scheme adherence, its parameters, effectivity and relief declarations, with linked compliance observations.", "media_or_form": [ "structured record", "agreement document" ], "serial": true, "identity_strategy": "Venue-assigned scheme adherence reference as authoritative master-system identifier, keyed by member code and scheme, with a monotonic amendment sequence.", "source_refs": [ "SRC-006", "SRC-009" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "b-offer-and-demand", "name": "Offer and Demand", "description": "What may be traded on the venue, and the buying and selling interest expressed against it: orders, quotes and requests for quote, their attributes, their event sequence and the resulting order book state.", "rationale": "RTS 24 makes the trading venue the master of a defined order record and event sequence, and the REMIT implementing regulation imposes an equivalent order record on organised energy market places. These records are venue-owned market facts, distinct from the instrument reference data they point at.", "source_refs": [ "SRC-004", "SRC-008", "SRC-006", "SRC-012" ], "layers": [ { "id": "l-tradable-scope-and-intake", "name": "Tradable Scope and Interest Intake", "description": "The objects admitted to trading and the forms in which buying and selling interest is expressed against them.", "source_refs": [ "SRC-006", "SRC-008", "SRC-004", "SRC-011" ], "findings": [ { "id": "f-admission-of-tradable-objects", "name": "Admission of tradable objects to trading", "description": "The venue's decision to admit an instrument, product or contract to trading on a segment, with the trading parameters attached, and the termination of that admission.", "source_refs": [ "SRC-006", "SRC-008", "SRC-009" ], "questions": [ { "id": "q-ato-1", "text": "Which external identifier resolves the object admitted to trading, and which classification accompanies it?", "kind": "relationship", "answer_data": [ "instrument or product identifier reference such as ISIN or unique product identifier", "classification code with scheme version", "energy delivery point or zone code where applicable", "notional or price currency" ] }, { "id": "q-ato-2", "text": "From which instant is the object tradable on which segment, and when does admission terminate?", "kind": "temporal", "answer_data": [ "admission effective-from timestamp", "termination or expiry timestamp", "segment code", "observation timestamp of the admission fact" ] }, { "id": "q-ato-3", "text": "Which venue-specific trading parameters attach to the admission rather than to the object itself?", "kind": "constraint", "answer_data": [ "tick size or price step", "trading unit or lot size", "minimum and maximum order size", "price band or limit configuration", "applicable trading phases" ] }, { "id": "q-ato-4", "text": "Which product reference data must the venue supply before trading may commence, and to whom?", "kind": "requirement", "answer_data": [ "reference data field set", "recipient authority reference", "supply deadline relative to trading start", "update obligation on change" ] } ], "data_elements": [ { "id": "de-admitted-object-ref", "name": "Admitted object reference", "description": "Governed identifier of the instrument, product or contract admitted to trading; the object's own reference data is peer-owned.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-006", "SRC-008" ] }, { "id": "de-admission-interval", "name": "Admission validity interval", "description": "Effective start and end of tradability on a named segment, with event time and observation time distinguished.", "value_kind": "object", "cardinality": "1", "required": true, "source_refs": [ "SRC-006" ] }, { "id": "de-trading-parameters", "name": "Venue trading parameters", "description": "Tick size, lot size, order-size bounds, price bands and eligible phases that the venue attaches to the admission.", "value_kind": "object", "cardinality": "1", "required": true, "source_refs": [ "SRC-006", "SRC-009" ] } ], "artifacts": [ { "id": "a-admission-to-trading-record", "name": "Admission to trading record", "description": "Record of the admission decision, its segment, validity interval, venue trading parameters and the reference data supplied to authorities.", "media_or_form": [ "structured record", "reference data extract" ], "serial": true, "identity_strategy": "Composite of segment MIC and the venue's admission reference as authoritative master-system identifier, with the external object identifier as a governed global reference; admission versions are sequenced, never date-keyed.", "source_refs": [ "SRC-006", "SRC-008" ] } ], "inline_only_rationale": null }, { "id": "f-order-record-and-attributes", "name": "Order record and attributes", "description": "The full attribute set the venue must hold for each order: identification, party attribution, type and conditions, prices, quantities, capacity, validity and trading phase.", "source_refs": [ "SRC-004", "SRC-008", "SRC-012" ], "questions": [ { "id": "q-ora-1", "text": "Which identifiers make an order uniquely resolvable within the venue and across a reporting chain?", "kind": "identity", "answer_data": [ "order identification code", "segment MIC", "order book code", "strategy or parent order linking code", "external transaction reference where present" ] }, { "id": "q-ora-2", "text": "Which price and quantity attributes must be held, and how are undisclosed portions represented?", "kind": "measurement", "answer_data": [ "limit price, stop price, pegged price and currency", "initial, displayed and remaining quantity with notation", "minimum acceptable and minimum executable quantity", "undisclosed or reserve quantity" ] }, { "id": "q-ora-3", "text": "Which attributes express the order's conditions and intent rather than its economics?", "kind": "classification", "answer_data": [ "order type and venue-neutral classification (limit, stop, market, pegged)", "validity period type and restrictions", "buy or sell indicator", "passive or aggressive indicator", "self-execution prevention setting", "routing strategy" ] }, { "id": "q-ora-4", "text": "Which fields are mandatory for every order and which are conditional on the trading model?", "kind": "validation", "answer_data": [ "mandatory field list", "conditionality rule per field", "order-driven, quote-driven, hybrid or auction applicability", "rejection reason codes for missing fields" ] } ], "data_elements": [ { "id": "de-order-id", "name": "Order identification code", "description": "Venue-assigned code uniquely identifying an order within a segment and order book for its whole life.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-008" ] }, { "id": "de-order-price", "name": "Order price set", "description": "Limit, stop and pegged prices with explicit currency and price notation.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-order-quantity", "name": "Order quantity set", "description": "Initial, displayed, remaining, minimum acceptable and minimum executable quantities with the applicable notation and unit.", "value_kind": "quantity", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-004", "SRC-008" ] }, { "id": "de-order-conditions", "name": "Order type and conditions", "description": "Order type, classification, validity period, restrictions, side, capacity and self-execution prevention settings.", "value_kind": "object", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-012" ] } ], "artifacts": [ { "id": "a-order-record", "name": "Order record", "description": "The complete attribute set held for a single order, scoped to a segment and order book and attributed to a member and decision maker.", "media_or_form": [ "structured record", "tabular dataset" ], "serial": false, "identity_strategy": "Order identification code assigned by the venue's matching system as authoritative master-system identifier, scoped by segment MIC and order book code; no date or session label forms part of the key.", "source_refs": [ "SRC-004", "SRC-008" ] } ], "inline_only_rationale": null }, { "id": "f-quote-and-rfq-interest", "name": "Quotes, requests for quote and indications of interest", "description": "Non-order forms of trading interest used by quote-driven, request-for-quote and negotiated trading models, and how they differ from firm orders.", "source_refs": [ "SRC-006", "SRC-004", "SRC-005", "SRC-011" ], "questions": [ { "id": "q-qri-1", "text": "Which forms of trading interest does this venue accept besides firm orders, and how is each defined?", "kind": "definition", "answer_data": [ "interest form (two-sided quote, request for quote, response, indication of interest, negotiated interest)", "firmness (firm, indicative, actionable)", "addressability (public, targeted, bilateral within the venue)" ] }, { "id": "q-qri-2", "text": "Which timestamp granularity and clock tolerance applies to a request-for-quote or negotiated interest as opposed to an electronic order?", "kind": "temporal", "answer_data": [ "applicable divergence tolerance", "timestamp granularity", "trading model classification driving the tolerance" ] }, { "id": "q-qri-3", "text": "How is a quote's lifecycle bounded, and what happens on expiry, withdrawal or non-response?", "kind": "state", "answer_data": [ "quote state set", "expiry rule and validity duration", "withdrawal event", "non-response outcome" ] } ], "data_elements": [ { "id": "de-quote-record", "name": "Quote or request-for-quote record", "description": "Structured interest record with side or two-sided prices, size, firmness, addressee scope and validity.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006", "SRC-004" ] }, { "id": "de-interest-firmness", "name": "Interest firmness", "description": "Whether the interest is firm, actionable or indicative, governing whether it can bind on acceptance.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-006" ] }, { "id": "de-quote-clock-profile", "name": "Applicable clock profile", "description": "Divergence tolerance and granularity that apply given the trading model, recorded with the interest.", "value_kind": "object", "cardinality": "1", "required": true, "source_refs": [ "SRC-005" ] } ], "artifacts": [ { "id": "a-quote-and-rfq-record", "name": "Quote and request-for-quote record", "description": "Record of non-order trading interest with firmness, addressing, validity and the clock profile that applied.", "media_or_form": [ "structured record", "time-ordered event log" ], "serial": false, "identity_strategy": "Venue-assigned quote or negotiation identifier as authoritative master-system identifier, scoped by segment MIC; responses carry the originating request identifier as a governed reference.", "source_refs": [ "SRC-006", "SRC-004" ] } ], "inline_only_rationale": null } ] }, { "id": "l-order-lifecycle-and-book-state", "name": "Order Lifecycle and Book State", "description": "The evidenced sequence of events that changes an order's status, and the resulting priority and depth of the order book.", "source_refs": [ "SRC-004", "SRC-012", "SRC-005", "SRC-006" ], "findings": [ { "id": "f-order-event-sequence-and-status", "name": "Order event sequence and status", "description": "Each new order, modification, cancellation, rejection, expiry and execution, in a strictly sequenced record that preserves prior states rather than overwriting them.", "source_refs": [ "SRC-004", "SRC-012", "SRC-005" ], "questions": [ { "id": "q-oes-1", "text": "Which event types change an order's state, and which resulting status does each produce?", "kind": "event", "answer_data": [ "event type set (new, replaced, cancelled, rejected, expired, partially filled, filled, done for day, suspended, pending)", "resulting status value", "precedence rule where an order occupies more than one state" ] }, { "id": "q-oes-2", "text": "How is the ordering of events guaranteed when two events carry the same timestamp?", "kind": "process", "answer_data": [ "monotonic sequence number per order and per order book", "tie-break rule", "gap-detection rule" ] }, { "id": "q-oes-3", "text": "Which timestamps are recorded per event, and how are event time and ingestion time kept apart?", "kind": "temporal", "answer_data": [ "date and time of receipt", "date and time of the event itself", "priority assignment timestamp", "observation or ingestion timestamp", "timestamp granularity and clock divergence tolerance applied" ] }, { "id": "q-oes-4", "text": "How is a superseded order state preserved when an order is amended?", "kind": "provenance", "answer_data": [ "prior-version pointer", "amendment reason where captured", "immutability rule for emitted event records", "correction versus amendment distinction" ] } ], "data_elements": [ { "id": "de-order-event", "name": "Order event", "description": "Single evidenced change to an order, carrying event type, resulting status, sequence number, event time and ingestion time.", "value_kind": "object", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-004", "SRC-012" ] }, { "id": "de-sequence-number", "name": "Event sequence number", "description": "Monotonically increasing number establishing deterministic order of events within the order book.", "value_kind": "number", "cardinality": "1", "required": true, "source_refs": [ "SRC-004" ] }, { "id": "de-order-status", "name": "Order status", "description": "Current status of the order after the event, using the venue's status vocabulary mapped to a venue-neutral state model.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-012", "SRC-004" ] } ], "artifacts": [ { "id": "a-order-event-log", "name": "Order event log", "description": "Append-only, sequenced log of all order events for a segment and order book, retained as the venue's own operational market record.", "media_or_form": [ "time-ordered event log", "tabular dataset" ], "serial": true, "identity_strategy": "Composite of segment MIC, order book code, order identification code and the venue's monotonic event sequence number as authoritative master-system identifiers; trading-day labels appear only as descriptive partition qualifiers, never as the key.", "source_refs": [ "SRC-004", "SRC-005" ] } ], "inline_only_rationale": null }, { "id": "f-order-book-state-and-priority", "name": "Order book state and priority", "description": "The composition of resting interest at a point in time, the priority each order holds, and the depth published or retained for reconstruction.", "source_refs": [ "SRC-004", "SRC-006", "SRC-011" ], "questions": [ { "id": "q-obs-1", "text": "What determines an order's position in the queue, and which attribute records it?", "kind": "constraint", "answer_data": [ "priority timestamp", "priority size where a size-time model applies", "priority rule reference (price-time, pro-rata, size-time, other)", "re-prioritisation triggers on amendment" ] }, { "id": "q-obs-2", "text": "What exactly does a book state record capture, and is it a snapshot or a derived reconstruction?", "kind": "quality", "answer_data": [ "snapshot versus reconstruction indicator", "depth levels covered", "aggregation level (per order, per price level)", "reconstruction method reference and confidence" ] }, { "id": "q-obs-3", "text": "Which parts of the book are displayed to participants and which are not?", "kind": "access", "answer_data": [ "displayed versus non-displayed quantity", "segmentation or counterparty-selection restrictions", "recipient class per view", "waiver reference where pre-trade display is not required" ] } ], "data_elements": [ { "id": "de-priority-attributes", "name": "Priority attributes", "description": "Priority timestamp and, where a size-time model applies, priority size determining queue position.", "value_kind": "object", "cardinality": "1", "required": true, "source_refs": [ "SRC-004" ] }, { "id": "de-book-depth", "name": "Book depth entry", "description": "Aggregated or per-order resting interest at a price level, with displayed and non-displayed quantities distinguished.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006", "SRC-011" ] }, { "id": "de-book-derivation", "name": "Book state derivation flag", "description": "Marker distinguishing a captured snapshot from a state reconstructed from the event log, with method and confidence.", "value_kind": "object", "cardinality": "1", "required": true, "source_refs": [ "SRC-004" ] } ], "artifacts": [ { "id": "a-order-book-snapshot", "name": "Order book state record", "description": "Point-in-time record of resting interest and priority for one order book, marked as captured or reconstructed with its method.", "media_or_form": [ "structured record", "tabular dataset" ], "serial": true, "identity_strategy": "Composite of segment MIC, order book code and the venue's snapshot sequence number as authoritative master-system identifiers; the capture instant is an attribute, not the identifier.", "source_refs": [ "SRC-004", "SRC-006" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "b-matching-and-price-discovery", "name": "Matching and Price Discovery", "description": "How the venue converts resting interest into trades and prices: trading phases and calendar, matching algorithm and priority, volatility controls, official and indicative prices, and the transparency the venue must publish.", "rationale": "IOSCO Principles 33-37 require fair and transparent trading rules; MiFIR Articles 3-13 and RTS 1 set pre- and post-trade transparency with waivers, deferrals and flags; CFTC core principles require execution of transactions, daily publication of trading information and prevention of market disruption. Price formation is the venue's defining function and is owned here.", "source_refs": [ "SRC-002", "SRC-006", "SRC-015", "SRC-009", "SRC-011" ], "layers": [ { "id": "l-phases-and-matching", "name": "Trading Phases and Matching Rules", "description": "When the venue trades, in which phase, and by which deterministic or disclosed rules interest is matched.", "source_refs": [ "SRC-004", "SRC-011", "SRC-006", "SRC-009" ], "findings": [ { "id": "f-session-calendar-and-phases", "name": "Trading calendar, sessions and phases", "description": "The venue's operating calendar and the named phases within a session, including pre-open, auctions, continuous trading, close and out-of-hours trading.", "source_refs": [ "SRC-004", "SRC-011", "SRC-009" ], "questions": [ { "id": "q-scp-1", "text": "Which named phases exist in a session, and in which order do they run for each segment?", "kind": "process", "answer_data": [ "phase name set", "phase ordering per segment", "phase start and end rules including randomised endings", "phase applicability by product class" ] }, { "id": "q-scp-2", "text": "Which days are trading days for this venue, and which are holidays or partial sessions?", "kind": "temporal", "answer_data": [ "trading day calendar", "holiday exclusions", "partial session definitions", "reference time zone and offset handling across daylight changes" ] }, { "id": "q-scp-3", "text": "How does the venue treat activity outside regular trading hours?", "kind": "constraint", "answer_data": [ "out-of-hours availability indicator", "permitted order and interest types outside hours", "transparency treatment of out-of-hours activity" ] }, { "id": "q-scp-4", "text": "Which phase was in force when a given order event or trade occurred?", "kind": "evidence", "answer_data": [ "trading phase name recorded on the event", "phase transition event reference", "authority or automatic trigger for the transition" ] } ], "data_elements": [ { "id": "de-trading-phase", "name": "Trading phase", "description": "Named phase with ordering, start and end rules and product applicability, recorded on order and trade events.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-004", "SRC-011" ] }, { "id": "de-trading-calendar", "name": "Trading calendar entry", "description": "Trading day, holiday or partial-session designation for a segment, with the reference time zone.", "value_kind": "object", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-009", "SRC-011" ] } ], "artifacts": [ { "id": "a-trading-calendar", "name": "Trading calendar and phase schedule", "description": "Published schedule of trading days, session times and phase sequences per segment, versioned and effective-dated.", "media_or_form": [ "structured record", "published schedule document" ], "serial": true, "identity_strategy": "Composite of segment MIC and the venue's calendar version reference as authoritative master-system identifier, with a monotonic revision sequence; calendar year appears only inside the payload, never in the key.", "source_refs": [ "SRC-011", "SRC-009" ] } ], "inline_only_rationale": null }, { "id": "f-matching-algorithm-and-priority", "name": "Matching algorithm and priority rules", "description": "The rule by which the venue pairs interest and allocates fills, whether execution is non-discretionary, and where operator discretion is permitted and disclosed.", "source_refs": [ "SRC-011", "SRC-006", "SRC-009", "SRC-002" ], "questions": [ { "id": "q-map-1", "text": "Which matching algorithm applies to each order book and phase, and how are fills allocated?", "kind": "definition", "answer_data": [ "algorithm name (price-time, pro-rata, size-time, allocation with priority tier, auction uncrossing)", "allocation formula reference", "minimum allocation and residual handling", "phase applicability" ] }, { "id": "q-map-2", "text": "Is execution non-discretionary, and where discretion exists, how is it constrained and disclosed?", "kind": "authority", "answer_data": [ "non-discretionary indicator", "permitted discretion type", "constraint on discretion", "public disclosure location" ] }, { "id": "q-map-3", "text": "Which orders may not match each other, and why?", "kind": "constraint", "answer_data": [ "self-execution prevention rule", "segmentation or counterparty-selection rule", "eligibility mismatch conditions", "resulting action (cancel resting, cancel incoming, cancel both, decrement)" ] }, { "id": "q-map-4", "text": "How would an independent party verify that a published fill followed the stated algorithm?", "kind": "validation", "answer_data": [ "reconstruction input set (order events, book state, phase)", "determinism assumptions", "known non-deterministic elements such as randomised auction endings", "tolerance for verification" ] } ], "data_elements": [ { "id": "de-matching-algorithm", "name": "Matching algorithm specification", "description": "Named algorithm with its allocation rule, phase applicability and rulebook version reference.", "value_kind": "object", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-011", "SRC-009" ] }, { "id": "de-discretion-scope", "name": "Operator discretion scope", "description": "Whether and how the operator may exercise discretion over placement or matching, with its disclosure reference.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006", "SRC-011" ] }, { "id": "de-interaction-restriction", "name": "Interaction restriction", "description": "Rule preventing specific interests from matching, with the action taken when the restriction bites.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004", "SRC-011" ] } ], "artifacts": [ { "id": "a-matching-rule-specification", "name": "Matching rule specification", "description": "Versioned statement of matching algorithm, allocation, discretion scope and interaction restrictions per order book and phase.", "media_or_form": [ "versioned document", "structured record" ], "serial": true, "identity_strategy": "Composite of segment MIC, order book code and rulebook version identifier as authoritative master-system identifiers, with a monotonic specification revision sequence.", "source_refs": [ "SRC-011", "SRC-009" ] } ], "inline_only_rationale": null } ] }, { "id": "l-price-formation-and-transparency", "name": "Price Formation and Transparency", "description": "Controls that interrupt or constrain price formation, the prices the venue itself produces, and the pre- and post-trade information it must publish.", "source_refs": [ "SRC-006", "SRC-015", "SRC-009", "SRC-002" ], "findings": [ { "id": "f-volatility-controls-and-halts", "name": "Volatility controls and trading halts", "description": "Price bands, circuit breakers, auction extensions, suspensions and emergency interventions that constrain or stop trading, and the events that record them.", "source_refs": [ "SRC-009", "SRC-006", "SRC-011", "SRC-002" ], "questions": [ { "id": "q-vch-1", "text": "Which automatic controls constrain price movement, and against which reference price are they measured?", "kind": "constraint", "answer_data": [ "control type (static band, dynamic band, circuit breaker, auction extension)", "reference price basis", "threshold value and unit", "action on breach" ] }, { "id": "q-vch-2", "text": "Which halt and suspension states exist, and what evidence records entry to and exit from each?", "kind": "state", "answer_data": [ "state set (trading, limit state, auction extension, halted, suspended, closed)", "triggering event with event time and observation time", "resumption event", "authorising role or automatic trigger" ] }, { "id": "q-vch-3", "text": "Under what emergency authority may the operator intervene beyond the automatic controls, and how is that recorded?", "kind": "authority", "answer_data": [ "emergency authority basis in the rulebook or regulation", "permitted interventions", "notification obligations", "intervention record reference" ] }, { "id": "q-vch-4", "text": "What is the safe state when the matching system itself fails, and how is participant interest treated?", "kind": "exception", "answer_data": [ "declared safe state", "treatment of resting orders (retained, cancelled, cancel-on-disconnect)", "participant notification route", "recovery and reconciliation procedure reference" ] } ], "data_elements": [ { "id": "de-volatility-control", "name": "Volatility control configuration", "description": "Control type, reference price basis, threshold and breach action per instrument or class and phase.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009", "SRC-006" ] }, { "id": "de-halt-event", "name": "Halt or suspension event", "description": "Evidenced entry to or exit from a halted, limit or suspended state with cause, authorising role, event time and observation time.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009", "SRC-002" ] } ], "artifacts": [ { "id": "a-halt-and-control-event-record", "name": "Halt and volatility control event record", "description": "Sequenced record of control breaches, halts, suspensions, emergency interventions and resumptions, with cause and authority.", "media_or_form": [ "time-ordered event log", "structured record" ], "serial": true, "identity_strategy": "Composite of segment MIC, affected object reference and the venue's intervention sequence number as authoritative master-system identifiers; the event instant is an attribute rather than the key.", "source_refs": [ "SRC-009", "SRC-002" ] } ], "inline_only_rationale": null }, { "id": "f-official-and-indicative-prices", "name": "Official and indicative prices", "description": "Prices the venue itself produces - indicative auction price and volume, opening, closing and settlement prices - together with the method, inputs and status of each.", "source_refs": [ "SRC-004", "SRC-009", "SRC-006", "SRC-008" ], "questions": [ { "id": "q-oip-1", "text": "Which official prices does this venue produce, and by which published method is each derived?", "kind": "measurement", "answer_data": [ "price kind (indicative auction, opening, closing, settlement, reference)", "derivation method reference", "input window and input set", "currency and price notation" ] }, { "id": "q-oip-2", "text": "What is the status of a published price, and how is a provisional value distinguished from a final one?", "kind": "quality", "answer_data": [ "status value (indicative, provisional, final, corrected)", "correction pointer to the superseded value", "confidence or quality qualifier where the method permits fallback" ] }, { "id": "q-oip-3", "text": "When was the price effective, and when was it published and observed?", "kind": "temporal", "answer_data": [ "price effective instant or reference period", "publication timestamp", "observation or ingestion timestamp" ] }, { "id": "q-oip-4", "text": "Where a downstream benchmark or index consumes this price, what does the venue assert and what does it not?", "kind": "interoperability", "answer_data": [ "assertion scope statement", "benchmark administrator reference", "disclaimer that benchmark methodology and governance are peer-owned" ] } ], "data_elements": [ { "id": "de-official-price", "name": "Official price value", "description": "Numeric price with currency, notation and the price kind it represents.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009", "SRC-006" ] }, { "id": "de-price-method", "name": "Price derivation method", "description": "Reference to the published method, its input window and any fallback applied on the occasion.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-009" ] }, { "id": "de-price-status", "name": "Price status", "description": "Indicative, provisional, final or corrected status, with a pointer to any value it supersedes.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-015" ] } ], "artifacts": [ { "id": "a-official-price-record", "name": "Official and indicative price record", "description": "Record of each price the venue publishes, with kind, method, inputs, status, effective instant and publication instant.", "media_or_form": [ "structured record", "tabular dataset" ], "serial": true, "identity_strategy": "Composite of segment MIC, admitted object reference, price kind and the venue's publication sequence number as authoritative master-system identifiers; corrections are new sequence entries linked to the superseded one.", "source_refs": [ "SRC-009", "SRC-004" ] } ], "inline_only_rationale": null }, { "id": "f-pre-and-post-trade-transparency", "name": "Pre- and post-trade transparency, waivers, deferrals and market data terms", "description": "What the venue must make public before and after trading, the waivers and deferrals that modify it, the flags that qualify a publication, and the terms on which market data is supplied.", "source_refs": [ "SRC-006", "SRC-015", "SRC-009", "SRC-002" ], "questions": [ { "id": "q-ptt-1", "text": "Which pre-trade information must be made public, and which waiver removes or limits that duty?", "kind": "requirement", "answer_data": [ "pre-trade field set (current bid and offer, depth of trading interest)", "waiver type (reference price, negotiated, large in scale, order management facility)", "granting authority reference", "waiver validity interval" ] }, { "id": "q-ptt-2", "text": "Which fields constitute a post-trade publication, and which flags qualify it?", "kind": "interoperability", "answer_data": [ "trading date and time", "instrument identification code", "price and price currency", "quantity", "venue of execution", "publication date and time", "transaction identification code", "flag set including benchmark, agency cross, non-price-forming, negotiated, special dividend, large in scale, cancellation and amendment" ] }, { "id": "q-ptt-3", "text": "Under what conditions may publication be deferred, and when does the deferred detail become public?", "kind": "temporal", "answer_data": [ "deferral ground", "deferral duration or trigger", "aggregated versus full publication during deferral", "final publication instant" ] }, { "id": "q-ptt-4", "text": "On what terms is market data supplied, and how is non-discriminatory access evidenced?", "kind": "access", "answer_data": [ "data product definition", "pricing and licensing terms reference", "recipient class and entitlement", "non-discrimination statement and its disclosure location", "latency or delay applied per product" ] } ], "data_elements": [ { "id": "de-transparency-publication", "name": "Transparency publication", "description": "Published pre- or post-trade record with its full field set and qualifying flags.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-015", "SRC-006" ] }, { "id": "de-waiver-or-deferral", "name": "Waiver or deferral binding", "description": "The waiver or deferral applied, its granting authority, scope and validity interval.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "de-market-data-terms", "name": "Market data product terms", "description": "Product definition, entitlement class, delay and commercial terms under which venue data is supplied.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006", "SRC-002" ] } ], "artifacts": [ { "id": "a-transparency-publication-record", "name": "Transparency publication record", "description": "Retained record of each pre- and post-trade publication with its fields, flags, deferral status and the market data product through which it was distributed.", "media_or_form": [ "structured record", "published data feed extract" ], "serial": true, "identity_strategy": "Transaction identification code assigned by the venue as authoritative master-system identifier for post-trade records, scoped by segment MIC; amendments and cancellations are new records carrying the original code plus a correction sequence.", "source_refs": [ "SRC-015", "SRC-006" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "b-execution-and-settlement", "name": "Execution and Settlement Handoff", "description": "The trade event the venue records when interest matches, its correction and supersession, and the disciplined handoff of the trade to the clearing and settlement infrastructures that own post-trade semantics.", "rationale": "The venue masters the executed-trade event and its corrections. PFMI assigns settlement finality, netting, margin, default rules and delivery to the FMI, so this bundle carries only the binding and the terms asserted at execution plus downstream status as an observation.", "source_refs": [ "SRC-015", "SRC-001", "SRC-009", "SRC-008" ], "layers": [ { "id": "l-trade-execution-record", "name": "Trade Execution Record", "description": "The venue's authoritative record of an executed trade and of any correction, cancellation or supersession of it.", "source_refs": [ "SRC-015", "SRC-004", "SRC-009" ], "findings": [ { "id": "f-executed-trade-event", "name": "Executed trade event", "description": "The market event created when interest matches: identifiers, economics, timing, attribution to orders and members, capacity, and the venue of execution.", "source_refs": [ "SRC-015", "SRC-004", "SRC-008", "SRC-009" ], "questions": [ { "id": "q-ete-1", "text": "Which identifier is authoritative for the trade, and which order and member records does it link back to?", "kind": "identity", "answer_data": [ "transaction identification code", "segment MIC as venue of execution", "contributing order identification codes", "member codes for each side", "client identification where required" ] }, { "id": "q-ete-2", "text": "Which economic terms does the venue assert at execution?", "kind": "definition", "answer_data": [ "price and price currency", "quantity and unit or notation", "side attribution", "trading capacity per side", "delivery point, zone and delivery period for physical or energy products" ] }, { "id": "q-ete-3", "text": "Which timestamps must be recorded, and at which granularity?", "kind": "temporal", "answer_data": [ "execution or trading timestamp with granularity", "publication timestamp", "observation or ingestion timestamp", "applied clock divergence tolerance" ] }, { "id": "q-ete-4", "text": "What does the venue assert about the trade, and what does it explicitly not assert?", "kind": "provenance", "answer_data": [ "asserted facts (match occurred, terms as matched, phase and algorithm applied)", "non-asserted matters (contract formation, obligation performance, settlement finality)", "asserting role and rulebook version" ] } ], "data_elements": [ { "id": "de-trade-id", "name": "Transaction identification code", "description": "Venue-assigned code uniquely identifying the executed trade for publication and downstream reference.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-015", "SRC-008" ] }, { "id": "de-trade-economics", "name": "Trade economic terms", "description": "Price, currency, quantity, unit, side and, for physical products, delivery point and period as matched.", "value_kind": "object", "cardinality": "1", "required": true, "source_refs": [ "SRC-015", "SRC-008" ] }, { "id": "de-trade-timing", "name": "Trade timing set", "description": "Execution instant, publication instant and observation instant, each with explicit offset and recorded granularity.", "value_kind": "timestamp", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-015", "SRC-005" ] } ], "artifacts": [ { "id": "a-trade-execution-record", "name": "Trade execution record", "description": "The venue's authoritative record of a matched trade, linking contributing orders, members, economics, timings and the phase and algorithm under which it occurred.", "media_or_form": [ "structured record", "time-ordered event log" ], "serial": false, "identity_strategy": "Transaction identification code assigned by the venue's matching system as authoritative master-system identifier, scoped by segment MIC; no trading-day component forms part of the key.", "source_refs": [ "SRC-015", "SRC-004" ] } ], "inline_only_rationale": null }, { "id": "f-trade-correction-and-supersession", "name": "Trade correction, cancellation and supersession", "description": "How an erroneous or invalidated trade is amended or cancelled without destroying history, including the venue's error-trade policy and the flags that mark the change publicly.", "source_refs": [ "SRC-015", "SRC-009", "SRC-011" ], "questions": [ { "id": "q-tcs-1", "text": "On what grounds may the venue amend or cancel an executed trade, and within what window?", "kind": "exception", "answer_data": [ "error-trade policy reference and rulebook version", "eligible grounds", "review window duration", "deciding role and any counterparty consent requirement" ] }, { "id": "q-tcs-2", "text": "How is the original trade preserved when a correction is issued?", "kind": "lifecycle", "answer_data": [ "original record retained flag", "correction record with pointer to the superseded record", "correction sequence number", "status of the original after correction" ] }, { "id": "q-tcs-3", "text": "Which flag signals a cancellation or amendment to consumers of the venue's published data?", "kind": "interoperability", "answer_data": [ "cancellation flag value", "amendment flag value", "republication rule", "downstream notification route" ] }, { "id": "q-tcs-4", "text": "What evidence supports a cancellation decision, and how long must it be retained?", "kind": "evidence", "answer_data": [ "evidence item references", "deciding role", "decision record reference", "applicable retention parameter" ] } ], "data_elements": [ { "id": "de-correction-record", "name": "Trade correction record", "description": "Correction or cancellation with grounds, deciding role, superseded record pointer and correction sequence.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-015", "SRC-009" ] }, { "id": "de-correction-flag", "name": "Publication correction flag", "description": "Flag applied to republished data marking a cancellation or amendment of a previously published trade.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-015" ] } ], "artifacts": [ { "id": "a-trade-correction-record", "name": "Trade correction and cancellation record", "description": "Non-destructive record of each amendment or cancellation, linked to the superseded trade record and to the supporting decision evidence.", "media_or_form": [ "structured record", "decision document" ], "serial": true, "identity_strategy": "Original transaction identification code as authoritative master-system identifier plus a monotonic correction sequence number; the superseded record is retained and linked, never overwritten.", "source_refs": [ "SRC-015", "SRC-009" ] } ], "inline_only_rationale": null } ] }, { "id": "l-clearing-and-settlement-handoff", "name": "Clearing and Settlement Handoff", "description": "The binding between an executed trade and the infrastructures that will clear and settle it, and the observed downstream status, without absorbing post-trade semantics.", "source_refs": [ "SRC-001", "SRC-009", "SRC-011", "SRC-008" ], "findings": [ { "id": "f-clearing-arrangement-binding", "name": "Clearing arrangement binding", "description": "Which clearing arrangement applies to a trade executed on this venue, which clearing member and infrastructure it routes to, and what the venue asserts about that routing.", "source_refs": [ "SRC-001", "SRC-009", "SRC-011" ], "questions": [ { "id": "q-cab-1", "text": "Which clearing arrangement applies to a trade on this segment, and which infrastructure is named?", "kind": "relationship", "answer_data": [ "clearing model (central counterparty cleared, bilateral, non-cleared)", "central counterparty reference", "clearing member reference per side", "interoperable link reference where more than one infrastructure is available" ] }, { "id": "q-cab-2", "text": "At what point does the venue's responsibility end and the clearing infrastructure's begin?", "kind": "authority", "answer_data": [ "handoff event definition", "venue assertion scope", "explicit statement that novation, netting, margin, default management and settlement finality are peer-owned" ] }, { "id": "q-cab-3", "text": "Which pre-execution checks does the venue perform on clearing eligibility, and what happens on failure?", "kind": "validation", "answer_data": [ "clearing eligibility check description", "failure outcome (rejection, hold, non-cleared routing)", "record of the failed check" ] } ], "data_elements": [ { "id": "de-clearing-model", "name": "Clearing model", "description": "Coded statement of how trades on this segment are cleared, with the scheme version that defines the values.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-011" ] }, { "id": "de-clearing-infrastructure-ref", "name": "Clearing infrastructure reference", "description": "Reference to the central counterparty or clearing member; that entity's rules and risk semantics remain peer-owned.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [], "inline_only_rationale": "This finding is deliberately a pure reference binding. PFMI assigns novation, netting, margin, collateral, participant-default rules, segregation, portability and settlement finality to the financial market infrastructure. Materialising a clearing artifact here would create a second, unauthoritative copy of the infrastructure's own records and invite an agent to treat venue-held data as evidence of clearing outcomes. The venue holds only coded model values and external references, which are carried inside the trade execution and settlement handoff artifacts." }, { "id": "f-settlement-terms-and-downstream-observation", "name": "Settlement terms asserted and downstream status observed", "description": "The settlement or delivery terms the venue asserts at execution, and any downstream status the venue later observes, recorded strictly as an observation with its source and confidence.", "source_refs": [ "SRC-001", "SRC-008", "SRC-009" ], "questions": [ { "id": "q-sto-1", "text": "Which settlement or delivery terms does the venue assert at the moment of execution?", "kind": "requirement", "answer_data": [ "intended settlement date or delivery period", "place of settlement or delivery point reference", "settlement currency", "delivery type (cash, physical) where applicable" ] }, { "id": "q-sto-2", "text": "When the venue records a downstream status, what marks it as an observation rather than an authoritative fact?", "kind": "quality", "answer_data": [ "observation source reference", "observation timestamp distinct from the underlying event timestamp", "confidence or reliability qualifier", "statement that the peer infrastructure holds the authoritative status" ] }, { "id": "q-sto-3", "text": "How is a conflict between the venue's asserted terms and the peer infrastructure's record resolved?", "kind": "exception", "answer_data": [ "conflict detection rule", "precedence rule naming the peer as authoritative", "exception record reference", "correction route in this model" ] }, { "id": "q-sto-4", "text": "Which downstream statuses are meaningful to record here, and which must never be inferred?", "kind": "constraint", "answer_data": [ "recordable status list (accepted for clearing, matched downstream, failed to reach clearing)", "prohibited inferences (settled, final, discharged)", "rationale for the prohibition" ] } ], "data_elements": [ { "id": "de-settlement-terms", "name": "Asserted settlement terms", "description": "Intended settlement date, place, currency and delivery specification as asserted by the venue at execution.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008", "SRC-001" ] }, { "id": "de-downstream-observation", "name": "Downstream status observation", "description": "Observed downstream status with its source reference, observation timestamp and confidence qualifier.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [ { "id": "a-settlement-handoff-record", "name": "Settlement handoff record", "description": "Record of the settlement terms asserted at execution and of any downstream status observations, each labelled with its source and confidence.", "media_or_form": [ "structured record" ], "serial": false, "identity_strategy": "Transaction identification code of the executed trade as authoritative master-system identifier, with observation entries sequenced; the peer infrastructure's own reference is carried as a governed external reference and never used as this record's key.", "source_refs": [ "SRC-001", "SRC-008" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "b-integrity-and-oversight", "name": "Market Integrity and Oversight", "description": "The conduct rules that apply on the venue, the surveillance arrangements the venue declares, the records and clock traceability it must retain, and the exceptions, disputes and referrals it raises.", "rationale": "IOSCO Principles 33-37, MiFIR, REMIT and CFTC core principles all place monitoring, recordkeeping, disciplinary procedures and dispute resolution on the venue. This bundle carries the venue's declarations, parameters and referral pointers; evaluation, investigation, adjudication and enforcement remain with peer models.", "source_refs": [ "SRC-002", "SRC-006", "SRC-007", "SRC-009", "SRC-014" ], "layers": [ { "id": "l-conduct-and-surveillance", "name": "Conduct Rules and Surveillance Arrangements", "description": "The prohibitions and disclosure duties applying on the venue, and the monitoring arrangements the venue declares without owning their execution.", "source_refs": [ "SRC-007", "SRC-009", "SRC-002", "SRC-014" ], "findings": [ { "id": "f-market-conduct-rule-set", "name": "Market conduct rule set and disclosure duties", "description": "The prohibitions on insider dealing and manipulation applicable at this venue, the disclosure duties placed on participants, and the rulebook version in which they sit.", "source_refs": [ "SRC-007", "SRC-009", "SRC-002", "SRC-014" ], "questions": [ { "id": "q-mcr-1", "text": "Which conduct prohibitions apply to activity on this venue, and from which instrument do they derive?", "kind": "requirement", "answer_data": [ "prohibition category (insider dealing, unlawful disclosure, market manipulation, attempted manipulation)", "legal or rulebook source reference", "jurisdiction and validity interval" ] }, { "id": "q-mcr-2", "text": "Which inside-information disclosure duty applies to participants, and what role does the venue play in it?", "kind": "process", "answer_data": [ "disclosure duty scope", "venue role (publication platform, recipient, none)", "permitted delay conditions", "publication location reference" ] }, { "id": "q-mcr-3", "text": "How does an agent tell whether a conduct rule is a venue rule or a statutory rule the venue merely restates?", "kind": "authority", "answer_data": [ "rule origin indicator (venue rulebook, statute, regulator instrument)", "amending authority", "precedence where they differ" ] }, { "id": "q-mcr-4", "text": "Which version of the conduct rule set applied to a given event?", "kind": "temporal", "answer_data": [ "rule set version identifier", "effective-from and effective-to timestamps", "event timestamp used for the match" ] } ], "data_elements": [ { "id": "de-conduct-rule", "name": "Conduct rule reference", "description": "Prohibition or duty with its origin, source instrument reference, jurisdiction and validity interval.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-007", "SRC-009" ] }, { "id": "de-disclosure-duty", "name": "Inside information disclosure duty", "description": "Scope of the participant disclosure obligation and the venue's declared role in receiving or publishing it.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] } ], "artifacts": [], "inline_only_rationale": "The conduct rule set is a set of references into instruments and rulebook versions that are already retained as artifacts elsewhere: the statutes are external authoritative texts owned by their publishers, and the venue's own restatement lives inside the versioned rulebook artifact. Creating a separate artifact would duplicate governed text, risk drift from the authoritative source, and imply that this model publishes conduct rules rather than pointing at them." }, { "id": "f-surveillance-arrangement-and-referral", "name": "Declared surveillance arrangement and referral pointer", "description": "The monitoring arrangement the venue declares - scope, coverage and responsible function - and the reference by which a matter is handed to the investigating or enforcing body.", "source_refs": [ "SRC-002", "SRC-009", "SRC-006", "SRC-014" ], "questions": [ { "id": "q-sar-1", "text": "What monitoring arrangement does the venue declare, over which activity, and which function operates it?", "kind": "definition", "answer_data": [ "arrangement description and coverage scope", "monitored activity classes", "responsible function reference", "whether monitoring is in-house or outsourced with the provider reference" ] }, { "id": "q-sar-2", "text": "By which reference is a matter handed to an investigating or enforcing body, and what does this model retain?", "kind": "relationship", "answer_data": [ "referral reference identifier", "recipient authority or peer case model reference", "referral timestamp and observation timestamp", "explicit statement that alert evaluation, investigation, adjudication and sanctions are peer-owned" ] }, { "id": "q-sar-3", "text": "Which surveillance details must not be disclosed, and to whom may the arrangement be described?", "kind": "privacy", "answer_data": [ "non-disclosable elements (thresholds, detection logic, open matters)", "permitted recipient classes", "minimum-disclosure description available publicly", "legal basis for withholding" ] }, { "id": "q-sar-4", "text": "How does the venue evidence that the declared arrangement was in force at a given time?", "kind": "evidence", "answer_data": [ "arrangement version identifier", "effective interval", "attesting role", "review or assurance record reference" ] } ], "data_elements": [ { "id": "de-surveillance-arrangement", "name": "Declared surveillance arrangement", "description": "Versioned description of monitoring scope, coverage, responsible function and outsourcing, without detection logic.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-009" ] }, { "id": "de-referral-pointer", "name": "Referral pointer", "description": "Identifier and recipient of a matter referred out, with referral and observation timestamps; the case itself is peer-owned.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006", "SRC-009" ] } ], "artifacts": [ { "id": "a-surveillance-arrangement-description", "name": "Surveillance arrangement description", "description": "Versioned, disclosure-controlled description of the venue's monitoring arrangement and its referral routes, holding no detection thresholds and no case content.", "media_or_form": [ "versioned document", "structured record" ], "serial": true, "identity_strategy": "Composite of venue MIC and the venue's arrangement version reference as authoritative master-system identifier, with a monotonic revision sequence; referral identifiers are carried as governed external references only.", "source_refs": [ "SRC-002", "SRC-009" ] } ], "inline_only_rationale": null } ] }, { "id": "l-records-and-exceptions", "name": "Records, Clock Traceability and Exceptions", "description": "The retention parameters and clock evidence the venue must hold, the data it is bound to supply to authorities, and the exceptions and disputes it records.", "source_refs": [ "SRC-004", "SRC-005", "SRC-006", "SRC-009", "SRC-008" ], "findings": [ { "id": "f-record-retention-and-clock-traceability", "name": "Record retention parameters and clock traceability", "description": "How long each class of venue record must be kept, under which authority, and the documented traceability of the venue's business clocks to Coordinated Universal Time.", "source_refs": [ "SRC-004", "SRC-005", "SRC-006", "SRC-009" ], "questions": [ { "id": "q-rct-1", "text": "Which retention period applies to each class of venue record, and which instrument sets it?", "kind": "retention", "answer_data": [ "record class (order events, trades, publications, membership, rulebook)", "retention duration", "source instrument reference and jurisdiction", "legal hold override route" ] }, { "id": "q-rct-2", "text": "Which clock divergence tolerance and timestamp granularity apply to this venue, and on what basis?", "kind": "measurement", "answer_data": [ "gateway-to-gateway latency band", "maximum divergence from Coordinated Universal Time", "timestamp granularity", "participant-side tolerance where different" ] }, { "id": "q-rct-3", "text": "How is traceability to Coordinated Universal Time documented and reviewed?", "kind": "validation", "answer_data": [ "timing source reference", "system design and specification document reference", "points in the flow where timestamps are applied", "review frequency and last review record" ] }, { "id": "q-rct-4", "text": "Which party executes disposition when a retention period ends, and what does this model retain afterwards?", "kind": "ownership", "answer_data": [ "executing party (adopting Dimension records policy, venue operator)", "tombstone content permitted after disposition", "evidence of disposition", "statement that this model records the rule, not the disposal action" ] } ], "data_elements": [ { "id": "de-retention-parameter", "name": "Retention parameter", "description": "Record class, retention duration, governing instrument and jurisdiction, with any legal-hold marker.", "value_kind": "object", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-006", "SRC-009" ] }, { "id": "de-clock-profile", "name": "Clock synchronisation profile", "description": "Applicable divergence tolerance, granularity, timing source and traceability review record for the venue's business clocks.", "value_kind": "object", "cardinality": "1", "required": true, "source_refs": [ "SRC-005" ] } ], "artifacts": [ { "id": "a-clock-traceability-documentation", "name": "Clock traceability and retention parameter record", "description": "Documented traceability of business clocks to Coordinated Universal Time with timestamp application points and review evidence, together with the retention parameter set per record class.", "media_or_form": [ "structured record", "technical specification document", "review attestation" ], "serial": true, "identity_strategy": "Composite of venue MIC and the venue's traceability document version reference as authoritative master-system identifier, with a monotonic review sequence; review dates are attributes rather than key components.", "source_refs": [ "SRC-005", "SRC-006" ] } ], "inline_only_rationale": null }, { "id": "f-exception-dispute-and-referral", "name": "Exceptions, disputes and supervisory data supply bindings", "description": "Operational exceptions and participant disputes raised at the venue, the interim treatment applied, and the standing bindings under which the venue supplies order, trade and reference data to authorities.", "source_refs": [ "SRC-009", "SRC-006", "SRC-008", "SRC-007" ], "questions": [ { "id": "q-edr-1", "text": "Which exception classes does the venue record, and what interim treatment applies to each?", "kind": "exception", "answer_data": [ "exception class (system outage, erroneous data, disputed fill, failed check, rule breach report)", "interim measure applied", "raising role", "open, held and closed states with event and observation timestamps" ] }, { "id": "q-edr-2", "text": "How is a participant dispute recorded, and where does its resolution live?", "kind": "process", "answer_data": [ "dispute record identifier", "parties as references", "dispute resolution route reference", "statement that adjudication and remedy are peer-owned" ] }, { "id": "q-edr-3", "text": "Which data must the venue supply to which authority, under which legal basis and on what deadline?", "kind": "interoperability", "answer_data": [ "data class (order records, transaction reports, product reference data, inside information)", "recipient authority reference", "legal basis reference", "deadline rule", "statement that the submission lifecycle is peer-owned" ] }, { "id": "q-edr-4", "text": "Who may see an open exception record, and under what minimum-disclosure projection?", "kind": "access", "answer_data": [ "recipient class", "fields included in a minimum-disclosure projection", "fields withheld while the matter is open", "purpose limitation statement" ] } ], "data_elements": [ { "id": "de-exception-record", "name": "Exception or dispute record", "description": "Classified exception with interim measure, raising role, state and separated event and observation timestamps.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009", "SRC-006" ] }, { "id": "de-supply-binding", "name": "Supervisory data supply binding", "description": "Standing obligation to supply a named data class to a named authority under a stated legal basis and deadline.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006", "SRC-008", "SRC-007" ] } ], "artifacts": [ { "id": "a-exception-and-referral-record", "name": "Exception, dispute and supply binding record", "description": "Non-destructive record of exceptions and disputes with interim measures and states, plus the venue's standing supervisory data supply bindings.", "media_or_form": [ "structured record", "time-ordered event log" ], "serial": true, "identity_strategy": "Venue-assigned exception or dispute reference as authoritative master-system identifier with a monotonic state sequence; peer case, adjudication and submission identifiers are carried as governed external references only.", "source_refs": [ "SRC-009", "SRC-006" ] } ], "inline_only_rationale": null } ] } ] } ] }, "functions": [ { "id": "fn-create-and-identify-venue-record", "name": "Create and identify a governed market or exchange record", "description": "Open a record for a venue or segment, binding it to the authoritative registry code and the operator's governed entity reference before any dependent record is created.", "inputs": [ "Candidate market identifier code or registry submission reference", "Operator legal entity reference", "Authorisation class and granting authority reference", "Country and city of registration" ], "outputs": [ "Venue identity record with authoritative identifier", "Identity precedence statement listing which identifier was used and why" ], "preconditions": [ "A registry code exists or a registration request reference is available", "The operator entity resolves in the peer entity registry or is recorded as unresolved" ], "effects": [ "A uniquely addressable venue record exists and can scope segments, memberships, orders and trades", "An adopting-Dimension surrogate identifier, if minted, is flagged for replacement once a registry code is assigned" ], "source_refs": [ "SRC-003", "SRC-010" ] }, { "id": "fn-classify-with-versioned-schemes", "name": "Classify the venue with versioned schemes and jurisdiction profile", "description": "Attach authorisation class, market category and trading-model classifications, each qualified by scheme version and the jurisdiction or profile in which it is authoritative.", "inputs": [ "Venue identity record", "Classification scheme identifier and version", "Jurisdiction or regulatory profile" ], "outputs": [ "Versioned classification set with jurisdiction qualifiers", "List of classifications that are profile-specific rather than universal" ], "preconditions": [ "The venue record exists", "The scheme version is resolvable and dated" ], "effects": [ "Downstream obligations can be selected by profile rather than assumed globally", "Conflicting classifications across jurisdictions are recorded side by side rather than reconciled silently" ], "source_refs": [ "SRC-006", "SRC-009", "SRC-003" ] }, { "id": "fn-link-owned-relationships", "name": "Link owned relationships without copying peer semantics", "description": "Create references from this model to instruments, entities, clearing and settlement infrastructures, authorities and peer case records, carrying only the binding and subject-specific parameters.", "inputs": [ "Source record in this model", "Target model reference and identifier", "Relation type and purpose" ], "outputs": [ "Relationship record with target reference and binding parameters", "Ownership statement naming which model owns the target's lifecycle" ], "preconditions": [ "The target identifier is governed and resolvable, or the link is marked unresolved", "The relation does not reproduce the target's lifecycle or operational functions" ], "effects": [ "Cross-model navigation is possible without duplicating peer data", "Attempts to record peer-owned states such as settlement finality are rejected at validation" ], "source_refs": [ "SRC-001", "SRC-006", "SRC-010" ] }, { "id": "fn-record-market-event", "name": "Record a market event with separated event and observation time", "description": "Append an order, quote, halt, price, trade, correction or membership transition event with its sequence number, event time and the instant this model observed it.", "inputs": [ "Scoping segment and order book reference", "Event type and payload", "Event time from the source system", "Observation or ingestion time" ], "outputs": [ "Sequenced event record", "Updated current-state projection" ], "preconditions": [ "The scoping venue, segment and, where relevant, order or trade record exists", "The applicable clock profile is recorded and the timestamp carries seconds and an explicit offset" ], "effects": [ "Prior states remain retrievable; no event is overwritten", "Deterministic replay of state from the event sequence remains possible" ], "source_refs": [ "SRC-004", "SRC-005", "SRC-012" ] }, { "id": "fn-inspect-state-and-provenance", "name": "Inspect current state, provenance and assertion basis", "description": "Return the current state of a venue, membership, order, trade or price together with the asserting role, source, rulebook version and whether each value is asserted, observed or derived.", "inputs": [ "Record reference", "As-of instant" ], "outputs": [ "Current state with validity interval", "Provenance set naming source, asserting role and rulebook version", "Assertion class per value (asserted, observed, derived)" ], "preconditions": [ "The record exists and at least one event has been recorded" ], "effects": [ "An agent can distinguish venue assertions from observations of peer systems before acting", "As-of queries return the state that was in force, not the latest state" ], "source_refs": [ "SRC-004", "SRC-001", "SRC-011" ] }, { "id": "fn-validate-record", "name": "Validate mandatory fields, identifiers, temporal ordering and relation constraints", "description": "Check a record against identifier priority, required-field rules for the applicable trading model, sequence monotonicity, timestamp format and granularity, and relation ownership limits.", "inputs": [ "Record or batch under validation", "Applicable jurisdiction or profile", "Clock profile" ], "outputs": [ "Validation outcome with per-rule results", "Rejection reasons and remediation hints" ], "preconditions": [ "The applicable profile and scheme versions are known" ], "effects": [ "Records that would misattribute peer-owned semantics are rejected", "Timestamps lacking seconds or an explicit offset are rejected" ], "source_refs": [ "SRC-004", "SRC-005", "SRC-006" ] }, { "id": "fn-compare-versions", "name": "Compare versions and explain material changes", "description": "Produce a difference between two versions of a rulebook, matching specification, entitlement profile, calendar or admission record and classify each change as material or editorial.", "inputs": [ "Two version references of the same record", "Materiality criteria reference" ], "outputs": [ "Structured difference set", "Materiality classification per change", "Effective interval of each version" ], "preconditions": [ "Both versions are retained and canonicalised" ], "effects": [ "Participants and supervisors can see what changed and when it took effect", "Editorial changes do not mask material rule changes" ], "source_refs": [ "SRC-011", "SRC-009" ] }, { "id": "fn-project-minimum-necessary-view", "name": "Project a minimum-necessary view for an authorised purpose", "description": "Emit a purpose-limited projection of venue, participant, order, trade or surveillance data, withholding owner-gated and confidential fields and recording the purpose and recipient.", "inputs": [ "Record set reference", "Declared purpose and recipient class", "Applicable waiver, deferral or confidentiality basis" ], "outputs": [ "Projected view containing only fields permitted for the purpose", "Projection manifest naming purpose, recipient, withheld field classes and legal basis" ], "preconditions": [ "A purpose and recipient class are declared", "Any applicable deferral or waiver is resolved" ], "effects": [ "Public transparency, participant and supervisory views can be derived from one record set", "Detection thresholds, open matters and undisclosed order quantities are excluded unless explicitly authorised" ], "source_refs": [ "SRC-006", "SRC-015", "SRC-002" ] }, { "id": "fn-handle-exception-and-supersession", "name": "Handle exceptions, disputes, correction and supersession without history loss", "description": "Raise an exception, register a dispute, or issue a correction or cancellation that supersedes an earlier record while retaining the original and linking the two.", "inputs": [ "Target record reference", "Exception or correction grounds", "Deciding role and evidence references" ], "outputs": [ "Correction or exception record with supersession pointer", "Republication instruction with the applicable correction flag" ], "preconditions": [ "The target record exists and the grounds fall within the declared policy window", "The deciding role holds the stated authority" ], "effects": [ "The superseded record remains retrievable and marked as superseded", "Downstream consumers receive an explicit cancellation or amendment signal", "Adjudication and remedy remain with the peer dispute or enforcement model" ], "source_refs": [ "SRC-015", "SRC-009", "SRC-011" ] }, { "id": "fn-apply-retention-instruction", "name": "Apply retention, legal hold, tombstone and disposition instructions through the owning policy", "description": "Attach or lift retention and legal-hold markers on this model's records and request disposition from the policy that owns execution, leaving a tombstone that preserves referential integrity.", "inputs": [ "Record class and record references", "Retention parameter or legal-hold instruction", "Owning policy reference" ], "outputs": [ "Updated retention and hold markers", "Disposition request and its outcome reference", "Tombstone record where content was disposed" ], "preconditions": [ "A retention parameter or hold instruction exists with a named owning policy", "No open legal hold blocks the disposition" ], "effects": [ "Content may be disposed while identifier, class and disposition evidence survive as a tombstone", "This model records the rule and the request; the adopting Dimension's records policy executes the disposal" ], "source_refs": [ "SRC-006", "SRC-009" ] }, { "id": "fn-export-and-import-via-alignments", "name": "Export and import through declared standards alignments", "description": "Map this model's records to and from external representations such as registry extracts, regulatory field sets and messaging vocabularies, recording each mapping as an alignment rather than a conformance claim.", "inputs": [ "Record set reference", "Target alignment identifier and version", "Field mapping table" ], "outputs": [ "Mapped representation", "Alignment report listing unmapped fields, lossy conversions and semantic mismatches" ], "preconditions": [ "The target alignment version is declared and resolvable", "No conformance is asserted without evidence of a completed assessment" ], "effects": [ "Interoperability is achieved without implying certification against the target standard", "Mapping gaps are surfaced rather than silently filled" ], "source_refs": [ "SRC-004", "SRC-008", "SRC-012", "SRC-015" ] }, { "id": "fn-validate-against-iso-register", "name": "Validate against the published MIC list", "description": "Compare local identity, type, category, status and LEI fields to the current ISO 10383 publication and record differences as evidence, not as silent overwrite of legal-class fields owned by jurisdictional registers.", "inputs": [ "Current ISO 10383 publication", "Local identity, type, category, status and LEI fields" ], "outputs": [ "Recorded differences between the local record and the current MIC publication" ], "preconditions": [], "effects": [ "Records differences as evidence", "Does not silently overwrite legal-class fields owned by jurisdictional registers" ], "source_refs": [ "SRC-003", "SRC-023" ] } ], "composition": [ { "target": "Financial instrument / tradable product model (identity via ISIN, unique product identifier, classification code, or energy product reference data)", "relation": "REFERENCE", "purpose": "Resolve the object admitted to trading. This model carries only the admission binding, the segment on which it trades, the validity interval and venue-specific trading parameters such as tick size and lot size. Instrument identity, terms, classification mastering and lifecycle stay with the peer model.", "required": true, "source_refs": [ "SRC-006", "SRC-008" ] }, { "target": "Legal entity / organisation model (identity via ISO 17442 LEI, ACER registration code or equivalent sector register)", "relation": "REFERENCE", "purpose": "Resolve the venue operator, participants, clearing members and authorities. This model carries the venue-assigned member code and the external identifier reference. Entity reference data, ownership hierarchies, registration status, validation and renewal remain peer-owned.", "required": true, "source_refs": [ "SRC-010", "SRC-007", "SRC-003" ] }, { "target": "Financial market infrastructure model (central counterparty, central securities depository, securities settlement system, payment system)", "relation": "REFERENCE", "purpose": "Bind an executed trade to the clearing and settlement arrangement that will process it. This model carries the clearing model value, the infrastructure reference and the settlement terms asserted at execution. Novation, netting, margin, collateral, participant-default rules, segregation, portability, settlement finality and money settlement are owned by the peer model under the PFMI.", "required": true, "source_refs": [ "SRC-001" ] }, { "target": "Contract / agreement model", "relation": "REFERENCE", "purpose": "Point from an executed trade event to the legal contract it gives rise to. This model asserts only that a match occurred on stated terms; contract formation, obligations, performance, remedies and discharge are peer-owned.", "required": false, "source_refs": [ "SRC-006", "SRC-009" ] }, { "target": "Market abuse surveillance and enforcement case model", "relation": "REFERENCE", "purpose": "Carry the referral pointer and the recipient body reference when the venue hands a matter out. Alert evaluation, investigation, case adjudication, sanctions, enforcement and the evidentiary audit-trail semantics of those processes are owned by the peer model.", "required": false, "source_refs": [ "SRC-002", "SRC-009", "SRC-006" ] }, { "target": "Regulatory reporting submission model (order record supply, transaction reporting, product reference data supply)", "relation": "REFERENCE", "purpose": "Record the standing supply binding: which data class goes to which authority under which legal basis and deadline. The submission lifecycle, acknowledgement, rejection, resubmission and correction states are peer-owned.", "required": false, "source_refs": [ "SRC-006", "SRC-008", "SRC-007" ] }, { "target": "Regulatory authority / jurisdiction model", "relation": "REFERENCE", "purpose": "Resolve the competent, designating or recognising authority named on an authorisation, waiver, deferral or supply binding. Authority identity, mandate and instrument publication remain peer-owned.", "required": true, "source_refs": [ "SRC-006", "SRC-009", "SRC-002" ] }, { "target": "Price benchmark / index administration model", "relation": "REFERENCE", "purpose": "Point from an official closing or settlement price produced here to any benchmark that consumes it. Benchmark methodology, governance, oversight and publication are peer-owned; this model asserts only its own price observation and derivation method.", "required": false, "source_refs": [ "SRC-002", "SRC-009" ] }, { "target": "ISO 10383 Market Identifier Code registry", "relation": "ALIGN", "purpose": "Align venue and segment identification with the registry's codes, statuses and validation dates. Code assignment, modification, deactivation and the publication cycle are owned by the registration authority; this model consumes the registry as an authoritative source and does not mint or retire codes.", "required": true, "source_refs": [ "SRC-003" ] }, { "target": "Order, trade and reference data field sets in RTS 24, RTS 1 and the REMIT implementing regulation", "relation": "ALIGN", "purpose": "Align this model's order, trade, publication and product reference data elements with named regulatory field sets so that projections can be produced. Alignment is a mapping, not a conformance claim; a completed assessment is required before conformance may be asserted.", "required": false, "source_refs": [ "SRC-004", "SRC-015", "SRC-008" ] }, { "target": "FIX order state model (OrdStatus and ExecType semantics)", "relation": "ALIGN", "purpose": "Align this model's venue-neutral order state vocabulary with the de facto industry order state model for interoperability. The messaging standard's session, transport and encoding layers are projections and remain outside this model.", "required": false, "source_refs": [ "SRC-012" ] }, { "target": "Clock synchronisation and traceability profile (RTS 25 tolerance and granularity tables)", "relation": "ALIGN", "purpose": "Bind the venue's recorded clock profile to a named external tolerance and granularity table. Timing-source operation, calibration and attestation are owned by the operator's technical and assurance functions, not by this model.", "required": true, "source_refs": [ "SRC-005" ] }, { "target": "Adopting-Dimension records, retention and access policy", "relation": "MIX-IN", "purpose": "Supply the retention durations, legal-hold, disposition and access rules that this model records but does not execute. The policy owns execution of deletion and of access decisions; this model owns only the parameters, markers and evidence pointers.", "required": true, "source_refs": [ "SRC-006", "SRC-009" ] } ], "serviceLayers": { "dimension": { "owner_package_requirements": [ "The adopting Dimension must name one accountable operator or maintainer per venue record - the market operator, the supervising authority, or a contracting party acting for one of them - and must record that role separately from the record steward who maintains this model's entries.", "The package must declare its jurisdiction and regulatory profile set before any classification, transparency or retention parameter is populated, because authorisation classes, waiver types, publication flags and retention durations are profile-specific rather than universal.", "The package must supply the retention, legal-hold, disposition and access policy referenced by this model, since this model records those parameters but never executes disposal or access decisions.", "The package must declare which peer models resolve instruments, legal entities, clearing and settlement infrastructures, authorities and enforcement cases, or mark each as unresolved, so that no venue record silently absorbs peer-owned semantics.", "The package must register the clock synchronisation profile in force for each venue, including timing source and tolerance band, before any sequenced market event is accepted." ], "namespace_guidance": "Use a stable Dimension namespace of the form /market-exchange/ with sub-namespaces per venue keyed on the ISO 10383 operating code, then segment code, then record class (membership, admission, order, trade, publication, exception). Never place a trading day, calendar year or session label in a namespace path segment. External identifiers keep their issuing authority's namespace and are never re-minted locally; a locally minted surrogate carries an explicit provisional marker and is retired when an authoritative identifier becomes available.", "registry_links": [ "ISO 10383 Market Identifier Code registry, published monthly by the registration authority, as the authoritative source of operating and segment codes, market category, country, city and registry status.", "Global LEI Index for operator, participant and issuer entity references, consumed read-only.", "Competent authority registers of authorised trading venues, designated contract markets and registered market participants, consumed as evidence for authorisation status." ] }, "canon_and_patch": { "canonicalization_rules": [ "Canonical form orders object keys lexicographically, normalises all time values to RFC 3339 with seconds and an explicit offset or Z, expresses quantities with an explicit unit or notation, and expresses codes as a scheme-version-value triple.", "Identifiers are canonicalised in the declared priority order; where more than one identifier is present, the authoritative master-system identifier is the canonical key and all others are carried as typed references.", "Event records are canonicalised in sequence-number order within a scoping segment and order book; where sequence numbers tie or are absent, canonical order falls back to event time then to a documented deterministic tie-break, and the fallback is recorded.", "Derived values such as reconstructed book state or compliance measurements are canonicalised with their method reference and are never merged into asserted values." ], "patch_rules": [ "Patches are additive: a new version supersedes an earlier one by pointer and never overwrites it. Emitted market-event records are immutable; corrections are new records carrying the original identifier plus a correction sequence.", "A patch that changes a classification, authorisation class, matching rule, entitlement or retention parameter must carry the new scheme or rulebook version and an effective-from instant, plus the observation instant at which this model learned of the change.", "A patch may not introduce a value whose ownership belongs to a referenced peer model; such a patch is rejected with the relation link that owns the concept.", "A patch that would remove content under a retention or disposition instruction must be expressed as a disposition request against the owning policy, not as a field deletion." ], "compatibility_rules": [ "Adding an optional data element, question, artifact or alignment is backward compatible. Removing an element, tightening cardinality, or changing an identifier strategy is breaking and requires a new major version of the model.", "Alignments to external field sets are versioned independently; an external standard revision does not by itself force a model version change, but the alignment record must be re-dated and its unmapped-field report regenerated.", "Vocabulary values may be added within a scheme version; reassigning the meaning of an existing value is breaking and requires a new scheme version.", "No conformance to any external standard is asserted by compatibility alone; conformance requires a recorded assessment with evidence." ] }, "artifact_rules": { "identity_priority": [ "Authoritative master-system identifier issued by the system of record for the subject: the ISO 10383 operating or segment market identifier code for a venue, the competent authority's authorisation or designation reference for regulatory standing, and the venue matching system's own member code, order identification code, transaction identification code, sequence number or exception reference for its operational records.", "Governed global identifier or internationalised resource identifier: the ISO 17442 legal entity identifier for the operator and participants, sector registration codes such as an ACER registration code, instrument identifiers such as ISIN or unique product identifier, or an internationalised resource identifier minted in the adopting Dimension's governed namespace.", "UUID or ULID assigned by the adopting Dimension, used only where no authoritative or governed identifier exists, marked provisional, and retired in favour of an authoritative identifier as soon as one is assigned. A date, trading day, calendar year, session label or publication cycle is never an identifier." ], "timestamp_rule": "Every time value is recorded as an RFC 3339 date-time with seconds present, fractional seconds retained at the source granularity, and an explicit numeric UTC offset or Z; local wall-clock strings without an offset are rejected. Event time (order receipt, order event, priority assignment, match, halt, publication, authorisation change) is stored in a field distinct from observation or ingestion time (the instant this model received or recorded the fact), and both are retained whenever they differ. Each event carries the clock synchronisation profile that applied - timing source, maximum divergence from Coordinated Universal Time and recorded granularity - because venue tolerances range from one millisecond down to one hundred microseconds with granularity to one microsecond, and a coarser participant-side tolerance may apply to voice, request-for-quote and negotiated activity.", "serial_naming_rule": "A serial artifact is named .., where the scope identifier is the operating or segment market identifier code combined with the order book code, member code, object reference or transaction identification code as applicable, and the sequence is the source system's own monotonic number (for example the order-event sequence number, correction sequence or specification revision number). Trading day, calendar year, session name and publication cycle may appear only as descriptive qualifiers inside the payload or after the sequence, never as any part of the identifying key. Gaps in a sequence must be detectable and explained rather than renumbered.", "integrity_rule": "Each retained artifact carries a content digest computed over its canonical form, the identifier and version of the source it was derived from, the asserting or capturing role, and the event and observation timestamps. Emitted market-event artifacts are append-only: an error is remedied by a linked correction artifact carrying the original identifier and a correction sequence, never by mutation. Any artifact whose digest cannot be recomputed, or whose source reference cannot be resolved, is marked as unverified and excluded from projections that assert evidentiary weight." }, "policies": [ "Separation of assertion classes: every value is labelled as asserted by the venue, observed from a peer or external source, or derived by a stated method. A derived or observed value may never be promoted to an assertion without a recorded basis, and an observation of a peer system's state never becomes authoritative in this model.", "Relation ownership discipline: no bundle, layer, finding, artifact or function of this model may hold the lifecycle or operational semantics of a referenced model. Clearing, settlement finality, contract performance, enforcement adjudication, benchmark administration, entity registration and report submission states are carried only as references and observations, and validation rejects local values that would duplicate them.", "Non-destructive history: superseded rulebook versions, membership decisions, orders, trades, prices and publications are retained and linked. Cancellation, amendment, expiry and disposition are represented as new linked records with explicit flags rather than as deletions.", "Profile explicitness: authorisation classes, waivers, deferrals, publication flags, position and reporting duties and retention durations are recorded as jurisdiction-scoped profiles with scheme versions, never as universal facts. Where two profiles conflict, both are retained with their jurisdiction qualifiers and the conflict is recorded.", "No unevidenced conformance: alignment to an external standard is recorded as a mapping with an unmapped-field report. Conformance may be asserted only where a completed assessment with evidence is referenced.", "Validation: Validate MIC pattern [A-Z0-9]{4}, MIC type against operating MIC, status against {ACTIVE, UPDATED, EXPIRED}, LEI format if present, and that SI/DRSP records are not classified as MiFID trading venues. Treat ISO, MiFID, SEA, CEA and MiCA classes as alignments and fail closed on silent conformance claims.", "Retention: Retain expired MIC identity indefinitely as a historical place-of-trade key. Retain listing and trading-state history for the period required by venue recordkeeping rules and adopting-Dimension policy. Destruction of extra local attributes, if any, is executed by adopting-Dimension policy after tombstone; referenced models own destruction of operator, trade and audit records." ], "crud": { "read": [ "Reads are scoped by declared purpose and recipient class; every read returns the assertion class, provenance and validity interval alongside each value.", "As-of reads return the state in force at the requested instant using event time, with observation time available separately so that late-arriving facts are visible.", "Public transparency projections expose only the published field set with its qualifying flags; undisclosed order quantities, entitlement configurations, surveillance parameters and open exception content are excluded by default.", "Reads of peer-owned values return the reference and the observation, never a locally reconstructed authoritative value." ], "create": [ "A venue, segment, membership, admission, order, trade, price, publication or exception record may be created only with an identifier chosen by the declared identity priority and marked provisional if surrogate.", "Creation requires the scoping records to exist: a segment requires its operating venue, an order requires its segment, order book and member, a trade requires its contributing orders where the venue holds them.", "Creation of any event record requires event time, observation time and the applicable clock profile; records failing the timestamp rule are rejected.", "Creating a record that asserts a peer-owned state is rejected with a pointer to the composition link that owns the concept." ], "update": [ "Reference and configuration records are updated by adding a new version with an effective-from instant and a supersession pointer; the prior version is retained.", "Emitted market-event records are never updated in place; an amendment or cancellation is a new linked record carrying the applicable correction flag and republication instruction.", "An update that changes a classification or rule must carry the new scheme or rulebook version; an update that changes an identifier strategy is treated as a breaking change requiring a model version increment.", "Late-arriving or corrected observations of peer state are appended as new observations with their own observation timestamps rather than replacing earlier ones." ], "delete": [ "Hard deletion is not available in this model. A record whose retention period has expired and which carries no legal hold is disposed of by content removal, leaving a tombstone that retains the authoritative identifier, record class, retention parameter applied, disposition instant, disposing authority reference and the digest of the disposed content, so that inbound references and sequence continuity remain resolvable.", "Retention durations, legal holds and disposition triggers are recorded here but executed by the adopting Dimension's records, retention and access policy declared through the MIX-IN composition link; where a statutory retention duty sits on the venue operator under MiFIR Article 25, RTS 24 or the CFTC recordkeeping core principle, this model records the parameter and the operator's obligation and never performs or evidences the disposal itself.", "An open legal hold blocks disposition of the held record class; the hold, its basis and its lifting are recorded as linked events with event and observation times.", "Disposition of a record whose content is also held by a referenced peer model - clearing, settlement, enforcement case or reporting submission records - does not dispose of the peer's copy; the peer model or its owning policy governs that copy, and this model retains only the reference and the tombstone.", "A tombstone is itself retained under the same policy and may only be removed by an explicit instruction from the owning retention policy that also accounts for the referential integrity of every inbound link." ] }, "roles": [ { "name": "Market operator authority", "responsibilities": [ "Holds authority to adopt and amend the rulebook, admit and suspend participants, admit and terminate tradable objects, set matching and volatility parameters, and declare halts and emergency interventions.", "Asserts the venue's own facts: executed trades, official prices, transparency publications and corrections.", "Cannot alter this model's governance, retention or access policy, which belongs to the adopting Dimension." ] }, { "name": "Model record steward", "responsibilities": [ "Maintains this model's entries: creates records, applies patches, canonicalises content, recomputes digests and resolves or flags unresolved peer references.", "Enforces the identity priority and the timestamp rule at write time and rejects records that assert peer-owned semantics.", "Holds no authority over venue rules, admissions or trading decisions and must not originate market assertions." ] }, { "name": "Supervisory or oversight reader", "responsibilities": [ "Reads full-fidelity order, trade, membership and exception records under a declared supervisory purpose and legal basis.", "Receives referral pointers and supply bindings but conducts investigation, adjudication and enforcement in the peer case model, not here.", "Records the legal basis and purpose of each access so that projections remain auditable by the adopting Dimension's audit model." ] }, { "name": "Participant reader", "responsibilities": [ "Reads its own membership, entitlement, order, quote and trade records, plus published transparency and market data products according to entitlement.", "Raises disputes and exception reports against its own records.", "Has no visibility of other participants' undisclosed interest, entitlement configurations or surveillance parameters." ] }, { "name": "Public transparency consumer", "responsibilities": [ "Reads only the published pre- and post-trade field sets, official prices, rulebook, calendar, admitted-object list and governance disclosure.", "Receives deferral and correction flags so that provisional and superseded publications are distinguishable.", "Has no access to participant identity beyond what the published field set discloses, nor to any open exception or referral content." ] }, { "name": "Retention and access policy owner", "responsibilities": [ "Supplies retention durations, legal-hold instructions, disposition triggers and access rules through the declared policy link.", "Executes disposition and access decisions that this model records but does not perform.", "Owns the governance audit trail of reads and writes against this model's records." ] } ], "access": { "default_rule": "Deny by default. Every read, projection or export requires a declared purpose, a recipient class and a legal or contractual basis, and returns the minimum field set sufficient for that purpose. Venue identity, authorisation status, rulebook, calendar, admitted-object list and published transparency records are the only classes with a standing public projection; membership, entitlement, order, quote, book-depth, exception, referral and surveillance-parameter records are owner-gated and require an explicit grant.", "scopes": [ "bundle", "layer", "finding", "artifact" ], "exceptions": [ "Supervisory access: a competent, designating or recognising authority acting under a stated legal basis may read full-fidelity records across all scopes, including undisclosed order quantities and open exception content, without participant consent; the basis and scope are recorded on the access.", "Deferred publication: post-trade detail subject to a granted deferral is withheld or published in aggregated form until the deferral expires, after which the full record becomes part of the public projection automatically.", "Waived pre-trade display: where a waiver applies, book-depth and quote information is withheld from the public projection while remaining fully readable under supervisory and participant-own-record access.", "Surveillance confidentiality: detection thresholds, monitoring logic and open referral content are excluded from every projection including participant-own-record access, and are released only to the recipient body named on the referral.", "Emergency operational disclosure: during a declared halt, outage or emergency intervention, a restricted operational status projection may be issued to all participants ahead of normal publication timing, marked provisional and reconciled afterwards.", "Participant own-record access: a participant may always read its own membership, entitlement, order, quote and trade records, but never another participant's, and never the counterparty identity of an anonymous match unless the rulebook discloses it.", "Authorisation instruments, member registers, unpublished halt reasons and emergency playbooks are owner-gated under adopting-Dimension policy.", "This model does not grant access to FMI, trade or surveillance stores by reference.", "Minimum-disclosure projection uses de-disclosure-class to split public register data from owner-gated operating detail." ], "audit_requirements": [ "Every access records recipient class, declared purpose, legal or contractual basis, scope granted, fields withheld and the access instant with an explicit offset.", "Every projection carries a manifest naming the purpose, the withheld field classes and any waiver, deferral or confidentiality basis applied, so that a later reviewer can tell what was suppressed and why.", "Denials and partial grants are recorded with the rule that produced them, not silently reduced.", "The governance audit trail of these accesses is written to and owned by the adopting Dimension's audit model; this model retains only the projection manifests and the reference to the audit entry.", "Record register provenance for each populated record: register name, source URL, publication time, implementation time, ingested_at and ingested_by.", "Record event time separately from observation or ingestion time for MIC changes, authorisation acts, listings, halts and session transitions, using RFC 3339 with seconds and offset.", "Venue recordkeeping and clock-synchronisation obligations are stored as constraints only; the audit trail itself is owned by the referenced audit model or by adopting-Dimension policy." ] }, "agents_bootstrap": { "filename": "AGENTS.md", "required_fields": [ "Name", "Type", "Specification URL", "Storage type URL", "Interface URL", "Processes URL", "Registry ID", "Model version and status" ], "read_order": [ "Read AGENTS.md first and resolve Name, Type, Specification URL, Storage type URL, Interface URL and Processes URL before any read or write; if any is unresolvable, stop and report a bootstrap hold rather than guessing.", "Read the model scope statement, in-scope and out-of-scope lists and boundary notes, so that peer-owned concepts are recognised before the structure is traversed.", "Read the composition links and their ownership statements to learn which concepts must be referenced rather than modelled locally.", "Traverse Bundle to Layer to Finding to Question to Artifact, treating each finding as one atomic answerable body of context and each question as eliciting one answer with declared answer data.", "Apply the five facets to every instance: identity and class, direct nonphysical properties, recognition and observation criteria, capabilities, behaviour, states, transitions and affordances, and context and evidence.", "Label every value as fact, hypothesis or unknown, and distinguish asserted, observed and derived values before writing.", "Read the service layers - identity priority, timestamp rule, serial naming, integrity, canonicalisation and patch rules, CRUD, roles and access - and run the pre-write checks they define.", "Perform the operation, then run post-write checks: identifier priority honoured, timestamps carry seconds and an explicit offset with event and observation time separated, sequences monotonic, no peer-owned semantics written locally, and artifact-versus-inline exclusivity preserved.", "Escalate for human confirmation before any operation that supersedes a published record, changes an authorisation or membership state, alters retention or access parameters, or asserts conformance to an external standard; routine reads, validations and additive event appends may proceed autonomously.", "Once the public agent protocol is published, follow https://ver.cy/model-agent-protocol.md; until then treat that link as an open publication dependency and verification hold." ] } }, "coverage": { "claim": "Covers the context an agent needs to identify, describe, operate and audit an organised multilateral venue as evidenced by EU instruments (MiFIR, MiFID II, RTS 24, RTS 25, RTS 1, REMIT and its implementing regulation), US instruments (SEA 1934, CEA core principles for DCMs, Regulation ATS Form ATS-N) and global standards (ISO 10383, ISO 17442, PFMI, IOSCO principles), extended by the ISO 10383 code-lifecycle and multilateral recognition tests taken from the Grok pack. This is not a universal or complete account of markets: non-EU/US licensing regimes, MiCA crypto-asset platforms, DLT pilot venues, energy and non-financial marketplaces, fee and market-data schedules, and message-level bindings remain unevidenced in this pass.", "confidence": "medium", "checklist": [ { "dimension": "identity", "status": "covered", "notes": "Venue identity uses the ISO 10383 operating or segment code as authoritative master identifier, with the operator LEI as governed global reference and a provisional surrogate only where neither exists. Operational records use venue-assigned member, order, transaction and sequence identifiers. No date-like component appears in any key." }, { "dimension": "lifecycle", "status": "covered", "notes": "Authorisation status, membership, admission to trading, order state, halt state, trade correction and exception states are each modelled with a valid state set, an evidenced transition event and separated event and observation times. Superseded states are retained and linked." }, { "dimension": "relationships", "status": "covered", "notes": "Twelve composition links declare instrument, entity, infrastructure, contract, enforcement, reporting, authority, benchmark, registry, field-set, order-state and clock-profile relations, each with an explicit ownership statement. Internal relations cover operating-to-segment, member-to-channel, order-to-trade and trade-to-correction." }, { "dimension": "temporal", "status": "covered", "notes": "RFC 3339 with seconds and an explicit offset or Z is mandatory; event time and observation or ingestion time are stored separately; clock divergence tolerance and granularity are recorded per event; validity intervals apply to authorisations, admissions, rulebook versions, waivers and entitlements." }, { "dimension": "provenance", "status": "covered", "notes": "Every value carries an assertion class (asserted, observed, derived), an asserting role, a source reference and a rulebook or scheme version. Book state is explicitly marked as captured or reconstructed with method and confidence." }, { "dimension": "ownership", "status": "covered", "notes": "Market operator authority, model record steward, retention and access policy owner and the peer models are separated. Rule-change authority is distinguished from record stewardship, and ownership of clearing, settlement, enforcement and reporting semantics is assigned away by composition link." }, { "dimension": "validation", "status": "covered", "notes": "A validation function checks identifier priority, profile-conditional mandatory fields, sequence monotonicity, timestamp format and granularity, and relation ownership limits. Matching-rule verification and liquidity-commitment measurement are modelled as checkable, with non-deterministic elements such as randomised auction endings declared." }, { "dimension": "access", "status": "covered", "notes": "Deny by default with declared purpose, recipient class and legal basis; four scopes; six named exceptions covering supervisory access, deferrals, waivers, surveillance confidentiality, emergency disclosure and participant own-record access; projection manifests record what was withheld." }, { "dimension": "retention and deletion", "status": "covered", "notes": "Retention parameters are recorded per record class with their governing instrument; hard deletion is unavailable; disposition leaves a tombstone preserving identifier, class, parameter, instant, authority and content digest. Execution of disposal is assigned to the adopting Dimension's records policy through a MIX-IN link, and peer copies are explicitly out of reach." }, { "dimension": "interoperability", "status": "covered", "notes": "Alignments are declared to the ISO 10383 registry, RTS 24, RTS 1 and REMIT implementing field sets, the FIX order state model and the RTS 25 clock tolerance tables, each as a mapping with an unmapped-field report and an explicit refusal to assert conformance without a recorded assessment." }, { "dimension": "classification", "status": "covered", "notes": "Authorisation class, market category, membership category, order type, trading phase, matching algorithm, clearing model and publication flags are all carried as scheme-version-value triples with jurisdiction qualifiers." }, { "dimension": "authority", "status": "covered", "notes": "Competent, designating and recognising authorities are referenced; rule-change authority, emergency authority and decision-making roles are named per transition; the model records authority rather than exercising it." }, { "dimension": "measurement and price formation", "status": "covered", "notes": "Official, indicative, opening, closing and settlement prices are modelled with derivation method, input window, status and correction pointer. Liquidity-commitment compliance and book depth are measured observations with method, window and confidence. Physical measurements are deliberately absent because the subject is non-physical." }, { "dimension": "evidence and quality", "status": "covered", "notes": "Evidence references attach to admission decisions, halt declarations, trade cancellations, surveillance arrangements and clock traceability reviews. Provisional versus final status and captured versus reconstructed derivation are explicit." }, { "dimension": "exceptions and disputes", "status": "covered", "notes": "Exception classes, interim measures, dispute records, error-trade policy, emergency safe states and referral pointers are modelled, with adjudication and remedy assigned to peer models." }, { "dimension": "security", "status": "covered", "notes": "Access-channel controls, throttles, kill switches, cancel-on-disconnect settings and intervention records are modelled at the entitlement level. Operational risk and system safeguards obligations are cited but their engineering implementation is not modelled here." }, { "dimension": "spatial", "status": "covered", "notes": "Registry country and city, declared matching-facility location, jurisdiction of authorisation and recognition, and energy delivery point or zone codes are all represented, with registry location explicitly distinguished from operational location." }, { "dimension": "privacy", "status": "gap", "notes": "Client identification codes, natural-person decision-maker identifiers and personal data in membership records are referenced as fields but the model does not carry a data-protection basis, subject-rights route or cross-border transfer rule. This is deliberately delegated to the adopting Dimension's policy and remains an unclosed gap for personal-data-bearing deployments." } ], "known_omissions": [ "No relations are registered for this model in the registry, so all twelve composition links are proposals rather than confirmed contracts. Until they are registered and their targets exist, cross-model ownership boundaries are asserted here but not enforceable.", "Fee and tariff schedules, rebate structures and maker-taker economics are only touched through market data terms and are not modelled as a first-class finding, although they materially shape order routing behaviour and are disclosed on Form ATS-N.", "Position limits, accountability levels and large-trader reporting are cited through the CFTC core principles but not modelled, because they attach to participant positions held in a peer position model rather than to the venue record.", "Cross-venue routing, consolidated tape arrangements and best-execution obligations are not modelled; they span multiple venues and belong to a market-structure or execution-quality peer model.", "Auction-specific mechanism detail beyond phase and uncrossing - for example multi-round, sealed-bid, combinatorial or capacity-allocation auctions used in energy, emissions and spectrum markets - is not decomposed, though the phase and matching findings can carry it.", "Resilience, business continuity and system-safeguard testing regimes are acknowledged under PFMI Principle 17 and CFTC core principle 20 but not decomposed into findings.", "Crypto-asset trading platforms and their regional regimes are not separately evidenced; they may or may not fit the organised-market-place recognition test used here.", "Non-financial marketplaces such as retail platforms, public procurement portals and agricultural spot markets are within the nominal subject name but have no primary source support in this pass and are therefore not claimed.", "National exchange-licensing regimes outside the EU, US federal CEA/SEA and MiCA (for example Japan FIEA, Hong Kong SFO, MAS, SEBI, CVM, CSRC) were not fetched as primary texts and are unmarked as canonical classes.", "Wholesale energy organised marketplaces under REMIT, agricultural spot exchanges, warehouse-receipt markets and spectrum or treasury auction systems lack primary support in this pass and may be sibling models.", "FIX tag 30 LastMkt and ISO 20022 PlaceOfTrade message bindings are implied by ISO 10383's purpose but were not fetched as first-party technical specifications; they are interoperability holds, not claimed mappings.", "WFE membership, IOSCO Objectives and Principles for secondary-market regulation, and EU DLT Pilot Regime (Regulation 2022/858) trading venues were not ingested as primary sources.", "Tick-size, lot-size, colocation fee schedules and market-data licensing products are likely omitted and may belong to fee or data-product siblings.", "Whether APA/ARM/CTP should ever be instantiated as WM-ECO-001 records remains unresolved; they have MICs but are not markets.", "Islamic capital-market exchanges, SME growth-market subclass operational detail, security-futures dual CFTC/SEC notice registration workflows, and national ATS/MTF subtypes beyond those named.", "Market-maker scheme agreements required by MiFID recital 113 are referenced only as a constraint, not modelled as contracts.", "Clock synchronisation to UTC as a technical standard (MiFID RTS 25) was not fetched.", "Unresolved boundary: Systematic internaliser is MIC-bearing in ISO 10383/FIBO but is not a trading venue under MiFID Article 4(24); instantiation policy is a Dimension choice.", "Unresolved boundary: DRSPs with MICs versus a dedicated data-reporting model.", "Unresolved boundary: Physical marketplace or bazaar without a MIC.", "Unresolved boundary: Prediction markets and event-contract venues where CEA versus CFTC jurisdiction is contested.", "Unresolved boundary: When a crypto-asset platform is a MiCA CASP versus a MiFID trading venue because the token is a financial instrument." ], "conflicts": [ "Authorisation taxonomies do not align across jurisdictions: the European regulated market, multilateral trading facility and organised trading facility classes, the United States national securities exchange and alternative trading system distinction, the CFTC designated contract market and swap execution facility classes, and the REMIT organised market place concept overlap without mapping one to one. The model carries all of them as jurisdiction-scoped profiles and records no crosswalk as authoritative.", "Discretion in execution is treated differently: an organised trading facility may exercise discretion over placement and matching, while a regulated market must apply non-discretionary rules and a designated contract market is bound by its own execution core principle. A single non-discretionary flag would misrepresent at least one regime, so discretion scope is carried alongside it.", "Timestamp granularity requirements conflict across regimes: RTS 25 requires venue divergence down to one hundred microseconds with one microsecond granularity, while the REMIT implementing regulation requires only a UTC transaction timestamp. Recording the applicable clock profile per event is the only safe reconciliation.", "Order state vocabularies differ between the FIX industry model, the RTS 24 order event categories and venue-native statuses. The model keeps a venue-neutral state with an explicit mapping rather than adopting one vocabulary as canonical.", "The word market carries two incompatible senses: an institution with an operator and a rulebook, and an analytical relevant market delimited by substitutability. Only the first is modelled; the second is excluded by boundary note.", "ISO 10383 codes are immutable once allocated and cannot be modified, whereas the venue's legal name, operator and category may change. Identity therefore persists across changes that a naive consumer might read as a new venue.", "MiFID II Article 4(24) trading venue equals RM, MTF or OTF only; ISO 10383 and FIBO assign MICs and Exchange subclasses to SI, DRSP and CASP.", "FIBO uses market as a synonym of exchange; competition-law relevant market is a different neighbour.", "SEA 1934 exchange includes ATS-like systems that may operate under an exemption rather than as a national securities exchange.", "PFMI FMI set excludes trading venues; some operators are vertically integrated with CCP or CSD legal persons and must still be split across models." ], "regional_assumptions": [ "Primary structural evidence is drawn from European Union and United States regimes plus two global standard-setters. Asian, Latin American, African and Middle Eastern venue regimes are assumed to be broadly consistent with the IOSCO principles but were not independently verified in this pass.", "Retention durations, waiver and deferral types, publication flags and position-limit regimes are treated as jurisdiction-scoped profiles. No universal default is asserted for any of them.", "The clock synchronisation tolerance and granularity tables are a European profile; other jurisdictions impose different or no equivalent requirements, so the profile must be declared per venue rather than assumed.", "Wholesale energy market coverage rests on the European REMIT regime; other energy market regimes may use different participant registration, order reporting and delivery-point identification schemes.", "The assumption that a venue always has an ISO 10383 code holds for regulated and most organised venues but not for every organised market place, particularly smaller energy platforms and non-financial marketplaces; a provisional surrogate identifier is provided for those cases.", "Legal class enumerations are written against EU MiFID II/MiCA and US SEA/CEA as the densest primary regimes. Other jurisdictions must be added as profiles, not assumed to match.", "CFTC dormancy (twelve months, 36-month grace, vacated reapplication) is US DCM-specific and must not be generalised to every exchange.", "ISO 10383 publication on the second Monday and effectiveness on the fourth Monday follow the RA's Belgian calendar." ], "adversarial_checks": [ "Does the root match the subject rather than the registry label? The registry records standalone-mm, but the subject is a composite with one consistency boundary spanning venue, rulebook, segments, memberships, orders, phases and trades under a single operator's authority. The entry kind is therefore set to aggregate, and the registry-plane label is treated as a packaging term rather than a semantic classification.", "Does any bundle absorb a peer model's lifecycle? The execution and settlement bundle was re-checked against PFMI: it carries a clearing model value, an infrastructure reference and settlement terms asserted at execution, and it explicitly records downstream status only as an observation. Novation, netting, margin, default management and settlement finality appear only in out-of-scope entries, a boundary note and a REFERENCE link.", "Does the integrity bundle claim surveillance or enforcement ownership? It was reduced to a declared arrangement description with no detection thresholds, plus a referral pointer. Alert evaluation, investigation, adjudication, sanctions and the evidentiary audit trail of those processes are assigned to a peer model, and detection logic is excluded from every projection.", "Are actor identity, ownership, authority and access distinguished? Participant entity identity is a peer reference, venue member code is a local identifier, rule-change authority is separated from record stewardship, and access is governed by a deny-by-default rule with six named exceptions. Six roles are defined with non-overlapping responsibilities.", "Are planned, actual, observed, asserted and derived states kept separate? An assertion-class label is mandatory on every value; book state carries a captured-versus-reconstructed flag with method and confidence; official prices carry indicative, provisional, final and corrected statuses; downstream settlement status is confined to observation.", "Are correction, supersession, cancellation, expiry and deletion represented without history loss? Emitted market events are immutable, corrections are linked new records with cancellation and amendment flags, membership and authorisation transitions retain prior versions, and deletion is replaced by tombstoned disposition executed by an external policy.", "Are identifiers stable and non-date-like with an explicit authoritative-first priority? The identity priority names the master-system identifier first, the governed global identifier second and a provisional surrogate third. The serial naming rule forbids trading day, calendar year, session name and publication cycle from any key, and the namespace guidance repeats the prohibition.", "Are regional rules and classifier versions marked as profiles? Authorisation classes, waivers, deferrals, flags, retention durations and clock tolerances are all carried as scheme-version-value triples with jurisdiction qualifiers, and six substantive cross-regime conflicts are recorded rather than reconciled.", "Are artifact and inline-only rationale mutually exclusive? Every one of the twenty-six findings was checked individually: twenty-three declare at least one artifact with inline_only_rationale set to null, and three - segment hierarchy, clearing arrangement binding and conduct rule set - declare an empty artifact array with a substantive rationale explaining why materialising an artifact would duplicate an authoritative external source.", "Are evidence gaps exposed as holds rather than filled? Eight known omissions, five regional assumptions and one privacy gap are recorded. The absence of registered relations is stated as a hold that makes all composition links proposals, and the agent protocol URL is declared an open publication dependency.", "Can a minimum-disclosure projection be produced without exposing owner-gated detail? Yes: the public projection is restricted to venue identity, authorisation status, rulebook, calendar, admitted objects, governance disclosure and published transparency with flags. Undisclosed quantities, entitlement configurations, surveillance parameters and open exception content are excluded by default and each projection carries a manifest of what was withheld.", "Was any structural node left without primary support? Every bundle, layer, finding, function and composition link cites at least one source, and eleven of the fifteen sources are primary from nine independent organisations. The single node resting on secondary corroboration - the IOSCO Principles 33 to 37 wording - is cited to both the standard record and the supervisory summary because the primary PDF was not directly retrievable.", "Hold: Claude independent research has not run.", "Hold: The separate no-tools adversarial audit has not run.", "Hold: ISO 10383:2012 full text remains paywalled; scope and definitions were taken from the ISO catalogue abstract, OBP/search excerpts, the RA FAQ and Release 2.0 factsheet.", "Hold: https://ver.cy/model-agent-protocol.md is an explicit publication dependency for AGENTS.md interface and processes URLs.", "Hold: Registered relations array is empty; proposed REFERENCE and ALIGN links are candidate composition, not adopted Dimension contracts.", "Hold: Access, retention, deletion and exception execution require adopting-Dimension policy.", "Hold: Cross-jurisdiction multi-profile validation is outstanding.", "Hold: No canonical completeness claim is permitted." ] }, "researchAdjudication": { "providerMode": "dual-provider", "activeProviders": [ "claude", "grok" ], "waivedProviders": [], "providerPolicy": { "contract_version": "1.0.0", "mode": "dual-provider", "effective_at": "2026-09-05T11:39:25Z", "scope": "Queued subject-model research from WM-XCT-037 onward", "active_providers": [ "claude", "grok" ], "waived_providers": [], "review_rule": "Claude and Grok results require comparison, separate no-tools adversarial adjudication, synthesis and validation before publication." }, "boundaryDecision": { "entry_kind": "aggregate", "status": "accepted", "rationale": "The subject is an organised venue whose identity, segment and order-book structure, rulebook version, participant admissions, admitted objects, trading phases, matching rules, order and quote records, official prices, transparency publications and executed-trade events all sit under one operator's authority inside a single consistency boundary, with clearing, settlement, contract performance, enforcement and instrument or entity mastering assigned away by reference. That is an aggregate with the venue as root, not a single entity record. Grok's 'entity' framing describes only the venue's registry-facing header and would leave the venue's own RTS 24 order records and executed-trade events unowned by any model in the pack. The registry record's 'standalone-mm' value is a record-plane packaging label and is deliberately not used as the subject-model kind." }, "decisions": [ { "concept": "Base provider selection", "disposition": "Claude adopted as base", "rationale": "Claude's scope statement, ten boundary notes and out-of-scope list draw a single explicit consistency boundary and assign clearing, settlement, contract, enforcement, reporting, benchmark, instrument and entity semantics away by named peer. Grok's boundary is coherent but stops at the registry-facing header, leaving the venue's own order and trade records unowned. Base was chosen on boundary completeness, not on node count." }, { "concept": "Entry kind: aggregate versus entity", "disposition": "aggregate", "rationale": "Venue, segments, order books, memberships, admissions, orders, quotes, phases, prices, publications and executed trades share one operator's authority and one consistency boundary with the venue as root. 'entity' would fit only the registry header record and would fragment the subject." }, { "concept": "Ownership of order, quote and executed-trade records", "disposition": "retained inside the aggregate boundary", "rationale": "RTS 24 order recordkeeping, RTS 1 post-trade publication and the CFTC recordkeeping core principle place these records on the venue operator itself, so they are the venue's own market records rather than a peer model's. Grok's exclusion of them is rejected; the handoff point stays at clearing and settlement, which PFMI assigns to the infrastructure." }, { "concept": "Grok multilateral-recognition-criteria", "disposition": "accepted into l-venue-identity-and-authorisation", "rationale": "Supplies the applicability and adjacent-class rejection test that Claude carries only as prose in a boundary note, and its wording excludes non-venue classes rather than admitting them, so a verbatim copy does not contradict the aggregate root." }, { "concept": "Grok mic-lifecycle-and-dormancy", "disposition": "accepted into l-venue-identity-and-authorisation", "rationale": "Adds code-level lifecycle (never removed, EXPIRED, publication versus implementation date) and CFTC operational dormancy, both absent from Claude's identity and authorisation findings, and keeps the two paths explicitly distinct." }, { "concept": "Grok fn-validate-against-iso-register", "disposition": "accepted as a new function", "rationale": "External-register reconciliation with divergence recorded as evidence is not covered by Claude's internal validation or version-diff functions and is essential for a model keyed on a registry-assigned identifier." }, { "concept": "Grok venue-class-and-perimeter", "disposition": "deferred", "rationale": "The SI, APA, ARM and CTP perimeter is a genuine gap because ISO 10383 assigns MICs to facilities that are not multilateral venues, but the finding's description states that an instance of this model may be an SI or DRSP, which contradicts Claude's scope statement and out-of-scope list. Verbatim copy is refused; a re-worded exclusion-side finding is queued for research." }, { "concept": "Grok operating-segment-and-listings", "disposition": "rejected, one gap deferred", "rationale": "Largely duplicates f-segment-and-order-book-hierarchy and f-admission-of-tradable-objects, and its artifact identity strategy keys on the admission event time, which violates the base model's rule that no date-like value is ever part of an identifier. The place-of-listing versus place-of-trade versus reporting-only role distinction is a real gap and is deferred instead." }, { "concept": "Grok iso-10383-mic-identity", "disposition": "rejected as duplicative", "rationale": "f-venue-identity-codes already covers operating and segment codes, operator LEI, published names, country, city and registry status with an artifact and identity strategy; a second identity finding would create a divergent copy of the same registry extract." }, { "concept": "Grok operator-lei-and-location", "disposition": "rejected as duplicative", "rationale": "Operator LEI and registry country and city are already carried by f-venue-identity-codes, which additionally distinguishes registry location from matching-engine location. Only the published website field is new, which is too thin to justify a node." }, { "concept": "Grok membership-and-fair-access", "disposition": "rejected as duplicative", "rationale": "Covered across f-participant-membership-record, f-eligibility-and-admission-decision and f-access-channel-and-entitlements, which already model membership categories, objective and disclosed criteria, indirect access tiers, direct electronic access, sponsored access and colocation." }, { "concept": "Grok trading-calendar-halts-transparency", "disposition": "rejected as duplicative", "rationale": "Split three ways in the base model across f-session-calendar-and-phases, f-volatility-controls-and-halts and f-pre-and-post-trade-transparency, each with its own artifact; merging them back into one node would coarsen the base structure." }, { "concept": "Grok post-trade-and-data-bindings", "disposition": "rejected as duplicative", "rationale": "f-clearing-arrangement-binding and f-settlement-terms-and-downstream-observation already hold the venue-side bindings with a deliberate inline-only rationale, and reporting destinations are carried by f-exception-dispute-and-referral as supply bindings." }, { "concept": "Grok public-register-and-interop-codes", "disposition": "rejected as covered by service layers", "rationale": "Register provenance, master-versus-alias identifier priority, alignment-not-conformance and minimum-disclosure classification are all already binding rules in the base model's artifact rules, canonicalisation, compatibility rules, policies and access section, plus fn-export-and-import-via-alignments. Its one distinctive element, the publication versus implementation date split, arrives with the accepted MIC lifecycle finding." }, { "concept": "Grok rulebook-governance-and-emergency", "disposition": "rejected, hazard gap deferred", "rationale": "Rulebook identity and version sit in f-rulebook-version-and-governance, emergency intervention in f-volatility-controls-and-halts, and recordkeeping and clock synchronisation in f-record-retention-and-clock-traceability. The declared hazard and failure-mode question has no home in the base model and is queued for research rather than imported inside a duplicative node." }, { "concept": "Service-layer merge precedence", "disposition": "Claude scope governs the merge", "rationale": "Grok's service layer and scope text disown individual orders, quotes, trades and matching execution. Merging those statements verbatim would place a self-contradiction next to the accepted aggregate scope, so Grok service-layer content may only be added where it is additive and silent on scope; any Grok statement that narrows ownership of order, quote, trade, matching or price-formation records must be dropped." }, { "concept": "Grok source list merge and reference remapping", "disposition": "required before any verbatim copy", "rationale": "The two packs use colliding SRC identifier namespaces: Grok SRC-003 is MiFID II while Claude SRC-003 is the ISO 10383 registry. The accepted findings and function carry Grok-namespace refs, so Grok's MiFID II, SEA 1934, MiCA, ISO 10383 standard, RA FAQ and Release 2.0 factsheet entries must be merged into the base source list and every copied ref remapped, or the draft will cite the wrong instruments." }, { "concept": "Registry record entry_kind 'standalone-mm'", "disposition": "treated as record-plane packaging only", "rationale": "It is a registry packaging label with no subject-model semantics and must not be written into the subject-model entry kind, which is set to aggregate on the evidence of the consistency boundary." } ], "publicationHolds": [ "Source and live-version verification: all fifteen base sources plus the six merged Grok sources must be re-fetched and confirmed at their pinned versions before publication, including the EUR-Lex consolidated texts, the ISO 10383 MIC list publication of 10 August 2026 with its 24 August 2026 implementation date, the CFTC DCM page, the SEC Form ATS-N page and the FIX EP284 order-state document.", "Cross-jurisdiction multi-profile validation is outstanding: structural evidence is EU and US plus two global standard-setters, and Asian, Latin American, African and Middle Eastern venue regimes were not independently verified in either pass, so no profile beyond EU and US may be presented as validated.", "Source-identifier namespace merge: the accepted Grok findings and function carry Grok-namespace source_refs that collide with base source IDs; the merged source list and a complete ref remap must be produced and checked before the deterministic verbatim copy is executed.", "Service-layer merge precedence must be enforced: Grok service-layer and scope statements that disown order, quote, trade, matching or price-formation semantics must be dropped rather than merged, otherwise the published draft contradicts its own aggregate scope.", "The registered relations array is empty, so all proposed composition links to instrument, entity, infrastructure, contract, enforcement, reporting, authority, benchmark, registry, field-set, order-state and clock-profile models are candidate proposals and not enforceable contracts; cross-model ownership statements must be labelled as such.", "https://ver.cy/model-agent-protocol.md is an unpublished dependency for the AGENTS.md interface and processes URLs and must be resolved or explicitly flagged as pending in the draft.", "Evidence-quality hold: the ISO 10383:2012 full text is paywalled and its definitions were taken from the catalogue abstract, registration-authority FAQ and Release 2.0 factsheet, and the IOSCO principles PDF was not directly retrievable and rests on a supervisory summary as corroboration.", "Privacy hold: client identification codes, natural-person decision-maker identifiers and personal data in membership records are carried as fields without a data-protection basis, subject-rights route or cross-border transfer rule; this gap is delegated to the adopting Dimension and must be stated in the draft." ], "deferredResearch": [ "Re-research a boundary-guard finding for MIC-bearing facilities that are not multilateral venues - systematic internalisers and the APA, ARM and CTP data-reporting service providers - worded from the exclusion side so it cannot be read as admitting them as instances of this aggregate.", "Research the place-of-official-listing versus place-of-trade versus trade-reporting-facility role per admitted object, with an identity strategy that does not key on the admission event time, for addition to the tradable scope layer.", "Decompose venue-declared hazards, failure modes, resilience and system-safeguard regimes under PFMI Principle 17 and CFTC core principle 20, which both passes acknowledge but neither models.", "Establish whether non-EU and non-US venue licensing regimes (Japan FIEA, Hong Kong SFO, MAS, SEBI, CSRC, CVM) can be carried as jurisdiction profiles against the existing authorisation-class structure, using primary texts.", "Research MiCA crypto-asset trading platforms and EU DLT Pilot Regime venues against the multilateral recognition test, including when a token makes the platform a MiFID trading venue instead.", "Research fee, tariff, rebate and market-data licensing schedules, which are disclosed on Form ATS-N and materially shape routing behaviour but are only touched through market-data terms in this pass.", "Determine whether non-financial marketplaces - procurement portals, agricultural spot markets, warehouse-receipt markets, spectrum and capacity auctions - are in-subject profiles or sibling models, since neither pass found primary support for them.", "Fetch the FIX tag 30 LastMkt and ISO 20022 PlaceOfTrade specifications as first-party technical sources so the messaging bindings can move from interoperability hold to recorded alignment." ] }, "statistics": { "sources": 23, "bundles": 6, "layers": 12, "findings": 28, "questions": 106, "artifacts": 23, "functions": 12 } }