نالج گراف کے ساتھ مالی فراڈ کے نمونوں کا پتہ لگانے کا طریقہ: ایک پروڈکشن گائیڈ

انٹرپرائز ادائیگی کے ورک فلو میں زیادہ تر فراڈ سے بچاؤ کے فن تعمیرات انفرادی طور پر لین دین کا جائزہ لیتے ہیں۔

جب کوئی رسید آتا ہے، تو ایک خودکار قواعد کا انجن اسے جامد حدوں کے خلاف چیک کرتا ہے۔ تصدیق کریں کہ ڈالر کی رقم معمول کی حد کے اندر ہے، وینڈر منظور شدہ وینڈر لسٹ میں ہے، اور آپ جو IP ایڈریس جمع کراتے ہیں وہ واقف نظر آتا ہے۔ اگر انفرادی اوصاف قابل فہم نظر آتے ہیں تو ادائیگی منسوخ ہو جاتی ہے۔

اس نقطہ نظر کے ساتھ مسئلہ ساختی ہے۔ فراڈ کی نفیس اسکیمیں جیسے منی موول رِنگز، سرکلر انوائسنگ لوپس، اور سپلائر کے تنازعات شاذ و نادر ہی ایسے لین دین پیدا کرتے ہیں جو انفرادی حدوں کو خبردار کرتے ہیں۔ ایک شیل کمپنی جو $5,000 ڈبل اجازت کی حد کے نیچے رہنے کے لیے $4,800 کی رسیدیں جاری کرتی ہے جب اسے تنہائی میں دیکھا جائے تو بالکل ٹھیک نظر آتا ہے۔ لیکن جب 25 بظاہر آزاد سپلائرز ایک ہی بینک اکاؤنٹ میں تمام روٹ ادائیگی کرتے ہیں، تو مربوط پیٹرن واضح ہونے لگتے ہیں۔

آپ کو الگ تھلگ لین دین کی خصوصیات میں کوئی انتباہ نہیں ملے گا۔ یہ ادائیگی کے نیٹ ورک کی ٹوپولوجی میں موجود ہے۔

ایک متعلقہ ڈیٹا بیس میں ان کثیر ہستی کے تعلقات کو ٹریک کرنے کے لیے وینڈر، انوائس، ادائیگی، اور بینک اکاؤنٹ ٹیبلز میں ریکسریو سیل جوائن کی ضرورت ہوتی ہے۔ تاہم، جیسے جیسے میزیں لاکھوں قطاروں تک بڑھتی ہیں، گہرے راستے کی تلاش کی وجہ سے استفسار کی کارکردگی تیزی سے کم ہوتی جاتی ہے۔ گراف ڈیٹابیس رشتوں کو فرسٹ کلاس انڈیکس لیس کنٹیگوئس پوائنٹرز کے طور پر اسٹور کرکے اور ملٹی ہاپ ٹراورسلز کو مستقل وقتی تلاش میں تبدیل کرکے اس مسئلے کو حل کرتے ہیں۔

اس ٹیوٹوریل میں، ہم Neo4j پر بنی اینڈ ٹو اینڈ ریلیشنل فراڈ ڈیٹیکشن پائپ لائن کے فن تعمیر کو دیکھیں گے۔ ہم دیکھیں گے کہ مالیاتی اداروں کو گرافس کے طور پر کیسے ماڈل بنایا جائے، استفسار کے لیٹینسی کو بہتر بنانے کے لیے پہلے سے اخذ کردہ کناروں کو کیسے بنایا جائے، اور پانچ اہم پروکیورمنٹ فراڈ اسکیموں کا پردہ فاش کرنے کے لیے پیرامیٹرائزڈ سائفر سوالات لکھیں۔

فراڈ ڈٹیکشن- نالج گرافس ریپوزٹری میں مکمل حوالہ کا نفاذ پایا جا سکتا ہے۔

ہم کیا احاطہ کریں گے:

کیوں ٹیبلر رولز رشتہ سے متعلق فراڈ سے محروم ہیں۔

اکاؤنٹس قابل ادائیگی پائپ لائن میں، خطرے کی جانچ عام طور پر الگ تھلگ ریکارڈ پر کی جاتی ہے۔

# Transaction-level view — nothing suspicious
transactions = [
    {"vendor": "Alpha Corp", "amount": 5200.00, "date": "2025-08-01"},
    {"vendor": "Beta LLC", "amount": 4800.00, "date": "2025-08-02"},
    {"vendor": "Gamma Inc", "amount": 5100.00, "date": "2025-08-03"},
]
# All amounts within normal range ($1K–$15K). All vendors valid.
# Dates are sequential. Nothing triggers any rule.

جب آپ انہی ریکارڈوں کو ایک دوسرے سے منسلک گراف میں نقشہ بناتے ہیں، تو پوشیدہ ڈھانچہ فوری طور پر واضح ہو جاتا ہے۔

# Graph view — all three vendors pay to the same account
connections = {
    "ACC-MULE-001": ["Alpha Corp", "Beta LLC", "Gamma Inc"],
    "ACC-0042":     ["Delta Corp", "Epsilon LLC"],
    "ACC-0099":     ["Zeta GmbH"],
}
# ACC-MULE-001 receives from 25+ vendors. That's a money mule ring.
# The convergence is the red flag.

بنیادی ڈیٹا تبدیل نہیں ہوا ہے۔ تاہم، ہستی گراف کے اندر لین دین کا جائزہ لیتے وقت، مربوط فنل نمایاں ہو جاتے ہیں۔

ان نقطوں کو متعلقہ ڈیٹا بیس میں جوڑنے کے لیے الگ الگ ٹیبلز میں متعدد جوائنز کی ضرورت ہوتی ہے۔ علمی گراف میں، کنکشنز کو براہ راست کناروں کو جوڑنے والے نوڈس کے طور پر محفوظ کیا جاتا ہے، اس لیے ان سے ایک ہی ٹراورسل میں استفسار کیا جا سکتا ہے۔

پیٹرن	یہ کیا ہے	جو موجودہ ٹولز کیپچر نہیں کرتے
ڈپلیکیٹ رسید	ایک ہی انوائس اور وینڈر، تقریباً ایک ہی رقم، مقررہ تاریخ۔	ایک عین مطابق میچ میں کچھ اختلافات چھوٹ جائیں گے۔
سرکلر انگوٹی	سپلائرز ایک دوسرے کو بند لوپ میں رسید کرتے ہیں۔	ہر رسید اپنے طور پر جائز معلوم ہوتی ہے۔
پیسے خچر کی انگوٹی	بہت سے سپلائرز ایک کنٹرول اکاؤنٹ میں آتے ہیں۔	واحد ادائیگی میں کوئی حرج نہیں ہے۔
سپلائر کی ملی بھگت	بنیادی خصوصیات کا اشتراک کرنے والے آزاد دکاندار	اداروں میں کسی کلسٹرز کا پتہ نہیں چلا۔
ادائیگی یا اس سے زیادہ	محکمہ کی طرف سے مجاز نہ ہونے والے افراد کے ذریعے منظور شدہ رسیدیں	کردار پر مبنی چیک پاس اور سیاق و سباق کے چیک موجود نہیں ہیں۔

