Platform · Trading Infrastructure
The trading engine for event-contract markets.
A matching engine, AMM, order book, and settlement layer built to the operational standards of a derivatives exchange, and to the specific market mechanics of event contracts.
The case for a purpose-built engine
Event contracts are not a generic-derivatives use case.
Event contracts have structural properties that distinguish them from traditional derivatives: finite-horizon settlement against external sources of truth, frequently thin liquidity at market open, multi-outcome contract families, and deterministic resolution rather than mark-to-market valuation.
A generic derivatives matching engine is not designed for these properties. Markets that resolve in hours rather than years, against discrete real-world outcomes rather than continuous price series, place different demands on every layer of the stack, from liquidity bootstrapping to settlement adjudication.
Vinfotech's trading engine is built for these properties specifically. The matching engine, AMM, order book, and settlement layer are designed as a coordinated system, not as event-contract behaviour bolted onto an engine designed for something else.
01
Matching engine
A deterministic, audit-replayable matching engine implementing price-time priority across the contract families supported on the platform.
Order type support
Limit, market, immediate-or-cancel (IOC), fill-or-kill (FOK), post-only, and stop orders. Iceberg orders for member firms managing visible-versus-hidden quantity. Order modification and cancellation supported throughout the trading session.
Pre-trade risk gate
Every order passes through per-firm and per-account exposure checks before reaching the book. Position limits, notional exposure caps, and message-rate limits are enforced at the gate, not after the match.
Self-trade prevention
Configurable per-firm anti-self-cross logic, with policy options for cancel-newest, cancel-oldest, or cancel-both.
Audit-replay determinism
Every session is reproducible byte-for-byte from the event log. Order entry, modification, cancellation, match, and settlement events are captured in a single ordered stream that can be replayed deterministically for surveillance, dispute resolution, and regulatory inspection.
02
AMM and liquidity
A proactive automated market maker designed for the liquidity profile of event-contract markets, where natural two-sided flow is often absent at market open and needs to be bootstrapped.
Curve configuration per market
LMSR-style, CPMM-style, and hybrid configurations are supported on a per-market basis. Operators set initial liquidity, curve parameters, and inventory caps when the market is defined.
AMM and order book coordination
The AMM acts as a configurable counterparty to member-firm orders when book depth is insufficient. As natural two-sided flow develops, the AMM's role recedes by design, it provides the bootstrap, not a permanent crutch. Slippage is bounded by curve parameters and per-trade size limits.
Capital and inventory management
Per-market AMM inventory limits, per-outcome exposure caps, and global position controls. Operators can adjust AMM parameters mid-market within configured bounds, or halt AMM participation entirely while leaving the book open.
03
Order book and market mechanics
Contract families on one engine
Binary (Yes/No), scalar bands, and multi-outcome (N-way) contracts are supported on the same matching engine. The contract family is a market-definition parameter, not a separate code path.
Configurable market parameters
Tick sizes, lot sizes, price bands, minimum order size, and maximum order size are configured per market at definition time.
Market states
Pre-open, open, halted, closed, resolving, and settled. State transitions are deterministic, logged, and externally observable via the market data feed.
Trading session structure
Continuous trading is the default. Optional opening and closing auctions can be configured for markets where a single-price clearing event is preferred at session boundaries.
Circuit breakers and halts
Price-move-based halts and volatility-based halts are configurable per market. Operator-initiated halts are supported with full audit trail.
04
Settlement
Deterministic resolution
Every market settles against pre-declared sources of truth and pre-declared resolution rules. The resolution source and rule are bound to the market at definition time, not chosen at settlement.
Atomic settlement
Settlement is atomic across all positions in a market, partial states are not possible. Either all positions in the market are settled and payouts finalised, or the settlement transaction is rolled back.
Idempotent processing
Settlement operations are idempotent. Repeated settlement instructions for the same market produce the same final state, which is essential for recovery scenarios and operator dispute workflows.
Audit and reporting
Position-by-position settlement records are written to the event log and exposed via reporting APIs for finance, audit, and regulatory reporting.
For the surveillance side of disputes and resolution challenges, see Compliance & Surveillance.
05
Risk controls
Pre-trade
Per-firm exposure limits, per-account position limits, fat-finger price-bound checks, and message-rate limits enforced at the order gate.
Intra-trade
Kill-switches at the member-firm level, at the market level, and at the platform level. Throttles on order entry rate per firm. Manual operator overrides available with role-based authorisation and full audit trail.
Post-trade
Position reconciliation against the event log. End-of-day risk reports per firm, per market, and aggregate.
06
How it fits together.
Order flow enters through the pre-trade risk gate, passes into the matching engine which is coordinated with the AMM against a single order book, and exits through deterministic settlement with simultaneous emission to the market data feed, the audit log, and the reporting layer.
Related platform capabilities
The rest of the platform.
FIX & Connectivity
How member firms reach the engine, via FIX 4.4 and 5.0 SP2.
AI Market Operations
How markets are defined, monitored, and resolved at scale.
Compliance & Surveillance
Market manipulation surveillance, audit trails, and regulatory reporting.
Architecture & Security
Deployment models, high-availability, SOC 2 alignment.
07
Frequently asked questions.
Structured for buyer research and AI-assisted summarisation. Each answer is self-contained.
What is Vinfotech's trading infrastructure?
Vinfotech's trading infrastructure is a complete trading engine for regulated event-contract markets, comprising a matching engine, an automated market maker, an order book, and a settlement layer. It is designed for the operational standards of a derivatives exchange and the specific market mechanics of event contracts. The engine is offered as a white-label platform to exchanges, brokerages, and licensed operators.
What contract types does the matching engine support?
The matching engine supports binary (Yes/No), scalar band, and multi-outcome (N-way) contracts on the same engine. The contract family is a market-definition parameter set at the time the market is created. Operators can run all three contract families concurrently on the same platform instance.
What order types are supported?
The engine supports limit, market, immediate-or-cancel (IOC), fill-or-kill (FOK), post-only, stop, and iceberg orders. Order modification and cancellation are supported throughout the trading session. Specific order type availability can be configured per market.
Does the engine use price-time priority?
Yes. The matching engine implements price-time priority with deterministic ordering. Every match is reproducible from the event log.
How does the AMM work?
The AMM is a proactive market maker designed for the thin-liquidity profile of event-contract markets at open. It supports LMSR-style, CPMM-style, and hybrid configurations on a per-market basis. The AMM acts as a configurable counterparty to member-firm orders when book depth is insufficient, with per-market inventory limits and per-outcome exposure caps. As natural two-sided flow develops, the AMM's role recedes by design.
How does the AMM interact with the order book?
The AMM and order book are coordinated. The AMM provides liquidity when the book is thin, and steps aside as member-firm flow builds depth. Slippage from AMM-counterparty trades is bounded by curve parameters and per-trade size limits. Operators can adjust AMM parameters mid-market within configured bounds or halt AMM participation entirely while leaving the book open.
What pre-trade risk controls are in place?
Every order passes through a pre-trade risk gate that enforces per-firm exposure limits, per-account position limits, fat-finger price-bound checks, and message-rate limits before the order reaches the book. Risk limits are enforced at order acceptance, not after the match.
How does settlement work?
Settlement is deterministic, atomic, and idempotent. Every market is bound at definition time to a pre-declared source of truth and a pre-declared resolution rule. At resolution, all positions in the market settle in a single atomic transaction, partial settlement states are not possible. Settlement operations are idempotent, so repeated settlement instructions produce the same final state.
What contract resolution sources are supported?
The platform supports configurable resolution sources, bound to each market at definition time. Resolution source patterns include external data providers, official statistical agencies, market data feeds, and operator-curated sources of truth. The AI Market Operations layer handles source-of-truth selection, ambiguity detection, and resolution adjudication.
Is the engine audit-replayable?
Yes. Every trading session is reproducible byte-for-byte from the event log. Order entry, modification, cancellation, match, and settlement events are captured in a single ordered event stream. The event log is the system of record and supports deterministic replay for surveillance, dispute resolution, and regulatory inspection.
What market states does the engine support?
Markets transition through pre-open, open, halted, closed, resolving, and settled states. State transitions are deterministic, logged in the event stream, and observable via the market data feed. Circuit breakers and operator-initiated halts are supported with full audit trail.
Is the platform white-label?
Yes. The trading infrastructure operates entirely under the customer's brand, license, and regulatory framework. Vinfotech provides the underlying platform; the customer operates the venue. See the white-label platform page for the broader white-label model.
What does Vinfotech not include in trading infrastructure?
Trading infrastructure covers the engine layer: matching, AMM, order book, settlement, and risk controls. Connectivity (FIX 4.4 and 5.0 SP2) is documented on the FIX and Connectivity page. Surveillance, audit, and regulatory reporting are documented on the Compliance and Surveillance page. Market creation, monitoring, and resolution adjudication are documented on the AI Market Operations page. Deployment models and operational posture are documented on the Architecture and Security page.
Who is Vinfotech's trading infrastructure designed for?
The platform is designed for institutional operators: CFTC Designated Contract Market (DCM) license holders and applicants, brokerages and prop trading platforms adding event contracts as an asset class, and licensed operators adding a regulated event-contract vertical. The engagement model is a structured commercial arrangement, not self-serve onboarding.
Talk to us about your trading infrastructure requirements.
We work with serious operators on structured commercial arrangements. Tell us about your use case and we'll set up a briefing.