> Kontinuierliche Prozessverbesserung > Zahlungsabwicklung > Fiserv > Daten Template

Ihr Daten-Template für die Zahlungsabwicklung

Name: Zahlungsabwicklung-Datentemplate für Process Mining
Creator: ProcessMind
License: https://creativecommons.org/licenses/by/4.0/

Fiserv

Ihr Daten-Template für die Zahlungsabwicklung

← Zurück zum Leitfaden zur Prozessverbesserung

Attribute der Zahlungsabwicklung (19) Aktivitäten der Zahlungsabwicklung (13) Anleitungen zum Extrahieren (1)

Ihr Daten-Template für die Zahlungsabwicklung

Dieses Template bietet einen strukturierten Rahmen, um Ihre Fiserv-Daten in ein Format für Process Mining und Analysen zu überführen. Es beschreibt die wesentlichen Attribute und Aktivitäten, mit denen Sie Ihre Abwicklungs- und Abstimmungszyklen transparent machen. Mit diesem Leitfaden erstellen Sie ein aussagekräftiges Event Log, das Ineffizienzen und Compliance-Risiken in Ihren Finanzprozessen sichtbar macht.

Empfohlene Attribute für die Zahlungsanalyse
Wichtige Prozessmeilensteine zur Überwachung
Technische Anleitung zum Extrahieren von Fiserv-Daten

Neu bei Event Logs? Erfahren Sie, wie Sie ein Event Log für Process Mining erstellen.

Template herunterladen

Attribute der Zahlungsabwicklung

Diese empfohlenen Datenfelder liefern den erforderlichen Kontext für Ihr Event Log und ermöglichen eine umfassende Analyse des gesamten Zahlungszyklus.

5 Erforderlich 9 Empfohlen 5 Optional

	Name	Beschreibung
	Aktivitätsname ActivityName	Das konkrete Ereignis oder die Statusänderung im Zahlungsprozess.
Beschreibung Dieses Attribut beschreibt den ausgeführten Schritt, zum Beispiel „Zahlungsanfrage erstellt“ oder „Zahlung abgewickelt“. Es legt die Knoten in der Prozessübersicht fest und ist entscheidend, um die Abfolge der Vorgänge zu verstehen. Anhand der einzelnen Aktivitäten können Organisationen den Workflow visualisieren, übersprungene Schritte erkennen und nicht konforme Abläufe aufdecken, bei denen vorgeschriebene Validierungen oder Genehmigungen umgangen wurden. Warum das wichtig ist Legt die Ereignisse fest, aus denen sich der zeitliche Ablauf des Prozesses zusammensetzt. Woher beziehen Transaktionshistorie oder Audit-Tabellen zu Statusänderungen. Beispiele Zahlungsanfrage erstelltZahlung autorisiertZahlungsfehler erkanntZahlung abgewickeltZahlung storniert
	Ereigniszeitstempel EventTimestamp	Das genaue Datum und die Uhrzeit, zu der die Aktivität stattgefunden hat.
Beschreibung Dieses Attribut erfasst den genauen Zeitpunkt eines Ereignisses. Es bildet die Grundlage für alle zeitbezogenen Analysen, darunter Zyklus- und Durchlaufzeiten sowie die Ermittlung von Engpässen. In Dashboards dienen diese Daten dazu, die Dauer zwischen Prozessschritten zu berechnen, etwa die Zeit von „Zahlungsanfrage erstellt“ bis „Zahlung autorisiert“. Zeitstempel mit hoher Genauigkeit sind erforderlich, um Ereignisse, die kurz nacheinander auftreten, korrekt zu ordnen. Warum das wichtig ist Erforderlich, um Ereignisse zu ordnen und die Prozessdauer zu berechnen. Woher beziehen Audit-Protokolle oder Zeitstempelspalten für Transaktionsaktualisierungen. Beispiele 2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:00:00Z2023-10-17T10:00:00Z
	Zahlungstransaktions-ID PaymentTransactionId	Die eindeutige Kennung der jeweiligen Zahlungsanweisung oder des Transaktionsfalls.
Beschreibung Dieses Attribut dient als zentraler Schlüssel, um alle Aktivitäten innerhalb eines Zahlungszyklus miteinander zu verknüpfen. Es ermöglicht Analysten, den Ablauf von der ursprünglichen Anfrage über Validierung und Genehmigung bis zur endgültigen Abwicklung oder Stornierung nachzuverfolgen. In Fiserv-Umgebungen ist dies in der Regel der Primärschlüssel in den Tabellen zur Transaktionshistorie. Er ist unverzichtbar, um den Prozessablauf zu rekonstruieren und sicherzustellen, dass zeitlich getrennte Ereignisse, etwa eine Abwicklung Tage nach der Autorisierung, demselben Geschäftsobjekt zugeordnet werden. Warum das wichtig ist Dies ist die grundlegende Case-ID, die erforderlich ist, um Ereignisse zu Prozessinstanzen zusammenzufassen. Woher beziehen Prüfen Sie die Fiserv-Dokumentation zu Transaktions- oder Zahlungs-Header-Tabellen. Beispiele TRX-99823101PMT-2023-88421002938475CHK-5512WIRE-US-9921
	Letzte Datenaktualisierung LastDataUpdate	Der Zeitstempel der letzten Extraktion oder Aktualisierung des Datensatzes.
Beschreibung Zeigt, wie aktuell die für die Analyse verwendeten Daten sind. So lässt sich beurteilen, ob die Dashboards den laufenden Betrieb oder historische Datenstände abbilden. Die Aktualität stärkt das Vertrauen der Benutzer in die angezeigten Kennzahlen und hilft ihnen, Entscheidungen auf Basis veralteter Daten zu vermeiden, insbesondere bei der Überwachung von Fristen und aktuellen Engpässen. Warum das wichtig ist Stellt die Aktualität und Zuverlässigkeit der Daten sicher. Woher beziehen Systemzeit zum Zeitpunkt der ETL-Ausführung. Beispiele 2023-10-27T12:00:00Z2023-10-28T06:00:00Z
	Quellsystem SourceSystem	Der Name des Systems, aus dem die Daten stammen.
