Raxx · internal docs

internal · gated

Data Protection Impact Assessment — Trace Architecture

Raxx Workflow UUID Tracing System

Document version: 1.0.0 Date: 2026-05-12 UTC Owner: Kristerpher (data controller, DPO) Status: Draft — requires attorney review before finalisation GDPR Article 35 trigger: Systematic and large-scale processing of personal behavioral data Next review trigger: Any retention policy change; any new subsystem emitting trace events; annual review no later than 2027-05-12 UTC Related artifacts: - Design doc: docs/architecture/workflow-uuid-tracing.md (PR #498, commit 5cb40c3) - ADR-0003: GDPR by default - ADR-0021: Trace storage — Timescale vs Postgres - ADR-0022: Event log append-only hash chain - ADR-0023: Render ID granularity - Issue #502 (this card), parent epic #500 - Privacy policy: docs/legal/policies/privacy-policy-v1.md

Executive Summary (1 page — for attorney review)

Raxx is a SaaS algorithmic trading strategy platform. The trace architecture assigns every user workflow a persistent UUID and records a time-ordered stream of events: user actions, system actions, support-agent access, and rendered views. This data is stored in an append-only, hash-chained database and retained for up to 7 years for trade-affecting events.

What this assessment covers. The processing described in docs/architecture/workflow-uuid-tracing.md constitutes systematic recording of personal behavioral data tied to financial activity. GDPR Article 35 requires a DPIA before this processing begins at scale. This document fulfils that requirement.

Conclusion — Art. 35 trigger analysis. The processing meets two of the Art. 35(3) criteria and the EDPB's supplementary criteria:

  1. Systematic monitoring (Art. 35(3)(c)): every user action, page render, and support access is recorded continuously and automatically.
  2. Large-scale processing of sensitive behavioral data: financial behavioral sequences are not "special category" data under Art. 9, but their volume and sensitivity (they can support inference about a user's financial decisions) satisfy the EDPB's "large scale" and "vulnerability" guidelines.

A DPIA is therefore required before this processing begins in production.

Residual risk rating: MEDIUM. The architecture incorporates strong mitigations — append-only storage, hash chain integrity, pseudonymization on erasure, RBAC access control, support-access scoping to active tickets, and user-visible admin access logs. No Very High residual risks remain after mitigations are applied.

Supervisory authority consultation. Based on the Medium residual risk rating, prior consultation with a supervisory authority under Art. 36 is not required. However, the data controller should retain this document and make it available to a supervisory authority on request (Art. 35(9)).

Attorney review scope. This document describes the architecture accurately. It does not constitute legal advice. Matthew Crosby (IP counsel) is asked to review the executive summary and confirm: (1) the legal basis analysis in §4, (2) whether Art. 36 consultation is required given the financial-adjacent context, and (3) whether the retention periods in §6 align with applicable financial record-keeping requirements.

1. Description of Processing

1.1 Controller and Processor

Role Entity
Data controller Raxx (operator: Kristerpher)
Data processors Heroku (Salesforce) — database hosting; AWS — cold-tier S3 storage; Sentry — error monitoring
DPO Kristerpher (product owner, pre-appointment of dedicated DPO)

1.2 What the Trace Architecture Does

The trace system assigns every user workflow in Raxx a UUID and records a time-ordered, append-only event stream covering:

1.3 Subsystems That Emit Events

Subsystem Events emitted Codename
Frontend session layer act_*, wfl_* (client-minted, server-countersigned for sensitive flows) Antlers
API middleware rnd_* on every authenticated API response Raptor
Order router sys_* with action_type: order.* Raptor / MQ-A
Paper-gate evaluator sys_* with action_type: gate.* MQ-A
Support tool (Console) sup_* on agent access; rnd_* for support-rendered views Console
Admin replay API rnd_* on every admin query Raptor

1.4 Volume Estimate

At MVP launch (1,000 active users), estimated 250,000 events/day (50 events per session × 5 sessions/day/user). At 10,000 users: 2.5 million events/day. Hot tier (30 days) peak: ~75 million rows at 1,000 users; ~750 million rows at 10,000 users. Cold tier (S3) accumulates over 7 years. Volume qualifies as "large scale" under EDPB WP248.

1.5 Technology Stack

2. Necessity and Proportionality

2.1 Purpose Specification

Purpose Justification Data minimised to
Security monitoring and fraud detection Detect bad actors, anomalous session patterns, account compromise Action type, session/user ID, IP prefix, timestamp
Dispute resolution and non-repudiation Cryptographic evidence for disputed trades; FINRA-adjacent recordkeeping posture Trade-affecting events with hash-chain integrity
Support transparency Enable support agents to reconstruct user sessions; give users visibility into who accessed their data Actor ID, action type, timestamp; PII fields masked per RBAC
Platform debugging Reconstruct error states without relying on user recall Action type, view name, surface tag
User self-audit Users see their own workflow history; trust feature User-scoped view only, no internal detail

2.2 Proportionality

Behavioral event sequences are retained for 7 years for trade-affecting events. This period is driven by financial-adjacent regulatory norms (ADR-0003: aligns with FINRA Rule 17a-4 and brokerage norms). For render events and non-trade events, retention is 2 years cold (render) or 7 years cold (user-action, support-action). The retention periods are the minimum necessary for each purpose:

Data minimisation controls: email addresses, raw passkey credential IDs, broker API keys, full IP addresses, and request body content are never stored in trace events (design §11; ADR-0003 redaction rules).

3. Data Inventory

3.1 Categories of Data Subjects

Category Description
Registered users All Raxx account holders who use the platform
Support agents Raxx team members accessing the support tool (internal)
Admins Raxx platform admins (operator) accessing the admin replay API

3.2 Categories of Personal Data

Data Type Sensitivity Example value stored
user_id Internal UUID Pseudonym (resolves to identity in users table) usr_01HZ...
actor_id Internal UUID Pseudonym usr_01HZ... or sup_01HZ...
actor_role RBAC role string Non-PII raptor-trace-support
action_type Behavioral Behavioral metadata trade.submit, backtest.run
view_name Behavioral Low trade-entry-view
surface_tag Classification Non-PII ai, deterministic
context_json Sanitized context Low (no credentials, no raw PII) {"symbol": "SPY", "quantity": 10}
ts_emitted Timestamp Metadata 2026-05-12T14:30:00Z
IP prefix Derived from IP Low (not full IP) 203.0.113.0/24
data_mask_json Render state Non-PII {"broker_account_id": "masked"}

Special categories (Art. 9): None directly. The system does not collect health, biometric, political, religious, sexual, or racial data. Financial behavioral sequences are not Art. 9 data but may enable inference about financial circumstances; this is addressed in the risk register (§7).

3.3 Cross-Border Transfers

All data is stored on Heroku (Salesforce) infrastructure in the United States. Cold-tier data flows to AWS S3 (US). Transfer mechanism: Standard Contractual Clauses (SCCs) — Heroku DPA and AWS DPA. Transfer safeguards are documented in the privacy policy §4 and the ROPA (docs/architecture/gdpr-ropa.md, to be filed under issue #1687).

4. Lawful Basis

4.1 Primary Basis

Processing activity Lawful basis Proportionality argument
Recording user actions and system actions for security monitoring and fraud detection Art. 6(1)(f) — legitimate interests Raxx has a legitimate interest in detecting fraud and security incidents; this interest overrides the data subject's interests given the financial nature of the platform and the low intrusiveness of the data (no special categories; behavioral metadata only). Balancing test: users benefit from fraud detection; data is not used for any purpose beyond those specified.
Recording trade-affecting events for dispute resolution and non-repudiation Art. 6(1)(f) — legitimate interests Dispute resolution is a legitimate interest; the data subjects have a corresponding interest in being able to prove their own actions in a disputed trade. The processing is proportionate: only trade-affecting events are retained for 7 years; other events are retained for shorter periods.
Recording render events for support transparency and self-audit Art. 6(1)(b) — contract performance + Art. 6(1)(f) Support access to user sessions is necessary for contract performance (delivering the service). User-visible admin-access events are a privacy-enhancing feature that serves both the contract and the data subjects' rights.
Retaining support-action events for accountability Art. 6(1)(f) — legitimate interests Raxx has a legitimate interest in accountability for staff access to customer data; this directly benefits the data subject (they can see who accessed their account).

Art. 9 engagement: Not applicable. No special-category data is processed.

4.2 Legitimate Interests Assessment (LIA) Summary

The processing is necessary for the purposes listed above and cannot reasonably be achieved with less data or shorter retention periods for trade-affecting events. The data subjects have a reasonable expectation that a trading platform will log their trading activity (this is standard industry practice for financial services). The LIA outcome: legitimate interests prevail.

Full LIA documentation: to be filed at docs/legal/artifacts/lia-trace-architecture.md (see open question §9.1).

5. Data Subject Rights Analysis (Arts. 12–22)

Right Art. Mechanism SLA Trace-specific note
Transparency 13/14 Privacy policy §2–§5; user-visible trace timeline at GET /api/me/trace At signup; updated on material change Users are informed that their actions are traced via the privacy policy and the self-audit surface (SC-8)
Access 15 POST /api/gdpr/export bundle (ADR-0003); also GET /api/me/trace for live self-service 24h target (30-day max) The export bundle includes trace event data in machine-readable JSON
Rectification 16 Trace events are append-only; corrections are superseding events (ADR-0022). A user cannot alter past events, but they can dispute an event via the DSR process and a correcting event is appended. Case-by-case The append-only constraint is disclosed; ADR-0022 explains the corrective event model
Erasure 17 POST /api/gdpr/erase — step-up verified; triggers pseudonymization of user_id and actor_id in trace events within 30 days. Hash chain is preserved over pseudonymized data (the chain is still valid). Pseudonymization salt destroyed at end of 2-year audit retention. 30 days Trade-affecting events are retained in pseudonymized form for 7 years to satisfy financial recordkeeping obligations; the erasure request is honored to the maximum extent possible given legal retention obligations (ADR-0003 §Erasure semantics). This exception is disclosed in the privacy policy §5.
Restriction 18 Account freeze (admin action); user can request via support@raxx.app. Processing restriction suspends query APIs but does not delete stored events. Case-by-case —
Portability 20 Same JSON export bundle as access (Art. 15). Trace event data is included in machine-readable JSON format. 24h target Applies where basis is Art. 6(1)(b); for Art. 6(1)(f) events portability is not mandatory but provided anyway for user convenience
Objection 21 User may object to legitimate-interest-based processing. Raxx will conduct a case-by-case review; if the user's objection overrides the LIA, trace events not required for legal retention will be pseudonymized. 30 days Objection to security-monitoring processing is treated as equivalent to an erasure request for non-retained data
Not subject to automated decision 22 Trace data is not used for automated individual decision-making or profiling that produces legal or similarly significant effects. Anomaly detection generates alerts to human reviewers, not automated account actions. N/A If this changes, DPIA update and Art. 22 assessment required before ship

6. Retention Policy

Per docs/architecture/workflow-uuid-tracing.md §4.2 and ADR-0003:

Data Hot tier Cold tier Deletion / pseudonymization
Render events (rnd_*) 30 days 2 years Pseudonymized on DSR erasure; deleted at 2-year ceiling
User-action events (act_*) 30 days 7 years Pseudonymized on DSR erasure; retained in pseudonymized form for 7 years
System-action events (sys_*) 30 days 7 years Retained (no PII in system events after credential-exclusion schema invariant)
Support-action events (sup_*) 30 days 7 years Pseudonymized on DSR erasure (support_agent_id + target_user_id)
Workflow metadata 30 days 7 years Pseudonymized on DSR erasure

Change-trigger clause: any change to the above retention periods requires a DPIA update before the change ships. The DPIA version is incremented and the change is noted in the version history.

7. Risk Register

# Risk Likelihood (pre-mitigation) Impact (pre-mitigation) Inherent rating Mitigations Residual rating
R1 Data breach — trace database exfiltration. Attacker exfiltrates trace_events table, obtaining behavioral sequences tied to user IDs. No credentials are in the table, but behavioral fingerprints + user IDs constitute personal data. Medium High High (1) No credentials in schema (CI grep enforced). (2) Append-only DB grants — no UPDATE/DELETE. (3) RBAC access control on query APIs. (4) TLS-only data in transit. (5) Encryption at rest on Heroku Postgres. (6) Breach notification pipeline per ADR-0003 (72-hour Art. 33 clock). Medium
R2 Insider access — support agent queries user data without active ticket. Support agent with raptor-trace-support role queries users outside their active support scope. Low Medium Medium (1) Support access scoped to active ticket (Q4 decision, design §14). (2) Every support access generates a sup_* event visible to the user. (3) Admin access also generates rnd_* events visible to user. (4) Anomaly detection on trace_events can flag unusual agent query patterns. Low
R3 Ed25519 key exfiltration — forged system-action events. Attacker exfiltrates a subsystem signing key from Infisical and inserts fabricated sys_* events (e.g., falsely recording a paper-gate pass for a live trade). Low Very High High (1) Signing keys in Infisical, not in code or config files. (2) Key rotation procedure without redeploy (design §11). (3) sig_key_version stored alongside each signed event; revoked key renders prior events verifiable but new forgeries detectable. (4) Hash chain — inserted event without correct hash_prev breaks chain verification. (5) Nightly integrity checker alerts on chain breaks. Medium
R4 Scope creep — PII fields added to context_json. Developer adds email address or passkey credential ID to context_json violating schema invariant. Data appears in trace without DPIA coverage. Medium High High (1) CI grep on migration files for credential field names. (2) Schema invariant documented in design §11 and code review checklist. (3) context_json sanitization function (to be implemented in SC-2) strips known-PII field names at write time. Low
R5 Retention policy drift — events retained beyond declared periods. Nightly retention job fails silently; events accumulate beyond declared retention ceilings. Medium Medium Medium (1) Nightly retention job writes a summary audit_log row; absence of the row is alertable. (2) Timescale tiered-storage policy enforces chunk expiry independently of the job. (3) DPIA change-trigger clause: any retention change requires DPIA update. Low
R6 Cross-user query — admin replay API returns wrong user's data. Authorization bug in GET /api/admin/trace/replay/<user_id> allows querying a different user's events. Low High Medium (1) raptor-trace-admin RBAC role required; RBAC is centralized in Queue (design + RBAC-V2 ADR). (2) Response always includes user_id field; mismatched user_id in response is testable. (3) Every admin query generates an rnd_* event linking actor_id to the queried user_id — misuse is auditable. Low
R7 Render event volume — support tool replay exposes more context than intended. The "what did user see" toggle in the support replay UI inadvertently surfaces internal fields not intended for the user's view. Medium Medium Medium (1) data_mask_json field explicitly records which fields were masked at render time (design §3.4). (2) Support view uses a separate role-gated serializer. (3) "What user sees" toggle re-filters through antlers-trace-self role serializer, not the support-role serializer. Low
R8 Pseudonymization salt loss — erasure becomes irreversible prematurely. Per-user pseudonymization salt stored in encrypted form; if the encryption key is lost before the 2-year retention ends, the pseudonym cannot be reversed even if needed (e.g., for a law enforcement order). Low Medium Low (1) Salt encryption key managed in Infisical with separate access control. (2) Salt backup procedure documented in ops runbook. (3) This risk is symmetric: losing the salt also means the pseudonym is irrecoverable, which is the desired GDPR outcome after 2 years. Low
R9 Supervisory authority inquiry — DPIA not available. Supervisory authority requests DPIA under Art. 35(9); Raxx cannot produce it. Low High Medium (1) This document is the mitigation. Filed under issue #502, linked to design PR #498. Retained in docs/legal/dpia/. Low
R10 Support agent identity spoofing — fabricated sup_* events. Attacker with a compromised support account generates sup_* events to cover their tracks or frame a legitimate agent. Low High Medium (1) sup_* events require raptor-trace-support RBAC role — compromised account must have this role. (2) Events are append-only; the attacker cannot remove their own real sup_* events. (3) All support access is visible to the user in their timeline, creating a detection surface. (4) Incident response runbook: RBAC role revocation immediately terminates access. Low

7.1 Overall Residual Risk Rating

All risks are rated Low or Medium after mitigations. No Very High residual risks. Overall: MEDIUM.

8. Security Considerations

8.1 Technical Measures

Measure Implementation Status
Append-only database grants raptor_app DB user: INSERT + SELECT only on trace tables. CI lint rejects GRANT UPDATE/DELETE on trace tables. Required — must be in place at first data.
Hash chain integrity SHA-256 hash_prev chain per workflow; nightly integrity checker (SC-6) Recommended pre-MVP; required by GA.
Ed25519 subsystem signing Signing keys in Infisical; sys_* events carry sig + sig_key_version Optional at MVP; required post-launch (SC-12).
Pseudonymization on erasure user_id + actor_id replaced with sha256(id || per-user-salt); salt destroyed at end of 2-year audit retention Required — must be in place when erasure is enabled.
Credential exclusion at schema level No email, passkey IDs, broker keys, full IPs in trace schema. CI grep on migration files. Required — enforced from day 1.
RBAC on trace query APIs antlers-trace-self, raptor-trace-support, raptor-trace-admin roles. Support scoped to active ticket. Required — must be in place before support tool access.
TLS in transit + encryption at rest Heroku Postgres (encrypted at rest); TLS-only API. Required.
Kill-switch TRACE_ENABLED=0 disables all event emission without data loss. Required (invariant §2.8 of design doc).

8.2 Organisational Measures

9. Supervisory Authority Consultation (Art. 36)

Required: No.

Rationale: The overall residual risk rating is Medium. Art. 36 prior consultation is required only where the DPIA indicates that processing would result in a high risk in the absence of measures taken to mitigate it. No individual risk in the register remains at High or Very High after mitigations. The existing technical and organisational measures are sufficient.

However, the following conditions would elevate this assessment and require re-evaluation for Art. 36 consultation:

  1. The trace system begins processing Art. 9 special-category data.
  2. Raxx becomes a registered broker-dealer or investment adviser subject to SEC/FINRA oversight, which may trigger a different legal basis analysis.
  3. Volume exceeds 10 million behavioral events per day (approaching "very large scale" thresholds in EDPB guidance WP248 rev.01).
  4. Raxx begins operating automated risk-scoring or profiling using trace data.

The data controller should retain this document and make it available to any supervisory authority on request (Art. 35(9)).

10. Open Questions

The following items require resolution before this DPIA is finalised. They are not blockers for filing the DPIA, but they must be answered before GA.

10.1 Legitimate Interests Assessment (LIA) formal document

A full written LIA is referenced in §4.2 but has not yet been produced. The LIA documents the three-part test (purpose, necessity, balancing) in detail. This should be filed at docs/legal/artifacts/lia-trace-architecture.md. Tracked under issue #502.

10.2 EU Art. 27 Representative designation

The privacy policy (§1) flags that an EU/EEA representative has not yet been designated (tracked: issue #1648). Until designation is complete, the data controller should avoid actively marketing to EU users. This does not block the DPIA, but it must be resolved before Raxx accepts EU customers at scale.

10.3 Vendor DPAs

The following vendor DPAs are referenced but not confirmed executed: Heroku (Salesforce), AWS, and Sentry. Standard Contractual Clauses (SCCs) are listed as the transfer mechanism; DPA execution status should be confirmed and documented in the ROPA before GA.

10.4 ROPA entry for trace architecture

The Records of Processing Activities (docs/architecture/gdpr-ropa.md, tracked: issue #1687) should include a dedicated entry for the trace architecture covering the fields required by Art. 30. This DPIA cross-references the ROPA but does not duplicate it.

10.5 Attorney sign-off on retention periods

The 7-year retention for trade-affecting events is based on FINRA-adjacent norms and is not specific legal advice. Matthew Crosby should confirm whether this period is appropriate given Raxx's current regulatory status (not a registered broker-dealer) and jurisdiction.

11. Version History

Version Date (UTC) Author Change
1.0.0 2026-05-12 software-architect (Raxx) Initial DPIA scoping document, all sections drafted. Awaiting attorney review.

This document is a human-to-human deliverable. Per project convention (feedback_human_to_human_drive.md), it must also be uploaded to Google Drive before the GA milestone for attorney meeting access. Attorney contact: Matthew Crosby (IP counsel, engaged — see reference_attorneys.md).

This document does not constitute legal advice. Attorney review of the executive summary and §4 (lawful basis) and §9 (Art. 36 consultation determination) is required before this DPIA is considered finalised.