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 提供两个工具和一个资源，这就是它的全部功能范围： fetch-transactions、two-factor-auth，以及用于报告各银行所需凭据字段的 banks://list 资源。下方第 3 至第 5 步中的所有操作，都由 Agent 对返回的数据执行。不要指望服务会进行分类、汇总或导出。

第 2 步：获取交易记录

获取所需期间的交易数据：

• 明确传入开始日期。fetch-transactions 在省略 startDate 时会默认使用今天，因此几乎不会返回任何数据。查询“上个月”时，从该月第一天开始，并将结果筛选到该月（脚本的 --from / --to），因为抓取会一直进行到今天，且信用卡抓取器还会返回下一个账单周期的数据
• 保持关闭 combineInstallments（这是服务端默认值）。开启后，库只保留每笔消费的第一期分期，因此查看多个月的数据时会少算
• 历史数据：库的 README 说明，大多数抓取器最多支持回溯一年（Discount 和 Mercantile 最多回溯一年减一天，Yahav 最多回溯六个月）。较早的开始日期不算错误；例如，Hapoalim 会在不提示的情况下将日期调整到允许的最早日期。请如实说明实际返回的数据。
• 包括：银行账户和信用卡交易

请读取库实际返回的字段。 fetch-transactions 返回库的抓取结果：一个包含 accounts 的对象，每个账户中都有 txns。交易记录没有 amount 字段，而是包含 chargedAmount（本期计费金额）和 originalAmount（以 originalCurrency 计价的消费原始金额）。对于信用卡分期消费（type: "installments"，תשלומים），已完成交易的 chargedAmount 是单期金额，因此查看月度数据时应使用它，绝不要累加 originalAmount。installments 对象（number、total）表示尚未履行的付款承诺：金额约为 chargedAmount 乘以（total 减去 number），如果用户询问某笔消费还欠多少，值得告知这一点。每条记录还包含 status（completed 或 pending）以及两个日期：date 和 processedDate（计费日期）。date 通常是消费日期，但对于一笔消费的第 N 期分期，库会将它调整到该期所在月份。选择一个字段用于归属月份，并说明选择的是哪个字段，因为月末的信用卡消费通常会在下个月计费。

待处理记录不可靠。 待处理的 Visa Cal 分期消费可能会以完整消费金额出现，Max 的待处理记录可能会出现 chargedAmount 为 0 的情况，而 Visa Cal 的待处理退款可能会出现负的 chargedAmount，但其原始金额为正数。脚本会处理这三种情况（完整金额的记录和金额未知的记录会列出，但不会计入总和；退款沿用原始金额的符号），手动计算时也必须同样处理；已结账月份的统计或提供给会计师的导出文件则应排除待处理记录。

银行 CSV 或 Excel 导出文件需要先规范化，脚本才能读取。 脚本读取 JSON，因此请先转换文件。以色列常见的导出文件通常不是 UTF-8 编码（常见的是旧版希伯来语 Windows 代码页），日期格式为日/月/年，借方和贷方分别放在 חובה / זכות 列中，而不是放在一个带正负号的金额列中；此外，文件还可能包含滚动余额（יתרה）列（它不是交易记录），以及需要删除的表头和页脚行。将这两列合并为一个带正负号的 amount（借方为负，贷方为正）；空单元格不等于零，脚本遇到空单元格会停止。信用卡账单应使用计费金额（סכום חיוב），而不是交易金额（סכום עסקה）：交易金额是分期消费的全额。一些信用卡导出文件会将扣款显示为正数；如果所有记录都是正数，脚本会发出警告。

步骤 3：分类和分析

应用以色列特定分类：

