تشخیص بانک از شماره کارت

شش رقم اول شمارهٔ sixteen رقمی کارت بانکی — BIN یا IIN — در بسیاری از معاملات روزمره اولین سرنخ است: این کارت از کدام صادرکننده چاپ شده؟ آیا با شبایی که برای واریز دادید «هم‌خانواده» است؟ آیا لوگوی روی درگاه باید با آن بانک باشد؟ ابزار تشخیص بانک از BIN در FinAI فقط به این شش رقم (یا به کل کارت که خودش همان ابتدا را برمی‌دارد) نگاه می‌کند و نام بانک را از جدول ثابت داخل repository پروژه برمی‌گرداند. نه API زنده از core banking، نه Luhn اجباری، نه استعلام موجودی. این مقاله توضیح می‌دهد جدول BIN چگونه نگه‌داری می‌شود، چرا پس از ادغام بانک‌ها نام‌ها عوض می‌شوند ولی BIN قدیمی هنوز دیده می‌شود، چرا BIN تازه ممکن است «نامشخص» بماند، و چه زمانی باید سراغ اعتبارسنجی کامل کارت بروید.

BIN چه چیزی را برمی‌گرداند و چه چیزی را نه

BIN پاسخ می‌دهد: «این بازهٔ شش‌رقمی در فهرست ما به موسسهٔ X نسبت داده شده.» BIN پاسخ نمی‌دهد: کارت فعال است، مسدود است، debit است یا credit، یا به نام چه کسی است. همچنین BIN به‌تنهایی نمی‌گوید ۱۶ رقم باقی‌مانده درست تایپ شده — برای آن Luhn لازم است. lookup FinAI می‌تواند با ورودی ۶ رقم یا ۱۶ رقم کار کند؛ در حالت دوم فقط شش رقم اول برای جدول استفاده می‌شود مگر اینکه در UI ترکیب با Luhn نشان داده شود.

تفاوت با ابزار validate-card: آنجا ابتدا طول ۱۶ و Luhn چک می‌شود، سپس BIN. اگر Luhn رد شود، هنوز ممکن است شش رقم اول «شبیه» یک بانک باشد ولی کل PAN غلط است. lookup برای زمانی است که فقط prefix دارید — مثلاً از رسید کارتخوان بخش اول PAN mask شده — یا می‌خواهید قبل از تایپ ۱۰ رقم بعدی بدانید کارت دست کدام بانک است.

جدول ثابت در repo؛ مزیت و محدودیت

FinAI عمداً به جای webservice بانکی، از فایل دادهٔ version-controlled استفاده می‌کند. مزیت: سرعت، بدون نیاز به token بانکی، و حریم خصوصی — شش رقم یا کارت کامل به سرور FinAI برای lookup ارسال نمی‌شود؛ منطق در مرورگر است. محدودیت: به‌روزرسانی دستی یا از pipeline داخلی است؛ BIN تازه‌ای که هفتهٔ قبل صادر شده ممکن است تا release بعدی «null» برگردد.

برای کاربر این یعنی «نامشخص» لزوماً کلاهبرداری نیست؛ ممکن است دادهٔ FinAI عقب باشد. برای maintainer یعنی issue یا PR با منبع عمومی (لیست‌های منتشرشده، اعلام بانک مرکزی، یا مستندات صادرکننده) لازم است. کاربران می‌توانند با جدول کدهای بانک کد شبا را cross-check کنند، ولی PAN و Sheba یک-to-one نیستند — فقط family بانک.

ادغام بانک‌ها؛ وقتی نام عوض شد ولی BIN ماند

در بازار ایران چند ادغام بزرگ رخ داده: برند روی کارت و اپ عوض شده، ولی میلیون‌ها PAN با BIN قدیمی در دست مشتری است. جدول FinAI معمولاً نام فعلی موسسه را نشان می‌دهد حتی اگر BIN به برند پیش از ادغام تعلق داشت. بنابراین ممکن است روی کارت فیزیکی «سپه» ببینید ولی BIN به نگهداری legacy اشاره کند — یا برعکس بسته به نسل کارت.

این برای پذیرنده مهم است: mismatch بین لوگوی درگاه و BIN گاهی به‌خاطر cache ذهنی مشتری است، نه کارت جعلی. برای تحلیلگر compliance، باید تاریخ صدور کارت را از بانک بپرسید؛ lookup عمومی تاریخ ندارد.

