israeli-bank-connector

イスラエル銀行コネクター

手順

ステップ 1：接続されている銀行を特定する

利用可能な MCP サーバーと、接続されている口座を確認します。

• israeli-bank-mcp：直接スクレイピングによる連携
• il-bank-mcp：永続的な分析が可能な Docker ベースの連携
• MCP がない場合：銀行のウェブサイトから CSV または Excel をエクスポートする方法をユーザーに案内します

どちらの MCP も npx ではインストールできません。 israeli-bank-mcp は npm に公開されておらず、 bin も宣言していないため、npx israeli-bank-mcp の実行を指示するのは誤りで、 失敗します。各リポジトリに記載されている実際の構成は次のとおりです。

サーバー	実際のインストール方法と実行方法
israeli-bank-mcp	リポジトリをクローンし、npm install、npm run build を実行してから、MCP クライアントで node /path/to/israeli-bank-mcp/build/server.js を指定します
il-bank-mcp	Docker を使用します。銀行の環境変数を設定して docker compose up -d を実行し、クライアントから docker compose -f /path/to/il-bank-mcp/docker-compose.yml run --rm -i mcp-server を実行します

israeli-bank-mcp を使う場合は Node 22.22.2 以降を、同梱スクリプトを使う場合は Python 3.9 以降を実行してください（日付フィルターにはタイムゾーンデータが必要です。Windows では pip install tzdata を実行します）。israeli-bank-scrapers は engines.node >= 22.22.2 を宣言しているため、Node 22.0～22.22.1 も要件を満たしていません。古い Node を使っている場合、ライブラリのサポート対象外となるため、まったく動作しないという報告があったら、まず node --version を確認してください。il-bank-mcp は Docker イメージ内に独自の Node を構築するため、ホスト側の Node は関係ありません。

israeli-bank-mcp が公開するのは、2 つのツールと 1 つのリソースだけです。 fetch-transactions、two-factor-auth、および各銀行が必要とする認証情報フィールドを示す banks://list リソースです。以下のステップ 3～5 の内容はすべて、返されたデータを使ってエージェントが行う作業です。サーバーが分類、集計、エクスポートを行うとは想定しないでください。

ステップ 2：取引を取得する

指定した期間の取引データを取得します。

• 開始日を明示的に渡してください。fetch-transactions は省略時に startDate を今日に設定するため、ほとんど何も返りません。「先月」の場合はその月の1日を開始日にし、結果をその月に絞り込んでください（スクリプトの --from / --to）。スクレイピングは今日まで実行され、カードのスクレイパーは次の請求サイクルも返すためです
• combineInstallments はオフのままにしてください（サーバーのデフォルト）。オンにすると、ライブラリは各購入の初回分のみを保持するため、複数月の表示では件数が過少になります
• 取得履歴：ライブラリの README では、ほとんどのスクレイパーが過去1年分までに制限されています（Discount と Mercantile は1年マイナス1日、Yahav は6か月）。それより古い開始日でもエラーではありません。たとえば Hapoalim は、通知なしに開始日を上限まで繰り上げます。返されたデータを報告してください
• 対象：銀行口座とクレジットカードの取引の両方

ライブラリが実際に返すフィールドを読み取ってください。 fetch-transactions は、ライブラリのスクレイピング結果を返します。これは accounts を持つオブジェクトで、各口座に txns が含まれます。取引に amount フィールドはありません。代わりに、chargedAmount（今期の請求額）と originalAmount（originalCurrency での購入価格）があります。クレジットカードの分割払い（type: "installments"、תשלומים）の場合、完了済みの明細の chargedAmount は1回分の金額です。月ごとの表示にはこれを使い、originalAmount を合計しないでください。installments オブジェクト（number、total）は残りの支払い義務を示します。これはおよそ chargedAmount ×（total から number を引いた値）であり、購入に対してまだいくら支払いが残っているかを尋ねられた場合は、ユーザーに伝えると役立ちます。各明細には status（completed または pending）と2つの日付（date と processedDate（請求された日））も含まれます。date は通常、購入日ですが、購入のN回目の分割払いでは、ライブラリがその日付を該当する分割払いの月に繰り下げます。月の割り当てに使うフィールドを1つ選び、どちらを使うか伝えてください。月末近くのカード購入は、通常は翌月に請求されるためです。

