Billing — Customer Scoring Ethics + Tier Downgrade Data Handling

Status: research-only. This document does NOT constitute legal or tax advice. Before filing, acting, or making any architectural or business decision based on this research, consult a privacy attorney licensed in relevant jurisdictions (US-federal, California, and EU), and separately a CPA for any tax-retention implications. Last updated: 2026-05-11 UTC. Sources as of that date — verify freshness. Related epic: https://github.com/raxx-app/TradeMasterAPI/issues/403 Related PR: https://github.com/raxx-app/TradeMasterAPI/pull/1604

TL;DR (3 sentences)

Storing raw payment-event counts (late payments, chargebacks, failed charges) as operator-visible internal data carries low FCRA risk and low ECOA risk because Raxx is not a creditor and the data never leaves Raxx — but the moment any such count programmatically triggers a pricing, access, or tier-eligibility decision for California-resident users it activates CPRA ADMT opt-out obligations (effective 2026-2027) and potentially GDPR Article 22 if it "similarly significantly affects" an EU user. Downgraded users have GDPR Article 20 portability rights and CCPA right-to-access rights that survive subscription cancellation, and the "read-only with history, no upgrade CTA" pattern the architect proposed is the safest compliant path because it preserves access without locking or deleting. The single highest-risk architectural decision is adding a computed numeric trust score that drives automated tier or pricing decisions — that crosses the GDPR Art. 22 / CPRA ADMT line; raw counts displayed to operators do not.

Part 1 — Customer Narrative Score / Payment Reliability Profile

1.1 FCRA Analysis

Question: Does storing a "payment reliability" score or raw payment-event counts trigger FCRA consumer reporting agency obligations?

Primary statute: Fair Credit Reporting Act, 15 U.S.C. §§ 1681 et seq.

Key definitions (exact statutory language, LII Cornell, 15 U.S.C. § 1681a):

• "Consumer reporting agency" (§ 1681a(f)): "any person which, for monetary fees, dues, or on a cooperative nonprofit basis, regularly engages in whole or in part in the practice of assembling or evaluating consumer credit information or other information on consumers for the purpose of furnishing consumer reports to third parties." (Emphasis added.)

• "Consumer report" (§ 1681a(d)(1)): "any written, oral, or other communication of any information by a consumer reporting agency bearing on a consumer's credit worthiness, credit standing, credit capacity, character, general reputation, personal characteristics, or mode of living."

• "Transactions or experiences" exclusion (§ 1681a(d)(2)(A)(i)): The term "consumer report" does NOT include "any report containing information solely as to transactions or experiences between the consumer and the person making the report."

Research finding for Raxx:

Raxx is almost certainly not a "consumer reporting agency" under the FCRA for this use case because:

1. The FCRA definition requires furnishing consumer reports to third parties. Raxx's internal payment-event counts are used by Raxx operators only — they are not furnished to any third party.
2. Even if data were communicated internally, the § 1681a(d)(2)(A)(i) "transactions or experiences" exclusion covers exactly what Raxx is recording: Raxx's own payment experience with its own customers. A chargeback, a failed charge, a late payment — these are all transactions between Raxx and the customer. They are structurally excluded from the "consumer report" definition.
3. The CRA definition additionally requires "assembling or evaluating consumer credit information for the purpose of furnishing to third parties." Raxx does neither.

FCRA risk level: LOW — as long as the data stays internal and is not sold, licensed, shared, or otherwise furnished to third parties (lenders, landlords, other SaaS providers, etc.).

Caveat for attorney confirmation: If Raxx ever builds a feature that exports customer payment profiles to third-party partners, that export would need a FCRA compliance analysis before launch. Flag to privacy attorney.

Sources: - https://www.law.cornell.edu/uscode/text/15/1681a (15 U.S.C. § 1681a — definitions) - https://www.ftc.gov/legal-library/browse/statutes/fair-credit-reporting-act (FTC full-text) - https://www.govinfo.gov/content/pkg/USCODE-2011-title15/html/USCODE-2011-title15-chap41-subchapIII.htm

1.2 ECOA / Regulation B Analysis

Question: If Raxx uses a payment reliability score to affect pricing, tier eligibility, or service terms, is that "adverse action" requiring ECOA notice? Does ECOA's anti-discrimination prohibition apply?

Primary statute: Equal Credit Opportunity Act, 15 U.S.C. §§ 1691 et seq.; Regulation B, 12 C.F.R. Part 1002.

