明細の文字列が暗号のように見える理由

明細文字列の基本構造

銀行やカードの明細文字列は主に3つの要素で構成されます：決済事業者プレフィックス（決済を処理した事業者）、加盟店識別名（実際に支払った相手）、そして場合によりサフィックス（店舗所在地コード、会員番号、注文番号など）。国際ブランド（Visa、Mastercard、Amex、Discover）がこの文字列を発行カード会社へ伝送し、銀行がそのまま明細に印字します。

SQ *DAILY GRIND CAFEという表記を例にとると、SQ *はSquareの決済事業者トークンであり、DAILY GRIND CAFEがSquareに登録された店舗名です。「SQ *」という命名規則を知らなければ、無意味な暗号コードのように読めてしまいます。

詳細な解説はこちら： SQ * はSquareの決済表記 — 仕組みの完全な内訳を掲載。

文字数制限による短縮問題

カード決済ネットワークは明細の加盟店表記欄を22〜25文字前後に制限しています（上限はブランドにより異なります）。これは英語でわずか3〜4単語分です。「Verizon Communications Inc.」のような長い社名を収めるため、ネットワーク側で「VZWRLSS*」のように機械的に切り詰められ、利用者にとって意味不明な社内用コードになってしまいます。

この文字切り詰め（トランケーション）こそが、身に覚えのない請求が生じる最大の原因です。正式名称ならすぐに分かるサービスも、22文字に短縮されスペースが削除されると認識できなくなります。

実例：ACHMA VISBは「Automated Clearing House Merchant Authorization Visa（自動決済機関加盟店承認Visa）」という5つの単語がわずか8文字に圧縮されたものです。

決済代行トークンと実際の店舗名

加盟店が決済代行業者の端末やシステム（Square、Toast、PayPal、Stripe、CCBillなど）を利用している場合、明細にはまず決済会社の名前が表示され、アスタリスク等の区切り文字を挟んで店舗名が続きます。これが明細における最も大きな混乱の原因です。

TST* RIVERSIDE DINERの場合、決済代行はToast（TST*）で店舗名はRiverside Dinerです。「PAYPAL *NOVELTYSHOP」なら決済代行はPayPalで販売者はNovelty Shopです。区切り文字のルールを知らないと、店舗との結びつきが見えなくなってしまいます。

この形式を採用している代表的な決済事業者： SQ* (Square), TST* (Toast), PAYPAL*, PADDLE.NET* など。

口座引き落とし（ACH）とカード決済の違い

口座振替や銀行間電送（ACH）は、カード決済とは異なる命名体系を持ちます。ACHの明細表記は店舗ではなく送金元金融機関（ODFI）から発行されるため、親しみやすい店舗名ではなく銀行内部コードや照会番号が記載されることが多くなります。

IRS TREAS 310 TAX REFは米国財務省からのACH税金還付です。「310」はSECコード（ACH取引の種別）で、「TAX REF」は目的区分です。これは請求ではなく入金ですが、コードだらけの形式であるため多くの人が検索しています。

詳しくはIRS TREAS 310 の解説および銀行コード・口座振替カテゴリをご覧ください。

金融機関によって表記が異なる理由

加盟店からカードネットワークに送られる文字列は1つですが、各銀行が独自のフォーマットに加工します。Chaseは取引種別（PURCHASE や DEBIT）を追加し、Bank of Americaは大文字小文字を変換し、Wells Fargoは余分な文字を削除します。そのため、同じカフェでの支払いが異なる銀行の明細書では全くの別店舗に見えることがあります。

当サイトの Chase, Bank of America, Wells Fargo, Citi、および USAA 各銀行ハブで、これらの詳細な表記規則を解説しています。

あらゆる明細行を自分で解読する方法

身に覚えのない請求がある場合は、まずステップ別対処ガイドブックをお読みください。順を追って特定する手順を解説しています。

また、以下の専用ツールを使って難解な文字列を分析できます：

• 明細デコーダー — 文字列を貼り付けて不要なコードを自動除去。
• 請求元電話番号検索 — 明細内に電話番号が含まれている場合。
• オーソリ保留か確定請求か？ — 一時的な保証枠か実際の請求かを判定。
• 未登録明細の報告 — まだ掲載されていない文字列を編集部へ提供。