VayTínPhát app icon

Consumer lending · Vietnam

What VayTínPhát holds once a borrower registers by phone

Register a phone number, clear the 18-plus and Vietnamese-citizen check, and VayTínPhát starts keeping a server-side record: the amount asked for (3,500,000 to 20,000,000 VND, per its Play Store listing), the term in days, an APR band, and a repayment total it works out to the dong. That record — not any marketing screen — is what a partner, a collections workflow, or a borrower-facing dashboard actually wants to read. The app reaches a backend after an OTP sign-up, and everything useful sits behind that one session.

The data behind the login

These are the surfaces the app exposes to a signed-in user, named as close to the app's own flow as the listing allows. An integrator reads them, normalizes them, and serves them back as JSON.

Data domainWhere it comes from in the appGranularityWhat you do with it
Borrower identity / KYCPhone registration plus the guided info entry (age, citizenship, income declaration)One profile per registered numberMatch a borrower to your own records; gate downstream pulls on KYC state
Loan applicationsThe "submit loan request" step and the receive-evaluate-respond flowPer application, with a statusTrack an application from submitted to a decision without screen-scraping
Product termsThe reference loan table: limit, term, APR, service fee, overdue feePer product / per offerDrive eligibility and quote logic from live terms, not hard-coded numbers
Repayment mathThe worked example: interest, service fee, net disbursed, total repayablePer application scheduleReconcile a borrower's balance and due total to the dong
Fee and penalty ledgerService fee (1–5%) and the daily overdue charge (max 0.1%/day, capped at 18%)Per application, accruedFeed collections, delinquency reporting, and dunning logic

Routes into the loan backend

Three routes genuinely apply to an app shaped like this one. Each is described by what it reaches, how durable it is, and what we set up to run it with you.

Protocol analysis of the authenticated app

We map the traffic between the app and its backend after a real OTP sign-up: the auth handshake, the bearer token it hands back, and the calls for the product catalog, application submit, application status, and the repayment schedule. This reaches everything a signed-in borrower can see. Durability is good as long as we account for app updates — see the build notes. Onboarding is simple: access is arranged with you, and the build runs against a consenting account we register together.

User-consented session access

Where the borrower is your own customer, they consent and we operate the same session on their behalf to pull their application and schedule. This is the cleanest fit for a borrower dashboard or a servicing tool, and it keeps consent explicit and logged.

Regulated open-data participation

Vietnam now has a formal open-data track. The State Bank's Circular 64 Open API regime and the Decree 94 sandbox — which covers Open API, technology-based credit scoring, and P2P lending, drawing on National Credit Information Centre data — both move data on customer consent. Where the operator participates in that track, consent-based sharing through standardized APIs becomes the durable, regulator-blessed path. Until then it sits alongside the working route rather than replacing it.

For VayTínPhát as it stands, protocol analysis of the authenticated app is the route we would build first: it is a self-contained lender reached after a phone-OTP registration, so the data lives in its own session, and reading that session under consent gets you the applications, terms and schedules directly. The consented-session variant layers on top when the borrower is yours; the regulated track is where this moves as the operator joins Vietnam's open-API regime.

Reading the session and application calls

A sketch of the shape we confirm during the build. Endpoint paths and field names are settled against live traffic, not copied from any VayTínPhát document.

# Illustrative. Field names verified during the build.

POST /api/v1/auth/otp/verify
  { "phone": "+8490xxxxxxx", "otp": "xxxxxx", "device_id": "..." }
  -> 200 { "access_token": "ey...", "expires_in": 3600, "customer_id": "..." }

GET /api/v1/loan/applications        Authorization: Bearer ey...
  -> 200 {
       "application_id": "...",
       "status": "under_review",        # tiep nhan -> danh gia -> phan hoi
       "principal_vnd": 20000000,
       "term_days": 91,
       "apr_pct": 12.0,
       "service_fee_vnd": 600000,
       "net_disbursed_vnd": 19400000,
       "total_repayable_vnd": 20604931.5
     }

# Reconcile, do not trust a single field:
#   interest = principal * apr/100 / 365 * day_count
#   total    = principal + interest + service_fee
on_token_expiry: re-run otp/verify, retry once, then surface a clear error
      

What lands in your repository

Each deliverable is tied to a surface above, not a generic checklist.

  • An OpenAPI 3 specification covering OTP verify, the application list and status, the product/terms catalog, and the repayment schedule.
  • A protocol and auth-flow report documenting the OTP-to-bearer-token chain, token lifetime, and the re-authentication path.
  • Runnable client source in Python and Node.js for those endpoints, with the interest and fee math implemented to reconcile to the dong.
  • An automated test set that asserts a clean session refresh and checks the computed total against the listing's worked example.
  • Interface documentation plus data-retention guidance written against Vietnam's PDPL, including consent capture and minimization.

One normalized loan record

The shape we serve back, so the dong-level math is yours to verify rather than trust.

{
  "borrower":     { "customer_id": "...", "kyc_status": "verified" },
  "application":  { "id": "...", "status": "under_review",
                    "requested_principal": { "amount": 20000000, "currency": "VND" },
                    "term_days": 91, "apr_band_pct": [3, 12] },
  "schedule":     { "interest_vnd": 604931.5, "service_fee_vnd": 600000,
                    "net_disbursed_vnd": 19400000, "total_due_vnd": 20604931.5 },
  "penalty":      { "daily_rate_pct": 0.1, "cap_pct": 18 }
}
      

Vietnamese consent and data rules in play