Beschreibung Gibt an, welches Fiserv-Modul oder externe System das Ereignis erzeugt hat. Das ist besonders in komplexen Systemlandschaften hilfreich, in denen Zahlungen über einen Frontend-Kanal eingehen und in einem zentralen Backend-Bankensystem abgewickelt werden. Analysten können die Prozessansicht nach Ursprungssystem filtern und die Analyse so auf bestimmte technische Umgebungen oder Integrationspunkte ausrichten. Warum das wichtig ist Liefert technischen Kontext und Informationen zur Datenherkunft. Woher beziehen Bei der Extraktion fest codiert oder aus Systemmetadaten übernommen. Beispiele Fiserv PremierFiserv SignatureFiserv DNAFiserv Enterprise Payments Platform
	Fälligkeitstermin der Zahlung PaymentDueDate	Das Datum, bis zu dem die Zahlung verarbeitet werden muss.
Beschreibung Der Zieltermin für den Abschluss der Zahlung. Im Monitor zur Einhaltung der Verarbeitungsfristen dient er dazu, Transaktionen zu kennzeichnen, bei denen eine verspätete Ausführung droht. Durch den Vergleich des Zeitstempels „Zahlung abgewickelt“ mit diesem Attribut lassen sich Kennzahlen zur termingerechten Ausführung berechnen. So kann die Organisation das Vertrauen der Zahlungsempfänger erhalten. Warum das wichtig ist Referenzwert zur Messung der SLA-Einhaltung. Woher beziehen Details zur Zahlungsanweisung. Beispiele 2023-11-012023-11-15
	Fehlercode ErrorCode	Der spezifische Code, der bei einer fehlgeschlagenen Zahlungsvalidierung erzeugt wird.
Beschreibung Erfasst den technischen oder fachlichen Fehlercode, der mit Aktivitäten wie „Zahlungsfehler erkannt“ verbunden ist. Dieses Attribut bildet die Grundlage für den Tracker zu Validierungsfehlern und Nacharbeit. Durch die Auswertung der Häufigkeit einzelner Fehlercodes kann die Organisation systematische Probleme mit der Datenqualität, etwa eine ungültige Bankleitzahl, erkennen und gezielte Korrekturen an der Validierungslogik oder bei der Benutzerschulung vornehmen. Warum das wichtig ist Macht die Ursachen für Nacharbeit sichtbar. Woher beziehen Fehlerprotokolle oder Details zum Transaktionsstatus. Beispiele E-101INV_ACCNSF_ERRAUTH_FAIL
	Kontonummer des Zahlungsempfängers PayeeAccountNumber	Die Kontonummer, auf die das Geld gutgeschrieben wird.
Beschreibung Gibt das Zielkonto an. Wie das Konto des Zahlungspflichtigen ist auch dieses Attribut für die Ansicht zur Erkennung doppelter Zahlungen entscheidend. So lässt sich die Analyse gezielt auf bestimmte Empfängerbeziehungen ausrichten. Bei der Überwachung von Fristen kann die Kenntnis des Zahlungsempfängers dabei helfen, strategische Lieferanten oder kritische Abwicklungen zu priorisieren, die unbedingt erfolgreich sein müssen. Warum das wichtig ist Unverzichtbar für die Erkennung doppelter Zahlungen und die Analyse von Zahlungsempfängern. Woher beziehen Transaktionsdetails, Spalte „Credit Account“ oder „Beneficiary“. Beispiele 555000111222333444BEN-882-11
	Kontonummer des Zahlungspflichtigen PayerAccountNumber	Die Kontonummer, von der das Geld abgebucht wird.
Beschreibung Gibt das Ursprungskonto der Zahlung an. Dieses Attribut ist ein wichtiger Bestandteil der Ansicht zur Erkennung doppelter Zahlungen. Zusammen mit Zahlungsempfänger, Betrag und Zeitpunkt bildet es einen eindeutigen Fingerabdruck, mit dem versehentliche Doppelzahlungen erkannt werden können. Außerdem ermöglicht es die Analyse des Zahlungsvolumens nach Ursprungskonto, um die aktivsten internen Portfolios zu ermitteln. Warum das wichtig ist Unverzichtbar für die Erkennung doppelter Zahlungen und die Betrugsanalyse. Woher beziehen Transaktionsdetails, Spalte „Debit Account“. Beispiele 123456789987654321ACC-001-992
	STP IsStraightThroughProcessing	Kennzeichnet, ob für die Zahlung kein manueller Eingriff erforderlich war.
Beschreibung Ein berechnetes boolesches Attribut, das den Wert „wahr“ hat, wenn der Case keine Schritte wie „Zahlungsfehler erkannt“, „Zahlungsfehler behoben“ oder eine manuelle „Zahlung genehmigt“ enthält, je nach Definition. Es unterstützt direkt die KPI zur Straight-Through-Processing-Rate. Damit lässt sich der Prozess in zwei Gruppen unterteilen: vollständig automatisierte Abläufe und Abläufe mit menschlichem Eingriff. So wird das Automatisierungspotenzial deutlich. Warum das wichtig ist Zentrale Kennzahl für Prozesseffizienz und erfolgreiche Automatisierung. Woher beziehen Bei der Datentransformation berechnet. Beispiele truefalse
	Verarbeitender Benutzer ProcessingUser	Die Benutzer-ID oder der Systemagent, der für die Aktivität verantwortlich ist.
Beschreibung Gibt an, wer die jeweilige Aktion ausgeführt hat, ob eine genehmigende Person oder ein automatisierter Systemagent. Diese Daten fließen in die Dashboards zur Effizienz bei der Fehlerbehebung und zum Durchsatz der Genehmigungsbefugnisse ein. Durch die Nachverfolgung der Benutzer können Analysten Schulungsbedarf bei Personen mit hohen Fehlerquoten erkennen oder Engpässe aufdecken, wenn einzelne Genehmigende mit Anfragen überlastet sind. Warum das wichtig ist Ermöglicht die Ressourcenanalyse und die Ermittlung von Engpässen. Woher beziehen Audit-Protokolle, Spalte „User ID“. Beispiele jdoeSYSTEM_BATCHmsmith_approverAPI_USER
	Währungscode CurrencyCode	Der ISO-Währungscode des Zahlungsbetrags.
