> Continu verbeteren van processen > Betalingsverwerking > Fiserv > Datatemplate

Datatemplate voor betalingsverwerking

Name: Betalingsverwerking-datatemplate voor process mining
Creator: ProcessMind
License: https://creativecommons.org/licenses/by/4.0/

Fiserv

← Terug naar de verbetergids

Attributen voor betalingsverwerking (19) Activiteiten voor betalingsverwerking (13) Extractiegidsen (1)

Datatemplate voor betalingsverwerking

Deze template biedt een vaste structuur om Fiserv-data om te zetten naar een formaat dat geschikt is voor process mining en analyse. Je ziet welke essentiële attributen en activiteiten nodig zijn voor een helder beeld van afwikkelings- en afstemmingscycli. Met deze gids maak je een event log dat inefficiënties en compliancerisico’s in je financiële processen zichtbaar maakt.

Aanbevolen attributen voor betalingsanalyse
Belangrijke procesmomenten om te volgen
Technische gids voor data-extractie uit Fiserv

Nieuw met event logs? Lees hoe je een event log voor process mining maakt.

Template downloaden

Attributen voor betalingsverwerking

Deze aanbevolen datavelden geven je event log de context die nodig is om de volledige levenscyclus van betalingen te analyseren.

5 Verplicht 9 Aanbevolen 5 Optioneel

	Naam	Beschrijving
	Activiteitsnaam ActivityName	De gebeurtenis of statuswijziging in het betaalproces.
Beschrijving Dit attribuut beschrijft de uitgevoerde stap, zoals ‘Betaalverzoek aangemaakt’ of ‘Betaling afgewikkeld’. Het bepaalt de knooppunten in de proceskaart en is nodig om de volgorde van de activiteiten te begrijpen. Door de verschillende activiteiten te analyseren, kunnen organisaties de workflow visualiseren, overgeslagen stappen opsporen en afwijkende routes vinden waarbij verplichte controles of goedkeuringen zijn overgeslagen. Waarom dit belangrijk is Bepaalt welke gebeurtenissen de tijdlijn van het proces vormen. Waar vind je dit? Transactielog of controletabellen met statuswijzigingen. Voorbeelden Betalingsverzoek aangemaaktBetaling geautoriseerdBetalingsfout vastgesteldBetaling afgewikkeldBetaling geannuleerd
	ID van betalingstransactie PaymentTransactionId	De unieke identificatiecode van de betaalopdracht of transactie-case.
Beschrijving Dit attribuut is de centrale sleutel waarmee je alle activiteiten binnen één betaalproces aan elkaar koppelt. Analisten kunnen hiermee het hele verloop volgen, van het eerste verzoek tot de validatie, goedkeuring en uiteindelijke afwikkeling of annulering. In Fiserv-omgevingen is dit meestal de primaire sleutel in de transactielogtabellen. Deze sleutel is nodig om het procesverloop te reconstrueren en losse gebeurtenissen, zoals een afwikkeling dagen na de autorisatie, aan dezelfde zakelijke transactie te koppelen. Waarom dit belangrijk is Dit is de belangrijkste Case-ID om gebeurtenissen in procesinstanties te groeperen. Waar vind je dit? Raadpleeg de Fiserv-documentatie voor tabellen met transacties of betalingskoppen. Voorbeelden TRX-99823101PMT-2023-88421002938475CHK-5512WIRE-US-9921
	Timestamp van gebeurtenis EventTimestamp	De exacte datum en tijd waarop de activiteit plaatsvond.
Beschrijving Dit attribuut legt het exacte moment van een gebeurtenis vast. Het vormt de basis voor alle tijdsanalyses, waaronder doorlooptijden en het opsporen van bottlenecks. In dashboards wordt deze data gebruikt om de tijd tussen stappen te berekenen, bijvoorbeeld tussen ‘Betaalverzoek aangemaakt’ en ‘Betaling geautoriseerd’. Nauwkeurige timestamps zijn nodig om gebeurtenissen die kort na elkaar plaatsvinden in de juiste volgorde te zetten. Waarom dit belangrijk is Nodig om gebeurtenissen op volgorde te zetten en de doorlooptijden van het proces te berekenen. Waar vind je dit? Auditlogs of kolommen met timestamps van transactie-updates. Voorbeelden 2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:00:00Z2023-10-17T10:00:00Z
	Bronsysteem SourceSystem	De naam van het systeem waar de data vandaan komt.
