SAR filing (goAML)

A SAR (Suspicious Activity Report) is a regulator-facing report you file with PPATK when a transaction or customer pattern suggests money laundering, terrorism financing, or other reportable conduct.

Quantum Elixir generates the goAML XML envelope PPATK requires. You forward the XML to PPATK through your established channel (the PPATK goAML web portal or your direct connector).

Workflow

1. Maker drafts SAR        ← dashboard form (heavy UX, not API)
2. Maker submits draft     ← POST /api/sar-filings/{id}/submit (draft → pending_review)
3. MLRO reviews + signs    ← dashboard or POST /api/sar-filings/{id}/approve
4. MLRO submits to PPATK   ← POST /api/sar-filings/{id}/submit again (pending_review → submitted)
                              returns the goAML XML
5. You forward XML to PPATK
6. PPATK acknowledges      ← POST /api/sar-filings/{id}/acknowledge with ack receipt

Steps 1 and 3 are dashboard-heavy (form fields per PPATK SAR template). The API endpoints documented here cover the programmable state transitions.

Prerequisite: PPATK rentity ID

Before your first SAR can be submitted, your organization needs a PPATK reporting entity ID (Bahasa: rentity) configured. This is the identifier PPATK assigned to your bank / fintech / payment processor when you registered as a reporting entity under UU TPPU 8/2010.

Set it from Dashboard → Settings → Compliance → PPATK rentity ID, or via API:

{ "ppatkRentityId": "0012345678" }

The rentity ID is rendered into the <rentity> element of every goAML XML envelope you generate. Submission will fail with HTTP 422 ppatk_rentity_id_missing if it's not set.

SAR object

{
  "id": "sar_01HXY...",
  "caseId": "cas_01HXY...",
  "filingType": "STR | CTR | XSR",
  "typology": "structuring | trade_based_ml | terrorism_financing | ...",
  "status": "draft | pending_review | submitted | acknowledged | amended",
  "filedById": "usr_drafter_...",
  "submittedById": "usr_mlro_...",
  "submittedAt": "...",
  "acknowledgedAt": null,
  "ppatkReferenceNo": null,
  "xml": "(only on submit response)",
  "createdAt": "..."
}

List + read

Filters: caseId, customerId, status (draft · pending_review · submitted · acknowledged · amended), from, to (ISO-8601). Paginated (default 50, max 200).

curl "https://sandbox.quantumelixir.tech/aml/api/sar-filings?status=submitted&from=2026-01-01T00:00:00Z" \
  -H "Authorization: Bearer $QE_API_KEY"

{
  "ok": true,
  "data": {
    "items": [
      {
        "id": "sar_01HXY...",
        "caseId": "cas_01HXY...",
        "filingType": "STR",
        "typology": "structuring",
        "status": "submitted",
        "filedById": "usr_drafter_...",
        "submittedById": "usr_mlro_...",
        "submittedAt": "2026-04-12T10:32:11Z",
        "ppatkReferenceNo": "PPATK/STR/2026/04/000142"
      }
    ],
    "total": 47,
    "page": 1,
    "limit": 50
  }
}

Use this endpoint to feed your internal compliance ledger, or to reconcile against the SAR registry your compliance team maintains. It accepts the same Bearer API key as the write endpoints (with sar.read scope instead of sar.write).

Returns the full SAR object, including draft form fields. The xml field is not returned by GET — it's only emitted on the final submit response to prevent stale envelopes from circulating.

Submit (maker → MLRO review)

When the SAR is in draft, calling this advances it to pending_review. The dashboard then queues it on the MLRO's inbox.

curl -X POST .../api/sar-filings/sar_01HXY.../submit \
  -H "Authorization: Bearer $QE_API_KEY"

Submit (MLRO → PPATK-ready)

When the SAR is in pending_review, calling submit again — by a different user from the drafter — advances it to submitted and returns the goAML XML:

{
  "ok": true,
  "data": {
    "filing": {
      "id": "sar_01HXY...",
      "caseId": "cas_01HXY...",
      "status": "submitted",
      "filedById": "usr_drafter_...",
      "submittedById": "usr_mlro_...",
      "submittedAt": "..."
    },
    "xml": "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<goAML xmlns=\"http://www.unodc.org/goaml/2.0\" ...>...</goAML>",
    "next": "Forward XML to PPATK goAML gateway via the configured connector."
  }
}

XML envelope

The XML follows PPATK's goAML v2 schema (UNODC-issued, Indonesia-localized). It includes:

• <rentity> — your reporting entity (org's PPATK reg. number)
• <report> — the SAR itself
  • <report_indicators> — typology codes (PER-09)
  • <entity> (customer, counterparty)
  • <account> (each bank account involved)
  • <transaction> (every linked transaction)
  • <narrative> (free-text from notes)
• <signature> — XML-DSig digital signature

The signature uses your org's PPATK-registered signing cert. We sign on submit; the cert and key live in our HSM and never leave it.

Acknowledge

After you forward the XML to PPATK and they return an ack receipt, record it:

{
  "ppatkReferenceNo": "PPATK/STR/2026/05/001234",
  "acknowledgedAt": "2026-05-25T09:14:22Z"
}

This is for your audit trail — PPATK acks aren't programmatically piped back from PPATK to us.

Amend

If PPATK requests an amendment, draft and submit a new SAR with parentSarId pointing to the original. Both versions remain in the audit log.

Four-eyes rule (mandatory)

filedById !== submittedById          ← must always hold on submitted state

Attempting to submit your own draft returns HTTP 409:

{
  "ok": false,
  "error": "four-eyes violation: drafter cannot submit"
}

This is non-configurable for SAR — it's a regulatory requirement. Other approval workflows (rule changes, case closes) have configurable four-eyes; SAR doesn't.

Webhooks

Subscribe to:

• sar.submitted — fires when a SAR transitions to submitted status
• sar.acknowledged — fires when you record a PPATK ack

Use these to update your internal compliance ledger or to notify ops.