Risk intelligence should protect both the transaction and the processing relationships it depends on.
Signals are collected before routing so the decision can consider both the transaction and the rail it is about to use. Each signal is visible on the transaction record — no opaque number without a reason.
| SIGNAL | VALUE | STATE |
|---|---|---|
| velocity (card, 10 min) | 6 attempts | ELEVATED |
| decline pattern | 4 × 51 in sequence | ELEVATED |
| issuer country | matches billing | NORMAL |
| authentication | not attempted | NEUTRAL |
| MID exposure (24h) | within threshold | NORMAL |
Controls can be configured as explicit conditions with a defined outcome, so a risk team can review, test and change them without guessing how a model will behave.
WHEN velocity.card_10m >= 5
AND decline_pattern = "repeated_51"
THEN outcome = STOP
reason = "card_testing_suspected"
WHEN amount > 2500 AND auth = "NONE"
THEN outcome = CHALLENGEA risk decision changes where the transaction goes next. That makes risk part of payment control rather than a gate in front of it.
Acquirers monitor fraud and chargeback ratios per merchant account. Stopping card-testing traffic before it reaches a MID protects the processing relationship, not just the single payment.
10:41:0212 attempts blocked before forwardingOK10:41:02MID_US_01 decline ratio unaffectedOK10:44:19velocity threshold approaching on EU_PRIMARYWARNLet's discuss the infrastructure your business needs.