Beschreibung Gibt die Währung des Zahlungsbetrags an, zum Beispiel USD oder EUR. Dieses Attribut ist wichtig für das Dashboard zu Trends bei Währungen und Zahlungsarten. Damit kann die Organisation ihr Engagement in verschiedenen Fremdwährungen überwachen. Außerdem dient es dazu, Beträge für globale Berichte zu vereinheitlichen und zu verhindern, dass bei der Prüfung auf doppelte Zahlungen Transaktionen mit gleichem Zahlenwert, aber unterschiedlicher Währung fälschlich als Duplikate erkannt werden. Warum das wichtig ist Erforderlich für die Analyse der Verarbeitung von Zahlungen in mehreren Währungen. Woher beziehen Transaktions-Header-Tabelle, Spalte „Currency“. Beispiele USDEURGBPCADJPY
	Zahlungsbetrag PaymentAmount	Der Geldbetrag der Zahlungstransaktion.
Beschreibung Dieses Attribut gibt den mit der Zahlung verbundenen Geldbetrag an. Es ist eine zentrale Dimension für die Segmentierung der Analyse und ermöglicht es Benutzern, Zahlungen mit hohem strategischem Wert von routinemäßigen Zahlungen mit geringem Wert zu unterscheiden. Für die Ansicht zur Erkennung doppelter Zahlungen ist das Attribut unverzichtbar: Identische Beträge in Verbindung mit Angaben zum Zahlungspflichtigen und Zahlungsempfänger weisen auf mögliche Fehler hin. Es unterstützt auch die Analyse von Genehmigungsbefugnissen, da für höhere Beträge häufig andere Workflows gelten. Warum das wichtig ist Entscheidend für die Analyse finanzieller Risiken und die Erkennung doppelter Zahlungen. Woher beziehen Transaktions-Header-Tabelle, Spalte „Amount“. Beispiele 150.0025000.5010.991000000.00
	Zahlungsmethode PaymentMethod	Das Verfahren zur Ausführung der Zahlung, zum Beispiel Wire oder ACH.
Beschreibung Ordnet die Transaktion dem verwendeten Zahlungsweg zu. Dieses Attribut ist grundlegend für die Analyse der Autorisierungszykluszeit, da sich die Standardvorgehensweisen und Service Level Agreements je nach Methode deutlich unterscheiden. Der Vergleich von Prozessvarianten nach Zahlungsmethode zeigt, ob Verzögerungen auf einen bestimmten Kanal, etwa internationale Überweisungen, oder auf die Organisation insgesamt zurückzuführen sind. Warum das wichtig ist Gliedert Prozessabläufe nach der verwendeten Infrastruktur. Woher beziehen Spalte für Transaktionstyp oder Instrumentencode. Beispiele ÜberweisungACHScheckRTPInterne Überweisung
	Bank des Zahlungsempfängers BeneficiaryBank	Der Name oder die Kennung der empfangenden Bank.
Beschreibung Gibt das Finanzinstitut an, das die Zahlung empfängt. Das ist hilfreich, um Verzögerungen bei der Abwicklung zu untersuchen, da sich die Verarbeitungsgeschwindigkeit und Integrationsprobleme je nach Empfängerbank unterscheiden können. Als zusätzliche Dimension im Dashboard zur Zeitspanne von der Abwicklung bis zum Abgleich zeigt das Attribut, ob Verzögerungen extern, also bankbedingt, oder intern verursacht sind. Warum das wichtig ist Analyse externer Abhängigkeiten. Woher beziehen Transaktionsdetails, Spalte „Bank ID“ oder „Name“. Beispiele ChaseBank of AmericaWells FargoCitibank
	Fristüberschreitung IsCutoffMissed	Kennzeichnet, ob die Zahlung nach der täglichen Annahmefrist der Bank gesendet wurde.
Beschreibung Ein berechneter boolescher Wert, der den Zeitpunkt des Versands der „Zahlungsanweisung“ mit der täglichen Annahmefrist für die jeweilige Währung und Zahlungsmethode vergleicht. Er unterstützt die KPI zur Einhaltung der Annahmefristen. Die Ermittlung versäumter Fristen hilft, die Ursachen von Verzögerungen zu untersuchen, etwa einen verspäteten Start oder eine langsame interne Verarbeitung. Warum das wichtig ist Entscheidend für die Einhaltung betrieblicher Vorgaben und das Liquiditätsmanagement. Woher beziehen Durch den Vergleich von EventTimestamp mit der Referenztabelle für Annahmefristen berechnet. Beispiele truefalse
	Genehmigungsebene ApprovalLevel	Die Hierarchieebene, die für die Autorisierung der Zahlung erforderlich ist oder verwendet wurde.
Beschreibung Gibt den Rang oder die Befugnisstufe an, die mit der Aktivität „Zahlung genehmigt“ verbunden ist. Im Dashboard zum Durchsatz der Genehmigungsbefugnisse lässt sich damit untersuchen, ob Genehmigende auf höheren Ebenen zu Engpässen werden. Die Verteilung der Zahlungen auf verschiedene Ebenen, etwa Ebene 1 und Ebene 3, hilft dabei, Richtlinien zur Delegation von Befugnissen zu optimieren. Warum das wichtig ist Gliedert Engpässe bei Genehmigungen nach Hierarchieebene. Woher beziehen Tabellen zu Benutzerrollen oder Genehmigungsworkflows. Beispiele Ebene 1FührungskraftDirektorCFO
	Geschäftseinheit BusinessUnit	Die Abteilung oder der Geschäftsbereich, von dem die Zahlung veranlasst wurde.
