走进 HIFI CREDIT 的借款人贷款账户

HIFI CREDIT 的每一笔贷款都带有固定的每日利息——按其 Google Play 商店说明的表述，是每天 0.05%——并对本金逐日计息，而这个本金按说明所述大约在 1,000,000 到 30,000,000 越南盾之间，期限为 91 到 360 天。真正值得获取的正是这份数据：它不是一个静态的贷款金额，而是一份服务端台账，只要贷款仍在存续，它每天都在变化。说明里甚至把算式都列了出来——1,000,000 越南盾按每天 0.05% 计息 120 天，是 60,000 越南盾的利息，结清金额为 1,060,000 越南盾。按需、逐个借款人地把这个数字复现出来，就是这次对接的核心。

HIFI CREDIT 是一家非银行放贷机构。它并不在越南国家银行面向银行的 Open API 目录之内，因此没有现成的聚合端点可供订阅。不过数据仍然是可获取的——它就藏在借款人自己的登录之后，藏在 App 发起的那些请求里。我们在借款人授权下对这些请求做映射，再把一份干净的贷款记录接口交回给你。这就是我们在这里会采取的路径，本页余下内容讲的都是"怎么做"。

登录之后有些什么

这个 App 持有一小组结构清晰的逐借款人记录。里面没有什么稀奇的东西，价值在于把它以结构化、且保持实时的方式取出来。

如何获取：适用的几条路径

对于这样一个 App，真正合适的路径有两条，外加一个兜底方案。我们依据借款人已同意的内容、以及 App 在会话中暴露出的内容来选择。

1 · 对 App 流量的授权接口集成

我们观察 HIFI CREDIT 客户端在借款人知情同意的会话中发出的请求——登录、拉取贷款、拉取还款——并把它们重建为一份有文档的接口。可获取范围：上面那份完整的贷款记录。工作量适中，因为接口面很少、贷款算法也是固定的。可持续性取决于 App 的发版节奏，这一点我们用固定样本（fixture）来兜住（见工程要点）。接入权限会与你一起安排——一个知情同意的账户，或项目专用的测试借款人，用来捕获并验证这些请求。

2 · 用户授权的凭据访问

如果使用场景是借款人想把自己的数据搬到别处——比如个人理财工具、债务跟踪服务——那么由借款人同意并完成身份验证，我们代其完成拉取。可获取范围：同一份记录，但限定在这一位借款人。这与下文的越南同意规则契合得最干净，因为每一次拉取，数据主体都在闭环之中。

3 · 原生导出作为兜底

如果 App 或其客服渠道能生成一份对账单或一份数据副本，我们就把它解析进同一套 schema。保真度低于实时拉取——那是一张快照，而非一条数据流——但在实时同步上线之前，用来回补历史很有用。

对 HIFI CREDIT 来说，诚实的选择是以路径 2 的同意来驱动的路径 1：对贷款与还款请求做实时接口，且只在持有者已同意的账户上运行。这组贷款数据太小、也对时间太敏感，静态导出承载不了；同时又没有银行端点可以依靠，所以 App 自己的会话，才是当前数字所在的地方。

针对贷款台账的一次真实拉取

这就是实时路径的样貌，精简到最关键的两个请求。字段名和路径在构建阶段确认，而非凭空猜测；这里把主机地址做了脱敏。

# Illustrative — auth then loan fetch, normalized on the way out.
import requests

BASE = "https://api.hificredit.example"   # captured host, redacted

def login(phone, otp):
    r = requests.post(f"{BASE}/api/v1/auth/token",
                      json={"phone": phone, "otp": otp})
    r.raise_for_status()
    return r.json()["access_token"]        # short-lived bearer; refresh below

def active_loan(token):
    r = requests.get(f"{BASE}/api/v1/loan/active",
                     headers={"Authorization": f"Bearer {token}"})
    r.raise_for_status()
    return r.json()

