레저 투 레저(L2L)

은행의 커뮤니케이션 서버, 미들 레이어 서버, 코어/결제 서버 및 원장/계좌 서버 간의 주요 차이점

은행 기술에서 서버는 금융 거래의 원활한 처리와 기록 관리를 보장하는 데 결정적인 역할을 합니다. 은행이 의존하는 서버의 주요 유형은 통신 서버와 원장/계좌 서버의 두 가지입니다. 두 서버 모두 필수적이지만, 각기 다른 목적을 수행하며 서로 다른 유형의 데이터를 처리합니다.

통신 서버

통신 서버는 은행 및 금융기관 간 안전한 데이터 교환의 중추입니다. 통신 서버의 주요 기능과 특징은 다음과 같습니다.

1. 보안 데이터 교환: 이러한 서버는 보안 데이터 교환을 지원하여, 민감한 금융 정보가 기관 간에 안전하게 전송될 수 있도록 합니다.
2. 프로토콜 및 표준: 은행 간 통신에는 SWIFT, SEPA 또는 ACH 등의 표준화된 프로토콜을 활용하여 서로 다른 플랫폼 간에도 일관성과 신뢰성을 확보합니다.
3. 암호화 및 인증: 보안을 유지하기 위해 통신 서버는 고도의 암호화 방식과 엄격한 인증 절차를 적용하여 전송 중인 데이터를 보호합니다.
4. 거래 처리: 이들은 주로 거래 요청, 메시지 및 지시를 처리하며, 거래에 필요한 정보를 전달하는 중개자 역할을 수행합니다.
5. 자금 이동 없음: 중요한 점은 이 서버들이 자금을 이동하거나 계좌 잔액을 직접 갱신하지 않으며, 그러한 조치에 필요한 통신만을 지원한다는 것입니다.

코어뱅킹 서버

코어 뱅킹 서버는 금융기관의 디지털 중추로서, 금전 거래의 정확한 실행, 검증 및 결제를 총괄합니다. 이 서버는 수신된 거래 지시(예: SWIFT 메시지)를 안전하게 처리하고, 상세한 고객 계좌 및 내부 계좌를 유지하며, 환거래 은행 및 중개 은행이 확인한 실제 자금 결제 내역과 이들 거래를 대사하고, 그에 따라 고객 잔액을 정확하게 갱신합니다.

핵심 서버는 단순한 거래 처리 기능을 넘어 규제 준수를 관리하고, 자동화된 대사 및 AML/KYC 검증을 수행하며, 리스크 관리 절차를 확보하고, 완전한 감사 추적 기록을 생성함으로써 기관의 은행 업무 전반에 걸쳐 운영의 무결성, 재무의 정확성 및 규제 준수를 보장합니다.

원장/계정 서버

한편 원장/계정 서버는 은행의 금융 기록을 보관하는 수탁 시스템입니다. 그 주요 특징은 다음과 같습니다.

1. 금융 기록 유지: 이 서버는 은행의 핵심 금융 기록을 저장 및 관리하여 모든 거래가 정확하게 기록되도록 합니다.
2. 거래 기록: 차변과 대변을 포함한 모든 거래를 기록하며, 현재 계좌 잔액을 갱신하고 보관할 책임을 집니다.
3. 총계정원장 관리: 원장 서버는 은행의 총계정원장과 개별 고객 계좌를 관리하여 재무 건전성에 대한 전체적인 조망을 제공합니다.
4. 데이터 무결성: 이러한 기록은 정확한 재무 보고 및 컴플라이언스에 필수적이므로 데이터의 일관성과 무결성을 확보하는 것이 중요합니다.
5. 강력한 보안 조치: 원장 서버는 데이터의 민감성을 고려하여 추가적인 암호화 계층과 엄격한 접근 통제를 포함한 보다 강화된 보안 조치를 적용하는 것이 일반적입니다.

통신 서버는 거래를 개시하고 처리를 지원하지만, 원장 서버는 검증을 거친 후 해당 거래를 은행 장부에 최종적으로 기록하고 반영합니다.

현대 은행 시스템에서는 이러한 기능이 통합되어 운영되는 경우가 많으며, 보안이 확보된 은행 내부 통신 프로토콜이 원장 관리 시스템과 연동하여 작동합니다. 이러한 통합은 은행 전체 금융 생태계에 걸쳐 실시간 업데이트와 일관성을 보장하여 효율성과 보안을 모두 강화합니다.

은행업에서 원장 조정으로서의 거래

통화를 한 계좌에서 다른 계좌로 이체하는 등의 금융 거래가 발생할 때 실물 화폐는 이동하지 않습니다. 대신 거래는 환거래 은행, 중앙은행 또는 RTP 청산 시스템의 각 계좌에 대한 원장 기재를 조정함으로써 실행됩니다. 은행 시스템은 한 계좌의 잔액을 줄이고 다른 계좌의 잔액을 늘려, 별도로 결제될 가치의 이전을 반영합니다.

대사 및 최종 결제: 관련 은행들은 거래의 정확성을 확인하기 위해 대사 절차를 수행합니다. 중개 은행이 개입하는 경우, 각 은행은 환거래 은행 관계를 통해 자신이 담당하는 부분을 결제합니다.