类别	希伯来语	示例
住房	דיור (diur)	房租、arnona、vaad bayit
日常采购	מזון (mazon)	Shufersal、Rami Levy、Victory
交通	תחבורה (tahaburah)	Rav-Kav、燃油、Gett
公用事业	שירותים (shartuim)	Electric Company、Mekorot、Bezeq
医疗保健	בריאות (briut)	Kupat Cholim、药房
教育	חינוך (chinuch)	Gan、学校、课程
娱乐	בילוי (bilui)	餐厅、电影院、流媒体
保险	ביטוח (bituach)	健康、汽车、房屋保险
储蓄	חיסכון (chisachon)	养老金、keren hishtalmut

不要将转入储蓄的钱计为支出。 养老金缴款、keren hishtalmut 存款、gemel 转账、银行存款（פיקדון）或证券购买，都是用户自己的钱从一个口袋转到另一个口袋，并非支出。储蓄规则会匹配这些词语，以及出现在直接扣款中的养老金产品和基金管理公司名称，即使其中没有“养老金”一词（מקפת、אלטשולר、ילין לפידות、מנורה מבטחים、מיטב דש）。由于 מיטב、מבטחים 和 פיקדון 也可能是商店名称中的普通词语或瓶罐押金，这三个词只有在独立出现，或与基金、存款相关词语一起出现时，才计为储蓄（מיטב גמל、הפקדה לפיקדון、פיקדון שקלי）。规则未能识别的基金名称会归入“其他”，因此请询问其中金额较大的月度扣款。脚本会报告总支出（不含储蓄）、转入储蓄和总流出（前两项之和）。若把总流出金额说成“您花了 X”，就会高估用户的支出，高估的金额等于用户存下的钱；在有养老金扣款的以色列工资单上，这可不是一笔小数目。

自有账户间转账和税款也会单独列出。 如果某条记录列出了同一份抓取数据中的另一个账户（完整账号，或作为独立数字出现的末六位），或者列出了汇入用户自有外汇账户的外币购买（המרת / רכישת מט"ח），则会将转账两端都报告为“自有账户间转账”，且不计入任何其他金额。这只有在两个账户都已抓取且银行打印了账号时才有效，因此，在将“其他”中的大额转账（העברה）认定为支出前，请先询问用户。所得税、增值税（מע"מ）、预缴税款（מקדמות מס）和 Bituach Leumi 会归入“税款和 BL”类别（普通的 מקדמה，即付给供应商的预付款，不属于此类）：它们仍计入总支出，因为钱确实已经流出，但这些是汇缴款项，不是消费，绝不能算作业务费用。转给他人的款项（Bit、PayBox、转给他人的银行转账）无法被识别，会归入“其他”。

不要将信用卡消费重复计算。 银行账户会将每月信用卡账单显示为一条记录（ישראכרט、מקס איט、כאל、לאומי קארד 等），而信用卡公司的自有数据会逐笔列出相同的消费。脚本会将银行侧的这条记录单独列为 Card Bills，不计入总支出或总流出。如果用户只连接了银行而没有连接信用卡公司，这条记录就是其信用卡消费的唯一记录：请自行将其加到支出中，并说明这是一笔无法拆分的总额。不同银行对此类记录的表述各不相同，因此，当“其他”中出现一笔金额较大且数额整齐的月度扣款时，请询问用户确认哪条是信用卡账单。只有当 “Max” 是完整描述时才会匹配，因为 Max Brenner 和 Max Stock 是商店。 **分类基于关键词匹配，因此在将其作为事实呈现前，请先核查。**脚本会将商户描述与希伯来语和英语关键词模式进行匹配，并分别为两种文字设置边界条件，确保模式匹配的是完整词语，而非片段：希伯来字母前后查找边界可确保 פז 不会在 פזגז 中触发；拉丁字母两侧的边界则可确保 hot 不会在 Hotel 或 PHOTO 中触发。脚本还会为每个词元生成去掉希伯来语单字母前缀的副本并进行匹配，因此 הפקדה לפנסיה 会匹配到储蓄规则；如果不这样处理，边界条件就会阻止最自然的希伯来语表达方式，导致养老金存款被归为保险支出。