# Normalized loan record (Vietnamese fields mapped to stable English keys):
# {
#   "loan_id":             "...",
#   "principal_vnd":       1000000,
#   "daily_rate":          0.0005,      # 0.05%/day, per the app listing
#   "term_days":           120,
#   "accrued_interest_vnd": 60000,      # principal * daily_rate * days_elapsed
#   "payoff_vnd":          1060000,     # matches the listing's worked example
#   "due_date":            "2026-10-21",
#   "status":              "active"     # mapped from "dang_vay"
# }

计息这一行是最要拿准的地方。我们用与说明完全相同的方式计算它，并把结果与 App 在同一天所显示的数字核对——如果两者对不上，说明构建有误，一个测试会在你看到之前就把它揪出来。

交付时你拿到什么

交付物是一套可运行的、针对上述接口面的集成，而不是一份讲述它们的报告。对 HIFI CREDIT 而言，这意味着：

• 一份 OpenAPI（Swagger）规范，覆盖鉴权、在贷贷款与还款请求，并以归一化后的贷款 schema 作为响应模型。
• 这些端点在 Python 或 Node.js 下的可运行源码——登录、令牌刷新、贷款与还款历史的拉取，以及计息对账。
• 一份协议与鉴权流程报告：bearer 令牌如何签发与刷新、会话有效期，以及客户端所依赖的 cookie 或请求头链路。
• 自动化测试，包含一个固定样本，把那道算例（1,000,000 越南盾 → 120 天后 1,060,000 越南盾）钉死，以便捕获计息漂移。
• 英文接口文档，外加与下文越南法规相匹配的数据留存与同意留痕指引。

塑造这次构建的越南数据法规

越南的开放银行框架——越南国家银行的 Circular 64/2024/TT-NHNN，据我们查阅的报道自 2025 年 3 月 1 日起施行——为银行设定了一套以同意为核心、分阶段推进的 Open API 制度。HIFI CREDIT 并不是参与其中的银行，所以这次对接不搭乘那份目录。真正约束它的是个人数据方面的法律：第 13/2023/ND-CP 号法令，以及将于 2026 年 1 月 1 日生效的《个人数据保护法》。二者都把借款人明确、限定用途的同意作为处理的基础，禁止预勾选或默示同意，并要求撤回同意必须被尊重。

因此，这次构建的范围被这份同意所限定。我们只拉取某个明示用途所需的贷款字段，把每一次访问对照同意记录留痕，并把撤回设计成一个真正的"停止"——一旦借款人撤回，同步随即结束，留存计时开始。凡是触及放贷方自身系统的环节，都签署了保密协议。这是我们的工作方式，而不是横在你面前的一道障碍。

我们会预先设计的工程细节

这个具体 App 有两件事在主导设计，另有几件是我们按惯例处理的。

• 计息时钟。利息以每天 0.05% 推进，所以一个结清金额只对某一天成立。我们把计息锚定在放贷方所在的时区（ICT），让日界对齐，并且每天刷新结清金额、而不是把它缓存起来——在这里，一个过时的数字就是一个错误的数字。
• 处于银行边界之外。由于非银行放贷机构没有 SBV Open API 端点，这次对接依赖于 App 自身的会话。我们仔细梳理它的令牌签发与刷新，让长时间运行的同步不会在贷款进行到一半时中断；同时把鉴权流程隔离开来，使其中的变动不会波及数据请求。
• 越南语界面文案。状态和标签以越南语返回，且可能在不同版本间改动措辞。我们在归一化阶段把它们映射到稳定的英文键名，因此你的系统绑定的是键名，而不是屏幕上的文字。
• 前端变动。当 App 更新界面时，我们会拿捕获到的请求对照已保存的固定样本重新核对，这样一次布局或字段的变化就会以一个失败的测试形式浮现，而不是在数据流里留下一个无声的缺口。这类重新核对所需的接入，会在入网阶段与你一起、针对一个知情同意的账户来安排。

让同步保持实时

