مقابله با تقلب فروشگاه اینترنتی؛ کنترل، سنجش و پاسخ

فروشگاه پس از یک کمپین نوروزی، سفارش‌های مشکوک را با یک قانون ساده می‌بندد: «خرید اول بالای مبلغ X رد شود». زیان ظاهری کم می‌شود، اما مشتریان واقعیِ کمپین هم رد می‌شوند، پشتیبانی شلوغ می‌شود و تیم نمی‌داند کدام سفارش واقعاً تقلب بوده است. چند روز بعد مهاجم با مبلغ‌های کوچک‌تر برمی‌گردد. مشکل کمبود قانون نبود؛ فروشگاه Risk، Outcome و هزینه خطا را تعریف نکرده بود.

مقابله با تقلب در فروشگاه اینترنتی یعنی کاهش زیان مورد انتظار در کل سفر حساب، پرداخت، سفارش، ارسال و بازگشت—بدون تبدیل امنیت به مانع دائمی برای مشتری سالم. هیچ AI، OTP، CAPTCHA یا Rule واحدی تقلب را حذف نمی‌کند. سیستم قابل اتکا، لایه‌های پیشگیری، تشخیص، Step-up، بررسی انسانی، پاسخ به Incident و یادگیری از نتیجه واقعی را با هم اداره می‌کند.

مرز: این راهنما مشاوره حقوقی، بانکی یا تعیین‌کننده الزامات PSP/Acquirer نیست. قرارداد درگاه، شبکه پرداخت، نوع داده‌ای که لمس می‌کنید و حوزه قضایی شما دامنه کنترل و گزارش‌دهی را تغییر می‌دهد. الزامات جاری را مستقیماً با PSP، پذیرنده‌یار/Acquirer، مشاور حقوقی و مسئول امنیت خود تأیید کنید.

تقلب تجارت الکترونیک چیست؟

E-commerce fraud استفاده فریبکارانه یا غیرمجاز از حساب، پرداخت، تخفیف، سفارش، تحویل، مرجوعی یا فرایند پشتیبانی برای کسب منفعت یا تحمیل زیان است. اما هر اختلاف، Refund یا پرداخت ناموفق «تقلب عمدی» نیست. خطای Fulfillment، شرح مبهم صورتحساب، تحویل ناقص، سوءتفاهم مشتری و باگ نرم‌افزار می‌توانند نشانه مشابه بسازند.

چهار مفهوم را جدا نگه دارید:

• Cyberattack: تلاش فنی مانند Credential stuffing، Injection یا سرقت Session؛
• Abuse: سوءاستفاده از منطق مجاز مانند Coupon stacking یا ساخت حساب انبوه؛
• Payment/order fraud: استفاده غیرمجاز یا فریب در پرداخت، سفارش یا تحویل؛
• Operational dispute/error: اختلاف یا خطای واقعی که هنوز Intent متقلبانه‌اش ثابت نشده است.

اگر همه را یک برچسب بزنید، داده آموزش مدل آلوده، مشتری سالم مجازات و Root cause عملیاتی پنهان می‌شود.

هدف «صفر تقلب» نیست؛ کمینه‌کردن زیان کل است

بستن همه سفارش‌های پرریسک ممکن است Fraud loss را کم کند و هم‌زمان درآمد، اعتماد و دسترس‌پذیری را تخریب کند. تابع تصمیم باید چند هزینه را ببیند:

Total expected loss =
  confirmed fraud loss
  + false-positive margin loss
  + review and support cost
  + fulfillment/refund operational loss
  + incident and recovery cost
  + customer/brand harm

وزن هر جزء به مدل کسب‌وکار وابسته است. کالای دیجیتال فوری، کالای لوکس قابل ارسال، Marketplace و سفارش سوپرمارکتی Threat model یکسان ندارند.

از Govern تا Recover: مالکیت برنامه ضدتقلب

چارچوب رسمی NIST Cybersecurity Framework 2.0 شش Function دارد: Govern، Identify، Protect، Detect، Respond و Recover. این چارچوب چک‌لیست مخصوص فروشگاه نیست، اما کمک می‌کند پروژه به خرید Tool تقلیل نیابد.

برای هر Control یک Owner، On-call، معیار، تاریخ بازبینی و Fallback تعیین کنید. «سرویس ضدتقلب روشن است» وضعیت عملیاتی کافی نیست.

