CONFIDENTIAL — ATTORNEY WORK PRODUCT — SUBJECT TO ATTORNEY-CLIENT PRIVILEGE
EXHIBIT A
SERVICE LEVEL AGREEMENT
Revised Draft — June 12, 2025
Matter No.: 1009-00007
Prepared by: Amy Chesterton Calderwood & Harkness LLP 200 South Ashbury Asset Advisors, Suite 1800 Chicago, IL 60604
Reference: This Exhibit A (the "Service Level Agreement" or "SLA") is attached to and forms a part of the Master Software-as-a-Service Agreement (the "MSA") by and between Skybridge Fintech Ltd. ("Provider" or "Licensor"), a Delaware limited liability company with principal offices at 1400 Concord Pike, Suite 320, Wilmington, DE 19803, and Meridian National Bank, National Association ("Customer" or "Licensee"), a national banking association chartered under the laws of the United States with principal offices at 600 Lexington Avenue, 40th Floor, New York, NY 10022.
DRAFTING NOTE (INTERNAL — TO BE REMOVED BEFORE EXECUTION): This Revised Draft reflects negotiated positions following the Hargrove, Tully & Cascade Insurance Brokers ("HTM") markup dated May 28, 2025. This draft was prepared following discussion with Amara Okafor, Chief Information Security Officer, Skybridge Fintech Ltd., regarding Orion Cloud Services, Inc. Upstream SLA parameters, and further consultation with Marcus Holt, Chief Technology Officer, Skybridge Fintech Ltd. Bracketed language indicates open negotiation items. All internal drafting notes are to be stripped from the execution version.
Capitalized terms used but not defined herein shall have the meanings ascribed to them in the MSA.
EXHIBIT A — SERVICE LEVEL AGREEMENT
Section 1: Definitions
The following definitions apply to this Exhibit A. Where a term defined in this Section 1 is also defined in the MSA, the definition set forth in this Exhibit A shall control solely for purposes of interpreting and applying the provisions of this SLA.
1.1 "Availability" or "Uptime" shall mean the percentage of time during a Measurement Period that the SkyComply™ platform is operational and accessible to Customer's authorized users via the standard access methods documented in the applicable technical specifications, calculated in accordance with Section 3 of this Exhibit A. For the avoidance of doubt, Availability is measured with respect to the production instance of the SkyComply™ platform and does not include sandbox, development, staging, or testing environments unless expressly agreed in writing by the parties.
1.2 "Downtime" shall mean any period during which the SkyComply™ platform is not materially accessible or functional for Customer's authorized users, as determined in accordance with the measurement methodology set forth in Section 3. Downtime shall exclude the following categories of unavailability, which are addressed separately under this Exhibit A: (a) Scheduled Maintenance, as defined in Section 1.7 and further described in Section 4; (b) Excused Downtime, as defined in Section 1.3; and (c) unavailability resulting from Force Majeure Events as defined in the MSA. For purposes of this definition, the SkyComply™ platform shall be deemed "not materially accessible or functional" when the platform's core transaction-monitoring, alert-generation, case-management, or regulatory-reporting functionality is unavailable to all or substantially all of Customer's authorized users, or when latency or error rates render such functionality effectively unusable.
1.3 "Excused Downtime" shall mean Downtime resulting from any of the following causes:
(a) Customer's acts or omissions, including but not limited to misconfiguration of Customer-controlled settings, unauthorized modifications to the platform environment, or Customer's failure to implement Provider-recommended updates or patches within the timeframes specified by Provider;
(b) failures, interruptions, or degradation of Customer's network, hardware, software, or systems, including Customer's internet connectivity, firewalls, load balancers, or other infrastructure components not provided or managed by Provider;
(c) Force Majeure Events, as that term is defined in Article [15] of the MSA;
(d) suspension or limitation of service in accordance with the terms of the MSA, including without limitation suspension due to Customer's breach of the Acceptable Use Policy (Exhibit D to the MSA), failure to pay undisputed fees when due, or other circumstances expressly permitting suspension under the MSA; and
(e) failures, interruptions, or degradation of third-party systems or services that are outside Provider's reasonable control; provided, however, that failures of Provider's subprocessors, sub-contractors, and hosting or infrastructure providers—including, without limitation, Orion Cloud Services, Inc.—shall not constitute Excused Downtime and Provider shall remain fully responsible for all Downtime attributable to such parties in accordance with Section 9 of this Exhibit A.
1.4 "Measurement Period" shall mean each calendar month during the Term of the MSA, commencing on the Platform Go-Live Date. The first Measurement Period shall run from the Platform Go-Live Date (targeted: March 1, 2026) through the last day of the calendar month in which the Platform Go-Live Date occurs. If the Platform Go-Live Date falls on a date other than the first day of a calendar month, the first Measurement Period shall be a partial month, and the Availability calculation for such partial month shall be based on the Total Available Minutes from the Platform Go-Live Date through the end of that calendar month.
1.5 "Monthly Subscription Fee" shall mean the portion of the subscription fees payable by Customer under the MSA and the Order Form that is allocable to the applicable calendar month, calculated as follows:
(a) Year 1 (Platform Go-Live Date through the first anniversary thereof): $12,700,000.00 per annum ÷ 12 = $1,058,333.33 per month.
(b) Years 2 through 5: $9,325,000.00 per annum ÷ 12 = $777,083.33 per month, subject to annual fee escalation as set forth in the Order Form, commencing in Year 3 at a rate of three percent (3.0%) per annum, with such annual escalation capped at three and one-half percent (3.5%) per annum.
For purposes of calculating SLA Credits under Section 5, the Monthly Subscription Fee for any partial Measurement Period shall be prorated based on the number of days in the partial month relative to the total number of days in the full calendar month.
1.6 "Platform Go-Live Date" shall mean the date on which the SkyComply™ platform is deployed in the production environment and made available for production use by Customer in accordance with the Implementation Plan attached as Exhibit E to the MSA. The targeted Platform Go-Live Date is March 1, 2026. The actual Platform Go-Live Date shall be confirmed in writing by both parties upon completion of User Acceptance Testing and satisfaction of the Go-Live Readiness Criteria set forth in the Implementation Plan.
1.7 "Scheduled Maintenance" shall mean pre-planned maintenance activities performed by Provider during the standard maintenance windows or at such other times as may be agreed by the parties, in each case in accordance with Section 4 of this Exhibit A. Scheduled Maintenance includes software updates, patches, upgrades, database maintenance, infrastructure scaling activities, and other routine operational tasks necessary to maintain the performance, security, and functionality of the SkyComply™ platform.
1.8 "Service Level Credit" or "SLA Credit" shall mean the credit amounts to which Customer is entitled under Section 5 of this Exhibit A as a result of Provider's failure to meet the Availability Target in any Measurement Period. SLA Credits represent Customer's sole and exclusive financial remedy for Provider's failure to meet the Availability Target, subject to the exceptions and limitations set forth in Section 5.5.
1.9 "Severity Level" shall mean the classification of incidents affecting the SkyComply™ platform as set forth in the incident severity matrix in Section 7.1 of this Exhibit A. Severity Levels are designated as Severity 1 (Critical — Platform Down), Severity 2 (Major — Feature Impaired), and Severity 3 (Minor — Limited Impact), each as further defined therein.
1.10 "Total Available Minutes" shall mean the total number of minutes in a Measurement Period, minus the aggregate number of Scheduled Maintenance minutes during such Measurement Period, minus the aggregate number of Excused Downtime minutes during such Measurement Period. Total Available Minutes represents the denominator in the Availability calculation set forth in Section 3.1.
Section 2: Availability Target
2.1 Platform Availability Target.
Provider shall use commercially reasonable efforts to maintain Availability of the SkyComply™ platform of not less than ninety-nine and nine-tenths percent (99.9%) per Measurement Period (the "Availability Target"). The Availability Target represents Provider's commitment to the minimum level of platform Availability during each Measurement Period, and Provider's failure to meet the Availability Target in any Measurement Period shall entitle Customer to SLA Credits as set forth in Section 5 and, in the case of chronic Availability failures, termination rights as set forth in Section 6.
DRAFTING NOTE (INTERNAL — TO BE REMOVED BEFORE EXECUTION): Meridian National Bank's initial position, as reflected in the HTM markup dated May 28, 2025, demanded an Availability Target of 99.95%. Provider's position, maintained in this revised draft, is 99.9%. The compromise reflected herein is as follows: Provider maintains 99.9% as the contractual Availability Target but agrees to enhanced SLA Credit tiers (see Section 5.1, Enhanced Credit Tier Alternative) and an additional termination trigger (see Section 6.2) as consideration for Customer's acceptance of the 99.9% standard.
The rationale for maintaining the 99.9% target is grounded in the architecture of the SkyComply™ platform and the upstream infrastructure SLA. Orion Cloud Services, Inc. ("Orion Cloud"), Provider's infrastructure-as-a-service hosting provider, maintains an upstream platform SLA of 99.95% monthly uptime for its compute, storage, and networking services. Provider's 99.9% commitment to Customer reflects the compounding effect of application-layer availability on top of the infrastructure-layer availability. Total system availability is a mathematical function of both layers: if infrastructure availability is 99.95% and application-layer availability is 99.95%, the resulting end-to-end availability is approximately 99.90% (0.9995 × 0.9995 = 0.999). Provider cannot contractually guarantee availability at a level equal to or exceeding its upstream infrastructure provider's commitment, as doing so would require the application layer to operate at 100% availability — an unrealistic standard. A 99.9% target represents approximately 43.2 minutes of permissible Downtime per 30-day month; a 99.95% target represents approximately 21.6 minutes, which does not allow a meaningful margin for application-layer issues beyond infrastructure availability. This analysis was confirmed by Amara Okafor (CISO, Skybridge) and Marcus Holt (CTO, Skybridge) during the preparation of this revised draft.
2.2 Availability Target During Implementation Period.
The Availability Target set forth in Section 2.1 shall not apply during the Implementation Period, which is currently scheduled to commence on September 15, 2025, and conclude on February 28, 2026 (or such later date as the parties may agree in writing in the event of a delay in the Platform Go-Live Date). During the Implementation Period, Provider shall use commercially reasonable efforts to maintain the availability and performance of any pre-production or staging environments made available to Customer, but no SLA Credits or other remedies under this Exhibit A shall accrue during the Implementation Period. All SLA obligations under this Exhibit A shall commence on the Platform Go-Live Date and shall apply to each Measurement Period thereafter throughout the Term.
Section 3: Measurement Methodology
3.1 Calculation of Availability.
Availability for each Measurement Period shall be calculated using the following formula:
Availability (%) = ((Total Available Minutes – Downtime Minutes) ÷ Total Available Minutes) × 100
Where:
(a) Total Available Minutes equals the total number of minutes in the applicable calendar month, minus the aggregate number of Scheduled Maintenance minutes (as recorded in accordance with Section 4), minus the aggregate number of Excused Downtime minutes (as determined in accordance with Section 1.3).
(b) Downtime Minutes equals the aggregate number of minutes during which the SkyComply™ platform experiences Downtime during the applicable Measurement Period, as measured from the earlier of (i) the time at which Provider's automated monitoring systems detect platform unavailability, or (ii) the time at which Provider confirms a platform-wide outage upon notification by Customer, and continuing until the time at which platform functionality is restored, verified by Provider's monitoring systems, and confirmed as accessible to Customer's authorized users. For the avoidance of doubt, Downtime Minutes do not include Scheduled Maintenance minutes or Excused Downtime minutes, each of which are excluded from both the numerator and denominator of the Availability calculation.
By way of illustration, for a 30-day Measurement Period containing 43,200 total minutes, assuming 4 hours (240 minutes) of Scheduled Maintenance and zero Excused Downtime, the Total Available Minutes would be 42,960 minutes. If the platform experienced 45 minutes of Downtime during such period, Availability would be calculated as: ((42,960 – 45) ÷ 42,960) × 100 = 99.895%, which would fall below the 99.9% Availability Target and trigger SLA Credits under Section 5.
3.2 Monitoring Tools.
Provider shall deploy and maintain commercially reasonable automated monitoring tools to measure the Availability and performance of the SkyComply™ platform on a continuous basis throughout each Measurement Period. Such monitoring tools shall meet the following minimum requirements:
(a) Polling Interval. Automated monitoring shall poll the SkyComply™ platform's core services and endpoints at a minimum interval of once every sixty (60) seconds.
(b) Monitoring Scope. Monitoring shall cover, at a minimum, the following components: (i) application server availability and responsiveness; (ii) database connectivity and query performance; (iii) API endpoint availability and response times; (iv) authentication and authorization service availability; (v) core transaction-monitoring engine operation; and (vi) scheduled job execution and batch processing status.
(c) Customer Dashboard. Provider shall make real-time or near-real-time availability dashboards accessible to Customer's designated administrators through the SkyComply™ administrative portal. Such dashboards shall display current platform status, historical Availability data for the current and prior Measurement Periods, active incident status, and upcoming Scheduled Maintenance windows.
(d) Data Retention. Provider shall retain all raw and processed availability monitoring data for a minimum period of twenty-four (24) months from the end of the applicable Measurement Period. Upon Customer's reasonable request, Provider shall make such data available to Customer in a standard machine-readable format (e.g., CSV or JSON) within ten (10) business days of the request.
3.3 Reporting.
Provider shall deliver to Customer the following reports related to SLA performance:
(a) Monthly Availability Report. Within ten (10) business days following the end of each Measurement Period, Provider shall deliver to Customer a written monthly availability report containing, at a minimum, the following information:
(i) the total number of minutes in the Measurement Period;
(ii) the aggregate number of Scheduled Maintenance minutes during the Measurement Period, with dates and times of each maintenance window;
(iii) the aggregate number of Excused Downtime minutes during the Measurement Period, with a description of each event giving rise to Excused Downtime and the basis for its classification as Excused Downtime;
(iv) the aggregate number of Downtime minutes during the Measurement Period, with a summary description and root cause categorization for each Downtime incident;
(v) the calculated Availability percentage for the Measurement Period, derived in accordance with the formula in Section 3.1;
(vi) any SLA Credits earned by Customer for the Measurement Period, including the applicable credit tier and the dollar amount of the credit; and
(vii) a summary of all incidents classified as Severity 1 or Severity 2 during the Measurement Period, including resolution status and links to applicable Root Cause Analysis reports.
(b) Quarterly Service Review Report. In connection with the quarterly Steering Committee meetings described in Section 10, Provider shall prepare and present a quarterly report that includes, in addition to the information contained in the monthly reports for the applicable quarter: (i) Availability trend analysis over the trailing twelve (12) months; (ii) root cause categorization and frequency analysis for all Downtime incidents; (iii) remediation measures implemented during the quarter and their effectiveness; (iv) capacity planning projections and any anticipated risks to Availability in future Measurement Periods; (v) a reconciliation of all SLA Credits issued and applied during the quarter; and (vi) any recommended modifications to the SLA metrics, targets, or processes.
3.4 Dispute Resolution for Availability Calculations.
In the event that Customer disputes the Availability calculation for any Measurement Period as reflected in the monthly availability report delivered by Provider, the following dispute resolution process shall apply:
(a) Notice of Dispute. Customer shall notify Provider in writing of the dispute within fifteen (15) business days of Customer's receipt of the applicable monthly availability report. The notice shall specify in reasonable detail the basis for Customer's dispute, including any alternative data or calculations supporting Customer's position.
(b) Escalation Procedures. Upon receipt of a notice of dispute, the parties shall attempt to resolve the dispute through the escalation procedures set forth in the MSA, which provide for the following sequential escalation levels:
(i) Level 1 (Account Managers): The parties' designated account managers shall attempt to resolve the dispute within five (5) business days of the date of the notice of dispute.
(ii) Level 2 (VP-Level): If the dispute is not resolved at Level 1, it shall be escalated to the parties' respective Vice President-level (or equivalent) representatives, who shall attempt to resolve the dispute within ten (10) business days of escalation.
(iii) Level 3 (CEO/CIO): If the dispute is not resolved at Level 2, it shall be escalated to the Chief Executive Officer of Provider and the Chief Information Officer of Customer (or their designees), who shall attempt to resolve the dispute within fifteen (15) business days of escalation.
(c) External Dispute Resolution. If the dispute remains unresolved following completion of the escalation procedures, the dispute shall be subject to the dispute resolution provisions of the MSA, which provide for mediation administered by JAMS in New York, New York, followed by litigation in the state or federal courts located in the State of Delaware if mediation does not result in a resolution.
(d) Interim Treatment. Pending resolution of a dispute, Provider shall apply the SLA Credit amount, if any, that is not in dispute. Any additional credit determined to be owed to Customer following resolution of the dispute shall be applied to the next invoice following such resolution, together with interest at the rate of one and one-half percent (1.5%) per month on the disputed credit amount from the date such credit would have been due absent the dispute.
Section 4: Scheduled Maintenance
4.1 Standard Maintenance Windows.
Provider may perform Scheduled Maintenance during the following standard maintenance window:
Saturdays, 2:00 AM – 6:00 AM Eastern Time (a maximum of four (4) hours per week).
Downtime occurring during the standard maintenance window, where such maintenance has been noticed in accordance with Section 4.2, shall not count toward Downtime Minutes for purposes of the Availability calculation set forth in Section 3.1. Provider shall use commercially reasonable efforts to minimize the duration of platform unavailability during Scheduled Maintenance and to complete maintenance activities within the shortest practicable timeframe.
4.2 Advance Notice of Scheduled Maintenance.
Provider shall provide Customer with at least five (5) business days' advance written notice of any Scheduled Maintenance to be performed during the standard maintenance window. Such notice shall be delivered via email to Customer's designated operations contact and shall include: (a) the date and expected start time of the maintenance; (b) the expected duration of the maintenance; (c) a description of the maintenance activities to be performed; and (d) the anticipated impact on platform availability or functionality, if any.
Routine maintenance that does not result in platform unavailability or material degradation of performance—including, without limitation, rolling updates, hot patches, configuration changes, and minor software deployments that are performed without requiring platform downtime—does not require advance notice under this Section 4.2 but shall be logged in the availability dashboard described in Section 3.2(c) and reflected in the monthly availability report.
4.3 Emergency Maintenance.
Provider may perform maintenance outside the standard maintenance window on an emergency basis when such maintenance is necessary to address any of the following: (a) critical security vulnerabilities that pose an imminent threat to the confidentiality, integrity, or availability of Customer data or the SkyComply™ platform; (b) imminent service degradation or platform instability that, if not addressed, would be reasonably likely to result in unplanned Downtime; or (c) regulatory compliance requirements necessitating immediate remedial action.
(a) Notice. Provider shall provide Customer with as much advance notice of emergency maintenance as is reasonably practicable under the circumstances, and in any event shall notify Customer no later than thirty (30) minutes prior to the commencement of emergency maintenance. If prior notice is not feasible due to the urgency of the situation, Provider shall notify Customer immediately upon commencement of the emergency maintenance.
(b) Treatment as Downtime. Emergency maintenance shall count toward Downtime Minutes for purposes of the Availability calculation unless both of the following conditions are satisfied: (i) the emergency maintenance is required to remediate a critical security vulnerability (i.e., a vulnerability rated as "Critical" or "High" under the Common Vulnerability Scoring System (CVSS) version 3.1 or its successor) that, if left unpatched, would expose Customer data to material risk of unauthorized access, loss, or corruption; and (ii) Provider limits the duration of the emergency maintenance to the minimum time reasonably necessary to remediate the vulnerability.
(c) Monthly Cap on Excluded Emergency Maintenance. The total amount of emergency maintenance Downtime excluded from the Availability calculation pursuant to Section 4.3(b) shall not exceed four (4) hours in any single Measurement Period. Any emergency maintenance Downtime in excess of four (4) hours per Measurement Period shall count toward Downtime Minutes regardless of whether the conditions in Section 4.3(b) are otherwise satisfied.
4.4 Limitations on Maintenance Windows.
The following limitations apply to all Scheduled Maintenance and emergency maintenance:
(a) Peak Processing Periods. Provider shall not schedule maintenance—whether during the standard maintenance window or otherwise—during Customer's peak processing periods, which are defined as Monday through Friday, 6:00 AM – 10:00 PM Eastern Time, without Customer's prior written consent. Customer shall not unreasonably withhold or delay such consent in the case of emergency maintenance that satisfies the criteria set forth in Section 4.3.
(b) Monthly Maintenance Cap. Total Scheduled Maintenance (including both standard and emergency maintenance windows) shall not exceed sixteen (16) hours per calendar month. If Provider anticipates that Scheduled Maintenance in any calendar month will exceed sixteen (16) hours, Provider shall notify Customer at least ten (10) business days in advance and obtain Customer's prior written consent. Any Scheduled Maintenance in excess of sixteen (16) hours per calendar month that is not consented to by Customer in writing shall count toward Downtime Minutes for purposes of the Availability calculation.
Section 5: Service Level Credits
5.1 SLA Credit Tiers.
If Availability in any Measurement Period falls below the Availability Target, Customer shall be entitled to receive SLA Credits calculated as a percentage of the Monthly Subscription Fee for the applicable Measurement Period, in accordance with the following tiered schedule:
For the avoidance of doubt, SLA Credits are not cumulative across tiers; the applicable credit percentage shall be determined by the single tier into which the actual Availability level falls. By way of example, if Availability in a Measurement Period is 98.7%, the applicable SLA Credit would be twenty percent (20%) of the Monthly Subscription Fee, not the sum of 5% + 10% + 20%.
DRAFTING NOTE (INTERNAL — TO BE REMOVED BEFORE EXECUTION): In the initial draft prepared by Calderwood & Harkness, credits at the 99.9%–99.5% tier were set at 5%, consistent with Provider's standard enterprise SLA template. As a compromise for maintaining the 99.9% Availability Target (rather than Meridian's requested 99.95%), Provider has agreed to consider the addition of intermediate credit tiers and enhanced credit percentages. The following Enhanced Credit Tier Alternative is presented as a bracketed alternative for Customer's consideration. The final tier structure remains subject to further negotiation between the parties.
Enhanced Credit Tier Alternative [BRACKETED FOR NEGOTIATION]:
The Enhanced Credit Tier Alternative provides Customer with earlier and more granular credit entitlements, effectively delivering greater financial protection at Availability levels between 99.9% and 99.0%. In particular, the intermediate tier at 99.7% ensures that Customer receives a meaningful credit (10% vs. 5% under the standard tier) when Availability falls to a level that, while still above 99.5%, represents a significant deviation from the 99.9% target. Similarly, the enhanced credit percentages at the 99.5%–99.0% and 99.0%–98.0% tiers (15% and 25%, respectively, versus 10% and 20% under the standard tiers) reflect the parties' acknowledgment that extended periods of reduced Availability impose material operational costs on Customer that should be more robustly compensated.
5.2 Monthly Credit Cap.
SLA Credits in any single Measurement Period shall not exceed thirty percent (30%) of the Monthly Subscription Fee applicable to such Measurement Period. The maximum monthly SLA Credit amounts under the current fee structure are as follows:
(a) Year 1: 30% × $1,058,333.33 = $317,500.00 maximum monthly SLA Credit.
(b) Years 2 through 5 (prior to annual escalation): 30% × $777,083.33 = $233,125.00 maximum monthly SLA Credit.
In the event that the calculated SLA Credit for any Measurement Period would exceed the monthly credit cap, the SLA Credit for such Measurement Period shall be limited to thirty percent (30%) of the applicable Monthly Subscription Fee, and Customer shall not carry over or bank any excess credit amount to subsequent Measurement Periods.
5.3 Annual Credit Cap.
Aggregate SLA Credits issued to Customer in any twelve (12)-month period (measured from the anniversary of the Platform Go-Live Date) shall not exceed fifteen percent (15%) of the total annual subscription fees applicable to such twelve-month period. The maximum annual SLA Credit amounts under the current fee structure are as follows:
(a) Year 1: 15% × $12,700,000.00 = $1,905,000.00 maximum annual SLA Credit.
(b) Years 2 through 5 (prior to annual escalation): 15% × $9,325,000.00 = $1,398,750.00 maximum annual SLA Credit.
In the event that the aggregate SLA Credits issued in any twelve-month period reach the annual credit cap, no further SLA Credits shall accrue for the remainder of such twelve-month period; provided, however, that the occurrence of Availability failures giving rise to SLA Credits in excess of the annual cap shall be considered for purposes of determining whether a termination trigger under Section 6 has been satisfied.
DRAFTING NOTE (INTERNAL — TO BE REMOVED BEFORE EXECUTION): Meridian/HTM's position in their May 28, 2025 markup was to eliminate all caps on SLA Credits, asserting that Provider should bear unlimited financial responsibility for Availability failures. Provider's position, maintained in this revised draft, is that the annual cap at 15% of annual fees is appropriate and consistent with market practice for enterprise SaaS agreements in the financial services sector. As a compromise, this revised draft couples the maintained 15% annual cap with the Enhanced Credit Tier Alternative in Section 5.1, which provides Customer with materially greater financial protection at intermediate Availability levels and results in a higher aggregate credit exposure for Provider at Availability levels between 99.9% and 99.0%.
5.4 Credit Request Process.
The following procedures govern the request, verification, and issuance of SLA Credits:
(a) Submission. Customer must submit a written SLA Credit request to Provider within thirty (30) calendar days following the end of the Measurement Period in which the Availability failure giving rise to the credit request occurred. Requests submitted after the thirty (30)-day deadline shall be deemed waived unless Customer demonstrates that it did not receive the applicable monthly availability report within the timeframe specified in Section 3.3(a), in which case the thirty (30)-day period shall run from the date of Customer's actual receipt of the report.
(b) Content. Each SLA Credit request shall identify: (i) the applicable Measurement Period; (ii) the specific Downtime events giving rise to the credit request, including dates, times, and durations; (iii) the calculated Availability percentage for the Measurement Period; and (iv) the SLA Credit amount requested, with reference to the applicable credit tier under Section 5.1.
(c) Verification and Response. Provider shall verify Customer's SLA Credit request against Provider's monitoring records and availability data within fifteen (15) business days of receipt of the request. Provider shall notify Customer in writing of: (i) approval of the request, in whole or in part; (ii) denial of the request, with a reasonably detailed explanation of the basis for denial; or (iii) a request for additional information, in which case the fifteen (15)-business-day period shall be tolled until Customer provides the requested information.
(d) Application of Credits. Approved SLA Credits shall be applied as a credit against the next invoice issued by Provider to Customer following Provider's approval of the credit request. SLA Credits are not redeemable for cash, are not transferable, and may not be applied against any fees other than the subscription fees payable under the MSA and the applicable Order Form.
5.5 Sole and Exclusive Remedy.
SLA Credits constitute Customer's sole and exclusive financial remedy for Provider's failure to meet the Availability Target set forth in Section 2.1. Notwithstanding the foregoing, SLA Credits shall not limit, restrict, or waive:
(a) Customer's termination rights under Section 6 of this Exhibit A;
(b) any remedies expressly preserved under the MSA, including without limitation Provider's indemnification obligations under Article [12] of the MSA and Provider's liability for breaches of its confidentiality and data protection obligations under Articles [9] and [10] of the MSA and the Data Processing Addendum (Exhibit C);
(c) Customer's right to seek specific performance or injunctive relief to the extent available under the MSA; or
(d) any rights or remedies available to Customer under applicable law that cannot be waived by contract.
Section 6: Termination Rights for Chronic Availability Failures
6.1 Termination Trigger.
Customer shall have the right to terminate the MSA upon written notice to Provider if Availability falls below ninety-eight percent (98.0%) in any three (3) of any consecutive six (6) Measurement Periods (the "Primary Termination Trigger"). For purposes of this Section 6.1, the three Measurement Periods need not be consecutive, so long as they occur within a rolling window of six consecutive Measurement Periods.
Upon such termination, Provider shall refund to Customer all pre-paid subscription fees attributable to the unexpired portion of the then-current Term on a pro-rata basis, calculated from the effective date of termination through the end of the then-current Term. Such refund shall be paid to Customer within thirty (30) days of the effective date of termination. Customer's right to receive such refund is in addition to, and not in lieu of, any accrued and unpaid SLA Credits as of the effective date of termination.
6.2 Additional Termination Trigger (New in Revised Draft).
DRAFTING NOTE (INTERNAL — TO BE REMOVED BEFORE EXECUTION): This Section 6.2 is a new provision added in this revised draft as a further compromise in connection with maintaining the 99.9% Availability Target. The addition of this provision was discussed and approved by Amara Okafor (CISO) and Marcus Holt (CTO) as an acceptable concession given the low likelihood of triggering and the importance of securing Meridian's agreement to the 99.9% (rather than 99.95%) Availability standard. This provision gives Customer additional exit protection in the event of sustained Availability failures that fall short of the Primary Termination Trigger threshold but nonetheless demonstrate a pattern of underperformance.
In addition to the termination right set forth in Section 6.1, Customer shall have the right to terminate the MSA upon written notice to Provider if Availability falls below ninety-nine percent (99.0%) in any four (4) of any consecutive six (6) Measurement Periods (the "Secondary Termination Trigger"). As with the Primary Termination Trigger, the four Measurement Periods need not be consecutive, so long as they occur within a rolling window of six consecutive Measurement Periods.
Upon such termination, Provider shall refund to Customer all pre-paid subscription fees attributable to the unexpired portion of the then-current Term on a pro-rata basis, calculated and payable in the same manner as set forth in Section 6.1. Customer's right to receive such refund is in addition to, and not in lieu of, any accrued and unpaid SLA Credits as of the effective date of termination.
6.3 Cure Period.
Prior to exercising a termination right under Section 6.1 or Section 6.2, Customer shall provide Provider with written notice specifying the triggering Availability failures, including the applicable Measurement Periods and the Availability levels achieved during each such period (a "Termination Notice"). Following receipt of a Termination Notice, the following cure process shall apply:
(a) Remediation Plan. Provider shall have thirty (30) calendar days following receipt of the Termination Notice to prepare and deliver to Customer a written remediation plan that describes in reasonable detail the root causes of the triggering Availability failures, the specific corrective actions Provider proposes to implement, and the timeline for implementation. The remediation plan must be reasonably satisfactory to Customer, taking into account the nature and severity of the triggering failures and the adequacy of the proposed corrective measures.
(b) Performance Demonstration. If Provider delivers a remediation plan that is reasonably satisfactory to Customer, Provider shall have an opportunity to demonstrate improved performance. If Provider achieves Availability of at least ninety-nine and five-tenths percent (99.5%) in each of the two (2) Measurement Periods immediately following delivery of the remediation plan, Customer's termination right with respect to the triggering failures identified in the applicable Termination Notice shall be deemed waived. For the avoidance of doubt, such waiver applies only to the specific triggering failures identified in the Termination Notice and does not affect Customer's right to terminate upon the occurrence of subsequent triggering events.
(c) Limitation on Cure Rights. Provider may exercise the cure right set forth in this Section 6.3 no more than one (1) time during the Initial Term of the MSA. If Provider has previously exercised and successfully completed a cure under this Section 6.3, any subsequent Termination Notice delivered by Customer shall be effective immediately upon the expiration of a thirty (30)-day wind-down period, and Provider shall not be entitled to present a further remediation plan or performance demonstration period.
6.4 No Waiver.
Customer's election not to exercise its termination rights following the occurrence of a Primary Termination Trigger or Secondary Termination Trigger shall not constitute a waiver of Customer's right to terminate upon the occurrence of a subsequent triggering event. Each occurrence of a triggering event under Section 6.1 or Section 6.2 shall give rise to an independent termination right. The parties acknowledge that Customer's continued use of the SkyComply™ platform following a triggering event does not constitute acceptance of the reduced Availability level or a modification of the Availability Target.
Section 7: Incident Response and Resolution
7.1 Severity Classifications.
All incidents affecting the availability, performance, or functionality of the SkyComply™ platform shall be classified by Provider in accordance with the following severity matrix. Provider shall assign the initial Severity Level classification; provided, however, that Customer may request reclassification to a higher Severity Level by providing a reasonable justification, and Provider shall not unreasonably refuse such request.
For purposes of this Section 7.1:
(a) "Acknowledgment" means Provider's confirmation to Customer that the incident has been received, logged, and assigned to a support engineer or incident response team, together with an initial severity classification.
(b) "First Response" means the initial substantive communication from Provider's support team to Customer that includes a preliminary assessment of the incident, identification of probable cause (if determinable), and a proposed action plan or next steps for diagnosis and resolution.
(c) "Resolution Target" means the target time within which Provider shall restore affected functionality to normal operating parameters. Resolution targets are measured from the time of Acknowledgment. Resolution targets are commercially reasonable objectives and are not absolute guarantees; provided, however, that repeated or material failures to meet Resolution Targets shall be addressed through the governance mechanisms in Section 10 and may constitute evidence of a material breach of this SLA.
7.2 Incident Communication Protocol.
Provider shall maintain and make available to Customer the following incident communication capabilities:
(a) 24/7/365 Incident Response Contact. Provider shall designate a 24/7/365 incident response contact accessible to Customer by telephone (dedicated toll-free number) and email (dedicated support email address). The contact information for the incident response team shall be provided to Customer on the Platform Go-Live Date and updated in writing within five (5) business days of any change.
(b) Severity 1 Status Updates. For all Severity 1 incidents, Provider shall provide status updates to Customer's designated incident contact every thirty (30) minutes from the time of Acknowledgment until the incident is resolved and platform functionality is restored. Status updates shall include a current assessment of the incident's scope and impact, actions being taken, and estimated time to resolution (if determinable).
(c) Severity 2 Status Updates. For all Severity 2 incidents, Provider shall provide status updates to Customer's designated incident contact every two (2) hours from the time of Acknowledgment until the incident is resolved. Status updates shall include the information described in Section 7.2(b).
(d) Severity 3 Status Updates. For all Severity 3 incidents, Provider shall provide status updates to Customer's designated incident contact every business day until the incident is resolved. The frequency of status updates for Severity 3 incidents may be adjusted by mutual agreement of the parties' account managers.
(e) Communication Methods. All incident status updates shall be delivered via email and, for Severity 1 incidents, supplemented by telephone communication to Customer's designated incident contact. Provider shall additionally post incident status information on the availability dashboard described in Section 3.2(c).
7.3 Incident Reporting and Root Cause Analysis.
For all incidents classified as Severity 1 or Severity 2, Provider shall prepare and deliver to Customer a Root Cause Analysis ("RCA") report within five (5) business days following the resolution of the incident. The RCA report shall contain, at a minimum, the following information:
(a) a detailed timeline of the incident, from initial detection or report through resolution, including all significant milestones, escalations, and communications;
(b) identification and description of the root cause of the incident, including any contributing factors;
(c) an assessment of the impact of the incident on Customer's operations, including the number of affected users, the specific features or functions that were impaired, and any impact on Customer data (including data integrity, availability, or confidentiality);
(d) a description of the remediation actions taken to resolve the incident and restore normal platform operations; and
(e) a description of the preventive measures that Provider has implemented or proposes to implement to reduce the likelihood of recurrence of substantially similar incidents, including timelines for implementation of any such measures.
Provider shall make the incident response team available for a post-incident review call with Customer's technical and operational personnel within ten (10) business days of delivery of each RCA report for Severity 1 incidents, and upon Customer's reasonable request for Severity 2 incidents.
Recurring Severity 1 Incidents. If three (3) or more Severity 1 incidents occur within a rolling twelve (12)-month period and are determined (based on the applicable RCA reports) to arise from substantially similar root causes, such pattern of recurring incidents shall trigger: (i) mandatory escalation to the Steering Committee described in Section 10; and (ii) Provider's obligation to develop and deliver to the Steering Committee a long-term remediation plan within thirty (30) calendar days of the third qualifying incident. The long-term remediation plan shall address the systemic root cause, specify corrective actions with milestones and timelines, and identify the resources Provider will dedicate to implementation. The Steering Committee shall monitor Provider's progress against the plan at each quarterly review.
7.4 Relationship to Security Incident Notification.
The incident response obligations set forth in this Section 7 are in addition to, and do not limit or supersede, Provider's security incident notification obligations under the Security Exhibit (Exhibit B to the MSA) and the Data Processing Addendum (Exhibit C to the MSA). In the event that an incident affecting the SkyComply™ platform constitutes both a Downtime event under this Exhibit A and a Security Incident under Exhibit B or a Personal Data Breach under Exhibit C, Provider shall comply with the notification and response obligations under all applicable exhibits and addenda concurrently. To the extent any conflict exists between the notification timing requirements of this Exhibit A and those of Exhibit B or Exhibit C, the most stringent notification timeline shall control. Customer is referred to Exhibit B, Section [4], for notification timing related to confirmed Security Incidents affecting Customer data.
Section 8: Performance Standards Beyond Availability
8.1 Response Time.
In addition to the Availability Target set forth in Section 2, Provider shall maintain the following performance standards with respect to the responsiveness of the SkyComply™ platform:
(a) API Response Time. Provider shall maintain average API response times of no more than five hundred (500) milliseconds, measured at the application layer (exclusive of Customer-side network latency), for standard transaction-monitoring queries during normal operating conditions. Response time shall be measured as the elapsed time between Provider's receipt of an API request at the application server and Provider's transmission of the corresponding API response.
(b) User Interface Response Time. Provider shall use commercially reasonable efforts to maintain average page-load times for the SkyComply™ web-based user interface of no more than three (3) seconds under normal operating conditions, as measured from the server-side rendering time.
(c) Reporting. Provider shall include API response time metrics and, to the extent available, user interface response time metrics in the monthly availability report described in Section 3.3(a). Response time metrics shall be reported as average, median, 95th percentile, and 99th percentile values for each Measurement Period.
8.2 Batch Processing Windows.
Provider shall complete all scheduled batch processing jobs—including, without limitation, Anti-Money Laundering ("AML") screening runs, sanctions list updates, suspicious activity report data compilation, and regulatory reporting data aggregation—within the processing windows mutually agreed upon by the parties during the Implementation Period and documented in the applicable operational runbook (the "Batch Processing Schedule"). The Batch Processing Schedule shall be finalized no later than thirty (30) days prior to the Platform Go-Live Date.
Failure to complete a batch processing job within the designated processing window shall be classified as a Severity 2 incident for purposes of Section 7, unless the parties' account managers mutually agree in writing to a different severity classification based on the specific circumstances, including the nature of the job, the extent of the delay, and the operational impact on Customer.
8.3 Data Throughput.
The SkyComply™ platform shall be designed, provisioned, and maintained to process Customer's transaction volumes without material degradation of response time or Availability. Customer's estimated transaction volumes at the Platform Go-Live Date are approximately 2,400,000 transactions per business day, based on Customer's current production environment metrics. Provider shall monitor transaction throughput on an ongoing basis and shall proactively notify Customer if actual or projected transaction volumes approach the capacity thresholds of the current platform configuration. Capacity expansion to accommodate growth in transaction volumes beyond the initial estimates shall be addressed through the change management procedures set forth in the MSA.
Section 9: Subprocessor SLA Flow-Down
9.1 Orion Cloud Services, Inc.
Provider acknowledges that the SkyComply™ platform is hosted on cloud infrastructure provided by Orion Cloud Services, Inc. ("Orion Cloud"), a Delaware corporation with principal offices at 4500 Great America Parkway, Santa Clara, CA 95054. Provider represents that, as of the date of this Exhibit A, Orion Cloud's current platform service level agreement provides for monthly uptime of not less than 99.95% for the compute, storage, and networking services utilized by the SkyComply™ platform.
Provider shall maintain commercially reasonable contractual arrangements with Orion Cloud sufficient to ensure that Orion Cloud's SLA commitments applicable to the infrastructure hosting the SkyComply™ platform are no less favorable than those in effect as of the date of the MSA. Provider shall promptly notify Customer of any material change to Orion Cloud's SLA terms that could adversely affect Provider's ability to meet the Availability Target under this Exhibit A.
Provider remains fully responsible to Customer for all Downtime, regardless of whether such Downtime is attributable in whole or in part to Orion Cloud infrastructure failures, outages, degradations, or maintenance activities. Orion Cloud infrastructure outages shall not constitute Excused Downtime under Section 1.3 of this Exhibit A, and Provider shall not assert Orion Cloud's infrastructure SLA or any credits received thereunder as a defense to or offset against Provider's SLA Credit obligations under Section 5.
9.2 Subprocessor Changes.
Any change in Provider's infrastructure hosting provider—including a migration from Orion Cloud to a different infrastructure-as-a-service, platform-as-a-service, or hosting provider—shall be subject to the subprocessor approval process set forth in the Data Processing Addendum (Exhibit C to the MSA). Such process requires, at a minimum:
(a) Advance Notice. Provider shall provide Customer with at least thirty (30) calendar days' advance written notice of any proposed change in infrastructure hosting provider, including a description of the proposed replacement provider, its relevant certifications and compliance posture, and the terms of its SLA commitments.
(b) Customer Objection Right. Customer shall have the right to object to the proposed change on reasonable grounds, including concerns related to security, data sovereignty, regulatory compliance, or the adequacy of the replacement provider's SLA commitments. If Customer objects, the parties shall negotiate in good faith to resolve Customer's concerns.
(c) Minimum SLA Commitments. Provider shall ensure that any replacement infrastructure hosting provider maintains SLA commitments—including uptime guarantees, incident response commitments, and data protection standards—that are at least as favorable as those provided by Orion Cloud as of the date of the MSA.
Section 10: Steering Committee and Governance
10.1 Quarterly Service Reviews.
The Steering Committee established under Article [8] of the MSA shall conduct quarterly reviews of SLA performance in connection with its regularly scheduled meetings. Each quarterly service review shall include, at a minimum, the following agenda items:
(a) review of Availability trends for the preceding quarter and trailing twelve (12) months, including comparison to the Availability Target;
(b) summary of all incidents classified as Severity 1 and Severity 2 during the preceding quarter, including the status of outstanding Root Cause Analysis reports and remediation actions;
(c) reconciliation of SLA Credits issued and applied during the preceding quarter, including year-to-date totals and comparison to the annual credit cap;
(d) capacity planning analysis, including current and projected transaction volumes, infrastructure utilization rates, and any anticipated capacity constraints;
(e) review of upcoming Scheduled Maintenance activities for the following quarter, including any planned major upgrades, migrations, or infrastructure changes; and
(f) discussion of any proposed changes to SLA metrics, targets, credit structures, or other terms of this Exhibit A, with any mutually agreed modifications to be documented in accordance with Section 10.3.
10.2 Designated Representatives.
The following individuals are designated as the initial Relationship Leads for purposes of day-to-day management of the SLA relationship and coordination of quarterly service reviews:
Provider's Relationship Lead: Tara Bellingham, Vice President, Enterprise Sales, Skybridge Fintech Ltd. Email: t.bellingham@skybridgefintech.com. Phone: (302) 555-4820.
Customer's Relationship Lead: Luis Arriaga, Senior Vice President, Procurement & Vendor Management, Meridian National Bank, N.A. Email: luis.arriaga@meridianbank.com. Phone: (212) 555-6140.
Either party may change its designated Relationship Lead by providing written notice to the other party at least ten (10) business days prior to the effective date of the change.
10.3 Annual SLA Review.
The parties shall conduct a comprehensive annual review of the SLA metrics, targets, credit structure, and operational processes set forth in this Exhibit A within sixty (60) days following each anniversary of the Platform Go-Live Date. The annual review shall consider, among other things, changes in Customer's operational requirements, industry benchmarks for SaaS platform performance, Provider's infrastructure capacity and technology roadmap, and the parties' experience under this Exhibit A during the preceding year. Any modifications to this Exhibit A agreed upon during the annual review shall be documented in a written amendment executed by authorized representatives of both parties in accordance with Section 11.3.
Section 11: General Provisions
11.1 Governing Law.
This Exhibit A shall be governed by, and construed in accordance with, the laws of the State of Delaware, without regard to its conflict of laws principles, consistent with the governing law provision of the MSA.
11.2 Order of Precedence.
This Exhibit A is an integral part of the MSA and is incorporated herein by reference. In the event of any conflict, ambiguity, or inconsistency between the terms of this Exhibit A and the terms of the MSA (including any other exhibits or schedules thereto), the terms of the MSA shall control and take precedence, unless this Exhibit A expressly states that a specific provision herein supersedes a particular provision of the MSA with respect to the subject matter addressed in such provision. The parties intend that this Exhibit A and the MSA be read together as a single, integrated agreement to the greatest extent possible.