Erkennung von Sozialleistungsbetrug und Fehlerrisiken (Schutzmaßnahmen für Hochrisiko-KI nach KI-Verordnung)

Sozialversicherungs-, Arbeitslosen-, Wohn- und Kindergeldbehörden verlieren Geld sowohl durch Betrug als auch durch ehrliche Fehler und haben zu wenige Sachbearbeitende, um jeden Antrag zu prüfen. Risikomodelle können Anträge nach Rang ordnen, die einen menschlichen Blick verdienen. Aber in diesem Anwendungsfall hat die algorithmische Auswahl in Europa den am besten dokumentierten Schaden angerichtet (niederländischer Kindergeldskandal, SyRI, dänische und schwedische Systeme). Richtig umgesetzt ist es ein Hochrisiko-KI-System mit Bias-Audits, einer Grundrechte-Folgenabschätzung, Erklärbarkeit und wirksamer menschlicher Prüfung. Nachlässig umgesetzt kann es in das verbotene Social Scoring abrutschen.

Problem & Nutzen

• Heute: Behörden stützen sich auf Regeln („Red Flags“), Hinweise, Datenabgleiche mit Arbeitgeber-, Steuer- und Melderegistern sowie Stichproben. Die Auswahl von Fällen für vertiefte Ermittlungen erfolgt zunehmend mit statistischen Modellen.
• KI-Nutzen: bessere Trefferquoten je Ermittlerstunde, frühere Erkennung von Fehlern (falsches Einkommen, nicht gemeldete Änderung des Haushalts), die sich günstig und ohne Sanktion korrigieren lassen, sowie einheitliche, dokumentierte Auswahlkriterien statt Verdacht von Fall zu Fall.
• Belege für Schaden, nicht nur für Nutzen: Ein selbstlernendes Risikomodell im niederländischen Kinderbetreuungsgeld-System nutzte die Staatsangehörigkeit als Faktor; Zehntausende überwiegend einkommensschwache Eltern wurden zu Unrecht beschuldigt, und die Regierung trat im Januar 2021 zurück [1][2]. Das Bezirksgericht Den Haag erklärte die SyRI-Profiling-Gesetzgebung 2020 für rechtswidrig (Art. 8 EMRK; berichtet in [2]). Amnesty (2024) kritisierte die dänischen Systeme von Udbetaling Danmark / ATP (bis zu 60 Modelle; „Really Single“ und „Model Abroad“ nutzen Proxys für Wohnverhältnisse und Auslandsbezüge) [3]. Lighthouse Reports und Svenska Dagbladet (2024) berichteten, dass das Modell der schwedischen Försäkringskassan Frauen, Migranten und Geringverdienende überproportional auswählte; die Behörde bestreitet die Befunde [4].
• Ehrliche Einordnung: Veröffentlichte Zahlen zu „verhindertem Betrug“ solcher Systeme sind überwiegend Selbstberichte der Behörden und umstritten; behandeln Sie jede ROI-Aussage ohne randomisierte Kontrollgruppe als unbewiesen.

Varianten

• Triage auf Antragsebene bei Eingang (neuer Antrag oder Änderungsmitteilung): inkonsistente oder unvollständige Daten für eine Rückfrage markieren, nicht für einen Vorwurf.
• Auswahl für Nachprüfungen nach Auszahlung: gezahlte Fälle für eine periodische Prüfung nach Rang ordnen; stets kombiniert mit einer Zufallsstichprobe, um die tatsächliche Fehler-/Betrugsrate zu messen und Modelldrift zu erkennen.
• Dokumenten- und Nachweisprüfungen (Gehaltsabrechnungen, Mietverhältnis, Kontoauszüge): siehe ANOM-017 und ANOM-014; dieser Eintrag behandelt die Entscheidungsebene auf Fallebene.
• Netzwerk-/Analyse organisierten Betrugs (gemeinsame Adressen, Bankkonten, Arbeitgeber, Vermittler): Graphanalytik auf Entitäten und Konstrukte statt auf den Lebensstil einzelner Bürger; am nächsten an ANOM-020.
• Hinweise zur Fehlervermeidung (Nudges): vorausgefüllte Formulare, Erinnerungen und Plausibilitätsprüfungen, die unbeabsichtigte Überzahlungen verringern; meist risikoärmer und wirksamer als Betrugsbewertung.
• Nicht Gegenstand: Auswahl bei Steuer- und Umsatzsteuerbetrug (ANOM-018); Abrechnungsbetrug von Gesundheitsleistern (ANOM-007); Versicherungsschäden (ANOM-003); allgemeines Rahmenwerk zur Prüfungsfallauswahl (PRED-028).