This is borrower financial data in Vietnam, so the privacy regime is specific. The Personal Data Protection Law (Law 91/2025/QH15) has been in force since 1 January 2026, per Vietnam Briefing, replacing the 2023 personal-data decree; consent under it must be voluntary, specific and informed, and its finance provisions mean credit information is not used for scoring without consent. We build to that: explicit consent capture, consent and access logging, data minimized to the fields a use case needs, and NDAs where a client requires them. On the open-data side, the State Bank's Circular 64 Open API regime and the Decree 94 sandbox both run on customer consent, so the lawful basis is the same whichever route the work takes — the borrower's authorization is the dependable footing, and the regulated APIs are where the route moves as participation grows.

What the build accounts for

Two things specific to this app shape the work, and we handle both rather than hand them back as conditions.

First, the session. The token issued after OTP verification is short-lived and the registration is tied to a device. We map the verify-and-refresh flow and pin the build to a registration we set up with you, so the sync re-authenticates on its own instead of tripping a rate limiter or silently dropping out mid-pull. Second, the money. Limits, term, APR band and service fee vary by product, and the listing's own example computes interest over a 92-day count on a 91-day term, so we model the product table as data and recompute every figure the way the app does — interest, service fee, net disbursed, total repayable — and assert it reconciles to the dong before any number reaches you. When the app ships an update, field names or the submit payload can move; we keep a small contract-test set that flags a changed response shape early, and refresh the mapping as routine upkeep.

Screens behind the brief

The app screens we referenced while mapping the flow. Tap to enlarge.

VayTínPhát screen 1 VayTínPhát screen 2 VayTínPhát screen 3 VayTínPhát screen 4

The same per-borrower records — applications, terms, schedules, fee ledgers — sit behind a row of comparable apps. Naming them maps the wider picture a single, normalized integration would cover.

  • Doctor Đồng — short-term online cash loans; holds application, disbursement and repayment records behind an account.
  • MoneyVeo — instant personal loans with ID-based onboarding; keeps loan status and schedule data per user.
  • Cashwagon — first-loan-focused consumer lending; per-borrower application and repayment history.
  • iVAY — online lending by ID card; stores borrower profile, loan state and due amounts.
  • Tamo — short-term installment loans; account-bound application and schedule records.
  • MoneyCat — small-ticket online loans; holds limits, terms and repayment ledgers per user.
  • FE Credit — large consumer-finance lender; loan accounts, statements and installment schedules.
  • Home Credit — point-of-sale and cash loans; per-customer contracts, balances and repayment plans.
  • Tima — peer-to-peer lending marketplace; connects borrower applications to lender funding records.

Questions an integrator asks here

Does the loan total your client returns match what the borrower sees in the app?

Yes. We recompute interest the way the app does, principal times APR divided by 365 times the day count, then reconcile the service fee, the net disbursed amount and the total repayable to the dong against the worked example in the app's own listing, so the numbers your integration returns line up with the borrower's screen.

What happens to the integration when the phone-OTP session expires?

The access token issued after OTP verification is short-lived. Our client re-runs the verify step or the refresh call when the token lapses, and the test set asserts a clean re-authentication, so a scheduled pull of application status or the repayment schedule does not stall halfway.

Which Vietnamese rules cover pulling a borrower's loan record?

Vietnam's Personal Data Protection Law, Law 91/2025/QH15, governs consent for personal and credit data, and its finance provisions mean credit information is not scored without consent. The regulated open-data path runs through the State Bank's Circular 64 Open API regime and the Decree 94 fintech sandbox, both of which are consent-based; absent participation in those, the working route is authorized protocol analysis of the app under the borrower's consent.

Can you scope this to just the application-status feed instead of the whole app?

Yes. We can build only the OTP-verify and applications endpoints if status tracking is all you need, and add the product catalog or the repayment schedule later without redoing the auth work.

What we verified

We read VayTínPhát's Play Store listing (the loan terms, fees, worked example and the receive-evaluate-respond flow described there) on 30 June 2026, and checked the Vietnamese regime against primary legal coverage: the State Bank's Circular 64 Open API rollout, the Decree 94 fintech sandbox, and the new Personal Data Protection Law. The package identifier and figures here are taken from that listing and the sources below.

Mapped by the OpenBanking Studio integration desk, June 2026.

Getting the integration built

A working client for the OTP login and the application-and-schedule endpoints is a one-to-two-week build. You can take it as source you run yourself — runnable Python and Node code, the OpenAPI spec, the auth-flow report and the tests, priced from $300 and paid only after delivery once you are satisfied — or skip hosting and call our endpoints instead, paying per call with nothing upfront. Tell us the app and what you need from its data; access and any compliance paperwork are arranged with you as part of the work, not asked of you first. Start at our contact page.

App profile — VayTínPhát

VayTínPhát is a Vietnamese consumer-lending app for personal loan reference and application, published under package com.vay.tin.phat.fly per its Play Store listing. Stated eligibility is age 18 or over, Vietnamese citizenship and a stable income. The flow is: install, register by phone number, enter the requested details, submit a loan request, then the system receives, evaluates and responds. Reference terms on the listing: limit 3,500,000–20,000,000 VND, term 91–365 days, APR 3–12%, service fee 1–5%, and an overdue charge of up to 0.1% per day capped at 18%, with no hidden fees beyond those disclosed. A worked example puts a 20,000,000 VND / 91-day / 12% loan at 604,931.5 VND interest, a 600,000 VND service fee, 19,400,000 VND net disbursed and 20,604,931.5 VND total repayable. The listing gives a Ho Chi Minh City contact address.

Mapping reviewed 2026-06-30.

VayTínPhát screen 1 enlarged
VayTínPhát screen 2 enlarged
VayTínPhát screen 3 enlarged
VayTínPhát screen 4 enlarged