Zusammenfassung

  • Am 3. Mai 2026 hob das ICANN Board die Beschränkung des Supplemental Fund for Implementation of Community Recommendations auf vom Board gebilligte Community-Empfehlungen auf, führte den Namen Project Fund ein und wies den President and CEO oder eine beauftragte Person an, Regeln für die Förderqualifikation zu entwickeln.
  • Die Ausgabenbefugnis ging damit nicht auf das Management über. Jede Nutzung des Fonds bleibt vom Board zu genehmigen und muss in der Finanzberichterstattung von ICANN erscheinen.
  • Am 28. Mai erörterte das Board Finance Committee einen prognostizierten operativen Überschuss für FY26 von 18 bis 21 Millionen US-Dollar. Der Project Fund war ein möglicher Empfänger, keine beschlossene Zuweisung; technologische Modernisierung war ein Beispiel, kein genehmigtes Projekt. Abschluss, Prüfung, förmliche Empfehlung und Board-Entscheidung standen noch aus.
  • Ein prüfbarer öffentlicher Beleg muss die geltende Regelversion mit den Projektdaten verbinden und Konsultation, Fondstransfer, Nutzungsbeschluss, Auszahlung, Änderung, Ergebnis und Abschluss als eigene Zustände erhalten.

Der frühere Fonds begann mit einer Herkunftsprüfung

Der 2021 geschaffene SFICR war für große, komplexe oder mehrjährige Arbeiten gedacht, die sich nicht sinnvoll in einem einzelnen Jahresbudget unterbringen ließen. Sein Gegenstand war jedoch begrenzt: Es ging um Community-Empfehlungen, die das Board bereits gebilligt hatte oder voraussichtlich bald billigen würde.

Der Einrichtungsbeschluss vom 22. Juli 2021 enthielt einen ersten Transfer von 15 Millionen US-Dollar. Eine Community-Empfehlung garantierte weder gute Projektausführung noch wirtschaftliche Mittelverwendung. Sie schuf aber eine nachvollziehbare erste Antwort auf die Frage, woher der Auftrag stammte: identifizierbare Empfehlung, Board-Billigung und eine Umsetzung, deren Größe oder Dauer den normalen Haushaltszyklus überforderte.

Die genehmigten Board-Resolutionen vom 3. Mai 2026 entfernten diese Herkunftsbeschränkung. Resolution 2026.05.03.01 weitete den Zweck auf jedes qualifizierte Projekt aus. 2026.05.03.02 führte den Namen Project Fund ein und wies die Geschäftsleitung an, Regeln für die Förderqualifikation zu entwickeln. 2026.05.03.03 passte die Investment Policy an und setzte Ziel- und Höchstwerte für den Reserve Fund.

Diese Entscheidungen betreffen verschiedene Ebenen. Die Reichweite sagt, welche Arten von Vorhaben grundsätzlich in Betracht kommen können. Der Name macht den institutionellen Behälter erkennbar. Die Qualifikationsregel muss für einen konkreten Antrag zeigen, wie er die Schwelle überschreitet. „Qualifiziert“ ist ohne solche Prüfkriterien nur die Behauptung des gewünschten Ergebnisses.

Zwei wichtige Kontrollen blieben bestehen. Jede Nutzung braucht weiterhin einen Board-Beschluss, und die Ausgaben sollen in ICANNs Finanzberichten ausgewiesen werden. Der Auftrag, Kriterien zu verfassen, ist daher keine Ermächtigung des Managements zum selbstständigen Geldausgeben. Umgekehrt ersetzt die abschließende Zustimmung des Boards nicht die Begründung dazwischen. Ein Beschluss beweist, dass das zuständige Organ gehandelt hat. Er erklärt ohne Verweis auf Regel und Projektakte nicht zwingend, warum gerade dieses Vorhaben außerhalb des ordentlichen Budgets behandelt wurde.

ICANN bezeichnete die Änderung vom 3. Mai als Maßnahme ohne unmittelbare finanzielle Auswirkung. Gebäudeverbesserungen sowie Technologie-, Sicherheits- und Ausrüstungsmodernisierung waren Beispiele neuer Projektklassen. Eine Klasse ist keine dauerhafte Bewilligung. Sie belegt weder Beschaffung noch Vertrag noch Zahlung.

