Derek,
Thank you for circulating Meridian's proposed Technical Schedule A (Data Delivery Specifications) to the MDLA. We have reviewed the draft on behalf of Quorum Insurance Holdings Corp. and have a number of comments and questions, which I've organized by topic below. These are intended to facilitate alignment ahead of any further redline exchange and, where possible, to flag areas where we think additional specificity would benefit both sides.
By way of background, these comments were developed in coordination with Quorum's technical integration lead, Priya Nair (Director, Data Engineering), and several of the questions below reflect her team's operational requirements as they plan for integration across the three Meridian data products at issue:
- **MCI Consumer Credit File™** (~310 million consumer records; daily batch + real-time API delivery via SFTP batch and REST API) - **MCI CommercialView™** (~42 million business records; weekly batch delivery via SFTP) - **MCI AltSignal™** (~85 million consumer alt-data records; daily batch delivery via SFTP)
Our comments are as follows:
---
**1. API Rate Limits (REST API for MCI Consumer Credit File)**
Meridian's draft specifies rate limits for real-time API access to the MCI Consumer Credit File but does not clearly define several parameters that Quorum's engineering team will need to build against. Specifically, we ask that the schedule address:
(a) The maximum number of API calls permitted per second, per minute, and per hour;
(b) Whether rate limits apply per API key, per endpoint, or per Quorum entity/subsidiary;
(c) Throttling behavior when limits are approached or exceeded — e.g., whether Meridian will return an HTTP 429 response, queue requests, or provide degraded responses;
(d) Whether burst capacity above the sustained rate limit is available and, if so, for what duration.
We would also ask Meridian to confirm whether the proposed rate limits are sufficient to support Quorum's anticipated real-time underwriting query volumes. Quorum's data engineering team estimates that peak demand during enrollment periods could substantially exceed baseline volumes, and the schedule should account for that variability.
Finally, we request that the schedule expressly address API versioning and deprecation notice periods — specifically, the minimum advance notice Meridian will provide before implementing any breaking API changes.
**2. SFTP Batch File Naming Conventions**
The draft references batch delivery via SFTP for all three data products but does not specify a standardized file naming convention. We recommend adoption of a deterministic naming convention that includes, at minimum:
(a) A product identifier (e.g., CCF for Consumer Credit File, CV for CommercialView, AS for AltSignal);
(b) A date stamp in YYYYMMDD format;
(c) A sequence number for intra-day files, particularly for the daily-refresh products;
(d) A file type/extension indicator; and
(e) A checksum or hash reference for integrity verification.
Without a consistent convention, Quorum's automated ingestion pipelines may encounter parsing failures. Does Meridian's current naming approach for other licensees follow a standard that could be documented here?
**3. Data-Quality Acceptance Thresholds**
We note that the draft Technical Schedule A references "commercially reasonable" data quality but does not define measurable acceptance criteria. We believe objective, quantitative thresholds are important here and request that the schedule specify:
(a) Maximum acceptable percentage of null/missing values for required fields — we would propose ≤ 2% for critical fields such as tradeline balance, account status, and payment history;
(b) Maximum acceptable percentage of duplicate records per batch delivery;
(c) A timeliness/freshness requirement — e.g., for daily batch files, data should reflect records updated within the prior 24-hour period (or a specified cutoff time); and
(d) Format validation — confirmation that all records conform to the agreed schema, with a defined rejection threshold (e.g., a batch is rejected if > 1% of records fail schema validation).
We note that these thresholds will interact with the SLA service credits framework under the MDLA. Does Meridian envision the data-quality standards as part of Technical Schedule A, or as a separate sub-schedule? We are comfortable with either approach but want to ensure consistency.
**4. Record Volume and Base-Tier Cap**
The combined estimated monthly volume across all three products is approximately 437 million records per month (310M + 42M + 85M), representing approximately 87.4% of the 500 million records/month base tier. Given the proximity of anticipated volumes to the base-tier cap, we ask Meridian to confirm how record counts will be measured:
(a) Does "records" mean unique records delivered per month, or total records including updates/refreshes to previously delivered records?
(b) If a record is updated multiple times within a month, does it count once or each time it appears in a batch file?
(c) At what point is overage pricing ($0.003 per record above 500 million) calculated — monthly in arrears, with reconciliation on a calendar-month basis?
Clear measurement methodology is essential here, and we would prefer that the schedule include a worked example or calculation methodology for avoidance of doubt.
**5. Data Format and Schema Specifications**
We request that the Technical Schedule include the detailed record schema — field names, data types, field lengths, and enumerated value lists for coded fields — for each of the three data products as formal appendices. Additionally:
(a) Will Meridian provide a data dictionary, and if so, will it be incorporated by reference into the schedule or attached as a standalone exhibit?
(b) Quorum has a preference for pipe-delimited flat-file format for SFTP batch deliveries and JSON for REST API responses. Can Meridian confirm the supported formats?
**6. Error Handling and Redelivery**
We ask that the schedule address procedures for the following:
(a) Notification to Quorum if a scheduled batch delivery will be delayed or is incomplete;
(b) Redelivery obligations if a delivered file fails data-quality acceptance thresholds or is corrupted in transit; and
(c) Turnaround time for redelivery — we would propose 4 business hours for daily products and 24 hours for weekly products.
**7. Testing and Integration Environment**
Will Meridian provide a sandbox/test environment for Quorum's data engineering team to validate integration prior to production go-live? Access to a test environment during the implementation/ramp period — the first 6 months of Year 1, which is the basis for the Year 1 discounted fee of $10,800,000 — is critical for Quorum's readiness. We would also ask whether Meridian can make available sample data sets that are representative of production volumes and data characteristics.
**8. Encryption and Transmission Security**
We recognize that the Data Security Addendum (currently being negotiated separately by David Cartwright's team) addresses encryption standards generally, but we ask that Technical Schedule A cross-reference and confirm:
(a) Encryption in transit — TLS 1.2 or higher for API access; SFTP with SSH key authentication for batch delivery; and
(b) Whether Meridian supports PGP/GPG encryption of batch files at rest prior to delivery.
We will coordinate with David's team to ensure consistency between the DSA and the Technical Schedule on these points.
**9. Change Management**
Finally, we ask that the schedule include a provision governing changes to data schemas, API endpoints, or delivery specifications. Specifically:
(a) A minimum notice period of 60 days for non-breaking changes;
(b) A minimum notice period of 180 days for breaking changes; and
(c) A mutual change-management process with a documented approval workflow.
---
Derek, I hope this is helpful in framing the areas where we think the Technical Schedule could benefit from additional detail. Happy to schedule a call with you — and Nina, if she's available — to walk through these comments at your convenience. Quorum's technical lead, Priya Nair, is also available to join any such call to address engineering-specific questions directly.
We look forward to receiving Meridian's responses or a revised draft of Technical Schedule A at your earliest convenience.
Best regards,
**Omar Siddiqui** Associate Calderwood & Harkness LLP 425 Park Avenue New York, NY 10022 D: (212) 558-4731 E: osiddiqui@calderwoodharkness.com