读取 Bangkok Bank 手机银行里的存款、卡片与转账记录

打开这款 App，首屏加载的不是单一余额，而是一整个资产组合：存款与 e-Savings 账户、信用卡、共同基金、政府债券、Bualuang 贷款账户，以及覆盖十八种货币的外币存款（FCD）账户。Bangkok Bank 把泰国最老牌的手机银行产品之一建立在这样的广度之上，而对接方往往想要的，正是账户持有人所看到的同一份合并视图 —— 余额、对账单、持仓 —— 按计划定时拉取进自己的系统。这份简报讲的就是这份读取，而我们真正会跑的路径，是针对经同意账户的界面对接，同时把泰国新出台的数据可携带机制视为这项工作日后迁移的方向。

逐个界面看 App 承载了什么

下表每一行都对应 App 本身向已登录用户暴露的内容，命名沿用 Bangkok Bank 自己的叫法。"粒度"一列是经同意读取能带出的信息，最后一列是它通常服务的用途。

FCD 是大多数对接方最容易低估的一块。这类账户各自带有独立币种和跨境转账背景，因此不能被并入某个泰铢合计数，否则含义就丢了。我们会把它们单独保留。

触达这些数据的授权路径

这里适用三条路径，而对这款 App 而言它们并不等价。

经同意账户的界面对接

目前最可靠的一条。在账户持有人授权的前提下，我们分析 App 自身的客户端到服务端流量，还原其认证与会话链路，构建一个镜像上述界面的读取客户端。它能触达用户看到的一切，因为它以与 App 相同的方式发起请求。工作量中等；持久性取决于前端，而这一点我们会预先规划。访问权限在项目启动阶段与你一起安排，构建过程针对一个经同意的账户进行。

泰国央行 "Your Data" 可携带机制

面向未来的一条。泰国央行（BOT）于 2025 年底出台了 Your Data 法规；据央行自己的公告，各提供方预计在 2026 年底前开放个人存款数据共享，贷款和支付类别在 2027 至 2028 年间陆续跟上。随着每个类别在 Bangkok Bank 上线，一套标准化的、基于同意的数据源将取代对应的抓取界面。我们在设计对接时就让这种切换成为一次配置更改，而非重建。

原生对账单导出

补历史数据时好用的一条兜底路径。App 本就支持按需通过邮件发送泰铢和 FCD 对账单；当一次性回补或较慢的节奏就够用时，解析这些导出文件可以完全不触碰实时会话。

对多数客户而言，日常负载目前由经同意账户路径来扛，因为在机制成熟之前，只有它能触达完整的资产组合 —— 而我们会把构建接到 Your Data 存款数据源上，只等 Bangkok Bank 一开放就切换。导出路径则继续作为低成本的历史回补手段保留。

一次经同意的拉取长什么样

以下为示意，且在构建过程中依 App 的实际行为核对得来，而非照抄任何已公开的接口契约。App 中的对账单申请是异步的 —— 你提出请求，银行准备好，你再来取 —— 所以客户端也镜像了这种两步式的形态。

POST /retail/statement/request        # authenticated session, consented scope
{
  "account":  "xxx-x-xxxxx-x",        # deposit or FCD account ref
  "currency": "THB",                  # FCD accounts carry their own code
  "from":     "2026-04-01",
  "to":       "2026-06-25"
}
-> 202 { "job_id": "stmt_8f21", "status": "preparing" }

GET  /retail/statement/result/stmt_8f21
-> 200 {
     "account":  "xxx-x-xxxxx-x",
     "currency": "THB",
     "as_of":    "2026-06-25T08:14:00+07:00",
     "lines": [ { "date":"2026-06-20", "desc":"PromptPay in",
                  "amount":"1500.00", "balance":"..." } ]
   }

# client concerns we handle, not you:
#  - session/token refresh when the prepared job outlives the login
#  - polling backoff so a slow statement job is not hammered
#  - per-account currency kept on every line; THB and FCD never merged

交付到你仓库的内容

交付物是可用的软件，加上让它可维护的文档，范围限定在你确实需要的那些界面上：

• 一份 OpenAPI 规范，覆盖我们建模的读取端点 —— 账户、对账单、卡片、贷款、持仓。
• 一份协议与认证流程报告：登录、令牌与会话刷新链路在这款 App 上的实际行为，并写清对账单任务的生命周期。
• 关键端点的可运行源代码，Python 或 Node.js 均可，包含同意采集与 FCD 币种处理。
• 针对录制响应的自动化测试，外加一套回放框架，让前端变更在进入生产之前就被发现。
• 接口文档与符合 PDPA 的数据留存指引：存了什么、存多久、同意如何记录与撤销。

同意，以及它所依据的泰国法律

访问某位 Bangkok Bank 客户的记录，立足于该客户在泰国《个人数据保护法》（PDPA）下的明确同意 —— 这正是央行把 Your Data 计划与 PDPA 合规绑定时所援引的同一依据。对这款 App 而言，这意味着我们会落地三件具体的事：一份精确限定到所请求账户界面的同意记录；一条有效期与撤销路径，让被撤回的同意直接停下同步，而不是悄无声息地失败；以及一份访问日志，记录读取了哪些记录、何时读取。数据被最小化到用途所需的范围；如你要求，会以 NDA 覆盖本次合作。Your Data 是前进的方向，而非今天已经落定的管道，所以我们把它的存款数据里程碑当作一个要为之构建的日期，而不是一个可以假定已经就绪的数据源。

