Executive Playbooks

Executive Guides

Boardroom-ready playbooks for fraud, payments and risk leaders who need to turn fragmented signals into accountable decisions.

Each guide converts a high-stakes operating problem into questions, metrics, meeting cadences and next actions.

Guides
4 Guides
Updated
August 2026
Format
On-page, no gating
Audience
Executives, Heads of Fraud & Payments

Executive Guide 01 · Updated August 2026

The Executive Guide to VAMP Readiness

What the programme actually measures

Visa’s 2025 fact sheet defines VAMP as [TC40 fraud + TC15 disputes] divided by TC05 settled card-not-present transactions — a count-based ratio, not a value-based one. Volume of low-value disputes therefore matters as much as a handful of large fraud losses.

Pre-dispute resolutions and qualifying CE3.0 fraud can be excluded from the numerator, contingent on timing. In AP, Canada, EU and the U.S., the fact sheet shows an excessive-merchant threshold of 220 bps with at least 1,500 monthly fraud-plus-dispute count, reducing to 150 bps on 1 April 2026. Enumeration thresholds are a ratio of at least 2,000 bps together with a count of at least 300,000 transactions. Confirm current applicability with your acquirer, processor or Visa representative.

10-minute diagnostic

Answer these before your next payments review

  • Can you reproduce last month's VAMP numerator and denominator from your own data?
  • Do you know your current ratio and your distance to the applicable threshold in bps?
  • Do you track the fraud-plus-dispute count, not just the ratio, against the 1,500 monthly floor?
  • Can you name the top three dispute drivers by count for last month?
  • Do you know what share of eligible disputes were resolved pre-dispute inside the timing window?
  • Is one named executive accountable for the ratio across risk, payments and support?

Monthly numerator/denominator reconciliation checklist

  • Pull TC40 fraud counts for the reporting month and reconcile to your internal confirmed-fraud records.
  • Pull TC15 dispute counts and normalise reason codes to your internal taxonomy.
  • Pull TC05 settled CNP transaction counts and confirm the channel scope matches the numerator.
  • List every pre-dispute resolution filed and verify each fell inside its qualifying timing window.
  • List every CE3.0 submission and verify eligibility and timing before assuming exclusion.
  • Recompute the ratio, compare against the acquirer-reported figure, and document any variance.
  • Record the count as well as the ratio; the count qualifies the threshold.
  • Sign off jointly — payments and finance — and archive the working file.

Ownership RACI

VAMP readiness RACI
ActivityRiskPaymentsCX / SupportFinanceAcquirer
Fraud count accuracyACIIC
Dispute count and reason-code normalisationCRCIC
Pre-dispute resolution within timing windowCCR/AIC
CE3.0 evidence quality and submissionRCCIC
Monthly ratio reconciliationCRIAC
Threshold interpretation and effective datesCCIIR/A
Executive and board reportingR/ACICI

R = responsible, A = accountable, C = consulted, I = informed. Threshold interpretation sits with your acquirer because programme applicability is theirs to confirm.

Early-warning dashboard specification

Dashboard specification
PanelMeasureRefreshTrigger
Ratio trendRolling ratio vs applicable threshold, in bpsDailyAny move toward the threshold for three consecutive days
Count trendFraud + dispute count vs the monthly count floorDailyCount pace projecting above the floor
Denominator healthSettled CNP transaction trendDailyDenominator decline of any material size
Driver mixDispute counts by normalised driverWeeklyAny driver rising two weeks running
Exclusion pipelinePre-dispute and CE3.0 items by timing statusDailyAny item within 48 hours of its window closing
Reconciliation varianceInternal ratio vs acquirer-reported ratioMonthlyAny unexplained variance

30/60/90-day action plan

30/60/90-day action plan
WindowFocusOwnerDone looks like
Days 1–30Reproduce the ratio internally; confirm thresholds and dates with the acquirer; normalise reason codesPayments leadA signed-off ratio you can rebuild without help
Days 31–60Stand up the early-warning dashboard; instrument exclusion timing; name a driver owner eachRisk leadDaily visibility and a ranked driver list with owners
Days 61–90Run the first controlled interventions on the top two drivers; establish the monthly reconciliation and board slideAccountable executiveDriver movement explained, cadence running, escalation plan tested

KPI scorecard

VAMP readiness scorecard
KPITypeReview
VAMP ratio and distance to threshold (bps)LaggingDaily / monthly sign-off
Fraud + dispute count vs count floorLaggingDaily
Pre-dispute resolutions completed in window (%)LeadingWeekly
CE3.0 submissions eligible and on time (%)LeadingWeekly
Dispute driver mix shiftLeadingWeekly
Reconciliation variance vs acquirerControlMonthly