Beschreibung Ordnet die Zahlung der Organisationseinheit zu, die für die Ausgabe verantwortlich ist. Das erleichtert die Kostenverteilung und zeigt, in welchen Bereichen der Organisation besonders viel manuelle Nacharbeit anfällt oder Fehler entstehen. Das Attribut unterstützt das Compliance-Audit für Zahlungsabläufe und hilft sicherzustellen, dass die einzelnen Einheiten ihre jeweiligen regulatorischen oder internen Kontrollanforderungen einhalten. Warum das wichtig ist Liefert organisatorischen Kontext für die Leistungsbewertung. Woher beziehen Zuordnung der Kostenstellen oder Abteilungscode. Beispiele PrivatkundengeschäftGewerbliche KreditvergabeVermögensverwaltungBetrieb
	Nacharbeit IsRework	Kennzeichnet, ob diese Aktivität Teil einer Nacharbeitsschleife ist.
Beschreibung Ein boolesches Kennzeichen für Aktivitäten, die nach der Erkennung eines Fehlers und vor dessen Behebung stattfinden, oder für wiederholte Aktivitäten. Es unterstützt die KPI zur Nacharbeitsquote bei der Zahlungsvalidierung. Analysten können die Prozessübersicht so filtern, dass nur der „Happy Path“ oder ausschließlich der „Nacharbeitsablauf“ angezeigt wird. So lassen sich Fehlerursachen gezielt untersuchen. Warum das wichtig ist Trennt wertschöpfende Arbeit von Korrekturaufwand. Woher beziehen Anhand von Prozessschleifen berechnet. Beispiele truefalse

Erforderlich Empfohlen Optional

Aktivitäten der Zahlungsabwicklung

Erfassen Sie diese wichtigen Prozessschritte und Meilensteine in Ihrem Event Log, damit Sie Ihre Zahlungsabläufe präzise entdecken und optimieren können.

5 Empfohlen 8 Optional

	Aktivität	Beschreibung
	Zahlung abgeglichen	Der interne Abgleich der Transaktion mit Kontoauszügen oder Abwicklungsdateien. Damit ist der Buchungsvorgang abgeschlossen.
Warum das wichtig ist Erforderlich für die Kennzahl „Zeitspanne von der Abwicklung bis zum Abgleich“. Stellt sicher, dass die Finanzbücher korrekt abgeschlossen werden. Woher beziehen Protokolle des Abgleichmoduls, in denen der Status auf „Zugeordnet“ oder „Abgeglichen“ gesetzt wird. Erfassung Wird protokolliert, wenn die Transaktion abgeglichen wird. Ereignistyp explicit
	Zahlung abgewickelt	Der Geldtransfer ist abgeschlossen und im Hauptbuch verbucht. Aus Sicht der Bank ist die Transaktion damit finanziell abgeschlossen.
Warum das wichtig ist Der wichtigste Endpunkt für die „Straight-Through-Processing-Rate“. Zeigt an, dass das Geld tatsächlich transferiert wurde. Woher beziehen Transaktionsstatus „Gebucht“ oder ein „Buchungsdatum“-Zeitstempel im Hauptbuch. Erfassung Wird protokolliert, wenn die Buchung im Hauptbuch erfolgt. Ereignistyp explicit
	Zahlung genehmigt	Eine manuelle oder automatisierte Entscheidung, die Zahlung innerhalb der geltenden Befugnisgrenzen auszuführen. Dieser Schritt wird erfasst, wenn ein autorisierter Benutzer oder eine Systemregel die Freigabekennzeichnung aktualisiert.
Warum das wichtig ist Wichtig für die „Analyse der Autorisierungsdurchlaufzeit“. Verzögerungen an dieser Stelle weisen auf Engpässe in der manuellen Freigabekette hin. Woher beziehen Audit-Protokolle zeigen eine Benutzeraktion, durch die sich der Status von „Freigabe ausstehend“ zu „Genehmigt“ ändert. Erfassung Wird protokolliert, wenn die Freigabe erteilt wird Ereignistyp explicit
	Zahlungsanfrage erstellt	Die Zahlungsanweisung wird erstmals in das Fiserv-System eingegeben. Dieser Schritt wird ausdrücklich protokolliert, wenn ein Benutzer oder ein externes System eine Transaktion über eine API oder Benutzeroberfläche anstößt.
Warum das wichtig ist Markiert den Beginn des Prozesszeitraums. Dieser Timestamp ist wichtig, um die gesamte Durchlaufzeit zu berechnen und Engpässe bei der Erfassung zu erkennen. Woher beziehen Timestamp der Erstellung des Transaktionsverlaufs. Suchen Sie nach dem frühesten Datensatz mit der betreffenden Payment Transaction ID. Erfassung Wird protokolliert, wenn der Transaktionsdatensatz angelegt wird Ereignistyp explicit
	Zahlungsanweisung gesendet	Übertragung der Zahlungsdatei, zum Beispiel eines ACH-Sammelauftrags oder einer Wire-Nachricht, an das externe Netzwerk oder die Clearingstelle. Dies ist ein kritischer Übergabepunkt.
Warum das wichtig ist Wichtig für den „Monitor zur Einhaltung der Verarbeitungsfristen“. Stellt sicher, dass die Organisation die täglichen Bankfristen einhält. Woher beziehen Protokolle der Stapelverarbeitung oder Zeitstempel der Dateierstellung. Häufig als „Stapel erstellt“ oder „Datei übertragen“ protokolliert. Erfassung Wird protokolliert, wenn die Stapeldatei erstellt wird. Ereignistyp explicit
	Zahlung autorisiert	Die abschließende interne Bestätigung, dass die Gelder verfügbar und die Transaktion zur Ausführung freigegeben sind. Dieser Schritt kann gleichzeitig mit der Genehmigung erfolgen oder als separate Systemprüfung stattfinden.
