Integrating the CardX app: e-Statement, Dee Jung and the SPEEDY ledgers

On 10 December 2022 CardX absorbed the credit card book, the SPEEDY CASH cash cards and the SPEEDY LOAN personal-loan portfolio that had previously sat inside Siam Commercial Bank, under the SCBX reorganization announced the prior year. CardX's own TiDB-on-AWS case study with PingCAP describes the resulting core as scaling 3–4 million credit accounts, and the th.co.cardx Android app — together with its iOS sibling at App Store id 1622961294, per the Thai App Store listing — became the surface those customers now read their statements, schedule Dee Jung conversions and watch their SPEEDY ledgers through.

The integration question for a partner is rarely whether CardX holds the data. It is which slice of it is in scope, how the authentication chain (CardX, SCB EASY, NDID via ThaID) plays with the partner's own auth, and what survives the transition to the Bank of Thailand's Your Data regulation when the credit card phase lights up. That is what the rest of this page works through, ending with the specific deliverable we hand over for a CardX build.

Data that lives behind a CardX login

Each row below maps a surface a logged-in CardX customer sees to where it originates in the app and what an integrator typically does with it. Surface names follow CardX's own labels where the cardx.co.th product pages or the App Store listing use a specific Thai term.

One thing the table cannot say cleanly: a small number of co-branded SCB credit cards are still serviced inside SCB EASY rather than CardX. Reviews of the CardX app flag this; the integration plan accounts for it (see build notes below).

Routes that actually reach this data

Four routes apply to CardX. Of the four we typically build route 1 first; route 2 gets wired as the on-ramp the moment the BOT Your Data credit card phase lands.

1. PDPA-grounded consent into the app's authenticated surfaces

The customer authorizes the integration explicitly under Thailand's PDPA, with purpose and scope written into a consent record we keep alongside the integration. The build then reads the same e-Statement, Dee Jung, SPEEDY and POINTX surfaces the customer sees in the app. Effort is moderate; durability is good as long as the consent is refreshed and the app version is tracked. Onboarding access — a consenting test account, the CardX app build we test against, and the partner's PDPA paperwork — is arranged with you in week one.

2. BOT "Your Data" data-share rail (forward-looking)

Once the credit card phase of the 30 October 2025 regulation goes live in the 2027–2028 expansion, the same data points can be requested over a BOT-supervised data-share interface. We design the internal interface today so that the swap is a transport change rather than a rewrite. This route is not in force yet for credit cards and the brief is honest about that.

3. NDID-mediated re-auth via SCB TechX's NDID Proxy

CardX's onboarding/eKYC rides on SCB TechX's NDID Proxy talking to ThaID, per SCB TechX's own product write-up. That same path is the cleanest way to keep a long-running consent alive across customer device changes; we wire it in for partners whose users churn devices frequently.

4. Native export (e-Statement PDF)

CardX issues monthly e-Statements that can be downloaded by the customer. As an integration route this is a thin fallback — fine for a one-off statement pull, weak for live reads. We parse it where it earns its place and skip it otherwise.

A sample request against the statement endpoint

The pseudo-call below is illustrative, with the exact shape confirmed during the build against the customer's own consenting account. Field names follow CardX's own surface labels where they are visible to the user, so the JSON your service writes against will read the same way the app does.

POST /v1/cardx/statement.query
Headers:
  Authorization: Bearer <session_token>     # from the PDPA-consented auth flow
  X-Device-Fingerprint: <stable_install_id> # the app expects a per-install id
  X-CardX-App-Version: 2.14.2               # Android floor tested in this build
Body:
  {
    "card_token": "ctx_xxx",                 # opaque per consented card
    "from":  "2026-04-01",
    "to":    "2026-04-30",
    "include": ["transactions", "dee_jung_actions", "pointx_deltas"]
  }

Response (200, illustrative):
  {
    "card_token": "ctx_xxx",
    "currency":   "THB",
    "statement_cycle": { "closes": "2026-04-25", "due": "2026-05-10" },
    "available_credit": 84200.00,
    "transactions": [
      { "posted": "2026-04-03", "merchant": "BTS RABBIT",
        "amount": -320.00, "category": "transport" },
      { "posted": "2026-04-14", "merchant": "TOPS DAILY",
        "amount": -1480.50, "category": "groceries" }
    ],
    "dee_jung_actions": [
      { "type": "transfer", "amount": 15000.00,
        "tenor_months": 12, "effective_rate": 0.22,
        "destination_bank": "SCB", "booked_at": "2026-04-08T11:02:00+07:00" }
    ],
    "pointx_deltas": [
      { "date": "2026-04-12", "points":  850, "reason": "spend_accrual" },
      { "date": "2026-04-19", "points": -300, "reason": "redeem_cashback" }
    ]
  }