So funktioniert es

1. claim / change notification + lawful register data
2. data minimisation & feature governance (no protected attributes, no proxies such as nationality, postcode, family status)
3. rules + supervised model (gradient boosting) and/or anomaly detection
4. score + reason codes + confidence
5. treated as a recommendation only
6. human caseworker review (can see reasons, can override, may ask the claimant first)
7. outcome label (correct / error / fraud / unclear) fed back
8. monitoring: per-group false-positive rates, drift, random control sample, complaints

• Modelle: tabellarisches ML (Gradient Boosting wie XGBoost/LightGBM, Explainable Boosting Machines) mit Begründungscodes im SHAP-Stil; unüberwachte Anomalieerkennung für neue Muster; Graphanalytik für Cluster mit gemeinsamen Merkmalen. LLMs eignen sich nur für die Dokumentenaufnahme, die Zusammenfassung einer Fallakte für die Prüfenden und das Entwerfen neutraler Rückfrageschreiben; sie dürfen keine Bewertungen oder Beschuldigungen erzeugen.
• Labels sind die Schwachstelle: Frühere Ermittlungen spiegeln wider, wo die Behörde ohnehin hingesehen hat (Auswahlverzerrung), sodass überwachte Modelle die historische Verzerrung der Behörde selbst lernen. Gegenmaßnahme: eine Zufallsstichprobe als unverzerrte Referenz und die Trennung der Labels „Fehler“ und „vorsätzlicher Betrug“ [4].
• Stellen mit Mensch-in-der-Schleife (Human-in-the-Loop): (1) Freigabe der Merkmale durch ein Governance-Gremium mit Rechts- und Datenschutzpersonal, (2) Prüfung durch Sachbearbeitende vor jeder Ermittlung oder Aussetzung einer Leistung, (3) Anhörung und Widerspruch der antragstellenden Person, (4) regelmäßige unabhängige Prüfung.

Datenaufbereitung

Die Daten stammen aus Leistungsantragssystemen, Zahlungs- und Falldaten, eingescannten Nachweisdokumenten und Registerdaten, auf die auf ausdrücklicher Rechtsgrundlage zugegriffen wird. In einer Behörde liegen sie in Fachverfahren, dateibasierten Fallakten und Papierdossiers. Typische Lücken: eingescannte Nachweise ohne OCR, uneinheitliche Fallkodierung, keine saubere Trennung zwischen bestätigtem Betrug, ehrlichem Fehler und ohne Befund, fehlende Ergebnisse aus Zufallsstichproben (es wurden immer nur verdächtige Fälle geprüft, was die Labels verzerrt) sowie strenge Zugriffsrechte und Zweckbindungen. Schritte: (1) Dateninventur und Zuordnung der Daten zum Anwendungsfall, siehe PREP-001 und PREP-002; (2) Prüfung von Rechtsgrundlage und Zweck vor jeder Weiterverwendung, siehe PREP-025; (3) OCR der Papiernachweise, siehe PREP-006 und DOC-014; (4) das Kategorienschema (Betrug, Fehler, ohne Befund) vor der Beschriftung festlegen, siehe PREP-019, und Labels aus früheren Prüfungen gewinnen, siehe PREP-020; (5) mit Sachbearbeitenden eine zufällige Kontrollstichprobe und Testmengen aufbauen, siehe PREP-018; (6) Entwicklungsdaten pseudonymisieren, siehe PREP-022; (7) geschützte und Proxy-Merkmale entfernen, soweit das Gesetz es verlangt, und dies dokumentieren. Werkzeuge: ETL-Pipelines, OCR (Tesseract, docTR), ein Feature Store. Rechnen Sie mit 50 bis 60 Prozent des Aufwands für die Datenaufbereitung. Siehe GUIDE-003 für den Reifegradtest.

Umsetzungswege

Welcher Weg für wen