علم کے گراف قواعد کے انجن یا ایم ایل ماڈلز کی جگہ نہیں لیتے ہیں۔ لیکن یہ اس خلا کو ختم کرتا ہے جس تک وہ نہیں پہنچ سکتے: تعلقات۔

شرطیں

اس ٹیوٹوریل کے ساتھ آگے بڑھنے کے لیے، آپ کو ضرورت ہو گی:

آپ کے کمپیوٹر پر Python 3.10 یا اس سے زیادہ انسٹال ہے۔
مقامی Neo4j مثال کو چلانے کے لیے Docker اور Docker Compose انسٹال کیا۔
ازگر اور ڈیٹا بیس کے تصورات کا بنیادی علم۔

مالیاتی گراف اور جمع کرنے کے اسکیموں کا ماڈل کیسے بنایا جائے۔

دھوکہ دہی کے سوالات پر عمل کرنے سے پہلے، آپ کو اپنے ڈیٹا کو مربوط وصف کے گراف میں ترتیب دینے کی ضرورت ہے۔ حوالہ ڈیٹاسیٹ چھ ہستیوں کی اقسام کو عام طور پر مالیاتی نظاموں میں پایا جاتا ہے۔

حقیقت	اہم خصوصیات	کردار
فراہم کنندہ	ٹیکس ID، نام، ملک، شہر	انوائس جاری کرنے والا شخص
رسید	انوائس_ID، رقم، تاریخ، زمرہ	وصول کی گئی رقم
ادائیگی	ادائیگی_ID، رقم، تاریخ	کے لئے ادا کیا
بینک اکاؤنٹ	اکاؤنٹ_آئی ڈی، روٹنگ_نمبر، بینک کا نام	پیسہ کہاں گیا
ملازم	ملازم کی شناخت، نام، محکمہ	جس نے منظوری دی
گروپ	org_id، نام، شعبہ	ساختی درجہ بندی

بنیادی تعلق دو حصوں کی ادائیگی کا نیٹ ورک بناتا ہے۔

(Employee)-[:APPROVED]->(Payment)-[:LINKED_TO]->(Invoice)-[:ISSUED_BY]->(Vendor)
                                   |
                                   v
                            (Payment)-[:PAID_TO]->(BankAccount)

مرحلہ 1: معلوم انجیکشن پیٹرن کے ساتھ ڈیٹا سیٹ کیسے بنائیں

پرائیویسی اور ریگولیٹری پابندیوں کی وجہ سے حقیقی دنیا کے مالیاتی ڈیٹاسیٹس تک رسائی مشکل ہے۔ مصنوعی ڈیٹا کا استعمال کرتے ہوئے، آپ فراڈ کے معروف نمونوں کو انجیکشن کر سکتے ہیں اور منظم طریقے سے چیک کر سکتے ہیں کہ آیا پتہ لگانے کے سوالات ان نمونوں کو تلاش کرتے ہیں۔

ڈیٹاسیٹ جنریٹر تقریباً 500 اداروں کو پانچ معلوم نمونوں کے ساتھ تیار کرتا ہے۔

12 ڈپلیکیٹ انوائس کے جوڑے
1 گول رسید کی انگوٹی (3 سپلائرز)
1 منی خچر کی انگوٹھی (25 تاجر فی اکاؤنٹ)
1 وینڈر کولیشن کلسٹر (4 وینڈرز)
3 یا اس سے زیادہ ادائیگی

from dataset.generate import FraudDatasetGenerator

gen = FraudDatasetGenerator(
    num_vendors=100,
    num_employees=30,
    num_organizations=5,
    seed=42,
)
output_dir = gen.save("dataset/output")

مقررہ ترتیبات seed=42 اپنے ڈیٹاسیٹ کو مکمل طور پر دوبارہ پیدا کرنے کے قابل بنائیں۔ جنریٹر چلانے سے ہر بار بالکل وہی دھوکہ دہی کا نمونہ پیدا ہوتا ہے جو جانچ کے سوالات کے لیے ایک قابل اعتماد معیار فراہم کرتا ہے۔

Vendors: 100
Invoices: 220 (200 base + 20 fraud)
Payments: 331 (300 base + 31 fraud)
Bank Accounts: 51 (50 + 1 mule)
Employees: 30
Organizations: 5
Fraud Patterns: 5 types

جنریٹر زمینی سچائی کا اظہار بھی کرتا ہے۔ ground_truth.json یہ تمام انجکشن شدہ بے ضابطگیوں کو لاگ کرتا ہے اور خودکار تصدیقی اوریکل کے طور پر کام کرتا ہے۔

مرحلہ 2: Neo4j سے کیسے جڑیں اور رکاوٹیں بنائیں

آپ APOC طریقہ کار کو فعال کر کے مقامی Neo4j 5.20 کنٹینر کو گھمانے کے لیے Docker Compose استعمال کر سکتے ہیں۔

docker compose up -d

اگلا، ہم ڈیٹا بیس ڈرائیور کو شروع کرتے ہیں اور انفرادیت کی پابندیاں قائم کرتے ہیں۔

from graph.connection import FraudGraph

with FraudGraph() as graph:
    graph.create_constraints()

یہ رکاوٹیں استفسار کی کارکردگی کے لیے اہم ہیں۔ Neo4j میں، منفرد وصف کی رکاوٹیں خود بخود بنیادی B-tree انڈیکس بناتی ہیں۔ اس کے بغیر، کوئی بھی MERGE آپریشن ڈیٹا بیس میں تمام نوڈس پر مکمل، غیر اشاریہ شدہ اسکین پر مجبور کرتا ہے۔

class FraudGraph:
    def __init__(self, uri=None, user=None, password=None):
        self.uri = uri or os.environ.get('NEO4J_URI', 'bolt://localhost:7687')
        self.user = user or os.environ.get('NEO4J_USER', 'neo4j')
        self.password = password or os.environ.get('NEO4J_PASSWORD', 'password')
        self.driver = None

    def connect(self):
        self.driver = GraphDatabase.driver(
            self.uri, auth=(self.user, self.password),
            max_connection_pool_size=50,
            connection_acquisition_timeout=30,
        )
        with self.driver.session() as session:
            session.run('RETURN 1')
        return self

    def __enter__(self):
        self.connect()
        return self

    def __exit__(self, exc_type, exc_val, exc_tb):
        self.close()

    def create_constraints(self):
        with self.driver.session() as session:
            session.run("CREATE CONSTRAINT vendor_tax_id IF NOT EXISTS FOR (v:Vendor) REQUIRE v.tax_id IS UNIQUE")
            session.run("CREATE CONSTRAINT invoice_id IF NOT EXISTS FOR (i:Invoice) REQUIRE i.invoice_id IS UNIQUE")
            session.run("CREATE CONSTRAINT account_id IF NOT EXISTS FOR (a:BankAccount) REQUIRE a.account_id IS UNIQUE")
            session.run("CREATE CONSTRAINT employee_id IF NOT EXISTS FOR (e:Employee) REQUIRE e.employee_id IS UNIQUE")

