- Published on
오픈뱅킹·PSD3·Open Finance 2026 — Plaid·TrueLayer·Tink·Yapily·Belvo·금융결제원·全銀協 심층 가이드
- Authors

- Name
- Youngju Kim
- @fjvbn20031
프롤로그 — PSD2의 8년, 그리고 PSD3가 열리는 2026년
2018년 1월 EU에서 PSD2(Payment Services Directive 2)가 시행됐을 때, 은행 업계의 반응은 둘로 나뉘었다. "외부 회사가 우리 계좌 데이터를 가져간다고?" 그리고 "이건 결국 표준이 될 것이다." 8년이 지난 2026년, 후자가 맞았다. EU는 PSD3 + PSR(Payment Services Regulation)을 2026년부터 단계 시행하고, FIDA(Financial Data Access Regulation)가 통과되며 Open Banking은 Open Finance로 확장된다.
미국에서는 Plaid·Finicity(Mastercard)·MX·Akoya가 FDX(Financial Data Exchange) 표준 위에서 경쟁한다. 영국·EU에서는 TrueLayer·Tink(Visa 자회사)·Yapily·Salt Edge가, LatAm은 Belvo가, 인도는 Account Aggregator(Sahamati)가 같은 자리를 메운다. 한국은 금융결제원의 오픈뱅킹 API와 마이데이터 사업이 5년차에 접어들었고, 일본은 全銀協(전국은행협회)의 銀行 API 가이드라인이 의무화 단계로 들어선다.
이 글의 목적은 한 가지다 — 2026년의 오픈뱅킹·Open Finance를 한 호흡으로 이해하는 것. 표준(PSD3·FIDA·FDX·FAPI), 라이선스(AISP·PISP·PIP), 보안(SCA·다이내믹 링크), 인프라(애그리게이터), 그리고 한국과 일본의 시장 구조까지.
1장 · 용어 정리 — AISP·PISP·CBPII·SCA·FAPI
오픈뱅킹은 약어가 많다. 정리하면 다음과 같다.
| 용어 | 의미 | 누가 쓰나 |
|---|---|---|
| AISP | Account Information Service Provider | 계좌 정보 조회 (Plaid, TrueLayer) |
| PISP | Payment Initiation Service Provider | 결제 개시 (TrueLayer, Tink) |
| CBPII | Card-Based Payment Instrument Issuer | 카드 잔고 확인 |
| ASPSP | Account Servicing Payment Service Provider | 은행 자체 |
| TPP | Third Party Provider | AISP/PISP/CBPII 통칭 |
| SCA | Strong Customer Authentication | 강력 고객 인증 (2요소) |
| RTS | Regulatory Technical Standards | EBA가 정의한 기술 표준 |
| FAPI | Financial-grade API (OpenID Foundation) | OAuth 2.0 + 보안 강화 |
| QSeal/QWAC | Qualified Certificates | TPP 신원 증명 인증서 |
| eIDAS | EU 전자 신원 규정 | QSeal/QWAC 근거법 |
PSD2 시대에는 RTS와 eIDAS 인증서가 통신 신원을 보장했다. PSD3는 여기에 FAPI 2.0과 더 강한 fraud-prevention 의무를 결합한다.
2장 · PSD2(2018) → PSD3 + PSR(2026) — 무엇이 바뀌나
PSD2의 가장 큰 한계는 두 가지였다 — (1) 회원국별 RTS 해석 차이로 통합 시장이 안 됐다, (2) AISP/PISP가 은행 API의 품질 편차로 고생했다. PSD3는 이를 정면 돌파한다.
PSD3 + PSR(Payment Services Regulation)의 핵심 변경점:
- 단일 시장 통합: PSR이 regulation 형태(directive가 아님)라 회원국이 그대로 적용해야 함.
- API 품질 의무: 은행이 dedicated interface(screen scraping 금지) 운영, downtime 보고, KPI 공시.
- 사기 책임 분담: AISP·PISP·은행 간 사기 손실 분담 규칙 명문화.
- AISP/PISP 라이선스 통합: 단일 PSP(Payment Service Provider) 라이선스로 통합.
- SCA 예외 확대: 저금액·정기 결제·trusted beneficiary 등 예외 정비.
- 다이내믹 링크 강화: 결제 금액·수취인이 인증 토큰에 결합되어야 함.
2026년 1월 PSR 1차 적용 시작, 2027-2028년 사이 PSD3 회원국 전환 완료가 일정이다. 실무자 입장에서 중요한 건 API SLA와 KPI 공시다. 은행이 다운된 API를 방치할 수 없게 됐다.
3장 · FIDA — Open Banking에서 Open Finance로
FIDA(Financial Data Access Regulation)는 2025년 EU 의회를 통과해 2026년 시행에 들어간다. 핵심은 금융 데이터 공유의 범위를 결제·계좌에서 보험·연금·투자·모기지로 확장하는 것이다.
PSD3가 결제·계좌라면 FIDA는 그 외 모든 금융 데이터다. 의무 공유 대상:
- 모기지·소비자 대출 잔액·상환 일정
- 예금·정기예금·MMF
- 보험 — 종신·자동차·주택·여행
- 연금 — 사적 연금, 직장 연금
- 투자·증권 계좌 — 잔고·체결·평가
- 암호자산 보유 (MiCA와 연계)
FIDA의 새 개념은 **FISP(Financial Information Service Provider)**다. AISP가 결제·계좌에 해당했다면, FISP는 그 외 영역을 담당한다. 그리고 **FIDP(Financial Data Provider)**가 데이터를 제공하는 측이다.
규제 측면에서 FIDA는 더 명확한 보상 모델을 도입한다 — FIDP가 데이터를 제공할 때 합리적 수수료를 받을 수 있다. PSD2가 무료였던 것과는 다르다. 이는 은행·보험사·연금사가 API를 운영할 인센티브를 만든다.
4장 · Plaid — 미국 오픈뱅킹의 표준이 된 회사
Plaid는 2013년 샌프란시스코에서 시작했다. Venmo·Robinhood·Acorns 같은 핀테크의 은행 연결 인프라로 자리 잡으며 2026년 현재 미국·캐나다·EU에서 $50B transactions 규모의 데이터를 처리한다(자체 공시 기준 추정).
Plaid 제품 라인:
- Plaid Link: 사용자가 자기 은행을 선택하고 OAuth/credential로 연결하는 위젯.
- Transactions API: 거래 내역 가져오기.
- Auth: 계좌·라우팅 번호 확인.
- Identity: KYC용 신원 확인.
- Balance: 실시간 잔액.
- Income: 소득 검증.
- Assets: 자산 보고서(대출 심사용).
- Liabilities: 학자금·신용카드·모기지 잔액.
- Investments: 증권 계좌 보유 종목·체결.
- Signal: ACH 사기 위험 점수.
Plaid Link 자바스크립트 사용 예 (개념 코드):
// Plaid Link — 클라이언트 사이드 흐름
const handler = Plaid.create({
token: linkToken, // 서버에서 미리 생성한 link_token
onSuccess: async (publicToken, metadata) => {
// 클라이언트는 publicToken만 받음.
// publicToken을 서버로 보내 access_token으로 교환.
await fetch('/api/plaid/exchange-public-token', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ public_token: publicToken })
})
},
onExit: (err, metadata) => {
if (err) console.error('plaid_exit', err)
},
onEvent: (eventName, metadata) => {
// OPEN, SELECT_INSTITUTION, SUBMIT_CREDENTIALS, HANDOFF, ERROR ...
}
})
handler.open()
서버 측의 토큰 교환:
// 서버 — public_token → access_token 교환
import { Configuration, PlaidApi, PlaidEnvironments } from 'plaid'
const client = new PlaidApi(new Configuration({
basePath: PlaidEnvironments.production,
baseOptions: {
headers: {
'PLAID-CLIENT-ID': process.env.PLAID_CLIENT_ID,
'PLAID-SECRET': process.env.PLAID_SECRET,
},
},
}))
async function exchange(publicToken) {
const res = await client.itemPublicTokenExchange({ public_token: publicToken })
// res.data.access_token — 사용자의 access token
// res.data.item_id — Plaid Item 식별자
return res.data
}
Plaid는 2022년 Visa의 인수 시도가 미국 DOJ 반독점 조사로 무산된 이후 독립 노선을 걷는다. 2026년 IPO가 임박했다는 보도가 많다.
5장 · TrueLayer·Tink·Yapily — UK·EU 애그리게이터 빅3
영국과 EU의 오픈뱅킹 인프라는 세 회사가 주도한다.
- TrueLayer (2016, 런던): PISP 결제에 강함. eBay·Revolut·셀러브리티 토토 자선단체까지 결제 채널로 사용. AISP + PISP 통합.
- Tink (2012, 스톡홀름 → 2022 Visa 인수): EU 전역 커버리지, PFM(개인 재무 관리) 출발. Visa 인수 후 Visa Direct와 결합해 결제·정산까지 통합.
- Yapily (2017, 런던): "헤드리스" AISP를 표방. UI 없이 API만 제공해 핀테크가 자기 UX를 만들도록 함.
TrueLayer 결제 개시(PISP) 흐름 예:
// TrueLayer — 결제 인텐트 생성 (서버)
const res = await fetch('https://api.truelayer.com/payments/v3', {
method: 'POST',
headers: {
'Authorization': `Bearer ${accessToken}`,
'Idempotency-Key': idempotencyKey,
'Content-Type': 'application/json',
},
body: JSON.stringify({
amount_in_minor: 1099,
currency: 'GBP',
payment_method: { type: 'bank_transfer', provider_selection: { type: 'user_selected' } },
beneficiary: {
type: 'merchant_account',
merchant_account_id: 'acc_xxx',
account_holder_name: 'Example Ltd'
},
user: { id: 'usr_123', name: 'Alice', email: 'alice@example.com' }
})
})
const payment = await res.json()
// payment.resource_token + redirect URL로 사용자 인증 → 결제 완료
Tink은 Visa 자회사가 된 후 Visa Direct·CyberSource와 결합해 결제·정산 인프라를 글로벌화했다. AISP 단독으로는 TrueLayer에 밀려도, Visa의 체급 위에서 다른 시장(LatAm·아시아)으로 확대 중이다.
Yapily의 차별점은 화이트라벨 비즈니스 모델이다. 모든 UI를 핀테크가 만들고 Yapily는 API 호출만 받는다. 이는 규제·라이선스에서 핀테크에 자유도를 주지만, UX 설계 부담을 떠넘긴다.
6장 · Belvo·Salt Edge — LatAm과 글로벌 커버리지
- Belvo (2019, 멕시코시티 + 마드리드): LatAm 오픈뱅킹의 표준. 멕시코·브라질·콜롬비아·칠레·아르헨티나의 은행 API 통합. 핀테크인 Konfío·Bitso·Clip 같은 회사들의 인프라.
- Salt Edge (2013, 토론토): "글로벌 커버리지"가 무기. 50+개국, 5,000+개 금융기관 연결. 단일 API로 EU·UK·미국·아시아 일부·LatAm·중동을 모두 다룬다.
Belvo가 다루는 특수 과제 중 하나는 PIX(브라질의 즉시 결제 시스템) 연동이다. PIX는 중앙은행 직영으로 EU의 SEPA Instant나 한국의 오픈뱅킹 즉시이체에 해당한다. 2026년에 브라질 결제 인프라가 거의 PIX로 전환된 후 Belvo는 PIX 결제 개시를 PISP 방식으로 제공한다.
// Belvo — 브라질 PIX 결제 개시 예 (개념)
const res = await fetch('https://api.belvo.com/payments/payment-intents/', {
method: 'POST',
headers: {
'Authorization': 'Basic ' + btoa(`${secretId}:${secretPassword}`),
'Content-Type': 'application/json',
},
body: JSON.stringify({
amount: '49.90',
currency: 'BRL',
description: '주문 #12345',
payment_method_type: 'pix',
callback_urls: { success: 'https://example.com/ok', error: 'https://example.com/err' },
customer: { name: 'Maria Silva', email: 'maria@example.com', document_id: '12345678901' }
})
})
Salt Edge는 "넓이"가 무기다. 5,000개 기관의 일관된 데이터 모델을 위해 자체 분류 체계를 운영한다. 이게 거래 카테고라이제이션을 가능하게 한다(주거·식비·교통 등 자동 분류).
7장 · Finicity·MX·Akoya — 미국의 FDX 시대
미국은 EU와 다른 길을 걸어왔다. 정부 주도의 PSD2가 없는 대신 시장 주도의 FDX(Financial Data Exchange)가 표준 역할을 한다. 2026년 CFPB(Consumer Financial Protection Bureau)의 1033조 규정 발효로 본격적인 규제 단계로 진입한다.
- Finicity (2000, 유타 → 2020 Mastercard 인수): 자산 검증·소득 검증·모기지 인수에 강함. Mastercard 인수 후 결제·신용 시너지.
- MX (2010, 유타): 은행·신용조합용 PFM 백엔드. 데이터 클리닝·분류에 강함.
- Akoya (2018, 보스턴): Fidelity·8개 미국 대형 은행 합작. 컨소시엄 모델. "은행이 만든 애그리게이터"라는 포지션.
CFPB의 1033조(Personal Financial Data Rights Rule)는 2024년 10월 최종 발효됐다. 핵심:
- 소비자가 자기 금융 데이터에 대한 권리 보유.
- 데이터 보유자(은행)는 소비자나 그가 지정한 TPP에게 데이터를 무료로 제공해야 함.
- FDX 표준을 사실상 인정.
- screen scraping 금지 일정.
{
"fdx_api_version": "6.0",
"endpoint": "GET /accounts/{accountId}/transactions",
"permission_scope": "ACCOUNTS_DETAIL_READ TRANSACTIONS_READ",
"rate_limits": {
"per_consumer_per_day": 4,
"burst": 30
},
"auth": "OAuth 2.0 + DPoP",
"data_format": "FDX Common Schema"
}
미국 시장은 2026년에 큰 정리 단계에 있다. screen scraping이 줄고 OAuth/FDX API가 늘어난다. 이 흐름에서 Plaid·Finicity·MX·Akoya는 각자의 포지션을 굳히려 한다.
8장 · FAPI 2.0 — 금융 등급 OAuth 표준
OAuth 2.0은 좋지만 금융에 쓰기엔 약하다. OpenID Foundation의 **FAPI(Financial-grade API)**는 금융을 위해 OAuth를 강화한 표준이다. 2026년 FAPI 2.0이 표준이 됐다.
FAPI 2.0의 주요 강화점:
- PAR (Pushed Authorization Requests): 클라이언트가 인증 파라미터를 서버에 미리 푸시. URL의 길이·노출 문제 해결.
- mTLS 또는 private_key_jwt: 클라이언트 인증 강화.
- DPoP (Demonstrating Proof-of-Possession): 액세스 토큰을 클라이언트 키에 바인딩. 도난 토큰 무력화.
- RAR (Rich Authorization Requests): 세부 권한(금액·수취인·기간) 명시.
- JARM: 응답을 JWS로 서명.
전체 흐름의 예시:
POST /par HTTP/1.1
Host: as.bank.example
Content-Type: application/x-www-form-urlencoded
response_type=code
&client_id=tpp_acme
&redirect_uri=https%3A%2F%2Ftpp.example%2Fcb
&scope=accounts%20payments
&authorization_details=%5B%7B%22type%22%3A%22payment_initiation%22%2C%22amount%22%3A%7B%22currency%22%3A%22EUR%22%2C%22value%22%3A%2299.99%22%7D%2C%22creditor%22%3A%7B%22iban%22%3A%22DE89370400440532013000%22%7D%7D%5D
&code_challenge=...&code_challenge_method=S256
&state=xyz
응답으로 request_uri를 받아 인증 URL을 만든다. 사용자는 은행에서 SCA를 수행하고, 콜백으로 code를 받는다. 이를 토큰 엔드포인트에 mTLS·DPoP과 함께 제출해 access_token을 받는다.
PSD3는 FAPI 2.0을 사실상 권고하며, 2027-2028년에 EU의 거의 모든 ASPSP가 FAPI 2.0 호환 인증 서버를 운영할 것으로 보인다.
9장 · SCA — Strong Customer Authentication 정리
SCA는 PSD2의 핵심 보안 요구다. 두 가지 다른 요소를 결합한다.
- 지식(knowledge): 비밀번호, PIN.
- 소유(possession): 휴대전화, 토큰.
- 본인(inherence): 생체.
PSD2 SCA는 결제·계좌 접근에 의무다. 다만 예외(exemption)가 있다.
| 예외 | 조건 | 적용 |
|---|---|---|
| 소액 결제 | <EUR 30 (누적 EUR 100/5건 한도) | 비대면 카드 |
| 신뢰 수익자 | 사용자가 자기 신뢰 명단에 등록 | 정기 송금 |
| 정기 결제 | 동일 금액 정기 | 구독 |
| 기업 결제 | 기업용 안전 결제 시스템 | B2B |
| TRA (Transaction Risk Analysis) | TPP가 사기율 임계 이하 | 가맹점·이슈어 |
| 무인 결제 | 통행료·주차 | 자동 |
| 1회 인증 90일 | 동일 TPP·계좌 한정 | AISP 데이터 갱신 |
PSD3는 TRA 강화와 AISP 90일 재인증 완화가 핵심이다. 90일마다 강제 SCA가 필요했던 PSD2 RTS의 규칙이 풀리면서, 모바일 앱·자산관리 앱의 UX가 개선된다.
다이내믹 링크(dynamic linking)는 SCA의 또 다른 핵심이다. 인증 토큰이 결제 금액·수취인을 포함해야 한다. 이는 MITM 공격에서 결제 변조를 막는다.
10장 · 한국 오픈뱅킹 — 금융결제원의 100+개 API
한국의 오픈뱅킹은 2019년 12월 전면 시행됐다. 금융결제원(KFTC)이 중앙 허브를 운영하고 은행·증권사·전자금융업자가 API를 통해 접근한다.
운영 현황(2026년 기준 추정):
- 참여 기관: 은행 19개, 상호금융, 저축은행, 우체국, 카드사, 핀테크.
- 핵심 API: 잔액 조회, 거래내역 조회, 출금이체, 입금이체, 계좌 실명, 수취조회 등 100여 종.
- 사용량: 일 평균 수억 건의 호출, 누적 수십조 원 규모의 이체.
- 비용: 표준 수수료가 핀테크 진입을 낮춤.
금융결제원 OpenAPI의 OAuth 흐름은 표준 OAuth 2.0 + 다이내믹 클라이언트 등록을 기반으로 한다. 다이내믹 링크와 SCA도 표준화돼 있다.
GET /v2.0/account/balance/fin_num
?bank_tran_id=M202612340U001234567
&fintech_use_num=199912345678901234
&tran_dtime=20260525120000
Authorization: Bearer {access_token}
응답 예:
{
"api_tran_id": "f1234567-1234-5678-9abc-1234567890ab",
"rsp_code": "A0000",
"rsp_message": "정상",
"bank_code_std": "088",
"balance_amt": "1250000",
"available_amt": "1250000",
"account_type": "1",
"product_name": "기업자유예금",
"bank_tran_id": "M202612340U001234567",
"bank_tran_date": "20260525",
"api_tran_dtm": "20260525120000123"
}
오픈뱅킹 표준 덕분에 토스·카카오뱅크·뱅크샐러드·핀크 같은 회사들이 짧은 시간에 다중 은행 계좌 통합을 구현할 수 있었다. 2026년 현재 한국 오픈뱅킹은 EU PSD2와 비슷한 성숙도지만, 라이선스 구조가 다르다 — EU는 AISP/PISP, 한국은 전자금융업자 + 본인신용정보관리업(마이데이터).
11장 · 한국 마이데이터 — 본인신용정보관리업
마이데이터는 2022년 1월 본격 출범했다. 신용정보법 개정으로 만들어진 본인신용정보관리업이 법적 근거다. 2026년 현재 마이데이터 사업자가 60+개를 넘었다.
대표 사업자:
- 은행: 신한·KB국민·하나·우리·NH농협·기업·SC제일·DGB·BNK·iM·전북·광주·제주.
- 카드: 신한·삼성·KB·현대·롯데·우리·하나·BC·NH.
- 핀테크: 카카오뱅크·토스·뱅크샐러드·핀크·페이코·네이버페이·카카오페이·NHN페이코.
- 증권: 미래에셋·NH투자·삼성·KB·키움·한투·신한투자.
- 보험: 삼성·한화·교보·신한·KB·동양·미래에셋.
마이데이터의 데이터 범위는 오픈뱅킹보다 넓다.
| 분야 | 데이터 |
|---|---|
| 은행 | 계좌·거래·대출·외환 |
| 카드 | 결제·승인·청구·할부·해외 |
| 증권 | 보유 종목·체결·시세·평가 |
| 보험 | 가입·납입·청구·해약 |
| 통신 | 통신비 |
| 공공 | 국세·관세·연금 |
| 헬스 | 의료 데이터(2024년 의료 마이데이터 확장) |
마이데이터 통합인증 API는 사용자가 한 번 인증으로 여러 기관 데이터에 접근하도록 한다. 통합인증 1.0은 2022년 시행, 통합인증 2.0이 2024년 도입되며 OIDC + DID 결합이 강화됐다.
POST /oauth/2.0/token
Host: api.mydatakorea.example
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code
&client_id={조직코드}
&client_secret={시크릿}
&code={인가코드}
&redirect_uri={리다이렉트}
&org_code={정보제공자코드}
마이데이터의 장점은 데이터 범위가 넓고 사용자 동의가 표준화돼 있다는 점이다. 단점은 정보제공기관별로 API 품질·갱신 주기·기관 코드가 다르다는 운영 부담이다. 금융결제원과 신용정보원이 협력해 표준화를 진행 중이다.
12장 · 카카오뱅크·토스 — 한국 마이데이터의 두 모델
한국 마이데이터에서 두 큰 사업자는 카카오뱅크와 토스(Viva Republica)다. 같은 면허인데 비즈니스 모델이 다르다.
- 카카오뱅크: 인터넷 전문은행 본업 + 마이데이터. 자산 통합·소비 분석·신용 평가 강화.
- 토스: 종합 금융 플랫폼. 마이데이터로 통합한 데이터를 토스증권·토스뱅크·토스인슈어런스에 활용.
토스의 강점은 통합 UX다. 사용자가 토스 앱 안에서 자기 금융 라이프 전체를 본다. 카카오뱅크는 메신저 친화 UX와 26주 적금 같은 게임화 상품이 강하다.
마이데이터의 다음 단계는 개인사업자·소상공인 마이데이터다. 매출·매입·세금·인건비 같은 사업 데이터를 통합해 SME 금융을 가속할 것이다. 2025-2026년에 시범사업이 진행 중이다.
13장 · 일본 全銀協 API — 의무화로 가는 길
일본은 2017년 銀行法 개정으로 전자결제등 대행업 라이선스를 만들었다. EU의 AISP/PISP에 해당한다. 2018-2020년에 全銀協(전국은행협회)이 銀行 API 가이드라인을 발표했고, 2024-2026년에 의무화 단계로 진입한다.
운영 구조:
- ASPSP에 해당하는 일본 은행 — 三井住友·MUFG·みずほ·りそな + 지방은행.
- 전자결제등 대행업자: マネーフォワード·freee·MoneyTree·Moneytree·Nudge.
- 全銀協이 API 표준·접속 규약을 운영.
三井住友(SMBC), MUFG, みずほ는 각자 API를 운영하지만 全銀協 가이드라인을 따른다. 표준은 OAuth 2.0 + FAPI 1.0이 다수, 일부 은행은 FAPI 2.0을 준비 중이다.
GET /v1/accounts/{accountId}/balance
Host: bankapi.smbc.example
Authorization: Bearer {access_token}
x-fapi-financial-id: ZNG-2026-SMBC
x-fapi-interaction-id: 5a8e2b1c-...
200 OK
{
"Data": {
"Account": [{
"AccountId": "ACC-2026-001234",
"Currency": "JPY",
"AvailableBalance": "523450",
"BookedBalance": "523450"
}]
}
}
일본의 특수성은 PSP 영역과 은행 영역의 명확한 분리다. PayPay·LINE Pay·楽天Pay 같은 전자결제 서비스는 은행 API를 통해 자동 충전을 한다. 사용자는 은행 잔고에서 직접 결제 대신 PSP 지갑에 충전한다.
마네ーフォワード·freee는 일본판 PFM·회계 SaaS의 대표 주자다. 銀行 API를 받아 자영업자·SME의 통합 회계를 구현한다. 미국의 Mint·QuickBooks와 비슷하다.
14장 · 일본 JFSA 가이드라인과 2026년 방향
일본 금융청(JFSA)은 2024년 "オープンバンキング推進" 정책을 발표했다. 핵심:
- 銀行 API의 표준화·품질 KPI 공시.
- 전자결제등 대행업자의 보안·운영 기준 강화.
- 데이터 휴대권(Data Portability) 인정.
- 보험·증권·연금 분야 확장 — EU FIDA와 유사한 방향.
JFSA는 2025년 "金融データ活用基本方針"을 발표하며 Open Finance로의 확장을 명시했다. 일본의 특이점은 개인정보보호위원회와 JFSA의 이원 거버넌스다. 개인정보보호법(2022년 개정)이 데이터 보호 베이스라인을 깔고, JFSA가 금융 특화 규제를 더한다.
업계 동향:
- 三井住友(SMBC): SMBC Cloud Sign + API. AI 신용 평가 자체 구축.
- MUFG: GO-NET·MUFG Coin 등 디지털 전략. API는 표준화.
- みずほ: J-Coin Pay + 銀行 API.
- りそな: 데이터 분석·법인 API 강화.
- 楽天銀行: 인터넷은행, 楽天 경제권 연동.
- PayPay 銀行(舊 ジャパンネット銀行): PayPay 연동.
15장 · 미국 1033조 시행 — Open Banking이 법이 되다
미국은 정부 주도 PSD2가 없었다. 그러나 CFPB 1033조(Personal Financial Data Rights Rule)가 2024년 10월 최종 확정되며 사실상 미국판 PSD2가 됐다.
주요 의무:
- 데이터 보유자는 소비자나 그가 위임한 TPP에게 1년치 거래·잔액·기본 계좌 정보를 무료로 제공.
- 데이터 형식은 FDX 표준 사실상 인정.
- screen scraping 단계적 금지.
- 데이터 사용에 대한 소비자 동의 요구.
- 데이터의 secondary use 제한.
시행 일정은 자산 규모별로 단계적 적용이다. 대형 은행은 2026년 4월, 중형은 2026년 10월, 소형은 2027년 등으로 적용된다.
이로 인해 미국의 오픈뱅킹 생태계는 PSD2-EU와 비슷한 표준화 흐름에 들어선다. Plaid·Finicity·MX·Akoya는 각자 FDX 호환 API 운영자가 되며, screen scraping 의존도가 줄어든다.
16장 · 보안·사기 — 다이내믹 링크와 token binding
오픈뱅킹 보안의 두 큰 축은 다이내믹 링크와 토큰 바인딩이다.
다이내믹 링크: 결제 인증 토큰이 금액·수취인을 포함해야 함. 이는 MITM 공격에서 결제 변조를 막는다.
토큰 바인딩: access_token이 클라이언트 키·디바이스에 묶여 있어야 함. DPoP·mTLS가 이를 구현한다.
# DPoP 헤더 — 토큰을 클라이언트 키에 바인딩
POST /payments HTTP/1.1
Host: as.bank.example
Authorization: DPoP eyJraWQiOiJ...access_token...
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIs...signed_proof...
DPoP는 클라이언트의 공개키에 access_token을 묶고, 매 요청마다 클라이언트가 비밀키로 서명한 proof JWT를 추가한다. access_token이 도난당해도 비밀키 없이는 사용 못 한다.
사기 방지의 추가 신호:
- 디바이스 핑거프린트·IP 지리·세션 행동.
- behavior biometrics(타이핑 패턴, 마우스 움직임).
- 거래 그래프 — Plaid Signal·TrueLayer Trust 같은 제품이 ACH·결제의 사기 위험 점수를 제공.
PSD3 + PSR의 책임 분담 규칙은 사기 손실이 발생했을 때 TPP·ASPSP·소비자의 부담을 명확히 한다. 이전 PSD2의 모호함이 자주 분쟁을 만들었다.
17장 · 데이터 카테고라이제이션 — 거래를 의미로 바꾸기
오픈뱅킹 데이터의 가치는 raw에 있지 않다. 거래를 "스타벅스 커피", "월세", "교통비"처럼 분류했을 때 사용자에게 의미가 된다. 카테고라이제이션은 모든 애그리게이터·PFM 앱의 핵심 IP다.
표준 분류 체계:
| 대분류 | 소분류 |
|---|---|
| 식비 | 외식·배달·식료품·카페 |
| 교통 | 대중교통·택시·연료·주차·통행료 |
| 주거 | 월세·관리비·공과금·인터넷 |
| 통신 | 휴대전화·인터넷·구독 |
| 쇼핑 | 의류·전자·가구·생활용품 |
| 엔터테인먼트 | 영화·게임·OTT·여행 |
| 건강 | 의료·약국·헬스장 |
| 교육 | 학원·교재·전공 |
| 금융 | 보험·대출 상환·투자 |
| 송금 | 개인 송금·해외 송금 |
카테고라이제이션의 방법:
# 거래 분류 — 룰 + ML 결합 (개념 코드)
import re
from typing import Dict
RULES = [
(r"STARBUCKS|스타벅스", "식비/카페"),
(r"UBER|KAKAO T|카카오 T", "교통/택시"),
(r"넷플릭스|NETFLIX", "엔터테인먼트/OTT"),
(r"이마트|EMART|롯데마트", "식비/식료품"),
]
def rule_categorize(memo: str) -> str | None:
for pattern, cat in RULES:
if re.search(pattern, memo, re.IGNORECASE):
return cat
return None
# 룰이 못 잡으면 ML 모델로 fallback
def hybrid_categorize(tx: Dict, ml_model) -> str:
cat = rule_categorize(tx.get("memo", ""))
if cat:
return cat
return ml_model.predict([tx])[0]
규제 측면에서 카테고라이제이션은 신용 평가·마케팅·정부 보조금 자격 판정에 영향을 줘서, 미국·EU·한국 모두 정확도·편향 모니터링을 요구한다.
18장 · 인도 Account Aggregator — 또 다른 모델
인도는 다른 길을 걸었다. 인도 중앙은행(RBI)이 2016년에 만든 Account Aggregator(AA) 체계가 표준이다. NBFC-AA라는 새 라이선스를 만들어 데이터 매개자의 역할을 분리했다.
특징:
- 동의 관리(consent manager) 중심 모델.
- FIP(Financial Information Provider) — 은행·증권·연금 등 데이터 제공자.
- FIU(Financial Information User) — 데이터 사용자.
- AA — 동의·라우팅·암호화 매개자. 데이터를 보지 않음.
- ReBIT(Reserve Bank IT)가 표준 운영. Sahamati가 산업 협회.
AA 모델은 EU와 다르다. AA가 데이터를 보지 않고 단순히 라우팅한다. 데이터는 FIP에서 FIU로 직접 흐른다. AA는 동의의 무결성·감사 로그·암호화 보장에 집중한다.
이 모델은 한국 마이데이터의 일부 설계에도 영향을 줬다. 한국이 본인신용정보관리업자에게 데이터 통합·표시를 허용하는 게 다른 점이다.
19장 · Open Finance — 보험·연금·투자로 확장
PSD2가 결제·계좌라면 Open Finance는 그 외 모든 금융이다. FIDA가 EU의 시발점이며, 한국·일본·미국도 비슷한 흐름이다.
확장의 시그널:
- 보험: 종신·자동차·주택 보장·청구 데이터를 다른 보험사·비교 마켓이 받음.
- 연금: 직장 연금·사적 연금의 잔액·기여·예상 수령액.
- 투자: 증권 계좌의 보유·체결·평가·수수료.
- 모기지: 잔액·이자율·상환 일정. 리파이낸싱 비교 가속.
- 암호자산: MiCA·VASP 규제와 연계.
기술 표준은 PSD2/PSD3와 같은 OAuth 2.0 + FAPI 2.0 + JSON API다. 데이터 모델만 분야별로 새로 정의된다. EBA·EIOPA가 표준화 가이드를 발표 중이다.
한국에서는 마이데이터가 처음부터 Open Finance에 가까웠다 — 보험·증권·통신·공공이 1단계에 포함됐다. 일본은 銀行 API에서 시작해 단계적으로 보험·증권으로 확장한다.
20장 · TPP 라이선스 — 어디서 어떻게 받나
오픈뱅킹·Open Finance 사업을 하려면 TPP 라이선스가 필요하다. 국가별 정리.
| 국가 | 라이선스 | 감독 |
|---|---|---|
| EU | AISP, PISP (단일 PSP로 통합) | 국가 감독청 + EBA |
| UK | AISP, PISP (FCA 등록) | FCA |
| US | 단일 라이선스 없음. 주별 MTL 등 | CFPB, OCC, FinCEN |
| KR | 전자금융업, 마이데이터(본인신용정보관리업) | 금융위·금감원 |
| JP | 전자결제등 대행업 | 金融庁(JFSA) |
| BR | Open Finance 단계 라이선스 | BCB(중앙은행) |
| IN | NBFC-AA | RBI |
| MX | Fintech Law 라이선스 | CNBV |
EU에서 가장 많이 쓰이는 길은 리투아니아·아일랜드·룩셈부르크 같은 작은 국가에서 라이선스를 받고 EU 패스포팅을 활용하는 것이다. 영국은 Brexit 이후 별도 등록이 필요하다.
한국은 마이데이터 면허가 신청만으로는 어렵다. 자기자본 5억 원 이상, 보안 시스템·관제·인력·재무건전성 요건이 있다. 일본은 시스템 운영·재무 감사·정보 보호 기준이 까다롭지만 자본 요건은 상대적으로 가볍다.
21장 · 인프라 비교 — 자체 구축 vs 애그리게이터
핀테크가 오픈뱅킹을 도입할 때 두 갈래가 있다. 직접 ASPSP 연결 vs 애그리게이터 사용.
| 항목 | 자체 직접 연결 | 애그리게이터(Plaid/TrueLayer/Tink/Belvo/Salt Edge) |
|---|---|---|
| 초기 비용 | 높음 (라이선스·인증서·테스트) | 낮음 (월간 비용) |
| 운영 비용 | 낮음 (호출당 비용 없음) | 호출당 또는 사용자당 |
| 시간 | 6-18개월 | 1-2주 |
| 커버리지 | 자기가 통합한 만큼 | 수백-수천 기관 |
| 안정성 | 자기가 책임 | 애그리게이터가 책임 |
| 데이터 표준화 | 자기가 처리 | 애그리게이터가 정규화 |
| 규제 책임 | 직접 | 공동 (TPP 책임 + 처리자 책임) |
대부분의 스타트업은 애그리게이터로 시작해 규모가 커지면 핵심 시장만 직접 연결하는 하이브리드로 간다. 예: Wealthsimple은 캐나다·미국 큰 은행은 직접, 작은 기관은 Plaid로.
22장 · 실전 예 — 종합 자산 대시보드 만들기
종합 자산 대시보드는 오픈뱅킹·마이데이터의 대표 활용처다. 한 화면에 여러 은행·증권·카드·보험의 자산을 모은다.
설계 흐름:
- 사용자 가입·OAuth 동의(다중 기관).
- access_token·refresh_token 저장(보안 KMS).
- 주기적 동기화(
<2초 API call응답을 받으려면 캐시·풀링 결합). - 정규화 — 통화·잔액·자산 클래스 표준화.
- 표시 — 잔액·시계열·자산 배분·목표.
// 종합 자산 대시보드 — 동기화 잡 (개념 코드)
async function syncAllAccounts(userId) {
const userTokens = await tokenStore.list({ userId })
// 동시 호출 (Plaid + 마이데이터 + 銀行 API 등)
const results = await Promise.allSettled(
userTokens.map(async (t) => {
switch (t.provider) {
case 'plaid':
return await plaid.balances(t.accessToken)
case 'kr_mydata':
return await krMydata.accounts(t.accessToken, t.orgCode)
case 'jp_smbc':
return await jpSmbc.accounts(t.accessToken)
case 'truelayer':
return await truelayer.accounts(t.accessToken)
}
})
)
// 결과를 표준 모델로 변환
return normalize(results)
}
운영 이슈:
- 토큰 만료(보통 90일). PSD3는 AISP 90일 재인증을 완화해 UX 개선.
- 다중 기관 합산 시 통화 환산 — 환율 소스 신뢰성.
- 거래 분류·중복 제거 — 카드 결제와 은행 출금이 중복으로 보일 수 있음.
- 다운타임 처리 — 일부 기관이 응답 못해도 화면이 깨지지 않게.
23장 · 종합 비교 — US·EU·KR·JP 규제 매트릭스
| 항목 | US (CFPB 1033) | EU (PSD3 + PSR + FIDA) | KR (오픈뱅킹 + 마이데이터) | JP (全銀協 + JFSA) |
|---|---|---|---|---|
| 법적 근거 | Dodd-Frank §1033 | PSD3, PSR(regulation), FIDA | 전자금융거래법, 신용정보법 | 銀行法 + 가이드라인 |
| 표준 | FDX (사실상) | RTS, FAPI 2.0 | 금융결제원 OAS | 全銀協 API ガイドライン |
| TPP 라이선스 | 단일 없음. 주별 | AISP/PISP (단일 PSP) | 전자금융업·마이데이터 | 전자결제등 대행업 |
| 데이터 범위 | 결제·계좌·신용카드 | 결제·계좌 + (FIDA) 보험·연금·투자 | 은행·카드·증권·보험·통신·공공 | 결제·계좌 (확장 중) |
| SCA/MFA | 없음 (시장 자율) | 의무, RTS 다이내믹 링크 | 의무, 통합인증 2.0 | 의무, 가이드라인 |
| 사기 책임 | 카드 chargeback 등 | 명시적 분담 규칙 | 분쟁조정 + 책임분담 가이드 | 책임분담 권장 |
| 데이터 수수료 | 무료 (1033) | FIDA 합리적 수수료 가능 | 무료 (오픈뱅킹) | 무료-저렴 |
| 감독 | CFPB, OCC | EBA, EIOPA, 국가 감독청 | 금융위·금감원·금융결제원 | JFSA, 全銀協 |
| 데이터 보호 | GLBA, CCPA, 1033 | GDPR + PSD3 | 개인정보보호법·신용정보법 | 個人情報保護法 |
24장 · 운영 체크리스트 — TPP·핀테크가 출시하기 전에
마지막으로 실무 체크리스트.
- 라이선스 확보: 운영 국가의 TPP 라이선스(또는 EU 패스포팅 활용).
- eIDAS 인증서: QSeal/QWAC 발급 — Buypass, Globalsign, Sectigo 등.
- 샌드박스 통과: 각 ASPSP의 샌드박스에서 conformance.
- FAPI 2.0 호환: PAR + DPoP + mTLS 또는 private_key_jwt.
- SCA UX: 다이내믹 링크와 90일 재인증의 매끄러운 흐름.
- 모니터링: API 가용성·지연·에러 분포.
- 토큰 보안: KMS·HSM 기반 비밀키 보관.
- 데이터 최소화: 동의 범위 내 최소 데이터만 저장.
- 카테고라이제이션 품질: 분류 정확도와 편향 모니터링.
- 사기 탐지: device fingerprint·behavior·graph 결합.
- 규제 보고: 사기 손실·다운타임·민원 보고 양식.
- 소비자 권리: 동의 철회·데이터 삭제 자동화 흐름.
- 재해 복구: ASPSP 다운·자체 다운에 대한 fallback.
- 벤더 거버넌스: 애그리게이터·KMS·인증 서버 SLA·테스트 결과.
이 14개가 2026년의 표준이다. 핵심은 오픈뱅킹의 핵심 가치(연결·동의·표준화)가 핀테크의 속도·기술과 결합되는 것이다. PSD3·FIDA·1033조·마이데이터·全銀協이 만드는 규제 격자 위에서, Plaid·TrueLayer·Tink·Yapily·Belvo·Salt Edge·Finicity·MX·Akoya·금융결제원·마네ーフォワード가 인프라를 만든다. 사용자는 한 번의 동의로 자기 금융 라이프 전체를 본다.
References
- Plaid — https://plaid.com/
- TrueLayer — https://truelayer.com/
- Tink (Visa) — https://tink.com/
- Yapily — https://www.yapily.com/
- Belvo — https://belvo.com/
- Salt Edge — https://www.saltedge.com/
- Finicity (Mastercard) — https://www.finicity.com/
- MX — https://www.mx.com/
- Akoya — https://akoya.com/
- 금융결제원 (KFTC) 오픈뱅킹 — https://www.kftc.or.kr/
- 마이데이터 종합포털 — https://www.mydatacenter.or.kr/
- 신용정보원 — https://www.kcredit.or.kr/
- 금융위원회 — https://www.fsc.go.kr/
- 금융감독원 — https://www.fss.or.kr/
- 全銀協(全国銀行協会) — https://www.zenginkyo.or.jp/
- 日本金融庁(JFSA) — https://www.fsa.go.jp/
- EBA Open Banking — https://www.eba.europa.eu/
- EIOPA — https://www.eiopa.europa.eu/
- ESMA — https://www.esma.europa.eu/
- CFPB 1033 Rule — https://www.consumerfinance.gov/rules-policy/final-rules/personal-financial-data-rights/
- FDX (Financial Data Exchange) — https://financialdataexchange.org/
- OpenID FAPI 2.0 — https://openid.net/specs/fapi-2_0-security-profile.html
- Sahamati (India AA) — https://sahamati.org.in/
- マネーフォワード — https://moneyforward.com/
- freee — https://www.freee.co.jp/