Key definition (exact regulatory language, 12 C.F.R. § 1002.2):

• "Credit": "the right granted by a creditor to an applicant to defer payment of a debt, incur debt and defer its payment, or purchase property or services and defer payment therefor."
• "Creditor": "a person who, in the ordinary course of business, regularly participates in a credit decision, including setting the terms of the credit."

Research finding for Raxx:

ECOA and Regulation B apply specifically to credit transactions — arrangements involving deferred payment, incurrence of debt, or payment deferral. A SaaS subscription billed monthly (charged at time of billing, no deferral) is not a credit transaction and Raxx is not a creditor under the ECOA definition. Accordingly:

• Raxx charging different prices to different customer segments based on an internal reliability metric is not an "adverse action" under ECOA — no credit is being extended.
• ECOA's prohibited bases for discrimination (race, sex, religion, marital status, national origin, etc.) do not apply to non-credit service-tier pricing decisions.
• The CFPB's ECOA/Reg B enforcement scope explicitly covers credit products; it has not extended to SaaS access-tier decisions.

Important carve-out: If Raxx ever offers a deferred payment plan, a subscription-on-credit product, "pay later after your first trade," or any product where the customer owes money after service delivery, ECOA analysis becomes live. Flag to attorney before any such product feature ships.

Anti-discrimination laws that DO apply to non-credit services: Even without ECOA, if Raxx's pricing algorithm produces disparate impact on a protected class (race, national origin, disability) under non-credit civil rights laws (e.g., 42 U.S.C. § 1981, ADA), there could be claims. This is distinct from ECOA and requires attorney analysis of the algorithm's actual inputs and outputs if a trust score drives pricing. The operator's proposal — raw event counts, no algorithmic score — keeps this risk low because no algorithm produces a biased output.

ECOA risk level: LOW — Raxx is not a creditor. Raw event counts stored for internal operator use do not trigger ECOA adverse-action notice requirements.

Sources: - https://www.law.cornell.edu/cfr/text/12/1002.2 (12 C.F.R. § 1002.2 — Regulation B definitions) - https://www.consumerfinance.gov/rules-policy/regulations/1002/9/ (CFPB § 1002.9 adverse action) - https://www.consumercomplianceoutlook.org/2013/second-quarter/adverse-action-notice-requirements-under-ecoa-fcra/ - https://www.federalregister.gov/documents/2022/06/14/2022-12729/consumer-financial-protection-circular-2022-03-adverse-action-notification-requirements-in-connection-with-credit-decisions-based-on-complex-algorithms

1.3 GDPR Article 22 — Automated Decision-Making Analysis

Question: If Raxx stores a numeric "trust score" and uses it programmatically, does GDPR Art. 22 require human-in-the-loop review? If we display raw counts to operators only, are we outside Art. 22?

Primary source: GDPR Article 22 (EU Regulation 2016/679), gdpr-info.eu.

Exact statutory language (Article 22(1)): "The data subject shall have the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly significantly affects him or her."

Subsection 22(2) exceptions (Art. 22 does not apply if the decision is): (a) necessary for entering/performing a contract; (b) authorized by EU/Member State law; (c) based on explicit consent.

Subsection 22(3) safeguards (if exceptions (a) or (c) apply): controller must implement "the right to obtain human intervention on the part of the controller, to express his or her point of view and to contest the decision."

CJEU reinforcement: In SCHUFA (Case C-634/21, December 2023), the CJEU confirmed that even credit scoring algorithms fall under Art. 22 when they significantly influence downstream human decisions — even if a human technically makes the final call. The score feeding the human decision is itself within Art. 22's scope.

Research finding for Raxx — two scenarios:

Recital 71 (verbatim scope): Profiling that evaluates "economic situation, health, personal preferences or interests, reliability or behaviour ... where it produces legal effects ... or similarly significantly affects him or her" is within Art. 22. "Reliability" is explicitly named.

Architecture recommendation consistent with research: Store raw counts only. No computed score. Operator sees raw data, makes human decisions. This design is cleanly outside Art. 22.

Sources: - https://gdpr-info.eu/art-22-gdpr/ (Art. 22 full text) - https://gdpr-info.eu/recitals/no-71/ (Recital 71 — profiling scope) - https://fpf.org/wp-content/uploads/2022/05/FPF-ADM-Report-R2-singles.pdf (FPF case law analysis including SCHUFA) - https://gdprlocal.com/automated-decision-making-gdpr/ (Art. 22 scope explainer)