مرحلہ 3: گراف میں اشیاء کو کیسے لوڈ کریں۔

کہ FraudGraphLoader سائفر استعمال کریں۔ UNWIND پیرامیٹرائزڈ ٹرانزیکشن میں بڑی تعداد میں اداروں کو داخل کرنے کے لیے:

from graph.loader import FraudGraphLoader

with FraudGraph() as graph:
    graph.create_constraints()
    loader = FraudGraphLoader(graph)
    loader.load_all(data)

لوڈ آرڈر غیر ملکی کلیدی انحصار کا احترام کرتا ہے۔ تنظیمیں پہلے لوڈ کرتی ہیں، پھر سپلائرز، بینک اکاؤنٹس اور ملازمین، اور رسیدیں اور ادائیگیاں آخری۔

ہر بوجھ کا طریقہ ایک ہی پیٹرن کی پیروی کرتا ہے۔

UNWIND $data AS v
MERGE (vendor:Vendor {tax_id: v.tax_id})
SET vendor.name = v.name,
    vendor.country = v.country,
    vendor.city = v.city
WITH vendor, v
MATCH (org:Organization {org_id: v.organization})
MERGE (vendor)-[:BELONGS_TO]->(org)

MERGE نوڈ بنائیں یا میچ کریں (O(1) تلاش کے لیے رکاوٹوں کا استعمال کرتے ہوئے)۔ SET خصوصیات منسلک کریں اور MERGE تعلقات میں نوڈس کو جوڑیں۔

مرحلہ 4: فاسٹ استفسار کے لیے اخذ کردہ تعلقات کو کیسے مادی بنایا جائے۔

گراف ڈیٹا بیس میں ایک اہم آرکیٹیکچرل فیصلہ یہ ہے کہ آیا استفسار کے وقت تعلقات کی گنتی کی جائے یا جمع کرنے کے دوران ان کو عملی شکل دی جائے۔

یہ تعین کرنے کے لیے کہ آیا دو دکاندار ایک بینک اکاؤنٹ کا اشتراک کرتے ہیں، آپ کو 4-ہاپ راستے سے گزرنا ہوگا۔

(Vendor)<-[:ISSUED_BY]-(Invoice)<-[:LINKED_TO]-(Payment)-[:PAID_TO]->(BankAccount)<-[:PAID_TO]-(Payment)-[:LINKED_TO]->(Invoice)-[:ISSUED_BY]->(Vendor)

ہر ریئل ٹائم فراڈ استفسار کے دوران اس 4-ہاپ پاتھ کا جائزہ لینے سے اہم کمپیوٹیشنل اوور ہیڈ ہوتا ہے۔ اس کے بجائے، آپ اخذ کردہ کناروں کو بہتر کر سکتے ہیں کیونکہ ڈیٹا سسٹم میں داخل ہوتا ہے۔ یہ بیچ پروسیسنگ کے دوران لکھنے میں کچھ تاخیر کا اضافہ کرتا ہے، لیکن رن ٹائم تلاش کے سوالات کے دوران ملٹی ہاپ ٹراورسلز کو براہ راست سنگل ہاپ تلاش میں تبدیل کرتا ہے۔

پہلا اخذ کردہ رشتہ یہ ہے: SHARED_ACCOUNT_WITH؛ آپ کے ٹارگٹ بینک اکاؤنٹ کو شیئر کرنے والے سپلائرز سے رابطہ کریں۔

MATCH (v1:Vendor)<-[:ISSUED_BY]-(i1:Invoice)<-[:LINKED_TO]-(p1:Payment)-[:PAID_TO]->(a:BankAccount)
MATCH (v2:Vendor)<-[:ISSUED_BY]-(i2:Invoice)<-[:LINKED_TO]-(p2:Payment)-[:PAID_TO]->(a)
WHERE id(v1) < id(v2)
MERGE (v1)-[:SHARED_ACCOUNT_WITH]->(v2)

فلٹر WHERE id(v1) < id(v2) تعلقات کو اندرونی نوڈ IDs کے درمیان واحد سمت کناروں کے طور پر ذخیرہ کیا جاتا ہے، نقلی ریورس کناروں کو روکتا ہے۔

یہ مشترکہ جغرافیائی مقامات اور بینک روٹنگ کے سابقوں کو بہتر بنا کر ڈھیلے ملی بھگت والے نیٹ ورکس کا بھی پتہ لگا سکتا ہے۔

-- Same city and country
MATCH (v1:Vendor), (v2:Vendor)
WHERE id(v1) < id(v2)
  AND v1.city = v2.city
  AND v1.country = v2.country
MERGE (v1)-[:SHARED_LOCATION]->(v2)

-- Bank accounts with same routing prefix (first 3 digits)
MATCH (v1:Vendor)<-[:ISSUED_BY]-(i1:Invoice)<-[:LINKED_TO]-(p1:Payment)-[:PAID_TO]->(a1:BankAccount)
MATCH (v2:Vendor)<-[:ISSUED_BY]-(i2:Invoice)<-[:LINKED_TO]-(p2:Payment)-[:PAID_TO]->(a2:BankAccount)
WHERE id(v1) < id(v2)
  AND a1.account_id <> a2.account_id
  AND substring(a1.routing_number, 0, 3) = substring(a2.routing_number, 0, 3)
MERGE (v1)-[:SHARED_ROUTING_PREFIX]->(v2)

ایک بار جمع کرنے کے مکمل ہونے کے بعد، آپ گراف ٹوپولوجی کا معائنہ کر سکتے ہیں تاکہ یہ یقینی بنایا جا سکے کہ بنیاد اور اخذ کردہ تعلقات دونوں درست طریقے سے لوڈ کیے گئے ہیں۔

info = graph.get_info()
for label, count in sorted(info['nodes'].items(), key=lambda x: -x[1]):
    print(f"  {label}: {count} nodes")
for rel, count in sorted(info['relationships'].items(), key=lambda x: -x[1]):
    print(f"  {rel}: {count} relationships")

آؤٹ پٹ خام اداروں اور نتیجے میں اخذ کردہ تعلقات کو ظاہر کرتا ہے۔

  Invoice: 220 nodes
  Payment: 331 nodes
  Vendor: 100 nodes
  BankAccount: 51 nodes
  Employee: 30 nodes

  SHARED_ACCOUNT_WITH: 412 relationships
  SHARED_LOCATION: 387 relationships
  LINKED_TO: 331 relationships
  PAID_TO: 331 relationships
  ISSUED_BY: 220 relationships
  APPROVED: 331 relationships
  SHARED_ROUTING_PREFIX: 52 relationships

