> Kontinuierliche Prozessoptimierung > Zahlungsabwicklung > Fiserv > Datenvorlage

Ihr Template für ZahlungsabwicklungsDaten

Name: Zahlungsabwicklung Process Mining Data Template
Creator: ProcessMind
License: https://creativecommons.org/licenses/by/4.0/

Fiserv

Ihr Template für ZahlungsabwicklungsDaten

← Zurück zum Optimierungsleitfaden

Zahlungsabwicklungs-Attribute (19) Zahlungsabwicklungs-Aktivitäten (13) Extraktionsanleitungen (1)

Ihr Template für ZahlungsabwicklungsDaten

Diese Vorlage bietet einen strukturierten Rahmen, der Sie hilft, Ihre Fiserv-`data` in ein Format zu `abbilden`, das für `Process Mining` und Analyse geeignet ist. Es skizziert die wesentlichen Attribute und `Aktivitäten`, die erforderlich sind, um klare Transparenz in Ihre Abwicklungs- und Abstimmungszyklen zu erhalten. Indem Sie diesem Leitfaden folgen, können Sie ein leistungsstarkes `Event Log` erstellen, das Ineffizienzen und `Compliance`-Risiken in Ihren Finanzprozesse aufzeigt.

Empfohlene Attribute für die Zahlungsanalyse
Wichtige Prozessmeilensteine zum Monitoring
Technische Anleitung zur Fiserv-`Daten`-Extraktion.

Neu bei Event-Logs? Erfahren Sie wie Sie ein Process-Mining-Event-Log erstellen.

Vorlage herunterladen

Zahlungsabwicklungs-Attribute

Diese empfohlenen `data`-Felder liefern den notwendigen Kontext für Ihr `Event Log`, um eine vollständige Analyse Ihres gesamten ZahlungsLebenszyklus zu unterstützen.

5 Erforderlich 9 Empfohlen 5 Optional

	Name	Beschreibung
	Aktivitätsname ActivityName	Das spezifische `Event` oder den Antrag bearbeitet.ie Statusänderung, die im Zahlungsprozess aufgetreten ist.
Beschreibung Dieses `Attribut` beschreibt den durchgeführten Schritt, wie z.B. 'Zahlungsanforderung erstellt' oder 'Zahlung abgewickelt'. Es definiert die Knoten in der `Prozessdarstellung (Process Map)` und ist maßgeblich für das Verständnis der Abfolge von Operationen. Durch die Analyse der verschiedenen `Aktivitäten` können Unternehmen den `Workflow` visualisieren, übersprungene Schritte identifizieren und `non-compliant paths` erkennen, bei denen obligatorische Validierungen oder Genehmigungen umgangen wurden. Bedeutung Definiert die Ereignisse, die die Prozess-Timeline bilden. Datenquelle Transaktionshistorien-`Log` oder `Audit`-Tabellen für Statusänderungen. Beispiele Zahlungsanforderung erstelltZahlung autorisiertZahlungsfehler identifiziertZahlung beglichenZahlung storniert
	Ereignis-Zeitstempel EventTimestamp	Das genaue Datum und die Uhrzeit, zu der den Antrag bearbeitet.ie Aktivität stattgefunden hat.
Beschreibung Dieses `Attribut` zeichnet den genauen Moment auf, in dem ein `Event` stattfand. Es ist die Grundlage für alle zeitlichen Analysen, einschließlich `Durchlaufzeits`, `Durchlaufzeiten` und `Bottleneck`-Identifikation. In `Dashboards` treiben diese `data` die Berechnung der Dauer zwischen den Schritten an, wie z.B. die Zeit von 'Zahlungsanforderung erstellt' bis 'Zahlung autorisiert'. `High-precision Zeitstempels` sind notwendig, um `Ereignisse`, die in schneller Abfolge geschehen, präzise zu ordnen. Bedeutung Erforderlich, um `Ereignisse` zu ordnen und die Dauer der `Process Leistungsfähigkeit` zu berechnen. Datenquelle Audit-Logs oder Transaktionsaktualisierungs-Zeitstempel-Spalten. Beispiele 2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:00:00Z2023-10-17T10:00:00Z
	Zahlungstransaktions-ID PaymentTransactionId	Die eindeutige Kennung für die spezifische Zahlungsanweisung oder den Antrag bearbeitet.en Transaktions`case`.
