लेनदेन धोाधड़ी का पता लगाने के लिए इस्तेमाल होने वाले SQL पैटर्न

 (analytics.fixelsmith.com)
17 पॉइंट द्वारा GN⁺ 2026-05-17 | 4 टिप्पणियां | WhatsApp पर शेयर करें
  • धोखाधड़ी का पता लगाना अक्सर machine learning से पहले table और join को सही तरह से सेट करने और गति, स्थान, राशि, merchant, और समय-खंड में असामान्य पैटर्न को SQL से खोजने से शुरू होता है
  • Velocity छोटे समय अंतराल में एक ही cardholder के लेनदेन के जमाव को ढूंढता है, और इसके लिए time window, threshold tuning, और false positive whitelist की ज़रूरत होती है
  • Impossible travel LAG() और distance calculation के ज़रिए Chicago में भुगतान के 7 मिनट बाद Los Angeles में भुगतान जैसे शारीरिक रूप से असंभव मूवमेंट को cloned card के मज़बूत संकेत के रूप में पकड़ता है
  • राशि असामान्यता $1.00, $99.99, $499.99 जैसे amount range ढूंढती है, जो card testing या नियमों से बचने का संकेत दे सकते हैं, लेकिन benefit transactions में यह उतनी उपयोगी नहीं होती
  • merchant spike, सामान्य समय-खंड के बाहर के लेनदेन, और window function derived columns को साथ में इस्तेमाल करने पर लेनदेन को कई संकेतों के आधार पर score किया जा सकता है और iteration cycle को कई हफ्तों से घटाकर कुछ घंटों तक लाया जा सकता है

लेनदेन डेटा में धोखाधड़ी के संकेत खोजने के SQL पैटर्न

  • धोखाधड़ी का पता लगाना अक्सर machine learning या graph database से पहले सही table और join, और असामान्य लेनदेन पैटर्न को खोजने वाले SQL से शुरू होता है
  • यह credit card, medical claims, ecommerce, POS, और government benefit programs जैसे उन डेटा पर लागू हो सकता है जहाँ पैसा चलता है और logs बनते हैं
  • नए dataset में आम तौर पर velocity, impossible travel, amount anomalies, merchant concentration, unusual time-of-day, और window function आधारित signals के क्रम में पैटर्न जोड़े जाते हैं

1. Velocity: कम समय में अत्यधिक लेनदेन

  • जब चुराए गए कार्ड या account को जल्दी खाली करने की कोशिश होती है, तो उसी cardholder के लिए कम समय में लेनदेन का जमाव दिखता है
  • बुनियादी query हाल के 30 दिनों के लेनदेन को घंटे के हिसाब से group करती है और cardholder_id के अनुसार उन intervals को ढूंढती है जहाँ लेनदेन की संख्या सीमा से ऊपर जाती है
  • मुख्य tuning parameters हैं time window का आकार और transaction count threshold
    • 1 minute, 5 minute, और 1 hour वाले versions को parallel चलाकर तुलना की जा सकती है
    • card testing groups कुछ सेकंड में लेनदेन ठूंस सकते हैं, जबकि benefit fraud groups आधे दिन तक सक्रिय रह सकते हैं, इसलिए scale अलग होता है
  • सामान्य उपयोगकर्ता भी threshold पार कर सकते हैं
    • vending machine ऑपरेटर
    • prepaid card को bulk में reload करने वाले लोग
    • शुरुआती exploration के बाद ऐसे false positive targets की whitelist ज़रूरी होती है
  • sliding window तरीका COUNT(*) OVER (...) RANGE BETWEEN INTERVAL '5 minutes' PRECEDING AND CURRENT ROW से पिछले 5 मिनट के भीतर लेनदेन की संख्या निकालता है
  • QUALIFY Snowflake, BigQuery, Databricks, Teradata में काम करता है
    • Postgres में पूरी query को CTE में wrap करके बाहर filter करना पड़ता है

