Prämien und Auszahlungen

Warum das zählt

Prämien und Auszahlungen erfordern das VDP-Add-on (49 $/Monat). Damit schalten Sie die vollständige Auszahlungspipeline, das unveränderliche Finanzhauptbuch und die auf dieser Seite beschriebene Verwaltung von Steuerdokumenten frei.

Korrekte Auszahlungen sind sowohl eine Frage der Forscherbindung als auch eine Compliance-Pflicht. Manuelle PayPal-Überweisungen ohne Einholung von W-8BEN- (Nicht-US) oder W-9-Formularen (US) schaffen für Ihr Unternehmen ein unmittelbares Haftungsrisiko gegenüber der IRS. Jede Zahlung an einen Forscher ist ein meldepflichtiger steuerbarer Vorgang, und fehlende Steuerdokumente verlagern die Haftung auf Sie. Die Auszahlungspipeline von Kit löst dies, indem sie Auszahlungen an eine konfigurierbare Bereitschafts-Checkliste bindet, die auch die Prüfung der Steuerdokumente umfasst.

Das unveränderliche Finanzhauptbuch ist der primäre SOC 2-Nachweis für die Finanzkontrollen Ihres Vulnerability-Disclosure-Programms. Jede Prämiengenehmigung, jede Auszahlung und jede Aktion an einem Steuerdokument wird mit Akteur, Zeitstempel und Betrag erfasst. Prüfer können die vollständige Nachweiskette von der Behebung der Meldung bis zur Zahlungsbestätigung in einem einzigen Export nachvollziehen.

Prämienmatrix

Die Prämienmatrix ordnet CVSS-Schweregraden Dollarspannen zu. Konfigurieren Sie sie unter VDP > Programmeinstellungen > Prämienmatrix. Wenn ein Teammitglied eine Meldung mit einer CVSS-Bewertung versieht, wird die vorgeschlagene Prämienspanne automatisch aus der Matrix übernommen und im Genehmigungsformular vorausgefüllt.

Prämienspannen werden auf Ihrer öffentlichen Disclosure-Policy-Seite angezeigt, damit Forscher schon vor der Einreichung wissen, was sie erwartet. Diese Transparenz reduziert Streitfälle und setzt klare Erwartungen.

Für reine Anerkennungsprogramme belassen Sie alle Schweregrade bei 0 $. Forscher sehen dann auf der Policy-Seite „nur Anerkennung“ anstelle von Dollarbeträgen.

Siehe Ihr Programm konfigurieren für alle Details zur Matrixkonfiguration.

Zwei Wege zu einem Betrag

Zu einer genehmigten Prämie führen zwei Wege, und beide enden bei derselben unumkehrbaren Aktion.

Weg	So funktioniert er	Wann er passt
Direkte Genehmigung	Ein Admin gibt einen Betrag ein und genehmigt ihn. Ein Schritt. Unten beschrieben.	Der Betrag ist offensichtlich – eine Meldung mit niedrigem Schweregrad am unteren Rand ihrer Matrix-Spanne, ein Fund nahe am Duplikat, alles, worüber niemand streiten würde.
Vorschlagen, dann genehmigen	Ein beliebiges Teammitglied legt einen Betrag mit Begründung auf den Tisch. Kollegen stimmen zu oder wenden mit Gegenvorschlägen ein. Ein Admin genehmigt anschließend.	Der Betrag ist strittig, ungewöhnlich hoch oder setzt einen Präzedenzfall, an dem man Sie bei der nächsten Meldung messen wird.

Vorschläge sind beratend und für den Forscher unsichtbar: Nichts an einem Vorschlag benachrichtigt den Forscher, schreibt ins Hauptbuch oder bewegt Geld. Sie blockieren auch nichts – ein Admin kann jederzeit direkt genehmigen, ob ein Vorschlag offen ist oder nicht. Siehe Prämienvorschläge und Abstimmung im Team.

Eine Prämie genehmigen

Administratoren können eine Prämie zu jedem Zeitpunkt genehmigen, bevor die Meldung den Status Paid erreicht. Als bewährte Vorgehensweise warten Sie, bis die Meldung validiert – idealerweise behoben – ist, damit der Betrag eine bestätigte, bewertete Schwachstelle widerspiegelt.

So genehmigen Sie eine Prämie:

1. Öffnen Sie die Detailseite der Meldung
2. Klicken Sie auf Prämie genehmigen
3. Füllen Sie das Genehmigungsformular aus

Feld	Erforderlich	Beschreibung
Betrag	Ja	Prämienbetrag, vorausgefüllt aus der Prämienmatrix anhand des CVSS-Schweregrads der Meldung.
Währung	Ja	Standardmäßig USD. Muss mit der konfigurierten Währung Ihres Programms übereinstimmen.
Notizen	Nein	Interne Notizen, die nur für Ihr Team sichtbar sind. Verschlüsselt gespeichert.

Die Genehmigung erfordert ein ausdrückliches Absenden – kein Betrag wird festgeschrieben, bis Sie das Formular speichern. Bei Genehmigung:

• Ein bounty_approved-Eintrag wird dem unveränderlichen Hauptbuch angefügt
• Der Forscher wird über die E-Mail-Vorlage Prämie genehmigt benachrichtigt
• Ein offener Prämienvorschlag auf der Meldung wird als ersetzt geschlossen; seine Stimmen bleiben als Protokoll erhalten

Der letzte Punkt verdient Beachtung, wenn Ihr Team mit Vorschlägen arbeitet: Wer direkt genehmigt, während ein Vorschlag offen ist, zahlt den eingetippten Betrag – nicht den, über den das Team gerade beriet – und beendet die Beratung. Genehmigen Sie stattdessen über den Prämien-Tab der Meldung, wenn Sie den vorgeschlagenen Betrag wollen.

Eine Prämie widerrufen

Wird eine Meldung mit genehmigter Prämie abgelehnt, wird die Prämie automatisch widerrufen. Das Ablehnungs-Modal warnt Sie mit Betrag, Genehmiger und Genehmigungsdatum, und die Absende-Schaltfläche ändert sich zu Ablehnen & Prämie über X $ widerrufen. Beim Widerruf:

