Listen To Our Podcast🎧

Which UAE rules govern goAML reporting in 2026?
UAE reporting entities should treat goAML as a controlled reporting workflow, not a website login. Under Federal Decree-Law No. 10 of 2025, financial institutions and designated non-financial businesses and professions (DNFBPs) must report suspicious funds or transactions to the UAE Financial Intelligence Unit (FIU) directly and without delay when reasonable grounds for suspicion exist.
A sound process has three parts. Register the right entity and users under the right supervisor, build an internal escalation path that reaches the money laundering reporting officer (MLRO), then submit a complete suspicious transaction report (STR) without warning the customer. The UAE FIU receives the report. The reporting entity's authorised human remains responsible for the filing decision, accuracy and follow-up.
Sahil Kataria | Founder and CEO of FluxForce | Draft prepared 2026-10-04. Publication date pending.- Identify the correct supervisory route.
- Prepare the SACM registration pack.
- Move from an internal alert to an MLRO decision.
- Write an evidence-led STR narrative.
- Confirm and preserve the submitted filing.
Request a goAML STR workflow review

The Register, Investigate, Report, Prove model
Connect portal access, case evidence, human authority and the post-filing record.
- Register the entity and authorised users under the correct supervisor.
- Investigate the transaction, customer and ownership evidence.
- Report only after the MLRO or authorised delegate approves the filing.
- Prove what was known, decided, submitted and answered later.
UAE reporting entities should register under the correct supervisor, investigate the available evidence, let the MLRO decide whether the reporting threshold is met and submit through a named authorised user.
The Register, Investigate, Report, Prove model
A practical goAML operating model has four connected stages.
- Register. Put the legal entity, supervisory body, MLRO and authorised users on the correct access path.
- Investigate. Gather the transaction, customer, ownership and alert evidence needed to test the suspicion.
- Report. Let the authorised reporting owner select the report type, approve the narrative and submit through goAML.
- Prove. Preserve what was known, who decided, what was filed and how the entity answered later FIU requests.
This is an editorial operating model. It is not legal advice and it does not replace the UAE FIU's portal instructions, your supervisor's directions or counsel's interpretation of the current law.
Which UAE rules govern goAML reporting in 2026?
Federal Decree-Law No. 10 of 2025 is the current federal law on anti-money laundering, counter-terrorist financing and proliferation financing. It took effect on October 14, 2025 and replaced the earlier Federal Decree-Law No. 20 of 2018.
Cabinet Resolution No. 134 of 2025 is the current executive regulation. It took effect on December 14, 2025 and replaced Cabinet Decision No. 10 of 2019.
That matters because some operational pages still cite the previous 2018 and 2019 instruments. The Ministry of Economy and Tourism's goAML page was updated on October 3, 2026, but its alert text still names the old framework. Use the page for current registration mechanics and DNFBP scope cues, then confirm legal duties against the 2025 law, the 2025 executive regulation and your supervisor's current directions.
The law sets the reporting trigger. When a financial institution or DNFBP has reasonable grounds to suspect that funds are criminal proceeds, linked to a crime or intended for a crime, it must report directly and without delay to the FIU and provide the available transaction and party information.
The executive regulation requires financial institutions and DNFBPs to appoint a competent compliance officer with enough authority and independence to perform the role. Your governance should make clear who receives internal alerts, who investigates, who can submit, who acts as backup and who answers FIU follow-up.
Is every UAE business required to register?
No. Registration follows the entity's regulated status and supervisory route. The UAE FIU's SACM launch page says supervisory bodies and reporting entities under those bodies use the registration process to secure goAML access for STR and suspicious activity report submissions.
- The legal entity identifies its supervisor, registers through SACM, activates goAML access and assigns the MLRO and authorised users.
The current SACM form asks the applicant to choose either Reporting Entity or Supervisory Body. It also asks the reporting entity to select its supervisor. The listed choices include the Central Bank of the UAE, Dubai Financial Services Authority, Abu Dhabi Global Market, Securities and Commodities Authority, Ministry of Economy and Tourism, Ministry of Justice and the Virtual Assets Regulatory Authority.
For DNFBPs under the Ministry of Economy and Tourism, the Ministry page identifies four main categories covered by its registration guidance: real estate businesses, auditors and accountants, dealers in precious metals and stones, and trust or company service providers.
Do not copy another firm's registration route. A bank, an ADGM firm, a mainland real estate broker and a law firm may reach goAML through different supervisory relationships. Start with the licence and supervisor, not the trade name.
Step 1: confirm the legal entity and supervisor
Build a one-page registration record before anyone opens the form. Record the entity's exact licensed name, licence or registration number, legal form, regulated activity, supervisor and the reason the entity is a reporting entity.
Then resolve these questions.
- Is the entity regulated by the Central Bank of the UAE, DFSA, ADGM, SCA, VARA, the Ministry of Economy and Tourism, the Ministry of Justice or another listed body?
- Does the licence cover more than one regulated activity?
- Is registration required at entity level, branch level or for a particular licensed establishment?
- Has the supervisor supplied an identification number, code or approval that must be used in goAML?
- Is an existing registration already attached to the entity?
A duplicate or misrouted application can slow access and create a weak audit trail. Keep the supervisor's answer with the registration file.
Step 2: appoint the MLRO and backup before creating users
The registered user should be authorised to act for the entity. The SACM terms require the person completing pre-registration to confirm that they are authorised and that the submitted identity information is correct.
The practical owner is usually the MLRO or another compliance officer operating under the entity's approved authority matrix. Name a backup as well. Absence, leave or staff turnover should not stop a required report.
Set out four separate permissions.
| Permission | What the user can do | Control boundary |
|---|---|---|
| Prepare | Build the case, populate fields and attach evidence. | Cannot submit unless separately authorised. |
| Review | Test the legal trigger, facts and narrative. | Cannot change evidence without a recorded reason. |
| Submit | Send the approved report through goAML. | Must use a named account and approved authority. |
| Administer | Add or remove users and maintain access. | Should not inherit filing authority by default. |
Avoid shared credentials. The SACM terms make each entity responsible for activity under its user accounts and for maintaining password confidentiality.
Step 3: prepare the registration pack
The Ministry's current DNFBP page lists an authorisation letter, passport, residence visa, Emirates ID and the commercial trade licence among the documents needed for registration. It also directs applicants to install an authenticator application used for the SACM access code.
The current SACM form asks for the entity name, supervisor, registration number, registering person's identity, nationality, ID type and number, email, mobile number, remarks and a PDF attachment.
Prepare clean, legible files with consistent names. Check that the entity name is identical across the licence, authorisation letter and form. Confirm that the email is controlled by the institution, the mobile number is usable for the authorised person and the attachment contains no unrelated personal information.
A registration checklist should include:
- current licence or registration evidence;
- signed authorisation for the applicant;
- identity documents required for that applicant;
- MLRO appointment or supervisor correspondence where applicable;
- entity and supervisor identifiers;
- institutional email and active mobile number;
- access-owner and backup details; and
- an internal approval showing who authorised the application.
Step 4: complete SACM pre-registration
The UAE FIU's launch page uses SACM, the Services Access Control Manager, as the access gate for the goAML launch portal. The Ministry's DNFBP instructions describe the first operational step as registering in SACM and obtaining a username.
On the live form, select Reporting Entity, enter the exact entity details, choose the supervisor and complete the authorised user's identity fields. Upload the requested PDF. Read the portal terms before accepting them.
The form also tells applicants to allow messages from the FIU's no-reply SACM and goAML addresses. Add those addresses to the institution's email controls before submission. A registration process can appear stalled when approval or activation mail is trapped by the spam gateway.
Save the submitted data, attachment hash, submission time and confirmation. Do not store credentials in the case file.
Step 5: activate secure access and complete the goAML profile
Once SACM access is approved, activate the secure login according to the current portal instructions. The Ministry page says the access sequence uses an authenticator-generated password after SACM registration.
The organisation profile in goAML should match the licensed entity. Add the MLRO and other users only within the approved role design. Confirm who can prepare, review, submit and manage users.
Run these checks before treating registration as complete.
- The organisation ID and entity name match the licence.
- The correct supervisor is associated with the registration.
- The primary MLRO and backup can log in independently.
- Filing rights match the authority matrix.
- FIU messages reach a monitored institutional mailbox.
- Former staff and test users have no active access.
- The entity can retrieve its registration details and record the completion date.
What should happen before an STR is filed?
The internal process should turn an alert into an evidence-based human decision. It should not create an extra approval chain that delays a report after the legal trigger is met.
- An alert becomes a case, the MLRO decides, an authorised user submits the report, and the entity preserves the receipt and filed version.
A useful sequence is:
- A frontline employee, monitoring control or investigator raises an internal alert.
- The case owner secures the relevant account, customer, transaction and ownership information.
- The investigator tests alternative explanations and records unresolved facts.
- The MLRO or authorised delegate decides whether reasonable grounds for suspicion exist.
- The preparer drafts the report and narrative in goAML.
- The authorised submitter checks the filing against the source evidence and sends it.
- The entity preserves the receipt, filed content, decision record and later FIU correspondence.
The system can collect evidence and draft the report. It should not turn a risk score into an automatic legal conclusion.
What evidence belongs in a filing-ready case?
The legal duty calls for a detailed report with available data about the transaction and parties. The exact fields depend on the report type and current goAML form, but the underlying case should normally contain:
- Customer and transaction evidence establish observed facts. Investigators explain inferences, draft the narrative, and route it to the MLRO.
- the reporting entity and responsible user;
- customer and beneficial-owner identifiers;
- account, wallet or relationship details relevant to the suspicion;
- transaction references, dates, currencies and amounts;
- originators, beneficiaries and counterparties;
- the alert, referral or event that started the review;
- the facts that created suspicion;
- expected activity and the observed departure from it;
- linked transactions, accounts or parties;
- documents and screening results relied on;
- actions already taken under policy and law;
- missing information or conflicting explanations; and
- the MLRO's decision, time and rationale.
Do not dump every available document into the report. Include what supports the suspicion and keep the full case record available for follow-up.
How should the STR narrative be written?
A useful STR narrative lets an FIU analyst understand the subject, conduct, timeline, money flow and reason for suspicion without reverse engineering the case.
Use a clear order.
- Identify the subject and relationship to the reporting entity.
- State the suspicious conduct in one or two sentences.
- Give the relevant chronology and money flow.
- Explain why the activity is inconsistent with the known profile or expected purpose.
- Name linked parties, accounts and transactions.
- State what the entity did and what remains unknown.
- Point to the attached or retained evidence.
Use facts rather than labels. "High risk" is not an explanation. State which transactions occurred, how they connected and why the known information did not explain them.
Separate observation from inference. For example, a newly opened company received transfers from several unrelated senders, then sent most of the funds to one overseas beneficiary within hours. That is an observation. The inference may be that the account is acting as a pass-through. Record both, and say what evidence supports the inference.
What must never happen during filing?
Do not alert the customer or another unauthorised person that an STR has been or may be filed. Federal Decree-Law No. 10 of 2025 prohibits direct or indirect disclosure that a report was submitted, an investigation is underway or information has been or will be provided to the FIU.
The SACM terms also require confidentiality around reports and information transmitted through the service.
Build the control into daily work.
- Use restricted case access.
- Keep customer communication neutral and approved.
- Do not place "STR" or "FIU report" in a customer-visible note.
- Limit email distribution.
- Record who viewed or exported the case.
- Train service, operations and relationship teams on escalation wording.
The same rule applies to automation. A customer-facing message must never reveal that an internal review or FIU report caused an action.
How do you submit and confirm the report?
The authorised user should select the current FIU report type, complete all mandatory fields, check the parties and transactions, attach the permitted evidence and submit through goAML. The UAE FIU portal is designed for reporting entities to register and file STRs or suspicious activity reports.
- Funds arrive from unrelated senders and move to an overseas beneficiary. The activity creates an alert, an agent prepares the case, and the MLRO decides whether an authorised user files.
Before the final click, compare the report with the approved case record.
- Are entity and subject identifiers correct?
- Do transaction totals match the listed transactions?
- Does the narrative match the chronology?
- Are facts separated from assumptions?
- Are names, account numbers and dates consistent?
- Does the report omit customer-facing or privileged material that should not be attached?
- Has the authorised human approved submission?
After submission, save the receipt or reference number, date, time, report type, submitter and exact filed version. Monitor the portal and institutional mailbox for requests or status messages. A successful upload is not the end of the reporting process.
Illustrative scenario: a trading company used as a pass-through
Illustrative scenario, not a customer result.
A UAE trading company receives transfers from unrelated overseas individuals and moves most of the funds to one overseas beneficiary within hours.
- Gather customer, ownership and transaction evidence.
- Separate observations from investigator inference.
- Prepare a proposed narrative.
- Have the MLRO decide whether reasonable grounds for suspicion exist.
- Submit through an authorised goAML user only if approved.
Illustrative scenario: a trading company used as a pass-through
Illustrative example, not a customer result. A UAE trading company opens an account for domestic wholesale activity. During the next month, it receives transfers from several unrelated overseas individuals. Most incoming funds leave within hours to one company in another jurisdiction. The payment descriptions do not match the invoices provided, and the customer gives different explanations to relationship management and compliance.
The monitoring system creates an alert. An investigator gathers account history, onboarding records, beneficial-owner information, counterparties, transfer details and the customer's explanations. The case shows the observed flows separately from the investigator's inference.
An AI agent may organise the transactions, identify linked parties, draft a chronology and prepare a proposed narrative. The MLRO reviews the evidence and decides whether reasonable grounds for suspicion exist. If the MLRO approves the filing, the authorised user submits through goAML. The system records the final text, receipt and later FIU requests. No agent makes or files the regulated decision independently.
Who owns each part of the reporting architecture?
| Component | Responsibility | Boundary |
|---|---|---|
| Monitoring and referrals | Identify activity that needs investigation. | An alert is not an STR decision. |
| Case workspace | Join customer, transaction, ownership and review evidence. | The workspace cannot decide legal suspicion. |
| Investigation support | Build chronology, links and unresolved questions. | Recommendations remain reviewable. |
| MLRO or delegate | Decide whether the reporting threshold is met. | The decision must follow the authority matrix. |
| goAML preparer | Populate the approved report accurately. | Cannot change the MLRO's rationale without review. |
| Authorised submitter | Submit and preserve the official receipt. | Must not use shared credentials. |
| Access administrator | Maintain users and roles. | Access management is separate from filing authority. |
Human control should be explicit. The MLRO can approve, reject or return a draft. Authorised staff can override an automated suggestion. The institution can pause the workflow or use a kill switch if an agent behaves outside its configured scope.
How FluxForce fits the reporting workflow
FluxForce's relevant solution is Regulatory Reporting (STR / SAR / CTR). The product fit is an AI-agent workflow that investigates the underlying alert, gathers the available evidence, prepares a filing-ready case and drafts reporting content for human review.
The company-level position is: AI agents that investigate AML, sanctions, fraud and KYC alerts and prepare the case. Your analyst makes the call, with evidence an examiner can replay. You decide how much each agent does on its own, and every one has a kill switch.
For goAML, Zara Trustwell can support the regulatory workflow and Arin Narrate can support the evidence trail. The customer configures what each agent may collect or draft and where it must stop for approval. The MLRO decides whether to file. An authorised human submits the report.
FluxForce does not provide legal advice, decide that suspicion exists, guarantee acceptance by the FIU or replace goAML. It must fit the institution's data, supervisor, policies, authority matrix and portal controls. The goAML template glossary, UAE jurisdiction guide and SAR filing deadline calculator are useful review points.
A goAML registration and filing checklist
Registration
- Confirm the legal entity, licence and supervisory body.
- Check whether an existing goAML registration already exists.
- Appoint the MLRO and backup under a written authority matrix.
- Prepare the authorisation and identity documents required for the applicant.
- Use an institutional email and monitored mobile number.
- Complete SACM pre-registration under the correct supervisor.
- Activate secure access and test independent logins.
- Restrict user administration and filing permissions.
Filing
- Record the internal alert and investigation start time.
- Preserve the customer, ownership and transaction evidence.
- Separate observed facts from investigator inference.
- Let the MLRO decide whether the legal reporting trigger is met.
- Draft a chronological narrative tied to listed transactions.
- Run an independent data and identity check before submission.
- Submit through a named authorised user.
- Save the receipt and exact filed version.
- Monitor FIU messages and answer requests through the controlled case.
- Keep customer communication free of tipping-off language.
Which metrics show whether the process works?
- Metrics trigger sampled review. Control gaps get a named owner, approved remediation and a retest.
| Metric | Definition | Guardrail |
|---|---|---|
| Registration completion time | Time from approved application pack to working access. | Separate supervisor delay from internal delay. |
| Access exceptions | Failed logins, orphaned users and excess permissions. | Do not trade access security for speed. |
| Alert-to-MLRO time | Time from internal escalation to a decision-ready case. | Fast routing cannot replace investigation. |
| Narrative rework rate | Reports returned internally for factual or structural correction. | A low rate matters only if review is real. |
| Filing data accuracy | Share of checked fields matching the case evidence. | Filled fields are not proof of correct fields. |
| Post-filing response time | Time to answer a valid FIU request. | Restrict responses to authorised channels. |
| Evidence completeness | Required case items present at closure. | Measure usefulness, not document count. |
| Human overrides | Agent drafts changed, rejected or stopped by authorised users. | Review the reasons instead of treating every override as failure. |
Key takeaways
- The current federal framework is Federal Decree-Law No. 10 of 2025 and Cabinet Resolution No. 134 of 2025.
- Registration starts with the correct legal entity and supervisor, then moves through SACM to goAML access.
- The reporting trigger is reasonable grounds for suspicion, followed by direct reporting to the FIU without delay.
- The MLRO owns the filing decision. Systems and agents can prepare the case and draft the narrative.
- Tipping off is prohibited. Confidentiality belongs in access, communication and workflow design.
Who owns each part of the reporting architecture?
Monitoring, investigation support and goAML preparation support the filing. They do not replace the MLRO or authorised submitter.
| Component | Responsibility | Boundary |
|---|---|---|
| Monitoring and referrals | Identify activity that needs investigation. | An alert is not an STR decision. |
| Case workspace | Join customer, transaction, ownership and review evidence. | The workspace cannot decide legal suspicion. |
| MLRO or delegate | Decide whether the reporting threshold is met. | The decision follows the approved authority matrix. |
| Authorised submitter | Submit and preserve the official receipt. | Shared credentials are prohibited. |
| Access administrator | Maintain users and roles. | Access administration does not grant filing authority. |
The MLRO can approve, reject or return a draft. Authorised staff can override an agent suggestion, pause the workflow or use the kill switch.
Which sources govern this workflow?
Current federal reporting trigger, direct reporting and confidentiality boundary.
Federal law; entity-specific applicability requires UAE legal review.
2026-10-04
Current executive regulation and compliance-officer governance.
Federal executive regulation; supervisor-specific requirements may add detail.
2026-10-04
Current secure launch and registration route for reporting entities.
Operational portal guidance, not legal interpretation.
2026-10-04
DNFBP categories, documents and registration sequence.
Operational guidance; older legal citations require current-law caution.
2026-10-04
How FluxForce fits the reporting workflow
FluxForce Regulatory Reporting (STR / SAR / CTR) uses AI-agent workflows to investigate the underlying alert, gather available evidence, prepare a filing-ready case and draft reporting content for human review.
Your analyst makes the call. The customer configures each agent's autonomy and retains a kill switch. The MLRO decides whether to file, and an authorised human submits through goAML.
Review the goAML template glossaryFluxForce does not provide legal advice, decide that suspicion exists, guarantee FIU acceptance or replace goAML.
A goAML registration and filing checklist
- Confirm the legal entity and supervisor.
- Appoint the MLRO and backup.
- Prepare the authorised registration pack.
- Complete SACM pre-registration.
- Test roles and secure access.
- Preserve source evidence.
- Route the filing decision to the MLRO.
- Submit through a named authorised user.
- Save the receipt and exact filed version.
- Monitor FIU follow-up.
| Metric | Definition | Decision guardrail |
|---|---|---|
| Registration completion time | Time from approved application pack to working access. | Separate supervisor delay from internal delay. |
| Alert-to-MLRO time | Time from escalation to a decision-ready case. | Fast routing cannot replace investigation. |
| Filing data accuracy | Share of checked fields matching case evidence. | Filled fields are not proof of correct fields. |
| Evidence completeness | Required case items present at closure. | Measure usefulness, not document count. |
- Use the 2025 federal AML law and executive regulation as the current legal framework.
- Start registration with the licensed entity and correct supervisor.
- Route the filing decision to the MLRO.
- Keep customer communication free of tipping-off language.
- Preserve the receipt, exact filed version and later FIU correspondence.
Conclusion
Pick a recent internal investigation and replay it from alert to filing decision. Check whether the entity can identify who knew what, when they knew it, why the MLRO decided and which version was filed. Fix the breaks before the next urgent case arrives.
Request a goAML STR workflow review