Failure modes worth handling explicitly:
  401  consent_expired       -> trigger NDID re-auth via SCB TechX proxy
  409  card_not_in_cardx     -> fall back to the SCB EASY adapter
  423  app_version_too_old   -> refresh the per-install fingerprint & retry

What lands in the repo at handover

A CardX engagement closes with a usable build sitting in your repository. Concretely:

• An OpenAPI 3 spec covering the surfaces named above: /statement.query, /dee-jung/transfer.simulate, /dee-jung/installment.preview, /speedy-cash/draws, /speedy-loan/schedule, /pointx/balance, /pointx/redemptions, plus the auth and refresh routes.
• A protocol & auth-flow report walking through the SCB-EASY-adjacent login chain, the session refresh window observed during the build, and the NDID-mediated re-auth handoff for long-running consents.
• Runnable Python and Node.js source for the most-asked endpoints — typically the e-Statement pull and the Dee Jung simulate/book pair — so your team can run the build the day of handover.
• A contract test suite (pytest by default) that hits a consenting account in your environment, plus a recorded-fixture replay so CI does not need a live login on every run.
• Compliance notes: the PDPA consent record schema, scope-tracked retention policy, and a short paragraph on how to flip transport to a BOT-supervised Your Data rail when the credit card phase ships.

Three concrete things integrators have built on this

A few shapes show up repeatedly when partners brief CardX work. Each is delivered as the same OpenAPI surface above, scoped narrowly:

• Expense automation for SME owners. A daily pull of the credit card e-Statement into the partner's bookkeeping tool, with CardX-side categorisation preserved and Dee Jung Installment bookings split into separate accounting lines.
• Debt-coaching dashboard. A weekly snapshot of the SPEEDY LOAN amortization schedule and SPEEDY CASH draws, surfaced to the customer in a third-party planning app, with early-payoff scenarios calculated against CardX's published interest method (reducing-balance Effective Rate).
• Rewards aggregator. A nightly read of POINTX balance and recent redemptions, combined with the same customer's KTC FOREVER, Krungsri UCHOOSE and AEON points in a single ledger.

The Thai consent rules CardX integrations live under

Today the dependable basis for a CardX integration is the customer's PDPA-grounded consent — explicit purpose, explicit scope, revocable. Thailand's Personal Data Protection Act (B.E. 2562) has been fully in force since 1 June 2022, and the PDPC's cross-border transfer notifications implementing Sections 28 and 29 took effect on 24 March 2024, per the Royal Gazette publication of 25 December 2023. Enforcement is no longer theoretical: PDPC announcements through 2024 and 2025 describe penalties in the THB 15–21 million range across published cases, per DLA Piper's 2025 analysis.

The Bank of Thailand's "Your Data" regulation is where the route widens. The 30 October 2025 enactment, per the BOT's own press release, gives consumers and businesses a right to share BOT-supervised financial data — deposit, loan and payment information via accounts, e-money and credit cards — across BOT-supervised providers. Phased go-live runs end-2026 through 2027–2028, with deposit account information first and credit card information later in the expansion. CardX, as a BOT-supervised non-bank credit card operator, sits inside that perimeter. We design the consent storage and the internal interface today so that the eventual swap is a transport change, not a re-architecture.

Notes from previous CardX builds

Two judgements are worth stating up front, because they shape the scope conversation more than anything else.

We scope CardX integrations across the three product families separately. Credit cards, SPEEDY CASH cash-cards and SPEEDY LOAN personal loans share an app, not a data model. Dee Jung options, repayment schedule fields and POINTX visibility differ between them, and a single "CardX" integration that flattens them quietly loses what makes each useful. We agree which families are in scope at week one and price accordingly.

Re-auth is designed around SCB TechX's NDID Proxy, not against it. CardX's onboarding/eKYC already rides that path to ThaID, and it is the cleanest way to keep a consented session alive across device changes. We wire the partner's re-auth into the same chain rather than building a parallel one. The consenting test account, the CardX app build we pin against, and the partner's PDPA paperwork are arranged with you during onboarding so the build hits real CardX data, not just a description of it.

