> Continuous Process Improvement > Payments Processing > FIS Global > Data Template

Your Payments Processing Data Template

FIS Global

Payments Processing Attributes (20) Payments Processing Activities (13) Extraction Guides (1)

Your Payments Processing Data Template

This template provides a comprehensive guide to the essential data attributes and process activities needed for effective payments processing analysis. It also includes practical guidance on how to extract this critical information from your systems. Use this resource to ensure you capture all necessary data for a robust process mining initiative.

Recommended attributes to collect
Key activities to track
Extraction guidance

New to event logs? Learn how to create a process mining event log.

Download Template

Payments Processing Attributes

These are the recommended data fields to include in your event log for comprehensive payments processing analysis.

3 Required 7 Recommended 10 Optional

	Name	Description
	Activity Name ActivityName	The name of the specific process step or event that occurred.
Description This field records the specific action taken at a given point in time, such as 'Payment Request Created' or 'Payment Settled'. It defines the nodes in the process map and determines the structure of the process flow. Analysts use this attribute to understand the sequence of operations. It is critical for identifying deviations from the happy path, spotting skipped steps, or detecting redundant activities like multiple approval loops. Why it matters It defines the 'what' of the process, enabling the visualization of process maps and variant analysis. Where to get Consult FIS Global documentation Examples Payment Request CreatedPayment Details ValidatedPayment ApprovedPayment Settled
	Event Timestamp EventTimestamp	The specific date and time when the activity occurred.
Description This attribute provides the temporal context for every event in the payment process. It records the exact moment an action was logged by the system, allowing for the chronological ordering of activities. In analysis, this is used to calculate durations between steps, total cycle times, and throughput rates. It allows for the identification of bottlenecks by highlighting delays between specific process stages. Why it matters Time-based analysis is impossible without this field; it drives all performance and efficiency KPIs. Where to get Consult FIS Global documentation Examples 2023-10-12T08:30:15Z2023-10-12T09:45:00Z2023-10-13T14:20:10Z
	Payment Transaction ID PaymentTransactionId	The unique identifier for the specific payment instruction or transaction.
Description This attribute serves as the central key for linking all events within a single payment lifecycle. It allows analysts to trace the payment from the initial request through validation, approval, and final settlement or reconciliation. In analysis, this ID is essential for grouping discrete events into process instances. It enables the visualization of the end-to-end flow and is the basis for all case-level metrics, such as cycle time and rework loops. Why it matters It is the fundamental connector for process mining, allowing disparate activities to be reconstructed into a coherent journey. Where to get Consult FIS Global documentation Examples TRX-2023-899102PAY-US-99281ACH-7721-X99WIRE-2210-001
	Actual Settlement Date ActualSettlementDate	The date when the payment was actually finalized and settled.
Description This attribute captures the effective date when funds were transferred or the transaction was considered complete. It differs from the processing timestamp as it reflects the value date. In analysis, this is used alongside the Due Date to calculate 'On-Time Payment Rate'. It is also the trigger for the reconciliation phase, making it vital for analyzing the 'Payment Reconciliation Cycle Time'. Why it matters It represents the financial conclusion of the payment and is key for cash flow analysis. Where to get Consult FIS Global documentation Examples 2023-11-022023-11-14
	Business Unit BusinessUnit	The internal division or department originating the payment.
Description This attribute maps the payment to a specific organizational unit, such as 'Retail Banking', 'Commercial Lending', or 'Treasury'. It is used to aggregate KPIs like 'Payment Throughput' and 'Average Payment Cycle Time' by department. This helps management compare performance across different divisions and allocate resources effectively. Why it matters It enables internal benchmarking and accountability for process performance. Where to get Consult FIS Global documentation Examples TreasuryAccounts PayableRetail OperationsWealth Management
	Currency Code CurrencyCode	The 3-letter ISO code denoting the currency of the payment.