• Ein bounty_revoked-Eintrag wird dem unveränderlichen Hauptbuch als Belastung angefügt – die Summen genehmigter und ausstehender Prämien im Hauptbuch ziehen ihn ab. Die Metadaten des Eintrags erfassen den Ablehnungsgrund, den ursprünglichen Genehmiger samt Genehmigungsdatum und den Auszahlungsstatus zum Zeitpunkt des Widerrufs.
• Die Ablehnungs-E-Mail an den Forscher weist darauf hin, dass die zuvor genehmigte Prämie zurückgezogen wurde und nicht ausgezahlt wird; der reguläre Einspruchsweg ist der vorgesehene Rechtsbehelf. Im Portal des Forschers erscheint statt der Prämienkarte ein Hinweis „zurückgezogen“.
• Das für die Prämie vergebene Karma wird mit einem Karma-Ereignis „Prämie widerrufen“ rückgängig gemacht.

Zwei Schutzmechanismen gelten:

• Eine Prämie, deren Auszahlung Completed ist, kann niemals widerrufen werden – bezahlt bleibt bezahlt.
• Eine laufende Auszahlung (Status Pending oder Processing) blockiert die Ablehnung. Markieren Sie die Auszahlung zuerst als fehlgeschlagen oder lassen Sie sie abschließen. Nur eine Auszahlung im Status Processing lässt sich als fehlgeschlagen markieren – Pending ist ein Übergangszustand von unter einer Sekunde (siehe Auszahlungsstatus), kein Zustand, in dem Sie handeln können.

Das Rückgängigmachen einer Ablehnung stellt die Prämie nicht wieder her. Sobald die Meldung erneut validiert ist, genehmigen Sie manuell eine neue Prämie – die Oberfläche zeigt einen entsprechenden Hinweis.

Auszahlungspipeline

Navigieren Sie zu VDP > Auszahlungen, um Auszahlungen zu verwalten. Die Warteschlange öffnet sich mit einer Reihe von Tabs, sodass Sie stets den Ausschnitt der Arbeit sehen, der Sie interessiert: Bereit, Blockiert, Bei der Finanzabteilung, Bezahlt, Fehlgeschlagen und Alle. Standardmäßig landen Sie im Tab Bereit.

Am oberen Rand verlaufen vier Übersichtskacheln:

• Bereit – Meldungen mit genehmigter Prämie und noch ohne Auszahlung, bei denen die Bereitschafts-Checkliste erfüllt ist und das Geld jetzt fließen kann.
• Blockiert – Meldungen mit genehmigter Prämie und noch ohne Auszahlung, bei denen die Bereitschafts-Checkliste noch nicht erfüllt ist.
• In Bearbeitung – Auszahlungen, die bereits an die Finanzabteilung übergeben wurden und auf Bestätigung warten.
• Am längsten wartend – die einzelne älteste genehmigte Prämie, die noch aussteht und nicht ausgezahlt ist. Sie zeigt, wie viele Tage sie bereits gewartet hat, den Forscher und den Betrag, und verlinkt direkt zu dem Tab, in dem diese Zeile liegt, damit Sie darauf reagieren können.

Beträge in unterschiedlichen Währungen werden niemals zusammengezählt. Jede Kachel zeigt die Beträge je Währung, sodass ein Programm, das in USD und EUR zahlt, beide Summen nebeneinander sieht statt einer sinnlosen Gesamtsumme.

Die Tabs Bereit und Blockiert sind die beiden Hälften derselben Menge – Meldungen mit genehmigter Prämie, aber noch ohne Auszahlung – aufgeteilt danach, ob die Bereitschafts-Checkliste erfüllt ist.

Bereitschafts-Checkliste

Bevor eine Auszahlung erfolgen kann, muss der Forscher eine Bereitschafts-Checkliste erfüllen. Alle drei Punkte sind in den Auszahlungseinstellungen Ihres Programms konfigurierbar:

• Auszahlungsinformationen eingereicht – Der Forscher hat seine Zahlungsdaten (Bank, PayPal oder andere Methode) über das Forscherportal eingegeben
• Vereinbarung akzeptiert – Der Forscher hat die Teilnahmevereinbarung Ihres Programms akzeptiert (falls Ihr Programm eine voraussetzt)
• Steuerdokument verifiziert – Das W-8BEN oder W-9 des Forschers wurde hochgeladen und von Ihrem Team verifiziert (falls Ihr Programm Steuerdokumente voraussetzt)

Punkte, die in Ihren Programmeinstellungen nicht aktiviert sind, werden automatisch als erfüllt markiert.

Die Checkliste richtet sich außerdem nach dem Status der Meldung, gesteuert über Geprüfte Behebung vor Auszahlung verlangen unter VDP > Programmeinstellungen > Auszahlungen:

• Ein (Standard) – Die Prämie kann erst ausgezahlt werden, nachdem Ihr Team die Behebung der Meldung als geprüft markiert hat. So zahlen Sie nie für einen ungelösten Fehler, doch Forscher müssen unter Umständen warten, bis die Behebung ausgeliefert ist.
• Aus (Auszahlung bei Validierung) – Die Auszahlung wird freigeschaltet, sobald die Meldung den Status Validated erreicht – der Branchenstandard auf Plattformen wie HackerOne und Bugcrowd. Forscher werden schneller bezahlt, und die Zahlung ist vom Schließen der Meldung entkoppelt: Die Meldung bleibt nach der Geldbewegung offen und schließt automatisch als Paid, sobald sie behoben (oder ihre Behebung geprüft) ist. Bezahlte Meldungen können niemals abgelehnt werden, und die Prüfung der Behebung wird zu einem optionalen QA-Schritt – erfassen Sie sie, bevor die Meldung behoben wird, sonst wird sie nicht festgehalten.

Das Nachfass-Board