Beschreibung Dieses `Attribut` dient als zentraler Schlüssel zur Verknüpfung aller `Aktivitäten` innerhalb eines einzigen ZahlungsLebenszyklus. Es ermöglicht `Analysten`, den Verlauf von der ersten Anforderung über die Validierung, Genehmigung bis zur endgültigen Abwicklung oder Stornierung zu verfolgen. In Fiserv-Umgebungen ist dies in der Regel der `Primärschlüssel` in den Transaktionshistorientabellen. Es ist wichtig für die Rekonstruktion des `Prozessflusss` und um sicherzustellen, dass getrennte `Ereignisse` (wie z.B. die Abwicklung, die Tage nach der Autorisierung erfolgt) korrekt mit demselben `Business Object` verknüpft werden. Bedeutung Es ist die wesentliche Case-ID, die benötigt wird, um Ereignisse zu Prozessinstanzen zu gruppieren. Datenquelle Konsultieren Sie die Fiserv-Dokumentation für Transaction- oder Payment Header Tabellen. Beispiele TRX-99823101PMT-2023-88421002938475CHK-5512WIRE-US-9921
	Letzte Datenaktualisierung LastDataUpdate	Der Zeitstempel, wann der Datensatz zuletzt extrahiert oder aktualisiert wurde.
Beschreibung Gibt die Aktualität der für die Analyse verwendeten Daten an. Dies ist maßgeblich, um zu bestimmen, ob die Dashboards Echtzeit-Operationen oder historische Momentaufnahmes widerspiegeln. Es hilft Benutzern, den angezeigten Metriken zu vertrauen, indem es sicherstellt, dass sie keine Entscheidungen auf Basis veralteter Daten treffen, insbesondere beim Monitoring der Cut-off-Compliance oder aktiver Engpässe. Bedeutung Stellt Datenaktualität und -leistungsstarkkeit sicher. Datenquelle 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 Identifiziert das spezifische Fiserv-Modul oder externe System, das das Event generiert hat. Dies ist besonders nützlich in komplexen Umgebungen, in denen Zahlungen in einem Front-End-Channel entstehen und in einem Back-End Core Banking System abgewickelt werden könnten. Es ermöglicht Analysten, die Prozessansicht nach dem Ursprungssystem zu filtern, wodurch sichergestellt wird, dass die Analyse auf spezifische technische Umgebungen oder Integrationspunkte ausgerichtet werden kann. Bedeutung Bietet technischen Kontext und Daten-Lineage. Datenquelle Hardcoded während der Extraktion oder System-MetaDaten. Beispiele Fiserv PremierFiserv SignatureFiserv DNAFiserv Enterprise Payments Platform
	Bearbeiter ProcessingUser	Die Benutzer-ID oder den Antrag bearbeitet.er Systemagent, der für die Aktivität verantwortlich ist.
Beschreibung Identifiziert, wer die spezifische Aktion durchgeführt hat, sei es ein menschlicher Genehmiger oder ein Systemautomatisierungs-Bot. Diese Daten treiben die Dashboards 'Fehler Resolution Cycle Efficiency' und 'Approval Authority Throughput' an. Durch die Verfolgung von Benutzern können Analysten Schulungsbedarfe für Personen mit hohen Fehlerraten identifizieren oder Engpässe erkennen, bei denen bestimmte Genehmiger mit Anfragen überlastet sind. Bedeutung Ermöglicht Ressourcenanalyse und Bottleneck-Identifizierung. Datenquelle Audit-Logs, Benutzer-ID-Spalte. Beispiele jdoeSYSTEM_BATCHmsmith_approverAPI_USER
	Fehlercode ErrorCode	Der spezifische Code, der generiert wird, wenn eine Zahlung die Validierung nicht besteht.
Beschreibung Erfasst den technischen oder geschäftlichen Fehler Code, der mit 'Payment Fehler Identified' Aktivitäten verbunden ist. Dieses Attribut ist die Grundlage für den Validierung Fehler und Rework Tracker. Durch die Aggregation der Häufigkeiten spezifischer Fehler Codes kann die Organisation systemische Daten Quality Issues (z.B. 'Invalid Routing Number') identifizieren und gezielte Fixes für die Validierung Logic oder Benutzer Training implementieren. Bedeutung Identifiziert die Ursachen für Nacharbeit. Datenquelle Fehler Logs oder Transaktionsstatusdetails. Beispiele E-101INV_ACCNSF_ERRAUTH_FAIL
	Ist STP IsStraightThroughProcessing	Flag, das anzeigt, ob die Zahlung keinen manuellen Eingriff erforderte.
