Fraud

Real-time card fraud decisioning inside the authorisation.

Processor agnostic. Embeddable components for the stack you already run.

Experience

Walk through your authorisation flow

Start

Brochure

An authorisation gives you a few hundred milliseconds to decide whether a transaction is your cardholder or somebody using their card. There is no second look, and no opportunity to revisit the decision once the response has gone back to the network.

Kenshyn, our real-time card fraud decisioning engine, is built for that position. It receives the authorisation event, evaluates your rules against the transaction and against the history it maintains for that card, and returns a decision within a budget you set.

Features

A decision inside the authorisation

Every authorisation follows the same path, within a response budget and internal cut-off set per deployment. Where the cut-off is reached, the engine returns your configured fallback decision, marked as a fallback.

Rules that are yours

Rules are expressed over the fields of the transaction and the features the engine derives from the history it holds for that card. Thresholds, window lengths and response codes are configuration, so a rule can change without a release.

History built from the event stream

Spend and count aggregates over rolling windows, distinct countries and merchants, declines and authentication failures, maintained per card and corrected for reversals and confirmations.

Working with the scheme score

The network risk score arriving with the transaction becomes one term in a rule alongside the card's own history. Rules remain evaluable in its absence.

Change as a controlled act

A rule set moves through draft, validated, shadow, active and retired. Versions are immutable, and the approver cannot be the author.

Shadow evaluation

A candidate rule set is evaluated against live traffic without enforcing anything, which is how thresholds are tuned on your own portfolio.

What the rules see

The feature model is built from the event stream. Authorisations, notifications, confirmations and, where available, authentication events are reduced into the card state, including the corrections: declines that never became spend, reversals both full and partial, and confirmations that adjust an amount already counted.

Score and attribute

Network risk score thresholds, amount, currency and merchant category, entry mode, card present or not present.

Velocity

Transaction counts and spend totals over rolling windows, declines and authentication failures, distinct merchants in a window.

Geography

Country allow and deny logic, distinct countries in a window, impossible travel between card-present events.

Pattern and derived

Card age and first-use behaviour, repeat attempts after a decline, deviation from the card's own history.

Enforcement

When the engine acts

Card controls

Block or freeze the card, with the reason recorded.

Usage controls

Velocity and daily limits, channel controls including e-commerce and ATM, card-not-present and international controls. Selective restriction in place of a blanket block.

Cardholder verification

An outbound verification session on a suspect transaction. The reply confirms or denies the transaction.

Case handling

A case opened in your own case management system or in Pannovate Case Management, with later events attached to the same case.

Key Benefits

Decisions you can explain

The engine records what it decided, why, and what happened next. A redelivered authorisation returns the original decision; it is not evaluated a second time.

Rule-level reporting

How often a rule fired and how those transactions were subsequently labelled, with shadow and active rule sets reported side by side.

Roles and audit

Roles separate viewing, analysis, authorship and approval, and every change and every refusal is written to an append-only audit trail.

Actions that can be undone safely

Where a cardholder confirms that a transaction was genuine, the engine restores only what its own flow restricted.

Identifiers handled deliberately

Search and reporting operate on programme-scoped indexes, not raw card or customer identifiers.

Partitioned by programme

Rules, configuration, thresholds and reporting are scoped to the programme they belong to.

Quiet until it counts

Scope and integration

The engine is processor agnostic by design. It is built against the shape of an authorisation, and the field paths it reads are configuration.

Open Components

The engine, its interfaces and its data model, embedded into whatever stack you run and connected to your case management system.

In BankVault

For customers already using BankVault, rule configuration, case handling and analyst tooling surface there, in the same place the programme is already managed.

What the engine needs

An authorisation event delivered synchronously with a stated time budget, the transaction feed that follows it, and an interface for card status, limits and usage controls.

Product

Transaction Monitoring

Kenshyn decides whether to approve this transaction, now. Anti-money-laundering monitoring and screening ask what a pattern of completed activity says about a customer. Pannovate delivers those through specialist partners, and the two work alongside each other.