یہ اخذ کرنے والے تعلقات خاص طور پر تیز رفتار سینسنگ کے لیے بنائے گئے ہیں۔ رشتہ دار ڈیٹا بیس میں مشترکہ اکاؤنٹس کی تلاش کے لیے متعدد ٹیبلز میں خود شمولیت کی ضرورت ہوتی ہے۔ گرافس میں، یہ پہلے سے گنتی والے کنارے بن جاتے ہیں، پیچیدہ ٹراورسلز کو براہ راست تلاش میں بدل دیتے ہیں۔

پاس ورڈ کے سوالات کے ساتھ 5 فراڈ پیٹرنز کا پتہ لگانے کا طریقہ

اسکیما اور اخذ کردہ تعلقات قائم ہونے کے بعد، ہم پیرامیٹرائزڈ سائفر استفسارات بنا سکتے ہیں جو پانچ مروجہ پروکیورمنٹ فراڈ پیٹرن کو ظاہر کرتے ہیں۔

پیٹرن 1: ڈپلیکیٹ رسیدیں کیسے تلاش کریں۔

دھوکہ دہی کرنے والے اکثر دن یا ہفتوں کے علاوہ ڈپلیکیٹ رسیدیں جمع کراتے ہیں، یہ فرض کرتے ہوئے کہ آپ کے اکاؤنٹس کی قابل ادائیگی ٹیم ان کو معمول کے، بار بار چلنے والے اخراجات کے طور پر دیکھے گی۔

قواعد پر مبنی انجن اکثر عین مطابق مماثلت پاتے ہیں، لیکن تھوڑی سی بدلی ہوئی تاریخوں کی وجہ سے رسیدیں چھوٹ سکتی ہیں۔ گراف آپ کو رولنگ ڈیٹ ونڈو کے اندر ایک ہی سپلائر کی طرف سے جاری کردہ تمام رسیدوں سے استفسار کرنے کی اجازت دیتا ہے۔

// graph/queries.py — detect_duplicates()
MATCH (v:Vendor)<-[:ISSUED_BY]-(i1:Invoice),
      (v)<-[:ISSUED_BY]-(i2:Invoice)
WHERE i1.invoice_id < i2.invoice_id
  AND i1.amount = i2.amount
  AND i1.date < i2.date
  AND duration.between(date(i1.date), date(i2.date)).days <= $max_days
RETURN i1.invoice_id AS invoice_a,
       i2.invoice_id AS invoice_b,
       v.name AS vendor,
       i1.amount AS amount,
       i1.date AS date_a,
       i2.date AS date_b,
       duration.between(date(i1.date), date(i2.date)).days AS days_apart
ORDER BY days_apart

یہاں اہم نکات:

حالت i1.invoice_id < i2.invoice_id یہ ایک ہی جوڑی کو دو بار واپس کرنے سے روکتا ہے: (A, B) اور (B, A).
i1.amount = i2.amount یہ ایک دھوکہ دہی کا اشارہ ہے۔ اگر رقم ایک جیسی ہے تو، ایک ہی رسید دو بار جمع کرائی جائے گی۔
اسی سپلائر کی طرف سے جاری کردہ انوائسز کی تلاش کو اسکوپ کرتے ہوئے، استفسار پہلے سے طے شدہ وقتی duration.between() فنکشن کا استعمال کرتے ہوئے تاریخ کے وقفے کا جائزہ لینے سے پہلے سپلائر کے لیے انڈیکس تلاش کرتا ہے۔

آپ اس استفسار کو ازگر کے ریپر کے ذریعے چلا سکتے ہیں۔

from graph.queries import FraudQueries

queries = FraudQueries(graph)
duplicates = queries.detect_duplicates(max_days_apart=14)
print(f"Found {len(duplicates)} duplicate invoice pairs")
for dup in duplicates[:5]:
    print(f"  {dup['invoice_a']} ↔ {dup['invoice_b']} | "
          f"{dup['vendor']} | ${dup['amount']} | "
          f"{dup['days_apart']} days apart")

استفسار مصنوعی ڈیٹاسیٹ میں ڈالے گئے تمام 12 ڈپلیکیٹ جوڑوں کا پتہ لگاتا ہے، 100% یاد کو حاصل کرتا ہے۔

پیٹرن 2: سرکلر انوائس کی انگوٹھی کیسے تلاش کی جائے۔

ایک سرکلر انوائسنگ سسٹم میں، تین یا زیادہ سپلائرز ایک دوسرے کو بند لوپ میں بل دیتے ہیں۔ ہر لین دین اپنے آپ میں جائز معلوم ہوتا ہے، لیکن کوئی حقیقی سامان یا خدمات فراہم نہیں کی جاتی ہیں۔

کیونکہ آپ نے پہلے سے حساب لگا لیا تھا۔ SHARED_ACCOUNT_WITHسائیکل کا پتہ لگانے کو وینڈر سب گراف میں تین نوڈ مثلث تلاش کرنے کے لیے آسان بنایا گیا ہے۔

// graph/queries.py — detect_circular_schemes()
MATCH path = (v1:Vendor)-[:SHARED_ACCOUNT_WITH]-(v2:Vendor)
              -[:SHARED_ACCOUNT_WITH]-(v3:Vendor)
              -[:SHARED_ACCOUNT_WITH]-(v1)
WHERE id(v1) < id(v2) AND id(v2) < id(v3)
RETURN path,
       [n IN nodes(path) | {name: n.name, tax_id: n.tax_id}] AS vendors,
       length(path) AS hops

یہاں اہم نکات:

فارماسیوٹیکل id(v1) < id(v2) اور id(v2) < id(v3) سرکلر تبدیلیوں کو ختم کرتا ہے۔ اس کے بغیر، ایک واحد 3 نوڈ کی انگوٹی. (A, B, C) یہ تین الگ الگ بار لوٹتا ہے۔
اگر آپ اس استفسار کو براہ راست خام 4-ہاپ ٹرانزیکشن پاتھ کے خلاف بغیر مادی کناروں کے چلاتے ہیں، تو آپ کو 3 سائیکل تلاش کرنے کے لیے 12 ہوپس کو عبور کرنا پڑے گا، جس کے نتیجے میں بڑے ڈیٹا سیٹس پر CPU کا زیادہ استعمال ہوگا۔

circles = queries.detect_circular_schemes(min_cycle_length=3)
print(f"Found {len(circles)} circular invoice rings")
for ring in circles:
    vendor_names = [v['name'] for v in ring['vendors']]
    print(f"  Ring ({ring['hops']} hops): {' ↔ '.join(vendor_names)}")

استفسار 100% یاد کے ساتھ سرکلر انوائس رِنگز کو حاصل کرتا ہے۔

پیٹرن 3: منی مول نیٹ ورک کا پتہ لگانے کا طریقہ

پیسے کے خچر کے سیٹ اپ میں، متعدد شیل ادارے فنڈز کو ایک ہی اکاؤنٹ میں بھیجتے ہیں جو ایک سنڈیکیٹ کے زیر کنٹرول ہوتا ہے۔ اگرچہ انفرادی خرچ کی رقم چھوٹی ہے، لیکن ہدف والے اکاؤنٹ کا فین ان لیول غیر معمولی طور پر زیادہ ہے۔

