Was ist ein Hash-Algorithmus und wofür dient er in SEPA?

Ein Hash-Algorithmus ist eine mathematische Funktion, die eine Datei in einen eindeutigen, festen digitalen Fingerabdruck umwandelt. Im SEPA-Kontext dient ein Hash dazu, die Integrität einer Zahlungsdatei nachzuweisen. Mit einem Hash können Sie überprüfen, ob die empfangene SEPA-XML-Datei exakt derselben Datei entspricht, die Sie versendet haben. Schon die Änderung eines einzelnen Zeichens ergibt einen völlig anderen Hash.

Was ist der Unterschied zwischen MD5 und SHA-256?

Beide Algorithmen erzeugen einen Hash-Wert, aber mit unterschiedlicher Sicherheit. MD5 gilt als kryptographisch gebrochen und anfällig für Kollisionen – zwei unterschiedliche Dateien können theoretisch denselben Hash haben. SHA-256 ist modern und sicher; Kollisionen sind praktisch nicht realistisch. Für Finanzprozesse ist MD5 nicht akzeptabel. SHA-256 ist die richtige Wahl für SEPA-Dateien.

Warum sollte MD5 nicht für Integritätsprüfungen von SEPA-Dateien verwendet werden?

MD5 ist kryptographisch gebrochen und erlaubt bekannte Kollisionen. Im SEPA-Umfeld bedeutet das: Ein Angreifer könnte theoretisch zwei unterschiedliche SEPA-Dateien (z.B. eine mit manipulierten Kontoinformationen) mit demselben MD5-Hash erstellen. Ein MD5-Prüfsystem würde die Manipulation nicht erkennen. Im Finanzbereich sind solche bekannten Schwächen nicht akzeptabel. SHA-256 bietet dagegen echten Schutz.

Wie berechne ich einen SHA-256-Hash für eine SEPA-Datei?

Sie können einfache Systembefehle verwenden: Windows: `certutil -hashfile DEINEDATEI.xml SHA256`, macOS: `shasum -a 256 DEINEDATEI.xml`, Linux: `sha256sum DEINEDATEI.xml`. Oder mit Python: `import hashlib; hashlib.sha256(open('datei.xml','rb').read()).hexdigest()`. Der Hash sollte direkt nach dem finalen Export berechnet und dokumentiert werden. Vergleichen Sie ihn später am Zielsystem, um sicherzustellen, dass die Datei nicht verändert wurde.

SHA-256 und MD5 in SEPA - Sicherheitsleitfaden 2026

Sie haben die SEPA-Datei fertig. Die Lastschriften sind geprüft, die Beträge abgestimmt, das XML ist exportiert. Dann fordert das Bankportal, ein Middleware-System oder ein technischer Dienst plötzlich einen Hash-Wert oder eine Prüfsumme an, und genau an dieser Stelle wird aus einem Routineprozess ein Sicherheitsproblem.

Viele Finance-Teams erleben das erst dann bewusst, wenn etwas hakt. Eine Datei wird abgelehnt. Ein Upload lässt sich nicht eindeutig verifizieren. Oder die IT fragt zurück, ob für die Integritätsprüfung noch MD5 verwendet wird, obwohl intern längst von SHA-256 die Rede ist. Bei Sha-256 and Md5 in Sepa geht es deshalb nicht um akademische Kryptographie, sondern um eine praktische Frage: Woran erkennen Sie, dass Ihre Zahlungsdatei exakt die Datei ist, die Ihr System erzeugt hat?

Wer SEPA-Dateien an Banken, EBICS-Strecken, Portale oder Schnittstellen übergibt, muss zwei Risiken sauber trennen. Erstens: die Datei kann unbeabsichtigt verändert werden, etwa durch Encoding-Probleme, Exportfehler oder manuelle Nachbearbeitung. Zweitens: sie kann absichtlich manipuliert werden. In beiden Fällen brauchen Sie eine verlässliche Methode, um die Integrität zu prüfen.

Eine digitale Signatur für Ihre SEPA-Datei

Nehmen wir einen typischen Ablauf aus dem Tagesgeschäft. Die Buchhaltung erstellt eine Sammeldatei für Lastschriften. Das ERP liefert die Daten, ein Export erzeugt die SEPA-XML, danach wird die Datei an die Bank oder an einen zwischengeschalteten Prozess übergeben. Kurz vor dem Versand taucht die Anforderung auf: „Bitte Hash oder Checksumme angeben.”

