Blog Image

goAML STR Returned for Correction: What Does It Mean?

Seeing “Returned for Correction” after submitting a Suspicious Transaction Report (STR) on goAML can be confusing. If you are a Compliance Officer, MLRO or business owner in the UAE, you may immediately wonder: Was the STR rejected? Do I need to file a new report? Did I make a serious mistake?

Not necessarily.

When an STR is returned for correction, it generally means that something in the submitted report needs to be corrected, clarified or completed before it can move forward. The important thing is to understand what the system or relevant authority is asking you to fix and respond within the applicable timeframe.

An STR being returned does not automatically mean that the underlying suspicious activity has been cleared.

In this article, we explain what “Returned for Correction” means in goAML, the common reasons an STR may be sent back, what you should do next and how to avoid similar issues in future.

What Does “Returned for Correction” Mean in goAML?

A goAML STR can be returned when the submitted report requires additional information, corrections or clarification.

The goAML platform provides a Message Board through which reporting entities can receive communications relating to submitted reports, including acceptance, rejection and requests for additional information.

So, when your STR is returned, the first thing you should do is check the message associated with the report.

Don't immediately create another STR.

The correction message should help you understand what needs attention.

Depending on the issue, you may need to correct:

  • Customer information
  • Transaction details
  • Reporting reasons
  • Suspicion narrative
  • Parties involved
  • Supporting information
  • Action taken
  • Other required fields

The exact correction required will depend on the report and the reason it was returned.

Is a Returned STR the Same as a Rejected STR?

Not necessarily.

The two statuses can be confused because both indicate that the submitted report has not moved forward as expected.

However, businesses should always look at the specific status and instructions shown in their goAML account rather than assuming that every returned report follows the same process.

In practical terms, think of it this way:

Returned for Correction:

Something needs to be reviewed or corrected.

Rejected:

The submitted report has not been accepted and needs to follow the applicable correction/resubmission process.

The important point is that neither status should be treated casually.

If the underlying activity remains suspicious, correcting the report does not remove the underlying AML concern.

Why Would a goAML STR Be Returned for Correction?

There isn't one single reason why an STR may be returned.

In many cases, the problem comes down to incomplete information, inconsistent data or a narrative that doesn't clearly explain the suspicion.

Here are some of the common issues businesses should look out for.

1. Missing Mandatory Information

An STR needs to contain the information required for the particular report type.

Depending on the circumstances, this may include:

  • Reporting entity details
  • Internal STR/SAR reference
  • Customer information
  • Transaction information
  • Parties involved
  • Reason for reporting
  • Description of the suspicion
  • Action taken by the business

For example, the CBUAE's goAML reporting guidance identifies the report type, internal STR/SAR number, description or summary of the suspicion, action taken and location of the incident among relevant report information.

Before submitting an STR, don't just check whether the portal accepts the form.

Review whether the information actually makes sense and is complete.

2. The Suspicion Narrative Is Too Vague

This is one of the most important areas of an STR.

A report should explain why the business believes the activity is suspicious.

A sentence like:

“The customer's transaction is suspicious.”

doesn't provide enough context.

Instead, the narrative should explain the relevant facts.

For example:

  • What did the customer do?
  • When did the activity happen?
  • Which transactions are involved?
  • Why is the activity unusual?
  • How does it differ from the customer's normal profile?
  • What information did the customer provide?
  • What checks did the business perform?
  • Why did the concern remain after the review?
  • What action did the business take?

The UAE FIU's goAML reporting guidance expects the report to provide information explaining the suspicion and reason for reporting.

The goal isn't to write the longest possible narrative.

It's to make the situation easy to understand.

3. Incorrect Report Type

Another issue can be selecting a report type that doesn't match the circumstances.

The goAML framework distinguishes between different reporting types, including STRs and SARs.

For example, suspicious transactions and suspicious activity where no transaction has actually taken place can require different treatment depending on the circumstances and applicable regulatory guidance.

Before resubmitting, ask:

“Am I using the correct report type for what actually happened?”

Don't select a report type simply because it seems close enough.

4. Wrong Reporting Reason or Indicator

The reporting reason should support the facts described in your STR.

For example, if the narrative talks about unexplained third-party payments but the selected reason relates to an unrelated risk indicator, the report becomes inconsistent.

The selected indicator and the narrative should tell the same story.

Before resubmitting, compare:

Reporting reason → Narrative → Transaction → Investigation findings

All four should make sense together.

5. Transaction Details Are Incorrect

Transaction information needs to be checked carefully.

A report could be returned if information such as the following is incorrect or inconsistent:

  • Transaction date
  • Transaction amount
  • Currency
  • Account number
  • Sender
  • Beneficiary
  • Financial institution
  • Transaction type

This is why it is a good idea to compare the STR against the original transaction records before submitting it again.

Don't rely only on memory.

6. Customer Information Is Incomplete

