A trading venue can extend its operating hours with a software release. Sustaining that schedule across financial markets is a much larger undertaking.
When an exchange, alternative trading system, or digital asset venue offers trading across more hours, the change affects the entire operating environment. Market data must remain available, order handling must follow the correct rules, risk controls must function without interruption, and personnel must be ready to respond when something fails. External services also need compatible schedules, even when they operate under different business calendars.
This is the central challenge of 24-hour market infrastructure: the trading interface may be available continuously, but the systems behind it depend on people, technology, financial resources, counterparties, and processes that do not automatically operate on the same timetable.
The distinction becomes especially important as U.S. equity markets move toward extended overnight access. In September 2026, the Securities and Exchange Commission (SEC) held a roundtable addressing preparations for 24-hour trading, including market-data continuity, system resilience, cybersecurity, staffing, and operational readiness. The discussion reflected a broader industry transition from treating overnight activity as an exception to planning for it as a recurring operating condition.
Continuous availability changes the definition of operational readiness. A venue must establish which services remain active, which processes run on separate schedules, who owns each operational decision, and what happens when a critical dependency becomes unavailable.
The objective is not simply to keep a matching engine running. It is to maintain a controlled trading environment across changing market conditions and service windows.
Trading Sessions Need an Explicit Operating Model
Extended trading does not eliminate sessions. It changes how sessions are defined, connected, and managed.
A venue may divide its schedule into regular trading, extended sessions, overnight periods, maintenance windows, and scheduled interruptions. Each period can have different order types, eligible instruments, access permissions, market-data characteristics, risk limits, and participant obligations.
Those distinctions must exist in the operating rules as well as the trading interface. A participant should not encounter an order accepted under one session’s rules and processed under another without a defined transition.
Consider a venue that permits certain order types during the main session but restricts them overnight. The system must enforce the appropriate permissions even when an order remains active across a session boundary. Similar questions arise when an instrument becomes temporarily ineligible, a participant’s access changes, or a market-wide control activates.
A session schedule therefore functions as an operational control framework rather than a calendar displayed to users.
What a session model should define
- Eligibility: Which securities, products, participants, and order types are available during each period?
- Transitions: How are open orders, pending requests, and system states handled when a session starts or ends?
- Control changes: Which risk limits, price protections, or trading restrictions apply in each session?
- Communications: How are planned interruptions, schedule changes, and exceptional conditions announced?
- Ownership: Which team approves session changes and verifies that the transition has completed correctly?
The difficult cases often occur between sessions. A planned transition may coincide with a delayed data feed, an unsettled operational exception, or a participant experiencing connectivity problems. Procedures must account for these overlapping conditions rather than assume that each service changes state at exactly the scheduled time.
Session design also needs a clear relationship with the venue’s official trading calendar. Weekends, holidays, daylight-saving changes, unscheduled closures, and differences between international time zones can affect system behavior. A timestamp that appears unambiguous to one team may be interpreted differently by another system using a different time convention.
A reliable operating model defines the schedule centrally, distributes it consistently, and tests boundary conditions before changes reach production.
Market Data Must Remain Trustworthy, Not Merely Available
An active market needs information that participants and control systems can use with confidence. That includes prices, quotes, order status, trading restrictions, instrument reference data, and relevant market-state messages.
The challenge is that these services may come from different providers and follow different operating schedules. A venue can remain open while an external feed is delayed, a reference-data update is missing, or a downstream consumer has stopped receiving messages.
A green status indicator is not sufficient evidence that the information is fit for trading.
Market-data controls need to assess freshness, sequencing, completeness, and consistency. If a feed stops updating, the system should distinguish a quiet market from a stalled connection. If messages arrive out of order or a sequence gap appears, downstream processes must know whether the information can still be trusted.
This distinction matters most when trading continues outside the hours in which data services have historically received the greatest attention.
Build controls around data quality
A practical market-data framework should include:
- Feed health monitoring: Detect interrupted connections, unusual delays, sequence gaps, and unexpected changes in message volume.
- Source validation: Identify the origin of each feed and establish which source is authoritative for a given purpose.
- Stale-data controls: Define when a quote, reference value, or status message becomes too old for its intended use.
- Recovery procedures: Specify how missing messages are recovered, state is reconciled, and normal processing resumes.
- Consumer monitoring: Confirm that risk engines, surveillance tools, order-management systems, and user-facing applications receive the required data.
A recovery process should not silently convert incomplete information into apparently normal operation. If the system cannot establish a reliable state, it may need to restrict particular functions until validation is complete.
Market-data dependencies also extend beyond prices. Instrument eligibility, trading status, corporate-action information, participant permissions, and operational notices can influence whether an order should be accepted or how an existing position should be handled.
For venues trading multiple asset classes, those dependencies may cross providers, networks, and jurisdictions. A market can be technically connected yet operationally impaired if one essential data source is no longer updating.
The objective is to maintain a clear distinction between available data and validated data. Continuous markets require both.
Risk Controls Must Operate Across Every Active Session
Risk does not follow staffing schedules. Price movements, order surges, account restrictions, connectivity failures, and abnormal trading patterns can emerge at any hour.
A venue that extends trading must decide which controls operate continuously, which are session-specific, and which require human approval. These decisions should be documented before expanded access begins.
Some controls can run automatically. Examples include order-size limits, account-level exposure checks, price collars, message-rate restrictions, and restrictions triggered by an instrument’s trading status. Other situations require investigation or a decision from an authorized person.
Automation reduces dependence on manual intervention, but it does not eliminate the need for escalation. A control can trigger correctly while the surrounding process fails to notify the right team, preserve the relevant evidence, or prevent an unsafe restart.
Separate detection, containment, and recovery
A mature control framework treats these as three distinct responsibilities.
Detection identifies a deviation from expected behavior. This might be a surge in rejected orders, an unusual concentration of activity, inconsistent position data, or a sudden decline in market-data quality.
Containment limits the potential impact. Depending on the circumstances, that may involve restricting an account, disabling an order type, pausing a specific instrument, or suspending a service.
Recovery establishes that the underlying problem has been addressed and that normal operation can resume safely. It should include validation of system state, review of outstanding orders, confirmation of restored data flows, and appropriate authorization.
The sequence matters. Restarting a component because it appears responsive does not prove that its internal state is correct or that dependent systems have reconciled.
Risk controls should also be tested under conditions that resemble real operating pressure. A routine daytime test may not reveal problems involving reduced overnight staffing, delayed third-party support, or several simultaneous service interruptions.
The operating model should define which decisions can be made automatically, which require an on-call owner, and which demand coordinated approval across risk, technology, and market operations.
Funding and Liquidity Services Need Their Own Coverage Plan
Extended trading creates a timing challenge for firms that must manage cash, collateral, credit limits, and exposure while market activity continues.
The relevant question is not simply whether an account has sufficient funds at the beginning of a session. Firms need to understand how exposure is measured, how limits are updated, what happens when a funding source is unavailable, and whether risk decisions remain effective across service boundaries.
Funding dependencies can include internal treasury systems, banks, payment networks, custodians, collateral-management platforms, and credit providers. Their operating hours may differ from those of the venue.
A trading system might accept orders at a time when a related funding service cannot process a transfer or confirm a balance change. Whether that creates a problem depends on the product, account structure, credit arrangements, and applicable controls.
The operating design must make those limitations explicit.
Questions to resolve before extending access
- Which balances and exposures are available in real time?
- How frequently are credit and margin limits recalculated?
- What happens if an external balance or collateral feed becomes stale?
- Can new orders be restricted when funding status cannot be verified?
- Which team has authority to adjust limits or approve exceptions?
- How are funding-related incidents communicated to participants?
Funding controls should not rely on assumptions that a service will be available simply because it normally operates during the main trading session. A documented fallback might restrict new exposure, preserve existing positions, or require a controlled suspension of specific activity.
These measures should be consistent with the venue’s product rules and participant agreements. The objective is to prevent uncertainty in a supporting service from becoming an unmanaged trading exposure.
The critical design principle is to align trading permissions with verified risk capacity. When the information required to establish that capacity becomes unavailable, the system needs a defined response rather than an informal judgment made under pressure.
Surveillance Cannot Depend on the Main Session
Trading surveillance must reflect the activity that occurs during the hours a venue actually operates. Extending access without extending the associated monitoring framework creates a gap between market availability and oversight.
The SEC has previously highlighted how lower participation during extended-hours trading can affect liquidity, spreads, price volatility, and susceptibility to manipulation. Its extended-hours trading bulletin outlines risks that remain relevant when firms design controls for less active sessions.
Surveillance needs to account for the conditions in which trading occurs, rather than apply a single activity threshold across every period.
For example, a volume-based alert designed around regular-session activity may be ineffective when the overnight baseline is much lower. Conversely, a rule that automatically flags every unusual movement could generate excessive alerts during legitimate periods of heightened activity.
The response is not to weaken surveillance outside peak hours. It is to calibrate detection to the market’s operating characteristics while preserving appropriate controls.
An alert generated at 3 a.m. is of limited value if it sits unreviewed until the next business morning while the underlying behavior continues. The operating model must define what the system can contain automatically, which alerts require immediate human attention, and which can enter a documented review queue.
Coverage also includes the tools used by surveillance teams. If data pipelines, case-management systems, or investigation interfaces become unavailable, the firm needs a fallback that preserves evidence and maintains the required level of oversight.
Continuous access should be matched by continuous control capability.
Staffing Is an Operational Dependency
Software may run around the clock, but many decisions still depend on people. Extended trading changes the hours during which someone must be able to diagnose incidents, approve actions, communicate with participants, and coordinate external providers.
A staffing plan should distinguish between continuous monitoring, on-call expertise, and decision-making authority. These are related responsibilities, but they are not interchangeable.
Continuous monitoring means that operational signals are observed and alerts are received. On-call expertise means that someone with the necessary technical or business knowledge can respond when an issue requires investigation. Decision-making authority determines who can restrict trading, authorize recovery, contact regulators where required, or approve a return to normal operation.
A rota that lists a telephone number without confirming the person’s authority, availability, or ability to access the required systems is not a complete coverage plan.
Assign named operational ownership
A practical responsibility model should identify accountable owners for:
- Trading operations and session control.
- Market-data infrastructure and external feed dependencies.
- Technology incidents, cybersecurity, and recovery.
- Risk controls, exposure limits, and account restrictions.
- Surveillance alerts and market-integrity investigations.
- Funding, collateral, and relevant external service dependencies.
- Participant communications and incident reporting.
Some functions may share personnel in a smaller organization. That arrangement still requires clear separation of duties where necessary, documented escalation paths, and a realistic assessment of workload.
Staffing also needs to account for fatigue, handovers, and overlapping incidents. A single engineer may be able to manage a routine connectivity issue but become a bottleneck if a cyber alert, data interruption, and trading-control failure occur together.
Shift handovers deserve particular attention. Open incidents, temporary restrictions, unresolved alerts, outstanding approvals, and known service degradations should transfer through a structured record. Verbal updates alone can leave critical details unclear.
The operating objective is not to reproduce a full daytime organization at every hour. It is to ensure that the necessary functions remain available, the people responsible are identifiable, and the response capacity matches the potential impact of failure.
Service Coverage Extends Beyond the Trading Venue
A venue’s internal infrastructure is only one part of the operating chain. Market participants also depend on brokers, connectivity providers, cloud and hosting services, identity platforms, payment systems, custodians, data vendors, and post-trade institutions.
Each dependency has its own service commitments, maintenance periods, incident procedures, and escalation contacts. Extending a venue’s hours does not automatically extend the availability of these external services.
The gap can appear in several ways. A provider may offer technical support only during specified business hours. A third-party system may remain online but process certain requests in batches. A connectivity provider may have a recovery procedure that requires manual intervention. A market-data vendor may distribute different content outside the primary session.
These are not necessarily defects. They become operational risks when the venue’s trading model assumes a level of service that the provider has not committed to deliver.
The register should capture dependencies that are easy to overlook, including credentials, certificates, network routes, DNS services, time synchronization, security monitoring, and vendor-managed software.
A backup connection is not a meaningful fallback if it uses the same underlying provider or fails under the same conditions as the primary route. Dependency mapping should therefore identify shared failure points, not simply count redundant components.
Service agreements should also be reviewed against actual operating needs. Response-time commitments, support hours, maintenance notifications, incident updates, and recovery obligations may require revision before the venue can reliably extend its schedule.
Incident Escalation Must Work Without Delay
A continuous market needs an incident framework that functions regardless of when a problem begins. The framework should distinguish an ordinary service degradation from an event that threatens market integrity, participant access, risk controls, or the reliability of transaction records.
Not every incident requires trading to stop. A degraded reporting dashboard may be manageable if core controls remain intact. A failure affecting order validation or the integrity of market data may require restrictions or suspension.
The decision depends on the service affected, the uncertainty created, the available safeguards, and the venue’s governing rules.
Define severity through impact
An effective escalation model classifies incidents using operational consequences rather than relying solely on technical labels.
- Limited degradation: A noncritical function is impaired, with no immediate effect on trading integrity or essential controls.
- Material service disruption: A supporting function is unavailable or unreliable, requiring restrictions, increased monitoring, or coordinated remediation.
- Critical trading incident: The venue cannot establish that core trading, data integrity, access controls, or essential risk protections are operating safely.
Each category should have a defined response owner, notification process, decision deadline where appropriate, and criteria for escalation.
The process also needs to identify who has authority to pause affected activity. If several teams must approve an emergency restriction, uncertainty about decision rights can extend the period during which the system operates in an unsafe state.
Communications should be prepared in advance. Participants may need to know which instruments or functions are affected, whether orders are being accepted, what restrictions apply, and where verified updates will appear. Internal teams need a consistent incident record so that operational decisions are not based on conflicting status reports.
Recovery requires the same discipline as containment. Teams should verify system health, reconcile relevant state, confirm that controls have resumed, and obtain the required approval before removing restrictions.
A service that appears restored is not necessarily ready to support normal trading volume.
Resilience Requires Tested Recovery Paths
Redundancy, backups, and disaster-recovery environments are necessary components of market infrastructure, but their existence does not prove that they will work under production conditions.
A backup environment may have outdated configuration, missing permissions, incomplete reference data, or insufficient capacity. Replicated systems may also reproduce corrupted information if the underlying problem is not detected before failover.
Near-continuous operations require regular testing of these dependencies and the procedures used to recover them.
Testing should cover more than a planned switch between primary and secondary environments. It should examine the failure of a market-data provider, the loss of a network route, a cybersecurity event, the unavailability of a critical employee, and the simultaneous degradation of multiple supporting services.
Recovery objectives should be defined for each important function. The acceptable interruption for an informational dashboard may differ significantly from the acceptable interruption for order validation, surveillance, or a core risk control.
Teams also need to understand the state of transactions during an incident. Which orders were accepted? Which acknowledgments were delivered? Which events reached downstream systems? Can the recovered environment reconstruct an accurate state without creating duplicates or overlooking valid activity?
These questions are particularly important when a service fails partway through a transaction sequence.
The SEC’s September 2026 roundtable identified resiliency, failover, capacity planning, cybersecurity, shortened maintenance windows, and market-data continuity as central concerns for extended-hours operations.
A useful testing program combines technical exercises with operational simulations. The technical exercise establishes whether systems can recover. The operational simulation determines whether people can make decisions, communicate restrictions, and coordinate external services under pressure.
Both are necessary.
Post-Trade Dependencies Still Matter When Trading Continues
An extended trading session does not mean every process associated with a trade runs continuously on the same schedule.
Execution creates downstream obligations involving trade capture, allocation, confirmation, clearing, settlement, position records, reporting, and, where applicable, corporate actions. These processes may have different cutoffs, service windows, and dependencies.
The distinction between trading availability and post-trade availability must be explicit. A participant may be able to submit an order at a particular hour while some downstream processes operate under a separate timetable. The venue needs to understand that relationship and communicate any material limitations.
This is especially relevant in markets with compressed settlement cycles. The Depository Trust & Clearing Corporation (DTCC) notes that the U.S., Canada, and Mexico transitioned to T+1 settlement in May 2024, while the UK, EU, Switzerland, and Liechtenstein are scheduled to move to T+1 in October 2027. Shorter cycles increase the importance of timely data, accurate instructions, automation, and coordination across firms.
The purpose here is not to prescribe detailed clearing-day workflows. Those require separate analysis of market-specific cutoffs, settlement systems, and processing obligations. The operating requirement is to map the interfaces between extended trading and those downstream processes.
A venue should also establish what happens when a post-trade dependency becomes unavailable. Depending on the product and applicable rules, the response might involve continued trading with defined controls, restricted activity, participant notification, or a more extensive operational intervention.
The decision must be grounded in documented dependencies rather than an assumption that the post-trade system will catch up later.
Measure Service Readiness With Operational Evidence
Readiness should be demonstrated through measurable results rather than a declaration that systems are available around the clock.
A useful measurement framework combines technical service indicators with control effectiveness and response performance.
Availability and data quality: Track service uptime alongside data freshness, message completeness, connectivity stability, and the frequency of degraded operating states.
Incident response: Measure detection time, acknowledgment time, escalation time, containment time, and recovery duration. Review whether the response met the required standard for each severity level.
Control coverage: Verify that risk checks, surveillance, access controls, and essential logging remain active during every trading session.
Dependency performance: Compare vendor service windows, response commitments, and actual incident performance with the venue’s operating requirements.
Recovery validation: Record failover-test results, identified gaps, corrective actions, and evidence that recovered systems return to a validated state.
Staffing effectiveness: Test whether the assigned personnel can access required systems, make authorized decisions, contact external providers, and manage handovers.
Metrics need context. A high availability percentage can conceal a short but consequential outage during an important event. A fast technical recovery may also conceal a longer period before participants receive accurate status information or downstream systems reconcile.
Operational reviews should therefore examine the full impact of incidents, including secondary effects and the time needed to restore confidence in system state.
Readiness assessments should be repeated after material changes to trading hours, providers, risk controls, system architecture, or regulatory obligations. An operating model that worked under one schedule may no longer be sufficient after another expansion.
Learn More About the Operating Model Behind Extended Trading
Near-continuous markets depend on coordinated services, reliable data, enforceable risk controls, effective surveillance, clear incident ownership, and realistic recovery plans. Trading hours are only one part of that system.
The team of digital asset management consultants at Kenson Investments examines the infrastructure and market-structure developments shaping digital asset and traditional financial markets.
Sign up to learn how to identify the operational dependencies that deserve closer review in a near-continuous trading model, including market-data reliability, incident escalation, and coordination across trading and post-trade services.
Disclaimer: The information provided on this page is for educational and informational purposes only and should not be construed as financial advice. Crypto currency assets involve inherent risks, and past performance is not indicative of future results. Always conduct thorough research and consult with a qualified financial advisor before making investment decisions.
“The cryptocurrency and digital asset space is an emerging asset class that has not yet been regulated by the SEC and the US Federal Government. None of the information provided by Kenson LLC should be considered as financial investment advice. Please consult your Registered Financial Advisor for guidance. Kenson LLC does not offer any products regulated by the SEC, including equities, registered securities, ETFs, stocks, bonds, or equivalents.”