Escalation plan

  • Tier 1 — drift detected: driver owner responds within five business days with a named action.
  • Tier 2 — sustained movement toward the threshold: accountable executive convenes risk, payments and support weekly.
  • Tier 3 — threshold proximity confirmed with the acquirer: daily standing review, written remediation plan, board notification.
  • Every tier records the decision, the owner and the expected effect before action is taken.

Common traps

  • Managing the ratio while ignoring the count floor that qualifies it.
  • Assuming an exclusion applies without verifying the timing window.
  • Accepting a reported ratio you cannot reproduce from your own data.
  • Treating non-fraud disputes as a support problem with no network consequence.
  • Quoting fees or penalties internally that no source supports.

Questions for your acquirer or processor

  • Which VAMP thresholds and effective dates apply to each of our regions and MIDs today?
  • How exactly do you compute our numerator and denominator, and can we reconcile line by line?
  • What is your cut-off for a pre-dispute resolution or CE3.0 submission to qualify for exclusion?
  • What reporting will we receive, at what frequency, and with what lag?
  • What is your escalation and remediation process if we approach the threshold?

Executive Guide 02 · Updated August 2026

The Executive Guide to Account Takeover

What the evidence says — and what it does not

Verizon’s 2025 DBIR research reports compromised credentials as an initial access vector in 22% of reviewed breaches. In the analysed SSO-provider data, the median daily credential-stuffing share was 19% of authentication attempts — 25% for enterprise-sized organisations and 12% for small businesses. In the median infostealer case, only 49% of a user’s passwords were distinct.

Median daily credential-stuffing share of authentication attempts

Verizon 2025 DBIR research, analysed SSO-provider data. Cohorts are organisation size bands.

  • Small businesses12%
  • All analysed organisations (median)19%
  • Enterprise-sized organisations25%
View data as a table
Median daily credential-stuffing share of authentication attempts
CohortMedian daily share
Small businesses12%
All analysed organisations (median)19%
Enterprise-sized organisations25%

10-minute diagnostic

Answer these with your fraud and identity leads

  • Do you measure what share of your login attempts are adversarial, and how is that share trending?
  • Are passkeys or phishing-resistant MFA available, and what proportion of active accounts use them?
  • Do you step up on value movement and contact-detail change, or only at login?
  • Can you link a profile change and a subsequent payment or withdrawal as one event?
  • Do you notify the prior contact detail out-of-band when contact details change?
  • Can support retrieve the full session and change history for a reported takeover in one place?

Executive briefing

Lifecycle detection and proportionate control
Lifecycle stageDetection focusControl principle
Pre-login pressureAttempt velocity, infrastructure reuse, known-compromised credentialsSilent controls first; never spend customer friction on bot traffic
AuthenticationDevice recognition, MFA/passkey outcome, geography changeStep up on unrecognised context, not on every login
Post-login sessionNavigation, velocity, device continuityScore silently; hold rather than block
Profile changeEmail, phone, address, MFA method, payout detailsStep up and notify the prior contact out-of-band
Value movementNew instrument, top-up, withdrawal, fulfilment changeScale friction to value; apply a cooling period after a change
RecoveryCustomer report, reversal, reimbursementFast, documented, consistent — slow recovery becomes a dispute

The governing principle is proportionality. Friction applied uniformly costs conversion across the whole base to address risk concentrated in a fraction of it. Friction applied at value movement is both cheaper and more effective.

One-page incident readiness checklist

Before the next incident

  • A named incident owner and a named customer-communications owner, with deputies.
  • A documented trigger for declaring an ATO incident rather than a set of individual cases.
  • A tested ability to force credential and session invalidation for a defined cohort.
  • A tested ability to freeze withdrawals or instrument changes for a cohort without a full outage.
  • Pre-drafted customer and support messaging, reviewed by legal.
  • Support scripts and authority to reverse or reimburse within a stated policy.
  • A retention policy that keeps session, device and change evidence long enough for disputes.
  • A post-incident review that names the control that would have shortened the sequence.

30/60/90-day action plan

30/60/90-day action plan
WindowFocusOwnerDone looks like
Days 1–30Measure credential-stuffing pressure; inventory step-up points; map the value-movement pathsFraud leadA written sequence map with current controls marked
Days 31–60Move friction from login to value movement; add out-of-band notice on contact change; link change-plus-payment eventsProduct + FraudStep-up rate down at login, up at value movement
Days 61–90Run an incident readiness exercise; instrument recovery metrics; report the sequence, not the loginAccountable executiveTested playbook and a board view of value moved and recovered

