How to Integrate goAML with AML Screening and Case Management

An alert is not a filing. Between the two sit investigation, evidence, suspicion assessment, an authorised reporting decision, report preparation and a country-specific technical handoff. A reliable goAML integration keeps those stages connected without pretending they are the same control.

The practical test is simple: can your team trace one signal from detection through investigation and decision to the information handed to the FIU, then retain the resulting submission record without rebuilding the story across disconnected systems?

Where goAML fits in the AML operating model

UNODC describes goAML as a platform supporting financial intelligence units (FIUs) in collecting, analysing and disseminating financial information related to suspicious activity.¹ Its product overview includes a reporting-entity portal, validation functionality and interoperability with other systems.²

That describes the global product context, not one universal reporting process. The FIU operating a national implementation determines the available report types, fields, submission methods, permissions and procedures. Other jurisdictions use different reporting systems altogether. FATF sets international standards, while countries implement them through their own legal, administrative and operational frameworks.³

For a reporting entity, goAML is therefore downstream of the wider AML compliance operating model:

Business or control signal → alert → case and investigation → suspicion or reportability assessment → authorised report decision → report preparation → FIU-specific transmission → FIU response or acknowledgement → retained record

The sequence can begin with transaction monitoring, transaction screening, ongoing monitoring, a sanctions or PEP alert, an internal referral or another source. None of those inputs automatically establishes suspicion or creates a universal duty to file.

Do not collapse detection, decision and filing

The central design requirement is to give each control state its own owner, evidence and outcome.

This separation prevents an automated alert from becoming an automated suspicion decision. It also prevents a technically valid file from being presented as an approved or accepted report. The MLRO reporting decision and evidence remain a human-governed responsibility under the applicable framework and the organisation's authority model.

Start with a controlled case, not a report form

Before designing field mappings, make the upstream investigation reproducible. The case should connect the alert to the correct customer, account, transaction and related parties; show who owns the work; retain notes, attachments and source material; and provide a chronology of requests, findings, reviews and decisions.

Where sanctions screening produces the signal, complete the identity and applicable-regime analysis before treating the case as a suspicious-activity reporting matter. The guide to documenting a sanctions alert investigation covers that earlier control in detail.

A useful reporting-readiness record may include:

• the original signal, source data and relevant configuration or rule reference;
• customer, CDD, ownership and relationship context available at the time;
• relevant persons, entities, accounts and transactions;
• supporting and contradictory evidence, attachments and previous related cases;
• analyst findings, unresolved questions and requests for further information;
• the suspicion or reportability assessment, decision authority and approval history; and
• internal references that can link the prepared report and later FIU response back to the case.

This is an internal control model, not a universal goAML field list. The destination report type and FIU technical package determine which data must be transformed or added for submission.

Put an authorised decision gate before the reporting handoff

An investigator can recommend escalation without having authority to submit an external report. The system should make that distinction visible.

A controlled approval gate identifies who can assess the case, who is authorised to make the reporting decision, what evidence was available, what was decided and whether material changes require further review. Software can route the work, enforce internal states and preserve the record. It should not autonomously decide legal suspicion, approve a report for the MLRO or infer that every alert must be filed.

The report-preparation stage begins only after the appropriate decision under the organisation's policy and applicable law. If information changes during preparation, the workflow should identify whether the decision or approval needs to be revisited rather than silently changing the basis of the filing.

Map case data to the FIU's report structure

The mapping layer converts controlled case information into the structure required for a specific FIU, report type and implementation version. That can involve persons and entities, accounts, transactions, indicators, narrative, attachments and reporting-entity identifiers.

Do not begin with the assumption that one goAML XML model works everywhere. Malta's FIAU publishes implementation material including an XSD, samples and an offline XML validator.⁴ Switzerland's MROS publishes Switzerland-specific XML specifications and manuals.⁵ New Zealand's FIU documents XML upload for prescribed transaction reports (PTRs), alongside other submission options.⁶

For each destination, establish:

1. Which FIU and reporting population are in scope?
2. Which report types are permitted or required for the use case?
3. Which fields, values, attachments and narrative rules apply?
4. What current schema, technical package or portal form governs the handoff?
5. Which internal data is authoritative, and where must an authorised user add filing-specific information?
6. How will mapping changes be tested, approved and version-controlled?

These questions matter even when the final submission is manual. A structured reporting pack can reduce re-keying and keep the portal entry aligned with the approved case, but an authorised user still needs to follow the FIU's current process.

Choose the integration model the FIU actually supports

“goAML integration” does not necessarily mean an API. Select the operating model only after verifying the current FIU interface, report type and access rules.

Country-specific examples demonstrate the variation. For New Zealand PTRs, the FIU documents web forms, XML upload and B2B automated submission, with testing required before approved automated production use.⁶ South Africa's FIC documents individual, batch and system-to-system reporting in specific reporting contexts.⁷ These examples do not establish a public or reporting-entity API for every goAML implementation.

The same architecture should accommodate non-goAML destinations. Spain's SEPBLAC reporting environment, for example, reinforces why an organisation should design around FIU-specific handoffs rather than hard-code a universal goAML workflow.

Validate the handoff without confusing technical and legal tests

Validation should happen before an approved report leaves the controlled workflow. Depending on the FIU method, checks can cover required fields, allowed values, internal references, attachment rules, file structure, the applicable XSD and other published business rules.

Three questions must stay separate:

1. Is the file or form technically valid? It conforms to the applicable structure and validation rules.
2. Was it received or accepted for processing? The destination produced the response defined by that FIU workflow.
3. Was the reporting judgment legally and factually adequate? The authorised team applied the relevant law and facts.

