CoreVex · Financial Market Infrastructure
The infrastructure
behind the broker.
CoreVex engineers the execution, risk, automation, data and operational systems that power modern brokerage businesses. The broker owns the client relationship. CoreVex operates the layer underneath it.
Design targets and architecture benchmarks · not independently verified production results · see metric classification
Telemetry panel is an illustrative representation of the operating state · not a live production feed
CoreVex sits underneath the visible financial business.
A broker is a customer relationship, a brand and a balance sheet. Underneath all three is an operating system: connectivity to liquidity, an order and risk engine, onboarding, payments, client records, reporting and support. That system is what CoreVex builds, licenses and operates.
We are not a retail broker, a trading platform or a marketing wrapper. We are the infrastructure layer — engineered, documented, auditable and deployed under the operator's own name and permissions.
CoreVex does not contract with the end client and does not hold client money · the operator retains the regulated relationship
One operating layer.
Multiple financial systems.
Nine layers, one back-end, one login and one audit trail. Select a layer to see what it does, why it matters, its technical surface and the metrics it is held to.
What it does
Owns the connection between the operator's book and external liquidity: FIX sessions to Tier-1 banks, prime-of-primes and non-bank market makers, with aggregation, last-look filtering and dynamic per-tier markup.
Why it matters
A third-party bridge is unobservable latency and a per-lot cost you cannot remove. Owning the connection makes best execution provable rather than asserted.
Technical surface
Key metrics
What it does
Holds the book. An in-memory order book with netting, dual-layer booking and a smart router that dispatches cleared flow either externally to liquidity or internally to a bounded risk pool.
Why it matters
Routing is a revenue and risk decision made thousands of times a second. Making it deterministic and logged turns the book into something the risk function can actually read.
Technical surface
Key metrics
What it does
Scores every ticket before routing against market state and session context, classifies accounts continuously rather than statically, and keeps any internalised exposure inside a published ceiling with automated break-even hedging.
Why it matters
Unbounded internalisation is a balance-sheet event waiting to happen. A bounded, hedged pool is a risk decision with a number attached to it.
Technical surface
Key metrics
What it does
One record per client merging identity, verification state, funding history, trading behaviour, risk tier, support history and revenue contribution — with segmentation, campaign automation and partner hierarchy on top.
Why it matters
A CRM disconnected from the book is a contact list. Connected, it becomes the control surface for retention, suitability and revenue management.
Technical surface
Key metrics
What it does
Managed-account infrastructure (PAMM, MAM, LAMM) with automated profit share, an investor portal with collateralised portfolio credit, and a treasury layer for firm funds including a digital-asset settlement rail.
Why it matters
Fee revenue that does not depend on client losses is the only structurally durable revenue line a brokerage has. This layer builds it.
Technical surface
Key metrics
What it does
A single data plane for prices, depth, tick history, derived analytics, execution-quality measurement, client statements and regulatory reporting extracts — exposed over WebSocket and REST with scoped keys.
Why it matters
Everything downstream — terminals, risk, reporting, marketing — is only as trustworthy as the data plane feeding it. Consolidating it removes reconciliation disputes.
Technical surface
Key metrics
What it does
Runs funding and withdrawals through a single pipeline: rule checks, screening, automatic rail selection, ledger posting with four-eyes, and instant escalation of outliers to a named human with full context attached.
Why it matters
Clients do not judge a broker on spreads. They judge it on the first withdrawal. Every hold must be a logged rule with an owner, never a discretionary retention tactic.
Technical surface
Key metrics
What it does
Document capture and validation, liveness detection, screening against sanctions, AML and PEP sources, client categorisation, appropriateness assessment, promotion approval workflow and a continuously exported evidence trail.
Why it matters
Compliance that lives in a spreadsheet does not survive an audit. Compliance encoded as non-overridable engine parameters does — and it does not slow the standard case down.
Technical surface
Key metrics
What it does
Places operating leadership around the infrastructure: fractional CTO, CRO and COO capacity, compliance leadership, technology and vendor due diligence, unit-economics modelling and launch governance.
Why it matters
Systems do not make decisions. The layer fails when nobody owns the trade-off between revenue, risk and capital — so ownership is part of the offer.
Technical surface
Key metrics
Seventeen modules, organised into five decisions.
Operators do not buy modules. They buy outcomes: faster execution, lower operating cost, deeper client capital, a route to market and leadership that has run the system before. Each pillar is a decision, with the modules that implement it underneath.
Core execution
Connectivity, booking, terminal and the data plane beneath all three.
Robotic operations
The standard case handled by machine; the exceptional case routed to a named human.
Capital & settlement
Managed accounts, investor credit and treasury rails that clear around the clock.
Broker launch
An engineering programme from entity and banking to first live ticket.
Advisory
Operating leadership placed around the infrastructure, not beside it.
See the system.
Nothing in the CoreVex stack is decorative. Every node has a protocol, an owner, a failure mode and a documented recovery path. The diagram below is the production topology in simplified form.
Simplified representation of the CoreVex reference topology · client-specific deployments vary by jurisdiction, tenancy and liquidity configuration
Every section answers two questions.
The person who signs the contract and the person who integrates the system are rarely the same person, and they need different facts. CoreVex publishes both, side by side, without translation loss.
Switch the view to see the same operating layer described in commercial terms and in technical terms.
The operating floor, before and after.
Comparison against a conventional white-label retail brokerage operating model. Right-hand column is the CoreVex design target for a deployed stack.
| Function | Conventional white-label model | CoreVex operating layer | Mechanism |
|---|---|---|---|
| Onboarding | 1–3 business days, manual review, drop-off at document stage | <60 s standard case, screening automated, exceptions to a named officer | L08 Compliance |
| Withdrawals | 1–5 business days, batch processed, discretionary holds | <3.2 s for 90% of flow, 24/7, every hold a logged rule | L07 Payments |
| Client support | Business hours, human queue, inconsistent answers | 92% resolved by NLP layer, sub-second, 6+ languages, context attached | L04 Client ops |
| Terminal | Licensed third-party platform, per-seat cost, vendor roadmap | Proprietary browser engine alongside MetaTrader, no licence ceiling | L02 Execution |
| Liquidity access | Third-party bridge, per-lot fee, unobservable latency | Own FIX connection, no per-lot vendor fee, per-session latency reported | L01 Liquidity |
| Risk classification | Static client types set at onboarding, reviewed occasionally | Continuous quantitative tiers recomputed on a short cycle | L03 Risk |
| Hedging | Manual desk, discretionary, overtime-dependent | Automated break-even hedging inside a published exposure ceiling | L03 Risk |
| Operational headcount | ≈42 FTE floor across KYC, back office, support, dealing | ≈8 specialists: risk, compliance, engineering, growth | Cross-layer |
| Reporting | Manual extracts, spreadsheet reconciliation, audit scramble | Continuous export from one data plane, evidence on demand | L06 Data |
Left column describes a typical retail white-label operating model, not a named competitor · right column figures are design targets from validated operating models · actual results are client-specific and depend on configuration, jurisdiction and volume
Four tenancy models. One codebase.
Deployment is a regulatory and commercial decision, not an afterthought. The same modules ship into four isolation models, selected on jurisdiction, data-residency obligation and volume.
Dedicated cloud
Isolated infrastructure in a shared region, operated by CoreVex. Fastest route to production with the lowest capital commitment.
Single tenant
A dedicated instance per operator with its own database, keys and network boundary. The standard choice for regulated entities.
On-premises
Deployed inside the operator's own data centre or private cloud, for jurisdictions that require in-country processing and custody.
Co-located
Placed beside liquidity in LD4 or NY4 for operators whose execution quality is measured in microseconds and negotiated in rebates.
Built for the operators, not the audience.
Segment 01
Retail & multi-asset brokers
Licensed or offshore brokers replacing a white-label stack with infrastructure they control — or launching a second brand on the same back-end.
- Removal of per-seat and per-lot vendor cost
- Own terminal roadmap and branding
- Execution-quality reporting they can publish
Segment 02
Prime brokers & PoPs
Firms whose product is connectivity and credit. They need aggregation depth, FIX tiering, margin and netting logic, and clean reporting to their own introducees.
- Multi-venue aggregation with dynamic markup
- Institutional FIX tier and credit controls
- Introducee hierarchy and settlement automation
Segment 03
Prop firms & trading groups
Evaluation businesses and multi-manager desks that need automated drawdown enforcement, funded-account provisioning and disciplined flow routing.
- Automated evaluation rules and provisioning
- Manager vetting against trading history
- Managed-account infrastructure on the same book
Segment 04
Family offices & wealth managers
Multi-strategy allocators needing consolidated execution, portfolio credit facilities and institutional reporting across asset classes.
- Collateralised credit without closing positions
- Consolidated reporting across venues
- Algorithmic allocation infrastructure
Segment 05
Fintech & payment operators
Businesses adding a trading or treasury capability to an existing customer base, without becoming a technology company.
- Embeddable terminal and JS SDK
- Treasury and settlement rails
- Compliance layer with evidence export
Not a fit
Where we say no
CoreVex does not take engagements that require misrepresenting execution, obscuring routing, holding client money outside segregation, or marketing unauthorised activity.
- No retail client relationships in our name
- No client money custody
- No guaranteed regulatory outcomes
A launch is an engineering programme, not a product purchase.
Two tracks, one architecture. Offshore compresses time-to-market; licensed compresses regulatory risk. Both are run as scoped programmes with named deliverables, dependencies and gates.
Track A
Offshore launch
- Jurisdiction selection
- Formation & registers
- Costed obligations
- Corporate accounts
- PSP onboarding
- Settlement rails
- Venue selection
- FIX connectivity
- Spread & pricing model
- Module deployment
- White-label theming
- Desk & ops training
- Partner network
- First live tickets
- Post-launch tuning
Track B
Licensed launch
- Pathway mapping
- Permission scoping
- Counsel alignment
- Own-funds modelling
- Wind-down costing
- Treasury design
- Senior manager mapping
- Accountability framework
- Board & committees
- Segregation design
- Daily reconciliation
- Bank acknowledgements
- Conduct & conflicts
- Best execution policy
- Promotion approval
- Engine rule enforcement
- Evidence automation
- Audit readiness
- Post-authorisation ops
- Reporting cadence
- Supervisory liaison
Programme structure shown is the CoreVex reference plan · actual sequencing depends on regulator, jurisdiction, banking counterparties and applicant readiness
Control is part of the architecture.
Trust in an infrastructure vendor is not a badge on a footer. It is a set of mechanisms that continue to work when nobody is watching, and that produce evidence when somebody asks.
Append-only audit trail
Every state change carries an actor, a timestamp, a reason and the rule that permitted it. Immutable by design, exportable on demand.
Role-based access
Least-privilege roles per function, per environment and per jurisdiction. Privileged access is time-bound and logged.
Client-money segregation
Client funds are never firm capital. Segregated accounts, daily reconciliation, acknowledgement letters and a documented ledger trail.
Four-eyes on overrides
No single human can silently override a limit, release a payment or reclassify an account. Overrides require a second named approver.
Failover & recovery
Hot-standby sessions, second-site recovery, tested failover and documented recovery point and time objectives per module.
Continuous monitoring
Session health, latency, queue depth, screening hits and settlement failures alert to a named owner, not to a shared inbox.
Environment isolation
Development, staging and production are separated by network, credential and data boundary. Production access is exceptional and recorded.
Data controls & residency
Encryption in transit and at rest, field-level protection for identity data, residency selectable per jurisdiction, retention configurable.
Evidence, on demand
Regulatory and internal-audit evidence packs are generated from the audit trail rather than assembled by hand before a deadline.
Engineered for measurable operating states.
Every number on this website carries a classification. We do not present design targets as verified production results, and we do not present one client's outcome as a universal benchmark.
Measurement method, observation window and configuration assumptions are published in the architecture pack · figures marked design target are engineering objectives, not achieved production results · figures marked client-specific relate to a particular deployment and are not generalisable
When the system becomes the strategy.
Infrastructure without ownership drifts. CoreVex places operating leadership around the stack it builds: fractional CTO, CRO and COO capacity, compliance leadership, vendor and technology due diligence, unit-economics modelling and launch governance.
This is not consulting delivered in a deck. It is accountability for decisions that have to be made weekly, taken by people who have run the desk before.
Advisory surface
Four ways to work with CoreVex.
Commercial structure follows the decision being made: a single capability gap, a full stack, a route to market, or leadership capacity. Pricing is scoped on volume, jurisdiction and tenancy — published ranges would be meaningless without them.
Module licence
One module, deployed against an existing stack. For operators closing a specific capability gap.
- Any of the 17 modules
- API access and documentation
- Standard SLA and support window
- Integration engineering included
Full stack
All seventeen modules on one back-end, one login and one audit trail, under the operator's brand.
- Complete operating layer
- White-label theming and domains
- Dedicated or single-tenant deployment
- Priority SLA and named engineering contact
- Source-code escrow available
Launch programme
Fixed-scope build-out from entity and banking through to first live ticket — offshore or licensed.
- Offshore: 60–90 days
- Licensed: scoped per regulator
- Entity, banking, liquidity, PSP coordination
- Operating procedures and desk training
- Go-live and post-launch tuning
Advisory retainer
Fractional operating leadership and strategic counsel, scoped to named deliverables each month.
- Fractional CTO / CRO / COO
- Compliance leadership
- Due diligence and vendor assessment
- Board and investor reporting packs
Included in every engagement
- Architecture documentation
- Integration engineering support
- Append-only audit trail
- Evidence export on demand
- Migration assistance
- Named engineering contact
- 24/7 operating coverage
- Versioned API and changelog
What operators ask first.
If your question is not answered here, it is answered in the architecture pack or on a technical discovery call with an engineer — not with a sales script.
Book a technical discoveryNo. CoreVex is a technology, infrastructure and advisory provider to brokers, prime brokers, prop firms, family offices and financial operators. We do not hold client money, do not contract with retail clients, do not provide investment advice and do not provide retail execution services in our own name. The operator retains the client relationship and the regulatory permissions.
Yes. Every module is independently licensable and deployable against an existing stack, with API access, documentation and integration engineering included. Most engagements begin with one capability gap — onboarding, settlement, liquidity connectivity or reporting — and extend from there.
No. The CoreVex web engine runs alongside MetaTrader access on the same account and the same book. Operators typically keep MT4/MT5 for the segment that expects it and route new clients, copy-trading and managed-account flows through the proprietary terminal, which carries no per-seat licence ceiling.
White-label theming, domains and branding are standard on every deployment. Source-code escrow, dedicated single-tenant instances and fully on-premises deployment inside the operator's own data centre are available on Full Stack and Launch engagements, selected on jurisdiction and data-residency obligation.
Sixty to ninety days from kickoff to first live ticket is achievable when entity formation, banking and liquidity onboarding run in parallel with the technical build. Banking counterparty responsiveness is usually the critical path, not the technology. We publish the dependency graph at scoping so the risk is visible before commitment.
No, and any provider that does should be treated with suspicion. Authorisation depends on the applicant's own submission, capital, personnel, governance and the assessment of the relevant regulator. We design the systems, evidence and controls to be authorisation-ready, map the pathway, and work alongside your legal counsel — we are not a law firm and we do not provide legal advice.
English, Farsi, Russian, Arabic, Turkish and Vietnamese are live at deployment, with additional locales configurable. Intent classification, escalation rules and compliance guard-rails operate identically across languages, and tickets are routed to language-matched human agents when escalation triggers.
Every figure carries a classification: design target, benchmark, illustrative or client-specific. Design targets are engineering objectives with a published measurement method. Benchmarks compare against a conventional operating model. Client-specific figures relate to one deployment and are not generalisable. The architecture pack contains the measurement definitions.
15 — Next step
Start with the architecture, not the pitch.
A technical discovery is a working session with an engineer: your volume, your jurisdiction, your current stack, and which layers actually need replacing. You leave with a scoped dependency graph — whether or not you engage us.