Frequently Asked Questions
goAML is the system used by the UAE FIU for reporting entities to register and submit STRs and suspicious activity reports. Access begins through the FIU's SACM launch portal.
Financial institutions and DNFBPs that are reporting entities should follow the route set by their supervisor. The live SACM form includes several UAE supervisors, so the correct choice depends on the entity's licence and regulated activity.
The Ministry's DNFBP page lists an authorisation letter, the applicant's passport, residence visa and Emirates ID, plus the company's trade licence. Other supervisors may require different or extra evidence, so confirm the current pack before submission.
A financial institution or DNFBP must report directly and without delay when it has reasonable grounds to suspect that funds are proceeds, linked to crime or intended for criminal use. The MLRO should apply that legal test to the available facts.
No. The federal law prohibits direct or indirect disclosure that a report was submitted, an investigation is underway or information has been or will be given to the FIU.
No. An AI agent can collect evidence, build a chronology and draft reporting content within customer-configured limits. The MLRO decides whether to file, and an authorised person submits through goAML.
Save the receipt or reference, submission time, report type, submitter, exact filed version, supporting case evidence and later FIU correspondence. Keep access restricted and preserve the decision trail.
About the author
Sahil Kataria is the Founder and CEO of FluxForce. His FluxForce author profile is the controlled source for public attribution. Final author and biography approval remain pending for this draft.
Related reading
- goAML template glossary, for report preparation terminology
- UAE financial-crime jurisdiction guide, for local supervisory context
- SAR filing deadline calculator, for internal deadline planning
About the author

Sahil Kataria
Founder and CEO of FluxForce
Sahil Kataria is the Founder and CEO of FluxForce. His public FluxForce profile places his work at the intersection of financial security, AI and compliance in regulated industries.
The same profile discusses identity verification, secure payments and AML/KYC requirements. That published subject focus is relevant to this guide, but legacy QServices references and unsupported biography or deployment claims are excluded; it does not constitute independent credential verification or final author approval.
View Sahil Kataria's author profile →Related articles
Report preparation terminology.
Local supervisory context.
Internal deadline planning.





Share this article