AI transaction investigations
An AI transaction investigation analyses retained rule evidence and historical patterns for one transaction and saves the provider's Markdown findings with that transaction. It is available only when all of these conditions are met:
- the installed release supports AI transaction investigation;
- the current license includes AI and Transaction Monitoring → Transactions;
- a supported provider/model configuration is active, has passed its connection test, and is selected as default; and
- the transaction exists in the licensed Transactions Sub-module.
The feature does not create a new transaction decision. It cannot approve, release, reject, report, delete, or record an analyst disposition. An authorised analyst must still review the evidence and follow the client's procedure.
Automatic investigation
Open Transaction Monitoring → Settings. Viewing the setting requires transaction_settings:read; changing it
requires transaction_settings:manage. The institution base currency must already be configured, and a default AI
provider must be connected and ready before automatic investigation can be enabled.
When enabled, OneView schedules an investigation after a newly received transaction results in FLAG, HOLD, or
BLOCK. PASS and NOT_EVALUATED transactions are not automatically investigated. Transaction ingestion and its
decision do not wait for the external provider; an investigation can therefore appear as in progress shortly after
the transaction is stored.
Disabling the setting stops automatic investigation for future eligible transactions. It does not remove completed findings or cancel work that has already begun.
Manual investigation
Any user with transactions:read can run the investigation from a transaction's Decision & review tab when AI is
ready. The same permission allows the user to ask context chat to investigate a transaction. No separate
transactions:investigate permission or confirmation is required because the operation only derives and retains an
assessment; it does not change the monitoring or analyst decision.
OneView first checks for a saved investigation. If a completed result exists, it returns that Markdown instead of calling the provider again. If an investigation is already running, another run is not started. This protects the record from competing or silently replaced assessments.
Evidence and result
The provider receives a server-prepared, non-identifying evidence package rather than the full transaction detail. It can include transaction characteristics, the decision and rule/check evidence, non-identifying customer risk attributes, aggregate customer history, aggregate counterparty history, device/IP availability, coarse geolocation, and shared-device or shared-network counts. The evidence excludes names, account numbers, customer and identity identifiers, contact details, raw device and IP values, credentials, and raw KYC records.
The Markdown result separates the investigation summary, reasons for the decision, customer history, counterparty patterns, device/location signals, risk assessment, recommended next steps, and data limitations. Missing evidence is identified rather than inferred. The saved result records the provider, model, and completion time shown to the user.
This minimisation reduces disclosure but does not make an external AI provider risk-free. The client must approve the provider and processing terms described in AI in OneView.
Decision & review display
The Review card contains AI Investigation and Analyst Review when AI investigation is available.
- When a saved AI investigation exists, AI Investigation appears first and opens by default.
- When no investigation exists, Analyst Review appears first and opens by default; the AI tab remains available for an authorised manual run while AI is ready.
- When AI is unavailable, the card shows the analyst review without an AI tab.
The AI tab shows in-progress, completed, failed, or empty state. A completed investigation is rendered as Markdown.
The Analyst Review tab continues to enforce transactions:review for recording a disposition and any required held
transaction release decision.
Failure and retry
If the configured provider times out, fails, returns no usable analysis, or becomes unavailable, the investigation is marked failed and the transaction remains unchanged. The transaction page offers another investigation attempt after the provider or connectivity issue is corrected. A successful retry replaces the failed state with one completed result; a completed result cannot be regenerated from the application.
Review the provider status without exposing credentials, then retry once the underlying issue is resolved. Do not use repeated retries to work around provider quota, billing, policy, or outage conditions. If the evidence or answer is insufficient, record that limitation in the analyst workflow rather than treating AI output as verified fact.