On this page
Risk scores are useful only when you can prove what happened afterwards. Myaza connects each fraud or transaction decision to a downstream outcome so your team can measure captured fraud, false positives, check quality and financial impact.
This gives your organisation three concrete benefits:
- Protect more revenue: identify the controls and check types associated with confirmed fraud, prevented loss and recovery.
- Reduce customer friction: measure legitimate customers interrupted by review or block decisions.
- Improve safely: review drift, thresholds and check reliability without silently changing a live policy.
Open Risk Intelligence → Effectiveness to see the current state, why Myaza reached it and the next safe action. Metrics remain marked as Not enough evidence until enough confirmed outcomes exist. Myaza does not turn missing labels into a reassuring zero.
Understand the four headline measures
- Fraud captured is the share of confirmed fraud linked to an interrupted transaction.
- Precision is the share of interrupted, labelled transactions that were confirmed as fraud.
- False positives are legitimate customers interrupted by a review or block decision.
- Outcome coverage is the share of decisions with a confirmed downstream result. Low coverage means the other measures are not yet trustworthy.
Record an outcome
Send the final known result for a transaction. Use the same idempotency key when retrying the same outcome.
The path reference may be a Myaza activity ID, external activity ID, Myaza transaction ID or your external transaction ID. Include externalUserId as an ownership guard when you have it. Myaza rejects the request with 409 external_user_mismatch if that customer does not own the resolved activity.
curl --request POST \
--url https://trust.myaza.app/api/v1/transactions/{transactionId}/outcomes \
--header 'Authorization: Bearer sk_live_…' \
--header 'Idempotency-Key: outcome-2026-08-16-001' \
--header 'Content-Type: application/json' \
--data '{
"externalUserId": "customer-8421",
"classification": "fraud",
"source": "chargeback",
"occurredAt": "2026-08-16T10:30:00.000Z",
"reasonCode": "chargeback.confirmed",
"currency": "USD",
"lossAmount": "125.50000000",
"recoveredAmount": "25.00000000"
}'Outcome records are append-only. Replaying an identical request is safe. Reusing the idempotency key with different data is rejected.
Resolved investigations are recorded automatically as fraud, legitimate or inconclusive outcomes for every linked transaction decision. Filed SARs add inconclusive escalation evidence and never assert guilt. For chargebacks, call this endpoint from the final dispute webhook with the event ID as the idempotency key.
Read effectiveness evidence
curl --request GET \
--url 'https://trust.myaza.app/api/v1/risk-intelligence/effectiveness?from=2026-08-01T00:00:00.000Z&to=2026-09-01T00:00:00.000Z' \
--header 'Authorization: Bearer sk_live_…'The response includes decision distribution, outcome coverage, fraud-capture rate, false-positive rate, precision, exact decimal financial impact, segment comparisons and per-rule effectiveness. Check completeness.complete before using a report for policy decisions. The dashboard lets authorised teams filter the evidence window, review recommendations, manage immutable system versions and run shadow experiments.
Drift, check reliability and relationships
Use the authorised Risk Intelligence endpoints to retrieve:
GET /api/v1/risk-intelligence/driftGET /api/v1/risk-intelligence/providersGET /api/v1/risk-intelligence/threshold-recommendationsGET /api/v1/risk-intelligence/system-versionsGET /api/v1/risk-intelligence/experimentsGET /api/v1/risk-intelligence/network/{subjectKind}/{subjectId}
Network exploration is bounded by depth and node limits. Reliability comparisons show availability, latency, disagreement and adjudicated false positives without ranking internal sources from incomplete evidence.
Safe optimisation
Recommendations never change a live customer decision automatically. They require labelled evidence, review, backtesting and a separately published system or rule version. Shadow experiments use the same canonical decision context but cannot change live decisions, alerts or billing.
Myaza refreshes fixed daily evidence windows on a schedule. Re-running the same window updates its canonical snapshot rather than creating duplicate drift evidence.
The full improvement loop is rule → safe historical test → governed publish → decision evidence → confirmed outcome → effectiveness review. Read Protect transactions with rules to install controls and test changes before they affect customers.
Webhooks
Subscribe to the lifecycle events below to keep your project in sync:
fraud.outcome.recordedrisk.drift.detectedrisk.threshold.recommendedrisk.system_version.changed
Each customer-facing event includes externalUserId when the activity is linked to one, together with the internal activity or transaction reference used by Myaza.