MerchantGo Methodologies
Frameworks
Practical decision systems for connecting signals, economics, controls and executive accountability.
These are working frameworks—not maturity theatre. Each is designed to improve the quality, speed and traceability of consequential risk decisions.
- Frameworks
- 4 Frameworks
- Updated
- August 2026
- Format
- Print-friendly, on-page
- Audience
- Practitioners & Executives
The frameworks
Four systems you can run this quarter.
- 01Operating Model
The MerchantGo Decision Intelligence Loop
Eight stages from raw signal to continuous optimisation, each with an executive question, minimum evidence, failure mode and decision output.
- For
- CRO, Heads of Fraud, Payments and Data
- Time
- 10 min to walk through
- 02Risk Economics
Total Risk Economics Framework
Five steps and one metric tree that price a control decision across approval, loss, friction and customer value — with template equations, not invented numbers.
- For
- CFO, Finance Partners, Risk Leadership
- Time
- 20 min to baseline
- 03Disputes
Chargeback Root-Cause Framework
Work dispute outcomes backwards to the policy or experience that created them, then choose between prevent, deflect, represent and accept.
- For
- Dispute Operations, CX, Product, Payments
- Time
- 15 min per driver review
- 04Identity & Authentication
Account Takeover Decision Sequence
Eight stages from acquisition signal to recovery, each with signals, proportionate controls, friction risk and the evidence recovery will need.
- For
- Fraud, Identity, Product, Support
- Time
- 15 min to map
Framework 01 · Updated August 2026
The MerchantGo Decision Intelligence Loop
Eight stages that carry a raw signal through to an accountable, reviewable decision — and back again. The loop is deliberately sequential: each stage consumes the output of the one before it, and a weakness early on cannot be recovered later by a better model.
- Owner
- Chief Risk Officer or equivalent single accountable executive
- Cadence
- Stages 1–6 continuous; stage 7 monthly; stage 8 quarterly
- Leading indicators
- Signal latency, identity confidence coverage, step-up rate
- Lagging indicators
- Approval rate, fraud loss bps, dispute bps, cohort retention
The eight stages
- 01Signal
- 02Identity
- 03Payments
- 04Behaviour
- 05Decision Intelligence
- 06Fraud Strategy
- 07Executive Reporting
- 08Continuous Optimization
Sequence: Signal → Identity → Payments → Behaviour → Decision Intelligence → Fraud Strategy → Executive Reporting → Continuous Optimization, returning to Signal.
| Stage | Executive question | Minimum evidence | Failure mode | Decision output |
|---|---|---|---|---|
| Signal | What are we actually observing, and how quickly? | Event coverage by channel, latency to availability, known blind spots | Signals collected but not joined to an entity or a decision | A ranked list of signals that change a decision |
| Identity | Who is this, and how confident are we? | Entity resolution rules, linkage quality, confidence bands | Confidence treated as binary; one weak match propagates everywhere | An identity confidence tier attached to the session |
| Payments | What is the instrument, route and issuer telling us? | Auth responses, decline codes, routing path, 3DS outcomes | Decline codes aggregated into 'declined' and never diagnosed | Instrument-level risk and retry/route decision |
| Behaviour | Does this session behave like the cohort it claims to belong to? | Velocity, navigation, device continuity, change events | Behavioural anomaly scored but not tied to value at stake | A proportionate friction decision |
| Decision Intelligence | What is the best decision given cost, confidence and context? | Policy, model output, cost of each error type, cohort value | Model accuracy optimised while business cost is unpriced | Approve, step up, review, decline — with a recorded reason |
| Fraud Strategy | Which decisions should change, for whom, and why now? | Driver ranking, cohort performance, capacity, network exposure | Reactive rule stacking with no retirement schedule | A prioritised change set with expected effects stated in advance |
| Executive Reporting | Can leadership see the trade-off, not just the ratio? | Defined metric tree, cohort views, distance to network thresholds | One ratio reported; the offsetting costs stay invisible | A decision-ready view with an owner against each action |
| Continuous Optimization | Did the change do what we said it would? | Pre-stated hypotheses, controlled comparison, cohort attribution | Wins claimed without a counterfactual; learning never recycled | Retain, revise or retire — and an updated definition set |
Framework 02 · Updated August 2026
Total Risk Economics Framework
A five-step method for pricing a risk decision in full, so that a change is judged on margin and customer value rather than on the single ratio it was designed to move.
- Owner
- Risk leadership with a named Finance partner
- Cadence
- Baseline once, then per change; review quarterly
- Leading indicators
- Approval rate, step-up rate, review rate, queue latency
- Lagging indicators
- Fraud loss bps, dispute bps and count, gross margin per cohort
| Step | What you do | Output |
|---|---|---|
| 1 · Define the decision and customer cohort | State the exact decision under review and the cohort it affects — channel, geography, tenure, instrument, value band | A one-sentence decision statement and a cohort definition |
| 2 · Build the full cost ledger | Price every consequence of the decision, including the ones owned by other functions | A ledger with an owner and a data source per line |
| 3 · Establish approval, loss and friction guardrails | Agree in advance the floors and ceilings that would cause the change to be reversed | Written guardrails signed off before launch |
| 4 · Test policy, model or routing changes | Run a controlled change against a comparable holdout or prior-period cohort where feasible | A measured result against the pre-stated hypothesis |
| 5 · Attribute realized value and recycle learning | Attribute the outcome to the change, update definitions, and retain or retire the control | A decision record and an updated metric tree |
The metric tree
Every metric below must have a written definition, a single source and one owner. Where a measure is a proxy, say so on the same line it appears.
| Metric | Definition discipline | Owner |
|---|---|---|
| Authorization rate | Numerator and denominator stated by channel and instrument | Payments |
| Fraud loss bps | Confirmed fraud on approved volume; state the confirmation lag | Fraud |
| Dispute bps and count | Both ratio and count; count is what network programmes use | Disputes |
| False-decline proxy | Named proxy with its known limits published alongside it | Fraud / Analytics |
| 3DS challenge and abandonment | Challenge rate and completion by cohort | Payments / Product |
| Review rate and cost | Queue volume, decision latency and fully loaded cost per review | Operations |
| Refund and support cost | Contacts and refunds attributable to the decision | CX / Support |
| Gross margin and customer value | Margin per approved order and cohort lifetime value | Finance |
Framework 03 · Updated August 2026
Chargeback Root-Cause Framework
Disputes are an output. This framework works each outcome backwards through six layers until it reaches the policy or experience decision that produced it — because that is the only layer where the volume can actually be removed.
- Owner
- Dispute operations lead with Product and CX co-owners
- Cadence
- Weekly driver review; monthly network reconciliation
- Leading indicators
- Pre-dispute resolution rate, evidence completeness, refund latency
- Lagging indicators
- Dispute bps and count, representment win rate, driver mix shift
The backward map
- 01
Reason-code normalization
Translate issuer and network codes into one internal vocabulary
- 02
Claim taxonomy
Classify what the cardholder actually claims happened
- 03
Transaction and session evidence
Retrieve device, session, authentication and delivery signals
- 04
Fulfilment, refund and support history
Check what the business did before the dispute was filed
- 05
Authentication and authorization
Review 3DS outcome, liability position and auth path
- 06
Policy or experience root cause
Name the decision that made the dispute likely
| Driver | Type | Primary treatment | Secondary treatment |
|---|---|---|---|
| Unclear billing descriptor | Controllable | Prevent | Deflect via support |
| Subscription renewal surprise | Controllable | Prevent (notice, consent) | Accept and refund fast |
| Delivery failure or delay | Controllable | Prevent (fulfilment SLA) | Represent with delivery evidence |
| Refund latency | Controllable | Prevent (refund speed) | Deflect |
| First-party claim on a legitimate order | Mixed | Represent with session evidence | Deflect pre-dispute |
| Third-party fraud on a compromised account | Mixed | Prevent upstream (see framework 04) | Accept |
| Issuer-side coding or process error | External | Represent | Feedback to acquirer |
| Organised enumeration or testing | External | Prevent at authorization | Accept where unavoidable |
Framework 04 · Updated August 2026
Account Takeover Decision Sequence
Account takeover is a sequence, not an event. Each stage below has its own signals, its own proportionate control, and its own cost if you apply friction in the wrong place. The evidence you capture here is the evidence your dispute and recovery teams will need later.
- Owner
- Fraud lead with Identity and Product co-owners
- Cadence
- Daily signal review; monthly sequence walkthrough
- Leading indicators
- Credential-stuffing pressure, step-up rate, profile-change velocity
- Lagging indicators
- Confirmed ATO cases, value moved, recovery rate, support contacts
| Stage | Signals | Proportionate control | Customer-friction risk | Recovery evidence |
|---|---|---|---|---|
| Acquisition signal | Traffic source, bot infrastructure, credential-list indicators | Edge rate limiting, bot mitigation | Low | Request fingerprint and rate history |
| Credential attempt | Attempt velocity, reuse patterns, known-compromised credentials | Throttling, compromised-credential blocking | Low if silent | Attempt log with outcome |
| Authentication | MFA/passkey outcome, device recognition, geography change | Step-up only on unrecognised device or risk signal | Medium — blanket MFA costs conversion | Auth method, result, timestamp |
| Session behaviour | Navigation pattern, velocity, device continuity within session | Silent scoring, hold rather than block | Low if silent | Session trace tied to the account |
| Profile change | Email, phone, address, MFA method, payout details | Step-up plus out-of-band notice to the prior contact | Medium and worth paying | Before/after values and notification record |
| Payment or stored value | New instrument, top-up, saved-instrument reuse, value at stake | Step-up scaled to value; cooling period after a change | Medium to high | Instrument add trail and decision reason |
| Fulfilment or withdrawal | Shipping change, digital delivery, cash-out or transfer | Hold on change-plus-withdrawal within a short window | High — genuine customers are also in a hurry | Fulfilment record and hold rationale |
| Recovery | Customer report, support contact, dispute filing | Defined reversal and reimbursement policy | High if slow | Full sequence assembled as one case file |
How to use these frameworks
Start with one decision, not one framework.
- 01
Choose one decision
Pick a single consequential decision you already make repeatedly. Frameworks applied to everything change nothing.
- 02
Assign one accountable executive
One name, not a committee. The owner holds the full cost ledger, not a single ratio.
- 03
Baseline where feasible
Gather 8–12 weeks of observations where volume allows. This is practical guidance for seeing a trend, not a statistical claim.
- 04
Document definitions
Write down every numerator, denominator, proxy and exclusion before you change anything.
- 05
Run controlled changes
State the expected effect on each metric in advance, then change one thing at a time.
- 06
Review outcomes by cohort
Portfolio averages hide the customers you lost. Review by cohort, then retain, revise or retire.
Sources & methodology
Where these figures come from.
These frameworks are MerchantGo methodologies. They contain no client data, no benchmark figures and no performance claims. Where a network rule is referenced — such as the VAMP ratio construction — it is drawn from Visa’s published 2025 fact sheet and should be confirmed with your acquirer, processor or Visa representative before use.
All equations shown are templates. They contain named variables only; no illustrative numbers have been substituted, because a plausible-looking example is routinely mistaken for a benchmark.
Timeframes such as an 8–12 week baseline are practical guidance for gathering enough observations to see a trend. They are not a statistical claim about significance, which depends entirely on your volume, variance and cohort definitions.
- VisaVisa Acquirer Monitoring Program fact sheet (2025, PDF)https://corporate.visa.com/content/dam/VCOM/corporate/visa-perspectives/security-and-trust/documents/visa-acquirer-monitoring-program-fact-sheet-2025.pdf
- VisaVAMP programme update: fraud and disputeshttps://corporate.visa.com/en/sites/visa-perspectives/security-trust/visa-vamp-program-update-fraud-disputes.html
- Verizon BusinessCredential stuffing attacks: 2025 DBIR researchhttps://www.verizon.com/business/resources/articles/credential-stuffing-attacks-2025-dbir-research/
Explore related MerchantGo intelligence