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

(analytics.fixelsmith.com)

3 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें

fraud detection अक्सर machine learning से पहले tables और joins को सही तरह से सेट करने और speed, location, amount, merchant, और time-of-day के abnormal patterns को SQL से खोजने से शुरू होती है
Velocity कम समय में उसी cardholder के लेनदेन के गुच्छों को ढूंढता है, और इसके लिए time window, threshold tuning, और false-positive whitelist की जरूरत होती है
Impossible travel LAG() और distance calculation से Chicago में payment के 7 मिनट बाद Los Angeles में payment जैसे physically impossible movement को strong cloned-card signal के रूप में पकड़ता है
Amount anomalies $1.00, $99.99, $499.99 जैसे amount ranges को खोजती हैं, जो card testing या rule evasion का संकेत दे सकती हैं, लेकिन benefits transactions पर अच्छी तरह फिट नहीं बैठतीं
merchant surge, usual time range के बाहर transactions, और window-function derived columns को साथ में इस्तेमाल करने पर transactions को multiple signals के आधार पर score किया जा सकता है और iteration cycle को कई हफ्तों से घटाकर कुछ घंटों तक लाया जा सकता है

लेनदेन डेटा में fraud के संकेत खोजने के SQL patterns

fraud detection अक्सर machine learning या graph database से पहले सही tables और joins, और unusual transaction patterns को खोजने वाले SQL से शुरू होती है
इसे credit card, medical claims, e-commerce, POS, और government benefit programs जैसे उन datasets पर लागू किया जा सकता है जहाँ पैसा चलता है और logs बचते हैं
नए dataset में आमतौर पर patterns को velocity, impossible travel, amount anomalies, merchant concentration, off-hours, और window-function based signals के क्रम में जोड़ा जाता है

1. Velocity: कम समय में बहुत अधिक transactions

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

2. Impossible travel: भौतिक रूप से असंभव movement

अगर एक card से Chicago में payment हो और 7 मिनट बाद Los Angeles में payment हो, तो दोनों में से एक के fake होने की संभावना बहुत अधिक है
यह pattern cloned card पकड़ने का मजबूत signal है, क्योंकि कुछ ही मिनटों में एक card का इतनी दूर दो जगह होना लगभग कभी legitimate नहीं होता
query LAG() से पिछले transaction का time और location लाती है, फिर current location और previous location के बीच distance और time निकालती है
haversine great-circle distance निकालने वाला function है
- ज़्यादातर data warehouses इसे देते हैं
- अगर न हो, तो इसे खुद लिखना संभव है
example threshold 600mph है
- commercial jet की cruising speed लगभग 575mph होती है, यानी यह ऐसी speed है जो flight से भी possible नहीं है
- अगर इसे 100mph तक घटाएँ, तो fast ground travel भी पकड़ में आएगा, लेकिन असली air travelers या बच्चों को pick up/drop करने वाले parents के legitimate transactions भी flag होने लगेंगे
इसी family में कुछ और signals भी देखे जा सकते हैं
- 5 मिनट के भीतर उसी state के दो दूर शहरों में transaction हो तो यह regional cloning ring का संकेत हो सकता है
- 1 घंटे के भीतर कई ZIP codes में transaction हो तो यह एक इलाके में चलने वाले skimmer ring का संकेत हो सकता है
- 10 मिनट के भीतर border cross करने वाले transactions international ring का signal हो सकते हैं

3. Amount anomalies: खास amount ranges में abnormal transactions

fraud में कुछ amount patterns बार-बार दिखते हैं, लेकिन normal usage में कम मिलते हैं
example conditions इन amount ranges को ढूंढती हैं
- $1.00, $5.00, $10.00
- $99.50 से ऊपर और $100.00 से कम
- $499.50 से ऊपर और $500.00 से कम
छोटे integer-dollar amounts आमतौर पर card testing का signal होते हैं
- flow यह होता है कि card-number dump से मिले numbers पहले check किए जाते हैं कि वे सच में काम करते हैं या नहीं, फिर resale की कोशिश होती है
- असली cardholder का ठीक $1.00 की चीज खरीदना uncommon है
- coffee $4.73 और fuel $52.81 जैसी amounts पर होने की संभावना ज़्यादा है, न कि बिल्कुल rounded amount पर
threshold के ठीक नीचे की amounts का अलग मतलब हो सकता है
- $99.99 कई जगह $100 से identity verification शुरू होने की line से बचने की कोशिश हो सकती है
- $499.99 $500 daily ATM limit से बचने का तरीका हो सकता है
- यह signal है कि transactor rules जानता है और उनके नीचे रहने की कोशिश कर रहा है
benefit transactions में rounded amount patterns ज़्यादा मददगार नहीं होते
- benefits को उसी तरह card-test नहीं किया जाता
- वहाँ आमतौर पर duplicate beneficiaries ज़्यादा महत्वपूर्ण signal होते हैं

4. Suspicious merchants: merchant level पर abnormal concentration

