Description

A focused course, tailored for you

The Senior Security Analyst Merchant-Risk Detection Playbook

How a senior security analyst inside a global commerce platform turns merchant fraud, account-takeover bursts, and partner-app abuse into ranked, owned, closed alerts.

The alert fires. A high-GMV merchant just accepted a thousand orders from one ASN in ten minutes. By the time triage decides whether this belongs to fraud, trust, platform-abuse, or security, the chargebacks have already started landing.

$199 one-time

Tailored to your situation. Access within 24 hours. 30-day money-back.

Includes a hand-built implementation playbook delivered alongside course access, generated for your specific situation.

Why this course

A senior security analyst inside a commerce-platform business sits at an awkward boundary. The signals look like classic security telemetry (failed auths, anomalous tokens, traffic shape changes) but the impact lands as merchant fraud, payout loss, support escalation, and reputational damage. The triage rules were written for a SaaS company with a single product surface, not a marketplace with hundreds of thousands of seller accounts, a partner-app ecosystem, and a payments stack on top. So a meaningful share of high-severity events sit in queue while ownership is debated. That is the gap the course closes: the detection logic, the routing logic, and the handoff contracts that turn an ambiguous merchant-side event into a ranked, owned, closed incident. The implementation playbook lands the work in a real commerce-platform topology, not a generic reference architecture.

What you walk away with

Write merchant-side detection queries that name the owner (fraud, trust, platform-abuse, or security) before the alert fires.
Build the handoff contract that resolves the four-team triage ambiguity for high-GMV merchant events inside ten minutes of detection.
Stand up the partner-app token-scope abuse detection layer that the OAuth audit log alone does not produce.
Translate post-incident chargeback signals back into pre-incident detection rules feeding the SIEM.
Present merchant-risk detection coverage to a CISO or VP of Trust in a format that maps to GMV impact rather than alert volume.

The 12 modules

Module 1. Merchant-side telemetry: the signal surface a senior security analyst actually inherits

Inventory of the telemetry a senior security analyst in a commerce platform actually has access to: auth logs, OAuth token logs, checkout-flow events, payout state machine transitions, BIN-level chargeback feedback, merchant-account audit trails, support-ticket metadata. The module walks through which of these are real-time, which are batch, which are downstream of a payment processor, and which carry merchant context the SIEM strips out by default. Output: a one-page telemetry map for your own stack.

Module 2. The four-team triage problem: fraud, trust, platform-abuse, security

Most ambiguous merchant-side alerts sit in queue because four teams could legitimately own them. This module defines the decision rules that resolve ownership before the alert fires: what makes an event a fraud event versus a trust event versus a platform-abuse event versus a security event, and what the routing logic should encode. Includes the handoff contract template and the escalation path when an event genuinely straddles two teams.

Module 3. Account-takeover detection: staff accounts versus merchant accounts versus customer accounts

ATO inside a commerce platform fires across three distinct account populations with very different blast radii. Staff ATO threatens the platform itself, merchant ATO threatens payout fraud and inventory exposure, customer ATO is mostly a fraud-team problem. The module walks through detection logic for each (impossible-travel, session-token reuse, device-fingerprint drift, MFA-bypass attempts), the runbook per population, and how to keep the three from blurring into a single noisy queue.

Module 4. Partner-app token-scope abuse: detection beyond the OAuth audit log

A partner app with read-orders scope quietly reading customer PII is invisible in the OAuth audit log because the scope was granted legitimately. The module builds the second-layer detection: rate-of-access anomalies, off-pattern data egress, scope-usage divergence from the app's documented purpose, and the cross-merchant pattern that surfaces a single rogue app abusing many stores at once. Includes the rule set, the alert thresholds, and the partner-app remediation runbook.

Module 5. Checkout-bot pattern shifts and the inventory-snipe attack class

Checkout bots evolve weekly. The detection layer cannot rely on static rules. The module walks through the pattern-shift detection approach: baseline checkout latency distributions per merchant, inventory-velocity anomalies during product drops, BIN clustering on first-touch checkouts, and the upstream traffic-shape signature that arrives at the WAF a minute before the checkout volume hits. Includes the cross-team handoff to the merchant-side anti-bot product team.

