Pulling card and loan records out of CardX

CardX carries the unsecured book that Siam Commercial Bank moved out of the bank: credit cards, the SPEEDY CASH cash-advance card, and SPEEDY LOAN personal loans. The transfer completed in December 2022, and the company now sits inside the SCBX group. For anyone building a debt-tracking, lending, or personal-finance product in Thailand, the records behind this one app — billed transactions, interest accrued daily, minimum-due math, installment schedules — are exactly the structured server-side state worth a clean integration.

The bottom line: a vendor API is beside the point here. We map the cardholder-facing surfaces of CardX under that cardholder's consent, normalize what they show, and hand back runnable code plus a spec. The recommendation for CardX specifically is to build against the authenticated app session today and keep the schema aligned to the Bank of Thailand Open Data field shapes, so the same integration slides onto the regulated rails when credit-card data joins that scheme. That choice is driven by timing, not preference — the regulated channel is real but phased in later than card data.

What CardX actually holds

These are the surfaces a cardholder sees in the app, mapped to what an integrator would do with each. Rows reflect CardX's own product naming.

Routes to the data

1 — Authorized interface integration (consented session)

A consenting cardholder authenticates the way they normally do; we observe and document the traffic the app produces and rebuild the calls behind the e-Statement, SPEEDY CASH, and SPEEDY LOAN screens. Reachable: everything the cardholder can see. Effort: moderate, since the login chain involves NDID verification and a device PIN. Durability: solid between front-end changes, with a re-check when the app ships a major release. We arrange the consenting account or a sponsor's test profile with you during onboarding.

2 — Bank of Thailand Open Data ("Your Data")

The BOT's Open Data programme gives individuals a standardized right to share data held by financial providers. Its consultation material describes a phased start with personal deposit data near the end of 2026, expanding to loans and credit cards through 2027–2028. For CardX this is the durable long-run channel; we shape the integration so the field schema matches that standard now and the connector can switch rails when card data is admitted. We handle the consent-grant plumbing on that scheme as it becomes available.

3 — Native in-app export

Where the cardholder can pull an e-Statement document themselves, we wire parsing of that artifact as a low-friction supplement for statement history. Narrow, but useful for backfill before a live connection is in place.

For CardX the consented-session route is the one we would actually build first, because it reaches the full product set today and survives the wait for the regulated scheme. Route 2 is where the same code lands once the BOT rails carry card data; route 3 fills statement history in the meantime.

A worked example

Illustrative shape only — exact field names and the auth chain are confirmed during the build against a consenting account. It sketches a token refresh followed by an e-Statement query, with the daily-interest figure CardX itself documents.

POST /auth/session/refresh
{ "refresh_token": "<consented-session>", "device_id": "<bound>" }
--> 200 { "access_token": "...", "expires_in": 900 }

GET /cards/{cardId}/e-statement?cycle=2026-09
Authorization: Bearer <access_token>
--> 200 {
  "cycle_close": "2026-09-25",
  "principal": 10000.00,
  "interest": 36.16,          // (10000 x 22% x 6) / 365, per CardX docs
  "minimum_due": 301.06,      // 3% of billed, floor 100 THB
  "transactions": [ { "date": "...", "merchant": "...", "amount": ... } ]
}

# error handling we wrap:
#  401  -> token expired, re-run refresh once, then surface re-consent
#  429  -> backoff; CardX session is per-device, do not parallelize a cardholder
#  423  -> PIN/NDID step required, hand back to the consented UI, never script it

What lands at the end

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

• An OpenAPI/Swagger spec covering the e-Statement, SPEEDY CASH, and SPEEDY LOAN calls, with the product-split fields modelled.
• A protocol and auth-flow report: the NDID-plus-PIN session, the token refresh chain, and per-device rate behaviour.
• Runnable source for the key endpoints in Python or Node.js, whichever your stack uses.
• Automated tests, including the revolving-versus-installment tagging so the two products never blur.
• Interface documentation and PDPA-aligned data-retention guidance for what you store.

Consent and the Thai data regime