Passing the first test does not answer the third. New Zealand's FIU expressly states, in its PTR testing guidance, that successful file review does not confirm regulatory or legislative compliance.⁶ Likewise, no internal validation should guarantee FIU acceptance.

Design rejection, correction and reconciliation into the workflow

The integration is incomplete if it stops when a file is generated or a user clicks submit. The originating case needs a controlled way to capture the destination response appropriate to the chosen method.

Possible internal states include prepared, approved for handoff, handed off, awaiting response, received, rejected, correction required and reconciled. These are useful operating states, not a claim that every FIU exposes the same status model.

Malta's FIAU provides a country-specific example: it documents submission feedback and requires rejected reports to be corrected in line with the rejection message and resubmitted.⁴ An internal workflow supporting that process should retain the rejected artifact and reason, route the issue to an owner, identify whether reapproval is required, and link the corrected submission to the original case. The precise correction or supplementary-report mechanism must come from the FIU's current instructions.

For an outage or failed handoff, maintain an owner, visible unresolved state and documented fallback procedure. Do not assume that a technical failure extends a legal deadline. That question belongs to the applicable law and FIU guidance.

Retain a reporting audit trail

The reporting record should allow an authorised reviewer to reconstruct what was known, decided, prepared and handed off. Depending on the integration, retain or link:

• the source alert and investigation evidence;
• the reporting assessment, decision, approver and timestamps;
• the approved report artifact or portal-entry record;
• the mapping, export or schema version used where applicable;
• the submission user or system and transmission attempt;
• the FIU reference, acknowledgement or rejection message where available; and
• corrections, supplementary information and later enquiries.

This list describes a defensible internal audit trail, not a globally mandated goAML record format or retention period. Retain records according to the law and policy that apply to the organisation. See Audit Trail & Evidence for the wider evidence-control model.

Govern change after go-live

FIU forms, schemas, values, permissions and instructions can change. Treat them as governed dependencies rather than one-off implementation details.

A practical change process should identify the FIU source owner, detect new technical material, compare it with the current mapping, run controlled tests, obtain business and compliance approval, deploy the change through the normal release process and reconcile the first production handoffs. Use synthetic or appropriately protected test information and follow the destination's rules: New Zealand tells reporting entities not to use identifiable real data in its test environment, and Switzerland similarly warns against real customer data in its demo system.⁶⁵

Fallback procedures also need testing. A technically elegant connection is not an operational control if the team does not know who owns a failed submission or how approved information reaches the FIU when the normal route is unavailable.

What changes by country and FIU

Practical goAML integration checklist

• Identify the governing FIU, reporting entity, jurisdiction and report types.
• Name the owners of investigation, suspicion assessment, report approval, preparation, handoff and reconciliation.
• Keep the alert, investigation and reporting decision as distinct case states.
• Define the evidence that must be complete before report preparation begins.
• Obtain the FIU's current forms, schema, validation rules, interface guidance and access requirements.
• Map authoritative case data to the destination without overwriting the original evidence.
• Choose manual, upload, batch, system-to-system or hybrid handling based on confirmed FIU support.
• Test technical validation and business rules without presenting them as proof of legal compliance.
• Preserve an authorised human decision gate and control who may transmit the report.
• Define how acknowledgements, rejections, corrections, outages and unresolved submissions return to the case.
• Retain the relevant artifacts, decisions, timestamps and FIU responses under applicable retention rules.
• Assign ownership for FIU technical changes, regression testing and fallback procedures.

Frequently asked questions

Is there a universal goAML API?

No universal reporting-entity API should be assumed. UNODC describes interoperability at the product level, while individual FIUs expose different submission methods. Some FIUs document automated or system-to-system reporting, including New Zealand for PTRs and South Africa in relevant reporting contexts. Confirm the interface, authentication, report types and approval process with the relevant FIU.

Is goAML XML the same in every country?

No. Multiple FIUs use XML, but the applicable schema, report types, mandatory values and technical rules can be implementation-specific and versioned. Use the current package published or approved by the destination FIU.

Can AML software decide whether to file automatically?

Software can detect signals, assemble evidence, route review and prepare structured information. It should not autonomously make the legal suspicion assessment or authorised reporting decision. Those depend on the facts, applicable law and the organisation's governance.

Does goAML perform the reporting entity's transaction monitoring?

Do not treat it as a substitute for the reporting entity's controls. UNODC positions goAML around FIU collection, analysis and dissemination. Screening or transaction-monitoring systems can create upstream signals that may later enter a controlled reporting workflow.

Does valid XML guarantee acceptance?

No. Schema validity, technical receipt and substantive legal adequacy are different questions. A file can pass structural validation and still require correction or further review under the FIU's rules.

What should happen when a report is rejected?

Follow the relevant FIU procedure. Internally, preserve the rejection message and artifact, assign correction, determine whether the change needs renewed approval, validate the corrected output and link the later handoff to the original case. Do not assume one universal correction or resubmission process.

Connect AML cases to the reporting workflow

Checklynx helps teams connect screening and monitoring handoffs with controlled cases, evidence, notes, attachments, decisions and timelines. Structured preparation, reporting packs, exports and AML integrations and system handoffs can support the path into goAML or another reporting system while the customer's authorised compliance function retains suspicion assessment, policy interpretation, report approval and filing responsibility.

The integration design should match the FIU interface actually available to the organisation. Whether that involves portal preparation, a structured export or another supported route is a question to confirm for each implementation—not a universal product promise.