Beschrijving Geeft aan welke Fiserv-module of welk extern systeem de gebeurtenis heeft gegenereerd. Dit is vooral handig in complexe omgevingen waar betalingen in een front-endkanaal kunnen beginnen en in een back-endsysteem voor core banking worden afgewikkeld. Analisten kunnen de procesweergave filteren op bronsysteem en de analyse zo richten op specifieke technische omgevingen of integratiepunten. Waarom dit belangrijk is Geeft technische context en inzicht in de herkomst van data. Waar vind je dit? Vast ingesteld tijdens de extractie of afkomstig uit systeemmetadata. Voorbeelden Fiserv PremierFiserv SignatureFiserv DNAFiserv Enterprise Payments Platform
	Laatste data-update LastDataUpdate	De timestamp waarop de gegevens voor het laatst zijn geëxtraheerd of vernieuwd.
Beschrijving Geeft aan hoe actueel de data voor de analyse is. Zo kun je bepalen of dashboards de bedrijfsvoering realtime weergeven of historische momentopnamen. Dit helpt gebruikers vertrouwen te hebben in de getoonde metrieken. Zo voorkom je beslissingen op basis van verouderde data, vooral bij het bewaken van bankdeadlines of actieve bottlenecks. Waarom dit belangrijk is Houdt de data actueel en betrouwbaar. Waar vind je dit? Systeemtijd op het moment dat ETL wordt uitgevoerd. Voorbeelden 2023-10-27T12:00:00Z2023-10-28T06:00:00Z
	Betaalmethode PaymentMethod	De manier waarop de betaling wordt uitgevoerd, bijvoorbeeld via Wire of ACH.
Beschrijving Deelt transacties in op basis van het gebruikte betaalnetwerk. Dit attribuut is belangrijk voor de analyse van de autorisatiedoorlooptijd, omdat per betaalmethode andere standaardprocedures en serviceafspraken gelden. Door procesvarianten per betaalmethode te analyseren, zie je of vertragingen alleen voorkomen bij een bepaald kanaal, zoals internationale overboekingen, of in de hele organisatie. Waarom dit belangrijk is Deelt processtromen in op basis van de gebruikte infrastructuur. Waar vind je dit? Kolom met transactietype of instrumentcode. Voorbeelden OverboekingACHChequeRTPInterne overboeking
	Betalingsbedrag PaymentAmount	De geldwaarde van de betalingstransactie.
Beschrijving Dit attribuut geeft de geldwaarde van de betaling weer. Je kunt het gebruiken om de analyse op te splitsen in bijvoorbeeld strategische betalingen met een hoge waarde en routinematige transacties met een lage waarde. Het is nodig voor de weergave voor detectie van dubbele betalingen. Gelijke bedragen in combinatie met gegevens over betaler en ontvanger kunnen op fouten wijzen. Het attribuut ondersteunt ook de analyse van goedkeuringsbevoegdheden, omdat voor hogere bedragen vaak andere workflows gelden. Waarom dit belangrijk is Belangrijk voor financiële risicoanalyses en het opsporen van dubbele betalingen. Waar vind je dit? Transactiekop, kolom Amount. Voorbeelden 150.0025000.5010.991000000.00
	Foutcode ErrorCode	De specifieke code die wordt gegenereerd wanneer een betaling de validatie niet doorstaat.
