Inline Decisioning
How to use WatchTower when a source system needs an immediate risk decision before completing a transaction.
Immediate decision
Return an ALLOW, REVIEW, or BLOCK-style outcome while the source transaction is still pending.
Audit-safe flow
Store references, idempotency keys, decision outcomes, and response timestamps for support and compliance review.
Operational follow-through
Review and block outcomes can create alerts, cases, notifications, and final analyst decisions.
When to use inline decisioning
Use inline decisioning when the source system can pause the transaction long enough for WatchTower to screen it and return an immediate decision.
This mode is best for channels where a clear action is needed before completion, such as transfer initiation, wallet movement, high-risk beneficiary payments, bill payments, or other real-time payment flows.
Typical outcomes
- allow the transaction to continue
- hold or route the transaction for review
- block or cancel the transaction before completion
Inline decisioning only applies when the upstream channel supports synchronous risk checks. If a source system cannot wait for a decision, use monitoring or batch ingestion instead.
Request flow
- The source system receives or creates a transaction request.
- The source system sends the transaction context to WatchTower from a trusted backend service.
- WatchTower authenticates the request, validates tenant routing, and normalizes the payload.
- Rules, behavioral signals, identity context, and watchlist checks run against the transaction.
- WatchTower returns an immediate decision response.
- The source system applies the decision and stores the response reference for reconciliation.
Decision response concepts
The response should be treated as the screening result for that specific transaction attempt. Store the transaction reference, idempotency key, decision, risk score, and response timestamp for later support and audit review.
Response fields to handle
- transaction reference or upstream reference
- decision such as ALLOW, REVIEW, or BLOCK
- recommended action for the source system
- risk score or confidence score
- triggered controls and evidence summary where available
- stable response identifier for support and reconciliation
Generic request and response example
The exact payload can vary by integration path. The important requirement is that the request gives WatchTower enough context to identify the customer, counterparty, amount, channel, direction, and source reference.
{
"reference": "TXN-EXAMPLE-0001",
"amount": 500000,
"currency": "NGN",
"channel": "TRANSFER",
"direction": "OUTBOUND",
"transactionType": "DEBIT",
"transactionCategory": "TRANSFER",
"timestamp": "2026-03-24T14:43:46.020Z",
"customer": {
"id": "cus_example_001",
"name": "Ada Example",
"accountNumber": "0000000001"
},
"counterparty": {
"name": "Bayo Example",
"accountNumber": "0000000002",
"bankCode": "999"
},
"narration": "Payment for services",
"metadata": {
"sourceSystem": "example-payment-platform",
"requestId": "req-example-001"
}
}{
"reference": "TXN-EXAMPLE-0001",
"decision": "REVIEW",
"recommendedAction": "HOLD_FOR_REVIEW",
"likelyFraud": true,
"confidenceScore": 0.87,
"riskScore": 82,
"evidenceSummary": "Velocity and counterparty signals require analyst review.",
"triggeredControls": [
{
"name": "Velocity threshold",
"category": "Behavioral monitoring",
"severity": "high"
}
]
}Retries and duplicate handling
Real-time transaction systems retry requests when networks are slow or responses are unclear. Inline integrations must therefore use stable transaction references and idempotency keys.
Retry expectations
- reuse the same idempotency key for the same transaction attempt
- do not generate a new reference for a retry of the same event
- store the decision returned by WatchTower
- treat duplicate responses as reconciliation events, not new transactions
Timeout and reconciliation planning
Every inline integration should define what the source system does when no response arrives before its own timeout. WatchTower can support follow-up status checks and downstream case workflows, but the source system still needs a safe timeout policy.
Plan before go-live
- client-side timeout threshold
- default source-system behavior when timeout occurs
- status query or reconciliation process
- how analyst resolution is reflected back into the source system
- audit record for delayed or retried decisions
What happens after the response
The inline response is only the first part of the workflow. If WatchTower returns review or block, the same transaction can create an alert, generate a case, notify the assigned team, and preserve the decision trail for reporting.
- allow decisions can be stored for monitoring and reporting
- review decisions can create analyst work queues
- block decisions can create high-priority cases
- case updates, notes, assignments, and final outcomes remain auditable