IP/IP 및 IPZip 이체

IP to IP (IPIP)

IP 간 이체는 인터넷 프로토콜(IP) 주소를 활용하여 환거래 은행 계좌 또는 데이터에서 서로 다른 금융기관이나 시스템 간으로 통화 또는 자산, 부채 및 자본을 이전하는 절차의 일부를 말합니다. 금융 거래에서 IP 주소는 인터넷에 연결된 모든 기기에 부여되는 고유한 숫자 식별자로, 서로 다른 시스템 간에 정보를 전달하는 데 사용됩니다. 은행업에서의 IP 간 이체는 각 시스템이 자신의 IP 주소를 이용하여 상호 직접 통신함으로써 금융 거래를 수행하는 것을 의미합니다. 정보의 무결성과 보안을 확보하기 위해 별도의 인증 및 승인 방식이 추가로 적용됩니다.

다만 IP 간 이체(IP to IP transfer)는 보안, 신뢰성, 컴플라이언스 측면의 우려로 인해 은행 업계에서 일반적이지 않으며 권장되지도 않는다는 점에 유의하시기 바랍니다. 이러한 우려에 관한 배경은 다음과 같습니다.

1. 보안: IP 간 이체는 SWIFT나 ACH와 같이 다중 보안 계층, 암호화 및 인증을 갖춘 기존 은행 네트워크에 비해 보안성이 낮을 수 있습니다. 두 IP 주소 간의 직접 통신은 해킹, 피싱 또는 중간자 공격 등 보안 위협에 민감한 정보가 노출될 수 있습니다.
2. 신뢰성: IP 간 이체의 사용은 거래의 신뢰성을 보장하지 않습니다. 은행 업계에는 IP 기반 이체에 대해 보편적으로 인정되는 표준이나 프로토콜이 마련되어 있지 않기 때문입니다. 이는 거래 처리, 추적 및 대사(對査) 과정에서 문제를 초래할 수 있습니다.
3. 컴플라이언스: 은행 및 금융기관은 자금세탁방지(AML) 및 고객확인(KYC) 정책을 포함한 다수의 규정과 요건의 적용을 받습니다. IP 간 이체는 이러한 규제 요건을 충족하지 못할 수 있으며, 이 경우 관련 당사자가 법적 및 재무적 위험에 노출될 수 있습니다.

은행 및 금융기관은 IP 대 IP 이체 대신 SWIFT, RTGS 또는 ACH/즉시결제와 같은 확립된 네트워크와 ISO 20022와 같은 메시지 표준을 사용하여 기관 간 안전하고 신뢰할 수 있으며 규정을 준수하는 자금 이체를 처리하는 것을 선호합니다.

은행의 통신 서버와 원장·계정 서버의 주요 차이점

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

통신 서버

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

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

원장/계정 서버

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

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

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

현대 은행 시스템에서는 이러한 기능들이 통합되어 운영되는 경우가 많으며, 안전한 은행 내부 통신 프로토콜이 원장 관리 시스템과 연동되어 작동합니다. 이러한 통합은 은행의 전체 금융 생태계에 걸쳐 실시간 업데이트와 일관성을 보장하여 효율성과 보안을 모두 강화합니다. 다수의 은행은 보안, 규제 준수 및 확장성 요건의 균형을 맞추기 위하여 자체 설치형 서버와 클라우드 기반 서버를 병행하여 사용합니다.

자산, 부채 및 지분의 실제 이전: 증권의 이전은 법적 소유권 기록을 관리하는 중앙예탁기관(CSD)에 기록되며, 대출, 고정자산 및 기타 포지션은 준거법에 따라 양도 또는 이전 계약을 통해 이전됩니다. 이 두 가지는 모두 통신 프로토콜의 범위를 벗어납니다. 자산 및 지분의 이전은 은행의 재무제표에도 영향을 미쳐 부채, 자산 및 자본 잔액을 변동시킵니다. 관련 감독 당국에 대한 이러한 재무 보고와 필요한 컴플라이언스 사항은 프로토콜의 데이터 전송 기능을 넘어서는 것이며, 별도의 재무 및 규제 절차가 필요합니다.

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

IP ZIP 이체

기관 지급 지시서의 안전한 파일 기반 전송

IP ZIP Transfer는 인증된 기관 시스템 간에 인터넷 프로토콜 네트워크를 통해 구조화된 지급 지시와 관련 거래 데이터를 직접 전송하는 안전한 파일 기반 방식으로 이해하는 것이 가장 적절합니다.

