New Product and Promo Launch Review

Core components

A launch review program has five parts:

1. Intake trigger. A clear, mechanical rule for which launches need fraud review. This can't depend on product managers remembering to ask.
2. Tiering. Light-touch for low-risk changes, full review for anything that creates new value paths.
3. The review itself. A structured walk through the money path: where value enters, moves, and leaves, and who can trigger each step.
4. Launch conditions. Controls, monitoring, limits and kill switches agreed before launch, with named owners.
5. Post-launch watch. Heightened monitoring for the first days and weeks, with pre-agreed tripwires.

What triggers a review

Review is required if the launch does any of the following:

• Creates a new way for value to enter: funding method, deposit type, instant credit, provisional balance, buying power, gift card load, receipt or offer submission
• Creates a new way for value to leave: payout method, withdrawal rail, transfer-out, P2P send, redemption option, gift card cash-out, crypto off-ramp
• Changes the timing of value: faster availability, faster payout, instant settlement, shorter holds
• Creates free value: promo, sign-up bonus, referral reward, cashback offer, price discount, fee waiver, free stock or crypto, sweepstakes
• Changes eligibility or identity requirements: lighter KYC, new onboarding path, guest checkout, new geography
• Changes account-control flows: login, recovery, contact change, device enrollment, payout-destination change
• Changes dispute, refund, return or claim policy
• Integrates a new partner that moves funds or rewards: issuer, processor, retailer, affiliate network, BaaS bank, agentic commerce integration (see Agentic Commerce Fraud)
• Changes limits: raises caps, removes velocity limits, adds higher tiers

Tiering

How to build it

The review: walk the money path

For every launch, answer the questions in the table below. Use the Payment Rails Map and Customer Lifecycle Map to make sure no path is missed.

Pre-launch checklist: payment features and funding methods

• Finality mapped. For each funding rail, the return or dispute window is documented and compared against when the customer can use the value (see ACH Funding Fraud, Check and Mobile Deposit Fraud, Card-Not-Present Fraud).
• Exposure model. Worst-case loss per account and in aggregate if every reversible inflow is reversed after value is extracted (see Instant Funding Abuse (Kiting)).
• Holds and availability. Tiered availability by tenure and risk, not one flat rule (see Funds Availability Holds).
• Limits. Per-transaction, daily and rolling limits by risk tier, with aggregate platform caps (see Velocity and Exposure Limits).
• Ownership verification. Bank or card ownership is confirmed before money-out to that instrument (see Bank Account Ownership Verification).
• Step-up. Risk-based step-up on first use, on high value, and after account changes (see Risk-Based Authentication and Step-Up).
• Account-change linkage. A recent contact, device or payout-destination change triggers holds or extra verification on money-out (see Contact Change Cooling-Off Periods, Account Change Events).
• Scoring integration. The new event type flows into Real-Time Transaction Risk Scoring with the features it needs. If the model has never seen this event type, plan rules-first coverage.
• Scam friction. For outbound rails, payee confirmation and in-flow warnings where scam risk is material (see Payee Confirmation and Payment Friction, Customer Education and Scam Warnings).
• Regulatory mapping. Reg E error resolution, Nacha monitoring obligations, network rules and any broker-dealer obligations identified (see US Regulatory Overview, Nacha Rules and ACH Risk, Regulation E and Unauthorized Transfers).
• Ops readiness. Review queue, SOP, QA criteria and support macros ready before launch (see Alert Review Operations, Fraud QA Program).

Pre-launch checklist: offers, promos and referrals

• Economic sanity. Can a single actor earn more than the cost of creating a qualifying account or transaction? If yes, assume someone will do it at scale.
• One-per-person key. What does "one per customer" actually key on? Account, device, payment instrument, verified identity, household? Each can be multiplied at a different cost. Combine them (see Device Reputation and Linkage, Entity Link Analysis).
• Qualifying action. Is the qualifying action real economic activity, or can it be faked, round-tripped or reversed afterwards (deposit-then-withdraw, buy-then-return, receipt-then-refund)? See Sign-Up Bonus Abuse, Card-Linked Offer Abuse, Receipt Fraud (Cashback).
• Vesting and clawback. Rewards vest after the qualifying funds or purchase are final. Terms allow clawback for abuse (see Reward Vesting and Clawback).
• Caps. Per-account, per-identity, per-device and total-budget caps, with an automatic stop at budget (see Promotion Design Guardrails).
• Stacking rules. Explicit, tested rules for combining this offer with other offers, codes and referral rewards (see Promo Code Abuse).
• Code design. Codes are not guessable or enumerable. Single-use codes for high-value offers. Rate limits on code redemption endpoints (see Rate Limiting and Throttling).
• Referral graph. Referral rewards require real, distinct, active referees. Plan for monitoring referral-tree shape (see Referral Abuse, Referral Program Controls, Referral Graph Patterns).
• Distribution control. Who is the offer meant for? Targeted offers leak to coupon forums and social media. Plan for the offer to reach the whole internet.
• Edge-case testing. QA has tested reversals, partial refunds, currency conversions, concurrent redemptions, account deletion and re-creation, and timezone boundaries. These are where logic exploits live (see Business Logic Exploitation).
• Partner settlement. For retailer-funded or card-linked offers: who pays for abused redemptions, and how are disputes reconciled?
• Monitoring. A dashboard exists before launch showing redemption rate vs forecast, redemptions per device or identity cluster, new-account share, and payout velocity (see Promo and Reward Redemption Patterns).