**误分类仍然存在，这是一类失败，而不是一个固定列表。**任何包含某个模式词元（且该词元是真实词语）的希伯来语商户字符串都会匹配到它：名为 קניון מגדל שלום 的购物中心会匹配到保险公司 מגדל，而 מלון הוט 会匹配到有线电视公司 הוט。之所以列出这两个例子，是因为它们很常见，并非因为只有这两个例子。应向用户展示类别明细并邀请他们纠正，而不是断言这些就是他们的支出；在用户看到明细行之前，绝不要把类别总额说成关于该用户的事实。

**流入资金不会抵扣支出，也不会提供净额视图。**任何正数金额，无论是退款、冲销、工资、转入款项还是贷款提款，都会单独列在 Credits In 行中，并从所有类别总额和百分比中排除。数据无法区分退款和工资，因此用该类别计算出的“净额”会将用户的工资从支出类别中扣除，并得出负总额。如果用户希望退款抵扣支出，请手动对他们指定的具体明细行进行净额计算。请先检查数据源的正负号规则：如果数据源将每笔记录都报告为正数，支出总额就会为空。

步骤 4：呈现洞察

脚本会生成类别拆分和主要商户。此列表中的其他内容都需要由 Agent 根据交易记录自行分析，因此在断言某种规律前，请先检查明细行。对于定期扣款，请查找同一收款方在相隔约一个月时出现的相近金额，并说明每笔扣款是银行直接扣款（显示在银行账户中），还是卡片上的定期扣款（显示在发卡公司的数据中），因为用户需要在不同地方取消它们。 请提供：

1. 按类别汇总的月度支出
2. 支出最高的 10 家商户
3. 月环比趋势
4. 识别出的定期扣款
5. 标记出的异常交易

步骤 5：导出税务资料（如有需要）

为用户的会计师准备交易记录，而不是代为报税：

• 按用户的说明区分业务支出和个人支出，并询问任何含糊不清的项目
• 仅纳入已完成的记录，并按 processedDate（扣款实际成功的日期）选择时段，除非会计师另有要求：运行脚本时使用 --exclude-pending --date-field processedDate。待处理记录仍可能发生变化
• 将用户表示属于业务采购的记录标记为待会计师审核的候选项。采购的增值税能否抵扣，取决于是否有有效税务发票以及企业情况，银行记录无法体现这些信息，因此不要计算或声称可以抵扣
• 将税款和 Bituach Leumi 款项、储蓄存款及本人账户间转账排除在业务支出清单之外，并单独列出供会计师查看。自雇用户的养老金和 keren hishtalmut 存款会影响其税务状况，因此应予以标记，但不要进行任何计算
• 将混合用途项目（汽车、电话、家庭办公室）标记为待会计师分摊；不要自行拆分
• 导出 CSV，包含以下列：date、processedDate、description、chargedAmount、currency、originalAmount、分期编号和总期数、category。使用带字节顺序标记的 UTF-8 保存，以便 Excel 正确显示希伯来语。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），并输出分类后的支出汇总。使用 --from / --to 按时段筛选，在 --date-field date（默认值）或 processedDate 上筛选；库中的时间戳按以色列时间读取，--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 枚举中的 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 银行代码、库的 scraper ID 以及 MCP 服务覆盖情况说明。设置银行连接或排查缺失账户时请查阅。

参考链接

