cpdeol
← Back to Projects
Payments + Compliance

Checkout Optimisation & Fraud Prevention

Reduced fraud by 94% and checkout abandonment by 12% simultaneously — with no perceptible impact on legitimate customer experience.

94%

fraud reduction

$3.8M+

annual fraud savings

12%

checkout conversion improvement

<200ms

total checkout latency

Role

Lead Technical Business Analyst — Payments & Compliance

Timeline

Q4 2022–Q1 2023 · 5 months

Delivery context

PaymentsFraudRequirementsSQLCompliance

The Problem

Dual pressures: significant annual fraud losses and checkout abandonment caused by a slow fraud detection step. The core challenge was defining exactly where to draw the line between fraud prevention and customer friction — a requirements problem before it was a technology problem.

My Contribution

I mapped the end-to-end checkout flow, identified every fraud decision point and its associated customer friction cost, and facilitated sessions with the fraud, product, and operations teams to define the precision/recall thresholds that balanced security with conversion. I authored the integration specifications for the payment gateway, designed the UAT scenarios used to validate fraud detection accuracy against historical fraud samples, and documented the edge case handling requirements for the async verification path. I also led stakeholder alignment on the risk tolerance framework that governed which orders could be auto-approved versus flagged.

The Solution

Requirements-led fraud prevention: end-to-end checkout flow mapping, fraud decision point analysis, precision/recall threshold definition with stakeholders, payment gateway integration specifications, and UAT design using historical fraud cases.

Results

  • 94% fraud reduction ($3.8M+ annual savings)
  • 12% checkout conversion improvement
  • <200ms total checkout flow
  • $500M+ annual transaction volume processed
  • 2% false positive rate (industry avg 8-15%)
Key learning
The async post-purchase verification path — applying high-friction checks only to genuinely suspicious orders after checkout — was a requirements insight, not a technical one. It only became viable once we had documented the full fraud decision taxonomy and identified which cases could tolerate a post-purchase check versus which needed inline blocking.

Tech Stack

Payments

Payment GatewaysTokenizationStripe API

Data

SQLSSMSExcelData Analysis

Tools

JIRAConfluenceVisio

Methodology

Agile/ScrumBRD/TDDUATProcess Modeling

Related

How this project connects to the rest of my work.