보고 및 기록 보관: 은행은 컴플라이언스, 감사 및 보고 목적으로 모든 거래 기록을 보관합니다.

코어 뱅킹 시스템(CBS)의 작동 방식

I. 핵심적 구분: 지시와 실제 결제

pacs.008(고객 이체) 또는 pacs.009(금융기관 이체)와 같은 SWIFT 메시지는 본질적으로 보안이 확보된 통신 또는 지시입니다. 이는 수취 은행에 자금이 입금될 예정임을 알리고 수취인 정보, 거래 금액 및 라우팅 지시를 명시하지만, 그 자체로 자금을 이전하는 것은 아닙니다. 실제 자금 이전은 지시된 금액이 환거래 은행 또는 중개 은행이 관여하는 은행 간 결제 체계를 통해 결제되고, 각 해당 기관의 계좌 잔액에 실제 변동이 발생함으로써 확인될 때에만 이루어집니다.

II. 환거래 은행 및 중개 은행의 정의와 역할

A. 환거래 은행

• 환거래 은행은 다른 은행과 직접적인 쌍방 계좌(노스트로/보스트로 계좌)를 유지합니다.
• 이 계좌는 다른 금융기관에 보유한 실제 현금 잔액을 반영하며, 국경 간 지급 및 결제를 지원합니다.

B. 중개 은행

• 중개 은행은 송금 은행과 수취 은행 사이에 직접적인 환거래 관계가 없는 경우 지급 경로상의 경유 지점 역할을 합니다.
• 환거래 관계가 없는 은행 간의 간극을 연결하며, 통화 환전, 국제 결제 및 복잡한 라우팅을 처리합니다.

III. 코어 뱅킹 시스템이 실제 자금 수령을 확인하는 방식

코어 뱅킹 시스템은 환거래 은행 및 중개 은행 시나리오에 따라 구분하여 다음과 같이 강력한 대사 및 확인 절차를 운영합니다.

A. 환거래 은행을 통한 확인

거래가 직접 환거래 계좌(노스트로 계좌)와 관련되는 경우:

상세 업무 절차:

1. 지시 수신(pacs.008/pacs.009): CBS가 SWIFT 지시를 수신하여 일시적으로 저장합니다.
2. 임시 기표: 검증이 완료될 때까지 자금이 내부 가수금 또는 결제 원장에 일시적으로 표시될 수 있습니다.
3. 노스트로 명세서 대사: 수취 은행은 환거래 은행으로부터 실제 계좌 잔액과 입금 내역을 반영한 자동화된 계좌 명세서(camt.053, 구형 MT 940/950 또는 전자 API)를 수신합니다. CBS는 이 명세서를 고유 식별자(UETR – Unique End-to-End Transaction Reference)를 활용하여 SWIFT 지시 내용과 자동으로 대사합니다.
4. 최종 계좌 입금: SWIFT 지시 내용이 환거래 은행이 확인한 입금 기록과 정확히 일치함을 대조한 후에만, 코어 뱅킹 시스템(CBS)이 수취인의 고객 계좌에 자금을 확정적으로 입금합니다.

B. 중개 은행을 통한 확인

자금이 중개은행을 거치는 경우(다단계 경로), 확인 절차는 다소 복잡해집니다.

상세 업무 절차:

1. 지시 도착(pacs.008): 코어 뱅킹 시스템(CBS)이 수신된 지시 메시지를 최초로 기록합니다.
2. 중개은행 결제 확인: 중개은행을 경유하여 송금된 자금은 일반적으로 여러 건의 SWIFT 확인 메시지를 발생시키며, 여기에는 입금 통지(camt.054, 구 MT 910) 또는 자금이 후속 은행으로 이전되었음을 알리는 후속 pacs.009 메시지가 포함됩니다. 중개은행은 수취은행의 환거래 노스트로 계좌에 자금이 정상적으로 입금되었음을 확인하는 입금 통지를 발행합니다. CBS는 이러한 확인 메시지를 중개 금융기관으로부터 수신하여 단계별 대사를 수행합니다.
3. 환거래 은행의 최종 확인: 환거래 은행이 발행하는 최종 명세서(camt.053 또는 구형 MT 940/950)는 수취 은행의 노스트로 계좌로 실제 현금 결제가 이루어졌음을 확인해 줍니다.
4. 최종 고객 배정: 환거래 은행으로부터 실제 결제 확인(중개 기관 확인 이후)을 수신하여 검증한 후에야 CBS가 수취인의 계좌에 최종적으로 입금 처리합니다.

IV. 코어뱅킹 시스템에 활용되는 기술 및 시스템

