محرك قواعد الاحتيال في المدفوعات: القواعد والخطوات والمراجعة

ماذا ستخرج به من هذا المقال؟

كل عملية دفع تمرّ بسؤال واحد: نسمح لها أم لا؟ السؤال يُختزل عادةً في قيمة منطقية، بينما القرار في المدفوعات ثلاثي: قبول، أو رفض، أو إرسال إلى المراجعة، وأحيانًا تعزيز التحقق قبل القبول. المحرك الذي يهمل هذا التعدد ينتهي في أحد طرفين: حاجز يوقف عملاء مشروعين، أو شبكة تمرّر أول محاولة احتيال غير مرصودة.

في هذا المقال نبني المحرك من الأسفل إلى الأعلى: الطبقات التي تُبنى فوقها القواعد، ثم جمع سياق القرار، ثم تحويل الإشارات إلى درجة خطر وعتبات لكل شريحة، ثم تسجيل القرار بما يسمح بإعادة تشغيله بعد أشهر، ثم ضبط القواعد دون كسر المسار الشرعي.

ثلاثة قرارات لا قراران: لماذا الرفض ليس مقابل القبول

القاعدة الأولى: لا تُرجع allow: boolean. كلفة الرفض لا تظهر في كشف الحساب: عميل مشروع أُغلقت بطاقته أثناء شراء شرائية، وتاجر خسر مبيعات متكررة. القبول الخاطئ يترك أثره بصمت عبر المطالبات بعد أسابيع. ولأن الكلفتين غير متماثلتين، لكل نتيجة مسار تشغيلي.

قرار «المراجعة» هو الأدق لأنه المكان الوحيد الذي يمنع الخسارة ويمنع ظلم العميل معًا، لكنه الأغلى. لذلك يُقاس بعدد المراجعات لكل ألف عملية وبنسبة ما ينتهي منها إلى احتيال فعلي. من يرفع كل شيء إليه لا يملك محركًا بل طابورًا.

طبقات القواعد: من الإشارة الأرخص إلى الأدق

المحرك الناضج يبني طبقات متدرّجة، كل طبقة تُضيّق المجال للتي تليها، وكل طبقة تجيب: لماذا توقّفنا؟

الطبقة الأولى: الجهاز والجلسة

بصمة الجهاز، وعنوان IP ونوعه (عميل منزلي أم نطاق استضافة)، وإعدادات المتصفح، وعمر الجلسة. إشارات رخيصة متاحة قبل أي اتصال خارجي، وقواعدها حتمية. اجعل hardStop في حالات محددة فقط، فهي الأكثر عرضة للخطأ مع المتنقلين.

الطبقة الثانية: السمة والسلوك

كم محاولة في آخر ساعة، كم بطاقة مختلفة على الحساب، وهل المبلغ يتبع توزيع العميل المعتاد أم قفزات مفاجئة. هذه القواعد تُحسب من مخزن المعاملات وتحتاج نافذة صريحة: «3 محاولات في 10 دقائق» و«5 في 24 ساعة» قراران مختلفان.

الطبقة الثالثة: السجل والسمعة

معدل نجاح المستخدم، نسبة مطالباته التاريخية، وسمعة الجهاز نفسه. أثقل استعلامًا لأنها تنضمّ بين جداول بعيدة، فلا بدّ لها من ميزانية زمنية وسلوك عند التجاوز. لا تعطّل طبقة كاملة بسبب خلل في خدمة خارجية؛ عطّل الحقل ووثّق ذلك.

الترتيب ليس اعتباطيًا: القاعدة الرخيصة قبل المحسوبة الثقيلة، وإلا دفعت كلفة الاستعلام الغالي على كل عملية. وتشغيل كل الطبقات يجعل سجل القرار أثمن لأنه يحوي الأدلة. الحل: افصل مسار التنفيذ (بتوقف مبكر) عن مسار التسجيل (كامل).

type Outcome = "approve" | "review" | "decline" | "challenge";



function evaluate(ctx: PaymentContext, rules: Rule[], version: string): Decision {

  const decisionId = crypto.randomUUID();

  const hits: RuleHit[] = [];

  let score = ctx.baseScore ?? 0;        // 0..100

  let stop: Outcome | null = null;



  for (const rule of sortByLayerAndWeight(rules)) {

    if (rule.expiresAt && rule.expiresAt < Date.now()) continue;   // TTL إلزامي

    if (ctx.degradedFields.includes(rule.requires)) continue;          // لا نحكم بغياب الإشارة

    if (!matches(rule, ctx)) continue;



    hits.push({ ruleId: rule.id, layer: rule.layer, delta: rule.weight, reasonCode: rule.reasonCode });

    score += rule.weight;



    if (rule.hardStop) { stop = rule.action; break; }   // مسار التنفيذ يتوقف مبكرًا

    // مسار التسجيل يكمل لجمع الأدلة الكاملة

  }



  const outcome = stop ?? decideBySegment(score, ctx.segment);

  return { decisionId, outcome, score: clamp(score, 0, 100), hits, rulesetVersion: version };

}

