1009-00007 · Skybridge Fintech Ltd · Transaction Documents/Exhibits

sla-exhibit-initial-draft.docx DOCUMENT Funds

28 / 35 ← → ✕

CONFIDENTIAL TREATMENT REQUESTED — INITIAL DRAFT Prepared by Calderwood & Harkness LLP

EXHIBIT A

SERVICE LEVEL AGREEMENT

to the Master Software-as-a-Service Agreement

between

SKYBRIDGE FINTECH LTD. ("Provider" or "Licensor") a Delaware limited company 1400 Concord Pike, Suite 320 Wilmington, DE 19803

and

MERIDIAN NATIONAL BANK, NATIONAL ASSOCIATION ("Customer" or "Licensee") a national banking association 600 Lexington Avenue, 40th Floor New York, NY 10022

relating to the

SkyComply™ AI-Driven AML and Transaction-Monitoring Platform

INITIAL DRAFT — CONFIDENTIAL Prepared by Calderwood & Harkness LLP June 12, 2025

This Exhibit A (this "SLA" or "Exhibit A") is incorporated into and forms part of the Master Software-as-a-Service Agreement (the "MSA") entered into between Skybridge Fintech Ltd. ("Provider") and Meridian National Bank, National Association ("Customer"). Capitalized terms used but not defined herein shall have the meanings ascribed to them in the MSA. In the event of any conflict between the terms of this Exhibit A and the terms of the MSA, the MSA shall control unless this Exhibit A expressly states otherwise. This Exhibit A sets forth the service levels, availability commitments, incident response obligations, and related credit mechanisms applicable to Provider's delivery of the SkyComply™ AI-driven anti-money-laundering and transaction-monitoring platform (the "Platform") to Customer under the MSA.

Section 1: Definitions

For purposes of this Exhibit A, the following terms shall have the meanings set forth below. Terms defined in the MSA and used but not separately defined in this Exhibit A shall retain the meanings given to them in the MSA.

1.1 "Availability" or "Uptime" means the percentage of time during a Measurement Period that the Platform is operational and accessible to Customer's authorized users, measured as set forth in Section 3 below. For the avoidance of doubt, "operational and accessible" means that Customer's authorized users are able to log in to the Platform and access its core functionality, including AML transaction-monitoring, alert generation, case management, and regulatory reporting, without material degradation.

1.2 "Downtime" means any period during which the Platform is unavailable to Customer's authorized users, excluding Scheduled Maintenance Windows and Excused Downtime. Downtime shall be measured from the time the unavailability is first detected by Provider's monitoring tools or first reported by Customer, whichever is earlier, until the time the Platform is restored to full operational status.

1.3 "Excused Downtime" means periods of unavailability caused by any of the following:

(a) force majeure events as defined in the MSA;

(b) Customer's acts or omissions, including Customer's misuse of the Platform or breach of the Acceptable Use Policy (Exhibit D to the MSA);

(c) failures of Customer's own systems, networks, hardware, or equipment, including but not limited to Customer's internal network infrastructure, firewalls, VPN connections, or endpoint devices;

(d) failures of third-party internet service providers or telecommunications carriers not within Provider's reasonable control;

(e) any actions taken by Provider at Customer's express written request that result in downtime, including but not limited to configuration changes, data migrations, or customization activities requested by Customer.

1.4 "Measurement Period" means each calendar month during the Term, beginning at 12:00:00 AM Eastern Time on the first day and ending at 11:59:59 PM Eastern Time on the last day of such calendar month. The first Measurement Period shall commence on the Platform Go-Live Date and shall consist of the remaining days of the calendar month in which the Platform Go-Live Date occurs.

1.5 "Monthly Subscription Fee" means the monthly portion of the annual subscription fee payable by Customer under the applicable Order Form executed in connection with the MSA. For purposes of this Exhibit A, the Monthly Subscription Fee shall be calculated as follows:

(a) Year 1: $12,700,000 ÷ 12 = $1,058,333 per month.

(b) Years 2 through 5: $9,325,000 ÷ 12 = $777,083 per month, in each case subject to adjustment for the annual escalator beginning in Year 3 as set forth in the Order Form.

1.6 "Platform" means the SkyComply™ AI-driven anti-money-laundering and transaction-monitoring platform provided by Provider as a software-as-a-service solution under the MSA, including all modules, features, functionalities, updates, and enhancements made generally available by Provider to its customers during the Term.

1.7 "Platform Go-Live Date" means the date on which the Platform is made available for production use by Customer in accordance with the implementation plan set forth in the MSA, targeted as March 1, 2026, or such other date as the parties may agree in writing.

1.8 "Scheduled Maintenance Window" means the recurring weekly maintenance period described in Section 4 of this Exhibit A, during which Provider may perform routine maintenance, updates, patches, and upgrades to the Platform and its underlying infrastructure.

1.9 "SLA Credit" means the service level credit to which Customer is entitled in the event Provider fails to meet the Availability Target, calculated as set forth in Section 6 of this Exhibit A.

1.10 "Severity Level" means the classification of incidents affecting the Platform as described in Section 8 of this Exhibit A, based on the nature, scope, and impact of the incident on Customer's operations.

1.11 "Total Available Minutes" means the total number of minutes in a given Measurement Period, minus the minutes attributable to Scheduled Maintenance Windows and Excused Downtime. Total Available Minutes represents the denominator used in calculating Availability for purposes of determining compliance with the Availability Target and any SLA Credits owed.

Section 2: Availability Target

2.1 Monthly Availability Target. Provider shall use commercially reasonable efforts to maintain Platform Availability of at least 99.9% per Measurement Period (the "Availability Target"), measured exclusive of Scheduled Maintenance Windows and Excused Downtime. The parties acknowledge that the 99.9% Availability Target permits a maximum of approximately forty-three (43) minutes of unscheduled Downtime per Measurement Period in a thirty (30)-day month. Provider's commitment to the Availability Target is a material obligation under the MSA, and Customer's agreement to the pricing, term, and other provisions of the MSA is made in reliance upon Provider's commitment to achieve and maintain the Availability Target throughout the Term.

2.2 Commencement. The Availability Target shall become effective on the Platform Go-Live Date (targeted: March 1, 2026) and shall continue in full force and effect throughout the Term of the MSA, including any renewal periods. During any implementation or pilot period preceding the Platform Go-Live Date, Provider shall use commercially reasonable efforts to maintain Platform availability consistent with the Availability Target, but no SLA Credits shall accrue for any failure to achieve the Availability Target prior to the Platform Go-Live Date.

2.3 Scope. The Availability Target applies to the production instance of the Platform as hosted by Provider's cloud infrastructure provider, Orion Cloud Services, Inc. ("Orion Cloud"), within the continental United States, specifically the US-East (Virginia) and US-West (Oregon) regions. For the avoidance of doubt, the following environments and components are excluded from the Availability Target:

(a) Non-production environments, including sandbox, staging, quality assurance (QA), user acceptance testing (UAT), and development environments;

(b) Any Customer-specific testing or training environments provisioned by Provider at Customer's request;

(c) Third-party integrations or data feeds not directly hosted or managed by Provider, except to the extent that Provider's Platform functionality is dependent upon such integrations for core AML transaction-monitoring and alerting capabilities, in which case the unavailability of such integrations shall be considered in the Availability calculation to the extent attributable to Provider's acts or omissions.

Section 3: Availability Measurement Methodology

3.1 Calculation. Monthly Availability 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 Measurement Period minus minutes attributable to Scheduled Maintenance Windows and Excused Downtime.

(b) Downtime Minutes equals the aggregate number of minutes during the Measurement Period in which the Platform was unavailable to Customer's authorized users, excluding Scheduled Maintenance Windows and Excused Downtime.

The resulting Availability percentage shall be rounded to two (2) decimal places for purposes of determining compliance with the Availability Target and calculating any applicable SLA Credits.

3.2 Monitoring Tools. Provider shall monitor Platform Availability using automated synthetic monitoring tools that test Platform accessibility at intervals of no greater than five (5) minutes from at least two (2) geographically distinct monitoring points within the continental United States. Provider's monitoring infrastructure shall include, at a minimum, HTTP/HTTPS endpoint checks, API health checks, and database connectivity verification. Provider shall maintain the monitoring tools in good working order throughout the Term and shall promptly notify Customer of any material changes to its monitoring methodology, tools, or procedures. Customer shall have the right to deploy its own independent monitoring tools, and in the event of any discrepancy between Provider's monitoring data and Customer's independently collected monitoring data, the parties shall work together in good faith to reconcile such data.

3.3 Monitoring Dashboard. Provider shall make available to Customer a real-time availability dashboard accessible via the Platform's administrative console, displaying current and historical availability metrics on a rolling twelve (12)-month basis. The monitoring dashboard shall include, at a minimum, the following information:

(a) Current Platform status (operational, degraded, or unavailable);

(b) Real-time Availability percentage for the current Measurement Period;

(d) Active incidents, including severity classification, status, and estimated time to resolution;

(e) Upcoming Scheduled Maintenance Windows; and

(f) SLA Credit status for the current and prior Measurement Periods.

The monitoring dashboard shall be accessible to Customer's designated administrators at all times, including during periods of Platform Downtime, through an independent hosting mechanism separate from the Platform's production infrastructure.

3.4 Monthly Reporting. Within ten (10) business days following the end of each Measurement Period, Provider shall deliver to Customer a written Availability Report (the "Availability Report") setting forth the following information for the applicable Measurement Period:

(a) The total number of minutes in the Measurement Period;

(b) The total number of minutes attributable to Scheduled Maintenance Windows;

(c) The total number of minutes attributable to Excused Downtime, together with a description of each period of Excused Downtime and the category under Section 5.1 to which it is attributed;

(d) The total number of Downtime minutes, together with a description of each incident giving rise to Downtime, including the date, start time, end time, duration, root cause (if known), and corrective action taken;

(e) The calculated Availability percentage for the Measurement Period; and

(f) Any SLA Credits earned by Customer for the Measurement Period, together with the calculation supporting each such credit.

The Availability Report shall be delivered to Customer's designated operations contact in a format reasonably acceptable to Customer (PDF or electronic format through the Platform's administrative console). Provider shall retain all underlying monitoring logs, incident records, and supporting documentation for each Availability Report for a period of not less than three (3) years following the applicable Measurement Period, and shall make such records available to Customer upon reasonable request.