نقشه حمله را روی Journey بسازید

این نقشه را با فرایند موجودی، ارسال و مرجوعی تطبیق دهید؛ بسیاری از زیان‌های «تقلب» در شکاف میان سیستم سفارش، انبار، پیک و Refund رخ می‌دهند.

Risk register را از ادعا به تصمیم تبدیل کنید

برای هر سناریو این فیلدها را نگه دارید:

• Asset و Business process؛
• Threat actor/abuse story بدون ذخیره جزئیات غیرضروری مهاجم؛
• شرایط و Signalهای قابل مشاهده؛
• Impact مالی، عملیاتی، مشتری و Compliance؛
• Prevent/Detect/Respond controlهای موجود؛
• Residual risk، Owner و Review date؛
• Outcome معتبر و روش Label؛
• False-positive harm و مسیر اعتراض مشتری.

شدت و احتمال را Range بنویسید، نه دقت ساختگی. Risk register باید با Incident و تغییر محصول به‌روزرسانی شود.

داده ضدتقلب: کمینه، نسخه‌دار و قابل توضیح

هر Signal باید قرارداد داده داشته باشد: تعریف، منبع، زمان، کیفیت، Retention، مجوز دسترسی، Purpose و Transform. شناسه‌های Order، Payment attempt، Account، Session، Device token، Shipment، Refund و Support case باید بدون آشکارکردن PII غیرضروری Join شوند.

نمونه Event:

{
  "event": "payment_verification_result",
  "event_version": 2,
  "order_id": "ord_…",
  "attempt_id": "pay_…",
  "provider": "psp_a",
  "provider_reference": "masked_or_tokenized",
  "result": "verified|failed|unknown",
  "amount_minor": 12500000,
  "occurred_at": "2026-08-11T12:00:00Z",
  "decision_id": "risk_…"
}

شماره کامل کارت، رمز، OTP، Access token، Session ID خام یا متن آزاد حساس را در Log و Feature store نریزید. OWASP Logging Cheat Sheet نیز توصیه می‌کند Secretها، Tokenها، Password و داده شخصی حساس حذف، Mask، Hash یا Encrypt شوند و دسترسی/یکپارچگی Log کنترل شود.

Identity: از Account takeover پیشگیری کنید

Credential stuffing یعنی آزمودن زوج نام کاربری/رمزِ افشاشده از سرویس دیگر. IP block به‌تنهایی کافی نیست؛ حمله می‌تواند توزیع‌شده باشد. راهنمای OWASP Credential Stuffing Prevention دفاع لایه‌ای شامل MFA، تشخیص Credential افشاشده، Rate/connection intelligence، Notification و Step-up را توضیح می‌دهد.

• Passkey/WebAuthn یا MFA مناسب Risk را ارائه کنید؛
• برای Admin، Finance و Refund نقش‌های حساس کنترل قوی‌تر اجباری کنید؛
• Login، Recovery، افزودن Authenticator و تغییر موبایل/ایمیل را یک Flow واحد ببینید؛
• پس از تغییر حساس، Sessionهای مشکوک را Revocation و کاربر را از کانال قبلی مطلع کنید؛
• پاسخ خطا نباید وجود حساب را به‌سادگی افشا کند؛
• Lockout را طوری طراحی کنید که مهاجم نتواند Denial-of-service بسازد؛
• Support override باید Ticket، دلیل، محدودیت و Audit داشته باشد.

مرجع NIST SP 800-63B-4 Password را phishing-resistant نمی‌داند و WebAuthn را نمونه Verifier-name binding معرفی می‌کند. OTP دستی، از جمله SMS OTP، ممکن است مفید باشد اما ذاتاً phishing-resistant نیست؛ پس «MFA» را یک سطح یکنواخت فرض نکنید.

Recovery ضعیف، MFA قوی را دور می‌زند

اگر پشتیبانی بتواند با چند سؤال عمومی MFA را حذف کند، مهاجم همان مسیر را هدف می‌گیرد. Account recovery باید Rate limit، Token یک‌بارمصرف/کوتاه‌عمر، اعلان، Audit، دوره Hold برای تغییر پرریسک و مسیر انسانی کنترل‌شده داشته باشد. پس از Recovery، گزینه invalidate کردن Sessionهای قبلی را در نظر بگیرید.