Beschrijving Legt de technische of zakelijke foutcode vast die hoort bij activiteiten als ‘Betalingsfout vastgesteld’. Dit attribuut vormt de basis voor de tracker voor validatiefouten en herstelwerk. Door te tellen hoe vaak specifieke foutcodes voorkomen, kan de organisatie structurele problemen met de datakwaliteit opsporen, zoals ‘Ongeldig routeringsnummer’. Vervolgens kunnen gerichte aanpassingen aan de validatieregels of training van gebruikers helpen. Waarom dit belangrijk is Spoort de oorzaken van herstelwerk op. Waar vind je dit? Foutlogs of gegevens over de transactiestatus. Voorbeelden E-101INV_ACCNSF_ERRAUTH_FAIL
	Rekeningnummer betaler PayerAccountNumber	Het rekeningnummer waarvan het geld wordt afgeschreven.
Beschrijving Geeft aan van welke rekening de betaling afkomstig is. Dit is een belangrijk onderdeel van de weergave voor detectie van dubbele betalingen. In combinatie met de ontvanger, het bedrag en het tijdstip vormt het een unieke combinatie waarmee onbedoelde dubbele betalingen kunnen worden opgespoord. Je kunt er ook het betalingsvolume per rekening mee analyseren en zien welke interne portefeuilles het actiefst zijn. Waarom dit belangrijk is Nodig om dubbele betalingen en fraude op te sporen. Waar vind je dit? Transactiegegevens, kolom Debit Account. Voorbeelden 123456789987654321ACC-001-992
	Rekeningnummer ontvanger PayeeAccountNumber	Het rekeningnummer waarop het geld wordt bijgeschreven.
Beschrijving Geeft aan op welke rekening het geld wordt bijgeschreven. Net als de rekening van de betaler is dit belangrijk voor de weergave voor detectie van dubbele betalingen. Zo richt de analyse zich op de juiste begunstigden. Bij het bewaken van bankdeadlines helpt informatie over de ontvanger om prioriteit te geven aan strategische leveranciers of belangrijke afwikkelingen die op tijd moeten plaatsvinden. Waarom dit belangrijk is Nodig om dubbele betalingen op te sporen en ontvangers te analyseren. Waar vind je dit? Transactiegegevens, kolom Credit Account of Beneficiary. Voorbeelden 555000111222333444BEN-882-11
	STP IsStraightThroughProcessing	Markering die aangeeft of de betaling zonder handmatige tussenkomst is verwerkt.
Beschrijving Een berekend booleaans attribuut dat waar is als de case geen stappen bevat zoals ‘Betalingsfout vastgesteld’, ‘Betalingsfout opgelost’ of handmatige ‘Betaling goedgekeurd’, afhankelijk van de definitie. Dit ondersteunt rechtstreeks de KPI voor het percentage Straight Through Processing. Hiermee kun je het proces opdelen in volledig geautomatiseerde routes en routes waarvoor menselijke tussenkomst nodig is. Zo wordt duidelijk waar verdere automatisering mogelijk is. Waarom dit belangrijk is Belangrijke metriek voor procesefficiëntie en succesvolle automatisering. Waar vind je dit? Berekend tijdens de datatransformatie. Voorbeelden truefalse
	Uiterste betaaldatum PaymentDueDate	De datum waarop de betaling verwerkt moet zijn.
Beschrijving De datum waarop de betaling uiterlijk afgerond moet zijn. De monitor voor naleving van verwerkingstermijnen gebruikt deze datum om transacties te markeren die mogelijk te laat zijn. Door de timestamp van ‘Betaling afgewikkeld’ met dit attribuut te vergelijken, kun je meten hoeveel betalingen op tijd zijn uitgevoerd. Zo helpt het de organisatie het vertrouwen van ontvangers te behouden. Waarom dit belangrijk is Referentiepunt om naleving van SLA’s te meten. Waar vind je dit? Gegevens van de betaalopdracht. Voorbeelden 2023-11-012023-11-15
	Valutacode CurrencyCode	De ISO-valutacode voor het betalingsbedrag.