信頼性が低いのは保留中の明細です。 保留中の Visa Cal の分割払いは購入額の全額で届くことがあり、Max の保留中の明細は chargedAmount が0で届くことがあり、Visa Cal の保留中の返金は chargedAmount が負の値で、originalAmount が正の値で届くことがあります。スクリプトはこの3つすべてに対応しており（全額の明細や金額不明の明細は合計せずに一覧表示し、返金は元の符号に従います）が、手作業で計算する場合も同じように処理してください。また、締め済みの月や会計士向けのエクスポートでは、保留中の明細を除外してください。

銀行の CSV または Excel エクスポートは、スクリプトで読み取る前に正規化する必要があります。 スクリプトが受け取るのは JSON なので、まずファイルを変換してください。イスラエルで一般的なエクスポートでは、UTF-8 ではなく（従来のヘブライ語 Windows コードページがよく使われます）、日／月／年形式の日付が使われ、借方と貸方が1つの符号付き金額ではなく別々の חובה / זכות 列に分かれ、取引ではない残高（יתרה）列があり、削除すべきヘッダー行やフッター行が含まれます。2つの列を1つの符号付き amount にまとめてください（借方は負、貸方は正）。空欄は0ではなく、空欄があるとスクリプトは停止します。クレジットカードの明細では、取引金額（סכום עסקה）ではなく請求金額（סכום חיוב）を使ってください。取引金額は分割払いの購入価格全額です。一部のカードのエクスポートでは請求が正の数で表示されます。すべての明細が正の数の場合、スクリプトは警告を出します。

ステップ 3：分類と分析

イスラエル固有の分類を適用します。

カテゴリー	ヘブライ語	例
住居	דיור (diur)	家賃、arnona、vaad bayit
食料品	מזון (mazon)	Shufersal、Rami Levy、Victory
交通	תחבורה (tahaburah)	Rav-Kav、燃料、Gett
公共料金	שירותים (shartuim)	電力会社、Mekorot、Bezeq
医療	בריאות (briut)	Kupat Cholim、薬局
教育	חינוך (chinuch)	Gan、学校、コース
娯楽	בילוי (bilui)	レストラン、映画館、ストリーミング
保険	ביטוח (bituach)	医療保険、自動車保険、住宅保険
貯蓄	חיסכון (chisachon)	年金、keren hishtalmut

貯蓄に回したお金を支出として報告しないでください。 年金拠出、keren hishtalmut への預け入れ、gemel への振替、銀行預金（פיקדון）、有価証券の購入は、 ユーザー自身のお金が置き場所を変えただけであり、支出ではありません。貯蓄ルールは、 これらの単語に加え、「年金」という単語を含まない口座振替に記載される年金商品や ファンド運用会社（מקפת、אלטשולר、ילין לפידות、מנורה מבטחים、מיטב דש）にも一致します。 ただし、מיטב、מבטחים、פיקדון は店舗名やボトルのデポジットにも使われる一般的な単語なので、 これら3つは、単独で説明文全体を占める場合、またはファンドや預け入れを示す単語と 組み合わせて使われる場合（מיטב גמל、הפקדה לפיקדון、פיקדון שקלי）に限り、貯蓄として扱います。ルールで検出されないファンド名は「その他」に 分類されるため、そこに大きな月次引き落としがある場合はユーザーに確認してください。 スクリプトは、貯蓄を除く総支出、貯蓄額、総出金額（この2つの合計）を報告します。 出金額を「Xを使いました」と伝えると、ユーザーが貯蓄に回している分だけ支出を 過大に伝えることになります。年金控除があるイスラエルの給与明細では、その金額は 決して小さくありません。

