Connecting to the loan and card ledgers behind iShinhan

Shinhan Vietnam Finance runs iShinhan as the front door to its consumer-loan and credit-card book, with unsecured loans advertised up to 300 million VND and terms out to 48 months per the app's Play Store listing. The company behind it, formerly Prudential Vietnam Finance, was bought by Shinhan Card in January 2019 (reported at roughly US$150 million). For anyone building on top of that book, the interesting part sits behind an eKYC login: per-borrower applications, repayment schedules, card balances and installment plans that only exist server-side, one account at a time.

The short version: iShinhan is a transactional app, so the data worth integrating is per-user state, not a bulk feed. The route we would actually take is a consent-based interface integration against a live account you control, with the flows re-checked after each app release. Vietnam's regulated Open API framework is the longer-run path; we build so an integration can move onto it without a rewrite.

What data lives inside the app

These are the surfaces a consenting iShinhan session exposes, named the way the app presents them where possible.

Ways in, and the one we would pick

Consent-based interface integration

We stand up an instrumented client against an account you authorize, map the eKYC + OTP session, and read the same endpoints the app calls. Everything in the table above is reachable this way. Effort is moderate; durability tracks iShinhan's release cadence, so front-end changes need a re-check. Access is arranged together at the start of the project — a consenting account on your side is set up during onboarding, not a hoop cleared beforehand.

Vietnam's regulated Open API rail

SBV Circular 64/2024/TT-NHNN put a consent-centric Open API framework in place for the banking sector, effective 1 March 2025 with full implementation reported by 1 March 2027. As standardized endpoints reach a finance company like this one, an integration can shift onto them for higher durability. We register and wire the consent flow when that path opens for the entity.

Single-user consented credential access

For a narrow job — one borrower checking their own status — a user grants a session and we read only that account. It is the lightest option and the easiest to keep within data-minimization limits.

For most buyers today the consent-based interface integration is the one that ships and pays off, because the regulated catalog does not yet cover this servicer end to end; we write the client so that when Circular 64 endpoints land for Shinhan Finance, swapping the transport underneath is a small change rather than a new project.

Request shapes we would confirm during the build

Illustrative only — endpoint names and fields are reconstructed while building against a consenting account, not published contracts. They show the shape a session takes: an eKYC-backed token, then reads of loan and card state, with a guard for the re-verification prompt iShinhan enforces.

# 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.

What lands at the end

Concrete artifacts, each tied to iShinhan's own surfaces:

• An OpenAPI/Swagger specification covering the loan-application, repayment-schedule, card-statement and bill-pay reads.
• A protocol and auth-flow report documenting the eKYC + OTP session, token refresh, and the re-verification 403 path.
• Runnable source for the key endpoints in Python and Node.js, with the re-KYC retry built in.
• Automated tests that exercise a live consented account and flag when a release shifts a field or route.
• Interface documentation an engineer can follow without us in the room.
• Data-retention and consent-record guidance keyed to PDPL Article 27, since loan and card records are sensitive personal data.

Engineering notes for this specific app

Two product realities drive the build, and we account for both. iShinhan carries two lending shapes — the fully automated Express Loan, which signs and disburses in-session off a chip Citizen ID, and the appraisal-based standard loan with its video-call review step. Their status models differ, so we map each product separately rather than assuming one state machine covers both.

The second is eKYC gating. The app blocks online card transactions until biometric and chip-ID data are refreshed, and it will drop a session into a re-verification state mid-flow. We keep a replay harness that re-runs the sign-in and card flows after each iShinhan release, so a version bump that changes the eKYC step is caught before it breaks a customer's sync. Where sandbox or account access is needed, we arrange it with you as part of setup and run the build against a consenting account.

Consent and Vietnamese law

The dependable basis for reading iShinhan data is the account holder's explicit consent. Vietnam's Personal Data Protection Law (Law 91/2025/QH15) took effect on 1 January 2026 and, per legal summaries, treats financial and credit records as sensitive personal data: consent must be specific to each purpose, pre-ticked boxes and silence do not count, and a breach touching credit information must be notified within 72 hours. Article 27 bars scoring credit information without consent. On top of that, SBV Circular 64/2024 governs how Open APIs and customer data-sharing work across the banking sector as that rail rolls out. We operate inside both: authorized, logged access; consent records retained; data minimized to the requested fields; and an NDA where the engagement calls for one.

