کارت به شماره حساب

در پیشخوان بانک یا فرم داخلی گاهی «شماره حساب» از روی «شماره کارت» خواسته می‌شود. امید کاربر این است که ده رقم میانی PAN مستقیماً همان account field در BBAN باشد. در اکوسystem ایران الگوریتم public یکسان کارت→شماره حساب منتشر نشده؛ هر بانک padding، branch encoding، و نگاشت PAN-to-core را خودش نگه می‌دارد. ابزار کارت به شماره حساب در FinAI مثل کارت به شبا عمل می‌کند: Luhn، نام بانک از BIN، و اگر تبدیل verified نباشد — صداقت به‌جای حدس حساب.

مرز PAN، حساب، و شبا

PAN: شناسهٔ پرداخت sixteen رقمی. شماره حساب: تا ۱۹ رقم در BBAN (با قواعد per bank). شبا: IR + check + BBAN. سه لایه related ولی not interchangeable. ساخت شبا وقتی حساب و کد بانک را از statement دارید کار می‌کند — نه وقتی فقط PAN دارید.

مسیر ابزار FinAI

ورودی ۱۶ رقم. Luhn fail → توقف. BIN → بانک. اگر repository الگوریتم account برای آن bankId ندارد → account null، definitive=false، copy فارسی «از اپ بانک بگیرید». این feature است — mis-booking payroll از account حدسی بدتر از «نمی‌دانیم» است.

چرا سایت‌های دیگر گاهی «حساب» می‌دهند

Heuristic غلط (ten digit middle = account) یا data leak. FinAI category دوم نیست. حتی اگر عدد با statement یکی شد، بدون audit vector reproducible نپذیرید.

Workflow پیشنهادی

1. PAN در validate-card.
2. بانک در lookup.
3. card-to-account — اگر null، اپ بانک.
4. حساب را در generate-sheba + validate-sheba.

مقایسه با sheba-to-card و card-to-sheba

هر سه جهت conversion بین identifiers محدودند. bank-from-sheba فقط label. account-to-sheba اگر leaf جدا باشد مسیر forward از account known.

حریم

client-side؛ PAN log نشود. PCI: server-side storage بدون compliance ممنوع.

برای حسابدار و حقوق

لیست ۵۰۰۰ PAN → bulk export از HR banking، نه online tool. یک ردیف sanity: Luhn + bank name کافی است؛ account برای واریز از فایل رسمی.

برای پذیرندگان

از PAN حساب settlement infer نکنید — acquirer policy. شبا در checkout جدا.

BIN vs کد بانک در شبا

BIN ۶۱۰۴۳۳ ممکن است brand legacy؛ کد شبا ۰۵۷ پاسارگاد — تناقض هشدار. truth برای transfer: شبا از گیرنده.

کارت هدیه و corporate pooled

PAN ممکن است به pooled account map شود — account «visible» معنی دار نیست. صادرکننده.

آینده محصول

اگر algorithm verified + test vectors برای bank خاص add شود، definitive=true — تا آن زمان copy صریح.

چرا ده رقم میانی PAN کافی نیست

در urban legend بانکی، «رقم‌های ۷ تا ۱۶» یا «میانی» account هستند — بدون spec بانک این almost always false است: branch code، product type، و checksum internal ممکن است در PAN encode شوند ولی mapping به ۱۹ رقم BBAN linear نیست. card-to-account در FinAI این extrapolation را code نمی‌کند — همان تصمیمی که در کارت به شبا گرفته شد.

مسیر صحیح وقتی حساب را پیدا کردید

statement PDF یا اپ: شماره حساب + کد بانک سه‌رقمی → ساخت شبا → validate. قالب‌بندی شبا برای paste در درگاه. card-to-account فقط مرحلهٔ «اگر فقط PAN دارید چه نمی‌توانیم».

Luhn و BIN قبل از هر inference

PAN typo → Luhn fail → stop. BIN unknown → bank label null → account inference meaningless. validate-card workflow اول.

حساب مشترک و امضا

account number روی statement ممکن است joint باشد — card ممکن است primary holder. legal خارج scope؛ tool numeric only.

واریز interbank

