KYC کے متضاد اصول
Know Your Customer (KYC) قوانین فن ٹیک فرمز کے لیے ایک حقیقی کشمکش پیدا کرتے ہیں۔ ریگولیٹرز مکمل شناختی جانچ چاہتے ہیں۔ وہ فرمز کو ذاتی دستاویزات جمع کرنے اور تصدیق کرنے کا تقاضا کرتے ہیں۔ لیکن ڈیٹا قوانین مخالف سمت دھکیلتے ہیں۔ وہ فرمز کو اس ڈیٹا کو جمع ہونے کے بعد کم از کم کرنے کا تقاضا کرتے ہیں۔
ایک نیا اکاؤنٹ کھولنے والا بینک بہت سی دستاویزات جمع کرتا ہے۔ ان میں قومی شناختی کارڈ، پاسپورٹ، اور ڈرائیونگ لائسنس شامل ہیں۔ یہ پتے کی تصدیق اور مالیاتی کاغذات بھی جمع کرتا ہے۔ ان فائلوں میں گھنا ذاتی ڈیٹا ہوتا ہے۔ GDPR، AML اصول، اور بینکنگ نگران سب سخت ہینڈلنگ کا تقاضا کرتے ہیں۔
جب وہ ڈیٹا دھوکہ دہی کے نظاموں یا تجزیات تک جاتا ہے، اضافی اصول لاگو ہوتے ہیں۔ GDPR کے ڈیٹا اصول کام میں آ جاتے ہیں۔ کسی بھی دوسرے استعمال سے پہلے ذاتی ڈیٹا کو mask یا de-identified کرنا ضروری ہے۔
2 دن کے بیک لاگ کا مسئلہ
ایک ڈیجیٹل بینک نے 15 EU ممالک میں روزانہ 5,000 KYC درخواستیں پروسیس کیں۔ ان کے PII اسکین مرحلے نے ایک سنگین مسئلہ پیدا کیا۔ غلط مثبت کی شرح بہت زیادہ تھی۔ جائزہ قطاریں بڑھتی رہیں یہاں تک کہ 2 دن کا بیک لاگ ہو گیا۔
بنیادی وجہ واضح تھی۔ ان کا ML پر مبنی ٹول تقریباً 8% غیر PII متن کو ذاتی ڈیٹا کے طور پر نشان زد کرتا تھا۔ ہر فائل میں بہت سے صفحات تھے۔ روزانہ غلط مثبت کا حجم ٹیم کے لیے ایک دن میں صاف کرنا بہت زیادہ تھا۔ وہ پیچھے پڑتے رہے۔
غلط مثبت تین گروپوں میں آئے:
- کمپنی کے نام جو شخص کے نام کے طور پر نشان زد ہوئے (ماڈل نے proper nouns کو الجھا دیا)
- حوالہ کوڈ جو ID نمبروں کے طور پر نشان زد ہوئے (کوئی checksum جانچ استعمال نہیں ہوئی)
- بینک ناموں میں "Chase" جیسے عام پہلے نام جو شخص کے نام کی PII کے طور پر نشان زد ہوئے
ہر غلط مثبت کو انسانی جائزے کی ضرورت تھی۔ 5,000 روزانہ فائلوں میں 8% پر، اس نے ہزاروں روزانہ کام پیدا کیے۔ ان میں سے کوئی بھی خودکار طور پر ختم نہیں کیا جا سکتا تھا۔
ACL تحقیق کیا ظاہر کرتی ہے
ACL 2024 کی تحقیق نے PII ڈیٹیکشن کے لیے کثیر زبانی NLP ماڈلز کی جانچ کی۔ نتیجہ واضح تھا۔ تمام 24 EU زبانوں میں غیر انگریزی PII کے لیے 85% سے بہتر F1-اسکور صرف 5% کثیر زبانی NLP ماڈلز حاصل کرتے ہیں۔
F1-اسکور precision اور recall کو یکجا کرتا ہے۔ کم precision کا مطلب بہت سے غلط مثبت ہے۔ کم recall کا مطلب بہت سے چھوٹ جانے والے آئٹمز ہیں۔ دونوں نتائج خراب اسکور کرتے ہیں۔ 85% F1 تک پہنچنے میں 95% ناکامی کی شرح ظاہر کرتی ہے کہ عملاً کثیر زبانی PII اسکیننگ کتنی مشکل ہے۔
اس کے برعکس، XLM-RoBERTa PII کاموں کے لیے 91.4% cross-lingual F1 حاصل کرتا ہے۔ یہ اعداد و شمار HuggingFace 2024 benchmarking سے ہیں۔ 91.4% اور median ماڈل کے درمیان خلاء وضاحت کرتا ہے کہ off-the-shelf ٹولز کثیر زبانی KYC میں کیوں ناکام ہوتے ہیں۔
ہائی-ولیوم KYC کے لیے ہائبرڈ ڈیزائن
غلط مثبت کا مسئلہ قابل حل ہے۔ تین ڈیزائن انتخاب اسے درست کرتے ہیں۔
Checksum جانچ کے ساتھ Regex: قومی ID نمبروں کے مقررہ اصول ہیں۔ جرمن Steuer-ID، ڈچ BSN، اور پولش PESEL ہر ایک checksum ریاضی استعمال کرتے ہیں۔ اگر کوئی نمبر checksum میں ناکام ہو، تو یہ قومی ID نہیں ہے۔ فارمیٹ اور checksum مل کر ان IDs کے لیے قریب صفر غلط مثبت پیدا کرتے ہیں۔
ناموں کے لیے context-aware NLP: KYC فائلوں میں شخص کے نام معلوم جگہوں پر آتے ہیں۔ ان میں "Name:"، "Surname:"، اور مقررہ فارم فیلڈز شامل ہیں۔ نام نشان زد کرنے سے پہلے سیاق و سباق کا لفظ درکار کرنا غلط مثبت کم کرتا ہے۔ یہ فرم کے ناموں کو شخص کے نام کے الرٹ ٹرگر کرنے سے روکتا ہے۔
فائل کی قسم کے لحاظ سے threshold tuning: KYC فائلیں سپورٹ ای میل یا طبی نوٹوں سے مختلف ہیں۔ ہر قسم کا ایک مختلف PII مکس ہے۔ فائل کی قسم کے لحاظ سے thresholds ترتیب دینا ٹیموں کو اپنی ضروریات کے لیے tune کرنے دیتا ہے۔ ہائی-ولیوم KYC کو زیادہ precision ملتی ہے۔ طبی de-identification کو زیادہ recall ملتی ہے۔
2 دن کا بیک لاگ PII اسکیننگ کی ناگزیر لاگت نہیں ہے۔ یہ ایک مخصوص workflow پر عام ٹولز استعمال کرنے کی لاگت ہے۔ حل سیٹ اپ میں ہے، بڑی ٹیم میں نہیں۔
ہماری GDPR تعمیل گائیڈ ڈیٹا کم از کم کرنے کے قوانین کا احاطہ کرتی ہے۔ ہمارا سیکیورٹی اور تعمیل کا جائزہ ان تکنیکی کنٹرولز کی وضاحت کرتا ہے جو تعمیل شدہ KYC workflows کی حمایت کرتے ہیں۔