2. Impossible travel: शारीरिक रूप से असंभव यात्रा

  • अगर एक कार्ड से Chicago में भुगतान हो और 7 मिनट बाद Los Angeles में भुगतान हो, तो दोनों में से कम से कम एक के नकली होने की संभावना बहुत अधिक है
  • यह पैटर्न cloned card पकड़ने का मज़बूत संकेत है, क्योंकि एक ही कार्ड का कुछ मिनटों में दो दूर-दराज़ जगहों पर होना सामान्य रूप से लगभग असंभव है
  • query LAG() से पिछले लेनदेन का समय और स्थान लाती है, फिर वर्तमान और पिछले स्थान के बीच दूरी और समय की गणना करती है
  • haversine great-circle distance निकालने वाला function है
    • ज़्यादातर data warehouses इसे देते हैं
    • अगर न हो, तो इसे खुद भी लिखा जा सकता है
  • उदाहरण threshold 600mph है
    • commercial jet की cruise speed लगभग 575mph होती है, इसलिए इसका मतलब ऐसा movement है जो plane से भी संभव नहीं है
    • अगर इसे 100mph तक घटाएँ, तो तेज़ ज़मीनी यात्रा भी पकड़ी जा सकती है, लेकिन फिर वास्तविक air travelers या बच्चों को ले जा रहे माता-पिता की सामान्य transactions भी flag होने लगेंगी
  • इसी परिवार में कुछ अतिरिक्त signals भी देखे जा सकते हैं
    • 5 मिनट के भीतर एक ही state के दो दूर शहरों में transaction हो तो यह स्थानीय cloning group का संकेत हो सकता है
    • एक घंटे के भीतर कई ZIP codes में transaction हों तो यह किसी एक इलाके में चल रहे skimmer group का संकेत हो सकता है
    • 10 मिनट के भीतर border पार करने वाले transaction अंतरराष्ट्रीय group का संकेत हो सकते हैं

3. Amount anomalies: खास राशि-स्तरों में असामान्य लेनदेन

  • धोखाधड़ी में कुछ amount patterns अक्सर दिखते हैं, लेकिन सामान्य उपयोग में कम दिखाई देते हैं
  • उदाहरण के तौर पर ये शर्तें निम्न राशि-स्तर ढूंढती हैं
    • $1.00, $5.00, $10.00
    • $99.50 से अधिक या बराबर और $100.00 से कम
    • $499.50 से अधिक या बराबर और $500.00 से कम
  • छोटे पूरे-dollar amounts अक्सर card testing का संकेत होते हैं
    • card number dump से मिली संख्या वास्तव में काम कर रही है या नहीं, यह जांचने के बाद उसे दोबारा बेचने की प्रक्रिया का हिस्सा
    • असली cardholder का ठीक $1.00 की चीज़ खरीदना कम ही होता है
    • coffee $4.73 और fuel $52.81 जैसी non-rounded रकम पर ज़्यादा मिलने की संभावना होती है
  • threshold से ठीक नीचे की राशियों का मतलब अलग होता है
    • $99.99 कई जगहों पर $100 से शुरू होने वाली ID check सीमा से बचने की कोशिश हो सकती है
    • $499.99 $500 की daily ATM limit से बचने का तरीका हो सकता है
    • यह संकेत है कि actor नियम जानता है और उसके ठीक नीचे बना रहना चाहता है
  • benefit transactions में rounded amount patterns बहुत मददगार नहीं होते
    • benefits का card testing उसी तरह नहीं होता
    • आम तौर पर duplicate beneficiaries अधिक महत्वपूर्ण signal होते हैं