Thailand's Personal Data Protection Act has been in full force since June 2022, and the PDPC lists financial information as sensitive data that needs explicit, granular, withdrawable consent. That governs every CardX integration we build: the cardholder grants scoped consent, that consent is logged, and they can revoke it. We minimize to the fields a use case needs, keep consent records, and work under an NDA where the engagement calls for one. Separately, the Bank of Thailand's Open Data initiative is building the standardized sharing right that card data will eventually ride; our consent design anticipates it rather than working against it. Compliance here is how we operate, not a hoop placed in front of you.

Build notes specific to CardX

Two things shape the work on this app, and we handle both:

• SPEEDY CASH and SPEEDY LOAN compute differently — revolving with a 3% minimum and daily calendar-year interest on one side, fixed amortization with a per-installment principal/interest split on the other. We model them as separate record types so a downstream ledger never applies a revolving minimum to an installment loan.
• Login runs through NDID verification (confirmed via the SCB TechX eKYC announcement) and a device-bound PIN, and the session is per device. We design the sync around a single consented session with a single-flight refresh, so it neither trips the per-device limit nor silently expires mid-pull. A re-validation step covers major app releases as part of maintenance.

Interface evidence

Store screenshots of the surfaces referenced above. Tap to enlarge.

Peer apps in the same space

Thai card and consumer-credit apps that a unified debt or PFM integration usually has to cover alongside CardX. Plain ecosystem context, no ranking.

• KTC (Krungthai Card) — credit cards and personal loans with statement and points history behind an account.
• Krungsri First Choice — Krungsri Consumer's card and installment-loan app with repayment schedules.
• AEON Thailand — AEON Thana Sinsap cards and loans, billed transactions and installment plans.
• SCB EASY — Siam Commercial Bank's main app; CardX cardholders can still service the same card there.
• UOB TMRW Thailand — UOB cards and loans (including the former Citi consumer book) with statement data.
• Home Credit Thailand — point-of-sale installment financing with per-contract schedules.
• CIMB Thai — consumer credit and loan products with account-level records.
• TrueMoney — wallet and pay-later balances and transaction history.

Questions integrators ask

Can you keep SPEEDY CASH and SPEEDY LOAN records separate in one feed?

Yes. The two products bill on different rules — SPEEDY CASH runs revolving with a 3% minimum and a 4–36 month repayment band, while SPEEDY LOAN runs fixed installments on a 12–72 month term. We tag each record by product at extraction so a downstream system never mixes a revolving minimum with an amortizing installment.

Where do the e-Statement transactions actually originate inside CardX?

The app's e-Statement view renders billed transactions, interest accrued per the daily calendar-year method, and the minimum-due calculation per statement cycle. We map that screen to its backing calls, then normalize each line into date, merchant, amount, and the principal-versus-interest split CardX shows on the loan side.

Does the Bank of Thailand 'Your Data' scheme cover CardX card data yet?

Per the BOT's Open Data material, the phased rollout starts with personal deposit data around late 2026 and expands to loans and credit-card data across 2027–2028. Card data is named in scope but not live on day one, so the working route today is authorized interface integration under the cardholder's consent, with a path to the regulated rails as they open.

How do you handle the NDID eKYC and PIN steps when mapping the login flow?

CardX uses NDID verification (confirmed via SCB TechX's eKYC announcement) plus a device PIN. We treat both as part of the documented consented session a real cardholder establishes, capture the token and session chain that follows, and never script around the verification itself.

Sources and how this was checked

Checked in June 2026 against the CardX Play Store listing and product description, the Bank of Thailand's Open Data pages and Your Data consultation paper, the SCB TechX NDID eKYC announcement, and current PDPA enforcement coverage. Primary references:

• Bank of Thailand — Open Data
• BOT — Your Data consultation paper (PDF)
• CardX on Google Play (th.co.cardx)
• SCB TechX — CardX NDID eKYC

Mapped by the OpenBanking Studio integration desk · June 2026.

One closing note on working together. You give us the app name and what you need from CardX's data; access, the consenting account or sponsor test profile, and the compliance paperwork are arranged with you as part of the job. Pick either model: source-code delivery from $300, where you pay after delivery once the integration runs and you are satisfied; or a pay-per-call hosted API with no upfront fee, where you call our endpoints and pay only for what you use. Either way the cycle is one to two weeks. Start the conversation at our contact page.