용어는 특별히 정확하게 사용해야 합니다.

IP ZIP 전송은 청산 시스템, 결제 시스템, 지급 경로 또는 화폐 가치를 이전하는 독립적인 메커니즘이 아닙니다. ZIP 아카이브는 전송용 컨테이너에 불과하며, IP 연결은 통신 채널입니다. 아카이브에 담긴 정보는 지시, 데이터 세트 또는 거래 메시지에 해당합니다.

따라서:

IP ZIP은 지급 정보와 지시 사항을 전송합니다. 그 자체로 자금을 결제하지는 않습니다.

개념적으로 이는 ISO 20022 pacs.008(금융기관 간 고객 대금이체) 메시지에 적용되는 구분과 유사합니다. pacs.008은 고도로 구조화된 은행 간 대금이체 지시를 전달할 수 있으나, 해당 메시지 자체를 중앙은행 화폐, 상업은행 화폐 또는 환거래 계좌 잔액의 최종적인 이동 및 결제와 혼동해서는 안 됩니다.

IP ZIP 전송에도 동일한 원칙이 적용됩니다.

2. 안전한 거래 컨테이너로서의 ZIP 파일

ZIP 구성요소는 주로 컨테이너화 및 패키징 수단으로 기능합니다.

개시 금융기관은 거래 구성 요소를 개별적으로 전송하는 대신, 관련 파일을 하나의 통제된 패키지로 취합할 수 있습니다.

합의된 양자 간 사양에 따라 이러한 패키지에는 다음이 포함될 수 있습니다.

• 구조화된 지급 지시,
• XML 지급 메시지;
• ISO 20022 호환 데이터셋;
• JSON 거래 객체
• CSV 또는 고정 형식의 거래 기록;
• 자체 은행 간 지급 파일;
• 채무자 및 채권자 정보;
• 송금인 및 수취인 계좌 정보;
• 거래 식별번호;
• 통화 및 금액 정보,
• 요청된 실행일 및 결제일;
• 환거래 은행 지시사항;
• 중개은행 정보;
• 송금 정보;
• 결제 경로 정보,
• 컴플라이언스 관련 서류;
• KYC 또는 KYB 참조 자료;
• 자금 출처 정보;
• 거래 명세서;
• 전자서명;
• 암호화 해시;
• 증서;
• 타임스탬프;
• 대사 파일, 그리고
• 통제 합계.

따라서 보관 기록에는 주된 지급 지시와 함께 해당 지시를 인증, 검증, 처리 및 대사(對査)하는 데 필요한 부수 정보가 모두 포함될 수 있습니다.

압축은 기술적으로 부수적인 요소입니다. 주된 목적은 통제된 패키징과 전송입니다.

따라서 ZIP 압축 파일은 그 안에 표시된 자금이 존재하거나, 사용 가능하거나, 담보 제약이 없거나, 결제가 완료되었음을 입증하는 증거로 간주되어서는 안 됩니다.

3. 구조화된 지급 지시

적절하게 설계된 경우, IP ZIP 패키지에 포함된 지급 지시는 통상의 구조화된 금융 메시지와 유사한 기능을 수행할 수 있습니다.

예를 들어, 금융기관은 ISO 20022 pacs.008 메시지에서 통상 확인되는 정보에 해당하는 필드를 포함한 XML 지시서를 전송할 수 있습니다. 해당 필드는 다음과 같습니다.

• 메시지 식별 정보;
• 생성 일시;
• 거래 건수,
• 결제 정보;
• 지시 대리인;
• 지시 대상 은행;
• 채무자;
• 채무자 계좌;
• 채무자 대리 금융기관;
• 수취인 측 대리은행(creditor agent);
• 채권자;
• 채권자 계좌;
• 지시 금액;
• 통화;
• 수수료 부담 주체;
• 결제 식별;
• 종단 간 식별, 그리고
• 송금 정보.

핵심적인 구분은 데이터 구조가 결제 메커니즘을 결정하지 않는다는 점입니다.

기술적으로 유효한 지급 지시가 수신 시스템에서 수신, 인증 및 승인되었더라도 이에 상응하는 금융 결제는 미결 상태로 남아 있을 수 있습니다.

따라서:

지시 접수 ≠ 자금 수령

지시 인증 ≠ 자금 결제 완료

파일의 정상적인 가져오기 ≠ 수취인에 대한 확정 자금의 입금

서버 수신 확인 ≠ 결제 완료 확인

이러한 구분은 IFB가 대체 이체 방식을 다루는 데 있어 근본이 됩니다.