اطلاعات سفارش اخیر، کد ملی، تاریخ تولد یا سؤال امنیتی لزوماً Secret قابل اعتماد نیستند. Proofing را متناسب با Risk و با حداقل داده طراحی کنید؛ «داده بیشتر» همیشه Identity assurance بهتر نمی‌سازد.

Authorization تراکنش باید Server-side و State-bound باشد

قیمت، تخفیف، گیرنده، مبلغ Refund و وضعیت سفارش را از Client قابل اعتماد ندانید. سرور باید State transition مجاز را بررسی کند و هر تغییر مهم، Authorization قبلی را بی‌اعتبار سازد. OWASP Transaction Authorization بر نمایش داده مهم به کاربر، Credential یکتا/محدودزمان، کنترل ترتیب Flow و Enforcement سمت سرور تأکید دارد.

created → payment_pending → paid_verified → fulfillment_hold
        → payment_failed

fulfillment_hold → approved → packed → shipped
                 → cancelled

paid_verified → refund_requested → refund_approved → refunded

# هر transition:
# actor + reason + policy_version + previous_state + new_state + timestamp

Endpoint نباید اجازه دهد کاربر با تغییر Parameter مستقیماً از payment_pending به shipped یا از refund_requested به refunded برود. برای Object-level authorization و API، راهنمای امنیت API و OWASP را اجرا کنید.

اتصال درگاه: بازگشت مرورگر اثبات پرداخت نیست

در Flow پرداخت، Merchant باید Order داخلی و Payment attempt یکتا بسازد، مبلغ/ارز را سمت سرور نگه دارد، Callback را اعتبارسنجی و نتیجه را Server-to-server با PSP Verify کند. Refresh، Retry و Callback تکراری نباید Order را دوبار Paid یا Fulfilled کند؛ Idempotency و Reconciliation ضروری‌اند.

• Reference/Authority و Status را با Order/attempt مرتبط کنید؛
• Amount/currency/merchant/order binding را طبق قرارداد Provider بررسی کنید؛
• Unknown/timeout را Success یا Failure قطعی فرض نکنید؛
• Job دوره‌ای Reconcile برای اختلاف Merchant/PSP داشته باشید؛
• Secretها در Backend و Secret manager بمانند؛
• پرداخت تکراری، Refund و Webhook/Callback replay تست شوند.

راهنمای اتصال امن درگاه پرداخت این State machine و Failure modeها را عمیق‌تر پوشش می‌دهد. AVS، CVV، ۳‑D Secure یا Chargeback فرایندهای یکسان و جهانی نیستند؛ قابلیت و مسئولیت را در Provider/شبکه/قرارداد خود بررسی کنید. CVV یا OTP نیز به‌تنهایی اثبات نمی‌کند خریدار صاحب مجاز Instrument است.

PCI DSS را درست Scope کنید

PCI DSS برای محیطی است که داده Cardholder شبکه‌های مشمول را ذخیره، پردازش یا منتقل می‌کند یا بر امنیت آن اثر دارد. «داشتن SSL»، «استفاده از درگاه» یا نمایش نشان PCI به‌تنهایی Compliance را ثابت نمی‌کند. دقیقاً تعیین کنید صفحه پرداخت Hosted/Redirect/Iframe است، کدام Scriptها می‌توانند بر آن اثر بگذارند و مسئول Validation چه نهادی است.

راهنمای رسمی PCI SSC درباره Payment page و E-skimming روی Authorization و Integrity اسکریپت‌های صفحه و پایش تغییرات تأکید می‌کند و تصریح دارد دامنه مسئولیت با نهاد مدیریت‌کننده Compliance مانند Acquirer/Payment brand روشن شود. applicability را برای شبکه پرداخت داخلی ایران از روی نام استاندارد حدس نزنید؛ با PSP/Acquirer قرارداد خود تأیید کنید.

E-skimming و Third-party script

حتی اگر داده پرداخت مستقیماً به PSP برود، Script آلوده در صفحه Merchant می‌تواند کاربر را Redirect یا محتوای حساس را دست‌کاری کند. Inventory بسازید:

