> Kontinuierliche Prozessoptimierung > Zahlungsabwicklung > Fiserv > Datenvorlage

Ihre Vorlage für Zahlungsverarbeitungs-`data`

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

Fiserv

Ihre Vorlage für Zahlungsverarbeitungs-`data`

← Zurück zum Optimierungsleitfaden

Attribute der Zahlungsabwicklung (20) Aktivitäten der Zahlungsabwicklung (13) Extraktionsleitfäden (1)

Ihre Vorlage für Zahlungsverarbeitungs-`data`

Dieses `Template` bietet einen strukturierten Rahmen, der Ihnen hilft, Ihre Fiserv-`data` in ein Format zu `mappen`, das für `Process Mining` und Analyse geeignet ist. Es skizziert die wesentlichen `Attribute` und `Activities`, 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 Finanzoperationen aufzeigt.

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

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

Vorlage herunterladen

Attribute der Zahlungsabwicklung

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

5 Erforderlich 10 Empfohlen 5 Optional

	Name	Beschreibung
	Aktivitätsname ActivityName	Das spezifische `Event` oder die 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 `Process Map` und ist entscheidend für das Verständnis der Abfolge von Operationen. Durch die Analyse der verschiedenen `Activities` 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 Events, die die Prozess-Timeline bilden. Datenquelle Transaktionshistorien-`Log` oder `Audit`-Tabellen für Statusänderungen. Beispiele Zahlungsanforderung erstelltZahlung autorisiertZahlungsfehler identifiziertZahlung beglichenZahlung storniert
	Ereignis-Timestamp EventTimestamp	Das genaue Datum und die Uhrzeit, zu der die 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 `Cycle Times`, `Lead Times` 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 Timestamps` sind notwendig, um `Events`, die in schneller Abfolge geschehen, präzise zu ordnen. Bedeutung Erforderlich, um `Events` zu ordnen und die Dauer der `Process Performance` zu berechnen. Datenquelle Audit Logs oder Transaktionsaktualisierungs-Timestamp-Spalten. Beispiele 2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:00:00Z2023-10-17T10:00:00Z
	Payment Transaction ID PaymentTransactionId	Die eindeutige Kennung für die spezifische Zahlungsanweisung oder den Transaktions`case`.
Beschreibung Dieses `Attribut` dient als zentraler Schlüssel zur Verknüpfung aller `Activities` 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 typischerweise der `Primärschlüssel` in den Transaktionshistorientabellen. Es ist essenziell für die Rekonstruktion des `Process Flows` und um sicherzustellen, dass getrennte `Events` (wie z.B. die Abwicklung, die Tage nach der Autorisierung erfolgt) korrekt mit demselben `Business Object` verknüpft werden. Bedeutung Es ist die fundamentale Case ID, die benötigt wird, um Events 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 Timestamp, wann der Datensatz zuletzt extrahiert oder aktualisiert wurde.
Beschreibung Gibt die Aktualität der für die Analyse verwendeten Daten an. Dies ist entscheidend, um zu bestimmen, ob die Dashboards Echtzeit-Operationen oder historische Snapshots 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 Cutoff Compliance oder aktiver Bottlenecks. Bedeutung Stellt Datenaktualität und -zuverlässigkeit 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 `data` stammen.
Beschreibung Identifiziert das spezifische Fiserv-Modul oder externe System, das das Event generiert hat. Dies ist besonders nützlich in komplexen Landschaften, 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
	Bearbeitungsdauer ProcessingDuration	Die für die spezifische `Activity` benötigte Zeit.
Beschreibung Repräsentiert die Dauer der `Activity` selbst oder die Zeit seit der vorherigen `Activity`. Dies ermöglicht eine detaillierte Analyse, wo im `Process` Zeit verbraucht wird. Es wird verwendet, um das `generische` Mapping der `Processing Time` zu füllen und hilft dabei, spezifische Schritte zu identifizieren, die konsistent langsamer sind als erwartet. Bedeutung Misst die Effizienz einzelner Prozessschritte. Datenquelle Aus Timestamp-Differenzen berechnet. Beispiele 00:05:0024:00:0000:00:30
	Fehlercode ErrorCode	Der spezifische Code, der generiert wird, wenn eine Zahlung die Validierung nicht besteht.
Beschreibung Erfasst den technischen oder geschäftlichen Error Code, der mit 'Payment Error Identified' Aktivitäten verbunden ist. Dieses Attribut ist die Grundlage für den Validation Error und Rework Tracker. Durch die Aggregation der Häufigkeiten spezifischer Error Codes kann die Organisation systemische Data Quality Issues (z.B. 'Invalid Routing Number') identifizieren und gezielte Fixes für die Validation Logic oder User Training implementieren. Bedeutung Identifiziert die Root Causes von Rework. Datenquelle Error Logs oder Transaktionsstatusdetails. Beispiele E-101INV_ACCNSF_ERRAUTH_FAIL
	Is 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 Error Identified', 'Payment Error 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 erleichtert. Bedeutung Kernmetrik für Prozesseffizienz und Automatisierungserfolg. Datenquelle Während der Daten Transformation berechnet. Beispiele truefalsch
	Kontonummer des Zahlers PayerAccountNumber	Die Kontonummer, von der die Gelder abgebucht werden.
Beschreibung Identifiziert das Quellkonto für die Zahlung. Dies ist eine Schlüsselkomponente der Duplicate 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 Duplicate Detection und Betrugsanalyse. Datenquelle Transaktionsdetails, Spalte Lastschriftskonto. Beispiele 123456789987654321ACC-001-992
	Kontonummer des Zahlungsempfängers PayeeAccountNumber	Die Kontonummer, der die Gelder gutgeschrieben werden.
Beschreibung Identifiziert das Zielkonto. Wie das Zahlerkonto ist dies entscheidend für die Duplicate Payment Detection View. Es stellt sicher, dass die Analyse spezifische Empfängerbeziehungen korrekt anspricht. Beim Cutoff 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 Duplicate Detection und Zahlungsempfängeranalyse. Datenquelle Transaktionsdetails, Spalte Gutschriftskonto oder Begünstigter. Beispiele 555000111222333444BEN-882-11
	Verarbeitender Benutzer ProcessingUser	Die Benutzer-ID oder der Systemagent, der für die `Activity` 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 'Error 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 Bottlenecks 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
	Währungscode CurrencyCode	Der ISO-Währungscode für den Zahlungsbetrag.
Beschreibung Gibt die Währung an, in der die Zahlung denominiert ist (z.B. USD, EUR). Dieses `Attribut` ist entscheidend 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 monetäre Wert 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 "Duplicate 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 Duplicate 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 Cutoff Compliance Monitor` verwendet, um Transaktionen zu kennzeichnen, bei denen die Gefahr einer Verspätung besteht. Der Vergleich des `Timestamp` "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 fundamental für die Authorization Cycle Time 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 `Process Flows` 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 die 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 Timestamp mit der Cutoff Reference Tabelle. Beispiele truefalsch
	Empfängerbank BeneficiaryBank	Der Name oder die Kennung der Empfängerbank.
