对接 iShinhan 背后的贷款与卡片账簿

Shinhan Vietnam Finance 以 iShinhan 作为其消费贷款与信用卡业务的入口。据该应用在 Google Play 的商店页面，其无抵押贷款额度可达 3 亿越南盾，期限最长 48 个月。运营公司的前身是 Prudential Vietnam Finance，2019 年 1 月被 Shinhan Card 收购（据报道金额约 1.5 亿美元）。对想在这份账簿之上做开发的人来说，真正有价值的部分藏在 eKYC 登录之后：逐笔的借款人申请、还款计划、卡片余额和分期方案——这些只存在于服务器端，而且一次只对应一个账户。

简单说：iShinhan 是一款交易型应用，因此值得集成的数据是逐个用户的状态，而非批量数据源。我们真正会走的路径，是针对你所掌控的一个真实账户，做一次基于用户同意的接口集成，并在每次应用发版后重新核对这些流程。越南的规管化 Open API 框架是更长期的方向；我们在构建时就让集成能够平滑迁移过去，无需重写。

应用内部藏着哪些数据

以下是一个经用户同意的 iShinhan 会话所能触及的面，尽量沿用应用本身呈现它们的叫法。

有哪些入口，以及我们会选哪个

基于用户同意的接口集成

我们针对你授权的账户搭建一个带监测的客户端，梳理 eKYC + OTP 会话，读取应用自身调用的那些端点。上表中的一切都能由此触及。工作量适中；可持续性取决于 iShinhan 的发版节奏，因此前端一旦变化就需要重新核对。访问权限在项目一开始一起安排——你这边的同意账户在启动阶段配置，而不是需要事先跨过的门槛。

越南的规管化 Open API 通道

SBV 第 64/2024/TT-NHNN 号通知为银行业确立了以用户同意为核心的 Open API 框架，自 2025 年 3 月 1 日起生效，据报道将于 2027 年 3 月 1 日前全面落地。随着标准化端点覆盖到像这样的金融公司，集成可以迁移过去，获得更高的可持续性。当这条路径对该主体开放时，我们负责注册并接入其同意流程。

单用户授权凭据访问

对于范围很窄的场景——某位借款人查询自己的状态——由用户授权一个会话，我们就只读取那一个账户。这是最轻量的选项，也最容易保持在数据最小化的边界之内。

对当下的大多数买家而言，能落地并见效的正是基于用户同意的接口集成，因为规管化目录尚未端到端覆盖这家服务商；我们把客户端写成这样：等第 64 号通知的端点对 Shinhan Finance 就位时，替换底层传输只是小改动，而非一个新项目。

构建阶段我们会核实的请求形态

仅作示意——端点名称和字段是在针对同意账户构建时重建出来的，并非已公开的契约。它们展示的是一个会话的形态：先是 eKYC 支撑的令牌，然后读取贷款与卡片状态，并对 iShinhan 强制的再验证提示做防护。

# 1) Establish a session (eKYC + OTP, per the app's sign-in)
POST /auth/session
  { deviceId, phone, otp, biometricAssertion }
  -> { accessToken, refreshToken, ekycState }

# 2) Read the borrower's loan applications
GET /loans/applications        Authorization: Bearer <accessToken>
  -> [ { applicationId, product: "express" | "standard",
         amountVnd, termMonths, aprBand, status, contractSigned } ]

# 3) Card statement + 0% installment plans
GET /cards/{cardId}/statement
  -> { creditLimitVnd, available, minimumDue, dueDate,
       installmentPlans: [ { planId, tenorMonths, convertedVnd } ] }

# Re-KYC guard: when ekycState == "REVERIFY", card reads return 403
# until biometric + chip-ID are refreshed. The client re-runs eKYC,
# then retries — the sync recovers instead of stalling.

最终交付什么

都是具体的交付物，且各自对应 iShinhan 自身的功能面：

• 一份 OpenAPI/Swagger 规范，覆盖贷款申请、还款计划、卡片账单与缴费的读取。
• 一份协议与认证流程报告，记录 eKYC + OTP 会话、令牌刷新，以及再验证的 403 路径。
• 关键端点的可运行源码，提供 Python 与 Node.js 两个版本，并内置再次 KYC 的重试逻辑。
• 自动化测试，针对一个真实的同意账户运行，并在某次发版改动了字段或路由时发出警示。
• 一份接口文档，工程师无需我们在场也能照着走通。
• 对照 PDPL 第 27 条的数据留存与同意记录指引，因为贷款和卡片记录属于敏感个人数据。

针对这款应用的工程要点

有两个产品层面的现实决定了构建方式，我们都做了考虑。iShinhan 承载两种放贷形态——全自动的 Express Loan，凭芯片版公民身份证在会话内完成签约和放款；以及基于审批的标准贷款，带有视频通话审核环节。两者的状态模型不同，因此我们对每种产品分别建模，而不是假设一个状态机就能涵盖两者。

第二点是 eKYC 门禁。应用会在生物识别与芯片身份证数据刷新之前阻止线上卡片交易，而且会在流程中途把会话打入再验证状态。我们保留一套回放测试装置，在每次 iShinhan 发版后重跑登录与卡片流程，这样一次改动了 eKYC 步骤的版本升级会在破坏客户同步之前被发现。凡是需要沙箱或账户访问的地方，我们都在配置阶段与你一同安排，并针对一个同意账户来构建。

