서버 간 전송(S2S)

서버 간 이체(S2S)

자금, 자산, 부채 및 자본을 각각의 노스트로 계좌에서 이전하거나 서로 다른 은행 또는 금융기관 간에 각 서버를 통해 데이터를 이전하는 절차의 일부를 말합니다. 이러한 이전은 보안 암호화 연결을 통해 이루어지며, 정보의 안전하고 효율적인 전송을 보장하기 위해 확립된 프로토콜과 표준에 의존합니다. 은행 업무에서 서버 간 이전은 여러 구성 요소로 이루어집니다.

1. 은행 간 네트워크: 금융기관은 국제은행간통신협회(SWIFT) 또는 자동결제청산소(ACH) 네트워크와 같은 은행 간 네트워크를 통해 서로 연결됩니다. 이러한 네트워크를 통해 은행은 서로 소통하고 자금 이체 및 지급과 같은 거래를 처리할 수 있습니다.
2. 프로토콜 및 표준: 서버 간 이체는 통신 및 거래 처리를 원활히 하기 위해 확립된 프로토콜과 표준에 의존합니다. 예로는 전자 데이터 교환을 위한 ISO 20022 표준과, 은행 간 금융 메시지 교환에 특정 형식을 사용하는 SWIFT 메시징 시스템이 있습니다.
3. 보안 연결: 은행은 서버 간 전송 과정에서 전달되는 민감한 정보의 기밀성과 무결성을 보호하기 위해 암호화된 보안 연결을 사용합니다. 여기에는 SSL(Secure Socket Layer) 또는 TLS(Transport Layer Security)와 같은 기술을 활용하여 보안 통신 채널을 구축하는 것이 포함됩니다.
4. 인증 및 권한 부여: 은행은 서버 간 이체에 관여하는 당사자의 신원을 확인하기 위해 강력한 인증 및 권한 부여 절차를 운영합니다. 여기에는 권한 있는 개인 또는 시스템만이 거래를 개시하거나 승인할 수 있도록 디지털 인증서, 암호화 키 또는 다중 요소 인증 방식의 사용이 포함될 수 있습니다.
5. 거래 처리: 필요한 보안 조치가 마련되면 은행 간 거래를 처리할 수 있습니다. 이는 통상 송금 은행이 이체 요청을 개시하고, 수취 은행이 해당 요청을 확인하여 수락한 뒤, 양 은행이 각자의 기록을 갱신하여 완료된 이체를 반영하는 절차로 이루어집니다.
6. 대사 및 결제: 서버 간 이체가 완료되면 은행들은 각자의 기록을 대사하고 미결 잔액을 결제합니다. 이 과정에는 원장 갱신, 거래 데이터 대사, 그리고 해당 이체와 관련된 미결 수수료 또는 비용의 정산이 포함될 수 있습니다.

S2S 전송 프로토콜

1. FIX(Financial Information eXchange): 증권 거래의 주문, 체결 및 배분을 위한 메시징 표준입니다. 거래 데이터를 전달하며, 지급 결제는 전달하지 않습니다.
2. EBICS(Electronic Banking Internet Communication Standard): 기업 고객과 거래 은행 간의 안전한 파일 교환을 위한 표준으로, 주로 독일, 프랑스, 스위스 및 오스트리아에서 사용됩니다.
3. Zengin: Zengin 시스템은 일본의 국내 은행 간 자금 이체 네트워크이며, Zengin 파일 형식은 국내 이체 및 자동이체에 사용됩니다.
4. AS2(Applicability Statement 2): 인터넷을 통해 업무 문서(EDI, XML)를 서명하여 안전하게 전송하며, 수신 확인을 제공합니다.
5. SNMPv3: 인증 및 암호화를 갖춘 네트워크 장비의 모니터링 및 관리. 인프라를 관리하는 용도이며, 거래를 전달하지는 않습니다.
6. Kerberos: 클라이언트와 서비스가 서로의 신원을 증명할 수 있도록 하는 티켓 기반 네트워크 인증 방식입니다.
7. OAuth 2.0: 제한된 접근 토큰을 통한 위임 인가 방식으로, 대부분의 오픈뱅킹 API의 기반이 됩니다.
8. SSH 기반 SFTP 및 SCP: 서버 간 암호화된 파일 전송 및 복사 방식으로, 지급 파일과 거래내역 파일에 널리 사용됩니다.

이들 프로토콜은 각각 데이터 교환 또는 시스템 접근을 보호합니다. 통화, 은행의 자산·부채 및 자본의 이전을 수반하는 S2S 거래에서 위 프로토콜은 필요하지만 금융 거래를 완결하기에는 충분하지 않습니다.