3.5 Disputes Regarding Measurement. In the event Customer disputes the Availability calculation for any Measurement Period, Customer shall notify Provider in writing within fifteen (15) business days of receipt of the applicable Availability Report. Such notice shall set forth the basis for Customer's dispute, including any supporting data or monitoring logs in Customer's possession. The parties shall cooperate in good faith to resolve the dispute, including by jointly reviewing monitoring logs, incident records, and any third-party monitoring data available to either party. If the dispute cannot be resolved within ten (10) business days following receipt of Customer's dispute notice, the dispute shall be escalated in accordance with the escalation procedures set forth in Section 10 of this Exhibit A. Pending resolution of any dispute, the SLA Credit (if any) claimed by Customer shall be provisionally applied to Customer's account, subject to adjustment following resolution of the dispute.

Section 4: Scheduled Maintenance Windows

4.1 Standard Maintenance Window. Provider's standard Scheduled Maintenance Window shall be Saturdays from 2:00 AM to 6:00 AM Eastern Time (a maximum of four (4) hours per week). During the Scheduled Maintenance Window, Provider may perform routine maintenance activities, including but not limited to software updates, patches, security fixes, database optimization, infrastructure upgrades, and configuration changes. Provider acknowledges that Meridian National Bank operates certain automated AML processes and batch jobs during overnight and weekend hours, and Provider shall use commercially reasonable efforts to coordinate maintenance activities to minimize disruption to such processes.

4.2 Advance Notice. Provider shall provide Customer with at least seventy-two (72) hours' advance written notice (via email to Customer's designated operations contact) of any scheduled maintenance to be performed during the Scheduled Maintenance Window. Such notice shall include a description of the maintenance activities to be performed, the expected duration of the maintenance, any anticipated impact on Platform functionality or performance, and any actions required of Customer in connection with the maintenance (e.g., clearing browser caches, restarting sessions). In the event that Provider determines that a scheduled maintenance activity may result in Platform unavailability exceeding two (2) hours, Provider shall use commercially reasonable efforts to provide at least five (5) business days' advance notice and shall coordinate the timing with Customer's designated operations contact.

4.3 Emergency Maintenance. In the event Provider determines that emergency maintenance is required to address a critical security vulnerability or imminent threat to Platform stability, Provider may perform maintenance outside of the Scheduled Maintenance Window, provided that:

(a) Provider notifies Customer as soon as reasonably practicable (and in no event later than one (1) hour after commencement of emergency maintenance), including a description of the nature of the emergency and the expected duration of the maintenance;

(b) Provider uses commercially reasonable efforts to minimize the duration of such maintenance and its impact on Customer's operations; and

Emergency maintenance shall be treated as Excused Downtime for purposes of Availability calculations only if Provider demonstrates, to Customer's reasonable satisfaction, that the maintenance was necessary to address a critical security vulnerability or imminent threat to Platform stability. Provider shall provide Customer with a written explanation of the circumstances giving rise to the emergency maintenance within two (2) business days following the occurrence. For the avoidance of doubt, emergency maintenance that does not meet the foregoing criteria shall be treated as Downtime for purposes of the Availability calculation.

4.4 Limitation on Maintenance. Provider shall not schedule more than one (1) Scheduled Maintenance Window per week. Total Scheduled Maintenance shall not exceed sixteen (16) hours per calendar month under ordinary circumstances. In the event that Provider anticipates that Scheduled Maintenance in any calendar month will exceed sixteen (16) hours, Provider shall provide advance notice to Customer and obtain Customer's prior written consent (such consent not to be unreasonably withheld). Provider shall use commercially reasonable efforts to complete all maintenance activities within the Scheduled Maintenance Window with minimal impact to Customer's operations, including by employing rolling deployments, blue-green deployment strategies, and other techniques designed to maintain Platform availability during maintenance activities to the greatest extent practicable.

Section 5: Excused Downtime

5.1 Categories of Excused Downtime. The following categories of downtime shall be excluded from the Availability calculation:

(a) Downtime during Scheduled Maintenance Windows, as defined in and subject to the limitations of Section 4 of this Exhibit A;

(b) Downtime caused by force majeure events as defined in the MSA, including but not limited to natural disasters, acts of war or terrorism, pandemics, government actions, and other events beyond the reasonable control of either party;

(c) Downtime attributable to Customer's acts, omissions, or negligence, including misuse of the Platform, unauthorized modifications to Platform configurations, introduction of malware or malicious code by Customer's users, or breach of the Acceptable Use Policy set forth in Exhibit D to the MSA;

(d) Downtime caused by failures of Customer's own systems, networks, hardware, or internet connectivity, including but not limited to failures of Customer's internal LAN/WAN infrastructure, firewalls, load balancers, VPN connections, or endpoint devices used to access the Platform;

(e) Downtime caused by failures of third-party internet service providers or telecommunications carriers outside Provider's reasonable control, provided that this exclusion shall not apply to failures of Orion Cloud Services, Inc. or any other infrastructure provider directly contracted by Provider to host or deliver the Platform;

(f) Downtime resulting from actions taken by Provider at Customer's express written request, including but not limited to custom configuration changes, data migration activities, or Platform modifications requested by Customer, provided that Provider has notified Customer in advance that such actions may result in downtime; and

(g) Downtime caused by denial-of-service attacks or other malicious third-party activity directed at Customer's infrastructure (rather than at Provider's Platform or Provider's hosting infrastructure), provided that if such attacks are directed at Provider's Platform or hosting infrastructure, the resulting downtime shall not be Excused Downtime.

5.2 Documentation. Provider shall document the cause and duration of all Excused Downtime in detail and include such documentation in the monthly Availability Report delivered pursuant to Section 3.4. For each period of Excused Downtime, Provider shall identify the applicable category under Section 5.1, the start and end times of the period, the total duration in minutes, and a narrative description of the cause. Customer reserves the right to dispute the classification of any period as Excused Downtime in accordance with the dispute resolution procedures set forth in Section 3.5. Provider bears the burden of demonstrating that any period of downtime qualifies as Excused Downtime under the applicable category.

Section 6: SLA Credits

6.1 Credit Tiers. If Provider fails to meet the Availability Target in any Measurement Period, Customer shall be entitled to SLA Credits as set forth in the following table:

For purposes of the foregoing table, the applicable credit tier shall be determined based on the calculated Availability percentage for the Measurement Period, rounded to two (2) decimal places. Only one credit tier shall apply per Measurement Period; the tiers are not cumulative.

6.2 Credit Calculation. SLA Credits shall be calculated as a percentage of the Monthly Subscription Fee for the Measurement Period in which the Availability failure occurred. The Monthly Subscription Fee for credit calculation purposes shall be as follows:

(a) Year 1: $1,058,333 (i.e., $12,700,000 ÷ 12).

(b) Years 2 through 5: $777,083 (i.e., $9,325,000 ÷ 12).

In each case, the Monthly Subscription Fee shall be subject to adjustment for any annual escalator applied pursuant to the Order Form. If the Order Form is amended or supplemented during the Term (including to add incremental users at $275 per user per year), the Monthly Subscription Fee for SLA Credit calculation purposes shall be adjusted to reflect the then-current total annual subscription fee divided by twelve (12).

6.3 Monthly Credit Cap. The maximum SLA Credit payable in any single Measurement Period shall not exceed thirty percent (30%) of the Monthly Subscription Fee for such Measurement Period. Accordingly, the maximum SLA Credit amounts are as follows:

(a) Year 1: $317,500 per month (30% × $1,058,333).

(b) Years 2 through 5: $233,125 per month (30% × $777,083).

These amounts are subject to adjustment in the event the Monthly Subscription Fee is adjusted pursuant to Section 6.2 above.

6.4 Annual Credit Cap. The aggregate SLA Credits payable in any twelve (12)-month period during the Term shall not exceed fifteen percent (15%) of the annual subscription fee for such period. Accordingly, the maximum annual SLA Credit amounts are as follows:

(a) Year 1: $1,905,000 (15% × $12,700,000).

(b) Years 2 through 5: $1,398,750 (15% × $9,325,000).

For purposes of calculating the annual credit cap, the twelve (12)-month period shall be measured on a rolling basis beginning on the Platform Go-Live Date and each anniversary thereof.

6.5 Credit Request Procedure. To receive an SLA Credit, Customer must submit a written credit request to Provider within thirty (30) days following the end of the Measurement Period in which the Availability failure occurred. The credit request shall be submitted to Provider's designated account manager and shall identify the following:

(a) The Measurement Period to which the credit request relates;

(b) The date(s) and time(s) of Downtime giving rise to the credit request;

(d) Any supporting documentation, including Customer's own monitoring data, incident reports, or correspondence with Provider's support team.

Provider shall respond to the credit request within fifteen (15) business days of receipt. If Provider agrees that a credit is owed, Provider shall confirm the credit amount in writing. If Provider disputes the credit request, Provider shall provide a written explanation of the basis for the dispute, and the matter shall be resolved in accordance with the dispute resolution procedures set forth in Section 3.5 and Section 10.

6.6 Application of Credits. Approved SLA Credits shall be applied as a credit against the next invoice issued to Customer following approval of the credit. If no further invoices are to be issued (e.g., because the Term is expiring), approved SLA Credits shall be refunded to Customer within thirty (30) days. SLA Credits may not be redeemed for cash (except as set forth in the preceding sentence) and shall not be carried forward beyond the Term. SLA Credits shall not be applied against implementation fees, professional services fees, or any other fees that are not part of the recurring subscription fee.

6.7 Sole and Exclusive Remedy. Subject to Section 7 (Chronic Failure — Termination Right), SLA Credits shall be Customer's sole and exclusive remedy, and Provider's sole and exclusive liability, for Provider's failure to meet the Availability Target set forth in Section 2. For the avoidance of doubt, the SLA Credit mechanism set forth in this Section 6 does not limit or waive any other remedies available to Customer under the MSA, at law, or in equity for breach of any other obligation of Provider, including but not limited to Provider's obligations with respect to data security, confidentiality, intellectual property, indemnification, or compliance with applicable law. Nothing in this Section 6.7 shall be construed to limit the aggregate liability cap set forth in the MSA.

Section 7: Chronic Failure — Termination Right

