Reaching a borrower's loan record inside Tiền Phong Linh Hoạt

A single approved loan inside this app carries a principal the listing puts at up to 25,000,000 VND, a term it describes as 93 to 365 days, and an APR it states at roughly 18–24% per year. All of that lives server-side, behind a phone-number registration and an SMS-OTP login. The app does not hand a borrower a file to download; the numbers exist as state on the lender's backend, refreshed as repayments post. That is the data an integrator wants, and the practical way to reach it is to work the app's own authenticated session under the account holder's consent.

This page maps what Tiền Phong Linh Hoạt holds per user, the authorized route we would take to read it, and what we hand back at the end. The lender is a finance company rather than a bank, which shapes how Vietnam's open-banking rules apply — covered below.

What the account stores

Each row below is a surface a logged-in borrower can see in the app, mapped to where it originates and what an integrator does with it. The numbers come from how the listing describes the product, not from a price sheet we can quote as fixed.

Repayment-schedule call

The shape below is illustrative — the exact field names get confirmed during the build against a consenting account. It shows how we would model the installment read: a bearer token from the OTP login, an account identifier, and a normalized schedule back. Errors get mapped to a stable set rather than passed through raw.

POST /auth/otp/verify          # phone + OTP -> short-lived bearer token
  { "phone": "+84…", "otp": "######" }
  -> { "access_token": "…", "expires_in": 900, "refresh_token": "…" }

GET  /loan/{loanId}/schedule    # Authorization: Bearer <access_token>
  -> {
       "loan_id": "…",
       "principal_vnd": 10000000,
       "apr_pct": 24.0,
       "term_days": 180,
       "installments": [
         { "seq": 1, "due_date": "2026-07-27", "principal_vnd": 1666667,
           "interest_vnd": 200000, "status": "due" },
         { "seq": 2, "due_date": "2026-08-27", "principal_vnd": 1666667,
           "interest_vnd": 200000, "status": "scheduled" }
       ]
     }

# Handling notes captured during the build:
#  401 -> token expired, run refresh, retry once
#  429 -> back off, the app rate-limits the session
#  re-auth needs a fresh OTP when refresh_token is rejected

The example figures mirror the repayment math the listing itself walks through for a 10,000,000 VND, 180-day loan at 24% APR. They illustrate the structure, not a quote.

The package you get

For an app of this shape the deliverable set is concrete:

• An OpenAPI/Swagger spec covering the login, token refresh, loan summary and schedule reads.
• A protocol and auth-flow report documenting the OTP exchange, the bearer-token chain, refresh behaviour and rate limits.
• Runnable source for the key endpoints in Python or Node.js, with the schedule normalized into the schema your side expects.
• Automated tests against captured fixtures so a front-end change is caught early.
• Interface documentation, plus data-retention and consent-record guidance written for Vietnamese requirements.

Each piece is tied to a surface that actually exists in the app — the installment schedule, the limit, the application status — not a generic CRUD stub.

Routes to the data

Authorized interface integration of the consented session

We work the app's own traffic: the OTP login, the token issuance, the loan and schedule reads. This reaches everything a borrower sees and is the route that does not depend on a bank-side rail existing. Effort is moderate; durability depends on how often the front end shifts, which we account for in maintenance. This is the route we would actually run for Tiền Phong Linh Hoạt — it is the only one that returns the full loan lifecycle for a finance-company product, and it is the kind of build we deliver routinely.

Open-API consent under Circular 64

For the disbursement bank account specifically, Vietnam's bank-side open-API framework is the clean rail. It is forward-looking for a non-bank lender and useful where the linked bank participates; we set up the consent path with you where it fits.

User-consented credential access

The borrower authorizes the access and we operate the session on their behalf, with the consent recorded. This is the lightest path for a single-account or pilot integration and the access is arranged with you during onboarding.

Consent & Vietnamese rules

Personal data here is governed by Vietnam's Law on Personal Data Protection (Law 91/2025/QH15), in effect since 1 January 2026 and replacing Decree 13/2023/ND-CP, alongside the Law on Cybersecurity. Prior, explicit, informed consent is the working basis — silence does not count as consent under that regime, and the new law adds finance-specific handling rules. On the banking side, Circular 64/2024/TT-NHNN from the State Bank of Vietnam, in force since 1 March 2025, sets the open-API and customer-consent framework for banks, with full compliance staged toward 2027 as the SBV describes it.

We operate authorized, logged and data-minimized. The consenting borrower's grant is the dependable basis for the read; consent scope, expiry and revocation are recorded, eKYC artifacts are kept out of the surface unless a project scopes them in, and an NDA is in place where the work needs one.