Für viele klingt das wie ein technisches Detail. Im Finanzprozess ist es keins. Dieser Wert ist der schnelle Nachweis, dass unterwegs niemand ein Feld, eine Referenz, einen Betrag oder ein Konto verändert hat. Schon eine minimale Änderung an der Datei führt bei einem guten Hash-Verfahren zu einem anderen Ergebnis. Genau deshalb sind Hashes im Zahlungsverkehr so nützlich.

Wo die Verwirrung meistens beginnt

Im Alltag werden Begriffe oft vermischt. Manche sprechen von Prüfsumme, andere von Signatur, wieder andere von Fingerabdruck. Fachlich ist das nicht immer dasselbe. Für die Praxis genügt zunächst diese Unterscheidung:

Hash oder Prüfsumme zeigt, ob sich der Dateiinhalt verändert hat.
Digitale Signatur baut oft auf einem Hash auf und weist zusätzlich nach, wer signiert hat.
SEPA-Validierung prüft Struktur und fachliche Plausibilität des XML, nicht automatisch dessen Unverändertheit.

Wer nur auf XML-Gültigkeit schaut, übersieht einen wichtigen Teil des Risikos. Eine Datei kann formal korrekt sein und trotzdem nicht mehr die Datei sein, die Ihr Team freigegeben hat. Genau deshalb gehört Integrität neben Validierung in jeden sauberen SEPA-Prozess.

Praxisregel: Wenn Ihre Organisation eine SEPA-Datei aus mehreren Systemen, Freigabeschritten oder Uploads heraus bewegt, brauchen Sie neben der Formatprüfung immer auch einen Integritätsnachweis.

Warum die Wahl des Verfahrens zählt

An dieser Stelle tauchen meist zwei Namen auf: MD5 und SHA-256. Beide erzeugen einen Hash. Beide liefern einen kompakten Prüfwert. Aber sie sind nicht gleichwertig. Für reine Altprozesse begegnet man MD5 noch immer. Für sicherheitsrelevante Finanzabläufe ist das heute die falsche Wahl.

Die entscheidende Frage lautet nicht, ob ein Verfahren „irgendwie funktioniert”. Die Frage lautet, ob es einem Angreifer oder einem veralteten Prozess erlaubt, zwei unterschiedliche Inhalte so erscheinen zu lassen, als wären sie identisch. Im SEPA-Umfeld ist das untragbar.

Was sind Hash-Algorithmen wie MD5 und SHA-256

Ein Hash-Algorithmus ist am einfachsten als digitaler Fingerabdruck zu verstehen. Sie geben eine Datei hinein, etwa Ihre pain.008.xml oder pain.001.xml, und erhalten einen festen Ausgabewert zurück. Dieser Wert repräsentiert den Inhalt der Datei, aber er ist nicht die Datei selbst.

Der digitale Fingerabdruck

Wenn zwei Personen unterschiedliche Fingerabdrücke haben, kann man sie voneinander unterscheiden. Bei Dateien gilt dieselbe Idee. Zwei unterschiedliche Dateien sollen unterschiedliche Hash-Werte erzeugen. Ändern Sie in einer SEPA-Datei nur ein Zeichen, etwa in einer Mandatsreferenz oder in einem Namen, sollte ein komplett anderer Hash herauskommen.

Ein guter Hash-Algorithmus hat dabei vier Eigenschaften, die in der Praxis nicht verhandelbar sind:

Einwegfunktion. Aus dem Hash lässt sich der Originalinhalt nicht zurückrechnen.
Änderungssensitivität. Schon kleine Änderungen am Input ändern den Hash deutlich.
Feste Ausgabelänge. Ob kleine XML-Datei oder grosse Sammeldatei, der Hash hat immer dieselbe Länge.
Verlässliche Unterscheidung. Unterschiedliche Inhalte sollen nicht denselben Hash liefern.

Das ist der Kern von Sha-256 and Md5 in Sepa. Beide Verfahren erzeugen einen solchen Fingerabdruck. Der Unterschied liegt in der Belastbarkeit dieses Fingerabdrucks unter realen Angriffsbedingungen.

Was der Hash im SEPA-Prozess leistet