• 자동 대사 소프트웨어: (예: SmartStream TLM, Temenos, Oracle FLEXCUBE)
• 실시간 모니터링 도구: 즉각적인 확인을 위한 API 연동 및 디지털 은행 거래내역서.
• 메시징 게이트웨이: SWIFT Alliance Access, SWIFT gpi 추적 서비스를 통해 거래 상태를 실시간으로 확인합니다.
• 고유 거래 참조번호(UETR): SWIFT가 의무화한 것으로, 지급 전 과정에 걸쳐 각 메시지를 고유하게 식별할 수 있도록 보장합니다.
• 이중 계층 대사 점검. 자동화된 전자 대사에 전담 운영 팀의 수작업 검증을 병행합니다.
• AML/KYC 및 컴플라이언스 통제. 모든 지급 지시는 입금 처리에 앞서 심사 및 검증되며, 이를 통해 규제상의 의무(FATF, AML 지침, OFAC, EU/UN 제재)를 준수합니다.
• 감사 추적 및 보고. 규제 준수 및 감사를 위해 전자 감사 추적 기록 전체를 유지합니다.

코어 뱅킹 시스템은 단순한 SWIFT 지시 메시지의 수신을 자금 결제의 증거로 신뢰하지 않습니다. 대신 환거래 은행(노스트로 계좌를 보유한 최종 청산 기관)과 중개 은행(입금 통지 또는 후속 확인을 통해 후속 이체를 확인하는 거래 경로 지정 은행) 양측으로부터 수신한 확정 명세서와의 대사를 통해 실제 자금 이동을 체계적으로 검증합니다.

환거래 은행 수준에서 실제 금전 잔액이 변동하고 중개은행과 환거래 은행 양측의 은행 명세서에 확정된 입금이 나타난 경우에 한하여 CBS가 비로소 해당 자금을 수취인 고객의 계좌에 확정적으로 인식하고 배분하며, 이로써 지급 지시와 실제 현금 결제 간의 정확한 구분이 보장됩니다.

은행 및 중앙은행에서의 장부 외 자금의 장부 내 자금 전환

장부 외 자금을 장부 내 자금으로 전환하는 것은 기존에 공식 대차대조표에 기록되지 않던 금융 활동을 주 회계 시스템에 통합하는 것을 의미합니다. 이는 정확한 재무 보고, 투명성 및 규제 준수를 위해 필수적입니다. 아래에서는 상업은행과 중앙은행 모두에 대해 식별, 검증, 대사, 기록 및 감사를 포함하여 이 절차를 상세히 설명합니다.

A. 상업은행

1. 부외 자금의 식별

장부 외 자금의 출처:

• 특수목적법인(SPE): 증권화 등 특정 거래를 위하여 설립되어 은행 본체의 재무상태표 밖에서 자산과 부채를 보유할 수 있는 법인입니다. 여기에는 구조화투자회사(SIV)와 컨듀잇이 포함될 수 있습니다.
• 유동화 자산: 투자자에게 매각되었으나 은행이 계속 관리하는 대출 또는 채권입니다. 주택저당증권(MBS)과 자산유동화증권(ABS)이 대표적인 예입니다.
• 리스 의무: 종전 회계기준에서는 자본화되지 않았으나 IFRS 16과 같은 신규 기준에 따라 포함이 요구되는 운용리스.
• 파생상품 및 우발부채: 스왑, 선물, 옵션 등의 금융상품과 보증 및 신용장에서 발생하는 잠재적 부채입니다.

2. 검증 및 확인

확인 절차:

• 금융 상품 평가: 부외 항목의 성격, 위험 및 가치를 판단하기 위한 상세 분석.
• 평가 모형: 현금흐름할인(DCF) 분석, 시가평가(MTM) 및 기타 금융 모형을 활용하여 파생상품 및 유동화 자산의 공정가치를 평가합니다.
• 신용 위험 분석: 부외거래(OBS)에 관련된 기초자산 및 거래상대방의 신용도를 평가합니다.
• 규제 검토: 관련 회계 기준 및 규제 기준의 준수 여부를 확인합니다.
• IFRS 9 및 IFRS 16: 각각 금융상품과 리스의 인식 및 측정을 규율합니다.
• 바젤 III 체계: 위험가중자산(RWA) 산출 및 레버리지 비율이 부외 익스포저의 취급에 미치는 영향.

프로토콜 및 표준:

• IFRS 및 GAAP: 정확한 재무 보고를 위해 국제회계기준(IFRS)과 일반적으로 인정된 회계원칙(GAAP)이 일관되게 적용되도록 보장합니다.
• AML 및 KYC 컴플라이언스: 불법 행위를 방지하기 위하여 자금세탁방지(AML) 및 고객확인(KYC) 요건을 준수합니다.

3. 대사 절차

대사 방법론:

• 상세 거래 검토: 부외 거래를 내부 기록과 대조하여 면밀히 검토하고 일치 여부를 확인합니다.
• 거래 단위 대사: 각 부외 항목이 대응하는 부내 계정 기재 내역에 정확히 반영되고 대사되도록 보장합니다.
• 예외 보고: 자동화된 시스템 또는 수작업 개입을 통해 불일치 사항을 식별하고 해결합니다.

도구 및 소프트웨어:

• ERP 시스템: 대사(對査) 절차를 자동화하기 위한 SAP, Oracle Financials 등의 전사적 자원 관리(Enterprise Resource Planning) 시스템.
• 전문 대사(Reconciliation) 소프트웨어: 대량 거래 매칭 및 이상 징후 탐지를 위한 BlackLine, SmartStream 등의 도구.