• public (C): Leistungsdaten sind hochsensibel, und das System ist nach der KI-Verordnung hochriskant; daher braucht es volle Kontrolle über Modelle, Protokolle und Bias-Audits auf souveräner Infrastruktur; Open-Source-ML auf HW2 genügt.
• enterprise (C): Versicherer, Sozialversicherungsträger und große Zahler mit vergleichbaren Leistungsdaten brauchen aus denselben Gründen prüfbare, selbst betriebene Modelle.
• developer (C): Anbieter, die Behörden beliefern, müssen transparente, selbst betreibbare Bewertung mit eingebauter Erklärbarkeit und Audit-Werkzeugen anbieten.

Weg A — Kaufen (Standardsoftware)

Es gibt Suiten für Betrugsbekämpfung und Fallmanagement im öffentlichen Sektor (zum Beispiel SAS-Produkte für Betrug und Compliance, Pega Case Management, IBM und Plattformen zur Entitätsauflösung im Stil von Quantexa; deutsche und EU-Integratoren bauen darauf oder auf Individualcode auf). Zu fordernde Prüfungen: EU-Hosting und Datensouveränität, White-Box-Begründungscodes, Fairnessberichte je Gruppe, Unterstützung der Dokumentation nach KI-Verordnung (Art. 9–15), standardmäßig keine Nutzung von Staatsangehörigkeit oder ähnlichen Proxy-Merkmalen sowie das Recht, das Modell einzusehen und zu testen. Nur für Behörden mit einem Beschaffungsweg und einer IT-Abteilung die richtige Wahl, die einen Anbieter steuern kann; undurchsichtige „Black-Box“-Betrugswerte sind das Muster, das in den obigen Fällen gescheitert ist. Kein Produkt für Privatpersonen oder KMU.

Weg B — Auf Cloud-KI-Diensten aufbauen

Nur für unterstützende Aufgaben geeignet: Dokumenten-Parsing (Azure AI Document Intelligence, Mistral OCR, Google Document AI mit EU-Regionen), Zusammenfassungen von Fallakten und neutrales Formulieren mit einem führenden oder EU-LLM-Anbieter (Mistral, Anbieter im Stil von Aleph Alpha, Claude/Gemini/GPT über EU-Regionen) hinter einer Schutzschicht (Guardrails). Die Bewertung von Bürger-Registerdaten in einer öffentlichen Cloud ist nur möglich, wenn Rechtsgrundlage, Auftragsverarbeitungsvertrag und Souveränitätsanforderungen (BSI C5, SecNumCloud-Stil, nationale Cloud-Richtlinie) erfüllt sind; viele Behörden werden sie ausschließen.

Weg C — Selbst betreiben (Open Source)

Empfohlene Standardlösung für Behörden: Tabellarisches ML bleibt CPU-tauglich. - Modellierung: scikit-learn, XGBoost/LightGBM, InterpretML (Explainable Boosting), SHAP; Graphanalyse mit Neo4j Community / NetworkX / PyG. - Fairness und Audit: Fairlearn (Werkzeugsatz für Bewertung und Gegenmaßnahmen) [5], AIF360, Aequitas; Evidently oder Ähnliches für Drift. - Dokumente/LLM (optional): Docling oder PaddleOCR mit einem offenen VLM/LLM (Qwen-, Mistral-, Llama-Familien) über vLLM im eigenen Rechenzentrum der Behörde. - Governance: MLflow für Modellregister und Nachvollziehbarkeit (Lineage); unveränderliches Prüfprotokoll jeder Bewertung und jeder menschlichen Entscheidung. - Hardware: HW1 (CPU-Server) für Bewertung und Training; HW2/HW3 nur, wenn die optionale Dokumenten-/LLM-Ebene selbst betrieben wird.

Weg D — Eigenes Training

Hier leben die meisten realen Systeme: ein Modell, trainiert auf den eigenen beschrifteten Ergebnissen der Behörde. Benötigt werden Tausende verifizierter Ergebnisse plus eine unverzerrte Zufallsprüfungsstichprobe, ein dokumentierter Merkmalskatalog mit rechtlicher Begründung je Merkmal und ein Trainings-/Validierungsschema, das Datenleckage aus dem Ermittlungsprozess vermeidet. Planen Sie mehr Zeit für Validierung, Fairnesstests und rechtliche Freigabe ein als für die Modellierung.

