Reaching Dola Dong's loan ledger through consented access

A Dola Dong loan tops out at 40,000,000 VND with terms between 93 and 365 days and an APR the app caps at 21.9% a year, as its Play Store listing describes the product. That is the shape of the data behind the account: not a payments stream but a credit ledger — an application, an approval decision, a disbursement to a named Vietnamese bank account, and a repayment schedule that runs for months. Pulling that cleanly is the job. Below is where the data lives in the app, the authorized way we reach it, and what lands in your hands at the end.

Two things make the timing useful. The State Bank of Vietnam now has a working open-API rulebook, and the lending product itself is structured enough to normalize without guesswork. We build the consented route to match where the regulator is heading, so the integration does not need re-architecting when banks publish their own interfaces.

Where the data sits inside the app

Each row below is a surface a borrower actually touches, mapped to what an integrator would take from it.

How we reach it

User-consented session capture

The dependable path. A borrower consents, authenticates through the app's own OTP flow, and we read the loan, schedule and disbursement surfaces as that consented user. Reachable: everything in the table. Effort: moderate — the OTP handshake and token lifecycle are the work. Durability: good while the borrower's consent stands; we design the refresh around it. We arrange the consenting account or a sandbox account with you at onboarding.

Authorized protocol analysis

We observe the app's own traffic under your authorization, document the request and response contracts behind the confirmation and active-loan screens, and rebuild them as clean endpoints. This is reverse engineering for interoperability — naming the fields, the auth chain and the error shapes so they can be called programmatically. Effort: heavier up front; durability depends on how often the front end changes, which we account for in maintenance.

Regulated open-API alignment

Where a partner bank exposes consented data under Circular 64 — Account Information and Loan Origination are named service types — we wire the integration to that standard instead of to the app surface. This is the longest-lived option as the regime rolls out toward full compliance in 2027.

For Dola Dong specifically, start with consented session capture. It returns the full loan ledger today, it does not wait on any third party, and because we already shape its tokens and payloads to OAuth 2.0 / JSON conventions, the same client slides onto the bank-side API later with little rework. Protocol analysis backs it up for fields the consented view does not surface; the open-API path is the destination, not the starting line.

What lands in your hands

Concrete artifacts, scoped to the surfaces above:

• An OpenAPI specification covering the login/OTP exchange, loan-offer read, repayment-schedule read and disbursement lookup.
• A protocol and auth-flow report: the OTP-to-token chain, token refresh, and how the app signs and rejects requests.
• Runnable source for those endpoints in Python and Node.js, with a normalized loan-schedule model so a 93-day lump loan and a 365-day installment loan come back in one shape.
• An automated test suite that exercises a live consenting account or sandbox and flags contract drift.
• Interface documentation plus data-retention and consent-logging guidance written against Vietnam's data-protection law.

A worked example

Reading the loan-offer terms after an OTP session, with the schedule normalized. Field names are illustrative and confirmed against the live surface during the build.

POST /v1/session/otp/verify
{ "phone": "+8490xxxxxxx", "otp": "******", "device_id": "<ekyc-bound>" }
=> 200 { "access_token": "<jwt>", "expires_in": 1800, "refresh_token": "<...>" }

GET /v1/loan/offer/current
Authorization: Bearer <jwt>
=> 200 {
     "principal_vnd": 25000000,
     "term_days": 93,
     "apr_pct": 21.9,
     "total_payable_vnd": 26395000,
     "maturity_date": "2026-09-25",
     "schedule": [ { "due": "...", "amount_vnd": ... } ],
     "disburse_to": { "bank": "VCB", "acct_masked": "****1234" }
   }

# handle the two repayment shapes Dola Dong issues:
#   - periodic installments  -> schedule[] has N entries
#   - lump principal+interest -> schedule[] has one entry at maturity
# 401 -> refresh token; 409 -> offer expired, re-read confirmation screen

Consent and the law it runs under

Two instruments govern this. On the data-sharing side, SBV Circular 64/2024/TT-NHNN took effect on 1 March 2025 and sets OAuth 2.0, REST/JSON over TLS 1.2 and JWS signing as the technical baseline for consented bank-data access, with phased bank compliance running toward 2027 — we keep the integration inside those conventions. On the personal-data side, Vietnam's Personal Data Protection Law (Law 91/2025/QH15), in force since 1 January 2026 and replacing Decree 13/2023/ND-CP, requires consent that is voluntary, specific and recorded, naming the data types, the purpose and who may process them. Our consent capture mirrors that: scoped to the loan surfaces the project needs, time-bound, revocable, with each access logged and an NDA in place. Data minimization is the default — we read the repayment state, not the borrower's full contact graph.

