How Parsela handles your data.

Current compliance posture

Parsela is in pre-GA with active design partners. SOC 2 Type II framework is in progress. The technical controls required for certification are already implemented; the audit itself is scheduled post-GA.

Compliance-grade shipment identity

In freight, merging two shipments that should have stayed separate is a compliance incident — not a data-quality bug. Two customers' cargo appearing on one BL. Two bookings merged because they share a container. One shipper's exports appearing under another's manifest. Any of these triggers customs exposure, regulatory disputes, and — in the worst case — cargo released to the wrong consignee.

Parsela's identity resolution is designed to never make this mistake. The 4-tier identity cascade uses only deterministic legal identifiers — House BL, Master BL, generic BL numbers, booking references — to merge shipments. Weaker signals like container numbers, vessel-voyage pairs, and email IDs are stored in the audit trail but never trigger a merge.

A booking can split into many shipments. Many bookings can merge into one consolidated shipment. But only with explicit operator action and an AMENDED audit event carrying the reason code (carrier re-issue, customer change, consolidation split, consolidation merge, operator correction), the effective date, and the triggering document identifier.

Every amendment is append-only logged. Rolling back an amendment creates another audit event — history is never silently edited. The compliance officer and the customs broker can reconstruct any shipment's identity history end-to-end without trusting the application layer.

On the field level, every shipment field carries an ownership state (Parsela-proposed, human-edited, or locked once a downstream event such as customs filing has committed it). When a value changes, a field_edit_log entry records the old value, new value, actor, source (Parsela, TMS operator, system), and timestamp. When Parsela and a TMS operator disagree, the conflict surfaces in a resolution queue — Parsela does not silently overwrite a human edit.

Authentication & access control

Parsela uses JWT-based authentication with short-lived tokens and server-side revocation. Role-based access control (RBAC) enforces a four-tier authority matrix across every privileged endpoint: Analyst (1), Manager (2), Director (3), Admin (4). Every mutation writes a canonical audit log entry capturing actor identity, target, before/after state, and timestamp.

Data handling

Parsela processes your shipping documents to extract structured data. Here is exactly what happens to that data at each stage.

Document ingestion

Documents arrive via IMAP email polling, web upload, or REST API. At ingestion, Parsela stores the original PDF in customer-controlled object storage (AWS S3, Google Cloud Storage, or on-prem MinIO depending on deployment). Document bytes never transit uncontrolled infrastructure.

AI extraction

Extraction uses frontier AI models under vendor agreements that forbid training on submitted data. For cloud deployments, API calls are made through the provider's standard commercial privacy terms. For customers with stricter data residency requirements, Parsela can be deployed with the hyperscaler's managed AI service (AWS or GCP), keeping document data within the customer's VPC. See the sub-processors section below for the specific vendors.

Data at rest

Extracted structured data is stored in PostgreSQL (RDS for AWS, Cloud SQL for GCP, or self-hosted) with encryption at rest enabled by default. Original PDFs remain in object storage with server-side encryption. Access is limited by vendor scoping — the multi-tenant architecture ensures operators only see documents from vendors they are explicitly assigned to.

Data in transit

All external traffic uses TLS 1.2+. Internal service-to-service calls within the VPC are also TLS. Webhook delivery to your TMS includes HMAC-SHA256 signatures so your TMS can verify the payload originated from Parsela.

PII handling

Shipping documents regularly contain PII (consignee contact names, signatures on PODs). Parsela includes optional PII redaction that runs before any LLM call — controlled by the PARSELA_PII_REDACT deployment flag. When enabled, named entities are replaced with semantic placeholders before extraction, then re-associated after. Standard mode is disabled; enterprise and air-gapped modes default to enabled.

Deployment options

Different customers have different data sovereignty requirements. Parsela ships in four deployment configurations, controlled by environment variable — no code changes required to switch.

Sub-processors

Parsela uses a small set of sub-processors. Each is vetted for security posture and has a DPA in place. The list below applies to Cloud (Standard) deployments; VPC, on-premises, and air-gapped deployments have reduced or zero external sub-processors.

• Anthropic — primary frontier LLM provider for document extraction and classification. SOC 2 Type II certified. No training on API-submitted data per Anthropic's commercial terms.
• Amazon Web Services — compute, storage (S3), queuing (SQS), and database (RDS PostgreSQL). SOC 2 Type II, ISO 27001, PCI DSS, HIPAA-eligible.
• Voyage AI — embeddings for retrieval-augmented contextual matching. Applied only to extracted field values, never to raw document bytes.
• Plausible Analytics — privacy-first web analytics for parselaai.com marketing pages only. No data collection inside the authenticated application.

Vulnerability reporting

If you believe you've found a security vulnerability in Parsela, please email [email protected] with a description and reproduction steps. We commit to acknowledging all reports within 48 hours and publishing a fix timeline within 7 days. Responsible disclosure is appreciated and we're happy to discuss bounty arrangements for substantive findings.