How a ไทยแนนซ์ loan account becomes an API you can call

Every approved loan in ไทยแนนซ์ carries a three-to-six installment declining-balance schedule, and that schedule — due dates, the principal-versus-interest split, the running balance — is the data most teams come here for. The app is a licensed provincial PICO-finance lender; its operator states amounts of 3,000 to 50,000 baht over 91 to 180 days, with interest accrued daily on the outstanding principal. None of that lives on the handset. It sits on the lender's servers, behind an OTP login, and the job is to read it out under the borrower's authorization and hand back something a backend can query.

Bottom line: the valuable surface is the live amortization ledger, and the dependable basis for reaching it is the account holder's own consent — not any vendor arrangement. The build we would put first reads a consenting account directly; where you need a record the controller stands behind, we add a PDPA data request alongside it.

Account data a borrower's login exposes

These are the surfaces ไทยแนนซ์ renders to a logged-in borrower, mapped to what an integrator does with each. Field names follow how the app and its listing describe them.

Authorized ways to reach it

Three routes genuinely apply to this app. Each is run with the borrower's authorization; access and any test account are set up with you during onboarding.

1 · Consented interface integration

We study the app's own traffic against a consenting account and rebuild the calls behind login, loan summary, schedule and payoff. Reachable: the full live ledger, including the daily-accrued balance. Effort is moderate; durability depends on app releases, which we account for with a layout-change check (see engineering notes). This is what we would build first, because the running payoff number only exists server-side.

2 · PDPA data-portability request

Thailand's Personal Data Protection Act gives a borrower access and portability rights, so they can ask QR Technologies for the personal data held about them. Durability is high — it is a statutory right — but the format and turnaround are set by the controller, and the result is a point-in-time snapshot. We normalize whatever comes back and use it where you need a controller-attested record.

3 · In-app contract capture

The contract and schedule render inside the app as the borrower's source of truth. We can parse that rendered surface as a verification path against the other two routes, useful when you want the exact figures a borrower sees confirmed.

What lands in your repository

Everything is tied to the surfaces above, not a generic template:

• An OpenAPI 3.1 specification covering the consented endpoints — login/OTP, loan summary, installment schedule, payoff quote.
• An auth-flow report documenting the OTP, token and refresh chain exactly as observed during the build.
• Runnable clients in Python and Node.js for loan summary, schedule and payoff.
• A normalized JSON schema for the declining-balance installment model, so ไทยแนนซ์ records line up with other lenders.
• A pytest suite whose assertions reproduce a contract's per-installment principal and interest to the satang.
• Interface documentation plus PDPA-aligned retention and data-minimization guidance.

A consented pull, in code

Illustrative — endpoint paths and field names are confirmed against the live app during the build, not published here as fixed contract.

import requests

S = "https://api.thainance.example/v1"   # base resolved during protocol analysis

def session(token):
    return {"Authorization": f"Bearer {token}", "Accept": "application/json"}

# token comes from the OTP login flow documented in the auth-flow report
loan = requests.get(f"{S}/loans/current", headers=session(tok)).json()

# declining-balance payoff = principal + interest accrued since last cut
principal = loan["outstanding_principal"]        # THB
annual    = loan["interest_rate_annual"]          # e.g. 0.1825, pinned at build
days      = loan["days_since_last_payment"]
accrued   = round(principal * annual / 365 * days, 2)
payoff    = round(principal + accrued, 2)

for inst in loan["schedule"]:
    print(inst["due_date"],
          inst["principal_component"],
          inst["interest_component"],
          inst["remaining_principal"])

if loan.get("error") == "OTP_SESSION_EXPIRED":
    raise SystemExit("re-auth via OTP; tokens are short-lived")

PDPA, pico supervision and consent scope

Thailand's Personal Data Protection Act has been in force since June 2022 and grants data subjects access, portability and erasure rights — that statutory consent is the basis the integration rides on. The lending side is supervised by the Ministry of Finance through its Fiscal Policy Office; the PICO-finance regime caps the effective rate at 36% a year, consistent with the 10–35.8% range the app's listing quotes. We work to a named consent scope per borrower, honour revocation by tearing down stored tokens, keep only the fields a use case needs, log every access, and sign an NDA where the engagement calls for one. For context on Thailand's broader open-data direction, the Bank of Thailand's dStatement service already moves machine-readable statement data between institutions on customer consent; ไทยแนนซ์ is a non-bank pico lender outside that scheme, which is why consent-based interface integration carries the work here.

Engineering details we plan around