실제 자금 이체: 이러한 프로토콜은 거래 정보를 효율적으로 전송하지만 자금의 실제 이동은 처리하지 않습니다. 자금 이체를 위해서는 환거래 은행 업무, 실시간 총액결제(RTGS) 및 즉시 결제와 같은 시스템이 필수적입니다. 이들 시스템은 계좌 간에 자금을 실제로 이동시켜 금융 거래를 완결하며, 자금이 이미 노스트로-보스트로 계좌에 예치되어 있어 그곳에서 인출되어야 하는 경우는 예외입니다. 데이터 전송을 넘어, 자금의 실시간 이동을 보장하고 거래를 은행 시스템에 정확하게 반영하기 위한 실제 자금 결제가 필요합니다.

자산, 부채 및 지분의 실제 이전: 자산, 부채 및 지분 거래에서는 이러한 이전 내역을 CSD에 기록하는 것이 필수적입니다. CSD는 증권 소유권에 대한 법적 기록을 유지할 책임이 있으며, 이 과정은 최초 통신 프로토콜의 범위를 벗어납니다. 자산 및 지분의 이전은 은행의 재무제표에도 영향을 미쳐 부채, 자산 및 자본 잔액을 변동시킵니다. 관련 감독 당국에 대한 이러한 재무 보고와 필요한 컴플라이언스 사항은 프로토콜의 데이터 전송 기능을 넘어서는 것으로, 별도의 재무 및 규제 절차를 필요로 합니다.

요컨대, 프로토콜은 S2S 거래에서 정보를 안전하고 효율적으로 교환하는 데 필수적이지만, 전체 과정에는 통화, 자산, 부채 및 지분의 실제 이동, 결제, 법적 기록 및 재무 보고를 위한 추가 시스템이 수반되어, 거래 전체가 은행 규제 기준을 준수하여 이행되도록 합니다.

당행으로의 S2S 자금 이체

pacs.008이 SWIFT가 아닌 S2S 방식으로 당행에 발송된 경우 일부 컴플라이언스 우려를 완화하기 위해, 형식이 허용하는 범위 내에서 환거래 은행 간 자금 이동 구간의 pacs.009 COV에 송금 은행이 다음 추가 정보를 포함하도록 고려하실 수 있습니다:

1. 송금 의뢰인 정보: MT 103의 필드 50과 유사하게 송금 의뢰인의 세부 정보를 기재합니다. 여기에는 성명, 주소 및 계좌번호가 포함될 수 있습니다.
2. 수취인 정보: MT103의 필드 59와 같이 수취인 정보를 기재합니다. 여기에는 수취인 명칭, 주소 및 계좌번호가 포함되어야 합니다.
3. 지급 목적: 거래의 사유를 명시적으로 기재하여야 하며, 이를 통해 자금세탁방지(AML) 관련 우려를 일부 완화할 수 있습니다.
4. 규제 보고 정보: 관할권에서 요구하는 경우, 규제 보고용 코드 또는 식별자를 포함하시기 바랍니다.
5. S2S pacs.008 참조: pacs.009 COV가 S2S pacs.008과 연계되어 있음을 구체적으로 명시하면 중개 은행에 맥락을 제공할 수 있습니다.
6. 연락처 정보: 수취은행이 즉시 확인을 요청할 경우에 대비하여, 해당 지급을 담당하는 컴플라이언스 부서 또는 거래 담당자의 구체적인 연락처를 기재하십시오.
7. 특별 취급 지시 사항: 이체 자금의 식별 및 적정한 처리를 원활하게 할 수 있도록 수취 은행에 전달하는 추가 지시 사항입니다.
8. 수수료 및 비용 정보: SWIFT pacs.008이 없는 경우, 오해를 방지하기 위하여 거래 관련 수수료를 누가 부담하는지 명확히 해 두는 것이 바람직할 수 있습니다.
9. 추가 식별자: 송장 번호나 내부 거래 ID 등 pacs.009 COV를 S2S pacs.008과 연계할 수 있는 추가 거래 식별자를 기재하십시오.

컴플라이언스 관련 유의사항
pacs.009 COV에 추가 정보를 포함하더라도 컴플라이언스 리스크, 특히 통상 SWIFT pacs.008 메시지를 통해 처리되는 AML 및 CFT(테러자금조달 방지) 점검과 관련된 리스크가 완전히 해소되지 않을 수 있으며, 수정된 pacs.009 COV가 적용 가능한 표준 및 은행 간 합의를 여전히 준수하는지 확인하는 것이 중요합니다.

Dropbox, Onedrive, WeTransfer 등.

Dropbox, OneDrive, WeTransfer 및 유사한 플랫폼은 클라우드 기반의 파일 공유 및 저장 솔루션입니다. 이들은 인터넷을 통한 디지털 파일의 전송과 저장을 용이하게 하도록 설계되었습니다. 다만 서버 간(S2S) 통화 거래, 특히 pacs.008 메시지와 유사한 금융 정보의 전송에서 이들이 수행하는 역할과 기능은 적절한 맥락에서 이해되어야 합니다.

S2S 거래에서의 역할

