Transaction Monitoring
Transaction Monitoring is Zyphe's real-time payment-screening capability. Where KYC and KYB verify who a user is at onboarding and AML screens them against sanctions, PEP, and adverse-media lists, Transaction Monitoring watches what they do afterwards: evaluating each payment event as it happens and returning an Allow, Review, or Block decision before your platform moves any funds.
Because Zyphe already verifies your users, every monitored transaction is tied to a verified identity. A single rule can combine transactional signals (amount, counterparty, country, timing) with identity signals (KYC risk score, account age). This is what closes the loop between onboarding, screening, and ongoing activity: full-cycle compliance from the first verification to every subsequent payment.
The decision model
Your integration reports a transaction event; Zyphe evaluates it synchronously against your organization's enabled rules. Each rule that fires contributes a probability, and the contributions are combined into a single risk probability with a probabilistic union (noisy-OR):
P(risk) = 1 − ∏ (1 − pᵢ)
P(risk) is compared against your organization's thresholds to produce the verdict:
| Condition | Decision |
|---|---|
P(risk) below the review threshold | Allow |
P(risk) ≥ review threshold | Review |
P(risk) ≥ block threshold | Block |
This is the same combinator used by Zyphe's generalized scoring engine. See Scoring for the underlying mathematics of tags, banding, and thresholds. Transaction Monitoring applies it to per-transaction rules rather than to verification-flow signals.
Privacy-preserving by design
Like the rest of Zyphe, Transaction Monitoring works over decentralized identity: only the minimal attributes needed to evaluate a rule are read from the user's vault, and every evaluation is written to a hash-chained audit trail. Personal data is not centralized to enable monitoring.
Sandbox-first
Transaction Monitoring can be enabled in sandbox only: a prospect gets the full rule builder, templates, lists, and evaluation loop against synthetic data, with no production entitlement and no data-processing agreement required. This makes it possible to design and backtest a rule set before any real payment traffic or contract is in place.
Where to go next
This page is the conceptual overview. To configure and operate Transaction Monitoring, reporting events, authoring rules, instantiating regulator-informed templates, curating lists, tuning thresholds, and handling alerts. See the Transaction Monitoring guides.