Pulling accounts, cards and loans out of Banksalad

The MyData regime that carries this data

South Korea runs one of the more prescriptive open-finance schemes in the world, and Banksalad is a licensed participant in it. Financial MyData rests on the 2020 amendment to the Credit Information Use and Protection Act and is supervised by the Financial Services Commission; the Korea Times reported Rainist among the fintechs granted preliminary MyData approval ahead of launch. Since the January 2022 go-live, operators may no longer scrape other services' sites — customer data moves only through standardized APIs, intermediated by the Korea Financial Telecommunications and Clearings Institute (KFTC). Public figures put the scheme at dozens of providers and over a hundred million cumulative consents within its first two years.

For an integrator the practical upshot is short. The financial categories — deposit and cash accounts, cards, loans, insurance, investment — are reachable through a documented, versioned consent flow rather than guesswork. Consent is per-user, scoped, and revocable; the law, not a vendor's goodwill, keeps the door open. We arrange the participant onboarding or the consenting-account setup with you as part of the build, so this regime works for the project rather than sitting in front of it.

What sits inside a Banksalad account

The app names its own surfaces, and the table keeps those names. Granularity below reflects how the data presents to the user and how the MyData category endpoints expose it.

The genetic-test results that Teragen Health provides inside the app are a separate matter — special-category health data, on their own consent. They are not part of a financial sync and get the handling described further down.

Routes in, and the one we'd build on

1 — Consented MyData API

This is the front door for everything that maps to a standard category. The KFTC-intermediated APIs are REST, authenticated with an access token issued under OAuth 2.0 conventions plus a fintech user number, over mutual TLS. What's reachable: accounts, cards, loans, insurance and investment, per the consent scope the user grants. Effort is moderate and front-loaded into onboarding; durability is high, because the endpoints are versioned and mandated rather than discretionary. We set up the participant or consenting-account path, the consent UI, and token lifecycle with you.

2 — Authorized protocol analysis of the app's traffic

Some of what makes Banksalad useful is not a raw feed but a derivation: the ledger's auto-classification, the merge of wallet money into one timeline, the comparison engine's ranked outputs. Those don't live in the MyData standard. We reach them by analysing the app's own authorized traffic against a consenting account and modelling the request and response shapes. Effort is medium; durability depends on the app's release cadence, so this route carries a re-check step.

3 — User-consented export

Where a user can export or share their own records directly, that path is a low-friction supplement for one-off pulls and reconciliation. It is narrow but useful when a full API build is more than a project needs.

What we'd actually recommend for Banksalad: build the accounts, cards and loans on route 1, because a national scheme keeps it stable through every app redesign, and bring in route 2 only for the derived ledger and comparison surfaces that the standard doesn't define — re-validated whenever Rainist ships an update. That split keeps the bulk of the integration on the most durable footing while still covering the surfaces that make the app distinctive.

The handover

Each deliverable is tied to a real Banksalad surface, not a generic checklist:

• An OpenAPI / Swagger specification covering the account, card, loan and ledger reads, with the MyData consent and token endpoints modelled alongside.
• A protocol and auth-flow report: the OAuth 2.0 token issuance, the fintech-user-number binding, the mutual-TLS handshake against the KFTC relay, and the request signing for category calls.
• Runnable source in Python or Node.js for the key endpoints — account list, transaction inquiry with paging, loan and card reads, plus the normalized ledger merge.
• Automated tests against recorded fixtures, including the 25-rows-per-page transaction pager and consent-expiry handling.
• Interface documentation and compliance and retention guidance shaped to the Credit Information Act — consent records, logging, data minimization, and where the health track is fenced off.

A consented account pull, in code

Illustrative shapes, confirmed and finalized during the build against the consenting account. The path pattern follows the MyData standard's <base>/<version>/bank/<resource> structure documented at the Korean MyData developer portal; field names are settled once we replay live responses.

POST  /oauth/2.0/token          # access token, OAuth 2.0 conventions
  grant_type=authorization_code  scope=bank.list bank.transactions
  -> { access_token, token_type: "Bearer", expires_in, scope }

GET   /v1/bank/accounts          # accounts the user consented to share
  Authorization: Bearer {access_token}
  x-fsp-fintech-num: {fintech_user_number}    # binds token to the consent
  -> { account_list: [ { account_num, prod_name, balance_amt } ], rsp_code }

GET   /v1/bank/accounts/transactions
  ?from_date=20260101&to_date=20260131&limit=25      # max 25 rows / page
  -> { trans_list: [ { trans_dtime, trans_amt, balance_amt, memo } ],
       next_page: "..." }   # cursor; we page until exhausted