Beschreibung Ein berechnetes boolesches Attribut, das wahr ist, wenn der Case keine Schritte wie 'Payment Fehler Identified', 'Payment Fehler Resolved' oder manuelle 'Payment Approved' Schritte enthält (je nach Definition). Dies unterstützt direkt den KPI für die Straight Through Processing Rate. Es ermöglicht eine binäre Segmentierung des Prozesses: rein automatisierte Flows gegenüber solchen, die menschlichen Eingriff erfordern, was eine klare Sicht auf das Automatisierungspotenzial vereinfacht. Bedeutung Kernmetrik für Prozesseffizienz und Automatisierungserfolg. Datenquelle Während der Daten Transformation berechnet. Beispiele JaNein
	Kontonummer des Zahlers PayerAccountNumber	Die Kontonummer, von der den Antrag bearbeitet.ie Gelder abgebucht werden.
Beschreibung Identifiziert das Quellkonto für die Zahlung. Dies ist eine Schlüsselkomponente der Duplizieren Payment Detection View. In Kombination mit Zahlungsempfänger, Betrag und Zeit bildet es den einzigartigen Fingerabdruck, der verwendet wird, um versehentliche Doppelzahlungen abzufangen. Es ermöglicht auch die Analyse des Zahlungsvolumens nach Ursprungskonto, um die aktivsten internen Portfolios zu identifizieren. Bedeutung Wesentlicher Bestandteil für Duplizieren Detection und Betrugsanalyse. Datenquelle Transaktionsdetails, Spalte Lastschriftskonto. Beispiele 123456789987654321ACC-001-992
	Kontonummer des Zahlungsempfängers PayeeAccountNumber	Die Kontonummer, der den Antrag bearbeitet.ie Gelder gutgeschrieben werden.
Beschreibung Identifiziert das Zielkonto. Wie das Zahlerkonto ist dies wichtig für die Duplizieren Payment Detection View. Es stellt sicher, dass die Analyse spezifische Empfängerbeziehungen korrekt anspricht. Beim Cut-off-Compliance Monitoring kann die Kenntnis des Zahlungsempfängers helfen, strategische Anbieter oder kritische Settlements zu priorisieren, die nicht fehlschlagen dürfen. Bedeutung Wesentlicher Bestandteil für Duplizieren Detection und Zahlungsempfängeranalyse. Datenquelle Transaktionsdetails, Spalte Gutschriftskonto oder Begünstigter. Beispiele 555000111222333444BEN-882-11
	Währungscode CurrencyCode	Der ISO-Währungscode für den Zahlungsbetrag.
Beschreibung Gibt die Währung an, in der den Antrag bearbeitet.ie Zahlung denominiert ist (z.B. USD, EUR). Dieses `Attribut` ist maßgeblich für das `Dashboard` "Währungs- und Methodenvolumen-Trends", da es dem Unternehmen ermöglicht, die Exposition gegenüber verschiedenen Fremdwährungen zu überwachen. Es wird auch verwendet, um Beträge für das globale `Reporting` zu `normalisieren` und sicherzustellen, dass `Duplikatsprüfungen` Transaktionen mit gleichem numerischem Wert, aber unterschiedlichen Währungen nicht fälschlicherweise als `Fehler` kennzeichnen. Bedeutung Notwendig für die Multicurrency Processing Analysis. Datenquelle Transaktionskopfzeilentabelle, Spalte Währung. Beispiele USDEURGBPCADJPY
	Zahlungsbetrag PaymentAmount	Der Geldwert der Zahlungstransaktion.
Beschreibung Dieses `Attribut` repräsentiert den finanziellen Wert, der mit der Zahlung verbunden ist. Es ist eine primäre Dimension für die Segmentierung der Analyse, die es Benutzern ermöglicht, zwischen hochwertigen strategischen Zahlungen und routinemäßigen Zahlungen mit geringem Wert zu unterscheiden. Es ist unerlässlich für die "Duplizieren Payment Detection View", wo identische Beträge, gepaart mit Zahler-/Empfängerdetails, potenzielle `Fehler` kennzeichnen. Es unterstützt auch die `Genehmigungsautoritätsanalyse`, da höhere Beträge oft unterschiedliche `Workflow-Pfade` auslösen. Bedeutung Kritisch für die Finanzrisikoanalyse und Duplizieren Detection. Datenquelle Transaktionskopfzeilentabelle, Spalte Betrag. Beispiele 150.0025000.5010.991000000.00
	Zahlungsfälligkeitsdatum PaymentDueDate	Das Datum, bis zu dem die Zahlung verarbeitet werden muss.
