PPATK SAR filing pipeline

End-to-end: alert detection → case investigation → SAR draft → MLRO sign-off → PPATK XML → forward to PPATK → ack ingestion. The minimum compliant pipeline for an Indonesian reporting entity.

The shape

Triggering activity (transaction or screening hit)
     │
     ▼
1. AML evaluate or screening creates an Alert
     │
     ▼
2. Analyst (maker) reviews alert
   - Dismisses (false positive)
   - Escalates → Case
     │
     ▼
3. Case investigation
   - Analyst adds notes
   - Pulls customer history (Identity, Bank Statement)
   - Optionally invokes AI Automation flow to summarize for MLRO
     │
     ▼
4. Maker drafts SAR via dashboard
   - typology, filing type (STR/CTR/XSR), narrative
   - linked alerts, customers, transactions, accounts
     │
     ▼
5. POST /api/sar-filings/{id}/submit  (maker → MLRO review)
     │   four-eyes rule: drafter ≠ submitter
     ▼
6. MLRO reviews + decides
   - Reject → back to maker
   - Approve → step 7
     │
     ▼
7. POST /api/sar-filings/{id}/submit  (MLRO submits)
   ← response includes the goAML XML
     │
     ▼
8. Forward XML to PPATK
   - Manual: paste into PPATK goAML web portal
   - Automated: your existing PPATK SFTP/SOAP connector
     │
     ▼
9. PPATK acknowledges
     │
     ▼
10. POST /api/sar-filings/{id}/acknowledge with PPATK reference number
    ← closes the loop, audit-logged

Orchestration version

{
  "slug": "ppatk-sar-pipeline-v1",
  "spec": {
    "startNodeId": "wait_for_draft",
    "nodes": [
      {
        "id": "wait_for_draft",
        "type": "human_approval",
        "actionLabel": "Draft SAR for case ${trigger.caseId}",
        "assignTo": "role:aml_analyst",
        "timeoutHours": 168
      },
      {
        "id": "summarize_for_mlro",
        "type": "service_call",
        "service": "ai-automation",
        "method": "POST",
        "path": "/api/flows/sar-summary/execute",
        "body": {
          "caseId": "${trigger.caseId}",
          "sarId": "${step.wait_for_draft.output.proposedAction.sarId}"
        }
      },
      {
        "id": "mlro_signoff",
        "type": "human_approval",
        "actionLabel": "MLRO sign-off on SAR ${step.wait_for_draft.output.proposedAction.sarId}",
        "assignTo": "role:mlro",
        "data": { "aiSummary": "${step.summarize_for_mlro.output.text}" }
      },
      {
        "id": "submit_sar",
        "type": "service_call",
        "service": "aml",
        "method": "POST",
        "path": "/api/sar-filings/${step.wait_for_draft.output.proposedAction.sarId}/submit"
      },
      {
        "id": "forward_to_ppatk",
        "type": "http_sink",
        "url": "${env.PPATK_SFTP_PROXY_URL}",
        "body": {
          "sarId": "${step.wait_for_draft.output.proposedAction.sarId}",
          "xml": "${step.submit_sar.output.data.xml}"
        }
      }
    ]
  }
}

The PPATK connector itself is yours to build (or use an off-the-shelf SFTP/SOAP integration). Quantum Elixir produces the XML; transmission to PPATK is on your network.

The four-eyes rule is non-configurable for SAR

Maker (filedById) and submitter (submittedById) MUST differ. The API enforces this regardless of org-policy settings — it's regulatory, not configurable. If a single user must do both, two separate user accounts are required.

Filing types (PPATK)

Filing	Code	When to use
STR	STR	Suspicious Transaction Report — default for most cases
CTR	CTR	Cash Transaction Report — automated for cash above PPATK threshold (IDR 500M default)
XSR	XSR	Cross-border Suspicious Transaction Report — cross-border element involved

Typology codes (PER-09)

PPATK's PER-09 defines a closed list of typology codes. The SAR draft form constrains the typology selector to these codes. A few common ones:

Code	Description
01	Money laundering — structuring (smurfing)
02	Money laundering — trade-based
03	Money laundering — real estate
04	Money laundering — virtual asset
05	Money laundering — investment fraud
11	Terrorism financing
21	Proliferation financing
31	Fraud — credit card
32	Fraud — online
41	Corruption — public
42	Corruption — private

Full list in the AML dashboard's SAR-Typology dropdown. Update when PPATK publishes new PER-09 versions.

Common pitfalls

Drafting in maker without all evidence. Maker should attach linked transactions, accounts, and customer references before submitting to MLRO. PPATK rejects SARs with insufficient narrative — fix the draft cycle, not the submission.
English-only narratives. PPATK requires Bahasa Indonesia for the narrative section. The dashboard's SAR form enforces language detection.
Stale watchlist references. Cite the watchlist version active at the time of the alert, not the current one — required for audit trail.
Forgetting to acknowledge. PPATK ack is your evidence of compliance. Without it, your audit trail is incomplete. Build the acknowledge step into your PPATK SFTP/portal workflow.

AI-assisted summarisation (optional)

A typical MLRO reviews 20–50 SARs per week. AI Automation can produce a one-paragraph summary of each case to speed review without replacing the MLRO's judgement:

agent: "SAR Pre-Review Summarizer"
system: "You are an AML pre-review assistant. Given a case (alerts, customer, transactions, notes), produce a 3-sentence summary highlighting the typology, the supporting evidence, and any red flags the MLRO should pay particular attention to. Don't recommend approve/reject — that's MLRO's call."

Surface the summary on the MLRO's queue card. MLRO reviews the summary first, then reads the full case for the ones that warrant deeper attention.

Step-up auth on high-value transfers Mobile device fraud detection