Integrating the loan ledger a GemCredit account holds

A GemCredit account carries the whole life of a consumer loan: a principal that runs between 5 and 35 million VND per the app's own description, a term of up to 12 months, the interest and any fees shown on screen before the borrower signs, then the repayment schedule, the running payoff balance and a timestamped transaction history. That is real, per-user, server-side state — the kind a lender, a collections partner or a personal-finance product wants to read and keep in sync. Vietnam's open-banking rules are arriving around it at the same time, which shapes the route. This brief sets out where that data lives, the authorized way to reach it, and what we hand over.

The working judgment up front: the borrower-facing app is the complete, live surface for a GemCredit loan, so the integration is built by analysing that app's own traffic under the account holder's authorization, with the consented Open API path that Circular 64 is phasing in folded in for the bank rails as it becomes available. We do the interface work; the client supplies the app name and what they need from the data.

What the account holds

Each row below is a surface the GemCredit app exposes to its own user, named the way the app's description names it where possible. The integration reads these the way the account holder already sees them.

Routes in

Three routes genuinely apply to GemCredit. They are not alternatives so much as stages that overlap.

Authorized protocol analysis of the borrower app

The mobile client holds the full ledger, so we capture and document its own request/response traffic under the account holder's authorization: the register-and-verify handshake, the session token and its refresh, then the profile, schedule, balance and history calls. Reachable: everything the app shows its user. Effort: moderate, mostly in mapping the auth chain and pagination. Durability: tied to app releases, which we manage with versioned fixtures. We set up the working environment with the client — a consenting borrower's account or a test account arranged during onboarding.

User-consented account access

Run against a consenting borrower's live session to pull current schedule, payoff and transaction data on a schedule you control. This pairs with the first route and is what keeps a sync fresh. Consent scope and revocation are recorded, per the PDPL.

Circular 64 consented Open API (the bank rails)

GemCredit's money moves through a bank account in the borrower's name. As Vietnamese banks bring consented Open API queries online under Circular 64 — the customer-consented information phase lands within 18 months of the 1 March 2025 effective date — those queries become a sanctioned way to confirm disbursements and repayments against the bank side. We design the build so it can move onto that call without a rebuild. Native in-app export, where a borrower can pull their own history, serves as a manual cross-check during validation.

The schedule call

This is illustrative — the field names and shape are confirmed during the build against the live app, not lifted from any published GemCredit document. It shows the auth handshake and a repayment-schedule read, using the worked figures from the app's own example loan.

# Device-bound session after register / OTP verify
POST /v1/auth/token
  { "phone": "+84xxxxxxxxx", "device_id": "…", "otp": "######" }
  -> 200 { "access_token": "…", "refresh_token": "…", "expires_in": 1800 }

# Read the repayment plan for one loan
GET /v1/loans/{loan_id}/schedule
  Authorization: Bearer <access_token>
  -> 200 {
       "loan_id": "…",
       "principal_vnd": 10000000,     # integer VND, no minor unit
       "term_months": 12,
       "apr_pct": 21.9,
       "outstanding_vnd": 12190000,
       "installments": [
         { "due_date": "15/07/2026", "amount_vnd": 1015833, "status": "due" },
         { "due_date": "15/08/2026", "amount_vnd": 1015833, "status": "scheduled" }
         # …
       ]
     }

# 401 -> refresh once. Persistent 401 -> consent withdrawn or session
# revoked: stop the pull, log it, do not retry.
      

Note the dd/mm/yyyy dates and the decimal-free VND. Both get normalized on the way into the canonical schema so figures reconcile.

What you receive

The deliverables are tied to GemCredit's actual surfaces, not a generic kit:

• An OpenAPI/Swagger specification covering the auth, loan-profile, schedule, balance and transaction-history endpoints.
• A protocol and auth-flow report: the register/verify chain, the bearer token, refresh behaviour and the revocation signal.
• Runnable source — Python or Node.js — for the schedule, payoff and history pulls, with paging handled.
• Automated tests, including token-refresh, an expired-consent path, and VND/date normalization checks.
• Interface documentation a developer who has never seen the app can follow.
• Consent-record and retention guidance written against the PDPL, so what you build is defensible.

Circular 64 and the PDPL

Two Vietnamese rules frame this work, and they are recent. Open banking runs under Circular 64/2024/TT-NHNN, issued by the State Bank of Vietnam and effective 1 March 2025; it phases standardized Open APIs in over three windows — public information queries first, customer-consented information queries (the Account Information Services style of access) next, and payment initiation last — with banks filing API catalogs by mid-2025 and full compliance due 1 March 2027. For a non-bank lender that mainly governs the bank rails the loan rides, which is why we treat the borrower app as the live surface now and the consented Open API as the durable path for the bank side.

Personal data sits under the Law on Personal Data Protection, in force since 1 January 2026, which replaced Decree 13/2023/ND-CP and raised both the consent bar and the penalties. We work consent-first: every pull is bound to a recorded, revocable consent with a stated purpose; access is logged; data is minimized to what the integration needs; and NDAs are in place where the engagement calls for it. The separate fintech sandbox under Decree 94/2025/ND-CP, live since 1 July 2025, governs P2P-lending and credit-scoring pilots — relevant context if a GemCredit-adjacent product enters supervised testing, less so for reading an existing account.

