Pulling balances and statements out of Citibank Korea's app

Citibank Korea stopped taking new consumer customers in February 2022 — per reporting on its retail exit, which the bank first announced in 2021 — yet existing Citi Mobile accounts stay open until each holder decides to close them. That gap is the whole integration problem here. The accounts still hold money, still post transfers, still issue statements, and the people who own them increasingly want that data sitting inside a different app: an aggregator, a bookkeeping tool, a migration to another Korean bank. The Citi Mobile app (package kr.co.citibank.citimobile, per its Play Store listing) is the front door; the data behind it is reachable through Korea's regulated data-portability rails with the account holder's consent.

So this brief is not about a growing product surface. It is about reaching the records inside a wound-down but still-live retail estate, cleanly and with consent, and handing you runnable code that does it.

What the account actually holds

These are the surfaces an integrator would target, named the way Citi Mobile presents them to a holder.

The routes that actually apply

MyData / open-banking consent

This is the clean path for a Korean bank account. Under the Credit Information Act's MyData licensing regime, a consented data subject can have their balances, transactions and product details pulled through a standardized API, and the KFTC open-banking rails carry inter-bank balance and transfer queries. For a legacy Citi Korea account this is the most durable option: it survives app redesigns because it does not depend on the app's own screens, and it is built around explicit, revocable consent. What's reachable is whatever the holder authorizes — typically balances, transaction history and account meta. We set up the licensed or sponsor route during onboarding so the build runs against a real grant.

Authorized interface integration / protocol analysis

Where a host needs a field the aggregation API does not expose — a specific statement layout, a notification event, a passbook PDF — we analyze the app's own authenticated traffic under the holder's authorization and implement the request/response directly. Effort is higher and it needs a re-validation pass when the front end changes, but it reaches surfaces the standardized feed flattens away.

Native export as fallback

The passbook copy and PDF export are first-class features in the app. For one-off or low-frequency needs, ingesting those artifacts and parsing them is cheap and entirely within what the holder can already do. It does not scale to live sync, so it sits underneath the consented API rather than replacing it.

For most jobs on this app the consented MyData/open-banking link is the one we'd build first — it is the route a Korean regulator already expects for this exact data, and for a wind-down estate where the holder simply wants their records elsewhere, consent is the natural and lowest-friction basis. Protocol work gets layered in only for the specific fields that route can't return.

What lands in your repo

• An OpenAPI/Swagger spec for the endpoints we wire — balance read, transaction list, statement fetch — modeled on the account's real surfaces.
• A protocol and auth-flow report: the phone-verification + 6-digit PIN registration, device binding, and the token/cookie chain for a consented session, written up so your team can maintain it.
• Runnable source for the key endpoints in Python or Node.js, with the consent handshake, paging, and error handling already in place.
• Automated tests against captured fixtures so a front-end change surfaces as a failing test, not a silent data gap.
• Interface documentation and data-retention guidance covering consent records, logging, and how long pulled data is kept.

A transaction pull, sketched

Illustrative shape of a consented transaction read — field names and the exact token exchange are confirmed during the build against the live grant, not asserted here.

# Consented transaction read — illustrative, MyData/open-banking style
import requests

def list_transactions(access_token, account_id, since):
    resp = requests.get(
        "https://api.example-aggregation.kr/v1/accounts/%s/transactions" % account_id,
        headers={
            "Authorization": "Bearer %s" % access_token,   # holder-consent grant
            "x-consent-scope": "balances,transactions",
        },
        params={"from": since, "limit": 100},
        timeout=20,
    )
    if resp.status_code == 401:
        raise ConsentExpired("re-run the consent refresh before retrying")
    resp.raise_for_status()
    body = resp.json()
    for tx in body["transactions"]:
        yield {
            "posted_at": tx["transactionDate"],
            "amount": tx["amount"],
            "counterparty": tx.get("payeeAccount"),
            "memo": tx.get("description"),
        }
    # cursor paging until the consented window is exhausted
    if body.get("nextCursor"):
        yield from list_transactions(access_token, account_id, body["nextCursor"])

Consent, and the rules around it

