Decisions and Risk Outcomes
Learn how WatchTower evaluates a transaction, which outcomes it can return, and how to handle each one safely in your own system.
The five decision outcomes
Every transaction you send to WatchTower comes back with one decision. That decision tells your system what to do next. WatchTower can return five outcomes, not just three, and the difference matters when you design your integration.
All five outcomes
- ALLOW: no material risk found, the transaction can continue
- REVIEW: the transaction should continue, but an analyst needs to look at it
- BLOCK: the transaction should be stopped or escalated before it settles
- CHALLENGE: the customer should complete a step-up check before the transaction continues
- CONTEXT_ONLY: the transaction was imported for history or baseline building and never produced a live decision
A common integration mistake is only handling ALLOW, REVIEW, and BLOCK and treating anything else as an error. CHALLENGE and CONTEXT_ONLY are normal, expected outcomes, and your integration should handle all five from day one.
What drives the decision
WatchTower combines several signals to reach a decision. No single signal decides the outcome on its own.
- triggered monitoring controls and their severity
- behavioral signals compared against the customer or account baseline
- anomaly score
- watchlist or screening hits
- organization-level risk thresholds
- linked customer and identity context when Identity is connected
How to handle each outcome
ALLOW
- Let the transaction continue with no extra action. It is still stored for reporting and future behavioral baselines.
REVIEW
- Let the transaction continue. WatchTower does not stop a REVIEW transaction for you.
- An alert is created for an analyst to look at. If you are integrated so that WatchTower can hold the transaction on your side pending that analyst review, treat REVIEW as a held state until you receive the follow-up outcome. See "Held transactions and the review outcome" below.
BLOCK
- Stop or escalate the transaction according to your own operating policy. WatchTower recommends the block, but your system enforces it.
CHALLENGE
- Apply the step-up check requested for this transaction, such as an OTP, a biometric prompt, or a second approver.
- Report the result back to WatchTower once the customer completes or fails the check, so the transaction reaches a final ALLOW or BLOCK outcome.
CONTEXT_ONLY
- No action needed. This outcome is expected for historical or backfilled records and does not represent a live risk decision.
Held transactions and the review outcome
Some integrations are built so that a REVIEW decision pauses the transaction on your side while an analyst investigates. When that is the case, the transaction stays held until WatchTower sends a follow-up outcome once the case is resolved.
The analyst records one of two explicit outcomes for a held transaction: release it, or cancel it. WatchTower never guesses this from the resolution notes. Once the analyst records the outcome, WatchTower sends it to your system as a signed callback so your side can act automatically instead of waiting on a person to check back.
What you receive back
- a reference to the original transaction
- the final outcome, expressed as allow or block
- a delivery identifier you can use to handle retries safely
- a timestamp for when the outcome was sent
If your integration pauses transactions on REVIEW, plan for the follow-up outcome as a core part of your flow, not an edge case. The initial response only tells you a transaction is held. The follow-up tells you what actually happened to it.
Operational context
Decisioning works best as part of a wider control framework. Most institutions pair WatchTower risk outputs with internal policy, customer context, fraud and compliance review standards, analyst escalation workflows, and identity-safe evidence from Remllo Identity when that organization is connected.
The decision engine is where fraud detection, transaction monitoring, identity context, and operational handling meet. A good setup connects decisions directly to alert review, case management, customer context, and reporting.