BIN جدید و کارت‌های co-branded

برخی محصولات مشترک با فintech یا طرح‌های ویژه BIN اختصاص می‌گیرند. تا وارد جدول مرجع FinAI نشوند، lookup «شناخته نشد» می‌زند در حالی که کارت در شبکه شتاب کار می‌کند. راه عملی: نام روی کارت فیزیکی و تماس با شماره پشت کارت. راه فنی برای تیم FinAI: افزودن ردیف BIN با citation.

مقایسهٔ سه ابزار در یک سناریو

فرض کنید رشتهٔ ۱۶ رقمی از مشتری دارید.

• card-bank-lookup: سریع‌ترین نام بانک از prefix؛ Luhn را الزام نمی‌کند.
• validate-card: Luhn + BIN؛ برای قبل از درگاه پرداخت مناسب‌تر.
• card-to-sheba: اگر Luhn OK و BIN شناخته شد، ممکن است فقط بگوید بانک کدام است و تبدیل قطعی نیست.

اگر فقط می‌خواهید بدانید «این ۶۱۰۴۳۳ مربوط به کدام بانک است؟» lookup کافی است. اگر می‌خواهید «آیا مشتری کل شماره را درست داده؟» validate-card. اگر می‌خواهید «شبا برای واریز چیست؟» اعتبارسنجی شبا یا اپ بانک — نه حدس از BIN.

خطاهای رایج در تفسیر BIN

اشتباه گرفتن ۴ رقم اول با BIN قدیمی: بعضی سیستم‌های legacy ۴+۴ می‌خوانند؛ استاندارد فعلی ۶ رقم است. FinAI شش رقم اول ۱۶‌رقمی را می‌گیرد.

کارت مجازی با BIN متفاوت: بعضی بانک‌ها برای virtual card range جدا دارند؛ ممکن است در جدول عمومی دیرتر بیاید.

PAN رمزنگاری‌شده یا token: Apple Pay token شمارهٔ واقعی نیست؛ lookup بی‌معناست.

امنیت و PCI؛ چرا شش رقم کمتر حساس‌اند ولی باز هم مراقب باشید

شش رقم اول به‌تنهایی معمولاً خارج از scope کامل PAN در many policies است، ولی ترکیب با نام، CVV، و expiry خطرناک می‌شود. lookup FinAI در client اجرا می‌شود؛ habit بد: paste کل کارت در تیکت پشتیبانی عمومی. habit خوب: فقط ۶ رقم اول برای تشخیص بانک، یا استفاده از ابزار local.

برای توسعه‌دهندگان فروشگاه

نمایش لوگوی بانک کنار فیلد کارت UX را بهتر می‌کند. از BIN table static می‌توانید در frontend همان دادهٔ FinAI sync کنید. cache invalidation با release سایت همگام باشد. fallback UI وقتی null: «بانک شناسایی نشد — Luhn را چک کنید» و لینک به validate-card.

برای کاربر نهایی

وقتی چند کارت در کیف دارید و فقط رقم‌های اول روی برچسب نوشته‌اید، lookup نام بانک را یادآوری می‌کند. وقتی واریز interbank می‌کنید، BIN کارت گیرنده با شبای داده‌شده «family» یکسان باید باشد — اگر lookup بگوید بانک A و شبا کد بانک B، قبل از transfer مکث کنید.

ارتباط با شبا و کد بانک

کد سه‌رقمی در شبا با کد بانک در جدول regulatory یک خانواده‌اند؛ BIN با آن کد رقم‌به‌رقم یکی نیست. mapping در FinAI از دو فایل جدا می‌آید. بنابراین تناقض ظاهری ممکن است؛ source of truth برای transfer شبا است. BIN برای کارتخوان و chargeback narrative.

وقتی lookup «نامشخص» برگرداند

1. دوباره شش رقم را از روی کارت فیزیکی بخوانید، نه از عکس blurry.
2. اعتبارسنجی Luhn را روی ۱۶ رقم بزنید؛ شاید اصلاً PAN invalid باشد.
3. اپ بانک را باز کنید؛ معمولاً نام صادرکننده روی home هست.
4. اگر مطمئنید کارت معتبر است، می‌توانید به FinAI feedback دهید — بدون ارسال ۱۶ رقم کامل در public issue؛ فقط BIN.

