Records of Processing Activities — Processor Role

Satisfies GDPR Art. 30(2), which requires a processor to maintain its own record of processing carried out on a controller's behalf. This document is the deliberately honest counterpart to PRIV-01: it asks whether Stratify, in its B2B/partner integrations (REST/webhook/MCP distribution to neobroker partners, register/facts.md "Product"), currently processes a partner's own end-customer personal data *on that partner's instructions* — the defining feature of Art. 30(2) processor-role activity — and finds that it largely does not, today.

The determination

Stratify's B2B surface has two real, code-backed data flows (dsgvo-data-flow.md §1–2, §4; register/facts.md):

1. Outbound signal distribution — drain-webhooks pushes Stratify's own research-signal

content to a partner's HTTPS webhook endpoint (HMAC-SHA256-signed). This is Stratify acting as controller of the signal content: Stratify determines the purpose (research distribution) and the means (what gets sent, on what schedule, in what format). The partner is the recipient, not the instructing party, and no personal data belonging to the partner's own customers flows into Stratify in this direction.

1. `partner_users` and `partner_api_keys` — these tables hold data about the partner

organization's own applicant/API-credential relationship with Stratify. As covered in PRIV-01 row 6, this is Stratify processing that data as controller of its own onboarding and API-key security process, not on the partner's instructions.

1. `api_request_log` — rate-limiting metadata (24h rolling, dsgvo-data-flow.md §2) captures

the partner's own API call patterns for Stratify's operational security purposes. Same controller-role analysis as #2.

No processing activity today meets the Art. 30(2) definition — Stratify does not currently ingest, store, or act on a partner's end-customer personal data under that partner's instructions. This category is genuinely thin, not padded to look complete: the table below is intentionally near-empty, and that emptiness is the finding, not an omission.

RoPA — processor-role activities (currently: none in force)

What would flip this determination

The category is thin because of product stage, not product design — the architecture (partner REST/webhook/MCP API) is exactly the shape that would carry processor-role data once any of the following becomes real:

• A partner requires Stratify to ingest and act on its own customer list (e.g., to personalize

signal routing per the partner's end-customer, rather than per Stratify's own subscriber account).

• Phase C's Stripe Connect pilot-payout flow or MiFID-II suitability engine (README.md Phase C)

begins processing a partner's or intermediary's end-customer financial data on that party's instructions rather than Stratify's own.

• Any future institutional-partner integration where Stratify's role is explicitly "vendor

processing the partner's data" in the partner's own DPA, rather than "controller distributing its own research."

When any of these ships, this document gets its first real row, a matching entry in register/suppliers.yaml's inverse (a controller register, if needed), and a DPA signed in the *other* direction from PRIV-05 (Stratify as the processor signing a partner's paper, not offering its own).

Review

Reviewed at every B2B/partner feature addition, and at minimum on the same cadence as PRIV-01. Owner: DPO / Privacy Owner (Antonios). The determination above should be re-run, not assumed still valid, at each review.