💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

Introduction — How Account Data Crosses the Bank Wall

Checking balances across multiple banks in a single fintech app and sending money to any bank account has become an everyday experience. Behind that everyday experience, however, stands a massive infrastructure: standard APIs, intermediary institutions, authentication schemes, consent management, and inter-institution settlement.

This article examines the technical structure underpinning financial data openness, centered on Korea's open banking shared network and the MyData regime (the personal credit information management business). We cover implementation perspectives on both sides — financial institutions that provide data and fintech companies that consume it — and add comparisons with global standards such as UK Open Banking, PSD2, and FAPI.

This article organizes publicly known institutional and standards structures from a technical perspective; it is not advice on any institution's internal specifications or legal interpretation. For actual projects, always check the latest regulations and official guidelines.

Korean Open Banking — The Shared Network and the Intermediary

The biggest characteristic of Korean open banking is the **central intermediary model** (operated by the Korea Financial Telecommunications and Clearings Institute, KFTC). Instead of signing individual contracts and building individual integrations with each bank, a fintech company connects once to the KFTC open banking shared system and can communicate with all participating institutions.

[Korean open banking shared network]

Fintech app / consumer KFTC Participating banks

┌──────────────┐ standard API ┌──────────────┐ external ┌──────────┐

│ Service │ ────────────▶ │ Open banking │ ─────────▶ │ Bank A │

│ servers │ ◀──────────── │ relay system │ ◀───────── │ Bank B │

└──────────────┘ resp/callback └──────────────┘ │ Savings C│

│ └──────────┘

├─ Auth (token issuance/validation)

├─ Transaction relay, message mapping

├─ Consumer onboarding and billing

└─ Inter-institution settlement

Open banking APIs fall broadly into inquiry and transfer.

| API class | Representative APIs | Characteristics |

| --- | --- | --- |

| Inquiry | Balance, transaction history, account holder verification | Read-only, relatively simple |

| Transfer | Credit transfer (deposit), debit transfer (withdrawal) | Money movement; idempotency and reconciliation mandatory |

| Management | Account registration/deregistration, token management | Consent and registration lifecycle |

The trickiest of these is the **debit transfer**. Money leaves a customer account at the request of a consumer institution, so you need prior debit consent registration, transaction limits, and unknown-outcome handling on response timeouts (the UNKNOWN state plus reconciliation covered in the earlier ledger article).

MyData Architecture — Implementing the Right to Data Portability

MyData (the personal credit information management business) is the technical realization of the **individual right to demand transmission of personal credit information** — "send my data from here to there." Where open banking centers on account inquiry and transfers, MyData is a regime for collecting information from a wide range of sectors — banking, cards, insurance, securities, telecom — through standard APIs.

[MyData information flow]

Customer ──(transmission demand + integrated auth)──▶ MyData provider app

│

│ standard APIs (REST, JSON)

▼

┌──────────────┬────────────────┬──────────────┐

│ Banks (data │ Card cos (data │ Brokers (data │

│ providers) │ providers) │ providers) │

└──────────────┴────────────────┴──────────────┘

│

Support: central portal (support center), auth relay,

standard spec governance

The core components are:

- **Integrated authentication**: Instead of logging in to each institution, the customer completes transmission demands toward multiple data providers at once through unified, certificate-based identity verification.

- **Data provision APIs**: REST APIs defined by sector-specific standard specs (account lists, transactions, card billing, insurance contracts, and so on).

- **Transmission demand management**: The lifecycle that manages the customer's transmission demands (target institutions, data scope, retention period) and stops collection upon revocation.

- **Periodic transmission**: The scheduling regime in which the provider regularly (for example daily) refreshes data within the scope the customer consented to.

The Shape of Standard API Specs — Requests and Responses

Standard APIs in the MyData and open banking families share a common shape. Field names in the real specs vary by version, so treat the following as simplified examples for understanding the structure.

Token issuance (based on the OAuth 2.0 authorization code grant) flows roughly like this.

POST /oauth/2.0/token HTTP/1.1