Beschreibung Das Zieldatum für den Zahlungsabschluss. Dies wird im `Processing Cut-off-Compliance Monitor` verwendet, um Transaktionen zu kennzeichnen, bei denen die Gefahr einer Verspätung besteht. Der Vergleich des `Zeitstempel` "Zahlung Abgewickelt" mit diesem `Attribut` ermöglicht die Berechnung von Pünktlichkeitskennzahlen und hilft dem Unternehmen, das Vertrauen der Zahlungsempfänger zu wahren. Bedeutung Referenzpunkt zur Messung der Einhaltung von SLAs. Datenquelle Zahlungsanweisungsdetails. Beispiele 2023-11-012023-11-15
	Zahlungsmethode PaymentMethod	Der Mechanismus, der zur Ausführung der Zahlung verwendet wird (z.B. `Wire`, ACH).
Beschreibung Klassifiziert die Transaktion nach ihrem Processing Rail. Dieses Attribut ist wesentlich für die Authorization Durchlaufzeit Analysis, da verschiedene Methoden sehr unterschiedliche Standard Operating Procedures und Service Level Agreements aufweisen. Die Analyse von Prozessvarianten nach Zahlungsmethode hilft zu isolieren, ob Verzögerungen systemisch für einen spezifischen Channel (wie internationale Überweisungen) oder allgemein für die Organisation sind. Bedeutung Segmentiert `Prozessflusss` nach der verwendeten Infrastruktur. Datenquelle Spalte Transaktionstyp oder Instrumentencode. Beispiele `Wire`ACHScheckRTPInterne Weiterleitung
	Cutoff verpasst IsCutoffMissed	Flag, das anzeigt, ob die Zahlung nach dem täglichen Bank-Cutoff gesendet wurde.
Beschreibung Ein berechneter boolescher Wert, der den Antrag bearbeitet.ie Zeit des 'Payment Instruction Sent' mit der täglichen Cutoff Time für die spezifische Währung/Methode vergleicht. Dies unterstützt den KPI für die Cutoff Adherence Rate. Das Identifizieren von verpassten Cutoffs hilft, die Ursachen von Verzögerungen zu untersuchen, sei es durch späte Initiierung oder langsame interne Verarbeitung. Bedeutung Kritisch für Operational Compliance und Liquiditätsmanagement. Datenquelle Berechnet durch Vergleich von Event Zeitstempel mit der Cutoff Reference Tabelle. Beispiele JaNein
	Empfängerbank BeneficiaryBank	Der Name oder den Antrag bearbeitet.ie Kennung der Empfängerbank.
Beschreibung Identifiziert das Finanzinstitut, das die Zahlung empfängt. Dies ist nützlich für die Analyse von Settlement Verzögerungen, da spezifische Empfängerbanken unterschiedliche Verarbeitungsgeschwindigkeiten oder Integrationsprobleme aufweisen können. Es fügt dem Settlement to Reconciliation Gap Dashboard eine weitere Dimension hinzu, die hervorhebt, ob Verzögerungen extern (bankspezifisch) oder intern sind. Bedeutung Analyse externer Abhängigkeiten. Datenquelle Transaktionsdetails, Spalte Bank-ID oder Name. Beispiele ChaseBank of AmericaWells FargoCitibank
	Genehmigungsstufe ApprovalLevel	Die hierarchische Ebene, die für die Autorisierung der Zahlung erforderlich ist oder verwendet wird.
Beschreibung Zeigt die Senioritäts- oder Berechtigungsstufe an, die mit der 'Payment Approved' Aktivität verbunden ist. Dies wird im Approval Authority Throughput Dashboard verwendet, um zu analysierenn, ob höhere Genehmiger zu Engpässe werden. Das Verständnis der Verteilung von Zahlungen über verschiedene Ebenen (z.B. Level 1 vs. Level 3) hilft, die Delegationsrichtlinien für Befugnisse zu optimieren. Bedeutung Segmentiert `Engpässe` bei Genehmigungen nach Hierarchie. Datenquelle Benutzerrolle oder `Genehmigungs-Workflow`-Tabellen. Beispiele Level 1ManagerDirektorCFO
	Geschäftseinheit BusinessUnit	Die Abteilung oder Division, die die Zahlung initiiert hat.
