오픈뱅킹과 마이데이터 API 아키텍처 — 금융 데이터 개방의 기술

들어가며 — 계좌 정보가 은행 담장을 넘기까지
한국 오픈뱅킹 구조 — 공동망과 중계기관
마이데이터 아키텍처 — 전송요구권의 기술적 구현
표준 API 스펙의 형태 — 요청과 응답
글로벌 비교 — 영국 오픈뱅킹, PSD2, FAPI
제공자 측 구현 — API 게이트웨이, 유량 제어, 과금
이용기관 측 구현 — 토큰 관리와 정기적 전송
보안 요구 — 전송구간, 인증서, 클라이언트 인증
동의 관리 시스템 설계 — 동의는 데이터다
데이터 표준화 문제 — 기관별 편차와 정규화 레이어
장애와 품질 관리 — 기관별 SLA와 서킷브레이커
비즈니스 활용과 한계
테스트 전략 — 테스트베드와 기관 시뮬레이터
설계 체크리스트
마치며
참고 자료

들어가며 — 계좌 정보가 은행 담장을 넘기까지

하나의 핀테크 앱에서 여러 은행의 잔액을 한 번에 조회하고, 어느 은행 계좌로든 송금을 보내는 경험은 이제 당연해졌습니다. 그러나 이 당연함의 뒤에는 표준 API, 중계기관, 인증 체계, 동의 관리, 기관 간 정산이라는 거대한 인프라가 있습니다.

이 글에서는 한국의 오픈뱅킹 공동망과 마이데이터(본인신용정보관리업) 아키텍처를 중심으로, 금융 데이터 개방을 떠받치는 기술 구조를 살펴봅니다. 데이터를 제공하는 금융회사 측과 데이터를 이용하는 핀테크 측 양쪽의 구현 관점을 모두 다루고, 영국 오픈뱅킹·PSD2·FAPI 같은 글로벌 표준과의 비교도 곁들입니다.

이 글은 공개된 제도·표준의 구조를 기술 관점에서 정리한 자료이며, 특정 기관의 내부 사양이나 법률 해석에 대한 자문이 아닙니다. 실제 사업 추진 시에는 최신 규정과 공식 가이드라인을 반드시 확인하시기 바랍니다.

한국 오픈뱅킹 구조 — 공동망과 중계기관

한국 오픈뱅킹의 가장 큰 특징은 중앙 중계기관(금융결제원) 모델입니다. 핀테크 기업이 은행마다 개별 계약과 개별 연동을 하는 대신, 금융결제원의 오픈뱅킹 공동업무 시스템에 한 번 연결하면 참가 기관 전체와 통신할 수 있습니다.

[한국 오픈뱅킹 공동망 구조]

  핀테크 앱/이용기관                금융결제원                참가 금융회사
  ┌──────────────┐    표준 API   ┌──────────────┐   대외계   ┌──────────┐
  │  서비스 서버  │ ───────────▶ │  오픈뱅킹     │ ────────▶ │  A 은행   │
  │  (이용기관)   │ ◀─────────── │  중계 시스템  │ ◀──────── │  B 은행   │
  └──────────────┘    응답/콜백  └──────────────┘            │  C 저축은행│
                                      │                      └──────────┘
                                      ├─ 인증(토큰 발급/검증)
                                      ├─ 거래 중계·전문 변환
                                      ├─ 이용기관 관리·과금
                                      └─ 기관 간 정산

오픈뱅킹 API는 크게 조회와 이체 두 축으로 나뉩니다.

API 분류	대표 API	특징
조회	잔액조회, 거래내역조회, 계좌실명조회	읽기 전용, 상대적으로 단순
이체	입금이체, 출금이체	자금 이동, 멱등성·대사 필수
관리	계좌등록·해지, 토큰 관리	동의·등록 라이프사이클

이 중 가장 까다로운 것이 출금이체입니다. 이용기관의 요청으로 고객 계좌에서 돈이 빠져나가는 구조이므로, 사전 출금 동의 등록, 거래 한도, 그리고 응답 타임아웃 시의 미확인 거래 처리(앞선 원장 글에서 다룬 UNKNOWN 상태와 대사)가 모두 필요합니다.