آپ اپنے ٹارگٹ بینک اکاؤنٹس پر ڈگری کا تجزیہ کرکے اس پیٹرن کو دریافت کرسکتے ہیں۔

// graph/queries.py — detect_money_mule_rings()
MATCH (a:BankAccount)<-[p_paid:PAID_TO]-(p:Payment)-[:LINKED_TO]->(i:Invoice)
                  -[:ISSUED_BY]->(v:Vendor)
WITH a, collect(DISTINCT v) AS vendors,
     sum(p.amount) AS total_received,
     count(DISTINCT v) AS unique_vendors,
     count(p) AS payment_count
WHERE unique_vendors >= $min_vendors
RETURN a.account_id,
       a.routing_number,
       a.bank_name,
       unique_vendors AS vendor_count,
       payment_count,
       total_received AS total_amount,
       [vendor IN vendors | vendor.name] AS vendor_names
ORDER BY unique_vendors DESC

آنے والے کنکشنز کی بنیاد پر اپنے اکاؤنٹ کا جائزہ لینے کے لیے آپ درج ذیل رسک گائیڈ استعمال کر سکتے ہیں۔

سپلائرز کی تعداد	خطرے کی سطح
1~3	عام
4~9	تحقیقات
10+	شاید پیسے کا خچر

پیداوار میں، آپ موصول ہونے والی کل رقم میں حد کا اضافہ کر کے جھوٹے مثبت کو کم کر سکتے ہیں۔

WHERE unique_vendors >= 10 AND total_received > 50000

Python میں تلاش کا استفسار چلانا:

mules = queries.detect_money_mule_rings(min_vendor_count=5)
for acct in mules:
    print(f"  {acct['a.account_id']} ({acct['a.bank_name']}) | "
          f"{acct['vendor_count']} vendors | ${acct['total_amount']:.0f}")

استفسار کامیابی کے ساتھ ایک انجکشن شدہ خچر رنگ (ACC-MULE-001) کی شناخت کرتا ہے جو 25 شیل سپلائرز کو ادائیگیوں کو جمع کرتا ہے۔

پیٹرن 4: سپلائر کی ملی بھگت کے کلسٹرز کی شناخت کیسے کریں۔

سازش کرنے والی شیل کمپنیاں اکثر مختلف کمپنیوں کے ناموں سے رجسٹر ہو کر اپنی وابستگی چھپاتی ہیں۔ تاہم، میٹا ڈیٹا، جیسے مشترکہ فزیکل آفس سویٹس یا ایک جیسے بینک برانچ روٹنگ کے سابقے، اکثر لیک ہو جاتے ہیں۔

ان کلسٹرز کی شناخت کے لیے، متعدد اخذ کردہ رشتوں کا بیک وقت جائزہ لیا جا سکتا ہے اور ایک جامع ساختی رسک سکور کا حساب لگایا جا سکتا ہے۔

// graph/queries.py — detect_vendor_collusion()
MATCH (v:Vendor)
OPTIONAL MATCH (v)-[:SHARED_ACCOUNT_WITH]->(v2)
OPTIONAL MATCH (v)-[:SHARED_LOCATION]->(v3)
OPTIONAL MATCH (v)-[:SHARED_ROUTING_PREFIX]->(v4)
WITH v,
     collect(DISTINCT v2) AS shared_account_vendors,
     collect(DISTINCT v3) AS shared_location_vendors,
     collect(DISTINCT v4) AS shared_routing_vendors
WITH v,
     size(shared_account_vendors) AS sc,
     size(shared_location_vendors) AS sl,
     size(shared_routing_vendors) AS sr
WHERE (sc + sl + sr) >= $min_score AND (sc + sl + sr) > 0
RETURN v.name AS vendor,
       v.tax_id,
       (sc + sl + sr) AS risk_score,
       [n IN shared_account_vendors + shared_location_vendors + shared_routing_vendors | n.name] AS related_vendors,
       [x IN range(1, sc) | 'shared_account'] +
       [x IN range(1, sl) | 'shared_location'] +
       [x IN range(1, sr) | 'shared_routing'] AS flags
ORDER BY risk_score DESC

یہاں اہم نکات:

اختیاری میچ کا استعمال یہاں ضروری ہے۔ سخت میچ مشترکہ روٹنگ اور مقامات کو ظاہر کرتا ہے، لیکن ان دکانداروں کو شامل نہیں کرتا جنہوں نے ابھی تک بینک اکاؤنٹ کا اشتراک نہیں کیا ہے۔
آپ اپنے کاروباری ماحول کی بنیاد پر اپنے رسک سکور کو ایڈجسٹ کر سکتے ہیں۔ بڑے تجارتی مراکز میں شہر کا اشتراک عام ہے، لیکن ایک ہی وقت میں روٹنگ کے سابقے اور آفس سویٹس کا اشتراک مجموعی اسکور کو تحقیق کی حد سے آگے بڑھاتا ہے۔

collusion = queries.detect_vendor_collusion(min_risk_score=2)
for vendor in collusion[:10]:
    print(f"  {vendor['vendor']} | Risk: {vendor['risk_score']} | "
          f"Flags: {vendor['flags']}")

ملٹی ایٹریبیوٹ اسکورنگ استفسار نے چار وینڈر کولیشن کلسٹرز کو کامیابی سے جھنڈا لگایا۔

پیٹرن 5: دائرہ اختیار سے باہر ادائیگی کی اجازت کی نشاندہی کیسے کریں۔

اندرونی فراڈ اکثر اس وقت ہوتا ہے جب ملازمین اپنے محکمے کے اختیار سے باہر رسیدیں منظور کرتے ہیں۔ مثال کے طور پر، ایک HR مینیجر بغیر منظوری کے انجینئرنگ انفراسٹرکچر وینڈر انوائس کو منظور کر سکتا ہے۔

منظوری کے نظام اکثر یہ جانچتے ہیں کہ آیا منظور کنندہ کے پاس دستخط کرنے کا اختیار ہے، لیکن شاذ و نادر ہی یہ چیک کرتے ہیں کہ آیا منظوری دینے والے کے محکمے کا انوائس کے زمرے پر دائرہ اختیار ہے یا نہیں۔ گراف کے سوالات پورے منظوری کے راستے کو تلاش کرسکتے ہیں اور محکمہ کے ذریعہ اجازتوں کا جائزہ لے سکتے ہیں۔

// graph/queries.py — detect_payment_anomalies()
MATCH (inv:Invoice)<-[:LINKED_TO]-(p:Payment),
      (e:Employee)-[:APPROVED]->(p),
      (e)-[:WORKS_FOR]->(org:Organization)