Module 6. Payout-fraud staging: detecting the days-before signal, not the moment-of signal

Payout fraud is detectable days before the actual fraudulent payout if the right signals are wired. This module catalogues the staging-phase signals: bank-account change followed by address change followed by rapid order acceptance, staff-account anomalies on merchants in dispute, refund-pattern shifts that precede payout-route changes. The output is a staging-phase detection rule set and the joint runbook with the payouts risk team.

Module 7. BIN-level chargeback signal: turning post-incident data into pre-incident detection

Chargebacks arrive 48 to 90 days after the underlying transaction. By the time the data lands, the fraud is long over. This module walks through the technique for feeding BIN-level chargeback patterns back into pre-transaction detection rules: which BIN segments correlate with which attack classes, how to roll the feedback into the SIEM without leaking issuer PII, and the joint review cadence with the chargeback-ops team.

Module 8. Cross-merchant correlation: the attack pattern that only surfaces in aggregate

A single attacker hitting one merchant looks like noise. The same attacker hitting fifty merchants at the same checkout step is a platform-level incident. This module covers cross-merchant correlation: the query patterns, the aggregation thresholds, the privacy-preserving join logic that does not surface individual merchant data to the wrong team, and the platform-level incident-declaration trigger that pulls the security incident commander in.

Module 9. Insider risk: staff accounts, support-tool access, and merchant data exposure

Support engineers and trust agents have legitimate access to merchant data. The detection challenge is separating legitimate access from abuse. The module walks through the access-pattern modelling (who normally touches which data, when, for how long), the just-in-time access tooling that constrains the blast radius, and the audit-replay technique that surfaces unauthorised lookups after the fact. Includes the joint handoff with the people-security and legal-investigations teams.

Module 10. Detection-as-code: the senior security analyst's contribution to the rule pipeline

Detection rules belong in version control with tests, code review, and CI. The module walks through the detection-as-code workflow that scales beyond a single analyst: rule templates, the test fixture pattern for replaying historical alerts against new rules, the alert-quality scorecard that catches rule drift, and the review cadence with the broader detection-engineering team. Output: your first three merchant-risk detection rules merged into the pipeline.

Module 11. Incident response for merchant-side events: the runbook the SOC playbook is missing

A merchant-side incident response looks different from a corporate-IT incident response. The affected party is a paying customer with a business depending on the platform. This module walks through the merchant-incident runbook: containment that does not break legitimate merchant operations, communication with the affected merchant via the trust team, regulatory implications (state breach laws, GDPR if EU merchants are affected, payment-network requirements), and the post-incident merchant-comms artefact that the legal and PR teams will need.

Module 12. Reporting to a CISO or VP of Trust in commerce-platform units, not alert volume

A CISO or VP of Trust at a commerce platform wants GMV impact, payout-fraud loss avoided, merchant churn risk reduced, and partner-app risk surface size. They do not want alert counts. This module builds the reporting layer for that audience: the merchant-risk coverage map, the GMV-weighted detection rate, the time-to-ownership metric, and the quarterly review artefact for the executive risk committee. Output: the template tuned to your stack.

How this addresses your situation

Specific modules that map to what you said you are dealing with.

The high-GMV merchant alert that triage cannot route inside ten minutes.

The partner-app pulling more customer data than its documented scope justifies, with the OAuth log saying it has permission.

The chargeback-ops team finding a BIN-level pattern that nobody fed back into detection.

The post-incident review where the response was on-time but the detection was wrong, and the fix is upstream of the SOC.

What you get with this course

12 written modules, each with detection logic, runbook, and team-handoff contract.
Downloadable rule templates for SIEM (Splunk SPL, Sumo, and a vendor-neutral pseudocode variant).
The four-team triage decision matrix as an editable artefact.
The hand-built implementation playbook, mapped to a commerce-platform stack rather than a generic SOC reference architecture.
Worked examples for every module, drawn from public commerce-platform incident reports.

