Trust
Security & trust
Flokte processes order and return data on a merchant's behalf. This page describes how that data is protected and how privacy obligations are met. It is written to be honest about what is and isn't in place yet.
Security posture
Encryption
All data is encrypted in transit (TLS). At rest, customer identifiers — email, name, full address — are encrypted with AES-256-GCM. Only coarse geography (country, region, ZIP prefix) is stored in clear, and only to test the model for fairness across regions.
Least-privilege access
Internal access to customer identifiers and scores is restricted to the roles that need it. Access to decrypted personal data is the exception, not the default.
Append-only audit log
Every score, every action taken on it, and every dispute and resolution is written to an audit log that the database itself prevents from being edited or deleted.
Separated environments
Test and production run in fully separate environments with separate data and separate credentials. Real customer data never flows into a test environment.
Data minimization
Flokte ingests only what the return-abuse purpose needs: order and return records and platform-provided identifiers. No payment instruments, no browsing or device data, no street addresses on individual orders, no off-platform data, and no pooling of one merchant's data with another's.
Retention limits
Retention windows are set per data type and enforced by a scheduled deletion job — not manual cleanup. Derived scores are versioned and aged out on the same basis.
Privacy-request handling
- • Flokte handles the platform's mandatory privacy webhooks — customer data-request, customer redaction, and shop redaction.
- • A customer-redaction request anonymizes or removes that customer's personal data. A shop-redaction request purges the merchant's data in full.
- • Because Flokte acts as a processor, requests about a specific shopper are routed to the merchant that store belongs to. See the privacy-request path.
Independent review
Flokte has not yet completed a third-party security audit or penetration test. A penetration test is planned before general availability, and the scoring-and-restriction flow is under independent legal review before restriction features are enabled for any live merchant. We would rather say this plainly than imply a certification we don't hold.
Model fairness is tested before launch and before any scoring change — details on the how it works page.
Sub-processors & reporting
The third parties Flokte relies on to run the service are listed on the sub-processors page. To report a security issue, email security@flokte.com. We aim to acknowledge within two business days.