Working with us

A working build lands in one to two weeks: a running client for iShinhan's loan-status and card reads, its OpenAPI spec, the auth-flow report, and tests. Two commercial shapes cover it. Source-code delivery starts at $300 — you get the runnable source and documentation, and you pay after delivery once the result satisfies you. Or take the hosted route: we run the endpoints, you call them and pay per call, with no upfront fee. Tell us the app and what you want out of its data and we scope it from there — start a conversation on the contact page.

Where this gets used

• A lending marketplace mirrors a borrower's iShinhan application status and contract terms into its own dashboard, with the borrower's consent.
• A personal-finance app pulls card balance plus open 0% installment plans so a user sees their real Shinhan Finance liability in one place.
• An SME accounting tool reconciles utility bill payments made through iShinhan against its ledger.
• A collections or servicing team tracks repayment schedules and due dates across a consented set of accounts.

Interface evidence

Store screenshots of iShinhan, useful for mapping the flows we integrate. Select one to enlarge.

How this was checked

Data domains and product details come from the iShinhan Play Store listing and Shinhan Finance's own newsroom; the regulatory picture from reporting on SBV Circular 64/2024 and Vietnam's PDPL; and the operator background from coverage of the Prudential Vietnam Finance acquisition. Checked July 2026.

• iShinhan on Google Play
• Shinhan Finance — credit-card features on iShinhan
• Vietnam's SBV Circular 64/2024 on Open APIs
• Vietnam's Personal Data Protection Law

Mapped by the OpenBanking Studio integration desk · 2026-07-01

Similar apps in the same market

Others in Vietnam's consumer-finance space hold comparable per-user data; a unified integration usually spans several of them.

• FE Credit — VPBank's consumer-finance arm and the market's largest, holding personal loans, credit cards and installment records.
• Home Credit (Home Credit Digi-Finance) — installment and cash loans with fast in-app approval, plus repayment schedules.
• HD Saison — installment lending across motorbike, durable-goods and cash loans, with a wide referral footprint.
• Mcredit — the MB Bank / Shinsei joint venture offering cash and installment loans behind an authenticated account.
• My Finance (Mirae Asset VN) — unsecured consumer and vehicle loans with online servicing.
• MB Shinsei Finance — cash and installment loans through Military Bank's finance venture.
• JACCS Vietnam — installment financing for consumer goods and vehicles with per-contract schedules.
• Viet Credit — card-linked consumer lending with in-app repayment and statements.

Questions integrators ask

Which iShinhan records can a consented integration reach?

Everything a logged-in user sees: loan applications and their e-signed contracts, repayment schedules, credit-card accounts and limits, 0% installment plans, cardless-withdrawal requests, utility bill payments, and eKYC status. Each field is pulled only for the account that granted consent and only for the fields your use case needs.

Does Vietnam's SBV Open API circular cover a finance company like Shinhan Finance?

Circular 64/2024/TT-NHNN set the banking-sector Open API rail, effective 1 March 2025 with full implementation reported by 1 March 2027. Whether Shinhan Vietnam Finance is inside the initial catalog is not publicly confirmed, so the dependable basis today is the account holder's own authorization. We move an integration onto the regulated rail as it covers the entity.

How do you handle iShinhan's biometric and chip-ID re-verification during a sync?

iShinhan asks users to refresh biometric data and chip-based Citizen ID before online card transactions stay open. We design the session layer to detect that re-verification state and re-run the eKYC step, so the sync recovers instead of failing silently when a re-KYC prompt fires.

Can you pull a single borrower's loan status without touching the whole book?

Yes. A user-consented session reads only that borrower's applications, contract terms and repayment schedule, minimized to the fields requested. This fits PDPL Article 27, which treats credit records as sensitive personal data requiring explicit, purpose-specific consent.