Präziser Abgleich: Feiertag Regelwerk ↔ SEC Daten

11 Scoring-Kriterien · Datenquelle je Kriterium · XBRL-Mapping · Lückenanalyse · Stand 28.03.2026

11 Scoring-Kriterien: Feiertag ↔ sec_data.db

K01+02

Phase 2 (Kurs > SMA200 steigend + > SMA50)

Yahoo/IB 2 Pkt

Feiertag-System

above_sma200 AND above_sma50 AND golden_cross AND sma200_rising
SMA200 via close.rolling(200).mean()
SMA200 steigend: Vergleich mit Wert vor SMA_RISING_LOOKBACK=20 Tagen
Quelle: yfinance Kursdaten (1 Jahr)

↔

sec_data.db

✗ Nicht vorhanden
SEC enthält keine Kursdaten.
Benötigt: Tägliche Schlusskurse für SMA-Berechnung.
Quelle: yfinance oder IB API (extern)

Fazit: Rein technisches Kriterium. Kein Bezug zu SEC-Finanzdaten. Muss aus Kursdaten-Pipeline kommen (yfinance/IB).

K03

Golden Cross (SMA50 > SMA200)

Yahoo/IB 1 Pkt

Feiertag-System

golden_cross_check(sma50, sma200)
Toleranz: GOLDEN_CROSS_TOLERANCE=0.95
→ SMA50 ≥ 95% der SMA200 reicht (Soft-GC)
Quelle: yfinance

↔

sec_data.db

✗ Nicht vorhanden
Technisches Kriterium, keine SEC-Daten.

Besonderheit: Feiertag nutzt 5%-Toleranz — Aktien knapp vor dem GC werden mitgenommen (z.B. DELL: SMA50 nur $0.98 unter SMA200).

K04

< 25% unter 52-Wochen-Hoch

Yahoo/IB 1 Pkt

Feiertag-System

SCORE_NEAR_HIGH_PCT = 25
abs(dist_high) ≤ 25%
52W-Hoch = close.tail(252).max()

↔

sec_data.db

✗ Nicht vorhanden
Benötigt tägliche Kursdaten.

K05

> 25% über 52-Wochen-Tief

Yahoo/IB 1 Pkt

Feiertag-System

SCORE_ABOVE_LOW_PCT = 25
dist_low ≥ 25%
52W-Tief = close.tail(252).min()

↔

sec_data.db

✗ Nicht vorhanden
Benötigt tägliche Kursdaten.

K06+07

Umsatzwachstum YoY (>20% = 1 Pkt, >50% = 2 Pkt)

SEC-Daten 1–2 Pkt

Feiertag-System (feiertag_trading.db)

SCORE_REV_GROWTH_MED = 20%
SCORE_REV_GROWTH_HIGH = 50%
View: v_fin_perf_001.rev_wachstum
Basis: t_fin_financials.fin_qtr_rev
Qualifier: 10q (direkt) | c-sec (berechnet) | nas (Fallback)
YoY = aktuelles Quartal vs. Vorjahresquartal

↔

sec_data.db

✓ Vorhanden
v_financials.revenue (Pivot-View)
XBRL: Revenues | RevenueFromContractWithCustomerExcludingAssessedTax
Form: 10-Q (Quartal) | 10-K (Jahres)
Periode: fiscal_period (Q1/Q2/Q3/FY)

Anknüpfungspunkt: Direktes Mapping möglich. v_financials.revenue mit form='10-Q' liefert Quartalsumsätze. Für Q4 gilt die 10-K-Regel (s.u.).
Abweichung: Feiertag nutzt Qualifier-System (10q/c-sec/nas) — sec_data.db hat keine Qualifier, aber die gleiche Datenquelle (SEC XBRL).
XBRL-Lücke: Feiertag-System nutzt auch RevenueFromContractWithCustomerExcludingAssessedTax als Fallback. sec_data.db mappt aktuell nur auf Revenues in v_financials.
Handlungsbedarf: Screening-Engine muss XBRL-Fallback-Konzepte für Revenue implementieren (327+ Firmen betroffen).

K08

Gewinnwachstum YoY > 20%

SEC-Daten 1 Pkt

Feiertag-System (feiertag_trading.db)

SCORE_EARN_GROWTH_MIN = 20%
View: v_fin_perf_001.net_wachstum
Basis: t_fin_financials.fin_qtr_net
Qualifier: 10q | c-sec | nas
YoY = aktuelles Quartal vs. Vorjahresquartal

