Reaching loan, repayment and KYC data inside Think Vay

A Think Vay account carries a live loan ledger: a credit limit the listing puts at up to VND 50,000,000, a drawn balance, and a repayment schedule running a stated 93 to 365 days at an APR the app caps at 20% per year. Behind that sits the borrower's verified identity and the same-name bank account a disbursement lands in. That is server-side, per-user, structured state — the kind a downstream lender, a collections system, or an account-aggregation product wants to read in a consistent shape. This brief maps what is there and the authorized way to reach it.

What a Think Vay account actually holds

The fields below come from how the app describes its own flow on the Play Store and in-app copy. Granularity is what an integrator should expect to normalize, not a guaranteed schema.

Authorized routes into the loan ledger

Two routes fit this app well, with native export as a thin third where it exists.

1 — Consented interface integration / protocol analysis

We work through the app's own authenticated session, under the borrower's consent, and document the request and response shapes for the loan, repayment and disbursement surfaces. This reaches everything a user can see in the app and survives as long as the front end stays stable. It is the route we would build first here, because the data that matters — the live repayment schedule and disbursement records — lives behind the account and a consented session is the cleanest way to it. Access to a consenting account is arranged with you during onboarding.

2 — Regulated Open API consent

Vietnam is standing up a consent-based data-sharing regime: Circular 64/2024/TT-NHNN requires banks to publish Open API catalogs, and Decree 94/2025 opened a sandbox covering Open API sharing, credit scoring and P2P lending. Where a lender or its partner bank participates, we build to those consented endpoints, which gives the most durable feed. The mechanism is still rolling out, so we treat it as the forward path and lean on the consented-session route for coverage today.

3 — Native export

Where the app or its support channel produces statements or a data export, we parse and normalize that as a fallback for record-keeping. It is the least real-time of the three.

What lands in your repository

Each item is tied to a real Think Vay surface, not a generic checklist.

• An OpenAPI/Swagger specification covering loan-status, repayment-schedule, disbursement and KYC-status reads.
• A protocol and auth-flow report — the login, token and session-refresh chain as it actually behaves on this app.
• Runnable source for the key endpoints in Python or Node.js, with the request/response models filled in.
• Automated tests covering the repayment-schedule and disbursement parses, including arrears and early-settlement edges.
• Interface documentation, plus consent-record and data-retention guidance shaped to Vietnam's rules.

A repayment-schedule pull, sketched

Illustrative only — field names and the exact auth handshake are confirmed during the build, not asserted here.

POST /auth/session            # consented login, returns short-lived token
  { "phone": "+84...", "otp": "******" }
  -> { "access_token": "...", "expires_in": 900 }

GET /loans/active             # Authorization: Bearer <token>
  -> { "loan_id": "...",
       "limit_vnd": 50000000,        # ceiling per the listing
       "principal_vnd": 2000000,
       "apr_pct": 20.0,              # capped at 20%/yr per app copy
       "term_days": 180,
       "disburse_account": { "holder_match": true, "bank_ref": "..." } }

GET /loans/{loan_id}/schedule
  -> [ { "due_date": "2026-07-09",
         "principal_vnd": ..., "interest_vnd": ..., "status": "due" }, ... ]

# error handling: 401 -> refresh via /auth/session; 423 -> KYC step incomplete

The KYC-incomplete state is worth handling explicitly: a loan record can exist while identity verification is still pending, and code that assumes a verified borrower will mis-read those rows.

Consent under the State Bank of Vietnam's rules

The dependable legal basis here is the borrower's own, explicit consent. Decree 13/2023/ND-CP made prior explicit consent the main ground for processing personal data, and the Law on Personal Data Protection that takes effect 1 January 2026 keeps that consent-centric stance with stronger withdrawal rights. We capture consent scope, expiry and a revocation path, and we keep the loan and identity data minimized — verification status and a bank reference rather than the raw CCCD image. Where the Open API framework under Circular 64/2024 and Decree 94/2025 applies through a participating bank, the same consent records carry across to it. Work runs under NDA where a counterparty needs one, with access logged.

Build details we plan around

We design the sync around the consent-refresh expectations of Vietnam's Open API rules, so a borrower's consent window is renewed before it lapses instead of the feed going dark mid-cycle. We model the KYC-to-disbursement link — Think Vay verifies identity from a CCCD photo and pays out only to a same-name bank account — so an approved application can be reconciled against the account that actually received funds. And we fold the 93-to-365-day term and the 20% APR cap into the schema, keeping amortization and accrued-interest fields consistent if the app's front end shifts; a re-validation pass is part of how we maintain that. Access to a consenting account or a sandbox is set up with you at onboarding, not something you clear before we begin.

Where integrators put this data

• A lending marketplace that needs a borrower's live exposure and arrears status before extending more credit.
• A collections or servicing tool that reads the repayment schedule and flags due and overdue instalments.
• An account-aggregation product pulling loan balances into a single Vietnamese-finance dashboard alongside bank and wallet data.
• A reconciliation job matching disbursements against the destination bank account for payout audit.

Screens we mapped

Store screenshots used to orient the surface map. Tap to enlarge.

Other Vietnamese lending apps in the same data shape

These hold comparable per-borrower records, which is why a unified loan-data integration tends to span several of them at once. Listed for context, not ranked.

• Tima — a lending marketplace holding loan listings, repayment records and borrower profiles.
• VayMuon — a P2P platform with loan requests and repayment ledgers per user.
• FE ONLINE 2.0 (FE Credit) — consumer-finance contracts, instalment schedules and disbursement records.
• Home Credit Tài Chính Online — instalment-loan balances and payment history.
• MoneyCat — short-term online loans with limit, due dates and KYC.
• Doctor Dong — small online loans, application status and repayment schedule.
• Cake by VPBank — a digital bank holding account balances alongside card and loan data.
• Vietdong — fast online loans with per-loan amount and term records.

Sources and how this was put together

The data domains came from Think Vay's own Play Store listing and in-app description; the regulatory framing from primary legal write-ups read in June 2026. Key references: Play Store listing, VILAF on Decree 94 and Open API, Tilleke & Gibbins on the sandbox decree, and Hogan Lovells on the Personal Data Protection Law.

Mapped by the OpenBanking Studio integration desk · reviewed 2026-06-25.

Questions integrators ask about Think Vay

Which data inside a Think Vay account is worth pulling?

The loan limit and drawn balance, the repayment schedule across the stated 93-to-365-day term, disbursement records, and the KYC identity tied to the borrower's own-name bank account. Those are the surfaces a third-party lender, collections workflow or aggregator would want to sync.

Does Vietnam's Open API regime cover an app like Think Vay?

Circular 64/2024/TT-NHNN and Decree 94/2025's sandbox set the consented data-sharing framework around banks and fintechs supervised by the State Bank of Vietnam. We build to the borrower's own authorization and consent records regardless of where a given lender sits in that rollout, since the consumer's consent is the dependable legal basis today.

How do you handle the CCCD identity-verification step?

We treat it as a KYC surface: we capture verification status and the linked disbursement account rather than the raw ID image, and keep the whole flow data-minimized and logged so only what the integration needs is retained.

Can we take just the repayment-schedule endpoint instead of the whole app?

Yes. A single surface can be scoped on its own and delivered as runnable source for that endpoint or as one hosted endpoint you call per request, without commissioning a full mapping of the app.

On cost: source code lands in your repository from $300, billed only after delivery once you are satisfied; or skip the build and call our hosted endpoints, paying per call with nothing upfront. Either way the cycle is one to two weeks. Tell us the app and what you need from its data and we take it from there — start a project.