把 Cloud Pocket 与存款数据从 MAKE by KBank 里取出来

根据 MAKE 自己在 Play Store 上的介绍，其电子储蓄对前 50 万泰铢按 1.35% 计息，超出部分按 0.35% 计息，利息可以每天查看。这些余额并不是一笔笼统的数字，而是记在每位用户各自的账本里，再由账户持有人拆分成一个个 Cloud Pocket。一个存款账户、多个命名口袋、其中一些还和朋友共享——正是这种结构，才是对接方真正想从 MAKE 里拿到的东西，也恰恰是通用银行连接器最容易搞错的地方。这份简报讲的是如何以授权合规的方式读到这些数据、我们会梳理哪些内容，以及最终交付到你代码仓库里的又是什么。

眼下最可行的路径是授权接口对接：我们在已获授权的账户上读取 App 自身的流量，直接还原出 Cloud Pocket、账本和汇总这几块界面。连接器在搭建时就预留了切换能力，等 KBank 把存款数据接入 BOT 的同意通道（监管方定的时间点是 2026 年底），就能顺势切过去。两条路都够不到的地方——比如归档的 Cloud Chat 会话、逐月导出的 Expense Summary——就靠 App 自带的历史回溯来补上。

MAKE 里究竟存了些什么

下面按 App 自己的叫法逐块列出各个数据面，说明每一块的来源，以及数据使用方拿到后能做什么。

Pop Pay 是一种近距离转账，能在大约十米范围内找出附近的好友，它写入的账本和其他交易是同一个，所以不需要单独处理。有两点决定了整个数据模型的形态：余额被拆散在各个口袋里，而不是汇成一个数字；共享口袋则意味着同一笔金额会出现在不止一位成员的视图中。

对接 MAKE 账户的授权方式

这里有三条路可走。每条路我们都会讲清楚：它能读到什么、工作量多大、可持续性如何，以及我们要和你一起搭建些什么来把它跑起来。

1 · 授权接口对接（协议分析）

我们在账户持有人已授权的前提下，抓取并重放 App 自身的会话，然后像 App 一样去读取 Cloud Pocket、Cloud Chat 账本和 Expense Summary。覆盖面很广——基本上用户能看到的都能读到。工作量适中，主要集中在与设备绑定的鉴权引导上。可持续性取决于前端是否稳定，这一点我们用一道重新校验流程来兜底（详见工程要点）。对接所需的访问权限会在启动阶段和你一起安排，落在一个已同意的账户上。

2 · 泰国央行「Your Data」同意通道

BOT 于 2025 年 10 月 30 日颁布了 Open Data 法规，允许客户在授权后，把受监管机构持有的存款、贷款和支付数据，通过标准化的数字通道分享给另一家机构。存款账户的共享计划在 2026 年底前启动，其余部分则在 2027 到 2028 年间分批上线。对存款和支付这两块界面来说，这是可持续、受监管的路径。我们现在就把同意通道的连接器接好，等 KBank 一放出存款数据源，整套对接就能立刻迁移过去，而不必再改动你这一侧。

3 · App 原生的历史回溯与导出

MAKE 保存的 Cloud Chat 历史没有回溯上限，Expense Summary 则按月呈现。对于一次性的历史回填或低频同步，在持有人同意下直接读这些界面是最轻量的做法，也能很好地补充上面那种实时读取。

如果这个季度就动工，路径 1 负责让数据即刻流动起来；路径 2 则是我们同步铺下的连接器，等 Your Data 一开通，存款数据源就转由同意机制管辖。路径 3 用来补齐前两条实时路径都懒得碰的历史边角。这个先后次序是针对 MAKE 当下的时点定的：受监管的通道确实存在，但还没对 KBank 存款开放，所以眼下真正扛活的是授权读取。

会话与口袋拉取大致长什么样

以下是示意性的结构，会在实际搭建时逐一确认，而不是照搬某份公开规范。重点在于与设备绑定的鉴权，以及「口袋 + 账本」的组织方式，而不是具体的字段名。

# MAKE pins identity to a K PLUS confirmation or a KBank ATM ID check,
# so the session token carries a device assertion and is short-lived.
POST /v2/auth/token
  { "device_id": "...", "assertion": "<k-plus-or-atm-derived>",
    "grant": "device_session" }
  -> { "access_token": "...", "refresh_token": "...", "expires_in": 900 }

