Revenue at Risk (live), CyberSource

Metrics type: Key Metrics • Category: Payment Gateway

Live decline-driven revenue loss while the spike is active.

At a glance

Live, real-time estimate of revenue being lost right now due to an in-progress decline-rate spike. Not a 30-day rear-view mirror; an active, minute-by-minute “money is leaking out the bottom of the bucket while you read this” number. Fires whenever the current decline rate exceeds the rolling 30D baseline by a threshold and the commerce platform shows checkout traffic in the same window. The single most board-pack-friendly card during a payment incident.


The formula	`(current_decline_rate − baseline_decline_rate) × commerce_sibling.checkout_attempts_per_min × avg_order_value × elapsed_minutes_since_spike_started`. Cross-platform derived from CyberSource decline data joined to the connected commerce platform’s live checkout pulse.
Numerator components	(1) Excess decline rate, current 15-minute rolling decline rate minus 30-day baseline. (2) Live checkout attempts per minute, from the connected commerce platform’s live checkout-funnel pulse. (3) AOV, 30-day rolling average. (4) Spike duration, time since the alert fired (or since decline rate crossed the +2σ threshold).
What “live” means	Updates every 60 seconds. Reads `/tss/v2/searches` for the most recent 15 minutes and queries the commerce-platform’s live checkout-funnel KPI. Goes back to $0 when the spike resolves (decline rate returns within +1σ of baseline).
What it doesn’t count	Disputes, refunds, and post-incident recoverable revenue. This card is forward-looking only: “right now, while I’m watching, this amount of revenue is at risk.” For the post-incident post-mortem use Recoverable Revenue (decline-driven).
Required connectors	CyberSource (this connector) AND a commerce-platform connector (Shopify, BigCommerce, or Adobe Commerce). The card grays out if no commerce sibling is connected because the formula needs `checkout_attempts_per_min` from the storefront.
Currency	Single currency at sync time. For multi-currency global merchants, the engine sums per-currency at fixed FX (current period rate) for a single dashboard number, with the per-currency breakdown on hover.
Refunds / disputes	Excluded. This is decline-driven revenue at risk, not retroactive write-downs.
Failed / declined payments	Counted (these ARE the at-risk revenue).
Time window	`RT` (real-time, 60-second refresh cycle during an active spike).
Alert trigger	`> $0`. The card only shows a non-zero number while a spike is active; any non-zero value is by definition an active incident.
Roles	owner, finance, operations, on-call

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 for ecommerce + Adobe Commerce for the storefront. On the morning of 09 Apr 26 at 09:42 UTC, Vortex IQ Nerve Centre fires cs_alert_decline_spike (decline rate jumped >2σ over the 1h baseline). The on-call payments lead opens the Decline Spike vs Checkout Funnel Drop card and confirms the storefront is also showing ~6% drop in checkout completion. This card lights up. State at 10:15 UTC (33 minutes into the spike):

Component	Value	Source
Current 15-min decline rate	11.4%	`/tss/v2/searches` (last 15 min)
30-day baseline decline rate	5.1%	`/tss/v2/searches` (rolling 30D)
Excess decline rate	6.3pp	(computed)
Live checkout attempts / min	84	Adobe Commerce checkout-funnel pulse
30-day avg order value	$147	(rolling)
Elapsed minutes since spike start	33	(timer started 09:42 UTC)

Revenue at Risk (live)
  = excess_decline_rate × checkout_attempts_per_min × AOV × elapsed_minutes
  = 0.063 × 84 × $147 × 33
  = $25,673

That is the dollar value of revenue lost between 09:42 and 10:15 UTC due to the decline spike, calculated against the rolling baseline. The card displays “

25,673 at risk and counting" and projects forward at the current burn rate (~

778 / minute) so the on-call lead can size the urgency. Five things worth noticing during a real incident:

