Reaching VayGo's borrower, loan and repayment records

A VayGo account turns a phone number, an ID-card photo and one active bank account into a live loan file: principal between roughly 9 and 20 million VND, a term of 91 to 365 days, and a repayment schedule the app computes from the borrower's job, the amount and the tenor (all figures as stated on its store listing). That schedule — not the marketing copy around it — is the asset an integrator wants. Pulling it out reliably, with the borrower's consent, is the whole job.

This brief maps what VayGo holds, the authorized way to reach each surface, and what we hand back. The route we recommend below is documented protocol analysis of the consented app session, structured to fit Vietnam's Open API rules as they come into force.

What VayGo holds, surface by surface

Each row is a real screen or step in the app's flow, not a generic lending checklist.

Authorized routes to that data

Consented protocol analysis of the app session

We observe the traffic VayGo's own client generates after a borrower consents — registration, OTP exchange, application submit, schedule fetch — and rebuild those calls as a documented client. Reachable: every surface in the table above, at the same freshness the app sees. Effort is moderate; durability depends on how often the front end shifts, which we cover in maintenance. We set up the capture environment and the consenting test account together with you during onboarding.

SBV Open API consent, as the regime matures

Circular 64/2024/TT-NHNN brings standardized, consent-gated bank APIs into force from 1 March 2025, with bank catalogs due mid-2025 and full compliance by 1 March 2027. Where VayGo's disbursement bank exposes account and transaction data under that scheme, the linked-account and payout surfaces can be read through a regulated channel instead of inferred. We build the consent handshake (OAuth 2.0, the standard Circular 64 names) and wire it in as banks publish.

User-consented credential access

For a borrower acting on their own data, a consent-scoped login against the app session retrieves their application and schedule directly. Narrow by design, audited per access, useful for single-user portals rather than fleet sync.

Our recommendation for VayGo is concrete: drive the day-one build off consented protocol analysis, because it reaches the loan and repayment surfaces today, and fold in the SBV Open API channel for the bank-account leg as the borrower's disbursement bank goes live under Circular 64. That gives you working data now and a regulated path for the most sensitive field later.

A sample call against the loan surfaces

Illustrative shapes confirmed against the observed flow during the build — field names are normalized, not lifted verbatim from the wire.

POST /v1/session/otp/verify
{ "phone": "+84xxxxxxxxx", "otp": "######", "device_id": "..." }
-> 200 { "access_token": "...", "expires_in": 900, "member": true }

GET /v1/loan/applications?status=active
Authorization: Bearer <access_token>
-> 200 {
     "application_id": "VG-...",
     "principal_vnd": 20000000,
     "term_days": 91,
     "apr_pct": 7.3,            // within the listed 7–12% band
     "daily_rate_pct": 0.02,
     "advisory_fee_pct": 0,     // listed range 0–5%
     "schedule": [ { "due": "2026-07-23", "amount_vnd": 20364000 } ]
   }

# token nears expiry at 900s -> refresh, do not re-trigger OTP
if remaining(access_token) < 120: refresh_session()

Error handling matters here: an expired session returns an auth fault that is easy to confuse with a rejected application, so the client separates the two before retrying.

What you get back

Deliverables are scoped to VayGo's real surfaces, not a generic kit:

• An OpenAPI specification covering the OTP session, application list, and repayment-schedule endpoints.
• A protocol and auth-flow report: the phone/OTP exchange, the bearer-token chain, refresh timing, any device binding.
• Runnable source for those endpoints in Python and Node.js, with the session-refresh logic built in.
• Automated tests against a consenting account, including the expired-token and rejected-application cases.
• A normalized schema that flattens VayGo's daily rate, APR band and advisory fee into one comparable cost object.
• Interface documentation plus data-retention guidance keyed to Vietnam's consent rules.

Normalized loan object we hand over

{
  "borrower_ref": "hashed",
  "principal_vnd": 20000000,
  "term_days": 91,
  "cost": { "apr_pct": 7.3, "daily_rate_pct": 0.02, "fee_pct": 0 },
  "schedule": [ { "due": "2026-07-23", "amount_vnd": 20364000 } ],
  "bank_link": { "verified": false, "source": "app_session" }
}

Consent and the Vietnamese rulebook