Stand der Technik (2026)

• Technik: kein Durchbruch an der Spitze; Gradient Boosting mit Erklärbarkeit bleibt der praktische Standard für tabellarische Leistungsdaten. Die Fortschritte liegen auf der Governance-Seite: Standard-Werkzeuge für Fairness, Algorithmenregister, Vorlagen für Folgenabschätzungen und (in der EU) ein verbindlicher Rechtsrahmen.
• Regulatorische Verschiebung: Die KI-Verordnung stuft KI-Systeme, die von oder für Behörden genutzt werden, um die Anspruchsberechtigung auf grundlegende öffentliche Unterstützungsleistungen und -dienste zu bewerten und diese zu gewähren, zu kürzen, zu widerrufen oder zurückzufordern, als hochriskant ein (Anhang III Nr. 5 Buchst. a) [6]. Die Ausnahme für Betrugserkennung in Nr. 5 Buchst. b gilt für die Kreditwürdigkeitsprüfung zur Aufdeckung von Finanzbetrug, nicht für die Leistungsberechtigung. Die Ausnahme der „engen Aufgabe“ nach Art. 6 Abs. 3 gilt nicht für Systeme, die natürliche Personen profilieren [7]. Die Leitlinien der Kommission zu Art. 5 (Feb. 2025) behandeln Social Scoring [8].
• Grenzen und Fehlerbilder: Proxy-Diskriminierung (Postleitzahl, Staatsangehörigkeit, Haushaltszusammensetzung), Rückkopplungsschleifen (markierte Gruppen werden häufiger geprüft, daher wird dort mehr „Betrug“ gefunden), Vermengung von Fehler und Betrug, Automatisierungsverzerrung bei Sachbearbeitenden („das System hat es gesagt“), nicht erklärte Werte, die eine Rechtsverteidigung unmöglich machen, und schleichende Zweckausweitung, wenn für eine Leistung erhobene Daten für die Bewertung wiederverwendet werden.
• Hinweis zu Fristen: Die Pflichten für Hochrisiko-Systeme sollten ursprünglich ab dem 2. August 2026 gelten; der Digital Omnibus zur KI (Verordnung (EU) 2026/1744, in Kraft seit 27. Juli 2026) hat die Pflichten nach Anhang III auf den 2. Dezember 2027 verschoben.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack (tabular-ml + anomaly-detection + graph-ml): ANOM-003 Betrug bei Versicherungsschäden, ANOM-007 Abrechnungsbetrug im Gesundheitswesen, ANOM-018 Steuer- und Umsatzsteuerbetrug, ANOM-020 Kollusion bei der Beschaffung und Betrug mit EU-Mitteln, PRED-028 risikobasierte Fallauswahl (gemeinsames Auswahl-Rahmenwerk mit Kapazitätsbudget und zufälliger Kontrollgruppe).
• Nachweisebene: ANOM-017 Dokumentenmanipulation und ANOM-014 Prüfung von Ausweisdokumenten; Dokumenten-Parsing im Stil von DOC-001 für eingehende Nachweise.
• Governance-Ebene gemeinsam mit: SEC-022 (KI-Inventar, Risikoklassifizierung, Dokumentation nach KI-Verordnung) und SEC-018 (DSFA, Verzeichnis der Verarbeitungstätigkeiten, Auskunftsanfragen).
• Hardware: ein CPU-/HW1-Analysecluster plus das Data Warehouse der Behörde bedient all dies; ein HW2/HW3-GPU-Knoten kommt nur hinzu, wenn LLM-/VLM-Dokumentenverarbeitung enthalten ist.

Aufwand, Kosten & Kennzahlen

• Weg A: Monate für die Beschaffung plus 6–12 Monate für die Integration; die Lizenzkosten hängen vom Volumen ab (keine verlässlichen öffentlichen Zahlen).
• Weg C/D: typischerweise ein Team aus Data Scientists, einer Leitung für Recht/Datenschutz und fachlichen Ermittlern über 9–18 Monate bis zu einem gesteuerten Produktivsystem; die Rechenkosten sind klein im Vergleich zu Personal- und Prüfaufwand.
• Kennzahlen: Präzision der markierten Fälle gegenüber einer zufälligen Kontrollstichprobe; Anteil der Befunde, die Fehler statt Betrug sind; Falsch-Positiv- und Markierungsraten-Parität je Gruppe; Zeit bis zur Entscheidung; Anteil der Übersteuerungen durch Prüfende; Ausgang von Beschwerden und Widersprüchen; zurückgeholte Beträge abzüglich der Kosten zu Unrecht ausgesetzter Leistungen; Modelldrift.

