System reference
See the system.
The reference topology, the protocols between each layer, the deployment models available and the controls that apply in all of them. Select any layer to inspect it.
Simplified reference topology · production deployments vary by tenancy model, jurisdiction and liquidity configuration
Layer 01
Liquidity providers
External venues supplying executable prices. CoreVex does not provide liquidity; it connects to it, aggregates it and proves the quality of the execution obtained.
Protocols
Layer 02
CoreVex Connect
The owned connection. Aggregates best bid and offer across venues, applies per-tier markup, filters last-look behaviour, and maintains hot-standby sessions for failover.
Protocols
Layer 03
Execution engine
Holds the book. In-memory order and position state, netting across segments, and dual-layer booking that keeps both sides on one symmetric price feed.
Protocols
Layer 04
Risk engine
Clears every ticket before routing, classifies accounts continuously, and keeps internalised exposure inside a published ceiling with automated break-even hedging.
Protocols
Layer 05
Client surfaces
Where the operator's client actually meets the system: a browser-native terminal, a mobile PWA, MetaTrader running side-by-side, and an institutional FIX tier.
Protocols
Layer 06
Operations modules
Onboarding, client records, settlement, managed accounts and support — all reading and writing the same event bus, all under the same permission model.
Protocols
Layer 07
Data & reporting
The plane that makes everything else provable: market data, derived analytics, execution-quality measurement, statements, audit export and regulatory extracts.
Protocols
Metrics shown per layer are design targets with a published measurement method · see metric classification on the homepage
Four protocols, one contract.
Every integration surface follows the same rules: versioned schemas, scoped credentials, idempotent writes, signed callbacks and generated documentation that cannot drift from the implementation.
Synchronous · read
REST
Control plane and query surface. OpenAPI 3.1 schemas, semantic versioning, cursor pagination, scoped API keys and per-key rate limits.
Streaming
WebSocket
Binary frames with delta updates for prices, depth, positions and derived signals. Subscription-scoped, heartbeat-monitored, resumable within a window.
Asynchronous · out
Webhook
Signed event callbacks for lifecycle changes: onboarding state, settlement outcome, risk escalation, ticket events and reporting availability.
Institutional
FIX
4.4 and 5.0 SP2 for venue connectivity and for the institutional client tier, with session management, sequence recovery and per-session latency reporting.
Non-negotiables across every surface
- Versioned schemas with a published deprecation window
- Scoped credentials, least privilege by default
- Idempotency keys on every state-changing call
- Signed callbacks with replay protection
- Append-only audit of every API action and actor
- Rate limits declared in the response, not guessed
- Documentation generated from the schema
- Sandbox environment with deterministic fixtures
Four tenancy models. One codebase.
Isolation is selected on jurisdiction, data-residency obligation, volume and the operator's own security posture — not on price tier.
| Model | Isolation | Keys & custody | Data residency | Provisioning | Typical selection driver |
|---|---|---|---|---|---|
| Dedicated cloud | Logical · per-tenant namespace | CoreVex-managed, operator-auditable | Region selectable | Days | Speed to market, lower capital commitment |
| Single tenant | Full · own database and network | Split control, operator-visible | Region selectable | Weeks | Regulated entities, audit expectation |
| On-premises | Physical · operator data centre | Operator-held | In-country | Weeks–months | In-country processing obligation |
| Co-located | Physical · beside liquidity | Split control | Exchange facility | Weeks | Execution quality measured in microseconds |
Shared across all models
- Same module set and same API contract
- Same control plane and permission model
- Same audit-trail format and export
- Same monitoring and alerting definitions
Resilience
- Hot-standby venue sessions on a second site
- Documented recovery point and time objectives per module
- Failover rehearsed before go-live, not after an incident
- Degraded-mode behaviour defined per surface
Data controls
- Encryption in transit and at rest
- Field-level protection on identity data
- Retention and deletion configurable per jurisdiction
- Access logged, time-bound and least-privilege
One place where permissions, limits and rules are defined.
Every module reads the same control plane. That is what makes the audit trail coherent: a limit changed in one place produces one logged event that explains behaviour change across seven layers.
Architecture · next step
Take the reference topology apart with an engineer.
The architecture pack contains the full topology, protocol specifications, control definitions, deployment options and the measurement method behind every figure published on this site.