4. Suspicious merchants: merchant स्तर पर असामान्य सघनता

  • अगर fuel pump card reader जैसा कोई खास reader skimmer से संक्रमित हो जाए, तो वह एक transaction नहीं बल्कि दर्जनों fraud cases पैदा कर सकता है
  • उस reader को कई हफ्तों तक इस्तेमाल करने वाले सभी कार्ड किसी के database में पहुँच सकते हैं
  • merchant के नज़रिए से यह कम समय में आपस में असंबंधित कार्डों की संख्या का सामान्य से बहुत अधिक बढ़ना और transaction amount का बढ़ना बनकर दिखता है
  • एक सरल threshold उदाहरण हाल के 7 दिनों में merchant और hour के हिसाब से group करके ये metrics निकालता है
    • unique cards की संख्या
    • कुल transactions
    • कुल transaction amount
    • उन time buckets की खोज जहाँ unique cards 20 से अधिक हों और total amount $5000 से ऊपर हो
  • static thresholds में size normalization की समस्या होती है
    • Costco 90 सेकंड में ही यह सीमा पार कर सकता है
    • used bookstore शायद ही कभी इसे पार करे
  • बेहतर तरीका है हर merchant की तुलना उसके अपने historical baseline से करना
    • हाल के 60 दिनों के लेनदेन को hour के हिसाब से group करें
    • हर merchant के पिछले 168 hourly buckets के आधार पर unique cards का average निकालें
    • उन intervals को ढूंढें जहाँ current unique cards historical average के 3 गुना से ऊपर हों
  • 168 hourly buckets का मतलब पिछले 7 दिनों के hourly intervals है
    • क्योंकि daily और weekly seasonality महत्वपूर्ण होती है
    • एक ही coffee shop के लिए मंगलवार दोपहर 2 बजे और शनिवार सुबह 9 बजे का baseline अलग होता है
  • शुरुआती बिंदु के रूप में सामान्य का 3 गुना इस्तेमाल किया जा सकता है
    • इतना ढीला कि alerts की बाढ़ न आ जाए
    • इतना सख्त कि वास्तव में असामान्य intervals पकड़ सके

5. Off-hours: व्यक्ति के सामान्य उपयोग समय के बाहर के लेनदेन

  • ज़्यादातर लोगों के spending habits होते हैं
  • अगर 9 से 5 काम करने वाला व्यक्ति अचानक रात 3 बजे fuel खरीदना शुरू करे, तो संभव है कि कार्ड किसी और द्वारा इस्तेमाल हो रहा हो या वह यात्रा पर हो
  • यात्रा में होने की बात को दूसरे signals से आगे verify किया जा सकता है
  • query हाल के 90 दिनों में cardholder और hour के हिसाब से transaction count निकालती है, फिर केवल उन hours को सामान्य समय-खंड मानती है जहाँ कम से कम 2 transactions हुए हों
  • उसके बाद अगर नया transaction उस cardholder की earliest_hour और latest_hour range के बाहर हो, तो उसे detect किया जाता है
  • inner query की “उस hour में 2 या उससे अधिक transactions” वाली शर्त महत्वपूर्ण है
    • यह 3 महीने पहले हुई किसी एक आकस्मिक late-night fuel purchase को सामान्य time range में शामिल होने से रोकती है
    • यह baseline को “कभी एक बार हुआ” नहीं बल्कि वास्तविक आदत के अनुरूप रखती है
  • इसकी कमी यह है कि historical data चाहिए
    • नए accounts के लिए baseline नहीं होता
    • नए accounts के लिए पूरे user base के time-of-day patterns का उपयोग किया जा सकता है, या account के कुछ महीने पुराने होने तक इस pattern को छोड़ा जा सकता है

6. Window functions से signals को जोड़ना

  • window function patterns अपने-आप में अलग fraud type नहीं हैं, बल्कि ऊपर के पाँच patterns को combine किए जा सकने वाले signals में बदलने की तैयारी हैं
  • हर transaction के लिए ये derived columns पहले से बनाए जा सकते हैं
    • पिछले transaction के बाद बीता समय: timestamp - LAG(timestamp)
    • merchant बदला या नहीं: पिछले merchant_id और वर्तमान merchant_id की तुलना
    • पिछले 24 घंटे की cumulative amount: SUM(amount) OVER (...)
    • उस दिन का कौन-सा transaction है: ROW_NUMBER()
  • अगर इन columns को materialize कर दिया जाए, तो fraud rules साधारण filter expressions बनकर रह जाते हैं
  • card testing groups को इन शर्तों से खोजा जा सकता है
    • दिन का 5वां या उससे बाद का transaction
    • पिछले transaction के 60 सेकंड से कम समय बाद
    • merchant पिछले transaction से अलग हो
  • अगर नई fraud hypothesis को engineering ticket की जगह SQL filter के रूप में व्यक्त किया जा सके, तो iteration cycle कई हफ्तों से घटकर कुछ घंटों की हो जाती है
  • नतीजतन ज़्यादा fraud को ज़्यादा तेज़ी से पकड़ा जा सकता है

