When a card-fraud incident occurs at a Saudi payment firm or bank, the clock starts on two parallel obligations: contain the fraud and preserve transaction logs for investigation. The Saudi Central Bank's Counter-Fraud Framework Article 4.3 mandates that regulated entities preserve evidence for fraud investigation and regulatory reporting, yet many incident response teams collect only application logs—and discover weeks later that the transactional, network, and authentication records required for digital forensics have been overwritten or were never captured at all.
The consequence is not simply an incomplete investigation. Without the four evidence types that Article 4.3 requires, your digital forensics engagement cannot establish the fraud's entry point, scope, or timeline. Your SAMA incident report under Article 7.2 disclosure requirements will lack the factual foundation regulators expect. And if the incident escalates to litigation or law enforcement referral, gaps in the evidence chain undermine every conclusion.
This article lists the four evidence types the Counter-Fraud Framework requires for card-fraud investigation, shows the minimum retention window for each, and provides the collection sequence that prevents overwriting or gaps. The goal is straightforward: when your digital forensics engagement starts, the evidence is complete, preserved with chain of custody, and ready for analysis.
Why Application Logs Alone Are Not Sufficient
Most incident response teams begin evidence collection by exporting application logs from the payment switch, card management system, or fraud-detection platform. These logs are essential—they record transaction approvals, declines, and fraud alerts—but they capture only one dimension of the incident.
Card fraud, whether account takeover, card-not-present fraud, or point-of-sale compromise, involves multiple systems and network layers. To reconstruct the fraud timeline, determine root cause, and identify all affected cardholders, forensic investigators require four distinct evidence types:
1. Authorization logs — Transaction requests, approvals, declines, reversals, and settlement records from the payment switch, acquirer gateway, or issuer processor.
2. Network flow data — Packet captures, firewall logs, and connection metadata showing source IP addresses, destination endpoints, session duration, and data volumes.
3. Authentication events — Cardholder authentication attempts, step-up challenges, 3-D Secure outcomes, PIN verification results, and session tokens.
4. Cardholder session records — Web server logs, mobile application session data, API calls, and user-agent strings that link transactions to specific devices or browsers.
Each evidence type answers a different investigative question. Authorization logs show *what* happened. Network flow data shows *where* the fraud originated. Authentication events show *how* the attacker bypassed controls. Cardholder session records show *who*—or which compromised credential or device—was involved.
Collecting only application logs leaves the other three questions unanswered.
The Four Evidence Types and Minimum Retention Windows
SAMA Counter-Fraud Framework Article 4.3 does not prescribe specific log formats or storage technologies, but it does require that evidence be preserved in a manner that supports investigation and regulatory reporting. In practice, this means each evidence type must be collected before retention windows expire or storage limits trigger automatic deletion.
1. Authorization Logs
Authorization logs are the transactional record: every authorization request, response code, merchant identifier, cardholder account, transaction amount, currency, and timestamp. For card-fraud incidents, these logs establish the fraud's financial scope and identify affected accounts.
Minimum retention window: 90 days from transaction date, per SAMA payment system rules. Many switches and processors retain authorization logs for 12 months, but high-volume systems may archive or compress logs after 90 days, making forensic analysis slower or incomplete.
Collection priority: High. These logs are often the first to be requested by regulators and the foundation of your Article 7.2 incident report.
2. Network Flow Data
Network flow data includes firewall logs, intrusion detection system alerts, packet captures, and NetFlow or sFlow records. This evidence shows the network path of fraudulent transactions: originating IP addresses, geolocation anomalies, connections to known fraud infrastructure, and lateral movement within your network if the incident involved a compromise.
Minimum retention window: 30 to 90 days, depending on storage capacity and regulatory requirements. Packet captures, which provide the most granular detail, are often retained for only 7 to 14 days due to volume.
Collection priority: Critical in the first 48 hours. Network flow data is the most perishable evidence type. If your firewall or intrusion detection system rotates logs weekly, waiting even three days can result in permanent loss.
3. Authentication Events
Authentication logs record every cardholder login attempt, multi-factor authentication challenge, 3-D Secure transaction, PIN entry, biometric verification, and session token issuance. In account-takeover fraud, these logs show whether the attacker used stolen credentials, bypassed step-up authentication, or exploited a session hijacking vulnerability.
Minimum retention window: 90 days, aligned with transaction logs. Authentication systems, particularly those integrated with mobile applications or third-party identity providers, may retain detailed event logs for only 30 days.
Collection priority: High, especially if the fraud involved online or mobile channels. Authentication events are essential for determining whether the incident resulted from credential compromise, social engineering, or a technical control failure.
4. Cardholder Session Records
Session records link transactions to specific devices, browsers, or API clients. Web server logs capture IP addresses, user-agent strings, referrer headers, and session cookies. Mobile application logs record device identifiers, operating system versions, and API call sequences. These records help investigators distinguish legitimate cardholder activity from attacker sessions and identify patterns across multiple compromised accounts.
Minimum retention window: 90 days. Session records are often stored separately from authorization logs, in web server access logs or application performance monitoring platforms that may have shorter retention policies.
Collection priority: Medium to high. Session records become critical when the fraud involves multiple accounts or when you need to correlate online activity with card-present transactions.
The Collection Sequence That Prevents Overwriting and Gaps
Evidence preservation is not simply a matter of exporting logs. The sequence in which you collect evidence determines whether you capture a complete record or introduce gaps that undermine the investigation.
Step 1: Identify Retention Windows Immediately
Within the first hour of incident declaration, identify the retention window for each evidence type in your environment. Contact the administrators of your payment switch, firewall, authentication platform, and web servers. Ask two questions: What is the current retention policy? When will the oldest relevant logs be deleted or overwritten?
If any retention window is shorter than the suspected fraud period—for example, if the fraud may have started 45 days ago but your packet captures are retained for only 14 days—prioritize that evidence type in Step 2.
Step 2: Preserve Network Flow Data First
Network flow data is the most perishable evidence. Begin collection with firewall logs, intrusion detection alerts, and any available packet captures covering the suspected fraud period. Copy these logs to write-once storage or a forensic workstation with documented chain of custody.
Do not rely on automated log forwarding to a SIEM or log management platform. Verify that the raw logs are intact and have not been filtered, aggregated, or summarized in a way that removes forensic detail.
Step 3: Collect Authorization and Authentication Logs in Parallel
Once network flow data is secured, collect authorization logs and authentication events in parallel. These logs are larger in volume but typically have longer retention windows, giving you a margin of hours or days.
For authorization logs, export the complete transaction record for the suspected fraud period, including declines and reversals. Do not filter by transaction amount or merchant category at this stage; forensic analysis may reveal fraud patterns that are not immediately obvious.
For authentication logs, include all events related to the affected cardholder accounts, even if the authentication was successful. Investigators need to see both legitimate and fraudulent sessions to establish a baseline and identify anomalies.
Step 4: Collect Cardholder Session Records Last
Cardholder session records—web server logs, mobile application session data, API call logs—are collected last because they are typically the least perishable and the most voluminous. Focus on the time windows and IP address ranges identified in the network flow data to reduce collection scope.
If session records are stored in a cloud-based application performance monitoring platform or content delivery network, coordinate with the platform administrator to ensure logs are exported in a format that preserves timestamps, session identifiers, and user-agent strings.
Step 5: Document Chain of Custody for Every Evidence Type
For each evidence type, document who collected the evidence, when, from which system, and where it is now stored. Record file hashes (SHA-256) for every log file to prove integrity. This chain of custody documentation is required for regulatory reporting, and it is essential if the incident leads to law enforcement involvement or litigation.
How Digital Forensics Uses the Four Evidence Types
Once evidence is preserved, the digital forensics engagement can begin. Specialists help contain the incident, preserve evidence, investigate root cause and scope, and support regulatory reporting and recovery. The investigation follows a structured process: triage to scope urgency and immediate containment, preserve evidence with chain of custody, analyze to build a timeline and determine root cause and impact, and report findings and recommendations.
The four evidence types are analyzed together to answer the investigative questions:
- Authorization logs establish the fraud's financial impact, identify affected accounts, and show transaction patterns.
- Network flow data reveals the attacker's infrastructure, geolocation, and any lateral movement within your network.
- Authentication events determine whether the fraud involved credential compromise, session hijacking, or a control bypass.
- Cardholder session records link transactions to specific devices or sessions and help distinguish attacker activity from legitimate use.
The investigation produces an investigation report, incident timeline, indicators of compromise, and remediation recommendations. These deliverables support your SAMA Article 7.2 incident report, guide containment and eradication, and provide the factual foundation for any regulatory inquiry.
Preparing Before the Incident
Evidence preservation is faster and more complete when the collection process is defined before an incident occurs. A pre-agreed incident response retainer means specialists can start immediately, with contracts and access already in place. Incident response readiness and tabletop exercises prepare your organization to respond by defining roles, escalation, and regulatory notification procedures, so your team knows exactly who does what in the first hours of an incident.
The time to confirm retention windows, document evidence sources, and establish chain of custody procedures is not during a fraud incident—it is now.
Closing
When card fraud strikes, the completeness of your evidence determines the success of your investigation and the credibility of your regulatory report. SAMA Counter-Fraud Framework Article 4.3 requires preservation of evidence for fraud investigation, and Article 7.2 requires timely, accurate disclosure. Meeting both obligations depends on collecting all four evidence types—authorization logs, network flow data, authentication events, and cardholder session records—in the sequence that prevents overwriting and gaps.
If your organization needs support with digital forensics and incident investigation, or if you want to establish incident response readiness before the next fraud event, we can help. Our Digital Forensics & Incident Investigation service is available on demand, with specialists who understand SAMA Counter-Fraud Framework requirements and the evidence payment fraud investigations require.