本人名義の振替と税金も別に扱います。 同じデータ取得対象にある別の口座を示す行 （口座番号全桁、または独立した数字として記載された下6桁）、あるいはユーザー自身の 外貨口座への外貨購入（המרת / רכישת מט"ח）は、どちらの側も「本人名義の振替」として報告し、 他のどの数値にも含めません。これは両方の口座のデータを取得していて、銀行が口座番号を 記載している場合にのみ機能するため、「その他」に残った大きな振替（העברה）が支出かどうかを 判断する前に、ユーザーに確認してください。所得税、VAT（מע"מ）、税の前払い （מקדמות מס）、Bituach Leumi は「税金およびBL」カテゴリーに分類します（単なる 前払いを意味する מקדמה や、サプライヤーへの頭金は該当しません）。これらはお金が実際に 出ていくため総支出には含まれますが、消費ではなく納付金であり、事業経費として扱うことは ありません。他人への送金（Bit、PayBox、他人への銀行振込）は検出されず、「その他」に 分類されます。

カードでの購入を二重計上しないでください。 銀行口座には、月々のクレジットカード請求額が 1行（ישראכרט、מקס איט、כאל、לאומי קארד など）で表示され、カード会社のデータには 同じ購入が1件ずつ記載されています。スクリプトは銀行側のその行を独立した カード請求額として扱い、総支出にも総出金額にも含めません。ユーザーが銀行だけを接続し、 カード会社を接続していない場合、その行がカード支出の唯一の記録です。手動で支出に加え、 内訳のない一括金額であることを伝えてください。銀行によってこの行の表記は異なるため、 「その他」の行に大きくて丸い月次引き落としがある場合は、どの行がカード請求額かユーザーに 確認してください。「Max」だけの表記は、説明文全体がそれだけの場合に限り一致します。 Max Brenner と Max Stock は店舗名だからです。 分類はキーワード照合によるものなので、事実として提示する前に確認してください。 スクリプトは、ヘブライ語と英語のキーワードパターンを使って加盟店の説明を照合します。どちらの文字体系でもパターンの両側に境界条件を設けているため、部分文字列ではなく単語全体に一致します。たとえば、ヘブライ文字の後読み条件により、פזがפזגזの中で誤って一致することはありません。また、ラテン文字の両側にも境界条件を設けているため、hotがHotelやPHOTOの中で一致することもありません。ヘブライ語の1文字の接頭辞には、各トークンの接頭辞を取り除いたコピーも照合することで対応しています。そのため、הפקדה לפנסיהは貯蓄のルールに一致します。この処理がなければ、境界条件によって最も自然なヘブライ語の表現が一致せず、年金の預け入れが保険の支出として分類されてしまいます。

誤分類は残ります。これは失敗の一種であり、固定されたリストではありません。 実際の単語としてパターントークンを含むヘブライ語の加盟店名は、どれも一致します。たとえば、קניון מגדל שלוםというショッピングモールは保険会社のמגדלに一致し、מלון הוטというホテルはケーブル会社のהוטに一致します。この2つを挙げているのはよくある例だからであり、これだけに限られるわけではありません。カテゴリーの内訳をユーザーに示し、支出だと断定するのではなく修正を促してください。また、ユーザーがその根拠となる明細を確認していない限り、カテゴリーの合計をその人についての事実として提示しないでください。

入金は支出と相殺されず、純額の表示もありません。 返金、取消処理、給与、振込入金、借入金の実行など、金額が正の明細はすべて、それぞれCredits Inの行に表示され、すべてのカテゴリー合計と割合から除外されます。データから返金と給与を区別できないため、その区分を使って算出した「純額」は、ユーザーの給与を支出カテゴリーから差し引き、合計をマイナスとして表示してしまいます。ユーザーが返金との相殺を希望する場合は、指定された明細だけを手作業で相殺してください。まず、データソースの符号規則を確認してください。すべての明細を正の金額として報告するフィードでは、支出の合計が空になります。

ステップ 4：インサイトを提示する

