Sooner or later an examiner, an auditor or a disputing customer picks one transfer and asks: show me everything that happened to it. Who verified the sender, what they were screened against, why the transfer stopped, who let it go, what rate they got, and what the payout partner was told. Most remittance platforms have plenty of logging. Far fewer can answer those questions in an afternoon without asking engineering. This guide is for compliance heads, MLROs and operations leads who want to be able to.
It covers why audit trails break, which record answers which question, and a walkthrough of reconstructing one transfer. Figures and references in the examples are illustrative.
Not legal advice: record-keeping periods, formats and access rules vary by jurisdiction and licence. Confirm your obligations with your regulator or adviser.
An audit trail is not the same as a log
Server logs tell an engineer what the software did. An audit trail tells a compliance officer what happened to a customer's money, who decided each step and why, in a form that can be found and trusted months or years later. A platform can produce gigabytes of logs and still fail the question "who released this transfer, and on what basis?"
Regulators treat a gap in that record as a control failure in its own right, whether or not the transfer itself was legitimate. Retention rules make the point. In the United States, most Bank Secrecy Act records must be kept for five years and be accessible within a reasonable time, and since March 2025 OFAC sanctions record-keeping carries a ten-year requirement (see sources below). Other jurisdictions set their own periods, so design for the longest one that applies to you.
For what an examiner typically asks for first, see your first regulatory audit.
Eight ways audit trails break, and the fix for each
Audit trails rarely fail in one dramatic event. They erode through small shortcuts taken under pressure.
| Failure | What it looks like | The fix |
|---|---|---|
| Decisions made outside the system | An exception approved by email or chat; the platform shows a status change with no reason | Every override happens in the platform and asks for a reason |
| Shared logins | "Admin" approved it, but nobody knows which person | Named accounts only, with two-step sign-in and every session logged |
| Rules and prices overwritten | Nobody can say which limit or rate applied on the day | Keep history for limits, rates and fees: who, when, before, after |
| Summary-only API logs | "Screening call succeeded", but not what came back | Keep the request and response for every partner call, with secrets masked |
| Lost incoming messages | A partner says it sent a status update; there is no trace of it | Save every incoming message before processing it |
| Edited money records | A balance was "corrected" and the original figure is gone | Never edit entries; reverse them, and keep both visible |
| Clocks out of step | Screening appears to happen after payout because two systems disagree on the time | Synchronise every system to one time source and check it after infrastructure changes |
| Retention set by storage cost | Records exist in an archive nobody can search in time | Set retention with compliance sign-off, and test retrieval |
Which record answers which auditor question
There is rarely one page that answers everything, and a platform that claims one should be tested on it. In practice an audit trail is a set of named records, each answering a specific question. The table below shows the records RemitSo keeps.
| The question | The record | What it shows |
|---|---|---|
| Who signed in, from where, and did they use two-step sign-in? | Login sessions | Every staff and customer sign-in with time, IP address, city, country, client app, operating system and whether MFA was completed |
| How was this customer verified? | KYC decisions | Documents approved or rejected with rejection labels; a reviewer's override with the reason kept; liveness recordings with the face-match score |
| Were they screened, against what, and what was decided? | Screening decisions | Every screening, what it matched, which list version it was measured against, and what an officer decided about each match |
| Why did this transfer stop? | The customer's risk page | Each risk check that fired, explained in plain language, linked to the records that tripped it, with the evidence kept |
| What rate did the customer get, and who set it? | Rate history | Every change to a standard rate, who made it, when, and the rate before and after |
| What limits applied, and who changed them? | AML rule history | Every change with who made it, what it was before and the reason |
| Who changed what, and when? | Audit log | A searchable, plain-language log, including every override of an AML limit, KYC document-type removals and payout hold reasons |
| What did the partner receive and say? | Outbound API and webhook logs | Every outbound request and response with status and errors, keys masked; every incoming message saved before processing |
| How did the money move? | Accounting journals | Double-entry records for every payment, payout, refund, fee and FX movement; mistakes reversed, never edited |
| Did anyone ask an AI assistant about it? | AI assistant question log | Each question, the tool that answered and the outcome; every question also recorded in the audit log under the person's name |
The AI assistant is an optional add-on. Its question list in System Utilities is kept for 30 days; the audit log entry under the person's name is the lasting record.
Reconstructing one transfer, step by step
An examiner picks a £2,400 transfer sent in the spring and asks for its full history. Here is how a compliance analyst rebuilds it from the records above, in the order the examiner is likely to ask.
| Step | Where to look | What the analyst writes down |
|---|---|---|
| 1. The customer | KYC decisions on the customer's profile | ID and selfie checked inside their first transfer; document approved; no override |
| 2. Screening | Sanction lookup for sender and recipient | Recipient matched a listed name; the officer ruled "not this person", with the reason and the list version used |
| 3. The stop | The customer's risk page | Two checks fired: transfer frequency and a new recipient; each explained, with links to the transfers behind it |
| 4. The limit | AML rule history and the audit log | The 90-day total crossed the tier asking for proof of address; the document was supplied; no limit override recorded |
| 5. The price | Rate history | The standard rate in force at the time of the quote, and who last changed it before the quote |
| 6. Who touched it | Login sessions | The reviewing analyst signed in from the office, two-step sign-in completed |
| 7. The payout | Outbound API log and webhook logs | The request sent to the payout partner, its response, and the partner's completion message |
| 8. The money | Accounting journals | Payment received, FX margin and fee recorded, payout posted; no reversals |
Eight lookups, one written page, and no request to engineering. If any step had needed someone's memory or an email search, that is the gap to close before the next examination.
Useful habit: every quarter, pick five transfers at random, including one that was held and one that was refunded, and reconstruct them this way. Time it. Gaps found in a quiet quarter cost far less than gaps found in an examination.
Doing it with RemitSo
RemitSo, a white label remittance platform, keeps each of the records above as part of normal operation, not as a separate project. Staff sign in with two-step sign-in, and roles decide who sees each page and uses each button, so every action belongs to a named person. Approved payouts are locked: what goes out is exactly what was approved. Refunds are recorded with a reason, and history is never edited.
A few habits make the records stronger:
- Ask for reasons that mean something. "Approved" is not a reason. "Source of funds confirmed by payslip, March" is.
- Keep decisions in the platform. A hold agreed with a partner by phone is recorded by hand with a reason. Do it at the time, not later.
- Hand auditors the software list. A software bill of materials in CycloneDX format is ready to download for a technology review.
Your team still decides retention periods, writes the reasons and tests reconstruction. For how records feed suspicious activity work, see suspicious activity reports, and for the wider programme, compliance and risk management. See the admin features, the release notes, or book a demo.
Sources
- 31 CFR 1010.430: Nature of records and retention period (Bank Secrecy Act, five years)
- Federal Register, 21 March 2025 (2025-04864): OFAC, Reporting, Procedures and Penalties Regulations, extending recordkeeping to ten years
Checked October 2026. Regulations change; confirm current requirements with the regulator or your adviser.
Frequently asked questions
What is an audit trail in a money transfer system?
The record of what happened to a transfer and who decided each step: verification, screening, risk checks, pricing, payout and the money in the books. Unlike server logs, it is written to be found and trusted by compliance staff, auditors and regulators.
How long should audit records be kept?
It depends on the jurisdiction. In the United States, most Bank Secrecy Act records must be kept for five years, and OFAC sanctions records for ten years since March 2025. Design for the longest period that applies to you and confirm it with your adviser.
Does RemitSo have one audit trail page?
No single page answers everything. RemitSo keeps named records: login sessions, KYC decisions, screening decisions, rate history, AML rule history, a searchable plain-language audit log, partner call and message logs, accounting journals and the AI assistant question log.
Can a record be changed after the fact?
Accounting entries are never edited; a mistake is reversed and both stay visible. Approved payouts are locked. Refunds are recorded with a reason and history is never edited.
How do we test our audit trail?
Pick a few transfers at random each quarter, including held and refunded ones, and reconstruct each end to end from the records alone. Any step that needs memory or email is a gap.