अगर gas pump card reader जैसा कोई specific reader skimmer से infected हो जाए, तो वह एक transaction नहीं बल्कि दर्जनों fraud cases पैदा कर सकता है
उस reader को कई हफ्तों तक इस्तेमाल करने वाले सभी cards किसी न किसी database में पहुँच सकते हैं
merchant viewpoint से यह कम समय में एक-दूसरे से असंबंधित cards की संख्या का सामान्य से ज़्यादा बढ़ना और transaction amounts का भी बढ़ना बनकर दिखता है
simple threshold example पिछले 7 दिनों को merchant और hour के हिसाब से group करके यह निकालता है
- unique cards की संख्या
- total transaction count
- total transaction amount
- और उन hours को ढूंढता है जहाँ unique cards 20 से ऊपर हों और total amount $5000 से ऊपर हो
static thresholds में size normalization की समस्या होती है
- Costco यह threshold 90 seconds में पार कर सकता है
- एक used bookstore शायद कभी नहीं करेगा
बेहतर तरीका है हर merchant को उसके अपने historical baseline से compare करना
- हाल के 60 दिनों के transactions को hourly buckets में group करें
- हर merchant के पिछले 168 hourly buckets के आधार पर average unique-card count निकालें
- और उन intervals को ढूंढें जहाँ current unique-card count historical average के 3x से ऊपर हो
168 hourly buckets का मतलब पिछले 7 दिनों के hourly intervals है
- क्योंकि daily और weekly seasonality महत्वपूर्ण होती है
- वही coffee shop Tuesday 2 PM और Saturday 9 AM पर अलग baseline रख सकती है
शुरुआत के लिए usual का 3x अच्छा point हो सकता है
- इतना loose कि alerts की बाढ़ न आ जाए
- और इतना strict कि सचमुच unusual intervals पकड़ में आ जाएँ

5. Off-hours: व्यक्ति के usual usage hours के बाहर transactions

ज़्यादातर लोगों की spending habits होती हैं
अगर 9 से 5 काम करने वाला व्यक्ति अचानक 3 बजे सुबह fuel भरवाता दिखे, तो संभव है कि card किसी और के हाथ में हो या वह travel कर रहा हो
travel होने की बात को दूसरे signals से confirm किया जा सकता है
query पिछले 90 दिनों में cardholder और hour के हिसाब से transaction counts निकालती है, फिर सिर्फ उन्हीं hours को usual hours मानती है जहाँ कम से कम 2 transactions हुए हों
इसके बाद अगर नए transaction का hour उस cardholder के earliest_hour और latest_hour range के बाहर हो, तो उसे detect किया जाता है
inner query की “उस hour में 2 या उससे ज़्यादा transactions” वाली condition महत्वपूर्ण है
- यह 3 महीने पहले हुई एक accidental late-night fuel purchase को usual hours में शामिल होने से रोकती है
- threshold को “एक बार हुआ था” की जगह वास्तविक आदत के मुताबिक सेट करती है
drawback यह है कि historical data चाहिए
- नए accounts के लिए baseline नहीं होता
- नए accounts के लिए पूरे user base के hour patterns इस्तेमाल किए जा सकते हैं, या account के कुछ महीने पुराने होने तक इस pattern को skip किया जा सकता है

6. Window functions से signals को combine करना

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

Patterns को साथ में इस्तेमाल करने का तरीका

कोई एक pattern अकेले काफ़ी नहीं है
हर pattern की साफ़ सीमाएँ हैं
- Velocity में vending machine operators जैसे false positives आते हैं
- geographically impossible movement एक ही metro area के भीतर होने वाले fraud को miss कर सकता है
- amount anomalies card-testing context के बाहर अच्छी तरह fit नहीं बैठतीं
- off-hours rule के लिए history चाहिए
practically, सभी patterns को चलाकर हर transaction को कई signals के आधार पर score करना काम करता है
जो transaction तीन या चार signals पर hit करे, वह लगभग हमेशा fraud होता है
जो transaction सिर्फ एक signal पर hit करे, वह travel कर रहे legitimate cardholder का unusual usage भी हो सकता है
अगर आप fraud detection की शुरुआत कर रहे हैं, तो Velocity से शुरू करना अच्छा है
- यह उपयोगी मात्रा में fraud सामने लाता है
- normal activity अपेक्षाकृत कम flag होती है
- इसे चलाने की cost भी कम है
अगर आपके पास पहले से 1 से 5 तक हैं, तो अगला investment window-function based raw columns में होना चाहिए
- एक बार बना देने पर टीम के सभी analysts इन्हें इस्तेमाल कर सकते हैं
- अगला fraud pattern जोड़ना अलग project नहीं रह जाता

ध्यान देने वाली बातें

NULL handling
- real transaction tables अक्सर SQL tutorials की तरह NULL का इस्तेमाल नहीं करतीं
- कई legacy systems “no end date” के लिए 9999-12-31 और “no start date” के लिए 0001-01-01 जैसे sentinel values इस्तेमाल करते हैं
- IS NULL से filter करने पर ऐसी rows चुपचाप छूट सकती हैं
- इसलिए WHERE clause लिखने से पहले उस table की convention की जाँच करनी चाहिए
False positives
- हर rule ऐसे real cardholders को पकड़ सकता है जो unusual लेकिन legitimate behavior कर रहे हों
- flagged cases के लिए human review चाहिए
- thresholds को real fraud और non-fraud के आधार पर tune करने के लिए feedback loop चाहिए
- एक single rule से auto-block करने पर customers खोए जा सकते हैं
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 पर बड़ा असर पड़ सकता है

1 टिप्पणियां

GN⁺ 3 시간 전

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 है
- लगता है हाल में 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 आम तौर पर कम चौंकाता है

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

लेनदेन डेटा में fraud के संकेत खोजने के SQL patterns

1. Velocity: कम समय में बहुत अधिक transactions

2. Impossible travel: भौतिक रूप से असंभव movement

3. Amount anomalies: खास amount ranges में abnormal transactions

4. Suspicious merchants: merchant level पर abnormal concentration

5. Off-hours: व्यक्ति के usual usage hours के बाहर transactions

6. Window functions से signals को combine करना

Patterns को साथ में इस्तेमाल करने का तरीका

ध्यान देने वाली बातें

NULL handling

False positives

Privacy

Cost

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

1 टिप्पणियां

Hacker News टिप्पणियाँ