What an audit trail is
An audit trail is a chronological record of actions taken within a system, kept in a form that cannot easily be altered. In a payments context, it records every meaningful step in the life of a payment and every change to the settings that govern payments: who logged in, who created a payment, who changed it, who approved it, when it was released, and what happened afterwards.
A bank statement is not an audit trail. A statement shows that money left an account. It does not show who decided to send it, who checked it, or whether the payee's bank details were changed the day before. Those are exactly the facts that matter when something goes wrong, or when an auditor needs to confirm that controls are working.
The most useful audit trails are generated automatically by the systems used to make payments, rather than kept by hand. Manual logs depend on people remembering to update them, and they are easy to edit after the event.
What a good trail records
At a minimum, a payment audit trail should capture each of the following, with the user, the date and time, and the details of the change:
- Access events. Logins, failed login attempts, logouts, password resets and changes to two-factor authentication.
- Payment creation. Who entered the payment, the amount, currency, debit account, payee and reference.
- Amendments. Any change to a payment after creation, with the previous and new values.
- Approvals and rejections. Each approver, the order in which they acted, and any comments.
- Release and execution. When the payment left the system and its status updates afterwards.
- Payee changes. Creation of new payees and any change to an existing payee's bank details.
- User and permission changes. New users, removed users, changes to roles, limits and approval rights.
- FX conversions. Who requested a conversion, the rate accepted and when.
- Exports and downloads. Who exported statements or data, and when.
Each entry should be tied to a named individual. Shared logins destroy the value of an audit trail, because they make it impossible to say who acted.
Recording the before and the after
For changes, recording only that something changed is not enough. The trail should show what the value was before and what it became. If a payee's account number was altered, the record should hold both the old and new numbers. If a user's approval limit was raised, both limits should appear.
This matters most in fraud investigations. A common pattern in payment fraud is a small, quiet change to a trusted payee's bank details, followed shortly after by a payment that looks routine. A trail that shows the old details, the new details, who made the change and from which session lets an investigator see exactly what happened and when.
Why auditors care
External auditors of a company, trust or fund need to be satisfied that payments were properly authorised and recorded. They usually test this by selecting a sample of payments and tracing each one back through the system to its approvals. A clear electronic trail makes this quick. Without it, the auditor must rely on emails, signed forms and interviews, which takes longer and gives less assurance.
Auditors also test controls themselves. If an organisation says that every payment above a threshold needs two approvers, the auditor will want evidence that the rule was enforced in practice, including whether anyone ever approved their own payment or whether the threshold was temporarily lowered. A system-generated trail of approvals and permission changes is the evidence they look for.
For trusts and family offices, auditors and accountants preparing trust accounts will often ask how distributions were approved. Pairing the trustee resolution with the platform's approval record for the same payment gives them everything they need.
Why regulators care
Regulated financial businesses must keep records of transactions and of the identity of their clients, and must be able to produce them on request. In Canada, anti-money laundering rules generally require reporting entities to keep prescribed records for at least five years. Other countries have similar requirements, sometimes longer.
Regulators and law enforcement may ask a regulated business to reconstruct a transaction: who instructed it, what checks were made, and what information was held at the time. A complete audit trail on the provider's side, matched with the client's own records, makes that reconstruction possible. It also protects the client, because it shows that payments were made on proper instructions.
Audit trails and segregation of duties
Audit trails and approval controls reinforce each other. Segregation of duties means that no single person can complete a sensitive process alone. In payments, the classic split is between the person who creates a payment and the person who approves it, and between the person who adds a payee and the person who pays them.
A platform can enforce these splits through user roles and dual authorisation. The audit trail then proves they were followed. When reviewing the trail, look for exceptions: a user who both created and approved payments, approval rights granted temporarily to cover a holiday and never removed, or payees added and paid by the same person on the same day. Each may have an innocent explanation, but each deserves a question.
Reviewing the trail
An audit trail that nobody reads offers protection only after the damage is done. A short periodic review catches problems while they are still small. A practical routine for a finance or operations team might include:
- A monthly check of user and permission changes, confirming each one was authorised.
- A review of all new payees and changes to payee bank details since the last check.
- A look at failed login attempts and logins at unusual times or from unusual locations.
- Sample testing of a handful of payments against their supporting documents.
- Confirmation that leavers' access was removed on their last day.
The review itself should be recorded, with the date and the reviewer's name, so that auditors can see the control in operation.
Retention and access
Audit trail data should be kept for at least as long as the underlying financial records, and often longer where the organisation's own regulator, the trust's governing law or tax rules require it. Trustees should keep records for the life of the trust and a period after it ends, since questions about distributions can arise many years later.
Access to historical records matters as much as their existence. If records are held by a provider, check that you can export them in a usable format, and that you will still be able to obtain them if the relationship ends. A trail that can only be viewed screen by screen, with no export, is of limited use to an auditor.
Protect the integrity of exported records. Store them where they cannot be edited, and keep them in the same place as the related resolutions and invoices so the full picture can be assembled quickly.
A worked example
Consider a corporate trustee whose auditors are reviewing the year's distributions from a family trust. They pick a capital distribution of a large sum in Canadian dollars paid to a beneficiary in September.
From the trustee's own file, the auditors receive the trustee resolution, dated a week before the payment, naming the beneficiary, the amount and the clause relied on, together with the protector's written consent. From the payment platform's audit trail, the trustee exports the full history of that payment.
The export shows that an administrator in the trust company's operations team created the payment two days after the resolution. It shows the euro to Canadian dollar conversion booked by the same administrator, with the rate and timestamp. It shows that the beneficiary had been added as a payee the previous month by a different user, with the bank details recorded at that time and unchanged since. It shows two approvals, by two directors of the trustee company, on the same afternoon. Finally it shows the release and the completed status.
In a few minutes the auditors can confirm that the payment matched the resolution, that consent was obtained beforehand, that the payee had not been altered, and that the trustee's two-signatory rule was applied. They move on to the next sample.
Now imagine the same payment made on the strength of an email from one director to a bank relationship manager. The auditors would need to find the email, confirm the director's authority, ask how the second director's approval was given, and check the payee details by some other route. The payment may have been entirely proper, but proving it would take far longer.
Common gaps
- Payments instructed by email or telephone, outside any system, leaving only a forwarded message as evidence.
- Shared user credentials used by a team.
- Approvals given verbally and recorded afterwards by the person who created the payment.
- Payee details changed by support staff on request, with no record of who asked.
- Logs that record actions but not the previous values of what was changed.
- Records held only on a former employee's laptop or mailbox.
Most of these are fixed by routing all payment activity through a single platform with individual logins, role-based permissions and an automatic trail.
General information only
This article is general information about audit trails and payment controls. It is not legal, accounting or regulatory advice. Record keeping obligations vary by jurisdiction and by type of organisation, and you should confirm your own requirements with your advisers and auditors.
CCYFX Online records user actions, approvals and changes in a full audit trail, with statements and exports available to clients. Read more about the platform.