4. 전송 프로토콜

기관용 IP ZIP 전송은 통제되고 인증된 통신 환경을 통해서만 이루어져야 합니다.

양자 간 기술 합의에 따라, 전송에는 다음과 같은 기술이 사용될 수 있습니다.

SFTP

SSH 기반 보안 파일 전송 프로토콜은 암호화된 전송, 서버 인증 및 통제된 사용자 인증을 제공합니다.

기관 고객 연결에는 일반적으로 비밀번호 단독 인증보다 공개 키 인증을 우선 적용해야 합니다.

FTPS

기존 인프라 환경에서 필요한 경우 FTP를 TLS로 보호할 수 있으며, 이 경우 적절한 인증서 검증, 암호화 표준 및 접근 통제가 구현되어야 합니다.

HTTPS / REST API

해당 패키지는 TLS 및 적절한 애플리케이션 수준 인증을 적용한, 인증된 HTTPS 엔드포인트 또는 API 구조를 통해 전송될 수 있습니다.

상호 TLS(Mutual TLS)

더 높은 수준의 보증이 요구되는 기관 간 연결에서는 상호 TLS(mTLS)를 통해 양측 단말이 디지털 인증서를 이용하여 서로를 인증할 수 있습니다.

이는 서버 단독 인증만 사용하는 경우보다 권한 없는 단말에 대해 실질적으로 더 강력한 보호를 제공합니다.

VPN

애플리케이션 계층 전송이 이루어지기 전에, 참여 기관 간에 사이트 간 IPSec 또는 이에 상응하는 VPN을 통해 암호화된 전용 터널을 구축할 수 있습니다.

전용 사설 연결망

거래량, 보안 요건 또는 기관의 위험 프로파일상 필요한 경우, 공용 인터넷을 통한 전송을 전용 또는 사설 네트워크 연결로 보완하거나 대체할 수 있습니다.

구체적인 프로토콜은 운영 개시 전에 양자 간 합의되어야 합니다.

5. 단말 인증

수신 기관은 해당 전문이 그 전문이 대표한다고 표시된 기관으로부터 발신되었음을 확인하여야 합니다.

관련 통제 수단에는 다음이 포함될 수 있습니다:

• 기관용 디지털 인증서;
• SSH 공개키/개인키 쌍;
• 상호 TLS(mutual TLS) 인증서;
• API 자격 증명;
• IP 허용 목록 등록;
• VPN 인증;
• 하드웨어 보안 모듈;
• 적절한 경우 인증서 고정(certificate pinning) 적용;
• 다중 요소 관리자 인증;
• 통제된 서비스 계좌;
• 역할 기반 접근 통제, 그리고
• 운영 환경과 테스트 환경의 분리.

IP 주소만으로는 기관의 신원을 입증하는 충분한 증거가 될 수 없습니다.

마찬가지로, 엔드포인트, 서버 로그인 정보, API 자격 증명 또는 ZIP 비밀번호를 보유하고 있다고 해서 기초 자금에 대한 소유권이 성립하는 것은 아닙니다.

6. 암호화

기밀 유지는 통상 둘 이상의 단계에서 확립되어야 합니다.

전송 구간 암호화

통신 채널은 TLS 또는 SSH와 같이 적절히 구성된 최신 프로토콜을 사용하여 암호화되어야 합니다.

이는 전송 중인 정보를 보호합니다.

페이로드 암호화

필요한 경우 거래 패키지 자체를 추가로 암호화할 수 있습니다.

이는 전송 채널과 무관하게 금융 정보를 보호하며, 파일이 일시적으로 저장되거나, 중개 인프라를 경유하거나, 보관되거나, 비동기 방식으로 처리되는 구간에서의 노출을 상당히 줄일 수 있습니다.

저장 데이터 암호화

처리 대기 중인 파일은 적절한 접근 제한과 저장 시 암호화가 적용된 통제된 보관 환경 내에서 보호되어야 합니다.

그러나 암호화는 기밀성을 확립할 뿐이며, 거래의 재무적 유효성을 확립하지는 않습니다.

7. 암호화 무결성

수신 기관은 또한 전송된 패키지가 생성 이후 변경되었는지 여부를 판단할 수 있어야 합니다.

따라서 해당 패키지 또는 이를 구성하는 개별 파일에 대하여 암호화 해시를 생성할 수 있습니다.

예를 들어:

원본 거래 패키지
→ 암호화 해시 생성
→ 패키지 전송
→ 수신 시스템이 독립적으로 해시 산출
→ 산출된 해시를 전송되었거나 서명된 해시와 대조