Beschrijving Geeft aan in welke valuta de betaling is uitgedrukt, bijvoorbeeld USD of EUR. Dit attribuut is nodig voor het dashboard met trends in valuta- en betaalmethodevolumes. Daarmee kan de organisatie de blootstelling aan verschillende valuta volgen. Je kunt het ook gebruiken om bedragen voor wereldwijde rapportages te normaliseren en te voorkomen dat controles transacties met hetzelfde bedrag maar een andere valuta ten onrechte als dubbel aanmerken. Waarom dit belangrijk is Nodig voor analyses van betalingen in meerdere valuta. Waar vind je dit? Transactiekop, kolom Currency. Voorbeelden USDEURGBPCADJPY
	Verwerkende gebruiker ProcessingUser	De gebruikers-ID of systeemagent die verantwoordelijk is voor de activiteit.
Beschrijving Geeft aan wie de actie heeft uitgevoerd, bijvoorbeeld een medewerker die goedkeurt of een geautomatiseerde systeemagent. Deze data voedt de dashboards voor efficiëntie bij foutafhandeling en doorvoer van goedkeuringsbevoegdheden. Door gebruikers te volgen, kunnen analisten opleidingsbehoeften opsporen bij medewerkers met veel fouten. Ook worden bottlenecks zichtbaar wanneer bepaalde goedkeurders te veel verzoeken krijgen. Waarom dit belangrijk is Ondersteunt bronanalyse en het opsporen van bottlenecks. Waar vind je dit? Auditlogs, kolom User ID. Voorbeelden jdoeSYSTEM_BATCHmsmith_approverAPI_USER
	Bank van begunstigde BeneficiaryBank	De naam of identificatiecode van de ontvangende bank.
Beschrijving Geeft aan welke financiële instelling de betaling ontvangt. Dit is nuttig bij het analyseren van vertragingen in de afwikkeling, omdat ontvangende banken verschillende verwerkingssnelheden of integratieproblemen kunnen hebben. Het voegt een extra dimensie toe aan het dashboard met het verschil tussen afwikkeling en afstemming. Zo zie je of vertragingen extern zijn, bijvoorbeeld bij een specifieke bank, of intern ontstaan. Waarom dit belangrijk is Analyse van externe afhankelijkheden. Waar vind je dit? Transactiegegevens, kolom Bank ID of Name. Voorbeelden ChaseBank of AmericaWells FargoCitibank
	Bedrijfseenheid BusinessUnit	De afdeling of divisie die de betaling heeft gestart.
Beschrijving Deelt betalingen in op basis van de organisatie-eenheid die verantwoordelijk is voor de uitgave. Zo zie je waar de meeste handmatige correcties of fouten ontstaan en kun je kosten toewijzen. Dit ondersteunt de compliance-audit van betaalroutes. Je kunt ermee controleren of verschillende bedrijfseenheden voldoen aan hun specifieke wettelijke of interne controlevereisten. Waarom dit belangrijk is Geeft context over de organisatie bij prestatieanalyses. Waar vind je dit? Koppeling met kostenplaatsen of afdelingscode. Voorbeelden RetailbankierenZakelijke kredietverleningVermogensbeheerBedrijfsvoering
	Deadline gemist IsCutoffMissed	Markering die aangeeft of de betaling na de dagelijkse deadline van de bank is verzonden.
Beschrijving Een berekende booleaanse waarde die het tijdstip van ‘Betaalopdracht verzonden’ vergelijkt met de dagelijkse deadline voor de betreffende valuta en betaalmethode. Dit ondersteunt de KPI voor het percentage nagekomen deadlines. Gemiste deadlines helpen de oorzaken van vertragingen te onderzoeken, bijvoorbeeld een late start of trage interne verwerking. Waarom dit belangrijk is Belangrijk voor compliance in de bedrijfsvoering en liquiditeitsbeheer. Waar vind je dit? Berekend door EventTimestamp te vergelijken met de tabel Cutoff Reference. Voorbeelden truefalse
	Goedkeuringsniveau ApprovalLevel	Het hiërarchische niveau dat nodig is of wordt gebruikt om de betaling te autoriseren.