来源	URL	检查内容
israeli-bank-scrapers（npm 库）	https://github.com/eshaham/israeli-bank-scrapers	支持的银行、重大变更和 scraper 限制的权威列表
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	基于 Docker 的 MCP，内置支出分析和 SQLite 存储。最后推送于 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 号通函中的 v6 文本	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	持牌提供商名录；如果用户想使用官方聚合服务而非 scraper，可查阅此名录
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 和登录字段，按驼峰命名转为大写下划线格式生成：例如，银行 ID 为 leumi、字段为 username 时，变量名为 LEUMI_USERNAME；银行 ID 为 otsarHahayal、字段为 username 时，变量名为 OTSAR_HAHAYAL_USERNAME。不要猜测某家银行需要哪些字段，应查询 banks://list 资源，因为各家银行的字段结构不同：Hapoalim 的字段是 userCode，因此对应的变量是 HAPOALIM_USER_CODE。变量缺失时不会返回有用的错误信息：服务只会返回通用错误 BANK_SCRAPER_ERROR，因此在怀疑银行出问题之前，先将 banks://list 的输出与环境变量进行核对。
• OneZero 需要长期双重验证令牌，而 israeli-bank-mcp 无法获取该令牌：它的 two-factor-auth 工具每次调用都会新建一个抓取器，因此 get-token 调用无法看到 trigger 调用创建的状态，会失败并提示「triggerOtp was not called」；而 trigger 无论实际发生什么，都会报告「2FA code sent」。请直接使用该库获取令牌：按照其 README 所示，在同一个抓取器对象上依次调用 triggerTwoFactorAuth（电话号码须以 + 开头）和 getLongTermTwoFactorToken。将该令牌视为密码。之后，服务要求为 OneZero 的每个登录字段都设置环境变量：ONE_ZERO_EMAIL、ONE_ZERO_PASSWORD、ONE_ZERO_PHONE_NUMBER、ONE_ZERO_OTP_LONG_TERM_TOKEN（令牌）以及 ONE_ZERO_OTP_CODE_RETRIEVER。令牌存在时，库会忽略最后一个变量，但仍必须将其设为占位值，否则服务只会返回通用错误。
• 绝不要索取用户的银行密码，也不要帮助用户将密码转交给任何其他人，包括其会计师。会计师或簿记员在工作期间使用客户的密码登录客户账户，属于第 60 条行为规范（见 Gotchas）所涉及的行为。某种安排是否适用该条款应由律师判断，因此不要告知用户其会计师是否违法。
• 绝不要打印、记录或重复任何凭据、OTP 或卡号，即使只显示其中一部分也不行；也不要要求用户将其粘贴到对话中。
• 环境变量不是保险库。 两个上游 README 都展示了以明文输入密码的方式：israeli-bank-mcp 将密码写在 MCP 客户端 JSON 配置的 env 块中，il-bank-mcp 则将密码写在 docker compose up 命令行中。这样会导致密码以明文形式保存在磁盘上的配置文件中，或留在命令行形式的 shell 历史记录中。不要照搬这些示例。请告知用户密码会存放在该文件中，并提醒他们将文件排除在任何 git 仓库或同步文件夹之外，且只允许自己的账户读取；如果其环境支持，应在启动时从密码管理器或操作系统钥匙串注入变量，而不是手动粘贴。长期双重验证令牌（OneZero）同样属于凭据。
• 除当前任务所需内容外，不要持久化原始交易数据；若你写入任何内容，应告知用户其存储位置。请注意，il-bank-mcp 会通过 better-sqlite3 将抓取的数据保存在本地 SQLite 数据库中（未声明任何加密层），因此完整的财务历史记录会以可读形式保存在磁盘上，并且按设计会在会话结束后继续留存。
• 交易描述可能会透露医疗服务提供者、政治捐款和宗教机构等信息。请概括交易，不要主动根据用户的消费推断其个人情况。

注意事项