불일치는 수신된 패키지가 최초로 인증된 패키지와 암호학적으로 동일하지 않음을 나타냅니다.

무결성 검증을 위해 구현 방식에 따라 SHA-2 또는 SHA-3 계열 등 최신 암호화 해시 알고리즘을 사용할 수 있습니다.

8. 전자서명

디지털 서명은 암호화와는 본질적으로 다른 기능을 수행합니다.

암호화는 기밀 유지를 보장합니다.

해싱은 무결성 확립에 기여합니다.

적절하게 구현된 전자서명은 다음 사항을 입증하는 데 도움이 될 수 있습니다.

1. 진정성 - 해당 패키지가 관련 개인키를 사용하여 서명되었음;
2. 무결성 - 서명된 데이터가 이후 변경되지 않았음을 의미합니다.
3. 책임성 - 서명은 해당 PKI 및 거버넌스 체계에 따라 관련 기관 자격 증명과 연결될 수 있습니다.

수신 기관은 거래 지시가 결제 처리 단계로 진입하기 전에, 해당 서명을 대응하는 신뢰 인증서 또는 공개키와 대조하여 검증하여야 합니다.

개인 서명 키는 적절하게 보호되어야 하며, 가급적 기관 차원의 키 관리 인프라를 통해, 필요한 경우 하드웨어 보안 모듈(HSM)을 활용하여 보호하는 것이 바람직합니다.

9. 재전송 및 중복 방지

금융 파일 전송에는 동일한 유효 지시가 반복적으로 제출되는 것을 방지하기 위한 통제 장치가 필요합니다.

따라서 적절하게 설계된 아키텍처는 고유 거래 식별자와 다음과 같은 적절한 통제 장치를 포함해야 합니다.

• 고유 메시지 ID;
• 고유 거래 식별번호;
• 타임스탬프;
• 일련번호,
• 파일 식별자;
• 중복 메시지 탐지;
• 멱등성 통제;
• 처리 상태 등록부; 및
• 기처리된 지시와의 대사(reconciliation)

수신 기관은 합의된 운영 절차에 따라 중복된 지시를 거절하거나 격리하거나 조사해야 합니다.

10. 파일 검증

파일이 정상적으로 수신되면 자동 결제가 아니라 검증 절차가 개시되어야 합니다.

보안 처리 환경에서는 해당 서류 묶음에 대해 다음과 같은 여러 단계의 순차적 통제가 이루어질 수 있습니다:

1단계 – 운송 검증

승인된 채널을 통해 패키지가 도착했음을 확인하는 절차입니다.

2단계 – 엔드포인트 인증

송신 시스템 및 기관 자격 증명에 대한 확인.

3단계 – 악성코드 및 파일 보안 통제

지급 인프라로 수용하기 전에 아카이브 및 그 구성 파일을 점검하는 절차입니다.

4단계 – 암호학적 검증

해시, 서명 및 인증서의 검증.

5단계 – 구조 검증

파일이 합의된 스키마, 명명 규칙, 문자 인코딩 및 데이터 사양을 준수함을 확인하는 절차입니다.

6단계 – 의미론적 검증

필수 결제 항목이 존재하며 내부적으로 일관성이 있음을 확인합니다.

7단계 – 거래 검증

통화, 금액, 계좌, 라우팅 정보, 거래 참조번호 및 결제 지시 사항에 대한 검증.

8단계 – 컴플라이언스 검증

AML, 제재, KYC/KYB, 거래 모니터링 및 기타 적용 가능한 통제 절차.

9단계 – 결제 검증

해당 금융 가치를 결제할 수 있는 실제 메커니즘이 존재한다는 확인.

이러한 통제 절차가 모두 완료된 후에야 지시는 수신 기관에 적용되는 절차에 따라 집행 단계로 진행되어야 합니다.

11. 수신 확인은 결제 완료가 아닙니다

IP ZIP 환경에서는 여러 건의 기술적 확인 응답이 생성될 수 있습니다.

예를 들어:

ACK – 파일 수신 확인

이는 수신 측 단말이 해당 패키지를 수령하였다는 사실만을 입증합니다.

ACK – 파일 인증 완료

이는 인증 통제 절차가 성공적으로 완료되었음을 입증합니다.

ACK – 파일 검증 완료

이는 해당 패키지가 적용되는 구조적 또는 기술적 검증 기준을 충족하였음을 입증합니다.

ACK – 지시 접수