# List the account's Cloud Pockets (one deposit account -> many pockets)
GET /pockets?include=balance,goal,members
  Authorization: Bearer <access_token>
  -> [ { "pocket_id": "...", "type": "wishlist",
         "goal_amount": 30000, "saved": 18450,
         "shared": true, "member_count": 3, "locked": false }, ... ]

# Pull the chat-format ledger for one pocket / counterparty
GET /pockets/{pocket_id}/ledger?cursor=...   # paginated
  -> entries[] { amount, party, ts, memo, attachment_url }

# Refresh before expiry; do not let the device session lapse mid-sync
POST /v2/auth/refresh  { "refresh_token": "..." }
      

错误处理比顺利路径更值得花心思。设备会话一旦过期，返回的鉴权失败看起来很像权限错误，所以客户端在进入重试循环之前，得先分清「刷新后重试」和「同意已撤销，停止」这两种情况。

交付时你会拿到什么

所有东西都紧扣上面那几块数据面，而不是一套通用的银行模板：

• 一份 OpenAPI 3.1 规范，覆盖按 MAKE 建模的口袋列表、单口袋账本、Expense Summary 和余额等接口。
• 一份协议与鉴权流程报告，记录与设备绑定的令牌交换、K PLUS / ATM 引导、刷新时机以及撤销信号。
• 关键调用的可运行源代码，含 Python 和 Node.js 两个版本——口袋枚举、带附件的账本分页、按月汇总拉取。
• 一套规范化数据模型，把「一个账户、多个口袋、部分共享」映射为「父账户 / 子口袋」结构，使余额能对得上，共享资金也不会被重复计算。
• 针对已同意账户运行的自动化测试，以及接口文档。
• 符合 PDPA 的数据留存与同意记录指引，供你在上层继续开发时参考。

授权同意从何而来

有两套泰国框架在管这件事，而且二者不能相互替代。PDPA（《个人数据保护法》B.E. 2562，已生效并在切实执行——PDPC 已于 2025 年开出首批重大行政罚款）把金融信息视为敏感个人数据，在采集或处理之前必须取得明确、知情的同意。这份同意——由账户持有人授权访问自己在 MAKE 里的数据——正是当下整套对接所依托的稳固基础。

泰国央行的「Your Data」Open Data 法规则是面向未来的那一层。它赋予客户通过标准化通道分享自己存款和支付数据的权利，但存款共享要到 2026 年底才计划启动，目前还不是一个可以拿来开发的实时数据源。我们把它看作受监管路径的走向，而不是已经打开的开关。落到实处，整套实现会记录同意的范围和有效期、干净利落地支持撤销、把读取字段收敛到用例真正需要的范围、记录每一次访问，并在合作有此要求时在 NDA 下进行。

MAKE 特有的工程要点

关于这款 App，有三件事决定了实现方式，而它们都由我们这边来处理。

• 与设备绑定的注册。MAKE 把访问权限绑在 K PLUS 确认或 KBank ATM 身份核验上，由此得到的会话存活时间很短。我们围绕这个设备断言和令牌有效期来设计引导流程，让同步按计划刷新，而不是悄无声息地断掉；对已同意账户的访问会在启动阶段和你一起安排。
• 共享口袋的记账。一个口袋可以归属多位成员，于是同一笔余额会出现在不止一个账户的视图里。我们显式地对成员关系建模，并给共享资金打上标记，这样跨家庭或跨群组的汇总数字才不会重复计算——这一点正是一个扁平的对账单导入器会搞错的地方。
• 前端漂移与 Your Data 切换。由于路径 1 读的是实时界面，一次 UI 改动就可能让某个字段挪位。我们在维护中内置了一道重新校验流程，能及早发现结构变化；同时让 BOT 同意连接器保持就绪，等 KBank 一开通，存款界面就能迁到受监管通道上，而无需重写。

我们参照的界面截图

梳理口袋、账本和汇总这几块界面时所用的公开商店截图。点击可放大。

让对接保持最新

