Every payment carries risk. The risk that the sender is not who they claim to be. The risk that funds originate from a prohibited source. The risk that a seemingly normal transaction is part of a larger pattern of fraudulent or illicit activity. PayShield was built to assess these risks in real time — before a transaction executes — using a multi-signal scoring engine that operates in milliseconds.

This post explains how PayShield's risk scoring works, what signals it evaluates, and how businesses can configure it to match their specific risk tolerance.

The Core Concept: Every Transaction Gets a Score

When a payment is initiated through the Paymonx platform, PayShield assigns it a risk score between 0 and 100 before execution proceeds. A score near 0 indicates a low-risk transaction with characteristics consistent with the sender's normal behavior and no adverse signals. A score near 100 indicates a transaction with multiple risk indicators that warrants blocking or escalation for manual review.

The score is computed in real time — typically within 50 to 150 milliseconds — using a combination of rule-based checks and machine learning models trained on historical transaction data. Businesses configure threshold values that determine which score bands trigger automatic approval, escalation to a review queue, or automatic blocking.

Signal Categories PayShield Evaluates

PayShield's scoring engine draws on several categories of signals simultaneously:

• Identity signals — Does the sender's name, address, and identity documentation match across the data sources on file? Are there discrepancies between KYC data provided at onboarding and the payment instruction being submitted now?
• Behavioral signals — Is this transaction consistent with the sender's historical payment patterns? A business that normally sends $10,000 to supplier accounts in Mexico sending a $200,000 instruction to a new account in a different jurisdiction is a behavioral outlier that warrants scrutiny.
• Counterparty signals — Is the receiving account or entity on any sanctions lists? Has the receiving account been associated with previous suspicious activity in the Paymonx network? Does the account's registration country match the instruction details?
• Network signals — Are there other transactions in the Paymonx network that share characteristics with this one? Payment fraud often involves coordinated attacks across multiple accounts. Network-level pattern detection can identify these correlations even when each individual transaction appears legitimate in isolation.
• Contextual signals — What is the time of day? What device or API client initiated this request? Is the originating IP address consistent with previous sessions? These contextual factors contribute to the overall picture of whether a transaction matches expected behavior.

How the Scoring Engine Combines Signals

Individual signals feed into a weighted scoring model. Rules-based checks — such as sanctions list matching — are deterministic: a hit on a sanctions list produces an automatic block regardless of the score from other signals. For non-deterministic factors, the model weights each signal based on its predictive value and combines them into the final score.

The model is retrained on a rolling basis as new transaction data becomes available. Fraud patterns evolve, and a scoring model trained only on historical data will gradually lose accuracy as attackers adapt their techniques. PayShield's model update pipeline ensures that emerging fraud patterns identified through manual review are incorporated into the model and deployed quickly.

Configurable Thresholds for Different Risk Profiles

Not every business has the same risk tolerance. A marketplace focused on micro-transactions may accept higher false positive rates to minimize fraud loss. A B2B platform processing large wire payments may prioritize minimizing false positives to avoid disrupting legitimate payments. PayShield allows businesses to configure threshold values and action policies through the Paymonx dashboard.

Three threshold values define the policy:

• Auto-approve threshold — transactions scoring below this value are automatically approved without intervention
• Review threshold — transactions scoring between the auto-approve and review thresholds are queued for human review before execution
• Auto-block threshold — transactions scoring above this value are automatically blocked and the sender is notified to contact support

Why Real-Time Scoring Matters

The value of real-time scoring over post-transaction monitoring is straightforward: blocking a payment before it executes prevents loss. Once funds have moved, recovery is difficult and often incomplete. Post-transaction monitoring can identify fraud for reporting and regulatory purposes, but it cannot recover funds that have already been disbursed.

PayShield's pre-execution scoring is one of the most important safeguards Paymonx provides to the businesses on its platform. It operates transparently within the payment flow — adding no perceptible latency to legitimate transactions while catching the patterns that human reviewers would miss at scale.

For businesses that want to understand more about PayShield's configuration options or review their current risk policy settings, the Paymonx support team is available to provide a guided walkthrough of threshold optimization based on your transaction data.