• هر Script، Owner، Business purpose، Source و نسخه؛
• مجوز اجرا در Checkout و صفحه‌های قبل از پرداخت؛
• Change control و Integrity/monitoring متناسب؛
• Content Security Policy در حالت Report-only سپس Enforcement؛
• Vendor incident/kill switch و Fallback؛
• بررسی Tag manager، Chat، Heatmap و A/B testing script.

برای استقرار تدریجی و جلوگیری از شکستن درگاه، از راهنمای Strict CSP و WordPress استفاده کنید.

Card testing، Bot و Automation abuse

Automation فقط Login را هدف نمی‌گیرد؛ می‌تواند Payment attempt، Coupon، موجودی محدود، Gift card یا API عمومی را مصرف کند. کنترل را در چند سطح Correlate کنید:

• Rate/velocity بر Account، Session، Device token، Instrument token، IP/ASN و Merchant؛
• تعداد Failure و تغییر سریع Amount/recipient؛
• Progressive delay، Queue، Challenge یا محدودیت موقت؛
• Server-side purchase/benefit cap؛
• Idempotency، replay protection و signed request برای Partner API؛
• Alert بر افزایش Failure، Provider response و Decline pattern.

محدودیت IP ثابت، CAPTCHA دائمی یا JavaScript-only gate می‌تواند مشتریان Shared network، ابزارهای کمکی و دستگاه ضعیف را آزار دهد و مهاجم توزیع‌شده را متوقف نکند. Control را تطبیقی، موقت و قابل مشاهده طراحی کنید.

Rule engine: Signal را با حکم اشتباه نگیرید

«IP جدید»، «سفارش اول»، «مبلغ بالا»، «آدرس متفاوت» یا «ساعت غیرمعمول» Signal هستند؛ هیچ‌کدام به‌تنهایی Fraud ثابت نمی‌کنند. Decision engine بهتر چهار خروجی دارد:

• Allow: ادامه بدون اصطکاک اضافه؛
• Challenge: Re-auth یا تأیید متناسب با ریسک؛
• Review/Hold: توقف محدود با SLA و Evidence؛
• Decline/Block: فقط با Policy و Confidence کافی.

هر تصمیم decision_id، policy_version، Signalهای استفاده‌شده، Reason code، Outcome و Override داشته باشد. Rule مبهم مثل «کشور بد» یا Proxy score واحد می‌تواند تبعیض، False positive و خطای توضیح‌ناپذیر بسازد.

Manual review باید Queue عملیاتی باشد

فرستادن همه چیز به «بررسی دستی» کنترل نیست. برای Case این موارد را تعیین کنید:

• Priority بر اساس expected loss و زمان Fulfillment؛
• SLA و Deadline قبل از ارسال/ارائه خدمت؛
• Evidence مجاز و PII حداقلی؛
• Reason code و Playbook تصمیم؛
• چه کسی می‌تواند Approve/Decline/Override کند؛
• Quality sampling و توافق میان Reviewerها؛
• مسیر Escalation و تماس با مشتری بدون افشای Rule؛
• Feedback پس از Outcome برای Rule/Model.

Reviewer نباید برای رسیدن به «Fraud caught» بیشتر پاداش بگیرد؛ این KPI مشتری سالم را قربانی می‌کند.

AI و Machine learning: مدل قاضی نیست

مدل می‌تواند Pattern چندSignalی و Nonlinear را پیدا کند، اما Label با تأخیر، Bias، Concept drift، Attack adaptation و Feedback loop دارد. اگر سفارش‌های ردشده هیچ‌گاه Outcome واقعی نمی‌گیرند، مدل فقط درباره سفارش‌های پذیرفته‌شده یاد می‌گیرد.

Model update باید Shadow، Canary و Rollback داشته باشد. Auto-decline را ابتدا با محدوده کم‌ریسک و شواهد کافی ارزیابی کنید.

Fulfillment: تصمیم ریسک بعد از پرداخت تمام نمی‌شود

ریسک می‌تواند در تغییر گیرنده، درخواست ارسال فوری، تغییر آدرس از پشتیبانی یا سفارش چندبخشی ظاهر شود. برای سفارش پرریسک:

• Hold کوتاه و زمان‌دار، نه تعلیق نامحدود؛
• تغییر مقصد با Re-auth و Audit؛
• Pick/pack با SKU/serial/condition evidence متناسب؛
• Proof of delivery با کمینه‌سازی داده شخصی؛
• آشتی Order/Shipment/Delivery/Return؛
• Escalation در صورت Provider یا پیک نامطمئن.