برای پایا فقط شبا — account internal bank useful برای transfer intra-bank. card-to-account حتی اگر someday partial algorithm داشت، cross-bank rule فرق دارد.

امنیت batch

CSV PAN در email — encrypt. FinAI one-row client tool نه batch processor.

آموزش prefill forms

فرم‌های قدیمی «شماره حساب از روی کارت» — label misleading. HR should collect IBAN.

تفاوت با card-bank-lookup

بانک از کارت فقط برند را از BIN می‌گوید؛ card-to-account همان گام را طی می‌کند ولی پیام اصلی دربارهٔ «شماره حساب داخلی» است: بدون الگوریتم تأییدشده، فیلد حساب خالی می‌ماند.

داستان بدون شماره واقعی: حقوق و دستمزد

شرکتی در Excel فقط ستون PAN دارد و می‌خواهد واریز گروهی به «شماره حساب» انجام دهد. مسئول IT ابزار card-to-account را امتحان می‌کند؛ خروجی می‌گوید بانک شناسایی شد ولی حساب قطعی نیست. تصمیم درست: درخواست bulk IBAN از بانک یا به‌روزرسانی پروندهٔ پرسنل — نه حدس ده رقم از وسط کارت. بعد از دریافت حساب، ساخت شبا و اعتبارسنجی برای هر ردیف.

کارت مجازی و چند حساب

کارت مجازی ممکن است به sub-account یا wallet داخلی وصل باشد که روی statement به‌صورت aggregate دیده می‌شود. PAN یکتا برای POS است؛ mapping به ledger بانک proprietary است. card-to-account نمی‌تواند بدون API بانک این لایه را باز کند.

شعبه و کد شعبه

گاهی کاربر فکر می‌کند «چهار رقم اول حساب = شعبه» — در BBAN ممکن است بخشی از account field باشد ولی از PAN قابل استخراج reliable نیست. جدول کدهای بانک کد موسسه را می‌دهد نه شعبهٔ فیزیکی.

هم‌راستایی با card-to-sheba

هر دو leaf از philosophy یکسان پیروی می‌کنند: Luhn، BIN، سپس honesty. اگر card-to-sheba برای بانکی null است، card-to-account هم برای همان PAN حساب قطعی نمی‌دهد — انتظار symmetry اشتباه است.

سوءاستفاده و مسئولیت

استفاده از «حساب حدسی» برای برداشت از حساب دیگر جرم است؛ ابزار آموزشی FinAI تشویق به inference نمی‌کند. برای dispute بانکی، source of truth statement است.

سؤالات HR و payroll

آیا می‌توان ۲۰۰۰ کارت را یک‌جا به حساب تبدیل کرد؟ FinAI نه — export از بانک. اگر فقط ۴ رقم آخر کارت داریم؟ insufficient — PAN کامل برای Luhn لازم است. حساب از statement با generate-sheba match نکرد؟ branch یا sub-account — بانک.

مسیر آموزشی FinAI برای کارمند تازه‌کار: PAN روی کارت ≠ شماره حساب روی statement. card-to-account این را explicit می‌کند. سپس شبا برای واریز interbank.

در کنار اعتبار کارت و lookup، triad کامل «شناخت بانک بدون حدس حساب» ساخته می‌شود — topical authority از transparency نه fake data.

گسترش workflow برای کاربر عادی

کاربر PAN دارد، می‌خواهد به دوست پول بدهد، دوست شبا داده — card-to-account irrelevant؛ validate-sheba relevant. card-to-account فقط وقتی form misleading «account from card» دارد. redirect mental model: open banking app → account tab → copy → generate-sheba.

برای حساب به شبا اگر leaf exists، forward path when account known. inverse card path closed.

پاسخ به انتظارات نادرست کاربران

بسیاری فکر می‌کنند «کارت همان حساب است» — در UX بانک sometimes یک tab هر دو را نشان می‌دهد ولی numerically distinct. card-to-account educates: Luhn OK + bank name ≠ account number. برای interbank فقط IBAN. برای intra-bank transfer sometimes account enough — rule بانک.

مسیر پیشنهادی FinAI در support doc: validate-card → card-to-account → if null open app → generate-sheba → validate-sheba. هیچ step PAN server-side.