用户同意与越南法律

读取 iShinhan 数据可靠的依据是账户持有人的明确同意。越南的《个人数据保护法》（第 91/2025/QH15 号法律）已于 2026 年 1 月 1 日生效，据法律摘要，它把金融与信贷记录视为敏感个人数据：同意必须针对每一项用途分别作出，预先勾选的选项和沉默都不作数，且涉及信贷信息的数据泄露须在 72 小时内通报。第 27 条禁止在未经同意的情况下对信贷信息进行评分。在此之上，SBV 第 64/2024 号通知在该通道逐步铺开时，规范着银行业范围内 Open API 与客户数据共享的运作方式。我们在两者的框架内行事：授权、有登录记录的访问；留存同意记录；数据压缩到所请求的字段；并在项目需要时签署保密协议。

合作方式

一个可用的构建成果会在一到两周内交付：一个针对 iShinhan 贷款状态与卡片读取的可运行客户端、它的 OpenAPI 规范、认证流程报告，以及测试。有两种商务形态可选。源码交付 300 美元起——你拿到可运行源码和文档，并在交付后、对结果满意时再付款。或者走托管路径：由我们运行这些端点，你来调用并按次付费，没有前期费用。告诉我们是哪款应用、你想从它的数据里得到什么，我们据此来划定范围——到联系页面开始沟通。

它会被用在哪里

• 一个借贷平台在获得借款人同意后，把其 iShinhan 的申请状态和合同条款镜像进自家看板。
• 一个个人理财应用拉取卡片余额和未结清的 0% 分期方案，让用户在一处看到自己在 Shinhan Finance 的真实负债。
• 一个中小企业记账工具，把通过 iShinhan 完成的生活缴费与自身账本对账。
• 一个催收或贷后服务团队，在一组已获同意的账户上跟踪还款计划和到期日。

界面佐证

iShinhan 的商店截图，有助于梳理我们要集成的流程。点选任一张可放大。

核实过程

数据域和产品细节来自 iShinhan 的 Google Play 商店页面以及 Shinhan Finance 自家的新闻室；监管背景来自关于 SBV 第 64/2024 号通知与越南 PDPL 的报道；运营方背景则来自关于 Prudential Vietnam Finance 收购案的报道。核对时间为 2026 年 7 月。

• Google Play 上的 iShinhan
• Shinhan Finance —— iShinhan 上的信用卡功能
• 越南 SBV 第 64/2024 号通知与 Open API
• 越南《个人数据保护法》

由 OpenBanking Studio 集成小组梳理 · 2026-07-01

同一市场的同类应用

越南消费金融领域的其他玩家也持有相近的逐用户数据；一次统一集成通常会横跨其中几家。

• FE Credit —— VPBank 旗下的消费金融业务，也是市场规模最大者，持有个人贷款、信用卡和分期记录。
• Home Credit（Home Credit Digi-Finance）—— 提供分期与现金贷，应用内审批快，并附带还款计划。
• HD Saison —— 覆盖摩托车、耐用品与现金贷的分期放贷，转介渠道分布广。
• Mcredit —— MB Bank 与 Shinsei 的合资公司，在需认证的账户背后提供现金与分期贷款。
• My Finance（Mirae Asset VN）—— 无抵押消费贷与车贷，配有线上贷后服务。
• MB Shinsei Finance —— 通过 Military Bank 的金融合资公司提供现金与分期贷款。
• JACCS Vietnam —— 面向消费品与车辆的分期融资，按合同提供还款计划。
• Viet Credit —— 与卡片挂钩的消费信贷，支持应用内还款与账单。

集成方常问的问题

经用户同意的集成能读取 iShinhan 的哪些记录？

登录用户能看到的一切：贷款申请及其电子签约合同、还款计划、信用卡账户与额度、0% 分期方案、无卡取现请求、生活缴费，以及 eKYC 状态。每个字段只针对授权的账户读取，且只读取你的用例真正需要的字段。

越南央行的 Open API 通知会覆盖像 Shinhan Finance 这样的金融公司吗？

第 64/2024/TT-NHNN 号通知搭建了银行业的 Open API 框架，自 2025 年 3 月 1 日起生效，据报道将于 2027 年 3 月 1 日前全面落地。Shinhan Vietnam Finance 是否在首批目录之内尚无公开确认，因此目前可靠的依据仍是账户持有人自己的授权。一旦规管化通道覆盖到该主体，我们就把集成迁移过去。

同步过程中，你们如何应对 iShinhan 的生物识别与芯片身份证再验证？

iShinhan 会要求用户在继续进行线上卡片交易前刷新生物识别数据和芯片版公民身份证。我们把会话层设计成能识别这一再验证状态并重跑 eKYC 步骤，这样当再次 KYC 提示触发时，同步会自动恢复，而不是无声失败。

能否在不触及整个信贷账簿的情况下，只取单个借款人的贷款状态？

可以。经用户同意的会话只读取该借款人的申请、合同条款与还款计划，并压缩到所请求的字段。这符合 PDPL 第 27 条——该条把信贷记录视为敏感个人数据，须取得明确、针对特定用途的同意。