마이데이터 아키텍처 — 전송요구권의 기술적 구현

마이데이터(본인신용정보관리업)는 개인이 자신의 신용정보를 "여기에서 저기로 보내라"고 요구할 수 있는 개인신용정보 전송요구권을 기술적으로 구현한 제도입니다. 오픈뱅킹이 계좌 중심의 조회·이체라면, 마이데이터는 은행·카드·보험·증권·통신 등 광범위한 업권의 정보를 표준 API로 수집하는 체계입니다.

[마이데이터 정보 흐름]

   고객 ──(전송요구+통합인증)──▶ 마이데이터 사업자 앱
                                      │
                                      │ 표준 API (REST, JSON)
                                      ▼
            ┌─────────────┬───────────────┬─────────────┐
            │  은행(정보제공자) │  카드사(정보제공자) │  증권사(정보제공자) │
            └─────────────┴───────────────┴─────────────┘
                                      │
            지원: 종합포털(지원센터), 인증중계, 표준 스펙 관리

핵심 구성요소는 다음과 같습니다.

통합인증: 고객이 기관마다 로그인하지 않고, 통합된 본인확인(인증서 기반)으로 여러 정보제공자에 대한 전송요구를 한 번에 처리합니다.
정보제공 API: 업권별 표준 스펙(계좌 목록, 거래내역, 카드 청구, 보험 계약 등)으로 정의된 REST API입니다.
전송요구 관리: 고객의 전송요구 내역(대상 기관, 정보 범위, 보유 기간)을 관리하고, 철회 시 수집을 중단하는 라이프사이클입니다.
정기적 전송: 고객이 동의한 범위에서 사업자가 주기적으로(예: 일 단위) 정보를 갱신 수집하는 스케줄링 체계입니다.

표준 API 스펙의 형태 — 요청과 응답

마이데이터·오픈뱅킹 계열의 표준 API는 공통적으로 다음 형태를 가집니다. 실제 스펙의 필드명은 버전에 따라 다르므로, 구조 이해를 위한 단순화 예제로 봐주시기 바랍니다.

토큰 발급(OAuth 2.0 권한부여코드 방식 기반)은 대략 이런 흐름입니다.

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"
}

계좌 거래내역 조회 요청·응답의 단순화 예제입니다.

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": "출금",
      "trans_amt": "50000",
      "balance_amt": "1250000",
      "trans_memo": "커피숍 결제"
    },
    {
      "trans_dtime": "20260611090000",
      "trans_type": "02",
      "trans_class": "입금",
      "trans_amt": "3000000",
      "balance_amt": "1300000",
      "trans_memo": "급여"
    }
  ]
}

스펙 읽을 때 주의할 실무 포인트입니다.

거래 고유번호 헤더: 모든 요청에 이용기관이 생성하는 거래 추적 ID가 들어갑니다. 장애 추적과 기관 간 대사의 기준점이므로 생성 규칙(기관코드+일자+일련번호)을 정확히 지켜야 합니다.
금액이 문자열: 표준 전문 다수가 금액을 문자열로 다룹니다. 파싱 시 십진 정밀 타입으로 변환하고, 절대 부동소수점을 경유하지 않습니다.
페이징 규약: next_page 토큰 방식과 기준일시 방식이 혼재합니다. "마지막 페이지 판단"을 잘못 구현하면 거래내역 누락이 생깁니다.
응답 코드 이원화: HTTP 상태 코드와 본문 rsp_code가 별도입니다. HTTP 200에 업무 오류 코드가 실려 오는 경우를 반드시 처리해야 합니다.

글로벌 비교 — 영국 오픈뱅킹, PSD2, FAPI

한국 모델을 더 잘 이해하려면 글로벌 표준과 비교하는 것이 좋습니다.

