IBK i-ONE Bank, from a logged-in screen to a consent-scoped API

Every balance, card charge and insurance record that lands on i-ONE Bank's My Assets screen already moves over Korea's MyData rails — the standardized, consent-scoped transmission APIs the Financial Services Commission mandated when the regime went live in January 2022. For anyone trying to read IBK data programmatically, that fixes the starting point: the authorized path is a regulated one, and this app sits on both ends of it. IBK is a data provider, transmitting its own deposit and card records on request. It is also a MyData operator, pulling a customer's accounts from other institutions into a single view. An integration can ride either end, and the right one depends on whose data you are after.

Where Korea's rules put this data within reach

MyData is not a vendor courtesy here; it is law. The amended Credit Information Use and Protection Act gives the data subject a right to portability of their personal credit information, and the Financial Services Commission turned that into a standardized, API-based transmission system, run through the Korea Financial Telecommunications and Clearings Institute (KFTC). A customer grants consent — and can withdraw it at any time, including through the government MyData support platform — and licensed operators then receive the records the consent covers. The Act requires a stated purpose, limits use to what is necessary, and asks institutions to make the consent legible rather than buried.

The regime keeps growing. In March 2026, Korean authorities moved to extend MyData rights beyond finance into further sectors, with public support funding attached, per Seoul Economic Daily reporting. For our purposes the practical points are narrower: consent is the basis, consents are time-boxed and re-confirmed, and the transmission runs over a versioned standard. We work to that posture — authorized and documented access, consent records and call logs retained, data minimized to the agreed scope, NDA in place where the client needs one.

What a logged-in customer can see, surface by surface

The app's description organizes the home screen into five themes — Assets, Products, Banking, Benefits, Stocks — and the data behind them is what an integrator actually wants. The table maps the real surfaces, where each originates in the app, how granular it is, and what a third party would build on it.

Routes we'd actually run for IBK data

Consent-scoped MyData transmission read

This is the regulated read. With the customer's consent in place, IBK transmits its own deposit, card, loan and investment records over the standard API; through the operator side, the same consent can pull the consolidated cross-institution picture behind My Assets. Most of the effort is in the consent grant and the certificate and token setup at the KFTC hub, which we arrange with you rather than hand you as homework. Durability is high — a regulator versions and maintains this rail, so it does not shift under a UI redesign.

Authorized interface integration

Some things MyData was never set up to carry: the in-app securities view, TokTok and photo-transfer confirmation flows, i-ONE Guard's security status, the product mall and the generational clubs. For those we analyze the app's own traffic under your authorization, map the auth token chain — the six-digit PIN, biometric or pattern login, plus device binding — and document the request and response shapes. This route needs re-validation when the front end changes; we plan for that up front.

User-consented session export

A pragmatic stopgap. Where a customer consents to a live session, we capture the statement and transaction exports the app already produces, normalize them, and use that while the consent route is being stood up.

If the data you need is account balances, transactions or the MyData asset picture, build on the consent read and do not look back — it is regulated, versioned, and will not move under you. The interface work earns its place only for the app-only screens, like the securities view or a TokTok confirmation. We rarely lead with the export path.

What a consent-scoped account read looks like

Sketch of a MyData bank-sector transaction read. The consumer login and the data transmission are two different auth paths, and the snippet keeps them apart on purpose.

# Illustrative MyData bank-sector read — org codes and exact field
# names confirmed against the spec during the build.

# 1) consumer login (app side): 6-digit PIN or biometric -> device-bound session
# 2) data transmission (server side): consent grant at the KFTC hub -> bearer token

GET /v1/banks/accounts/deposit/{account_num}/transactions
  Authorization: Bearer {access_token}     # scoped to the customer's MyData consent
  x-api-tran-id: {20-char unique tran id}  # per-call, used for idempotency + audit
  x-api-type: regular                      # regular | scheduled
  ?from_date=20260101&to_date=20260615&limit=100

# response (MyData standard shape, trimmed)
{
  "rsp_code": "00000",
  "trans_cnt": 2,
  "next_page": "",
  "trans_list": [
    { "trans_dtime": "20260612093114", "trans_type": "OUT",
      "trans_amt": "154000", "balance_amt": "2030940",
      "print_content": "TokTok transfer" },
    { "trans_dtime": "20260611201500", "trans_type": "IN",
      "trans_amt": "2500000", "balance_amt": "2184940",
      "print_content": "Payroll" }
  ]
}

# error handling: a non-"00000" rsp_code maps to a typed error; a 401 or
# expired token triggers a refresh at the hub, then a replay with the SAME
# x-api-tran-id so the call is not double-counted.
      

What lands in your repo

Deliverables are tied to the surfaces above, not a generic checklist:

• An OpenAPI/Swagger description of the account, transaction and MyData asset reads we wire, with field semantics for the messy bits like trans_type and print_content.
• A protocol and auth-flow report covering the KFTC token grant, the x-api-tran-id discipline, refresh handling, and — for the interface route — the PIN/biometric login chain.
• Runnable source in Python and Node for balance, transaction history and the My Assets aggregate.
• Automated tests that run against recorded fixtures so the suite stays green without a live consent.
• Interface documentation a backend team can hand to the next engineer.
• Consent and data-retention guidance scoped to exactly the MyData items you asked for.

Things this app does that shape the build

Two facts about i-ONE Bank change how the work is scoped, and we account for both:

• It sits on both sides of MyData. The app is a data provider for IBK-held records and an operator for everyone else's. We map both directions, so the build reads IBK balances over the provider API and, where you want the full picture, the consolidated operator view — without confusing the two consents.
• Consents expire on a clock. Korean MyData consents are time-boxed and periodically re-confirmed. We design the sync around that window and surface re-consent before a feed silently lapses, rather than discovering it when a nightly job returns empty.
• i-ONE Guard hardens the client. The bank ships its own antivirus and app-forgery checks. Those touch the interface route, not the server-to-server MyData rail, so we run the interface build against a consenting account or sandbox — access arranged with you during onboarding — and keep a re-validation pass for front-end or token-format changes.
• App login and transmission auth are separate. The six-digit PIN and biometric secure the app session; the data transmission rides a certificate and token grant at the hub. We keep those two auth paths distinct in the client so neither leaks into the other.

Where teams point this integration

• A budgeting app consolidating a user's IBK accounts alongside other banks through one MyData consent.
• An accounting tool reconciling IBK deposit movements against invoices, using the dated transaction feed.
• A lender pulling consented transaction history and the MyData credit module for an affordability check.
• A wealth dashboard merging the My Reports net-worth and asset-distribution view into its own analytics.

Screens we worked from

Store screenshots used while mapping the surfaces above. Tap to enlarge.

Where i-ONE Bank sits among Korean banking apps

The same MyData plumbing carries data across Korea's whole banking app field, which is what makes a unified integration realistic. Neighbours an aggregation project would touch:

• KB Star Banking — KB Kookmin's all-in-one app, the same operator-plus-provider duality over a large retail base.
• Shinhan SOL Bank — Shinhan's consolidated app, deposits, cards and investments under one login.
• Hana 1Q — Hana Bank's mobile app, strong on foreign-exchange and deposit data.
• Woori WON Banking — Woori's unified banking app for retail accounts and transfers.
• NH Smart Banking — Nonghyup's app, a wide rural and retail account footprint.
• KakaoBank — an internet-only bank, deposits, loans and cards, mobile-native from the start.
• Toss Bank — the Toss super-app's bank, which itself aggregates accounts across institutions.
• K Bank — an internet-only bank with deposit accounts and crypto-exchange links.

Sources and review

This brief was put together in June 2026 from the app's own Play Store description, the FSC and KFTC framing of the MyData regime, and reporting on IBK's app. Primary references opened while writing:

• Financial Services Commission — API-based MyData / open banking
• Finovate — IBK i-ONE Bank, Best Mobile Financial App (2024)
• MyData Korea — standard API base specification
• Seoul Economic Daily — Korea expands MyData rights (March 2026)

Mapped by the OpenBanking Studio integration desk · reviewed 2026-06-15.

Questions integrators ask about IBK i-ONE Bank

Does i-ONE Bank's data come through Korea's MyData scheme, or do you read the app directly?

Both are on the table. Account balances, transactions and the asset picture come through the customer's consent-scoped MyData transmission read, which is the durable, regulated route. Surfaces MyData was never set up to carry — the in-app securities view, TokTok transfer confirmations, i-ONE Guard status — come through authorized interface integration of the app's own traffic.

Can you reach the My Assets view that aggregates accounts from other banks and cards?

Yes, through IBK's MyData operator side, but only within the scope the customer consents to — each outside institution has to be covered by that consent. IBK's own deposit and card records come through the data-provider side, which is simpler to set up.

How does i-ONE Guard and the app's anti-tampering affect an integration?

It mostly affects the interface route, not the MyData read. The MyData transmission API is a server-to-server regulatory rail, so i-ONE Guard's device checks don't touch it. For the interface route we run against a consenting account or sandbox and wire a re-validation pass for when the front end or token format changes.

Who needs to hold the MyData licence for an IBK integration?

The MyData operator licence sits with a licensed financial entity in Korea, not with us. We build and document against the consenting-account and data-provider path, and the licensed-route specifics get arranged with you during onboarding alongside access and consent paperwork.

Most IBK builds run a one-to-two-week cycle. You can take the work as source — runnable Python or Node clients for the account, transaction and MyData asset reads, the OpenAPI description, the consent-flow report and the tests — from $300, invoiced only after delivery once you have looked it over. Or skip hosting and call our endpoints on the pay-per-call plan, with nothing upfront. Tell us the app and what you want from its data at /contact.html, and access, consent paperwork and the sandbox get arranged with you as the project runs.