1. 정보 전송: S2S 거래에서는 SWIFT pacs.008 메시지(결제 정보 전송을 위한 표준 형식)에 담길 수 있는 거래 세부 정보를 포함한 거래 관련 정보가 은행 간에 안전하게 전송되어야 합니다. 이론상 Dropbox나 OneDrive와 같은 서비스를 이용하여 이러한 정보가 담긴 문서나 데이터 파일을 전송할 수도 있을 것입니다. 그러나 이러한 플랫폼은 은행 간 보안 통신이나 금융 거래를 주된 목적으로 설계된 것이 아니므로, 이는 통상적이지 않은 방식에 해당합니다.
2. 보안 및 컴플라이언스: 금융기관은 일반적으로 민감한 금융 데이터를 전송할 때 보안이 확보된 전용 통신 채널을 사용합니다. 이러한 채널은 엄격한 규제, 보안 및 개인정보 보호 기준을 충족하는데, Dropbox나 OneDrive 등의 서비스는 특히 고도로 규제되는 은행 거래 기록 보관의 맥락에서 이러한 기준을 완전히 충족하지 못할 수 있습니다.

이러한 플랫폼에서 자금을 "내려받을" 수 없는 이유
금융 세계에서 돈을 보관한다는 개념은 디지털 파일을 저장하는 것과 근본적으로 다릅니다. 통화, 특히 은행 업무와 전자 거래의 맥락에서 통화는 파일처럼 옮기거나 복사할 수 있는 유형의 실체로 저장되지 않습니다. 오히려 돈은 금융기관이 관리하는 계좌 내의 가치 기록으로 존재합니다.

1. 은행 기능 부재: Dropbox, OneDrive, WeTransfer와 같은 플랫폼은 은행 시스템이 아닙니다. 이들은 금융 거래를 처리하거나 은행 네트워크에 접속하는 기능을 갖추고 있지 않습니다. 본질적으로 디지털 보관함에 불과하며, RTGS(실시간 총액결제), RTP(실시간 결제), 환거래 은행 네트워크와 같은 은행 시스템과 연동되지 않습니다.
2. 금융기관과의 직접 연결 부재: 이러한 파일 공유 서비스는 은행 인프라와 연결되어 있지 않습니다. 은행은 지급 처리 및 청산을 위해 특정한 보안 프로토콜과 시스템(국제 거래의 경우 SWIFT 등)을 사용합니다. 클라우드 스토리지 서비스의 인프라는 이러한 은행 시스템과 연동되지 않습니다.
3. 가치의 기록으로서의 통화: 은행 시스템에서 통화는 은행 계좌 원장상의 전자 기록 또는 기입 사항으로 표시됩니다. 이러한 원장은 금융기관이 유지하며 각 고객이 계좌에 예치한 금액을 반영합니다. 이러한 기록은 물리적이거나 유형적인 것이 아니라 가치의 전자적 표현입니다.
4. 원장 조정으로서의 거래: 한 계좌에서 다른 계좌로의 통화 이체와 같은 금융 거래가 발생하더라도 실물 화폐의 이동은 일어나지 않습니다. 거래는 환거래 은행, 중앙은행 또는 실시간 결제(RTP) 청산 시스템의 각 계좌 원장 기재를 조정함으로써 이루어집니다. 은행 시스템은 한 계좌의 잔액을 줄이고 다른 계좌의 잔액을 늘려, 별도로 결제될 가치의 이전을 반영합니다. 대사 및 최종 결제: 관련 은행들은 정확성을 확보하기 위해 거래를 대사합니다. 중개 은행이 개입하는 경우, 각 은행은 환거래 은행 관계를 통해 자신이 담당한 부분을 결제합니다. 보고 및 기록 보관: 은행은 컴플라이언스, 감사 및 보고 목적으로 모든 거래 기록을 보관합니다.
5. 파일 저장 시스템과의 비호환성: 현대 은행 시스템에서 통화는 은행의 보안 데이터베이스 내 원장 기재 사항으로 표시되므로, Dropbox, OneDrive, WeTransfer 등과 같은 일반적인 파일 저장 및 공유 시스템을 통해 저장하거나 이전할 수 없습니다. 이러한 플랫폼은 거래 명세서, 계약서 또는 SWIFT 메시지에 상응하는 문서와 같이 거래에 관한 정보를 담은 디지털 파일을 저장하고 전송할 수는 있으나, 화폐 가치 자체를 저장할 수는 없습니다.
6. 보안 및 규제: 이러한 은행 원장 내 자금의 관리는 엄격한 보안 프로토콜, 금융 규정 및 감독의 적용을 받습니다. 은행은 고도로 안전한 전문 시스템을 사용하여 계좌를 관리하고 체결된 거래를 기록합니다. 이러한 시스템은 일반 파일 저장 서비스가 처리하도록 설계되지 않은 금융 데이터의 무결성, 기밀성 및 정확성을 보장합니다.