Fraud Detection System ডিজাইন

প্রতিটি পেমেন্ট বা লেনদেন সিস্টেমের পেছনে একটা নীরব প্রহরী থাকে — fraud detection। কেউ চুরি করা কার্ড দিয়ে কেনাকাটা করছে, কেউ account নিয়ে নিয়েছে (account takeover), কেউ bot দিয়ে হামলা করছে। চ্যালেঞ্জ হলো — লেনদেন থামানো যাবে না, কিন্তু জালিয়াতি ছাড়াও দেওয়া যাবে না, আর সিদ্ধান্ত নিতে হবে চোখের পলকে। চলো একটা শক্ত সিস্টেম ডিজাইন করি।

১. সমস্যা বোঝা (Requirements)

Functional requirements:

• প্রতিটি লেনদেন রিয়েল-টাইমে স্কোর করে approve / decline / review সিদ্ধান্ত দাও।
• rule engine ও ML model দুটোই চালাও।
• সন্দেহজনক লেনদেন review queue-তে পাঠাও।
• ম্যানুয়াল review ও chargeback থেকে label সংগ্রহ করো (feedback)।
• কেস ও সিদ্ধান্ত audit-এর জন্য লগ করো।

Non-functional requirements (ML-নির্দিষ্ট):

• Latency: ইনলাইন স্কোরিং p99 ১০০ ms-এর কম (পেমেন্ট flow ব্লক করে)।
• Recall: যতটা সম্ভব fraud ধরা — মিস হলে সরাসরি টাকার ক্ষতি।
• Precision: ভালো গ্রাহককে ভুল করে আটকানো (false positive) যথাসম্ভব কম।
• Freshness: velocity feature প্রায় তাৎক্ষণিক আপডেট হবে।
• Explainability: কেন decline হলো তা ব্যাখ্যাযোগ্য (regulatory ও review-এর জন্য)।

২. স্কেল আন্দাজ (Estimation)

লেনদেন/দিন              : ১০০ মিলিয়ন
গড় TPS                  : ১০০M / ৮৬,৪০০ ≈ ১,১৫০ TPS
পিক TPS (৫x)            : ≈ ৬,০০০ TPS

Fraud rate              : ~০.৫% (প্রবলভাবে imbalanced dataset)
Latency budget (১০০ ms):
  feature fetch (velocity): ~৩০ ms
  rule evaluation        : ~১০ ms
  ML scoring             : ~৩০ ms
  decision + log         : ~২০ ms

Feature store           : প্রতি card/device/account এর rolling counter
                          (যেমন 1m/1h/24h window) → Redis জাতীয় store
ইভেন্ট লগ/দিন           : ১০০M লেনদেন × ~২ KB ≈ ২০০ GB/দিন
Label delay             : chargeback আসতে ১-৩ মাস লাগতে পারে

মূল শিক্ষা: dataset প্রবলভাবে imbalanced (০.৫% fraud) এবং label অনেক দেরিতে আসে — এই দুটোই মডেলিংকে কঠিন করে তোলে।

৩. API ডিজাইন

POST /v1/score
  body: { txn_id, user_id, card_id, device_id, amount,
          merchant, geo, ip, ts }
  → 200 OK (১০০ ms-এর মধ্যে)
    { "decision": "approve|decline|review",
      "risk_score": 0.82,
      "reasons": ["velocity_1h_high", "new_device"] }

POST /v1/label            # feedback (review/chargeback)
  body: { txn_id, label: "fraud|legit", source: "chargeback|manual" }
  → 202 Accepted

GET /v1/cases?status=review   # analyst-দের review queue

reasons field গুরুত্বপূর্ণ — explainability ও analyst review দুটোতেই দরকার। /label endpoint দিয়েই feedback loop সম্পূর্ণ হয়।

৪. ডেটা মডেল ও Features

Feature গ্রুপ	উদাহরণ	উৎস	কোথায়
Transaction	amount, merchant, category, time	request	request-time
Velocity	গত 1m/1h/24h-এ txn সংখ্যা ও মোট amount	streaming counter	online store
Device	device_id নতুন কিনা, fingerprint mismatch	device intel	online store
Location	geo বনাম home, "impossible travel"	request + history	compute
User/account	account বয়স, গড় খরচ প্যাটার্ন	profile	online + offline
Network/IP	proxy/VPN, IP reputation	enrichment	online store
Label (offline)	fraud/legit (delayed)	chargeback/review	offline store

Velocity feature হলো হৃদয় — এগুলো streaming aggregation (Kafka + Flink) দিয়ে রিয়েল-টাইমে রাখা হয়, যাতে স্কোরিংয়ের সময় সাম্প্রতিক আচরণ জানা থাকে। Recommendation/RTB-এর মতোই এখানে feature store-এর online (serving) ও offline (training) দুই অংশ একই definition থেকে আসে, যাতে training-serving skew না হয়।

৫. হাই-লেভেল ডিজাইন

কম্পোনেন্ট:

• Client / Payment Service — লেনদেন শুরু করে, scoring service-কে inline call।
• Scoring Orchestrator — feature fetch, rule, ML, decision সাজায়।
• Feature Store (online) — velocity ও অন্যান্য feature দ্রুত আনে।
• Rule Engine — দ্রুত deterministic নিয়ম (hard block/allow)।
• ML Model Server — risk score দেয়।
• Streaming pipeline (Kafka + Flink) — velocity counter আপডেট, লগ।
• Decision/Case store — সিদ্ধান্ত, review queue, audit।
• Offline training — label join করে মডেল retrain।

Flow ধাপে ধাপে:

1. Payment service লেনদেন শুরু করার আগে scoring orchestrator-কে call করে।
2. Orchestrator online feature store থেকে velocity, device, location feature আনে।
3. Rule engine চলে — কিছু নিয়ম তাৎক্ষণিক block (যেমন blacklist) বা allow।
4. Rule নিশ্চিত না হলে feature ML model server-এ গিয়ে risk score পায়।
5. Rule ও ML score মিলিয়ে threshold-ভিত্তিক decision: approve / decline / review।
6. সিদ্ধান্ত payment service-কে ফেরত; কম-latency log Kafka-তে।
7. Flink সেই লেনদেন থেকে velocity counter আপডেট করে (পরের লেনদেনের জন্য)।
8. পরে chargeback বা analyst review থেকে label আসে → offline store → retraining।

৬. গভীরে (Deep Dive)

Rules + ML একসাথে

Rule engine দ্রুত, explainable ও তাৎক্ষণিক নিয়ন্ত্রণ দেয় — নতুন fraud pattern দেখা গেলে কয়েক মিনিটে একটা rule যোগ করা যায়, মডেল retrain-এর অপেক্ষা না করে। কিন্তু rule একা যথেষ্ট নয়; fraudster দ্রুত নিয়ম শিখে এড়িয়ে যায়। ML model সূক্ষ্ম, বহু-feature প্যাটার্ন ধরে যা rule-এ লেখা কঠিন। সাধারণ আর্কিটেকচার — rule দিয়ে নিশ্চিত block/allow আগে সারো, বাকিগুলোতে ML score দিয়ে probabilistic সিদ্ধান্ত, এবং ML score-কেও একটা rule-এর input হিসেবে ব্যবহার করা যায়।

ML Model ও Imbalanced Data

Fraud মাত্র ~০.৫%, তাই accuracy অর্থহীন (সব approve করলেও ৯৯.৫% accuracy)। তাই precision, recall, ও PR-AUC দেখা হয়। সাধারণত gradient-boosted tree (explainable, tabular-এ শক্তিশালী) বা DNN ব্যবহার হয়। imbalance সামলাতে class weighting বা downsampling, এবং feature-এ velocity ও graph-based signal (একই device-এ অনেক card) যোগ করা হয়। Anomaly detection (unsupervised) নতুন/অজানা fraud ধরতে সম্পূরক হিসেবে কাজে লাগে, যেহেতু label সবসময় থাকে না।

Precision-Recall Tradeoff ও Threshold

এটাই সবচেয়ে ব্যবসায়িক সিদ্ধান্ত। Threshold কমালে recall বাড়ে (বেশি fraud ধরা) কিন্তু false positive বাড়ে — ভালো গ্রাহক আটকে যায়, যা revenue ও বিশ্বাস নষ্ট করে। তাই প্রায়ই তিন-স্তরের decision: উচ্চ score = auto-decline, মাঝারি = review queue (মানুষ দেখে), নিম্ন = approve। Threshold-গুলো fraud loss বনাম customer friction-এর cost বিবেচনায় টিউন করা হয়, কোনো একক "সঠিক" মান নেই।

৭. বটলনেক ও স্কেলিং

• Latency: ১০০ ms inline budget কড়া। সমাধান — velocity counter precompute করে in-memory store-এ রাখা, ML মডেল lightweight ও in-memory serving, কোনো ধীর synchronous call নয়।
• Velocity freshness: streaming aggregation-এ সামান্য দেরিও দ্রুত-পরপর লেনদেনে miss ঘটাতে পারে; তাই low-latency stream processing ও atomic counter দরকার।
• Imbalanced + drift: fraud pattern প্রতিনিয়ত বদলায় (adversarial), তাই ঘন ঘন retrain, monitoring, এবং দ্রুত rule যোগ করার ক্ষমতা।
• Feedback loop: label দেরিতে আসে; chargeback ও analyst review পাইপলাইন দিয়ে নিয়মিত label সংগ্রহ ও retrain।
• Model serving cost: ৬,০০০ TPS-এ scoring সস্তা রাখতে efficient model ও caching (একই entity-র সাম্প্রতিক score)।

৮. সারসংক্ষেপ

ভালো fraud detection হলো rule engine ও ML model-এর সমন্বয় — দ্রুত explainable নিয়ম + সূক্ষ্ম প্যাটার্ন ধরা মডেল, রিয়েল-টাইমে velocity/device/location feature দিয়ে চালিত, ১০০ ms-এর কম latency-তে। সবচেয়ে কঠিন অংশ ML নয়, বরং imbalanced data, delayed/biased label, আর precision-recall tradeoff ব্যবসায়িক খরচ অনুযায়ী টিউন করা।