Reaching a Sdong borrower's loan record

A Sdong file is small but dense. One application produces a credit limit of up to 50,000,000 VND, a 91–180 day term, an APR capped at 26% a year, and a day-by-day repayment schedule — generated in roughly ten minutes by an automated review, then held server-side behind a phone-OTP login (figures per the app's Play Store listing). That compact record is exactly what a partner lender, a personal-finance app, or a servicing back office wants in structured form. This page covers what the app keeps on a borrower, the authorized way to read it under Vietnamese rules, and the source code we hand over.

The bottom line: most of the value sits in the borrower's loan ledger inside Sdong's own backend, which a phone-OTP session opens. We read that with the borrower's consent through authorized interface integration, and confirm the money movement against the receiving bank account through the consent-based open-API path as it becomes available. The identity layer we deliberately leave alone — more on that below.

What a Sdong account actually stores

These are the surfaces an integrator would touch, named the way the app presents them. None of this is a generic finance checklist; it maps to Sdong's own four-step flow and product terms.

Authorized ways to reach the data

Three paths apply here, and they reach different layers of the same loan.

1 · Consent-based interface integration of the Sdong app

The Android client talks to Sdong's backend over HTTPS, authenticating a borrower by phone OTP and carrying a bearer token afterwards. With the borrower's consent we map those request signatures and read the loan ledger directly — limit, terms, schedule, disbursement, status. This is the path that reaches the lender-held data, it is moderate effort, and its durability tracks how often Sdong reshapes its endpoints. Access to a consenting account is arranged with you during onboarding; the build runs against that account or a sandbox you and we set up together.

2 · Consent-based open-API to the receiving bank

Disbursement lands in, and repayments leave from, a Vietnamese bank account. SBV Circular 64/2024/TT-NHNN brings a standard Open API for exactly this kind of consented, customer-authorized bank access — OAuth 2.0, TLS 1.2+, revocable time-bound consent (effective 1 March 2025, with full bank compliance staged to March 2027, per Tilleke & Gibbins). As banks publish their catalogues, this path confirms the cash side of a Sdong loan independently of the app. Higher durability, because it rides a regulated standard rather than a private client.

3 · Native artefacts as a fallback

Where a borrower can pull a loan contract or a repayment statement from the app, those documents are a low-effort supplement — useful for reconciliation snapshots, weaker for live sync. We use them to cross-check the field-level pull, not as the primary feed.

For most teams the first route is what we build to and run day to day, because the loan ledger is the asset; the bank-side open-API confirmation is what we layer on for funding certainty, and the native documents stay a reconciliation cross-check. We would recommend that shape unless your use case is purely about confirming that money arrived, in which case route two leads.

The handover

You receive a working integration, not a report. For Sdong that means:

• An OpenAPI/Swagger spec covering the OTP login, token refresh, the active-loans read, and the repayment-schedule read.
• A protocol and auth-flow report documenting the OTP-to-bearer-token chain, token lifetime, and device binding as we observe them during the build.
• Runnable source for the key endpoints in Python and Node.js — authenticate, fetch the ledger, normalise the schedule, recompute interest.
• Automated tests, including a check that recomputed interest reconciles to Sdong's published worked example.
• Interface documentation plus data-retention and consent-logging guidance written for Vietnam's personal-data rules.

A worked call: the repayment schedule

Illustrative shapes — endpoint paths and field names are confirmed during the build, not lifted from any published Sdong document. The interest figure below is Sdong's own example: 2,000,000 VND over 120 days at 13% a year resolves to 85,479 VND, and the schedule read is what reproduces that per borrower.

POST /api/v1/auth/otp/verify
  { "phone": "+84...", "otp": "######", "device_id": "..." }
-> 200 { "access_token": "<jwt>", "expires_in": 3600, "refresh_token": "..." }

GET /api/v1/loans/active
  Authorization: Bearer <jwt>
-> 200 {
    "loan_id": "...",
    "principal_vnd": 2000000,
    "term_days": 120,
    "apr": 0.13,
    "disbursed_at": "2026-...T..Z",
    "destination_bank_account": "****1234",
    "schedule": [
      { "due_date": "2026-...", "principal_vnd": ..., "interest_vnd": ..., "status": "due" }
    ]
  }

# interest re-check (day-count, matches the listing example):
#   2000000 * 0.13 / 365 * 120  ->  85479 VND

# 401 on the ledger read  -> refresh once, then re-auth by OTP
# OTP endpoint is rate-limited -> back off, never hammer it

What we plan around on a build like this

A couple of things on Sdong specifically shape how we engineer the pull. These are ours to handle, not hurdles for you.

• OTP sessions and device binding. Login is phone-OTP and the token is bound to a device, so a naive nightly job would re-trigger verification. We build the refresh loop around the token lifetime and the binding so a sync keeps running without prompting the borrower each time.
• The identity layer stays untouched. KYC runs through a licensed National Population Database partner gatekept by C06; raw ID images are not ours to move. We design the integration to read identity status only and never re-handle the documents, which keeps it data-minimised by construction.
• Frequent client releases. Lending apps ship often. We keep a small signature-diff check that flags when a Sdong release renames or relocates a field, so a pull degrades loudly instead of silently returning stale numbers.
• Interest reconciled to the dong. We mirror Sdong's day-count formula exactly so recomputed balances equal what the borrower sees, rather than drifting by rounding.

Consent and the Vietnamese rulebook

Sdong handles customer data of a credit business, which Vietnamese law treats as sensitive personal data. The governing instrument is now the Law on Personal Data Protection, in force since 1 January 2026 and replacing Decree 13/2023/ND-CP (per Vietnam Briefing); its core requirement is the data subject's prior, explicit, purpose-specific consent. Everything we read is read on that basis — borrower consent first, scoped to the fields the use case needs, with consent records and access logs kept, and an NDA in place where the engagement calls for one.

For the bank-side route, Circular 64/2024/TT-NHNN supplies the consent mechanics — OAuth 2.0 scopes, revocable and time-bound authorisation — that a customer-authorized read of the receiving account rides on. And because electronic-channel lending in Vietnam leans on eKYC against the National Population Database (framed by Circular 06/2023 amending Circular 39/2016, per Global Compliance News), we treat the identity tier as the regulated, partner-mediated layer it is and stay out of it.

Cost, and how the code reaches you

A Sdong loan-ledger integration is a one-to-two-week build. Source-code delivery starts at $300: you get the runnable endpoints, the OpenAPI spec, the tests and the interface docs, and you pay only after delivery, once it works as described. If you would rather not run anything, the hosted option lets you call our endpoints and pay per call, with nothing upfront. Send us the app name and what you want out of the loan file and we will scope it — start here.

Where teams put this to work

• A bank or BNPL partner checking a borrower's outstanding Sdong obligations before extending more credit.
• A personal-finance app showing a user their Sdong repayment schedule next to their bank balances.
• A servicing or collections desk reconciling Sdong disbursements against incoming bank credits.

Screens we worked from

The app's store screenshots, used to read the surfaces named above. Tap to enlarge.

What we checked, and when

Reviewed in June 2026. The product terms (loan envelope, term, APR, the worked interest example, the four-step flow) come from Sdong's own Google Play listing; the Vietnamese open-API timeline from a Tilleke & Gibbins analysis of SBV's circular; the personal-data position from Vietnam Briefing's tracking of the new data-protection law; and the eKYC/onshore-lending framing from Global Compliance News. Deep links:

• Sdong on Google Play (vm.sdong.app.loan)
• Tilleke & Gibbins — Vietnam's Open API circular
• Vietnam Briefing — Law on Personal Data Protection
• Global Compliance News — Circular 06/2023 on onshore loans

Mapped by the OpenBanking Studio integration desk · June 2026.

Other Vietnamese loan apps in the same integration set

Same category, same kind of borrower file — listed because a unified integration usually spans several of them, not to rank or judge any one.

• MoneyCat — online cash loans up to about 10 million VND; holds limit, schedule and disbursement records much like Sdong.
• Doctor Đồng — short-tenor small loans with a first-loan promo; a borrower file of contract terms and a repayment schedule.
• Tamo — installment loans over 3–6 months with automated approval; per-loan terms and amortisation data.
• Senmo — online lending operated by Gofingo, supporting thin-file borrowers; status, limit and schedule per account.
• Vamo — consumer loans up to roughly 50 million VND; loan terms and repayment ledger behind an account login.
• Robocash — fast micro-loans with rapid disbursement; per-loan balance and due-date data.
• Crezu — a loan-matching platform surfacing offers and approvals; application and decision records.
• Findo — 24/7 small loans with introductory fee-free terms; contract and schedule data per borrower.

Questions integrators ask about Sdong

Can you reproduce Sdong's interest figures down to the dong?

Yes. The build replicates the day-count formula — principal times annual rate divided by 365 times the number of days — that Sdong's own listing uses in its 2,000,000 VND, 120-day, 13% example to reach 85,479 VND of interest. Reconciled balances then match what the borrower sees in the app.

Does the disbursement live in Sdong's app or at the bank?

Both sides record it. Sdong holds the disbursement event and the destination account; the borrower's bank holds the matching credit. We usually pull the loan side from Sdong directly and confirm the funding against the bank through the consent-based open-API path as SBV Circular 64 rolls out.

How is a borrower's identity data handled in the integration?

Identity is verified through a licensed National Population Database partner gatekept by C06, not by us. We treat those verified fields as read-only references and keep raw ID-card images out of the integration entirely, in line with Vietnam's Personal Data Protection Law.

Do you need our Sdong production credentials before you can begin?

No. We start from the app name and the fields you want out of the loan file. A consenting test account and any authorizations are set up together with you while the build is underway, not demanded up front.