スクリプトはカテゴリー別の内訳と主要な加盟店を出力します。このリストにあるそれ以外の内容は、取引明細を基にエージェントが独自に作成するものなので、傾向を断定する前に明細を確認してください。定期的な請求を調べるには、同じ支払先に対して、約1か月の間隔で同程度の金額が請求されていないか確認してください。また、それぞれが銀行口座に表示される銀行口座からの口座振替なのか、カード会社のデータに表示されるカードの継続請求なのかも記載してください。ユーザーがそれぞれ異なる場所で解約するためです。 以下を提示してください：

1. カテゴリー別の月間支出の概要
2. 支出額が多い加盟店トップ10
3. 前月比の傾向
4. 特定された定期請求
5. フラグが付けられた異常な取引

ステップ 5：税務申告用のエクスポート（依頼があった場合）

申告書を作成するのではなく、ユーザーの会計士に渡す取引データを準備します。

• ユーザーが特定した事業経費と個人経費を分け、不明確な項目については確認します
• 完了した項目のみを含め、会計士から別の指示がない限り、processedDate（実際に引き落としが処理された日付）で期間を選択します。スクリプトは --exclude-pending --date-field processedDate を指定して実行します。保留中の項目は後から変更される可能性があります
• ユーザーが事業用の購入だと言った項目には、会計士による確認対象の候補として印を付けます。購入に対する VAT が控除対象となるかは、有効な税務インボイスの有無と事業の内容によって異なり、銀行明細からは判断できないため、控除額を計算したり、控除を申請したりしないでください
• 税金や Bituach Leumi への支払い、貯蓄預金、本人間の振替は事業経費の一覧に含めず、会計士向けに別途記載します。自営業者の年金と keren hishtalmut の預金は税務上重要なため、金額などを計算せずにその旨を記載します
• 用途が混在する項目（車、電話、自宅オフィス）は会計士による按分の対象として印を付けます。独自に按分しないでください
• date、processedDate、description、chargedAmount、currency、originalAmount、分割払いの回数と総回数、category の各列を含む CSV をエクスポートします。Excel でヘブライ語が正しく表示されるよう、バイトオーダーマーク付きの UTF-8 で保存します。MCP サーバーも同梱スクリプトも、会計ソフトへのインポート形式やこの CSV は作成しません。--output-json の出力から作成してください

例

例 1：月間支出の概要

ユーザーの依頼：「1 月の支出の内訳を見せて」 結果：カテゴリ別の NIS 金額、主な加盟店、12 月との比較を含む分類済みの内訳。

例 2：サブスクリプションの確認

ユーザーの依頼：「定期的に支払っているものは何ですか？」 結果：検出された定期的な請求の一覧。金額、頻度、節約できる可能性のある項目の提案を含みます。

例 3：税務経費のエクスポート

ユーザーの依頼：「会計士向けに事業経費をエクスポートして」 結果：ユーザーが事業用として指定した取引の CSV。会計士が税務インボイスを確認する必要のある項目についての注記も含みます。

同梱リソース

スクリプト

• scripts/categorize_transactions.py。Shufersal、Rami Levy、Rav-Kav など、イスラエル特有の加盟店パターンに基づいて、イスラエルの銀行取引を支出カテゴリ別に分類します。{description, amount} オブジェクトの JSON 配列（CSV 形式）、または fetch-transactions が返す israeli-bank-scrapers のスクレイピング結果（accounts[].txns[]。chargedAmount を読み取ります）を受け付け、分類済みの支出概要を出力します。--date-field date（デフォルト）または processedDate に対して --from／--to（YYYY-MM-DD）を指定すると、期間で絞り込めます。ライブラリのタイムスタンプはイスラエル時間として読み取られ、--period はラベルとしてのみ使われます。銀行側のクレジットカード請求額と本人間の振替は、Total Spending および Total Outflow の対象外として個別に報告され、カードの明細項目に加算されることはありません。外貨建ての項目は別に記載され、NIS の金額には決して合算されません。保留中の項目と分割払いの項目は集計対象となり、印が付けられます。ただし、全額が保留中の分割払い購入と、金額不明の保留中の項目は、合算せずに記載されます。金額が欠落、空欄、null、または数値以外の取引があると、ゼロとして読み取るのではなく、エラーで実行が停止します。デモを実行するには python3 scripts/categorize_transactions.py --example を、実データを処理するには python3 scripts/categorize_transactions.py --json transactions.json を実行します。機械可読な出力にするには --output-json を追加します。