WITH inv, p, e, org,
     CASE
       WHEN inv.category = 'procurement' AND
            e.department IN ['finance', 'operations', 'procurement']
            THEN 'ok'
       WHEN inv.category = 'payroll' AND
            e.department IN ['hr', 'finance']
            THEN 'ok'
       WHEN inv.category = 'travel' AND
            e.department IN ['operations', 'finance', 'hr']
            THEN 'ok'
       WHEN inv.category = 'marketing' AND
            e.department IN ['marketing', 'finance']
            THEN 'ok'
       WHEN inv.category = 'consulting' AND
            e.department IN ['finance', 'operations', 'procurement']
            THEN 'ok'
       WHEN inv.category = 'services' AND
            e.department IN ['finance', 'operations', 'procurement']
            THEN 'ok'
       WHEN inv.category = 'supplies' AND
            e.department IN ['operations', 'procurement', 'finance']
            THEN 'ok'
       WHEN inv.category = 'maintenance' AND
            e.department IN ['operations', 'procurement', 'finance']
            THEN 'ok'
       WHEN inv.category = 'software' AND
            e.department IN ['engineering', 'operations', 'finance']
            THEN 'ok'
       ELSE 'ANOMALY'
     END AS approval_status
WHERE approval_status="ANOMALY"
RETURN inv.invoice_id, inv.amount, inv.category,
       inv.vendor_name, inv.date,
       e.name AS approver, e.employee_id,
       e.department AS approver_department
ORDER BY inv.date DESC

یہاں اہم نکات:

پہلے سے طے شدہ انکار ELSE 'ANOMALY' ڈھانچہ اس بات کو یقینی بناتا ہے کہ انوائس کے زمرے جو واضح طور پر منظور نہیں ہوئے ہیں ناکام ہو گئے ہیں بند کر دیے گئے ہیں۔
انٹرپرائز فن تعمیر میں، آپ کو اس پالیسی منطق کو براہ راست گراف میں استعمال کرتے ہوئے عملی شکل دینا چاہئے: (:Department)-[:AUTHORIZED_FOR]->(:Category) سوالات میں قدروں کو ہارڈ کوڈنگ کرنے کے بجائے، نوڈس کا استعمال کریں۔ یہ تعمیل کرنے والی ٹیموں کو اجازت دیتا ہے کہ وہ نئے کوڈ کی تعیناتی کے بغیر اجازت کے میٹرکس کو اپ ڈیٹ کر سکیں۔

anomalies = queries.detect_payment_anomalies()
print(f"Found {len(anomalies)} anomalous approvals")
for a in anomalies:
    print(f"  Invoice {a['inv.invoice_id']}: "
          f"{a['e.name']} ({a['e.department']}) approved "
          f"{a['inv.category']} | ${a['inv.amount']}")

استفسار 100% ریکال کے ساتھ داخلے کی تینوں انجیکشن کی بے ضابطگیوں کو ظاہر کرتا ہے۔

آخر سے آخر تک پائپ لائن کیسے چلائیں اور نتائج کی توثیق کریں۔

مندرجہ ذیل اقدامات کو خودکار کمانڈ لائن پائپ لائن میں ڈھال لیا جا سکتا ہے۔

python analysis/run_detections.py

اختتام سے آخر تک ڈیٹا کا بہاؤ چھ الگ الگ مراحل میں کام کرتا ہے:

Generate Dataset → Load to Neo4j → Build Derived Relationships → Run 5 Queries → Save Results → Validate

جمع کرنے اور پتہ لگانے کا طریقہ

ڈیفالٹ پائپ لائن اسکرپٹ ڈیٹا جنریشن، اسکیما کی تخلیق، ریلیشن شپ میٹریلائزیشن، اور استفسار کے عمل کو مربوط کرتی ہے۔

# analysis/run_detections.py
from dataset.generate import FraudDatasetGenerator
from graph.connection import FraudGraph
from graph.loader import FraudGraphLoader
from graph.queries import FraudQueries

def run_pipeline(output_dir="analysis/output", force_regenerate=False):
    os.makedirs(output_dir, exist_ok=True)

    # Step 1: Generate or load dataset
    dataset_path = os.path.join(output_dir, 'data')
    if not os.path.exists(os.path.join(dataset_path, 'vendors.json')) or force_regenerate:
        gen = FraudDatasetGenerator(seed=42)
        gen.save(dataset_path)
    else:
        print(f'Dataset already at: {dataset_path}')

    # Load JSON files
    data = {}
    for name in ['vendors', 'invoices', 'payments', 'bank_accounts',
                  'employees', 'organizations', 'ground_truth']:
        with open(os.path.join(dataset_path, f'{name}.json')) as f:
            data[name] = json.load(f)

    # Step 2: Load into Neo4j
    graph = FraudGraph()
    graph.connect()
    graph.create_constraints()
    loader = FraudGraphLoader(graph)
    loader.load_all(data)
    loader.create_shared_account_relationships()
    loader.create_attribute_based_relationships()

    info = graph.get_info()
    print('Graph loaded:')
    for label, count in sorted(info['nodes'].items(), key=lambda x: -x[1]):
        print(f'  {label}: {count} nodes')

    # Step 3: Run all detections
    queries = FraudQueries(graph)
    results = queries.detect_all()

    # Step 4: Save results
    with open(os.path.join(output_dir, 'detection_results.json'), 'w') as f:
        json.dump(results, f, indent=2, default=str)

    for pattern, items in results.items():
        print(f'  {pattern}: {len(items)} findings')

کہ detect_all() یہ طریقہ تمام پانچ سوالات کو انجام دیتا ہے اور ایک ہی لغت واپس کرتا ہے۔

# graph/queries.py
def detect_all(self):
    return {
        'duplicate_invoices': self.detect_duplicates(),
        'circular_schemes': self.detect_circular_schemes(),
        'money_mule_rings': self.detect_money_mule_rings(),
        'vendor_collusion': self.detect_vendor_collusion(),
        'payment_anomalies': self.detect_payment_anomalies(),
    }

انجیکشن گراؤنڈ ٹروتھ کے لیے یاد کی تصدیق کیسے کریں۔

توثیق اسکرپٹ استفسار کے نتائج کا زمینی سچائی فائلوں سے موازنہ کرکے یاد کرنے کی پیمائش کرتا ہے۔

# analysis/validate.py
from collections import defaultdict

def validate(results_path, output_path=None):
    with open(results_path) as f:
        results = json.load(f)

    with open(os.path.join(os.path.dirname(results_path), 'data',
                           'ground_truth.json')) as f:
        ground_truth = json.load(f)

    gt_by_pattern = defaultdict(list)
    for pattern in ground_truth:
        gt_by_pattern[pattern['pattern']].append(pattern)

توثیقی منطق ہر پیٹرن کی قسم کے لیے پتہ لگانے کی درستگی کا اندازہ کرتی ہے۔

for pattern_name, gt_patterns in gt_by_pattern.items():
    found = results.get(pattern_name, [])
    gt_count = len(gt_patterns)

    if pattern_name == 'duplicate_invoices':
        print(f"DUPLICATE INVOICES: DETECTED {len(found)} of {gt_count} pairs — {len(found)/max(1,gt_count):.0%} recall")

    elif pattern_name == 'money_mule_rings':
        matched = sum(1 for gt in gt_patterns
                      for r in found
                      if r.get('a.account_id') == gt['shared_account'])
        print(f"MONEY MULE RINGS: DETECTED {matched} of {gt_count} rings — {matched/max(1,gt_count):.0%} recall")