관점	한국 (오픈뱅킹/마이데이터)	영국 (Open Banking)	EU (PSD2)
추진 방식	중계기관 중심 공동망 + 법정 전송요구권	규제 당국 주도, 표준화 기구(OBIE) 설립	지침(Directive) 기반, 회원국별 이행
연결 구조	중앙 중계 허브 경유	기관별 API 직접 연결 + 디렉터리	기관별 API, 표준은 시장 주도(Berlin Group 등)
인증 표준	통합인증 + 기관별 토큰	OAuth 2.0 + FAPI 프로파일	강력한 고객 인증(SCA) 요구
대상 범위	계좌·결제에서 전 업권 신용정보로 확장	결제계좌 중심	결제계좌·결제 서비스 중심

기술적으로 가장 참고할 만한 것은 FAPI(Financial-grade API) 보안 프로파일입니다. OpenID Foundation이 정의한 금융 수준 API 보안 표준으로, 일반 OAuth 2.0 대비 다음을 요구합니다.

상호 TLS(mTLS) 또는 DPoP 기반 송신자 구속 토큰: 토큰을 탈취해도 클라이언트 인증서 없이는 사용할 수 없습니다.
PAR(Pushed Authorization Requests): 인가 요청 파라미터를 프런트 채널 URL이 아니라 백 채널로 전달해 변조를 막습니다.
서명된 요청·응답(JAR, JARM): 인가 요청과 응답 자체를 JWT로 서명합니다.
PKCE 필수화, 약한 플로우 금지: 임플리시트 플로우 같은 취약 패턴을 금지합니다.

한국 표준도 인증서 기반 상호 인증과 전문 서명을 요구한다는 점에서 지향점이 같습니다. 새로 시스템을 설계한다면 FAPI 2.0 Security Profile을 기준선으로 잡는 것이 안전합니다.

제공자 측 구현 — API 게이트웨이, 유량 제어, 과금

은행 같은 정보제공자 관점에서 오픈뱅킹·마이데이터는 "외부에서 들어오는 대량의 조회 트래픽"입니다. 내부 채널과 다른 특성을 이해해야 합니다.

[제공자 측 참조 아키텍처]

  중계기관/이용기관
        │
        ▼
  ┌────────────────────────────────────────────┐
  │ API 게이트웨이                              │
  │  - 클라이언트 인증(mTLS, 인증서 검증)        │
  │  - 토큰 검증, 스코프 확인                    │
  │  - 유량 제어(기관별/API별 rate limit)        │
  │  - 거래 ID 검증·로깅                        │
  └────────────────────────────────────────────┘
        │
        ▼
  ┌────────────────┐      ┌──────────────────┐
  │ 오픈API 서비스층 │ ───▶ │ 조회 전용 데이터층 │ ◀─ 계정계로부터 CDC/배치 복제
  │ (변환·조립)     │      │ (read replica/캐시)│
  └────────────────┘      └──────────────────┘
        │ 이체성 거래만
        ▼
  계정계 (원장)

핵심 설계 포인트입니다.

조회와 원장의 분리: 마이데이터 정기 전송은 새벽 시간대에 트래픽이 집중되는 특성이 있습니다. 이 조회 부하가 계정계 원장 DB를 직접 때리지 않도록, 조회 전용 복제본이나 캐시 계층으로 흡수합니다. 이체성 API만 계정계 경로를 탑니다.
유량 제어: 이용기관별·API별 호출 한도를 게이트웨이에서 강제합니다. 특정 사업자의 폭주가 전체 서비스에 번지지 않게 하는 1차 방어선입니다.
과금·통계: 오픈뱅킹 API는 건별 수수료 체계가 있으므로, 과금 기준이 되는 호출 기록을 유실 없이 적재해야 합니다. 과금 데이터와 운영 로그는 목적이 다르므로 분리 설계합니다.
스키마 버전 관리: 표준 스펙 개정 시 신구 버전 병행 기간이 있습니다. URL 버저닝과 필드 추가에 관대한(직렬화에 엄격하지 않은) 파서 정책이 필요합니다.

이용기관 측 구현 — 토큰 관리와 정기적 전송

핀테크·마이데이터 사업자 관점의 난제는 "수백만 사용자 x 수십 기관"의 토큰과 수집 스케줄을 관리하는 일입니다.