1.4 GDPR Articles 13/14 — Privacy Notice Disclosure Obligations

Question: What must the privacy policy disclose if Raxx stores acquisition_source, customer_segment, and derived payment-event counts?

Primary sources: GDPR Articles 13, 14 (EU Regulation 2016/679).

What Art. 13 requires (data collected from the data subject at collection time): - Purposes of processing and legal basis (Art. 13(1)(c)) - Period for which data will be stored (Art. 13(2)(a)) - Whether automated decision-making / profiling exists and "meaningful information about the logic involved" (Art. 13(2)(f)) — only if Art. 22 is engaged - Categories of recipients (Art. 13(1)(e))

What Art. 14 additionally requires (data NOT obtained directly from the data subject — e.g., acquisition_source derived from UTM parameters, referral tracking, or third-party attribution): - Categories of personal data concerned (Art. 14(1)(d)) - The sources from which data originated (Art. 14(2)(f)) — must identify whether data comes from publicly accessible sources - Must be disclosed within 1 month of obtaining the data (Art. 14(3)(a))

Research finding for specific data types:

Does "profiling" as defined in GDPR Art. 4(4) apply? GDPR defines profiling as "any form of automated processing of personal data consisting of the use of personal data to evaluate certain personal aspects relating to a natural person." Storing segmentation tags and payment event counts is arguably profiling — it evaluates "economic situation" and "reliability." The privacy policy must disclose: (1) that profiling occurs; (2) the purposes; (3) meaningful information about any automated decision logic if Art. 22 is triggered.

If Art. 22 is NOT triggered (raw counts, human decisions only): Art. 13(2)(f) disclosure of automated decision logic is not required. Still required: processing purpose, legal basis, retention period for these data categories.

Legal basis for processing payment event counts: Most defensible basis is legitimate interests (Art. 6(1)(f)) — Raxx has a legitimate interest in maintaining payment integrity and preventing fraud. A Legitimate Interests Assessment (LIA) should be documented. If the data is ever used for marketing purposes, the legal basis shifts to consent.

Sources: - https://gdpr-info.eu/art-13-gdpr/ (Art. 13 full text) - https://gdpr-info.eu/art-14-gdpr/ (Art. 14 full text) - https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/individual-rights/right-to-be-informed/ (ICO right to be informed guidance) - https://gdprlocal.com/article-14-guide-meeting-regulatory-requirements-for-personal-data-not-directly-obtained-from-data-subjects/ - https://ec.europa.eu/information_society/newsroom/image/document/2016-51/wp242_en_40852.pdf (WP29 data portability guidelines — inferred vs. provided data distinction)

1.5 CCPA / CPRA — Profiling Opt-Out

Question: Do California residents have the right to opt out of Raxx storing and using these data points? Does the CPRA ADMT regulation apply?

Primary sources: California Consumer Privacy Act (CCPA), as amended by CPRA; California Privacy Protection Agency (CPPA) final ADMT regulations, effective January 1, 2026 (full consumer rights compliance January 1, 2027 for ADMT-specific provisions).

CCPA thresholds for coverage (Cal. Civ. Code § 1798.140): Raxx must comply if it meets ANY of: - Annual gross revenues > $25 million (CA only), OR - Buys/sells/receives/shares personal info of 100,000+ California consumers or households, OR - Derives 50%+ of annual revenues from selling California consumers' personal information.

These thresholds must be confirmed against Raxx's CA user count at the time of v1 launch. If Raxx is below all three, CCPA does not apply — but CPRA's ADMT regulations are worth tracking given the product trajectory.

CPRA ADMT regulations (CPPA, effective 2026):

The CPPA finalized ADMT regulations in October 2025 (Skadden analysis), effective January 1, 2026 for risk assessments; consumer notice and opt-out compliance required by January 1, 2027 for businesses already using ADMT:

• ADMT is defined broadly to include automated processing used to make "significant decisions" about consumers (access to services, pricing, eligibility).
• Businesses using ADMT for significant decisions must provide a pre-use notice explaining: (1) that ADMT is used; (2) the inputs; (3) intended output; (4) how to opt out; (5) how to request information about how ADMT evaluated them.
• Opt-out is opt-out, not opt-in — consumers can continue to be profiled until they opt out.
• A "significant decision" includes "access to or denial of services" and "pricing."

Research finding for Raxx:

Note: Even if Raxx is below CCPA thresholds, California has a history of private attorneys general actions; implementing ADMT-compatible design now is low-cost insurance.

Sources: - https://cppa.ca.gov/regulations/ccpa_updates.html (CPPA final ADMT regulations) - https://www.skadden.com/insights/publications/2025/10/california-finalizes-cppa-regulations (Skadden ADMT analysis) - https://oag.ca.gov/privacy/ccpa (CA DOJ CCPA overview) - https://secureprivacy.ai/blog/ccpa-requirements-2026-complete-compliance-guide - https://www.akingump.com/en/insights/blogs/ag-data-dive/proposed-california-regulations-for-automated-decision-making

1.6 Architect's Proposal: Raw Counts Only, No Aggregated Score

Operator question: Is storing only raw event counts (no aggregated score) safe? Or do we still owe disclosure and right-to-correct mechanisms?

Research finding:

The raw-counts-only architecture is the safest available option under current law for these reasons:

1. Art. 22 — OFF the radar. No computed score means no solely automated decision. The architecture is structurally outside Art. 22's scope as long as a human acts on the data.

2. CPRA ADMT — OFF the radar. No automated decision-making means no ADMT obligation for the scoring/reliability use case.

3. FCRA — remains inapplicable. The "transactions or experiences" exclusion covers raw counts.

But disclosure and right-to-correct obligations exist regardless of architecture:

Even for raw event counts, Raxx owes:

• Privacy notice disclosure (GDPR Art. 13/14): The privacy policy must disclose that payment event history is recorded, its purpose, legal basis, and retention period.

• Right of access (GDPR Art. 15): A user can request to see all data Raxx holds about them, including late_payment_count. Raxx must be able to fulfill this.

• Right to rectification (GDPR Art. 16): If a Stripe event was incorrectly recorded (e.g., a payment erroneously marked as failed), the user can request correction. Raxx needs a documented process for this — likely: user contacts support, support verifies against Stripe, updates the record.

• CCPA right to access / right to correct (Cal. Civ. Code §§ 1798.100, 1798.106): Same as GDPR — right to see and correct their personal information.

Retention limit: GDPR's storage limitation principle (Art. 5(1)(e)) requires data be kept "no longer than is necessary for the purposes for which the personal data are processed." For payment event counts, a reasonable retention period is the duration of the subscription plus whatever post- termination period is needed for legitimate interests (dispute resolution, chargeback defense). Keeping raw counts for 7+ years post-termination needs a documented justification. The billing doc notes a 7-year retention floor for invoice rows (tax/SOC2) — but payment event counts are not invoices; they should be reviewed separately.

Summary for operator: The raw-counts-only architecture is the right call. The obligations it creates (privacy notice disclosure, access, rectification, retention limits) are modest and straightforward. The obligations that a computed score would create (Art. 22 safeguards, CPRA ADMT notice/opt-out, potentially Art. 9 if score is correlated with protected characteristics) are materially more complex and expensive.

1.7 Industry Reference — Peer Fintech Handling

No public documentation was found (as of 2026-05-11) of Robinhood, Public.com, or M1 Finance exposing a "customer trust score" or "payment reliability" surface to operators. The absence is itself informative: these platforms are B2C; they have no "operator" layer with visibility into per-customer internal scoring.

Raxx is meaningfully different — it has a B2C customer surface (the trader) and a B2O (business-to- operator) console surface, which creates an asymmetry of information about the customer that the B2C fintechs do not have. This asymmetry is the primary privacy design consideration, and it is not addressed in public peer documentation. The closest industry analog is Stripe's internal "radar" fraud-risk scores, which Stripe does not expose to end customers — and Stripe, like Raxx, relies on the "transactions or experiences" exclusion to avoid FCRA classification.

Unsourced claim — confirm with attorney: The Stripe Radar design (internal score, not shared with consumers, not used by third parties, not exposed externally) is widely cited as the industry model for FCRA-safe internal risk scoring. Verify with privacy attorney that Raxx's implementation mirrors the relevant structural elements.

Part 2 — Tier Downgrade Data Handling

2.1 GDPR Article 20 — Right to Data Portability

Question: Does a downgraded user have the right to export all historical data regardless of current subscription state?

Primary source: GDPR Article 20 (EU Regulation 2016/679), gdpr-info.eu.

Exact statutory scope (Art. 20(1)): Right applies to personal data that the data subject "has provided to a controller" AND the processing is based on consent (Art. 6(1)(a)) or contract (Art. 6(1)(b)) AND processing is carried out by automated means.