Beschreibung Kategorisiert die Zahlung nach der für die Ausgabe verantwortlichen Organisationseinheit. Dies hilft bei der Kostenzuordnung und dem Verständnis, welche Teile der Organisation die meiste manuelle Nachbearbeitung oder Fehler generieren. Es unterstützt das Payment Path Compliance Audit, indem es sicherstellt, dass verschiedene Einheiten ihre spezifischen regulatorischen oder internen Kontrollanforderungen einhalten. Bedeutung Bietet organisatorischen Kontext für die Leistungsfähigkeit. Datenquelle Kostenstellen-Mapping oder Abteilungscode. Beispiele Retail BankingGewerbliche KreditvergabeWealth ManagementOperations
	Ist Nacharbeit IsRework	Flag, das anzeigt, ob diese spezifische Aktivität Teil einer Rework Loop ist.
Beschreibung Ein boolesches Flag, das Aktivitäten kennzeichnet, die nach der Identifizierung eines Fehlers, aber vor dessen Behebung, oder wiederholte Aktivitäten stattfinden. Dies unterstützt den KPI für die Nachbearbeitungsrate bei der Zahlungsvalidierung. Es ermöglicht Analysten, die Prozessablauf so zu filtern, dass nur der 'Happy Path' angezeigt wird, oder umgekehrt, sich vollständig auf den 'Rework Path' zu konzentrieren, um Fehlerursachen zu verstehen. Bedeutung Isoliert wertschöpfende Arbeit von Korrekturarbeit. Datenquelle Basierend auf Prozessschleifen berechnet. Beispiele JaNein

Erforderlich Empfohlen Optional

Zahlungsabwicklungs-Aktivitäten

Erfassen Sie diese wesentlichen Prozessschritte und Meilensteine in Ihrem Event Log, um eine präzise Entdeckung und Optimierung Ihrer Zahlungs-Workflows zu ermöglichen.

5 Empfohlen 8 Optional

	Aktivität	Beschreibung
	Zahlung abgestimmt	Der interne Abgleich der Transaktion mit Kontoauszügen oder Abwicklungsdateien. Dies schließt den Kreis für die Buchhaltung.
Bedeutung Erforderlich für die 'Abwicklungs- und Abstimmungslücke'. Gewährleistet den korrekten Abschluss der Finanzbücher. Datenquelle Das Abstimmungsmodul protokolliert Statusaktualisierungen auf 'Abgeglichen' oder 'Abgestimmt'. Erfassen Protokolliert, wenn Abstimmungsübereinstimmung erfolgt Ereignistyp explicit
	Zahlung beglichen	Die Bewegung der Gelder wird finalisiert und im Hauptbuch verbucht. Dies markiert den finanziellen Abschluss der Transaktion aus Sicht der Bank.
Bedeutung Der primäre Endpunkt für die `Straight Through Processing Rate`. Zeigt an, dass das Bargeld tatsächlich bewegt wurde. Datenquelle Transaktionsstatus 'Gebucht' oder Vorhandensein eines `Zeitstempel` 'Buchungsdatum' im `Ledger`. Erfassen Protokolliert, wenn Hauptbuchbuchung erfolgt Ereignistyp explicit
	Zahlung genehmigt	Eine manuelle oder automatisierte Entscheidung, die Zahlung auf Basis von Berechtigungslimits fortzusetzen. Dies wird erfasst, wenn ein autorisierter Benutzer oder eine Systemregel das Approval Flag aktualisiert.
Bedeutung Schlüssel für die 'Authorization Durchlaufzeit Analysis'. Verzögerungen hier deuten auf Engpässe in der menschlichen Genehmigungskette hin. Datenquelle Audit-Logs, die eine Benutzeraktion zeigen, welche den Status von 'Pending Approval' zu 'Approved' ändert. Erfassen Protokolliert, wenn Genehmigungsaktion erfolgt Ereignistyp explicit
	Zahlungsanforderung erstellt	Die erstmalige Eingabe der Zahlungsanweisung in das Fiserv-System. Dies wird explizit protokolliert, wenn ein Benutzer oder ein externes System eine Transaktion über eine API oder Schnittstelle initiiert.