이는 지급 지시가 수취 기관의 처리 절차에 진입하였음을 입증하는 근거가 될 수 있습니다.

이러한 상태가 반드시 다음을 의미하는 것은 아닙니다.

결제 완료

결제에는 별도의 금융 이벤트가 필요합니다.

이러한 구분은 기존 금융 메시징에서 결제 메시지의 성공적인 전달 및 수락과 기초가 되는 금전 채무의 최종 결제를 구별하는 것과 유사합니다.

12. 기초 거래의 결제

IP ZIP 지급 지시가 인증, 검증, 접수 및 승인되면, 그 기초가 되는 금전적 가치는 적절한 금융 인프라를 통해 결제되어야 합니다.

관련된 통화, 기관 및 관할권에 따라 결제는 다음을 통해 이루어질 수 있습니다.

• 환거래 은행 업무;
• 노스트로/보스트로 계좌;
• 중앙은행 계좌;
• RTGS 인프라;
• 공인된 청산 시스템,
• 국내 결제 시스템;
• 즉시결제 인프라;
• 환거래 결제은행; 또는
• 법적·운영적으로 인정되는 그 밖의 결제 체계.

14. 보안 원칙

IFB는 모든 대체 송금 방식에 대해 다음과 같은 근본적인 구분을 적용합니다.

보안 전송은 데이터가 안전하게 전송될 수 있음을 입증할 뿐입니다. 자금이 결제될 수 있음을 입증하는 것은 아닙니다.

• 암호화는 자금을 증명하지 않습니다.
• 디지털 서명은 자금을 증명하지 않습니다.
• 서버상의 잔액은 자금의 존재를 증명하지 않습니다.
• 거래 파일만으로는 자금을 증명할 수 없습니다.
• 파일 수신이 성공적으로 이루어졌다고 해서 자금의 존재가 증명되는 것은 아닙니다.
• 기술적 수신 확인은 결제 완료를 증명하지 않습니다.

결정적인 금융상의 질문은 여전히 송금 발신 금융기관이 공인된 은행 인프라를 통해 해당 금전적 가치를 이행할 수 있는, 검증된 유동성과 실제 작동 가능한 결제 경로를 보유하고 있는지 여부입니다.

15. IFB 수용 체계

IFB는 승인된 기관 거래상대방 및 수락된 고객에 한하여, 기술, 법무 및 컴플라이언스 심사를 충족하는 경우에만 IP ZIP 전송을 검토할 수 있습니다.

실제 운영 환경 연결을 개시하기 전에 IFB는 다음 사항에 대한 확인을 요구할 수 있습니다.

• 개시 금융기관,
• 거래를 전송할 기관의 권한;
• 실질 소유권 및 거래 당사자;
• 자금의 출처 및 적법성;
• 근본적인 경제적 목적;
• 송신 및 수신 인프라;
• 엔드포인트 소유권;
• IP 및 네트워크 아키텍처;
• 인증 방식;
• 인증서 및 암호화 자격 증명;
• 암호화 표준,
• 파일 형식 및 스키마;
• 지급 메시지 구조;
• 거래 식별 방법론;
• 수신 확인 프로토콜;
• 중복 및 재전송(replay) 통제;
• 예외 처리;
• 대사(對査) 절차;
• 환거래 관계;
• 결제 계좌;
• 유동성 관련 약정, 그리고
• 최종 결제 경로.

기술적 상호운용성만으로는 충분하지 않습니다.

IFB는 IP ZIP 패키지의 전송 성공을 자금 수령으로 간주하지 않습니다. 거래는 해당 가치가 합의된 은행 또는 결제 인프라를 통해 정상적으로 결제되고 그 결제 내역을 독립적으로 대사할 수 있을 때에 한하여 금융상 완료된 것으로 봅니다.

기본 원칙

IP ZIP은 지시 사항을 안전하게 전송하는 것을 의미합니다. 결제는 이에 상응하는 금융 가치의 이동을 의미합니다.

두 절차는 동일한 거래 워크플로의 일부를 이룰 수 있으나, 서로 같은 사건은 아닙니다.

기관 은행 업무 용어로는 다음과 같습니다.

메시지 전송 → 인증 → 검증 → 수락 → 실행 → 결제 → 대사

해당 결제 절차가 완료되어야만 거래의 자금 이전 부분이 완료된 것으로 확정됩니다.

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

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

당행 계좌로 자금 또는 자산을 이전하는 방법에 대해 더 자세히 알고 싶으시면 Marie Mayer에게 문의해 주시기 바랍니다.