The number grows linearly while the spike persists. Every minute adds ~ $778 at the current burn rate. This is what makes the card so useful, the operator can immediately convert "decline rate spike" into "we're losing$ X every minute” for the incident commander or CFO call.
Checkout attempts per minute matters as much as decline rate. The same 6.3pp excess decline rate during a midnight-quiet window (10 attempts/min) is only ~ $93/min of risk; during peak afternoon shopping (84 attempts/min) it's$ 778/min. The card incorporates this naturally so the dollar number always reflects the actual revenue exposure.
The card goes back to $0 when decline rate returns to baseline. This is intentional and important: the card is forward-looking. After the spike resolves, the post-mortem uses Recoverable Revenue (decline-driven) to estimate what could be won back via dunning / retry.
Root cause investigation runs in parallel. While this card is counting, the operator should be checking Top Decline Reasons (which bucket spiked?), Top Declining Issuers (single-issuer outage?), Decision Manager Score Mix (recent rule pack deploy?). For this incident the root cause was a Decision Manager rule pack deployed at 09:35 UTC that over-weighted AVS-mismatch on non-US issuers; rolled back at 10:38 UTC and the spike resolved within 4 minutes.
Total incident loss came in at ~$54,000. The spike ran from 09:42 to 10:42 UTC (60 minutes), with the final minutes at lower burn rate as decline rate began returning to baseline. This becomes the line-item on the incident post-mortem and the case for tighter DM rule-pack deployment review going forward.

This card is the only Nerve Centre card calibrated specifically for the “active incident” use case. It is not designed to read in steady state (it shows $0 most of the time, by design); when it shows a number, that’s the operator’s signal to drop everything and investigate.

Sibling cards merchants should reference together

Card	Why pair it with Revenue at Risk (live)
Decline Spike vs Checkout Funnel Drop	The cross-platform companion. This card is the dollar number; that card is the dual-axis chart showing the decline + funnel correlation.
Decline Rate Spike Alert	The alert that triggers this card to light up.
Top Decline Reasons	The first card to open during an active incident: which reason spiked?
Top Declining Issuers	Single-issuer-outage diagnostic.
Decision Manager Score Mix	Was a recent fraud rule pack the cause?
Recoverable Revenue (decline-driven)	The post-incident view: of the revenue lost during the spike, how much could be won back via dunning / retry?
Decline Rate	The base metric this card watches.
Payment Health Score	The composite that drops sharply during an active spike.
Adobe Commerce / BigCommerce / Shopify `checkout_funnel`	The live checkout-attempts pulse that feeds the formula.

Reconciling against the vendor’s own dashboard

Where to look in CyberSource Business Center (EBC2): This card has no direct EBC2 counterpart, it’s a Vortex IQ-derived cross-platform signal that joins CS decline data to commerce-platform live checkout data. The closest EBC2 view is Transactions → Search filtered to last 15 minutes; from there the operator can see decline-rate-now but not the dollar projection. For the active-incident workflow:

EBC2 → Transactions → Search, confirm the spike is real-time on CS side.
EBC2 → Decisions → Decision Manager → Performance, was a rule pack recently deployed?
[Adobe Commerce / Shopify / BigCommerce checkout-funnel dashboards], confirm the storefront is also seeing checkout drop.

Why our number may legitimately differ from a hand-rolled equivalent:

Reason	Direction	What to do
15-minute rolling window. We compute current decline rate over the most recent 15 minutes. Smaller windows are noisy; larger windows lag the spike.	The number can jump as the spike crosses the 15-min boundary.	Treat as live indicator, not a forensic figure. The post-incident Recoverable Revenue card uses tighter window logic.
AOV is rolling 30D. If the spike happens during a sale event with abnormal AOV, our projection may understate / overstate.	Either direction.	Use the post-incident card with actual transaction-level AOV for the exact loss number.
Multi-currency FX. We use current-period FX rates to sum into the dashboard’s display currency.	Tiny drift versus end-of-period FX.	n/a for incident response.
Commerce sibling refresh. The checkout-attempts-per-min KPI is itself refreshed on a 60-second cycle.	Small lag possible during very fast-moving spikes.	Both connectors must be live for accurate output; the card grays if either is offline.

Cross-connector reconciliation:

Comparison	Expected relationship	When divergence is legitimate
`cs_revenue_at_risk_live` ↔ commerce platform’s own funnel-drop alert	They co-fire within 60 seconds of each other during a real CS-driven incident.	If commerce funnel drops without this card lighting up, the cause is storefront-side (page broken, JS error) not payment-side.
`cs_revenue_at_risk_live` ↔ post-incident `cs_xc_recoverable_revenue`	The latter is typically a smaller number (some of the at-risk revenue is winnable back via dunning / retry; not all).	If recoverable >> at-risk, the formula calibration needs review.
`cs_revenue_at_risk_live` ↔ `cs_payment_health_score`	The composite always drops while this card is non-zero.	n/a (causal relationship).

