Investigations and reporting

This is where flagged activity becomes an owned, evidence-backed decision. Events that score high raise alerts; your team opens an investigation, assigns an owner, reviews the evidence and records an outcome. Where activity is reportable, the investigation can produce a SAR or STR. Every action is audited server-side.

Alert or investigation?

An alert is a signal that needs triage. It shows what happened, why Myaza raised it and the rules or screening evidence involved.

An investigation is the casework record. Use it when the alert needs an accountable owner, more evidence, remediation, escalation or a formal outcome. This separation keeps the alert queue fast without losing the deeper audit trail required for material decisions.

Alerts

An alert is opened automatically when an event scores at or above your review threshold. Review alerts under Compliance → Alerts (alerts:read).

The list shows each alert's entity, decision, risk score, status, and how many investigations it belongs to.

Alerts appear here when monitoring flags an event for review or block.

Opening and assigning an investigation

Open an alert to review its decision evidence. If more work is needed, choose an investigator from your organisation and select Open investigation. You can also select multiple alerts from one entity and open a grouped investigation. All linked alerts must belong to the same entity so the investigation remains scoped to one customer.

Investigation workspace

The investigation workspace puts the decision controls first:

1. State shows where the investigation is in its lifecycle.
2. Why summarises the strongest reasons that raised the linked alerts.
3. Evidence keeps rule explanations, linked records and uploaded attachments together.
4. Owner assigns accountability to a member of your organisation.
5. Next action starts review, escalates, records an outcome, closes or reopens the investigation.

Resolving and closing are separate. Resolve records the evidence-backed outcome; close completes the operational work. The rationale, actor, timestamps and later reopening remain in the immutable timeline.

Open an investigation from the Alerts view when the evidence needs an owner or outcome.

Server-side SDK

The public SDK calls this resource investigations:

const investigation = await myaza.investigations.retrieve(investigationId);
const evidence = await myaza.investigations.evidence.list(investigationId);
const timeline = await myaza.investigations.timeline(investigationId);

The canonical HTTP paths are /api/v1/investigations. The deprecated /api/v1/cases paths and myaza.cases SDK resource remain available for existing integrations; new integrations should use myaza.investigations and the primary Investigation SDK types.

SARs & STRs

When an investigation is reportable, draft a regulatory filing from it. The existing permission key for these actions is cases:manage.

The lifecycle:

1. Draft: choose SAR or STR and a reason. The report is generated server-side in goAML format.
2. Review & export: inspect the goAML payload on the SAR detail view and export it as XML for submission to your FIU/regulator.
3. File: record the external reference and file path; the SAR moves to FILED.
4. Cancel: a DRAFT can be cancelled if it's no longer needed.

Audit

Every investigation and SAR write (open, assign, add evidence, transition, resolve, close, reopen, draft, file, cancel) is recorded in your organisation's audit log (Dashboard → Audit logs), with the actor and timestamp.

Related

• Event monitoring: how alerts get raised.
• Monitoring rules: the thresholds that decide REVIEW vs BLOCK.
• Compliance overview: the end-to-end lifecycle.