What is an audit-ready payment log?

A record of each payment complete enough that an examiner, sponsor bank or auditor can rebuild the transaction from the log alone: who paid whom, how much, when, through which channel, what checks ran and who touched it. Nigerian law requires records that let individual transactions be readily reconstructed.

How long should payment logs be kept?

Follow the longest rule that applies to you. In Nigeria transaction records must be kept for at least five years after completion; Kenya requires at least seven years; South Africa at least five years after the business relationship ends. Data protection law limits keeping personal data longer than needed.

Is encryption enough to make logs audit-ready?

No. Encryption protects confidentiality, but a reviewer also needs to trust that records were not changed or deleted. That needs sequence numbers or hashes, append-only storage, separate administration of the log store, and unique user IDs with multi-factor authentication for anyone who can reach it.

Does StackWeaver audit our payment logs?

No. Our evidence readiness assessment is a readiness review, not an audit. In five working days we look at the evidence you can show today, list the gaps against the controls on this page, and give you a plan. Audit opinions come from independent auditors.

Audit-Ready Payment Logs: Fields, Retention and Integrity

A payment system is audit-ready when anyone with the right to ask can rebuild a single payment from its records, quickly, and trust that the records were not changed. This guide sets out the fields to log, how long to keep them, how to protect them, and the evidence that shows it.

Last reviewed: 12 October 2026 · Next review: 10 January 2027 · By the StackWeaver compliance research team

What "audit-ready" means for payment logs

That sentence is the practical test. When an examiner, a sponsor bank or an independent auditor picks a payment, the question is whether you can show its whole life from your records alone, without engineers rebuilding it from several databases. If you can, your logs are doing their job. If it takes a week and a spreadsheet, they are not.

The fields to log for every payment

Recommended payment log fields
Field	What to capture
Transaction reference	One unique ID per payment, the same in every system it passes through, plus the scheme or processor reference.
Timestamps	Initiated, authorised, settled and any reversal, each in UTC with the time source stated.
Amount and currency	The amount as instructed and as settled, with any fees and FX rate kept separately.
Payer and payee	Account or wallet identifiers that link back to the customer record from onboarding, not free-text names only.
Channel and rail	App, API, USSD, card or agent, and the payment rail or scheme used.
Status history	Every state change in order, with the reason code for declines, holds and reversals.
Screening and monitoring results	The sanctions screening result and any transaction-monitoring alert ID linked to the payment, with its disposition.
Who did what	The unique user or service ID behind every manual action: approvals, overrides, refunds and data corrections.
Source system and integrity data	Which system wrote the record, a sequence number, and a hash or signature so gaps and edits show up.

Two gaps are easy to miss. The first is logging the payment but not the decisions around it: the screening hit that was cleared, the limit that was overridden, the refund that was approved by hand. The second is keeping names instead of identifiers, so a payment cannot be tied back to the customer record that was verified at onboarding. If you also store or process card data, check the PCI DSS logging requirements separately; they go further than this list.

How long to keep them

Retention is set by law, and the rules differ by country. These are the anti-money-laundering record-keeping minimums in three markets we cover, each checked against the official text and recorded in our source ledger.

Data protection law pulls the other way. Kenya's Data Protection Act and South Africa's POPIA both say personal data should not be kept longer than needed for its purpose, unless the law requires or allows it. The answer is a written retention schedule that names the legal basis for each record type, so you keep what the AML rules require and dispose of the rest on time. In our control library this is SWC-26 Retention and disposal, supported by SWC-35 Record keeping and SWC-16 Logging, monitoring and retention.

Integrity and access

Make changes visible. Give each record a sequence number and a hash that chains to the one before, or write to storage that cannot be overwritten. Then run a check on a schedule and keep the output. Our audit trail walkthrough shows what a tamper-evident record looks like in practice.
Protect it. Encrypt the log store at rest and in transit, and manage the keys separately from the people who administer the logs (SWC-18 Encryption and key management).
Know who touched it. Every person and service that can read or change the log store should have its own ID, and people should use multi-factor authentication (SWC-08 Unique IDs and multi-factor authentication). Shared admin accounts make every manual action unattributable.
Separate duties. The engineers who run the payment system should not be able to edit or delete its logs without a second person and a record of it.

A sample evidence index

Sample evidence index for payment logs (illustrative)
Evidence	What it shows	Control (draft library)
Logging standard and field schema	Which events are logged, the field list above, and who owns it	SWC-16 Logging, monitoring and retention
Retention schedule	How long payment logs and customer records are kept, the legal basis, and how they are disposed of	SWC-26 Retention and disposal
Reconstruction test	Five payments picked at random, each rebuilt end to end from the logs alone, with the time it took	SWC-35 Record keeping
Integrity check output	A dated run of the hash or sequence check across the log store, with any gaps explained	SWC-16 Logging, monitoring and retention
Access list for the log store	Who can read, who can administer, and the MFA setting for each, reviewed on a schedule	SWC-08 Unique IDs and multi-factor authentication
Archive restore test	Proof that logs from the oldest retained period can still be found and read	SWC-26 Retention and disposal

Draft mapping, pending named reviewer sign-off. The StackWeaver control library (SWC ids) is a draft.

Find your gaps in five working days

Our evidence readiness assessment is a readiness review, not an audit. We look at the evidence you can show today for payment logging, retention and access, list the gaps against these controls, and give you a plan with owners. For the anti-money-laundering side of the same records, see AML audit readiness and our CBN AML/CFT page; for the wider picture, see audit readiness for fintechs.

This guide is general information, not legal advice. The official text is the authority. Local legal interpretation should come from qualified counsel in each country. AI tools helped research and draft this guide; every legal statement is recorded in our public source ledger and checked automatically against the official text. Labels follow our editorial policy.