Im Zahlungsverkehr nutzen Sie einen Hash nicht, um Daten zu verschlüsseln. Er dient auch nicht dazu, Berechtigungen zu ersetzen. Sein Zweck ist klarer: Integrität. Sie wollen nachweisen, dass die Datei beim Export, beim Versand, beim Upload oder beim Import nicht verändert wurde.

Das ist besonders wichtig, wenn mehrere Stationen beteiligt sind:

Prozessschritt	Typisches Risiko	Rolle des Hash
Export aus ERP	Zeichensatz, Mapping, unerwünschte Nachbearbeitung	Referenzwert direkt nach Erzeugung
Übergabe an Dritte	Austausch falscher Datei, manuelle Umbennung	Abgleich zwischen Absender und Empfänger
Import bei Bank oder Middleware	Konvertierung, Trunkierung, technische Fehler	Prüfung auf bitgenaue Übereinstimmung

Ein Hash schützt nicht vor jeder Bedrohung. Er beantwortet eine präzise Frage: Ist der Inhalt noch exakt derselbe?

Warum der Begriff Signatur oft falsch verwendet wird

Im Sprachgebrauch heisst es schnell „Datei signieren”, obwohl eigentlich „Hash berechnen” gemeint ist. Das ist verständlich, aber riskant. Ein Hash bestätigt nur die Unverändertheit des Inhalts. Eine echte digitale Signatur verknüpft diesen Inhalt zusätzlich mit einem kryptographischen Schlüssel und damit mit einem Absender.

Für Ihre tägliche SEPA-Arbeit ist diese Unterscheidung wichtig. Wenn ein Lieferant oder ein internes Team sagt, eine Datei sei „signiert”, sollten Sie nachfragen, ob wirklich eine digitale Signatur gemeint ist oder nur ein Hash-Wert mitgeschickt wurde.

Sicherheitsvergleich MD5 vs SHA-256 im Detail

Wenn ich einen Finance- oder IT-Verantwortlichen nur auf einen Punkt festnageln müsste, dann auf diesen: MD5 gehört nicht mehr in sicherheitsrelevante SEPA-Prozesse. Nicht als bevorzugter Standard, nicht als bequeme Altlast, nicht als „reicht für uns”.

Das eigentliche Problem bei MD5

Das Schlüsselwort heisst Kollision. Eine Kollision liegt vor, wenn zwei verschiedene Dateien denselben Hash-Wert erzeugen. Für ein Prüfsystem ist das fatal. Es würde zwei unterschiedliche Inhalte als identisch behandeln.

Die einfachste Analogie lautet: Zwei verschiedene Menschen mit demselben Fingerabdruck. Bei einer Zugangskontrolle wäre das absurd. Im Zahlungsverkehr ist es gefährlich.

MD5 gilt seit langem als gebrochen, wenn es um Sicherheitszwecke geht. Das ist keine theoretische Spitzfindigkeit. Wer MD5 für Integritätsnachweise in einem finanziellen Workflow stehen lässt, akzeptiert ein Verfahren, dessen Schwächen bekannt sind.

Was das im SEPA-Kontext bedeutet

Stellen Sie sich zwei XML-Dateien vor. Die erste ist die freigegebene Lastschriftdatei. Die zweite enthält veränderte Empfängerdaten oder manipulierte Kontoinformationen. Wenn ein Angreifer beide Varianten so vorbereitet, dass ein reines MD5-Prüfsystem denselben Hash akzeptiert, dann fällt die Manipulation bei dieser Kontrolle nicht auf.

Nicht jeder Angreifer kann das einfach aus dem Ärmel schütteln. Aber das ist der falsche Massstab. In Finanzprozessen prüfen Sie nicht, was ein durchschnittlicher Anwender vermutlich nicht tut. Sie schliessen Verfahren aus, die bekannte kryptographische Schwächen haben.

Wichtiger Punkt: Im Finanzumfeld reicht „meistens okay” nicht. Wenn ein Hash-Verfahren bekannte Kollisionen zulässt, ist es für Integritätsprüfungen an Zahlungsdateien falsch gewählt.

Warum SHA-256 die vernünftige Wahl ist

