Getting structured loan data out of Sen Vay

A Sen Vay account opens with a phone number, and once it does it holds a loan file: amounts from 3.5 to 20 million VND, terms of 91 to 365 days, an APR band of 3 to 12 percent and a service fee of 1 to 5 percent, per the figures in the app's Play Store listing. The worked example in that listing runs a 20 million VND loan over 91 days to a net-disbursed 19.4 million VND. That is the data a partner, a debt servicer, or an internal risk team actually wants — and none of it lives in a spreadsheet anywhere. It sits behind the borrower's authenticated session. The job is to read it in a stable, consented, documented way and hand back something you can call.

Vietnam is mid-transition on financial data sharing. The State Bank issued Circular 64/2024, in force since March 2025, setting a standardized Open API framework for banks and third parties to share data with explicit customer consent, and Decree 94/2025 stood up a fintech sandbox covering Open API and credit-scoring use cases. For a non-bank lending front end like Sen Vay, the dependable path today is not waiting on that framework to cover every app — it is reading the borrower's own data with the borrower's consent, through the interface the app already exposes to its client.

What the app actually holds

These are the surfaces worth integrating, named the way the app presents them.

Reaching it — the routes that apply

Protocol analysis of the app's own traffic

The app talks to its backend over a documented request/response interface to render a borrower's loans. We capture that exchange under authorization, document the auth handshake and the loan and schedule endpoints, and rebuild them as a clean client. Reachable: everything the borrower sees in-app. Effort is moderate and front-loaded into the mapping. Durability is good between front-end releases, and we account for the releases that do change it. Access is arranged with you during onboarding, against a consenting test account.

User-consented credential access

The borrower authorizes the connection and authenticates as themselves; we read only their records, with the consent recorded. This is the cleanest basis under Vietnamese data law and the one we lead with for a production borrower-facing flow. It pairs with the protocol map above rather than competing with it.

Regulated Open API consent (bank leg)

Where a loan touches a bank account for disbursement or repayment, the SBV Circular 64/2024 Open API path can carry that leg under standardized consent. It does not cover Sen Vay's own application and schedule records, so it is a complement for the money-movement side, not the whole picture.

For most teams the working recommendation is concrete: build the borrower-consented protocol client as the thing you call every day, and reserve the Open API path for the bank-account leg if your use case settles money. That keeps the integration grounded in the borrower's own authorization, which is exactly where Vietnamese law puts the consent.

What you get back

Delivery is source you own, not a black box. For Sen Vay that means:

• An OpenAPI specification covering the auth, loan-list, schedule and fee surfaces as we map them.
• A protocol and auth-flow report — the OTP login, token issuance and refresh chain as it behaves for this app.
• Runnable source for the key endpoints in Python or Node.js, with the VND and Vietnamese-text normalization already wired.
• Automated tests against recorded fixtures, including overdue-fee edge cases.
• Interface documentation plus data-retention and consent-logging guidance fitted to Decree 13 / Law 91.

How the calls look

Illustrative shape, confirmed and adjusted against live captures during the build. Field names settle once the auth flow is mapped.

POST /api/v1/auth/otp-verify
{ "phone": "+84xxxxxxxxx", "otp": "######" }
-> 200 { "access_token": "…", "refresh_token": "…", "expires_in": 3600 }

GET /api/v1/loans/active
Authorization: Bearer <access_token>
-> 200 {
     "loan_id": "…",
     "principal_vnd": 20000000,     // from the worked example in the listing
     "term_days": 91,
     "apr_pct": 12.0,
     "service_fee_vnd": 600000,
     "net_disbursed_vnd": 19400000,
     "overdue_fee_day_pct": 0.1,    // ceiling, not to exceed 18% of overdue
     "schedule": [
       { "due_date": "…", "principal_vnd": …, "interest_vnd": …, "balance_vnd": … }
     ]
   }

# Errors we handle: expired token -> refresh; OTP throttle -> backoff;
# loan-not-found -> empty schedule, not a 500.

Consent and the rules that bind it

Vietnam's data regime is the anchor here, not a generic privacy nod. Decree 13/2023 was the country's first dedicated personal-data instrument and made prior explicit consent the main legal basis for processing; as of January 2026 it has been elevated by Law 91/2025 on Personal Data Protection, with Decree 356/2025 providing detailed guidance and effectively superseding the decree. We build the connection so consent is explicit, scoped to the records the integration needs, recorded, and revocable — and so a withdrawal actually stops the sync. Access is authorized and logged, data is minimized to what the use case requires, and we work under an NDA where the engagement calls for it. On the money-movement side, the State Bank's Circular 64/2024 Open API framework sets the consent and security expectations for any bank-account leg.