KPI scorecard

Account takeover scorecard
KPITypeReview
Adversarial share of authentication attemptsLeadingDaily
Phishing-resistant MFA / passkey adoptionLeadingMonthly
Step-up rate at login vs at value movementLeadingWeekly
Confirmed ATO cases and value movedLaggingWeekly
Time from first adversarial signal to containmentLaggingPer incident
Recovery rate and time to customer resolutionLaggingMonthly
Support contacts generated per confirmed caseControlMonthly

Common traps

  • Reporting ATO as a login metric, which hides the value that actually moved.
  • Blanket MFA that costs conversion everywhere to address risk concentrated in a few paths.
  • Treating a profile change and a subsequent withdrawal as two unrelated events.
  • Recovery policies that differ by agent, which turn incidents into disputes.
  • Presenting cybersecurity percentages as merchant fraud rates.

Questions for vendors

  • What exactly do you observe post-authentication, and at what latency?
  • How do you link a profile change to a subsequent payment or withdrawal in one case view?
  • What evidence do you retain, in what format, and can our dispute team use it directly?
  • How is your model retrained, and what governance do we get over threshold changes?
  • What is measured to show effect — attempts blocked, or value protected?

Executive Guide 03 · Updated August 2026

The Executive Guide to Chargeback Governance

What the evidence says

Mastercard says global merchant chargeback costs are forecast to reach $42 billion by 2028, with nearly half reported as fraudulent. This is a forecast, not an observed result, and it is the only external figure used in this guide.

10-minute diagnostic

Answer these with your dispute lead

  • Can you rank last month's disputes by normalised driver, not by raw reason code?
  • What share of eligible disputes were resolved pre-dispute, and within what window?
  • What is your representment win rate by driver, and do you know why you lose?
  • How long does a refund take, and how many disputes arrive after a refund was requested?
  • Is your billing descriptor recognisable to a customer 30 days after purchase?
  • Does anyone own subscription renewal notice and consent as a dispute-prevention control?

Executive briefing: the governance stack

Chargeback governance stack
LayerWhat it doesOwnerFailure signal
PreventionDescriptor clarity, fulfilment reliability, renewal notice, refund speedProduct / OperationsDisputes rising on non-fraud drivers
Pre-dispute resolutionResolve eligible cases before they become disputes, inside the timing windowSupport / DisputesEligible cases missed or filed late
Representment qualityComplete, structured, driver-specific evidence packagesDisputesLosses on cases with strong underlying evidence
CE3.0 / First-Party Trust awarenessUnderstand which compelling-evidence paths apply and what they requireDisputes / PaymentsEvidence assembled that does not meet the standard
Refund and support operationsFast, consistent resolution before the customer calls the issuerCXDisputes filed after a support contact
Reason-code normalisation and feedbackOne internal vocabulary; structured feedback to issuers and acquirersPaymentsCodes reported raw; no trend visible

30/60/90-day action plan

30/60/90-day action plan
WindowFocusOwnerDone looks like
Days 1–30Normalise reason codes; rank drivers by count; measure refund latency and descriptor recognisabilityDispute leadA ranked driver list with named owners
Days 31–60Stand up pre-dispute resolution with timing controls; rebuild representment templates by driverDisputes + CXPre-dispute rate measured; evidence packages standardised
Days 61–90Run prevention changes on the top two controllable drivers; establish monthly governance reviewAccountable executiveDriver movement explained and a repeatable cadence

KPI scorecard

Chargeback governance scorecard
KPITypeReview
Dispute count and bps by normalised driverLaggingWeekly
Pre-dispute resolution rate and timing complianceLeadingWeekly
Representment win rate by driverLaggingMonthly
Evidence completeness at submissionLeadingWeekly
Refund latencyLeadingWeekly
Disputes filed after a support contactControlMonthly

Common traps

  • Measuring the representment win rate while the volume upstream keeps growing.
  • Reporting raw reason codes, which hides the drivers that could be removed.
  • Assuming a compelling-evidence path applies without checking its specific requirements.
  • Refund policies slow enough that the issuer is the faster route for the customer.
  • Quoting the $42B forecast as though it were a measured loss.

Questions for vendors and acquirers

  • How do you normalise reason codes, and can we see the mapping?
  • Which pre-dispute and compelling-evidence paths do you support, and what are the timing cut-offs?
  • What evidence fields do you submit, and what is your loss reason breakdown?
  • How is win rate reported — by driver, by issuer, or as one blended number?
  • What feedback loop exists back into prevention, and who reviews it?