Concrete things this app forces, all handled on our side:

• Daily declining-balance accrual. The app states interest is computed as remaining principal × the annual rate ÷ 365 × days in the period. Its listing shows both a per-day example figure and an 18.25% annual basis, so we pin the exact rate basis observed against the live contract and assert it in tests — that is what makes the payoff reproduce to the satang.
• OTP session lifecycle. Everything sits behind an SMS-OTP login with short-lived tokens. We design the sync around the refresh window so it does not silently expire mid-run, and we arrange a consenting or test account with you at onboarding to build against.
• Early-payoff re-amortization. Per the app, paying above the minimum cuts principal immediately and lowers the next period's interest. We handle the recompute so a partial prepayment does not desync the stored schedule.
• Front-end drift. The contract screen is the schedule's source of truth. We add a layout-change check to maintenance so a redesigned screen shows up as a failing test rather than quietly bad data.

Where teams put this

• A debt-overview dashboard that shows a user's ไทยแนนซ์ balance next to their other consumer loans.
• A reminder or collections service firing on each installment due date.
• An accounting sync that posts the principal and interest split into a ledger every period.
• An affordability or refinance check that reads the live payoff before quoting a replacement loan.

Working with us, and the cost

A working ไทยแนนซ์ loan-data client — with tests that reproduce the contract's amortization — comes back in one to two weeks. You can take it as source: the runnable code, the OpenAPI specification, the auth-flow report and the documentation, delivered into your repository and paid from $300 only once it is in your hands and you are satisfied. Or skip hosting entirely and call our maintained endpoints, paying per call with nothing upfront. Either way you give us two things — the app name and what you want from its data — and access and compliance are arranged with you as part of the project. Start at /contact.html.

Screens we mapped against

Store screenshots used while tracing the app's surfaces. Tap to enlarge.

How this brief was put together

Checked in June 2026 against the app's store listings and the disclosures in its description (operator, licence number, loan terms, the daily declining-balance calculation), plus Thailand's regulatory picture for pico lending and personal data. Primary sources opened: Bank of Thailand — dStatement / open data, ไทยแนนซ์ on Google Play, the PICO-finance licence framework (MOF/FPO), and the National Credit Bureau.

Mapped by the OpenBanking Studio integration desk — June 2026.

Other Thai lending apps in the same data picture

Same category, named for keyword reach — each holds per-user credit data a unified integration could read alongside ไทยแนนซ์. This is context, not a ranking.

• LINE BK — social-banking app with a revolving pocket-money credit line inside LINE.
• MoneyThunder — AI-scored nano-finance lending from Abacus Digital, aimed at thin-file borrowers.
• FINNIX — digital nano-finance loans with in-app schedules and balances.
• KTC Mobile — Krungthai Card's app for card and personal-loan accounts.
• KMA Krungsri — Krungsri's mobile app offering personal and instant-cash loans.
• Ngern Tid Lor (TIDLOR) — title and vehicle-registration loans with repayment tracking.
• Heng — Heng Leasing's nano and title-loan app for up-country borrowers.
• SCB EASY — Siam Commercial Bank's retail app, lending included.
• Krungthai NEXT — Krungthai Bank's everyday banking and loan app.

Questions integrators ask about ไทยแนนซ์

Does ไทยแนนซ์ report repayment behaviour to a credit bureau, and can that feed be pulled?

Pico lenders in Thailand operate under Ministry of Finance supervision and many are National Credit Bureau members, so a borrower's repayment record may sit at NCB as well as inside the app. The bureau file is a separate, consent-gated source; the integration we build reads the loan, schedule and balance from the borrower's own ไทยแนนซ์ account, and a credit-bureau pull is scoped on its own if you need it.

The loan accrues interest daily on a declining balance — can the client reproduce the exact payoff?

Yes. We model interest as remaining principal times the annual rate divided by 365, multiplied by the days in the period, which is how the app describes its own calculation. The pytest suite asserts the per-installment principal and interest split against a contract so the payoff figure matches to the satang.

Is a PDPA data-portability request a realistic way to obtain the loan records?

It can be. Thailand's PDPA gives a data subject access and portability rights, so a borrower can ask QR Technologies for their personal data. That returns a controller-attested snapshot rather than a live balance, so we usually pair it with a consented interface read when a product needs the running figure.

We only need a handful of borrower accounts mapped first — does that fit?

It does. The build runs against one consenting account or a test account we arrange with you, so a small pilot is the normal starting shape, and the same client scales to more accounts without rework.