How to Prepare an Evidence File for a goAML RFI in the UAE

When a UAE business receives a Request for Information (RFI) related to goAML reporting, collecting the requested documents is only one part of the response process. The business must also ensure that its evidence is accurate, organised, traceable, and directly relevant to the information requested.

Poorly organised records can make it difficult for compliance teams to identify the right documents, verify transaction details, and explain how the evidence supports their response. Missing references, inconsistent file names, and unclear document sources can also create unnecessary delays during internal reviews.

Preparing a structured evidence file helps businesses manage these challenges. By using consistent document naming, source verification, cross-referencing, and an evidence register, compliance teams can create a clear record of the information gathered for an RFI response.

This guide explains how UAE businesses can build and maintain an organised evidence file to support their goAML RFI response process.

1. Define the Scope of the Evidence File

Before collecting documents, identify the exact information required by the RFI. The evidence file should be built around the request rather than around every document the business holds about a customer.

Start by reviewing the individual questions or information points included in the request. Identify the customer, business relationship, transaction, reporting period, or other subject to which each point relates.

For each requirement, record:

The information being requested.
The relevant customer, transaction, or business relationship.
The period covered by the request, where specified.
The likely source of the required information.
The documents available and those still outstanding.

This initial mapping creates a clear boundary for the evidence file. It also helps the team avoid collecting unrelated documents that do not contribute to answering the request.

If a requirement is unclear, record the issue and follow the appropriate internal process for clarification rather than making assumptions about what is needed.

2. Create a Structured Evidence Folder

Once the scope is defined, create a controlled folder or case file for the specific RFI. The folder structure should allow authorised reviewers to find information without searching through unrelated customer records or email attachments.

A practical structure could include:

RFI Case File

01_Request_and_Reference
02_Customer_and_KYC_Records
03_Transaction_Documents
04_Contracts_and_Invoices
05_Correspondence_and_Explanations
06_Verification_and_Reconciliation
07_Response_Review_and_Approval
08_Submission_and_Follow_Up

Adapt the structure to the actual information requested. Not every RFI will require every folder.

Keep the original request and its reference details in a clearly identifiable location. Store the working evidence separately from the final response and submission record so that reviewers can distinguish source material from the documents prepared for submission.

Access should be limited to authorised personnel, particularly where the evidence contains customer identification information, financial records, or confidential compliance material.

3. Use Consistent Document Naming Conventions

A clear file-naming system makes documents easier to identify, retrieve, review, and cross-reference. Generic names such as document.pdf, invoice_new.pdf, or final_version2.pdf do not explain what a file contains.

Instead, use a consistent format such as:

RFI-Reference_Document-Type_Entity-or-Transaction_Date_Version

For example:

RFI-2026-015_KYC-Record_Customer-A_2026-08-12_v01.pdf
RFI-2026-015_Invoice_TXN-1048_2026-08-18_v01.pdf
RFI-2026-015_Transaction-Statement_TXN-1048_2026-08-18_v01.pdf
RFI-2026-015_Internal-Review_2026-10-05_v01.docx

These are illustrative file names, not official UAE or goAML naming requirements. Use a case reference that follows your organisation's internal conventions and avoid putting unnecessary personal or sensitive information in file names.

A good naming convention should be:

Consistent: Apply the same format to all relevant documents.
Descriptive: Identify the document type and its relevance.
Searchable: Use predictable references and dates.
Version-controlled: Distinguish working drafts from approved files.
Secure: Avoid exposing confidential customer details unnecessarily.

Do not rename or alter original records in a way that obscures their identity or provenance. Where needed, preserve the original file and create a clearly labelled working copy.

4. Verify the Source and Authenticity of Each Document

An evidence file is useful only when the documents can be trusted and their origins can be explained.

For every important record, identify where it came from and whether it is an original record, an authorised system export, a copy, or an internally prepared document.

For example, a transaction statement may come from an accounting system, an invoice may be obtained from the finance department, and a customer identification record may be held in the customer due diligence system.

The reviewer should check:

Who provided the document.
Which system, department, or external source produced it.
When it was obtained.
Whether it appears complete and readable.
Whether relevant dates and reference numbers are consistent.
Whether the document has been altered or converted during processing.
Whether additional verification is required.

If the business receives a scanned document or a copy from another department, record that fact where it matters to understanding the evidence.

Where information is extracted from a system, retain sufficient details to identify the source and retrieval date. If a document's authenticity cannot be established, flag the limitation rather than presenting it as independently verified.

Never create, modify, or backdate source records to make the evidence file appear complete.

5. Maintain an Evidence Register

An evidence register is a central index of the documents collected for an RFI. It helps compliance staff understand what is available, what each document supports, and which items still require attention.

The register can be maintained in an access-controlled spreadsheet or an approved compliance case-management system.

Useful fields include:

Evidence ID: A unique reference for the item.
Document name: The stored file name.
Document type: For example, invoice, KYC record, statement, or contract.
Source: The system, department, or person from which it was obtained.
Date obtained: When the team received or retrieved it.
Relevant RFI point: The request item the document supports.
Verification status: Whether it has been checked or requires further review.
Location: Where the document is stored.
Assigned reviewer: The person responsible for checking it.
Notes or limitations: Missing pages, unresolved discrepancies, or other relevant observations.

6. Cross-Reference Evidence to the RFI Requirements