SHA-256 ist für diese Aufgabe das richtige Werkzeug. Es ist der etablierte moderne Standard, wenn Sie Dateiintegrität nachvollziehbar und belastbar prüfen wollen. Der Algorithmus ist so konstruiert, dass Kollisionen nach heutigem Stand praktisch nicht als realistischer Weg für Angriffe in normalen Geschäftsprozessen taugen.

Das bedeutet nicht, dass SHA-256 jedes Problem im Zahlungsverkehr löst. Es ersetzt keine Zugriffskontrolle, keine Vier-Augen-Freigabe und keine sichere Transportstrecke. Aber es liefert genau den Integritätsnachweis, den Sie zwischen Export und Empfang brauchen.

Eine knappe Gegenüberstellung hilft bei der Entscheidung:

MD5 passt allenfalls noch in Altumgebungen, in denen es ausschliesslich um nicht sicherheitsrelevante Altkompatibilität geht.
SHA-256 ist die richtige Wahl für neue Prozesse und für die Bereinigung bestehender Workflows.
Mischbetrieb verursacht Fehler. Wenn ein System MD5 ausgibt und das andere SHA-256 erwartet, entsteht Reibung. Wenn beide erlaubt sind, bleibt oft die schwächere Option im Einsatz.

Was in Projekten oft nicht funktioniert

Drei Muster sehe ich regelmässig:

„Wir prüfen nur intern, daher genügt MD5.”
Interne Systeme sind kein Sicherheitsfreiraum. Gerade dort entstehen manuelle Workarounds, Zwischenablagen und Altjobs.
„Die Bank verlangt es nicht ausdrücklich.”
Dann sollten Sie es trotzdem in Ihrem eigenen Prozessstandard festlegen. Sie wollen Ihre Integritätsprüfung nicht vom kleinsten gemeinsamen Nenner abhängig machen.
„Wir migrieren später.”
Später wird selten sauber. Solche Übergangslösungen bleiben oft jahrelang bestehen und werden mit jeder Schnittstelle schwerer zu entfernen.

Wenn Sie eine klare Richtlinie wollen, ist sie einfach: MD5 auslaufen lassen, SHA-256 verbindlich machen, Ausnahmen dokumentieren und terminieren.

Typische Anwendungsfälle im SEPA-Umfeld

Im Alltag tauchen Hashes nicht als theoretisches Konstrukt auf, sondern an klaren Stellen im Workflow. Dort entscheiden sie, ob Sie einen Fehler früh erkennen oder erst dann, wenn die Datei bereits bei der Bank hängt.

Dateiintegrität beim Versand

Das ist der häufigste Fall. Ihr System erzeugt eine SEPA-XML-Datei. Direkt danach berechnen Sie den SHA-256-Hash und speichern ihn im Exportprotokoll oder übermitteln ihn im vereinbarten Prozess an den Empfänger. Nach dem Download oder Import berechnet die Gegenseite denselben Hash erneut.

Stimmen beide Werte überein, wurde der Inhalt nicht verändert. Stimmen sie nicht überein, beginnt die Fehlersuche nicht bei den Fachabteilungen, sondern bei der Dateiübertragung, der Konvertierung oder der falschen Version.

Das wirkt banal, spart aber im Tagesgeschäft enorm viel Zeit. Ohne Hash-Vergleich diskutieren Teams oft über Freigaben, Fachlogik oder Bankregeln, obwohl schlicht eine andere Datei hochgeladen wurde.

API-Uploads und automatisierte Übergaben

Sobald SEPA-Dateien nicht mehr manuell hochgeladen werden, sondern über API, SFTP, Middleware oder Integrationsplattformen laufen, wird die Integritätsprüfung noch wichtiger. Sie sehen die Datei dann nicht mehr auf dem Bildschirm, sondern vertrauen einer Prozesskette.

Ein API-Workflow braucht deshalb mehr als nur TLS und Authentifizierung. Er braucht eine Möglichkeit, den konkreten Payload auf Unverändertheit zu prüfen. Gerade bei automatisierten Einzügen oder wiederkehrenden Exporten ist das sinnvoll.

Hashes als Baustein für digitale Signaturen

Im SEPA-Umfeld begegnen Sie ausserdem Verfahren, in denen Hashes nicht allein stehen, sondern Teil einer digitalen Signatur sind. Das ist etwa bei signierten Transport- oder Autorisierungsverfahren relevant. Der Hash bildet dort die verdichtete Repräsentation des Inhalts, die anschliessend kryptographisch signiert wird.