↔

sec_data.db

✓ Vorhanden
v_financials.net_income (Pivot-View)
XBRL: NetIncomeLoss
Form: 10-Q | 10-K
Periode: fiscal_period (Q1/Q2/Q3/FY)

Anknüpfungspunkt: Direktes Mapping. NetIncomeLoss ist das Standard-XBRL-Konzept, deckt den Großteil ab.
Sonderfall: Bei Earnings Growth ist Vorzeichenwechsel zu beachten (Verlust → Gewinn). Feiertag löst das über v_fin_perf_001 mit status = 'reported'.

K09

Keine Dividende (< 0.5%)

SEC + extern 1 Pkt

Feiertag-System

SCORE_MAX_DIVIDEND_PCT = 0.5%
Aktuell: nicht in DB implementiert (TODO)
Full-Universe: yf.Ticker.info['dividendYield']
Daily Report: Heuristik — alle Ticker = 0 Dividende

↔

sec_data.db

✓ Teilweise vorhanden
v_financials.dividend_per_share
XBRL: CommonStockDividendsPerShareDeclared
→ Gibt Dividende/Aktie, nicht Yield.
Für Yield: dividend_per_share / Kurs nötig.

Anknüpfungspunkt: sec_data.db liefert dividend_per_share aus 10-K. Zusammen mit einem Kursdatum ergibt das die Dividend Yield. Alternativ: Binärcheck — wenn dividend_per_share = 0, dann keine Dividende → 1 Punkt.
Feiertag-Lücke: Dividenden-Daten fehlen im Daily Report komplett (aktuell immer 1 Punkt für alle). SEC-Daten können das beheben.

K10

Tech/Scalable Sektor

SEC + extern 1 Pkt

Feiertag-System

SCORE_TECH_SECTORS = ['Technology', 'Communication Services', 'Financial Services']
Basis: t_std_stammdaten.std_sector
Quelle: Yahoo Finance Sektorzuordnung (GICS)

↔

sec_data.db

✓ Teilweise vorhanden
companies.sic (SIC-Code, 4-stellig)
companies.sic_desc (Branchenbeschreibung)
→ SIC ≠ GICS. Mapping nötig:
SIC 3570-3579, 3670-3679, 7370-7379 ≈ Technology

Problem: SEC verwendet SIC (Standard Industrial Classification), Feiertag/Yahoo verwendet GICS (Global Industry Classification). Kein 1:1-Mapping.
Lösung: SIC→GICS Mapping-Tabelle erstellen, oder weiterhin Yahoo-Sektordaten verwenden. SEC-SIC allein reicht nicht für exakte Zuordnung.

K11

3-Monats-Performance > 0%

Yahoo/IB 1 Pkt

Feiertag-System

SCORE_MIN_PERF_3M = 0%
perf_3m = (kurs - kurs_vor_63_tagen) / kurs_vor_63_tagen * 100

↔

sec_data.db

✗ Nicht vorhanden
Benötigt tägliche Kursdaten.

c-sec Regel: Vergleich beider Systeme

10-K-Regel (Q4-Berechnung bei fehlendem 10-Q)

Beide Systeme lösen das gleiche Problem: Viele Firmen veröffentlichen kein separates 10-Q für Q4, weil der 10-K-Jahresbericht die Jahresdaten enthält.
Q4 = 10-K (Jahres) − (Q1 + Q2 + Q3)

Aspekt	Feiertag (feiertag_trading.db)	AI Artifakte (sec_data.db)
Formel	c-sec = 10K_ann - (Q1+Q2+Q3)	Identische Logik nötig in Screening-Engine
Qualifier	c-sec (berechnet), 10q (direkt), nas (NASDAQ-Fallback)	Kein Qualifier-System. fiscal_period=FY + form=10-K identifiziert Jahresberichte
Q4-Erkennung	Zeile mit fin_qlf_qtr_rev='d' + fin_qlf_ann_rev='10k'	fiscal_period='FY' + form='10-K' → enthält implizit Q4
FYE-Toleranz	FYE-Monat ±1 Monat (52/53-Wochen-FY: DELL, HD, LOW, KR)	companies.fiscal_year_end (MMDD) vorhanden, Toleranzlogik muss implementiert werden
Fallback	NASDAQ-Quartalsdaten (fin_qtr_nas_rev) als Notlösung	Kein Fallback. Nur SEC-Daten.
Addierbare Felder	7 Felder: rev, cor, opr, int, tax, net, shr	Relevante Felder in v_financials: revenue, net_income (für Screening genügen 2)
EPS-Sonderregel	Q4_eps = Q4_net / annual_shr	eps_diluted in v_financials vorhanden, gleiche Logik anwendbar

