Getting LoanBuddy's loan ledger into a system you control

A LoanBuddy account carries a fully-itemised short-term loan. The listing advertises a line between 2,000 and 50,000 baht, a term it sets at 91 to 180 days, and interest it quotes two ways — up to 13% a year and 0.035% a day. It even prints the arithmetic: borrow 50,000 baht over 180 days and the app says you repay 53,205 baht, 50,000 of principal plus 3,205 of interest. That is a small, rigidly-shaped ledger. It is exactly the kind of record a collections desk, an accounting sync, or a credit-aggregation product wants to read out of the app and into its own systems.

There is no consumer open-banking rail in Thailand to do that through. So the work is interface integration: map the app's own request traffic against an account you are authorized to use, and fall back to a consenting borrower login for the few states that only render in-session. The sections below name what is reachable, show one of the real calls, and lay out what we hand over.

What sits behind a LoanBuddy login

Each row below is a surface the app actually maintains per borrower, named the way the listing frames it where possible. The granularity column is what a mapped client can return; the last column is the reason an integrator reaches for it.

How we'd pull LoanBuddy's data

Two routes carry real weight here; a third is a fallback only if the account is unreachable any other way.

Authorized interface mapping (protocol analysis)

We observe the app's traffic against an account you are authorized to use, identify the loan, schedule, and disbursement calls, and rebuild them as a documented client. Reachable: the whole ledger, since the app itself renders it from those calls. Effort sits in the auth chain and the Thai field labels, not the data shape. Durability is good between front-end revisions because the underlying objects rarely change. We set up the capture environment and the test account with you as part of the build.

User-consented login

Where a borrower wants their own records moved — into a debt-advisory tool, say — the integration runs under their session, with their consent recorded. Reachable: that borrower's full account. Effort is low per user; durability depends on how the app issues and refreshes its session token, which the protocol report pins down.

Native export, if present

If the app emits a statement or receipt, we parse it as a confirming cross-check rather than a primary feed. Useful for reconciliation, thin on coverage.

On LoanBuddy I would build against the app's own request traffic first. The ledger is small and tightly structured — limit, term, installments, accrued interest — so a mapped client reproduces it cleanly and deterministically, and a consenting login sits underneath to cover the in-session-only states. That ordering comes from the data being fixed-shape, not from any preference for one technique.

A look at the repayment-schedule call

This is the surface most integrations start from: pull the installment plan for one loan, with the interest split the app itself shows. Shapes here are illustrative and get confirmed against a consenting test account during the build; the Thai labels the app uses are preserved alongside English aliases.

# Illustrative — endpoint and fields confirmed against a consenting
# test account during the build.

POST /api/v1/loan/schedule
Authorization: Bearer <session_token>   # issued at login, refreshed via the app's flow
Content-Type: application/json

{ "loan_id": "LB-…", "lang": "th" }

# Response (normalized; original Thai labels kept as *_th)
{
  "loan_id": "LB-…",
  "principal_thb": 50000,
  "term_days": 180,
  "annual_rate_pct": 13.0,      # carried separately —
  "daily_rate_pct": 0.035,      #   the two do not reconcile by arithmetic
  "outstanding_thb": 50000,
  "installments": [
    { "seq": 1, "due_date": "2026-07-16",
      "principal_thb": 8190, "interest_thb": 561, "balance_thb": 41810 }
    # …remaining rows sum to the listing's worked total of 53,205 THB
  ]
}

# Tests assert the schedule totals back to 53,205 THB on the 50k / 180-day
# example before the client is accepted.
      

What ships into your repo

The output is a working integration for LoanBuddy's surfaces, not a report. Concretely:

• An OpenAPI/Swagger spec covering the loan-account, schedule, and disbursement calls, with the Thai-to-English field map written in.
• A protocol and auth-flow report: how the session token is issued at login, how it refreshes, and any cookie or signing step found in the chain.
• Runnable source in Python and Node.js for fetch-account, fetch-schedule, and fetch-disbursements, with the day-count reconciliation built in.
• Automated tests, including the assertion that the 50,000-baht / 180-day schedule sums to the listing's 53,205-baht total.
• Interface documentation in English laid over the original Thai source labels.
• Data-retention and compliance guidance scoped to the loan ledger — what to keep, what to drop, how consent is recorded.

PDPA, the Bank of Thailand, and consent

Two regimes apply, and neither is a generic checkbox. The lender sits under Bank of Thailand supervision: BOT's 2020 digital personal loan rules cap that specific product at 20,000 baht, a six-month term, and a 25% effective annual all-in rate, per Tilleke & Gibbins' summary of the circular. LoanBuddy's advertised 50,000-baht ceiling sits above that box, which tells us the loan object likely follows the broader supervised personal-loan or nano-finance schema rather than the digital-personal-loan one — a difference we account for when we model the record.

On the data side, Thailand's Personal Data Protection Act has been in full force since June 2022 and is enforced by the PDPC under the Digital Economy and Society Ministry, with penalties the law sets up to 5 million baht. The PDPC and the central bank have been actively flagging unlicensed Thai loan apps for over-broad data collection, so we keep the integration minimized to the loan ledger and stay off the device-permission surface entirely. The dependable basis for access is the borrower's own authorization, or yours over an account you control; consent is logged, the data set is narrowed to what the use case needs, and we work under NDA where the records are sensitive.

