Overview

Transaction monitoring

Transaction monitoring receives transactions from your core banking system, evaluates them against rules you author, returns a decision synchronously, and retains the transaction and its evaluation in your own PostgreSQL database.

It is a Module with two independently licensed Sub-modules:

A licence may include Transactions without Rules. In that case every transaction is still received and stored, and its decision is recorded as Not evaluated. That is deliberate: a caller must never read silence as approval.

Transaction monitoring is a native capability. It uses no vendor adapter and needs no vendor connection.

Before ingestion begins, an administrator must configure the institution base currency once and create an active API service account scoped to Transaction Monitoring or all modules. The in-product Get Started page tracks these prerequisites and disappears when both are complete. See Get started for the full checklist and Transaction monitoring settings for the currency rules.

When the separately licensed AI Module has a tested default provider, an administrator can optionally enable automatic AI investigation for new FLAG, HOLD, and BLOCK decisions. The provider produces a derived Markdown assessment from minimized evidence after the transaction decision is stored. It does not delay ingestion, change the decision, or replace an analyst. See AI transaction investigations.

What OneView decides, and what your systems decide

OneView evaluates a transaction and returns a decision. Your orchestrator decides what to do with it. OneView is not designed to sit in a payment authorisation path as a blocking dependency.

Two responsibilities follow from that, and both belong to you:

• Implement caller-side fail-open. If OneView returns an error, times out, or is unreachable, your system must apply its own fallback policy rather than waiting.
• Allow transactions through without review during an update. While OneView is draining for a release, it returns a maintenance response rather than a decision.

The response format is designed so you can always tell these apart. A 2xx means a decision exists and you should act on it. Any 4xx or 5xx means no decision was made and your fallback applies. A lapsed licence or a maintenance window never surfaces as a BLOCK.

The four outcomes

FLAG and HOLD differ in when a person is involved, not in how suspicious the transaction is. A flagged transaction settles and is reviewed afterwards. A held transaction waits.

Resolving a held transaction

When an analyst reviews a held transaction they record both an investigation outcome and a release decision of RELEASED or REJECTED.

OneView does not call you back. Your system learns the outcome by polling the transaction query API for the reference it submitted and reading the release decision. There is no webhook, callback or queue in the current release. Build the poll into whatever process holds the suspended transaction.

Risk scores

Each rule declares one action: FLAG, HOLD or BLOCK. Rule authors do not assign risk points. The institution's versioned grading policy defines the score range for each decision. The defaults are PASS 0 to 34, FLAG 35 to 49, HOLD 50 to 74, and BLOCK 75 to 100.

The most severe triggered live action determines the decision and receives that range's starting score. A FLAG therefore scores 35 by default, a HOLD scores 50, and a BLOCK scores 75. Multiple rules in the same range add evidence but do not inflate the score or promote the transaction into another decision.

Every rule whose scope matches is evaluated. There is no short-circuit, so an analyst sees every rule that fired rather than only the first.

Data held in your environment

Transaction payloads contain full customer information by design, because regulatory reporting requires it. All of it stays in your PostgreSQL database. None of it is sent to OneView, and none of it appears in licensing traffic.

Rule evaluation records are deliberately narrower: they hold field names, thresholds, timestamps and computed numbers, and never customer data.

An enabled AI investigation sends a separate, non-identifying evidence package to the client-selected external AI provider. It contains transaction characteristics and aggregate patterns needed for the assessment, not the full transaction detail. See AI in OneView for the external-provider boundary.

Reporting

The separately licensed Reporting Sub-module prepares CTR, FTR, SAR, and STR reports as goAML XML from data already retained in this database, with an optional maker-checker approval workflow and optional automatic CTR/FTR generation. It does not submit reports to a regulator or FIU. See Reporting.

Current limitations

• Metering is not applied to transactions in this release. A licensed installation can submit transactions without a volume limit.
• Settlement, reversal and other post-submission status changes have no update path yet. A transaction is evaluated as it was received.
• Reporting prepares and locally records reports but does not submit them to a regulator or FIU, ingest a submission receipt, or synchronise regulator messages. See Reporting.
• Automated case creation from transaction rules is not included. A permitted reviewer can create a licensed Case Management case from a transaction detail page and preserve the transaction as evidence.