Bedeutung Markiert den Beginn der Prozess-Timeline. Wesentlich für die Berechnung der Gesamt-Durchlaufzeit und die Identifizierung von Intake Engpässe. Datenquelle `Zeitstempel` der Erstellung der Transaktionshistorientabelle. Suchen Sie nach dem frühesten `Datensatz` mit der spezifischen Zahlungs-Transaktions-ID. Erfassen Protokolliert, wenn TransaktionsDatensatz eingefügt Ereignistyp explicit
	Zahlungsanweisung gesendet	Die Übermittlung der Zahlungsdatei (z.B. ACH-Batch, `Wire`-Nachricht) an das externe Netzwerk oder den Antrag bearbeitet.ie Clearingstelle. Dies ist ein kritischer Übergabepunkt.
Bedeutung Kritisch für den 'Processing Cut-off-Compliance Monitor'. Stellt sicher, dass die Organisation die täglichen Banking Cutoffs einhält. Datenquelle Batch Processing Logs oder Dateigenerierungs-Zeitstempels. Oft als 'Batch Created' oder 'File Transmitted' protokolliert. Erfassen Protokolliert, wenn Batch-Datei generiert Ereignistyp explicit
	Zahlung autorisiert	Die finale interne Bestätigung, dass Gelder verfügbar sind und die Transaktion zur Ausführung freigegeben ist. Dies kann gleichzeitig mit der Genehmigung oder als eigenständige Systemprüfung erfolgen.
Bedeutung Differenziert zwischen managerialer Genehmigung und System-Level-Autorisierung. Wichtig für das 'Approval Authority Throughput' Dashboard. Datenquelle Statusänderung auf 'Autorisiert' oder 'Bereit zum Buchen'. Erfassen Statusfeld vor/nachher vergleichen Ereignistyp inferred
	Zahlung bestätigt	Erhalt einer positiven Bestätigung (ACK) vom externen Netzwerk oder Gateway. Dies bestätigt, dass die Anweisung von der nächsten Instanz korrekt empfangen wurde.
Bedeutung Validiert, dass die 'Anweisung gesendet' erfolgreich war. Lücken hier weisen auf Netzwerkverbindungsprobleme oder externe `Formatprobleme` hin. Datenquelle Inbound File Processing Logs oder API Response Codes, die den Empfang bestätigen. Erfassen Protokolliert, wenn ACK empfangen Ereignistyp explicit
	Zahlung storniert	Die Beendigung eines Zahlungsflusses vor der Abwicklung, initiiert durch einen Benutzer oder eine Systemregel. Dies stoppt jede weitere Verarbeitung.
Bedeutung Identifiziert Verschwendung und abgebrochene Arbeit. Hohe Stornierungsraten nach der Genehmigung deuten auf Prozesseffizienz-Mängel hin. Datenquelle Statusänderung auf 'Storniert', 'Ungültig' oder 'Gestoppt'. Erfassen Protokolliert, wenn Status zu 'Abbrechenled' wechselt Ereignistyp explicit
	Zahlung terminiert	Tritt auf, wenn eine Zahlung genehmigt, aber für ein zukünftiges Effektivdatum gehalten wird. Das System reiht die Transaktion ein, bis das Bearbeitungsfenster sich öffnet.
Bedeutung Erklärt Leerlaufzeiten im Prozess. Differenziert zwischen einer durch ein Bottleneck verursachten Verzögerung und einem bewussten Warten auf das Fälligkeitsdatum. Datenquelle Vergleich von 'Entry Date' und 'Effective Date'. Wenn 'Effective Date' in der Zukunft liegt, ist dieser Zustand aktiv. Erfassen Ableitung durch Vergleich von Feld X mit Y Ereignistyp calculated
	Zahlungsbenachrichtigung gesendet	Das System löst eine Kommunikation (E-Mail/SMS) an den Zahler oder Empfänger aus, die die Transaktion bestätigt. Dies erhöht die Kundentransparenz.
Bedeutung Unterstützt 'Benachrichtigungsgeschwindigkeit und Reaktionsfähigkeit'. Lange Lücken nach der Abwicklung verringern das Kundenvertrauen. Datenquelle Kommunikations-Logs oder Customer Interaction History Tables, die mit der Transaction ID verknüpft sind. Erfassen Protokolliert, wenn E-Mail/SMS ausgelöst Ereignistyp explicit
	Zahlungsdetails validiert	Das System prüft Kontonummern, Bankleitzahlen und die `Format-Compliance`. Dies wird in der Regel dann abgeleitet, wenn eine Transaktion erfolgreich von einem empfangenen Status in einen ausstehende Zahlungen identifizieren.enden oder genehmigten Status übergeht, ohne einen `Fehler` auszulösen.