اگلا، تیار کردہ ڈیٹاسیٹ پر توثیق کنندہ کو چلائیں۔ seed=42 یہ مندرجہ ذیل نتیجہ پیدا کرتا ہے:

DUPLICATE INVOICES: DETECTED 12 of 12 pairs — 100% recall
CIRCULAR SCHEMES: DETECTED 1 of 1 rings — 100% recall
MONEY MULE RINGS: DETECTED 1 of 1 rings — 100% recall
VENDOR COLLUSION: 89 high-risk vendors flagged (multi-attribute scoring)
PAYMENT ANOMALIES: DETECTED 3 of 3 anomalies — 100% recall

پورے ورک فلو کو کیسے چلایا جائے۔

ماحول کو ترتیب دینے، پائپ لائن چلانے اور نتائج کی تصدیق کرنے کے لیے مکمل ٹرمینل کمانڈ کی ترتیب یہ ہے:

# 1. Start Neo4j
docker compose up -d

# 2. Install dependencies
pip install -r requirements.txt

# 3. Run the full pipeline
python analysis/run_detections.py

# 4. Validate results
python analysis/validate.py

# 5. (Optional) Regenerate with fresh data and re-run
python analysis/run_detections.py --regenerate

پروڈکشن آرکیٹیکچر: اپنی گراف پائپ لائن کی پیمائش کیسے کریں۔

جبکہ حوالہ پروٹو ٹائپ سینکڑوں نوڈس پر کام کرتا ہے، پروڈکشن فراڈ کا پتہ لگانے والا انجن روزانہ لاکھوں لین دین پر کارروائی کرتا ہے۔ اس فن تعمیر کو اسکیل کرنے کے لیے اہم آپریشنل رکاوٹوں کو دور کرنے کی ضرورت ہے۔

New Transaction
    ↓
Stage 1 — Deterministic queries (fast, rule-based)
    ↓  (if any pattern matches)
Stage 2 — ML scoring on graph features
    ↓
Risk Score → Alert / Approve / Escalate

دو مرحلے کا پتہ لگانے والے فن تعمیر کو کیسے نافذ کیا جائے۔

آن لائن ادائیگی کے راستے میں آنے والے تمام لین دین کے لیے عالمی سائیکل کا پتہ لگانے کے سوالات کو ہم وقت سازی سے انجام دینے سے ڈیٹا بیس کنکشن پول ختم ہو جائے گا۔

اس کے بجائے، پتہ لگانے کو دو تہوں میں تقسیم کیا جانا چاہئے۔

مرحلہ 1 (ہم وقت ساز گیٹنگ): ذیلی ملی سیکنڈ سائفر استفسارات جو معلوم نمونوں کو حاصل کرتے ہیں۔ یہ تیز ہے کیونکہ یہ اشاریہ شدہ خصوصیات، پہلے سے بنائے گئے تعلقات، اور پیٹرن کی محدود لمبائی کا استعمال کرتا ہے۔
مرحلہ 2 (اسینکرونس گراف تجزیہ): ان لین دین کے لیے جو تعییناتی اصولوں کو متحرک نہیں کرتے ہیں، گراف سے اخذ کردہ خصوصیات کو شمار کیا جاتا ہے اور اسکور کیا جاتا ہے۔

حد کو ایڈجسٹ کرنے اور غلط مثبتات کا انتظام کیسے کریں۔

پتہ لگانے کے نظام لامحالہ غلط مثبت پیدا کرتے ہیں۔ پیداوار میں، تعمیل تجزیہ کاروں کے جائزے کے تاثرات کا استعمال کرتے ہوئے استفسار کی حد کو مسلسل ایڈجسٹ کیا جانا چاہیے۔

#Tune thresholds based on false positive rate

queries.detect_money_mule_rings(min_vendor_count=10) # was 5
queries.detect_duplicates(max_days_apart=7) # was 14
queries.detect_vendor_collusion(min_risk_score=3) # was 2

آپ واپسی پر اثرات کی نگرانی کے لیے ہر تھریشولڈ اپ ڈیٹ کے بعد توثیق کو دوبارہ چلا سکتے ہیں۔

python analysis/validate.py --input analysis/output/detection_results.json

سپر نوڈ اسکیلنگ کو کیسے کم کیا جائے۔

گراف سسٹم میں ایک عام ناکامی "سپر نوڈ" کا مسئلہ ہے۔ ایک جائز مشترکہ ادارہ (جیسے ایک بڑا کارپوریٹ مالک مکان، قومی افادیت، یا اندرونی پے رول اکاؤنٹ) دسیوں ہزار آنے والے کنارے جمع کر سکتا ہے۔

اگر کوئی استفسار فلٹرنگ کے بغیر سپرنوڈ کو عبور کرنے کی کوشش کرتا ہے، تو ٹراورسل لیٹنسی تیزی سے بڑھ جاتی ہے۔

آپ اسے دو حکمت عملیوں سے کم کر سکتے ہیں:

ڈگری کی پابندیاں: ٹراورسل میں ڈگری کی کٹائی شامل کریں۔

میچ (a:بینک اکاؤنٹ)

جہاں سائز((a)<-[:PAID_TO]-()) <1000

نوڈ لیبل: معروف بڑے ادارہ جاتی اداروں کو :وائٹ لسٹڈ یا :یوٹیلیٹی لیبلز کا استعمال کرتے ہوئے ٹیگ کریں اور انہیں واضح طور پر ملی بھگت اور پیسے کے خچر اسکین سے خارج کریں۔

مشین لرننگ میں گراف فنکشنز کا استعمال کیسے کریں۔

دھوکہ دہی کا پتہ لگانے کے سب سے مؤثر نظام گرافس اور مشین لرننگ کو مسابقتی نمونوں کے طور پر نہیں مانتے ہیں۔ اس کے بجائے، گراف پیش گوئی کرنے والے ماڈلز کے لیے ایک اعلیٰ سطحی فیچر اسٹور کے طور پر کام کرتا ہے۔

ڈگری مرکزیت: ہم خچر کنورجنسی کی شناخت کے لیے اکاؤنٹس کی کنیکٹوٹی کی پیمائش کرتے ہیں۔
مرکزیت کے درمیان: ایسے اداروں کی شناخت کریں جو سپلائرز کے بظاہر منقطع گروپوں کے درمیان پل کا کام کرتے ہیں۔
پیج رینک اور کمیونٹی کا پتہ لگانا: پورے نیٹ ورک میں کلسٹر ایسوسی ایشنز اور ہستی کی اہمیت کا اندازہ لگائیں۔