Beschreibung Identifiziert das Finanzinstitut, das die Zahlung empfängt. Dies ist nützlich für die Analyse von Settlement Delays, 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 analysieren, ob höhere Genehmiger zu Bottlenecks 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 `Bottlenecks` 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 Performance. Datenquelle Kostenstellen-Mapping oder Abteilungscode. Beispiele Retail BankingGewerbliche KreditvergabeWealth ManagementVorgänge
	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 Prozesslandkarte 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 truefalsch

Erforderlich Empfohlen Optional

Aktivitäten der Zahlungsabwicklung

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 `Timestamp` '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 Cycle Time Analysis'. Verzögerungen hier deuten auf Bottlenecks 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-Cycle Time und die Identifizierung von Intake Bottlenecks. Datenquelle `Timestamp` der Erstellung der Transaktionshistorientabelle. Suchen Sie nach dem frühesten `Record` 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 die Clearingstelle. Dies ist ein kritischer Übergabepunkt.
Bedeutung Kritisch für den 'Processing Cutoff Compliance Monitor'. Stellt sicher, dass die Organisation die täglichen Banking Cutoffs einhält. Datenquelle Batch Processing Logs oder Dateigenerierungs-Timestamps. 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 'Cancelled' 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 typischerweise dann abgeleitet, wenn eine Transaktion erfolgreich von einem empfangenen Status in einen ausstehenden oder genehmigten Status übergeht, ohne einen `Fehler` auszulösen.
Bedeutung Zeigt an, dass das erste automatisierte Gate passiert wurde. Ein Fehler hier deutet auf Data 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 Errors'. Es hilft, die Effizienz des Operations Teams zu messen. Datenquelle Abgeleitet, wenn der Transaktionsstatus von einem Error 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 'Validation Error and Rework Tracker' Dashboard. Hohe Volumina hier weisen auf Upstream Data Quality Probleme hin. Datenquelle Das Feld `Transaktionsstatus` ändert sich zu einem `Exception Code` (z.B. 'Ungültig', 'Halten', 'Fehler'). Erfassen Protokolliert, wenn Status zu 'Error' wechselt Ereignistyp explicit

Extraktionsleitfäden

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 typischerweise die Generierung einer HMAC Signature unter Verwendung Ihres API Secret, des Timestamp 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 typischerweise einen Snapshot des Transaction Object zurück, der verschiedene Timestamps (z.B. Submission Time, Authorization Time, Settlement Time) enthält. Das Skript parst dieses einzelne JSON Object und entpivotisiert es in multiple Rows (Events) für den Event Log. Zum Beispiel generiert ein einzelner JSON Record mit einem Submission Timestamp und einem Settlement Timestamp 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 Records 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 Datasets 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) Errors.

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 Activities enthält und dass das EventTimestamp 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 dies 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 EventTimestamp auf Timestamp. 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 die 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 Records pro Call, um Memory Usage und Network Overhead auszugleichen.
Timezone: Die API gibt Timestamps in UTC zurück. Das Skript bewahrt diesen Standard, um Konsistenz über Regionen hinweg zu gewährleisten.
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()

Ihre Vorlage für Zahlungsverarbeitungs-`data`

Ihre Vorlage für Zahlungsverarbeitungs-`data`

Attribute der Zahlungsabwicklung

Aktivitäten der Zahlungsabwicklung

Extraktionsleitfäden

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

Ihre Vorlage für Zahlungsverarbeitungs-data

Ihre Vorlage für Zahlungsverarbeitungs-data

Attribute der Zahlungsabwicklung

Aktivitäten der Zahlungsabwicklung

Extraktionsleitfäden

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

Ihre Vorlage für Zahlungsverarbeitungs-`data`

Ihre Vorlage für Zahlungsverarbeitungs-`data`