参考資料

• references/spending-categories.md：イスラエルの支出カテゴリの定義と、各カテゴリのヘブライ語表記および一般的な加盟店の例（住宅／diur、食料品／mazon、交通／tahaburah、公共料金／shartuim など）が記載されています。分類ルールをカスタマイズする場合や、ユーザーにカテゴリを説明する場合に参照してください。
• references/supported-banks.md：israeli-bank-scrapers の CompanyTypes enum に含まれる14行の銀行（Hapoalim、Leumi、Discount、Mercantile、Mizrahi-Tefahot、FIBI、Otsar HaHayal、Pagi、Union、Yahav、Massad、OneZero、Behatsdaa、Beyahad Bishvilha）と4社のクレジットカード会社（Visa Cal、Max、Isracard、Amex）の全リストです。BOI 銀行コード、ライブラリのスクレイパー ID、MCP サーバーの対応状況に関する注記が記載されています。銀行接続の設定や、口座が見つからない場合のトラブルシューティングに参照してください。

参考リンク

情報源	URL	確認する内容
israeli-bank-scrapers（npm ライブラリ）	https://github.com/eshaham/israeli-bank-scrapers	対応銀行、互換性を損なう変更、スクレイパーの制限に関する信頼できる情報
npm 上の israeli-bank-scrapers	https://registry.npmjs.org/israeli-bank-scrapers	現行リリースと engines.node の最低要件。最新バージョンは 6.12.2（2026-09-29）、Node >= 22.22.2
israeli-bank-mcp（Motti Bechhofer）	https://github.com/mottibec/israeli-bank-mcp	より新しい MCP ラッパー（最終プッシュは2026年5月）。npm では公開されていません。クローンしてビルドしてください。README の銀行一覧は古いですが、サーバーはライブラリの SCRAPERS マップを反復処理するため、インストール済みライブラリが対応する銀行をすべてカバーします
il-bank-mcp（Gilad Lekner）	https://github.com/glekner/il-bank-mcp	支出分析機能と SQLite ストレージを内蔵した、Docker ベースの MCP。最終プッシュは2025年6月です。コミット済みの yarn.lock では israeli-bank-scrapers が 6.1.4 に解決され、Dockerfile は yarn install --immutable でインストールするため、新規ビルドでは 6.1.4 が取得されます。これは Max と Isracard の修正を含む 6.7.9 および 6.7.10 より古く、6.9.0 以降の変更も含まれていません
Bank of Israel：消費者からの問い合わせ	https://www.boi.org.il/en/information-and-service-to-the-public/consumer-enquiries-and-inspections/	BOI の公式一般問い合わせ窓口、銀行のカスタマーサービス、苦情申し立ての手順
Bank of Israel：指令368（オープンバンキング）、通達2778の第6版	https://www.boi.org.il/media/k1dl4le3/2778.pdf	公式のオープンバンキング標準。Berlin Group NextGenPSD2 フレームワークをイスラエル向けに適合させたもので、API アクセスは認可を受けたプロバイダーに限られます
金融情報サービス法（2021年、公式官報）	https://fs.knesset.gov.il/24/law/24_lsr_611801.pdf	金融情報サービスプロバイダーの認可、および顧客のログイン認証情報を用いたアクセスに関する第60条
Israel Securities Authority：認可を受けた金融情報サービスプロバイダー	https://www.new.isa.gov.il/nav-index/supervised-api/supervised-by-isa	スクレイパーではなく公式のアグリゲーターを利用したい場合に確認する、認可プロバイダーの登録簿
Bank of Israel：決済システムへのアクセス	https://www.boi.org.il/en/economic-roles/supervision-and-regulation/payment-systems-oversight/access-to-payment-systems/	決済システムへのアクセス条件。注：2026年8月27日にブラウザーで表示したところ、最終更新日が2023年11月19日のランディングページで、識別コードの一覧はありませんでした。そのため、銀行コードの出典として引用しないでください