Warum das wichtig ist Unterscheidet zwischen der Genehmigung durch Verantwortliche und der Autorisierung auf Systemebene. Wichtig für das Dashboard „Durchsatz der Genehmigungsbefugnisse“. Woher beziehen Statusänderung zu „Autorisiert“ oder „Zur Buchung bereit“. Erfassung Statusfeld vorher und nachher vergleichen Ereignistyp inferred
	Zahlung bestätigt	Eingang einer positiven Empfangsbestätigung (ACK) vom externen Netzwerk oder Gateway. Damit wird bestätigt, dass die nächste Stelle die Anweisung ordnungsgemäß erhalten hat.
Warum das wichtig ist Bestätigt den erfolgreichen Versand der „Zahlungsanweisung“. Fehlende Bestätigungen weisen auf Probleme mit der Netzwerkverbindung oder dem externen Format hin. Woher beziehen Protokolle der Verarbeitung eingehender Dateien oder API-Antwortcodes, die den Empfang bestätigen. Erfassung Wird protokolliert, wenn die ACK eingeht. Ereignistyp explicit
	Zahlung storniert	Beendet einen Zahlungsablauf vor der Abwicklung. Die Stornierung wird durch einen Benutzer oder eine Systemregel ausgelöst und stoppt die weitere Verarbeitung.
Warum das wichtig ist Macht unnötigen Aufwand und abgebrochene Arbeit sichtbar. Eine hohe Stornierungsrate nach der Genehmigung deutet auf ineffiziente Prozesse hin. Woher beziehen Statusänderung zu „Storniert“, „Ungültig“ oder „Gestoppt“. Erfassung Wird protokolliert, wenn sich der Status zu „Storniert“ ändert. Ereignistyp explicit
	Zahlung terminiert	Wird erfasst, wenn eine Zahlung genehmigt wurde, aber erst zu einem späteren Ausführungsdatum erfolgen soll. Das System stellt die Transaktion in eine Warteschlange, bis das Verarbeitungsfenster beginnt.
Warum das wichtig ist Erklärt Leerlaufzeiten im Prozess. Unterscheidet zwischen Verzögerungen durch einen Engpass und einem gezielten Warten bis zum Fälligkeitstermin. Woher beziehen Vergleich von „Eingangsdatum“ und „Ausführungsdatum“. Liegt das Ausführungsdatum in der Zukunft, ist dieser Status aktiv. Erfassung Wird durch den Vergleich von Feld X mit Feld Y abgeleitet. Ereignistyp calculated
	Zahlungsbenachrichtigung gesendet	Das System sendet eine Mitteilung per E-Mail oder SMS an den Zahlungspflichtigen oder Zahlungsempfänger, um die Transaktion zu bestätigen. Das sorgt für mehr Transparenz gegenüber Kunden.
Warum das wichtig ist Unterstützt die Kennzahl „Geschwindigkeit und Reaktionsfähigkeit bei Benachrichtigungen“. Lange Verzögerungen nach der Abwicklung beeinträchtigen das Vertrauen der Kunden. Woher beziehen Protokolle der Mitteilungen oder Tabellen zur Kundeninteraktionshistorie, verknüpft mit der Transaktions-ID. Erfassung Wird protokolliert, wenn eine E-Mail oder SMS ausgelöst wird. Ereignistyp explicit
	Zahlungsdetails validiert	Das System prüft Kontonummern, Bankleitzahlen und die Einhaltung von Formatvorgaben. Dieser Schritt lässt sich in der Regel daran erkennen, dass eine Transaktion ohne Fehler vom Status „Eingegangen“ in den Status „Ausstehend“ oder „Genehmigt“ wechselt.
Warum das wichtig ist Zeigt an, dass die erste automatisierte Prüfstufe bestanden wurde. Ein Fehler an dieser Stelle weist auf Probleme mit der Datenqualität hin, nicht auf Liquiditäts- oder Freigabeprobleme. Woher beziehen Abgeleitet aus einem Statuswechsel von „Eingegangen“ zu „Ausstehend“ oder „Bereit“ innerhalb kurzer Zeit. Erfassung Statusfeld vorher und nachher vergleichen Ereignistyp inferred
	Zahlungsfehler behoben	Bezeichnet die Korrektur einer zuvor fehlerhaften Transaktion. Dieser Schritt lässt sich daran erkennen, dass eine Transaktion von einem Fehlerstatus zurück in einen Verarbeitungs- oder gültigen Status wechselt.
Warum das wichtig ist Wichtig für die Berechnung der „Durchschnittlichen Behebungszeit von Zahlungsfehlern“. Damit lässt sich die Effizienz des Betriebsteams messen. Woher beziehen Abgeleitet, wenn sich der Transaktionsstatus von einem Fehlercode zu einem regulären Verarbeitungscode ändert. Erfassung Statusfeld vorher und nachher vergleichen Ereignistyp inferred
	Zahlungsfehler erkannt	Erfasst den Zeitpunkt, an dem eine Transaktion mit einem Fehlerstatus oder Ausnahmecode gekennzeichnet wird. Dazu kommt es, wenn Validierungsregeln nicht erfüllt werden oder externe Prüfungen negativ ausfallen.
Warum das wichtig ist Wichtig für das Dashboard „Validierungsfehler und Nacharbeiten“. Hohe Fallzahlen weisen auf Probleme mit der vorgelagerten Datenqualität hin. Woher beziehen Das Statusfeld der Transaktion wechselt zu einem Ausnahmecode, zum Beispiel „Ungültig“, „Zurückgestellt“ oder „Fehler“. Erfassung Wird protokolliert, wenn sich der Status zu „Fehler“ ändert Ereignistyp explicit

Anleitungen zum Extrahieren

So exportieren Sie Ihre Daten aus Fiserv

Schritte

1. Voraussetzungen und Konfiguration

Stellen Sie sicher, dass Sie Zugriff auf das Entwicklerportal von Fiserv Commerce Hub haben. Sie müssen einen API Key und ein API Secret erstellen, die mitunter auch als Client ID und Client Secret bezeichnet werden. Diese benötigen Berechtigungen für die Transaction Inquiry API oder die Search API. Prüfen Sie bei aktivierten IP-Beschränkungen, ob Ihre IP-Adresse in der Fiserv-Umgebung freigegeben ist.

