EU Open Banking MCP

자체 호스팅, 읽기 전용 MCP 서버입니다. Enable Banking을 통해 개인 유럽 은행 계좌에 접근하며, Cloudflare Workers에서 보안 처리되고 배포됩니다.

[!IMPORTANT] 모든 배포를 개인 금융 시스템으로 취급하세요. 이 저장소는 오픈소스이지만, 여러분의 Worker, MCP URL, 비밀 값, 세션 ID, 계좌 ID, 금융 데이터는 비공개입니다.

존재 이유

ChatGPT Finances는 어시스턴트가 실제 잔액과 거래를 바탕으로 추론할 때 무엇이 가능해지는지 보여줍니다. 이 기능의 계좌 연결은 Plaid가 제공하며 현재 미국에서 사용할 수 있습니다.

저는 유럽 개인 계좌에 대해 그만큼 직접적이고 자체 호스팅이 가능한 경로를 찾지 못해 이 프로젝트를 만들었습니다. 유럽에는 오픈 뱅킹이 있지만, 개인은 여전히 프로덕션 온보딩과 API가 제각각인 규제 제공업체를 통해서만 은행 데이터에 접근할 수 있습니다. Plaid가 공개한 MCP 서버들은 개발자 도구와 프로덕션 진단에 유용하지만, 개인의 잔액과 거래를 개인금융 MCP 도구로 노출하지는 않습니다.

이 프로젝트는 그 좁은 격차를 메웁니다. 한 사람이 비공개 MCP 하나를 배포하고, 자신의 은행 계좌만 인가하며, 선택한 MCP 클라이언트가 제한된 읽기 전용 분석을 수행하도록 하는 것입니다. 이는 호스팅형 금융 상품이나 다중 사용자 집계기가 아닌, 개인 사용을 위한 인프라입니다.

Related MCP server: openbanking-mcp

왜 Enable Banking인가

평가한 제공자 중 Enable Banking이 자체 호스팅 개인 배포에 가장 잘 맞았습니다. Enable Banking의 제한된 프로덕션 모드는 상업 계약을 체결하기 전에 소유자 본인 계좌를 연결해 애플리케이션을 활성화할 수 있도록 명시적으로 허용하며, 개인의 비상업적 사용도 포함합니다. 그러면 애플리케이션은 연결된 계좌만 읽을 수 있습니다. Enable Banking의 restricted-production 계좌 안내를 참조하세요.

이 모델은 이 프로젝트의 보안 경계와 일치합니다:

• Enable Banking 대시보드는 계좌 허용 목록입니다.

• 은행의 인가 흐름은 취소 가능한 API 동의를 생성합니다.

• MCP는 대시보드와 은행 인가가 모두 적용된 계좌에 대해서만 고정된 읽기 작업을 노출합니다.

대시보드 연결 자체는 API 인와 다릅니다. 배포 후에도 /setup은 이용자를 은행의 동의 흐름으로 보내고, 그 결과로 생성된 Enable Banking 세션 ID를 저장합니다. 동일한 계좌가 이미 대시보드에 연결되어 있어도 이 두 번째 단계는 필요합니다.

아키텍처

flowchart LR
  C[ChatGPT, Codex, or another MCP client] --> A[Cloudflare Access]
  A -->|platform-validated ctx.access| W[Stateless MCP Worker]
  W -->|session IDs only| K[Workers KV]
  W -->|fresh RS256 JWT per call| E[Enable Banking]
  E --> B[Your bank]

• 클라이언트 → MCP: Cloudflare Access Managed OAuth, 배포 소유자로 제한됨

• MCP → Enable Banking: Worker 비밀로 저장된 개인 키로 서명된 1시간짜리 RS256 JWT

• 저장소: KV에는 보호된 설정 흐름을 통해 생성된 Enable Banking 세션 ID만 들어 있습니다

• 온라인 계좌 읽기: Worker는 연결 클라이언트 IP와 MCP 클라이언트 User-Agent를 Enable Banking의 Psu-Ip-Address 및 Psu-User-Agent 헤더로 전달합니다. 이 요청 범위의 값들은 저장되거나 기록되지 않습니다. 이를 통해 로그인한 사용자가 소유자가 직접 데이터를 요청했음을 은행에 알립니다.

Worker는 잔액, 거래, 계좌, UUID, IBAN, 인가 코드, 제공자 응답을 저장하지 않습니다. 모든 응답은 Cache-Control: no-store를 사용합니다.

도구

finance_list_accounts는 불투명하며 세션별로 지정된 accountId를 반환합니다. 단일 계좌를 대상으로 하는 도구는 해당 ID를 받아 사용하기 전에 활성 Enable Banking 세션을 대조 검증합니다. 별칭이나 수동으로 복사한 계좌 UUID는 필요하지 않습니다.