Host: api.provider.example

Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code

&code=AUTH_CODE_FROM_CONSENT_FLOW

&client_id=CLIENT_ID

&client_secret=CLIENT_SECRET

&redirect_uri=https://app.example/callback

{

"token_type": "Bearer",

"access_token": "eyJhbGciOiJSUzI1NiIs...",

"expires_in": 3600,

"refresh_token": "rt_8f14e45fceea167a...",

"scope": "bank.read card.read"

}

A simplified account transaction inquiry request and response:

GET /v1/accounts/transactions?account_num=110-123-456789&from_date=20260601&to_date=20260613&limit=100 HTTP/1.1

Host: api.provider.example

Authorization: Bearer eyJhbGciOiJSUzI1NiIs...

x-api-tran-id: M2026061300001234567890

{

"rsp_code": "00000",

"rsp_msg": "success",

"search_timestamp": "20260613091500",

"next_page": "",

"trans_list": [

{

"trans_dtime": "20260612143015",

"trans_type": "03",

"trans_class": "withdrawal",

"trans_amt": "50000",

"balance_amt": "1250000",

"trans_memo": "coffee shop payment"

{

"trans_dtime": "20260611090000",

"trans_type": "02",

"trans_class": "deposit",

"trans_amt": "3000000",

"balance_amt": "1300000",

"trans_memo": "salary"

}

]

}

Practical points when reading these specs:

- **Transaction trace ID header**: Every request carries a trace ID generated by the consumer institution. It is the anchor for incident tracing and inter-institution reconciliation, so the generation rule (institution code plus date plus sequence) must be followed exactly.

- **Amounts are strings**: Many standard messages carry amounts as strings. Parse them into decimal-precision types and never route them through floating point.

- **Paging conventions**: Both next-page tokens and timestamp-based paging exist. Getting "last page detection" wrong silently loses transactions.

- **Dual response codes**: HTTP status and the in-body rsp_code are separate. You must handle business error codes arriving inside an HTTP 200.

Global Comparison — UK Open Banking, PSD2, FAPI

Comparing with global standards puts the Korean model in sharper relief.

| --- | --- | --- | --- |

| Approach | Intermediary-centered shared network plus statutory portability right | Regulator-driven, standards body (OBIE) established | Directive-based, implemented per member state |

The most technically useful reference is the **FAPI (Financial-grade API) security profile**. Defined by the OpenID Foundation as a financial-grade API security standard, it demands the following beyond plain OAuth 2.0.

- **Sender-constrained tokens via mutual TLS (mTLS) or DPoP**: A stolen token is useless without the client certificate.

- **PAR (Pushed Authorization Requests)**: Authorization request parameters travel over the back channel rather than front-channel URLs, preventing tampering.

- **Signed requests and responses (JAR, JARM)**: The authorization request and response themselves are signed as JWTs.

- **PKCE made mandatory, weak flows banned**: Vulnerable patterns like the implicit flow are prohibited.

Korean standards point the same direction with certificate-based mutual authentication and message signing. If you are designing a new system, taking the FAPI 2.0 Security Profile as your baseline is the safe choice.

Provider-Side Implementation — API Gateway, Rate Control, Billing

From the perspective of a data provider such as a bank, open banking and MyData mean "large volumes of inquiry traffic arriving from outside." Its characteristics differ from internal channels.

[Provider-side reference architecture]

Intermediary / consumer institutions

│

▼

┌────────────────────────────────────────────┐

│ API gateway │

│ - client authentication (mTLS, cert check) │

│ - token validation, scope check │

│ - rate control (per institution / per API) │

│ - trace ID validation and logging │

└────────────────────────────────────────────┘

│

▼

┌────────────────┐ ┌────────────────────┐

│ Open API service │ ──▶ │ Read-only data layer │ ◀─ CDC/batch replication

│ layer (mapping) │ │ (read replica/cache) │ from core banking

└────────────────┘ └────────────────────┘

│ transfer APIs only

▼

Core banking (ledger)

Key design points:

1. **Separate inquiries from the ledger**: MyData periodic transmission concentrates traffic in the early morning hours. Absorb this read load with read replicas or cache layers so it never hits the core ledger database directly. Only transfer-type APIs ride the core banking path.

2. **Rate control**: Enforce per-consumer, per-API call quotas at the gateway. It is the first line of defense keeping one runaway consumer from spreading into a full-service incident.

3. **Billing and statistics**: Open banking APIs carry per-call fee schedules, so call records that drive billing must be persisted without loss. Billing data and operational logs serve different purposes — design them separately.

4. **Schema version management**: Standard spec revisions come with dual-version transition periods. You need URL versioning and parsers tolerant of added fields.

Consumer-Side Implementation — Token Management and Periodic Transmission

The hard problem for fintech and MyData operators is managing tokens and collection schedules at the scale of millions of users times dozens of institutions.

Start with **token management**.

- An access token and refresh token exist per user-institution pair. Encrypted storage (encryption at rest plus key management) is table stakes.

- Access token expiry is the normal path; standardize the pattern of refreshing on 401 and retrying once.

- When the refresh token itself is expired or revoked, automatic recovery is impossible. Transition the pair into a state requiring user re-consent, and surface that state clearly in the UX.

**Periodic transmission scheduling** is essentially a distributed crawling design.

Skeleton of a periodic collection scheduler (conceptual example)

def schedule_daily_collection(users, providers, window_start, window_end):

"""Distribute collection tasks within institution rate limits and time windows."""

tasks = []

for user in users:

for p in user.consented_providers:

tasks.append(CollectTask(user_id=user.id, provider=p))

1) Group by institution → apply per-institution concurrency caps