2. Umgebung einrichten

Installieren Sie Python 3.8 oder höher auf Ihrem Extraktionsserver oder lokalen Rechner. Sie benötigen die Bibliotheken requests und pandas. Installieren Sie diese mit pip: pip install requests pandas. Erstellen Sie ein Arbeitsverzeichnis für das Skript und die Ausgabedateien.

3. Skript konfigurieren

Laden Sie das bereitgestellte Python-Skript in Ihr Arbeitsverzeichnis herunter. Öffnen Sie es und passen Sie den Konfigurationsabschnitt am Anfang an. Tragen Sie Ihre Werte für API_KEY, API_SECRET und BASE_URL ein. Verwenden Sie zum Testen die Sandbox-URL und für den abschließenden Lauf die Produktions-URL. Passen Sie START_DATE und END_DATE an den gewünschten Process-Mining-Zeitraum an.

4. Authentifizierung einrichten

Das Skript enthält eine Hilfsklasse für die spezifischen Authentifizierungsanforderungen von Fiserv. Dazu gehört in der Regel die Erstellung einer HMAC-Signatur aus Ihrem API Secret, dem Timestamp und dem Anfrageinhalt. Ändern Sie die Signaturerstellung nur, wenn Ihre Fiserv-Implementierung einen anderen Standard verwendet, zum Beispiel OAuth2-Bearer-Tokens.

5. Parsing-Logik verstehen

Das Skript ruft Transaktionen über die API ab. Die API liefert in der Regel einen Snapshot des Transaktionsobjekts mit verschiedenen Timestamps, etwa für Übermittlung, Autorisierung und Abwicklung. Das Skript liest dieses einzelne JSON-Objekt ein und wandelt es in mehrere Zeilen (Ereignisse) für das Event Log um. Ein JSON-Datensatz mit einem Übermittlungs- und einem Abwicklungs-Timestamp erzeugt beispielsweise mindestens zwei separate Zeilen in der CSV-Datei.

6. Seitennavigation verarbeiten

Das Skript enthält eine Schleife für die Seitennavigation. Fiserv-APIs begrenzen die Anzahl der Datensätze pro Antwort häufig auf 50 oder 100. Das Skript ruft automatisch die nächste Seite ab, bis alle Transaktionen im gewählten Zeitraum geladen sind. Achten Sie auf eine stabile Internetverbindung, da der Abruf großer Datensätze einige Zeit dauern kann.

7. Skript ausführen

Führen Sie das Skript über die Befehlszeile aus: python fiserv_extraction.py. Die Konsole zeigt den Fortschritt, die Zahl der verarbeiteten Seiten und die abgerufenen Transaktionen an. Achten Sie auf HTTP-Fehler 401 (Unauthorized) oder 429 (Rate Limit).

8. Ausgabe prüfen

Prüfen Sie nach Abschluss des Skripts, ob im Verzeichnis die Datei fiserv_event_log.csv vorhanden ist. Öffnen Sie die Datei und kontrollieren Sie, ob die Spalte ActivityName eine Auswahl der 13 erforderlichen Aktivitäten enthält und das Feld EventTimestamp korrekt formatiert ist.

9. Nachbearbeitung (optional)

Wenn Sie die Zeitzone anpassen müssen, zum Beispiel UTC in Ortszeit umwandeln, können Sie den pandas-Transformationsabschnitt im Skript ändern oder die Anpassung nach dem Upload in ProcessMind vornehmen.

10. In ProcessMind hochladen

Importieren Sie die CSV-Datei in ProcessMind. Ordnen Sie PaymentTransactionId der Case-ID, ActivityName der Aktivität und EventTimestamp dem Timestamp zu. Ordnen Sie numerische Spalten wie PaymentAmount den Attributen zu.

Konfiguration

API-Zugangsdaten: Erforderlich sind ein API Key und ein Secret oder Shared Secret. Stellen Sie sicher, dass diese Zugangsdaten Lesezugriff auf die Transaction-Reporting-Endpunkte haben.
Basis-URL: Verwenden Sie für die Produktion https://api.commerce.fiserv.com oder die beim Onboarding angegebene Zertifizierungs- bzw. Sandbox-URL.
Datumsbereich: Aufgrund der Größe der API-Antworten empfiehlt sich ein Extraktionszeitraum von 30 bis 90 Tagen. Führen Sie historische Ladevorgänge monatsweise aus.
Seitengröße: Auf 100 Datensätze pro Aufruf eingestellt, um Speicherbedarf und Netzwerkaufwand auszubalancieren.
Zeitzone: Die API liefert Timestamps in UTC. Das Skript behält dieses Format bei, damit die Daten regionsübergreifend einheitlich sind.
Wiederholungslogik: Eine einfache Wiederholungslogik für vorübergehende Netzwerk-Timeouts (HTTP 500/502/503) ist enthalten.

a Beispielabfrage python