認証情報と取引データの取り扱い

このスキルは、イスラエルの銀行の実際のユーザー名、パスワード、ワンタイムコードを受け取り、完全な取引履歴を生成するスクレイパーを利用します。どちらも機密情報として扱ってください。

• 認証情報はMCPサーバー自体の設定または環境変数に保存し、チャット、作成するファイル、ユーザーにそのまま返すコマンドには決して含めないでください。
• israeli-bank-mcp は環境変数から認証情報を読み込み、ツールの引数からは意図的に読み込みません。これにより、認証情報がLLMの会話履歴に残らないようにしています。環境変数名は、銀行IDとログインフィールドをcamelCaseから大文字のスネークケースに変換して作られます。そのため、leumi と username の組み合わせは LEUMI_USERNAME、otsarHahayal と username の組み合わせは OTSAR_HAHAYAL_USERNAME になります。銀行によってフィールドの形式が異なるため、推測せずに banks://list リソースで、各銀行に必要なフィールドを確認してください。たとえばHapoalimのフィールドは userCode なので、環境変数は HAPOALIM_USER_CODE です。環境変数が設定されていなくても、役立つエラーは表示されません。サーバーは汎用的な BANK_SCRAPER_ERROR だけを返すため、銀行側に問題があると考える前に、banks://list の出力と環境変数を照合してください。
• OneZeroでは長期間有効な2要素認証トークンが必要ですが、israeli-bank-mcp では取得できません。two-factor-auth ツールは呼び出すたびに新しいスクレイパーを作成するため、get-token の呼び出し時には trigger の呼び出しで作成された状態が存在せず、"triggerOtp was not called" というエラーで失敗します。一方、trigger は実際の処理にかかわらず "2FA code sent" と報告します。ライブラリを直接使い、同じスクレイパーオブジェクトで triggerTwoFactorAuth（+ で始まる電話番号を指定）を呼び出してから getLongTermTwoFactorToken を呼び出し、READMEの手順に従ってトークンを取得してください。トークンはパスワードとして扱ってください。続いて、サーバーではOneZeroのすべてのログインフィールドに環境変数を設定する必要があります。ONE_ZERO_EMAIL、ONE_ZERO_PASSWORD、ONE_ZERO_PHONE_NUMBER、ONE_ZERO_OTP_LONG_TERM_TOKEN（トークン）、および ONE_ZERO_OTP_CODE_RETRIEVER が必要です。トークンが設定されている場合、ライブラリは ONE_ZERO_OTP_CODE_RETRIEVER を無視しますが、プレースホルダーを設定しておかなければ、サーバーは汎用的なエラーだけを返します。
• ユーザーの銀行パスワードを他人に渡すよう求めたり、その方法を案内したりしないでください。会計士を含め、誰に対しても渡してはいけません。会計士や簿記担当者が業務上、顧客のパスワードで顧客の口座にログインする行為については、「Gotchas」で説明されているconduct section 60が該当します。特定の取り決めに適用されるかどうかは弁護士に確認すべき問題なので、ユーザーの会計士が法律に違反している、または違反していないと伝えてはいけません。
• 認証情報、OTP、カード番号は、一部であっても表示、ログ記録、再掲しないでください。また、会話に貼り付けるようユーザーに求めないでください。
• 環境変数は保管庫ではありません。 どちらの上流READMEにも、パスワードを平文で入力する方法が記載されています。israeli-bank-mcp ではMCPクライアントのJSON設定の env ブロックに、il-bank-mcp では docker compose up コマンドラインに入力します。この方法では、パスワードが設定ファイル上で読み取り可能になり、コマンドライン形式ではシェル履歴にも残ります。これらの例をそのまま使わないでください。パスワードがそのファイルに保存されることをユーザーに伝え、ファイルをGitリポジトリや同期フォルダーに置かず、本人のアカウントだけが読み取れるようにしてください。また、環境が許す場合は、パスワードを直接貼り付けるのではなく、パスワードマネージャーやOSのキーチェーンから起動時に環境変数を設定してください。長期間有効な2要素認証トークン（OneZero）も認証情報です。
• 現在のタスクに必要な範囲を超えて、生の取引データを保存しないでください。作成したファイルの保存場所もユーザーに伝えてください。il-bank-mcp はスクレイピングしたデータをローカルのSQLiteデータベースに保存します（better-sqlite3 を使用し、暗号化レイヤーは宣言されていません）。そのため、金融履歴の全体が読み取り可能な形式でディスクに保存され、設計上、セッション終了後も残ります。
• 取引の説明から、医療提供者、政治献金、宗教施設などが分かる場合があります。要約するにとどめ、支出からその人について推測した内容を自発的に述べないでください。