Cross-referencing connects each request point to the evidence that supports the response. Without it, a reviewer may have to open multiple files to determine whether a particular question has been addressed.

Assign a reference to each RFI requirement, such as RFI-P01, RFI-P02, and RFI-P03. Then link the relevant evidence IDs to each requirement in the evidence register.

For example:

RFI-P01 – Customer identity: EV-001
RFI-P02 – Transaction details: EV-002
RFI-P03 – Transaction purpose: EV-003 and EV-004

The response preparation document can use the same references to show which records support each explanation.

Cross-referencing is especially helpful when one document supports multiple points or when several documents must be read together. It also makes it easier to identify requirements that do not yet have supporting evidence.

However, the presence of a document does not automatically prove the conclusion being drawn from it. The reviewer must assess whether the evidence actually supports the statement in the proposed response.

7. Reconcile Related Documents and Identify Gaps

Documents collected from different systems may contain inconsistent information. Customer names may be formatted differently, transaction dates may not match, and invoice amounts may differ from recorded payments because of fees, adjustments, or other circumstances.

Before finalising the evidence file, compare related documents and investigate significant discrepancies.

For example, when reviewing an invoice alongside a transaction statement, check the available transaction reference, amount, date, currency, and parties involved. If the records differ, determine whether the difference has a documented explanation.

Record:

The discrepancy identified.
The records compared.
The checks performed.
The explanation, if supported by evidence.
Any unresolved limitation.
The person responsible for further action.

Do not silently correct source records or remove an inconvenient document from the evidence file. Preserve the relevant records and document the outcome of the review in accordance with internal procedures.

If the requested information is unavailable, record the gap in the evidence register and follow the applicable process for addressing it. Never invent details to fill a gap.

8. Control Document Versions and Preserve the Audit Trail

During preparation, a document may pass through several stages, including collection, review, correction of an internal draft, and approval. Without version control, team members may accidentally use an outdated or unapproved version.

Use a clear process to distinguish:

Original source documents.
Working copies and internal notes.
Draft response documents.
Reviewed or approved response versions.
Records of what was actually submitted.

Record material changes to the evidence register or response preparation documents when appropriate. The record should help an authorised reviewer understand who made a change, when it was made, and why.

Keep evidence of the final submission and any subsequent correspondence in the case file, where permitted and appropriate. Retain records according to applicable legal requirements and the organisation's record-retention policy.

These practices support continuity when staff responsibilities change and make it easier to reconstruct the handling of an RFI later.

9. Review the Evidence File Before Submission

Before the response is submitted through the applicable goAML process, conduct a final review of the evidence file and the response being prepared.

Use the following checklist:

Every RFI requirement has a corresponding response or documented outstanding issue.
Relevant documents are indexed in the evidence register.
File names and evidence references are consistent.
Document sources have been identified.
Important details have been checked against underlying records.
Discrepancies and information gaps have been investigated or recorded.
Each response point is linked to relevant supporting evidence.
Sensitive records are stored and shared through authorised channels.
The appropriate internal review or approval has been completed.
The final response and submission record can be identified clearly.

The evidence file should support the response, not replace the submission instructions. Follow the format, channel, and other requirements specified for the particular request.

10. Common Evidence Management Mistakes to Avoid

Saving all documents in one folder: This makes relevant records difficult to locate. Use a structured folder system and a central register.

Using unclear file names: Generic names increase the risk of selecting the wrong document. Apply a consistent, descriptive naming convention.

Failing to record document sources: A reviewer may be unable to establish where a record originated. Record its source and retrieval details.

Submitting documents without cross-references: The relationship between evidence and the request may be unclear. Map each document to the relevant RFI point.

Ignoring conflicting information: Unexplained differences can weaken the response. Record the discrepancy and investigate it.

Overwriting original records: This can obscure the evidence history. Preserve source records and control working versions.

Leaving the evidence register outdated: The register may no longer reflect the actual case file. Update it throughout the review process.

Retaining no final submission record: The business may struggle to confirm what was sent. Keep an appropriate record of the final response and submission.

Frequently Asked Questions

1. What is an evidence file for a goAML RFI?

An evidence file is an organised collection of records used to support the review and response to a Request for Information. It may contain customer records, transaction documents, correspondence, internal review notes, and a register linking the evidence to the request.

2. What is an evidence register?

An evidence register is an index that identifies each document, its source, storage location, verification status, and the RFI requirement it supports. It helps reviewers track documents and identify missing information.

3. How should documents be named for an RFI evidence file?

Use a consistent naming convention that includes an internal case reference, document type, relevant date, and version where necessary. Avoid exposing unnecessary personal information in file names.

4. Why is source verification important?

Source verification helps the compliance team understand where a document came from, whether it is complete, and whether it can reliably support the response. Unverified information should be flagged rather than presented as confirmed.

5. Should original documents be changed when preparing an evidence file?

Original source records should not be altered in a way that obscures their authenticity or history. If working copies or annotations are needed, preserve the original and identify the working version clearly.

6. What should a business do if evidence is missing or inconsistent?

Record the gap or discrepancy, investigate it using reliable sources, and document the outcome. If it remains unresolved, follow the applicable internal and reporting procedures rather than making assumptions.

7. Is an evidence register an official goAML requirement?

The register described in this article is a practical internal recordkeeping method, not a claim that the UAE FIU requires a specific register format. Businesses should follow the instructions applicable to their particular request and sector.