Bedeutung Zeigt an, dass das erste automatisierte Gate passiert wurde. Ein Fehler hier deutet auf Daten Quality Issues hin und nicht auf Liquiditäts- oder Genehmigungsprobleme. Datenquelle Abgeleitet aus einer Statusänderung von 'Received' zu 'Pending' oder 'Ready' innerhalb eines kurzen Zeitrahmens. Erfassen Statusfeld vor/nachher vergleichen Ereignistyp inferred
	Zahlungsfehler behoben	Stellt die Korrektur einer zuvor fehlerhaften Transaktion dar. Dies wird abgeleitet, wenn eine Transaktion von einem Fehlerstatus zurück in einen Verarbeitungs- oder gültigen Status wechselt.
Bedeutung Wesentlicher Bestandteil zur Berechnung der 'Mean Time to Resolve Payment Fehlers'. Es hilft, die Effizienz des Operations Teams zu messen. Datenquelle Abgeleitet, wenn der Transaktionsstatus von einem Fehler Code zu einem normalen Processing Code aktualisiert wird. Erfassen Statusfeld vor/nachher vergleichen Ereignistyp inferred
	Zahlungsfehler identifiziert	Erfasst den Moment, in dem eine Transaktion mit einem Fehlerstatus oder Exception Code gekennzeichnet wird. Dies geschieht, wenn Validierungsregeln fehlschlagen oder externe Checks eine negative Antwort zurückgeben.
Bedeutung Kritisch für das 'Validierung Fehler and Rework Tracker' Dashboard. Hohe Volumina hier weisen auf Upstream Daten Quality Probleme hin. Datenquelle Das Feld `Transaktionsstatus` ändert sich zu einem `Exception Code` (z.B. 'Ungültig', 'Halten', 'Fehler'). Erfassen Protokolliert, wenn Status zu 'Fehler' wechselt Ereignistyp explicit

Extraktionsanleitungen

So erhalten Sie Ihre Daten von Fiserv

Schritte

1. VorabKonfiguration

Stellen Sie sicher, dass Sie Zugriff auf das Fiserv Commerce Hub Developer Portal haben. Sie müssen einen API Key und API Secret (manchmal auch als Client ID und Client Secret bezeichnet) mit Berechtigungen für den Zugriff auf die Transaction Inquiry oder Search API generieren. Verifizieren Sie, dass Ihre IP-Adresse in der Fiserv-Umgebung whitelisted ist, falls IP Restrictions aktiviert sind.

2. Umgebungseinrichtung

Installieren Sie Python 3.8 oder höher auf Ihrem Extraktionsserver oder lokalen Rechner. Sie benötigen die requests und pandas Libraries. Diese können Sie via pip installieren: pip install requests pandas. Erstellen Sie ein Working Directory für Ihr Skript und die Output Files.

3. SkriptKonfiguration

Laden Sie das bereitgestellte Python-Skript in Ihr Working Directory herunter. Öffnen Sie das Skript und aktualisieren Sie den Configuration Section am Anfang. Sie müssen Ihren spezifischen API_KEY, API_SECRET und die BASE_URL (verwenden Sie die Sandbox-URL für Tests und die Production-URL für den finalen Run) angeben. Passen Sie START_DATE und END_DATE an, um das gewünschte Process Mining Window abzudecken.

4. Implementierung der Authentifizierungslogik

Das Skript enthält eine Helper Class, um die spezifischen Authentifizierungsanforderungen von Fiserv zu handhaben, die in der Regel die Generierung einer HMAC Signature unter Verwendung Ihres API Secret, des Zeitstempel und des Request Payload umfassen. Modifizieren Sie die Signature Generation Logic nicht, es sei denn, Ihre spezifische Fiserv-Implementierung verwendet einen anderen Standard (z.B. OAuth2 Bearer Tokens).

5. Verständnis der Parsing Logic

Das Skript fragt die API nach Transactions ab. Die API gibt in der Regel einen Momentaufnahme des Transaction Object zurück, der verschiedene Zeitstempels (z.B. Submission Time, Authorization Time, Settlement Time) enthält. Das Skript parst dieses einzelne JSON Object und entpivotisiert es in multiple Rows (Ereignisse) für den Event Log. Zum Beispiel generiert ein einzelner JSON Datensatz mit einem Submission Zeitstempel und einem Settlement Zeitstempel mindestens zwei unterschiedliche Rows in Ihrer CSV.

6. Paginierung Handhaben