注意点

• israeli-bank-scrapers はユーザー自身のユーザー名とパスワードでログインし、銀行のウェブサイトをスクレイピングします。これはイスラエルの公式なオープンバンキングチャネルではなく、エージェントが英国のオープンバンキングや汎用的な PSD2 エンドポイントを使おうとすることがよくあります。公式チャネルは存在します。2021 年金融情報サービス法（2022 年 6 月 14 日施行）と、技術標準がイスラエル向けの調整を加えた Berlin Group NextGenPSD2 フレームワークに基づくイスラエル銀行指令 368 です。その API を利用できるのは、イスラエル証券庁から認可を受けた事業者（または、銀行など、事業者自体が規制対象機関である場合は、その機関を管轄する規制当局から承認を受けた事業者）に限られるため、個人が銀行のオープンバンキング API を直接呼び出すことはできません。
• ユーザーが他人のアカウントにログインするサービスを構築しようとしている場合は、作業を止めてその旨を伝えてください。 同法第 60 条は、事業として（דרך עיסוק）、顧客自身のログイン認証情報を使ってオンラインで顧客の金融データにアクセスし、顧客にサービスを提供することを禁止しており、同法の罰則規定では、違反は最長 1 年の懲役刑が科される犯罪とされています。他人向けにこのスクレイパーを使って構築した製品は、まさにこの行為に該当します。そのための認可済み API の利用経路は存在します。このようなサービスを構築する予定がある人には、着手前に法律の専門家に相談するよう伝えてください。この条項は、自分自身のアカウントで自分のためにスクレイパーを実行する人については定めていないため、個人利用が合法とも違法ともユーザーに伝えないでください。
• スクレイパーは銀行ごとに異なります。ログインフィールドも履歴の上限もそれぞれ異なるため、イスラエルのすべての銀行に対応する共通の接続形式はありません。
• Mercantile と Otsar HaHayal は、それぞれ Discount と FIBI の子会社ですが、上流ライブラリでは別個のスクレイパーです。それぞれ独自の接続として扱ってください（loginFields の形式もそれぞれ異なります）。Discount の認証情報で Mercantile に接続できる、または FIBI の認証情報で Otsar HaHayal に接続できると想定しないでください。
• 取引履歴の取得範囲はスクレイパーごとに設定されています。ライブラリの README では、ほとんどのスクレイパーは 1 年、Discount と Mercantile は 1 年から 1 日を引いた期間、Yahav は 6 か月とされています。これより古いデータをリクエストすると拒否されずに期間が切り詰められるため、指定した期間ではなく、実際に取得されたデータをユーザーに伝えてください。
• ライブラリが取得できる内容はインストール済みバージョンによって異なるため、デバッグする前にバージョンを確認してください。6.9.0（2026-07-22）では Leumi の普通預金口座と Max のクレジットカード残高が追加され、6.10.0 では Isracard のクレジットカード残高が追加され、6.12.0 では Leumi の外貨口座が追加されました。最新リリースは 6.12.2（2026-09-29）で、Mizrahi による銀行のパスワード変更ページの検出が修正されています。これらのデータが見つからないとユーザーから報告された場合、スクレイピングの失敗と決めつける前に、インストール済みバージョンを確認してください。6.7.9 より前のリリースでは Max のログインページに関する不具合があり、6.7.10 より前のリリースでは Isracard のボット検出に関する問題がありました（どちらもリリースノートによると、それぞれのバージョンで修正済みです）。そのため、古いインストールでは、これら 2 つの事業者についてデータが一部返されるだけでなく、処理自体に失敗する可能性が高くなります。
• Leumi の外貨口座の取引は、その通貨で報告されます。シェケルの合計に加算しないでください。同梱のスクリプトで外貨建ての明細を別に表示しているのはこのためです。
• 宣言された範囲ではなく、インストール済みのスクレイパーバージョンを確認してください。israeli-bank-mcp は ^6.7.3 を宣言しているため、新規の npm install では現行リリースが解決されます。il-bank-mcp は ^6.1.4 を宣言していますが、6.1.4 に固定する yarn.lock をコミットしており、--immutable を指定してビルドするため、ロックファイルを更新しない限り、新規の Docker ビルドでも常に 6.1.4 が使われます。Max、Isracard、または 6.9.0 以降で追加された機能を使う場合は、israeli-bank-mcp を優先してください。
• 保留中のカード明細は信頼できません（ステップ 2 を参照）。保留中の Visa Cal の分割払い購入では全額が記載され、保留中の Max の明細では請求額が 0 と記載されることがあります。
• イスラエルの銀行口座番号には、支店番号（snif）が先頭に含まれます。エージェントが口座番号を国際的な IBAN 形式で検証することがありますが、イスラエル国内の振込では現地の支店番号＋口座番号の形式が使われます。
• イスラエルのクレジットカード明細は銀行ではなく、別会社（Isracard、Max、CAL）が発行します。エージェントはカード会社の API ではなく、銀行の API からクレジットカードデータを取得しようとすることがあります。