4. 총계정원장 기장

기장 방법:

• 분개: 모든 관련 세부 사항이 빠짐없이 반영되도록, 부외 항목을 총계정원장에 편입하기 위한 상세 분개.
• 자동 전기: 코어뱅킹 시스템을 활용하여 거래 기록을 자동화함으로써 수작업 입력 오류를 최소화합니다.
• 계열사 간 및 은행 내부 분개: 은행 그룹 내 복수의 법인이 관련된 거래에 대하여 적절한 회계 처리를 보장합니다.

프로토콜 및 표준:

• 복식부기: 회계 등식(자산 = 부채 + 자본)을 유지하기 위해 모든 거래가 최소 두 개 이상의 계정에 영향을 미치도록 하는 방식입니다.
• IFRS/GAAP 준수: 재무 보고의 투명성과 일관성을 확보하기 위해 국제 및 각국의 회계 기준을 준수합니다.

5. 감사 및 컴플라이언스

감사 절차:

• 내부 감사: 정책 및 절차의 준수와 재무보고의 정확성을 확인하기 위한 정기적인 내부 점검.
• 지속적 모니터링: 실시간 감사 시스템을 구축하여 이상 징후를 탐지하고 컴플라이언스를 지속적으로 확보합니다.
• 위험 기반 감사: 파생상품 및 특수목적법인(SPE)과 같은 고위험 영역에 집중하여 견고한 감독을 확보합니다.
• 외부 감사: 외부 감사인에 의한 독립적인 검증을 통해 회계 기준 및 규정 준수를 확보합니다.
• 감사 추적 유지: 명확한 감사 추적을 제공하기 위해 모든 거래 및 조정 내역에 대한 전체 기록을 보관합니다.

컴플라이언스 체계:

• 사베인스-옥슬리법(SOX): 기업 공시의 정확성과 무결성을 보장합니다(미국 한정).
• EU 회계감사 규정: 유럽 내 재무 보고의 정확성과 투명성을 보장합니다.

프로토콜 및 기술:

• 규제 보고 도구: 규제 보고서 작성 및 제출에 사용되는 AxiomSL, Wolters Kluwer 등의 소프트웨어
• 블록체인 및 DLT: 분산원장기술(DLT)을 활용하여 금융 거래의 기록을 변경 불가능하게 유지하고 투명성을 확보합니다.

B. 중앙은행

1. 부외 자금의 식별

부외 자금의 원천:

• 외환 스왑 라인: 약정되었으나 인출되지 않은 스왑 라인 및 스왑의 선도 거래분으로, 약정 사항으로만 나타납니다.
• 우발부채: 대차대조표에 기록되지 않는 보증 및 기타 잠재적 의무.
• 수탁 보유분: 다른 중앙은행을 위해 수탁 보관하는 금과 증권으로, 수탁 기관의 대차대조표에는 계상되지 않습니다.

2. 검증 및 유효성 확인

확인 절차:

• 준비자산 평가: 외환보유액 및 기타 부외 자산의 시장가치를 평가합니다.
• 시장 가격 및 환율: 준비금을 정확하게 평가하기 위해 최신 시장 데이터를 사용합니다.
• 리스크 평가: 이러한 준비금을 보유함에 따른 신용 리스크 및 시장 리스크를 평가합니다.
• 규제 검토: IMF가 정한 기준 등 국제 기준에 대한 준수 여부를 확인합니다.
• IMF 가이드라인: 국제준비자산 및 외화유동성에 관한 IMF 데이터 템플릿을 준수합니다.

프로토콜 및 표준:

• IMF 기준: 외환보유액 및 기타 통화 통계 보고에 관한 국제통화기금 지침.
• 중앙은행 회계 기준: 중앙은행 회계 및 재무 보고에 관한 구체적인 기준과 관행.

3. 대사 절차

대사 방법론:

• 보유 자산 세부 검토: 외환보유액 및 기타 장부 외 항목의 기록을 실제 보유 내역과 대조합니다.
• 원장-실잔액 대사: 기록된 데이터가 실물 자산 또는 계좌 잔액과 일치하는지 확인합니다.
• 통화 대사: 외화 보유 잔액을 시장 환율 및 거래 내역과 정기적으로 대조합니다.

도구 및 소프트웨어:

• 중앙은행 시스템: 중앙은행의 거래 및 보유 자산을 관리하기 위한 맞춤형 소프트웨어 솔루션.
• 전문 대사 도구: 대량의 외환 거래 및 준비금을 대사하기 위해 설계된 도구입니다.

4. 총계정원장 기장

기록 방법:

• 분개: 부외 항목을 총계정원장에 반영하기 위한 상세 분개.
• 자동화 시스템: 중앙은행 시스템을 활용하여 총계정원장의 기록 및 갱신을 자동화합니다.
• 다중 통화 회계: 여러 통화로 이루어지는 거래와 보유 자산에 대한 정확한 회계 처리를 보장합니다.

프로토콜 및 표준:

• 복식부기: 복식부기를 통해 균형 잡힌 재무 기록을 유지합니다.
• IMF 및 중앙은행 기준: 국제 지침 및 개별 중앙은행의 회계 기준 준수.

5. 감사 및 컴플라이언스

감사 절차:

• 내부 감사: 중앙은행 내 정확성과 정책 준수를 확인하기 위한 정기 검토.
• 실시간 모니터링: 지속적인 모니터링과 실시간 감사 기능을 위한 시스템을 구축합니다.
• 리스크 기반 접근법: 외환보유액 및 우발채무와 같이 중대한 리스크 노출이 있는 영역에 중점을 둡니다.
• 외부 감사: 국제 기준 준수 및 보고의 투명성을 확보하기 위한 독립 감사.
• 완전한 문서화: 감사 목적을 위해 모든 거래 및 조정 내역에 대한 상세한 기록을 유지합니다.

컴플라이언스 체계:

• IMF 지침: 국제 준비자산 및 외화 유동성 보고의 투명성과 정확성을 보장합니다.
• 중앙은행 규정: 중앙은행 자체를 규율하는 법정 규칙 및 회계 규칙의 준수.

프로토콜 및 기술:

• 블록체인 및 분산원장기술(DLT): 불변 기록과 분산원장기술을 통한 투명성 및 정확성 제고.
• 규제 보고 도구: 정확하고 적시에 규제 보고서를 작성하고 제출할 수 있도록 지원합니다.

요약
장부 외 자금을 장부 내 자금으로 전환하는 과정은 식별, 검증, 대사, 기록 및 감사를 면밀히 수행해야 하는 세부적이고 다면적인 절차입니다. 시중은행과 중앙은행 모두 재무제표의 정확성, 투명성 및 규제 준수를 보장하기 위해 엄격한 기준과 프로토콜을 준수해야 합니다. 이러한 기관은 첨단 도구를 활용하고 국제 기준을 준수함으로써 부외 항목을 주요 회계 체계에 효과적으로 통합하여 재무 보고의 무결성을 확보할 수 있습니다.

IFB – 인터레저 프로토콜(ILP) 게이트웨이 및 보완적 지급 결제망

목적 및 위상

ILP는 IFB 크로스 원장 전략의 핵심입니다. ILP는 메시징 단계에서 수 초 내에 완결되는 조건부 암호화 결속 이체를 제공하며, 당행의 DMZ 커넥터와 핵심 ISO 20022 원장 간의 분리 원칙을 준수합니다. 그러나 오늘날의 결제 환경은 다양한 방식이 공존합니다. 고객은 특정 송금 경로, 유동성 특성 또는 규제 관할권에 최적화된 결제망을 필요로 할 수 있습니다. 이하에서는 고객이 준수하여야 하는 ILP 사양과 함께, 주요 대체 결제망 및 각각에 대한 건전성 또는 기술적 근거를 설명합니다.

1 Interledger Protocol – 표준 명세서

• 커넥터 계층 – 강화된 미들 계층에서 Rafiki v 1.3 이상 또는 Interledger.rs를 사용하며, 외부 트래픽은 TLS 1.3 상의 BTP/STREAM으로 처리하고, 내부에서는 ISO 20022 PACS.008/009로 변환합니다. 이 구성은 NIST SP 800-53 Rev 5의 SC-7 “경계 보호(Boundary Protection)” 통제 항목을 따릅니다.
• 자격 증명 위생 관리 – 토큰화된 BTP 자격 증명은 OWASP Application Security Verification Standard의 자격 증명 관리 요건에 따라 90일마다 교체되며 24시간 이내에 폐기할 수 있습니다.
• 경로 입증 테스트 – 0.01 EUR 소액 결제 3건(왕복 지연시간 1초 이하)에 이어 1 EUR STREAM 버스트(손실률 0.5% 미만, 지연시간 750ms 미만)를 실행하여 보고 임계치를 초과하지 않고 처리 용량을 검증합니다.
• 결제 완결성 – 이행된 각 패킷은 T2(구 TARGET2) 또는 환거래 은행의 노스트로 계좌로 pacs.009 지시를 발생시키며, 취소 불가능한 확인이 도착할 때까지 수취인 계좌에 대한 입금이 보류됩니다. 이로써 CPMI-IOSCO 금융시장인프라 원칙(Basel/BIS, 2012년 4월)의 원칙 8 '결제 완결성'을 충족합니다.

2 Swift 즉시 국경 간 결제 – 기존 결제망

• 개요 – Swift는 국내 즉시결제 체계를 국경 간 지급에 연결하며, 양측 국내 체계가 이를 지원하는 경우 ISO 20022 pacs.008 메시지를 사용하여 수취인에게 수 초 내에 입금될 수 있도록 합니다.
• IFB가 이를 활용하는 이유 – 기존 환거래 계좌를 기반으로 하여 새로운 토큰 인프라가 필요하지 않으며, 전 세계 은행을 포괄합니다.
• 규제상 이점 – 결제가 여전히 전통적인 RTGS 인프라에서 이루어지므로, 자본 및 유동성 처리는 ILP의 조건부 에스크로 관련 세부 사항 없이 바젤 III(Basel III)의 확립된 체계를 따릅니다.