Delay امنیتی باید در Promise تحویل و اطلاع‌رسانی لحاظ شود. مشتری نباید بدون توضیح عملیاتی در وضعیت «در حال پردازش» بماند.

Refund و Return: هم Abuse را کنترل کنید، هم حق مشتری را

سیاست سخت و مبهم می‌تواند اختلاف و شکایت واقعی را بیشتر کند. Return fraud را با «همه مرجوعی‌ها مشکوک‌اند» حل نکنید:

• Policy قابل فهم، بازه و شرط هر Category؛
• RMA/Case ID یکتا و ارتباط با Order line؛
• ثبت SKU، Serial، وزن، Condition و Exception متناسب؛
• Refund به Instrument/مسیر مجاز طبق Provider و Contract؛
• Dual approval برای مبلغ/نقش حساس؛
• جداسازی wrong item، damaged، not received، remorse و confirmed abuse؛
• مسیر اعتراض و بازبینی انسانی.

قوانین و حقوق مشتری در ایران را با راهنمای قوانین فروشگاه اینترنتی و مشاور حقوقی جاری تطبیق دهید؛ کنترل Fraud جایگزین تعهد قانونی و قراردادی نیست.

Promotion، Loyalty و Gift value

زیان فقط از Payment نیست. Coupon، Referral، امتیاز، Wallet و Gift code دارایی مالی‌اند. Eligibility و Redemption باید Server-side، Idempotent و دارای Cap باشد. Relationship signal مانند Device/address/payment token می‌تواند Review بسازد، اما اشتراک خانوادگی یا سازمانی را هم در نظر بگیرید.

برای Clawback، Expiry، انتقال امتیاز و Support override Policy روشن داشته باشید. کمپین قبل از Launch Abuse case و Kill switch می‌خواهد.

پشتیبانی و پنل ادمین: مسیر کم‌صدای تقلب

مهاجم ممکن است به‌جای شکستن Login، Agent را قانع کند ایمیل، موبایل، آدرس یا Refund destination را تغییر دهد. کنترل‌های لازم:

• Role-based access و حداقل مجوز؛
• MFA phishing-resistant برای نقش حساس؛
• Just-in-time elevation و Approval دو نفره برای Refund بزرگ؛
• عدم نمایش Secret/Payment data به Agent؛
• Callback یا Re-auth برای تغییر حساس؛
• Session recording هدفمند/قانونی یا Audit event کمینه؛
• Offboarding فوری و بازبینی دوره‌ای Access.

Rule یا Threshold دقیق را در پاسخ مشتری افشا نکنید؛ دلیل قابل فهم و مسیر حل ارائه کنید.

Phishing و جعل برند

Fraud خارج از دامنه شما نیز به مشتری و برند آسیب می‌زند. دامنه‌های مشابه، صفحه جعلی پرداخت، پیامک یا اکانت جعلی را در Runbook بیاورید:

1. کانال رسمی و دامنه/شماره‌های معتبر را شفاف اعلام کنید.
2. هیچ‌گاه Password، OTP یا اطلاعات کامل کارت را در پشتیبانی درخواست نکنید.
3. گزارش مشتری را با Evidence حداقلی و Ticket بگیرید.
4. Domain/hosting/platform/PSP و مراجع ذی‌ربط را طبق Runbook مطلع کنید.
5. اگر حساب/Session در خطر است، Recovery و Revocation ارائه کنید.
6. هشدار عمومی را بدون انتشار داده حساس و با متن دقیق منتشر کنید.

«آموزش کاربر» جای کنترل فنی نیست؛ Passkey/WebAuthn به‌دلیل binding به دامنه در برابر بسیاری از Phishing flowها مقاوم‌تر از OTP دستی است.

حریم خصوصی و جلوگیری از Surveillance بی‌مرز

Mouse movement، typing cadence، Device fingerprint، IP intelligence و Identity graph می‌توانند داده حساس یا خطاپذیر باشند. پیش از جمع‌آوری بپرسید:

• Purpose دقیق چیست و آیا Signal کم‌تهاجمی‌تری وجود دارد؟
• Notice/consent یا مبنای مجاز در حوزه شما چیست؟
• Retention حداقل و Delete/Access process چگونه است؟
• Vendor داده را کجا نگه می‌دارد و برای چه استفاده ثانویه‌ای؟
• کدام Role Raw data را می‌بیند؟
• آیا Feature برای گروهی Proxy تبعیض‌آمیز می‌سازد؟
• اگر داده Leak کند، Impact چیست؟

Feature engineering نباید PII خام را بی‌دلیل تکثیر کند. Tokenization، Hash با طراحی صحیح، Aggregation و Short retention را ارزیابی کنید.

Incident response برای موج تقلب یا ATO

در موج حمله، Auto-block وسیع می‌تواند Incident دوم بسازد. Emergency rule باید Owner، Expiry، Impact monitor و Rollback داشته باشد.

Metric tree: زیان، پذیرش، اصطکاک و عملیات

تعریف Fraud loss شامل چه چیزهایی است—کالا، ارسال، کارمزد، Refund، بازیابی؟ Numerator و Denominator را نسخه‌دار کنید. Dispute/Chargeback metric فقط وقتی معنا دارد که در شبکه و قرارداد شما همان Process وجود داشته باشد.

تشخیص False positive

سفارش ردشده Outcome طبیعی ندارد؛ نمی‌دانید واقعاً سالم بود یا نه. برای برآورد:

• نمونه‌ای از Review/Challenge را با کنترل ریسک آزاد کنید؛
• Appeal و Support overturn را ثبت کنید؛
• مشتری بازگشتی سالم و خرید موفق بعدی را ببینید؛
• Rule جدید را Shadow یا Holdout کنید؛
• Manual review agreement و QA sampling داشته باشید؛
• Segmentهای با افت approval غیرعادی را بررسی کنید.

هدف عدد Precision زیبا نیست؛ کاهش هزینه واقعی در Guardrailهای پذیرفته‌شده است.

Build یا خرید سامانه ضدتقلب؟

دموی Vendor با «کاهش X درصد تقلب» قابل انتقال نیست؛ Baseline، Label و Cost شما متفاوت است. خرید را با Budget مبتنی بر Risk هماهنگ کنید؛ راهنمای بودجه امنیت سایت برای اولویت Controlها مفید است.

سناریوی ایران: فروشگاه پوشاک در کمپین نوروز

فروشگاه ایرانی در اسفند با رشد ترافیک، Coupon abuse، Login failure، پرداخت ناموفق و مرجوعی پس از تعطیلات روبه‌رو است. برنامه قابل دفاع:

1. Order، Payment attempt، PSP reference، Campaign، Shipment و Return را با ID یکتا متصل می‌کند.
2. نتیجه پرداخت را از Browser return قبول نمی‌کند و Verify/Reconcile سمت سرور دارد.
3. Login و Coupon endpoint را با velocity چندسیگنالی و Challenge تطبیقی محافظت می‌کند.
4. افزودن گیرنده/آدرس جدید به سفارش پرداخت‌شده را Re-auth و Audit می‌کند.
5. سفارش‌های پرریسک را با Hold زمان‌دار و Queue دارای SLA بررسی می‌کند؛ همه سفارش اول‌ها را رد نمی‌کند.
6. انبار SKU/condition و پیک Delivery exception را به Case متصل می‌کنند.
7. Refund فقط پس از State مجاز و تأیید نقش‌های مربوط انجام می‌شود.
8. Rule اضطراری کمپین Expiry و Rollback دارد؛ نتایج پس از نوروز با Seasonality تفسیر می‌شوند.

قابلیت‌هایی مانند AVS، Chargeback یا ۳‑D Secure را از Playbook کارت‌های بین‌المللی کپی نمی‌کند؛ Provider، شبکه، قرارداد پذیرندگی و فرایند داخلی ایران را مستقیماً بررسی می‌کند. هم‌زمان UX Checkout را با راهنمای بهینه‌سازی Checkout کنترل می‌کند تا Security friction فروش سالم را نابود نکند.

برنامه ۹۰روزه برای تیم کوچک

روز ۱ تا ۳۰: Baseline و کنترل حیاتی

• Journey، Asset، Provider، Risk register و Ownerها را ثبت کنید.
• Order/payment state، Verify، Idempotency و Reconciliation را تست کنید.
• Admin/Refund access و MFA را اصلاح کنید.
• Loss ledger و تعریف Outcome/False positive را بسازید.