Things we account for on Sen Vay specifically

Two details on this app change how the build is engineered, and we handle both rather than hand them to you as homework.

• The overdue-fee cap is a real rule, not a footnote. The app states a 0.1 percent daily overdue fee that may not exceed 18 percent of the overdue amount. We encode that ceiling in the normalization layer so any balance our client computes matches what the borrower is shown — long-overdue loans are exactly where a naive accrual drifts, so we test that case directly.
• Vietnamese text and VND formatting need careful handling. Labels, names and addresses carry full diacritics, and amounts appear with VND grouping. We normalize to UTF-8 and parse currency into integer minor units so nothing rounds or mojibakes on the way into your store.
• Consent has a lifetime under the data law. We design the sync around the consent-refresh window so a connection does not silently outlive its authorization, and we re-validate the mapping during maintenance whenever the app ships a front-end change that moves a field.

Where this tends to get used

• A servicing or collections team that needs live repayment schedules and overdue balances out of the borrower's own account.
• A risk or underwriting workflow that prefills from the KYC and income fields a borrower already entered, with their consent.
• An aggregator presenting a borrower's Sen Vay loan alongside other obligations in one normalized view.
• An accounting reconciliation that matches disbursement and net-received figures against bank settlement.

Screens we worked from

What was checked, and when

This mapping draws on the app's own Play Store listing for its loan terms, fee structure and registration flow, and on Vietnamese regulatory primary sources for the consent and Open API position. Reviewed June 2026 against: the State Bank's Open API circular as reported by Indochine Counsel; Vietnam's personal-data decree as summarized by Securiti; the fintech-sandbox Decree 94/2025 via Tilleke & Gibbins; and the National Credit Information Center's role via CIC's partner announcement.

Mapped by the OpenBanking Studio integration desk · June 2026.

Similar apps in the same data space

These Vietnamese lending and wallet apps hold comparable per-borrower records, and a unified integration usually spans several of them:

• FE Online 2.0 — FE Credit's consumer-lending app, with loan accounts and repayment schedules behind a login.
• Home Credit Tài Chính Online — installment and cash-loan records for Home Credit Vietnam customers.
• Cake by VPBank — a digital bank holding accounts, cards and loan products in one app.
• Viettel Money — a wallet and financial-services app with balances and transaction history.
• VNPAY — a payments app carrying transaction and wallet data.
• TrueMoney — wallet and short-term loan products with per-user ledgers.
• Vietdong Vay nhanh online — an online lender with small-ticket loan files from around 1 to 40 million VND.
• Moneyveo — an online consumer-loan service with application and repayment records.

Questions integrators ask about Sen Vay

The listing prints fee and cost figures — are those carried per-loan in the data, or only in marketing copy?

Per the worked example in the app's listing, each loan file carries its own principal, term in days, APR, service fee and a net-disbursed figure. Those are account-bound values, not static marketing text, so a mapped integration reads the actual numbers attached to a borrower's loan rather than the headline ranges.

Sen Vay caps the overdue fee at 0.1 percent a day and 18 percent of the overdue amount — how do you handle that in a balance sync?

We model the cap explicitly so a computed outstanding balance matches what the app shows the borrower. The daily accrual and the 18 percent ceiling are encoded as a single rule in the normalization layer, which keeps reconciliation against the app's own figures exact and avoids drift on long-overdue loans.

Which Vietnamese rules govern consent when pulling a borrower's Sen Vay records?

The consent basis is Vietnam's personal-data law — Decree 13/2023, now elevated by Law 91/2025 on Personal Data Protection with Decree 356/2025 guidance — which makes prior explicit consent the main legal basis for processing. Where a bank disbursement leg is involved, the State Bank's Open API framework under Circular 64/2024 applies. We build to consented, logged access against those instruments.

Can Sen Vay repayment data be lined up against CIC credit reporting?

Repayment schedules and settlement events from the app can be normalized into the same shape a CIC-linked workflow expects, since the National Credit Information Center under the State Bank collects repayment data from lenders. We map the app's installment and payoff records to that structure; CIC itself updates on a monthly or per-transaction basis, so we design the sync cadence around it.

Engagement is short and direct. The build runs in a one-to-two-week cycle and lands either way you prefer: a source-code delivery starting at $300, where you own the runnable client, the spec and the tests and pay only after delivery once it works for you; or a pay-per-call hosted API, where we run the endpoints and you pay per call with nothing upfront. Tell us the app and what you need from its data — access and compliance are arranged with you as part of the work. Start a Sen Vay integration here.