FeedOracle Trust Infrastructure

Anti-Halluzinations-Layer
für regulierte Finanzen

Wenn KI in Banken und Versicherungen entscheidet, reicht „Vertrau uns" nicht.
Wir messen, beweisen und signieren jeden Tool-Aufruf — kryptografisch, anbieter-neutral, regulator-tauglich.

DORA MiCA BaFin-tauglich Provider-neutral

Ausgangslage

Banken vertrauen KI nicht — zu Recht

Drei Realitäten, mit denen jeder CRO heute arbeitet:

Halluzination

KI erfindet Fakten, die plausibel klingen aber falsch sind.

„USDT ist MiCA-autorisiert" — ist es nicht.

Keine Beweiskette

KI sagt „ich habe das Tool aufgerufen" — keiner kann das prüfen.

Audit Trail bricht an der wichtigsten Stelle ab.

Regulator wartet

DORA Art. 17, BaFin RS 10/2017, MaRisk: Verlangen forensisch saubere Belege.

Mit klassischer KI nicht erreichbar.

„Wir benutzen KI gerne — aber nicht für Entscheidungen, die der Prüfer eines Tages sehen wird."

— Sentenz aus 12 Pilotgesprächen mit Compliance-Verantwortlichen, Q1 2026

Empirische Grundlage

Wir haben es nicht vermutet — wir haben es gemessen

233

kontrollierte Test-Runs

LLM-Anbieter im Vergleich

FeedOracle MCP-Server

100%

reproduzierbar

Methodik

Identische Aufgaben in allen drei LLMs. Wir loggen am Server, was über das Netzwerk wirklich angefragt wird — und vergleichen mit dem, was im LLM-Antwort-Stream gemeldet wird.

Servers: mcp.feedoracle.io · Gateway-IP geloggt · TCP-Captures verfügbar · 233 JSON-Artefakte archiviert.

Das Ergebnis ist unangenehm — aber für Compliance-Verantwortliche das wichtigste KI-Finding 2026.

Das Ergebnis

Was die LLMs sagen vs. was am Server passiert

Anbieter	Stream meldet Tool-Call	Server sieht echten HTTP-Call	Audit-Lücke
Anthropic Claude MCP Connector	✓ Ja	✓ Ja, beobachtet	Konsistent
OpenAI Responses API MCP	✓ Ja	✓ Ja, beobachtet	Konsistent
xAI Grok Remote MCP (xai-sdk)	✓ Ja, „completed"	✗ Nein, nicht beobachtet	Reported ≠ Reality

Konkret bei einem Anbieter:

Der LLM-Antwortstrom meldet dem Nutzer „Tool aufgerufen, hier das Ergebnis".
Auf unseren Servern kommen initialize und tools/list an — der eigentliche tools/call aber nie.

Der Schock-Test

Wir haben den Server explizit blockiert

Server gibt absichtlich HTTP 503 zurück, wenn der Tool-Call kommt. tools/list bleibt erreichbar. Was machen die LLMs?

Anthropic + OpenAI

Erkennen den Server-Fehler
Melden „Tool execution failed" an den User
Audit-Trail bleibt ehrlich

→ Verhalten regulator-tauglich

xAI Grok

Liefert dem User „Tool aufgerufen, completed"
Server sah keinen einzigen tools/call
Audit-Trail meldet Vollzug ohne Vollzug

→ In regulierten Branchen K.O.

Wir haben xAI vorab informiert. Anbieter-Namen sind in der finalen Studie geschwärzt.

Warum das ein DORA-Problem ist

Compliance-Bedeutung in einem Satz

Es gibt einen prüfungsrelevanten Unterschied zwischen
„das Modell hat einen Tool-Aufruf gemeldet"
und
„der Server hat den Aufruf beobachtet, geloggt, signiert und kann ihn beweisen".

DORA Art. 17

ICT-bezogene Vorfälle müssen lückenlos belegt sein.

BaFin RS 10/2017

MaRisk: Auslagerung an Externe muss prüfbar dokumentiert sein — auch an KI.

MiCA Art. 70

CASPs müssen Empfehlungs-Entscheidungen nachweisen können.

Klassische LLM-Audit-Logs reichen nicht — der Stream ist kein verlässlicher Zeuge.

Die Lösung

Drei Schichten zwischen KI-Aussage und verifiziertem Output

