Privacy Policy

1. Who we are

The Service is operated by Moonlighter AB (Sweden, organisationsnummer 559395-7979). For data-protection enquiries, contact compliance@strale.io.

Moonlighter AB is the data controller for account, billing, and usage data described below. For data that customers send to the API to be processed by a capability (e.g. counterparty information for Payee Assurance), Moonlighter AB acts as a data processor on the customer’s behalf. A data processing agreement (DPA) is available on request.

2. Data we process

We process three categories of personal data:

• Account & billing: name, email, organisation, hashed API keys, billing records. Card and bank details are handled by our payment processor — we do not see or store them. On-chain wallet addresses used for x402 payments are public by design.
• Usage: request metadata (timestamp, IP, capability, response status, latency), audit records (input fingerprint as SHA-256 hash, output schema validation result, transparency markers), and minimal cookieless website analytics.
• Customer-input: data customers send to the API for processing by a capability. May include personal data (e.g. names, VAT numbers, beneficial-ownership data) and, for some capabilities, special-category data under Art. 9 GDPR (PEP / sanctions screening) or criminal-conviction data under Art. 10 GDPR (adverse-media checks). We process this data only to execute the requested capability. We do not use it to train models and do not sell it.

3. Why we process it (lawful basis)

• Contract (Art. 6(1)(b) GDPR): to provide the Service — issuing API keys, executing API calls, generating audit records, billing.
• Legitimate interests (Art. 6(1)(f) GDPR): security, fraud and abuse prevention, rate-limiting, audit-trail integrity, and aggregate product improvement.
• Legal obligation (Art. 6(1)(c) GDPR): accounting, tax, anti-money-laundering record-keeping, and lawful regulator requests.
• Consent (Art. 6(1)(a) GDPR): for marketing emails, withdrawable at any time.

Where customers use capabilities involving Art. 9 / Art. 10 data, the customer is responsible for ensuring an appropriate condition under Art. 9 / Art. 10 (typically substantial public interest, fraud prevention, or comparable lawful basis).

4. Recipients

We share personal data only with categories of recipients necessary to operate the Service: cloud hosting and database providers, payment processors, AI inference providers (for AI-assisted capabilities), and the upstream data sources required to fulfil a capability call (e.g. national company registries, sanctions data providers).

Each recipient is bound by an appropriate contract (data processing agreement, standard contractual clauses, or independent-controller terms). The current named sub-processor list is below; we update this list when a vendor changes (last reviewed 30 April 2026).

Current named sub-processors

Country-registry, vendor-API, and other upstream data sources for individual capabilities are documented per-call in the audit record's data_source and provenance.upstream_vendor fields. The sub-processor list above covers infrastructure and shared services; per-capability data sources may add additional processors documented in the call's audit body.

We notify customers via the contact email on file at least 30 days before adding or changing a sub-processor that processes personal data, except where the change is required for security or regulatory compliance and a shorter notice is necessary.

5. International transfers

Our infrastructure and several recipients are located in the United States. Where personal data leaves the EEA or the UK, we rely on:

• European Commission Standard Contractual Clauses (Decision 2021/914), with the UK International Data Transfer Addendum where applicable;
• the EU-US Data Privacy Framework and its UK Extension where the recipient is certified;
• supplementary measures including encryption in transit and at rest, access controls, and minimisation of data sent to recipients.

6. Retention

• Account data: lifetime of account plus seven years (Swedish accounting law).
• Audit records: 3 years by default (Colorado AI Act SB 24-205 minimum); configurable up to 7 years for customers with longer regulatory record-keeping obligations.
• Customer-input: stored alongside the audit record under Art. 30 (records of processing) for the same period as the audit itself; redacted in place when retention expires so the audit-chain integrity hash remains verifiable.
• Trial-credit record: a SHA-256 hash of the email address a one-off trial credit was issued to, with the date and amount. Retained indefinitely and deliberately survives account closure — it is the only way to enforce one trial credit per address without storing the address, and deleting it would let the same address claim the credit again by closing and re-registering. Lawful basis: Art. 6(1)(f). We do not present it as anonymised data: a hash of an email address is pseudonymous, because someone who already guesses the address can confirm it by hashing it. The account link and the IP hash on that record are cleared when the account closes; only the hash remains. To have it removed — accepting that the address can then claim trial credits again — email compliance@strale.io.
• Server & security logs: 90 days.
• Marketing data: until consent is withdrawn or 24 months of inactivity.

7. Security

We use industry-standard measures appropriate to the risk: TLS in transit, encryption at rest, hashed API keys, role-based access controls, audit logging, and tamper-evident audit chains. Detail on our public security posture is on the Security page.

7.5 Automated decisions and DPIAs

Strale operates as a processor for capability calls; the API customer is the GDPR controller for personal data they pass in. Under Art. 22, the right not to be subject to a decision based solely on automated processing runs against the controller. Strale (as processor) provides the infrastructure to support the controller's compliance — every audit response carries a gdpr.art_22_classification field (one of data_lookup, screening_signal, or risk_synthesis) plus a plain-language disclosure of what that classification means and a dispute_endpoint URL.

For capabilities where the processing characteristics meet at least one Art. 35(3) trigger (Art. 9 / Art. 10 special-category data, automated decision support, or systematic monitoring), we publish a Data Protection Impact Assessment as a reference document. These describe Strale's own processing risk profile and mitigations, and serve as a starting point for the customer's own DPIA covering their pipeline:

• sanctions-check + pep-check — Art. 9 (PEP) + Art. 10 (sanctions) data via Dilisense (combined DPIA — both capabilities share the same vendor wrap and risk profile)
• adverse-media-check — Art. 9 / Art. 10 data via Dilisense (primary) + Serper.dev fallback
• risk-narrative-generate — Art. 22 automated decision-support synthesis via Anthropic Claude
• company-enrich — Web-scraped company profile via Browserless + Anthropic

8. Your rights

Under the GDPR and UK GDPR you have the right to access, rectify, erase, restrict, port, and object to the processing of your personal data, and to withdraw consent where consent is the basis. To exercise any of these rights, email compliance@strale.io. We will respond within one month.

The Service exposes DELETE /v1/auth/me for full-account erasure (anonymises identifiers, burns the API key, zeroes the wallet, and clears the customer content from your transaction rows) and DELETE /v1/transactions/{id} for transaction-level erasure.

A note on full-account erasure: everything you sent and everything derived from it is cleared from your transaction rows by the request itself — the request payload, the response, failure messages, the audit body, upstream source records and your idempotency keys. This is the same in-place redaction we already apply to every transaction once its retention window expires, so it is proven not to break the integrity chain: the chain hashes are untouched and every later transaction still verifies, with yours reported as redacted rather than broken.

What survives is the processing record under Art. 30 — that a call happened, when, what it cost, and its place in the hash chain — together with the user_id on that row, which points at your now-anonymised account row. A bare identifier is not a name, and severing it would break the chain every later transaction references. The one exception to the clearing is a transaction under a legal hold, which we are required to preserve intact; the erasure response reports how many, if any, were held back.

If you believe we have not handled your data lawfully, you may lodge a complaint with the Swedish supervisory authority IMY, the UK ICO, or the supervisory authority in your country of residence.

9. Changes

We may update this policy. Material changes will be communicated by email at least 30 days before they take effect. The version date at the top of this page reflects the current effective date.