페이지네이션 nextCursor 값에는 인코딩된 연속 상태가 들어 있습니다. 이 값은 불투명하지만 기밀은 아닙니다. 같은 계좌와 같은 태그와 함께 변경 없이 그대로 반환해야 합니다. Worker는 사용하기 전에 내부 컨텍스트를 검증합니다.

모든 도구는 읽기 전용, 비파괴적, 멱등적입니다. 제공자 코드는 interim_available, booked, professional 같은 설명 값으로 정규화됩니다. 한 계좌의 여러 잔액은 서로 다른 측정값이므로 반드시 더하면 안 됩니다. 금액 계산은 정확한 십진수 연산을 사용하며 통화를 혼합하지 않습니다.

잔액 전체를 새로 고치려면 accountId 없이 finance_get_balances를 한 번 호출하세요. 이 도구가 모든 활성 세션을 스스로 검색하므로 먼저 finance_list_accounts를 호출할 필요가 없습니다. 응답은 일부 계좌가 실패해도 성공한 잔액을 유지하며, 실패 계좌에 대해서는 별도의 안전한 오류를 보고합니다. aspsp_rate_limited가 보고된 계좌는 즉시 다시 시도하지 마세요.

설치

설치 과정에는 세 가지 독립된 신뢰 관계가 있습니다: Worker가 Enable Banking에 신원을 증명하고, 은행이 Worker에게 취소 가능한 동의를 부여하며, Cloudflare Access가 MCP를 호출할 수 있는 사람을 제한합니다.

1. Cloudflare와 Enable Banking 준비

필요한 것:

• workers.dev 하위 도메인과 Zero Trust가 있는 Cloudflare 계정

• Enable Banking 제한-프로덕션(restricted-production) 애플리케이션

• 그 애플리케이션의 UUID와 RSA 개인 키

Enable Banking 애플리케이션을 등록하기 전에 Worker 이름을 정하세요. 다음 콜백 URL을 등록하고, 두 개의 자리 표시자 값을 대체하세요:

https://<worker-name>.<account-subdomain>.workers.dev/callback

프로덕션 애플리케이션을 등록하고, RSA 키를 브라우저 밖에서 생성하고, PEM 형식의 공개 인증서를 업로드합니다. 개인 키는 잊지 마세요. 배포 흐름이 이를 Worker secret으로 저장하며, 절대 커밋하거나 공유해서는 안 됩니다.

Enable Banking 제어판에서 제한된 애플리케이션이 접근할 수 있는 모든 계좌를 연결하세요. 대시보드 연결은 프로덕션용 허용 목록일 뿐이며, 애플리케이션에 대한 세션을 인가하지 않습니다. Worker는 배포 후 /setup을 통해 그 두 번째 인가를 완료합니다. Enable Banking의 linked-account 안내를 참조하세요.

이 저장소는 개인의 비상업적 사용을위한 것입니다. 배포 결과가 Enable Banking의 현재 약관을 준수하는지 확인하세요.

2. Cloudflare에 배포

위의 Deploy to Cloudflare 단추를 사용하세요. Cloudflare 배포 흐름에서 이 작업을 수행합니다:

1. 저장소를 사용자의 GitHub 또는 GitLab 계정에 복사하고

2. ENABLE_BANKING_APPLICATION_ID 및 ENABLE_BANKING_PRIVATE_KEY_PEM에 대해 묻습니다

3. SESSION_STORE KV 네임스페이스를 프로비딩합니다

4. 이 프로젝트가 요구하는 Cloudflare Access 정책을 연결

5. Workers Builds로 Worker를 구축하고 배포

두 secret 필드는 처음에는 .dev.vars.example에서 읽은 마스킹된 자리표시자 값, 즉 모두 0인 UUID와 replace-me 개인 키로 표시됩니다. 이것은 실제 사용자 이름이 아닙니다. 배포하기 전에 두 필드를 실제 애플리케이션 UUID 및 개인키로 교체하세요.

Workers는 공개될 수 있기 때문에 Cloudflare는 Access를 선택 사항으로 표시되지만, 이 프로젝트에서는 필수입니다. 배포 페이지에서 Protect with Cloudflare Access를 사용하고, All traffic을 선택하고, 인증 정책을 추가하세요. 개인 배포의 경우 정확한 본인(또는 신뢰할 수 있는 구성원만 있는 Cloudflare 계정) 만 허용하십시오. 미리보기만은 프로덕션 Worker를 보호하지 않습니다.

Cloudflare는 Deploy to Cloudflare buttons에서 이 동작을 설명합니다.

3. Managed OAuth 사용

1. Zero Trust → Access controls → Applications → 배포 중 생성된 Access 애플리케이션을 엽니다.

2. 고급 설정 열고 Managed OAuth를 사용하면 저장합니다.