Beschrijving Geeft het senioriteits- of bevoegdheidsniveau aan dat hoort bij de activiteit ‘Betaling goedgekeurd’. Met het dashboard voor doorvoer van goedkeuringsbevoegdheden kun je nagaan of goedkeurders op hogere niveaus bottlenecks vormen. Als je ziet hoe betalingen over de niveaus zijn verdeeld, bijvoorbeeld niveau 1 tegenover niveau 3, kun je het beleid voor gedelegeerde bevoegdheden verbeteren. Waarom dit belangrijk is Maakt bottlenecks bij goedkeuring per hiërarchisch niveau zichtbaar. Waar vind je dit? Tabellen met gebruikersrollen of goedkeuringsworkflows. Voorbeelden Niveau 1ManagerDirecteurCFO
	Herstelwerk IsRework	Markering die aangeeft of deze activiteit deel uitmaakt van een herstelronde.
Beschrijving Een booleaanse markering voor activiteiten die plaatsvinden nadat een fout is vastgesteld maar voordat deze is opgelost, of voor herhaalde activiteiten. Dit ondersteunt de KPI voor het percentage herstelwerk bij betalingsvalidatie. Analisten kunnen de proceskaart filteren om alleen de ‘Ideale route’ te tonen. Ze kunnen ook juist alleen de route met herstelwerk bekijken om te begrijpen hoe fouten ontstaan. Waarom dit belangrijk is Maakt onderscheid tussen werk dat waarde toevoegt en correctiewerk. Waar vind je dit? Berekend op basis van proceslussen. Voorbeelden truefalse

Verplicht Aanbevolen Optioneel

Activiteiten voor betalingsverwerking

Leg deze essentiële processtappen en mijlpalen vast in je event log. Zo kun je betalingsworkflows nauwkeurig in kaart brengen en optimaliseren.

5 Aanbevolen 8 Optioneel

	Activiteit	Beschrijving
	Betaalopdracht verzonden	Het verzenden van het betaalbestand, bijvoorbeeld een ACH-batch of Wire-bericht, naar het externe netwerk of clearing house. Dit is een belangrijk overdrachtsmoment.
Waarom dit belangrijk is Belangrijk voor de ‘Monitor voor naleving van verwerkingstermijnen’. Hiermee controleer je of de organisatie de dagelijkse bankdeadlines haalt. Waar vind je dit? Logs van batchverwerking of timestamps voor het genereren van bestanden. Vaak geregistreerd als ‘Batch aangemaakt’ of ‘Bestand verzonden’. Vastleggen Geregistreerd wanneer het batchbestand is gegenereerd Gebeurtenistype explicit
	Betaling afgestemd	De interne afstemming van de transactie met bankafschriften of afwikkelingsbestanden. Hiermee is de boekhoudkundige verwerking afgerond.
Waarom dit belangrijk is Nodig voor het ‘Verschil tussen afwikkeling en afstemming’. Hiermee controleer je of de financiële administratie correct wordt afgesloten. Waar vind je dit? Logs van de afstemmingsmodule waarin de status wordt bijgewerkt naar ‘Gematcht’ of ‘Afgestemd’. Vastleggen Geregistreerd wanneer de afstemming is gematcht Gebeurtenistype explicit
	Betaling afgewikkeld	De geldbeweging is afgerond en in het grootboek geboekt. Vanuit het perspectief van de bank is de transactie hiermee financieel voltooid.
Waarom dit belangrijk is Het belangrijkste eindpunt voor de KPI ‘Percentage Straight Through Processing’. Geeft aan dat het geld daadwerkelijk is overgemaakt. Waar vind je dit? Transactiestatus ‘Geboekt’ of een timestamp in het grootboek bij ‘Boekingsdatum’. Vastleggen Geregistreerd wanneer de boeking in het grootboek plaatsvindt Gebeurtenistype explicit
	Betaling goedgekeurd	Een handmatige of automatische beslissing om de betaling toe te staan op basis van de bevoegdheidslimieten. Dit wordt vastgelegd wanneer een bevoegde gebruiker of systeemregel de goedkeuringsstatus wijzigt.
