At a glance
Real-time anomaly-detection alert that fires when CyberSource decline rate exceeds 2 standard deviations above the rolling 1-hour baseline. The Nerve Centre’s first-line incident detector for payment-side problems: a single Decision Manager rule pack misfire, an issuer outage, or a checkout-script bug can show up here within 60-90 seconds of the cause. The alert that triggers operator response on every other CyberSource card (Revenue at Risk, Decline Spike vs Funnel Drop, etc).
Calculation
Calculated automatically from your CyberSource data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A North American electronics retailer running CyberSource. On 09 Apr 26 at 09:42 UTC, a Decision Manager rule pack deployed by fraud-ops at 09:35 UTC begins driving decline rate up. The alert fires. State at 09:42 UTC:
The alert sends pages / Slack / email per the merchant’s notification config and lights up Decline Spike vs Checkout Funnel Drop and Revenue at Risk (live).
Five things worth noticing during the incident:
- Detection latency is 60-120 seconds. The cause kicked in at 09:35 UTC; the alert fired at 09:42 UTC. The 7-minute lag is the time for the spike to actually start, accumulate enough volume in the 15-min window to register against baseline, and complete the 60-second detection cadence. For most enterprise incidents this is fast enough; for very fast-moving incidents (DDoS-driven decline spikes, multi-million-attempt-per-minute fraud incidents) the lag can feel slow.
- Anti-flap logic prevents alarm fatigue. Once the alert fires, it stays “armed” for 30 minutes. If the operator rolls back the cause at 10:38 UTC and the rate returns to baseline, the alert resolves automatically. If the rate dips and re-spikes within the 30-minute window (e.g. partial rollback), the alert doesn’t re-page; it surfaces the re-spike on the existing incident timeline.
- The 2σ statistical threshold matters. A naive “decline rate > 6%” alert would fire on every busy Friday afternoon when normal variation pushes the rate above 6%. The 2σ-vs-baseline threshold adapts: at 9am on a typical Tuesday, baseline σ might be 0.3pp so the alert fires at 5.8% absolute; on Black Friday with high traffic σ might be 0.6pp so the alert needs 6.2% absolute. This is what makes the alert actionable across all conditions.
- Volume floor prevents low-traffic false positives. During quiet hours (3-5am UTC for a North American merchant), the 15-min window might have only 80 attempts; even small absolute changes look statistically significant. The 100-attempt floor suppresses these. Most enterprise merchants doing high-volume processing rarely hit the floor; mid-market merchants on quiet hours might.
- Pairs with the cross-platform diagnostic. The alert fires; the operator opens Decline Spike vs Checkout Funnel Drop to confirm whether storefront completion is also dropping (real revenue loss) or stable (alternate-tender absorption). If storefront completion drops, this is a real incident; if it doesn’t, the alert is signaling a CS-side technical issue that customers are absorbing with workarounds. Different remediation paths.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look in CyberSource Business Center (EBC2): CyberSource Business Center does not have a parallel anomaly-detection alert; this is a Vortex IQ-derived signal. The closest equivalent EBC2 views during an active alert:- EBC2 → Transactions → Search, filter to last 15 minutes for current decline-rate confirmation.
- EBC2 → Decisions → Decision Manager → Performance for the DM-rule-pack diagnostic.
- EBC2 → Reports → Conversion Detail Report for transaction-level dump (post-incident analysis).
Cross-connector reconciliation:
Known limitations / merchant FAQs
The alert fired but I think it’s a false positive. How do I check? Three diagnostic checks: (1) Is current 15-min decline rate truly elevated vs baseline, or just slightly above? Open Decline Rate and look at the current value vs the 1-hour history. (2) Is one specific decline reason driving it? Open Top Decline Reasons; real spikes always have a single dominant reason. (3) Is one specific issuer driving it? Open Top Declining Issuers; real issuer outages are concentrated. If all three look “spread out and small”, it’s likely a noise alert. What’s a typical alert frequency for an enterprise merchant? Most enterprise merchants see 2-6 fires per month. Higher than 8-10/month suggests either (a) the merchant has genuine ops issues that need addressing, or (b) the threshold needs re-tuning (the merchant is naturally noisier than the 2σ default expects). Below 1/month suggests the threshold is too loose (real incidents are being missed); recalibrate to 1.5σ. Can I tune the alert threshold? Yes, in the manifest. The default2σ vs 1h baseline is calibrated for enterprise stability. For high-volume merchants doing >100k transactions/hour, the default might be too sensitive (every issuer hiccup fires); tune to 2.5σ. For low-volume merchants doing <10k transactions/hour, the default might be too loose; tune to 1.5σ.
Why 1-hour baseline and not longer?
Trade-off between adaptiveness and stability. 1 hour reacts quickly to evolving conditions (a Decision Manager rule deploy that’s been running for 30 minutes is “the new normal” and shouldn’t keep firing). Longer baselines (4h, 24h) take longer to adapt and would keep firing on the same incident. Shorter baselines (15-30 min) are too noisy.
What if my decline rate is naturally elevated for the time-of-day?
The 1-hour baseline adapts. At 3pm with normal-time-of-day decline rate of 6%, the alert wouldn’t fire on 6.5% (within +1σ). At 3am with normal decline rate of 4.2%, the alert WOULD fire on 5.5% (well above +2σ for that hour’s lower variance). This adaptiveness is the point.
Does the alert distinguish “real spike” from “fraud incident”?
Not directly. The alert just says “decline rate is unusually high right now”; the operator has to diagnose whether it’s a fraud incident, an issuer outage, a DM rule misfire, or a checkout-script bug. The companion alerts (Fraud Velocity Alert for fraud, 3DS Failure Alert for 3DS) help disambiguate when they fire alongside.
My team is getting alert fatigue. What can I do?
First check if it’s true alert fatigue (too many fires) or perceived fatigue (alerts firing on real incidents but the team ignoring them). For true: tune threshold up (2.5σ instead of 2σ) or extend the baseline window. For perceived: review the response process, ensure the team has clear playbooks for the top 5 alert causes (DM rule deploy, issuer outage, etc).
Does the alert fire during planned maintenance?
Yes, by default. If ops knows a Decision Manager rule pack deploy is planned (with expected decline-rate impact), suppress the alert manually for the deploy window. Vortex IQ supports a “scheduled maintenance” suppression option in the alert config.
My multi-currency global merchant, does the alert work across currencies?
Yes, the alert watches the rate (currency-neutral). Spikes in one currency / region will show up in the global rate. For per-region alerting (e.g. EU-only spike), configure region-specific alert variants.
What’s the relationship to other CyberSource alerts?
This is the core decline-rate anomaly alert. The siblings: Fraud Velocity Alert watches DM-score patterns specifically, 3DS Failure Alert watches 3DS challenge-success-rate, Settlement Stuck watches payouts, Dispute Threshold Watch watches the regulatory dispute-rate ceiling. The decline-spike alert is the most-frequently-fired of these by a meaningful margin because decline incidents happen more often than the others.