The customer details in the STR should be consistent with the KYC information held by the business.

Check details such as:

  • Full name
  • Date of birth
  • Nationality
  • Identification information
  • Address
  • Company name
  • Registration details
  • Customer type

If the customer is a company, review the relevant ownership and control information as well.

7. Beneficial Ownership Information Is Missing

A suspicious transaction involving a company may require more than the company's trade name.

Businesses should understand who ultimately owns or controls the customer where required.

For example, a company may receive funds from another business, but the investigation identifies an individual who ultimately controls both entities.

If relevant beneficial ownership information is missing from the report, the STR may not provide a complete picture of the activity.

This is why UBO checks should form part of the wider AML investigation, rather than being treated as a separate administrative exercise.

8. The Narrative and Transaction Data Don't Match

Imagine the narrative says:

“The customer received AED 250,000 on 15 August.”

But the transaction section shows:

AED 25,000 on 18 August.

Even if this is a simple typing mistake, it creates uncertainty about what the business is actually reporting.

Before resubmitting, read the entire report from beginning to end.

Check that:

  • Dates match
  • Amounts match
  • Names match
  • Transaction references match
  • Parties match
  • The narrative matches the transaction information

Small inconsistencies can make an otherwise good STR difficult to understand.

9. The Action Taken Is Not Clearly Explained

Your STR should accurately describe what your business did after identifying the concern.

Depending on the situation, this could involve:

  • Reviewing the customer's transaction history
  • Requesting additional documents
  • Conducting enhanced due diligence
  • Escalating the case internally
  • Increasing monitoring
  • Restricting activity where legally appropriate

The report should not claim that an action was taken if it wasn't.

Keep the explanation factual.

10. Supporting Information Is Incomplete

Sometimes the issue isn't the main report itself but the information supporting it.

Depending on the circumstances, relevant supporting information could include:

  • Customer documents
  • Transaction records
  • Contracts
  • Invoices
  • Bank records
  • Correspondence
  • Internal investigation notes

Don't upload documents simply to make the report look more complete.

The information should be relevant to the suspicion and useful for understanding the case.

What Should You Do When Your STR Is Returned?

If you see “Returned for Correction,” don't panic.

Follow a structured process.

Step 1: Read the goAML Message

Open the returned report and carefully read the message or correction request.

If multiple issues are identified, write them down.

Step 2: Review Your Internal Case File

Go back to the investigation that led to the STR.

Review:

  • KYC documents
  • Customer risk assessment
  • Transaction history
  • Beneficial ownership
  • Screening results
  • Supporting documents
  • Internal investigation notes

This helps ensure that the corrected report is based on the actual evidence.

Step 3: Identify What Needs to Be Corrected

Separate the issues into categories.

For example:

Data error:

Wrong transaction amount.

Missing information:

Beneficial owner not included.

Narrative issue:

Reason for suspicion isn't sufficiently explained.

Reporting issue:

Wrong reporting reason selected.

This makes the correction process much easier.

Step 4: Correct the Report

Update the relevant information in goAML.

Don't change facts just because you think another version might be accepted more easily.

Correct the report based on the evidence.

Step 5: Strengthen the Narrative

Read the narrative as if you were seeing the case for the first time.

Can you understand:

  • Who the customer is?
  • What happened?
  • What transactions are involved?
  • Why the activity is unusual?
  • What checks were performed?
  • Why suspicion remains?

If not, improve the explanation.

Step 6: Perform a Final Review

Before resubmitting, check the entire report again.

Don't focus only on the field mentioned in the correction request.

A correction is a good opportunity to check the whole report for inconsistencies.

Step 7: Resubmit Within the Applicable Timeframe

Once everything has been corrected, follow the applicable goAML workflow for resubmission.

Don't leave the report sitting in your account until the last minute.

Do You Need to Submit a New STR?

Usually, don't create a duplicate report simply because an existing STR was returned for correction.

First determine whether the existing report can be corrected and resubmitted through the available goAML workflow.

Creating multiple reports for the same matter without a clear reason can create unnecessary duplication.

If the system or relevant authority specifically instructs you to create a new report, follow those instructions.

Does a Returned STR Mean the Customer Is Cleared?

No.

This is one of the biggest misconceptions.

A returned STR relates to the submitted report.

It does not automatically mean:

  • The customer is cleared
  • The transaction is legitimate
  • The investigation is closed
  • The business no longer has AML concerns

If the facts continue to provide reasonable grounds for suspicion, the business needs to consider its reporting obligations independently.

Under the UAE AML framework, covered entities are required to report suspicious transactions or activities to the FIU without delay when the applicable reporting threshold is met.

What If the STR Is Returned Again?

If the corrected STR is returned again, don't simply keep making random changes.

Look for the underlying problem.