Der Tab Blockiert ist ein Nachfass-Board: Statt einer flachen Liste festhängender Auszahlungen gruppiert er blockierte Auszahlungen nach Forscher, sodass Sie eine Person einmal erinnern, statt derselben Person über mehrere Zeilen hinweg hinterherzulaufen. Anonyme Einreichungen, zu denen kein Forscher hinterlegt ist, bilden ihre eigene Gruppe ohne Forscher.

Jede Gruppe zeigt:

• Den Forscher (oder „anonym“ bei der Gruppe ohne Forscher)
• Wie viele ihrer Auszahlungen blockiert sind
• Den geschuldeten Gesamtbetrag, je Währung
• Welche Blocker gelten, als Blocker-Chips: Auszahlungsinformationen, Steuerdokument und Vereinbarung
• Wie viele Tage die älteste Auszahlung der Gruppe bereits gewartet hat

Die Gruppen sind nach fälliger Erinnerung zuerst sortiert – die Forscher, die Sie gerade jetzt erinnern können, stehen oben – und innerhalb dessen nach der längsten Wartezeit zuerst.

Jede Gruppe gibt außerdem an, wie viel eine Erinnerung tatsächlich freigeben würde – als Angabe „gibt N Auszahlungen / X $ frei“. Diese Zählung ist bewusst ehrlich: Sie zählt nur Meldungen, bei denen jeder verbleibende erforderliche Punkt etwas ist, das der Forscher selbst erledigen kann (Auszahlungsinformationen, Steuerdokument, Vereinbarung). Eine Meldung, die noch auf die Prüfung der Behebung wartet – ein Schritt, der Ihrem Team obliegt –, wird nicht mitgezählt, weil eine E-Mail an den Forscher sie nicht freigibt. Die Zahl spiegelt wider, was eine Erinnerung wirklich freischalten kann, nicht Wunschdenken.

Einen Forscher erinnern

Klicken Sie im Tab Blockiert bei einer Forschergruppe auf Erinnern, um diesem Forscher eine Erinnerung per E-Mail zu senden. Das Erinnern erfordert das VDP-Add-on und die Auszahlungsberechtigung (disburse).

Eine E-Mail pro Forscher deckt alle seine aktuellen Lücken auf einmal ab – Auszahlungsinformationen, Steuerdokument und jede meldungsbezogene Vereinbarung – statt eine separate E-Mail je Blocker zu senden. Der Forscher erhält eine einzige, vollständige Aufgabenliste.

Jeder Blocker in der E-Mail ist ein Deep-Link mit Magic Link. Ein Klick authentifiziert den Forscher und bringt ihn genau auf die Seite, die diese Lücke schließt: das Formular für die Auszahlungsinformationen, den Upload des Steuerdokuments oder die Vereinbarung der jeweiligen Meldung. Da das Token zustandslos ist, bleibt der bestehende Magic Link zur Anmeldung des Forschers gültig – eine Erinnerung macht ihn niemals ungültig.

Erinnerungen werden durch eine Abklingzeit von 3 Tagen je (Konto, Forscher) gedrosselt. Haben Sie diesen Forscher bereits innerhalb des Zeitfensters erinnert, meldet die Schaltfläche, dass sie sich in der Abklingzeit befindet, statt erneut zu senden. Die Abklingzeit ist mandantenbezogen: Die Erinnerung eines Kunden wirkt sich niemals auf die eines anderen aus, selbst bei einem Forscher, der an mehrere Programme meldet.

Erinnern erscheint nur, wenn der Forscher tatsächlich etwas freigeben kann. Lücken auf Meldungsebene – Prämiengenehmigung, Validierung und Prüfung der Behebung – sind Aufgabe Ihres Teams und lösen niemals eine Erinnerung aus; eine Erinnerung wird ausschließlich für vom Forscher behebbare Punkte angeboten.

Eine Auszahlung verarbeiten

Kit führt keine Überweisungen oder Payment-API-Aufrufe durch. Ihr Team wickelt die eigentliche Geldbewegung außerhalb von Kit ab (Banküberweisung, PayPal, Krypto usw.). Kit verfolgt den Lebenszyklus:

1. Sobald alle Bereitschaftspunkte erfüllt sind, klicken Sie auf Einleiten, um die Auszahlung in den Status Processing zu verschieben
2. Führen Sie die Überweisung über Ihren Zahlungsanbieter durch
3. Kehren Sie zu Kit zurück und klicken Sie auf Als bezahlt markieren – geben Sie die Transaktionsreferenz ein (z. B. PayPal-Transaktions-ID, Überweisungsbestätigungsnummer)
4. Die Auszahlung wechselt zu Completed und die Meldung geht in den Status Paid über (bei Programmen mit Auszahlung bei Validierung bleibt eine vor ihrer Behebung bezahlte Meldung offen und schließt automatisch als Paid, sobald sie behoben ist)

Bestätigung durch das Finanzteam

In den meisten Unternehmen sitzt die Person, die die Zahlung veranlasst, in der Finanzabteilung und nicht in der Sicherheit – sie überwacht ein Postfach wie [email protected] und hat kein Kit-Konto. Die Übergabe an die Finanzabteilung schließt diese Lücke: Kit schickt Ihrem Finanzteam alles, was es zur Veranlassung der Zahlung braucht, und das Team bestätigt sie selbst über einen sicheren Link.

Aktivieren Sie dies, indem Sie unter VDP > Programmeinstellungen > Auszahlungen eine Finanz-E-Mail festlegen. Lassen Sie das Feld leer, um Zahlungen weiterhin manuell in Kit zu erfassen.

Ist eine Finanz-E-Mail konfiguriert, löst ein Klick auf Einleiten zusätzlich eine Zahlungsanforderung an diese Adresse aus, die Folgendes enthält:

• Den Zahlungsempfänger (Forscher), den Betrag und die Zahlungsmethode – PayPal-Adressen werden vollständig angezeigt; Bankkontonummern werden bis auf die letzten vier Ziffern maskiert, die vollständigen Angaben sind nur hinter dem Bestätigungslink einsehbar
• Die Auszahlungsreferenz für den Verwendungszweck der Zahlung, damit der Abgleich in beide Richtungen funktioniert
• Die Genehmigungsherkunft: wer die Prämie wann genehmigt und wer die Auszahlung eingeleitet hat
• Einen sicheren Link, der 90 Tage gültig ist und zwei Aktionen anbietet: die Zahlung bestätigen oder melden, dass sie fehlgeschlagen ist