# transport: mutual TLS (1.3+); on rsp_code != 0000 we map the
# error, back off, and surface a typed exception rather than a raw body

The pager and the cursor logic matter more than they look: a month of an active account easily exceeds the per-page cap, so a faithful statement is reconstructed page by page, deduplicated on the transaction key.

What we plan for on this build

These are the things we account for so the integration behaves, written from our side of the table:

• The MyData transaction inquiry returns at most 25 items per page. We build the pager and an incremental-sync cursor so a full history reconstructs without gaps or duplicate rows when a sync resumes.
• MyData consent is scoped and time-bound. We design the sync around the consent-refresh window so it never silently lapses mid-period, and we persist consent and access logs to match the Credit Information Act's record-keeping.
• The 가계부 ledger blends bank and card rows with Kakao Pay and Toss Pay Money. We normalize those wallet entries into the same transaction schema, so downstream code reads one ledger rather than three source formats.
• Genetic results from Teragen are special-category data. We keep them on a separate consent track, apply data minimization, and exclude them from any financial sync unless a client explicitly scopes them in. Access and sandbox setup is arranged with you during onboarding; the build runs against a consenting account or a participant test environment.

Where teams point an integration like this

• A wealth or robo-advisory product that wants a Korean user's whole asset picture — banks, cards, loans, net worth — without writing two hundred institution connectors itself.
• A lender running affordability and refinancing checks, pulling consented loan balances and rates alongside income signals derived from the ledger.
• An accounting or expense tool ingesting the auto-classified ledger, wallet money included, as a clean categorized transaction stream.

Pricing and how a build runs

Most Banksalad integrations ship inside one to two weeks of focused work. Source-code delivery starts at $300: you receive the runnable API source and its documentation, and you pay only after delivery, once the integration does what you asked of it. The other model is our hosted API — you call our endpoints and pay per call, with nothing upfront and no maintenance on your side. Tell us the app and what you need from its data, and the access, consent and compliance arrangements are handled with you rather than left as homework. Start a Banksalad integration here.

How this brief was put together

Checked in June 2026 against the app's own description and the primary sources on Korea's MyData scheme: the regulator and the law, the KFTC relay's role, and the standard API's transport and paging rules. Citations open in a new tab.

• The Korea Times — Banksalad and the MyData licence
• MyData standard API base specification (Korean MyData developer portal)
• Global Government Fintech — Korea's MyData launch
• 뱅크샐러드 on Google Play

Mapped by the OpenBanking Studio integration desk · June 2026.

Screens we worked from

Other apps in the same data space

Banksalad shares the Korean MyData ecosystem with these. Several are themselves licensed MyData participants, which is exactly why a unified, consent-based integration generalizes across them.

• Toss (Viva Republica) — payments and transfers with full MyData aggregation across banks and cards.
• Kakao Pay — wallet, insurance and asset management inside the Kakao ecosystem.
• Naver Pay (Naver Financial) — payments plus loans, insurance and investment products.
• KakaoBank — internet-only bank holding deposit accounts, loans and transfers.
• Toss Bank — Toss's internet-only banking arm with accounts and personal loans.
• Finda — loan comparison and management built directly on MyData feeds.
• CashNote (Korea Credit Data) — card-sales and credit data aimed at small businesses.
• NICE Information Service — a credit bureau and MyData information provider.

Questions integrators ask about Banksalad

Does the consented MyData route cover the auto-classified 가계부, or only the bank and card feeds?

Raw accounts, cards, loans and insurance come through standard MyData category endpoints. The 가계부 ledger is different: its income, expenditure and transfer rows are Banksalad's own classification of those feeds, and it also folds in Kakao Pay and Toss Pay Money. We reach that derived ledger by analysing the app's authorized traffic and normalize it into the same transaction schema as the MyData rows.

Which regulator and law govern pulling Banksalad's financial data?

South Korea's Financial Services Commission oversees financial MyData under the Credit Information Use and Protection Act, amended in 2020. Since the January 2022 mandate, providers must transfer data through APIs rather than scraping, intermediated by the Korea Financial Telecommunications and Clearings Institute. The dependable basis for any pull is the account holder's own MyData consent.

Can the Teragen genetic and health results be part of an integration?

Those sit outside the financial MyData scope and are a special category under Korean privacy law, provided through Teragen Health. We keep them on a separate consent track, apply data minimization, and leave them out of any financial sync unless a client explicitly scopes them in with the matching consent.

If Banksalad redesigns its app, does the integration break?

The standard MyData category endpoints are versioned and survive front-end redesigns, so the accounts, cards and loans feed keeps working. The derived surfaces we reach through traffic analysis, like the ledger classification, get re-checked each time the client app ships an update; those fixes turn around inside the same one to two week cycle.