Compliance risk register
Validate the adult-platform constraints before public launch.
This register captures known legal, payment, tax, privacy, content-safety, and operational risks. It is a planning tool, not legal advice. Counsel and processor review are required before public commercial launch.
Ground rule
Minimum data does not mean zero obligations. The platform should be designed so compliance, payment, tax, and abuse response rely on purpose-bound records rather than broad identity collection.
Risk register
Known risks and current stance
| Risk | Current stance | Decision needed before public launch |
|---|---|---|
| Age assurance | Private/test mode can use self-attestation. Public launch should support a pluggable verifier without Nocturne storing ID documents. | Confirm jurisdiction and processor requirements; evaluate anonymous/pass-fail over-18 options. |
| ID document storage | Nocturne stores none. | Any third-party verifier must have strong deletion, minimization, security, and no-marketing-use commitments. |
| Payment processor approval | Source-backed provider matrix now marks Stripe, PayPal, and Lemon Squeezy as avoid-first for MVP and identifies CCBill/Verotel as primary outreach candidates. Current code remains processor-neutral with local payment proof/reversal, entitlement linking, and webhook inbox/replay; it does not assume a live provider or store raw processor payloads. | Use the payment provider matrix to capture written approval for AI adult content support, subscription/pass support, chargeback flow, tax/VAT support, age-assurance expectations, and prohibited-content rules before provider-specific code. |
| Crypto payments | Not MVP default. | Validate legality, refunds, chargebacks, accounting/tax, fraud, sanctions, and abuse implications before enabling. |
| VAT / digital services tax | Likely relevant for EU/UK/international sales. | Confirm where the entity is based, whether processor handles tax, and whether One Stop Shop or equivalent registration is needed. |
| AI-generated / deepfake labeling | Platform should disclose synthetic nature from day one. | Confirm EU AI Act and local rules around AI-generated/deepfake transparency before public launch. |
| Likeness / NCII complaints | No intentional real-person likeness; public /report and local CLI report cases can open private cases, while owner review can quarantine media or archive catalog/request targets for accidental resemblance or rights complaints. Public intake has non-identifying automation guardrails but does not require reporter identity by default. The private-VPS escalation runbook now defines SLA targets, quarantine-first handling, evidence minimization, and external-escalation triggers. | Validate the runbook against jurisdiction/provider obligations, long-form terms, privacy notice, and removal/audit requirements before public operation. |
| CSAM / child exploitation indicators | Zero tolerance. Public and local report cases support urgent priority; owner review can quarantine targets, but external reporting is not automated. Intake controls reduce low-effort spam without replacing urgent human review. The private-VPS runbook requires urgent quarantine-first handling and official reporting-path identification before public launch. | Confirm provider obligations, external reporting pathway, evidence preservation limits, and owner response procedure before public operation. |
| User-generated text | Private requests only in the current foundation; links are rejected, deterministic local Hermes screening records moderation state/rule/reason/version, poll options are owner-created, and live chat remains deferred. | Calibrate Hermes taxonomy, define fuller enforcement events, and validate escalation operations before expanding beyond local/private testing. |
| Privacy / GDPR | Data minimization, purpose limitation, retention ledger, and no behavioral analytics by default. Public report guardrails use an 8 KiB body cap, hidden honeypot, boot-secret stateless token, dwell/expiry checks, and owner queue cap rather than raw IP/user-agent tracking. | Draft privacy notice, data processing inventory, deletion/export policy, processor DPAs, and retention windows. |
| Security logs | No persistent raw identifying access logs by default; purpose-bound short-lived operational records. Public report abuse hardening currently avoids per-IP throttling and relies on non-identifying form/queue controls. Production-edge doctor/preflight checks and proxy templates now require HTTPS origin, secure cookies, owner gate, non-local backup posture, final non-placeholder origin, bounded owner-session lifetime, and disabled access logs by default before exposure. | Define exact incident log fields, hashing/truncation strategy, retention windows, access controls, deletion date, and production WAF posture before enabling any proxy access log override. |
| Production HTTPS edge | The app has an explicit production deployment profile, HTTPS public-origin validation, conditional HSTS, default/public-report body caps, backup posture diagnostics, local-only detailed diagnostics, copy-safe Caddy/nginx reverse-proxy templates, and an external edge smoke harness for final-origin checks. | Select VPS/provider, configure real TLS, avoid direct public app-port exposure, tune WAF/rate limits, run external smoke from outside the VPS network, configure encrypted/offsite backups, complete an isolated restore drill, and document proxy log retention. |
| Rewards / contests | Later feature only. | Gift cards, raffles, prizes, and regional restrictions may trigger contest/sweepstakes/tax rules; review before use. |
| Discord community | Optional satellite only, not core MVP. | Confirm Discord adult-content rules, age-restricted settings, moderation bot rules, and privacy tradeoffs before using. |
| Hosting jurisdiction | Europe preferred, Netherlands considered but not locked. | Compare Netherlands/EU alternatives for adult-content hosting, payment compatibility, privacy law, latency, and takedown process. |
Jurisdiction
Open jurisdiction questions
- Where will the legal entity be formed?
- Where will the VPS and media storage reside?
- Which markets will be intentionally served, and which will be blocked or unsupported?
- Will US users be accepted at launch?
- Which payment processor can support the content category, jurisdiction, subscription model, and tax handling?
Reference starting points
Official or primary references to review
| Topic | Reference | Why it matters |
|---|---|---|
| EU age verification direction | European Commission — EU age verification | Useful direction for privacy-preserving proof-of-age expectations. |
| AI-generated content transparency | European Commission — code of practice for AI-generated content | Relevant to synthetic/deepfake labeling posture. |
| NCII takedown obligations | FTC — complying with the TAKE IT DOWN Act | Relevant if US access exists or US law becomes operationally relevant. |
| CSAM reporting context | NCMEC CyberTipline and 18 U.S.C. § 2258A | Required escalation path must be understood before public operation. |
| EU VAT / OSS | European Commission — VAT One Stop Shop | Digital membership sales may create VAT obligations. |
| Payment provider policy | Nocturne payment provider matrix | Official-source shortlist/avoid evidence and vendor approval questions before live checkout integration. |
| Discord community rules | Discord Community Guidelines | Needed if Discord becomes an optional member satellite. |
| Session/security baselines | OWASP Session Management, OWASP CSRF, OWASP Password Storage | Implementation guardrails for sessions, CSRF, and credential hashing. |