Authoring rules
Transaction Monitoring → Rules is where rules are written. Viewing requires Read transaction rules; creating and editing requires Manage transaction rules. Reading transactions does not imply either.
A rule has four parts
Applies to selects which transactions the rule is evaluated against — direction, payment method, channel, initiator type, counterparty type, currency, and the intra-bank, GL and cross-border flags. Leave a facet empty to match every value. Within a facet, values combine with or; across facets they combine with and.
Conditions are what make it fire. Conditions are built from a fixed catalogue of fields, so the field picker offers only what OneView can evaluate and the operator picker only what makes sense for the chosen field's type. Group conditions with Match all or Match any, and nest groups where needed.
Outcome is the band: Review, Hold or Reject.
Risk points is the rule's contribution to the score, capped by the band's ceiling.
Counting over a window
Select Count over a window as a condition's field to detect velocity and structuring: how many transactions share the same account, customer or counterparty within the last hour, six hours, day, week or month.
The window covers transactions already recorded — the one being evaluated is not counted, because it has not been stored yet when the rule runs. Set thresholds accordingly.
Windows are a fixed set, and the subjects a rule can count over are limited to those the database can answer quickly. Both restrictions exist so a rule cannot make transaction submission slow.
Ledger conditions
For transactions carrying multi-leg journal postings, Ledger condition tests individual legs: whether any leg touches a given GL code, or whether every leg is in a given currency. Common whole-journal facts — leg count, debit and credit totals, and whether the journal balances — are available as ordinary fields without needing a ledger condition.
Shadow mode
Every new rule starts inactive and in shadow mode.
A shadow rule is evaluated and its result recorded, but it contributes nothing to the decision returned to your systems. This is how a rule is tuned against real traffic before it affects anything. When you are satisfied, edit the rule and change its mode to live.
The two settings are independent: inactive means the rule does not run at all, shadow means it runs without effect.
Editing and history
Rules are editable, and every edit creates a new immutable version. You are asked for a reason, which is stored with the version and the author.
Evaluations record the exact version that ran, so an explanation from six months ago still shows the rule as it was then, even after the rule has been renamed or its threshold changed.
Rules cannot be deleted. Archive is the terminal state: an archived rule cannot be edited or reactivated, and its name becomes available for reuse. Its history and past evaluations are preserved.
Band ceilings
Ceilings are installation policy, not per-rule. The defaults are 50 for review, 65 for hold and 75 for reject, and they must not decrease with severity.
Ceilings are versioned. A change applies to future evaluations only; past decisions remain explainable under the ceilings that produced them.
What a rule cannot see
Rules address a curated catalogue of fields rather than arbitrary payload contents. Two consequences are worth knowing before you plan an integration:
- Custom fields your core banking system sends are not addressable unless the catalogue includes them. Extending it requires a OneView release. Raise the need with support before relying on a field.
- Identity numbers, names, dates of birth, addresses and card numbers cannot be compared against. Where a rule needs them, the catalogue exposes presence instead — for example whether an identity number is present at all. This is what keeps stored rule evidence free of customer data.