VayGo's data is personal and, in the ID-card and financial parts, sensitive. The dependable basis for every access is the borrower's own explicit consent — voluntary, purpose-specific, revocable. Vietnam codified that in Decree 13/2023/ND-CP, now superseded by the Personal Data Protection Law in force from 1 January 2026 (with Decree 356/2025/ND-CP as its guiding instrument). On the open-data side, the State Bank of Vietnam's Circular 64/2024 sets the technical contract — OAuth 2.0, TLS 1.2 or higher, time-bound revocable consent with audit trails. We operate inside that: access is logged, consent records are kept, data pulled is minimized to what the integration needs, and an NDA covers the engagement where you want one. Decree 94/2025/ND-CP's sandbox, which names credit scoring and P2P lending, is the live policy backdrop for an app in exactly this segment.

Engineering notes specific to VayGo

Two things shape how we build this one:

• The session is OTP-seeded and short-lived. We design the sync around a token-refresh window so a long-running pull does not silently drop when the session ages out, and so we never re-fire an OTP the borrower would have to approve again.
• The repayment schedule is derived, not stored flat — VayGo computes instalments from job, principal and term, and its advisory fee moves with promotions (the listing shows a 0–5% range and a worked example at 0%). We capture the schedule as the app renders it and re-derive on our side only as a cross-check, so a promo-driven fee change does not corrupt the ledger.
• The front end of a fast-moving lending app changes. We wire a maintenance pass that re-validates the captured flow when the client updates, so the integration is repaired before it breaks in production rather than after.

Access, the consenting test account and any sandbox are arranged with you during onboarding — that setup is our step, part of the build, not something you clear before we start.

Working with us

You bring two things: the name VayGo and what you want out of its data. From there the typical build runs one to two weeks. Source-code delivery starts at $300 — you receive the runnable API source, the spec, tests and documentation, and you pay after delivery once it works to your satisfaction. The alternative is our hosted pay-per-call API: you call our endpoints, pay only for the calls you make, with no upfront fee. Tell us which fits and what you need at /contact.html and we'll scope it.

Interface evidence

Screens from the app's store listing — open any to enlarge.

Comparable apps in the same data space

Vietnam's quick-loan segment is crowded; an integrator usually wants several of these behind one schema. Listed for ecosystem context only.

• Doctor Dong — short-term cash loans, similar KYC-plus-bank-account onboarding.
• Tamo — instalment lending with an app-driven application and repayment view.
• MoneyCat — small online loans, comparable rate-and-fee disclosure.
• Home Credit — consumer finance with online disbursement and a repayment portal.
• FE Credit — large consumer-lending book, app-based loan management.
• MoMo (Vay nhanh) — wallet-embedded quick lending with linked-account data.
• Tin24 — quick online advances aimed at the same borrower profile.
• Vietdong — 24/7 online loans, no-collateral application flow.
• Timo — digital bank offering installment loans alongside accounts.

Questions an integrator asks

Which VayGo screens actually hold data worth syncing?

The borrower profile (CMND/CCCD images, name, contact), the linked bank account, the submitted loan application with amount and term, and the repayment schedule that the app derives from job, principal and tenor. Those four surfaces are where the structured, per-user state lives.

VayGo describes itself in Vietnamese for a Vietnamese audience — does the regulator matter for integration?

Yes. The relevant frame is the State Bank of Vietnam, whose Circular 64/2024/TT-NHNN governs Open APIs from 1 March 2025, alongside the Decree 94/2025/ND-CP fintech sandbox that names credit scoring and P2P lending. Borrower-side data carries consent obligations under Vietnam's new Personal Data Protection Law, in force from 1 January 2026.

How do you handle the OTP login and short-lived session VayGo uses?

We map the phone-plus-OTP registration flow and the token it issues during the build, then design the sync to refresh the session before it expires rather than re-triggering an OTP each call. The token chain and any device binding are documented in the auth-flow report we hand over.

Can you normalize VayGo's fee and interest fields into something comparable across lenders?

Yes. VayGo exposes a daily rate, an annual APR band (described as roughly 7 to 12 percent on its listing) and a consulting/management fee of 0 to 5 percent. We flatten those into a single normalized schedule object so a downstream ledger can compare it against other lenders consistently.

How this was checked and where

Reviewed in June 2026 against VayGo's Play Store listing (description, package id, screenshots) and Vietnam's current open-banking and data-protection materials. Sources opened for the regulatory claims:

• Tilleke & Gibbins — SBV Open API circular
• ASL — Decree 94/2025 fintech sandbox
• Hogan Lovells — Vietnam PDP Law
• VayGo on Google Play

Mapped by the OpenBanking Studio integration desk, June 2026.