Screening before a transaction reaches a provider
Antifraud is now available as an optional module in the tenant manager. Instead of reviewing a transaction after it has already gone to a provider, screening runs on the transaction create path, before the transaction is handed off. That timing is the point: a decision made here can block a transaction rather than merely record what happened to it afterward.
Velocity and pattern checks across your own data
The module evaluates counts and amounts across the tenant's own scope, so a risk signal is never looked at in isolation. Checks can be applied at different levels:
- Per card
- Per customer
- Per merchant
Thresholds for these checks are set by the operator, which means screening reflects how a specific tenant defines risk rather than a single fixed rule applied everywhere the same way.
Risk control that stays targeted
Risk is rarely spread evenly across a merchant book. A high-risk merchant can be screened hard, with tighter thresholds and more checks, without imposing that same friction on every other merchant on the tenant. Screening stays proportionate to where the risk actually sits, instead of slowing down the whole platform to cover one source of it.
Reasons, not silent declines
The rules behind a decision are inspectable. When a transaction is declined, the merchant gets a reason rather than an unexplained block. That visibility matters for merchants who need to understand their own flows and adjust them, rather than guessing why a payment failed.
Evidence ready before a chargeback arrives
Screened decisions are retained. When a chargeback lands later, the evidence about what the screening knew and decided at the time is already there, rather than having to be reconstructed after the fact under time pressure.
Availability
Antifraud is enabled per billing plan and enforced at the transaction create path, so the control applies consistently across every transaction a tenant processes, inside the tenant manager.
