Reaching the loan ledger inside ชัยเครดิต-Credit

A ชัยเครดิต-Credit loan accrues interest by the day. The app's own worked example puts a 10,000 THB loan over 120 days at 0.04% daily, repaid as roughly 2,620 THB a month, with 480 THB total interest — numbers that only mean something if you can read the live balance behind the login. That balance, the repayment schedule and the application's review state are the data an integrator actually wants, and they live in the backend of SIAMTECH DIGITAL COMPANY LIMITED, the PICO Finance operator behind the app (license no. 1156/2568, per the app's Play Store listing). This page maps that data, the authorized way to reach it for a third party, and what we hand over.

The short version: the loan ledger is single-tenant, sitting in SIAMTECH's servers, and the app is the only client that reads it. So the dependable way in is to study the app's authenticated traffic with the borrower's consent, normalise what comes back, and ship that as an interface you can call. The Bank of Thailand's data-sharing regime is real and worth designing toward, but loans land in its later phase — more on that below.

What the app holds per borrower

Each row below is a surface the app exposes to a signed-in user or generates server-side during the loan lifecycle. The lifecycle itself is stated in the app: register and verify, smart-match to an amount, submit, wait for review, then disbursement straight to a bank account.

Routes to the loan data

1 · Authorized analysis of the app's client traffic

The app talks to SIAMTECH's backend over a token-authenticated interface to fetch status, balance and schedule. With the customer's authorization and a consenting borrower, we capture and document that traffic, then rebuild the calls you need as a clean interface. This is what returns the full ledger today. Effort sits in the auth chain and in handling the daily-changing balance; durability is good as long as a re-check fires when SIAMTECH ships a new app build. We set up the capture environment and the consenting account with you.

2 · User-consented session access

Where a borrower wants their own data moved, they log in and consent, and we drive that authenticated session to read their statements, schedule and payment history. Thinner to stand up than full traffic analysis, scoped to one person at a time, and resting squarely on PDPA explicit consent. Useful for affordability checks and customer-initiated exports.

3 · BOT "Your Data" Open Data channel

The Bank of Thailand has enacted a regulation letting individuals share data held by financial providers — deposits, loans and payment services including e-Money and credit cards — over standardized channels. Personal deposit data opens around late 2026, with loans in the 2027–2028 expansion. We design schemas and consent records that fit this channel so a switch-over is incremental rather than a rebuild. The related dStatement service already moves bank statements in a machine-readable form between banks.

4 · Native in-app surfaces

The account screen shows balance and repayment schedule, and payments run in-app. As a fallback this is a useful oracle: we validate the interface against what a borrower sees on the screen, so the numbers reconcile.

Which one we recommend depends on the data lifetime and who initiates. For a lender, BNPL partner or bureau that needs the running ledger now, route 1 on a consenting account is what we build, with PDPA consent as its legal footing and the BOT channel adopted for the categories it covers as those phases land. For a one-off, customer-driven export, route 2 is lighter and faster.

Reading the account over the wire

Shapes below are illustrative — confirmed during the build against a consenting account, not copied from any published document. They show the calls a status-and-balance integration leans on.

# Auth — short-lived access token, longer refresh
POST /api/v1/auth/login
  { "phone": "+66XXXXXXXXX", "otp": "######" }
  -> 200 { "access_token": "…", "refresh_token": "…", "expires_in": 1800 }

# Loan account + live balance (interest accrues daily)
GET /api/v1/loan/account
  Authorization: Bearer <access_token>
  -> 200 {
       "loan_id": "…",
       "principal":   10000.00,
       "outstanding":  8120.00,
       "currency": "THB",
       "daily_rate": 0.0004,        # 0.04%/day, per the app's own example
       "term_days": 120,
       "status": "disbursed"        # matched | submitted | review | approved | disbursed
     }

# Repayment schedule -> drives reminders and reconciliation
GET /api/v1/loan/schedule?loan_id=…
  -> 200 { "installments": [
       { "due": "2026-07-10", "amount": 2620.00, "state": "paid" },
       { "due": "2026-08-10", "amount": 2620.00, "state": "due"  } ] }

# token expired? refresh rather than re-prompt for OTP
POST /api/v1/auth/refresh   { "refresh_token": "…" }
  -> 200 { "access_token": "…", "expires_in": 1800 }
      

Error handling matters here: a 401 means refresh, not re-login; a balance read taken mid-day must be reconciled to the schedule, because the figure moves every day.

The handover

Everything below is built against this app's real surfaces, not a template:

• An OpenAPI/Swagger spec for the borrower endpoints — auth, application status, account, schedule, payments.
• A protocol and auth-flow report: the token and refresh chain, request signing if present, and the status state machine.
• Runnable source in Python and Node.js for the core reads — status poll, balance, schedule — with retry and refresh built in.
• Automated tests against a consenting account or sandbox, including the token-expiry path.
• A normalised loan-account schema: THB amounts, daily accrual, due dates, payment state — ready to map into your ledger.
• Interface documentation plus PDPA-aligned consent and data-retention notes.

Where integrators put this data

• A BNPL or credit partner reconciling outstanding balances nightly against its own exposure view.
• A collections workflow firing reminders off the repayment schedule's due dates, days ahead.
• An affordability or bureau check reading a borrower's active-loan exposure, with consent, before extending more credit.
• A back-office dashboard tracking application status across borrowers, from match through disbursement.

Consent and the Thai rules in play

Thailand's Personal Data Protection Act, in force since 2022, classes financial information as sensitive personal data — that raises the bar to explicit, informed consent that the borrower can withdraw. Our basis for any read is that consent, recorded, scoped to the fields you use, and revocable. We log access, minimise what is pulled, and put an NDA over the work where a counterparty is involved. On the lending side the operator runs under a PICO Finance licence from the Ministry of Finance, a regime that caps the effective annual rate (the framework ceiling is 36% including fees, per the Fiscal Policy Office); the app's stated 26%/yr sits inside that. None of this is a wall in front of the build — it is how the build is run.

What we plan around on this build

Two things shape this integration more than anything else, and we account for both up front.

• Daily accrual. The outstanding balance is not a static number — it moves with the 0.04–0.07%/day rate the app quotes. We read it as a live value and reconcile every read against the installment plan, so a figure taken at 9am and one taken at 9pm both tie out.
• A live status state machine. Application status walks from matched to submitted to review to approved to disbursed. We map each transition so a polling client never silently misses one — the disbursed event in particular, which is what most downstream workflows wait on.
• App-build drift. When SIAMTECH ships a new release, request and response shapes can shift. We keep a check in maintenance that flags a changed response before it quietly breaks your sync.

Access is arranged with you during onboarding; the build runs against a consenting borrower account or a sandbox, set up together.

Screens from the app

The store screenshots, useful for matching interface evidence to the surfaces above:

Sources we opened

Checked in June 2026: the operator's own PICO services page for the loan products and the account features a signed-in user sees; the app's Play Store description for the loan envelope, rate and worked example; the Bank of Thailand's Open Data pages for the data-sharing scope and timeline; and Thai PDPA guidance for the consent basis. Primary references:

• SIAMTECH Digital — PICO services and app features
• Bank of Thailand — Open Data ("Your Data")
• Bank of Thailand — data-sharing regulation (Nov 2025)
• DLA Piper — data protection law in Thailand (PDPA)

Mapped by the OpenBanking Studio integration desk · June 2026.

Other Thai lending apps in the same picture

An integrator rarely stops at one lender. These are real apps in the same Thai consumer-credit space; named here for context, not ranked. A unified interface across several of them normalises balances, schedules and statuses into one shape.

• LINE BK — bank-grade lending and deposit accounts inside LINE; holds balances, statements and loan positions.
• MoneyThunder — SCB Abacus digital lending under BOT supervision; loan accounts and repayment data for thin-file borrowers.
• PROMISE สินเชื่อส่วนบุคคล — personal loans with in-app status, balance and installment data.
• Kredivo Thailand — pay-later and cash loans with a revolving limit and a per-user transaction ledger.
• Good Money (by GSB) — personal and nano-finance loans aimed at the underserved, with account and schedule data.
• ไทยแนนซ์ (Thai Nance) — online cash advances with application status and repayment tracking.
• มีตัง (Mee Tang) — provincial-level microfinance loan app under Ministry of Finance supervision.
• Krungsri iFIN — personal credit line with balance, limit and statement data in-app.
• KTC — card and personal-loan accounts moving onto mobile, with transaction and statement history.

Questions integrators ask

Where does a borrower's loan balance live in ชัยเครดิต-Credit, and can it be read as it changes?

It sits in SIAMTECH Digital's backend, behind the app login — the same store the account screen reads for balance and repayment schedule. Because interest accrues daily, we read it as a live value and reconcile each read against the installment plan rather than caching a stale figure.

How does Thailand's BOT Your Data rollout affect reaching this loan data?

The Bank of Thailand's Open Data regulation opens consented sharing of deposit, loan and payment data through standardized channels, starting with personal deposit data around late 2026 and widening across 2027 to 2028. Loan records sit in that later phase, so the channel that returns this app's ledger today is authorized analysis of its own client traffic, with the regulated path adopted as it comes online.

Is a borrower's consent enough under Thai law to pull their statements?

Financial data is sensitive personal data under Thailand's PDPA, so the basis is the borrower's explicit, withdrawable consent, recorded and scoped to what you actually use. We keep the consent record, minimise the fields pulled and log access; where a counterparty needs it, an NDA covers the engagement.

Can you start from the app alone, before we hand over a test login?

Yes. Give us the app name and what you want from its loan data; access, a consenting account and any sandbox are arranged with you as the build runs. The first read we usually target is application status and the account balance, since those drive most lender workflows.

A ชัยเครดิต-Credit build runs in one to two weeks. Take it as source-code delivery from $300 — the runnable endpoints, OpenAPI spec, tests and interface docs, paid only after we hand it over and you are satisfied — or skip the build and call our hosted endpoints, paying per call with nothing upfront. Tell us the app and what you need from its loan data, and we set up access, consent and the sandbox with you. Start at our contact page.