Executive Guide 04 · Updated August 2026

The Executive Guide to Canadian Payment-Fraud Readiness

What the evidence says

A Payments Canada survey conducted with Leger found that 20% of 500 surveyed Canadian businesses experienced payment fraud in the prior six months, and 15% lost money. Among the types experienced, impersonator fraud was reported by 25%, intercepted business e-Transfers by 22% and credit-card fraud by 20%. Separately, 45% noticed more fraudulent or suspicious email activity.

Payment fraud types experienced by surveyed Canadian businesses

Payments Canada / Leger survey of 500 Canadian businesses. Fieldwork 25 March – 5 April 2024. Margin of error ±2.5 percentage points, 19 times out of 20.

  • Impersonator fraud25%
  • Intercepted business e-Transfers22%
  • Credit-card fraud20%
View data as a table
Payment fraud types experienced by surveyed Canadian businesses
Fraud typeShare of surveyed businesses
Impersonator fraud25%
Intercepted business e-Transfers22%
Credit-card fraud20%

10-minute diagnostic

Answer these with finance and treasury

  • Is there a callback verification step, using a known number, for any change to payee bank details?
  • Are e-Transfer recipients and autodeposit registrations reviewed and controlled?
  • Does a payment above a defined threshold require dual authorisation?
  • Are inbound invoice changes verified out-of-band rather than by reply email?
  • Is suspicious email activity reported to a named owner, and is the volume trended?
  • Do you know your own six-month incident and loss count, or only an impression of it?

Executive briefing

Controls mapped to the reported fraud types
Reported typeAttack surfacePrimary controlOwner
Impersonator fraud (25%)People and process — executive or supplier impersonationOut-of-band callback verification and dual authorisationFinance
Intercepted business e-Transfers (22%)Email and recipient registrationRecipient controls, autodeposit governance, transfer limitsTreasury
Credit-card fraud (20%)Card acceptance and stored instrumentsAuthorization controls, 3DS where appropriate, dispute disciplinePayments
Increased suspicious email (45% noticed)Inbound email channelReporting path, domain controls, staff verification habitIT / Security

30/60/90-day action plan

30/60/90-day action plan
WindowFocusOwnerDone looks like
Days 1–30Baseline your own six-month incident and loss count; document current payment approval rulesFinance leadA written baseline you can repeat
Days 31–60Implement callback verification for payee changes and dual authorisation above a threshold; tighten e-Transfer recipient controlsTreasuryControls in place with exception logging
Days 61–90Run a supplier-impersonation exercise; establish a monthly review of attempts, losses and near-missesAccountable executiveTested process and a trended attempt log

KPI scorecard

Canadian readiness scorecard
KPITypeReview
Attempted fraud incidents detectedLeadingMonthly
Payee-detail change requests verified by callback (%)LeadingMonthly
Payments above threshold with dual authorisation (%)ControlMonthly
Confirmed losses and valueLaggingMonthly
Suspicious email reports receivedLeadingMonthly
Near-misses documented and reviewedLeadingQuarterly

Common traps

  • Treating survey percentages as your own incidence rate.
  • Verifying a payee change by replying to the email that requested it.
  • Dual authorisation that both parties perform from the same inbox.
  • Counting losses only, and never counting attempts or near-misses.
  • Applying this Canadian survey to global ecommerce fraud discussions.

Questions for your bank or payment provider

  • What recipient and limit controls are available on our business e-Transfer flows?
  • What verification tools exist for payee bank-detail changes?
  • What reporting do we receive on attempted and blocked payment fraud?
  • What is the recall or recovery process, and what are its time limits?
  • What authorisation controls can be enforced at the account level rather than by policy alone?

Sources & methodology

Where these figures come from.

Each figure quoted in these guides is taken verbatim from the primary source listed opposite, with its original framing preserved. MerchantGo does not blend datasets, extrapolate to other markets, or reference client outcomes.

Visa VAMP thresholds are published network programme rules and change over time; confirm the thresholds, exclusions and effective dates that apply to your portfolio with your acquirer, processor or Visa representative. No fees or penalties are stated anywhere in these guides because none are sourced here.

The Mastercard $42B figure is an explicitly labelled forecast for 2028, not observed loss. Verizon DBIR figures measure authentication and breach data, not payment fraud. The Payments Canada/Leger findings describe a survey of 500 Canadian businesses with fieldwork from 25 March to 5 April 2024 and a margin of error of ±2.5 percentage points, 19 times out of 20 — they cannot be generalised to global merchant ecommerce.

Run one of these playbooks with the MerchantGo team.