3 SEPA 즉시 이체 – 범유럽 유로 결제망

• 개요 – 유럽결제위원회(European Payments Council)의 SCT Inst 제도는 유로 계좌이체 자금을 연중무휴 24시간 10초 이내에 수취인이 이용할 수 있도록 합니다. 2025년 규칙집(2025년 10월) 이후 해당 제도는 더 이상 최대 금액을 정하지 않으며, 각 결제서비스제공자(PSP)가 자체 한도를 설정합니다.
• 중요한 이유 – 유로화 단일 통화 구간에서는 SEPA Instant를 이용하면 환율 스프레드가 발생하지 않으며, TARGET Instant Payment Settlement(TIPS) 또는 기타 청산 메커니즘을 통해 중앙은행 화폐로 결제됩니다.
• 규제상의 강점 – 즉시결제 규정(Instant Payments Regulation, (EU) 2024/886)에 따라 유로 지역의 결제서비스제공자(PSP)는 즉시 결제를 송금하고 수취해야 하며, 이에 대해 일반 계좌이체보다 높은 수수료를 부과해서는 안 됩니다.

4 RTGS.global – 원자적 동시결제(Payment-versus-Payment, PvP) 네트워크

• 개요 – RTGS.global은 참여 은행 간 다통화 국제 결제를 지급 대 지급(PvP) 방식으로 동시 결제하는 네트워크를 구축하고 있습니다.
• 중요한 이유 – PvP는 외환 결제에서 원금 리스크를 제거합니다. ILP는 이행 후에도 여전히 노스트로 대사가 필요한 반면, RTGS.global은 양측 거래를 단일 원자적 지시로 결합합니다.
• 규제상의 이점 – PvP 결제는 외환 결제 리스크에 관한 바젤위원회의 감독 지침이 실행 가능한 모든 경우에 권고하는 방식입니다.

5 Ripple Payments(구 RippleNet) – API 기반 원장 브리지

• 개요 – Ripple Payments는 참여 금융기관 간의 메시징, 외환 시세 제시 및 결제 조율을 제공하며, 유동성 확보를 위하여 XRP 또는 스테이블코인을 선택적으로 활용할 수 있습니다.
• 중요한 이유 – 일부 거래 상대방은 이미 Ripple 네트워크를 통해 운영되고 있으므로, 해당 네트워크에 연결하면 중복 연동을 피할 수 있습니다.
• 규제 유의사항 – 결제에 암호자산이 사용되는 경우, 지급 규제에 더하여 각 관할권의 암호자산 관련 규정이 적용됩니다.

6 Mojaloop – 포용적 즉시결제 시스템(IIPS)

• 개요 – Mojaloop은 상호운용이 가능한 소액 모바일 결제를 위한 오픈소스 참조 모델입니다. 내부적으로 ILP를 채택하고 있으며, 금융 포용을 목적으로 설계된 디렉터리 및 견적 서비스를 추가로 제공합니다.
• 중요한 이유 – 소액 송금을 환거래 은행 수수료 없이 Mojaloop 기반 국가별 결제 체계 간에 전달할 수 있습니다.
• 정책적 배경 – 금융 서비스 접근성에 관한 유엔 지속가능발전목표 세부목표 8.10을 뒷받침합니다.

로드맵으로 제시된 7가지 가능성

• 도매 CBDC PvP 회랑 – 중앙은행이 시험 중인 다중 CBDC 플랫폼은 중앙은행 화폐 기반의 DvP 및 PvP 원자적 결제를 제공할 수 있습니다.
• 토큰화 예금 네트워크 – Swift의 공유 원장(2026년 7월부터 시범 운영) 및 Regulated Liability Network와 같은 프로젝트는 공유 원장상의 토큰으로서의 은행 예금을 탐구하며, 최종 결제는 기존 시스템을 통해 이루어집니다.

8 의사결정 매트릭스 – 언제 어떤 결제망을 사용할 것인가

• 다중 자산 스트리밍, 소액결제 또는 프로그래밍 가능한 조건부 결제가 최우선 과제인 경우 ILP를 선택하십시오.
• 최소한의 연동 부담으로 전 세계 은행에 도달하려면 Swift 즉시 국경 간 지급을 선택하십시오.
• ECB의 감독 하에 유로화만 사용하는 구간에는 SEPA Instant를 선택하십시오.
• 이사회가 양자 간 동시결제(PvP) 리스크 제거를 최우선 과제로 삼는 경우 RTGS.global을 선택하십시오.
• 거래 상대방이 이미 Ripple의 네트워크를 이용하고 있는 경우에는 Ripple Payments를 선택하십시오.
• 신흥 시장에서 소액 및 금융 포용 지향의 송금에는 Mojaloop를 선택하십시오.

