CONFIDENTIAL — SUBJECT TO MUTUAL NON-DISCLOSURE AGREEMENT NDA-QIH-MCI-2022-001

CONFIDENTIAL — SUBJECT TO MUTUAL NON-DISCLOSURE AGREEMENT NDA-QIH-MCI-2022-001
TECHNICAL SCHEDULE A
DATA DELIVERY SPECIFICATIONS
Schedule to the Master Data License Agreement by and between Quorum Insurance Holdings Corp. and Meridian Credit intelligence, Inc.
DRAFT — Prepared by Calderwood & Harkness LLP C&H Matter No.: 1025-00008
February 2023
Prepared by: Omar Siddiqui Associate, intellectual Property Calderwood & Harkness LLP
With technical input from: Priya Nair Director, Data Engineering Quorum Insurance Holdings Corp.
This Technical Schedule A (this "Schedule") is attached to and incorporated by reference into the Master Data License Agreement (the "MDLA") dated as of the date set forth on the signature page thereto, by and between Quorum Insurance Holdings Corp., a Delaware corporation ("Licensee" or "Quorum"), and Meridian Credit intelligence, Inc., a Georgia corporation ("Licensor" or "Meridian"). This Schedule sets forth the technical specifications, data formats, delivery schedules, data-quality acceptance criteria, and related technical requirements governing the delivery of Data Products by Meridian to Quorum under the MDLA. Capitalized terms used but not otherwise defined herein shall have the meanings ascribed to such terms in the MDLA.
In the event of any conflict between the provisions of this Schedule and the provisions of the MDLA, the MDLA shall control, except with respect to matters that are exclusively technical in nature and are addressed solely in this Schedule, in which case this Schedule shall control.
Right-click to update Table of Contents
Section 1: Definitions
As used in this Technical Schedule A, the following terms shall have the meanings set forth below. Unless the context otherwise requires, all references to "Sections" and "Exhibits" herein are references to Sections of, and Exhibits to, this Schedule.
1.1 "API" means Application Programming Interface, and refers specifically to the REST API endpoints provided by Meridian for real-time data access as further described in Section 5.2 of this Schedule.
1.2 "Base Tier" means the monthly record volume threshold of five hundred million (500,000,000) Records per calendar month (consumer, commercial, and alternative data combined) included in the license fees set forth in the MDLA, as further described in Section 6.1 of this Schedule.
1.3 "Batch Delivery" means the delivery of data files via SFTP on the applicable refresh schedule set forth in Section 4 of this Schedule.
1.4 "Business Day" means any day other than a Saturday, a Sunday, or a day on which commercial banks in New York, New York or Atlanta, Georgia are authorized or required by law or executive order to close.
1.5 "Checksum" means a cryptographic hash value computed using the SHA-256 algorithm, used to verify the integrity of a data file by comparing the computed hash of the received file against the hash value provided in the corresponding Manifest File.
1.6 "Character Encoding" means the character set and encoding standard used to represent text data within data files or API responses, which, for purposes of this Schedule, shall be UTF-8 (Unicode Transformation Format, 8-bit) unless otherwise expressly specified.
1.7 "Data Dictionary" means the reference document setting forth complete field-level definitions, data types, field lengths, permitted values, code tables, null-handling rules, and related technical specifications for each Data Product, as further described in Sections 3.2.7, 3.3.7, and 3.4.7 and provided as Exhibits A-1 through A-3 to this Schedule.
1.8 "Data Products" means, collectively, the MCI Consumer Credit File™, MCI CommercialView™, and MCI AltSignal™, each as further described in Section 2 of this Schedule.
1.9 "Delimiter" means the character used to separate individual data fields within a delimited flat file. For purposes of this Schedule, the primary delimiter shall be the pipe character ("|") unless otherwise specified.
1.10 "Delivery Window" means the time period within which Meridian is required to make data available for each applicable refresh cycle, as specified in Section 4 of this Schedule.
1.11 "Field" means a discrete data element within a Record, corresponding to a single attribute or characteristic (e.g., consumer name, account balance, date opened), as defined in the applicable Data Dictionary.
1.12 "Manifest File" means a metadata file (with a .manifest extension) that accompanies each Batch Delivery and contains a listing of all component data files within the delivery, the Record count for each file, the SHA-256 Checksum for each file, the delivery timestamp, and such other metadata as may be specified in the applicable Data Dictionary.
1.13 "MCI AltSignal™" means Meridian's alternative data product containing utility payment history, telecom payment history, and rental payment data, covering approximately eighty-five million (85,000,000) consumer alt-data Records, as further described in Section 2.3. MCI AltSignal™ is a registered trademark of Meridian Credit intelligence, Inc.
1.14 "MCI CommercialView™" means Meridian's commercial credit data product covering approximately forty-two million (42,000,000) business Records, as further described in Section 2.2. MCI CommercialView™ is a registered trademark of Meridian Credit intelligence, Inc.
1.15 "MCI Consumer Credit File™" means Meridian's full-file consumer tradeline data product covering approximately three hundred ten million (310,000,000) consumer Records, as further described in Section 2.1. MCI Consumer Credit File™ is a registered trademark of Meridian Credit intelligence, Inc.
1.16 "Overage Rate" means the per-Record fee of $0.003 (three-tenths of one cent) applicable to any Records delivered or accessed in excess of the Base Tier in a given calendar month, as further described in Section 6.2.
1.17 "Record" means a discrete unit of data corresponding to a single consumer file, a single business file, or a single alternative-data file, as applicable. For purposes of Record counting under this Schedule, each Record is counted once regardless of the number of segments, fields, or sub-records comprising such Record.
1.18 "REST API" means Representational State Transfer Application Programming Interface, a software architectural style for distributed hypermedia systems that uses standard HTTP methods for data retrieval and manipulation.
1.19 "Schema" means the structured definition of the data layout for a given Data Product, including the sequence and composition of segments, fields, data types, field lengths, and permitted values, as documented in the applicable Data Dictionary.
1.20 "SFTP" means SSH File Transfer Protocol, a network protocol that provides file access, file transfer, and file management functionality over a secure data stream established via the Secure Shell (SSH) protocol.
1.21 Additional technical terms used in this Schedule (including, without limitation, "gzip," "JSON," "OAuth 2.0," "OpenAPI," "TLS," "AES-256," "RSA," "mTLS," "SHA-256," and "HTTP") shall have their commonly understood meanings in the information technology industry as of the date of this Schedule, unless the context otherwise requires or a specific definition is provided herein.
Section 2: Data Products — Description and Scope
This Section 2 describes the Data Products to be delivered by Meridian to Quorum under the MDLA and this Schedule. The Data Products consist of three distinct data offerings, each addressing a different segment of the credit and alternative-data landscape. The descriptions set forth below are intended to provide an overview of the scope and coverage of each Data Product; detailed field-level specifications are set forth in Section 3 and in the applicable Data Dictionaries (Exhibits A-1 through A-3).
2.1 MCI Consumer Credit File™
The MCI Consumer Credit File™ is Meridian's flagship full-file consumer tradeline data product. It provides comprehensive consumer credit information derived from Meridian's proprietary consumer credit database, which aggregates data furnished by thousands of data contributors, including banks, credit unions, finance companies, mortgage lenders, retailers, and other creditors.
Coverage and Scope. The MCI Consumer Credit File™ encompasses approximately three hundred ten million (310,000,000) consumer Records as of the date of this Schedule. Coverage includes substantially all credit-active consumers in the United States, subject to standard data contributor coverage limitations.
Record-Level Composition. Each consumer Record within the MCI Consumer Credit File™ consists of multiple segments, including but not limited to:
(a) Consumer Identification Segment: Core identifying information for the consumer, including consumer identification number, name fields, Social Security Number (masked or tokenized as applicable under the Fair Credit Reporting Act ("FCRA") and the Gramm-Leach-Bliley Act ("GLBA")), date of birth, current and prior address fields, and telephone number.
(b) Tradeline Segment: Account-level credit information, including account number (masked), creditor name, account type code, date opened, date reported, credit limit or high credit amount, current balance, amount past due, payment pattern (historical payment performance), account status code, repayment terms, and portfolio type.
(c) Public Record Segment: Public record entries associated with the consumer, including court name, record type (e.g., bankruptcy, tax lien, civil judgment), date filed, amount, and current status.
(d) Inquiry Segment: Records of inquiries made against the consumer's credit file, including subscriber name, inquiry date, and inquiry type (hard or soft).
Data Source. All data within the MCI Consumer Credit File™ is sourced from Meridian's proprietary consumer credit database and is updated on a continuous basis as data contributors furnish new and updated information. MCI Consumer Credit File™ is a registered trademark of Meridian Credit intelligence, Inc.
2.2 MCI CommercialView™
The MCI CommercialView™ product is Meridian's commercial credit data offering, providing comprehensive credit and business information on United States businesses of all sizes, from sole proprietorships to large corporations.
Coverage and Scope. The MCI CommercialView™ product encompasses approximately forty-two million (42,000,000) business Records as of the date of this Schedule. Coverage includes businesses across all industries and geographies within the United States, sourced from Meridian's proprietary commercial credit database and supplemented by public record sources, business registrations, and direct business data contributions.
Record-Level Composition. Each business Record within MCI CommercialView™ consists of multiple segments, including but not limited to:
(a) Business Identification Segment: Core identifying information, including Meridian business identification number, legal name, "doing business as" (DBA) name(s), Employer Identification Number (EIN), Data Universal Numbering System (DUNS) number (if available), Standard Industrial Classification (SIC) and North American Industry Classification System (NAICS) codes, principal address, telephone number, entity type, year established, and employee count.
(b) Credit Profile Segment: Business credit score, score factors, trade payment data (including supplier names, payment amounts, payment terms, and days-beyond-terms metrics), and aging bucket summaries.
(c) Public Filing Segment: Uniform Commercial Code (UCC) filings, tax liens, judgments, and bankruptcy filings associated with the business.
(d) Financial Statement Segment (where available): Summary financial data, including revenue range, net worth, and total assets, to the extent such data has been furnished to or obtained by Meridian.
MCI CommercialView™ is a registered trademark of Meridian Credit intelligence, Inc.
2.3 MCI AltSignal™
The MCI AltSignal™ product is Meridian's alternative data offering, designed to supplement traditional credit data with payment history information from non-traditional sources, thereby enabling a more comprehensive assessment of consumer creditworthiness.
Coverage and Scope. The MCI AltSignal™ product encompasses approximately eighty-five million (85,000,000) consumer alt-data Records as of the date of this Schedule. Coverage is concentrated in utility payment data, telecom payment data, and rental payment data sourced from utility providers, telecom carriers, landlords, and property management companies throughout the United States.
Record-Level Composition. Each alt-data Record within MCI AltSignal™ consists of multiple segments, including but not limited to:
(a) Consumer Identification Segment: Keyed to the MCI consumer identification number used in the MCI Consumer Credit File™ for matching and cross-referencing purposes.
(b) Utility Payment Segment: Utility provider type (electric, gas, water), account status, payment history (twelve to twenty-four months), and delinquency indicators.
(c) Telecom Payment Segment: Provider type (wireline, wireless, internet), payment history, and delinquency indicators.
(d) Rental Payment Segment: Landlord or property manager identifier, monthly rent amount, payment history, and eviction records.
MCI AltSignal™ is a registered trademark of Meridian Credit intelligence, Inc.
2.4 Aggregate Record Volumes
Based on the coverage estimates set forth above, the combined estimated monthly volume across all three Data Products is approximately four hundred thirty-seven million (437,000,000) Records per calendar month, representing approximately 87.4% of the five hundred million (500,000,000) Record Base Tier. The breakdown by Data Product is as follows:
The foregoing volume estimates are based on Quorum's current projections and Meridian's current database coverage as of the date of this Schedule. Actual volumes may vary from month to month based on data contributor activity, consumer and business credit activity, and Quorum's data consumption patterns. Nothing in this Section 2.4 shall be construed as a guarantee by either party of specific volume levels.
Section 3: Data Formats and Record Schemas
This Section 3 sets forth the data formats, file specifications, and record schemas applicable to the delivery of Data Products under this Schedule. Detailed field-level specifications for each Data Product are provided in the Data Dictionaries attached as Exhibits A-1 through A-3.
3.1 File Formats — Batch Delivery
The following file format specifications apply to all Batch Deliveries of Data Products via SFTP:
3.1.1 Primary Format. All Batch Delivery files shall be delivered as delimited flat files using the pipe character ("|") as the field delimiter. Each record shall be terminated by a newline character (line feed, "\n"). Fields containing pipe characters, newline characters, or other reserved characters shall be properly escaped in accordance with the escaping conventions set forth in the applicable Data Dictionary.
3.1.2 Alternative Format. Fixed-width positional files may be made available as an alternative format for specific sub-feeds upon mutual written agreement between the parties. If fixed-width format is elected for a particular sub-feed, the applicable field positions, widths, and padding conventions shall be documented in a supplement to the relevant Data Dictionary.
3.1.3 Character Encoding. All Batch Delivery files shall use UTF-8 character encoding. Byte order marks (BOMs) shall not be included in UTF-8 encoded files unless otherwise mutually agreed. All date and time values shall be represented in ISO 8601 format (YYYY-MM-DD for dates; YYYY-MM-DDTHH:MM:SSZ for timestamps, using UTC unless otherwise specified).
3.1.4 Compression. All Batch Delivery files shall be compressed using gzip compression (resulting in a .gz file extension). Uncompressed files shall not be posted to the SFTP server for production deliveries. The compression level shall be optimized for a reasonable balance between file size reduction and decompression speed.
3.1.5 File Naming Convention. All Batch Delivery files shall conform to the following naming template:
`[ProductCode][YYYYMMDD][SequenceNumber]_[BatchType].[extension].gz`
Where:
•  ProductCode identifies the Data Product: "MCCF" for MCI Consumer Credit File™, "MCV" for MCI CommercialView™, and "MCAS" for MCI AltSignal™.
•  YYYYMMDD represents the date of the data extract in ISO 8601 date format.
•  SequenceNumber is a three-digit zero-padded integer (e.g., 001, 002, 003) indicating the file's position within a multi-file delivery.
•  BatchType indicates whether the file contains a full-file refresh ("FULL") or an incremental/delta update ("DELTA").
•  extension indicates the file type (e.g., ".dat" for data files, ".manifest" for manifest files).
Example: `MCCF20230215001_FULL.dat.gz`
A complete file naming convention reference is provided as Exhibit A-5 to this Schedule.
3.1.6 Maximum File Size. No individual compressed Batch Delivery file shall exceed ten (10) gigabytes (GB) in size. If a Data Product delivery for a given refresh cycle exceeds 10 GB in compressed form, the delivery shall be split into multiple sequenced files, each conforming to the naming convention set forth in Section 3.1.5, with sequential SequenceNumbers.
3.1.7 Manifest File. Each Batch Delivery shall be accompanied by a Manifest File (with a .manifest extension) that includes the following information:
(a) A complete listing of all component data files included in the delivery;
(b) The Record count for each component data file;
(c) The total aggregate Record count for the entire delivery;
(d) The SHA-256 Checksum for each component data file;
(e) The delivery timestamp (UTC) indicating when the files were posted to the SFTP server;
(f) The Schema version identifier applicable to the delivery; and
(g) Such other metadata as may be specified in the applicable Data Dictionary.
The Manifest File shall itself conform to a structured format (pipe-delimited or JSON) as specified in Exhibit A-5. The Manifest File shall be the last file posted to the SFTP server for each delivery, serving as a signal to Quorum that the delivery is complete and all component files are available for download.
3.2 Record Schemas — MCI Consumer Credit File™
The MCI Consumer Credit File™ record schema consists of the following segments. Complete field-level definitions, data types, field lengths, permitted values, code tables, and null-handling rules for each segment are provided in the Data Dictionary attached as Exhibit A-1 to this Schedule.
3.2.1 Header Segment. Each MCI Consumer Credit File™ data file shall begin with a header segment containing the following elements: file identifier, creation date and time (UTC), file sequence number, Schema version number, and the total Record count contained in the file.
3.2.2 Consumer Identification Segment. Each consumer Record shall include a consumer identification segment containing the following fields (at minimum): Meridian consumer identification number (a unique, persistent identifier assigned by Meridian), consumer name fields (first name, middle name or initial, last name, name suffix, and generation indicator), Social Security Number (masked or tokenized as applicable under the FCRA and GLBA, and subject to the permissible purpose requirements of the MDLA), date of birth, current address fields (street address, city, state, ZIP code), prior address fields (up to two prior addresses, where available), and telephone number (where available).
3.2.3 Tradeline Segment. Each tradeline associated with a consumer Record shall be represented as a tradeline segment containing the following fields (at minimum): account number (masked, with only the last four digits visible), creditor name, account type code, date opened, date of most recent report, credit limit or high credit amount, current balance, amount past due, payment pattern (a coded string representing historical monthly payment performance for up to 24 months), account status code (e.g., current, delinquent, charged-off, paid, closed), repayment terms (e.g., monthly, revolving), and portfolio type (e.g., installment, revolving, mortgage, open). A single consumer Record may contain multiple tradeline segments.
3.2.4 Public Record Segment. Each public record associated with a consumer Record shall be represented as a public record segment containing the following fields: court name, record type (e.g., Chapter 7 bankruptcy, Chapter 13 bankruptcy, tax lien, civil judgment), date filed, date resolved or discharged (if applicable), amount, and current status. A single consumer Record may contain zero or more public record segments.
3.2.5 Inquiry Segment. Each inquiry associated with a consumer Record shall be represented as an inquiry segment containing the following fields: subscriber name (the entity that made the inquiry), inquiry date, and inquiry type (e.g., hard inquiry, soft inquiry, promotional inquiry, account review). A single consumer Record may contain zero or more inquiry segments.
3.2.6 Trailer Segment. Each MCI Consumer Credit File™ data file shall conclude with a trailer segment containing the total Record count and a SHA-256 Checksum computed over the data content of the file (excluding the header and trailer segments themselves). The trailer segment Record count shall match the Record count stated in the header segment and the corresponding entry in the Manifest File.
3.2.7 Data Dictionary. Meridian shall provide a comprehensive Data Dictionary for the MCI Consumer Credit File™, attached as Exhibit A-1 to this Schedule, containing complete field-level definitions, data types (e.g., alphanumeric, numeric, date), field lengths (minimum and maximum), permitted values and code tables (e.g., account type codes, account status codes, portfolio type codes, inquiry type codes), null-handling rules (whether a field is mandatory or optional, default values for null fields, and representation of null/empty values), and illustrative sample records. Meridian shall deliver Exhibit A-1 within fifteen (15) Business Days of execution of the MDLA.
3.3 Record Schemas — MCI CommercialView™
The MCI CommercialView™ record schema consists of the following segments. Complete field-level definitions are provided in the Data Dictionary attached as Exhibit A-2.
3.3.1 Header Segment. Each MCI CommercialView™ data file shall begin with a header segment containing the file identifier, creation date and time (UTC), Schema version number, and total Record count.
3.3.2 Business Identification Segment. Each business Record shall include a business identification segment containing the following fields (at minimum): Meridian business identification number (a unique, persistent identifier assigned by Meridian), legal name, "doing business as" (DBA) name(s), Employer Identification Number (EIN), Data Universal Numbering System (DUNS) number (if available from Meridian's records), Standard Industrial Classification (SIC) code(s), North American Industry Classification System (NAICS) code(s), principal address fields (street address, city, state, ZIP code), telephone number, entity type (e.g., corporation, LLC, sole proprietorship, partnership), year established, and employee count (where available).
3.3.3 Credit Profile Segment. Each business Record shall include a credit profile segment containing the following fields: Meridian commercial credit score, score factor codes (up to four factors contributing to the credit score), trade payment data (including supplier names, payment amounts, payment terms, and days-beyond-terms metrics), and aging bucket summaries (current, 1–30 days past due, 31–60 days past due, 61–90 days past due, and 91+ days past due). Trade payment data may include multiple trade lines per business Record.
3.3.4 Public Filing Segment. Each business Record may include zero or more public filing segments containing UCC filing data (filing type, secured party name, collateral description, filing date, and filing status), tax lien data (filing authority, amount, date filed, date released if applicable), judgment data (court name, plaintiff name, amount, date filed, date satisfied if applicable), and bankruptcy data (chapter, case number, date filed, date discharged if applicable).
3.3.5 Financial Statement Segment (Where Available). Where Meridian has obtained or derived financial statement data for a business, the business Record may include a financial statement segment containing revenue range, net worth, and total assets. This segment is populated only where data is available and shall not be present in all business Records. Meridian makes no representation as to the completeness or universal availability of financial statement data.
3.3.6 Trailer Segment. Each MCI CommercialView™ data file shall conclude with a trailer segment containing the total Record count and a SHA-256 Checksum, consistent with the conventions described in Section 3.2.6.
3.3.7 Data Dictionary. Meridian shall provide a comprehensive Data Dictionary for MCI CommercialView™, attached as Exhibit A-2 to this Schedule, containing complete field-level definitions, data types, field lengths, permitted values and code tables, null-handling rules, and illustrative sample records. Meridian shall deliver Exhibit A-2 within fifteen (15) Business Days of execution of the MDLA.
3.4 Record Schemas — MCI AltSignal™
The MCI AltSignal™ record schema consists of the following segments. Complete field-level definitions are provided in the Data Dictionary attached as Exhibit A-3.
3.4.1 Header Segment. Each MCI AltSignal™ data file shall begin with a header segment containing the file identifier, creation date and time (UTC), Schema version number, and total Record count.
3.4.2 Consumer Identification Segment. Each alt-data Record shall include a consumer identification segment keyed to the Meridian consumer identification number used in the MCI Consumer Credit File™. This cross-referencing key enables Quorum to match and link MCI AltSignal™ records to corresponding MCI Consumer Credit File™ records for purposes of comprehensive consumer credit assessment. The consumer identification segment shall also include the consumer's name and address to facilitate matching validation.
3.4.3 Utility Payment Segment. Each alt-data Record may include one or more utility payment segments containing the following fields: utility provider type (electric, gas, or water), account status (active, closed, or in arrears), payment history for a rolling period of twelve (12) to twenty-four (24) months (represented as monthly payment status codes), and delinquency indicators (number of times 30, 60, and 90+ days past due within the payment history window).
3.4.4 Telecom Payment Segment. Each alt-data Record may include one or more telecom payment segments containing the following fields: provider type (wireline, wireless, or internet service provider), payment history for a rolling period of twelve (12) to twenty-four (24) months, and delinquency indicators.
3.4.5 Rental Payment Segment. Each alt-data Record may include one or more rental payment segments containing the following fields: landlord or property manager identifier, monthly rent amount, payment history for a rolling period of twelve (12) to twenty-four (24) months, and eviction records (including eviction filing date, outcome, and status).
3.4.6 Trailer Segment. Each MCI AltSignal™ data file shall conclude with a trailer segment containing the total Record count and a SHA-256 Checksum, consistent with the conventions described in Section 3.2.6.
3.4.7 Data Dictionary. Meridian shall provide a comprehensive Data Dictionary for MCI AltSignal™, attached as Exhibit A-3 to this Schedule, containing complete field-level definitions, data types, field lengths, permitted values and code tables, null-handling rules, and illustrative sample records. Meridian shall deliver Exhibit A-3 within fifteen (15) Business Days of execution of the MDLA.
3.5 API Response Formats — Real-Time Access
The following specifications apply to real-time data access via the REST API provided by Meridian for the MCI Consumer Credit File™.
3.5.1 Response Format. All API responses shall be formatted in JSON (JavaScript Object Notation), conforming to the JSON specification (ECMA-404 / RFC 8259).
3.5.2 API Specification. Meridian shall provide and maintain a comprehensive API specification conforming to the OpenAPI 3.0 (formerly known as Swagger) standard. The OpenAPI 3.0 specification document shall be delivered as Exhibit A-4 to this Schedule and shall include complete endpoint definitions, request/response schemas, authentication requirements, error response definitions, and example payloads.
3.5.3 Response Schema. The JSON response schema for real-time API queries shall mirror the batch record schema segments described in Section 3.2 (consumer identification, tradeline, public record, inquiry), adapted for JSON data structures (using JSON objects and arrays in place of flat-file segments). Field names in the JSON response shall correspond to the field identifiers defined in the Data Dictionary (Exhibit A-1), with appropriate camelCase or snake_case naming conventions as specified in the OpenAPI specification.
3.5.4 Character Encoding. All API responses shall use UTF-8 character encoding, consistent with the JSON specification.
3.5.5 Maximum Response Payload Size. The maximum permitted response payload size for a single API call shall be five (5) megabytes (MB). In the event that a response for a particular consumer query would exceed this limit (e.g., due to an unusually large number of tradelines or inquiries), Meridian shall implement pagination or truncation mechanisms as documented in the API specification (Exhibit A-4), with appropriate pagination metadata included in the response headers or body.
3.5.6 Error Response Codes. API error responses shall use standard HTTP status codes (e.g., 200 OK, 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests, 500 Internal Server Error, 503 Service Unavailable). In addition, Meridian shall provide a custom error code reference table as part of the API specification (Exhibit A-4), including Meridian-specific error codes, error messages, and recommended corrective actions for each error condition.
3.6 Schema Versioning
3.6.1 Version Identifiers. Meridian shall maintain Schema version identifiers in the header segment of all Batch Delivery files and in the response headers or body of all API responses. The Schema version identifier shall follow semantic versioning conventions (e.g., v2.1.3), with major version increments indicating breaking changes, minor version increments indicating backward-compatible additions, and patch version increments indicating corrections or clarifications.
3.6.2 Notice of Material Schema Changes. Meridian shall provide Quorum with not less than ninety (90) days' prior written notice of any material change to record schemas, including the addition, deletion, or modification of mandatory fields, changes to data types or field lengths of existing fields, changes to code table values, and any other change that could reasonably be expected to require modifications to Quorum's data ingestion, processing, or storage systems. Such notice shall include a detailed description of the proposed change, the rationale for the change, the anticipated effective date, and a draft updated Data Dictionary reflecting the proposed change.
3.6.3 Backward Compatibility. Following the deployment of a new Schema version, Meridian shall maintain backward compatibility with at least one (1) prior Schema version for a minimum period of one hundred eighty (180) days. During this backward-compatibility period, Quorum may elect to continue receiving data in the prior Schema version format. Meridian shall not discontinue support for a prior Schema version until the expiration of the 180-day backward-compatibility period and, thereafter, only upon not less than thirty (30) days' additional written notice to Quorum.
3.6.4 Non-Material Changes. For non-material changes to record schemas (e.g., the addition of new optional fields that do not alter the structure or interpretation of existing fields, corrections to code table descriptions, or other changes that would not reasonably be expected to require modifications to Quorum's data systems), Meridian shall provide Quorum with not less than thirty (30) days' prior written notice.
Section 4: Refresh Frequencies and Delivery Schedules
This Section 4 sets forth the refresh frequencies, delivery schedules, and Delivery Windows applicable to each Data Product. All times referenced in this Section are Eastern Time (ET) unless otherwise specified.
4.1 MCI Consumer Credit File™
4.1.1 Batch Delivery: Daily.
(a) Full-File Refresh. A complete full-file refresh of the MCI Consumer Credit File™ shall be delivered once per calendar month, within the first three (3) Business Days of each calendar month. The full-file refresh shall contain all active consumer Records in Meridian's consumer credit database as of the extraction timestamp, regardless of whether such Records have been updated since the prior delivery.
(b) Incremental/Delta Updates. Incremental (delta) update files shall be delivered daily, no later than 6:00 AM Eastern Time on each Business Day. Each daily delta file shall contain (i) newly added consumer Records not present in any prior delivery, (ii) updated tradeline, public record, or inquiry segments reflecting changes since the prior day's delivery, (iii) consumer identification changes (e.g., updated addresses), and (iv) Records flagged for deletion (e.g., deceased consumers, dispute-related suppressions). Delta files shall clearly identify each Record as an addition, update, or deletion using appropriate record-type indicators as defined in the Data Dictionary (Exhibit A-1).
4.1.2 Real-Time API: Available 24/7/365.
The MCI Consumer Credit File™ real-time REST API shall be available for individual consumer credit file inquiries twenty-four (24) hours per day, seven (7) days per week, three hundred sixty-five (365) days per year (including holidays), subject to the uptime, latency, and performance commitments set forth in the Service Level Agreement ("SLA") attached to the MDLA. API responses shall reflect Meridian's then-current production database at the time of query.
4.2 MCI CommercialView™
4.2.1 Batch Delivery: Weekly.
(a) Full-File Refresh. A complete full-file refresh of MCI CommercialView™ shall be delivered once per calendar month, within the first five (5) Business Days of each calendar month. The full-file refresh shall contain all active business Records in Meridian's commercial credit database as of the extraction timestamp.
(b) Weekly Incremental/Delta Updates. Incremental (delta) update files shall be delivered weekly, every Monday, no later than 8:00 AM Eastern Time. If a Monday falls on a non-Business Day (e.g., a federal holiday), delivery shall be made on the next succeeding Business Day. Each weekly delta file shall contain newly added business Records, updated credit profiles, new public filings (UCC filings, liens, judgments, bankruptcies), and updated business demographic information since the prior week's delivery. Delta files shall clearly identify each Record as an addition, update, or deletion using appropriate record-type indicators as defined in the Data Dictionary (Exhibit A-2).
4.2.2 Real-Time API: Not Available Under Initial License Scope.
Real-time API access for MCI CommercialView™ is not included within the scope of the initial license granted under the MDLA. Real-time API access for MCI CommercialView™ may be made available as a future add-on upon mutual written agreement of the parties and subject to separate pricing and technical specifications to be negotiated in good faith.
4.3 MCI AltSignal™
4.3.1 Batch Delivery: Daily.
(a) Full-File Refresh. A complete full-file refresh of MCI AltSignal™ shall be delivered once per calendar month, within the first three (3) Business Days of each calendar month. The full-file refresh shall contain all active alt-data Records in Meridian's alternative data database as of the extraction timestamp.
(b) Daily Incremental/Delta Updates. Incremental (delta) update files shall be delivered daily, no later than 7:00 AM Eastern Time on each Business Day. Each daily delta file shall contain newly added alt-data Records, updated payment histories (utility, telecom, and rental), new delinquency indicators, and Records flagged for deletion. Delta files shall clearly identify each Record as an addition, update, or deletion using appropriate record-type indicators as defined in the Data Dictionary (Exhibit A-3).
4.3.2 Real-Time API: Not Available Under Initial License Scope.
Real-time API access for MCI AltSignal™ is not included within the scope of the initial license granted under the MDLA. Future API access for MCI AltSignal™ may be made available upon mutual written agreement and separate pricing.
4.4 Delivery Windows and Timeliness
4.4.1 Time Zone. All Batch Delivery times and Delivery Windows specified in this Schedule are stated in Eastern Time (ET), including Eastern Standard Time (EST) and Eastern Daylight Time (EDT), as applicable. For the avoidance of doubt, daylight saving time adjustments shall be observed.
4.4.2 Non-Business Day Deliveries. If any scheduled Batch Delivery falls on a day that is not a Business Day (as defined in Section 1.4), delivery shall be made on the next succeeding Business Day at the time otherwise specified in this Section 4. For purposes of SLA measurement, the Delivery Window for such rescheduled deliveries shall be the applicable time on the next succeeding Business Day.
4.4.3 Late Delivery. Any Batch Delivery that is not available on the SFTP server (as evidenced by the posting of the Manifest File) by a time more than four (4) hours past the scheduled Delivery Window shall constitute a "Late Delivery." Late Deliveries shall be subject to the remedies, service credits, and escalation procedures set forth in the SLA. For the avoidance of doubt, a delivery posted at 10:01 AM ET for a 6:00 AM ET Delivery Window would constitute a Late Delivery, while a delivery posted at 9:59 AM ET would not.
4.4.4 Planned Maintenance Windows. Meridian may schedule planned maintenance windows for its data delivery infrastructure, subject to the following limitations:
(a) Batch Systems: Planned maintenance for SFTP and batch processing systems shall not exceed a cumulative total of four (4) hours per calendar month.
(b) API Systems: Planned maintenance for REST API systems shall not exceed a cumulative total of two (2) hours per calendar month.
(c) Notice: Meridian shall provide Quorum with at least seventy-two (72) hours' prior written notice of any planned maintenance window, specifying the anticipated start time, duration, and systems affected.
(d) Scheduling: Planned maintenance shall, to the extent practicable, be scheduled during off-peak hours (between 11:00 PM ET Saturday and 5:00 AM ET Sunday) to minimize impact on Quorum's operations.
(e) SLA Exclusion: Time during planned maintenance windows for which proper advance notice has been provided shall not count as downtime or Late Delivery for purposes of the SLA.
4.5 Holiday Schedule
Meridian shall provide Quorum with an annual holiday and non-delivery schedule at least sixty (60) days before the start of each calendar year. The holiday schedule shall identify all dates on which Meridian's data delivery operations will be closed or operating on a reduced schedule. Holiday-related delays in Batch Delivery shall not exceed one (1) Business Day from the otherwise-applicable Delivery Window. In the first year of the MDLA, Meridian shall provide the holiday schedule within fifteen (15) Business Days of execution of the MDLA. Notwithstanding the holiday schedule, the MCI Consumer Credit File™ real-time REST API shall remain available 24/7/365 in accordance with Section 4.1.2 and the SLA, subject to planned maintenance windows as described in Section 4.4.4.
Section 5: Delivery Methods and Connectivity
This Section 5 sets forth the technical requirements and specifications for the connectivity and delivery mechanisms through which Meridian shall make the Data Products available to Quorum.
5.1 SFTP Batch Delivery
5.1.1 Primary Delivery Method. SFTP shall be the primary delivery method for all Batch Delivery data feeds across all three Data Products (MCI Consumer Credit File™, MCI CommercialView™, and MCI AltSignal™).
5.1.2 SFTP Endpoint. Meridian shall provide a dedicated SFTP server for Quorum's exclusive use in connection with this Schedule. The SFTP server connection details — including hostname, port number, and IP address whitelist — shall be exchanged between the parties during the implementation period described in Section 8. An SFTP Connectivity Worksheet for the exchange of such details is provided as Exhibit A-6 to this Schedule.
5.1.3 Authentication. All SFTP connections shall be authenticated using SSH key-based authentication with a minimum key length of RSA 4096-bit. Password-only authentication is expressly prohibited. Each party shall be responsible for generating, safeguarding, and rotating its SSH keys in accordance with the data security requirements set forth in the Data Security Addendum (DSA) to the MDLA. SSH key rotation shall occur at least annually, or more frequently as required by the DSA or applicable law, with not less than ten (10) Business Days' written notice to the other party prior to any key rotation.
5.1.4 Encryption. All data transmitted via SFTP shall be encrypted in transit using the SSH protocol (SSH-2, with acceptable cipher suites as specified in the DSA). Data at rest on Meridian's SFTP staging server shall be encrypted using AES-256 encryption. Meridian shall maintain and enforce encryption standards consistent with industry best practices and the requirements of applicable regulations, including GLBA Safeguards Rule requirements and NY DFS 23 NYCRR 500.
5.1.5 Directory Structure. Meridian shall maintain a standardized directory structure on the SFTP server, with separate top-level directories for each Data Product:
•  `/mccf/` — MCI Consumer Credit File™
•  `/mcv/` — MCI CommercialView™
•  `/mcas/` — MCI AltSignal™
Within each product directory, Meridian shall maintain subdirectories for full-file deliveries (`/full/`) and delta (incremental) deliveries (`/delta/`). Manifest Files shall be placed in the root of the applicable product directory or in a designated `/manifest/` subdirectory. The exact directory structure shall be documented in the SFTP Connectivity Worksheet (Exhibit A-6) during implementation.
5.1.6 File Retention on SFTP Server. Meridian shall retain all delivered files on the SFTP server for a minimum of thirty (30) calendar days following the date of delivery (i.e., the date on which the Manifest File was posted to the server). This retention period is intended to allow Quorum to re-download files in the event of failed transfers, data corruption during transit, or other operational needs. After the expiration of the 30-day retention period, Meridian may delete delivered files from the SFTP server without further notice to Quorum.
5.1.7 IP Whitelisting. Both parties shall maintain IP whitelists to restrict SFTP access to authorized IP addresses. Quorum shall provide Meridian with the IP addresses or CIDR ranges from which Quorum's systems will connect to the SFTP server, and Meridian shall restrict inbound connections to those whitelisted addresses. Similarly, Meridian shall provide Quorum with the IP addresses from which the SFTP server operates for Quorum's firewall configuration purposes. Any changes to either party's IP whitelist shall require a minimum of five (5) Business Days' prior written notice to the other party.
5.1.8 Quorum's SFTP Pull Responsibility. Quorum shall be responsible for initiating file transfers by pulling (downloading) files from Meridian's SFTP server. Meridian shall not be required to push files to Quorum's systems. Upon posting a completed Batch Delivery (as indicated by the posting of the Manifest File) to the SFTP server, Meridian shall send an automated notification to Quorum via email (to an address designated by Quorum during implementation) or via webhook (to a URL endpoint designated by Quorum) confirming that files are available for download. The notification shall include the applicable Data Product, the delivery date, the number of files, and the total Record count.
5.2 REST API Delivery
5.2.1 Applicability. The REST API delivery method is applicable exclusively to MCI Consumer Credit File™ real-time inquiries, as set forth in Section 4.1.2. The REST API is not available for MCI CommercialView™ or MCI AltSignal™ under the initial license scope.
5.2.2 Base URL. The production base URL for the REST API shall be provided by Meridian to Quorum during the implementation period described in Section 8. The base URL shall conform to a standard HTTPS scheme (e.g., `https://api.meridiancci.com/`) and shall be documented in the API specification (Exhibit A-4).
5.2.3 Authentication. All API requests shall be authenticated using the OAuth 2.0 client credentials flow. Meridian shall issue to Quorum one or more sets of client credentials (client ID and client secret) for use in obtaining access tokens. Access tokens shall have a configurable expiration period (default: sixty (60) minutes). Meridian shall also issue API keys to Quorum as an additional identification mechanism, to be included in request headers. Quorum shall be responsible for safeguarding its client credentials and API keys and shall promptly notify Meridian in the event of any suspected compromise.
5.2.4 Rate Limiting. Meridian shall implement rate limiting on the REST API to protect system stability and ensure fair usage. The following rate limits shall apply:
(a) Default Rate Limit: The default rate limit shall be mutually agreed upon by the parties during the implementation period, documented in the API specification (Exhibit A-4), and reflected in the SFTP Connectivity Worksheet (Exhibit A-6) or a separate API configuration document. The parties anticipate a default rate limit in the range of 100–500 requests per second, subject to Meridian's capacity assessment.
(b) Burst Allowance: A burst allowance, permitting a higher number of requests within a short window (e.g., 10-second window), shall be mutually agreed upon during implementation.
(c) Rate Limit Headers: Each API response shall include the following HTTP response headers to enable Quorum to monitor its rate limit consumption: `X-RateLimit-Limit` (the maximum number of requests permitted within the current window), `X-RateLimit-Remaining` (the number of requests remaining in the current window), and `X-RateLimit-Reset` (the time at which the current rate limit window resets, expressed as a Unix timestamp).
(d) Rate Limit Exceeded: Requests that exceed the rate limit shall receive an HTTP 429 (Too Many Requests) response, with a `Retry-After` header indicating the number of seconds until the client may retry.
5.2.5 API Versioning. Meridian shall implement URI-based API versioning, with version identifiers included in the API endpoint path (e.g., `/v1/consumer/credit-file`, `/v2/consumer/credit-file`). Meridian shall maintain support for at least one (1) prior API version for a minimum of twelve (12) months following the release of a new API version. Deprecation of a prior API version shall require not less than ninety (90) days' prior written notice to Quorum.
5.2.6 Sandbox/Test Environment. Meridian shall provide a dedicated sandbox (test) environment that mirrors the production API specification, including endpoint structure, authentication mechanisms, request/response formats, and error handling. The sandbox environment shall be populated with synthetic (non-production) data of sufficient volume and range to enable Quorum to conduct comprehensive integration testing. The sandbox environment shall be available throughout the term of the MDLA for ongoing regression testing and development purposes.
5.2.7 API Documentation. Meridian shall deliver and maintain current, comprehensive API documentation, including the OpenAPI 3.0 specification (Exhibit A-4), integration guides, code samples (in commonly used programming languages, including Python, Java, and JavaScript/Node.js), and a developer portal providing interactive API exploration capabilities. Meridian shall update the API documentation within fifteen (15) Business Days of any change to the API specification.
5.2.8 Encryption. All REST API communications shall be encrypted in transit using HTTPS with TLS 1.2 or higher. Meridian shall not support TLS versions below 1.2. At Quorum's request, mutual TLS (mTLS) may be implemented for additional client authentication, whereby both Meridian and Quorum present and validate X.509 certificates during the TLS handshake. Implementation of mTLS, if requested, shall be coordinated during the implementation period.
5.3 Connectivity and Network Requirements
5.3.1 Dedicated Connectivity. The parties may elect, by mutual written agreement, to establish a dedicated private network connection between their respective environments in lieu of or in addition to public internet-based connectivity. Such dedicated connectivity may take the form of Meridian Technologies PrivateLink, Azure Private Endpoint, Northgate Corporation Private Service Connect, or a comparable private networking service, depending on the cloud infrastructure utilized by each party. The costs associated with establishing and maintaining any such dedicated private connectivity shall be allocated between the parties as mutually agreed in writing.
5.3.2 Bandwidth Requirements. Meridian's SFTP infrastructure shall support a minimum sustained throughput sufficient to enable Quorum to download the largest anticipated monthly full-file delivery within a reasonable timeframe. The parties shall mutually agree upon minimum throughput requirements (expressed in MB/s) during the implementation period, taking into account expected file sizes, compression ratios, and delivery window constraints. Such agreed throughput requirements shall be documented in the SFTP Connectivity Worksheet (Exhibit A-6).
5.3.3 Network Monitoring. Both parties shall implement network monitoring and alerting for their respective systems involved in data delivery and receipt under this Schedule. Meridian shall provide a publicly accessible status page or API health-check endpoint (e.g., `https://status.meridiancci.com/` or `https://api.meridiancci.com/health`) that Quorum may poll to ascertain the real-time operational status of Meridian's SFTP and API systems. The health-check endpoint shall report the status of each Data Product delivery system and the REST API, with indicators for operational, degraded, and outage states.
Section 6: Data Volume Tiers and Overage
6.1 Base Tier
6.1.1 Included Volume. The Base Tier includes up to five hundred million (500,000,000) Records per calendar month, encompassing consumer Records (MCI Consumer Credit File™), commercial Records (MCI CommercialView™), and alternative data Records (MCI AltSignal™) in the aggregate.
6.1.2 License Fee Inclusion. The Base Tier volume is included in the annual license fees set forth in the MDLA, which provide for aggregate license fees of ten million eight hundred thousand dollars ($10,800,000) for Year 1 (reflecting the implementation ramp period described in Section 8) and twelve million three hundred thousand dollars ($12,300,000) for each of Years 2 through 5 of the initial license term. The total aggregate license fees under the MDLA for the initial five-year term are sixty million dollars ($60,000,000). No additional per-Record fees shall be charged for Records within the Base Tier.
6.1.3 Record Counting Methodology. For purposes of measuring Quorum's consumption against the Base Tier, each discrete Record delivered via Batch Delivery or requested via API shall count as one (1) Record, regardless of the number of segments, sub-records, or individual fields contained within such Record. For the avoidance of doubt:
(a) In the case of Batch Delivery, each Record contained in a delivered data file (as indicated by the Record count in the Manifest File) shall count as one Record.
(b) In the case of API delivery, each individual API request that returns a consumer credit file response (including responses that return a "no record found" result) shall count as one Record.
(c) Records included in both a full-file refresh and a delta delivery within the same calendar month shall be counted only once (i.e., the higher of the full-file Record count or the cumulative delta Record count, not the sum of both, shall be used for the purpose of measuring against the Base Tier). The methodology for avoiding such double-counting shall be documented in the first monthly volume report and applied consistently thereafter.
(d) Failed API requests (i.e., requests that result in a 4xx or 5xx HTTP error response) shall not count against the Base Tier.
6.2 Overage
6.2.1 Overage Rate. For all Records delivered via Batch Delivery or accessed via API in excess of five hundred million (500,000,000) Records in any calendar month, Quorum shall pay Meridian an Overage Rate of $0.003 (three-tenths of one cent) per Record.
6.2.2 Monthly Volume Report. Within ten (10) Business Days following the end of each calendar month, Meridian shall provide Quorum with a monthly volume report (the "Monthly Volume Report") detailing:
(a) The total number of Records delivered or accessed during the calendar month, broken down by Data Product (MCI Consumer Credit File™, MCI CommercialView™, and MCI AltSignal™);
(b) The number of Records delivered via Batch Delivery, further broken down by full-file and delta deliveries;
(c) The number of Records accessed via the REST API;
(d) The aggregate Record count for the month;
(e) The applicable Base Tier threshold (500,000,000 Records);
(f) Any overage, expressed as the number of Records in excess of the Base Tier; and
(g) The resulting overage charge, if any, calculated at the Overage Rate.
6.2.3 Overage Invoicing. Overage charges shall be invoiced monthly in arrears, with each invoice issued simultaneously with or promptly following the delivery of the applicable Monthly Volume Report. Overage invoices shall be payable within thirty (30) days of the invoice date. Overage charges are in addition to, and shall not reduce or offset, the annual license fees set forth in the MDLA.
6.2.4 Volume Disputes. Quorum may dispute any Record count reflected in a Monthly Volume Report by providing a reasonably detailed written objection to Meridian within thirty (30) days of receipt of the applicable Monthly Volume Report. The written objection shall specify the basis for the dispute, including any discrepancies between Meridian's reported counts and Quorum's own internal records. Upon receipt of a volume dispute notice, the parties shall work together in good faith to reconcile the discrepancy within thirty (30) Business Days. If the parties are unable to resolve the dispute through good-faith reconciliation, the dispute shall be subject to the dispute resolution provisions set forth in the MDLA. Pending resolution of any volume dispute, Quorum shall pay the undisputed portion of any overage invoice in full, and payment of the disputed portion shall be suspended without accrual of interest or late fees until the dispute is resolved.
6.3 Current Estimated Volumes
6.3.1 Volume Projections. Based on Quorum's current data consumption projections (provided by Priya Nair, Director, Data Engineering, Quorum Insurance Holdings Corp.), estimated monthly volumes during the steady-state production period (following completion of the implementation period described in Section 8) are as follows:
These estimates are provided for informational and planning purposes only and do not constitute a commitment by Quorum to consume any specific volume of Records.
6.3.2 Consumption Flexibility. Quorum reserves the right to adjust its data consumption patterns within the Base Tier at any time and without penalty. By way of example and without limitation, Quorum may elect to increase its consumption of one Data Product while decreasing its consumption of another, provided that the aggregate monthly Record count does not exceed the Base Tier (or, if it does exceed the Base Tier, that Quorum pays the applicable Overage Rate for such excess).
6.3.3 Volume Forecasting. To facilitate capacity planning, Quorum shall provide Meridian with a good-faith quarterly volume forecast at least thirty (30) days prior to the start of each calendar quarter, setting forth Quorum's anticipated Record consumption by Data Product for the upcoming quarter. Such forecasts are provided for Meridian's capacity planning purposes only and shall not constitute a binding commitment or guarantee by Quorum of any particular consumption level. Meridian shall use commercially reasonable efforts to ensure that its delivery infrastructure has sufficient capacity to accommodate Quorum's forecasted volumes, plus a reasonable capacity buffer.
Section 7: Data-Quality Acceptance Criteria
This Section 7 sets forth the data-quality acceptance criteria applicable to all Data Product deliveries under this Schedule. These criteria are intended to ensure that the data delivered by Meridian meets minimum standards of completeness, accuracy, timeliness, consistency, and integrity necessary for Quorum's intended use of the Data Products in its insurance underwriting, risk assessment, and related operations.
7.1 Data Completeness
7.1.1 Fill Rates for Mandatory Fields. Meridian warrants that all fields designated as "mandatory" in the applicable Data Dictionaries (Exhibits A-1 through A-3) shall have a fill rate of not less than [__]% across all Records in each Batch Delivery. The fill rate for a given mandatory field shall be calculated as the number of Records in which the field contains a valid, non-null value, divided by the total number of Records in the delivery, expressed as a percentage.
7.1.2 Missing Mandatory Fields — Exception Files. Any Record in a Batch Delivery in which one or more mandatory fields are missing (i.e., contain null, blank, or otherwise invalid values) shall be flagged and included in a separate error/exception file delivered alongside the primary data file. The exception file shall identify, for each affected Record, the Record identifier, the field(s) that are missing or invalid, and, where available, the reason for the missing data (e.g., "data not furnished by contributor," "suppressed per consumer dispute"). Exception files shall conform to the naming conventions specified in Section 3.1.5, with a distinct BatchType indicator (e.g., "EXCEPT") to distinguish them from primary data files.
7.1.3 Optional Fields. No minimum fill rate is required for fields designated as "optional" in the applicable Data Dictionaries. However, Meridian shall not degrade the fill rates of optional fields below their historical averages (computed as the trailing twelve (12)-month average fill rate for each optional field) by more than [__]% without providing Quorum with prior written notice and a reasonable explanation for the degradation. For the avoidance of doubt, seasonal or cyclical fluctuations in optional field fill rates within the specified tolerance shall not constitute a breach of this provision.
7.2 Data Accuracy
7.2.1 General Accuracy Standard. Meridian represents and warrants that all data delivered under this Schedule reflects Meridian's then-current database as of the applicable refresh timestam