compare کارت به شبا: same policy. topical SEO «کارت به حساب» با honesty rank بهتر از fake algorithm long term.

جمع‌بندی گسترده برای card-to-account

در اکوسystem Iran banking، card-to-account public inverse وجود ندارد؛ FinAI کارت به شماره حساب Luhn و BIN را نشان می‌دهد و account field را empty نگه می‌دارد مگر algorithm audited add شود. user journey: statement → account digits → generate-sheba → validate → paya. HR bulk: bank file not card inference. compare card-to-sheba same honesty. validate-card first. lookup for brand. education reduces mis-payment and fraud hope on magic formula.

لینک‌های مرتبط: ساخت شبا، validate، کارت به شبا، lookup، کدهای بانک.

تفاوت شماره حساب در اپ با عدد روی کارت

در اپ موبایل بانک، часто «شماره حساب» ده تا نوزده رقم بدون فاصله نشان داده می‌شود — این با sixteen رقم PAN یکی نیست. برخی کاربران آخرین چهار رقم هر دو را match می‌بینند و فکر می‌کنند «پس همان است» — correlation partial است نه equality. کارت به حساب این سوءبرداشت را با پیام «استخراج عمومی نیست» هدف می‌گیرد. برای واریز حقوق، HR باید IBAN یا account از onboarding form بگیرد، نه از photocopy کارت. برای واریز دستی بین دوست‌ها، شبا از contact card بانک کافی است — card-to-account در مسیر نیست. اگر form legacy سازمانی «حساب از کارت» دارد، label را به «شماره حساب از statement» تغییر دهید — FinAI tool از redesign فرم جلوگیری نمی‌کند ولی content صادقانه support می‌کند.

متن کامل برای شفافیت الگوریتم

بانک مرکزی و شبکهٔ شتاب الگوریتم یکنواخت «از روی هر کارت، شمارهٔ حساب دفتری را بده» را به عموم منتشر نکرده‌اند؛ هر بانک هستهٔ حسابداری، شعبه، نوع محصول (قرض‌الحسنه، جاری، پس‌انداز)، و نگاشت کارت مجازی را جدا نگه می‌دارد. به همین دلیل کارت به شماره حساب در FinAI بعد از اعتبار Luhn و تشخیص بانک از BIN، فیلد حساب را خالی می‌گذارد مگر روزی vector تست‌شده برای همان bankId اضافه شود. این همان رویکرد کارت به شبا است: جلوگیری از واریز به حساب اشتباه مهم‌تر از پر کردن جعبه با حدس plausible است. مسیر درست: اپ یا پیامک بانک → شماره حساب → ساخت شبا → اعتبارسنجی → پایا. برای حقوق گروهی، فایل IBAN از بانک — نه batch inference از PAN.

هم‌سویی با سیاست card-to-sheba

تیم محصول FinAI برای banking یک خط مشترک دارد: هر conversion از PAN به identifier دیگر (شبا، حساب) بدون مستندات بانک انجام نمی‌شود. کاربر گاهی می‌پرسد «پس چرا validate-card دارید؟» — validate برای typo و BIN است، نه reverse core banking. card-to-account در همان philosophy با کارت به شبا و شبا به کارت هم‌راستاست؛ فقط جهت سؤال فرق می‌کند. وقتی statement را باز کردید، حساب به شبا (در صورت وجود در سایت) مسیر forward است.

پرسش و پاسخ کوتاه

آیا FinAI شماره حساب را از روی کارت حدس می‌زند؟ خیر — مگر الگوریتم audited برای بانک خاص add شده باشد. پس چرا ابزار وجود دارد؟ برای Luhn، نام بانک، و آموزش مسیر درست. چه کنم؟ اپ بانک → حساب → شبا با generate و validate. آیا card-to-sheba بهتر است؟ همان محدودیت — هر دو honesty-first. حریم؟ client-side، PAN به سرور FinAI نرود.

جمع‌بندی

کارت به حساب Luhn و BIN؛ استخراج عمومی حساب نه. منبع رسمی: statement و اپ. سپس شبا و validate و کدهای بانک.