Effective Date: February 20, 2026 | Last Revised: January 15, 2026
Liquidity Connect (the "Provider") is committed to delivering world-class infrastructure services to our customers in the financial trading industry. This Service Level Agreement ("SLA") establishes the level of service quality, availability, support standards, and operational responsibilities we guarantee to our Clients.
This SLA applies to all services provided by Liquidity Connect, including low-latency servers, network connectivity, cross-connects, dedicated infrastructure, and firewall services. Provider's services are designed to optimize performance for high-frequency and algorithmic trading while maintaining industry-leading reliability and security standards.
By submitting an order, signing a service order or quote, or activating any service from Provider, the Client acknowledges and agrees to be bound by this SLA. Acceptance may be recorded electronically via Provider’s customer portal, ordering system, CRM platform, or other electronic signature workflow used by Provider at the time of order.
For existing Clients, continued use of Provider’s services after receipt of reasonable notice of an updated SLA constitutes acceptance of the updated SLA from the effective date specified in the notice.
Liquidity Connect is responsible for the following aspects of service delivery:
Infrastructure Management: Design, provisioning, operation, and maintenance of bare metal servers, virtual private servers, cross connects, and any additional accessories associated with the aforementioned.
Network Infrastructure: Operation and maintenance of network equipment, switches, routers, and connectivity to exchanges and liquidity venues. Cross-Connects and Connectivity: Provisioning and maintenance of dedicated cross-connects, internet circuits, and connections to trading venues.
Server Hardware Maintenance: Physical hardware support including hard drive replacements, hardware diagnostics via IPMI, component failures, and preventive maintenance of physical infrastructure.
Network Quality and Performance: Monitoring and maintaining network latency, packet loss, and connectivity guarantees as defined in Section 3 of this SLA. Service Level Agreement 1. Introduction and Commitment 2. Roles, Responsibilities, and Service Ownership 2.1 Provider Responsibilities (Liquidity Connect)
Firewall and Network Security: Management and support of firewall policies, ACL (Access Control List) changes, DDoS mitigation, and network-level security infrastructure.
Support and Escalation: Availability of technical support team for critical incidents, network-related issues, and connectivity problems.
Compliance with SLA Terms: Meeting or exceeding the uptime, latency, and support response time commitments outlined in this SLA.
After server hand-off and service activation, the Client assumes full operational responsibility for the following:
Server Operating System Management: Installation, configuration, patching, security updates, and all OS-level administration.
Application Management: Installation, configuration, updates,allocation of resources, and operational support of all trading applications, middleware, and software running on the server.
Trading Systems and Strategy: Management, testing, deployment, and operational oversight of all trading systems, algorithms, and strategies.
Data and Configuration: Responsibility for data backup, retention, disaster recovery strategy, and configuration of the Client's applications and systems.
Server Operations: Day-to-day operational decisions including server startup, shutdown, and reboots.
Client-Side Equipment and Networks: Any equipment, networks, or systems owned, operated, or controlled by the Client, including office networks, client-owned hardware, and external integrations.
Security and Access Management: Managing user accounts, passwords, API keys, and access credentials within the Client's environment.
Incident Response on Client Systems: Diagnosing and resolving issues within Client applications, OS configuration, or trading logic that do not relate to Provider infrastructure
The following activities are shared and require coordination:
Planned Maintenance: Provider proposes maintenance windows; Client reviews, approves, and prepares systems for the maintenance period.
Incident Investigation: Provider investigates infrastructure-level issues; Client provides system logs and application context to support root-cause analysis.
Performance Monitoring: Both parties monitor performance and share data to diagnose network vs. application vs. hardware issues.
Network Configuration Changes: Provider implements firewall and ACL changes; Client requests changes, tests them in their trading environment, and validates that they meet business requirements.
Once a server is handed over to the Client and confirmed as operational, Liquidity Connect will not:
Log in to the Client's server or OS environment without written authorization. A support request via email, message, and/or ticket may be construed as written authorization unless explicitly stated otherwise by the Client.
Perform server reboots, shutdowns, or power cycles without written authorization
Modify, reinstall, or update the Client's operating system without written authorization
Access Client data, applications, or configuration files without written authorization
Make changes to the Client's network configuration beyond firewall/ACL updates without written authorization
Exception: Liquidity Connect reserves the right to take immediate emergency action (limited to the minimum necessary) to protect the integrity of the Provider's infrastructure, prevent data loss, or respond to facility-level threats (e.g., fire, power failure, internet connectivity outage, physical security breach, cybersecurity breach), provided that Provider notifies the Client immediately and documents the action taken.
Liquidity Connect commits to the following performance and availability standards, designed specifically for low-latency trading infrastructure.
Commitment: Provider guarantees an average monthly transmission latency of less than 5 milliseconds (ms) between Client equipment and liquidity providers through dedicated cross-connects
Measurement: Latency is measured on a daily basis as the average one-way transmission time across the Provider's network and direct cross-connects.
Service Credit: If Provider fails to achieve an average latency of 5 milliseconds (ms) or better on any single calendar day, Provider will issue a service credit equal to 3% of the monthly recurring service fees for each such incident
Exclusions: Latency guarantees do not apply to:
Client applications or trading logic delays
Client network or equipment performance
Issues originating from the liquidity venue or exchange side
Periods of scheduled maintenance (outside normal trading hours)
Internet connectivity issues and/or outage
Power outage affecting server location(s)
Third-party failures (facility management, carriers, upstream providers)
Commitment: Provider guarantees an average of 1% or less of packet loss for all valid data packets within Provider's network over any given calendar day.
Measurement: Packet loss is measured daily across all Client connections and the Provider's core infrastructure.
Service Credit: On any day where packet loss averages over 1%, Provider will issue a service credit equal to 3% of the monthly recurring service fees for each such incident.
Exclusions: Packet loss guarantees do not apply to:
DDoS attacks or malicious traffic floods
Client equipment or network issues
Scheduled maintenance periods
Force Majeure events
Internet connectivity outage
Power outage affecting server location(s)
Third-party failures (facility management, carriers, upstream providers)
Commitment: Provider guarantees its connections to the Internet and all liquidity venues will be available 99.5% of the time in any given month (exclusive of scheduled maintenance).
Measurement: Network Unavailability is calculated from the date and time the Client reports the unavailability to Provider and ends upon Provider's confirmation that connectivity has been restored. The Provider will track all events and provide detailed logs to the Client upon request.
Service Credit: Provider will issue credits based on the Monthly Connectivity Guarantee table below:
Monthly Connectivity Percentage | Expected Service Credit |
99.5% or higher | No credit; SLA met |
Lower than 99.5% but 98% or higher | 10% of the Monthly Service Fee |
Lower than 98% but 95% or higher | 20% of the Monthly Service Fee |
Lower than 95% | 100% of the Monthly Service Fee per server affected |
Note: Monthly Connectivity Percentage excludes scheduled maintenance windows, emergency maintenance (after notification), and force majeure events.
Exclusions: Connectivity guarantees do not apply to:
Scheduled network maintenance (with 72+ hours notice)
Emergency maintenance necessary to protect or restore infrastructure
Client-caused outages (misconfiguration, attacks from Client environment)
Third-party failures (facility management, carriers, upstream providers)
Client applications, equipment, or facilities
Force Majeure events (e.g., natural disasters, war, government action, etc.)
Unavailability of the Services not reported to Provider within 3 business days of occurrence
The following table shows the maximum allowable downtime at different SLA levels, for reference:
At 99.5% Uptime:
Daily: 43 seconds
Weekly: 5 minutes 2 seconds
Monthly: 21 minutes 44 seconds
Quarterly: 1 hour 5 minutes
Yearly: 4 hours 20 minutes
At 98% Uptime:
Daily: 28 minutes 48 seconds
Weekly: 3 hours 21 minutes
Monthly: 14 hours 24 minutes
Quarterly: 43 hours 12 minutes
Yearly: 7 days 7 hours 12 minutes
At 95% Uptime:
Daily: 1 hour 12 minutes
Weekly: 8 hours 24 minutes
Monthly: 36 hours 13 minutes
Quarterly: 2 hours 10 minutes
Yearly: 8 hours 41 minutes
Liquidity Connect provides 24/7 support with dedicated experts available to assist Clients at all times, including nights, weekends, and holidays.
Clients can contact Provider support through any of the following channels:
Email: support@liqc.com or netops@liqc.com (monitored 24/7)
Ticketing System: Dedicated ticket portal for tracking issues and support requests
Slack: Real-time messaging for eligible Clients with Slack integration
Live Chat: Live chat support available on the Provider website and customer portal
Provider commits to the following response times based on issue severity:
Critical Issues: 5-Minute Response Target
Definition: Emergency affecting trading operations, revenue, or multiple systems; mission critical services down.
Examples:
Complete service outage
Hardware failure causing immediate service degradation
DDoS attack or active security incident overwhelming infrastructure
Network connectivity failure affecting trading venue access
Data breach or unauthorized access incident
Commitment: Provider will respond with an initial acknowledgment within 5 minutes of ticket creation or chat notification.
High Priority Issues: 30-Minute Response Target
Definition: Medium-severity issue affecting functionality or performance; critical operations not stopped but degraded.
Examples:
Performance degradation leading to slower response times
Configuration errors impacting system functionality
Resource limits exceeded (CPU, memory, storage)
Compliance or regulatory requirement issue
Loss of RDP access to the host server
Commitment: Provider will respond with initial assessment and action plan within 30 minutes.
Medium Priority Issues: 4-Hour Response Target
Definition: Lower-severity issue; does not immediately impact trading but requires attention.
Examples:
Backup issues or data recovery requests
Server or network optimization requests
Maintenance scheduling or planning
Firewall/ACL change requests
Commitment: Provider will respond with initial assessment within 4 hours
Low Priority Issues: 24-Hour Response Target
Definition: Non-urgent requests or informational inquiries.
Examples:
Planned maintenance scheduling and notifications
Sales inquiries or new service requests
Documentation or reporting requests
Administrative or billing questions
Password resets
Commitment: Provider will respond within 24 business hours.
Notice Period: Provider will provide a minimum of 72 hours' advance written notice (via email to all designated Client contacts) before conducting any planned maintenance that may impact Client services.
Market Hours Consideration: Provider will schedule all planned maintenance outside of defined "Market Hours" whenever technically feasible. "Market Hours" will be defined with each Client during onboarding or at the Client's request and may include:
Foreign exchange (FX) market hours
Cryptocurrency trading hours
Equity market hours
Regional or specific venue hours relevant to Client's trading operations
Communication: Maintenance notifications will include:
Exact date and time (in Client's local time zone)
Estimated duration and potential impact on services
Systems, networks, or facilities affected
Rollback and recovery plan
Escalation contact if Client has questions or concerns
For any planned maintenance expected to cause service downtime or impact to trading operations during trading hours, Client must provide written approval before work begins. This acknowledgment confirms that:
Client understands the maintenance scope and potential impact
Client has prepared systems, stopped trading, or taken other protective measures
Client has assigned resources to monitor systems during the maintenance window
Client agrees to the scheduled time and duration
Lack of written approval within 24 hours of the original notification may result in rescheduling of the maintenance window.
During planned maintenance, Provider will:
Begin work at the scheduled time and maintain communication via the primary support channel
Log all actions taken, including start time, completion time, and any issues encountered
Provide a status update to the Client if the maintenance extends beyond the estimated duration
Notify the Client immediately upon completion of all work
In rare cases where infrastructure failure or security threat requires immediate action, Provider may conduct emergency maintenance without prior approval. In these cases:
Provider will notify the Client immediately via email, phone, and/or Slack
Notification will include an estimated impact and timeline
Actions will be limited to the minimum necessary to restore service or protect infrastructure
Client will be updated every 30 minutes (or as frequently as possible) until resolution
A detailed postmortem report will be provided, documenting root cause, actions taken, and preventive measures
Liquidity Connect requires explicit, documented authorization before accessing, modifying, or performing actions on any Client-operated server. This framework protects Client systems and ensures clear accountability.
Each Client must designate one or more "Authorized Contacts" who have the authority to approve changes, grant access, or authorize maintenance. Authorized Contacts should include:
Client is responsible for maintaining an accurate, up-to-date list of Authorized Contacts and notifying Provider immediately of any changes. Provider may rely on this list to validate authorization requests.
Provider will not perform the following actions without written authorization from an Authorized Contact:
Written authorization may be provided via:
Email, text, or Slack from an Authorized Contact or their designated representative
Ticket system approval (if integrated with Client's workflow)
Signed change request form
Documented verbal approval (followed by email confirmation within 24 hours)
The following support and network-related actions do not require pre-authorization, but Client will be notified:
Firewall/ACL Changes: Implementing routine firewall or ACL changes requested by the Client
Network Diagnostics: Running network diagnostics, packet captures, and latency tests to troubleshoot connectivity issues
Connectivity Troubleshooting: Investigating and resolving network connectivity issues affecting the Client
System Monitoring: Monitoring network performance, alerts, and infrastructure health
Security Incident Response: Taking immediate action to mitigate active security threats or DDoS attacks, with notification to Client
In rare situations where an immediate threat to the Provider's infrastructure, data, or facilities exists, Provider may take emergency action without prior authorization, provided that:
The action is limited to the minimum extent necessary to address the threat
Client is notified immediately afterwards (within 15 minutes)
Detailed documentation is provided within 24 hours
A postmortem meeting or communication via phone, email and/ or Slack, is conducted with Client to review the incident and approval process
Examples of emergency situations:
Imminent data loss or system corruption
Uncontrolled resource consumption consuming facility power or cooling
Active security breach or intrusion originating from the Client's server
Facility-level threat (fire, power failure, natural disaster)
Force Majeure event
Clients may report incidents through any of the following channels:
Live Chat: Via the customer portal
Email: support@liqc.com or netops@liqc.com
Dedicated Incident Portal: Ticket system integrated with Client's workflow
Slack: Real-time messaging channel (if applicable)
All incidents will be assigned a unique Incident ID for tracking and reference.
For all significant incidents (P1, P2, and complex P3 issues), Provider will maintain detailed documentation including:
Incident ID and Creation Timestamp: Unique identifier and when incident was reported
Initial Assessment: Scope, systems affected, estimated impact
Timeline of Actions: Detailed log of all actions taken, with timestamps (UTC)
Approvals and Authorizations: Any Client approvals obtained during the incident
Root Cause: Analysis of underlying cause (infrastructure, network, Client application, etc.)
Resolution and Completion: When issue was fully resolved and confirmed by Client
Preventive Measures: Steps taken to prevent recurrence
This documentation will be made available to the Client upon request and will serve as the basis for the incident postmortem.
Provider commits to delivering a detailed postmortem report within 24 hours of any significant incident resolution.
Postmortem Report Contents:
Executive summary of the incident
Timeline of events (detection, notification, actions, resolution)
Root cause analysis Impact assessment (duration, affected systems, trading impact)
Actions taken to resolve the incident
Preventive measures to avoid recurrence
Postmortems will be shared in a Client-accessible format (PDF, email, or portal) for review and discussion.
In the event of prolonged incidents or communication breakdowns, Provider will follow an established escalation path:
Level 1: Initial support team member (frontline support)
Level 2: Senior network engineer or specialist (for technical escalation)
Level 3: Director of NetOps or Engineering (for severe or critical incidents)
Level 4: VP of Operations or Sales Leadership (for customer relationship or business impact issues)
The escalation path and contact information for each level will be provided to each Client during onboarding.
Both Provider and Client agree to maintain professional, respectful communication during all incidents and interactions. This includes:
Responding to communications promptly and respectfully
Providing accurate, timely information
Avoiding blame, offensive, or defensive language
Focusing on root cause analysis and resolution, not fault-finding
Following established escalation paths when communication becomes difficult
If communication becomes hostile, abusive, or deliberately obstructive, either party may escalate to senior management and pause routine support activity until professional communication is restored.
Provider may conduct maintenance during the following standard windows (unless Client specifies different trading hours):
Standard Maintenance Windows:
LD4:
Saturdays, 11:00 AM – 12:00 AM UTC
NY4:
Saturdays, 7:00 AM – 12:00 AM EST
Emergency:
As needed, with immediate notification
Market Hours Exceptions: If the standard window falls during or immediately before a Client's defined Market Hours, Provider will schedule maintenance outside those hours.
Timeframe | Communication | Method |
72+ hours before | Initial maintenance notice | Email to all Authorized Contacts |
24 hours before | Final confirmation and rollback plan | Email to all Authorized Contacts |
At start time | Maintenance beginning notification | Email to all Authorized Contacts |
Every 30 min (if extended) | Status updates | Email to all Authorized Contacts |
Upon completion | Completion notification | Email to all Authorized Contacts |
When a new server or service is provisioned, the following handover process occurs:
Provisioning Phase: Provider deploys hardware, installs base OS, configures networking, and prepares the server.
Access Transfer: Provider provides Client with full access credentials (IPMI, SSH, console, VPN, firewall rules, etc.).
Testing and Verification: Client verifies that the server is accessible and performs as expected.
Formal Handover: Client confirms that access is working and the server is ready for production use. This confirmation marks the end of Provider's pre-delivery responsibility and the beginning of Client's operational ownership.
Onboarding Documentation: Client receives this SLA, escalation paths, support contacts, and any service-specific documentation.
If a Client requests migration of a server to different hardware, data center, or facility, the following process applies:
Planning Phase: Provider and Client collaborate to plan the migration, including timing, expected downtime, and rollback procedures (minimum 72 hours' notice).
Client Approval: Client provides written approval for the migration window and acknowledges potential downtime.
Pre-Migration Testing: Provider tests the new environment and verifies connectivity and performance.
Migration Execution: Client migrates the server
Post-Migration Verification: Client verifies that the migrated server is functioning correctly and all data is intact.
Completion: Provider documents the completion and any findings; both parties confirm the migration is successful.
When a Client terminates service, stops using a server, or transitions ownership, the following process applies:
Termination Notice: Client notifies Provider of the service termination or transition date.
Data Handling: Client is responsible for data handling procedures (retention, secure deletion, migration, etc.). Once the service is terminated by Provider, data cannot be recovered.
Access Removal: Provider removes or resets all access credentials (e.g., IPMI, SSH, firewall rules, cross-connect assignments, etc.).
Credential Return (if applicable): Client returns any hardware credentials, tokens, or security devices in Provider's possession.
Secure Wipe (if applicable): Provider securely wipes or resets the server's hard drives, per Client's request and data protection regulations.
Confirmation: Both parties confirm that the transition is complete, data has been handled per agreement, and all access has been revoked.
Billing Adjustment: Provider adjusts billing only after formal confirmation that the transition is complete and credentials have been returned/revoked.
Exception: Provider has sole discretion to terminate and/or decommission a client server in the case of lack of responsiveness after multiple attempts over several days, lack of payment after multiple attempts to collect overdue balances, or suspicion/confirmation of illegal activity.
After service termination:
Provider will not retain Client data beyond the agreed retention period.
Provider will not have any further responsibility for the Client's systems, performance, or operations.
Client is responsible for any data back-up, data recovery, disaster recovery, or business continuity planning.
All support, incident response, and SLA commitments cease upon formal termination and confirmation of access removal.
In the event Provider fails to meet the service standards outlined in this SLA, Provider will issue Service Credits as compensation. Service Credits are the Client's sole remedy for Provider's failure to meet SLA commitments.
Provider's total liability under this Agreement shall be limited to the amount of recurring service fees paid to Provider for the month in which the failure occurred. Service Credits will not exceed 100% of monthly fees in any single month.
To be eligible for a Service Credit, the Client must:
Report the failure within 3 business days of the incident or failure to meet SLA standards within 3 days
Provide evidence of the failure (logs, screenshots, test results, timestamps)
Not be in breach of any other material term of the Service Agreement
Cooperate with Provider's investigation of the incident
Any SLA failures not reported within 3 business days are not eligible for Service Credits.
Submission: Client submits a Service Credit request to sales@liqc.com with:
Incident ID (if applicable)
Dates and times of the failure
Evidence of the failure (logs, metrics, postmortem reference)
Detailed description of impact
Investigation: Provider reviews the request and responds within 10 business days.
Determination: Provider determines whether the failure qualifies under this SLA and calculates the Service Credit amount.
Issuance: Provider issues the Service Credit as a credit against next month's invoice or as a direct refund, at Provider's discretion. Credits are not transferable and do not constitute a refund of fees already paid.
Communication: Provider notifies the Client of the credit amount and method of resolution.
Example 1: Latency Failure
SLA: 5ms average daily latency guarantee
Actual performance: 6.2ms average on March 15
Credit: 3% of monthly recurring service fees
Example 2: Connectivity Failure
SLA: 99.5% monthly connectivity
Actual uptime: 99.2% (due to 2-hour incident)
Monthly fees: $5,000
Credit: 10% × $5,000 = $500
Example 3: Multiple Incidents
Month includes 3 latency failures and 1 connectivity failure (99.8% uptime)
Latency credits: 3% × 3 incidents = 9%
Connectivity credit: 10% × 1 incident = 10%
Total: 19% of monthly fees (capped at 100% maximum)
Service Credits do not apply if the failure is caused by:
Client's actions, omissions, or misconfiguration
Client-provided applications, software, or data
Client's network, equipment, or facilities
Factors outside Provider's reasonable control (Force Majeure)
Unauthorized third-party interference
Scheduled maintenance (with 72+ hours' notice)
Emergency Maintenance due to third-party dependencies (e.g., power outage, internet connectivity, e.t.c.)
Neither party shall be liable for any failure or delay in performance under this SLA caused by events beyond the party's reasonable control, including but not limited to:
Natural disasters (earthquakes, floods, hurricanes, wildfires)
War, terrorism, or government action
Pandemics or public health emergencies Strikes, labor disputes, or civil unrest
Extreme weather or environmental events
Acts of God or other unforeseeable circumstances
The affected party will notify the other party as soon as reasonably possible and will take reasonable steps to resume performance.
Provider shall not be liable for any failure or delay in performance under this SLA caused by third-party carriers, facility management, ISPs, or exchanges outside of our direct control.
In the event of a dispute regarding SLA performance, service credits, or other contractual matters:
Good Faith Discussion: Both parties will attempt to resolve the dispute through good faith discussion between operational representatives.
Escalation: If unresolved within 10 business days, the dispute will be escalated to management (VP level or equivalent).
Formal Mediation: If escalation does not resolve the dispute, the parties may agree to enter into mediation or formal dispute resolution per the primary Service Agreement.
This SLA may be amended by Provider upon 30 days' written notice to the Client. Client's continued use of services after the 30-day notice period constitutes acceptance of the updated terms. If Client does not agree to updated terms, Client may request formal review or termination of service before the amendment becomes effective.
This SLA, combined with the Terms of Service, constitutes the entire agreement between the parties regarding service levels, support, and maintenance. This SLA supersedes any prior verbal or written representations, and no party has relied on any representations outside the written terms herein.