Zwischen Prognose und Zahlung liegen eigenständige Entscheidungen

Die BFC-Niederschrift vom 28. Mai machte den erweiterten Fonds finanziell relevant. Nach Angaben der Mitarbeiter lagen die FY26-Ausgaben im Wesentlichen im Plan. Die Finanzierung sollte den Plan dagegen übertreffen, vor allem wegen stärkerer Aktivität im Domainnamenmarkt. Daraus ergab sich eine Prognose für einen operativen Überschuss von 18 bis 21 Millionen US-Dollar.

Der Operating Fund und der Reserve Fund lagen über ihren Mindestständen; die Reserve lag leicht über dem Ziel. Der Mindeststand des Operating Fund entspricht weiterhin drei Monaten budgetierter Betriebsausgaben. Als möglicher Empfänger des erwarteten Überschusses wurde der Project Fund genannt. Technologische Modernisierung diente als Beispiel für potenziell förderfähige Arbeit.

Die Niederschrift hält zugleich fest, was noch nicht geschehen war. Eine förmliche Empfehlung sollte erst nach dem Ende des Geschäftsjahres und nach Abschluss der Prüfung vorgelegt werden. Jede Zuweisung würde einen Board-Beschluss verlangen. Der zutreffende Status am 28. Mai war deshalb „Zuweisungsoption in Beratung“. Er war nicht „18 bis 21 Millionen US-Dollar übertragen“ und schon gar nicht „Technologieprojekt finanziert“.

Ein Dollarbetrag kann in mehreren Akten gleich aussehen. Zuerst gibt es die unterjährige Prognose. Dann folgt der endgültige geprüfte Überschuss. Danach kann das Board einen bestimmten Betrag in den Fonds übertragen. Erst ein projektbezogener Nutzungsbeschluss erlaubt eine bestimmte Inanspruchnahme. Verpflichtungen, tatsächliche Zahlungen und Restmittel erzeugen weitere Werte. Wer alle Werte unter einer aktuellen Zahl zusammenführt, verliert Prognosefehler, Zuständigkeit und Zeitpunkt.

Der historische Transfer vom 30. Oktober 2025 zeigt die fehlende Form. Damals genehmigte das Board einen Transfer von 12 Millionen US-Dollar aus dem Überschuss des FY25 Operating Fund in den SFICR/Project Fund. Das Dokument benennt das abgeschlossene Jahr, die Quelle, den Betrag, das Ziel und die entscheidende Instanz. Ein künftiger FY26-Transfer muss einen eigenen vergleichbaren Nachweis erzeugen und kann nicht aus der Mai-Prognose abgeleitet werden.

Die Konsultation enthielt Bedingungen, nicht nur Zustimmung

ICANN legte die Fondsänderung zusammen mit den Betriebs- und Finanzplänen für FY27–31 zur öffentlichen Kommentierung vor. Der Summary Report vom 2. April berichtet, dass vier von sechs Antwortenden den Grund für die Erweiterung für klar hielten; eine weitere Antwort lautete „teilweise“. Derselbe Bericht bewahrt Fragen zu Transparenz, Auswahlkriterien und Aufsicht.

ICANN skizzierte drei erwartete Merkmale. Ein Vorhaben könne außerhalb des jährlichen Operating Plan liegen, groß in Umfang und Kosten sein und sich über mehrere Geschäftsjahre erstrecken. Die Board-Genehmigung sollte erhalten bleiben. Die Community könne sich im jährlichen Budgetprozess oder im Austausch mit dem Board äußern.

Diese Hinweise sind wertvoll, aber noch nicht die später ausdrücklich verlangte Regel. Groß im Verhältnis zu welchem Maßstab? Wird eine vorhersehbare Aufgabe dadurch förderfähig, dass sie im Jahresplan fehlt? Kann wiederkehrender Personalaufwand als Projekt gelten, wenn er zwei Jahre läuft? Muss eine wesentliche Erweiterung neu geprüft werden? Eine anwendbare Regel muss Grenzfälle ordnen, nicht nur drei offene Adjektive wiederholen.