2) Spread evenly inside the window (add jitter to avoid spikes)

3) Retry failures with exponential backoff; roll over past the cap

for provider, group in group_by_provider(tasks):

limit = provider.rate_limit # e.g. 50 calls per second

for i, task in enumerate(group):

task.scheduled_at = spread_with_jitter(

window_start, window_end, i, len(group))

task.max_retries = 3

enqueue(task, concurrency_key=provider.code, limit=limit)

Lessons operations will teach you:

- **A social contract on collection windows**: If everyone collects right after midnight, provider systems get hammered simultaneously. Respect the periodic transmission windows defined by the standard, and jitter within them.

- **Incremental collection**: Request only data since the last collection instead of re-pulling full ranges. But account for late-arriving postings on the provider side (yesterday's transaction appearing today) by overlapping windows and de-duplicating.

- **Partial failure is the normal state**: Out of 20 institutions, one is always in maintenance or slow. A UX that shows per-institution refresh timestamps is more realistic than one that presumes all institutions are collected.

Security Requirements — Transport, Certificates, Client Authentication

Security in a financial data openness regime is layered.

| Layer | Requirement | Implementation |

| --- | --- | --- |

| Transport | Encrypted links, strong TLS configuration | TLS 1.2 or higher, modern cipher suites |

| Client authentication | Cryptographic proof of institutional identity | mTLS client certificates, plus leased lines/VPN |

| Message | Tamper-proofing of messages | Digital signatures, trace ID and timestamp validation |

| Token | Preventing reuse of stolen tokens | Sender constraining (mTLS binding), short expiry |

| Storage | Protecting collected data and tokens | Encryption at rest, separated key custody, access control |

| Operations | Anomaly detection | Call pattern anomaly detection, certificate expiry monitoring |

The incident that strikes surprisingly often in practice is not a flashy hack but **certificate expiry**. Manage the expiry dates of inter-institution mTLS certificates, signing certificates, and TLS server certificates as an asset inventory, with alerts 30 days ahead and rotation rehearsals built into the operational routine.

Designing the Consent Management System — Consent Is Data

The legal foundation of MyData is customer consent, so consent itself must be a first-class data model.

-- Consent (transmission demand) model example

CREATE TABLE consents (

consent_id UUID PRIMARY KEY,

user_id BIGINT NOT NULL,

provider_code VARCHAR(10) NOT NULL, -- data provider

scope_codes TEXT[] NOT NULL, -- consented data scopes

purpose_code VARCHAR(10) NOT NULL, -- purpose of collection/use

granted_at TIMESTAMPTZ NOT NULL,

expires_at TIMESTAMPTZ NOT NULL, -- consent validity period

revoked_at TIMESTAMPTZ, -- revocation time

status VARCHAR(10) NOT NULL -- ACTIVE, EXPIRED, REVOKED

);

-- Consent history: record every state change append-only

CREATE TABLE consent_events (

event_id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,

consent_id UUID NOT NULL REFERENCES consents(consent_id),

event_type VARCHAR(20) NOT NULL, -- GRANTED, RENEWED, REVOKED ...

event_at TIMESTAMPTZ NOT NULL DEFAULT now(),

channel VARCHAR(20) NOT NULL,

evidence_ref TEXT -- reference to auth evidence etc.

);

Design principles:

- **Propagation of revocation**: When a customer revokes consent, a chain must fire: (1) stop collection schedules, (2) request token revocation, (3) delete or segregate data per retention policy. Event-driven propagation — publish a revocation event that downstream systems subscribe to — is robust against omissions.

- **Evidence retention**: You must be able to reconstruct what the customer consented to, when, and on which screen. Store the terms version at consent time and a reference to the authentication record.

- **Proactive expiry handling**: As consent expiry approaches, prompt the user to renew, and enforce consent state in front of the collector so that not a single call goes out under an expired consent.

The Data Standardization Problem — Variance and the Normalization Layer

A standard API does not mean homogeneous data. Even under the same spec, institutions vary in interpretation and data quality.

- The granularity of transaction type codes differs per institution.

- Memo field formats vary, so merchant name extraction quality varies.

- The as-of semantics of balances and amounts may differ (real-time versus previous-day close).

- The same purchase may appear as one record at institution A and as two records (authorization plus capture) at institution B.

A consumer-side architecture therefore needs a two-layer structure: **raw preservation plus a normalization layer**.

[Collected data normalization pipeline]

Standard API responses (per-institution raw)

│ store as-is (immutable raw preservation — enables reprocessing)

▼

raw_records (institution schemas as received)

│ normalization: code mapping, amount precision unification,

│ time zone unification, de-duplication (overlap windows),

│ merchant name cleansing

▼

canonical_transactions (common service model)

│

▼

Service features (asset view, spending analysis, credit management ...)

The reason for preserving raw data is that normalization logic keeps evolving. When you improve merchant name cleansing rules, the raw data makes full reprocessing possible; if only normalized output remains, there is no way back.

Failure and Quality Management — Per-Institution SLAs and Circuit Breakers

In a system integrated with dozens of institutions, the common event is not a total outage but a partial failure at one institution.

- **Per-institution health management**: Aggregate success rates and latency per institution over sliding windows, and when thresholds are crossed, block calls to that institution only (open the circuit).

- **Half-open probing**: After a cooldown, send a small number of probe calls to check recovery and restore gradually.

- **Timeout budgets**: When a user request fans out to several institutions, set short per-institution timeouts within the total response budget (say 3 seconds); show slow institutions as "refreshing" and retry in the background.

- **Maintenance calendars**: Financial institutions announce regular maintenance windows. Feeding the maintenance timetable into the collector removes unnecessary failures and alerts.

[Per-institution circuit breaker state machine]

CLOSED (healthy)

│ failure rate > 50% (last 100 calls) or N consecutive timeouts

▼

OPEN (blocked: fail fast, queued work rolls over)

│ cooldown elapsed (e.g. 60s)

▼

HALF-OPEN (small number of probe calls allowed)

├─ sustained success ──▶ back to CLOSED

└─ failure ──▶ re-enter OPEN (cooldown grows)

Business Use and Limits

Finally, what this infrastructure makes possible and what remains hard.

What became possible:

- Consolidated views of assets scattered across institutions and rebalancing suggestions

- Transaction-based spending analysis, subscription management, cash flow forecasting

- Better credit assessment for thin filers by combining non-financial credit information

- Account-based easy remittance and collection (open banking transfer APIs)

What remains hard:

- **Limits of real-time**: Periodic transmission cycles and provider-side lag mean a complete "right now" snapshot is not guaranteed.

- **The floor on data quality**: However good your normalization layer, it cannot exceed the quality of the source data.

- **Revenue models**: Inquiry API calls cost money, and data itself stopped being a differentiator. Differentiation comes from analysis and experience built on top of the data.

- **Keeping up with regulatory change**: Spec revisions, authentication policy changes, and fee schedule changes arrive periodically; organizational ability to track standards quickly is itself a competitive advantage.

Testing Strategy — Testbeds and Institution Simulators

Integration testing needs a strategy of its own.

- **Use official testbeds**: Verify authentication and message conformance first in the test environments offered by the intermediary and standards operators. Keep production and test certificates strictly separated.

- **In-house institution simulators**: If every integration test depends on external testbeds, CI becomes slow and flaky. Build mock servers that respond per the standard spec, with injectable scenarios for latency, timeouts, business error codes, and malformed responses (empty arrays, missing fields).

- **Contract tests**: Catch response schema drift with contract tests so spec revisions do not silently break parsers. The principle: tolerant of added fields, sensitive to changed field semantics.

- **Chaos scenarios**: Periodically verify that circuit breakers and queue rollover behave as designed under scenarios like one institution fully down, all institutions twice as slow, or mass token expiry.

Design Checklist

- [ ] Do trace ID generation rules follow the standard exactly, logged end to end?

- [ ] Does amount parsing avoid floating point entirely?

- [ ] Is dual handling of HTTP status plus business response codes (200 with error code) implemented?

- [ ] Are paging termination and overlap-window de-duplication verified?

- [ ] Are tokens encrypted at rest, with the 401-refresh-retry pattern standardized?

- [ ] Does an unrecoverable refresh state lead to a re-consent UX?

- [ ] Does the consent model treat history, evidence, expiry, and revocation as first class?

- [ ] Do collection stop, token revocation, and data handling (deletion/segregation) propagate on revocation?

- [ ] Is the architecture two-layered: raw preservation plus normalization?

- [ ] Are per-institution rate limits, circuit breakers, and maintenance calendars wired into the collector?

- [ ] Is periodic transmission spread with jitter inside the allowed window?

- [ ] Are mTLS, signing, and TLS certificate expiries managed as assets with alerts?

- [ ] If you are a provider: is inquiry load isolated from the ledger database?

- [ ] If you are a provider: are billing-grade call records persisted without loss?

Closing Thoughts

Open banking and MyData look like "integrating a few APIs," but in reality they are a distributed systems design problem where authentication, consent, standardization, failure management, and settlement interlock. Consent management and per-institution quality variance in particular are underestimated before launch and consume the most time after. Take this article's structure as a starting point — understand the intermediary model, set a FAPI-level security baseline, separate raw preservation from normalization, and isolate failures per institution — and you will design considerably more robust systems for the era of financial data openness.

References

- Korea Financial Telecommunications and Clearings Institute: https://www.kftc.or.kr/

- Open Banking Korea (operated by KFTC): https://www.openbanking.or.kr/

- MyData support portal (Korea): https://www.mydatacenter.or.kr/

- Financial Services Commission (Korea): https://www.fsc.go.kr/

- Financial Supervisory Service (Korea): https://www.fss.or.kr/

- Financial Security Institute (Korea): https://www.fsec.or.kr/

- UK Open Banking: https://www.openbanking.org.uk/

- OpenID Foundation — FAPI Working Group: https://openid.net/wg/fapi/

- FAPI 2.0 Security Profile: https://openid.net/specs/fapi-security-profile-2_0.html

- OAuth 2.0 (RFC 6749): https://datatracker.ietf.org/doc/html/rfc6749

- OAuth 2.0 mTLS (RFC 8705): https://datatracker.ietf.org/doc/html/rfc8705

- EU PSD2 (Directive 2015/2366): https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32015L2366