Description This attribute specifies the currency for the Payment Amount (e.g., USD, EUR, GBP). It is essential for normalizing financial data when analyzing global payment streams. In analysis, this field allows for the segmentation of process performance by currency, which often correlates with different clearing systems and regulations. It helps explain variations in settlement times for cross-border versus domestic payments. Why it matters Critical for multi-currency environments to accurately interpret financial volumes. Where to get Consult FIS Global documentation Examples USDEURGBPJPY
	Payment Amount PaymentAmount	The monetary value of the payment transaction.
Description This attribute represents the financial value associated with the payment request. It is the primary metric for analyzing financial throughput and risk. Analysts use this field to segment processes by high vs. low value payments, which often have different approval paths. It supports the 'Payment Throughput' dashboard and helps identify if high-value payments suffer from longer cycle times due to stricter scrutiny. Why it matters It adds the financial dimension to process mining, allowing for value-based prioritization. Where to get Consult FIS Global documentation Examples 1500.00250.501000000.0045.99
	Payment Due Date PaymentDueDate	The date by which the payment is expected to be settled.
Description This attribute records the deadline for the payment as requested by the initiator or defined by invoice terms. It serves as the target benchmark for on-time performance. This field is critical for the 'Payment Due Date Adherence' dashboard. By comparing this date to the actual 'Payment Settled' date, analysts can flag late payments, calculate potential penalties, and assess compliance with vendor agreements. Why it matters It provides the baseline for measuring service level adherence and timeliness. Where to get Consult FIS Global documentation Examples 2023-11-012023-11-15
	Payment Type PaymentType	The classification of the payment method or instrument.
Description This attribute categorizes the payment into types such as Wire, ACH, SEPA, Real-Time Payment (RTP), or Check. Different payment types follow distinctly different processing rules and SLAs. Analysts use this field to compare 'Payment Reconciliation Cycle Time' across different rails. It helps explain why some payments settle instantly while others take days, ensuring that performance is measured against the correct benchmark. Why it matters It is the primary dimension for segmenting process flows, as each type has unique routing and timing characteristics. Where to get Consult FIS Global documentation Examples Wire TransferACH CreditSEPA InstantCheck
	Processing User ProcessingUser	The identifier or name of the user or system agent performing the activity.
Description This attribute captures who or what executed the process step. It can distinguish between human operators (e.g., 'J.Smith') and automated system accounts (e.g., 'SYSTEM_BATCH'). This data is used to analyze resource utilization, identify manual bottlenecks, and audit segregation of duties. It helps in calculating the 'Processing User Utilization Rate' and distinguishing between manual and automated tasks. Why it matters Essential for resource analysis, automation rates, and compliance auditing. Where to get Consult FIS Global documentation Examples jsmithSYSTEM_AUTOBOTmdoe_approverAPI_GATEWAY
	Approval Authority ApprovalAuthority	The role, group, or individual responsible for authorizing the payment.
Description This attribute indicates which authority level or specific user group is required to approve the payment, often based on the amount threshold. It helps trace the routing of the approval workflow. Analysts use this to support the 'Payment Authorization Bottlenecks' dashboard. It allows for the breakdown of approval times by authority level to see if specific management layers are causing delays. Why it matters It enables organizational analysis of the approval hierarchy and bottleneck detection. Where to get Consult FIS Global documentation Examples Level 1 ManagerCFOCompliance TeamAuto-Approval System
	Beneficiary Country BeneficiaryCountry	The country code of the payment recipient.
Description This attribute identifies the destination country for the funds. It is used to distinguish between domestic and international payments. This context is crucial for 'Payment Compliance Monitoring' and routing analysis. International payments often involve different intermediaries, compliance checks, and longer cycle times, so analyzing performance by country helps isolate these variables. Why it matters It is a key dimension for geographical analysis and compliance risk assessment. Where to get Consult FIS Global documentation Examples USDECNGB
	Cycle Time (Days) CycleTimeDays	The duration in days from request creation to settlement.