7.1 Chronic Failure Threshold. In the event that Platform Availability falls below 98.0% in three (3) or more of any six (6) consecutive Measurement Periods (a "Chronic Failure"), Customer shall have the right to terminate the MSA upon sixty (60) days' prior written notice to Provider. Customer's termination right under this Section 7 shall be in addition to, and not in lieu of, any SLA Credits to which Customer may be entitled under Section 6 for the Measurement Periods constituting the Chronic Failure.

7.2 Effect of Termination. Upon termination of the MSA for Chronic Failure pursuant to this Section 7:

(a) Provider shall refund to Customer any pre-paid fees attributable to the period following the effective date of termination on a pro-rata basis, calculated as the proportion of the remaining Term (measured in days) relative to the total Term for which such fees were pre-paid. Such refund shall be paid within thirty (30) days of the effective date of termination.

(b) The data export and certified destruction obligations set forth in the MSA and the Data Processing Addendum (Exhibit C to the MSA) shall apply in full, including Provider's obligation to make all Customer Data available for export in a commercially standard format within thirty (30) days of the effective date of termination.

(c) No early termination fee shall be payable by Customer, notwithstanding any provision of the MSA or Order Form to the contrary.

(d) Customer's right to any accrued but unpaid SLA Credits shall survive termination.

7.3 Cure Period. Notwithstanding the foregoing, if, following delivery of a termination notice under Section 7.1, Provider demonstrates to Customer's reasonable satisfaction that the cause of the Chronic Failure has been identified and remediated, and Provider achieves at least 99.9% Availability for two (2) consecutive Measurement Periods following delivery of a written cure notice to Customer, Customer's termination right under this Section 7 shall be deemed waived with respect to such Chronic Failure. Such waiver shall be without prejudice to Customer's right to exercise termination in the event of any subsequent Chronic Failure. Provider's cure notice shall include a detailed description of the root cause(s) of the Chronic Failure, the corrective actions taken, and the preventive measures implemented to avoid recurrence. For the avoidance of doubt, Provider shall not be entitled to more than one (1) cure period in any twelve (12)-month period.

Section 8: Incident Classification and Response Times

8.1 Severity Levels. Incidents affecting the Platform shall be classified according to the following severity levels:

Severity 1 — Platform Down. The Platform is wholly inoperable or substantially unavailable to all or a material portion of Customer's authorized users, including, without limitation, a complete outage of the production instance. Core AML transaction-monitoring and alerting functionality is non-functional. A Severity 1 incident represents a critical business impact to Customer, as Customer is unable to perform its regulatory compliance monitoring obligations through the Platform during the period of the outage. Examples of Severity 1 incidents include, but are not limited to: complete Platform unavailability; inability of any authorized user to log in; failure of the transaction-monitoring engine to process incoming transaction data; and failure of the alerting system to generate or deliver AML alerts.

Severity 2 — Major Feature Impaired. A major feature or module of the Platform is materially degraded or inoperable, but the Platform as a whole remains accessible. Workarounds may be available but are not sustainable for extended periods. A Severity 2 incident represents a significant business impact to Customer, as one or more critical workflows are disrupted. Examples of Severity 2 incidents include, but are not limited to: significant performance degradation affecting transaction processing throughput (e.g., processing latency exceeding five (5) times normal levels); failure of the case management module, preventing investigators from managing or closing cases; inability to generate or export regulatory reports (e.g., SAR filings, CTR filings); and failure of the machine learning model scoring engine to return risk scores within acceptable timeframes.

Severity 3 — Minor Impact. A minor feature, function, or component of the Platform is impaired, but the impairment does not materially affect Customer's operations or regulatory compliance activities. Workarounds are available and sustainable. A Severity 3 incident represents a low business impact to Customer. Examples of Severity 3 incidents include, but are not limited to: cosmetic user interface issues that do not affect functionality; non-critical reporting delays (e.g., delayed availability of ad hoc management reports); minor performance variations that do not affect core functionality; and intermittent issues affecting a small number of users that can be resolved through standard troubleshooting steps.

8.2 Response Time Commitments. Provider shall respond to incidents in accordance with the following timeline:

All timeframes set forth in the foregoing table are measured from the time the incident is first reported by Customer or first detected by Provider's monitoring tools, whichever is earlier. Response time commitments for Severity 1 and Severity 2 incidents apply at all times, including outside of Provider's standard business hours, on weekends, and on U.S. federal holidays.

8.3 Definitions of Response Milestones. For purposes of this Section 8, the following terms shall have the meanings set forth below:

(a) "Acknowledgment" means Provider confirms receipt of the incident report and assigns a unique ticket number and initial severity classification. Acknowledgment shall be communicated to Customer's designated operations contact via email and, for Severity 1 incidents, by telephone.

(b) "First Response" means Provider assigns qualified technical personnel to the incident, begins root-cause analysis, and communicates initial findings and an estimated timeline for resolution to Customer. The First Response communication shall identify the personnel assigned to the incident and the steps being taken to diagnose and resolve the issue.

(c) "Resolution Target" means the target timeframe within which Provider shall restore full functionality or implement a commercially reasonable workaround that restores the affected functionality to a state that permits Customer to continue its operations without material disruption. Resolution Targets are measured from the time of the initial incident report. The parties acknowledge that Resolution Targets represent good-faith targets and not guaranteed commitments; however, Provider shall use all commercially reasonable efforts to meet Resolution Targets and shall promptly notify Customer if it anticipates that a Resolution Target will not be met, together with a revised estimated timeline.

8.4 24/7 Support Availability. For Severity 1 and Severity 2 incidents, Provider shall make available support personnel qualified to diagnose and resolve such incidents twenty-four (24) hours per day, seven (7) days per week, three hundred sixty-five (365) days per year. Provider shall maintain a staffed network operations center ("NOC") or equivalent support function at all times. Severity 3 incidents shall be addressed during Provider's standard business hours, which are Monday through Friday, 8:00 AM to 8:00 PM Eastern Time, excluding U.S. federal holidays. Provider shall publish a list of observed U.S. federal holidays on an annual basis and provide such list to Customer's designated operations contact no later than January 15 of each calendar year.

8.5 Severity Reclassification. Either party may request reclassification of the severity level of an incident based on evolving circumstances, including a change in the scope of impact, the availability of workarounds, or new information regarding root cause. Provider shall promptly evaluate such requests (and in no event later than thirty (30) minutes for requests to upgrade to Severity 1, or one (1) hour for other reclassification requests) and communicate any reclassification to Customer, together with an explanation of the basis for the reclassification. In the event of a dispute regarding severity classification, Customer's classification shall control pending resolution of the dispute through the escalation process set forth in Section 10. Provider shall apply the response time commitments associated with the higher severity level pending resolution of any such dispute.

8.6 Incident Reporting. Customer may report incidents to Provider via any of the following channels:

(a) Provider's dedicated support portal, accessible at a URL to be designated by Provider and communicated to Customer prior to the Platform Go-Live Date;

(b) Email to Provider's designated support address at support@skybridgefintech.com (or such other address as Provider may designate from time to time); or

(c) For Severity 1 incidents, Provider's emergency telephone hotline at a number to be designated by Provider and communicated to Customer prior to the Platform Go-Live Date. The emergency telephone hotline shall be staffed at all times.

Each incident report should include, to the extent reasonably available at the time of reporting: a description of the issue; identification of affected users, modules, or functionality; time of onset; any error messages, screenshots, or log files available; and any troubleshooting steps already taken by Customer. Failure by Customer to include all of the foregoing information shall not relieve Provider of its obligation to acknowledge and respond to the incident within the applicable timeframes.

Section 9: Incident Communication and Reporting

9.1 Status Updates During Active Incidents. Provider shall provide Customer with regular status updates during the pendency of active incidents, as follows:

(a) Severity 1 incidents: Provider shall provide status updates to Customer every thirty (30) minutes until the incident is resolved or until the incident is downgraded to a lower severity level. Status updates shall be delivered via email and telephone to Customer's designated operations contact and shall include a summary of current status, actions being taken, and estimated time to resolution.

(b) Severity 2 incidents: Provider shall provide status updates every sixty (60) minutes until the incident is resolved or downgraded. Status updates shall be delivered via email to Customer's designated operations contact and shall include a summary of current status, actions being taken, and estimated time to resolution.

(c) Severity 3 incidents: Provider shall provide status updates at least once per business day during active remediation. Status updates shall be delivered via the support portal or email and shall include a summary of current status and expected timeline for resolution.

9.2 Root-Cause Analysis. For all Severity 1 and Severity 2 incidents, Provider shall deliver a written Root-Cause Analysis report (an "RCA") to Customer within five (5) business days following the resolution of the incident. The RCA shall be prepared by qualified technical personnel and shall include, at a minimum, the following:

(a) A description of the incident, including the nature, scope, and duration of the impact on Customer's operations;

(b) A detailed timeline of events, from initial detection or report through resolution, including all material actions taken by Provider;

(c) Identification of the root cause(s) of the incident, including any underlying infrastructure, software, configuration, or process failures;

(d) A description of the corrective actions taken to resolve the incident; and

(e) A description of the preventive measures to be implemented by Provider to avoid recurrence of the same or similar incidents, together with an estimated timeline for implementation of such measures.

Customer shall have the right to request a follow-up meeting with Provider's technical team to discuss the RCA and any proposed preventive measures. Provider shall accommodate such requests within a reasonable timeframe. Provider shall track the implementation of preventive measures identified in each RCA and report on the status of such implementation in the next quarterly Steering Committee meeting.

9.3 Monthly Incident Summary. Provider shall include in the monthly Availability Report delivered pursuant to Section 3.4 a summary of all incidents reported during the applicable Measurement Period, including the following information for each incident:

(a) Incident ticket number and date of report;

(b) Severity classification (initial and final, if reclassified);

(d) Acknowledgment time, First Response time, and resolution time achieved;

(e) Compliance with the response time commitments set forth in Section 8.2 (met/not met);

(f) Root cause (for Severity 1 and Severity 2 incidents, referencing the applicable RCA); and

(g) Status of any corrective or preventive measures.

Section 10: Escalation Procedures

In the event of unresolved SLA disputes, persistent performance concerns, or any other matter arising under this Exhibit A that the parties are unable to resolve through ordinary course communications, the following escalation procedures shall apply:

10.1 Level 1 — Account Manager Escalation. The matter shall first be escalated to the designated account managers for each party:

• Provider: Tara Bellingham, Vice President, Enterprise Sales, Skybridge Fintech Ltd.

• Customer: Luis Arriaga, Senior Vice President, Procurement & Vendor Management, Meridian National Bank, N.A.

The Level 1 escalation team shall have five (5) business days from the date of escalation to resolve the matter. The escalating party shall provide the other party with a written summary of the issue and the resolution sought.

10.2 Level 2 — VP-Level Escalation. If the matter is not resolved at Level 1 within the five (5) business day period, the matter shall be escalated to VP-level executives designated by each party. Each party shall designate its Level 2 representative within two (2) business days of the expiration of the Level 1 escalation period. The Level 2 escalation team shall have ten (10) business days from the date of escalation to resolve the matter. The Level 2 representatives shall meet (in person or by videoconference) at least once during the escalation period to discuss the matter and attempt to reach a resolution.

10.3 Level 3 — Executive Escalation. If the matter is not resolved at Level 2 within the ten (10) business day period, the matter shall be escalated to the following executive representatives:

• Provider: Priya Chandrasekaran, Chief Executive Officer, Skybridge Fintech Ltd. (or her designee).

• Customer: Gerald Brannigan, Chief Information Officer, Meridian National Bank, N.A. (or his designee).

The Level 3 escalation team shall have fifteen (15) business days from the date of escalation to resolve the matter. The Level 3 representatives shall meet (in person or by videoconference) at least once during the escalation period to discuss the matter and negotiate a resolution in good faith.

10.4 Further Escalation. If the matter remains unresolved after the expiration of the Level 3 escalation period, the dispute resolution procedures set forth in the MSA shall apply, including mandatory JAMS-administered mediation and, if mediation is unsuccessful, litigation in the courts of the State of Delaware, as set forth in the MSA. Nothing in this Section 10 shall prevent either party from seeking injunctive or other equitable relief as permitted under the MSA.

Section 11: Steering Committee Review

11.1 Quarterly Review. SLA performance shall be a standing agenda item for the quarterly Steering Committee meetings established under the MSA. At each quarterly Steering Committee meeting, Provider shall present a comprehensive quarterly summary that includes, at a minimum, the following:

(a) Monthly Availability percentages for each Measurement Period in the quarter;

(b) A summary of all incidents occurring during the quarter, classified by severity level, together with trend analysis comparing the current quarter to prior quarters;

(c) SLA Credit activity for the quarter, including credits earned, credits applied, and credits remaining under the annual cap;

(d) Status of corrective and preventive actions arising from RCA reports;

(e) Planned infrastructure improvements, Platform upgrades, or other changes that may affect Availability or performance in the upcoming quarter; and

(f) Any recommendations for adjustments to the SLA terms or operational procedures based on the parties' experience during the preceding quarter.

Customer's designated representatives shall have the opportunity to raise any concerns, request additional information, and provide feedback on Provider's performance during the quarterly Steering Committee meeting.

11.2 Annual SLA Review. On or about each anniversary of the Platform Go-Live Date, the parties shall conduct a comprehensive annual review of the SLA terms set forth in this Exhibit A. The annual review shall encompass, at a minimum, the following topics:

(a) Whether the Availability Target remains appropriate based on actual performance, industry benchmarks, and changes to the regulatory environment;

(b) Whether the SLA Credit structure (including credit tiers, monthly cap, and annual cap) remains appropriate and proportionate;

(c) Whether the incident response time commitments remain appropriate based on actual performance and Customer's evolving operational needs;

(d) Whether changes to the underlying infrastructure (including changes to the Orion Cloud hosting environment) warrant modifications to the SLA terms; and

(e) Any other matters that either party reasonably determines are relevant to the performance of the SLA.

Any modifications to this Exhibit A resulting from the annual SLA review shall be made only by a written amendment executed by authorized representatives of both parties.

Section 12: Relationship to MSA and Other Exhibits

12.1 Incorporation. This Exhibit A is incorporated into and forms part of the MSA. In the event of any conflict between the terms of this Exhibit A and the terms of the MSA, the MSA shall control unless this Exhibit A expressly states otherwise. All terms and conditions of the MSA that are applicable to exhibits generally, including but not limited to provisions relating to confidentiality, indemnification, limitation of liability, governing law, and dispute resolution, shall apply to this Exhibit A.

12.2 Relationship to Security Exhibit. The security incident notification and response obligations set forth in the Security Exhibit (Exhibit B to the MSA) are separate from and in addition to the incident response obligations set forth in this Exhibit A. A Security Incident (as defined in Exhibit B) that also constitutes Downtime under this Exhibit A shall be subject to both sets of obligations concurrently. For the avoidance of doubt, the occurrence of a Security Incident shall not excuse or relieve Provider from its obligations under this Exhibit A with respect to Availability, incident response, SLA Credits, or any other obligation, and the exercise of remedies under Exhibit B shall not preclude Customer from exercising its remedies under this Exhibit A, or vice versa, except to the extent that Customer would receive duplicative recovery for the same harm.

12.3 Relationship to Order Form. The fee amounts and user counts referenced in this Exhibit A are based on the initial Order Form executed concurrently with the MSA. To the extent the Order Form is amended or supplemented during the Term (including to add incremental authorized users at $275 per user per year, or to adjust the annual subscription fee pursuant to the annual escalator), the SLA Credit calculations set forth in Section 6 shall be adjusted accordingly to reflect the then-current Monthly Subscription Fee. Provider shall notify Customer of any changes to the SLA Credit calculations resulting from amendments or supplements to the Order Form.

12.4 upstream Infrastructure SLA. Provider's Platform is hosted on infrastructure provided by Orion Cloud Services, Inc. ("Orion Cloud"). The parties acknowledge that Orion Cloud's platform SLA provides for 99.95% monthly uptime for its infrastructure services. Provider's obligations under this Exhibit A are independent of and not conditioned upon the performance of Orion Cloud, and Provider shall not be relieved of its obligations hereunder by reason of any failure by Orion Cloud to meet its upstream SLA commitments. Provider shall use commercially reasonable efforts to enforce its rights under its agreement with Orion Cloud for the benefit of Customer, including by pursuing service credits or other remedies available from Orion Cloud in the event of infrastructure failures affecting the Platform. Upon Customer's reasonable request, Provider shall provide Customer with information regarding the status of any claims made by Provider against Orion Cloud in connection with infrastructure failures affecting the Platform.

Section 13: General Provisions

13.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.

13.2 Amendment. This Exhibit A may be amended, modified, or supplemented only by a written instrument executed by duly authorized representatives of both parties. No course of dealing, course of performance, or trade usage shall be deemed to modify the terms of this Exhibit A.

13.3 No Waiver. Customer's failure to request an SLA Credit for any Measurement Period shall not constitute a waiver of Customer's right to request SLA Credits for subsequent Measurement Periods. No waiver of any right or remedy under this Exhibit A shall be effective unless made in writing and signed by the waiving party. A waiver of any right or remedy on one occasion shall not be deemed a waiver of such right or remedy on any subsequent occasion.

13.4 Survival. Sections 6 (SLA Credits), 7 (Chronic Failure — Termination Right), and 9.2 (Root-Cause Analysis) shall survive any termination or expiration of the MSA to the extent necessary to give effect to the parties' rights and obligations accruing prior to such termination or expiration. The survival of such provisions shall be in addition to any survival provisions set forth in the MSA.

SCHEDULE A-1

SLA Credit Calculation Examples

The following examples are provided for illustrative purposes only and are not intended to modify or limit the provisions of this Exhibit A. In the event of any conflict between these examples and the terms of the Exhibit, the terms of the Exhibit shall control.

Example 1: Year 1 — 30-Day Measurement Period

• Total minutes in month: 30 days × 24 hours × 60 minutes = 43,200 minutes

• Scheduled Maintenance: 4 hours × 4 weeks = 16 hours = 960 minutes

• Excused Downtime: 0 minutes

• Total Available Minutes: 43,200 − 960 = 42,240 minutes

• Downtime: 63 minutes (one Severity 1 incident lasting 63 minutes)

• Availability: (42,240 − 63) ÷ 42,240 = 42,177 ÷ 42,240 = 99.85%