Things this build has to get right

Three points need real attention on LoanBuddy, and we handle each as part of the work:

• Two interest quotes that don't reconcile. Up to 13% a year and 0.035% a day do not multiply into each other, so we pin the accrual basis — day-count and rounding — against the app's own worked example (50,000 baht over 180 days repaying 53,205 baht) and reconcile our computed schedule to that figure before the client is signed off.
• Which loan schema the account returns. Because the advertised limit exceeds the digital-personal-loan cap, we model the loan object to whatever the live account actually returns — extra fee lines, a longer term, different status codes — instead of assuming the smaller product's shape.
• Thai-language fields. The UI and the underlying keys are Thai, so we keep the source labels and add English-normalized aliases, which keeps the schema usable downstream without throwing away the original. We also schedule a light re-check for when the app's front end shifts, so the mapping does not quietly rot.

Screens from the app

Listing screenshots, opened for the interface read. Click to enlarge.

Keeping the sync honest

The ledger changes on events, not on a clock. A draw creates the schedule; repayments and the disbursement move the balance. So we sync on those events and the installment due-dates rather than polling daily, snapshot the schedule at consent time as the reference, and raise a flag if the app's fee structure or term options change under us. That keeps the data you hold matched to what a borrower sees in-app without hammering the back end.

Lenders in the same pocket

If you are mapping LoanBuddy you are likely looking at neighbouring Thai short-term-credit apps too. These hold comparable per-user records, and a single integration model can normalize across them. Listed for context, not ranked.

• FINNIX — MONIX's nano-finance app (SCBX and Abakus); accounts hold a revolving credit line, draws, and repayment history.
• MoneyThunder — ABACUS digital's personal-loan and nano-finance app under SCBX; carries approved limits and monthly-interest repayment schedules.
• PROMISE (Thailand) — a revolving personal-loan service whose accounts hold reusable credit lines and installment records.
• KTC — Krungthai Card's personal-loan and credit-card app, holding statements, limits, and cash-loan balances.
• Krungsri i-FIN — Bank of Ayudhya's digital personal-loan product, with online application status and repayment plans.
• SCB EASY — Siam Commercial Bank's app, whose borrow feature holds loan offers and installment balances beside transaction history.
• Line BK — the LINE and Kasikornbank social-banking service, with a credit-line product and a repayment ledger.
• Ngern Tid Lor — a vehicle-registration title-loan provider whose accounts hold collateral-backed balances and payment schedules.

What I checked, and where

I read LoanBuddy's own store listing for the loan terms, eligibility, and the worked repayment example, then cross-read the Thai regulatory picture against primary write-ups. The Bank of Thailand digital-personal-loan rules and caps come from Tilleke & Gibbins; the PDPC's scrutiny of unlicensed loan apps from Bangkok Post and Nationthailand; competitor context for FINNIX from MONIX. Links open in a new tab.

• Tilleke & Gibbins — Bank of Thailand introduces digital personal loans
• Bangkok Post — Thai data protection agency lists 11 suspicious apps
• Nationthailand — Bank of Thailand cracks down on illegal loan apps
• MONIX — FINNIX and Thai digital lending

Mapped and written by the OpenBanking Studio integration desk · 17 June 2026.

Questions integrators ask about LoanBuddy

Can you reproduce LoanBuddy's repayment schedule, daily-interest accrual included?

Yes. The store listing publishes a worked example — 50,000 baht over 180 days repaying 53,205 baht — so we pin our computed schedule to that figure and reconcile the day-count and rounding before anything ships. The quoted 13% per year and 0.035% per day are carried as separate fields, since they do not reconcile by simple arithmetic.

Is there a Thai open-banking rail the integration would go through?

No consumer open-banking or account-information scheme covers Thai lenders the way the UK or Brazilian regimes do. Access rests on the borrower's own authorization, or yours over a consenting test account. The Bank of Thailand supervises the lender; the PDPA governs the personal data.

Which borrower fields can the mapped client return?

The loan-account object: the advertised credit line (the listing quotes 2,000 to 50,000 baht), outstanding principal, the 91-to-180-day term, installment due-dates and amounts, accrued interest, disbursement records, and the eligibility flags the app checks — Thai national, at least 18, a stated income source. Thai field labels are kept, with English aliases added.

We only have the app name — is that enough to begin on LoanBuddy?

It is. You give us the app and what you want out of it, say the repayment schedule and disbursement records; access to a consenting account or test login is arranged with you along the way. The loan-ledger mapping comes back as runnable source with a spec and tests inside a one-to-two-week cycle.

Source for LoanBuddy's loan-ledger, schedule, and disbursement endpoints ships from $300, billed only after delivery once you have run it and are satisfied. Prefer not to host it? The same endpoints can run as a hosted API you pay per call, with nothing upfront. Either way the cycle is one to two weeks. Tell us the app and what you want pulled at /contact.html and we will scope it.