배포 중 Protect with Cloudflare Access를 사용하지 않았다면 계속하기 전에 Worker 수준 Access를 수동으로 연결하세요. Access가 연결되기 전에는 Worker는 Cloudflare가 ctx.access를 제공하지 않으므로 403 access_required와 함께 닫힙니다. Worker-level Access는 Worker가 연결된 도메인의 /, /setup, /callback, /mcp를 보호합니다. Cloudflare의 Worker-level Access 안내를 참조하세요.

MCP

4. 은행 권한 부여

1. https://<your-worker>.workers.dev/setup를 엽니다.

2. 국가와 학인(개인/기업) 로그인 여부를 관련 짓고, Enable Banking의 실시간 지원 은행 목록에서 은행을 선택합니다.

3. 은행에서 access를 승인합니다. 콜백은 state를 검증하고 일회성 코드를 교환하며, 결과 세션 ID만 KV에 저장합니다.

4. 별도의 은행 로그인마다 반복합니다. 한 번의 인가로 여러 계좌가 노출될 수 있습니다.

동의가 만료되거나 취소된 경우 /setup으로돌아가 비활성 세션을 제거하고 은행을 다시 연결합니다. 연결을 제거하면 Enable Banking에 동의를 종료하도록 요청합니다. Enable Banking은 재인가 시 새 세션 및 계정 ID를 생성하며, MCP가 이를 자동으로 존재합니다.

5. MCP 클라이언트 연결

다음 MCP URL을 사용하세요:

https://<your-worker>.workers.dev/mcp

검증

를 연결하기 전에 확인합니다:

• 인증되지 않은 요청은 Access에 의해 거부됩니다.

• /setup은 이 배포에서 만든 세션만 나열합니다.

• MCP tools/list에는 위 항목 5개 호출만 있음

• finance_list_accounts는 불투명한 계정 ID를 반환하며 IBAN은 반환하지 않습니다.

• 작은 잔액과 거래 요청이 성공합니다.

• 하나의 전체 계좌 잔액 요청이 다른 계좌가 실패해도 성공한 계좌를 반환합니다.

• Cloudflare 로그에 금융 페이로드, 비밀, 인가 코드, 세션 ID가 없습니다.

의도적으로 /health 엔드포인트도 없습니다. Cloudflare Workers에는 없어도 되며, /mcp와 보호된 설정 페이지가 애플리케이션을 실질적으로 점검하는 요소입니다.

보안 속성

• 업스트림 원본 수정: 요청은 https://api.enablebanking.com으로만 전송될 수 있습니다.

• Provider 작업 수정: 설정은 계정 인증을 시작, 완료, 종료할 수 있으며, MCP 도구는 문서화된 읽기 호출만 수행합니다.

• 사용자 트리거 계정 조회는 수신 Cloudflare 요청에서 파생된 제한된 Psu-Ip-Address 및 Psu-User-Agent 값을 전달하며, 세션 검색 및 권한 부여 요청은 해당 헤더를 수신하지 않습니다.

• 계정 강제 적용: 제공된 모든 계정 ID는 활성 상태로 저장된 세션에 속해야 합니다.

• 설정 및 콜백 라우트는 Worker 수준 Access 뒤에서 동작하며, origin/state를 검증합니다.

• 권한 부여 코드는 즉시 교환되며 절대 저장되지 않습니다.

• KV는 세션 ID만 저장하며, Cloudflare가 유휴 상태 암호화를 적용합니다.

• 입력, 날짜, 페이지, 결과, 업스트림 응답 및 타임아웃에는 제한이 있습니다.

• Provider 실패는 정규화된 작업, HTTP 상태, 허용 목록의 provider 오류 코드, 제한된 Retry-After 값만 기록하며, 식별자, 요청 헤더, provider 본문 또는 금융 데이터는 절대 기록하지 않습니다.

• 결제, 범용 HTTP 도구, 금융 데이터 저장, 응답 캐싱, CORS 또는 민감한 로깅이 없습니다.

위협 모델과 공개 정책은 SECURITY.md를 참조하세요.

개발

bun run typecheck
bun run test
bun run check

테스트는 Cloudflare Workers 런타임에서 실행되며 구성, Access 실패-폐쇄 동작, 설정 인증, 세션 검색, 계정 강제, MCP 도구 스키마, Enable Banking JWT 구성, 정규화 및 제한된 응답을 다루고 있습니다.

Provider 범위

Enable Banking은 첫 번째 provider 모듈입니다. 향후 provider는 일반적인 provider HTTP 작업을 MCP 도구로 노출하는 대신 동일한 좁고 정규화된 금융 인터페이스만 노출해야 합니다. 기여는 MCP에서 읽기 전용으로 유지되어야 하며 식별자 검증 및 응답 정규화 테스트를 포함해야 합니다.