토큰 관리부터 보겠습니다.

사용자·기관 쌍마다 액세스 토큰과 리프레시 토큰이 존재합니다. 토큰은 암호화 저장(저장 시 암호화 + 키 관리)이 기본입니다.
액세스 토큰 만료는 정상 흐름이므로 401 응답 시 리프레시 후 1회 재시도 패턴을 표준화합니다.
리프레시 토큰까지 만료·철회된 경우는 자동 복구가 불가능합니다. 사용자에게 재동의를 요청하는 상태로 전이시키고, 그 상태를 UX에 명확히 노출해야 합니다.

정기적 전송 스케줄링은 일종의 분산 크롤링 설계입니다.

# 정기 전송 수집 스케줄러의 골격 (개념 예제)
def schedule_daily_collection(users, providers, window_start, window_end):
    """기관별 호출 한도와 시간 창을 지키며 수집 작업을 분산한다."""
    tasks = []
    for user in users:
        for p in user.consented_providers:
            tasks.append(CollectTask(user_id=user.id, provider=p))

    # 1) 기관별로 그룹화 → 기관별 동시성 상한 적용
    # 2) 시간 창 내 균등 분산(특정 분에 몰리지 않게 지터 부여)
    # 3) 실패 작업은 지수 백오프 재시도, 상한 초과 시 다음 주기로 이월
    for provider, group in group_by_provider(tasks):
        limit = provider.rate_limit          # 예: 초당 50건
        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)

운영에서 배우게 되는 포인트들입니다.

수집 시간 창의 사회적 합의: 모두가 자정 직후에 수집하면 제공자 시스템이 동시에 두들겨 맞습니다. 표준이 정한 정기 전송 시간대를 지키고, 그 안에서도 지터를 부여합니다.
변경분 수집: 매번 전체 기간을 다시 받지 않고 마지막 수집 시점 이후만 요청합니다. 단, 제공자 측 지연 반영(어제 거래가 오늘 추가됨)을 고려해 겹침 구간을 두고 중복 제거합니다.
부분 실패는 정상 상태: 20개 기관 중 1개는 항상 점검 중이거나 느립니다. "모든 기관 수집 완료"를 전제로 한 UX 대신 기관별 갱신 시각을 보여주는 UX가 현실적입니다.

보안 요구 — 전송구간, 인증서, 클라이언트 인증

금융 데이터 개방 체계의 보안은 여러 겹으로 구성됩니다.

계층	요구 사항	구현 수단
전송 구간	구간 암호화, 강한 TLS 설정	TLS 1.2 이상, 최신 암호 스위트
클라이언트 인증	기관 신원의 암호학적 증명	mTLS 클라이언트 인증서, 전용선/VPN 병용
메시지	전문 위변조 방지	전자서명, 거래 ID와 타임스탬프 검증
토큰	탈취 토큰의 재사용 방지	송신자 구속(mTLS 바인딩), 짧은 만료
저장	수집 정보·토큰 보호	저장 시 암호화, 키 분리 보관, 접근 통제
운영	이상 징후 탐지	호출 패턴 이상 탐지, 인증서 만료 모니터링

실무에서 의외로 자주 터지는 사고는 화려한 해킹이 아니라 인증서 만료입니다. 기관 간 mTLS 인증서, 서명용 인증서, TLS 서버 인증서의 만료일을 자산 목록으로 관리하고, 만료 30일 전 알림과 교체 리허설을 운영 루틴에 넣어야 합니다.

동의 관리 시스템 설계 — 동의는 데이터다

마이데이터의 법적 기반은 고객 동의이므로, 동의 자체가 일급 데이터 모델이어야 합니다.

-- 동의(전송요구) 모델 예시
CREATE TABLE consents (
    consent_id      UUID PRIMARY KEY,
    user_id         BIGINT NOT NULL,
    provider_code   VARCHAR(10) NOT NULL,   -- 정보제공자
    scope_codes     TEXT[] NOT NULL,        -- 동의 정보 범위
    purpose_code    VARCHAR(10) NOT NULL,   -- 수집·이용 목적
    granted_at      TIMESTAMPTZ NOT NULL,
    expires_at      TIMESTAMPTZ NOT NULL,   -- 동의 유효기간
    revoked_at      TIMESTAMPTZ,            -- 철회 시각
    status          VARCHAR(10) NOT NULL    -- ACTIVE, EXPIRED, REVOKED
);