Menschen & Veränderung

Binden Sie früh Leitung, Abteilungsleitung und Sachbearbeitende (die Endanwender) ein, außerdem IT, die bzw. den Datenschutzbeauftragte(n) und die Rechtsabteilung. Datenschutzbeauftragte(r) und DSFA kommen zuerst: Besondere Kategorien und schutzbedürftige Personen sind betroffen, daher sind eine DSFA (Art. 35 DSGVO) und für öffentliche Stellen eine Grundrechte-Folgenabschätzung nötig, weil das System hochriskant ist (die Pflichten nach Anhang III gelten ab dem 2. Dez. 2027 gemäß Verordnung (EU) 2026/1744). Betriebsrat: ja. Die Bearbeitung bewerteter Fälle durch Sachbearbeitende wird protokolliert, daher ist das System objektiv geeignet, Verhalten oder Leistung zu überwachen, und §87 Abs. 1 Nr. 6 BetrVG gilt (in Behörden der Personalrat nach BPersVG oder Landesrecht); ebenso §90 Abs. 1 Nr. 3 für KI-geplante Arbeitsabläufe und §80 Abs. 3 für einen Sachverständigen. Vereinbaren Sie, dass Bewertungen nie für individuelle Leistungsbeurteilungen genutzt werden. KI-Kompetenz: Unterstützen Sie Sachbearbeitende mit Schulungen dazu, was ein Wert bedeutet, was Automatisierungsverzerrung ist und wie man eine Übersteuerung dokumentiert (Art. 4 KI-Verordnung, GUIDE-006). Starten Sie einen Pilot in einer Dienststelle mit einer gemischten Stichprobe, die zufällige Kontrollfälle enthält. Die Hauptsorge der Bürger ist ungerechter Verdacht: Kommunizieren Sie offen, was bewertet wird, geben Sie Betroffenen Benachrichtigung und Rechtsbehelfe, testen Sie die Verzerrung je Gruppe und stellen Sie sicher, dass nie eine Leistung allein aufgrund des Werts verweigert oder gekürzt wird. Siehe GUIDE-004, GUIDE-005 und GUIDE-014.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): hochriskant (Anhang III Nr. 5 Buchst. a), wenn das System die Anspruchsberechtigung bewertet oder das Gewähren, Kürzen, Widerrufen oder Zurückfordern von Leistungen unterstützt. Zu den Pflichten gehören Risikomanagement, Daten-Governance, Protokollierung, Transparenz, menschliche Aufsicht, Genauigkeit und Robustheit (Art. 9–15) und für öffentliche Stellen eine Grundrechte-Folgenabschätzung vor dem Einsatz (Art. 27), die betroffene Gruppen, spezifische Risiken, menschliche Aufsicht und Beschwerdemechanismen abdeckt [9]. Das Verbot des Social Scoring (Art. 5 Abs. 1 Buchst. c) gilt, wenn Bewertungen aus nicht zusammenhängendem sozialem Verhalten oder persönlichen Merkmalen zu ungerechtfertigter oder unverhältnismäßiger Schlechterbehandlung führen [10]; ein Entwurf, der aus zusammengeführten Registern Lebensstil- oder „atypische Wohnverhältnisse“-Profile bildet, ist diesem Verbot ausgesetzt, weshalb Amnesty fordert, das dänische System zu verbieten [3]. Art. 5 Abs. 1 Buchst. d untersagt zusätzlich die Vorhersage von Straftatrisiken allein auf Grundlage von Profiling. Wo ein Einsatz diese Grenzen überschreitet, darf er nicht rechtmäßig auf den EU-Markt gebracht werden; umsetzbar sind nur die oben beschriebenen engeren, faktenbasierten und menschlich unterstützten Varianten.
• DSGVO: Daten besonderer Kategorien (Gesundheit, ethnische Herkunft usw.) und Proxys; erforderlich sind eine spezifische Rechtsgrundlage (meist nationales Sozialversicherungsrecht), strenge Zweckbindung und Datenminimierung, eine DSFA (Art. 35) und die Grenzen des Art. 22 für ausschließlich automatisierte Entscheidungen. Das SCHUFA-Urteil des EuGH (C-634/21) wertete einen vorgelagerten Score, der eine Entscheidung maßgeblich prägt, selbst als automatisierte Entscheidung; das gilt unmittelbar für Bewertungen „nur als Empfehlung“, die Sachbearbeitende abzeichnen.
• Grundrechte: Nichtdiskriminierung (Charta Art. 21), Privatsphäre (EMRK Art. 8, wie im SyRI-Urteil angewandt), gute Verwaltung und wirksamer Rechtsbehelf. Das nationale Recht fügt Pflichten hinzu (deutsches SGB X zu automatisierten Entscheidungen, Vorschriften des Verwaltungsverfahrens, Algorithmenregister in den Niederlanden).
• Gegenmaßnahmen: geschützte und Proxy-Merkmale ausschließen, Zweck und Logik des Modells soweit möglich veröffentlichen, Antragstellenden Benachrichtigung und Anhörung geben, eine zufällige Kontrollstichprobe führen, externe Bias-Audits durchführen und für jedes Modell ein Ablauf-/Neufreigabedatum festlegen.

