LabHub

Blog

Open Banking and MyData API Architecture — The Technology of Financial Data Openness

2026-06-13 · 16 min read · #finance#open-banking#mydata#api#oauth2#fapi#architecture

한국어English日本語

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 classRepresentative APIsCharacteristics
InquiryBalance, transaction history, account holder verificationRead-only, relatively simple
TransferCredit transfer (deposit), debit transfer (withdrawal)Money movement; idempotency and reconciliation mandatory
ManagementAccount registration/deregistration, token managementConsent 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:

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:

Global Comparison — UK Open Banking, PSD2, FAPI

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

PerspectiveKorea (open banking/MyData)UK (Open Banking)EU (PSD2)
ApproachIntermediary-centered shared network plus statutory portability rightRegulator-driven, standards body (OBIE) establishedDirective-based, implemented per member state
ConnectivityThrough a central relay hubDirect per-institution APIs plus a directoryPer-institution APIs, market-driven standards (Berlin Group etc.)
Auth standardsIntegrated auth plus per-institution tokensOAuth 2.0 plus FAPI profileStrong Customer Authentication (SCA) required
ScopeFrom accounts/payments to credit data across sectorsPayment accounts centeredPayment accounts and payment services centered

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.

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.

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:

Security Requirements — Transport, Certificates, Client Authentication

Security in a financial data openness regime is layered.

LayerRequirementImplementation
TransportEncrypted links, strong TLS configurationTLS 1.2 or higher, modern cipher suites
Client authenticationCryptographic proof of institutional identitymTLS client certificates, plus leased lines/VPN
MessageTamper-proofing of messagesDigital signatures, trace ID and timestamp validation
TokenPreventing reuse of stolen tokensSender constraining (mTLS binding), short expiry
StorageProtecting collected data and tokensEncryption at rest, separated key custody, access control
OperationsAnomaly detectionCall 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:

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.

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 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:

What remains hard:

Testing Strategy — Testbeds and Institution Simulators

Integration testing needs a strategy of its own.

Design Checklist

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

Read the original: https://www.youngju.dev/blog/finance/2026-06-13-open-banking-mydata-api-architecture.en

Comments

No comments yet.

Sign in to leave a comment