Transaction Monitoring
Zyphe's Transaction Monitoring watches payment activity in real time. Your integration reports each payment event (deposit, withdrawal, or transfer) to Zyphe, the event is evaluated synchronously against your organization's enabled monitoring rules, and the response carries an Allow, Review, or Block decision — before your platform moves any funds.
Because Zyphe also verifies your users, every monitored transaction is tied to a verified identity: rules can combine transactional signals (amount, counterparty, country, timing) with identity signals (KYC risk score, account age) in a single evaluation. This closes the loop between onboarding (KYC/KYB), screening (AML), and ongoing activity — full-cycle compliance from the first verification to every subsequent payment.
How it works
-
Your application reports the transaction event, referencing the verified identity it belongs to.
-
Zyphe resolves the identity and counterparty, and enriches the event with derived fields (hour of day, business hours, country of the counterparty's IBAN, …) and matches against your managed lists.
-
Every enabled rule is evaluated. Each rule that fires contributes a probability — its confidence that the transaction is risky.
-
The contributions are combined into a single
P(risk)with a probabilistic union (noisy-OR):P(risk) = 1 − ∏ (1 − pᵢ) -
P(risk)is compared against your organization's thresholds to produce the decision, which is returned synchronously so your platform can hold or reject the payment inline. -
Rules flagged with Raise alert additionally create a review-queue alert and notify your webhook.
| Condition | Decision |
|---|---|
P(risk) below the review threshold | Allow |
P(risk) ≥ review threshold | Review |
P(risk) ≥ block threshold | Block |
Both thresholds are configurable per organization — see Settings and Alerts.
What you can do
- Screen every payment in real time — get a synchronous Allow / Review / Block verdict with full fired-rule provenance, and decide inline whether to execute, hold, or reject.
- Author your own rules — build boolean or banded-metric rules over transaction, list, and identity fields with a visual condition builder; every rule change is versioned and auditable.
- Start from a regulator-informed catalog — instantiate jurisdiction-tagged rule templates (with regulator citations such as UIF indicatori di anomalia and FCA/JMLSG) instead of starting from scratch.
- Curate lists once, apply everywhere — country-risk sets, keyword packs, and counterparty block/allow lists referenced by key from any rule.
- Backtest before going live — dry-run a rule against your stored transactions and compare simulated decisions with the stored baseline; nothing is persisted or billed.
- Route alerts to your review workflow — rules can raise alerts that appear in the transaction detail and fire a signed webhook to your systems.
- Rehearse in the sandbox — seed a deterministic synthetic transaction book, with a controllable share of suspicious patterns, through the real ingest path.
Key concepts
| Transaction | A payment event (deposit, withdrawal, or transfer) reported by your integration, idempotent on your external ID |
| Rule | A versioned condition over transaction, list, and identity fields that contributes a probability when it fires — see Rules and Templates |
| Rule template | A catalog entry — jurisdiction-tagged, with regulator citations — you can instantiate into your own rule set with one click |
| List | A managed set of countries, keywords, or counterparties referenced by rules — see Lists |
| Decision | The synchronous verdict — |
| Alert | A review-queue entry raised by a rule with Raise alert, also delivered via webhook — see Settings and Alerts |
Dashboard sections
The Transaction Monitoring area of the dashboard is organized in five sections:
| Transactions | Every monitored payment event with its status, decision, |
| Rules | The enabled rule set, the rule builder, per-rule version history, and backtesting |
| Rule Templates | The jurisdiction-tagged catalog to bootstrap your rule set from |
| Lists | Country-risk sets, keyword packs, and counterparty block/allow lists referenced by your rules |
| Settings | Decision thresholds, the timezone driving time-of-day rule fields, and the alert webhook |
Next steps
- Explore ingested events on the Transactions page — or seed sample data in the sandbox.
- Configure rules or instantiate templates.
- Curate the lists your rules reference.
- Tune thresholds and wire up the alert webhook in Settings and Alerts.
The ingest and read endpoints for reporting transactions from your backend are documented separately in the API reference (coming soon).