Description This calculated attribute measures the end-to-end time of the process. It is computed as the difference between the timestamp of 'Payment Settled' and 'Payment Request Created'. It is the primary metric for the 'Average Payment Cycle Time' KPI. Having this pre-calculated facilitates performance distribution analysis (e.g., histograms) to spot outliers and trends. Why it matters It quantifies the overall speed of the process. Where to get Derived from EventTimestamp Examples 1.50.25.0
	Is Late Payment IsLatePayment	A flag indicating if the payment settled after the due date.
Description This is a calculated boolean attribute. It returns true if the 'Payment Settled' date is later than the 'Payment Due Date'. This attribute is the direct driver for the 'On-Time Payment Rate' KPI. It simplifies dashboarding by allowing users to quickly filter for problematic cases without complex date logic in the visualization layer. Why it matters It simplifies exception reporting and compliance analysis. Where to get Derived from PaymentDueDate and ActualSettlementDate Examples truefalse
	Is Manual Intervention IsManualIntervention	A flag indicating if the activity involved manual work.
Description This boolean attribute flags activities or cases that required human input, such as 'Payment Error Resolved' or manual approvals, as opposed to straight-through processing (STP). This is essential for the 'Manual Payment Intervention Rate' dashboard. It helps quantify the percentage of payments that are not fully automated, highlighting opportunities for digital transformation. Why it matters It distinguishes between automated throughput and manual effort, guiding automation ROI calculations. Where to get Derived from ActivityName or ProcessingUser Examples truefalse
	Last Data Update LastDataUpdate	The timestamp when the record was last extracted or refreshed.
Description This attribute indicates the freshness of the data used in the analysis. It helps users understand if they are looking at real-time data or a snapshot from a previous period. In dashboarding, this field is often used to display a 'Data current as of' label. It ensures that decisions are made based on the most relevant information available and helps managing incremental data loads. Why it matters It establishes data currency and builds trust in the timeliness of the reporting. Where to get ETL process metadata Examples 2023-10-14T00:00:00Z2023-10-15T06:00:00Z
	Payment Channel PaymentChannel	The channel through which the payment request was initiated.
Description This attribute describes the origin of the payment instruction, such as Online Banking, Mobile App, API, or Branch. It helps understand the input vector of the transaction. Analysts use this to compare processing efficiency across different channels. For example, it helps determine if payments initiated via API have lower error rates compared to those manually entered at a branch. Why it matters It assists in channel optimization and understanding customer behavior. Where to get Consult FIS Global documentation Examples Online BankingMobile AppCorporate GatewayBranch Teller
	Sender Account SenderAccount	The account number from which funds are debited.
Description This attribute identifies the source account for the transaction. It provides granularity when analyzing payments from specific internal accounts. In analysis, it helps identify if specific funding accounts are prone to errors (e.g., insufficient funds) or delays. It supports reconciliation by allowing matching of ledger entries to process activities. Why it matters It is fundamental for financial reconciliation and account-level problem solving. Where to get Consult FIS Global documentation Examples 123456789987654321ACC-TREASURY-01
	Source System SourceSystem	The name of the system where the event data originated.
Description This attribute identifies the specific software component or database from which the record was extracted, such as the core banking engine, the payment gateway, or the sanctions screening tool. It is vital for data lineage and validation. When analyzing end-to-end flows that span multiple platforms, this field helps distinguish where specific activities took place and aids in troubleshooting data quality issues. Why it matters It ensures traceability and context, especially in complex environments with multiple integrated payment engines. Where to get Consult FIS Global documentation Examples FIS OPFTraxPaymentHub_01SanctionsScreeningDB
	Validation Error Code ValidationErrorCode	The code or reason indicating why a payment failed validation.
Description This attribute is populated when a payment enters the 'Payment Error Identified' activity. It contains specific details about the failure, such as 'Invalid IBAN', 'Insufficient Funds', or 'Missing Beneficiary Address'. This field drives the 'Payment Data Validation Error Rates' dashboard. Grouping by this attribute reveals the most common causes of rework, enabling targeted fixes in upstream data entry or system configuration. Why it matters It identifies the root causes of process friction and rework loops. Where to get Consult FIS Global documentation Examples ERR-001: Invalid AccountERR-055: Sanctions HitERR-009: Duplicate Transaction

Required Recommended Optional

Payments Processing Activities

These are the key process steps and milestones to capture in your event log for accurate process discovery and optimization.

6 Recommended 7 Optional

	Activity	Description
	Payment Approved	A key milestone where an authorized user approves the payment, allowing it to proceed to the next stage. This is almost always an explicit event logged with the approver's ID and a timestamp when they take action in the system.
Why it matters This is a critical checkpoint for measuring approval cycle times and ensuring compliance with financial controls. Delays at this stage can significantly impact on-time payment performance. Where to get Captured in an approval log table or as an explicit event in the main transaction history. The event log would link the Payment Transaction ID, the approver's user ID, and an approval timestamp. Capture Logged when a user with approval rights takes the 'approve' action on a payment. Event type explicit
	Payment Authorized	Represents a final authorization step, often required for high-value payments or by a different authority after initial approval. This action is captured as an explicit event when a user with authorization credentials confirms the payment.
Why it matters This activity is key to the 'Payment Authorization Bottlenecks' dashboard. Separating it from 'Payment Approved' helps pinpoint delays in multi-level sign-off processes. Where to get Recorded in an audit or transaction log. This event is triggered by a user with specific authorization permissions acting on the payment, generating a record with their ID and a timestamp. Capture An explicit log entry is created when a user performs the final authorization action. Event type explicit
	Payment Instruction Sent	This activity marks the point when the FIS system sends the finalized payment instruction to the relevant payment network, such as ACH, Fedwire, or SWIFT. This is a critical system-generated event.
Why it matters This is a major milestone indicating the payment has left the internal processing environment. It's crucial for analyzing routing efficiency and the time taken for external processing. Where to get Logged in a transaction or messaging log that tracks communications with external payment networks. Look for a record indicating a successful outbound message transmission with a timestamp. Capture System-generated event when the payment message is dispatched to the clearing network. Event type explicit
	Payment Reconciled	This is the final accounting activity where the payment transaction is matched against a bank statement or internal ledger entry. This can be an automated batch process or a manual user action.
Why it matters This activity marks the absolute end of the payment lifecycle. Analyzing the 'Payment Reconciliation Cycle Time' is crucial for understanding the efficiency of financial closing processes. Where to get Often inferred from a 'reconciliation_date' field being populated or a final status change to 'Reconciled' in a financial or accounting module linked to the payment system. Capture Identified by the population of a reconciliation date or a status change to 'Reconciled'. Event type inferred
	Payment Request Created	This is the first event in the payment lifecycle, representing the moment a new payment transaction is initiated in the FIS system. This is typically captured as an explicit entry in a transaction log table when a user or an automated system submits a new payment request.
Why it matters This activity serves as the definitive start of the process. It is essential for measuring the end-to-end payment cycle time and analyzing overall payment throughput and volume. Where to get Recorded in a core transaction table, identified by the creation timestamp associated with the Payment Transaction ID. Look for tables like 'Payment_Transactions' or 'Payment_Requests' for a 'creation_date' or 'entry_date' field. Capture Event logged upon creation of a new payment transaction record. Event type explicit
	Payment Settled	This activity marks the completion of the funds transfer, where the transaction is considered financially settled. This is typically recorded when a final settlement confirmation is received from the payment network or clearing house.
Why it matters This is the primary endpoint for measuring payment cycle time and on-time payment rates. It signifies the successful completion of the core payment execution process. Where to get Inferred from a final status change on the payment record to 'Settled', 'Completed', or 'Posted'. This status change is driven by batch settlement files or real-time messages from the clearing system. Capture A status change on the payment transaction to 'Settled' or equivalent. Event type inferred
	Late Payment Identified	A derivative event indicating that the payment was settled after its specified due date. This activity is not explicitly recorded but is calculated by comparing two date fields.
Why it matters This calculated activity directly supports the 'On-Time Payment Rate' KPI and the 'Payment Due Date Adherence' dashboard. It helps quantify the impact of process delays on vendor relationships and potential late fees. Where to get This is not directly extracted. It is calculated during data transformation by comparing the 'Settlement Date' timestamp with the 'Payment Due Date' field. If the settlement date is after the due date, this event is generated. Capture Calculated if 'Settlement Date' > 'Payment Due Date'. Event type calculated
	Payment Confirmed	Represents the receipt of an acknowledgement from the payment network or beneficiary bank that the payment has been received. This event is triggered by an incoming system message or status update.
Why it matters Confirmation provides certainty that the payment has reached its destination. The time between 'Instruction Sent' and 'Confirmed' measures external network latency and processing time. Where to get Generated from parsing incoming confirmation messages from payment networks. The system updates the payment status and records a confirmation timestamp. Capture Inbound message from a clearing network updates the payment status to 'Confirmed'. Event type explicit
	Payment Details Validated	This activity signifies that the payment data has passed initial automated validation checks for format, completeness, and correctness. It is often inferred from a status change on the payment record, for example, from 'New' to 'Validated' or 'Pending Approval'.
Why it matters Tracking this activity helps identify the frequency and location of data entry errors. It is a prerequisite for analyzing the Payment Data Validation Error Rate KPI and understanding sources of rework. Where to get Inferred from a status or state change field in the payment transaction table. A change from an initial state to a 'validated' state, along with a corresponding timestamp, marks this event. Capture Identified by a change in the payment status field to 'Validated' or a similar value. Event type inferred
	Payment Error Identified	Indicates that an error was detected at some point in the process after initial validation, such as a rejection from the receiving bank or an internal compliance flag. This is often an explicit event logged when an exception is raised.
Why it matters This activity is the entry point for all rework and exception handling loops. It is essential for calculating the Manual Intervention Rate and Payment Error Resolution Time KPIs. Where to get Recorded in an exception handling module or transaction log. It can be triggered automatically by a system rule or manually by a user flagging an issue, creating a log with an error code and timestamp. Capture An exception or error code is logged against the payment transaction. Event type explicit
	Payment Error Resolved	Marks the resolution of a previously identified payment error, allowing the payment to be re-processed or canceled. This is an explicit action taken by a user to clear the exception status.
Why it matters This activity closes the exception loop. The duration between 'Error Identified' and this event is a key measure of operational efficiency in handling exceptions. Where to get Logged when a user clears an error flag or moves the transaction out of an exception queue. This action is captured in an audit trail or transaction history log with a timestamp. Capture A user action clears the error state, which is recorded in an audit log. Event type explicit
	Payment Rejected	This activity occurs when an approver denies a payment request, typically requiring it to be corrected and resubmitted or canceled entirely. This is an explicit user action that is logged for audit purposes.
Why it matters Tracking rejections helps identify common reasons for payment failures, process deviations, and rework loops. It highlights issues with initial data quality or compliance. Where to get Logged as an explicit event in an approval or transaction history table when an approver selects the 'reject' option. The record usually includes a timestamp, the user ID, and often a reason code. Capture Event logged when a user executes the 'reject' action for a payment. Event type explicit
	Payment Sent For Approval	Represents the point where a validated payment is submitted into the approval workflow. This is typically captured by a status change indicating the payment is now awaiting action from an approver.
Why it matters This activity marks the beginning of the approval sub-process. Analyzing the time between this and 'Payment Approved' is crucial for understanding approval bottlenecks. Where to get Inferred from a change in the payment's status field to 'Pending Approval', 'Submitted for Approval', or a similar state within a workflow or transaction status log. Capture A status change on the payment transaction from 'Validated' to 'Pending Approval'. Event type inferred

Recommended Optional

Extraction Guides

How to get your data from FIS Global

Steps

Prerequisites and Setup: Ensure you have Python installed (version 3.8 or higher) and the necessary libraries (requests, pandas). You will need valid API credentials for the FIS Payment Hub, specifically a Client ID, Client Secret, and the Base API URL.
Configuration: Open the provided Python script. Update the configuration section at the top with your specific API Base URL, Client ID, and Client Secret. Set the START_DATE and END_DATE variables to define the extraction window.
Authentication: The script uses a helper function to authenticate against the FIS OAuth2 endpoint. It retrieves a Bearer token which is then included in the headers of all subsequent API requests.
Fetching Transactions: The script executes a GET request to the /payments endpoint. It implements pagination logic to loop through results until all transactions within the date range are retrieved. It filters for relevant payment types based on your scope.
Retrieving Event History: For every payment transaction retrieved, the script makes a secondary call to the /payments/{id}/history or /audit endpoint to fetch the lifecycle events. This nested loop ensures the granular history is captured.
Mapping Activities: The script contains a mapping dictionary (transformation logic) that translates FIS internal status codes (e.g., STAT_INIT, STAT_VAL, STAT_ACK) into the standard activity names required, such as Payment Request Created and Payment Confirmed.
Handling Derivative Events: The script specifically checks the ActualSettlementDate against the PaymentDueDate. If the settlement date is after the due date, it synthetically generates a new event row titled Late Payment Identified and appends it to the event log.
Attribute Extraction: During the iteration, the script extracts key attributes like Payment Amount, Currency, and Business Unit. These are repeated for every event associated with a specific Transaction ID to ensure a rich dataset.
Validation and Error Handling: The script includes basic error handling for failed API calls (e.g., 429 Rate Limit or 500 Server Error) and prints progress to the console. It skips incomplete records where critical timestamps are missing.
Data Flattening: The nested JSON structure from the API is flattened into a tabular format using the Pandas library. Each row represents a single activity occurrence.
Export: Finally, the script exports the processed DataFrame to a CSV file named fis_payment_event_log.csv. This file is formatted with standard headers ready for ProcessMind ingestion.
Final Review: Open the generated CSV file. Check that date columns are in ISO 8601 format (YYYY-MM-DDTHH:MM:SS) and that the activity column contains the human-readable names mapped in the script.

Configuration

API_BASE_URL: The root URL for your organization's FIS Payment Hub instance (e.g., https://api.fisglobal.com/paymenthub/v1).
CLIENT_ID / CLIENT_SECRET: OAuth2 credentials used to obtain the access token. These must have 'Read' permissions on Payment and Audit scopes.
START_DATE / END_DATE: The extraction window. It is recommended to extract data in 30-day chunks if volume is high (over 100k payments per month).
PAGE_SIZE: Set to 100 or 500 depending on API performance limitations to optimize throughput.
TIMEOUT: Connection timeout in seconds (default 30) to prevent the script from hanging on slow network responses.
RETRY_ATTEMPTS: Number of times the script should retry a failed request before skipping a record.

a Sample Query python

import requests
import pandas as pd
import json
from datetime import datetime, timedelta
import time

class=class="hl-string">"hl-comment"># === CONFIGURATION ===
API_BASE_URL = class="hl-string">"https://[Your FIS API Endpoint]/v1"
CLIENT_ID = class="hl-string">"[Your Client ID]"
CLIENT_SECRET = class="hl-string">"[Your Client Secret]"
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-01-31"
OUTPUT_FILE = class="hl-string">"fis_payment_event_log.csv"

class=class="hl-string">"hl-comment"># === MAPPINGS ===
class=class="hl-string">"hl-comment"># Maps FIS internal status codes to ProcessMind Activity Names
STATUS_MAP = {
    class="hl-string">"INITIATED": class="hl-string">"Payment Request Created",
    class="hl-string">"VALIDATED": class="hl-string">"Payment Details Validated",
    class="hl-string">"PENDING_AUTH": class="hl-string">"Payment Sent For Approval",
    class="hl-string">"APPROVED": class="hl-string">"Payment Approved",
    class="hl-string">"REJECTED": class="hl-string">"Payment Rejected",
    class="hl-string">"AUTHORIZED": class="hl-string">"Payment Authorized",
    class="hl-string">"SENT_TO_NETWORK": class="hl-string">"Payment Instruction Sent",
    class="hl-string">"ACKNOWLEDGED": class="hl-string">"Payment Confirmed",
    class="hl-string">"SETTLED": class="hl-string">"Payment Settled",
    class="hl-string">"EXCEPTION": class="hl-string">"Payment Error Identified",
    class="hl-string">"EXCEPTION_CLEARED": class="hl-string">"Payment Error Resolved",
    class="hl-string">"RECONCILED": class="hl-string">"Payment Reconciled"
}

def get_access_token():
    url = fclass="hl-string">"{API_BASE_URL}/oauth/token"
    payload = {
        class="hl-string">"grant_type": class="hl-string">"client_credentials",
        class="hl-string">"client_id": CLIENT_ID,
        class="hl-string">"client_secret": CLIENT_SECRET
    }
    try:
        response = requests.post(url, data=payload)
        response.raise_for_status()
        return response.json()[class="hl-string">"access_token"]
    except Exception as e:
        print(fclass="hl-string">"Authentication failed: {e}")
        exit(1)

def get_payments(token, start, end):
    headers = {class="hl-string">"Authorization": fclass="hl-string">"Bearer {token}"}
    payments = []
    page = 1
    has_more = True
    
    while has_more:
        class=class="hl-string">"hl-comment"># Placeholder endpoint for searching payments
        url = fclass="hl-string">"{API_BASE_URL}/payments?startDate={start}&endDate={end}&page={page}&pageSize=100"
        try:
            resp = requests.get(url, headers=headers)
            resp.raise_for_status()
            data = resp.json()
            
            batch = data.get(class="hl-string">"items", [])
            payments.extend(batch)
            
            if len(batch) < 100:
                has_more = False
            else:
                page += 1
        except Exception as e:
            print(fclass="hl-string">"Error fetching payments page {page}: {e}")
            has_more = False
            
    return payments

def get_payment_history(token, payment_id):
    headers = {class="hl-string">"Authorization": fclass="hl-string">"Bearer {token}"}
    try:
        class=class="hl-string">"hl-comment"># Placeholder endpoint for audit history
        url = fclass="hl-string">"{API_BASE_URL}/payments/{payment_id}/audit"
        resp = requests.get(url, headers=headers)
        resp.raise_for_status()
        return resp.json().get(class="hl-string">"events", [])
    except Exception as e:
        print(fclass="hl-string">"Error fetching history for {payment_id}: {e}")
        return []

def process_data():
    print(class="hl-string">"Authenticating...")
    token = get_access_token()
    
    print(fclass="hl-string">"Fetching payments from {START_DATE} to {END_DATE}...")
    raw_payments = get_payments(token, START_DATE, END_DATE)
    
    event_log = []
    
    print(fclass="hl-string">"Processing {len(raw_payments)} transactions...")
    
    for p in raw_payments:
        p_id = p.get(class="hl-string">"paymentId")
        amount = p.get(class="hl-string">"amount")
        currency = p.get(class="hl-string">"currency")
        p_type = p.get(class="hl-string">"paymentType")
        due_date_str = p.get(class="hl-string">"dueDate")
        unit = p.get(class="hl-string">"businessUnit")
        
        class=class="hl-string">"hl-comment"># Fetch history for this specific payment
        history = get_payment_history(token, p_id)
        
        class=class="hl-string">"hl-comment"># Variables for derivative logic
        settlement_date = None
        due_date = None
        
        if due_date_str:
            try:
                due_date = datetime.fromisoformat(due_date_str.replace(class="hl-string">"Z", class="hl-string">"+00:00"))
            except ValueError:
                pass

        class=class="hl-string">"hl-comment"># Process explicit API events
        for h in history:
            raw_status = h.get(class="hl-string">"status")
            timestamp_str = h.get(class="hl-string">"timestamp")
            user = h.get(class="hl-string">"userId")
            
            class=class="hl-string">"hl-comment"># Map to standard Activity Name
            activity_name = STATUS_MAP.get(raw_status, raw_status)
            
            class=class="hl-string">"hl-comment"># Only include relevant activities
            if activity_name:
                event_entry = {
                    class="hl-string">"PaymentTransactionId": p_id,
                    class="hl-string">"ActivityName": activity_name,
                    class="hl-string">"EventTimestamp": timestamp_str,
                    class="hl-string">"ProcessingUser": user,
                    class="hl-string">"PaymentAmount": amount,
                    class="hl-string">"CurrencyCode": currency,
                    class="hl-string">"PaymentType": p_type,
                    class="hl-string">"PaymentDueDate": due_date_str,
                    class="hl-string">"BusinessUnit": unit,
                    class="hl-string">"ActualSettlementDate": None class=class="hl-string">"hl-comment"># To be filled if known
                }
                
                class=class="hl-string">"hl-comment"># Capture settlement date for logic
                if activity_name == class="hl-string">"Payment Settled":
                    event_entry[class="hl-string">"ActualSettlementDate"] = timestamp_str
                    try:
                        settlement_date = datetime.fromisoformat(timestamp_str.replace(class="hl-string">"Z", class="hl-string">"+00:00"))
                    except ValueError:
                        pass
                        
                event_log.append(event_entry)

        class=class="hl-string">"hl-comment"># Logic for Derivative Activity: Late Payment Identified
        class=class="hl-string">"hl-comment"># Rules: If settled and due date exists, and settled > due date
        if settlement_date and due_date:
            if settlement_date > due_date:
                event_log.append({
                    class="hl-string">"PaymentTransactionId": p_id,
                    class="hl-string">"ActivityName": class="hl-string">"Late Payment Identified",
                    class="hl-string">"EventTimestamp": settlement_date.isoformat(),
                    class="hl-string">"ProcessingUser": class="hl-string">"System Calculation",
                    class="hl-string">"PaymentAmount": amount,
                    class="hl-string">"CurrencyCode": currency,
                    class="hl-string">"PaymentType": p_type,
                    class="hl-string">"PaymentDueDate": due_date_str,
                    class="hl-string">"ActualSettlementDate": settlement_date.isoformat(),
                    class="hl-string">"BusinessUnit": unit
                })

    class=class="hl-string">"hl-comment"># Export to CSV
    df = pd.DataFrame(event_log)
    class=class="hl-string">"hl-comment"># Ensure timestamps are consistent
    if not df.empty:
        df[class="hl-string">'EventTimestamp'] = pd.to_datetime(df[class="hl-string">'EventTimestamp']).dt.strftime(class="hl-string">'%Y-%m-%d %H:%M:%S')
        
    df.to_csv(OUTPUT_FILE, index=False)
    print(fclass="hl-string">"Extraction complete. Data saved to {OUTPUT_FILE}")

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

Your Payments Processing Data Template

Your Payments Processing Data Template

Payments Processing Attributes

Payments Processing Activities

Extraction Guides

Python Parsing of ISO 20022 XML Log Files

Steps

Configuration

a Sample Query python

Ready to Get Started?

Optimize Your FIS Global Payments Processing Today

Your Payments Processing Data Template

Your Payments Processing Data Template

Payments Processing Attributes

Payments Processing Activities

Extraction Guides

Python Parsing of ISO 20022 XML Log Files

Steps

Configuration

a Sample Query python

We value your privacy

Ready to Get Started?

Optimize Your FIS Global Payments Processing Today