存款余额和账本时刻在变，Expense Summary 则按月结算。我们的同步会按用例所需的节奏轮询实时界面，重新校验流程则盯着版本更迭之间的接口漂移。对 MAKE 而言，更大的一次「更新」来自监管层面：等 Your Data 存款通道开放，存款数据源就会从授权读取转为受同意管辖的读取，我们会把这次切换当作维护的一部分来规划，而不是另起一个项目。

MAKE 在泰国资金类 App 中的位置

统一数据层通常会和 MAKE 一并覆盖的同类 App。这里只为提供背景，并非排名。

• K PLUS — KBank 的旗舰手机银行；掌握完整的存款、转账和账单支付记录，MAKE 注册时往往就靠它来确认身份。
• SCB Easy — Siam Commercial Bank 的 App，涵盖账户、转账和扫码支付；SCB 是泰国较早布局开放 API 的银行之一。
• Krungthai NEXT — Krungthai Bank 的 App，覆盖存款、政府计划补贴发放和转账。
• Bualuang mBanking — Bangkok Bank 的 App；Bangkok Bank 运营着一个公开的开发者门户，提供 API 文档和沙箱。
• TTB Touch — TMB 与 Thanachart 合并后的 App，用于转账、支付和储蓄产品。
• Kept by Krungsri — Krungsri 的储蓄 App，把钱分成消费和储蓄两类桶，理念上和 Cloud Pocket 十分接近。
• LINE BK — LINE 即时通讯里的社交银行，带储蓄、借记卡和信用额度。
• Dime! — 一款泰国储蓄与投资 App，把现金和证券余额放在同一个登录后台。

这些事实的来源

2026 年 6 月对照一手来源做过核对：Cloud Pocket 类型、利率分档和功能名称取自 App 自己的商店与产品介绍；Open Data 法规、颁布日期和推进时间表来自泰国央行；PDPA 对金融数据的处理方式则参考泰国的数据保护资料。相关深链见下。

• Bank of Thailand — 数据共享法规，2025 年 10 月 30 日颁布
• Bank of Thailand — Open Data（「Your Data」）概览
• MAKE by KBank — 官方产品站点（KBTG）
• PDPA B.E. 2562 — 泰国数据保护参考资料

由 OpenBanking Studio 对接团队梳理 · 2026 年 6 月。

对接方常问的关于 MAKE 的问题

MAKE 的 Cloud Pocket 结构能映射到常规的账户模型上吗？

一个 MAKE 账户可以拆成数量不限的 Cloud Pocket，其中一些口袋还会和两位或更多成员共享。我们把它规范化为「父账户 + 子口袋」的结构，这样总余额和单口袋余额都能对得上，共享口袋里的资金也不会在多位成员之间被重复计算。

MAKE by KBank 的数据在泰国「Your Data」开放数据机制的覆盖范围内吗？

作为 KBank 旗下的存款与支付产品，它落在泰国央行 2025 年 10 月 30 日颁布的法规覆盖范围之内。存款账户共享计划在 2026 年底前上线，贷款和支付数据则在 2027 到 2028 年间跟进，全部以账户持有人的明确同意为前提。

MAKE 有 K PLUS 和 ATM 的身份核验，你们是怎么读取账户的？

MAKE 把注册绑定在 K PLUS 确认或 KBank ATM 身份核验上，因此会话是与设备绑定的。我们在一个已同意的账户上完成引导，捕获设备断言和短时令牌，并围绕令牌有效期设计刷新循环，让读取不会悄无声息地中断。

你们能读到较早的 Cloud Chat 会话和按月的 Expense Summary 吗？

可以。Cloud Chat 按对手方保存交易记录，回溯没有时间限制，我们会对账本分页读取，连同备注和图片附件一并拿到；Expense Summary 的收支汇总则按月快照拉取，并归入规范化的数据模型。

最终交付物是进到你代码仓库里的源代码，而不是一份幻灯片。MAKE 对接 300 美元起——可运行的 Python 和 Node 客户端、OpenAPI 规范、鉴权流程报告、测试和接口文档——交付后再付款，也就是等它在你已同意的账户上跑通之后。如果你不想自己托管，同样这套接口也能作为按调用计费的托管 API 使用，没有预付费用。把账户范围和你关心的界面告诉我们，写到 /contact.html，我们会把它安排进一到两周的周期里。