ثلاثة قرارات في الشيفرة: القواعد مرتّبة بالطبقة؛ ولكل قاعدة تاريخ انتهاء يُلغى به تلقائيًا؛ وhardStop وحده يوقف التقييم مبكرًا، أما الرفض العادي فيُسجَّل ويكمل جمع الأدلة.

سياق القرار: تجميع الحقائق قبل الحكم

قبل تشغيل أي قاعدة، يجب أن تملك PaymentContext: كل ما تحتاجه القواعد في كائن واحد مُجمَّد. البناء هنا هو الجزء المهل في النظام لا الحكم.

القاعدة الذهبية: ميزانية زمنية لكل حقل، لا مهلة شاملة واحدة. المهلة الشاملة إمّا تجعل الطابور ينتظر أبطأ مصدر، أو تقطع أغلى مصدر فتُفقد إشارة حسّاسة.

-- سمات سلوكية من نافذة 24 ساعة (مثال)

SELECT

    account_id,

    count(*)                           AS attempts_24h,

    count(DISTINCT device_fingerprint) AS devices_24h,

    count(DISTINCT card_fingerprint)   AS cards_24h,

    sum(amount)                        AS volume_24h,

    sum(amount) / nullif(avg(amount),0) AS amount_velocity

FROM payment_attempt

WHERE created_at >= now() - interval '24 hours'

  AND status IN ('authorized','captured','declined')

GROUP BY account_id

HAVING count(*) >= 3

    OR count(DISTINCT card_fingerprint) >= 3;

cards_24h وamount_velocity ليسا رقمين فقط: الأول مؤشر على card testing حيث تُجرَّب بطاقات متعددة على تاجر واحد، والثاني انحراف عن سلوك العميل المعتاد. القاعدة الجيدة تربط كل حقل بقرار وبسبب مكتوب.

تجزئة الخطر: من الإشارات إلى عتبات قابلة للضبط

الدرجة ليست بديلًا عن القواعد، بل طريقة لتحويل إشارات متفاوتة إلى رقم واحد: درجة أساس، ثم وزن لكل قاعدة مطابقة، مع جمع reason codes من القواعد التي أحدثت التغيّر. بذلك تصبح الدرجة قابلة للتفسير: 30 نقطة أساس، و25 من محاولات متعددة البطاقات، و10 من جهاز جديد.

الخطأ الشائع هو عتبة واحدة لكل النظام. عتبة 70 تعني شيئًا في الدفع بالحضور وشيئًا آخر بدون حضور، وشيئًا ثالثًا في الدفع المحلي مقابل العابر للحدود. اجعل العتبة دالة للشريحة (نوع اللمس، الموقع، القناة، فئة التاجر، حداثة العلاقة). لا يعني هذا تغييرها كل يوم؛ يعني أن السبب يبقى مفسّرًا بعد شهور.

سجل القرار: أهم جدول في النظام

بعد شهر من التشغيل، أول سؤال ليس «لماذا رُفضت هذه العملية؟»، بل «كيف أعرف أن هذا الرفض كان صحيحًا؟». الجواب سجل قرار مُصمَّم للتشخيص لا للتدقيق.

اجعل لكل عملية decision_id واحدًا يُولَّد قبل تنفيذ أي قاعدة، ويرتبط بكل ما بعدها: محاولة الدفع، ونتيجة المعالجة، وقرار المراجع البشري، ثم نتيجة المطالبة إن وصلت. هذا الخيط يحوّل ملفًا إلى بيانات: بدونه لا تنسب المطالبات إلى قاعدة بعينها، ولا تعيد تشغيل القرار على دفعة قديمة.

• مدخلات مُجمَّدة: قيمة كل حقل في PaymentContext وقت القرار، لا مرجعًا لكائن حي.


• نسخة القواعد: ruleset_version ووزن كل قاعدة وقت التنفيذ.


• مساهمات القواعد: معامل وسبب ودرجة قبل/بعد لكل قاعدة مطابقة، لا المجموع فقط.


• النتيجة والزمن: القرار مع اسم الشريحة، وزمن كل حقل، وحقول degraded.


• الحلقة الختامية: قرار المراجع ونتيجة المطالبة يُلحقان لاحقًا كسطر جديد، دون تعديل السجل.

هذا يجعل إعادة التشغيل ممكنة: تُعاد الدالة على المدخلات المُجمَّدة وتُقارن النتيجة، واختلافها يعني أن القواعد تغيّرت. احتفظ بالسجل مدة تكفي لتغطية دورة المطالبة كاملة.

ضبط القواعد دون كسر العمليات الشرعية

القاعدة التي تُطلق في ذروة البيع ليست تحسّنًا بل حادث. المسار الآمن يحوّل «تعديل قاعدة» إلى نشر ذا مراحل لا إلى commit.