Die Person aus der Finanzabteilung öffnet den Link, sieht die vollständigen Zahlungsangaben, führt die Zahlung über Ihren Zahlungsanbieter aus und gibt dann zur Bestätigung die Transaktionsreferenz und ihren Namen ein. Die Bestätigung schließt die Auszahlung genauso ab wie ein internes Als bezahlt markieren: Der Hauptbucheintrag wird geschrieben, die Meldung geht in den Status Paid über, der Forscher wird automatisch benachrichtigt, und Ihr Team erhält die übliche Benachrichtigung zur abgeschlossenen Auszahlung – darin ist die bestätigende Person aus der Finanzabteilung als diejenige genannt, die die Zahlung als bezahlt markiert hat. Die Bestätigung erfasst, wer bestätigt hat (Name und E-Mail), wann und von wo (IP-Adresse) – sichtbar in der Auszahlungszeile als Von Finanzabteilung bestätigt.

Geht die Zahlung nicht durch, bietet dieselbe Seite unter dem Bestätigungsformular einen Link Fehlgeschlagene Zahlung melden an. Damit wird der Fehlschlag mit identischer Herkunft erfasst – wer ihn gemeldet hat, wann und von wo –, und die Auszahlungszeile zeigt ihn als Zahlung fehlgeschlagen · Gemeldet von …. Siehe Wenn eine Auszahlung fehlschlägt.

Einige Details, die Sie kennen sollten:

• Antworten erreichen einen Menschen. Die Reply-to-Adresse der E-Mail ist das Teammitglied, das die Auszahlung eingeleitet hat, sodass Rückfragen aus der Finanzabteilung bei jemandem mit Kontext landen.
• Jederzeit erneut senden. Die Auszahlungszeile zeigt, wann und wohin die Anforderung gesendet wurde, samt einer Schaltfläche zum erneuten Senden, die einen neuen Link ausstellt.
• Der interne Ablauf bleibt verfügbar. Antwortet die Finanzabteilung per E-Mail mit „erledigt, Ref. #123“, statt zu klicken, kann Ihr Team die Auszahlung weiterhin manuell als bezahlt markieren – der Link zeigt dann eine Quittung „bereits erfasst“ an.
• Der Link erlischt mit der Auszahlung. Sobald sie abgeschlossen oder fehlgeschlagen ist, kann der Link nichts mehr bestätigen oder als fehlgeschlagen melden; er zeigt nur noch den aktuellen Status an. Ein über den Link gemeldeter Fehlschlag zeigt der Finanzabteilung ihre eigene Quittung – die meldende Person, das Datum, den Grund und den Hinweis, die Zahlung nicht erneut zu versuchen, weil eine neue Anforderung folgt.
• Eine Bestätigung durch die Finanzabteilung zählt als zweites Paar Augen. Da die Zahlung von außerhalb Ihres Kit-Teams bestätigt wurde, erhält der Genehmiger immer die Bestätigungsbenachrichtigung, und die unten beschriebene Stufe Zweiter Blick greift nie – jemand anderes als der Genehmiger hat die Zahlung bereits mitgetragen.
• Stornierungen werden angekündigt, wenn Ihr Team sie ausspricht. Wurde eine Zahlungsanforderung verschickt und markiert Ihr Team die Auszahlung später in Kit als fehlgeschlagen, erhält die Finanzabteilung vom selben gebrandeten Absender eine Benachrichtigung „Zahlung storniert – nicht ausführen“, damit niemand Geld für eine zurückgezogene Auszahlung überweist. Meldet die Finanzabteilung den Fehlschlag selbst über den Link, wird keine Benachrichtigung gesendet – sie hat ihn ja selbst gemeldet, und ihre Quittung sagt bereits, wie es weitergeht.

Wenn eine Auszahlung fehlschlägt

Kit bewegt niemals Geld und erfährt deshalb auch nie von selbst, dass eine Überweisung fehlgeschlagen ist. Jemand muss es aussprechen, und genau diese Aussage ist das Markieren einer Auszahlung als fehlgeschlagen. Es ist reine Buchführung: Es fließen keine Mittel, nichts wird erstattet, und die genehmigte Prämie bleibt unangetastet – der volle Betrag bleibt für den Forscher reserviert.

Zwei Personen können den Fehlschlag erfassen. Ihr Team nutzt Als fehlgeschlagen markieren in der Auszahlungszeile, was die Auszahlungsberechtigung (disburse) erfordert. Die Finanzabteilung nutzt den Link Fehlgeschlagene Zahlung melden auf der Bestätigungsseite – wer die Ablehnung der Bank gerade in der Hand hält, kann sie also erfassen, ohne sie erst zurück durch Ihr Team zu schleusen.

Beide Wege stellen dieselbe Frage mit denselben vier Antworten:

Grund	Was er für den Forscher auslöst
Der Empfänger kann derzeit keine Zahlungen annehmen	Der Forscher erhält eine E-Mail mit der Bitte um Auszahlungsinformationen, die funktionieren
Die Kontodaten passten zu keinem gültigen Konto	Der Forscher erhält eine E-Mail mit der Bitte um Auszahlungsinformationen, die funktionieren
Die Zahlung wurde ausgeführt, kam aber an uns zurück	Der Forscher erhält eine E-Mail mit der Bitte um Auszahlungsinformationen, die funktionieren
Etwas anderes	Kontaktiert niemanden – nur interne Klärung durch Ihr Team. Dieser Grund erfordert eine Notiz, denn diese Notiz ist alles, worauf sich Ihr Team später stützen kann