Engineering we plan around

A few things about this app shape the build, and we handle each:

• The login is phone-plus-OTP with a short-lived bearer token. We design the sync to refresh cleanly and to request a fresh OTP only when the refresh token is rejected, so the session does not silently die mid-pull.
• The limit and APR are set per borrower by the appraisal, not fixed product values. We read the schedule and pricing as returned per account rather than hardcoding the 25M / 18–24% figures the listing quotes.
• eKYC capture (face, CMND/CCCD/passport) is sensitive under Vietnamese law. We data-minimize it out of the integration surface by default and only touch it when a project explicitly requires identity matching.
• The repayment schedule is live state across a 93-to-365-day term. We re-check the captured flows when the app updates its screens, so a layout change does not quietly break reconciliation.

Screens we mapped

Public store screenshots we reviewed while sketching the surfaces above. Click to enlarge.

Keeping the sync current

The token from the OTP login is short-lived. The schedule changes as each installment posts. So a one-time pull goes stale fast. We poll the account or fire events around the repayment calendar, refresh tokens ahead of expiry, and treat the captured screen flows as something to re-validate when the app ships an update. The cadence is tuned to the term length so an integration of a 180-day loan is not hammering the session daily for data that moves monthly.

Other VN lending apps

Same category, often the same integration question — listed for context, not ranked.

• Doctor Dong — short-term online cash loans; holds per-user limits and repayment timelines much like this app.
• MoneyCat — CCCD-only online lending up to around 10 million VND; account state covers loan status and schedules.
• Tamo — small short-term loans with first-loan promotions; per-user loan and repayment records.
• Robocash — installment loans over 91–180 day terms; structured per-user schedule data.
• Moneyveo — personal loans with tiered first/repeat limits; underwriting and repayment records per account.
• FE Credit (FE ONLINE) — finance-company cash loans, ID-based onboarding; rich account and installment data.
• Home Credit — consumer and installment lending across many products; per-customer loan ledgers.
• Movi — quick-cash loans via partner credit institutions; per-user balances and disbursement records.

A unified integration across several of these normalizes limits, schedules and statuses into one schema, which is where most multi-app projects head.

Integrator questions

Which loan-lifecycle records can an integration read from a consenting Tiền Phong Linh Hoạt account?

The records a borrower sees once logged in: the approved limit and disbursed principal, the installment schedule with per-period dates and amounts, the stated APR and term, application and approval status, and the linked disbursement bank account. eKYC capture is treated as sensitive and stays out of the integration surface unless a project explicitly scopes it in.

Does Vietnam's Circular 64 on open APIs cover a non-bank lender like this one?

Circular 64/2024/TT-NHNN, in force since 1 March 2025 per the State Bank of Vietnam, sets the open-API framework primarily for banks. For the disbursement bank link it is the relevant rail, but a finance-company loan product like this is reached in practice through authorized interface integration of the app's own session, with the borrower's consent recorded.

How do you handle the OTP and eKYC steps when building against this app?

We design the flow around the phone-number registration and SMS-OTP login, capture the token issuance and refresh, and re-authenticate the sync cleanly when a token expires. Face and ID-document capture is data-minimized and excluded from the integration unless a project needs it, in which case it is logged and handled under Vietnamese data law.

What keeps changing after a loan is disbursed, and how does the sync stay current?

The installment schedule moves as payments post, so outstanding principal, the next due date and the paid/unpaid state of each period change over the 93-to-365-day term. We poll the account or schedule events around the repayment calendar rather than caching a static plan, and re-check the captured screens when the app updates its front end.

What we checked

We read the app's own Play Store listing for the product mechanics (limit, term, APR, the OTP-and-eKYC onboarding and the worked repayment example), then confirmed the regulatory picture against Vietnam's open-API circular and its personal-data law. Sources opened:

• Tiền Phong Linh Hoạt — Google Play listing
• Circular 64/2024/TT-NHNN — Open API in banking, from 1 March 2025
• Tilleke & Gibbins — Vietnam open-API circular analysis
• Hogan Lovells — Vietnam's Personal Data Protection Law (Law 91/2025)

Mapping reviewed 2026-06-27 by the OpenBanking Studio integration desk.

Working with us

Most builds against an app this size finish inside one to two weeks. You give us the app name and what you want out of its loan data; we arrange the access and the consent path with you and do the rest. Take it as source-code delivery — runnable API source, the OpenAPI spec, the tests and the interface docs — from $300, paid only after delivery once the build satisfies you. Or skip the source entirely and call our hosted endpoints, paying per call with nothing upfront. Either way, tell us what you need on the contact page and we will scope it.