CONFIDENTIAL TREATMENT REQUESTED — INITIAL DRAFT Prepared by Calderwood & Harkness LLP | Matter No. 1009-00007
EXHIBIT A
SERVICE LEVEL AGREEMENT
to the Master Software-as-a-Service Agreement
between
SKYBRIDGE FINTECH LTD. ("Provider" or "Licensor") a Delaware limited company 1400 Concord Pike, Suite 320 Wilmington, DE 19803
and
MERIDIAN NATIONAL BANK, NATIONAL ASSOCIATION ("Customer" or "Licensee") a national banking association 600 Lexington Avenue, 40th Floor New York, NY 10022
relating to the
SkyComply™ AI-Driven AML and Transaction-Monitoring Platform
INITIAL DRAFT — CONFIDENTIAL Prepared by Calderwood & Harkness LLP June 12, 2025
This Exhibit A (this "SLA" or "Exhibit A") is incorporated into and forms part of the Master Software-as-a-Service Agreement (the "MSA") entered into between Skybridge Fintech Ltd. ("Provider") and Meridian National Bank, National Association ("Customer"). Capitalized terms used but not defined herein shall have the meanings ascribed to them in the MSA. In the event of any conflict between the terms of this Exhibit A and the terms of the MSA, the MSA shall control unless this Exhibit A expressly states otherwise. This Exhibit A sets forth the service levels, availability commitments, incident response obligations, and related credit mechanisms applicable to Provider's delivery of the SkyComply™ AI-driven anti-money-laundering and transaction-monitoring platform (the "Platform") to Customer under the MSA.
Section 1: Definitions
For purposes of this Exhibit A, the following terms shall have the meanings set forth below. Terms defined in the MSA and used but not separately defined in this Exhibit A shall retain the meanings given to them in the MSA.
1.1 "Availability" or "Uptime" means the percentage of time during a Measurement Period that the Platform is operational and accessible to Customer's authorized users, measured as set forth in Section 3 below. For the avoidance of doubt, "operational and accessible" means that Customer's authorized users are able to log in to the Platform and access its core functionality, including AML transaction-monitoring, alert generation, case management, and regulatory reporting, without material degradation.
1.2 "Downtime" means any period during which the Platform is unavailable to Customer's authorized users, excluding Scheduled Maintenance Windows and Excused Downtime. Downtime shall be measured from the time the unavailability is first detected by Provider's monitoring tools or first reported by Customer, whichever is earlier, until the time the Platform is restored to full operational status.
1.3 "Excused Downtime" means periods of unavailability caused by any of the following:
(a) force majeure events as defined in the MSA;
(b) Customer's acts or omissions, including Customer's misuse of the Platform or breach of the Acceptable Use Policy (Exhibit D to the MSA);
(c) failures of Customer's own systems, networks, hardware, or equipment, including but not limited to Customer's internal network infrastructure, firewalls, VPN connections, or endpoint devices;
(d) failures of third-party internet service providers or telecommunications carriers not within Provider's reasonable control;
(e) any actions taken by Provider at Customer's express written request that result in downtime, including but not limited to configuration changes, data migrations, or customization activities requested by Customer.
1.4 "Measurement Period" means each calendar month during the Term, beginning at 12:00:00 AM Eastern Time on the first day and ending at 11:59:59 PM Eastern Time on the last day of such calendar month. The first Measurement Period shall commence on the Platform Go-Live Date and shall consist of the remaining days of the calendar month in which the Platform Go-Live Date occurs.
1.5 "Monthly Subscription Fee" means the monthly portion of the annual subscription fee payable by Customer under the applicable Order Form executed in connection with the MSA. For purposes of this Exhibit A, the Monthly Subscription Fee shall be calculated as follows:
(a) Year 1: $12,700,000 ÷ 12 = $1,058,333 per month.
(b) Years 2 through 5: $9,325,000 ÷ 12 = $777,083 per month, in each case subject to adjustment for the annual escalator beginning in Year 3 as set forth in the Order Form.
1.6 "Platform" means the SkyComply™ AI-driven anti-money-laundering and transaction-monitoring platform provided by Provider as a software-as-a-service solution under the MSA, including all modules, features, functionalities, updates, and enhancements made generally available by Provider to its customers during the Term.
1.7 "Platform Go-Live Date" means the date on which the Platform is made available for production use by Customer in accordance with the implementation plan set forth in the MSA, targeted as March 1, 2026, or such other date as the parties may agree in writing.
1.8 "Scheduled Maintenance Window" means the recurring weekly maintenance period described in Section 4 of this Exhibit A, during which Provider may perform routine maintenance, updates, patches, and upgrades to the Platform and its underlying infrastructure.
1.9 "SLA Credit" means the service level credit to which Customer is entitled in the event Provider fails to meet the Availability Target, calculated as set forth in Section 6 of this Exhibit A.
1.10 "Severity Level" means the classification of incidents affecting the Platform as described in Section 8 of this Exhibit A, based on the nature, scope, and impact of the incident on Customer's operations.
1.11 "Total Available Minutes" means the total number of minutes in a given Measurement Period, minus the minutes attributable to Scheduled Maintenance Windows and Excused Downtime. Total Available Minutes represents the denominator used in calculating Availability for purposes of determining compliance with the Availability Target and any SLA Credits owed.
Section 2: Availability Target
2.1 Monthly Availability Target. Provider shall use commercially reasonable efforts to maintain Platform Availability of at least 99.9% per Measurement Period (the "Availability Target"), measured exclusive of Scheduled Maintenance Windows and Excused Downtime. The parties acknowledge that the 99.9% Availability Target permits a maximum of approximately forty-three (43) minutes of unscheduled Downtime per Measurement Period in a thirty (30)-day month. Provider's commitment to the Availability Target is a material obligation under the MSA, and Customer's agreement to the pricing, term, and other provisions of the MSA is made in reliance upon Provider's commitment to achieve and maintain the Availability Target throughout the Term.
2.2 Commencement. The Availability Target shall become effective on the Platform Go-Live Date (targeted: March 1, 2026) and shall continue in full force and effect throughout the Term of the MSA, including any renewal periods. During any implementation or pilot period preceding the Platform Go-Live Date, Provider shall use commercially reasonable efforts to maintain Platform availability consistent with the Availability Target, but no SLA Credits shall accrue for any failure to achieve the Availability Target prior to the Platform Go-Live Date.
2.3 Scope. The Availability Target applies to the production instance of the Platform as hosted by Provider's cloud infrastructure provider, Orion Cloud Services, Inc. ("Orion Cloud"), within the continental United States, specifically the US-East (Virginia) and US-West (Oregon) regions. For the avoidance of doubt, the following environments and components are excluded from the Availability Target:
(a) Non-production environments, including sandbox, staging, quality assurance (QA), user acceptance testing (UAT), and development environments;
(b) Any Customer-specific testing or training environments provisioned by Provider at Customer's request;
(c) Third-party integrations or data feeds not directly hosted or managed by Provider, except to the extent that Provider's Platform functionality is dependent upon such integrations for core AML transaction-monitoring and alerting capabilities, in which case the unavailability of such integrations shall be considered in the Availability calculation to the extent attributable to Provider's acts or omissions.
Section 3: Availability Measurement Methodology
3.1 Calculation. Monthly Availability 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 Measurement Period minus minutes attributable to Scheduled Maintenance Windows and Excused Downtime.
(b) Downtime Minutes equals the aggregate number of minutes during the Measurement Period in which the Platform was unavailable to Customer's authorized users, excluding Scheduled Maintenance Windows and Excused Downtime.
The resulting Availability percentage shall be rounded to two (2) decimal places for purposes of determining compliance with the Availability Target and calculating any applicable SLA Credits.
3.2 Monitoring Tools. Provider shall monitor Platform Availability using automated synthetic monitoring tools that test Platform accessibility at intervals of no greater than five (5) minutes from at least two (2) geographically distinct monitoring points within the continental United States. Provider's monitoring infrastructure shall include, at a minimum, HTTP/HTTPS endpoint checks, API health checks, and database connectivity verification. Provider shall maintain the monitoring tools in good working order throughout the Term and shall promptly notify Customer of any material changes to its monitoring methodology, tools, or procedures. Customer shall have the right to deploy its own independent monitoring tools, and in the event of any discrepancy between Provider's monitoring data and Customer's independently collected monitoring data, the parties shall work together in good faith to reconcile such data.
3.3 Monitoring Dashboard. Provider shall make available to Customer a real-time availability dashboard accessible via the Platform's administrative console, displaying current and historical availability metrics on a rolling twelve (12)-month basis. The monitoring dashboard shall include, at a minimum, the following information:
(a) Current Platform status (operational, degraded, or unavailable);
(b) Real-time Availability percentage for the current Measurement Period;
(c) Historical Availability percentages for each of the preceding twelve (12) Measurement Periods;
(d) Active incidents, including severity classification, status, and estimated time to resolution;
(e) Upcoming Scheduled Maintenance Windows; and
(f) SLA Credit status for the current and prior Measurement Periods.
The monitoring dashboard shall be accessible to Customer's designated administrators at all times, including during periods of Platform Downtime, through an independent hosting mechanism separate from the Platform's production infrastructure.
3.4 Monthly Reporting. Within ten (10) business days following the end of each Measurement Period, Provider shall deliver to Customer a written Availability Report (the "Availability Report") setting forth the following information for the applicable Measurement Period:
(a) The total number of minutes in the Measurement Period;
(b) The total number of minutes attributable to Scheduled Maintenance Windows;
(c) The total number of minutes attributable to Excused Downtime, together with a description of each period of Excused Downtime and the category under Section 5.1 to which it is attributed;
(d) The total number of Downtime minutes, together with a description of each incident giving rise to Downtime, including the date, start time, end time, duration, root cause (if known), and corrective action taken;
(e) The calculated Availability percentage for the Measurement Period; and
(f) Any SLA Credits earned by Customer for the Measurement Period, together with the calculation supporting each such credit.
The Availability Report shall be delivered to Customer's designated operations contact in a format reasonably acceptable to Customer (PDF or electronic format through the Platform's administrative console). Provider shall retain all underlying monitoring logs, incident records, and supporting documentation for each Availability Report for a period of not less than three (3) years following the applicable Measurement Period, and shall make such records available to Customer upon reasonable request.
3.5 Disputes Regarding Measurement. In the event Customer disputes the Availability calculation for any Measurement Period, Customer shall notify Provider in writing within fifteen (15) business days of receipt of the applicable Availability Report. Such notice shall set forth the basis for Customer's dispute, including any supporting data or monitoring logs in Customer's possession. The parties shall cooperate in good faith to resolve the dispute, including by jointly reviewing monitoring logs, incident records, and any third-party monitoring data available to either party. If the dispute cannot be resolved within ten (10) business days following receipt of Customer's dispute notice, the dispute shall be escalated in accordance with the escalation procedures set forth in Section 10 of this Exhibit A. Pending resolution of any dispute, the SLA Credit (if any) claimed by Customer shall be provisionally applied to Customer's account, subject to adjustment following resolution of the dispute.
Section 4: Scheduled Maintenance Windows
4.1 Standard Maintenance Window. Provider's standard Scheduled Maintenance Window shall be Saturdays from 2:00 AM to 6:00 AM Eastern Time (a maximum of four (4) hours per week). During the Scheduled Maintenance Window, Provider may perform routine maintenance activities, including but not limited to software updates, patches, security fixes, database optimization, infrastructure upgrades, and configuration changes. Provider acknowledges that Meridian National Bank operates certain automated AML processes and batch jobs during overnight and weekend hours, and Provider shall use commercially reasonable efforts to coordinate maintenance activities to minimize disruption to such processes.
4.2 Advance Notice. Provider shall provide Customer with at least seventy-two (72) hours' advance written notice (via email to Customer's designated operations contact) of any scheduled maintenance to be performed during the Scheduled Maintenance Window. Such notice shall include a description of the maintenance activities to be performed, the expected duration of the maintenance, any anticipated impact on Platform functionality or performance, and any actions required of Customer in connection with the maintenance (e.g., clearing browser caches, restarting sessions). In the event that Provider determines that a scheduled maintenance activity may result in Platform unavailability exceeding two (2) hours, Provider shall use commercially reasonable efforts to provide at least five (5) business days' advance notice and shall coordinate the timing with Customer's designated operations contact.
4.3 Emergency Maintenance. In the event Provider determines that emergency maintenance is required to address a critical security vulnerability or imminent threat to Platform stability, Provider may perform maintenance outside of the Scheduled Maintenance Window, provided that:
(a) Provider notifies Customer as soon as reasonably practicable (and in no event later than one (1) hour after commencement of emergency maintenance), including a description of the nature of the emergency and the expected duration of the maintenance;
(b) Provider uses commercially reasonable efforts to minimize the duration of such maintenance and its impact on Customer's operations; and
(c) Emergency maintenance shall not exceed four (4) hours per occurrence.
Emergency maintenance shall be treated as Excused Downtime for purposes of Availability calculations only if Provider demonstrates, to Customer's reasonable satisfaction, that the maintenance was necessary to address a critical security vulnerability or imminent threat to Platform stability. Provider shall provide Customer with a written explanation of the circumstances giving rise to the emergency maintenance within two (2) business days following the occurrence. For the avoidance of doubt, emergency maintenance that does not meet the foregoing criteria shall be treated as Downtime for purposes of the Availability calculation.
4.4 Limitation on Maintenance. Provider shall not schedule more than one (1) Scheduled Maintenance Window per week. Total Scheduled Maintenance shall not exceed sixteen (16) hours per calendar month under ordinary circumstances. In the event that Provider anticipates that Scheduled Maintenance in any calendar month will exceed sixteen (16) hours, Provider shall provide advance notice to Customer and obtain Customer's prior written consent (such consent not to be unreasonably withheld). Provider shall use commercially reasonable efforts to complete all maintenance activities within the Scheduled Maintenance Window with minimal impact to Customer's operations, including by employing rolling deployments, blue-green deployment strategies, and other techniques designed to maintain Platform availability during maintenance activities to the greatest extent practicable.
Section 5: Excused Downtime
5.1 Categories of Excused Downtime. The following categories of downtime shall be excluded from the Availability calculation:
(a) Downtime during Scheduled Maintenance Windows, as defined in and subject to the limitations of Section 4 of this Exhibit A;
(b) Downtime caused by force majeure events as defined in the MSA, including but not limited to natural disasters, acts of war or terrorism, pandemics, government actions, and other events beyond the reasonable control of either party;
(c) Downtime attributable to Customer's acts, omissions, or negligence, including misuse of the Platform, unauthorized modifications to Platform configurations, introduction of malware or malicious code by Customer's users, or breach of the Acceptable Use Policy set forth in Exhibit D to the MSA;
(d) Downtime caused by failures of Customer's own systems, networks, hardware, or internet connectivity, including but not limited to failures of Customer's internal LAN/WAN infrastructure, firewalls, load balancers, VPN connections, or endpoint devices used to access the Platform;
(e) Downtime caused by failures of third-party internet service providers or telecommunications carriers outside Provider's reasonable control, provided that this exclusion shall not apply to failures of Orion Cloud Services, Inc. or any other infrastructure provider directly contracted by Provider to host or deliver the Platform;
(f) Downtime resulting from actions taken by Provider at Customer's express written request, including but not limited to custom configuration changes, data migration activities, or Platform modifications requested by Customer, provided that Provider has notified Customer in advance that such actions may result in downtime; and
(g) Downtime caused by denial-of-service attacks or other malicious third-party activity directed at Customer's infrastructure (rather than at Provider's Platform or Provider's hosting infrastructure), provided that if such attacks are directed at Provider's Platform or hosting infrastructure, the resulting downtime shall not be Excused Downtime.
5.2 Documentation. Provider shall document the cause and duration of all Excused Downtime in detail and include such documentation in the monthly Availability Report delivered pursuant to Section 3.4. For each period of Excused Downtime, Provider shall identify the applicable category under Section 5.1, the start and end times of the period, the total duration in minutes, and a narrative description of the cause. Customer reserves the right to dispute the classification of any period as Excused Downtime in accordance with the dispute resolution procedures set forth in Section 3.5. Provider bears the burden of demonstrating that any period of downtime qualifies as Excused Downtime under the applicable category.
Section 6: SLA Credits
6.1 Credit Tiers. If Provider fails to meet the Availability Target in any Measurement Period, Customer shall be entitled to SLA Credits as set forth in the following table:
For purposes of the foregoing table, the applicable credit tier shall be determined based on the calculated Availability percentage for the Measurement Period, rounded to two (2) decimal places. Only one credit tier shall apply per Measurement Period; the tiers are not cumulative.
6.2 Credit Calculation. SLA Credits shall be calculated as a percentage of the Monthly Subscription Fee for the Measurement Period in which the Availability failure occurred. The Monthly Subscription Fee for credit calculation purposes shall be as follows:
(a) Year 1: $1,058,333 (i.e., $12,700,000 ÷ 12).
(b) Years 2 through 5: $777,083 (i.e., $9,325,000 ÷ 12).
In each case, the Monthly Subscription Fee shall be subject to adjustment for any annual escalator applied pursuant to the Order Form. If the Order Form is amended or supplemented during the Term (including to add incremental users at $275 per user per year), the Monthly Subscription Fee for SLA Credit calculation purposes shall be adjusted to reflect the then-current total annual subscription fee divided by twelve (12).
6.3 Monthly Credit Cap. The maximum SLA Credit payable in any single Measurement Period shall not exceed thirty percent (30%) of the Monthly Subscription Fee for such Measurement Period. Accordingly, the maximum SLA Credit amounts are as follows:
(a) Year 1: $317,500 per month (30% × $1,058,333).
(b) Years 2 through 5: $233,125 per month (30% × $777,083).
These amounts are subject to adjustment in the event the Monthly Subscription Fee is adjusted pursuant to Section 6.2 above.
6.4 Annual Credit Cap. The aggregate SLA Credits payable in any twelve (12)-month period during the Term shall not exceed fifteen percent (15%) of the annual subscription fee for such period. Accordingly, the maximum annual SLA Credit amounts are as follows:
(a) Year 1: $1,905,000 (15% × $12,700,000).
(b) Years 2 through 5: $1,398,750 (15% × $9,325,000).
For purposes of calculating the annual credit cap, the twelve (12)-month period shall be measured on a rolling basis beginning on the Platform Go-Live Date and each anniversary thereof.
6.5 Credit Request Procedure. To receive an SLA Credit, Customer must submit a written credit request to Provider within thirty (30) days following the end of the Measurement Period in which the Availability failure occurred. The credit request shall be submitted to Provider's designated account manager and shall identify the following:
(a) The Measurement Period to which the credit request relates;
(b) The date(s) and time(s) of Downtime giving rise to the credit request;
(c) The basis for the credit claim, including the applicable credit tier and the calculated Availability percentage; and
(d) Any supporting documentation, including Customer's own monitoring data, incident reports, or correspondence with Provider's support team.
Provider shall respond to the credit request within fifteen (15) business days of receipt. If Provider agrees that a credit is owed, Provider shall confirm the credit amount in writing. If Provider disputes the credit request, Provider shall provide a written explanation of the basis for the dispute, and the matter shall be resolved in accordance with the dispute resolution procedures set forth in Section 3.5 and Section 10.
6.6 Application of Credits. Approved SLA Credits shall be applied as a credit against the next invoice issued to Customer following approval of the credit. If no further invoices are to be issued (e.g., because the Term is expiring), approved SLA Credits shall be refunded to Customer within thirty (30) days. SLA Credits may not be redeemed for cash (except as set forth in the preceding sentence) and shall not be carried forward beyond the Term. SLA Credits shall not be applied against implementation fees, professional services fees, or any other fees that are not part of the recurring subscription fee.
6.7 Sole and Exclusive Remedy. Subject to Section 7 (Chronic Failure — Termination Right), SLA Credits shall be Customer's sole and exclusive remedy, and Provider's sole and exclusive liability, for Provider's failure to meet the Availability Target set forth in Section 2. For the avoidance of doubt, the SLA Credit mechanism set forth in this Section 6 does not limit or waive any other remedies available to Customer under the MSA, at law, or in equity for breach of any other obligation of Provider, including but not limited to Provider's obligations with respect to data security, confidentiality, intellectual property, indemnification, or compliance with applicable law. Nothing in this Section 6.7 shall be construed to limit the aggregate liability cap set forth in the MSA.
Section 7: Chronic Failure — Termination Right
7.1 Chronic Failure Threshold. In the event that Platform Availability falls below 98.0% in three (3) or more of any six (6) consecutive Measurement Periods (a "Chronic Failure"), Customer shall have the right to terminate the MSA upon sixty (60) days' prior written notice to Provider. Customer's termination right under this Section 7 shall be in addition to, and not in lieu of, any SLA Credits to which Customer may be entitled under Section 6 for the Measurement Periods constituting the Chronic Failure.
7.2 Effect of Termination. Upon termination of the MSA for Chronic Failure pursuant to this Section 7:
(a) Provider shall refund to Customer any pre-paid fees attributable to the period following the effective date of termination on a pro-rata basis, calculated as the proportion of the remaining Term (measured in days) relative to the total Term for which such fees were pre-paid. Such refund shall be paid within thirty (30) days of the effective date of termination.
(b) The data export and certified destruction obligations set forth in the MSA and the Data Processing Addendum (Exhibit C to the MSA) shall apply in full, including Provider's obligation to make all Customer Data available for export in a commercially standard format within thirty (30) days of the effective date of termination.
(c) No early termination fee shall be payable by Customer, notwithstanding any provision of the MSA or Order Form to the contrary.
(d) Customer's right to any accrued but unpaid SLA Credits shall survive termination.
7.3 Cure Period. Notwithstanding the foregoing, if, following delivery of a termination notice under Section 7.1, Provider demonstrates to Customer's reasonable satisfaction that the cause of the Chronic Failure has been identified and remediated, and Provider achieves at least 99.9% Availability for two (2) consecutive Measurement Periods following delivery of a written cure notice to Customer, Customer's termination right under this Section 7 shall be deemed waived with respect to such Chronic Failure. Such waiver shall be without prejudice to Customer's right to exercise termination in the event of any subsequent Chronic Failure. Provider's cure notice shall include a detailed description of the root cause(s) of the Chronic Failure, the corrective actions taken, and the preventive measures implemented to avoid recurrence. For the avoidance of doubt, Provider shall not be entitled to more than one (1) cure period in any twelve (12)-month period.
Section 8: Incident Classification and Response Times
8.1 Severity Levels. Incidents affecting the Platform shall be classified according to the following severity levels:
Severity 1 — Platform Down. The Platform is wholly inoperable or substantially unavailable to all or a material portion of Customer's authorized users, including, without limitation, a complete outage of the production instance. Core AML transaction-monitoring and alerting functionality is non-functional. A Severity 1 incident represents a critical business impact to Customer, as Customer is unable to perform its regulatory compliance monitoring obligations through the Platform during the period of the outage. Examples of Severity 1 incidents include, but are not limited to: complete Platform unavailability; inability of any authorized user to log in; failure of the transaction-monitoring engine to process incoming transaction data; and failure of the alerting system to generate or deliver AML alerts.
Severity 2 — Major Feature Impaired. A major feature or module of the Platform is materially degraded or inoperable, but the Platform as a whole remains accessible. Workarounds may be available but are not sustainable for extended periods. A Severity 2 incident represents a significant business impact to Customer, as one or more critical workflows are disrupted. Examples of Severity 2 incidents include, but are not limited to: significant performance degradation affecting transaction processing throughput (e.g., processing latency exceeding five (5) times normal levels); failure of the case management module, preventing investigators from managing or closing cases; inability to generate or export regulatory reports (e.g., SAR filings, CTR filings); and failure of the machine learning model scoring engine to return risk scores within acceptable timeframes.
Severity 3 — Minor Impact. A minor feature, function, or component of the Platform is impaired, but the impairment does not materially affect Customer's operations or regulatory compliance activities. Workarounds are available and sustainable. A Severity 3 incident represents a low business impact to Customer. Examples of Severity 3 incidents include, but are not limited to: cosmetic user interface issues that do not affect functionality; non-critical reporting delays (e.g., delayed availability of ad hoc management reports); minor performance variations that do not affect core functionality; and intermittent issues affecting a small number of users that can be resolved through standard troubleshooting steps.
8.2 Response Time Commitments. Provider shall respond to incidents in accordance with the following timeline:
All timeframes set forth in the foregoing table are measured from the time the incident is first reported by Customer or first detected by Provider's monitoring tools, whichever is earlier. Response time commitments for Severity 1 and Severity 2 incidents apply at all times, including outside of Provider's standard business hours, on weekends, and on U.S. federal holidays.
8.3 Definitions of Response Milestones. For purposes of this Section 8, the following terms shall have the meanings set forth below:
(a) "Acknowledgment" means Provider confirms receipt of the incident report and assigns a unique ticket number and initial severity classification. Acknowledgment shall be communicated to Customer's designated operations contact via email and, for Severity 1 incidents, by telephone.
(b) "First Response" means Provider assigns qualified technical personnel to the incident, begins root-cause analysis, and communicates initial findings and an estimated timeline for resolution to Customer. The First Response communication shall identify the personnel assigned to the incident and the steps being taken to diagnose and resolve the issue.
(c) "Resolution Target" means the target timeframe within which Provider shall restore full functionality or implement a commercially reasonable workaround that restores the affected functionality to a state that permits Customer to continue its operations without material disruption. Resolution Targets are measured from the time of the initial incident report. The parties acknowledge that Resolution Targets represent good-faith targets and not guaranteed commitments; however, Provider shall use all commercially reasonable efforts to meet Resolution Targets and shall promptly notify Customer if it anticipates that a Resolution Target will not be met, together with a revised estimated timeline.
8.4 24/7 Support Availability. For Severity 1 and Severity 2 incidents, Provider shall make available support personnel qualified to diagnose and resolve such incidents twenty-four (24) hours per day, seven (7) days per week, three hundred sixty-five (365) days per year. Provider shall maintain a staffed network operations center ("NOC") or equivalent support function at all times. Severity 3 incidents shall be addressed during Provider's standard business hours, which are Monday through Friday, 8:00 AM to 8:00 PM Eastern Time, excluding U.S. federal holidays. Provider shall publish a list of observed U.S. federal holidays on an annual basis and provide such list to Customer's designated operations contact no later than January 15 of each calendar year.
8.5 Severity Reclassification. Either party may request reclassification of the severity level of an incident based on evolving circumstances, including a change in the scope of impact, the availability of workarounds, or new information regarding root cause. Provider shall promptly evaluate such requests (and in no event later than thirty (30) minutes for requests to upgrade to Severity 1, or one (1) hour for other reclassification requests) and communicate any reclassification to Customer, together with an explanation of the basis for the reclassification. In the event of a dispute regarding severity classification, Customer's classification shall control pending resolution of the dispute through the escalation process set forth in Section 10. Provider shall apply the response time commitments associated with the higher severity level pending resolution of any such dispute.
8.6 Incident Reporting. Customer may report incidents to Provider via any of the following channels:
(a) Provider's dedicated support portal, accessible at a URL to be designated by Provider and communicated to Customer prior to the Platform Go-Live Date;
(b) Email to Provider's designated support address at support@skybridgefintech.com (or such other address as Provider may designate from time to time); or
(c) For Severity 1 incidents, Provider's emergency telephone hotline at a number to be designated by Provider and communicated to Customer prior to the Platform Go-Live Date. The emergency telephone hotline shall be staffed at all times.
Each incident report should include, to the extent reasonably available at the time of reporting: a description of the issue; identification of affected users, modules, or functionality; time of onset; any error messages, screenshots, or log files available; and any troubleshooting steps already taken by Customer. Failure by Customer to include all of the foregoing information shall not relieve Provider of its obligation to acknowledge and respond to the incident within the applicable timeframes.
Section 9: Incident Communication and Reporting
9.1 Status Updates During Active Incidents. Provider shall provide Customer with regular status updates during the pendency of active incidents, as follows:
(a) Severity 1 incidents: Provider shall provide status updates to Customer every thirty (30) minutes until the incident is resolved or until the incident is downgraded to a lower severity level. Status updates shall be delivered via email and telephone to Customer's designated operations contact and shall include a summary of current status, actions being taken, and estimated time to resolution.
(b) Severity 2 incidents: Provider shall provide status updates every sixty (60) minutes until the incident is resolved or downgraded. Status updates shall be delivered via email to Customer's designated operations contact and shall include a summary of current status, actions being taken, and estimated time to resolution.
(c) Severity 3 incidents: Provider shall provide status updates at least once per business day during active remediation. Status updates shall be delivered via the support portal or email and shall include a summary of current status and expected timeline for resolution.
9.2 Root-Cause Analysis. For all Severity 1 and Severity 2 incidents, Provider shall deliver a written Root-Cause Analysis report (an "RCA") to Customer within five (5) business days following the resolution of the incident. The RCA shall be prepared by qualified technical personnel and shall include, at a minimum, the following:
(a) A description of the incident, including the nature, scope, and duration of the impact on Customer's operations;
(b) A detailed timeline of events, from initial detection or report through resolution, including all material actions taken by Provider;
(c) Identification of the root cause(s) of the incident, including any underlying infrastructure, software, configuration, or process failures;
(d) A description of the corrective actions taken to resolve the incident; and
(e) A description of the preventive measures to be implemented by Provider to avoid recurrence of the same or similar incidents, together with an estimated timeline for implementation of such measures.
Customer shall have the right to request a follow-up meeting with Provider's technical team to discuss the RCA and any proposed preventive measures. Provider shall accommodate such requests within a reasonable timeframe. Provider shall track the implementation of preventive measures identified in each RCA and report on the status of such implementation in the next quarterly Steering Committee meeting.
9.3 Monthly Incident Summary. Provider shall include in the monthly Availability Report delivered pursuant to Section 3.4 a summary of all incidents reported during the applicable Measurement Period, including the following information for each incident:
(a) Incident ticket number and date of report;
(b) Severity classification (initial and final, if reclassified);
(c) Description of the incident and its impact;
(d) Acknowledgment time, First Response time, and resolution time achieved;
(e) Compliance with the response time commitments set forth in Section 8.2 (met/not met);
(f) Root cause (for Severity 1 and Severity 2 incidents, referencing the applicable RCA); and
(g) Status of any corrective or preventive measures.
Section 10: Escalation Procedures
In the event of unresolved SLA disputes, persistent performance concerns, or any other matter arising under this Exhibit A that the parties are unable to resolve through ordinary course communications, the following escalation procedures shall apply:
10.1 Level 1 — Account Manager Escalation. The matter shall first be escalated to the designated account managers for each party:
•  Provider: Tara Bellingham, Vice President, Enterprise Sales, Skybridge Fintech Ltd.
•  Customer: Luis Arriaga, Senior Vice President, Procurement & Vendor Management, Meridian National Bank, N.A.
The Level 1 escalation team shall have five (5) business days from the date of escalation to resolve the matter. The escalating party shall provide the other party with a written summary of the issue and the resolution sought.
10.2 Level 2 — VP-Level Escalation. If the matter is not resolved at Level 1 within the five (5) business day period, the matter shall be escalated to VP-level executives designated by each party. Each party shall designate its Level 2 representative within two (2) business days of the expiration of the Level 1 escalation period. The Level 2 escalation team shall have ten (10) business days from the date of escalation to resolve the matter. The Level 2 representatives shall meet (in person or by videoconference) at least once during the escalation period to discuss the matter and attempt to reach a resolution.
10.3 Level 3 — Executive Escalation. If the matter is not resolved at Level 2 within the ten (10) business day period, the matter shall be escalated to the following executive representatives:
•  Provider: Priya Chandrasekaran, Chief Executive Officer, Skybridge Fintech Ltd. (or her designee).
•  Customer: Gerald Brannigan, Chief Information Officer, Meridian National Bank, N.A. (or his designee).
The Level 3 escalation team shall have fifteen (15) business days from the date of escalation to resolve the matter. The Level 3 representatives shall meet (in person or by videoconference) at least once during the escalation period to discuss the matter and negotiate a resolution in good faith.
10.4 Further Escalation. If the matter remains unresolved after the expiration of the Level 3 escalation period, the dispute resolution procedures set forth in the MSA shall apply, including mandatory JAMS-administered mediation and, if mediation is unsuccessful, litigation in the courts of the State of Delaware, as set forth in the MSA. Nothing in this Section 10 shall prevent either party from seeking injunctive or other equitable relief as permitted under the MSA.
Section 11: Steering Committee Review
11.1 Quarterly Review. SLA performance shall be a standing agenda item for the quarterly Steering Committee meetings established under the MSA. At each quarterly Steering Committee meeting, Provider shall present a comprehensive quarterly summary that includes, at a minimum, the following:
(a) Monthly Availability percentages for each Measurement Period in the quarter;
(b) A summary of all incidents occurring during the quarter, classified by severity level, together with trend analysis comparing the current quarter to prior quarters;
(c) SLA Credit activity for the quarter, including credits earned, credits applied, and credits remaining under the annual cap;
(d) Status of corrective and preventive actions arising from RCA reports;
(e) Planned infrastructure improvements, Platform upgrades, or other changes that may affect Availability or performance in the upcoming quarter; and
(f) Any recommendations for adjustments to the SLA terms or operational procedures based on the parties' experience during the preceding quarter.
Customer's designated representatives shall have the opportunity to raise any concerns, request additional information, and provide feedback on Provider's performance during the quarterly Steering Committee meeting.
11.2 Annual SLA Review. On or about each anniversary of the Platform Go-Live Date, the parties shall conduct a comprehensive annual review of the SLA terms set forth in this Exhibit A. The annual review shall encompass, at a minimum, the following topics:
(a) Whether the Availability Target remains appropriate based on actual performance, industry benchmarks, and changes to the regulatory environment;
(b) Whether the SLA Credit structure (including credit tiers, monthly cap, and annual cap) remains appropriate and proportionate;
(c) Whether the incident response time commitments remain appropriate based on actual performance and Customer's evolving operational needs;
(d) Whether changes to the underlying infrastructure (including changes to the Orion Cloud hosting environment) warrant modifications to the SLA terms; and
(e) Any other matters that either party reasonably determines are relevant to the performance of the SLA.
Any modifications to this Exhibit A resulting from the annual SLA review shall be made only by a written amendment executed by authorized representatives of both parties.
Section 12: Relationship to MSA and Other Exhibits
12.1 Incorporation. This Exhibit A is incorporated into and forms part of the MSA. In the event of any conflict between the terms of this Exhibit A and the terms of the MSA, the MSA shall control unless this Exhibit A expressly states otherwise. All terms and conditions of the MSA that are applicable to exhibits generally, including but not limited to provisions relating to confidentiality, indemnification, limitation of liability, governing law, and dispute resolution, shall apply to this Exhibit A.
12.2 Relationship to Security Exhibit. The security incident notification and response obligations set forth in the Security Exhibit (Exhibit B to the MSA) are separate from and in addition to the incident response obligations set forth in this Exhibit A. A Security Incident (as defined in Exhibit B) that also constitutes Downtime under this Exhibit A shall be subject to both sets of obligations concurrently. For the avoidance of doubt, the occurrence of a Security Incident shall not excuse or relieve Provider from its obligations under this Exhibit A with respect to Availability, incident response, SLA Credits, or any other obligation, and the exercise of remedies under Exhibit B shall not preclude Customer from exercising its remedies under this Exhibit A, or vice versa, except to the extent that Customer would receive duplicative recovery for the same harm.
12.3 Relationship to Order Form. The fee amounts and user counts referenced in this Exhibit A are based on the initial Order Form executed concurrently with the MSA. To the extent the Order Form is amended or supplemented during the Term (including to add incremental authorized users at $275 per user per year, or to adjust the annual subscription fee pursuant to the annual escalator), the SLA Credit calculations set forth in Section 6 shall be adjusted accordingly to reflect the then-current Monthly Subscription Fee. Provider shall notify Customer of any changes to the SLA Credit calculations resulting from amendments or supplements to the Order Form.
12.4 upstream Infrastructure SLA. Provider's Platform is hosted on infrastructure provided by Orion Cloud Services, Inc. ("Orion Cloud"). The parties acknowledge that Orion Cloud's platform SLA provides for 99.95% monthly uptime for its infrastructure services. Provider's obligations under this Exhibit A are independent of and not conditioned upon the performance of Orion Cloud, and Provider shall not be relieved of its obligations hereunder by reason of any failure by Orion Cloud to meet its upstream SLA commitments. Provider shall use commercially reasonable efforts to enforce its rights under its agreement with Orion Cloud for the benefit of Customer, including by pursuing service credits or other remedies available from Orion Cloud in the event of infrastructure failures affecting the Platform. Upon Customer's reasonable request, Provider shall provide Customer with information regarding the status of any claims made by Provider against Orion Cloud in connection with infrastructure failures affecting the Platform.
Section 13: General Provisions
13.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.
13.2 Amendment. This Exhibit A may be amended, modified, or supplemented only by a written instrument executed by duly authorized representatives of both parties. No course of dealing, course of performance, or trade usage shall be deemed to modify the terms of this Exhibit A.
13.3 No Waiver. Customer's failure to request an SLA Credit for any Measurement Period shall not constitute a waiver of Customer's right to request SLA Credits for subsequent Measurement Periods. No waiver of any right or remedy under this Exhibit A shall be effective unless made in writing and signed by the waiving party. A waiver of any right or remedy on one occasion shall not be deemed a waiver of such right or remedy on any subsequent occasion.
13.4 Survival. Sections 6 (SLA Credits), 7 (Chronic Failure — Termination Right), and 9.2 (Root-Cause Analysis) shall survive any termination or expiration of the MSA to the extent necessary to give effect to the parties' rights and obligations accruing prior to such termination or expiration. The survival of such provisions shall be in addition to any survival provisions set forth in the MSA.
SCHEDULE A-1
SLA Credit Calculation Examples
The following examples are provided for illustrative purposes only and are not intended to modify or limit the provisions of this Exhibit A. In the event of any conflict between these examples and the terms of the Exhibit, the terms of the Exhibit shall control.
Example 1: Year 1 — 30-Day Measurement Period
•  Total minutes in month: 30 days × 24 hours × 60 minutes = 43,200 minutes
•  Scheduled Maintenance: 4 hours × 4 weeks = 16 hours = 960 minutes
•  Excused Downtime: 0 minutes
•  Total Available Minutes: 43,200 − 960 = 42,240 minutes
•  Downtime: 63 minutes (one Severity 1 incident lasting 63 minutes)
•  Availability: (42,240 − 63) ÷ 42,240 = 42,177 ÷ 42,240 = 99.85%
•  Applicable Credit Tier: 99.9% – 99.5% → 5% of Monthly Subscription Fee
•  SLA Credit: 5% × $1,058,333 = $52,917
•  Monthly Cap Check: $52,917 < $317,500 (30% cap) — credit is within monthly cap
Example 2: Year 3 — 31-Day Measurement Period
•  Total minutes in month: 31 days × 24 hours × 60 minutes = 44,640 minutes
•  Scheduled Maintenance: 4 hours × 4 weeks = 16 hours = 960 minutes
•  Excused Downtime: 0 minutes
•  Total Available Minutes: 44,640 − 960 = 43,680 minutes
•  Downtime: 480 minutes (8 hours — two Severity 1 incidents totaling 480 minutes)
•  Availability: (43,680 − 480) ÷ 43,680 = 43,200 ÷ 43,680 = 98.90%
•  Applicable Credit Tier: Below 99.0% – 98.0% → 20% of Monthly Subscription Fee
•  SLA Credit: 20% × $777,083 = $155,417
•  Monthly Cap Check: $155,417 < $233,125 (30% cap) — credit is within monthly cap
Example 3: Year 2 — 28-Day Measurement Period (Chronic Failure Scenario)
•  Total minutes in month: 28 days × 24 hours × 60 minutes = 40,320 minutes
•  Scheduled Maintenance: 4 hours × 4 weeks = 16 hours = 960 minutes
•  Excused Downtime: 0 minutes
•  Total Available Minutes: 40,320 − 960 = 39,360 minutes
•  Downtime: 1,000 minutes (approximately 16 hours, 40 minutes — multiple Severity 1 and Severity 2 incidents)
•  Availability: (39,360 − 1,000) ÷ 39,360 = 38,360 ÷ 39,360 = 97.46%
•  Applicable Credit Tier: Below 98.0% → 30% of Monthly Subscription Fee
•  SLA Credit (calculated): 30% × $777,083 = $233,125
•  Monthly Cap Check: $233,125 = $233,125 (30% cap) — monthly cap reached
•  Chronic Failure Analysis: If Availability falls below 98.0% in this Measurement Period and in two (2) or more additional Measurement Periods within the same six (6) consecutive Measurement Period window, a Chronic Failure has occurred, and Customer may exercise its termination right under Section 7.
[End of Schedule A-1]
ACKNOWLEDGED AND AGREED
This Exhibit A is deemed executed and effective upon execution of the Master Software-as-a-Service Agreement to which it is attached. By executing the MSA, each party acknowledges that it has read, understood, and agreed to the terms and conditions set forth in this Exhibit A.
SKYBRIDGE FINTECH LTD. ("Provider")
By: ________
Name: Priya Chandrasekaran
Title: Chief Executive Officer
Date: ________
MERIDIAN NATIONAL BANK, NATIONAL ASSOCIATION ("Customer")
By: ________
Name: Gerald Brannigan
Title: Chief Information Officer
Date: ________
CONFIDENTIAL — This document constitutes an initial draft of Exhibit A to the Master Software-as-a-Service Agreement between Skybridge Fintech Ltd. and Meridian National Bank, National Association. This draft has been prepared by Calderwood & Harkness LLP, counsel to Skybridge Fintech Ltd., and is subject to negotiation, revision, and further review by the parties and their respective counsel. This document does not constitute a binding agreement unless and until executed by both parties as part of the MSA. All terms are subject to change. Calderwood & Harkness LLP | Matter No. 1009-00007.
Monthly Availability | SLA Credit (% of Monthly Subscription Fee)
99.9% – 99.5% (inclusive of 99.5%) | 5%
Below 99.5% – 99.0% (inclusive of 99.0%) | 10%
Below 99.0% – 98.0% (inclusive of 98.0%) | 20%
Below 98.0% | 30%
Severity Level | Acknowledgment | First Response | Resolution Target
Severity 1 (Platform Down) | 15 minutes | 1 hour | 4 hours
Severity 2 (Major Feature Impaired) | 30 minutes | 2 hours | 8 hours
Severity 3 (Minor Impact) | 4 hours | 1 business day | 5 business days

EXHIBIT A

SERVICE LEVEL AGREEMENT

SCHEDULE A-1

Record

Parties

Dates

Amounts