import requests
import json
import time
import hmac
import hashlib
import base64
import uuid
import pandas as pd
from datetime import datetime, timedelta

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># CONFIGURATION
class=class="hl-string">"hl-comment"># ==========================================
API_KEY = class="hl-string">"YOUR_API_KEY"
API_SECRET = class="hl-string">"YOUR_API_SECRET"
BASE_URL = class="hl-string">"https://cert.api.fiservapps.com"  class=class="hl-string">"hl-comment"># Update to Production URL as needed
ENDPOINT = class="hl-string">"/ch/payments/v1/transaction-inquiry"
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-01-31"
PAGE_SIZE = 50
OUTPUT_FILE = class="hl-string">"fiserv_event_log.csv"

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># AUTHENTICATION HELPER
class=class="hl-string">"hl-comment"># ==========================================
def generate_headers(payload):
    class=class="hl-string">"hl-comment"># Fiserv Commerce Hub typically requires HMAC auth
    class=class="hl-string">"hl-comment"># This is a standard implementation pattern
    client_request_id = str(uuid.uuid4())
    timestamp = str(int(time.time() * 1000))
    
    class=class="hl-string">"hl-comment"># specific signature construction depends on Fiserv documentation version
    class=class="hl-string">"hl-comment"># standard pattern: apiKey + reqId + timestamp + payload
    raw_signature = API_KEY + client_request_id + timestamp + payload
    
    hmac_obj = hmac.new(
        API_SECRET.encode(class="hl-string">'utf-8'),
        raw_signature.encode(class="hl-string">'utf-8'),
        hashlib.sha256
    )
    message_signature = base64.b64encode(hmac_obj.digest()).decode(class="hl-string">'utf-8')
    
    return {
        class="hl-string">"Content-Type": class="hl-string">"application/json",
        class="hl-string">"Client-Request-Id": client_request_id,
        class="hl-string">"Api-Key": API_KEY,
        class="hl-string">"Timestamp": timestamp,
        class="hl-string">"Message-Signature": message_signature
    }

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># PARSING LOGIC (UNPIVOTING EVENTS)
class=class="hl-string">"hl-comment"># ==========================================
def extract_events_from_transaction(tx):
    events = []
    
    class=class="hl-string">"hl-comment"># Base Attributes
    case_id = tx.get(class="hl-string">"transactionId", class="hl-string">"")
    amount = tx.get(class="hl-string">"amount", {}).get(class="hl-string">"total", 0.0)
    currency = tx.get(class="hl-string">"amount", {}).get(class="hl-string">"currency", class="hl-string">"USD")
    method = tx.get(class="hl-string">"paymentMethod", {}).get(class="hl-string">"type", class="hl-string">"Unknown")
    payer_acc = tx.get(class="hl-string">"paymentMethod", {}).get(class="hl-string">"maskedAccountNumber", class="hl-string">"")
    class=class="hl-string">"hl-comment"># Identifying common attributes
    base_data = {
        class="hl-string">"PaymentTransactionId": case_id,
        class="hl-string">"SourceSystem": class="hl-string">"Fiserv Commerce Hub",
        class="hl-string">"LastDataUpdate": datetime.utcnow().isoformat(),
        class="hl-string">"PaymentAmount": amount,
        class="hl-string">"CurrencyCode": currency,
        class="hl-string">"PaymentMethod": method,
        class="hl-string">"PayerAccountNumber": payer_acc,
        class="hl-string">"PayeeAccountNumber": class="hl-string">"MerchantAccount", class=class="hl-string">"hl-comment"># Placeholder
        class="hl-string">"ErrorCode": tx.get(class="hl-string">"processorResponseDetails", {}).get(class="hl-string">"responseCode", class="hl-string">""),
        class="hl-string">"IsStraightThroughProcessing": class="hl-string">"True" class=class="hl-string">"hl-comment"># Default assumption unless error found
    }

    class=class="hl-string">"hl-comment"># Helper to append event
    def add_event(activity, timestamp_str, specific_attrs={}):
        if timestamp_str:
            row = base_data.copy()
            row.update({
                class="hl-string">"ActivityName": activity,
                class="hl-string">"EventTimestamp": timestamp_str
            })
            row.update(specific_attrs)
            events.append(row)

    class=class="hl-string">"hl-comment"># 1. Payment Request Created (Submission Time)
    submission_time = tx.get(class="hl-string">"submissionTime")
    add_event(class="hl-string">"Payment Request Created", submission_time)

    class=class="hl-string">"hl-comment"># 2. Payment Details Validated (Inferred: slightly after submission if no immediate 400 error)
    class=class="hl-string">"hl-comment"># We infer this exists if the transaction exists and has a submission time
    if submission_time:
        class=class="hl-string">"hl-comment"># Infer validation happened 1 second after submission
        val_time = (datetime.fromisoformat(submission_time.replace(class="hl-string">'Z', class="hl-string">'+00:00')) + timedelta(seconds=1)).isoformat()
        add_event(class="hl-string">"Payment Details Validated", val_time)

    class=class="hl-string">"hl-comment"># 3. Payment Error Identified / 4. Resolved
    status = tx.get(class="hl-string">"transactionStatus", class="hl-string">"")
    if status == class="hl-string">"FAILED":
        fail_time = tx.get(class="hl-string">"processorResponseDetails", {}).get(class="hl-string">"responseTimestamp", submission_time)
        add_event(class="hl-string">"Payment Error Identified", fail_time, {class="hl-string">"IsStraightThroughProcessing": class="hl-string">"False"})
    elif status == class="hl-string">"APPROVED" and tx.get(class="hl-string">"retryCount", 0) > 0:
        class=class="hl-string">"hl-comment"># Logic: If approved but had retries, an error was resolved
        add_event(class="hl-string">"Payment Error Resolved", submission_time) class=class="hl-string">"hl-comment"># Simplified assumption

    class=class="hl-string">"hl-comment"># 5. Payment Approved
    approval_time = tx.get(class="hl-string">"approvalTime")
    if approval_time:
        add_event(class="hl-string">"Payment Approved", approval_time)

    class=class="hl-string">"hl-comment"># 6. Payment Authorized
    auth_time = tx.get(class="hl-string">"authorizationTime")
    class=class="hl-string">"hl-comment"># If separate auth time not provided, use approval time
    if not auth_time and approval_time:
        auth_time = approval_time
    add_event(class="hl-string">"Payment Authorized", auth_time)

    class=class="hl-string">"hl-comment"># 7. Payment Scheduled (if future dated)
    req_exec_date = tx.get(class="hl-string">"requestedExecutionDate")
    if req_exec_date and req_exec_date > submission_time:
         add_event(class="hl-string">"Payment Scheduled", submission_time)

    class=class="hl-string">"hl-comment"># 8. Payment Instruction Sent
    gateway_time = tx.get(class="hl-string">"gatewayTransmitTime")
    add_event(class="hl-string">"Payment Instruction Sent", gateway_time)

    class=class="hl-string">"hl-comment"># 9. Payment Confirmed (Gateway ACK)
    gateway_ack = tx.get(class="hl-string">"gatewayAckTime")
    add_event(class="hl-string">"Payment Confirmed", gateway_ack)

    class=class="hl-string">"hl-comment"># 10. Payment Settled
    settle_time = tx.get(class="hl-string">"settlementTime") or tx.get(class="hl-string">"fundingDate")
    add_event(class="hl-string">"Payment Settled", settle_time)

    class=class="hl-string">"hl-comment"># 11. Payment Notification Sent (Inferred or specific field)
    notify_time = tx.get(class="hl-string">"customerNotificationEmailTime")
    add_event(class="hl-string">"Payment Notification Sent", notify_time)

    class=class="hl-string">"hl-comment"># 12. Payment Reconciled
    recon_time = tx.get(class="hl-string">"reconciliationDate")
    add_event(class="hl-string">"Payment Reconciled", recon_time)

    class=class="hl-string">"hl-comment"># 13. Payment Cancelled
    if status == class="hl-string">"VOIDED" or status == class="hl-string">"CANCELLED":
        void_time = tx.get(class="hl-string">"voidTime") or tx.get(class="hl-string">"lastUpdateTime")
        add_event(class="hl-string">"Payment Cancelled", void_time)

    return events

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># MAIN EXTRACTION LOOP
class=class="hl-string">"hl-comment"># ==========================================
def main():
    all_events = []
    page_number = 1
    has_more = True
    
    print(fclass="hl-string">"Starting extraction from {START_DATE} to {END_DATE}...")

    while has_more:
        class=class="hl-string">"hl-comment"># Construct Search Payload
        payload_dict = {
            class="hl-string">"startDate": START_DATE,
            class="hl-string">"endDate": END_DATE,
            class="hl-string">"page": page_number,
            class="hl-string">"limit": PAGE_SIZE
        }
        payload_json = json.dumps(payload_dict)
        
        headers = generate_headers(payload_json)
        full_url = BASE_URL + ENDPOINT
        
        try:
            response = requests.post(full_url, headers=headers, data=payload_json)
            
            if response.status_code == 200:
                data = response.json()
                transactions = data.get(class="hl-string">"reports", []) class=class="hl-string">"hl-comment"># Key depends on specific endpoint schema
                
                if not transactions:
                    print(fclass="hl-string">"No transactions found on page {page_number}. Finishing.")
                    has_more = False
                    break
                
                print(fclass="hl-string">"Processing page {page_number}, found {len(transactions)} transactions.")
                
                for tx in transactions:
                    events = extract_events_from_transaction(tx)
                    all_events.extend(events)
                
                class=class="hl-string">"hl-comment"># Pagination Check
                total_pages = data.get(class="hl-string">"totalPages", page_number)
                if page_number >= total_pages:
                    has_more = False
                else:
                    page_number += 1
            else:
                print(fclass="hl-string">"Error fetching data: {response.status_code} - {response.text}")
                has_more = False
                
        except Exception as e:
            print(fclass="hl-string">"Exception occurred: {str(e)}")
            has_more = False

    class=class="hl-string">"hl-comment"># ==========================================
    class=class="hl-string">"hl-comment"># EXPORT TO CSV
    class=class="hl-string">"hl-comment"># ==========================================
    if all_events:
        df = pd.DataFrame(all_events)
        class=class="hl-string">"hl-comment"># Column ordering
        cols = [
            class="hl-string">"PaymentTransactionId", class="hl-string">"ActivityName", class="hl-string">"EventTimestamp", 
            class="hl-string">"SourceSystem", class="hl-string">"PaymentAmount", class="hl-string">"CurrencyCode", class="hl-string">"PaymentMethod",
            class="hl-string">"PayerAccountNumber", class="hl-string">"ErrorCode", class="hl-string">"IsStraightThroughProcessing"
        ]
        class=class="hl-string">"hl-comment"># Ensure columns exist even if empty
        for c in cols:
            if c not in df.columns:
                df[c] = None
                
        df = df[cols]
        df.to_csv(OUTPUT_FILE, index=False)
        print(fclass="hl-string">"Extraction complete. {len(df)} rows written to {OUTPUT_FILE}")
    else:
        print(class="hl-string">"No events extracted.")