Filter-Kaskade: Feiertag (6 Stufen vor dem Score)

Die Feiertag-Kaskade filtert VOR dem Scoring. Alle 6 Stufen sind technisch und brauchen Kursdaten (nicht SEC):

Stufe 1: Preis ≥ $20 + Vol ≥ 500K + 2-von-3 Liquiditätsregel (liquidity_check())
Stufe 2: Kurs > SMA200
Stufe 3: SMA200 steigend (vs. 20 Tage zuvor)
Stufe 4: Kurs > SMA50 + Golden Cross (mit 5% Toleranz)
Stufe 5: Max. 25% unter 52-Wochen-Hoch
Stufe 6: 3-Monats-Performance > 0%

→ Alle 6 Stufen: Keine SEC-Daten involviert. Reine Kursdaten-Pipeline.

XBRL-Konzept-Mapping: Feiertag ↔ sec_data.db

Kennzahl	Feiertag-Feld	sec_data.db Feld	XBRL-Konzept(e)	Status
Revenue	fin_qtr_rev	v_financials.revenue	Revenues, RevenueFromContractWithCustomer…	✓ Haupt-Mapping
Net Income	fin_qtr_net	v_financials.net_income	NetIncomeLoss	✓ 1:1 Match
EPS (diluted)	fin_qtr_eps	v_financials.eps_diluted	EarningsPerShareDiluted	✓ 1:1 Match
Shares	fin_qtr_shr / fin_ann_shr	v_financials.shares_weighted_avg	WeightedAverageNumberOfDilutedSharesOutstanding	✓ Vorhanden
Dividend/Share	nicht implementiert	v_financials.dividend_per_share	CommonStockDividendsPerShareDeclared	✓ In sec_data.db
Sektor	std_sector (Yahoo GICS)	companies.sic / sic_desc	—	SIC ≠ GICS

Gesamtergebnis: Datenquellen pro Kriterium

#	Kriterium	Punkte	Datenquelle	sec_data.db	Kursdaten (extern)
K01+02	Phase 2	2	Kursdaten	✗	✓ yfinance/IB
K03	Golden Cross	1	Kursdaten	✗	✓ yfinance/IB
K04	<25% unter 52W-Hoch	1	Kursdaten	✗	✓ yfinance/IB
K05	>25% über 52W-Tief	1	Kursdaten	✗	✓ yfinance/IB
K06+07	Revenue Growth YoY	1–2	SEC Filings	✓ v_financials.revenue	✗
K08	Earnings Growth YoY	1	SEC Filings	✓ v_financials.net_income	✗
K09	Keine Dividende	1	SEC + Kurs	✓ dividend_per_share	Kurs für Yield
K10	Tech Sektor	1	SEC + Yahoo	SIC (≠ GICS)	Yahoo Sektor
K11	3M-Performance	1	Kursdaten	✗	✓ yfinance/IB
SUMME		11		3 Kriterien (4 Pkt)	6 Kriterien (7 Pkt)

Handlungsbedarf für Screening-Engine (Agent B)

1. SEC-Daten (sec_data.db) — sofort nutzbar:
• Revenue YoY Growth: v_financials.revenue mit fiscal_period + form
• Earnings YoY Growth: v_financials.net_income
• Dividenden-Check: v_financials.dividend_per_share = 0 → keine Dividende
• 10-K-Regel implementieren: FY-Wert minus 3× 10-Q = Q4
• XBRL-Fallback für Revenue ergänzen (RevenueFromContract… als Alternative)

2. Kursdaten (externe Pipeline) — parallel aufbauen:
• yfinance Batch-Download (wie Feiertag-System)
• SMA50, SMA200, 52W-High/Low, 3M-Performance berechnen
• Phase-2-Check, Golden-Cross-Check, Liquiditätscheck
• Optional: IB API für Realtime-Kurse

3. Offene Punkte:
• SIC→GICS Mapping für Sektor-Kriterium (oder Yahoo-Daten beibehalten)
• FYE-Toleranz (±1 Monat) für 52/53-Wochen-Fiskaljahre
• Qualifier-System: Tracking ob Q4-Daten berechnet oder direkt sind
• Score-Threshold: 8/11, 7/10, 7/9 (dynamisch je nach verfügbaren Daten)