Die Stellungnahme des ccNSO SOPC fragte, wer ein Projekt definiert, welche Aufsicht die Community erhält und ob der Mechanismus die normale Budgetprüfung umgehen könnte. ALAC unterstützte die Board-Genehmigung jeder Nutzung und hielt die Projektdefinition für auslegungsfähig. Alfredo Calderon-Serrano verlangte Sichtbarkeit und eine Unterscheidung zwischen Community-getriebenen und intern angestoßenen Vorhaben.

Diese Beiträge sind keine Belege dafür, dass bereits ein Missbrauch oder eine Umgehung stattgefunden hat. Es sind zurechenbare Bedenken und Vorschläge. Die Aussage, dass die Erweiterung im Grundsatz verstanden wurde, darf deshalb nicht als bedingungslose Billigung verwendet werden. Eine Konsultation ist gerade dann informativ, wenn sie Zustimmung und offene Anforderungen zugleich festhält.

Öffentliche Beteiligung überträgt auch nicht die Verantwortung des Boards auf Kommentierende. Teilnehmer liefern Fakten, Kosten, Alternativen und Widerspruch. Das Board entscheidet über Organisationsmittel. Der belastbare Datensatz erhält beide Seiten: die wesentlichen Einwände und die Antwort der befugten Stelle. Kommentarzahlen sind keine Ersatzabstimmung.

Ein Ausnahmetopf darf kein zweites Jahresbudget werden

ICANNs Planungsprozess verbindet Strategieplan, Fünfjahres-Operating-Plan, jährlichen Operating Plan samt Budget und Leistungsberichterstattung. Der Nutzen dieses Zusammenhangs liegt in der Vergleichbarkeit: laufende Leistungen, Personal, Einnahmen und Prioritäten erscheinen in einem gemeinsamen Rahmen.

Ein Projektfonds kann dennoch sinnvoll sein. Eine Sicherheitsanforderung kann nach Budgetannahme entstehen, eine Kapitalerneuerung mehrere Jahre dauern, eine einmalige Infrastrukturinvestition den laufenden Haushalt verzerren. Der Fonds kann solche Zeitprobleme lösen. Seine Ausnahmequalität hängt aber davon ab, dass sich die Abweichung vom normalen Weg begründen lässt.

„Nicht im jährlichen Operating Plan enthalten“ darf kein sich selbst erfüllendes Kriterium sein. Ein Antrag sollte erklären, ob der Bedarf nach der Planannahme entstand, ob die Arbeit tatsächlich nicht wiederkehrt, ob Umfang und Dauer den normalen Betrieb beeinträchtigen würden oder welcher andere Grund gilt. Wenn bloßes Weglassen die Zulassung schafft, belohnt das System die Planungslücke.

Der Project Fund ist ferner nicht mit dem ICANN Grant Program gleichzusetzen. Das Grant Program verwendet Auktionserlöse aus der 2012er Runde neuer gTLDs und hat eine eigene Vergabearchitektur. Der Project Fund kann nach vorrangigen Fondsbedarfen durch Board-genehmigte Zuweisungen aus Operating-Fund-Überschüssen gespeist werden. Ähnliche Begriffe verschmelzen weder Geldquellen noch Befugnisse.

Auch der Reserve Fund bleibt eigenständig. Am 3. Mai blieb sein Minimum bei zwölf Monaten budgetierter Betriebsausgaben; das Ziel wurde auf sechzehn und das Maximum auf einundzwanzig Monate gesetzt. Ein Bestand oberhalb einer Schwelle beeinflusst die Reihenfolge möglicher Zuweisungen. Er wird dadurch nicht automatisch zum Projektgeld. Schwellenwert, Transfer und Nutzung sind drei Akte.

Der öffentliche Qualifikations- und Nutzungsbeleg

Die Regel selbst braucht eine feste Kennung, Version, ein Wirksamkeitsdatum und eine genehmigende Instanz. Jeder Projektantrag verweist auf die zum Entscheidungszeitpunkt geltende Version und zeigt, welche Voraussetzungen mit welchen Belegen erfüllt sind. „Strategisch“ und „wichtig“ sind Bewertungen, keine reproduzierbaren Prüfungen.