Die E-Mail zu den ersten drei Gründen nennt den Grund in den Worten des Forschers, bekräftigt, dass der volle Betrag weiterhin für ihn reserviert ist, und enthält einen Magic Link, der ihn direkt auf seine Auszahlungsseite bringt. Die Notiz zitiert sie nie: Was die Finanzabteilung oder Ihr Team eingetippt hat – eine Fehlermeldung aus dem Bankportal, eine interne Referenz – bleibt in Ihrem Team.

Anonyme Einreichungen haben keinen hinterlegten Forscher, deshalb ist keine E-Mail möglich, ganz gleich, welchen Grund Sie wählen.

Was Ihr Team sieht. Die Zeile wandert in den Tab Fehlgeschlagen der Warteschlange und trägt die ganze Geschichte: einen Chip Zahlung fehlgeschlagen mit dem Grund, Gemeldet von …, wenn die Finanzabteilung ihn erfasst hat, die eingetippte Notiz, Forscher um neue Auszahlungsinformationen gebeten, sobald diese E-Mail hinausging, und Neue Auszahlungsinformationen hinterlegt, sobald er antwortet. Die Zeitleiste der Meldung hält den Fehlschlag nur mit dem Grundcode fest – die Notiz gelangt nie in die Zeitleiste. Das Hauptbuch erhält einen disbursement_failed-Eintrag, der ebenfalls allein den Code trägt.

Erneut einreihen. Der erneute Versuch ist manuell und Ihrem Team vorbehalten – der Forscher kann ihn nicht auslösen. Die Schaltfläche Erneut versuchen sitzt in der fehlgeschlagenen Zeile und bleibt eine sekundäre Aktion, bis der Forscher neue Informationen hinterlegt hat; dann wird sie primär. Das ist ein Bereitschaftssignal und keine Dekoration: Ein Versuch vorher überweist nur wieder an dasselbe tote Konto.

Erneut versuchen stellt eine neue Zahlungsanforderung mit neuer Referenz und neuem Link aus. Der alte Bestätigungslink ist tot, und das Fehlschlagsdetail verlässt die Warteschlange zusammen mit dem Versuch, zu dem es gehörte – das Hauptbuch behält den Eintrag. Das präzisiert die oben beschriebene Referenz: Eine Referenz bezeichnet einen Versuch, nicht die Prämie – eine im zweiten Anlauf bezahlte Prämie wird also gegen die zweite Referenz abgeglichen.

stateDiagram-v2
    state "Processing" as Processing
    state "Failed" as Failed
    state "Forscher aktualisiert Auszahlungsinformationen" as Updated
    state "Processing (neue Auszahlung)" as Retried

    [*] --> Processing: Einleiten
    Processing --> Failed: Von Ihrem Team oder der Finanzabteilung als fehlgeschlagen markiert
    Failed --> Updated: E-Mail an den Forscher – nur bei den ersten drei Gründen
    Updated --> Retried: Erneut versuchen
    Retried --> [*]: Als bezahlt markieren

    note right of Retried
      Ein erneuter Versuch belebt die fehlgeschlagene
      Auszahlung nicht wieder. Er startet eine neue,
      deshalb sind alte Referenz und alter Link tot.
    end note

Benachrichtigungen zu abgeschlossenen Auszahlungen

Wird eine Auszahlung als bezahlt markiert, informiert Kit Ihr Team. Damit schließt sich die Lücke zwischen dem Genehmigen und dem tatsächlichen Auszahlen von Geld: Wer die Prämie genehmigt hat, erfährt von der Zahlung, ohne die Warteschlange im Auge behalten zu müssen.

Es gibt drei Stufen, und sie unterscheiden sich mit Absicht. Zwei sind rein informativ, eine nicht.

Stufe	Wer sie erhält	Wann sie ausgelöst wird	Abschaltbar?
Bestätigung	Das Teammitglied, das die Prämie genehmigt hat	Bei jeder abgeschlossenen Auszahlung, sofern die Person sie nicht selbst als bezahlt markiert hat	Ja
Zweiter Blick	Ihre Programm-Administratoren, außer der Person, die die Auszahlung als bezahlt markiert hat	Eine einzige Person hat dieselbe Prämie genehmigt, angepasst und ausgezahlt, und der Betrag ist wesentlich gestiegen	Ja
Abweichung im Hauptbuch	Der Genehmiger sowie alle Programm-Administratoren, außer der Person, die die Auszahlung als bezahlt markiert hat	Die an der Meldung hinterlegte Prämie und ihr Verlauf im Hauptbuch stimmen nicht mehr überein	Nein

Bestätigung ist der Normalfall und die Stufe, die Sie praktisch jedes Mal sehen. Der Genehmiger erhält eine kurze Mitteilung: wer die Prämie als bezahlt markiert hat, über welchen Betrag, wann und – falls erfasst – mit welcher Transaktionsreferenz. Wurde die Prämie zwischenzeitlich angepasst, nennt die Mitteilung die ursprüngliche Genehmigung und, davon getrennt, den angepassten Betrag samt der Person, die ihn angepasst hat. So lassen sich die Zahlen auf einen Blick abgleichen. Hat dieselbe Person die Prämie genehmigt und die Auszahlung abgeschlossen, wird nichts gesendet; niemand muss über sein eigenes Handeln informiert werden. Gehört der Genehmiger nicht mehr zu Ihrem Konto, geht die Bestätigung stattdessen an Ihre Programm-Administratoren, damit sich der Kreis dennoch schließt. Hier ist nichts zu tun: Es handelt sich um eine Quittung.

Zweiter Blick schließt die einzige Lücke, die die Bestätigungsstufe offenlässt. Weil eine Auszahlung, die der Genehmiger selbst abschließt, keine Benachrichtigung auslöst, könnte andernfalls eine einzelne Person eine kleine Prämie genehmigen, sie erhöhen und sich selbst auszahlen, ohne dass jemand davon erfährt. Diese Stufe stellt die Sichtbarkeit wieder her: Wenn die Genehmigung, jede Anpassung und die Zahlung von derselben Person vorgenommen wurden und der endgültige Betrag wesentlich höher liegt als der ursprünglich genehmigte, informiert Kit Ihre übrigen Programm-Administratoren.