• israeli-bank-scrapers 使用用户自己的用户名和密码登录，并抓取银行网站。它不是以色列官方开放银行渠道，Agent 往往会转而使用英国开放银行接口或通用 PSD2 接口。官方渠道确实存在：《2021 年金融信息服务法》（自 2022 年 6 月 14 日起生效）和以色列银行第 368 号指令，其技术标准以 Berlin Group NextGenPSD2 框架为基础，并针对以色列作了调整。其 API 仅向获得以色列证券管理局许可的服务提供商开放（如果服务提供商本身是银行等受监管机构，则须经该机构自身的监管机构批准），因此个人无法直接调用银行的开放银行 API。
• 如果用户正在构建一个登录他人账户的服务，请立即停止并明确指出这一点。 该法律第 60 条禁止在业务过程中（דרך עיסוק）在线使用客户自己的登录凭据访问其金融数据，并以此向客户提供服务；该法律的罚则规定，违反此条属于犯罪，最高可判处一年监禁。这正是一个基于此抓取工具、面向他人构建的产品会做的事；对此已有许可 API 渠道，计划提供此类服务的人应在开发前寻求法律意见。该条不涉及个人为自己抓取本人账户，因此不要告诉用户个人使用是合法还是非法。
• 各银行的抓取工具各不相同：每个工具都有自己的登录字段和历史记录上限，因此不存在适用于所有以色列银行的统一连接格式。
• Mercantile 和 Otsar HaHayal 在上游库中是独立的抓取工具，尽管它们分别是 Discount 和 FIBI 的子公司。应将它们视为各自独立的连接（每个都有自己的 loginFields 格式）。不要假设 Discount 凭据可以用于 Mercantile，也不要假设 FIBI 凭据可以用于 Otsar HaHayal。
• 交易历史记录的深度由各抓取工具单独设置。该库的 README 说明，大多数工具支持一年，Discount 和 Mercantile 支持一年减一天，Yahav 支持六个月。超出范围的历史数据请求会被截短，而不是拒绝，因此应告知用户实际抓取到的数据，而不是请求的数据范围。
• 库能检索到的内容取决于已安装的版本，因此排查问题前请先检查版本。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 机器人检测问题（两者均已在对应版本中修复）；因此，旧版本在这两家服务商上很可能会直接失败，而不只是返回较少的数据。
• Leumi 外币账户会以对应外币报告交易。切勿将这些交易加到谢克尔总额中；捆绑脚本会将外币交易单独列出，原因正在于此。
• 请检查已安装的抓取工具版本，而不是声明的版本范围。israeli-bank-mcp 声明了 ^6.7.3，因此全新执行 npm install 会解析到当前版本。il-bank-mcp 声明了 ^6.1.4，但提交的 yarn.lock 将版本锁定为 6.1.4，且构建时使用 --immutable，所以每次全新的 Docker 构建都会运行 6.1.4，除非更新锁文件。对于 Max、Isracard 或 6.9.0 之后新增的功能，优先使用 israeli-bank-mcp。
• 待处理的信用卡交易记录不可靠（见步骤 2）：待处理的 Visa Cal 分期付款交易会显示全额价格，而待处理的 Max 交易可能显示扣款金额为 0。
• 以色列银行账户号码包含分行编号（snif）前缀。Agent 可能会使用国际 IBAN 格式验证账号，但以色列境内转账使用本地分行编号＋账号格式。
• 以色列的信用卡账单由独立公司（Isracard、Max、CAL）出具，而非由银行直接出具。Agent 可能会尝试从银行 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 需要在环境中设置长期令牌），或者银行网站响应缓慢或拒绝自动访问 解决方案：对于双重身份验证，请直接使用该库获取长期令牌，具体说明见“处理凭据”（服务端自带的 two-factor-auth 工具无法完成此操作）。对于超时，几分钟后重试一次，然后查看 israeli-bank-scrapers 的 GitHub 问题列表，了解该银行的相关问题。此处未记录银行要求重新获取验证码的频率，因此不要向用户承诺只需操作一次。

错误：BANK_SCRAPER_ERROR

原因：服务端无法归类的任何问题，最常见的是缺少凭据变量或变量名错误 解决方案：将该银行的 banks://list 输出与实际设置的变量进行比较（例如 HAPOALIM_USER_CODE，而不是 HAPOALIM_USERCODE），并检查 node --version。

错误：“Missing credit card transactions”

原因：在以色列，信用卡公司与银行是分开的 解决方案：在 MCP 服务配置中，将信用卡公司（Visa Cal、Max、Isracard）添加为单独的连接。