Compliance (FRAML)
Compliance is Myaza Trust's fraud and anti-money-laundering layer (FRAML). On top of KYC verification, it lets you keep watching the people and businesses you've onboarded: screen them against sanctions / PEP / adverse-media watchlists, score their transactions in real time, and run a full investigation workflow — alerts, cases, and regulatory filings — from the dashboard.
There are two sides to it:
- The Identity Hub API — a server-to-server API you call to sync your users as monitored entities and to stream their events (transactions and actions) for scoring. See Identity Hub API and Event monitoring.
- The Compliance dashboard — where your compliance team reviews entities, screening hits, and alerts, works cases, and files reports. Under Dashboard → Compliance.
Everything is environment-scoped (sandbox vs. production) and organization-scoped, exactly like the rest of the platform — the API key you use decides which. See Environments.
Building blocks
| Concept | What it is |
|---|---|
| Entity | A person (INDIVIDUAL) or company (BUSINESS) you monitor, keyed by your own externalUserId. Carries a KYC disposition, a risk tier, and (once resolved) a link to a global identity. |
| Screening | An ongoing check of an entity against a watchlist type — SANCTIONS, PEP, or ADVERSE_MEDIA — producing zero or more matches. |
| Event | A transaction or action you send for scoring (POST /events). The engine returns a decision and a risk score. |
| Signal | The stored, scored record of an event — the monitored activity stream you browse in the dashboard. (A separate device/session signal stream is store-only.) |
| Alert | An investigation item opened automatically when an event scores at or above the review threshold. |
| Case | A grouping of one entity's alerts, tracked through investigation to a disposition. |
| SAR / STR | A Suspicious Activity / Transaction Report drafted and filed from a case, exportable as goAML XML. |
Risk & disposition vocabulary
An entity carries two independent axes:
- Disposition — its KYC standing:
PENDING,UNDER_REVIEW,APPROVED,REJECTED. - Risk tier — its monitoring risk posture:
LOW,MEDIUM,HIGH, orUNSCORED.
Each event yields a decision — ALLOW, REVIEW, or BLOCK — and a risk score from 0 to 100.
The monitoring lifecycle
An event flows through the system like this:
your backend
│ POST /api/identity/events
▼
Event ───score──► Signal (every event; browsable stream)
│
│ decision ≥ review threshold
▼
Alert (OPEN — needs triage)
│ group an entity's alerts
▼
Case (OPEN → IN_REVIEW → CLOSED + disposition)
│ if reportable
▼
SAR / STR (DRAFT → FILED, exported as goAML XML)- Event → Signal happens on every ingested event; the signal is stored and scored.
- Signal → Alert happens automatically when the composite score crosses your review threshold.
- Alert → Case → SAR are manual compliance actions taken in the dashboard.
Permissions
Each Compliance area has its own permission key, so you can grant read access to one surface without the others. The server enforces these; the dashboard hides what you can't use.
| Key | Grants |
|---|---|
identity:read | View individual entities, the compliance overview, and entity detail. |
business_identity:read | View business entities. |
screening:read | View screening results. |
signals:read | View the monitored event/signal stream. |
alerts:read | View alerts. |
alerts:manage | Open a case from selected alerts. |
cases:read | View cases. |
cases:manage | Open / assign / dispose cases and draft / file / cancel SARs. |
monitoring:manage | Edit monitoring rules (reading them is always allowed). |
All case and SAR writes are audited server-side and appear in your organization's audit log (Dashboard → Audit logs).
Next steps
- Identity Hub API — sync your users as monitored entities.
- Event monitoring — stream transactions for scoring.
- Monitoring rules — configure how events are scored.
- Screening — sanctions, PEP, and adverse-media checks.
- Alerts, cases & SARs — the investigation workflow.