Who does what (RACI)

A = accountable, R = responsible, C = consulted, I = informed. For Tier 1, if fraud and product disagree, the escalation path goes to the business owner who carries the loss budget (see Cross-Functional Partnerships). Fraud should rarely have a unilateral veto. It should have the right to document the residual risk and require explicit acceptance from someone senior enough to own it.

Artifacts and templates

Launch review document outline

1. Summary. What is launching, when, for whom, and the expected volume and value.
2. Money path diagram. Value in, movement, value out, with timing.
3. Tier and rationale.
4. Threat scenarios. Ranked by likelihood × impact (see Fraud Risk Assessment). Cover third-party (ATO, stolen instruments), first-party (abuse, disputes, kiting), organized (farms, rings) and victim-authorized (scams) actors.
5. Worst-case exposure. Per account, per day, in aggregate, with assumptions stated.
6. Launch conditions. Each control with an owner and a ready date.
7. Monitoring plan. Metrics, thresholds, dashboard link, who watches and when.
8. Kill switch and rollback. What can be paused, by whom, how fast, and the customer-facing message.
9. Residual risk and acceptance. What we're knowingly accepting, signed by the risk owner.
10. Post-launch review date.

Hypercare tripwires (illustrative, calibrate to your data)

Post-launch review checklist

• Actual vs forecast uptake, and the share attributed to abuse
• Losses and clawbacks by mechanism (see Loss Taxonomy and Attribution)
• Which launch conditions worked, which never fired, and which fired too often
• Customer friction: complaints, insult rate, drop-off (see Friction and Customer Experience Tradeoffs)
• Recommendations for the next launch of this type, added to the reusable checklist

Metrics

Pitfalls

• Reviewing only the PRD. The design was safe, but the promo tool was configured with no cap. Review the actual configuration before launch.
• Assuming targeting holds. "It's only for 10,000 invited users" lasts until the link is shared. Design for public exposure.
• Testing only the happy path. Logic exploits live in reversals, concurrency and edge cases. The well-known public examples of promo and buying-power logic flaws (see Case Study - Pinduoduo Coupon Exploit (2019), Case Study - Robinhood Infinite Leverage Glitch (2019), Case Study - Chase Infinite Money Glitch (2024)) came down to logic and timing; none required fraud sophistication.
• No kill switch, or a kill switch nobody can find. If pausing a promo needs an engineering deploy at 2 a.m., you don't have one.
• Fraud as the "no" team. If fraud only blocks, product routes around review. Bring solutions: caps, vesting, tiered limits and staged rollouts usually beat a no.
• Forgetting the second launch. Promo mechanics get reused months later with higher values and nobody re-reviews. Tier 3 (re-run) should still check that value, distribution and partner haven't changed.
• Ignoring support. Launches create new support contacts, and new ways to socially engineer agents into granting value (see Support Team Fraud Training).

Related

• Fraud Program Overview · Fraud Risk Assessment · Cross-Functional Partnerships · Fraud Incident Response · Threat Intelligence and Horizon Scanning · Fraud Tabletop Exercises
• Controls: Promotion Design Guardrails · Reward Vesting and Clawback · Referral Program Controls · Funds Availability Holds · Velocity and Exposure Limits · Withdrawal and Payout Controls
• Playbooks: Playbook - Sign-Up Bonus and Promo Abuse Members · Playbook - Referral Abuse Members · Playbook - Business Logic Exploit Response Members · Playbook - Instant Funding Abuse Members
• Industries: Cashback, Coupons and Rewards · Brokerage and Investing · Neobanks and Consumer Fintech · Online Marketplaces

Sources and further reading

• COSO/ACFE Fraud Risk Management Guide, 2nd ed., Executive Summary (2023): risk assessment of schemes, evaluation of existing controls, and mitigation of residual risk
• PRAC, Blueprint for Enhanced Program Integrity, Chapter 3: the public-sector lesson that fraud risk assessment belongs before launch, with risk tolerance documented
• GAO-15-593SP Highlights: A Framework for Managing Fraud Risks in Federal Programs: risk tolerance, risk profiles and a preventive-first strategy
• Nacha, Fraud Monitoring Phase 1: risk-based monitoring obligations to consider when launching ACH funding or payout features
• CFPB, Regulation E §1005.11: error-resolution obligations that new EFT features inherit