Waarom dit belangrijk is Belangrijk voor de ‘Analyse van de doorlooptijd van autorisaties’. Vertragingen wijzen op bottlenecks in de goedkeuringsketen. Waar vind je dit? Auditlog met een gebruikersactie die de status verandert van ‘Wacht op goedkeuring’ naar ‘Goedgekeurd’. Vastleggen Vastgelegd wanneer de betaling wordt goedgekeurd Gebeurtenistype explicit
	Betalingsverzoek aangemaakt	De betaalinstructie wordt voor het eerst ingevoerd in het Fiserv-systeem. Dit wordt vastgelegd wanneer een gebruiker of extern systeem via een API of interface een transactie start.
Waarom dit belangrijk is Dit markeert het begin van de procesduur. De timestamp is nodig om de totale doorlooptijd te berekenen en bottlenecks bij de invoer te vinden. Waar vind je dit? Timestamp waarop de tabel met transactiegeschiedenis is aangemaakt. Zoek de oudste registratie met de betreffende Payment Transaction ID. Vastleggen Vastgelegd wanneer de transactie is ingevoerd Gebeurtenistype explicit
	Betaalgegevens gevalideerd	Het systeem controleert rekeningnummers, banknummers en de juiste opmaak. Dit wordt meestal afgeleid wanneer een transactie zonder foutmelding van de status ontvangen naar in behandeling of goedgekeurd gaat.
Waarom dit belangrijk is Dit geeft aan dat de eerste automatische controle is doorlopen. Een fout in deze stap wijst op problemen met de datakwaliteit, niet met de liquiditeit of goedkeuring. Waar vind je dit? Af te leiden uit een statuswijziging van ‘Ontvangen’ naar ‘In behandeling’ of ‘Gereed’ binnen korte tijd. Vastleggen Vergelijk het statusveld voor en na Gebeurtenistype inferred
	Betaling bevestigd	Ontvangst van een positieve bevestiging (ACK) van het externe netwerk of de gateway. Hiermee wordt bevestigd dat de volgende partij de opdracht correct heeft ontvangen.
Waarom dit belangrijk is Controleert of ‘Betaalopdracht verzonden’ is geslaagd. Hiaten wijzen op problemen met de netwerkverbinding of het externe bestandsformaat. Waar vind je dit? Logs van inkomende bestanden of API-responscodes die de ontvangst bevestigen. Vastleggen Geregistreerd wanneer ACK is ontvangen Gebeurtenistype explicit
	Betaling geannuleerd	Beëindiging van een betaalproces vóór de afwikkeling, gestart door een gebruiker of systeemregel. Hiermee stopt alle verdere verwerking.
Waarom dit belangrijk is Maakt verspilling en afgebroken werk zichtbaar. Veel annuleringen na goedkeuring kunnen wijzen op inefficiënte processen. Waar vind je dit? Statuswijziging naar ‘Geannuleerd’, ‘Ongeldig’ of ‘Gestopt’. Vastleggen Geregistreerd wanneer de status verandert in Geannuleerd Gebeurtenistype explicit
	Betaling geautoriseerd	De laatste interne bevestiging dat er voldoende geld beschikbaar is en dat de transactie kan worden uitgevoerd. Dit kan tegelijk met de goedkeuring gebeuren of als aparte systeemcontrole.
Waarom dit belangrijk is Maakt onderscheid tussen goedkeuring door een manager en autorisatie op systeemniveau. Belangrijk voor het dashboard ‘Doorvoer van goedkeuringsbevoegdheden’. Waar vind je dit? Statuswijziging die aangeeft dat de betaling is geautoriseerd of klaar is om te boeken. Vastleggen Vergelijk het statusveld voor en na Gebeurtenistype inferred
	Betaling ingepland	Dit gebeurt wanneer een betaling is goedgekeurd, maar pas op een toekomstige datum van kracht mag worden. Het systeem zet de transactie in de wachtrij tot het verwerkingsvenster opengaat.
