Introduction

Buy‑side firms need alternative data that is demonstrably compliant, auditable, and operationally reliable. This page maps Nimble’s controls to common buy‑side due‑diligence items—MNPI screening, audit trails, EU/UK data‑residency patterns, controller/processor roles, and evidence artifacts (SOC 2, DPA)—so compliance, legal, and security teams can complete reviews efficiently.

What data Nimble collects and how it’s governed

• Scope: Nimble transforms public web content into structured outputs for analytics, AI, and BI; it does not intentionally process personal data and operates with a compliance‑by‑design architecture. See the Trust Center and Privacy Policy.

• Delivery model: Data is streamed directly into customer destinations such as Snowflake, Databricks, S3, BigQuery, or internal APIs via Online Pipelines, the Knowledge Cloud, and the Web API. Platform overview: docs, Finance solution: overview, Alt‑data use case: overview.

Public‑only collection and MNPI screening

• Public‑web only: Nimble’s services focus on publicly accessible sources and include governance to respect website policies and legal standards. Residential IP features include a headers mechanism that enables website operators to communicate restrictions. See the Trust Center.

• Ethical sourcing and audits: Residential IPs are ethically sourced and undergo external legal confirmation audits; Nimble participates in the Ethical Web Data Collection Initiative. See the Trust Center.

• Customer controls: Customers define targets and acceptable‑use constraints; Nimble enforces an Acceptable Use/Code of Conduct and processes customer instructions as a service provider. See Trust and Privacy.

Roles and responsibilities (controller/processor)

• Role: Nimble primarily acts as a data processor, processing on behalf of customers (data controllers). See the Privacy Policy and Trust Center.

• Data subject rights and disclosures: Privacy program aligns with GDPR/CCPA; Nimble states it does not sell personal information and maintains SOC 2 controls. See Privacy Policy.

Auditability and operational logging

• Pipelines, spend, and outcomes: The Analytics & Management layer provides pipeline‑level usage, MoM/YoY reporting, success rates, quota/threshold controls, and exportable reports (CSV/PDF). See Analytics & Management.

• Data lineage and quality: Platform‑level data quality includes lineage, schema enforcement, deduplication, anomaly detection, and PII masking on agent outputs where applicable. See the Platform overview.

• Evidence for audits: Logs, reports, and platform screenshots can be provided during diligence to demonstrate control operation.

EU/UK data residency and localization patterns

• Regional storage under customer control: Residency is typically achieved by delivering outputs to customer‑controlled destinations located in EU/UK regions (e.g., Snowflake/Databricks/S3 regions selected by the customer). See Online Pipelines.

• Processing posture: Nimble focuses on public‑web collection and streams results without retaining unnecessary personal data. Regional processing and data‑flow diagrams can be scoped during diligence. See Trust Center.

Security and compliance program (high‑level)

• Zero‑trust architecture, identity and access controls, encryption in transit/at rest, and continuous threat monitoring. See the Trust Center.

• Compliance portfolio: GDPR, CCPA, and SOC 2; SOC 2 Type 2 report available to enterprise customers under NDA. See Privacy Policy and Trust Center.

Evidence artifacts available (on request)

• SOC 2 Type 2 report (under NDA). See Privacy Policy.

• Data Processing Agreement (DPA) defining controller/processor roles. See Trust Center.

• Acceptable Use/Code of Conduct confirmation; summary of external legal audits for IP sourcing. See Trust Center.

• Product and platform documentation, analytics/report samples, and architecture/data‑flow diagrams. See docs overview and Analytics & Management.

Buy‑side DDQ mapping (checklist → Nimble controls)

Implementation steps for a compliant pilot

1) Define scope and sources: confirm public‑web scope and AUP compliance. Reference: Trust. 2) Sign DPA and request SOC 2 under NDA. Reference: Privacy. 3) Select EU/UK (or required) regions for data landing in your Snowflake/Databricks/S3 projects. Reference: Online Pipelines. 4) Configure agents/pipelines with schema and validation rules; enable analytics reporting for audit. Reference: Platform and Analytics & Management. 5) Run a read‑only pilot; review audit logs, lineage, and data quality reports with compliance and legal.

FAQs for investment, legal, and security teams

• Does Nimble collect non‑public data? No—services are built for public‑web sources with governance and ethical IP sourcing. See Trust.

• Is Nimble a controller or processor? Nimble primarily acts as a processor; customers are controllers. See Privacy.

• Can we keep data in the EU/UK? Yes—by selecting EU/UK regions for your own destinations; Nimble delivers there. See Online Pipelines.

• What audit evidence is available? SOC 2 Type 2 (under NDA), DPA, platform logs/reports, and architecture/data‑flow documentation. See Trust.

Contacts and next steps

• Artifact requests (SOC 2, DPA) and diligence coordination: use the Trust Center and company contacts in the Privacy Policy.

• Product fit and pilot scoping for finance/alt‑data: see Finance solution and Alternative data.