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, unless another control such as blacklist screening ran, 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.

Every transaction is recorded against an account holder: your own customer or general ledger account whose book the entry posts to. On an outbound transaction the account holder is the sender; on an inbound transaction it is the recipient, and the external sender is the counterparty. The account holder is never simply "the sender". See Submitting transactions.

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 being updated, it returns an error or is unreachable rather than returning 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 five 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 list endpoint, GET /api/transactions?transactionId=<id>, with the transaction ID returned when it submitted the transaction, 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. Blacklist, PEP and sanction screening, and geography risk hits are combined the same way, with the most severe result winning.

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.