我们预先考虑的工程问题

这款 App 有两点会影响构建方式，而两点我们都在自己这一侧处理。

第一，对账单流程是异步的，且通过邮件送达。一个期待即时响应的天真客户端会超时；我们的客户端把对账单获取当作一个带退避的任务来处理，而当银行只以邮件送达时，我们把取件步骤接进那条邮件通道，而不是假定可以同步下载。第二，资产组合把泰铢和覆盖十八种货币的外币存款（FCD）账户混在一起，App 还把 SWIFT 与 PromptPay International 转账穿插进同一批视图。我们把币种建模为每一笔余额和明细上的一等字段，在任何折算数旁保留原始金额，并按账户类型划定对接边界，使得某个 FCD 头寸永远不会被加进泰铢合计里。当前端发生变动 —— 而一个长寿的银行 App，其前端确实会变 —— 回放框架会标出这种偏离，重新校验这一步本就是我们维护对接的一部分。

保持数据新鲜

银行前端按银行的节奏变，不按你的。我们把读取节奏设到数据所需的程度 —— 余额按日，对账单按需 —— 而针对录制响应的测试同时充当绊线：当某个字段挪位或某条流程改变形态时，测试会在陈旧数据造成损害之前先失败。这套维护回路是合作的一部分，而不是事后另行计费的附加项。

界面佐证

取自 Play Store 页面的截图，用于印证上文点名的那些界面。点击可放大。

同一套对接里相邻的 App

点名要 Bangkok Bank 的团队，通常还想在同一套 schema 下顺带覆盖它的一两个同行，所以我们以同样的方式为它们建模。以下名称仅供参照，不作排名。

• K PLUS (KBank) —— Kasikornbank 的旗舰 App；面向极为庞大的零售用户群提供存款、卡片、转账与 PromptPay。
• Make by KBank —— KBank 的信封式记账伴侣 App，承载目标储蓄与交易记录。
• SCB Easy (Siam Commercial Bank) —— 覆盖 SCB 客户群的账户、卡片、投资与二维码支付。
• Krungthai NEXT —— Krungthai Bank 的 App，在政府相关支付和 PromptPay 上使用极为频繁。
• krungsri / KMA (Bank of Ayudhya) —— 支持生物识别与 PIN 登录的存款、卡片和贷款。
• TTB Touch (TMBThanachart) —— 合并后的 App，提供目标储蓄以及车贷、房贷的还款服务。
• MyMo by GSB —— 政府储蓄银行（Government Savings Bank）的 App，福利领取者和小额储户中很常见。

因为它们暴露的是同一种形态的数据 —— 余额、对账单、卡片、转账 —— 一套归一化的 schema 就能承载其中数个，而当一家 fintech 想要的是泰国银行的整体覆盖而非某一家机构时，这正是价值所在。

核查方式

于 2026 年 6 月 25 日对照 App 的 Play Store 描述及 Bangkok Bank 自家的数字银行页面进行核查，并与泰国央行的开放数据和 Your Data 公告交叉比对，以确认监管时间线。查阅的第一手来源：

• Bangkok Bank Mobile Banking —— Google Play 页面
• 泰国央行 —— 数据可携带法规（2025 年 11 月）
• 泰国央行 —— 开放数据计划
• Bangkok Bank —— 手机银行使用指南

OpenBanking Studio · 对接台梳理，2026 年 6 月。

对接方常问的问题

对接实际能读到 Bangkok Bank 的哪些记录？

这款 App 会呈现存款与 e-Savings 余额、泰铢及外币存款（FCD）对账单、信用卡余额与状态、Bualuang 贷款账户，以及共同基金、政府债券和公司债券的持仓。经用户同意的对接会镜像这些可读界面；转账与 PromptPay 历史可作为记录读取，但不涉及发起交易。

泰国的 Your Data 机制会改变我们对接这款 App 的方式吗？

会。泰国央行（Bank of Thailand）已于 2025 年底出台 Your Data 数据可携带法规，预计各提供方将在 2026 年底前开放个人存款数据的共享，其余类别在 2027 至 2028 年间分批推进。在某一类别于 Bangkok Bank 正式上线之前，我们基于用户同意的账户路径来构建，并让设计保持随时可切换到该机制的状态。

FCD 与多币种余额如何处理？

外币存款（FCD）账户各自带有币种代码和 SWIFT 侧的往来背景。我们会把每一笔余额连同其币种和截至时间一起做归一化处理，避免多币种资金视图在无声无息中把泰铢和 FCD 金额混在一起，并在任何折算值旁保留原始金额。

PDPA 同意记录是你们负责产出的吗？

是的。访问以账户持有人在泰国《个人数据保护法》（PDPA）下的明确同意为前提，我们会连同可运行的源代码一并交付同意采集、授权范围与有效期处理，以及访问日志，让数据的处理链路从第一天起就可审计。

开始很简单，把 App 名称和你需要从中取出的内容发给我们即可。源代码交付 300 美元起：你会拿到可运行的客户端、规范、测试与文档，验收满意后再付款。不想自己托管？调用我们的托管 API，按调用计费，无需预付。无论哪种方式，周期都是一到两周，访问权限与 PDPA 合规都会作为工作的一部分与你一起安排。把你正在做的东西告诉我们：/contact.html。