Ask:

  • Is the report type correct?
  • Is the reporting reason appropriate?
  • Is the narrative clear?
  • Are the transactions correctly identified?
  • Are the customer details accurate?
  • Is the UBO information complete?
  • Are supporting documents relevant?
  • Does the action taken match what actually happened?

Repeated corrections can indicate that the internal STR preparation process needs improvement.

How to Write a Better STR Narrative

A simple structure can help your Compliance Officer prepare clearer reports.

1. Customer Background

Briefly explain who the customer is and their normal business/activity.

2. Trigger

Explain what initially raised the concern.

3. Transaction or Activity

Describe the relevant transactions, dates, amounts and parties.

4. Investigation

Explain what the business checked.

5. Findings

Describe what was discovered.

6. Reason for Suspicion

Clearly explain why the activity remains suspicious.

7. Action Taken

Explain what the business did.

For example:

“The customer is a UAE-based trading company that normally conducts domestic supplier payments. During July and August, the customer received multiple transfers from unrelated third parties that were inconsistent with its stated business activity. The customer was asked to provide documentation explaining the source and commercial purpose of the funds but was unable to provide sufficient supporting evidence. A review of the transaction history identified repeated incoming and outgoing transfers involving parties with no clear business relationship. The matter was escalated to the Compliance Officer, who determined that the circumstances created reasonable grounds for suspicion.”

This is much more useful than simply writing:

“Customer transactions are suspicious.”

How Can Businesses Avoid STR Corrections?

The best way to deal with returned STRs is to reduce preventable errors before submission.

Create an STR Review Checklist

Use a standard checklist for every report.

Review the Customer Profile

Make sure the transaction makes sense—or clearly explain why it doesn't—in the context of the customer's known activity.

Verify Every Number

Check transaction amounts, dates and references against source records.

Review the UBO

For corporate customers, confirm that relevant beneficial ownership information is captured.

Match the Indicator to the Narrative

The reporting reason should actually relate to the suspicion described.

Use a Second-Level Review

Where practical, have another qualified member of the compliance team review the STR before submission.

Keep Supporting Documents Organised

A well-organised investigation file makes STR preparation much easier.

goAML STR Correction Checklist

Before resubmitting a returned STR, ask:

  •  Have we read the complete correction message?
  •  Have all requested corrections been addressed?
  •  Is the correct report type selected?
  •  Is the internal reference number correct?
  •  Is the reporting reason appropriate?
  •  Is the customer information accurate?
  •  Is beneficial ownership information complete?
  •  Are all relevant parties included?
  •  Are transaction dates correct?
  •  Are transaction amounts correct?
  •  Does the narrative clearly explain the suspicion?
  •  Does the narrative match the transaction data?
  •  Is the action taken accurately described?
  •  Are relevant supporting documents included?
  •  Has the entire report been reviewed?
  •  Is the report being resubmitted within the applicable timeframe?

Frequently Asked Questions

What does “Returned for Correction” mean in goAML UAE?

It generally means that the submitted STR requires correction, clarification or additional information before it can proceed through the reporting process.

Is a returned STR the same as a rejected STR?

Not necessarily. Always check the exact status and message shown in your goAML account and follow the instructions provided for that report.

Do I need to create a new STR?

Not automatically. If the existing report can be corrected and resubmitted, use the applicable correction process rather than creating an unnecessary duplicate.

Does a returned STR mean my suspicion was wrong?

No. A returned report does not automatically mean that the underlying suspicious activity has been cleared. You should continue to follow your AML investigation and reporting procedures.

What are common reasons for STR corrections?

Common issues include missing information, incorrect customer or transaction details, weak narratives, incorrect reporting reasons, wrong report types and inconsistencies between the narrative and transaction information.

What should I do if I don't understand the correction request?

Review the message carefully and check the applicable goAML guidance. For technical issues, contact the appropriate goAML support channel or relevant Supervisory Authority.

Can an STR be corrected after submission?

The available correction and resubmission options depend on the report status and goAML workflow. Follow the instructions displayed for the specific report.

Final Thoughts

A “Returned for Correction” message on goAML can be frustrating, but it doesn't have to become a major compliance problem.

The most important thing is to avoid treating it as a simple technical error.

Go back to the original investigation, understand what needs to be corrected and make sure the revised report accurately reflects the facts.

Check the customer information. Verify the transactions. Review the beneficial ownership details. Make sure the reporting reason matches the narrative. Most importantly, explain why the activity is suspicious in a clear and factual way.

And remember: correcting an STR does not mean changing the underlying facts to make the report acceptable.

The purpose of the correction is to make the report more accurate, complete and useful.

A strong internal review process can also reduce repeated corrections. When Compliance Officers use a consistent STR checklist and review the report before submission, many avoidable errors can be caught before the report reaches the correction stage.

If your goAML STR is returned for correction, don't start over blindly. Understand the issue, correct the report carefully and make sure the final submission tells the complete story.