Status: research-only. This document does NOT constitute legal or tax advice. Before implementing any email-collection or session-persistence flow at demo.raxx.app, consult a privacy/data attorney licensed in the relevant jurisdictions. Last updated: 2026-04-29 UTC. Sources as of that date — verify freshness before shipping.
A one-time "magic link" sent transactionally (session-resume only, never marketing) is the lowest-overhead, most-defensible pattern for demo.raxx.app under CAN-SPAM, GDPR, CCPA/CPRA, and CASL, provided the email is deleted after link consumption or expiry and the UI copy is unambiguously non-promotional. The primary risk is misclassification: if any part of the email contains promotional copy, all four regimes treat it as marketing, which triggers consent and opt-out obligations Kristerpher explicitly wants to avoid. A licensed privacy attorney must review the final UI copy and data-flow diagram before launch.
Raxx is a pre-launch retail options-trading SaaS. demo.raxx.app offers an open, 30-minute ephemeral walkthrough (frozen historical SPX data, no live trading, no account required). The desired UX: a visitor who wants to continue past the 30-minute window, or resume from a different device, sees a prompt like:
"Want to continue your session? Enter your email and we'll send you a private resume link. We won't save your data or send you marketing. This link is only for resuming this demo."
The operator (Kristerpher) explicitly does not want a marketing list, does not want to manage identities via an identity provider, and wants minimal ongoing overhead.
Description. When the visitor requests session continuation, Raxx generates a one-time cryptographically signed token (e.g., a 128-bit CSPRNG value stored as a SHA-256 hash), associates it with the serialized demo session state, and emails a single link. The link is valid for a configurable TTL (e.g., 72 hours). On click, the server validates the hash, restores session state, and immediately marks the token as consumed. The raw email address is deleted from the server at the same moment — or at maximum within 24 hours of token consumption or expiry, whichever comes first. No marketing database. No identity record. No follow-up.
What Raxx stores and for how long. - Token hash (not the raw token): stored until consumed or TTL expires. Suggested TTL: 72 hours. - Session-state blob (frozen backtesting parameters, UI state): stored alongside the token; deleted on the same trigger as the token. - Email address: stored only long enough to dispatch the message (minutes at most if using a transactional ESP like Postmark, Mailgun, or Amazon SES). Deleted from the application database immediately after dispatch. The ESP's own retention of the sent-message log is governed by the ESP's DPA — Raxx must configure the ESP to minimize retention (Postmark: 45 days log default; Mailgun: 30 days; both configurable lower via retention settings). - IP address of the requester (for rate-limiting and abuse defense): logged at the application layer. Retain for 30 days maximum; document this in the privacy notice.
Transactional or marketing? Transactional under all four regimes, provided: 1. The email contains no promotional copy (no "try Raxx Pro," no pricing, no CTAs beyond the resume link). 2. The primary purpose is to deliver a service the visitor explicitly requested. 3. The UI copy at collection makes the purpose unambiguous.
Under CAN-SPAM 15 U.S.C. § 7702(17)(A): "facilitate, complete, or confirm a commercial transaction that the recipient has previously agreed to enter into" — or, in plainer terms, "deliver goods or services... that the recipient is entitled to receive." Resuming a requested session falls into this category. Source: https://www.law.cornell.edu/uscode/text/15/7702
Under GDPR Art. 6(1)(b): processing is lawful when "necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract." The visitor requests the link; sending it is processing "at the request of the data subject." Source: https://gdpr-info.eu/art-6-gdpr/
Under CASL s. 6(6): transactional messages "confirming, facilitating, or completing a commercial transaction that the recipient agreed to enter into" are exempt from consent. Source: https://crtc.gc.ca/eng/com500/faq500.htm. NOTE: CASL still requires sender identification and a functioning unsubscribe mechanism even for exempt messages — see Section 2 below.
Under CCPA/CPRA: email is "personal information." Collection still triggers notice-at-collection obligations regardless of whether the processing is transactional. Source: https://oag.ca.gov/privacy/ccpa
Required disclosures and UI copy patterns. At the point the email field is shown (before submission):
"Enter your email to receive a one-time session-resume link. We will send one email, then delete your address. We will not add you to any mailing list or send you marketing."
Privacy notice link must be visible on the same screen. The notice must state, per GDPR Art. 13 (https://gdpr-info.eu/art-13-gdpr/): - Identity and contact of data controller (Raxx / legal entity) - Purpose: session resume; lawful basis: performance of a service at your request (Art. 6(1)(b)) or legitimate interest (Art. 6(1)(f)) — attorney should confirm which is cleaner given the pre-contract nature of a demo - Retention: "Your email address is deleted within 24 hours of sending the resume link or upon link expiry." - Rights: erasure, access, objection - Right to lodge complaint with supervisory authority
The transactional email itself must include, per CASL s. 6(6) identification rules: - Raxx's legal business name - Physical mailing address (can be registered-agent address) - Phone, email, or web address for contact - An unsubscribe mechanism valid for 60 days (even though this is a one-time email, CASL requires it for any CEM sent to a Canadian address — see Section 2)
Operator overhead. Minimal. Requires: - One-time: implement token generation, session serialization, transactional email send, deletion trigger. ~1–2 sprints. - One-time: draft compliant email template and UI copy; have attorney review before ship. - Ongoing: monitor ESP bounce/complaint dashboard (15 min/week). No list management, no opt-out processing (there is no list). - Periodic: review ESP data-retention settings on contract renewal. ~1 hr/year.
Abuse vectors and defenses. - Email enumeration / rate abuse: attacker submits thousands of email addresses to probe validity or flood inboxes. Mitigation: strict rate-limiting by IP (e.g., 3 requests per IP per hour, 5 per day); CAPTCHA at the email-request step; per-email daily cap (1 link per address per 24h). Log requester IP (30-day retention, documented in privacy notice). - Token theft from inbox: attacker reads victim's email and clicks link. Mitigation: short TTL (72h max); bind token validation to original IP or user-agent (optional, degrades cross-device UX — flag for attorney/PM decision). Mark token single-use immediately on click. - Spam trap hits: submitting a known spam-trap address gets Raxx's sending domain flagged. Mitigation: use reputable transactional ESP with dedicated sending domain (not raxx.app marketing domain); do not retry bounced addresses.
Description. The visitor's session state is serialized, encrypted with a server-side key (or with a key the visitor holds in a cookie), and encoded into a long URL or a QR code. The visitor can bookmark the URL or copy it to resume from any device. No email is collected, stored, or transmitted by Raxx.
What Raxx stores and for how long. If server-side encryption: the session blob is stored server-side and the URL contains only a lookup key. Retention: same as session TTL (e.g., 72h). If client-side encryption: Raxx stores nothing — the URL is the state. No personal data.
Transactional or marketing? Not applicable — no email is sent.
Required disclosures and UI copy patterns. If no personal data is collected, GDPR Art. 13 obligations are minimal. Still need a privacy notice addressing IP/log data. CCPA still applies to IP addresses. If the URL contains no PII and is purely opaque, this is the cleanest pattern from a regulatory standpoint.
Operator overhead. Low once built. No deletion workflows, no ESP management, no list. Requires careful key rotation and URL-length management (long encrypted blobs create UX friction).
Abuse vectors and defenses. - URL sharing: a visitor shares their resume URL publicly, allowing others to load their session. Mitigation: session state in a free demo is low-stakes; consider binding the token to IP or requiring a browser fingerprint match. - State-blob tampering: if encryption is weak, an attacker could craft a modified state blob. Mitigation: authenticated encryption (AES-GCM) with server-side key. - Link loss: user closes browser without copying URL. Mitigation: show explicit "copy this link" step; poor UX but acceptable for a demo. Does not survive device loss unless user copies URL.
Description. On first visit, Raxx sets a persistent first-party cookie containing a pseudonymous session ID (UUID). The server stores session state keyed to that ID. The visitor can resume any time from the same browser. No email collected.
What Raxx stores and for how long. - Session ID cookie: persistent, set to expire with session TTL (e.g., 72h or 7 days for a longer demo window). - Session-state blob server-side: keyed to session ID; deleted on TTL expiry or explicit user "end session" action. - IP address in access logs: retain per normal log policy (30 days documented).
Transactional or marketing? Not applicable.
Required disclosures and UI copy patterns. Cookie consent banner required for EU visitors under the ePrivacy Directive (the "cookie law"). A persistent session cookie is arguably "strictly necessary" for a service the user is actively using, which exempts it from opt-in consent under ePrivacy — but this determination is jurisdiction-specific. UK ICO guidance says strictly-necessary cookies do not require consent. GDPR still requires disclosure in a privacy/cookie notice. Source: https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/lawful-basis/legitimate-interests/what-is-the-legitimate-interests-basis/
Operator overhead. Low. No email infrastructure, no deletion workflows beyond TTL enforcement.
Limitation. Does not survive browser-cache clear, incognito mode change, or cross-device use. A user visiting demo.raxx.app on their phone cannot resume a session started on desktop. This is the UX gap Kristerpher is trying to close.
Abuse vectors and defenses. - Cookie theft / session hijacking: standard web-security mitigations (HttpOnly, Secure, SameSite=Lax flags; short TTL; CSRF protection).
Description. Pattern C is the default. If the visitor explicitly wants to resume on a different device or after clearing cookies, they can opt into Pattern A (magic link). The email collection step is entirely optional and clearly labeled. The cookie path has zero email overhead. The magic-link path carries the transactional obligations from Pattern A.
What Raxx stores and for how long. Combines Pattern A and Pattern C as above, with email stored only on the opt-in path.
Transactional or marketing? Same as Pattern A for the email path; not applicable for the cookie path.
Required disclosures and UI copy patterns. Cookie notice for Pattern C path. Full Pattern A disclosures at the email-input step, shown only if the user initiates the cross-device flow.
Operator overhead. Slightly higher than Pattern C alone (need email infrastructure). Lower than Pattern A alone (most users never trigger the email path, so complaint/bounce volume is minimal).
Recommendation alignment. This is the pattern that best fits Kristerpher's stated constraints. See Section 3.
Description. The visitor submits an email; Raxx sends a 6-digit OTP (not a link). The visitor enters the OTP on the demo site. Upon successful verification, Raxx creates a session token (cookie), deletes the email address, and proceeds as Pattern C (cookie-bound). The email is truly one-time-use for identity assertion, never retained. No marketing capability built in.
What Raxx stores and for how long. - Hashed OTP + expiry: stored until consumed or TTL (10 minutes). - Email address: stored only during OTP validation window (10 minutes maximum), then deleted. - Session cookie: same as Pattern C.
Transactional or marketing? The OTP email is transactional; the session continues anonymously thereafter.
Operator overhead. Similar to Pattern A. Slightly better UX (OTP on same screen vs. link open in new tab) but requires OTP delivery infrastructure.
Abuse vectors and defenses. Same as Pattern A plus OTP brute-force: mitigate with 3-attempt lockout and exponential backoff.
Transactional vs. marketing. CAN-SPAM distinguishes "commercial electronic mail messages" (CEMs) from "transactional or relationship messages." A message is transactional if its primary purpose is to "facilitate, complete, or confirm a commercial transaction that the recipient has previously agreed to enter into" or to "deliver goods or services... that the recipient is entitled to receive." 15 U.S.C. § 7702(17)(A). Source: https://www.law.cornell.edu/uscode/text/15/7702. A CEM is a message whose primary purpose is "commercial advertisement or promotion." 15 U.S.C. § 7702(2)(A). CAN-SPAM's opt-out, labeling, and subject-line requirements do NOT apply to transactional messages, provided the message contains no false or misleading routing information.
Minimum disclosure at collection. CAN-SPAM does not itself require a disclosure at the email-collection UI step. That obligation comes from GDPR and CCPA for non-US visitors. However, the email itself must not contain false or misleading header information.
Deletion/retention rules. CAN-SPAM does not mandate deletion. State laws (California, Colorado, Virginia, etc.) and GDPR impose deletion obligations. See CCPA and GDPR sections below.
Penalty exposure for a small startup. The FTC may seek civil penalties of up to $43,280 per email in violation. Source: https://www.ecfr.gov/current/title-16/chapter-I/subchapter-C/part-316. Violations must be intentional for the per-email penalty structure to apply; good-faith transactional classification with documented rationale reduces exposure. State AGs may also act.
Double opt-in for marketing (if ever converting). If Raxx ever decides to send marketing to these addresses, it must first obtain affirmative opt-in. CAN-SPAM does not require double opt-in for marketing (single opt-in suffices), but CASL requires express consent, and GDPR requires freely given, specific, informed, unambiguous consent. A double opt-in workflow (user submits address, receives confirmation email, clicks to confirm) satisfies all three regimes simultaneously — recommended if marketing is ever added. Do not repurpose transactional-collected addresses for marketing without a separate consent flow.
Transactional vs. marketing. GDPR does not use the term "transactional email." The applicable concepts are lawful basis (Art. 6) and purpose limitation (Art. 5(1)(b)).
For a session-resume magic link: - Lawful basis: Art. 6(1)(b) — "necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract." The visitor requests the link; sending it is processing at their request. Alternatively, Art. 6(1)(f) — legitimate interest — may apply, but requires a Legitimate Interests Assessment (LIA). Art. 6(1)(b) is cleaner here because the user initiates the request. Source: https://gdpr-info.eu/art-6-gdpr/
For marketing email: requires explicit consent under Art. 6(1)(a) and the ePrivacy Directive (Directive 2002/58/EC Art. 13). The ePrivacy Directive currently overrides GDPR's legitimate-interest basis for electronic marketing — meaning marketing emails to EU recipients require consent regardless of whether a legitimate interest exists. Source: https://gdpr-info.eu/issues/email-marketing/
Minimum disclosure at collection (Art. 13). At or before the point of email collection, the controller must disclose: 1. Controller identity and contact details. 2. DPO contact (if a DPO is required — not required for startups under 250 employees unless processing is high-risk). 3. Purpose and lawful basis for processing. 4. Retention period or criteria for determining it. 5. Data subject rights: access, rectification, erasure, restriction, portability, objection. 6. Right to lodge complaint with supervisory authority. 7. Whether provision is voluntary or required, and consequences of non-provision. Source: https://gdpr-info.eu/art-13-gdpr/
A layered approach is acceptable: show a short notice at the form ("We'll send one email and delete your address within 24 hours — see our privacy policy") with a link to the full policy.
Data minimisation and storage limitation (Art. 5). Collect only what is necessary for the stated purpose (Art. 5(1)(c)). Store only as long as necessary for that purpose (Art. 5(1)(e)). For a session-resume email: the purpose expires when the link is consumed or the TTL lapses. Delete the email address at that point. Source: https://gdpr-info.eu/art-5-gdpr/
Deletion/retention rules. Art. 17 (right to erasure) applies. Visitors can request deletion. For Pattern A with 24h email deletion, by the time a deletion request arrives, the email address is already gone — making compliance trivially easy.
Penalty exposure. GDPR fines: up to 4% of global annual turnover or EUR 20 million, whichever is higher (Art. 83(5)). For a pre-revenue startup, 4% of EUR 0 is EUR 0 — but regulators also consider the nature, gravity, and duration of the infringement. A clear, documented, privacy-by-design approach (delete-on-use) is the strongest mitigation. The threshold for a formal GDPR investigation at the startup stage is typically a data breach, a complaint from a data subject, or a referral from a supervisory authority — not proactive audit.
Double opt-in for marketing. If Raxx ever converts these users to marketing, a separate consent flow is required. GDPR requires: freely given, specific, informed, unambiguous consent (Art. 7). Best practice: double opt-in (first click = intent, confirmation email = verification). The consent record must be stored with timestamp, IP, and form version. Do not re-use the transactional-collection email for marketing without explicit re-consent.
Applicability threshold. CCPA applies to for-profit businesses doing business in California that meet ANY of: - Annual gross revenue > $25M - Buy/sell/share personal information of 100,000+ California consumers or households/year - Derive 50%+ of annual revenue from selling/sharing personal information Source: https://oag.ca.gov/privacy/ccpa
Raxx is pre-launch and pre-revenue. It does not currently meet any threshold. However, the 100,000-consumer threshold is calculated across all personal information collected — including cookies, IP addresses, and email addresses. If demo.raxx.app reaches meaningful traffic from California, this threshold can be reached faster than expected. Pattern D (hybrid cookie + email) counts cookies against the threshold even if no email is collected. Per https://www.truevault.com/learn/how-to-calculcate-100000-consumers, any unique identifier (including a cookie ID) from a California resident counts. For a free public demo, plan to monitor traffic against this threshold.
Notice at collection. Even before the threshold is reached, best practice (and the basis for any future compliance) is to display a notice at collection specifying: categories of personal information collected, purpose, and whether the information is sold or shared. Source: https://cppa.ca.gov/faq.html. The 2026 CPRA regulations (effective 2026-01-01) sharpen these requirements — disclosures must be more prominent, retention periods must be stated. Source: https://www.clym.io/blog/ccpa-notice-requirements-update
Deletion rights. Consumers have a right to request deletion of personal information within 45 days of request (extendable by 45 more with notice). If Raxx deletes emails within 24h of link send (Pattern A), there is effectively nothing to delete by the time a request arrives. Source: https://oag.ca.gov/privacy/ccpa
Penalty exposure for a small startup. CCPA does not apply until thresholds are met. Once met: CPPA may impose fines of $2,500 per unintentional violation and $7,500 per intentional violation. There is no per-email penalty structure; violations are assessed per incident or per practice. Source: https://oag.ca.gov/privacy/ccpa. Pre-launch recommendation: build compliant defaults so no remediation is needed when thresholds are crossed.
Double opt-in for marketing. CCPA does not require double opt-in. It requires a "Do Not Sell or Share" right and opt-out of targeted advertising for sensitive information. If Raxx ever sends marketing, the email address is personal information that cannot be "sold or shared" without disclosure and opt-out opportunity. This is distinct from the question of opt-in consent for sending — CCPA governs data use, not email send permissions (CAN-SPAM and CASL govern sending permissions).
Transactional vs. marketing. CASL regulates "commercial electronic messages" (CEMs) — any electronic message where a purpose is to encourage participation in a commercial activity. CASL s. 6(6) exempts from the consent requirement messages that "facilitate, complete, or confirm a commercial transaction that the recipient agreed to enter into." A session-resume magic link sent at the explicit request of the visitor qualifies. Source: https://crtc.gc.ca/eng/com500/faq500.htm
Critical distinction from CAN-SPAM. Under CASL, a transactional-exempt message may contain NO promotional content whatsoever. CAN-SPAM allows a small incidental promotional section; CASL does not. Any "try Raxx Premium" copy in the magic-link email converts the message to a CEM requiring prior express consent. Source: https://www.mcinnescooper.com/publications/canadas-anti-spam-legislation-casl-10-faqs/
Minimum disclosure at collection. CASL does not impose a specific notice-at-collection requirement on the email-input UI. But GDPR-style transparency (stating purpose and use) is best practice and satisfies all regimes simultaneously.
Identification requirements for transactional messages. Even exempt transactional messages must include: - Sender's business name - Physical mailing address - Phone number, email address, or web address - A functioning unsubscribe mechanism, available for 60 days post-send Source: https://www.mcinnescooper.com/publications/canadas-anti-spam-legislation-casl-10-faqs/
This means the magic-link email must include an unsubscribe link even though it is a one-time transactional message. For a single-use link, the unsubscribe mechanism is functional but practically meaningless (there is no list to unsubscribe from). Implementation: include a footer link that resolves to a page stating "You have been removed from all future communications" — which is trivially true since no list exists. This is low overhead but must be implemented.
Deletion/retention rules. CASL does not mandate data deletion. PIPEDA (Canada's federal private-sector privacy law, S.C. 2000, c. 5) requires that personal information be retained only as long as necessary and disposed of securely. Principle 5 of Schedule 1 to PIPEDA. Apply same 24h deletion policy as for GDPR.
Penalty exposure. Maximum: CAD $1 million for individuals, CAD $10 million for organizations per violation. The CRTC has issued fines in the $200K–$1.1M range for established businesses sending bulk unsolicited email. A transactional-only pattern with documented rationale and proper identification/unsubscribe elements presents minimal enforcement risk. Source: https://www.mcinnescooper.com/publications/canadas-anti-spam-legislation-casl-10-faqs/
Double opt-in for marketing. CASL requires express consent before sending any CEM. Express consent = the recipient must affirmatively request or agree to receive messages. Double opt-in (click-to-confirm) is the gold standard and the only form of consent CASL will accept for future marketing (implied consent from demo usage has a limited window and is debated for this context). If Raxx ever sends marketing to Canadians, obtain fresh express consent in a separate flow, independent of the transactional magic-link collection.
Pattern D — Hybrid (Anonymous Cookie by Default, Email-Gated Magic Link for Cross-Device) is the best fit for Kristerpher's constraints.
The majority of demo visitors will use the cookie path and never trigger email collection, keeping operator overhead near zero and eliminating regulatory exposure for those sessions. Visitors who explicitly need cross-device continuation opt into the Pattern A magic-link flow, where the email is deleted within 24 hours of link send — making the "maintaining an email list" problem structurally impossible rather than just a policy choice. The transactional classification is clean across all four regimes because the visitor must actively request the link, there is no promotional content in the email, and the UI copy is unambiguous. The unsubscribe-footer requirement under CASL is a small one-time implementation cost. This pattern also future-proofs Kristerpher's stated aversion to marketing lists: the architecture does not accumulate addresses, so there is no list to manage or be tempted to use.
NOTE on attorney type. Matthew Crosby is engaged for IP matters (trademark, copyright). The questions below are primarily privacy/data-law questions under US state law, GDPR, and CASL. Matthew Crosby may or may not have this specialty. Before this feature ships, Raxx should engage a privacy attorney (ideally one with US multi-state privacy law experience and familiarity with GDPR and CASL). A technology/privacy attorney at a firm with Canadian counsel access would cover all four regimes. If Matthew Crosby does not practice in this area, ask him for a referral to a privacy-specialist colleague.
Questions for the privacy attorney (bring the data-flow diagram and draft UI copy to the meeting):
Does the session-resume magic link qualify as a "transactional or relationship message" under 15 U.S.C. § 7702(17)(A) given that no prior commercial transaction has occurred — the visitor is using a free demo, not a paid product? Specifically: does "facilitate, complete, or confirm a commercial transaction that the recipient has previously agreed to enter into" cover a demo session, or is a stronger Art. 6(1)(b) GDPR / CASL s. 6(6) framing safer? This is the single most important question before ship because if the classification is wrong, every email is a CEM requiring opt-in consent.
Is Art. 6(1)(b) GDPR ("steps at the request of the data subject prior to entering into a contract") or Art. 6(1)(f) ("legitimate interest") the correct lawful basis for the magic-link send, given that no contract has been entered and no commercial relationship exists at the time of the demo? Which basis requires less documentation overhead for a pre-revenue startup?
Does the CASL unsubscribe-mechanism requirement for transactional-exempt messages (s. 6(6)) create any practical compliance risk if the unsubscribe link resolves to a static "you're not on any list" page, or must it be a functional opt-out backed by a database entry?
At what traffic volume from California does CCPA/CPRA likely apply to demo.raxx.app, given that Pattern D sets a cookie for every visitor (each cookie = one unique identifier = one California consumer in the threshold calculation)? Does Raxx need a "Do Not Sell or Share" banner before reaching the threshold, or only after?
Is the 24-hour email-deletion policy sufficient to satisfy GDPR Art. 5(1)(e) storage limitation and PIPEDA Principle 5, or does the attorney recommend a tighter window (e.g., immediately post-dispatch) given that the ESP retains sent-message logs for up to 45 days? What language should the privacy notice use to accurately describe both the application-layer deletion and the ESP log-retention?
(If Matthew Crosby is the reviewing attorney) Does the IP assignment agreement already in place between Raxx and any contractors cover the code implementing the session-token and email-dispatch flow? Flag if any new contractors work on this feature — IP assignment for this specific module should be confirmed before launch.
| Pattern | No marketing list | Anti-spam / low complaint risk | Low operator overhead | Cross-device resume | Regulatory cleanness (all 4 regimes) |
|---|---|---|---|---|---|
| A: Magic Link (transactional-only) | Yes | Yes (transactional, no promotional content) | Partial (email infra required; low volume) | Yes | Yes — provided zero promotional content and CASL unsubscribe footer |
| B: Encrypted State URL | Yes | Yes (no email sent) | Yes (no email infra) | Partial (link must be manually copied) | Best (no personal data if URL-only) |
| C: Anonymous Cookie | Yes | Yes (no email sent) | Yes | No (same browser/device only) | Yes (cookie disclosure required) |
| D: Hybrid Cookie + Magic Link | Yes | Yes | Yes (cookie path; email path is low volume by design) | Yes | Yes — cookie path is cleanest; email path requires CASL footer + privacy notice |
| E: OTP Email + Cookie | Yes | Yes (transactional) | Partial (email infra; OTP delivery) | Partial (cookie after verification; cross-device requires re-verification) | Yes — same obligations as Pattern A |
Key: "Yes" = fully satisfies the constraint. "Partial" = satisfies with caveats described above.
The recommended pattern (D) achieves "Yes" across all five constraints with the smallest number of caveats. The only "Partial" in the email path is the one-time CASL footer requirement, which is a one-sprint implementation task.