Waarom dit belangrijk is Verklaart wachttijd in het proces. Maakt onderscheid tussen vertraging door een bottleneck en bewust wachten tot de vervaldatum. Waar vind je dit? Vergelijking van ‘Invoerdatum’ en ‘Ingangsdatum’. Als de ingangsdatum in de toekomst ligt, is deze status actief. Vastleggen Afgeleid door veld X met veld Y te vergelijken Gebeurtenistype calculated
	Betalingsfout opgelost	Geeft aan dat een transactie met een fout is gecorrigeerd. Dit wordt afgeleid wanneer de status verandert van een foutstatus naar een verwerkingsstatus of geldige status.
Waarom dit belangrijk is Nodig om de ‘Gemiddelde tijd om betalingsfouten op te lossen’ te berekenen. Hiermee meet je hoe efficiënt het bedrijfsvoeringsteam fouten afhandelt. Waar vind je dit? Af te leiden wanneer de transactiestatus verandert van een foutcode naar een normale verwerkingscode. Vastleggen Vergelijk het statusveld voor en na Gebeurtenistype inferred
	Betalingsfout vastgesteld	Legt vast wanneer een transactie de status mislukt krijgt of een uitzonderingscode ontvangt. Dit gebeurt wanneer validatieregels niet worden gehaald of externe controles een negatieve reactie geven.
Waarom dit belangrijk is Belangrijk voor het dashboard ‘Validatiefouten en herstelwerk volgen’. Veel fouten wijzen op problemen met de datakwaliteit eerder in het proces. Waar vind je dit? Het statusveld van de transactie verandert in een uitzonderingscode, zoals ‘Ongeldig’, ‘Geblokkeerd’ of ‘Fout’. Vastleggen Vastgelegd wanneer de status verandert in Fout Gebeurtenistype explicit
	Betalingsmelding verzonden	Het systeem verstuurt een bericht, bijvoorbeeld per e-mail of sms, naar de betaler of ontvanger om de transactie te bevestigen. Zo weten klanten wat er met hun betaling gebeurt.
Waarom dit belangrijk is Ondersteunt ‘Snelheid en responsiviteit van meldingen’. Lange wachttijden na de afwikkeling kunnen het vertrouwen van klanten schaden. Waar vind je dit? Communicatielogs of tabellen met klantcontactgeschiedenis die aan de transactie-ID zijn gekoppeld. Vastleggen Geregistreerd wanneer e-mail of sms is verstuurd Gebeurtenistype explicit

Aanbevolen Optioneel

Extractiegidsen

Zo haal je data uit Fiserv

Stappen

1. Voorbereiding

Zorg dat je toegang hebt tot het ontwikkelaarsportaal van Fiserv Commerce Hub. Genereer een API Key en API Secret, soms Client ID en Client Secret genoemd, met rechten voor de Transaction Inquiry- of Search-API. Controleer of je IP-adres op de toelatingslijst van Fiserv staat als IP-beperkingen zijn ingeschakeld.

2. Omgeving instellen

Installeer Python 3.8 of hoger op de server of computer waarop je de data ophaalt. Je hebt de bibliotheken requests en pandas nodig. Installeer ze met pip: pip install requests pandas. Maak een werkmap voor het script en de uitvoerbestanden.

3. Script instellen

Download het meegeleverde Python-script naar je werkmap. Open het script en pas het configuratiegedeelte bovenaan aan. Vul je eigen API_KEY, API_SECRET en BASE_URL in. Gebruik de sandbox-URL om te testen en de productie-URL voor de definitieve uitvoering. Pas START_DATE en END_DATE aan voor de gewenste periode voor process mining.

4. Authenticatie instellen

Het script bevat een hulpprogrammaklasse voor de specifieke authenticatie van Fiserv. Daarbij wordt meestal een HMAC-handtekening gemaakt met je API Secret, de timestamp en de inhoud van het verzoek. Pas de logica voor het genereren van de handtekening niet aan, tenzij jouw Fiserv-implementatie een andere standaard gebruikt, zoals OAuth2-bearertokens.

5. De verwerkingslogica begrijpen