पैटर्न को साथ में इस्तेमाल करने का तरीका

  • कोई एक pattern अपने-आप में पर्याप्त नहीं है
  • हर pattern की स्पष्ट सीमाएँ हैं
    • Velocity में vending machine ऑपरेटर जैसे false positives आते हैं
    • geographically impossible travel बड़े metropolitan area के भीतर होने वाली fraud को मिस कर सकता है
    • amount anomalies card testing के बाहर के संदर्भों में उतनी उपयोगी नहीं हैं
    • unusual time rules के लिए history चाहिए
  • व्यवहार में सभी patterns को चलाकर हर transaction को कई signals पर score करना काम करता है
  • जो transaction तीन या चार signals पर hit करते हैं, वे लगभग हमेशा fraud होते हैं
  • जो transaction सिर्फ एक signal पर आते हैं, वे यात्रा कर रहे असली cardholder के असामान्य उपयोग भी हो सकते हैं
  • अगर आप fraud detection अभी शुरू कर रहे हैं, तो Velocity से शुरुआत करना अच्छा है
    • यह उपयोगी मात्रा में fraud उजागर करता है
    • सामान्य गतिविधि को अपेक्षाकृत कम flag करता है
    • इसे चलाने की लागत भी कम होती है
  • अगर आपके पास 1 से 5 तक के patterns पहले से हैं, तो अगला निवेश window function आधारित raw columns में होना चाहिए
    • एक बार बनने पर टीम के सभी analysts उनका उपयोग कर सकते हैं
    • अगला fraud pattern जोड़ना अलग project नहीं रह जाता

ध्यान देने योग्य बातें

  • NULL handling

    • वास्तविक transaction tables अक्सर SQL tutorials की तरह NULL का इस्तेमाल नहीं करतीं
    • कई legacy systems “कोई end date नहीं” के लिए 9999-12-31 और “कोई start date नहीं” के लिए 0001-01-01 जैसे sentinel values इस्तेमाल करते हैं
    • IS NULL से filter करने पर ऐसी rows चुपचाप छूट सकती हैं
    • WHERE clause लिखने से पहले संबंधित table की conventions जांचनी चाहिए

  • False positives

    • हर rule ऐसे वास्तविक cardholders को पकड़ सकता है जिनका व्यवहार असामान्य लेकिन वैध हो
    • flag की गई घटनाओं पर मानवीय समीक्षा ज़रूरी है
    • threshold को वास्तविक fraud और non-fraud outcomes के आधार पर समायोजित करने वाला feedback loop चाहिए
    • एक ही rule के आधार पर auto-block करने से ग्राहक खोए जा सकते हैं

  • Privacy

    • अगर data में PII है, तो लागू होने वाली data usage policies का पालन करना चाहिए
    • पहले de-identified या sample data पर काम करें, और production data को approval के बाद ही इस्तेमाल करें

  • Cost

    • बड़े partitions पर window functions सस्ते नहीं होते
    • पहले date range filter करें, उसके बाद window functions लागू करें
    • अगर पूरे dataset के 2 साल के transactions पर पहले LAG() चला दिया और बाद में WHERE लगाया, तो warehouse credit budget का बड़ा हिस्सा खर्च हो सकता है

संबंधित पढ़ाई

4 टिप्पणियां

 
kaydash 2026-05-17

