How to assess transaction risk with Myaza Trust
Assess transaction risk before your application moves money. Submit an exact amount, the right direction and the parties involved, then use the decision and its explanation.
Charles Archibong, Co-founder
· 3 min read
Key takeaways
- A complete request shows the intended sender and recipient.
- Allow, Review, Block and service failures use the correct payment paths.
- A retry does not score or bill again.
- The displayed decision matches the API record.
- Crypto release uses its separate qualified clearance integration.
Assess transaction risk before your application moves money. Submit an exact amount, the right direction and the parties involved, then use the decision and its explanation.
Before you begin
Exact amount, currency, direction and stable reference
Published rules and applicable transfer requirements
Use a team member with permission for this control. Check the organisation and environment before changing a setting. Review the current price before a paid check or ongoing enrolment. Screenshots show an example workspace or the public integration reference; they do not show a real customer or a completed paid check.
Set up and use the capability
Step 1: Configure transaction controls in Sandbox
Open Risk Intelligence → Fraud Monitoring → Transactions and review the setup requirements. In Rules & Policies → Fraud rules, install suitable rules from the library or test and publish a custom rule. Review thresholds and money limits. Installation publishes a rule version for the selected organisation and environment. A page preview with a risk score is demonstration data, not a configured decision system.
Integration reference: Start with the rule library
Step 2: Prepare one complete transaction request
Assign stable external activity and transaction references. Specify subject, original occurredAt, assetClass, direction, amount, currency and transactionType. Send amount as an exact positive decimal string, not a floating-point calculation. Direction is from your customer’s perspective: inbound means received by the customer, outbound means sent by them. Put each bank account or wallet under the party that used it.
Integration reference: Send a complete transaction
Step 3: Include the party that needs screening
For an outbound fiat payment, provide the recipient’s permitted name and identity context; inbound fiat screens the sender. For crypto, provide the relevant external party’s wallet address and explicit network. Each party needs a stable reference. Missing target evidence can produce Review for insufficient data instead of a clear result. A masked display value alone cannot identify a payment instrument.
Integration reference: How directional screening works
Step 4: Submit once and read the authoritative summary
Call POST /api/v1/transactions from your backend with a secret key and a stable Idempotency-Key. Store the returned activity, transaction and decision references. Read assessment.summary.outcome, reason and nextAction. Keep Review and Block separate from Allow. Detailed matched rules, screening and billing explain the result; do not sum them yourself to replace the returned outcome.
Integration reference: Transaction assessment response
Step 5: Enforce the result before funds movement
Your payment backend holds Review, stops Block and continues Allow according to its authorised operating policy. Keep unavailable or pending results on the required hold. For crypto, a risk-only Allow is not Travel Rule clearance or single-use execution authorisation. Myaza does not move funds. Search the transaction reference in the dashboard and inspect the evidence before a manual exception.
Integration reference: Enforcing decisions in your app
Step 6: Test retries, notifications and final outcomes
Retry unchanged requests with the original references and key after uncertainty. Subscribe to fraud.transaction.assessed and applicable decision changes. Verify signatures, store event IDs durably and retrieve current state for delayed events. Send confirmed downstream outcomes when known so Effectiveness can measure performance. A successfully delivered webhook does not establish that your payment system enforced the decision.
Integration reference: Idempotency and freshness
Get more from the capability
Include structured senders, recipients and instruments to make screening and relationship evidence more informative.
Backtest rule changes before publishing a new version and retain the exact version with the decisions it produced.
Record confirmed fraud, legitimate and inconclusive outcomes. Avoid tuning thresholds from unlabelled decisions alone.
Test before relying on it
Run the supported Sandbox or simulator scenarios for this product. Where a tool is Production only, check access and scope first, then use only a permitted, deliberately reviewed Production test. A documentation screenshot or a successful page load is not an end-to-end integration test.
A complete request shows the intended sender and recipient.
Allow, Review, Block and service failures use the correct payment paths.
A retry does not score or bill again.
The displayed decision matches the API record.
Crypto release uses its separate qualified clearance integration.
Troubleshooting
A transaction needs review despite no rule hit
Inspect directional screening and insufficient-data evidence, not only matched rule count.
Amount or location was rejected
Use exact decimal strings and supply both latitude and longitude when sending coordinates.
Retry produced a conflict
The same identifiers were used for changed immutable data. Reconcile the original transaction before a genuinely new operation.
Open the setup and integration references
Read the integration reference
Back to Solutions. Choose the capability you want to activate, then follow its own guide.
Sources
Charles Archibong
Co-founder
Charles Archibong co-founded Myaza Trust. He writes about identity verification, financial technology, and the practical work of building trusted digital services.
