DPIA / DSFA Screening — Core Product

1. Purpose and relationship to existing documents

docs/compliance/dsgvo-data-flow.md §8 already states a conclusion: Phase A requires no Data Protection Impact Assessment (DPIA / DSFA) because there is no systematic profiling, no Art. 9 sensitive-category data, and no automated decision-making. This document does not restate that conclusion — it formalizes the reasoning behind it into a documented Art. 35(3) threshold screening, which is what a DPIA screening record actually needs to survive scrutiny: not just a one-line "not required," but a criterion-by-criterion walk-through of why each trigger doesn't apply today, plus an explicit condition under which the determination expires.

This is a screening record, not a DPIA. If any criterion below flips to "applies," a full DPIA under Art. 35(7) becomes the deliverable, not this document.

2. Legal basis for screening

GDPR Art. 35(1) requires a DPIA where processing is "likely to result in a high risk to the rights and freedoms of natural persons," and Art. 35(3) lists three cases that automatically trigger the requirement. revDSG Art. 22 imposes the equivalent Swiss obligation (Datenschutz-Folgenabschätzung) under a comparable high-risk threshold. Both regimes require the controller to actually assess — not assume — whether the threshold is met; this document is that assessment for Stratify's current (Phase A) processing.

3. Art. 35(3) criteria, applied one by one

(a) Systematic and extensive evaluation of personal aspects, based on automated processing, including profiling, producing legal effects or similarly significantly affecting the data subject

Does not apply today. Signals are 1:N editorial content: a pilot publishes a signal for a strategy mandate (publishSignalAction → publishSignal(), docs/compliance/dsgvo-data-flow.md §4), and it is delivered identically to every subscriber of that mandate via signal_deliveries. There is no per-subscriber scoring, no profile-driven selection of *which* signal a given subscriber sees, and no automated evaluation of a subscriber's personal characteristics that feeds back into what they receive. The subscriber's only personalized input is a self-selected mandate (user_active_mandate) — an explicit, one-time choice, not a system-generated evaluation of the person.

This is also the exact line the business itself is regulated against: regulatory-roadmap-ch-eea.md identifies "personalization" (a signal presented as suitable *for you*, rather than for a mandate) as the threshold that converts research/Tippgeber activity into investment advice under both FIDLEG Art. 3 and MiFID II Art. 4(1)(4). The same fact — no personalization exists yet — is what keeps this criterion from applying and what keeps Stratify in its unlicensed Stufe 0 / E0 posture. The two determinations are not a coincidence; they rest on the same underlying product fact.

(b) Large-scale processing of special categories of data (Art. 9) or data relating to criminal convictions/offences (Art. 10)

Does not apply today. The data categories Stratify processes are enumerated in dsgvo-data-flow.md §2: account/email data, mandate selection, subscription status, push tokens, waitlist entries, referral attribution, signal-delivery and audit logs. None of these are Art. 9 special categories (health, biometric, political opinion, religious belief, sexual orientation, etc.) or Art. 10 criminal-offence data. Partner-user applications (partner_users) capture legal name and applicant name — ordinary identifying data, not a special category.

Note for forward planning: KYC data (Phase C) is not automatically Art. 9 data, but KYC processes commonly touch adjacent fields (government ID images, sometimes nationality) that warrant a fresh look at this criterion when KYC design work starts — see §5.

(c) Systematic monitoring of a publicly accessible area on a large scale

Does not apply. Stratify has no physical or public-space monitoring component of any kind — this criterion is inapplicable to the product by construction, not by a judgment call, and is not expected to become relevant at any planned phase.

4. Supplementary check — WP248 (EDPB) indicative criteria

The three Art. 35(3) criteria above are the automatic triggers; EDPB guidance (WP248 rev.01) adds nine broader indicative criteria used to catch high-risk processing that doesn't hit an automatic trigger but meets two or more of the nine. Applied briefly for completeness:

evaluation/scoring — no; automated decision with legal/similar effect — no; systematic monitoring — no; sensitive data — no; large-scale processing — signal-delivery and audit-log volumes are non-trivial but not sensitive-category, so this alone doesn't combine into a trigger; matching/combining datasets — no cross-dataset matching beyond a subscriber's own account rows; vulnerable data subjects — no market limitation to vulnerable groups; innovative use of technology — no (standard CRUD + email/push delivery); prevention of the exercise of a right or use of a service — no. Fewer than two criteria are met, consistent with the Art. 35(3) conclusion above.

5. Determination

No DPIA is required for Phase A processing, on the basis of the criterion-by-criterion review in §3–4. This matches and formalizes dsgvo-data-flow.md §8's existing conclusion.

6. Re-evaluation trigger — Phase C, not a one-time filing

This determination is not a document to file away. regulatory-roadmap-ch-eea.md's own "Empfohlene Sequenz" table names the trigger for Stratify's next regulatory rung as "personalisierte Empfehlungen geplant" — the same event README.md:33-36 and dsgvo-data-flow.md §8 tie to Phase C: the suitability engine (profile-driven personalized recommendations), KYC, and Stripe Connect pilot-payouts landing on the same backend.

When that happens, criterion (a) above is likely to flip from "does not apply" to "applies":

• A suitability engine is, by definition, a **systematic evaluation of personal aspects using

automated processing to select or rank recommendations for an individual — the textbook shape of Art. 35(3)(a). It is also, per the regulatory roadmap's own Stufe-1 threshold, the same fact pattern that converts the product from unlicensed research into regulated investment advice (FIDLEG Art. 3 / MiFID II Art. 4(1)(4)). A product change that crosses into "advice" under the regulatory roadmap is very likely to simultaneously cross into "DPIA required" under Art. 35(3)(a)** — these are not independent questions, and a Phase C go/no-go on the suitability engine should treat the DPIA as a co-requirement of the licensing step, not a follow-up task.

• KYC introduces identity-verification data that warrants a fresh Art. 9/10 check (criterion (b)),

even if it doesn't automatically qualify as special-category data — see the note in §3(b).

• Stripe Connect payouts introduce a new financial-data flow (payout destination, KYB/KYC linkage)

that should be re-assessed for scale and sensitivity alongside the above, even though payment card/IBAN data itself continues to sit with Stripe (dsgvo-data-flow.md §2).

Action on trigger: re-run this screening in full (§3–4) at the point the suitability engine's design is fixed enough to describe concretely — not after it ships. If §3(a) comes back "applies," the next deliverable is a full Art. 35(7) DPIA (necessity/proportionality assessment, risk assessment to data subjects, mitigating measures), not an updated version of this screening.

7. Sign-off

8. Review

Reviewed annually alongside the other Tier 3 privacy documents, and immediately — out of cycle — the moment suitability-engine, KYC, or Stripe Connect design work begins, per §6.