„Wesentlich höher“ bemisst sich an den Einstellungen Ihres eigenen Programms, nicht an einer festen Zahl:

• In einem Programm mit Prämienmatrix gilt der Betrag als wesentlich, sobald er über dem ausgewiesenen Maximum für den bewerteten Schweregrad der Meldung liegt. Bewegungen innerhalb der Spanne, die Ihre Matrix ohnehin freigibt, sind Routine und lösen keine Benachrichtigung aus.
• In einem Programm ohne Matrix, das die Höhe nach eigenem Ermessen festlegt, gilt der Betrag als wesentlich, wenn er sich mindestens verdoppelt und um mindestens die Mindestauszahlung Ihres Programms gestiegen ist. Steht diese Untergrenze auf null, greift der Kit-Standard von 50 $. Beide Bedingungen müssen zutreffen: 500 $ → 550 $ löst deshalb nichts aus, 6 $ → 12 $ ebenfalls nicht, 6 $ → 600 $ dagegen schon.

Von dieser Wesentlichkeitsprüfung gibt es eine Ausnahme. Trägt eine Meldung eine Anpassung, die vor dem 5. Juni 2026 erfasst wurde, lässt sich ihre genehmigte Gesamtsumme nicht aus dem Hauptbuch rekonstruieren (siehe Anpassungseinträge richtig lesen). Kit kann dann nicht beurteilen, ob der Betrag wesentlich gestiegen ist. Eine im Alleingang abgewickelte Auszahlung zu einer solchen Meldung erhält die Benachrichtigung Zweiter Blick unabhängig von der Höhe, und zwar mit einem Wortlaut, der lediglich festhält, dass keine zweite Person beteiligt war – eine Erhöhung, die Kit nicht messen konnte, wird darin nie behauptet.

Senkungen lösen die Stufe nie aus, und routinemäßige Alleinarbeit ebenso wenig – ein korrigierter Zahlendreher, eine kleine Aufstockung. Das ist so gewollt. In vielen Programmen wickelt ein einziger aktiver Administrator jede Auszahlung völlig legitim von Anfang bis Ende ab, und eine Benachrichtigung zu jeder Korrektur würde alle daran gewöhnen, genau jene Benachrichtigung zu übersehen, die man niemals übersehen darf. Für solche Auszahlungen bleiben das Hauptbuch und die Zeitleiste der Meldung der Nachweis.

Der Wortlaut ist sachlich, nicht anklagend: wer was genehmigt hat, wer es auf welchen Betrag angepasst hat, wer es ausgezahlt hat, dazu ein Link zur Meldung. Es ist die Bitte an einen Kollegen, einen Blick auf den Vorgang zu werfen – kein Prüfergebnis und kein Vorwurf gegen die Person, die die Arbeit gemacht hat.

Eine Folge, die Sie einplanen sollten: Hat Ihr Programm nur einen einzigen Programm-Administrator und hat diese Person die Auszahlung als bezahlt markiert, bleibt für diese Stufe niemand übrig, der benachrichtigt werden könnte – es wird nichts gesendet. Hauptbuch und Zeitleiste sind dann Ihr einziger Nachweis. Das ist ein guter Grund, einen zweiten Programm-Administrator zu benennen.

Abweichung im Hauptbuch ist die Stufe, die bedeutet, dass tatsächlich etwas nicht stimmt. Sie wird ausgelöst, wenn der an der Meldung hinterlegte Prämienbetrag nicht mehr mit der Summe ihres Hauptbuchverlaufs übereinstimmt. Jeder Weg durch Kit schreibt die Prämie und ihren Hauptbucheintrag gemeinsam – Genehmigen, Anpassen und Widerrufen bewegen stets beides zugleich –, sodass dies im normalen Betrieb nicht vorkommen kann. Eine Abweichung deutet darauf hin, dass die zugrunde liegenden Daten außerhalb der Anwendung verändert wurden.

Diese Stufe lässt sich nicht abschalten. Sie ignoriert die E-Mail-Kategorien und enthält keinen Abmeldelink, denn ein Signal zur Integrität Ihrer Finanzaufzeichnungen darf nicht stummschaltbar sein. Sie geht an den Genehmiger und an alle Programm-Administratoren, damit die Abweichung stets auch jemandem sichtbar ist, der die Auszahlung nicht selbst abgeschlossen hat.

Erhalten Sie eine solche Benachrichtigung, wenden Sie sich an den Support – versuchen Sie nicht, die Beträge von Hand abzugleichen. Behandeln Sie sie genau wie einen Verstoß gegen die Integrität des Hauptbuchs.

Wie die Stufen Sie erreichen:

• In-App-Benachrichtigungen kommen immer an – bei allen drei Stufen und bei jedem auf der Empfängerliste. Das Glockensymbol richtet sich nicht nach den E-Mail-Einstellungen.
• E-Mails zu Bestätigung und Zweitem Blick gehören in den E-Mail- und Benachrichtigungseinstellungen zur Kategorie Sicherheitsprogramm-Aktivität und pausieren, solange Sie im Urlaubsmodus sind.
• E-Mails zu Abweichungen im Hauptbuch ignorieren die Kategorie, beachten aber den Urlaubsmodus. Dass sie an alle Programm-Administratoren gehen, stellt sicher, dass die Warnung jemanden erreicht, während der Genehmiger abwesend ist.

Auszahlungsstatus

Status	Bedeutung
Pending	Die Auszahlungszeile existiert, wurde aber noch nicht eingeleitet. Einleiten erstellt die Zeile und schiebt sie im selben Atemzug weiter – Pending ist also ein Übergangszustand von unter einer Sekunde und kein Warteschlangenstatus. Eine Prämie, die noch auf die Bereitschafts-Checkliste wartet, hat gar keine Auszahlung und liegt im Tab Blockiert
Processing	Ihr Team hat die Überweisung außerhalb von Kit eingeleitet
Completed	Geldeingang bestätigt; Transaktionsreferenz erfasst – die Meldung schließt als Paid, sobald ihr Lebenszyklus es zulässt
Failed	Die Überweisung ist nicht durchgegangen. Bei drei der vier Fehlschlagsgründe hat Kit den Forscher bereits um neue Auszahlungsinformationen gebeten – schreiben Sie ihm nicht noch einmal. Reihen Sie die Auszahlung mit Erneut versuchen wieder ein, sobald neue Informationen hinterlegt sind

