Preparing for Your First Regulatory Audit as a Money Transfer Operator

A first regulatory audit rarely fails on policy. Most new operators have an AML policy that reads well. It fails on the gap between the policy and the records: a threshold in the manual that differs from the one in the system, a screening hit cleared with no reason recorded, a training module nobody signed off. Auditors test what you did, not what you wrote.

This guide is for compliance officers, MLROs and founders facing their first inspection by a regulator or financial intelligence unit, or a first independent AML review. It covers what auditors test, how to build the evidence pack before they ask, how to run a mock audit, and the findings that come up most often. We also show where RemitSo's admin panel produces the evidence and what your team still owns. Requirements differ by jurisdiction; use your regulator's own guidance as the final word.

Most AML audits of money transfer operators follow the same logic, whatever the country. The auditor asks three questions of each control: does it exist on paper, does it work in practice, and can you prove it worked on a sample they choose?

• Governance. A named compliance officer with authority and resources, board oversight, and a business-wide risk assessment that is current and actually shapes your controls.
• Customer due diligence. Identity checks, document review, enhanced due diligence when risk requires it, and ongoing monitoring of existing customers.
• Sanctions screening. Which lists, how current, who is screened, and how matches are decided.
• Transaction monitoring. The rules, how they map to your risk assessment, how alerts are reviewed, and how changes to rules are approved.
• Suspicious activity reporting. How staff escalate, how the decision to report is made and recorded, and whether reports were filed on time.
• Regulatory reporting. Threshold or cross-border reports complete and on time.
• Training. Who must complete what, whether they did, and whether it fits their role.
• Record keeping and access. Records kept for the required period, retrievable, and protected from unauthorised change.
• Independent review and outsourcing. Whether your programme has been tested by someone independent, and how you oversee the technology and partners you rely on.

Read the notification letter closely. It usually names the review period and the areas in scope. If it does not, ask; preparing for everything at equal depth wastes the weeks you have.

An evidence pack is an indexed set of documents and system extracts, one section per control, prepared before the audit starts. It turns "we will find that for you" into "it is in section 4". Each item should show the control, the period it covers and who produced it.

Two practical points. Produce system extracts close to the audit date and label them with the date and the person who ran them. And keep a request log during the audit: what was asked, what you provided, when and by whom. See also why audit logs are critical for remittance compliance.

A mock audit is a rehearsal done by someone who did not build the controls. An external reviewer is best; a colleague from outside compliance is better than self-review. Allow four to six weeks before the real audit so there is time to fix what it finds.

1. Pick samples the way an auditor would. Random customers from the review period, plus deliberate picks: high-risk countries, the largest senders, customers who hit a document tier, every screening hit that was cleared.
2. Walk each sample end to end. For one customer: onboarding documents and decision, screening results and rulings, limits applied, any alerts and their outcome, any report filed. Every step should be visible without asking the person who did it.
3. Time the retrieval. Ask for a specific record and measure how long it takes. Minutes is good; "by tomorrow" is a finding in waiting.
4. Test a rule change. Pick an AML rule that changed in the period. Find who changed it, when, why, and who approved it.
5. Interview staff. Ask a support agent what they would do with a suspicious request, and a compliance analyst how they decide a screening hit. Answers should match the procedure.
6. Write findings like an auditor. Control, what was expected, what was found, risk, fix, owner and date.

The numbers are illustrative, not drawn from any real operator.

A 15-person operator receives notice of an AML inspection covering the last twelve months. The compliance officer asks an external reviewer for a two-day mock audit. The reviewer samples 30 customer files, 12 cleared screening hits, 8 monitoring alerts, 4 suspicious activity reports and the training records of every member of staff.

• Customer files: 27 of 30 complete. Three rejections had no reason recorded because staff used a free-text note in an email instead of the rejection label.
• Screening hits: all 12 had an officer's decision. Two had no explanation of why the match was false.
• Rule changes: the AML rules history showed who changed a 90-day limit in March, but there was no record of who approved it or why.
• Reports: all four suspicious activity reports were submitted; one took far longer than the policy's stated timeframe from first escalation.
• Training: two staff overdue, both in customer service. The overdue alerts had been sent, but nobody had followed up.
• Access: one leaver still active, and four sessions in the period where MFA was not completed.

In five weeks the team relabels the three rejections, adds reasoning to the two screening decisions, records the March approval as a dated retrospective note rather than backdating anything, gets the two staff trained and signed off, deactivates the leaver and reviews the four sessions. They write a short note on the late report explaining the cause and the change to the escalation procedure.

• A stale risk assessment. Written for the licence application and never updated, even though corridors and products changed.
• Policy and system thresholds that disagree. The most avoidable finding of all.
• Decisions without reasons. Screening hits cleared and documents rejected with no recorded rationale.
• Uncontrolled rule changes. Monitoring thresholds changed with no approval or link to the risk assessment.
• Slow or thin suspicious activity reporting. Delays between escalation and filing, or decisions not to report with no written reasoning.
• Training on paper only. Generic content, no role-specific modules, overdue staff with no follow-up.
• Access drift. Leavers still active, shared logins, administrators who also approve payouts. See role-based access control for money transfer operators.
• Weak outsourcing oversight. No due diligence file on the platform or partners the operator relies on.

During. Name one coordinator who receives every request and keeps the request log. Give auditors read-only system access if they ask, with an account of their own. Answer the question asked, factually; if you do not know, say so and come back with the answer. Do not argue a finding in the room. Ask what evidence would satisfy the auditor and note it.

After. Findings are usually graded by severity. For each, write a corrective action plan: what you will change, who owns it, by when, and how you will show it worked. Report progress on the dates you committed to. Regulators read the response to findings as closely as the findings themselves, and they check it at the next visit.

Then keep the pack alive. Refresh the system extracts quarterly, rerun a small mock audit each year, and keep the request log template ready. Your second audit should be a much shorter exercise. For the ongoing monitoring view, see how to build a compliance dashboard.

RemitSo's admin panel keeps much of the evidence an auditor asks for as a by-product of daily work. See the admin features.

• AML rules with a history of changes and who last changed each rule: show exactly which limits applied in the review period and trace every change to a person.
• Sanction lookup with each officer's decision on every match: hand the auditor the screening record for any customer in the sample.
• Eight sanction lists, each with its loaded version, the publisher's last change and load history: prove the lists you screened against were current on any date.
• KYC document approvals and rejections with rejection labels: every customer file shows the decision and the reason.
• Suspicious Activity Reports generated and submitted from the console: reports and their submission sit with the rest of the compliance record.
• Regulatory reporting with a completeness check: each run is checked against in-scope transfers, so you can show nothing was left out.
• Training by department, with sign-off by someone else and alerts when staff fall behind (an optional add-on): signed records for every member of staff.
• 89 permissions and login sessions with MFA status, plus the Compliance Dashboard: evidence of access control, and one view of the programme for board reporting.

Your team still writes the policies and risk assessment, decides every screening hit, document and report, approves rule changes, commissions the independent review and answers the auditor.

Read the release notes, or book a demo to see where each piece of evidence lives.