-- 동의 이력: 모든 상태 변화를 추가 전용으로 기록
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                    -- 인증 기록 등 증적 참조
);

설계 원칙입니다.

철회의 전파: 고객이 동의를 철회하면 (1) 수집 스케줄 중단, (2) 토큰 폐기 요청, (3) 보유 기간 정책에 따른 데이터 삭제·분리 보관이 연쇄적으로 일어나야 합니다. 철회 이벤트를 발행하고 각 하위 시스템이 구독하는 이벤트 기반 전파가 누락에 강합니다.
증적 보관: "고객이 언제 어떤 화면에서 무엇에 동의했는가"를 재구성할 수 있어야 합니다. 동의 시점의 약관 버전과 인증 기록 참조를 함께 남깁니다.
만료 처리의 능동성: 동의 만료가 임박하면 사용자에게 갱신을 안내하고, 만료된 동의로는 단 한 건의 호출도 나가지 않도록 수집기 앞단에서 동의 상태를 강제합니다.

데이터 표준화 문제 — 기관별 편차와 정규화 레이어

표준 API라고 해서 데이터가 균질하지는 않습니다. 같은 스펙이라도 기관별 해석과 데이터 품질에 편차가 있습니다.

거래 유형 코드의 세분화 수준이 기관마다 다릅니다.
적요(메모) 필드의 포맷이 제각각이라 가맹점명 추출 품질이 다릅니다.
잔액·금액의 반영 시점(실시간 vs 전일 마감 기준)이 다를 수 있습니다.
같은 거래가 기관 A에서는 1건, 기관 B에서는 승인·매입 2건으로 보이기도 합니다.

따라서 이용기관 아키텍처에는 원본 보존 + 정규화 레이어의 2층 구조가 필요합니다.

[수집 데이터 정규화 파이프라인]

  표준 API 응답(기관별 원본)
        │  그대로 저장 (원본 불변 보존 — 재처리 가능성 확보)
        ▼
  raw_records (기관별 스키마 그대로)
        │  정규화: 코드 매핑, 금액 정밀도 통일, 시간대 통일,
        │          중복 제거(겹침 구간), 가맹점명 정제
        ▼
  canonical_transactions (서비스 공통 모델)
        │
        ▼
  서비스 기능 (자산 조회, 소비 분석, 신용 관리 ...)

원본을 보존하는 이유는 정규화 로직이 계속 진화하기 때문입니다. 가맹점명 정제 규칙을 개선했을 때 원본이 있으면 전체 재처리가 가능하지만, 정규화 결과만 남겼다면 되돌릴 수 없습니다.

장애와 품질 관리 — 기관별 SLA와 서킷브레이커

수십 개 기관과 연동하는 시스템에서 "전체 장애"보다 흔한 것은 "기관 한 곳의 부분 장애"입니다.

기관별 헬스 상태 관리: 기관 단위로 성공률·지연시간을 슬라이딩 윈도우로 집계하고, 임계치를 넘으면 해당 기관 호출만 차단(서킷 오픈)합니다.
서킷브레이커의 반개방 탐색: 차단 후 일정 시간이 지나면 소량의 탐색 호출로 회복 여부를 확인하고 점진 복구합니다.
타임아웃 예산: 사용자 요청 경로에서 여러 기관을 조회한다면, 전체 응답 예산(예: 3초) 안에서 기관별 타임아웃을 짧게 잡고, 늦는 기관은 "갱신 중"으로 표시한 뒤 백그라운드로 재시도합니다.
점검 캘린더 반영: 금융권은 정기 점검 시간대가 기관별로 공지됩니다. 점검 시간표를 수집기에 반영하면 불필요한 실패와 알림을 줄일 수 있습니다.