Die Projektakte nennt einen öffentlichen Namen, die verantwortliche Stelle und die rechenschaftspflichtige Führungskraft. Sie ordnet das Vorhaben ICANNs Mission und dem öffentlichen Interesse zu; erklärt den Weg außerhalb des Jahresbudgets; enthält Umfang, Kostenspanne, Dauer und Ergebnisse; und kennzeichnet, ob es aus einer Community-Empfehlung, einem internen Betriebsbedarf oder einer Mischform stammt.

Zur Begründung gehören die Alternativen: ordentliches Budget, kleinerer Umfang, stufenweise Umsetzung, Aufschub und Ablehnung. Konsultationszeitpunkte, wesentliche Stellungnahmen und ihre Behandlung bleiben mit der Akte verbunden. Interessenkonflikte und Enthaltungen werden erfasst. BFC-Empfehlung und Board-Resolution verweisen auf die exakte Regelversion und den Antrag.

Das Geld erhält eine eigene Kette. Ausgangsfonds, Transferbetrag, genehmigte Inanspruchnahme, tatsächliche Ausgabe, Restbestand und Abschlussverweis werden getrennt. Umfangs- oder Kostenänderungen erzeugen neue Genehmigungen, statt die ursprüngliche Schätzung zu überschreiben. Der Abschluss dokumentiert Ergebnisse, Abweichungen, ungenutzte Mittel und die Entscheidung über Fertigstellung oder Abbruch.

Ein öffentlicher Beleg muss keine Sicherheitsdetails, personenbezogenen Daten oder vertraulichen Lieferantenpreise offenlegen. Diese Felder können geschützt werden, während Voraussetzungen, Behörde, Betrag, Begründung, Status und Korrekturweg sichtbar bleiben. Vertraulichkeit darf den Beleg verkleinern, nicht den Entscheidungsgrund auslöschen.

Das nützt auch dem Management. Es kann nachweisen, dass eine hilfreiche Investition nicht aus der normalen Prüfung geschoben wurde, dass das Board Alternativen sah und dass spätere Kostenänderungen zurechenbar sind. Wenn die Regel lernt und sich ändert, bewahren Versionen die Vergangenheit, ohne sie an den neuen Wortlaut anzupassen.

Der belegte Stand ist enger als die mögliche Zukunft

Die bis zum 27. August 2026 geprüften offiziellen Dokumente belegen eine abgeschlossene Erweiterung und Umbenennung, die fortbestehende Board-Zuständigkeit, Finanzberichterstattung, erwartete Zulassungsmerkmale, einen Auftrag zur Regelentwicklung und eine spätere Überschussprognose. Sie belegen weder den endgültigen geprüften FY26-Überschuss noch dessen Transfer, ein genehmigtes Modernisierungsprojekt oder Ausgaben aus der Prognose.

In den geprüften offiziellen Quellen wurde kein getrennt veröffentlichtes endgültiges Dokument mit den Qualifikationsregeln gefunden. Das ist ein zeitlich und sachlich begrenztes Suchergebnis. Es beweist weder, dass innerhalb von ICANN keine Arbeit stattfindet, noch schließt es eine spätere Veröffentlichung aus. Zu beobachten ist das von Resolution 2026.05.03.02 verlangte Instrument, nicht ein aus einer Suchlücke konstruiertes Fehlverhalten.

Heng Lus Analyse des Agency-Problems im Kern der Internet Governance dient als Deutungsrahmen, nicht als Quelle für ICANNs Finanzdaten. Kontrolle, Anreize, Verantwortung und Abhilfe sollen verbunden bleiben. Das Management entwickelt Regeln, das BFC prüft Finanzvorschläge, das Board genehmigt, die Community liefert Erkenntnis und Kritik, Berichte und Prüfung zeigen die Ausführung. Getrennte Rollen verlangen gerade eine verbundene Belegkette.

Der erweiterte Project Fund ist weder von sich aus illegitim noch selbsterklärend legitim. Er kann Arbeit tragen, die ein Jahreszyklus schlecht abbildet. Entscheidend ist sein öffentlicher Betriebsnachweis: Regel veröffentlichen, Projekte an ihre Version binden, Prognose, Transfer, Nutzung und Ergebnis trennen, Konsultationsbedingungen erhalten, ohne die Board-Verantwortung zu verschieben, und jedes Vorhaben so präzise schließen, wie es eröffnet wurde.

Quellen