9 결론
IFB는 ILP를 보완하여 Swift 즉시 결제, SEPA Instant, RTGS.global, Ripple Payments 및 Mojaloop과, 장기적으로는 CBDC 및 토큰화 예금 결제망까지 갖춤으로써 고객에게 엄격한 거버넌스 체계 아래 운영되는 다양한 경로를 제공합니다. 각 결제망은 명확한 건전성 기준에 부합하도록 구성되어 있어, 고객께서 어떠한 경로를 선택하시더라도 기반 결제 메커니즘은 글로벌 규제 원칙 및 IFB 자체의 운영 복원력 확보 의지와 합치됩니다.

IFB의 프로토콜(ILP) 연결성 – 사양, 거버넌스 및 전략적 근거

1 핵심 개요

IFB는 외부 지급 네트워크와 당행 내부의 ISO 20022 결제 인프라 사이를 잇는 준실시간 연결 수단으로 Interledger Protocol(ILP)을 도입하였습니다. ILP는 코어 뱅킹 원장이 아닌 중간 계층의 커넥터에서 종결되는 조건부 암호화 검증 이전을 가능하게 하여 네트워크 분리를 유지하며, 법적 결제는 아래에 설명된 결제 인프라를 통해 이어집니다. 다음 사양은 ILP의 구현 방식, 각 통제 수단이 존재하는 이유, 그리고 해당 요건의 근거가 되는 법적 또는 건전성 규제상의 수단을 체계적으로 정리한 것입니다.

2 네트워크 아키텍처 및 분리

• 3계층 토폴로지. ILP 트래픽은 비무장 중간 계층(DMZ)에 배치된 강화형 커넥터를 통해서만 수신됩니다. 이 커넥터는 외부와는 TLS 1.3 기반의 BTP/STREAM으로 통신하며, 이행이 완료된 각 패킷을 ISO 20022 pacs.008 또는 pacs.009 메시지로 변환하여 내부 통합 버스를 거쳐 코어 원장으로 전달합니다. 코어 원장 VLAN에는 어떠한 ILP 소켓도 허용되지 않습니다. 그 이유는 무엇입니까? 이 설계는 NIST SP 800-53 Rev 5의 통제 항목 SC-7 '경계 보호'와 PCI DSS의 네트워크 분리 요건을 따르고 있습니다.
• 커넥터 스택. IFB는 Rafiki v 1.3 이상(자체 BTP 구현을 포함)을 표준으로 채택하고 있습니다. Interledger.rs는 승인된 동등 대체 수단으로 유지됩니다. 공급망 위험과 유지보수가 중단된 의존성을 방지하기 위해 ilp-plugin-btp와 같은 사용 중단 라이브러리의 사용은 금지됩니다.
• 전송 구간 보안. 모든 외부 연결에는 완전 순방향 비밀성(Perfect Forward Secrecy)을 갖춘 TLS 1.3이 적용되며, 암호 스위트는 독일 연방정보보안청이 승인한 항목(BSI TR-02102-2, 2025년판)으로 제한됩니다.

3 연결 방식 및 인증 정보 관리