对任何在贷贷款，结清与已计利息字段每天刷新，因为日利率在构造上就让任何超过一天的数字变成错的。静态字段——本金、期限、到期日——在放款时拉取一次，发生变化时再重新校验。拉取是幂等的、以贷款 id 为键，因此一次重试的同步绝不会把一笔还款重复计入。如果 App 发布更新挪动了某个请求，固定样本测试会在当天就把它标记出来。

费用与合作方式

一套可运行的 HIFI CREDIT 集成——贷款与还款请求的可运行源码、OpenAPI 规范，以及计息测试——在一到两周内交付。源码交付起价 300 美元，而且你是在代码到手、并且确实能用之后才付款，而不是提前付。如果你不想自己托管任何东西，第二种方式是我们的按调用计费 API：你调用我们的端点，只为你实际发起的调用付费，没有前期费用。无论哪种方式，你要开始所需要给我们的，只是 App 名称和你想从它数据里得到什么；接入与同意那一侧会一并安排。告诉我们哪种更合适，我们来做方案——从这里开始沟通。

这份简报是怎么整理出来的

于 2026-07-11 复核，贷款条款与算例对照该 App 的 Google Play 商店说明，数据法规对照当前的越南监管报道。路径与 schema 反映的是这类形态的 App 通常如何对接；字段名在构建阶段确认。主要来源：

• HIFI CREDIT——Google Play 页面
• Circular 64/2024/TT-NHNN 与越南的 Open API 制度（Brankas）
• SBV 的 Open API 通函草案——阶段划分与同意要求（Tilleke & Gibbins）
• 越南《个人数据保护法》（Hogan Lovells）

OpenBanking Studio 集成团队 · 映射复核于 2026-07-11。

我们据以工作的截图

这些是 App 自身的截图，取自其商店页面。点击可放大。

同样在范围内的其他越南借贷 App

HIFI CREDIT 处在一个竞争激烈的消费信贷领域。在其中若干家之上做一层统一集成，就能让主机系统用一套 schema 覆盖多家放贷方。这里列出只为提供背景，并非排名：

• Home Credit (Home Credit Tài Chính Online)——分期与现金贷，单笔额度更大；每位借款人的账户持有还款计划与余额。
• FE Credit (FE ONLINE 2.0)——按余额递减计息的无抵押现金贷；客户贷款仪表盘含期限与利率。
• MoMo——内嵌放贷功能的电子钱包；按用户持有钱包余额、交易历史与贷款报价。
• Cake by VPBank——提供现金贷的数字银行；账户、卡片与贷款台账集中在一个登录之后。
• Tima——撮合借款人与出借人的 P2P 借贷平台；按请求持有申请与放款记录。
• Doctor Dong——短期在线现金贷；借款人资料、贷款金额与还款到期日。
• Vietdong (Vay nhanh online)——无抵押短期借贷；按用户持有申请与实时贷款状态。
• RoboCash——即时在线放款；借款人账户承载费用、计划与出款时点。

集成方关于 HIFI CREDIT 常问的问题

对接是否覆盖每天 0.05% 的计息，还是只有名义贷款金额？

覆盖计息。我们按照应用商店说明中描述的方式建模每日利息，因此某一天拉取的结清金额与借款人当天看到的一致，而不仅仅是原始本金。

HIFI CREDIT 不是持牌的越南银行——这会改变你们获取数据的方式吗？

会。独立的非银行放贷机构不在越南国家银行的银行 Open API 目录之内，因此我们是在借款人授权下针对该 App 自身的客户端-服务端接口进行对接，而不是走某个银行聚合端点。

这个 App 的界面和状态是越南语的——数据会以什么格式返回？

我们在映射阶段把越南语字段标签和贷款状态归一化为一套稳定的英文 schema，因此你的下游系统读取的是一致的键名，而不是会随版本变动的界面文案。

哪些越南数据法规约束 HIFI CREDIT 的对接？

第 13/2023/ND-CP 号法令，以及将于 2026 年 1 月 1 日生效的《个人数据保护法》，两者都以同意为核心。访问建立在借款人明确、限定用途的同意之上，撤回同意会被尊重，处理过程也会留痕。