Schlägt eine Auszahlung fehl, erhält das Hauptbuch einen disbursement_failed-Eintrag mit dem Grundcode – die eingetippte Notiz bleibt bewusst außen vor. Die Finanzabteilung erhält nur dann eine Stornierungs-E-Mail, wenn Ihr Team den Fehlschlag markiert hat und der Finanzabteilung bereits eine Zahlungsanforderung geschickt worden war; ein Fehlschlag, den die Finanzabteilung selbst gemeldet hat, löst nichts aus. Das erneute Einreihen ist ein manuelles Erneut versuchen in der fehlgeschlagenen Zeile, das zur primären Aktion der Zeile wird, sobald der Forscher funktionierende Informationen hinterlegt. Den vollständigen Ablauf beschreibt Wenn eine Auszahlung fehlschlägt.

Steuerdokumente

Forscher laden Steuerdokumente über ihr Portal hoch. In den USA ansässige Forscher reichen ein W-9 ein, Forscher außerhalb der USA ein W-8BEN. Dokumente werden verschlüsselt gespeichert.

Ihr Team prüft hochgeladene Dokumente unter VDP > Steuerdokumente:

Status	Aktion
Pending	Dokument hochgeladen, wartet auf Ihre Prüfung
Verified	Sie haben bestätigt, dass das Dokument gültig ist – der Bereitschaftspunkt ist erfüllt
Rejected	Sie haben das Dokument abgelehnt – der Forscher wird benachrichtigt und kann es erneut hochladen

Sowohl Verifizierung als auch Ablehnung werden zu Prüfzwecken im Hauptbuch erfasst. Steuerdokument-Ereignisse werden mit der zuletzt prämierten Meldung des Forschers verknüpft, um Kontext im Hauptbuch herzustellen.

Das Finanzhauptbuch

Navigieren Sie zu VDP > Finanzhauptbuch, um den unveränderlichen finanziellen Audit-Trail einzusehen. Das Hauptbuch lässt nur Anfügen zu: Einträge können nicht bearbeitet, geändert oder gelöscht werden.

Jeder Eintrag erfasst:

• Eintragstyp – was geschehen ist
• Betrag – Dollarbetrag in Cent und Währung
• Akteur – das Teammitglied, das die Aktion ausgeführt hat. Einträge von außerhalb Ihres Teams – eine über den Finanz-Link bestätigte Zahlung oder ein darüber gemeldeter Fehlschlag – haben keinen Kit-Benutzer hinter sich und erscheinen als System. Das ist beabsichtigt und keine Lücke: Der Name der Person aus der Finanzabteilung wird in der verschlüsselten Herkunft der Auszahlung festgehalten und in der Warteschlangenzeile als Gemeldet von … angezeigt
• Zeitstempel – wann der Eintrag erstellt wurde
• Meldungsreferenz – die verknüpfte Schwachstellenmeldung

Jeder Eintrag erfasst einen der folgenden Typen:

Eintragstyp	Wann er erstellt wird
bounty_approved	Ein Teammitglied genehmigt einen Prämienbetrag für eine Meldung
bounty_adjusted	Ein Teammitglied korrigiert den Prämienbetrag vor dem Versand der Zahlung. Erfasst wird die Veränderung, nicht die neue Gesamtsumme – siehe Anpassungseinträge richtig lesen
bounty_revoked	Eine Meldung mit genehmigter Prämie wird abgelehnt; der Widerruf zählt als Belastung gegen die Summen des Hauptbuchs
disbursement_initiated	Ein Teammitglied versetzt die Auszahlung in den Status Processing
disbursement_completed	Ein Teammitglied markiert die Auszahlung mit einer Transaktionsreferenz als Paid
disbursement_failed	Eine Auszahlung wird als fehlgeschlagen markiert. Der Eintrag trägt einen von vier festen Grundcodes; die Freitextnotiz bleibt bewusst außerhalb des Hauptbuchs – siehe Wenn eine Auszahlung fehlschlägt
tax_document_submitted	Ein Forscher lädt ein W-8BEN- oder W-9-Dokument hoch
tax_document_verified	Ein Teammitglied verifiziert ein Steuerdokument als gültig
tax_document_rejected	Ein Teammitglied lehnt ein Steuerdokument ab; der Forscher wird benachrichtigt und kann es erneut hochladen

Filtern Sie das Hauptbuch nach Meldungs-ID, Eintragstyp oder Datumsbereich, um die Ergebnisse einzugrenzen. Nutzen Sie den Export des Hauptbuchs unter Metriken und Exporte, um SOC 2-Nachweispakete zu erstellen.

Anpassungseinträge richtig lesen

bounty_adjusted ist der einzige Eintragstyp, dessen Betrag eine Veränderung und keine Gesamtsumme ist. Jeder andere Eintrag hält einen absoluten Wert fest – die genehmigte Prämie, die ausgezahlte Summe, den widerrufenen Betrag. Eine Anpassung erfasst nur die Differenz, die die Korrektur bewirkt hat, positiv oder negativ.

Beim Abgleich ist dieser Unterschied entscheidend. Wird eine Prämie von 6 $ auf 600 $ korrigiert, erfasst der bounty_adjusted-Eintrag 594 $: Das ist der Umfang der Korrektur, nicht eine zweite Prämie über 594 $. Als Gesamtsumme gelesen, kann eine einzelne Anpassung aus einer harmlosen Korrektur eine scheinbare Überzahlung machen.

Kit kennzeichnet Anpassungen deshalb überall ausdrücklich, damit Sie nie erraten müssen, welche Lesart gilt:

• Zeitleiste der Meldung – zeigt „Prämie angepasst auf 600 USD“, also die resultierende Gesamtsumme; der an der Meldung angezeigte Betrag ist damit die Prämie selbst.
• Hauptbuchseite – zeigt die Veränderung mit ausdrücklichem Vorzeichen: +594 $ bei einer Erhöhung, -594 $ bei einer Senkung. Ein vorangestelltes + bedeutet „der Betrag hat sich um diesen Wert verändert“.
• CSV-Export des Hauptbuchs – enthält die Veränderung, eine Spalte mit der Angabe, ob dieser Betrag eine Veränderung oder ein absoluter Wert ist, und eine Spalte mit der Gesamtsumme, auf die die Anpassung geführt hat.
• PDF-Export des Hauptbuchs und das Dossier-PDF der Meldung – geben die Veränderung mit Vorzeichen aus, dahinter die daraus entstandene Gesamtsumme, als +$594 USD -> $600 USD.
• Slack, wo Ihr Programm Auszahlungsereignisse postet – eine abgeschlossene Auszahlung zu einer angepassten Prämie nennt die ursprüngliche Genehmigung und die angepasste Gesamtsumme, nicht die Veränderung allein.

Um die aktuell genehmigte Prämie allein aus dem Hauptbuch zu rekonstruieren, nehmen Sie die Genehmigung, addieren jede danach erfasste Anpassung und ziehen einen etwaigen Widerruf ab. Diese Summe vergleicht Kit mit dem Betrag, der an der Meldung selbst hinterlegt ist (siehe Benachrichtigungen zu abgeschlossenen Auszahlungen).

Anpassungen, die vor dem 5. Juni 2026 erfasst wurden, stammen aus der Zeit vor diesem Schema: Sie enthalten einen absoluten Betrag und keinen Hinweis auf die Gesamtsumme, zu der sie geführt haben. Kit kennzeichnet sie abweichend, statt zu raten – in der Zeitleiste steht „Prämie angepasst um“, im CSV ist die Betragsart als unknown markiert, und die Spalte mit der resultierenden Gesamtsumme bleibt leer. Ein älterer Eintrag wird nie als etwas dargestellt, was er nicht belegen kann.

Integrität des Hauptbuchs

Eine tägliche Integritätsprüfung läuft automatisch, um die Konsistenz des Hauptbuchs zu verifizieren. Sie durchläuft alle Einträge in chronologischer Reihenfolge und führt einen laufenden Saldo mit – Gutschriften (bounty_approved, bounty_adjusted) erhöhen ihn, Belastungen (disbursement_completed, bounty_revoked) verringern ihn. Wird der laufende Saldo jemals negativ, wird der betreffende Eintrag als Verstoß markiert.

Dieser laufende Saldo prüft die Zahlungsfähigkeit; er ist eine andere Rechnung als die genehmigte Gesamtsumme aus Anpassungseinträge richtig lesen. Der laufende Saldo zieht zusätzlich abgeschlossene Auszahlungen ab, denn ausgezahltes Geld darf nicht länger als geschuldet gelten. Die genehmigte Gesamtsumme tut das nicht – eine ausgezahlte Prämie ändert nichts daran, was genehmigt wurde. Mit dem laufenden Saldo beantworten Sie die Frage, ob das Geld dieses Programms über die Zeit aufgeht; mit der genehmigten Gesamtsumme die Frage, was an dieser Meldung derzeit genehmigt ist.

Jeder Verstoß wird zur Untersuchung an das Fehler-Monitoring von Kit (APM) gemeldet, damit das Engineering-Team ihn prüfen kann – es geht keine E-Mail an die Kontoadministratoren. Kontaktieren Sie den Support, wenn Sie eine Abweichung im Hauptbuch vermuten – versuchen Sie nicht, sie manuell zu beheben.

Auf einen Blick

• Konfigurieren Sie die Schweregrade der Prämienmatrix mit passenden Min/Max-Spannen für Ihre Risikotoleranz
• Legen Sie die Anforderungen an die Auszahlungsbereitschaft (Steuerdokumente, Vereinbarung) in den Auszahlungseinstellungen Ihres Programms fest
• Legen Sie eine Finanz-E-Mail fest, damit Zahlungsanforderungen das Team erreichen, das die Zahlungen tatsächlich veranlasst
• Kommunizieren Sie die Prämienspannen auf Ihrer Disclosure-Policy-Seite, bevor Forscher einreichen
• Prüfen Sie die Auszahlungswarteschlange wöchentlich auf ausstehende Zahlungen
• Arbeiten Sie den Tab Fehlgeschlagen bewusst ab – eine fehlgeschlagene Auszahlung löst weder eine E-Mail noch eine In-App-Benachrichtigung aus
• Wählen Sie Etwas anderes, bevor Sie eine Meldung mit noch laufender Auszahlung ablehnen, damit der Forscher nicht um Informationen zu einer Prämie gebeten wird, die Sie gerade zurückziehen
• Benennen Sie mindestens zwei Programm-Administratoren, damit eine von einer einzigen Person durchgängig abgewickelte Auszahlung dennoch einen unabhängigen Prüfer erreicht
• Vereinbaren Sie im Team, wann eine Prämie durch einen Vorschlag geht statt direkt zur Genehmigung – Kit setzt das nicht durch
• Lesen Sie bounty_adjusted-Beträge im Hauptbuch beim Abgleich eines Exports als Veränderung, nicht als Gesamtsumme
• Behandeln Sie eine Benachrichtigung über eine Abweichung im Hauptbuch als Fall für den Support und nicht als etwas, das Sie von Hand beheben
• Prüfen und verifizieren Sie hochgeladene Steuerdokumente zeitnah, um Forscherzahlungen nicht zu blockieren
• Exportieren Sie das Hauptbuch vierteljährlich als SOC 2-Nachweis über Metriken und Exporte

Wie geht es weiter

• Prämienvorschläge und Abstimmung im Team – einen Betrag im Team entscheiden, bevor er zu Geld wird
• Metriken und Exporte – Dashboard-KPIs, SOC 2-Nachweisexporte und Forscher-Karma
• Das Forscherportal – wie Forscher Auszahlungsinformationen und Steuerdokumente einreichen