ایک ML درجہ بندی جو مکمل طور پر لین دین کی رقم پر انحصار کرتا ہے اسے $4,900 کی ادائیگی کے بارے میں کوئی غیر معمولی چیز نہیں ملے گی۔ تاہم، جب گراف سے ماخوذ خصوصیات کے ساتھ جوڑ کر یہ ظاہر کرتا ہے کہ ایک وینڈر کے درمیان مرکزیت زیادہ ہے اور وہ شناخت شدہ فراڈ گروپس کے ساتھ ثانوی کنکشن رکھتا ہے، تو درجہ بندی کرنے والا بڑی درستگی کے ساتھ لین دین کو جھنڈا دیتا ہے۔

کلیدی فن تعمیر کے اسباق اور مضمرات

گراف پر مبنی فراڈ پائپ لائن کی تعمیر اور ٹیوننگ کچھ اہم فوائد اور نقصانات کو نمایاں کرتی ہے:

سب سے پہلے، متعلقہ ڈیٹا بیس میں، سکیما ڈیزائن ڈیٹا کی فالتو پن کو ختم کرنے کے لیے تیسرے نارمل فارم (3NF) کو ترجیح دیتا ہے۔ اپنا اسکیما ان ٹراورسلز کے ارد گرد ڈیزائن کریں جنہیں گراف پر انجام دینے کی ضرورت ہے۔ اگر کوئی استفسار ایک مربوط وصف تلاش کرنے کے لیے بار بار چار ہپس سے گزرتا ہے، تو ہم جمع کرنے کے دوران اس ارتباط کو براہ راست تعلق میں بدل دیتے ہیں۔

دوسرا، منفرد وصف کی رکاوٹیں صرف ڈیٹا کی سالمیت کے لیے نہیں ہیں۔ ایک بیس ہیش انڈیکس فراہم کرتا ہے جو $O(1)$ نوڈ تلاش کرتا ہے۔ رکاوٹ کو چھوڑنا تمام گراف انضمام کو مکمل، غیر اشاریہ شدہ اسکینوں میں بدل دیتا ہے۔

تیسرا، آپ کو اپنے اصولوں کی انوینٹری کو درست کرنے کی ضرورت ہے۔** ایک سیٹ کے ساتھ شروع کریں جو چار یا پانچ ہائی سگنل پیٹرن پر مرکوز ہو۔ ہر پیٹرن کے لیے تھریشولڈ کیلیبریشن اور درجہ بندی کے ورک فلو کی ضرورت ہوتی ہے۔ درجنوں غیر تصدیق شدہ ہیورسٹکس کو شامل کرنے سے تعمیل کرنے والی ٹیموں کے لیے آپریشنل شور اور الرٹ تھکاوٹ پیدا ہوتی ہے۔

آخر میں، ہم تجزیہ کار فیڈ بیک لوپ کو بند کر دیتے ہیں۔ تلاش کے استفسار کا نتیجہ ایک مفروضہ ہے، حتمی فیصلہ نہیں۔ جب تعمیل کے تجزیہ کار الرٹ کی چھان بین کرتے ہیں اور دھوکہ دہی کی تصدیق کرتے ہیں، تو وہ اس اسٹیٹس کو گراف پر واپس نوڈ پراپرٹی یا لیبل کے طور پر ریکارڈ کرتے ہیں، جیسے کہ:ConfirmedFraud۔ یہ پڑوس کی ٹوپولوجی کو مضبوط بناتا ہے اور ڈاؤن اسٹریم مشین لرننگ ماڈلز کی تربیت کے لیے واضح حقیقی معلومات فراہم کرتا ہے۔

نتیجہ

اس ٹیوٹوریل میں، آپ نے سیکھا کہ پوائنٹ ان ٹائم ریلیشنل چیکس پیچیدہ فراڈ اسکیموں سے کیوں محروم رہتے ہیں، اکاؤنٹس کے قابل ادائیگی ڈیٹا کو ایک دوسرے سے منسلک گراف کے طور پر کیسے ماڈل بنایا جائے، اور اخذ کردہ کناروں کو مادّی بنا کر ٹراورسل لیٹنسی کو کیسے تیز کیا جائے۔

ہم نے پانچ سائفر استفسارات کو بھی لاگو کیا ہے جو ڈپلیکیٹ بلنگ، سرکلر رِنگز، منی خچر، سپلائر کی ملی بھگت، اور غیر مجاز ادائیگی کی اجازتوں کا پتہ لگا سکتے ہیں۔

اس مضمون کا ساتھی کوڈ یہاں پایا جا سکتا ہے: github.com/kamalct/fraud-detection-knowledge-graphs. تمام ڈیٹا ترکیب شدہ اور مکمل طور پر دوبارہ پیدا کیا جا سکتا ہے۔

ہم کیا احاطہ کریں گے:

کیوں ٹیبلر رولز رشتہ سے متعلق فراڈ سے محروم ہیں۔

شرطیں

مالیاتی گراف اور جمع کرنے کے اسکیموں کا ماڈل کیسے بنایا جائے۔

مرحلہ 1: معلوم انجیکشن پیٹرن کے ساتھ ڈیٹا سیٹ کیسے بنائیں

مرحلہ 2: Neo4j سے کیسے جڑیں اور رکاوٹیں بنائیں

مرحلہ 3: گراف میں اشیاء کو کیسے لوڈ کریں۔

مرحلہ 4: فاسٹ استفسار کے لیے اخذ کردہ تعلقات کو کیسے مادی بنایا جائے۔

پاس ورڈ کے سوالات کے ساتھ 5 فراڈ پیٹرنز کا پتہ لگانے کا طریقہ

پیٹرن 1: ڈپلیکیٹ رسیدیں کیسے تلاش کریں۔

پیٹرن 2: سرکلر انوائس کی انگوٹھی کیسے تلاش کی جائے۔

پیٹرن 3: منی مول نیٹ ورک کا پتہ لگانے کا طریقہ

پیٹرن 4: سپلائر کی ملی بھگت کے کلسٹرز کی شناخت کیسے کریں۔

پیٹرن 5: دائرہ اختیار سے باہر ادائیگی کی اجازت کی نشاندہی کیسے کریں۔

آخر سے آخر تک پائپ لائن کیسے چلائیں اور نتائج کی توثیق کریں۔

جمع کرنے اور پتہ لگانے کا طریقہ

انجیکشن گراؤنڈ ٹروتھ کے لیے یاد کی تصدیق کیسے کریں۔

پورے ورک فلو کو کیسے چلایا جائے۔

پروڈکشن آرکیٹیکچر: اپنی گراف پائپ لائن کی پیمائش کیسے کریں۔

دو مرحلے کا پتہ لگانے والے فن تعمیر کو کیسے نافذ کیا جائے۔

حد کو ایڈجسٹ کرنے اور غلط مثبتات کا انتظام کیسے کریں۔

سپر نوڈ اسکیلنگ کو کیسے کم کیا جائے۔

مشین لرننگ میں گراف فنکشنز کا استعمال کیسے کریں۔

کلیدی فن تعمیر کے اسباق اور مضمرات

نتیجہ

Related Posts