Known limitations / merchant FAQs

**Why does this card show

0 most of the time?** By design. It's a forward-looking active-incident card; when there is no active spike (decline rate within +1σ of baseline), there's no revenue at risk to project. The card shows

0 in steady state and only fires during real incidents. If the operator wants a steady-state lost-revenue figure, see Recoverable Declines (soft). What’s the difference between this card and Recoverable Revenue? Time horizon. This card is forward-looking, real-time: “right now, while I’m watching, X dollars are leaking out per minute.” Recoverable Revenue is backward-looking, monthly: “of the soft declines we accumulated last month, how much could we win back via dunning / retry next month?” The two are complementary, not redundant. My commerce platform isn’t connected, why is this card grayed out? The formula needs the commerce platform’s live checkout_attempts_per_minute to compute. Without it, “decline rate spike” is incomplete information (the same +5pp spike during 10 attempts/min is trivially small revenue; during 100 attempts/min it’s catastrophic). Connect Adobe Commerce, BigCommerce, or Shopify to the same Vortex IQ workspace and the card lights up. The card fired but my commerce platform shows no funnel drop. What does that mean? Usually one of three things: (1) the decline spike is happening on retry / recurring traffic that doesn’t go through the storefront checkout funnel (B2B corporate billing, subscription auto-bill); (2) the customer is rebounding to alternate tender (Apple Pay, PayPal) successfully, so the storefront completes despite CS declines; (3) the spike is on a small subset of cards (e.g. one issuer) that only affects ~3% of attempts. Drill into Decline Spike vs Checkout Funnel Drop to see the dual-axis view. Can I trust this number for my incident post-mortem? For real-time incident response, yes, it’s the right size-of-problem signal at the time. For the formal post-mortem with finance attached, use Recoverable Revenue (decline-driven) which uses transaction-level decline data after the incident closes. The two should agree within 10, 20% on a typical incident. What’s a good “burn rate” threshold for incident escalation? Depends on the merchant’s scale. For a Fortune-500 enterprise,

1,000/min sustained is typically the on-call escalation threshold;

5,000/min sustained is incident-commander territory. For a mid-market merchant, those thresholds scale down 5, 10x. The card displays the burn rate alongside the running total so the operator can decide. Does this card fire on planned maintenance or known issuer outages? It fires on the underlying decline-rate spike regardless of cause. If ops knows that, e.g., Capital One has a known outage announced via Visa OPS Bulletin, the operator should still investigate (sometimes the announced outage is a small subset of the actual issue). Vortex IQ doesn’t have a “suppress alert during planned issuer outage” feature today; it could be added but most enterprise merchants prefer to see the alert and confirm cause manually. My multi-currency global merchant, what currency does this card display? The dashboard’s display currency at sync-time FX. The per-currency breakdown is on hover. For the most accurate per-currency view during an active incident, also keep Revenue by Currency open in a sibling tab. Can I get historical data on this card? The historical record of every time this card has fired (with start time, end time, peak burn rate, total at-risk dollars) lives in the Vortex IQ incident-history view. The card itself only displays the live state; the history shows up alongside the alert log.

Tracked live in Vortex IQ Nerve Centre

Revenue at Risk (live) is one of hundreds of KPI pulses Vortex IQ tracks across CyberSource and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. Start for free or book a demo to see this metric running on your own data.

Get Started

The AI OS

At a glance

Calculation

Worked example

Sibling cards merchants should reference together

Reconciling against the vendor’s own dashboard

Known limitations / merchant FAQs

Tracked live in Vortex IQ Nerve Centre

​At a glance

​Calculation

​Worked example

​Sibling cards merchants should reference together

​Reconciling against the vendor’s own dashboard

​Known limitations / merchant FAQs

​Tracked live in Vortex IQ Nerve Centre

At a glance

Calculation

Worked example

Sibling cards merchants should reference together

Reconciling against the vendor’s own dashboard

Known limitations / merchant FAQs

Tracked live in Vortex IQ Nerve Centre