Das Skript implementiert einen Loop, um Pagination zu handhaben. Fiserv APIs limitieren die Anzahl der Datensatzs pro Response (oft 50 oder 100). Das Skript fordert automatisch die nächste Page an, bis alle Transactions im Date Range abgerufen wurden. Stellen Sie sicher, dass Ihre Internetverbindung stabil ist, da dies bei großen Datensets Zeit in Anspruch nehmen kann.

7. Ausführung

Führen Sie das Skript via Command Line aus: python fiserv_extraction.py. Die Konsole zeigt den Fortschritt an, die Anzahl der verarbeiteten Pages und abgerufenen Transactions. Achten Sie auf HTTP 401 (Unauthorized) oder 429 (Rate Limit) Fehlers.

8. Output Verifizierung

Sobald das Skript beendet ist, überprüfen Sie das Directory auf eine Datei namens fiserv_Event_log.csv. Öffnen Sie diese Datei und verifizieren Sie, dass die ActivityName Column eine Mischung aus den 13 erforderlichen Aktivitäten enthält und dass das EventZeitstempel Feld korrekt formatiert ist.

9. Nachbearbeitung (Optional)

Falls Sie spezifische Timezone Adjustments benötigen (z.B. die Konvertierung von UTC in die lokale Zeit), können Sie den Pandas Transformation Section im Skript modifizieren oder den Antrag bearbeitet.ies innerhalb von ProcessMind nach dem Upload handhaben.

10. Upload zu ProcessMind

Importieren Sie die CSV-Datei in ProcessMind. Mappen Sie PaymentTransactionId auf Case-ID, ActivityName auf Activity und EventZeitstempel auf Zeitstempel. Stellen Sie sicher, dass numerische Columns wie PaymentAmount als Attribute gemappt werden.

Konfiguration

API Credentials: Erfordert API Key und Secret/Shared Secret. Stellen Sie sicher, dass diese Lesezugriff auf Transaction Reporting Endpoints haben.
Base URL: Für die Produktion auf https://api.commerce.fiserv.com oder den Antrag bearbeitet.ie spezifische Cert-/Sandbox-URL setzen, die während des Onboardings bereitgestellt wird.
Date Range: Das empfohlene Extraktionsfenster beträgt 30 bis 90 Tage aufgrund der API Payload Größen. Für historische Loads führen Sie das Skript in monatlichen Chunks aus.
Page Size: Konfiguriert auf 100 Datensatzs pro Call, um Memory Usage und Network Overhead auszugleichen.
Timezone: Die API gibt Zeitstempels in UTC zurück. Das Skript bewahrt diesen Standard, um Konsistenz über Regionen hinweg zu sicherstellen.
Retry Logic: Enthält einen grundlegenden Retry Mechanismus für intermittierende Netzwerk-Timeouts (HTTP 500/502/503).

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()

Ihr Template für ZahlungsabwicklungsDaten

Ihr Template für ZahlungsabwicklungsDaten

Zahlungsabwicklungs-Attribute

Zahlungsabwicklungs-Aktivitäten

Extraktionsanleitungen

Fiserv Commerce Hub API Python Script

Schritte

1. VorabKonfiguration

2. Umgebungseinrichtung

3. SkriptKonfiguration

4. Implementierung der Authentifizierungslogik

5. Verständnis der Parsing Logic

6. Paginierung Handhaben

7. Ausführung

8. Output Verifizierung

9. Nachbearbeitung (Optional)

10. Upload zu ProcessMind

Konfiguration

a Beispielabfrage python

Bereit, um loszulegen?

Zahlungsabwicklung optimieren und heute 98% STP erreichen

Ihr Template für ZahlungsabwicklungsDaten

Ihr Template für ZahlungsabwicklungsDaten

Zahlungsabwicklungs-Attribute

Zahlungsabwicklungs-Aktivitäten

Extraktionsanleitungen

Fiserv Commerce Hub API Python Script

Schritte

1. VorabKonfiguration

2. Umgebungseinrichtung

3. SkriptKonfiguration

4. Implementierung der Authentifizierungslogik

5. Verständnis der Parsing Logic

6. Paginierung Handhaben

7. Ausführung

8. Output Verifizierung

9. Nachbearbeitung (Optional)

10. Upload zu ProcessMind

Konfiguration

a Beispielabfrage python

Ihre Privatsphäre ist uns wichtig

Bereit, um loszulegen?

Zahlungsabwicklung optimieren und heute 98% STP erreichen