Das müssen Finance-Teams nicht im Detail implementieren. Wichtig ist das Verständnis: Der Hash ist nicht nur ein Prüfwert für Dateien, sondern eine Grundlage weiterführender Sicherheitsmechanismen. Wenn Sie den Hash-Teil vernachlässigen, steht auch die nächsthöhere Sicherheitsstufe auf wackligem Boden.

In SEPA-Prozessen ist ein Hash kein Add-on. Er ist die kurze, prüfbare Antwort auf die Frage, ob Ihr Zahlungsinhalt noch unverändert ist.

Wo Unternehmen sich unnötig angreifbar machen

Die Schwachstellen liegen selten im Algorithmus allein. Sie liegen im Ablauf:

Manuelle Zwischenschritte nach der Freigabe
Mehrere Dateiversionen im Umlauf
Uneinheitliche Hash-Verfahren zwischen Teams
Fehlende Protokollierung, welcher Hash zur freigegebenen Datei gehörte

Wenn Sie nur einen operativen Hebel setzen wollen, dann diesen: Berechnen Sie den SHA-256-Hash unmittelbar nach dem finalen Export und behandeln Sie ihn als Teil des Freigabebelegs.

Praktische Anleitung zur Hash-Berechnung und Verifikation

Die gute Nachricht: Einen SHA-256-Hash zu berechnen, ist kein grosses Projekt. Sie können das sofort testen, mit Bordmitteln des Betriebssystems oder mit ein paar Zeilen Python. Entscheidend ist nur, dass alle Beteiligten dieselbe Datei prüfen, nicht eine umbenannte oder lokal veränderte Kopie.

Direkt nutzbare Befehle

Für eine Datei namens DEINEDATEI.xml funktionieren diese Kommandos:

System	Befehl
Windows	`certutil -hashfile DEINEDATEI.xml SHA256`
macOS	`shasum -a 256 DEINEDATEI.xml`
Linux	`sha256sum DEINEDATEI.xml`

Der Ablauf ist einfach:

Exportieren Sie die finale SEPA-Datei.
Berechnen Sie den Hash direkt danach.
Speichern oder übermitteln Sie diesen Wert zusammen mit der Datei oder im Prozessprotokoll.
Berechnen Sie den Hash am Zielsystem erneut.
Vergleichen Sie beide Werte exakt.

Wenn auch nur ein Zeichen unterschiedlich ist, behandeln Sie die Datei nicht als identisch.

Was bei der Verifikation häufig schiefläuft

Der Befehl ist selten das Problem. Die Stolperstellen liegen davor oder danach.

Falsche Datei geprüft. Teams hashen eine lokale Arbeitskopie, versenden aber eine andere.
Datei nachträglich geöffnet und gespeichert. Manche Editoren ändern Formatdetails, Zeilenenden oder Encoding.
Hash manuell abgetippt. Das führt unnötig zu Übertragungsfehlern.
MD5 und SHA-256 parallel zugelassen. Dann bleibt das schwächere Verfahren oft im Schatten aktiv.

Für technische Teams lohnt sich deshalb ein klarer Standard: immer SHA-256, immer direkt nach dem finalen Export, immer mit protokolliertem Dateinamen und Freigabekontext.

Arbeitsanweisung: Wenn ein Mitarbeiter eine SEPA-Datei nach der Hash-Berechnung noch einmal öffnet und speichert, ist der alte Hash wertlos und muss neu berechnet werden.

Kurzes Python-Beispiel

Wenn Sie die Prüfung in ein internes Tool, ein ERP-Skript oder eine Upload-Strecke integrieren wollen, reicht oft schon ein minimales Python-Beispiel:

import hashlib

dateiname = "DEINEDATEI.xml"

with open(dateiname, "rb") as f:
    sha256 = hashlib.sha256(f.read()).hexdigest()

print(sha256)

Für grosse Dateien würde ich blockweise lesen, damit der Speicherverbrauch sauber bleibt. Für typische SEPA-XML-Dateien reicht dieses Beispiel oft schon als Demonstration oder für einen schnellen internen Prototyp.

Ein pragmischer Implementierungsstandard

Wenn Sie das in einem Unternehmen sauber einführen wollen, nehmen Sie nicht gleich die Vollautomatisierung als ersten Schritt. Besser funktioniert oft dieser Weg:

Zuerst manuell standardisieren und das Team an die Prüfung gewöhnen.
Dann im Exportprozess verankern, etwa im ERP-Job oder im Konverter.
Anschliessend im Zielsystem prüfen, idealerweise automatisiert vor Weiterverarbeitung.
Ausnahmen dokumentieren, statt Nebenwege stillschweigend zu dulden.

Fazit und Empfehlungen für Ihre SEPA-Prozesse

Die Entscheidung ist klar. SHA-256 gehört in moderne SEPA-Prozesse. MD5 nicht. Wer heute noch MD5 für Integritätsprüfungen von Zahlungsdateien akzeptiert, schleppt ein vermeidbares Risiko in einen Bereich, in dem Verlässlichkeit wichtiger ist als Bequemlichkeit.

Für die Praxis empfehle ich eine kurze interne Checkliste:

Verfahren festlegen. SHA-256 als verbindlichen Standard dokumentieren.
Altprozesse prüfen. Exportjobs, Bankportale, Middleware und interne Tools auf MD5-Reste untersuchen.
Hash-Punkt definieren. Immer nach dem finalen Export berechnen, nie an einer Vorversion.
Verifikation erzwingen. Eingehende und ausgehende Dateien systematisch vergleichen.
Freigabeprozess koppeln. Hash-Wert als Teil des fachlichen Freigabenachweises behandeln.
Partner ansprechen. Banken, Dienstleister und Integratoren aktiv auf SHA-256 festlegen.

Wenn Sie SEPA-Dateien erzeugen, prüfen oder weiterreichen, beginnt Sicherheit nicht erst bei der Autorisierung. Sie beginnt bei der Frage, ob die Datei, die ankommt, noch exakt die Datei ist, die Sie freigegeben haben.

Häufig gestellte Fragen

Was ist ein Hash-Algorithmus und wofür dient er in SEPA?: Ein Hash-Algorithmus ist eine mathematische Funktion, die eine Datei in einen eindeutigen, festen digitalen Fingerabdruck umwandelt. Im SEPA-Kontext dient ein Hash dazu, die Integrität einer Zahlungsdatei nachzuweisen. Mit einem Hash können Sie überprüfen, ob die empfangene SEPA-XML-Datei exakt derselben Datei entspricht, die Sie versendet haben. Schon die Änderung eines einzelnen Zeichens ergibt einen völlig anderen Hash.
Was ist der Unterschied zwischen MD5 und SHA-256?: Beide Algorithmen erzeugen einen Hash-Wert, aber mit unterschiedlicher Sicherheit. MD5 gilt als kryptographisch gebrochen und anfällig für Kollisionen – zwei unterschiedliche Dateien können theoretisch denselben Hash haben. SHA-256 ist modern und sicher; Kollisionen sind praktisch nicht realistisch. Für Finanzprozesse ist MD5 nicht akzeptabel. SHA-256 ist die richtige Wahl für SEPA-Dateien.
Warum sollte MD5 nicht für Integritätsprüfungen von SEPA-Dateien verwendet werden?: MD5 ist kryptographisch gebrochen und erlaubt bekannte Kollisionen. Im SEPA-Umfeld bedeutet das: Ein Angreifer könnte theoretisch zwei unterschiedliche SEPA-Dateien (z.B. eine mit manipulierten Kontoinformationen) mit demselben MD5-Hash erstellen. Ein MD5-Prüfsystem würde die Manipulation nicht erkennen. Im Finanzbereich sind solche bekannten Schwächen nicht akzeptabel. SHA-256 bietet dagegen echten Schutz.
Wie berechne ich einen SHA-256-Hash für eine SEPA-Datei?: Sie können einfache Systembefehle verwenden: Windows: `certutil -hashfile DEINEDATEI.xml SHA256`, macOS: `shasum -a 256 DEINEDATEI.xml`, Linux: `sha256sum DEINEDATEI.xml`. Oder mit Python: `import hashlib; hashlib.sha256(open('datei.xml','rb').read()).hexdigest()`. Der Hash sollte direkt nach dem finalen Export berechnet und dokumentiert werden. Vergleichen Sie ihn später am Zielsystem, um sicherzustellen, dass die Datei nicht verändert wurde.