if __name__ == class="hl-string">"__main__":
    main()

Möchten Sie starten?

Optimieren Sie Ihre Finanz-Workflows, indem Sie dieses Template in Ihrer Fiserv-Umgebung einsetzen. Mit unserer Anleitung stellen Sie sicher, dass Ihnen die richtigen Daten vorliegen, um den Cashflow und die operative Compliance gezielt zu verbessern.

Zurück zum Leitfaden zur Prozessverbesserung Template herunterladen

Optimieren Sie die Zahlungsabwicklung und erreichen Sie noch heute 98 % STP

Vermeiden Sie Verzögerungen bei der Abstimmung und behalten Sie Ihre Fiserv-Workflows im Griff.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. In wenigen Minuten eingerichtet.

Ihr Daten-Template für die Zahlungsabwicklung

Ihr Daten-Template für die Zahlungsabwicklung

Attribute der Zahlungsabwicklung

Aktivitäten der Zahlungsabwicklung

Anleitungen zum Extrahieren

Python-Skript für die Fiserv Commerce Hub API

Schritte

1. Voraussetzungen und Konfiguration

2. Umgebung einrichten

3. Skript konfigurieren

4. Authentifizierung einrichten

5. Parsing-Logik verstehen

6. Seitennavigation verarbeiten

7. Skript ausführen

8. Ausgabe prüfen

9. Nachbearbeitung (optional)

10. In ProcessMind hochladen

Konfiguration

a Beispielabfrage python

Möchten Sie starten?

Optimieren Sie die Zahlungsabwicklung und erreichen Sie noch heute 98 % STP

Der Schutz Ihrer Daten ist uns wichtig