One smaller note that has tripped up two previous engagements: the CardX rebrand left a handful of co-branded SCB credit cards inside SCB EASY rather than CardX. We list which cards fall under that thin SCB EASY adapter as part of the design note, so the downstream caller does not need to know which surface a given card lives on.

One last housekeeping point on identity: the US payment-surcharging company at cardx.com is unrelated to the SCBX-spinoff Thai CardX. We confirm at the kickoff that we are integrating th.co.cardx, the SCBX entity, not the US namesake.

Other Thai card and consumer-finance apps in this neighbourhood

The list below is for context only: each entry is a real same-category Thai app whose holder a unified integration commonly aggregates alongside CardX. Names are neutral; we work with whichever the partner asks for, in the same shape.

• KTC Mobile — published by Krungthai Card PCL; surfaces KTC credit cards and KTC PROUD personal loans.
• MAAI by KTC — companion loyalty/rewards app from Krungthai Card PCL.
• UCHOOSE — Krungsri Consumer; manages Krungsri Credit Card, Krungsri First Choice, Krungsri Now and HomePro Visa from a single login.
• Krungsri First Choice — revolving credit and personal-loan product surfaced through UCHOOSE.
• AEON THAI MOBILE — AEON Thana Sinsap (Thailand) PCL; AEON credit cards, Digital Your Cash, Happy Loan, auto loans, insurance.
• ttb touch — TMBThanachart's mobile banking app and the main channel for ttb credit cards and personal/auto loans.
• UOB TMRW Thailand — UOB Thailand's digital banking app, including the former Citi Thailand consumer portfolio after the UOB acquisition.
• LINE BK — KASIKORN LINE joint venture; Credit Line and Nano Credit Line products inside LINE.
• Krungthai NEXT — Krungthai Bank's banking app, covering KTB credit cards and personal loans.
• K PLUS — Kasikornbank's flagship mobile banking app; KBank credit card surfaces live here.

Questions integrators ask before signing

Does the integration cover Dee Jung Transfer (credit-to-cash) end to end, or just the e-Statement view?

Both. The handover includes the Dee Jung simulation call (amount, tenor, effective rate) and the booking call, alongside the e-Statement transaction feed and the SPEEDY CASH and SPEEDY LOAN schedules. Dee Jung Installment, Dee Jung 0% and Dee Jung Min Pay are mapped separately because their permitted tenors and eligible amounts differ; we name which Dee Jung variants you actually need at scoping.

How does authenticating against CardX compare with going through SCB EASY?

CardX and SCB EASY share an upstream identity story — eKYC for new CardX customers is handled by SCB TechX's NDID Proxy talking to ThaID — but the per-product surfaces and session handling differ. An SCB EASY token does not directly transact on a CardX SPEEDY LOAN schedule, and vice versa. We treat them as two adjacent endpoints behind one internal interface.

Will the Bank of Thailand "Your Data" rule cover CardX data when it goes live?

The 30 October 2025 regulation explicitly names credit card information in its scope (payment information via accounts, e-money and credit cards), with phased go-live from end-2026 into 2027–2028. CardX, as a BOT-supervised non-bank credit card operator, sits inside that perimeter. Our build today is structured so the swap to a BOT-supervised data-share rail, when the credit card phase lands, is a routing change behind the same OpenAPI surface rather than a rebuild.

What happens for the cards that are still managed in SCB EASY instead of CardX?

A handful of co-branded SCB credit cards are still serviced inside SCB EASY rather than CardX. The integration plan covers both endpoints — a thin SCB EASY adapter sits behind the same internal interface, so a downstream caller does not need to know which surface a given card lives on. The list of cards that fall under that adapter is documented as part of the design note.

Where these notes came from

Sourcing for this brief: the CardX spin-off chronology was cross-checked against SCBX's investor relations page and contemporaneous Thai news from October–December 2022. The data-surface list comes from the cardx.co.th product pages and the Thai App Store listing for app id 1622961294. The 3–4 million credit-account scale figure is from CardX's own PingCAP case study. The Bank of Thailand "Your Data" status, scope and phasing are from the BOT press release on the 30 October 2025 enactment. Reviewed 30 May 2026 by the OpenBanking Studio integration desk.

A source-code delivery covering the CardX surfaces named above starts at USD 300, paid after handover once it runs against your account — one to two weeks end to end is the usual cycle. If you would rather not host anything, the same endpoints are available as a pay-per-call hosted API with no upfront fee. Send the app name and what you want from it via /contact.html and we will scope it.