What this covers: - Data the user actively provided: trading strategies entered, form submissions, account preferences, broker connection settings, uploaded trading history. - Data observed from user activity: trade logs, backtest results generated by the user's own rules, activity history. - Format required: "structured, commonly used and machine-readable format" — CSV and JSON both qualify.

What this does NOT cover (WP29 Guidelines on Data Portability, 2017): - Inferred or derived data (e.g., a platform-generated performance score, a risk rating the platform computed about the user) — this is the controller's own intellectual product, not data the user provided. - Data the controller holds about the user purely for its own operational purposes (e.g., server logs, system audit trails) — these are not "provided by" the data subject.

Does portability survive subscription downgrade?

The statute contains no temporal limitation tied to subscription state. The right to portability attaches to the legal basis (contract or consent) and ends only when: (a) the underlying data is deleted/erased, OR (b) the legal basis for processing expires.

If Raxx retains user data post-downgrade (which the current billing doc assumes for the 7-year retention floor), the portability right persists. WP29 guidance (2017) specifically recommends that controllers "always include information about the right to data portability before any account closure, which allows users to take stock of their personal data and to easily transmit the data."

Research finding: A downgraded user retains GDPR Art. 20 portability rights as long as Raxx holds their data. Raxx must be able to provide a machine-readable export (JSON or CSV) of user- provided and observed data on request, regardless of current subscription tier.

Sources: - https://gdpr-info.eu/art-20-gdpr/ (Art. 20 full text) - https://ec.europa.eu/information_society/newsroom/image/document/2016-51/wp242_en_40852.pdf (WP29 portability guidelines — scope of "provided by" data) - https://gdprhub.eu/Article_20_GDPR (GDPRhub case law index on Art. 20) - https://www.dataprotection.ie/en/individuals/know-your-rights/right-data-portability-article-20-gdpr

2.2 CCPA — Right to Access After Downgrade

Question: Can Raxx lock a free-tier user out of their old Pro+ data?

Primary source: California Consumer Privacy Act, Cal. Civ. Code § 1798.100.

Scope of right: California residents have the right to request disclosure of personal information a business has collected. The 2026 CPRA regulations extended the lookback from 12 months to "going back as far as January 1, 2022" for data collection.

Research finding: The CCPA right to access is a disclosure right — it requires Raxx to tell the user what data Raxx holds about them, not that Raxx must provide full product functionality. There is a meaningful distinction:

• Raxx must respond to a CCPA access request by disclosing the categories and specific pieces of personal information it collected — including data from the Pro+ period.
• Raxx does NOT have to restore Pro+ features to a free-tier user to satisfy a CCPA access request.
• However, if Raxx deletes or permanently destroys the data upon downgrade, Raxx can no longer fulfill the access request — and CPRA requires disclosed retention periods.

Conclusion: Raxx cannot delete user data upon downgrade without triggering a gap between disclosed retention periods and actual retention. Raxx can restrict feature access (operational decisions — which tools are available at which tier) but cannot silently destroy the user's data.

Sources: - https://oag.ca.gov/privacy/ccpa (CA DOJ CCPA) - https://cppa.ca.gov/regulations/pdf/ccpa_statute_eff_20260101.pdf (CPPA statute effective 2026) - https://www.jacksonlewis.com/insights/navigating-california-consumer-privacy-act-30-essential-faqs-covered-businesses-including-clarifying-regulations-effective-1126

2.3 What Is "Stranded Data" Legally?

Operator question: If a Pro+ user creates 1,000 strategies and downgrades to free, what are the legal obligations regarding those strategies?

Research finding:

The term "stranded data" is operational, not legal. Under applicable law, the user's strategies are:

1. Personal data (GDPR): To the extent strategies contain or are linked to personal information (user-authored rules, linked account data, backtesting history tied to the user's identity), they are personal data. Art. 15 (access), Art. 16 (rectification), Art. 17 (erasure on request), Art. 20 (portability) all attach.

2. Possibly copyrighted expression: User-authored trading rules may be creative expression subject to copyright. This is distinct from personal data. Raxx does not own user-authored content and cannot delete or restrict it in ways that extinguish the user's copy rights without clear ToS authorization.

3. Subject to the service ToS: Raxx can contractually limit the number of active strategies on the free tier. This is a contract term, not a privacy violation, as long as: (a) users were informed of downgrade consequences at signup or before downgrade, and (b) Raxx does not delete the data without the user's consent.

Operational options and their legal analysis:

Research conclusion: The read-only-with-history pattern is the legally safest option AND the correct product-direction choice under the operator's "hide, don't gray" design philosophy. Data is not deleted; the user can access and export it; Raxx simply does not activate Pro+ execution features on a free-tier token.

Sources: - https://gdpr-info.eu/art-17-gdpr/ (Art. 17 — the right to erasure is a user right, not an operator deletion right) - https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/individual-rights/right-to-erasure/ - https://drata.com/learn/gdpr/for-saas-compliance (GDPR for SaaS operational guidance)

2.4 Read-Only-with-History Pattern — Legal Assessment

Operator question: The architect proposed downgraded users see their old Pro+ data read-only with no upgrade CTA. Is this compliant?

Research finding: Yes — this is the recommended pattern, and it satisfies every applicable right:

No "discriminatory UI" risk: The concern that read-only-with-history could create "haves vs have-nots" UI patterns actionable under discrimination law does not have a legal foundation in current US law for SaaS product features. Anti-discrimination law (ECOA, FHA, ADA) is context-specific; showing a former Pro+ user their own past data in read-only mode is not discriminatory under any identified federal or state statute. ADA requires reasonable accommodation for disability access (not tier parity). This is not a legal risk; it is a product design question.

One obligation the read-only pattern creates: Users who see their old Pro+ data but cannot act on it could request erasure (Art. 17) to reduce cognitive dissonance. Raxx should have a clear erasure path. The existing billing DSR design already covers this.

2.5 Pause vs. Cancel vs. Downgrade — Data Retention Distinctions

Research finding:

Key difference at cancel: Once the contract ends, Raxx's legal basis for processing narrows. Processing for ongoing billing is gone. Residual legitimate interests (dispute resolution, fraud prevention, tax records) may justify retaining some data, but must be documented and disclosed. WP29 guidance recommends offering portability export at the time of account closure.

Sources: - https://gdpr-info.eu/art-5-gdpr/ (Art. 5 storage limitation principle) - https://www.pwc.com/us/en/services/consulting/cybersecurity-risk-regulatory/library/cpra-data-retention-preparation.html - https://ec.europa.eu/information_society/newsroom/image/document/2016-51/wp242_en_40852.pdf (WP29 recommendation on portability at account closure)

2.6 Data Import Edge Case — Imported Broker History

Operator question: If a Pro+ user imported trading history from Schwab or Fidelity, then downgrades, does that imported data have different obligations?

Research finding:

Imported broker data is still the user's personal data under GDPR and CCPA — Raxx is a data controller for data it holds, regardless of the original source. The obligations are the same.

However, there are two additional considerations:

1. Ownership of the imported data itself: The user is the data subject. The originating broker (Schwab, Fidelity) retains its own obligations as a separate controller for the data in its own systems. Raxx becomes an independent controller the moment it ingests the import. Raxx's obligations are independent of the broker's obligations — Raxx cannot cite "it came from Schwab" as a reason to apply different rules to the data.

2. Third-party data under GDPR Art. 14: If Raxx receives transaction data from a third-party broker API (not directly from the user typing it in), Art. 14 disclosure requirements apply. Raxx must disclose in its privacy notice: (a) the categories of data imported; (b) the source (the user's broker via the user's connection authorization); (c) the purpose of processing.

3. Portability of imported data: GDPR Art. 20 applies to data "provided by" the data subject. A user-authorized broker connection import is arguably "provided by" the data subject (the user authorized it). WP29 guidance on Art. 20 is that data obtained via user authorization falls within the portability right. This means Raxx must be able to export imported broker transaction history on portability request, not just natively-entered data.

Practical implication: On downgrade, imported broker transaction history should be treated identically to natively-created data — read-only access preserved, export available, no deletion without user request.

Sources: - https://gdpr-info.eu/art-14-gdpr/ (Art. 14 — third-party sourced data) - https://ec.europa.eu/information_society/newsroom/image/document/2016-51/wp242_en_40852.pdf (WP29 — Art. 20 scope for data provided via user-authorized third parties)

Risk Matrix

Each combination of storage/use × jurisdiction × risk level.

Timing / Deadlines

Draft Privacy Policy Disclosures (Attorney-Reviewable Language)

The following are research-grade draft disclosures for attorney review only. They should NOT be published without review by a privacy attorney licensed in the relevant jurisdictions.

Disclosure A — Payment Event History

Payment reliability information. We record information about your payment history with Raxx, including the number of successful payments, failed charge attempts, and chargebacks associated with your account. We use this information to manage our billing systems, prevent fraud, and maintain the integrity of our platform. We do not sell this information or share it with third parties for credit reporting purposes. The legal basis for this processing is our legitimate interest in operating a financially sound platform (GDPR Art. 6(1)(f)). We retain this information for [X years] following termination of your account [attorney to confirm retention period].

Disclosure B — Customer Segmentation and Acquisition Source

How you found us. We record how you first connected with Raxx, including referral sources, marketing channels, or partner introductions. We use this information to understand how our customers discover our platform and to assess the effectiveness of our marketing efforts. This information is not used to make automated decisions about your access, pricing, or eligibility for features. We retain this information for the duration of your account relationship with us.

Disclosure C — Downgrade Data Treatment (ToS addition, not privacy policy)

Your data on plan changes. If you change to a lower subscription tier, your existing data (including trading strategies, backtest results, and imported account history created under your prior plan) remains accessible to you in read-only format. You can export any of your data in machine-readable format at any time, regardless of your current subscription tier, by visiting [Account Settings > Data Export]. Raxx does not delete your data when you change subscription tiers. If you wish to delete your data, you may submit a deletion request at [privacy@raxx.app].

Disclosure D — No Automated Pricing/Tier Decisions

Automated decision-making. Raxx does not use automated algorithms to determine your subscription tier eligibility or pricing. Any decisions about account access or pricing are made by our team based on your account status and subscription terms.

[Note for attorney: Include only if raw-counts-only architecture is confirmed. Delete or modify this disclosure if a computed score is ever used for automated pricing/access decisions — at that point, the CPRA ADMT and GDPR Art. 22 disclosures are required instead.]

Questions for Privacy Attorney

These are research-flagged open questions requiring attorney resolution. Recommended professional: privacy attorney with GDPR, CCPA/CPRA, and FCRA experience. See reference_attorneys.md — no privacy attorney has been formally engaged as of 2026-05-11.

1. FCRA third-party sharing boundary: At what point does sharing payment event data with a Raxx service partner (e.g., a collections partner, a fraud consortium, or a future B2B product where Raxx provides operator risk data) cross into consumer reporting agency territory? Get a bright- line definition for the product team.

2. GDPR Art. 22 — SCHUFA extension risk: If a computed score is displayed to operators (not used for automated decisions), does the SCHUFA (C-634/21) ruling extend Art. 22 obligations to that operator-display-only scenario? Need attorney's view on the "significantly influences" standard for human-decision support tools.

3. Legitimate Interests Assessment for payment event data: Is Raxx's legitimate interest in storing late_payment_count etc. defensible under GDPR Art. 6(1)(f)? A formal LIA document should be prepared before launch.

4. CPRA threshold confirmation: Confirm whether Raxx meets any of the three CCPA coverage thresholds at v1 launch. If yes, confirm timeline for ADMT risk assessment and notice/opt-out implementation.

5. Art. 16 right to rectification — Stripe event disputes: What process is legally required if a user claims a failed_charge_count is inaccurate (e.g., a Stripe outage caused a false failure)? What documentation does Raxx need to reject or accept a rectification request?

6. "Export-only" vs. "in-app view" for Art. 15 access: Does providing a downloadable export satisfy GDPR Art. 15 right of access, or must the data be viewable in-app? ICO has not issued definitive guidance on this for archive/downgrade scenarios specifically.

7. ToS downgrade disclosure timing: When must Raxx disclose downgrade data treatment — at initial signup, at the time of downgrade, or both? What constitutes sufficient notice for contractual purposes?

8. Quebec customers (if geo-block lifted): Once fr-CA parity is achieved and Quebec signups are accepted, Quebec's Act Respecting the Protection of Personal Information in the Private Sector (Law 25 / Bill 64) has profiling and automated decision-making provisions. Confirm obligations specifically for payment reliability data under Law 25 Chapter II.

Questions for CPA

1. 7-year floor for payment event data: The billing doc carries a 7-year retention floor for invoice rows (tax/SOC2). Does this floor extend to payment event counts (late_payment_count, chargeback_count)? Or are these operational metrics not subject to the same tax-record retention requirement? The CPA should confirm which data rows are "books and records" under 26 U.S.C. § 6001 and IRS Publication 583.

2. Chargeback documentation retention: Chargeback dispute records may need to be retained for Raxx's bank/Stripe dispute processes. What is the minimum retention period for chargeback event records for financial dispute purposes? Does it differ from GDPR's "as long as necessary" standard?

3. State tax nexus and billing data: If billing event data is used to understand customer geography (billing address for tax purposes), confirm that Raxx's data model correctly flags the address_country retention post-DSR-erasure (the billing doc already retains address_country for tax compliance — confirm this is sufficient for state nexus reporting).

Sources (Full URL List)

Primary statutory and regulatory: - https://www.law.cornell.edu/uscode/text/15/1681a — 15 U.S.C. § 1681a (FCRA definitions) - https://www.ftc.gov/legal-library/browse/statutes/fair-credit-reporting-act — FTC FCRA page - https://www.govinfo.gov/content/pkg/USCODE-2011-title15/html/USCODE-2011-title15-chap41-subchapIII.htm - https://www.law.cornell.edu/cfr/text/12/1002.2 — 12 C.F.R. § 1002.2 (Regulation B definitions) - https://www.consumerfinance.gov/rules-policy/regulations/1002/9/ — CFPB Reg B § 1002.9 - https://gdpr-info.eu/art-13-gdpr/ — GDPR Art. 13 - https://gdpr-info.eu/art-14-gdpr/ — GDPR Art. 14 - https://gdpr-info.eu/art-17-gdpr/ — GDPR Art. 17 - https://gdpr-info.eu/art-20-gdpr/ — GDPR Art. 20 - https://gdpr-info.eu/art-22-gdpr/ — GDPR Art. 22 - https://gdpr-info.eu/recitals/no-71/ — GDPR Recital 71 (profiling) - https://gdpr-info.eu/recitals/no-72/ — GDPR Recital 72 - https://oag.ca.gov/privacy/ccpa — CA DOJ CCPA - https://cppa.ca.gov/regulations/ccpa_updates.html — CPPA ADMT final regulations - https://cppa.ca.gov/regulations/pdf/ccpa_statute_eff_20260101.pdf — CPPA statute eff. 2026

Regulatory guidance: - https://ec.europa.eu/information_society/newsroom/image/document/2016-51/wp242_en_40852.pdf — WP29 data portability guidelines (covers "provided by" scope) - https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/individual-rights/right-to-data-portability/ — ICO portability guidance - https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/individual-rights/right-to-be-informed/ — ICO right to be informed - https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/individual-rights/right-to-erasure/ — ICO Art. 17 guidance - https://www.dataprotection.ie/en/individuals/know-your-rights/right-data-portability-article-20-gdpr — DPC Ireland portability - https://www.federalregister.gov/documents/2022/06/14/2022-12729/consumer-financial-protection-circular-2022-03-adverse-action-notification-requirements-in-connection-with-credit-decisions-based-on-complex-algorithms — CFPB Circular 2022-03 (complex algorithms and adverse action) - https://www.consumercomplianceoutlook.org/2013/second-quarter/adverse-action-notice-requirements-under-ecoa-fcra/ — Philadelphia Fed ECOA/FCRA analysis

Analysis sources (used as secondary explainers alongside primary sources above): - https://www.skadden.com/insights/publications/2025/10/california-finalizes-cppa-regulations — Skadden CPPA ADMT final regs - https://www.akingump.com/en/insights/blogs/ag-data-dive/proposed-california-regulations-for-automated-decision-making — Akin ADMT analysis - https://fpf.org/wp-content/uploads/2022/05/FPF-ADM-Report-R2-singles.pdf — FPF GDPR Art. 22 case law report (includes SCHUFA) - https://gdprlocal.com/automated-decision-making-gdpr/ — Art. 22 scope explainer - https://gdprhub.eu/Article_20_GDPR — GDPRhub Art. 20 case index - https://drata.com/learn/gdpr/for-saas-compliance — GDPR SaaS operational guidance - https://www.pwc.com/us/en/services/consulting/cybersecurity-risk-regulatory/library/cpra-data-retention-preparation.html — PwC CPRA retention

Before any architectural decision is finalized or any data is collected under the described schemas, consult a privacy attorney experienced in GDPR (EU), CCPA/CPRA (California), and FCRA (US federal) in all relevant jurisdictions. The attorney pipeline in docs/legal/research/reference_attorneys.md does not currently include a privacy attorney — this engagement should be initiated before v1 launch. For tax-retention questions, consult the project CPA.