Build notes specific to this app

Two things shape the engineering, and we handle both:

• The repayment object is not a single balance. A Dola Dong loan is either periodic installments or one principal-plus-interest payment at maturity, depending on the product the borrower chose. We model it as a schedule with explicit due dates so reconciliation against the app's confirmation screen is exact, whichever form a given loan takes.
• The session is OTP-bound and the token has a short life. We design the sync around the OTP handshake and refresh window so the consented connection does not silently lapse mid-term, and we wire a re-validation step into maintenance for when the app's front end or field names shift.
• Disbursement targets vary by bank. Payout lands in domestic accounts across Vietcombank, VietinBank, BIDV, Agribank and others; we normalize the bank identifiers so the payout record matches cleanly regardless of which institution received it.

What teams build with it

• A lender-side aggregator that reads a consenting borrower's active Dola Dong loan and folds its schedule into a single repayment calendar.
• A credit-history service that observes on-time versus late repayment state to enrich a risk file, under the borrower's consent.
• An accounting sync that reconciles each disbursement against the receiving bank statement and flags mismatches.

Interface evidence

Store screenshots we referenced while mapping the surfaces above. Tap to enlarge.

How this was sourced

Checked in June 2026. App facts come from the Dola Dong Play Store listing and the operator's own pages; the regulatory framing from the SBV open-API circular coverage and Vietnam's personal-data law analyses.

• Dola Dong on Google Play
• Brankas — Vietnam Circular 64 explainer
• Lexology — SBV Open API circular
• Securiti — Vietnam personal-data framework

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

Similar apps in the Vietnamese lending space

Same category, named for keyword reach and to show where a unified loan-data integration would reach next. Neutral context, no ranking.

• Vietdong — online cash loans of 1–50 million VND over 91–365 day terms; holds comparable per-borrower schedules.
• EasyCash — a P2P-model lending platform with online appraisal and automatic disbursement.
• MoMo — a wallet that also runs online lending alongside its payment ledger.
• Home Credit Vietnam — installment loans from a multinational consumer-finance lender, longer 6–36 month terms.
• Timo Plus — bank-backed installment lending with fixed-rate repayment schedules.
• LoanHub Vietnam — an online loan marketplace surfacing application and offer data.
• Doctor Dong — a long-running Vietnamese short-term cash-loan brand with similar account records.

Questions integrators ask

Which Dola Dong screens hold the data worth pulling?

The loan-offer confirmation screen is the richest surface: before a borrower accepts, the app renders the principal, each installment amount, total cost of borrowing and the maturity date. Around it sit the OTP login session, the eKYC identity record, the chosen domestic bank account for disbursement, and the repayment history. We map each of those to a stable field set.

Does Vietnam's Circular 64 change how a Dola Dong integration should be built?

It sets the direction. Circular 64/2024/TT-NHNN took effect on 1 March 2025 and defines OAuth 2.0, REST/JSON over TLS 1.2 and JWS signing for consented bank data sharing, with Account Information and Loan Origination among the named service types. We build the consented route to match that shape so the integration ages well as banks publish their open APIs through 2027.

How do you handle the 93-to-365-day repayment terms when normalizing Dola Dong data?

We model the loan as a schedule object rather than a single balance, because a Dola Dong loan can be periodic installments or a lump principal-plus-interest payment at maturity depending on the product the borrower picked. The normalized schema carries every due date, the per-installment amount and a running outstanding figure so a downstream system can reconcile against the app's own confirmation screen.

Can repayment status be observed without storing the borrower's credentials?

Yes. We design the session around the app's OTP flow and the consenting account, capture only the repayment-state fields the project needs, and keep credentials out of any long-lived store. Access is arranged with you during onboarding, against a consenting account or a sandbox, and every fetch is logged under an NDA.

One closing note on working together. The build runs in a 1–2 week cycle and arrives one of two ways: source-code delivery starting at $300, where you receive the runnable endpoints, the spec, the tests and the documentation and pay only after delivery once the result satisfies you; or a pay-per-call hosted API, where we run the endpoints and you are billed per call with no upfront fee. Give us the app name and what you need from its data — access, consenting accounts and compliance paperwork are arranged together as part of the engagement. Start the conversation at /contact.html.