Managed infrastructure. A separate line of business from our platform, and it does not require you to adopt it.
PrimeXM X-Core hosting
We host and operate your PrimeXM X-Core deployment: the aggregation and bridging engine, its sessions, and the colocation it sits in.
Who this is for
Brokers using X-Core who want it operated close to their liquidity and monitored by people who will notice a degrading session before clients do.
Licence position
Your PrimeXM agreement is yours and we operate under it. We hold no licence over your deployment and there is nothing of ours to disentangle if you move.
What is included.
- 01
Provisioning and configuration of X-Core as your agreement covers.
- 02
Colocation selected for proximity to your providers and your platform.
- 03
FIX session setup, maintenance and credential rotation per provider.
- 04
Aggregation and bridge configuration, changed on instruction and recorded.
- 05
Monitoring of sessions, price continuity, latency between hops and reject rates.
- 06
Configuration backups with restore to a known-good state.
The useful half. Anyone can list what is included.
What is not included.
Stated up front so you are not finding it out during an incident. If something you need is on this list, say so before you sign rather than after.
- The PrimeXM licence and your commercial relationship with them.
- Liquidity provider agreements and credit lines.
- Your risk and routing policy. We implement it; we do not set it.
Structure, not numbers. The targets are figures and none is verified yet.
How support is structured.
Response targets are numbers, and no number appears on this site until it carries its definition and its measurement. What can be stated now is the shape: what starts the clock, how severity is decided, and what counts as finished.
- What starts the clock
- A ticket raised through the support channel, or an alert from our own monitoring — whichever comes first. If we detect it before you report it, the clock started when the monitor fired, not when you noticed.
- Severity, set by impact not by opinion
- Severity is defined by what a client cannot do: trade, deposit, withdraw, or log in. It is not negotiated per ticket, and it is not lowered because a workaround exists.
- Escalation path
- One queue, and it is engineers rather than a first line reading a script. Escalation is by elapsed time against severity, automatic, and does not require you to ask.
- What counts as resolved
- Service restored and cause identified are two separate states, and the ticket does not close on the first one. You get the cause in writing.
How a migration runs.
- 01
Inventory
Providers, sessions, current aggregation rules, and the latency profile you have today.
- 02
Target configuration
Aggregation and bridging written down before it is built.
- 03
Session build
Sessions established and validated per provider.
- 04
Shadow running
New configuration observes real prices without routing real flow.
- 05
Staged cutover
Flow moved incrementally, previous configuration one instruction away.
- 06
Handover
Configuration, monitoring access, escalation contacts, runbook.
Technical detail.
| Components | X-Core aggregation and bridging, per your agreement. |
|---|---|
| Colocation | Selected for proximity to providers and platform. |
| Monitoring | Sessions, price continuity, per-hop latency, rejects. |
| Configuration | Version-controlled and restorable. |
Pricing.
Figures not published yet. Setup and monthly pricing for this service is a commercial decision that has not been made, and inventing a “from” number would be the first thing on this page that was not true. What is settled is what you get for it — the scope above is the complete list, and the boundary section is the complete exclusion list. When figures exist they go through the same gate as every other number on this site.
Questions that come up.
- Can you tell us where our latency is going?
- Per-hop timing is monitored, so we can say which leg is slow rather than that "the network is slow". Publishing a figure for it is a separate matter — see the open items below.
- What if PrimeXM and our platform disagree about a fill?
- We hold the session logs on both sides and will reconstruct the sequence for you. Being the party that operates both ends is the reason that is a query rather than an argument.
- Do we have to move platform to use this?
- No. This is hosting and operation of the deployment you already chose. Nothing here requires changing your platform.
7open items on this page
- Which X-Core versions and configurations we have run in production.
- Per-hop latency figures, which need their measurement endpoints, statistic, window and sample size before publication.
- Response and resolution targets per severity — these are figures and none is verified yet, so no number appears on the page (see /trust/execution for the rule).
- Uptime commitment, and the measurement window it is calculated over.
- Pricing: setup and monthly figures per configuration.
- A dedicated infrastructure enquiry route. The demo form is for the platform and would be the wrong intent here, so the CTA currently points at the support plans page.
- Confirmation of our current data-centre footprint, so the colocation options can be listed by name rather than described.
Next step.
The support arrangement behind this service is the thing worth reading before you talk to anyone, including us.
A dedicated enquiry form for infrastructure work is outstanding — it is on the list above. The demo form is for the platform and would be the wrong thing to send you to.