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.

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 an outcome band and a number of risk points. Each band has a ceiling configured for the installation — by default 50 for review, 65 for hold and 75 for reject.

Scores do not accumulate across bands. Within a band the points of every rule that fired are added and capped at that band's ceiling; the transaction's score is then the highest band score reached. A transaction that trips both a review rule and a reject rule scores 75, not 125, and its outcome is the more severe of the two.

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.

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.
• Regulatory report generation and filing are not included.
• Case management beyond per-transaction review is not included.