• وضع الظل (shadow): شغّل القاعدة على حركة الإنتاج دون أثر: تُسجَّل نتيجتها المحتملة، لكن القرار يبقى للمسار القائم. هذه الوسيلة الوحيدة لقياس كم عملية شرعية سترفضها.


• الإطلاق المتدرّج: نسبة صغيرة أولًا (1% ثم 5% ثم 25%) على شريحة محددة، بنافذة مراقبة بالساعات لا بالدقائق.


• مهلة انتهاء إلزامية (TTL): ما لم تُحدَّث القاعدة خلال 90 يومًا يختفي تاريخ انتهاءها، فلا تتحول «قاعدة مؤقتة» إلى دائم.


• مفتاح إيقاف مستقل: تعطيل قاعدة واحدة دون إيقاف النشر كله.


• عينا القرار: أي تغيير يلمس عتبة أو يضيف قاعدة حاسمة يمرّ على مراجع ثانٍ.


• تقويم التجميد: نافذة منع تغيير في ذروة نهاية الشهر أو إطلاق تاجر كبير، لأن بيانات تلك الفترة متحيزة.

مؤشرات الإيقاف ليست «عدد حالات الاحتيال» فقط. راقب معدلات القبول والمراجعة والرفض، ومعدل المطالبة على أساس الألف عملية داخل الشريحة نفسها، ونسبة المراجعات التي انتهت إلى «ليست احتيالًا» من مراجعة بشرية عشوائية. رفع الرفض على شريحة عملاء مخلصين دون قياس بشري تركٌ للضبط للصدفة.

أخطاء شائعة

قائمة تحقق

• كل قاعدة تُنتج قيمة صريحة (قبول/مراجعة/رفض/تحقق) مع مهلة تنفيذ ومعالجة احتياطية عند التجاوز.


• كل قاعدة تحمل: مالكًا، وطبقة، ونافذة زمنية، ووزنًا، وسببًا، وتاريخ انتهاء، ونسخة قواعد.


• ميزانية زمنية لكل حقل في سياق القرار، وسلوك التجاوز معلن كقرار لا كتفصيل برمجي.


• سجل قرار كامل مربوط بـ decision_id: مدخلات مُجمَّدة، ومساهمات القواعد، ونسخة القواعد، ثم نتيجة المراجعة والمطالبة.


• لوحة مؤشرات لكل شريحة: القبول والمراجعة والرفض، ومعدل المطالبة، ونسبة المراجعات التي انتهت إلى «غير احتيال».

الأسئلة الشائعة

هل الأفضل رفض العملية فورًا أم إرسالها للمراجعة؟

يعتمد على كلفة عدم التماثل وسرعة المراجعة. إن كانت المراجعة تُحسم في دقائق وقناة الدفع لا تدعم خطوة تحقق، فالرفض ليس الأوفر: تحمي نفسك من احتمال صغير، وتخسر عميلاً كان سيشتري. في التجارة الإلكترونية المراجعة السريعة أفضل من الرفض «الآمن»، لأن العميل الذي يختفي ليجرّب مكانًا آخر لا يعود.

كيف أعرف أن قاعدة قاسية أكثر من اللازم قبل أن يشتكي العملاء؟

بالقياس لا بالانتظار. عيّن نسبة صغيرة من قرارات «القبول» واعرضها على مراجع بشري يبحث عن علامات احتيال دون أن يعرف أنها عيّنة. هذه المراجعة بالعينة تعطيك تقديرًا لنسبة الإيجابيات الكاذبة لكل قاعدة، فتحوّل نقاش «هل هذه القاعدة قاسية؟» إلى رقم. وتغيّر معدل القبول دون تغيّر المطالبات إشارة إلى رفض مشروع.

الخلاصة

الخطوة التالية

بعد ضبط القواعد وتخزين سجلها، تظهر الخطوة التالية: كيف يقرأ فريق المخاطر هذه القرارات على دفعات كاملة بدل حالة واحدة في اليوم، بتجميعها حسب القاعدة والشريحة والوقت وربطها بمعدل المطالبات بعد أسابيع. هذا ينقل المحرك من «يصدر قرارًا لكل عملية» إلى «يتعلّم من دفعة قرارات».

كيف تستخدم هذا المقال في عمل حقيقي؟

ابدأ من القيود الحقيقية: حجم معاملاتك، وزمن الاستجابة المقبول عند الدفع، والمزودون المشاركون في خطوة التحقق، والالتزامات على حفظ السجلات. ابدأ بطبقتين فقط (جهاز وسمة)، واجعل كل قاعدة قابلة للعزل والتعطيل بتاريخ انتهاء، واطلب من سجل القرار أن يجيب عن «لماذا؟» في أقل من دقيقة. إن لم تستطع الإجابة في أول أسبوع، فالتعقيد سيضاعف المشكلة لا يحلها.

flowchart LR

    A["القناة المصرفية"]

    B["التحقق والهوية"]

    C["قواعد الأعمال"]

    D["النظام البنكي"]

    E["التسجيل والتسوية"]

    A --> B

    B --> C

    C --> D

    D --> E