[기관별 서킷브레이커 상태 머신]

   CLOSED (정상)
     │  실패율 > 50% (최근 100건) 또는 연속 타임아웃 N회
     ▼
   OPEN (차단: 즉시 실패 응답, 큐 작업은 이월)
     │  쿨다운 경과 (예: 60초)
     ▼
   HALF-OPEN (탐색 호출 소량 허용)
     ├─ 성공 지속 ──▶ CLOSED 복귀
     └─ 실패 ──▶ OPEN 재진입 (쿨다운 증가)

비즈니스 활용과 한계

마지막으로 이 인프라 위에서 무엇이 가능하고 무엇이 어려운지 짚어보겠습니다.

가능해진 것들입니다.

여러 기관에 흩어진 자산의 통합 조회와 리밸런싱 제안
거래 데이터 기반의 소비 분석, 구독 관리, 현금흐름 예측
비금융 신용정보 결합을 통한 신파일러(thin filer) 신용평가 개선
계좌 기반 간편 송금·수납(오픈뱅킹 이체 API)

여전히 어려운 것들입니다.

실시간성의 한계: 정기 전송 주기와 기관별 반영 지연 때문에 "지금 이 순간"의 완전한 스냅샷은 보장되지 않습니다.
데이터 품질의 하한: 정규화 레이어가 아무리 좋아도 원천 데이터 품질을 넘을 수 없습니다.
수익 모델: 조회 API 호출에는 비용이 들고, 데이터 자체는 차별화 요소가 아니게 되었습니다. 차별화는 데이터 위의 분석·경험에서 나옵니다.
규제 변화 대응: 스펙 개정, 인증 정책 변화, 과금 체계 변경이 주기적으로 발생하므로, 표준 변화에 빠르게 따라가는 조직 역량 자체가 경쟁력입니다.

테스트 전략 — 테스트베드와 기관 시뮬레이터

연동 테스트에도 전략이 필요합니다.

공식 테스트베드 활용: 중계기관과 표준 운영 주체가 제공하는 테스트 환경에서 인증·전문 규격 적합성을 먼저 검증합니다. 운영 인증서와 테스트 인증서의 분리 관리에 주의합니다.
기관 시뮬레이터 내재화: 모든 통합 테스트를 외부 테스트베드에 의존하면 CI가 느려지고 불안정해집니다. 표준 스펙대로 응답하는 목(mock) 서버를 만들고, 지연·타임아웃·업무 오류 코드·기형 응답(빈 배열, 누락 필드) 시나리오를 주입할 수 있게 합니다.
계약 테스트: 스펙 개정 시 기존 파서가 깨지지 않는지, 응답 스키마 변화를 계약(contract) 테스트로 잡습니다. "필드 추가에는 관대하게, 필드 의미 변화에는 민감하게"가 원칙입니다.
카오스 시나리오: 기관 1곳 전면 장애, 전 기관 지연 2배, 토큰 대량 만료 같은 시나리오에서 서킷브레이커와 큐 이월이 설계대로 동작하는지 정기적으로 검증합니다.

설계 체크리스트

마치며

오픈뱅킹과 마이데이터는 "API 몇 개 연동"처럼 보이지만, 실제로는 인증·동의·표준화·장애 관리·정산이 맞물린 분산 시스템 설계 문제입니다. 특히 동의 관리와 기관별 품질 편차는 시작 전에는 과소평가되고 운영 후에는 가장 많은 시간을 가져가는 영역입니다. 이 글의 구조 — 중계 모델 이해, FAPI 수준의 보안 기준선, 원본 보존과 정규화 분리, 기관 단위 장애 격리 — 를 출발점으로 삼으시면, 데이터 개방 시대의 시스템을 한층 견고하게 설계할 수 있을 것입니다.

참고 자료

금융결제원: https://www.kftc.or.kr/
오픈뱅킹공동업무 (금융결제원 운영): https://www.openbanking.or.kr/
마이데이터 종합포털: https://www.mydatacenter.or.kr/
금융위원회: https://www.fsc.go.kr/
금융감독원: https://www.fss.or.kr/
금융보안원: 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