تنجح مراقبة معاملات العملات المشفّرة حين يتوقف السجلّ العام (public ledger) عن كونه جدارًا من الرموز التجزيئية (hashes) ويبدأ في التحوّل إلى عملائك وأطرافهم المقابلة والواجبات التبليغية المحدّدة التي يُنشئها كل تحويل. فالسلسلة تخبرك بما انتقل وإلى أين، لكنها لا تخبرك بمن، ولا لماذا، ولا أيّ التزام تفعّل للتوّ. وبناء هذا الربط وتسويته هو العمل بأكمله.
الخطأ الذي ترتكبه الفرق في أول مشروع تشفير لها هو التعامل مع بيانات السلسلة كأنها نسخة أنظف من مسارات البطاقات (card rails). وهي ليست كذلك. فبيانات السلسلة عامّة وشبه مجهولة (pseudonymous)، مُهيكَلة من أجل التوافق (consensus) لا من أجل الامتثال. كل ما تحتاجه مرئيّ، ولا شيء منه تقريبًا موسوم. على نظام المراقبة أن يضيف ثلاث طبقات تتركها السلسلة خارجًا: مَن يتحكّم في العنوان، وكيف يتصرّف ذلك العنوان عبر الزمن، وما الذي تتوقّع منك جهتك الرقابية فعله حيال ذلك.
ابدأ بالإسناد، وعامله كدليل
يسجّل السجلّ تحويلًا بين عنوانَين. أما التزامك فيتعلّق بأشخاص وكيانات. وسدّ هذه الفجوة هو تحليل هوية الكيانات (entity resolution) مقابل بيانات البلوكتشين، وهو موضع معظم القيمة التحليلية.
ستعتمد على مصادر تحليلات السلسلة التجارية في الجزء الأكبر منه، لأن وسم المنصّات والخلّاطات (mixers) والجسور (bridges) وخدمات المقامرة والعناوين الخاضعة للعقوبات على نطاق واسع مشكلة جمع بيانات أمضى هؤلاء المورّدون سنوات في حلّها. ما تملكه أنت هو الربط: وصْل إسناد التجميع (cluster attribution) الخاص بالمورّد بعناوين الإيداع والسحب التي خصّصتها لعملائك أنت. أخطئ في هذا الربط فتشير كل التنبيهات اللاحقة إلى الحساب الخطأ.
بعض الأمور التي نصرّ عليها عند دمج الإسناد:
- خزّن الإسناد الذي تصرّفت بناءً عليه، لا الإسناد الحالي فحسب. فوسوم المورّد تتغيّر مع إعادة تحليل التجمّعات (clusters). إذا انطلق تنبيه لأن عنوانًا وُسم ككيان خاضع للعقوبات في يوم التحويل، فيجب أن يُظهر مسار التدقيق (audit trail) لديك ذلك الوسم كما كان حينها، مع مصدره ودرجة ثقته. الصحّة المرتبطة بلحظة زمنية محدّدة (point-in-time correctness) هي ما يميّز تقرير معاملة مشبوهة (SAR) قابلًا للدفاع عنه عن مجرّد تخمين.
- احتفظ بسلسلة النسب (lineage) من المعاملة الخام إلى التنبيه المُثرى. فحين يسأل مفتّش لماذا قدّمت البلاغ، تريد أن تتتبّع التنبيه رجوعًا عبر التحويل المفكوك الترميز، وإسناد العنوان، وسجلّ العميل، والقاعدة التي أطلقته، دون إعادة بناء أي شيء يدويًّا.
- عامل درجة الثقة كحقل، لا كحاشية. فإسناد التجميع احتمالي بطبيعته. وقاعدة مراقبة تعامل وسم خلّاط بثقة 60% مثل وسم منصّة بثقة 99% ستغرقك في الضجيج.
اقرأ السلسلة قراءةً صحيحة قبل أن تستدلّ منها
مكافحة غسل الأموال للعملات المستقرّة تحيا أو تموت على فكّ الترميز (decoding). فتحويل USDC أو USDT لا ينقل أي قيمة أصلية؛ إنه استدعاء لعقد رمزي (token contract) يُصدر حدث Transfer. إذا كان خط تجميع البيانات (ingestion pipeline) لديك يقرأ القيمة الأصلية ويتجاهل السجلّات (logs)، فستفوّت غالبية نشاط العملات المستقرّة، أو ستحتسبه مكرّرًا مقابل معاملة الغاز (gas). وقد رأينا الحالتين معًا.
يعني التحليل الجنائي للبلوكتشين (blockchain forensics) كذلك فهم الأنماط التي تخفي النيّة:
- سلاسل التقشير (peel chains)، حيث تنتقل القيمة عبر تسلسل طويل من العناوين يتخلّى كلٌّ منها عن مبلغ صغير، مصمّمة لهزيمة عدّ القفزات السطحي (naive hop-counting).
- الحركة عبر الجسور والسلاسل المتقاطعة (cross-chain)، حيث يغادر التدفق سجلًّا ليعاود الظهور على آخر. والمراقبة التي تتوقّف عند حدود السلسلة تفقد الخيط في المكان نفسه الذي يريد الغسل أن يفقده فيه بالضبط.
- التفاعلات مع العقود الخاصة بالخلّاطات (mixers) وموجّهات التبادل اللامركزي (DEX routers) وأدوات الخصوصية، والتي تبدو كتحويلات عادية ما لم تفكّ ترميز الوجهة.
تضيف العملات المستقرّة آليات خاصّة بالجهة المُصدِرة ينبغي أن تستوعبها كإشارات. فبإمكان كلٍّ من Circle وTether تجميد العناوين وإدراجها في القائمة السوداء. وحين يُدرَج طرف مقابل يتعامل معه عميلك في القائمة السوداء من قِبل الجهة المُصدِرة، فذلك حدث مراقبة قائم بذاته، وكثيرًا ما يقع قبل أن يحدّث أي مورّد وسومه. والاستردادات إلى العملة الورقية حدث منفصل آخر: نقطة سحب (off-ramp) يجب أن تُسوّى مقابل السجلّ البنكي للعميل، لأن استردادًا لا تُظهره دفاترك يمثّل خللًا في التسوية (reconciliation break) يستحقّ التحقيق.
السلوك لا يقلّ أهمية عن نقاط النهاية. فالخصائص المرتبطة بلحظة زمنية محدّدة على مدى تاريخ العنوان، وزمن المكوث (dwell time) بين الاستلام والتحويل اللاحق، ومصادر التمويل، والتعرّض للخدمات عالية المخاطر، تخبرك أكثر مما تخبرك به أي معاملة مفردة. ابنِ هذه الخصائص في مخزن خصائص (feature store) بالانضباط نفسه الذي تستخدمه لاحتيال البطاقات: بلا نظر مستقبلي (lookahead)، بلا تسرّب لمعلومات لم تكن معروفة وقت المعاملة، ومع مجموعة تقييم (eval set) موثّقة كي تتمكّن من قياس ما إذا كانت قاعدة جديدة تُمسك فعلًا بأنماط الاحتيال (typologies) بدلًا من مجرّد إطلاق مزيد من التنبيهات.
ادمج الالتزامات كمنطق من الدرجة الأولى
قاعدة السفر (Travel Rule) هي المكان الذي تلتقي فيه تحليلات السلسلة بالتنظيم مباشرةً. فحين يرسل عميلك عملة مشفّرة إلى مزوّد خدمات أصول مشفّرة آخر (crypto-asset service provider)، تكون مدينًا لمزوّد المستفيد بمعلومات المُنشئ والمستفيد، وتتوقّع المثل عائدًا إليك. وقد ألغت لائحة الاتحاد الأوروبي لتحويل الأموال (اللائحة (EU) 2023/1113) عتبة الحدّ الأدنى (de minimis) التي تعتمد عليها مسارات البطاقات: فبالنسبة للتحويلات بين مزوّد ومزوّد، ينطبق الالتزام على أي مبلغ، في حين تُفعّل التحويلات من محفظة ذاتية الاستضافة أو إليها بما يتجاوز 1000 يورو واجبَها الخاصّ في التحقّق من الملكية. وكون الطرف المقابل منصّة مستضافة أم محفظة ذاتية الاستضافة هو ما يحدّد أي التزام يُفعَّل، لذا يجب أن يكون هذا التصنيف في صميم نموذج البيانات، لا في خطوة إثراء مركّبة لاحقًا.
نمط الفشل العملي هو نظام مراقبة يولّد تنبيهات لا يستطيع أحد اتخاذ إجراء بشأنها لأن الالتزام لم يُنمذَج. فالتنبيه الذي يقول “تعرّض عالي المخاطر” هو مهمّة. أما التنبيه الذي يقول “تحويل إلى محفظة ذاتية الاستضافة يتجاوز العتبة، بيانات الطرف المقابل بموجب قاعدة السفر مطلوبة، تصنيف مخاطر العميل متوسّط” فهو قرار يستطيع المحلّل إغلاقه. رمّز الالتزام، لا مجرّد درجة المخاطر.
أمران يبقيان النظام كله نزيهًا عبر الزمن. الأول: موازنة إيجابيات كاذبة (false-positive budget) متّفق عليها مع فريق الامتثال قبل أن تضبط أي شيء، كي يكون للمعالجة الآلية الكاملة (straight-through processing) هدف لا مجرّد انطباع، وكي لا يُرخي أحد القواعد سرًّا لتصفية تراكم من الحالات. والثاني: مراقبة الانحراف (drift monitoring) على السلسلة وعلى دفاترك أنت معًا. فالرموز الجديدة، والجسور الجديدة، وتقنيات الخلط الجديدة، وتغيّر سلوك العملاء، كلّها تحرّك الأرض من تحت نموذج بدا مُعايَرًا جيدًا عند الإطلاق. أعد فحص تغطية الإسناد ودقّة التنبيهات مع نهاية كل ربع سنة على الأقل، وأبقِ مجموعة التقييم مواكِبة، لأن نمط احتيال تشفيري كان مهمًّا قبل عام قد يصبح ضجيجًا خلفيًّا الآن بينما ظلّت ثلاثة أنماط جديدة دون وسم.
لا شيء من هذا غريب بمجرّد أن تكفّ عن توقّع أن تناولك السلسلة الإجابات. إنها تناولك سجلًّا عامًّا كاملًا بلا أي وسم. والهندسة تكمن في الوسم، والتسوية رجوعًا إلى عملائك، والالتزامات التي تدمجها كي يكون كل تنبيه يراه إنسان مرتبطًا مسبقًا بقرار مؤهَّل لاتخاذه.
الأسئلة الشائعة
هل نحتاج إلى مورّد تجاري لتحليلات السلسلة (chain-analytics vendor)، أم يمكننا بناء عملية الإسناد (attribution) داخليًا؟
معظم الفرق تشتري خدمة الإسناد وتبني حولها البنية التشغيلية. يستثمر المورّدون بكثافة في وسم عناوين المنصّات والخلّاطات (mixers) والعناوين الخاضعة للعقوبات، وهو أمر مكلف جدًّا لإعادة إنتاجه. ما ينبغي أن تملكه أنت هو الربط بين وسومهم وسجلّات عملائك، إضافةً إلى منطق التنبيهات المبني فوق ذلك.
كيف تعمل قاعدة السفر (Travel Rule) حين يكون الطرف المقابل محفظة ذاتية الاستضافة (self-hosted wallet)؟
لا توجد مؤسسة مستقبِلة لتبادُل بيانات المُنشئ والمستفيد معها، لذا ينتقل الالتزام إلى إثبات ملكية المحفظة والعناية الواجبة المعزّزة. بموجب لائحة الاتحاد الأوروبي لتحويل الأموال (اللائحة (EU) 2023/1113)، فإن التحويلات من محفظة ذاتية الاستضافة أو إليها بما يتجاوز 1000 يورو تُفعّل التحقّق من الهوية والملكية، ولهذا يجب أن يكون إسناد المحفظة حقلًا من الدرجة الأولى في نظام مراقبتك.
لماذا تتصرّف تدفقات العملات المستقرّة بشكل مختلف عن تدفقات الأصول الأصلية (native assets) في المراقبة؟
تنتقل العملات المستقرّة كتحويلات لعقود الرموز (token-contract transfers) لا كقيمة أصلية، لذا يهمّ فكّ ترميز سجلّات الأحداث (event logs) بشكل صحيح، كما يمكن للجهات المُصدِرة تجميد العناوين أو إدراجها في القائمة السوداء. فتجميد طرف مقابل أو إدراجه في القائمة السوداء إشارة ينبغي أن يستوعبها نظام مراقبتك، والاسترداد إلى العملة الورقية (fiat) حدث سحب منفصل (off-ramp) عليك تسويته مقابل السجلّ البنكي لعميلك.