Erste Schritte

1. Legen Sie Rechtsgrundlage und Mandat schriftlich fest; erfassen Sie die Daten (SEC-018) und klassifizieren Sie das System nach der KI-Verordnung (SEC-022), bevor Sie modellieren.
2. Beginnen Sie mit Fehlern und Datenqualität (Plausibilitätsprüfungen, vorausgefüllte Formulare) statt mit Betrugsbewertung; messen Sie die tatsächliche Fehlerrate mit einer Zufallsstichprobe.
3. Legen Sie eine Positivliste der Merkmale mit rechtlicher Begründung fest; verbieten Sie Staatsangehörigkeit, ethnische Herkunft, Religion, Postleitzahl und Proxys der Haushaltsstruktur und testen Sie mit Fairlearn auf verbleibende Proxys.
4. Bauen Sie ein erklärbares Modell (Boosting + Begründungscodes), führen Sie einen Pilot mit Sachbearbeitenden durch, die übersteuern dürfen, und behalten Sie eine Kontrollgruppe.
5. Schließen Sie DSFA und FRIA ab und richten Sie ein Prüfprotokoll, einen Beschwerdekanal und eine unabhängige Prüfung ein, bevor Sie skalieren.

Quellen

1. Amnesty International — Xenophobic machines: Dutch child benefit scandal — https://www.amnesty.org/en/latest/news/2021/10/xenophobic-machines-dutch-child-benefit-scandal/
2. Lighthouse Reports — The Algorithm Addiction (SyRI, childcare benefits, Overvecht profiling) — https://www.lighthousereports.com/investigation/the-algorithm-addiction/
3. Amnesty International — Denmark: AI-powered welfare system fuels mass surveillance (12 Nov 2024) — https://www.amnesty.org/en/latest/news/2024/11/denmark-ai-powered-welfare-system-fuels-mass-surveillance-and-risks-discriminating-against-marginalized-groups-report/
4. Lighthouse Reports / Svenska Dagbladet — Sweden's Suspicion Machine (27 Nov 2024) — https://www.lighthousereports.com/investigation/swedens-suspicion-machine/
5. Fairlearn project — https://fairlearn.org/
6. AI Act Annex III (point 5) — https://artificialintelligenceact.eu/annex/3/
7. AI Act Article 6 (classification, derogation, profiling) — https://artificialintelligenceact.eu/article/6/
8. European Commission — Guidelines on prohibited AI practices (4 Feb 2025) — https://digital-strategy.ec.europa.eu/en/library/commission-publishes-guidelines-prohibited-artificial-intelligence-ai-practices-defined-ai-act
9. AI Act Article 27 (fundamental rights impact assessment) — https://artificialintelligenceact.eu/article/27/
10. AI Act Article 5 (prohibited practices) — https://artificialintelligenceact.eu/article/5/
11. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj