Integrating with UCHOOSE, Krungsri Consumer's card app

UCHOOSE sorts every card swipe into six spending buckets — shopping, food, travel, lifestyle, bill payments, and a catch-all — and keeps them behind a Krungsri Consumer login, next to statements, due dates, card locks and a loyalty wall. Krungsri Consumer has publicly targeted 7.3 million UCHOOSE accounts (per Money & Banking, 2023), so the data behind that login is not a niche feed. It is the front end to First Choice and other Krungsri-issued cards. This brief maps what a third party can reach inside it, the authorized route to get there, and the code we hand back.

The bottom line: the richest, reachable-today surface is the authenticated app itself — a cardholder who consents can hand us access to everything UCHOOSE renders for them. Thailand's national open-data regime is real and moving, but credit-card data sits in a later rollout phase, so we build on consent now and design so the same integration can ride the regime once it covers cards.

Card, payment and loyalty data the app puts in front of its users

Each row below is something UCHOOSE actually renders to a signed-in cardholder, mapped to where it lives in the app and what an integrator does with it.

The app's own listing describes First Choice limits up to roughly 2 million baht and effective rates in the 21–25% band; those figures are the product's, not ours, and we treat them as inputs, not claims to re-publish.

An auth-and-statement pull, sketched

The login is device-bound. A short-lived token guards each read, and the app throttles rapid statement fetches, so a real integration paces itself and refreshes cleanly. The shape below is illustrative; exact field names and the token chain are confirmed against a consenting account during the build.

# Illustrative. Auth chain and field names verified during the build,
# run against a cardholder who has consented.

POST /uchoose/auth/token            # device-bound login
  body: { deviceId, username, pinHash }
  -> { accessToken, refreshToken, expiresIn }     # accessToken is short-lived

GET  /uchoose/cards                  # cards on this profile
  auth: Bearer <accessToken>
  -> [ { cardId, product: "First Choice", last4, statusFlags } ]

GET  /uchoose/cards/{cardId}/statement?cycle=current
  -> { closingBalance, dueDate, minPayment,
       txns: [ { postedAt, amount, merchant, mcc,
                 appCategory } ] }    # appCategory is user-editable

on 401 -> refresh(accessToken) via refreshToken; retry once
on 429 -> back off; the app rate-limits back-to-back statement reads

Note appCategory beside mcc: the cardholder can re-file a transaction into a different bucket, so those two fields disagree by design. We keep both.

The package that lands on your side

Handover centres on the statement, transaction and payment reads a cardholder sees in U Manage and U Pay:

• An OpenAPI/Swagger spec covering the statement, transaction, payment and card-control reads as UCHOOSE exposes them.
• A protocol and auth-flow report: the device-binding step, token issuance and refresh cadence, and how sessions expire.
• Runnable source for the key reads — Python or Node.js — including the merchant/MCC-plus-app-category mapping so categorized spend arrives normalized.
• Automated tests that replay captured sessions and assert on statement and transaction shapes.
• Interface documentation an in-house engineer can maintain after handover.
• PDPA-aligned data-retention and consent-record guidance for the card data you will hold.

Authorized ways into the data

Cardholder-consented interface integration

With the cardholder's authorization, we analyze the app's own traffic and rebuild the reads as a clean interface. This reaches everything UCHOOSE shows — statements, categorized spend, payments, card state, U Like offers. Effort is moderate; durability depends on the app's front end, which we account for with a re-check step. Access is set up together with you against a consenting account when the project starts.

Bank of Thailand open-data ("Your Data")

The BOT enacted an open-data regulation in late 2025 (announced by the Bank of Thailand) that lets consumers direct a supervised provider to share their financial data — deposit, loan, payment, e-money and credit-card. Deposit data leads the rollout around late 2026; card data sits in the phase running through 2027–2028. Reachable coverage is narrow today, high once cards are in scope, and durable because it is regulator-defined. We position the integration to switch onto it as a recipient when the phase lands.

dStatement, for statement documents

Thailand's dStatement service (live since 2022, identity-checked through NDID) moves machine-readable bank statements between institutions. Where statement documents are the goal rather than live in-app fields, it is a clean, sanctioned fallback for that slice.

For a team that needs the data working this quarter, the consented interface route is the one we would build first — it is the only one that reaches the full card-and-spend surface today — while we wire it so the BOT regime becomes a drop-in source once its card phase is live.

Where teams actually plug this in

• A Thai personal-finance app pulling a consenting cardholder's categorized First Choice spend to show a unified monthly picture.
• An accounting tool reconciling a small-business owner's Krungsri card statements against posted transactions.
• A lender using consented, current card balances and the U Product credit line as affordability signals.
• A loyalty aggregator syncing U Like entitlements so offers surface outside the app.

Consent, and where Thailand's rules actually stand

Under the PDPA — in force since June 2022 — financial data is sensitive personal data, so processing needs the cardholder's explicit, documented consent with a clear way to withdraw it. The regulator has moved from guidance to penalties; the first sizeable administrative fines landed in August 2025 (reported at over 21 million baht), which is the enforcement climate any card-data integration now operates in. We work consent-first: authorized or user-consented access only, every read logged, consent records kept, data minimized to what the use case needs, and an NDA where the engagement calls for one.

The BOT open-data regime matters for the medium term, not today's card pull. Because its credit-card phase is still ahead, we do not treat card data-sharing as a present-tense right; the cardholder's own consent is the basis we build on, with the regime as the path the same integration grows into.

Build details specific to Krungsri Consumer's stack

UCHOOSE fronts more than one card product on a single login — First Choice sits beside other Krungsri-issued and co-brand cards. We map each product's statement schema on its own so a multi-card cardholder reconciles per card, never as one blurred balance.

The six spending categories are user-editable — a cardholder drags a transaction into whichever bucket they prefer — so the app-side tag can diverge from the acquirer's merchant coding. We persist both the UCHOOSE category and the underlying merchant name and MCC, keeping downstream analytics stable when a user re-files something. And because the token is short-lived and the app throttles repeated statement reads, we build the sync around that refresh window and back-off behaviour so it neither expires mid-run nor trips the app's rate limit. When the app's front end changes, a re-validation pass catches it before your data goes stale.

Screens we referenced

Store screenshots we looked at while mapping the surfaces above.

Where UCHOOSE sits among Thai finance apps

A single integration usually spans several of these. Neutral notes on what each one holds:

• K PLUS (Kasikornbank) — full retail bank app with accounts, transfers and card management; the broadest Thai mobile-banking data set.
• SCB EASY (Siam Commercial Bank) — accounts, cards, payments and P2P transfers behind one login.
• Krungthai NEXT (Krungthai Bank) — transfers, bill pay, loans and payment reminders for KTB customers.
• UOB TMRW (UOB Thailand) — manages UOB credit cards, tracks spending and shows statements in real time.
• KTC Mobile (Krungthai Card) — a card-issuer app for statements, points and card payments, close in scope to UCHOOSE.
• TrueMoney Wallet — a widely used e-wallet for top-ups, everyday payments and small transfers.
• Rabbit LINE Pay — wallet and transit payments tied into the LINE ecosystem.
• Bangkok Bank Mobile Banking (Bualuang) — accounts, cards and transfers for Bangkok Bank customers.

How this brief was put together

Checked on 1 July 2026 against the app's own store and Krungsri Consumer material, the Bank of Thailand's open-data and dStatement pages, and Thai data-protection references. Primary sources:

• Krungsri Consumer — UCHOOSE
• Bank of Thailand — consumers' right to share financial data (2025)
• Bank of Thailand — dStatement
• Money & Banking — Krungsri Consumer's UCHOOSE 7.3M account target

Mapped by the OpenBanking Studio integration desk · 2026-07-01.

Questions integrators ask about UCHOOSE

Can you keep UCHOOSE's user-edited spend categories separate from the card network's merchant coding?

Yes. The app lets a cardholder drag transactions between its six spending buckets, so the app-side category can drift from the acquirer's merchant code. We store both the UCHOOSE category and the underlying merchant name and MCC, so your analytics can trust one and audit against the other.

Is credit-card data shareable now under Bank of Thailand's open-data rule?

Not yet for cards. The Bank of Thailand's open-data regulation was enacted in late 2025 and rolls out in phases — deposit data first around late 2026, with loan, payment, e-money and credit-card data in the following phase through 2027 to 2028. Until then the dependable basis is the cardholder's own documented consent.

Which Krungsri card products show up in the app, and can a multi-card cardholder be reconciled?

UCHOOSE fronts First Choice and other Krungsri Consumer-issued and co-brand cards on one login. We map each product's statement schema separately, so a cardholder holding more than one Krungsri card reconciles per card rather than as a single blurred balance.

How fresh is the statement and transaction data you return?

Posted transactions and closing balances refresh on the app's own polling cadence, which we mirror rather than hammer. We design the sync around the token and consent-refresh window so a session does not silently expire mid-pull, and we timestamp every record so downstream systems know exactly how current each field is.

Source for the UCHOOSE statement-and-category pull starts at $300, billed only after we deliver it and you have run it against a consenting account; prefer no build at all and you can call our hosted endpoints instead, paying per call with nothing upfront. Either path runs one to two weeks. Tell us the app and what you need from its data, and we handle access and compliance with you — start a project.