AML Platform

AML Platform

PPATK-aligned AML monitoring. Sanctions/PEP/adverse-media screening, real-time transaction monitoring, case management, and goAML XML SAR filing.

What it does

Capability	API
Onboarding screening	`POST /api/screenings` — single subject or batch of up to 100
Transaction monitoring	`POST /api/transactions/evaluate` — sub-100ms decision
Watchlists	OFAC · UN · EU · UK · ANC · PEP lists + your own private lists
Alerts	Auto-created from screening/transaction hits; manual creation supported
Cases	Group alerts, four-eyes maker/checker workflow
SAR filing (goAML)	Auto-generates goAML XML envelope, ready to file with PPATK
Rules engine	Configurable risk rules: thresholds, structuring, velocity, geography
Decision policy	Per-org thresholds (confirmed-hit, review, escalate-score, sar-score)

Core concepts

Concept	What it is
Customer	Subject of monitoring. Persistent.
Screening	Single run of a subject against the watchlists. Produces matches with scores.
Alert	Something looked off — a transaction over threshold, a screening hit, a pattern.
Case	An investigation: 1+ alerts + analyst notes + documents + a disposition.
SAR filing	A Suspicious Activity Report destined for PPATK. Maker drafts, MLRO submits (four-eyes).
Rule	A condition that, when satisfied by a screening or transaction, produces an alert.
Watchlist	A list of sanctioned/PEP/adverse-media subjects. Refreshed on a schedule.
Decision policy	Per-org thresholds that turn raw scores into actions (alert · escalate · file SAR).

Lanes

AML monitoring runs in three lanes:

Lane	When it fires	Typical action
`onboarding`	New customer creation, KYC tier change	Screen against watchlists
`ongoing`	Periodic re-screen of existing customer base	Re-screen at watchlist refresh
`transaction`	Each inbound/outbound transaction	Score risk, alert on hit

Common integration shape

Onboarding

1
POST/api/customers
Register the customer record.
2
POST/api/screenings
Screen against PEP / sanctions watchlists.
Auto-creates an alert on confirmed hit.
3
GET/api/alerts?customerId=…
Poll for alerts — or subscribe to the alert.created webhook.
Optional.
4
PATCH/api/cases/{id}Analyst
Work the case (notes, disposition).
5
POST/api/sar-filings/{id}/submitMLRO
File SAR — returns the goAML XML envelope.

Transaction monitoring (per-transaction, sub-100ms)

1
POST/api/transactions/evaluate
Inline decision + alertId.
2
Use decision to allow / block / hold the transaction in your core banking system.

RBAC

Roles map to the standard maker/checker pattern Indonesian banks already use:

Role	Read	Write	Approve	Sign-off SAR	Notes
`admin`	✓	✓	✓	—	Manage rules, members, billing
`mlro`	✓	✓	✓	✓	Money Laundering Reporting Officer
`analyst`	✓	✓	—	—	Maker: drafts, edits, dismisses
`checker`	✓	—	✓	—	Approves what makers create
`viewer`	✓	—	—	—	Read-only

Four-eyes: rule changes and SAR submissions must be drafted and submitted by different users. The API enforces this regardless of dashboard or programmatic access.

Indonesia-specific behaviour

goAML XML format — SAR submissions are emitted in the PPATK-required XML envelope. We do not transmit to PPATK on your behalf in production yet (the connector exists in sandbox-mock form); you forward the XML using your existing PPATK channel.
NIK-aware matching — when a subject has a NIK, we de-duplicate matches that point to the same person across multiple watchlists.
IDR-native thresholds — cash deposit threshold defaults to IDR 500,000,000 (per PPATK Reg. PER-11/1.02/PPATK/06/2013). Configurable.
Bahasa Indonesia-aware — name fuzzy matching handles Indonesian naming conventions (single-name customers, patronymics, BIN/BINTI).

AML is regulator-facing — accuracy matters

Sandbox watchlists are synthetic test data. Live access requires that your organization has signed our MSA and provided your PPATK reporting entity ID. Email sales@quantumelixir.tech.

Production considerations

Concern	Answer
Data residency	Customer records, watchlist data, screening rows, alerts, cases, and SAR filings live in `id-jkt-1`. Never replicated cross-border.
Watchlists	UN-SC + OFAC sourced upstream in `us-iad-1`, proxied + cached in `id-jkt-1` daily. PPATK PEP lists sourced directly in-region.
Retention	Screening rows + alerts + cases + SAR filings retained 7 years (PPATK regulatory minimum). Transaction monitoring rows retained 5 years.
Rate limits	Screening: 60/min/org. Transaction evaluate: 600/min/org (production tier higher on request). Bulk screening: 5 batches/min.
Idempotency	Transaction evaluate accepts an `externalId` field — repeated calls with the same `externalId` within 24h return the original decision.
Four-eyes	Rule changes + SAR submission enforce drafter ≠ submitter at the API layer. Non-configurable for SAR; configurable per-org for rule approvals.
PPATK rentity ID	Required before first SAR submission. Set via Dashboard → Settings → Compliance, or `PATCH /api/organization` with `ppatkRentityId`.
Audit	Every customer create, screening, alert action, rule change, SAR draft / submit / ack is audit-logged. Immutable, 7-year retention (regulatory).
Webhook signing	HMAC-SHA256 over the raw body, header `X-Aml-Signature: sha256=<hex>`. Suite-wide migration to `X-Quantum-Signature` on the 2026 roadmap.
Machine accountability	API keys can carry `actAsUserId` to bind a machine caller to a human user — required for four-eyes enforcement on bot-driven SAR submission. See Authentication →.