What should organisations retain for PSD2 audit and fraud review?

What records matter most for PSD2 audit and fraud review?

For PSD2, the useful retention set is the one that lets you reconstruct consent, authentication, the payment flow, and any exception handling without relying on memory. That means the artefacts should be traceable end to end, tied to the transaction, and retained long enough to support audit, dispute resolution, and fraud investigation. Missing context turns a valid action into an unprovable one.

Which artefacts create a defensible PSD2 evidence trail?

The core records are consent records, transaction provenance, third-party identity details, authentication evidence, and fraud handling records. Together they answer five questions: who requested the action, who was allowed to act, how the payment was initiated, what authentication occurred, and what happened if the transaction was challenged or flagged. That combination is what makes a later review credible.

Consent records should show the scope, timing, and revocation status of permission where the payment journey depends on customer authorisation or delegated access. Transaction provenance should connect the payment event to the originating channel, request, timestamp, beneficiary, amount, and any downstream status changes. Third-party identity details matter when a payment service provider, technical intermediary, or other external party participated in the flow, because investigators need to know which entity performed which step.

Authentication evidence should be rich enough to demonstrate the method used, the assurance level, and the linkage to the specific transaction or session. In practice, that usually means keeping challenge and response artefacts, successful and failed authentication attempts, and any step-up or strong-customer-authentication outcome that influenced the payment. Fraud handling records should capture alerts, case notes, analyst decisions, freezes, reversals, and customer or counterparty communications so the organisation can show not only what was detected, but how it was handled.

How should teams structure retention so audit and fraud review still work later?

The practical issue is not just keeping records, but keeping them correlated. If consent sits in one system, authentication evidence in another, and fraud notes in a case tool with no common transaction key, the organisation may have data but still fail an audit because it cannot rebuild the story coherently. Retention should therefore preserve identifiers, timestamps, and chain-of-custody information across systems.

For PSD2 evidence to remain usable, retention rules should also account for lifecycle events such as consent withdrawal, chargebacks, account closure, and provider offboarding. Those events can change the meaning of earlier evidence, so the organisation needs to retain the historical state, not only the current one. Where multiple parties are involved, the record set should show which organisation owned which step and which logs are authoritative for each segment of the payment journey.

Operationally, the best test is whether an investigator can answer the question, “What exactly happened, under whose authority, and with what proof?” without assembling a manual reconstruction from scattered notes. That requires consistent naming, reliable timestamps, secure storage, and a retention period aligned to the longest plausible audit, dispute, or fraud inquiry window.

Risk and Threat Considerations

Weak retention creates two failure modes: one where a legitimate payment cannot be proven compliant, and another where fraudulent or unauthorised activity cannot be reconstructed in time to limit loss. If records are incomplete, inconsistent, or dropped too early, an organisation may be unable to defend an action, identify the compromised step, or distinguish customer-authorised behaviour from abuse.

Failure mechanism: Evidence is spread across systems, overwritten too soon, or never tied to a common transaction and identity trail, so the organisation cannot prove consent, authentication, or third-party involvement after the fact.

Impact: Audit findings, weaker fraud recovery, slower investigations, and higher exposure to disputes, regulatory challenge, and repeated control failures.

Practitioner Guidance

What to prioritise: Retain the evidence that binds the payment story together first, not just the largest volume of logs. If an artefact cannot be linked back to a specific transaction, consent state, and authentication event, its standalone value for PSD2 review is limited.

What to verify: Confirm that retained records can support a full reconstruction from request to outcome, including the external party involved, the authentication method used, and any fraud decision taken. A good retention scheme is one an investigator can query without depending on tribal knowledge.

Common mistake: Treating fraud case notes as a substitute for system evidence. Narrative summaries help analysts, but they do not replace immutable or well-governed source records when an auditor or dispute process needs proof.

Practitioner takeaway: Keep the smallest evidence set that still proves authority, identity, and transaction lineage, because PSD2 review failures usually come from broken linkage, not from a total lack of data.

Related resources from NHI Mgmt Group

• Why do non-human identities create more audit risk than human accounts?
• Why do non-human identities create audit risk in modern environments?
• How do organisations operationalise NHI ownership at scale?
• When should organisations treat an NHI as a high-priority risk?