Het script vraagt transacties op via de API. De API geeft meestal een momentopname van het transactieobject terug met verschillende timestamps, zoals de indienings-, autorisatie- en afwikkelingstijd. Het script verwerkt dit JSON-object en zet het om naar meerdere rijen (gebeurtenissen) voor het event log. Eén JSON-record met een indieningstimestamp en een afwikkelingstimestamp levert bijvoorbeeld minstens twee afzonderlijke rijen in het CSV-bestand op.

6. Paginering verwerken

Het script gebruikt een lus om de paginering af te handelen. Fiserv-API’s beperken het aantal records per antwoord, vaak tot 50 of 100. Het script vraagt automatisch de volgende pagina op totdat alle transacties binnen het datumbereik zijn opgehaald. Zorg voor een stabiele internetverbinding. Bij grote datasets kan dit even duren.

7. Uitvoeren

Voer het script uit via de opdrachtregel: python fiserv_extraction.py. De console toont de voortgang, waaronder het aantal verwerkte pagina’s en opgehaalde transacties. Let op HTTP 401-fouten (Unauthorized) en 429-fouten (Rate Limit).

8. Uitvoer controleren

Controleer na afloop of de map het bestand fiserv_event_log.csv bevat. Kijk of de kolom ActivityName een combinatie van de 13 vereiste activiteiten bevat en of het veld EventTimestamp de juiste notatie gebruikt.

9. Nabewerking (optioneel)

Als je de tijdzone wilt aanpassen, bijvoorbeeld UTC omzetten naar lokale tijd, kun je het pandas-transformatiegedeelte in het script wijzigen. Je kunt dit ook na het uploaden in ProcessMind doen.

10. Uploaden naar ProcessMind

Importeer het CSV-bestand in ProcessMind. Koppel PaymentTransactionId aan Case ID, ActivityName aan Activiteit en EventTimestamp aan Timestamp. Stel numerieke kolommen zoals PaymentAmount in als attributen.

Configuratie

API-inloggegevens: Je hebt een API Key en Secret/Shared Secret nodig. Controleer of deze leesrechten hebben voor de Transaction Reporting-eindpunten.
Basis-URL: Gebruik https://api.commerce.fiserv.com voor productie of de specifieke cert-/sandbox-URL die je tijdens de onboarding hebt gekregen.
Datumbereik: Vanwege de omvang van API-antwoorden wordt een extractieperiode van 30 tot 90 dagen aanbevolen. Voer historische data in maandelijkse delen in.
Paginagrootte: Ingesteld op 100 records per verzoek om het geheugengebruik en netwerkverkeer in balans te houden.
Tijdzone: De API geeft timestamps in UTC terug. Het script behoudt deze standaard voor consistente gegevens tussen regio’s.
Opnieuw proberen: Er is een eenvoudige herhaalpoging ingebouwd voor tijdelijke netwerkproblemen (HTTP 500/502/503).

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

Klaar om te beginnen?

Verbeter je financiële workflows met deze template in je Fiserv-omgeving. Met deze aanpak beschik je over de juiste data om je cashflow en compliance in de bedrijfsvoering te verbeteren.

Terug naar de verbetergids Template downloaden

Optimaliseer de betalingsverwerking en bereik vandaag 98% STP

Voorkom vertragingen bij de afstemming en krijg grip op Fiserv-workflows.

Start je gratis proefperiode

Geen creditcard nodig. Binnen enkele minuten ingesteld.

Datatemplate voor betalingsverwerking

Datatemplate voor betalingsverwerking

Attributen voor betalingsverwerking

Activiteiten voor betalingsverwerking

Extractiegidsen

Python-script voor de Fiserv Commerce Hub API

Stappen

1. Voorbereiding

2. Omgeving instellen

3. Script instellen

4. Authenticatie instellen

5. De verwerkingslogica begrijpen

6. Paginering verwerken

7. Uitvoeren

8. Uitvoer controleren

9. Nabewerking (optioneel)

10. Uploaden naar ProcessMind

Configuratie

a Voorbeeldquery python

Klaar om te beginnen?

Optimaliseer de betalingsverwerking en bereik vandaag 98% STP

We gaan zorgvuldig om met je privacy