---
name: myaza-risk-intelligence
description: Integrate and improve Myaza Trust risk intelligence flows. Use when designing, implementing, debugging or reviewing risk intelligence, including policy outcomes, customer enforcement and recovery.
---

# Myaza Trust: Risk Intelligence

## Start with the customer outcome

Connect customer evidence to reviewable, measurable risk decisions.
Ask only for missing choices that affect the design: the customer's business flow, launch markets, review team, desired decision and the action their application will enforce. Do not ask for API keys in chat.

## Read the current contract

1. Discover current resources at https://trust.myaza.co/llms.txt and https://trust.myaza.co/documentation/index.json.
2. Read these guides before implementation. They are the same authored source as the human documentation:
   - https://trust.myaza.co/documentation/risk-intelligence/markdown
   - https://trust.myaza.co/documentation/risk-intelligence-quickstart/markdown
   - https://trust.myaza.co/documentation/customer-risk-reads/markdown
   - https://trust.myaza.co/documentation/identity-hub/markdown
   - https://trust.myaza.co/documentation/compliance/markdown
   - https://trust.myaza.co/documentation/decision-effectiveness/markdown
   - https://trust.myaza.co/documentation/investigations/markdown
3. Also read authentication, environments, errors and webhook authentication. Use https://trust.myaza.co/documentation/ai-integration/markdown for API-family boundaries and handoff requirements.
4. For /api/v1 operations, fetch https://trust.myaza.app/api/openapi.json and resolve referenced schemas. Do not assume it describes the separate /api/kyc or /api/identity families. Their guide contracts remain necessary.
5. If the guide and deployed response differ, report the discrepancy and inspect the actual schema. Never invent an endpoint, enum or readiness flag. Use the index SHA-256 values to identify the content reviewed.

## Design safeguards

Link the same customer reference across verification, screening, activity and transactions. Distinguish evidence, risk score, policy decision and the customer's enforcement action. Unknown or unavailable evidence is not low risk. Explain which team owns review and remediation before proposing automation. Never use another tenant or environment's evidence.

Keep credentials on the customer's backend. Scope reads and writes to the organisation and environment. Use least-privilege permission checks. Never auto-publish a policy, activate Live, change financial entitlements or approve a company on the user's behalf without explicit permission. Country coverage and rules are not a guarantee of regulatory compliance; the organisation's authorised reviewer owns its obligations.

## Implement and verify

- Start in Sandbox. Use documented explicit scenarios for deterministic tests; ordinary Sandbox operations can use configured pricing.
- Reuse stable customer and operation references. Send an idempotency key where the operation contract requires one. On an uncertain response, retain the same payload and key and reconcile current state.
- Model pending, review, blocked, unavailable and retryable states explicitly. Never turn an error or missing result into approval.
- Customer reads are an opt-in SHADOW preview, not execution authority. Keep current and as-assessed results distinct. Risk rows, monitoring filters and totals must share one response; expire them together using each owner's relative validity window. A missing score is not zero and unavailable monitoring is not non-enrolment.
- Explain an assessment using its exact snapshot and retained sources. Connections is assessment lineage, not proof of wallet ownership or a live customer network. Supporting context and excluded observations do not add points. Never refill an erased historical view from current evidence; refuse contradictory score and evidence totals.
- Verify signed webhooks on raw bytes, deduplicate and persist before acknowledging, and fetch current state before enforcement.
- Minimise personal data. Do not log keys, raw identity documents, party details, full wallet addresses or biometric evidence.
- Add executable tests for the happy path, invalid input, missing information, tenant/environment isolation, permission denial, duplicate requests, timeout/recovery and out-of-order notifications.
- Use the product's testing guide for required negative and boundary cases. A mocked success does not prove a real institution channel or Live readiness.

## Deliver the customer handoff

Provide the implemented flow, exact API families and versions used, data mapping, decision-to-action table, review owner, webhook recovery procedure, test evidence, and unresolved external prerequisites. Separate local qualification from Sandbox integration and Live acceptance. Suggest workflow improvements with rationale and trade-offs; do not silently change the customer's risk appetite or claim legal approval.