यह वही तरीका है जो पहले बैंक के account system और channel system में उधार लिया जाता था।
 
GN⁺ 2026-05-17
Hacker News टिप्पणियाँ

  • मुझे लगता है कि यह मानदंड कि असली कार्ड मालिक शायद ही कभी ठीक $1.00 की खरीदारी करता है, इस बात पर निर्भर नहीं करता कि विक्रेता कीमत कैसे तय करता है?
    चोरी किए गए credit card को टेस्ट करने के लिए वेबसाइट पर कुछ खरीदते समय खरीदार अपनी मर्ज़ी से कीमत तय नहीं कर सकता
    साथ ही यह अमेरिका जैसी स्थिति के हिसाब से बहुत ज़्यादा सोचा गया लगता है, जहाँ टैक्स कीमत में शामिल नहीं होता, जबकि दूसरे इलाकों में ठीक-ठीक कीमतें बहुत आम हैं
    लेख के दूसरे मानदंड भी कितने अच्छे से काम करेंगे, इस पर भी संदेह है। उदाहरण के लिए, अगर पिछले 90 दिनों में आम तौर पर 2 से ज़्यादा लेन-देन करने वाले समय के बाहर लेन-देन करने वालों को चिह्नित किया जाए, तो क्या लगभग आधे लोग इसमें नहीं फँसेंगे?
    यह साफ़ नहीं है कि यह जटिल domain knowledge को बहुत साधारण SQL query में समेटने की कोशिश करने वाला लेख है, या पूरी तरह अटकल और गढ़ंत है। “लेन-देन धोखाधड़ी पकड़ने के लिए इस्तेमाल होने वाले छह SQL patterns” और “यहाँ ऐसा कुछ नहीं है जिस पर मैंने वास्तव में काम किया हो या देखा हो” — ये दोनों वाक्य एक-दूसरे से टकराते हैं

    • “सामान्य समय के बाहर का लेन-देन” काफ़ी बुनियादी मानदंड लगता है
      आम तौर पर कोई रात 2 बजे fuel, coffee, snacks नहीं खरीदता, लेकिन अगर कभी बहुत कम ही ऐसा करे, तो उसके पीछे कोई निजी आपातस्थिति होने की संभावना ज़्यादा है, और उस समय बैंक को फोन करने का मन नहीं होगा
      मुझे पता है कि अवसरवादी चोर भी उसी समय सक्रिय हो सकते हैं, लेकिन false positive की लागत भी होती है
    • इससे भी बुरा। मेरे अनुभव में coffee अक्सर round amount में होती है, और fuel भरवाते समय कुछ लोग जानबूझकर ठीक-ठीक रकम तक भरवाते हैं
      और कुछ petrol station 10, 20, 50 euro जैसी पहले से तय रकम ही माँगते हैं
    • एक रात bar में मुझे भूख लगी थी और मैं chips का एक packet खरीदना चाहता था, लेकिन कार्ड की minimum payment £5 थी, तो मैंने कहा बस £5 charge कर दीजिए
      फिर कार्ड fraud के शक में block हो गया, और यह काफ़ी चिढ़ाने वाला था। रात 2 बजे नशे की हालत में यह झेलना बिल्कुल नहीं चाहता था
      शायद उसने मुझे मुझसे ही बचाया हो, लेकिन फिर भी बहुत असुविधाजनक था
    • पता नहीं अब भी ऐसा होता है या नहीं, लेकिन पहले hotel या rental car जैसी जगहों पर कमरा बुक करने या गाड़ी किराए पर देने से पहले $1.00 transaction से credit card validity जाँची जाती थी
    • इस तरीके को test transaction में थोड़ा jitter जोड़कर आसानी से bypass किया जा सकता है, और सही statistical analysis से इसे आसानी से बेहतर भी बनाया जा सकता है
      और वैसे भी, जहाँ लगभग 100% accuracy की उम्मीद नहीं होती, ऐसे heuristic pattern recognition तो वही क्षेत्र है जहाँ AI को अच्छा होना चाहिए, है न?

  • “10 मिनट में border crossing मतलब international organization” वाला मानदंड यूरोप के border-adjacent इलाकों में रहने वाले सामान्य लोगों पर भी लागू हो सकता है
    भले ही card-not-present transactions को बाहर कर दें, फिर भी यह गलत मान लेता है कि सभी merchant locations सही तरह से सेट हैं, सारी बिक्री physical stores में ही होती है, mobile sales जैसी कोई चीज़ नहीं है, और सभी transactions online process होती हैं

    • कुछ हफ़्ते पहले जब मैं अमेरिका से कनाडा गया था, तब भी शायद 10 मिनट ही लगे थे

  • अंत तक पढ़ने पर पता चलता है कि सामग्री खोखली है और सलाह आपस में विरोधाभासी है। लगभग तय है कि यह LLM-generated लेख है
    एक तरफ़ कहता है कि “आपकी टीम” को किसी एक pattern पर निर्भर नहीं होना चाहिए, लेकिन दूसरी तरफ़ कहता है कि सिर्फ़ pattern 1 से भी “उपयोगी मात्रा में fraud” सामने आ सकता है
    “टीम के सभी analyst उन्हें, यानी window functions, मिलते ही इस्तेमाल करेंगे, और अगला fraud pattern जोड़ना अब कोई project नहीं रहेगा” जैसी अजीब पंक्तियाँ भी हैं
    फिर लगभग सभी examples में IS NULL नहीं है, लेकिन IS NULL filtering लागू न होने की एक अप्रासंगिक चर्चा आ जाती है, और जिस एक उदाहरण में है भी, वह दूसरे संदर्भ में है
    कुल मिलाकर यह low-quality और बहुत लंबा लेख है

  • Hacker News, इस पर ध्यान देना चाहिए
    “Fixel Smith” एक AI-निर्मित व्यक्ति है, और यह लेख fraud analysis से लगभग असंबंधित है। यह नाम एक musician(1), novelist(2), fraud analyst(3), influencer(4) — लगभग हर कल्पनीय पहचान में इस्तेमाल हो रहा है
    220 से ज़्यादा points और 70 से ज़्यादा comments होने के बावजूद, लगभग किसी ने नहीं पहचाना कि यह लेख काफ़ी नकली है, और किसी ने यह भी नहीं देखा कि यह एक AI-generated persona है

    1. https://www.amazon.it/Forged-Soundtrack-Explicit-Fixel-Smith...

    2. https://fixelsmith.com

    3. https://analytics.fixelsmith.com/

    4. https://www.instagram.com/fixeltales/

    • लगता है हाल में Hacker News को ऐसी low-quality AI submissions ऊपर लाने की एक परेशान करने वाली आदत पड़ गई है
      सोचता हूँ कि क्या यह AI बाढ़ समुदाय की निर्णय क्षमता के बारे में कोई असुविधाजनक सच्चाई दिखा रही है, या यह बस मौजूदा सुरक्षा-तंत्र की विफलता है जिसे बदलना चाहिए
    • मैं फ़ोन पर लेख देख रहा था और बस comments हल्के से पढ़े। यह तय करना हमेशा आसान नहीं होता कि कोई लेख AI-generated है या edited, लेकिन यहाँ तो quotes देखते ही पहली नज़र में साफ़ था
      अगर मान लें कि सारे comments सद्भावना में लिखे गए थे, तो यहाँ तक कि इस जगह पर भी AI literacy कम होना काफ़ी चिंताजनक है
    • ऊपर-ऊपर देखने पर भी यह या तो बहुत ज़्यादा लिखने वाला कोई व्यक्ति लगता है या bot
      novels का analysis posts से लगभग कोई संबंध नहीं है, और analysis posts में LLM writing style दिखती है, इसलिए पूरा मामला संदिग्ध लगता है। मूल लेख का विषय fraud है, यह सोचकर विडंबना और बढ़ जाती है
    • अगर ज़्यादातर लोग पढ़ी जा रही चीज़ के लेखक की आदतन जाँच करते हों, तो मुझे वह और भी ज़्यादा हैरान करेगा
      सच कहूँ तो मैं आम तौर पर byline भी नहीं देखता, और साइट के दूसरे हिस्से तो बिल्कुल नहीं
    • यह साफ़ तौर पर एक वास्तविक मौजूद लेख है। बेशक यह LLM द्वारा लिखा हुआ लगता है, लेकिन अगर किसी लेख पर की जा सकने वाली सबसे बुरी आलोचना सिर्फ़ यह है कि वह LLM जैसा दिखता है, तो शायद वह असल आलोचना नहीं है
      सामग्री गढ़ी हुई है या नहीं, यह स्पष्ट नहीं है, लेकिन यह अंदाज़ा लगाए बिना भी कि इसे LLM ने लिखा या यह fiction है, लेख की सामग्री की आलोचना की जा सकती है। इसमें कहीं ज़्यादा ठोस खामियाँ हैं

  • हम open source security framework tirreno विकसित कर रहे हैं
    यहाँ समझाए गए approach पर मुझे संदेह है। उदाहरण के लिए impossible travel एक वैध और व्यापक रूप से इस्तेमाल की जाने वाली तकनीक है, लेकिन यह IP address-आधारित online user behavior से जुड़ी होती है
    tirreno में उन मामलों के लिए अलग rules हैं जहाँ IP साफ़ तौर पर Apple Relay या VPN/Tor से आया हो, और वे अलग flags हैं
    मुझे लगता है कि कुछ या शायद पूरे examples LLM-generated हैं। संदर्भ आपस में गड़बड़ हैं, और card payments में GPS location को बड़े पैमाने पर इकट्ठा करने वाली कोई वास्तविक व्यवस्था नहीं है

    1. https://github.com/tirrenotechnologies/tirreno

  • यह ज़्यादा “supporting data के बिना SQL queries में encoded rule-based logic” जैसा है
    thresholds तो बहुत हैं, लेकिन ऐसा कोई data नहीं है जो दिखाए कि वे thresholds मायने रखते हैं

  • “transaction data में fraud detection ज़्यादातर SQL है, न कि machine learning, न graph database, न Gartner इस साल जो भी hype कर रहा है” जैसी बात सिर्फ़ तब जायज़ लगती है जब आप पूरे program integrity काम को कवर कर रहे हों
    अगर कोई आसान और खुरदरा तरीका समस्या-क्षेत्र हल कर देता है, तो वह बेहतर हो सकता है
    fintech customers आम तौर पर जानना चाहते हैं कि अभी जो transaction हो रही है वह fraud है या नहीं, और वे high-dimensional data पर कुछ milliseconds में जवाब चाहते हैं। relational database के लिए यह काम अक्सर इतने पैमाने और real-time constraints वाला होता है कि उसे निभाना मुश्किल हो जाता है, इसलिए उसका उपयोग historical data loading जैसी दूसरी चीज़ों के लिए होता है
    इसी वजह से in-memory databases, stream processing engines, और machine learning तक आए
    फिर भी लेखक की कुछ बातें ठीक हैं, ख़ासकर noisy alerts को संभालने की समस्या performance engineering से आगे की एक सामान्य समस्या है, इसलिए अगली पोस्ट का इंतज़ार है

    • मेरे अनुभव में, जो चीज़ यहाँ बताई गई है, उसे fraud detection से ज़्यादा fraud prevention कहना सही होगा
      एक mature setup में दोनों साथ मौजूद होते हैं और एक-दूसरे को पूरा करते हैं
      prevention में हमेशा latency requirements, available data, और user behavior की अधूरी तस्वीर जैसी सीमाएँ होती हैं। machine learning और rules से तेज़ निर्णय लेकर ज़्यादातर मामलों को संभाला जाता है, लेकिन इन सीमाओं के कारण हर fraud को ठीक-ठीक रोका नहीं जा सकता
      detection उसके बाद के नतीजों से जुड़ा होता है। analyst teams approved transactions का विश्लेषण करके fraud के संकेत ढूँढती हैं। यह उन fraud types में ख़ास तौर पर महत्वपूर्ण है जहाँ chargeback या customer complaints जैसे बाहरी signals नहीं मिलते। platform integrity इसका एक उदाहरण है, और fintech के anti-money-laundering systems को भी fraud ढूँढना पड़ता है
      दोनों के पूरक होने की वजह यह है कि detected transactions आगे के prevention models को train और evaluate करने के लिए labels बनते हैं

  • कहा गया कि अगर Chicago में कार्ड swipe हुआ और 7 मिनट बाद Los Angeles में फिर swipe हुआ, तो दोनों में से एक नकली होगा, लेकिन मैं सोचता हूँ कि online shopping में यह कैसे काम करता है
    अगर मैं सोफ़े पर बैठकर Amazon से कुछ खरीदूँ, तो address कहाँ रिकॉर्ड होता है?
    और एक edge case यह भी हो सकता है कि पति-पत्नी online account share कर रहे हों, और उनमें से एक यात्रा पर हो तथा saved card details से खरीदारी कर रहा हो

    • कार्ड swipe, insert या tap करना card-present transaction है। online shopping की तरह कार्ड नंबर दर्ज करना card-not-present transaction है
      retailer और bank इस फ़र्क को समझ सकते हैं
    • transaction metadata से यह अलग किया जा सकता है। मैंने credit card company में काम किया है
    • मेरी समझ से system card-present और card-not-present में फ़र्क करता है

  • “यह तरीका history बनने तक काम नहीं करता, और नए accounts के लिए कोई baseline नहीं होती” — यह एक कम आंका गया customer experience पहलू है
    जब मैं नया customer हूँ या कोई नया pattern दिखाता हूँ और कार्ड decline हो जाता है, तो लगता है software अच्छा काम कर रहा है
    लेकिन जब मेरा authenticated past history मौजूद होने के बावजूद transaction decline हो जाए, तो किसी भोले और paranoid algorithm पर झुंझलाहट होती है

    • banks की प्रेरणा fraud कम करने में होती है
      fraudulent transactions आखिरकार reversal या refund के रूप में bank के नुकसान में बदलती हैं। declined transaction सिर्फ़ एक नाराज़ customer बनाती है, और customer शिकायत करके जल्दी भूल जाता है। इसलिए externalized cost का बोझ customer पर चला जाता है
      इसीलिए bank ज़्यादा सावधानी की तरफ़ गलती करने और false positives होने पर भी transaction decline करने के लिए प्रोत्साहित होते हैं

  • क्या machine learning का सार यही नहीं है कि ऐसे rules data से सीखे जाएँ?
    मुझे लगता है सही तरीका यह होगा कि machine learning model से fraud से जुड़े patterns ढूँढे जाएँ और फिर देखा जाए कि उनमें कौन-से वाजिब लगते हैं। इससे शायद नई hypotheses भी मिल सकती हैं

    • जो चीज़ explainable न हो और deterministically दोहराकर सुधारी न जा सके, वह financial transaction declines के काम में बहुत जोखिमभरी है
      human analyst को compliance team को 5 मिनट के email में यह समझा सकना चाहिए कि किसी खास transaction को क्यों decline किया गया, और adverse decision से बचने के लिए क्या अलग किया जाना चाहिए था
      machine learning से एक समस्या ठीक करो तो अक्सर दो नई समस्याएँ पैदा हो जाती हैं जो अभी स्पष्ट भी नहीं होतीं। समय के साथ बदलने पर regression या unexpected side effects के मामले में SQL आम तौर पर कम चौंकाता है
 
aliveornot 2026-05-19

मैं सोच रहा था कि rounded amount क्या है.. पता चला rounded ही है
 
xguru 2026-05-19

इसे ऐसा क्यों अनुवाद किया गया था, हुह? मैंने इसे ठीक कर दिया है।