Running a Venue That Never Closes: The Ops Posture 24/7 Multi-Asset Demands
A venue that runs 168 hours a week is a different operational animal from one that runs 40. Most of the design decisions that quietly worked on a Monday-to-Friday exchange stop working the moment the platform stays open through the weekend. Recon jobs that assumed a nightly close start missing settlements. Deploy windows disappear. The support queue never empties. Every incident happens somewhere in a follow-the-sun rota rather than during the ops director's working day.
This is a playbook for operators licensing or building a 24/7 multi-asset venue. The trading pitch ("we never close") is easy to write. The ops posture underneath is where most implementations fail.
Why Most Competitors Are Really 5x24, Not 24/7
On the marketing page, everyone is 24/7. On the actual ops rota, most competitor venues are staffed like a bank. Business hours in one timezone gets full desk coverage. Overnight gets a skeleton crew and a pager. Weekends get a chatbot, a Zendesk queue that pretends to be monitored, and a first-response SLA measured in hours.
That model works right up until the moment a client tries to lift margin at 03:00 on a Sunday, or an ops-visible incident hits during the Tokyo open on Christmas Day. The venues that staff for real 24/7 across three shifts, with equal weight given to weekend and overnight windows, capture the flow the 5x24 venues cannot serve. It is the single biggest operational differentiator in the multi-asset perpetuals space right now.
The reason most venues do not staff this way is cost. Three shifts across three timezones with genuine weekend cover roughly triples the ops payroll versus a single-shift model. That cost is the entry ticket to hosting a book that actually trades continuously.
Follow-the-Sun Staffing: What Three Shifts Actually Requires
The pattern that works, distilled from ~30 years of the team's combined experience shipping venue infrastructure:
- Three geographic hubs, minimum. Something like APAC (Singapore or Sydney), EMEA (London or Dublin), Americas (New York or Toronto). Each hub owns an 8-hour window with a 30-minute overlap on either side for handoff.
- Documented handoff protocol. A written state-of-the-book summary at every shift boundary — open incidents, elevated-risk positions, planned changes, pending client escalations. Not a Slack scroll-back. A structured template.
- Equal seniority across shifts. The overnight and weekend shifts cannot be junior-only. A P0 that hits at 04:00 UTC on a Saturday needs an engineer who can restart the matching engine and a risk manager who can approve a manual liquidation. If those decisions have to escalate to a day-shift lead in London, the venue is 5x24 with a night watch, not 24/7.
- Rotating on-call for depth roles. Not every specialist needs a full three-shift rota. Compliance, treasury, and senior engineering can run on-call with defined response SLAs (typically 15 minutes for P0, 1 hour for P1). The frontline (trading ops, risk, first-line support) has to be always-on.
- Timezone-neutral tooling. Every ops surface has to display in both UTC and the operator's local time. World-clock context in every header. Session-open badges (Sydney / Tokyo / London / New York) so the on-call engineer knows without thinking which markets are live at the moment of the incident.
Session-Aware Ops Surfaces
A 24/7 venue does not have quiet windows in the aggregate, but individual symbols absolutely have session structure. A US equity perp at 03:00 UTC is trading against a closed underlying with thin arbitrage; the same symbol at 14:30 UTC is trading against the NYSE open with tight two-way flow. The risk posture on that symbol at those two moments is completely different.
Ops surfaces have to reflect that:
- Per-symbol session state. Every symbol tile shows OPEN / RESTRICTED / CLOSED against its underlying market, not just a green dot for "the venue is up". Forex majors flip to RESTRICTED on Friday 22:00 UTC and back to OPEN on Sunday 22:00 UTC; equity perps flip on their own cadence; crypto stays OPEN.
- Session-boundary alerts. The engine should emit an alert when a symbol crosses a session boundary, so the on-call desk knows to expect a spread widening or a gap. These are not incidents; they are events. The ops team wants them logged and visible, not silenced.
- World Clock in every header. UTC, local, and session-open badges for the four majors (Sydney, Tokyo, London, New York) should be visible without a page change. The on-call engineer at 04:00 anywhere needs to know at a glance whether they are in the Tokyo open, the London pre-open, or a genuinely quiet window.
- Session-adjusted margin schedules. Maintenance margin on a forex major during the Friday-to-Sunday closed window is not the same as during the London session. If the risk engine cannot adjust per-session, the venue is under-margined for the risky window or over-margined for the liquid one.
Monitoring Cadence Without a Quiet Window
A legacy exchange runs its heavy monitoring during the day and lets things quiet down overnight. A 24/7 venue does not have that luxury. Monitoring has to be tiered by frequency, and the frequency has to be appropriate to the failure mode, not to the wall clock.
A sensible cadence for a multi-asset perpetuals venue:
| Cadence | What runs | Why |
|---|---|---|
| Every second | Matching-engine liveness, WS feed heartbeat, mark-price feed freshness | Any lag here is a live-book incident |
| Every minute | Position vs balance recon delta, insurance-fund level, HOUSE net exposure | Slow drifts caught before they compound |
| Every 5 minutes | Book-seeder heartbeat, per-symbol funding cycle progression, stale-quote sweeps | Middle-tier degradation that would otherwise present as a client complaint |
| Every hour | Fee accrual vs published schedule, cross-venue mark divergence, systemd watchdog audit | Slow-moving reconciliation |
| Every 8 hours | Funding settlement close-out, per-symbol cadence check | Aligned to the funding cycle, not the calendar day |
| Daily (rolling window) | Off-site backup, retention-window audit, admin-audit log flush | The one job class that still runs on a 24-hour cadence — but as a rolling window, not at midnight |
The important shift for operators coming from a traditional venue: there is no "end of day". Every job that used to run at midnight has to be either rewritten as a rolling window or attached to a session boundary that means something for the specific symbol involved.
Deploys Without a Maintenance Window
The single biggest architectural constraint 24/7 imposes: no planned outages. A venue that has to shut down to ship a patch is a venue that will lose the book to a competitor that does not.
The pattern that works:
- Blue/green matching-engine shards. Two instances per symbol group. Drain one behind the load balancer, upgrade it, re-attach, drain the other. Order books stay visible throughout; only new orders on the actively-cycling symbol pause briefly (measured in seconds, not minutes).
- Backwards-compatible schema changes. Every migration has to work in both the old and new binary version simultaneously, because during a rolling deploy both are live. Additive columns are safe; renaming or dropping is not, and needs a two-step deploy with an intermediate compatible state.
- Positions and orders survive restarts. The matching engine has to be able to lose its process at any moment and come back with the full book intact. That means state-of-record lives in PG, snapshots are taken frequently enough to bound replay cost, and trade replay on boot fills the gap. Snapshot-only recovery misses fills that happened between snapshot and crash — a real incident from a real venue.
- Feature flags for anything user-visible. Ship the code dark, flip the flag when the market is quiet for that specific instrument (per-symbol quiet windows exist even when the aggregate does not). Roll back by flag, not by redeploy.
- Two-shard minimum for any stateful service. Book seeder, aggregator, hedge router — none of these can be single-instance if the venue is 24/7. The maintenance-restart pattern of "take it down, upgrade it, bring it back" is not compatible with a live book.
Reconciliation Without a Daily Close
Most brokerage back-office logic assumes a T+1 recon cycle: batch the day's trades, generate statements, reconcile balances against custodian, close the books. That whole pipeline breaks when there is no "day".
The replacement pattern is continuous reconciliation with rolling audit windows:
- Position-vs-ledger recon every minute. Not every night. If the engine's view of a client's position diverges from the ledger by more than epsilon, the alert fires within 60 seconds, not by tomorrow morning.
- Statement generation as a rolling 24-hour window. Any client can pull "my last 24 hours" at any moment, computed against the closing state at whatever T-24 boundary matters for them. "End of day" as a concept is replaced by "end of your viewing window".
- Funding true-up at the funding cycle, not the calendar day. Every 8 hours for crypto, per-symbol cadence for forex and other asset classes. See Per-Symbol Funding Cadences for the mechanics.
- Custodian recon on the custodian's cadence. Crypto custodians settle on-chain when they settle. Forex prime brokers run T+1 or T+2. The venue's recon system has to speak both languages simultaneously without collapsing to the slowest one.
Customer Support at 03:00 Sunday
A client trading at 03:00 on a Sunday will hit support at 03:00 on a Sunday. If the first-response SLA is "next business day", the client will not come back.
The minimum support model for a genuine 24/7 venue:
- First-line support staffed on the same three-shift rota as ops. Not a night-shift bot with a day-shift escalation queue. Real humans on all three shifts, with authority to resolve tier-1 issues without a callback.
- P1 escalation path that works at any hour. A client who cannot log in at 04:00 on a Saturday needs a human within 15 minutes. That requires an on-call rotation with defined response SLAs and a paging system that actually pages, not an email inbox.
- Async and sync channels both live 24/7. Ticketing, chat, and phone all covered on every shift. Some clients prefer async; institutional clients calling about a live-book issue want a voice on the line.
- Knowledge base written for self-service at 3am. Because most 3am tickets are password resets, 2FA lockouts, and "where do I click to enable the API". A KB that resolves 60%+ of tier-1 volume without a human means the humans on the overnight shift are free to handle the actual incidents.
What Basis Points Ships
Every ops surface in the Basis Points platform is built for a genuinely 24/7 venue, not a 5x24 one dressed up with an on-call rota. World Clock in the header on every page, showing UTC + local + Sydney/Tokyo/London/NY session badges. Per-symbol session state on every symbol tile. Session-boundary alerts wired into the ops feed. Position-vs-ledger recon on a one-minute cadence. Funding cycles per-symbol, not per-calendar-day. Deploy pipeline is blue/green with backwards-compatible schema migrations and trade-replay-on-boot for the matching engine.
The operator inheriting the platform gets the ops surfaces already built — what they still have to bring is the three-shift staffing model, the escalation protocols, and the discipline to actually treat the overnight and weekend shifts as first-class. The team behind the platform has roughly 30 years combined shipping matching engines, hedging stacks and venue infrastructure, most of it against real 24/7 books. The scars are baked into the defaults.
24/7 multi-asset is the biggest moat in the current perpetuals landscape, if the operator can genuinely operate it. Most competitors cannot. Getting there is a design and staffing choice made deliberately, at the platform layer and in the ops org, before the first client trades a weekend fill.
Frequently Asked Questions
What does 24/7 actually cost an operator versus a 5x24 model?
Roughly triple the ops payroll for equivalent coverage — three geographic shifts, senior on-call on each shift, and full weekend cover instead of a skeleton crew. Plus the infrastructure cost of a deploy pipeline that never uses a maintenance window (blue/green shards, backwards-compatible schema migrations, trade-replay-on-boot). Most competitors budget for one and skip the other; the operators who fund both capture the flow the 5x24 venues cannot serve.
How do we handle deploys when the venue never closes?
Blue/green matching-engine shards drained one symbol at a time behind a load balancer. Every schema migration has to work in both binary versions simultaneously because both are live during the rolling deploy. Feature-flag anything user-visible so it ships dark and flips per-symbol during a quiet window for that instrument. Anything that requires a platform-wide outage window is architecturally incompatible with 24/7.
What does the recon cadence look like when there is no daily close?
Position-vs-ledger recon runs every minute, not every night. Funding settlement aligns to the funding cycle (typically 8h crypto, per-symbol cadence for other asset classes), not the calendar day. Client statements are generated as a rolling 24-hour window at request time. Custodian recon runs on the custodian's cadence (T+1 or T+2 for prime brokers, on-chain settlement for crypto custodians) rather than collapsing everything to the slowest cycle.
How do we staff overnight and weekend shifts without them becoming second-class?
Equal seniority on every shift, documented handoff protocols at every shift boundary, and enough authority on the overnight and weekend desks to resolve P0 incidents without escalating to a day-shift lead. If the Saturday-night engineer has to wake up the London ops director to approve a manual liquidation, the venue is 5x24 with a night watch, not genuinely 24/7.
What monitoring frequency is appropriate for a 24/7 venue?
Tiered by failure mode, not by wall clock. Live-book systems (matching engine, WS feeds, mark price) monitored every second. Position and balance recon every minute. Middle-tier degradation (book seeder, funding cadence progression) every five minutes. Slow-moving reconciliation every hour. Funding-cycle jobs every 8 hours aligned to the cycle. The one job class still on a 24-hour cadence — backups, retention audits — runs as a rolling window, not at midnight.
Can 24/7 be phased in, or does it have to be day-one?
It has to be day-one for the platform and can be phased in for the org. The matching engine, deploy pipeline, recon jobs and ops surfaces all need to be 24/7-native from launch — retrofitting them later means an outage window during the migration, which is exactly what the design was meant to avoid. The staffing rota can start thinner and scale up as book volume justifies additional shifts. Most operators launching on the Basis Points platform start with two shifts plus weekend on-call and move to full three-shift coverage inside the first six months.
Evaluating the platform?