Details we account for

Concrete things this app forces, and how we handle them on our side:

• VND and Vietnamese locale. Amounts are large integers with no decimal subunit and dates are dd/mm/yyyy. We canonicalize both at the boundary so the 1,015,833 VND-per-month figure and the ~12,190,000 VND payoff reconcile cleanly downstream.
• Consent lifecycle. We design the sync around the PDPL consent and revocation model, so a borrower withdrawing consent propagates immediately, the pull halts, and the event is logged — never a silent, stale fetch.
• Front-end churn. The profile and schedule screens shift between app releases. We keep versioned fixtures of the schedule, balance and history responses and re-check them against each release, so a UI change shows up as a failing test rather than quiet data drift.
• Bank-rail timing. Disbursement and repayment touch a bank account in the borrower's name. We model the flow of funds across the lender ledger and that bank, and structure the call so it can switch to a Circular 64 consented query as banks expose it.

Access and onboarding are arranged with you as part of the project — a consenting account or a test environment set up together. That is our step, handled during the build.

Where the data goes

Common jobs this integration feeds:

• A collections or servicing platform that needs each borrower's due dates and current payoff to time reminders and settlements.
• A personal-finance or debt-aggregation app pulling a consenting user's schedule and history into one view of their obligations.
• A lender-side reconciliation job matching the in-app transaction history against the disbursement bank account.
• An analytics pipeline tracking application-to-approval state and APR against the 21.9% ceiling.

Screens we mapped

Store screenshots used while mapping the surfaces above. Select to enlarge.

Similar Vietnamese apps

Other consumer-finance apps in the same Vietnamese market hold comparable account data; a single normalized schema lets one integration cover several of them. Named here for context, not ranking.

• Home Credit (Tài Chính Online) — consumer installment and cash loans with in-app repayment schedules and balances.
• FE Credit (FE ONLINE) — cash loans, cards and installment plans, each with its own account ledger.
• Mcredit — the MB-linked consumer finance arm, holding loan accounts and repayment data in-app.
• Mirae Asset Finance Vietnam — consumer and installment lending with account-bound statements.
• Lotte Finance — consumer credit and card accounts managed through its app.
• Shinhan Finance — consumer lending accounts, schedules and payoff figures.
• Cake by VPBank — a digital bank that also extends loans, holding balances and transaction history.
• Doctor Dong — short-term online loans with application status and repayment tracking.
• Tima — a loan-connection platform holding borrower application and matching records.

How this was put together

The data surfaces come from GemCredit's own Play Store listing and description (loan size, term, the 21.9% APR ceiling and the worked repayment example); the regulatory framing from the State Bank of Vietnam's Circular 64 on Open APIs, the 2025 Law on Personal Data Protection, and the Decree 94 fintech sandbox. Checked June 2026 against the sources below.

• GemCredit on Google Play (pb.publicbankamc.vn)
• Circular 64/2024/TT-NHNN — Vietnam Open API framework
• Vietnam Law on Personal Data Protection (PDPL 2025)
• Decree 94/2025/ND-CP — fintech regulatory sandbox

Mapped by the OpenBanking Studio integration desk · June 2026.

Questions integrators ask

Which data inside a GemCredit account is worth pulling?

The loan profile a borrower files, the amount-and-term offer with its interest, fees and schedule shown before signing, the repayment schedule with each due date, the running payoff balance, and the timestamped transaction history. The disbursement and repayment bank account in the borrower's name ties all of it to flow of funds.

Does Circular 64 change how we reach GemCredit's data?

Circular 64/2024/TT-NHNN from the State Bank of Vietnam, effective 1 March 2025, phases in consented Open API queries on the bank side, including Account Information Services. The live surface today is the borrower app itself, worked under the borrower's authorization; the consented-query phase becomes the durable path for the disbursement and repayment bank rails as it comes online.

How do you handle a borrower who withdraws consent under the PDPL?

We build consent records and revocation into the sync so a withdrawal stops the pull and is logged, in line with Vietnam's Law on Personal Data Protection, in force since 1 January 2026. Consent scope, purpose and retention are recorded against each pull rather than assumed.

Everything is in VND and Vietnamese dates. How is that normalized?

We normalize VND amounts as integers with no minor unit and convert dd/mm/yyyy due dates into ISO dates inside a canonical schema, so the schedule, interest and payoff figures reconcile against whatever system consumes them.

Source code is the deliverable: runnable pulls for the schedule, balance and transaction-history endpoints, an OpenAPI spec, tests and documentation, priced from $300 and billed only after delivery, once you have checked it works against your own GemCredit data. Prefer not to host anything? The same endpoints run as a pay-per-call hosted API with no upfront fee — you call, you pay for calls. Either way the cycle is one to two weeks. Tell us the app and what you need from its data, and the access and compliance pieces get arranged with you from there — start a GemCredit integration.