Reviewing transactions

Transaction Monitoring → Transactions lists everything received, with its execution date and decision. Search by reference, customer, or account, or narrow the list by execution date range, direction, and decision. The active filters remain in the page URL so a filtered view can be revisited or shared with another authorised operator.

The initial view covers the previous 24 hours. Open Filters to select the last 7 days, last 30 days, a custom date range, or all time. Time frame, direction, and decision controls are grouped in the filter drawer so the main list toolbar stays compact.

Opening a transaction separates the stored information into six tabs:

Overview contains transaction references, lifecycle timestamps, amounts, balances, and currency values.
Parties contains the complete initiator and counterparty snapshots supplied by the source system. Use View profile to compare a party's transaction-time snapshot with its current OneView customer profile.
Ledger contains debit and credit posting legs and shows whether they balance.
Decision & review contains the monitoring outcome, rule evidence, saved AI investigation where available, and analyst review record.
Device context contains the device, network, location, and application telemetry supplied with the request.
Processing log contains the ordered server-side events recorded from request receipt through validation, duplicate protection, rule evaluation, storage, and final response delivery.

Each tab explains what the displayed information represents. When no information was supplied for a tab, the page shows a clear empty state instead of an empty table or card. Recording an analyst review requires Review flagged transactions.

Party profiles

The party cards preserve the information supplied with the transaction, including nested provider or core banking context. View profile opens a side panel with two records:

Current customer profile is the latest customer record known to OneView. It appears when the party carries a customer ID that can be linked to the customer store.
Transaction-time snapshot is the complete party payload accepted with this transaction. It remains tied to the transaction even if the current customer profile changes later.

External bank, card, value-added service, and GL counterparties may not have a linked customer profile. Their transaction-time snapshot remains available in the same panel.

Processing log

The processing log is an audit-oriented timeline, not a client-supplied payload. It records each completed stage with its timestamp, status, and duration where applicable. New transactions include the final HTTP response marker after OneView finishes returning the decision to the submitting system. Transactions accepted before processing logs were introduced display an empty state because their earlier lifecycle was not inferred or backfilled.

Evaluation criteria

Open Decision & review to see one combined table of evaluation checks and rules. Check rows include authentication and request acceptance, payload validation, and duplicate protection. Rule rows include the retained name and version, live or shadow mode, action, and outcome such as Passed, Triggered, Error, or Skipped.

Evaluation checks are retained as reviewer-facing decision evidence in records that are separate from the chronological processing events. The table never derives validation outcomes from the processing log. Storage, response delivery, timestamps, sequencing, and durations remain exclusively in the Processing log tab.

When retained evidence exists, select View evidence from the relevant row. Rule evidence shows the conditions that matched in plain language. Other evaluation checks can retain bounded evidence such as the party checked, the source or list version, the match status, and a safe result reference. The table does not show point additions.

The Risk score card shows the assigned score out of 100, the resulting decision, every range from the grading version retained with the transaction, and the score's position across those ranges. The adjacent evaluation record shows completion, timing, and rule count where licensed. The underlying ruleset fingerprint remains stored for audit verification but is not displayed in the dashboard.

Two kinds of line appear:

A field condition names the field and the threshold — "Amount is above 1,000,000". The value itself is on the transaction, shown further down the page.
A window count shows the number that was computed and the exact period it covered — "14 transactions for the same initiator account in the last hour". Because the period is recorded, the line links to those transactions.

That link matters: a count on its own tells you a rule fired, whereas the underlying transactions tell you whether it should have.

Shadow rules appear separately and are marked as not having affected the decision.

Rules do not display individual point contributions. Rule actions determine the decision, while the versioned risk score grading policy assigns the score for that decision.

AI and analyst review

The Review card separates derived AI findings from the analyst's recorded outcome. When a saved AI investigation exists, AI Investigation is the first tab and opens by default. When no investigation exists, Analyst Review comes first and opens by default. If AI is not licensed or no provider is ready, only the analyst review is shown.

A user with transactions:read can run an available AI investigation without a separate investigation permission. The result is saved as Markdown and asking again returns the completed result rather than calling the provider again. AI findings never release, reject, approve, or otherwise change the transaction, and do not replace the analyst review. See AI transaction investigations for setup, evidence, failure, and retry behavior.

Adding a transaction to a report

A user with reports:manage and the licensed Reporting Sub-module can select Add to report on a transaction to attach it to a new or existing CTR, FTR, SAR, or STR report. See Reporting.

Incomplete evaluations

If some rules could not run, the section carries a warning and the decision is partial. The rules that failed are listed with a reason. Treat a partial PASS with the same care your integration does.

Recording an analyst review

Record review captures an investigation outcome: Cleared, Suspicious, Escalated or False positive, plus an optional note.

For a held transaction you also record a release decision:

Release — allow it to complete.
Reject — do not complete it.

This is the value your core banking system reads when it next polls the transaction. Until a review is recorded, a held transaction stays unresolved from the caller's point of view, so held transactions should be worked promptly.

A transaction can be reviewed once. The review, the reviewer and the time are recorded, and the action is written to the activity log, which is integrity-linked and append-only.

Working the queue

Filter the list by decision to find what needs attention. Add a direction or execution date range when reviewing a specific operational window. Held transactions are the most time-sensitive, because a person is holding up a payment; flagged transactions have already settled and can be worked in order.

What the list does not show

The list deliberately omits customer and counterparty detail. Those snapshots appear on the transaction detail page, which records an access event when opened. Identity numbers are currently shown in full on that page to users who can read transactions.