جمع‌بندی نقش lookup در اکوسystem ابزار بانکی FinAI

تشخیص بانک از BIN یک ذره‌بین روی prefix است: سریع، offline-friendly، و وابسته به جدول ثابت که گاهی کامل نیست. اعتبارسنجی کامل PAN با Luhn مرحلهٔ بعد است؛ شبا و mod 97 مسیر پول واقعی؛ card-to-sheba پل محدود بدون algorithm واحد. lookup را جایی بگذارید که «نام بانک» کافی است؛ جایی که پول movement است، شبا و درگاه رسمی را مقدم بدانید.

تاریخچهٔ کوتاه BIN و چرا شش رقم شد

در گذشته چهار رقم اول برای شناسایی صادرکننده کافی دانسته می‌شد؛ با رشد تعداد بانک‌ها و محصولات co-brand، فضای شش رقم (IIN) استاندارد شد تا collision کمتر شود. در ایران نیز rangeهای جدید برای neobank و digital issuance به جدول اضافه می‌شوند. FinAI هر release ممکن است doc changelog داشته باشد؛ کاربر نهایی فقط «نامشخص» را می‌بیند اگر range هنوز merge نشده باشد.

نمونهٔ ذهنی: رسید کارتخوان بدون PAN کامل

برخی رسیدهای POS فقط ۶+۴+۴+۲ mask می‌کنند. اگر ۱۲۳۴۵۶******۱۲۳۴ دارید، lookup روی ۱۲۳۴۵۶ نام بانک را می‌دهد تا بدانید settlement به کدام acquirer نزدیک است — نه برای chargeback کامل، که به PAN full از سیستم بانکی نیاز دارد. این use case compliance-light است ولی برای reconciliation روزانه مفید.

تفاوت lookup با استعلام «کارت متعلق به بانک X»

برخی اپ‌ها ادعا می‌کنند با «اسکن رقم» authenticity می‌سنجند. BIN فقط issuer را نشان می‌دهد؛ counterfeit card می‌تواند BIN درست و Luhn درست داشته باشد ولی در blacklist باشد. تشخیص جعل فیزیکی و chip auth خارج از scope lookup است. برای merchant، 3DS و response code درگاه مهم‌تر از BIN alone است.

نگهداری جدول؛ انتظار realistic از دادهٔ open

منابع عمومی BIN گاهی با تأخیر منتشر می‌شوند؛ بانک‌ها همه rangeها را public نمی‌کنند. FinAI table curated است نه exhaustive. اگر coverage برای use case سازمانی شما critical است، SLA داخلی خودتان را با export جدول و diff release-to-release بسازید — نه assume realtime از lookup UI.

کار با کارت هدیه و corporate

کارت‌های هدیه گاهی BIN موسسهٔ پرداخت third-party دارند؛ نام بانک retail ممکن است با نام روی پلastic فرق کند. lookup نام issuer از جدول را می‌دهد؛ redeem policy در قرارداد merchant است. corporate card با BIN تجاری ممکن است settlement به account مرکزی شرکت برود — BIN باز هم فقط issuer label است.

سوالات پرتکرار بدون الگوی FAQ یکسان

آیا شش رقم کافی است برای واریز؟ خیر؛ برای واریز شبا لازم است. آیا lookup جای Luhn است؟ خیر؛ validate-card برای ۱۶ رقم. BIN عوض می‌شود وقتی کارت renew می‌شود؟ معمولاً PAN جدید با همان BIN family می‌آید؛ گاهی reissue با range جدید. چرا FinAI API بانک نمی‌زند؟ privacy، cost، و نیاز به contract — جدول static tradeoff آگاهانه است.

طراحی UX در FinAI

ورودی کوتاه ۶ رقم برای کسانی که فقط prefix دارند؛ paste ۱۶ رقم برای lazy path. نتیجه:name + hint اگر logo در site موجود باشد. لینک cross به validate-sheba وقتی user goal transfer است نه curiosity. error state برای digit non-numeric بعد از normalize.

جمع‌بندی دوم از زاویهٔ risk

اتکأ صرف به BIN در anti-fraud کافی نیست؛ ولی نبود BIN در جدول signal ضعیف برای «کارت خارج از coverage» است، نه proof fraud. combine با Luhn، با رفتار transaction، و با verification شبا برای payout. lookup brick در wall است، نه کل ساختمان.