VOR dem Tool-Aufruf · TrustOracle Semantischer Faktencheck: Vergleich gegen Live-Evidenz. Erkennt absolute Sprache („garantiert", „immer", „100%") und faktisch verdächtige Claims. Confidence-Schwelle entscheidet: proceed / caution / abstain / escalate.

WÄHREND des Tool-Aufrufs · Grounding Receipts Server emittiert pro Tool-Call einen kryptografisch signierten Beleg (ES256K). Beleg enthält Hash der Eingabe, Hash der Ausgabe, Server-Identität, Zeitstempel. Provider-neutral — funktioniert mit jedem LLM.

NACH dem Tool-Aufruf · verify_tool_usage Forensische Self-Check-Primitive: Existiert das Tool wirklich? Ist die Hash-Form gültig? Passt es zu bekannten Halluzinations-Signaturen? Ergebnis pro Behauptung: REAL / HALLUCINATED / UNVERIFIABLE.

Drei unabhängige Schichten. Keine kann von der KI umgangen werden.

Kernstück

Was ein Grounding Receipt enthält

Ein Beleg pro Tool-Call. ~500–1000 Bytes. Verifizierbar mit nur dem öffentlichen Schlüssel.

{
  "receipt_version": "0.1",
  "call_id":         "fo-rcpt-7f3a8b9c1d2e",
  "tool":            "mica.peg_deviation",
  "server_url":      "https://mcp.feedoracle.io",
  "server_did":      "did:web:feedoracle.io",
  "input_hash":      "sha256:a3f8d2...c91b",
  "output_hash":     "sha256:7e2c5a...4d9f",
  "observed_at":     "2026-04-29T14:32:11.847Z",
  "observed_ip":     "34.238.102.218",
  "observed_auth":   "x-api-key",
  "verdict":         "executed",

  "billing":  { "wallet_id": "w_da52...", "credits_charged": 5,
                "tier": "pro", "x402_tx": "0xabc..." },
  "anchor":   { "ledger_id": "mesh-economics-v1", "entry_id": 1842,
                "prev_hash": "sha256:..." },

  "signature": {
    "alg":       "ES256K",
    "kid":       "feedoracle-mcp-es256k-1",
    "jwks_url":  "https://feedoracle.io/.well-known/jwks.json",
    "sig":       "MEUCIQDx8nF...kAsB",
    "signed_at": "2026-04-29T14:32:11.892Z"
  }
}

Verifizierbar — von jedem

Auch der Wirtschaftsprüfer kann es nachrechnen

Vier öffentliche Endpunkte

GET /receipts/jwks.json
Öffentlicher Schlüssel zum Verifizieren

GET /receipts/{call_id}
Einzelnen Beleg abrufen

GET /receipts/{call_id}/chain
Vollständige Beweis-Kette

POST /receipts/verify
Unabhängige Verifikation

So prüft ein externer Auditor

JWKS holenvom öffentlichen Endpoint

Canonical Formnach RFC 8785 rekonstruieren

Signatur prüfenECDSA ES256K

Optional: On-Chain-Ankerauf Polygon prüfen

Niemand muss FeedOracle vertrauen. Mathematik ersetzt Vertrauen.

Strategischer Vorteil

Anbieter-neutral — funktioniert mit jedem LLM

Anthropic Claude

Receipts werden inline in der MCP-Antwort mitgeschickt unter _meta.grounding_receipt

OpenAI

Identisches Verhalten. Optional via Retrieval-API nachträglich abrufbar.

xAI Grok & andere

Receipts werden trotzdem ausgestellt. Wenn der Provider den Tool-Call wirklich macht, kommt ein Receipt zurück. Wenn nicht — keiner. Das ist die Lücke, die wir schließen.

Was das für regulierte Kunden bedeutet

Sie wählen LLM-Anbieter nach Qualität und Preis — nicht nach „welcher hat den besten Audit-Trail". Die Beweislast liegt bei FeedOracle. Provider können wechseln, der Audit-Layer bleibt.

Was es heute außerhalb FeedOracle nicht gibt

Stand der Technik bei den großen Anbietern

Feature	Anthropic	OpenAI	xAI	FeedOracle
Tool-Call wird ausgeführt wenn behauptet	✓	✓	teils	✓
Server-signierter Ausführungsbeweis	✗	✗	✗	✓ ES256K
Öffentlich verifizierbar (JWKS)	✗	✗	✗	✓
On-Chain-Verankerung möglich	✗	✗	✗	✓ Polygon
Forensische Halluzinations-Erkennung	✗	✗	✗	✓ verify_tool_usage
Provider-neutral	—	—	—	✓

Anthropic, OpenAI und xAI bauen großartige Modelle. Niemand baut den Beweis-Layer dazwischen — wir schon.

Konkretes Beispiel

Halluzination in Aktion — und wie wir sie stoppen

ohne FeedOracle

KI sagt:

„USDT ist gemäß MiCA reguliert und für institutionelle Verwahrung freigegeben."

Realität: USDT hat keine MiCA-Autorisierung. Tether ist nicht in der ESMA-Liste der zugelassenen E-Geld-Token.

Konsequenz: Falsche Compliance-Entscheidung. Im Prüfungsfall: Verwarnung oder schlimmer.

mit FeedOracle

System antwortet:

{
  "status": "unverified",
  "confidence": 25,
  "red_flags": [
    "Factually suspect claim:
     'USDT MiCA-authorized'"
  ],
  "ground_truth_check": {
    "esma_register":  "not_listed",
    "mica_status":    "no_authorization"
  },
  "recommended_action": "escalate"
}

Konsequenz: Aussage wird blockiert, Compliance-Officer entscheidet — vor Schaden.

Architektur

Vollständiger Daten- und Beweis-Fluss

Drei Schichten · Ein Verifikations-Pfad · Anbieter-neutral

Vorher / Nachher

Die Beweis-Lücke — und ihre Schließung

Wer das gebaut hat

Forschung trifft Produktion

Empirische Grundlage

233 kontrollierte Tests gegen 3 Anbieter
Methodik-Dokument verfügbar
tcpdump-Captures archiviert
Per-Run JSON-Artefakte (vollständig)

Produktiv im Einsatz

98 MCP-Server live
1.151 verfügbare Tools
23 DORA-Compliance-Module
x402 Pay-per-Call Gateway aktiv

Geplante Veröffentlichung

Neutraler technischer Bericht in ca. 30 Tagen — Messmethodik, Receipt-Spezifikation, regulatorischer Kontext. xAI, OpenAI und Anthropic wurden vorab informiert. Wir sind nicht auf Bug-Bounty aus — wir wollen, dass das Ökosystem prüfbar wird.

Nächste Schritte

Drei Wege, das selbst zu prüfen

15 Minuten

Live-Demo

Wir rufen ein Tool auf, Sie prüfen den Receipt mit Ihrem eigenen Tool gegen unser JWKS.

90-Tage-Pilot

Integration

Wir verbinden FeedOracle mit Ihrem System. Sie sehen täglich, was die KI behauptet — und was sie wirklich getan hat.

Whitepaper

Methodik & Daten

Vollständige 233-Run-Studie inkl. Reproduktions-Anleitung. NDA-frei verfügbar.

Murat Keskin · CEO FeedOracle Technologies

feedoracle.io · tooloracle.io · mcp.feedoracle.io

Anti-Halluzinations-Layerfür regulierte Finanzen

Banken vertrauen KI nicht — zu Recht

Halluzination

Keine Beweiskette

Regulator wartet

Wir haben es nicht vermutet — wir haben es gemessen

Methodik

Was die LLMs sagen vs. was am Server passiert

Konkret bei einem Anbieter:

Wir haben den Server explizit blockiert

Anthropic + OpenAI

xAI Grok

Compliance-Bedeutung in einem Satz

DORA Art. 17

BaFin RS 10/2017

MiCA Art. 70

Drei Schichten zwischen KI-Aussage und verifiziertem Output

Was ein Grounding Receipt enthält

Auch der Wirtschaftsprüfer kann es nachrechnen

Vier öffentliche Endpunkte

So prüft ein externer Auditor

Anbieter-neutral — funktioniert mit jedem LLM

Anthropic Claude

OpenAI

xAI Grok & andere

Was das für regulierte Kunden bedeutet

Stand der Technik bei den großen Anbietern

Halluzination in Aktion — und wie wir sie stoppen

KI sagt:

System antwortet:

Vollständiger Daten- und Beweis-Fluss

Die Beweis-Lücke — und ihre Schließung

Forschung trifft Produktion

Empirische Grundlage

Produktiv im Einsatz

Geplante Veröffentlichung

Drei Wege, das selbst zu prüfen

Live-Demo

Integration

Methodik & Daten

Anti-Halluzinations-Layer
für regulierte Finanzen