The governing regime is the Credit Information Act (신용정보법) and its MyData licensing system, supervised by the Financial Services Commission, with the Personal Information Protection Act sitting underneath it for personal-data questions. MyData in financial services has been live since January 2022; the FSC reported 69 MyData providers and 117.8 million cumulative subscriptions as of end-February 2024, and has published a MyData 2.0 plan extending scope and consent handling. The Act requires prior, purpose-limited consent, a clear statement of what is collected and for how long, and it gives the data subject the right to revoke.

We operate consent-first: every pull is tied to an authorization record, sessions are logged, data is minimized to the consented scope, and an NDA is in place where the engagement needs one. Consent has a refresh window, so the integration is designed to renew rather than silently lapse. The dependable basis throughout is the account holder's own authorization, not any assumption about what the bank exposes.

Things we handle on this one

Two details about Citi Mobile shape how the build is designed, and we account for both up front.

• Anti-tamper posture. The app refuses to run on rooted or jailbroken devices and binds to a device ID with a 6-digit PIN. We don't fight that. The consented build draws data over the regulated API or a holder-authorized session, so the app's tamper checks are never in the data path — and we map the registration and device-binding flow so a session reconnects cleanly instead of forcing a full re-enrollment.
• Legacy product mix. Because the consumer bank is wound down, some product types are effectively read-only for existing holders. We map which surfaces still return live data before committing the schema, so the integration reflects what an existing account actually serves rather than a full live product catalog that no longer applies.
• Consent cadence. MyData consent expires and must be refreshed. We design the sync around that window — renewal is part of the maintenance design, not an afterthought that breaks the feed a month in.

Where this gets used

• A Korean aggregator wants a holder's Citi Korea balances and transactions alongside their other banks, refreshed daily under one consent.
• A bookkeeping product reconciles Citi Mobile transfer history into its ledger so a small business closing its Citi account keeps a clean record.
• A migration tool ingests the passbook PDF and statement lines to pre-fill an application at the holder's new bank.

App screens

Store screenshots, opened during the mapping. Click to enlarge.

Sources and how this was put together

Mapping done in June 2026 from the app's Play Store listing and description, Korea's open-banking and MyData regulatory material, and reporting on Citibank Korea's retail exit. Primary references: Citi Mobile on Google Play, FSC — MyData 2.0 plan, MyData launch coverage, and ICLG Fintech — Korea.

OpenBanking Studio · integration desk mapping, June 2026.

Other Korean banking apps in the same picture

Anyone aggregating a Citi Korea account is usually holding accounts at several of these too; a unified integration spans them through the same MyData rails.

• KB Star Banking — KB Kookmin Bank's main app; balances, transfers and a broad product set behind PIN/biometric login.
• Shinhan SOL — Shinhan Bank's flagship app with accounts, cards and investment views.
• Hana 1Q — Hana Bank's banking app covering deposits, transfers and FX.
• Woori WON Banking — Woori Bank's consolidated app for retail accounts and payments.
• NH All One Bank — NongHyup's retail banking app, widely held across regional Korea.
• Toss — Viva Republica's finance super-app aggregating accounts, cards and payments.
• KakaoBank — internet-only bank with deposits, loans and transfers, large retail base.
• K Bank — Korea's first internet-only bank, deposit and lending products.
• Standard Chartered Korea (SC제일은행) — another foreign-owned retail bank with comparable account data.

Questions an integrator asks here

Citibank Korea wound down its consumer bank — can its accounts still be integrated?

Yes. The retail exit stopped new sign-ups, but existing Citi Mobile accounts stay open until each holder closes them, so they still carry balances, transfer history and statements. A consented MyData or open-banking link reaches that data the same way it reaches any held Korean account.

Which Korean rules govern pulling data out of Citi Mobile?

The Credit Information Act and its MyData licensing regime, supervised by the Financial Services Commission, with the inter-bank open-banking rails run by the Korea Financial Telecommunications & Clearings Institute (KFTC). Consent is per data subject, purpose-limited, and has a defined refresh window.

The app refuses to run on rooted or jailbroken phones — does that block a build?

No. We do not bypass that check. We build against a consenting holder's account or a MyData/open-banking consent grant, where data arrives over the regulated API rather than off a tampered device, so the app's anti-tamper posture is never in the path.

How is access to a legacy Citi Korea account arranged for the build?

You give us the app name and what you want from its data; we arrange the consented account or MyData grant with you during onboarding and run the build against it. Access and compliance are handled as part of the project.