• 선호 방식 – Open Payments / HTTPS 결제 포인터(Payment Pointer). 수취인은 ILDCP 규격에 부합하는 JSON(ILP 주소, assetCode, assetScale, STREAM 자격 증명)을 반환하는 공개 엔드포인트(/.well-known/pay/*)를 게시합니다. 탐색은 자동으로 이루어지며 스스로 문서화됩니다.
• 대체 모드 – 정적 BTP 피어링. 정적 인증 정보는 PGP로 암호화된 채널을 통해 교환되며, 90일마다 갱신되고, 24시간 이내에 폐기할 수 있어야 합니다.
• 속도 제한. 커넥터는 인바운드 요청을 분당 500패킷으로 제한하며, 초과 시 HTTP 429를 반환합니다. 그 이유는 무엇입니까? 이는 ISO/IEC 27002:2022 및 OWASP 애플리케이션 보안 검증 표준(Application Security Verification Standard)의 모니터링 및 오남용 탐지 통제를 뒷받침하기 위함입니다.

4 경로 증명 검증

상업적 거래가 허용되기에 앞서, 거래 상대방은 다음을 이행하여야 합니다.

1. €0.01 소액결제를 세 건 실행하며, 각 건은 1000ms 이내에 이행되어야 합니다.
2. €1의 처리량 버스트를 발생시킵니다(STREAM을 통해 분할 처리). 패킷 손실은 0.5% 미만, 평균 왕복 지연 시간은 750ms 미만이어야 합니다.
3. BTP 토큰을 교체하고 1단계를 반복하여 자격 증명 교체를 입증하십시오.

그 이유는 무엇일까요? 소액 결제는 규제상 보고 기준을 넘지 않으면서 STREAM의 조건부 에스크로 로직을 작동시키고, 토큰 롤오버는 OWASP 및 ISO 27002가 요구하는 자격 증명 수명 주기 통제를 검증하기 때문입니다.

5 결제 완결성 및 건전성 컴플라이언스

• 조건부 이행과 법적 결제의 구분. ILP 이행은 패킷을 해제하지만, 법적 결제 완결성은 금융시장인프라(FMI)가 취소 불가능하게 결제한 때에만 발생합니다. 따라서 이행된 각 패킷은 T2(EUR) 또는 승인된 환거래 노스트로 계좌로 전송되는 ISO 20022 PACS.009 금융기관 간 지시를 발생시킵니다. 코어 원장은 T2 또는 노스트로 계좌에서의 결제가 확인된 후에만 수취인에게 입금 처리합니다. 이러한 이중 단계 모델은 CPMI-IOSCO 금융시장인프라 원칙(2012년 4월) 중 원칙 8 "결제 완결성" 및 Basel III 운영 리스크 체계(최종안, 2017년 12월)를 준수합니다.
• 결제 실패 처리. 결제 확정성이 결제일(T+0)에 확보되지 못할 경우 ILP 에스크로는 자동으로 환원되며, 해당 사건은 Basel III 운영리스크 지침에 따라 기록됩니다. 예외 보고서는 최고리스크책임자(CRO)에게 상신됩니다.

6 컴플라이언스 및 모니터링 통제

• KYC/KYB 및 제재 대상 심사. 거래 상대방은 온보딩에 앞서 완전한 KYC/KYB 서류 일체, 최종 실소유자 구조도 및 최신 자금 증명을 제출합니다. 모든 ILP 목적지 태그는 EU 제재 규정, 규정(EU) 2024/1624(EU 자금세탁방지 규정) 및 2025년 6월에 개정된 FATF 권고 16에 따라 EU 이사회 통합 금융제재 목록 및 OFAC SDN 목록과 대조하여 실시간으로 심사됩니다.
• AML 거래 모니터링. ILP 패킷 흐름은 이상 징후 탐지 엔진에 입력되며, 의심스러운 패턴은 상위 보고 절차에 따라 처리되고 필요한 경우 관할 금융정보분석기구에 지체 없이 보고됩니다. 또한 규정(EU) 2023/1113(자금이체 규정)이 요구하는 바에 따라 송금인 및 수취인 정보가 각 이체와 함께 전달됩니다.
• 디지털 운영 복원력. 커넥터 계층은 EU DORA(규정 (EU) 2022/2554)의 기준에 따라 핵심 ICT 구성요소로 취급됩니다. 연 1회의 침투 테스트, 분기별 취약점 점검 및 DORA에 부합하는 기한 내 사고 통지가 의무화되어 있습니다.
• 로그 보존. 모든 ILP 패킷 로그, ISO 20022 메시지 및 컴플라이언스 증빙 자료는 ISO/IEC 27001에 부합하는 기록 보존 관행에 따라 7년간 보존됩니다.

7 보안 및 기밀 유지 조항 (통합)

전송 구간은 TLS 1.3으로 암호화되며, BTP 토큰은 AES-256으로 암호화되어 저장됩니다. 침해 사고 통지 기한은 24시간입니다. 본 통합 조항은 이전 초안에 중복되어 있던 모든 "보안 및 기밀 유지" 관련 문구를 대체하며, 거버넌스를 단순화하고 향후 개정을 용이하게 합니다.

8 계약상 이정표 및 단계별 자금 집행

• 검증이 성공적으로 완료되면 양 당사자는 준비 완료 확인서와 기본 서비스 계약서(결제 기간 24시간, 분쟁 제기 기간 48시간)에 서명합니다.
• 최초 트랑슈: 상업 조건표에 명시된 금액(예: EUR 100 000)이 검증된 ILP 채널을 통해 집행됩니다.
• 분기별 재검증과 연간 침투 테스트를 통해 지속적인 기술적 무결성을 유지합니다.

9 전략적 성과

IFB는 ILP를 분리된 중간 계층에 배치하고, 최신 커넥터 도구를 채택하며, 엄격한 자격 증명 관리 원칙을 적용하고, 각 절차 단계를 공신력 있는 기준(NIST SP 800-53, ISO 27002, CPMI-IOSCO PFMI, Basel III, DORA, FATF 16 및 EU 제재 관련 법령)에 연계함으로써, 최첨단 수준이면서 동시에 규제를 준수하고 운영 복원력을 갖춘 원장 간 이체 역량을 고객에게 제공합니다. 메시지는 거의 실시간으로 처리되며, 결제는 규제를 받는 결제망에 기반을 두고 이루어집니다. 요컨대 IFB의 ILP는 신속성과 확실성을 결합하여, 글로벌 은행 규제의 원칙에 충실하면서 혁신의 속도에 맞춰 가치를 전달합니다.

대체적 또는 과거 방식의 이체 수단과 관련된 용어는 은행 인프라의 맥락 안에서 해석되어야 합니다. 이러한 용어는 통신 채널, 내부 처리 방식 또는 과거의 관행을 설명할 수는 있으나, 규제를 받는 기관, 공인된 결제 시스템 및 정식 결제 절차에 대한 요건을 대체하지 않습니다.

용어와 관계없이 모든 이전은 궁극적으로 확립된 금융 시스템 내에서 처리, 청산 및 대사되어야 합니다.

당행에 개설된 고객님의 계좌로 자금을 이체하는 방법에 대해 더 자세히 알고 싶으시면 Marie Mayer에게 문의해 주십시오.