روز ۳۱ تا ۶۰: Detect و Respond

• Event schema، Log hygiene و Alertهای Login/payment/refund را پیاده کنید.
• Allow/Challenge/Review/Decline و Reason code را نسخه‌بندی کنید.
• Manual review queue، SLA و Quality sample بسازید.
• ATO/payment/refund/phishing Runbook را Tabletop کنید.

روز ۶۱ تا ۹۰: Pilot و یادگیری

• یک Rule یا Vendor را در Shadow mode ارزیابی کنید.
• Approval، confirmed loss، challenge success و review cost را بسنجید.
• False positive و Segment disparity را نمونه‌گیری کنید.
• Controlهای موفق را Scale و Ruleهای پرضرر را Rollback کنید.

چک‌لیست عملیاتی ماهانه

• Risk register و Top loss scenario بازبینی شده‌اند.
• PSP/Merchant/Reconciliation اختلاف حل‌نشده ندارد.
• Admin، Support و Refund access بازبینی شده است.
• Emergency rule منقضی اما فعال باقی نمانده است.
• Model/Rule/Feature drift و Missing data بررسی شده است.
• Manual review SLA، Overturn و Agreement دیده شده‌اند.
• False positive، challenge success و Support complaint کنار loss گزارش شده‌اند.
• Third-party script، Tag manager و Payment flow تغییر کنترل‌نشده ندارند.
• Log شامل Secret/OTP/Card data/PII غیرضروری نیست.
• Incident و Near miss به Test/Runbook/Policy برگشته‌اند.

پرسش‌های متداول

رایج‌ترین نوع تقلب در فروشگاه اینترنتی چیست؟

پاسخ جهانی و ثابتی وجود ندارد. نوع کالا، کانال، کشور، PSP، Account model و سیاست بازگشت الگو را تغییر می‌دهد. از Loss ledger خود بین ATO، payment/order fraud، promotion abuse، delivery/return dispute و خطای عملیاتی تفکیک بسازید.

فروشگاه کوچک بدون AI از کجا شروع کند؟

از State و کنترل پایه: Verify سمت سرور، Idempotency، Reconciliation، MFA برای نقش حساس، Rate limit، Log امن، Queue بررسی محدود و Runbook. داده قابل اعتماد و کنترل Flow معمولاً پیش‌نیاز هر مدل است.

آیا MFA جلوی Account takeover را می‌گیرد؟

ریسک را بسیار کم می‌کند، اما Recovery ضعیف، Session theft، Social engineering یا MFA phishing همچنان مسیر حمله‌اند. Passkey/WebAuthn phishing-resistant‌تر از OTP دستی است و تغییر Authenticator/موبایل نیز باید محافظت شود.

آیا سفارش پرریسک را خودکار رد کنیم؟

فقط وقتی Policy، Evidence، هزینه خطا و مسیر اعتراض روشن است. در بسیاری از موارد Challenge یا Review زمان‌دار بهتر از Decline قطعی است. Rule را ابتدا Shadow کنید و False positive را بسنجید.

موفقیت سیستم ضدتقلب را چگونه بسنجیم؟

Confirmed net fraud loss را کنار approval، false-positive estimate، challenge success، review SLA/cost، support complaint و contribution margin ببینید. کاهش Fraud rate همراه با رد مشتری سالم یا رشد هزینه عملیات موفقیت کامل نیست.

جمع‌بندی

برنامه ضدتقلب بالغ از «ابزار تشخیص» شروع نمی‌شود؛ از Flow، State، Owner، Risk و Outcome شروع می‌شود. Identity و Recovery، پرداخت و Reconciliation، Fulfillment و Return، Support و Admin همه بخشی از یک سیستم‌اند. Signal به‌تنهایی حکم نیست و Model به‌تنهایی قاضی نیست.

Control را لایه‌ای و Server-side بسازید، داده را کمینه و قابل توضیح نگه دارید، مشتری سالم را به‌عنوان Guardrail ببینید و برای Incident و Recovery تمرین کنید. اعتماد نیز با شعار امنیت ساخته نمی‌شود؛ برای اتصال کنترل فنی به وعده، Evidence و جبران خطا، راهنمای جلب اعتماد مشتری در فروشگاه اینترنتی را بخوانید.