What you will have in hand by Day 1, Week 1, Month 1

Within 24 hours, learning environment account provisioned and the hand-built implementation playbook delivered alongside.

Week 1: modules 1 to 4 (telemetry map, four-team triage, ATO across three populations, partner-app abuse).

Week 2: modules 5 to 8 (checkout bots, payout-fraud staging, BIN-chargeback feedback, cross-merchant correlation).

Week 3: modules 9 to 12 (insider risk, detection-as-code, merchant-incident response, executive reporting).

Implementation playbook used in parallel: pick three detection rules from your real stack and walk them through the merchant-risk framework end to end.

Before and after

Before

Merchant-side alerts sit in queue while four teams debate ownership, post-mortems focus on response time when the upstream defect was routing logic, and the detection layer cannot articulate its coverage in terms anyone outside the SOC understands.

After

Merchant-side alerts arrive pre-routed, the four-team handoff contract is named in the rule itself, the chargeback feedback loop closes back into detection, and the quarterly merchant-risk review reads in GMV-impact units that the executive risk committee actually uses.

What happens if you do not address this

The next high-GMV merchant ATO sits in triage long enough for payout fraud to land, the chargebacks arrive in 60 days, and the post-mortem concludes that detection was working but ownership was unclear. The same conclusion was written the previous quarter and will be written the next quarter unless the routing logic moves upstream into the detection layer itself.

Who it is for

A senior security analyst inside a commerce, marketplace, or platform business where merchant accounts, partner apps, and payments sit on top of the core security telemetry layer. Two to seven years of SOC, detection-engineering, or trust-and-safety adjacent work. Already comfortable with SIEM query languages, MITRE ATT&CK mapping, and Python or Go for tooling. Frustrated by detections that fire correctly but route incorrectly, and by post-mortems that focus on response time when the real defect was upstream in the ownership model.

Who this is NOT for. Pure enterprise IT security analysts whose surface area is corporate endpoints and the office network. Junior SOC analysts in their first six months. People looking for a generic Security+ refresher or a vendor-led SIEM certification path. This course assumes you can already write the detection query; what you need is the decision-routing logic and the merchant-side context that makes the query worth running.

How it arrives

Text-based course in the Art of Service learning environment, plus downloadable templates and worked examples for every module, plus the hand-built implementation playbook delivered alongside course access.

Time investment. Around 14 to 18 hours of reading and exercises over three weeks. The implementation playbook adds another 6 to 10 hours of guided work on a real detection from your own queue.

Why $199 is the right number

SANS detection-engineering courses cover the rule-writing craft but assume a corporate-IT surface, not a marketplace plus payments stack. Vendor-led SIEM certifications optimise for tool fluency, not for merchant-side context. Internal threat-intel reading and conference talks cover individual attack classes but rarely the four-team routing logic that decides whether a finding becomes an owned incident. This course is the merchant-risk detection layer specifically, written for the senior security analyst who already has the SIEM skills and needs the platform-specific framework.

FAQ

Does this assume a specific SIEM or detection stack?

No. Detection logic is given in vendor-neutral pseudocode plus Splunk SPL and Sumo variants. The rule templates port to most modern SIEMs in under an hour each.

Is this a fraud course or a security course?

It sits on the boundary. The detection logic is security-engineering work; the impact framing and handoff contracts are fraud and trust work. That boundary is the whole point of the course.

Can a detection engineer take this instead of a senior security analyst?

Yes. The rule-writing modules will feel familiar; the four-team triage and the GMV-impact reporting modules are where the new ground is.

What gets delivered alongside the course?

A hand-built implementation playbook tuned to a commerce-platform stack: detection-rule templates, the four-team handoff contract, the chargeback-feedback wiring guide, and the executive-reporting template.

How is the refund handled if the course is not a fit?

30-day refund window from purchase. Contact via the learning environment or reply to the welcome email.

30-day money-back guarantee. If after a week of working through the materials this is not what you needed, reply to the receipt email and a full refund is processed. No questions, no forms.

Within 24 hours your account in the learning environment is provisioned and the tailored implementation playbook is delivered alongside it.