トラブルシューティング

israeli-bank-mcp では、スクレイピングに失敗すると {"error": "<errorType>", "message": "Bank scraper error occurred"} が報告されます。errorType はライブラリが定める値のいずれかです。認証情報変数が設定されていない場合を含め、それ以外の失敗はすべて汎用の BANK_SCRAPER_ERROR として返されます。

エラー：INVALID_PASSWORD、CHANGE_PASSWORD、または ACCOUNT_BLOCKED

原因：銀行がログインを拒否した、銀行のサイトでパスワードを変更する必要がある、またはアカウントがブロックされた 解決策：処理を停止してください。自動的に再試行しないでください。ログインの失敗を繰り返すとアカウントがブロックされる可能性があり、ACCOUNT_BLOCKED はライブラリが報告するエラーの一つです。CHANGE_PASSWORD の場合、ユーザーはまず銀行のウェブサイトにログインし、その後、環境変数を更新します。ACCOUNT_BLOCKED の場合、ユーザーは銀行に問い合わせます。

エラー：TWO_FACTOR_RETRIEVER_MISSING または TIMEOUT

原因：サーバーが取得できないワンタイムコードがログインに必要（サーバーがコードの入力を求めない。OneZero では環境変数に長期トークンが必要）、または銀行のサイトの応答が遅い、もしくは自動アクセスを拒否した 解決策：2 要素認証の場合は、「認証情報の取り扱い」で説明されているように、ライブラリを直接使って長期トークンを取得してください（サーバー独自の two-factor-auth ツールでは完了できません）。タイムアウトの場合は数分後に一度だけ再試行し、その後、その銀行に関する israeli-bank-scrapers の GitHub の課題を確認してください。銀行が新しいコードを要求する頻度はここでは説明されていないため、ユーザーに一度きりの手順だと約束しないでください。

エラー：BANK_SCRAPER_ERROR

原因：サーバーが分類できなかったエラー。多くの場合、認証情報変数が設定されていないか、名前が間違っています 解決策：その銀行の banks://list の出力と、実際に設定されている変数（たとえば HAPOALIM_USERCODE ではなく HAPOALIM_USER_CODE）を照合し、node --version を確認してください。

エラー：「クレジットカードの取引が見つかりません」

原因：イスラエルではクレジットカード会社が銀行とは別です 解決策：クレジットカード会社（Visa Cal、Max、Isracard）を、MCP サーバーの設定で別の接続として追加してください。