SWIFT

SWIFT 송금 및 MT·MX 메시지를 통한 커뮤니케이션

SWIFT(국제은행간통신협회, Society for Worldwide Interbank Financial Telecommunication)는 은행 등 금융기관이 지급 지시 및 확인과 같은 금융 거래에 관한 표준화된 메시지를 주고받을 수 있도록 하는 보안 메시징 네트워크입니다. SWIFT는 계좌를 보유하거나 자금을 이체하지 않으며, 정보를 교환하기 위한 안전하고 신뢰할 수 있는 플랫폼을 제공할 뿐입니다.

일반적인 SWIFT 송금은 MT(Message Type) 메시지로 알려진 일련의 표준화된 메시지 유형을 사용합니다. 이러한 메시지는 사전에 정의된 형식과 필드를 갖추고 있어, 금융기관이 메시지에 담긴 정보를 쉽게 이해하고 처리할 수 있도록 합니다.

MX(ISO 20022) 메시지는 XML(eXtensible Markup Language)을 기반으로 하는 신형 금융 메시징 표준입니다. 보다 풍부하고 구조화된 형식을 제공하여 향상된 데이터 교환과 개선된 자동 처리(STP)를 가능하게 합니다. MX 메시지는 SWIFT 네트워크에서 MT 메시지를 점진적으로 대체하고 있으며, 이는 상호운용성과 데이터 처리 능력을 높이기 위한 것입니다.

전통적인 SWIFT 송금은 수십 년간 국제 결제의 근간이 되어 왔으나, 투명성 부족, 느린 처리 속도, 비정형 데이터 등의 한계가 있습니다.

Swift 103+ STP(직통 처리, Straight Through Processing)

Swift 103+ STP는 자동 처리(STP, Straight Through Processing)에 최적화된 기존 MT 형식이었으며, 병행 운영 종료 이후에는 그 역할을 pacs.008 STP 이용 지침이 대신하고 있습니다. STP를 통해 개시부터 최종 결제까지 전 지급 과정을 수작업 개입 없이 전자적으로 처리할 수 있습니다.

추가 기능:

1. 표준화된 형식: 표준화된 형식을 엄격히 준수하도록 요구하여 오류와 지연을 줄입니다.
2. 자동 처리: 거래가 자동으로 처리되어 더욱 신속하고 효율적인 처리가 보장됩니다.
3. 수작업 개입 감소: 수기 입력 및 확인 필요성이 최소화되어 오류 및 지연 위험이 줄어듭니다.
4. 신속한 결제: 기존 방식에 비해 거래가 더 빠르게 결제됩니다.

STP 관련 고려사항:

1. 정확한 데이터 입력: 지연이나 거절을 방지하려면 데이터를 정확하게 입력하여야 합니다.
2. 형식 요건 준수: 은행은 103+ STP의 형식 요건을 엄격히 준수하여야 합니다.
3. 소프트웨어 및 시스템: 은행은 STP를 효과적으로 처리하기 위하여 적절한 소프트웨어와 시스템을 갖추어야 합니다.

메시징과 결제를 구분하는 것이 중요합니다. SWIFT는 기관 간 정형화된 금융 메시지를 전송하지만, 그 자체로 자금을 이동하거나 잔액을 보유하지 않습니다. pacs.008 메시지를 포함한 SWIFT 확인서는 참여 기관의 은행 시스템 내에서 실제로 처리되고 대사된 거래와 일치하는 경우에만 유효합니다.

기관의 검증 없이 단독으로 제시된 SWIFT 문서, 화면 캡처 또는 메시지는 결제 완료의 증거로 간주되어서는 안 됩니다.

SWIFT gpi 송금.

SWIFT gpi(Global Payments Innovation):

2017년에 출범한 SWIFT gpi는 기존 SWIFT 송금의 한계를 보완하여 국경 간 결제의 속도, 투명성 및 추적 가능성을 높이기 위해 마련된 이니셔티브입니다. SWIFT gpi는 기존의 MT 및 MX 메시지 형식을 활용하여 결제 서비스를 개선합니다. SWIFT gpi의 주요 특징은 다음과 같습니다.

• 신속한 지급: gpi는 절차를 간소화하고 은행 간 서비스 수준 계약(SLA)을 한층 엄격하게 설정하여 거래 처리 시간을 단축하며, 통상 수 분 또는 수 초 이내에 처리됩니다.
• 지급 추적: gpi Tracker를 통해 거래를 실시간으로 추적할 수 있어 투명성이 높아지고 수작업 조사가 줄어듭니다.
• 수수료 투명성: 은행은 고객에게 거래 수수료에 관한 정보를 사전에 제공함으로써 보다 나은 의사결정을 지원할 수 있습니다.
• 더 풍부한 데이터: gpi는 보다 상세하고 구조화된 정보 교환을 지원하여 대사 업무와 규제 준수를 개선합니다.

SWIFT gpi는 종단 간 추적, 신속한 처리, 풍부한 데이터를 통해 국경 간 결제를 개선함으로써 기존 SWIFT 송금의 한계를 해소합니다.

SWIFT gpi 비참가 기관을 위한 주요 매개변수

SWIFT gpi 비참가 기관(예: gpi에 직접 가입하지 않은 은행 또는 금융기관)이 gpi 참가 은행에 지급 지시를 송부하는 경우, gpi 참가 은행은 이를 필요한 SWIFT 메시지 형식(고객 신용이체용 pacs.008, 커버 이체용 pacs.009 COV, 금융기관 신용이체용 pacs.009)으로 변환할 수 있습니다. 이러한 변환을 통해, 지시서에 필수 항목을 채우기에 충분한 정보가 포함되어 있고 종단 간 추적 가능성 등 gpi 규정을 준수하는 경우에 한하여 gpi 네트워크 내에서의 처리 및 추적이 가능합니다.

gpi 비참여 은행은 통상 이러한 매개변수를 국내 결제 체계, API 또는 기존 포맷을 통해 제공하며, gpi 은행이 gpi 고유의 추가 사항을 처리합니다(예: UETR이 제공되지 않은 경우 이를 생성하되, 비gpi 기관의 경우 전달은 선택 사항입니다). 구체적인 요건은 관할권, 통화 및 양자 간 합의에 따라 다를 수 있으나, 핵심 매개변수는 CBPR+(Cross-Border Payments and Reporting Plus) 지침 및 ISO 20022 표준에서 도출됩니다. 2025년 11월 22일 병행 운영 기간이 종료됨에 따라 국경 간 결제 지시는 ISO 20022 포맷으로 교환되며, 아래의 기존 MT 필드 참조는 참고용으로만 제공됩니다.
1. 당사자 식별(채무자 및 채권자 정보)
이는 송금인과 수취인을 식별하여 트래블 룰 요건에 관한 FATF 권고사항 16의 준수를 보장합니다.

• 채무자/지시 고객(Debtor/Ordering Customer): 성명 전체, 구조화된 주소(도로명, 도시, 우편번호, 국가) 및 계좌 식별 정보(예: IBAN 또는 계좌번호). 종전 MT 103/MT 202 COV에서는 Field 50a에 해당하며, pacs.008/pacs.009에서는 <Dbtr> 및 <DbtrAcct>에 해당합니다.
• 채권자/수취인 고객: 성명 전체, 구조화된 주소 및 계좌 식별 정보. 기존 MT 103/MT 202 COV의 필드 59a에 대응하며, pacs.008/pacs.009에서는 <Cdtr> 및 <CdtrAcct>에 대응합니다.
• 최종 채무자/채권자(해당하는 경우): 주 당사자와 다른 경우, 투명성 제고를 위해 해당 당사자의 정보를 기재합니다(선택 사항이나 gpi 추적을 위해 권장됨). pacs.008/pacs.009의 <UltmtDbtr>/<UltmtCdtr>에 매핑됩니다.

필요 사유: 정확한 라우팅과 규제 점검을 가능하게 하며, 정보가 불완전한 경우 거절 또는 지연이 발생할 수 있습니다.

2. 대리 기관 및 경로 정보
체인에 관여하는 금융기관을 명시합니다.

• Debtor Agent(지급인 은행): 송금 은행의 BIC(Bank Identifier Code) 또는 기타 식별자입니다. 기존 MT 103의 Field 52a에 대응하며, pacs.008/pacs.009에서는 <DbtrAgt>에 해당합니다.
• 수취 은행(Creditor Agent): 수취 은행의 BIC입니다. 종전 MT 103/MT 202 COV의 Field 57a에 대응하며, pacs.008/pacs.009에서는 <CdtrAgt>에 해당합니다.
• 중개 은행(알려진 경우): 모든 환거래 은행의 BIC(최대 3단계). 기존 MT의 Field 56a에 해당하며, pacs.008/pacs.009에서는 <IntrmyAgt1-3>에 해당합니다.
• 지시 에이전트/피지시 에이전트: 거래 체인상 직접적인 송신 은행 및 수신 은행의 BIC입니다. 선택 사항이나 직렬 방식 또는 커버 방식에 도움이 됩니다.
• 이전 지시 대리인(해당되는 경우): 다단계 경로의 경우 최대 3개의 이전 대리인.

필수 사유: 적정한 중개기관 경로 지정을 보장합니다. pacs.009 COV에서는 정확성을 위해 기관 명칭보다 BICFI를 사용하십시오.

3. 거래 세부 정보
결제를 위한 핵심 금융 요소입니다.

• 금액 및 통화: 은행 간 결제 금액 및 ISO 4217 통화 코드(예: USD, EUR)입니다. 기존 MT 103/MT 202 COV의 32A 필드에 대응하며, pacs.008/pacs.009의 <IntrBkSttlmAmt>에 해당합니다.
• 지시 금액(상이한 경우): 공제 전 원래 금액.
• 은행 간 결제일: 결제 기산일입니다. MT에서는 필드 32A의 일부에, pacs.008/pacs.009에서는 <IntrBkSttlmDt>에 대응합니다.
• 결제 방식: RTGS(CLRG), 커버(COVE) 또는 대리 은행(INDA/INGA) 방식 여부를 표시합니다. 직접 대응하는 MT 항목은 없으나 묵시적으로 포함됩니다.

필요한 이유: 가치 이전의 내용을 정의하며, 모든 형식에서 필수입니다.

4. 참조 및 추적 식별자
특히 gpi에서의 추적 가능성을 위한 것입니다.

• 종단 간 식별자: 전체 거래 흐름을 연결하는 참조 번호(예: 청구서 또는 거래 ID)입니다. pacs.008/pacs.009의 <EndToEndId>.
• 지시 식별자: 발신자 참조 번호(MT에서는 16자로 제한됩니다). 종전 MT의 Field 20에 대응하며, pacs.008/pacs.009에서는 <InstrId>에 해당합니다.
• 고유 종단 간 거래 참조번호(UETR): 종단 간 추적을 위한 UUID입니다. pacs.008/pacs.009에서 필수이며, 종전의 MT103/MT202에서는 필드 121에 기재됩니다. 개시 채널이 이를 제공하지 않는 경우, 처리 경로상의 첫 번째 Swift 은행이 이를 생성합니다.
• 거래 식별자: 추가 내부 참조 번호.

필요 사유: gpi 추적 및 연계(예: pacs.008과 pacs.009 COV 간 연계)를 가능하게 하며, UETR은 범용 확인 메시지의 핵심 요소입니다.

5. 목적 및 서비스 정보
지급 유형을 분류합니다.

• 목적 및 범주 목적 코드: 거래의 성격을 나타내는 ISO 코드(예: 급여를 뜻하는 SALA)입니다. 일부 송금 경로에서 필수이며, pacs.008의 <Purp> 및 <CtgyPurp>에 해당합니다.
• 서비스 수준 코드: gpi 서비스를 식별합니다(예: gpi 고객 신용이체의 경우 G001). 비 gpi 은행은 합의되지 않은 한 gpi 전용 코드를 포함해서는 안 됩니다. MT의 Field 23E, pacs.008/pacs.009의 <SvcLvl>에 대응합니다.
• 로컬 상품 코드(Local Instrument Code): 특정 방식(예: 그룹 내 이체)에 사용됩니다.

필요 사유: 규제 준수와 처리 우선순위를 확보하며, ISO 이행 이후 의무화되는 추세입니다.

6. 송금 및 추가 지시 사항

• 송금 정보: 비정형(최대 140자) 또는 정형(예: 송장 세부 정보) 형식입니다. 기존 MT 103의 Field 70에 대응하며, pacs.008/pacs.009에서는 <RmtInf>에 해당합니다.
• 대리 은행에 대한 지시사항: 예: 수취인을 나타내는 /REC/, 계좌를 나타내는 /ACC/ 또는 전화 지시(PHOB). 과거 MT의 Field 72에 해당하며, pacs.008/pacs.009에서는 <InstrForNxtAgt>/<InstrForCdtrAgt>에 대응됩니다.
• 결제 시각 표시자: 요청된 시각(예: CLS 시각을 나타내는 CLSTm).

필요 사유: 맥락과 처리 지침을 제공하며, pacs.009 COV의 커버 방식에 필수적입니다.

7. 규제 및 컴플라이언스 데이터

• 규제 보고: 코드 또는 세부 정보(예: 세금 식별번호, CRED/DEB와 같은 보고 지표). MT에서는 Field 77B에, pacs.008/pacs.009에서는 <RgltryRptg>에 매핑됩니다.
• 반환 사유 코드(반환 건에 해당하는 경우): 예를 들어 해지된 계좌의 경우 AC04이며, pacs.004에서 원 메시지와 연결됩니다.

필요 사유: AML/KYC 및 보고 의무를 충족하며, 규제 대상 송금 구간에서는 필수입니다.

모범 사례로서, gpi 비참가 은행은 MT-MX 변환 과정에서 데이터가 잘리지 않도록 데이터를 구성하고, 구체적인 필요 사항에 관하여 gpi 회원 은행과 협의하여야 합니다. 결제에 커버 방식이 수반되는 경우, 기초 고객 정보는 메시지 간에 동일하게 반영되어야 합니다(예: pacs.008에서 pacs.009 COV로).

SWIFT gpi의 지급 메시지

SWIFT gpi(Global Payments Innovation) 체계에서 원본 지급 메시지(예: 고객 이체용 pacs.008 또는 커버 이체용 pacs.009 COV)는 일단 발송되면 변경할 수 없는 것으로 간주됩니다. 수취 은행은 이들 메시지의 내용을 직접 변경하거나 수정할 수 없으며, 이는 SWIFT 메시지가 지급 전 과정에서 무결성과 감사 가능성을 유지하도록 설계되어 있기 때문입니다. 대신 모든 변경, 정정 또는 취소는 별도의 후속 메시지, gpi Tracker를 통한 상태 업데이트 또는 gSRP(gpi Stop and Recall Payment)와 같은 전용 서비스를 통해 처리됩니다. 이를 통해 고유 종단 간 거래 참조번호(UETR)를 이용한 종단 간 추적 가능성이 보장됩니다.

다만 수취 은행(통상 채권자 대리 은행 또는 중개 은행으로 활동하는 은행)은 송금 은행의 변경 요청에 응하거나, 지급 결과를 사실상 변경하는 조치(예: 반환 또는 보류)를 개시할 수 있습니다. 또한 특정 조건에서 송금 은행에 확인 또는 정정을 요청할 수 있습니다. 이러한 절차는 SWIFT의 규정집, 시장 관행 지침(예: Payments Market Practice Group – PMPG) 및 규제 요건에 따라 운영되며, 자동화, 투명성 및 사기 방지를 우선시합니다.

수취 은행이 변경을 요청하거나 지원할 수 있는 조건
수취 은행은 원 지급이 지시된 대로 처리될 수 없는 경우 변경(예: 세부 정보의 정정)을 요청하거나 변경의 필요성을 시사하는 조치를 취할 수 있습니다. 이는 통상 조회 메시지(예: MT 195/199) 또는 발신자가 개시한 요청에 대한 회신을 통해 이루어집니다. 주요 조건은 다음과 같습니다.

• 지급 정보 오류: 수취인 계좌 오류(예: 해지된 계좌 – 코드 AC04), 통화 오류(코드 CURR), 대리 은행 라우팅 오류(코드 AGNT), 기술적 문제(코드 TECH) 등 부정확한 사항이 있는 경우, 수취 은행은 해당 지급을 보류 처리하고 송금인에게 정정된 정보의 제공 또는 신규 지급 지시를 요청할 수 있습니다. 이를 통해 전면적인 거절을 피하면서도 문제를 해결할 수 있습니다.
• 지급 처리 불가: 코드 CUTA(Cancel Upon Unable to Apply)에 따라, 명의 또는 계좌 불일치, 정보 부족 등으로 인해 대금을 입금할 수 없는 경우 수취 은행은 시정을 위해 송금 은행에 취소 또는 정정 정보를 요청할 수 있습니다.
• 사기 의심 또는 무권한 거래: 사기(코드 FRAD)의 경우, 수취 은행은 송금인의 사전 요청 없이도 문제를 독자적으로 탐지하여 자금 반환 절차를 개시할 수 있습니다. 또한 송금인의 회수 요청에 대응하여 자금을 격리하고, 이미 입금된 경우에는 위험을 완화하기 위해 반환 전에 면책 보증(코드 INDM)을 요청할 수 있습니다.
• 중복 또는 부당 지급: DUPL(중복 지급) 또는 UPAY(부당 지급)와 같은 코드를 통해 수취 은행은 거래에 오류가 있거나 정당하지 않은 경우 이를 표시하고 취소를 요청할 수 있습니다.
• 규제 또는 컴플라이언스 문제: 해당 지급이 현지 법령, 제재 또는 AML 요건을 위반하는 경우(코드 LEGL), 수취은행은 이를 거절하거나 보류하고 송금인에게 추가 서류 또는 정정을 요청할 수 있습니다.
• 고객 또는 수취인의 결정: 수취인이 지급을 거절하는 경우(코드 CUST 또는 NOAS – 수취인 무응답), 수취은행은 이를 반환하고 송금인에게 통지할 수 있으며, 변경 사항에 대한 확인을 요청할 수 있습니다.
• 보류 해결 사항: 차기 에이전트의 회신 대기(PTNA) 또는 출금 권한 대기(RQDA)와 같은 보류 건(코드 PDCR)의 경우, 수취 은행은 지급을 보류하고 진행을 위한 추가 지시 또는 변경을 요청할 수 있습니다.

모든 경우에 요청은 직통 처리(straight-through processing)를 지원할 수 있도록 자동화에 적합하게 구성되어야 합니다(예: UETR, 필드 20/32A/50/59와 같은 원 참조번호, 메시지 필드 79의 특정 코드 포함). 자금이 입금되는 경우 당사자 간 면책 계약이 요구될 수 있으며, 수취은행은 요청을 수락할 의무가 없으나 긴급한 요청(예: 사기 관련)은 우선 처리해야 합니다.

관련 절차

• 송금인 개시 회수 요청에 대한 대응: 송금인(채무자 은행)은 일반적으로 gSRP 서비스를 통해 MT 192/292(또는 camt.056 등 ISO 20022 상응 메시지)로 회수 요청을 개시하며, 이는 순차적으로 또는 수취 은행에 직접 전송됩니다. 수취 은행은 즉시 수신을 확인하고, CNCL(취소), RJCR(사유 부기 거절), PDCR(보류) 등의 코드를 사용하여 MT 196/296(구조화된 경우 MT 199/299)으로 회신하여야 합니다. 회수가 수락되면 자금은 pacs.004(지급 반환)를 통해 반환됩니다.
• 수취은행의 독자적 조치: 내부적으로 사기가 탐지된 경우, 수취은행은 구조화된 세부 정보와 함께 pacs.004를 사용하여 자금을 반환할 수 있으며, Tracker를 통해 실시간 처리 현황을 통지합니다.
• 수정/확인 요청: 수취은행은 문의 메시지(예: MT 195/295)를 사용하여 추가 정보 등 변경 사항을 요청합니다. 이는 보류 중인 지급에서 흔히 발생합니다.
• 트래커 연동: 모든 조치는 gpi Tracker에 실시간으로 반영되며, API 또는 GUI를 통해 접근할 수 있어 모든 당사자가 처리 현황을 확인할 수 있습니다. gpi 회원은 gCCT(고객 신용이체), gCOV(커버), gSRP에 대한 필수 규정집을 준수해야 합니다.
• 한계 및 성공 요인: 변경은 보장되지 않으며, 성공 여부는 지급 단계(입금 전이 더 용이), 수취인의 협조 및 관할권에 달려 있습니다. 입금이 완료된 경우 반환에는 수취인의 동의 또는 면책이 필요합니다. 규정은 언제나 지침보다 우선합니다.

이러한 관행은 주로 gpi 회원은행에 적용되며, gpi에 속하지 않은 은행도 게이트웨이를 통해 참여할 수 있습니다. 최신 내용은 SWIFT의 공식 규정집을 참고하시기 바랍니다. 해당 절차는 ISO 20022 이행 등에 따라 계속 변화하고 있습니다.

SWIFT gpi의 메시징과 결제의 분리

SWIFT gpi는 주로 메시징(예: 고객 이체용 pacs.008, 금융기관 간 이체용 pacs.009 등 ISO 20022 형식 또는 기존 MT103/MT202)을 통해 지급 지시와 추적을 처리하지만, 실제 자금 이동은 결제 단계에서 별도로 이루어집니다. 결제는 일반적으로 환거래 은행 관계(노스트로/보스트로 계좌), 양자 간 차감 결제 또는 실시간 총액결제(RTGS) 시스템(예: 유럽의 T2(구 TARGET2), 미국의 Fedwire, 영국의 CHAPS)과 같은 청산·결제 메커니즘(CSM)을 통해 이루어집니다. gpi Tracker는 메시지 상태에 대한 실시간 가시성을 제공하지만, 자금 이체는 이러한 기반 시스템에 의존합니다.

국경 간 지급 지시에 대한 병행 운영 기간은 2025년 11월 22일에 종료되었습니다. MT 103 및 MT 202와 같은 지급 지시는 pacs.008 및 pacs.009와 같은 ISO 20022(MX) 메시지로 대체되었으며, 그 밖의 MT 카테고리는 이후 일정에 따라 단계적으로 폐지될 예정입니다. 아래에서는 계좌, 청산 및 결제 단계에서 반환과 보류 해제가 이루어지는 방식을 설명합니다.

계좌·청산·결제 단계에서의 자금 반환 방식
반환은 반환(리콜) 요청이 성공적으로 접수된 후(gSRP, 즉 gpi Stop and Recall Payment 서비스를 통해) 또는 독립적인 탐지(예: 사기, 오류)에 따라 개시됩니다. gSRP는 송금 은행이 보내는 camt.056(지급 취소 요청)을 사용하며, 이에 대해 camt.029(조사 결과 회신)로 응답합니다. 요청이 수락되면 자금 반환은 자금 흐름을 역전시키는 새로운 지급 지시를 통해 이루어지며, 수취 은행의 계좌를 차기하고 거래 체인을 거슬러 대기합니다. 이는 원래 메시지의 변경이 아니라 별도의 거래입니다.

주요 결제 방식 및 반환 절차
결제 방식에 따라 반환이 이루어지는 방법이 결정됩니다.

• CLRG (시장 인프라를 통한 청산): RTGS 또는 CSM(예: 중앙은행을 통한)을 통한 결제입니다. 반환 시에는 pacs.004를 사용하여 시장 인프라(MI)에 수취 에이전트의 계좌를 차변 처리하고 이전 에이전트의 계좌를 대변 처리하도록 지시하며, 이는 흔히 실시간 또는 당일 내에 이루어집니다.
• INGA(지시 대리은행 선결제): 발신자가 메시지 전송 전에 자금을 결제합니다. pacs.004를 통한 반환은 결제 완료 후 지시받은 대리은행의 계좌에서 차감됩니다.
• INDA(지시받은 대리 기관이 수신 시 결제): 수신자는 메시지 수신 시 결제합니다. 결제되지 않은 경우 pacs.002를 통해 거절하며(자금 이동 없음), 결제된 경우 pacs.004를 통해 반환합니다.
• COVE(커버 방식): 커버 이체(pacs.009 COV)를 수반하는 고액 지급에 사용됩니다. 반환은 역방향 체인을 따르며, 수취인 측 금융기관에서 중개 금융기관으로 pacs.004가 전달되고 환거래 계좌에 이에 상응하는 차기 및 대기가 이루어집니다.

결제 단계에서의 단계별 반환 절차

1. 개시 및 수락: 송신 은행이 반환 요청을 개시합니다(예: UETR을 포함한 camt.056 사용). 수신 은행은 camt.029로 회신하며, 자금이 있고 수취인에게 아직 입금되지 않은 경우 이를 수락합니다(입금 전이 더 용이합니다). 이미 입금된 경우에는 수취인의 동의 또는 면책 확약이 필요할 수 있습니다.

2. 자금 반환 지시: 수신인은 pacs.004(지급 반환) 또는 기존 방식의 MT 103/MT 202를 반환 코드(예: RETN)와 함께 발행합니다. 이 메시지에는 다음이 포함됩니다.

• 원 거래 참조번호(UETR, End-to-End ID, Instruction ID).
• 역할의 전환: 원채권자는 채무자가 되고, 원채무자의 대리은행은 채권자가 됩니다.
• 결제 세부 정보: 원 은행 간 결제 금액 및 결제일, 환율(외환 거래가 수반되는 경우), 수수료(공제된 경우).
• 반환 사유 코드(예: 폐쇄 계좌의 경우 AC04, 사기의 경우 FRAD).
• 원 메시지에 포함된 경우, 입금 계좌를 지정하기 위한 결제 계좌 필드.

3. 결제 실행:

• pacs.004는 수취 은행의 노스트로/보스트로 계좌(직전 에이전트 또는 MI에 개설된 계좌)에 대한 차기(借記)를 발생시킵니다.
• 자금은 동일한 결제 방식(예: CLRG의 RTGS 이체)을 사용하여 체인을 따라 단계별로 환입됩니다.
• 일부 반환의 경우, 추가 정보란에 "PART"를 기재하고 안분 금액을 명시하십시오.
• 트래커가 상태(예: "반환됨")를 실시간으로 업데이트하며, API 또는 GUI를 통해 확인할 수 있습니다.

4. 최종 입금: 최초 송금인의 계좌에 입금이 이루어지며, 통상 수수료가 공제됩니다. CSM을 경유하는 경우 결제는 원자적(atomic)으로 이루어지며, 양자 간 방식에서는 일과 종료 시점의 차액결제가 수반될 수 있습니다.

5. 반환 후 통지: 원장 갱신을 확인하기 위해 camt.053/054(계좌 명세서/차변·대변 통지)를 사용합니다. '반환의 반환'에 대해서는 더 이상 pacs.004를 사용하지 않으며, 대신 조회를 사용합니다.
반환은 가능한 한 자동으로 처리되나, 컴플라이언스상의 이유로 또는 자금이 동결된 경우 수작업 개입이 발생할 수 있습니다. 회수가 보장되지는 않으며, 무엇보다 회수 요청이 얼마나 신속하게 발송되었는지와 자금이 이미 입금되었는지 여부에 달려 있습니다. 미결제 상태(예: 결제 전 거절)인 경우 자금이 이동하지 않으므로, 대신 pacs.002를 사용합니다.

보류된 지급의 해제(승인)가 계좌·청산·결제 단계에서 이루어지는 방식

보류는 지급이 오류, 컴플라이언스 점검 또는 명확화 대기 등의 사유로 즉시 처리될 수 없을 때 발생하며, 지급은 결제되지 않은 '대기' 상태에 놓입니다. 문제가 해소될 때까지 자금은 출금되거나 입금되지 않습니다. gpi Tracker에는 '보류(On Hold)' 또는 '대기(Pending)'(예: PDCR 코드)와 같은 상태가 표시되며, 해소는 조회 메시지(MT 195/199 또는 camt.029)를 통해 이루어집니다.

보류 조치로 이어지는 사유

• 불일치(예: 계좌/성명 불일치 – CUTA 코드).
• 규제 점검(예: 제재 – LEGL 코드).
• 수취인의 회신(NOAS 코드) 또는 출금 권한(RQDA) 대기 중.
• 수취 은행의 영업 외 시간 또는 일괄 처리.

결제 단계의 해제 절차
1. 보류 통지: 수신 은행은 pacs.002(상태 업데이트) 또는 보류 코드가 포함된 MT 199를 송부하며, 일부만 결제된 경우(예: 커버 방식)에는 자금을 가계정/에스크로 계좌에 보류합니다.
2. 해소: 송신 은행이 정정 또는 소명 사항을 제공합니다(예: MT 195 응답 또는 camt.029). 해소되면 수신 은행이 원 지시를 처리하여 진행을 승인합니다.
3. 결제 실행:

• 원본 pacs.008/pacs.009의 보류가 해제됩니다.
• 자금은 지정된 방식에 따라 결제됩니다. 송금인의 계좌에서 출금하고 수취인 측 계좌에 입금한 후(예: CLRG의 RTGS를 통해), 최종적으로 수익자의 계좌에 입금합니다.
• 수취인 구간(수취 은행에서 최종 고객까지)은 특히 자본 통제가 있거나 인프라가 제한적인 시장에서 지연이 자주 발생하는 구간입니다.
• 추적 화면이 “입금 완료” 또는 “처리 완료”로 업데이트되며, pacs.002(지급 상태 보고서)가 이를 확인합니다.

4. 미해제 시: 해결되지 않은 경우(예: 시한 경과 후) 위와 같이 pacs.004를 통해 반환하거나, pacs.002로 거절합니다(결제 없음).

gpi 규정은 가능한 경우 당일 입금을 요구하며, Swift는 2018년에 gpi 지급 건의 거의 50%가 30분 이내에, 거의 100%가 24시간 이내에 입금되었다고 발표했습니다. 자본 통제나 은행의 업무 중단 시간 등의 요인으로 보류 기간이 길어질 수 있으나, gpi는 이를 최소화하기 위해 자동화를 중시합니다.

SwiftNet Instant

SwiftNet Instant. 24시간 연중무휴로 이용 가능한 실시간 저지연 메시징 플랫폼으로, 청산·결제 메커니즘(CSM)과 그 참가자 간의 즉시 결제 흐름을 안전하게 교환할 수 있도록 지원합니다.

고객은 VPN 장비, 전용회선, 하드웨어 보안 모듈 등 기존 Swift 연결 및 보안 인프라를 통해 SwiftNet Instant에 접속할 수 있습니다. 은행 IT 환경과의 통합은 Alliance Gateway Instant(AGI)를 통해 이루어집니다.

즉시 결제 체인에 참여하는 모든 당사자는 AGI 및 SwiftNet Instant 메시징을 이용할 수 있습니다. 활용 사례로는 오버레이 서비스를 통한 결제 개시, 간접 참가기관과 스폰서 참가기관 간의 커뮤니케이션, 기업의 결제 확인 수신 등이 있습니다.

SWIFT Instant는 각국의 즉시 결제 시스템과 연계되어 ISO 20022 표준에 따라 국내외 거래를 실시간으로 처리할 수 있도록 합니다. 이러한 시스템은 금융 업계의 결제 프로세스를 현대화하고 간소화하기 위한 지속적인 노력을 나타냅니다.

SWIFT 자동이체

SWIFT 시스템의 자동이체(direct debit)는 기업과 개인이 여러 국가의 지급인 은행 계좌에서 다양한 통화로 자금을 추심할 수 있게 하는 결제 방식입니다. SEPA 지역을 위해 특별히 설계되어 유로화 거래로 제한되는 SEPA 자동이체와 달리, SWIFT의 자동이체는 전 세계를 대상으로 하며 폭넓은 통화를 지원합니다.

SWIFT 시스템 내에서 자동이체(직불) 거래를 개시하는 절차는 통상 다음 단계로 이루어집니다.

1. 채권자와 채무자 간의 합의: 채권자와 채무자 사이에는 자동이체 거래의 이용 조건을 포함하는 기존 합의가 있어야 합니다. 이 합의에는 채권자가 채무자의 은행 계좌에서 대금을 수취할 수 있도록 하는 위임 또는 승인의 설정이 포함될 수도 있습니다.
2. 메시지 교환: 채권자의 은행이 채무자의 은행에 SWIFT 메시지를 전송하여 자동이체를 개시합니다. ISO 20022에서는 pacs.003(고객 자동이체) 또는 pacs.010(금융기관 자동이체)이며, 과거에는 MT 104 또는 MT 204였습니다. 이 메시지에는 금액, 통화, 채무자의 계좌 정보 및 기타 필요한 정보 등 거래의 세부 사항이 담겨 있습니다.
3. 검증 및 승인: 지급인 은행은 거래 내역을 검증하고, 지급인 계좌의 자금 가용 여부를 확인하며, 해당 거래에 대한 승인 여부를 확인합니다. 모든 사항이 적정한 경우 지급인 은행은 지급인 계좌에서 자금을 인출합니다.
4. 자금 이체: 자금은 환거래 계좌 또는 청산·결제 시스템을 통해 채무자의 은행과 채권자의 은행 간에 결제됩니다.
5. 확인: 자금을 수령하면 채권자의 은행은 채권자에게 확인 메시지를 발송하여 자동이체 거래가 성공적으로 완료되었음을 통지합니다.

SWIFT 시스템 내에서 자동이체 거래를 개시하기 위한 전제 조건은 다음과 같습니다.

1. 은행 계좌: 채권자와 채무자 모두 SWIFT 네트워크에 속한 금융기관에 은행 계좌를 보유해야 합니다.
2. 합의 및 권한 부여: 자동이체 거래가 가능하도록 채권자와 채무자 간에 사전 합의 및 권한 부여(위임)가 이루어져 있어야 합니다.
3. SWIFT 메시지 형식: 채권자와 그 거래 은행은 적절한 메시지 형식을 사용해야 합니다. 자동이체 개시에는 pain.008을, 은행 간에는 pacs.003 또는 pacs.010을 사용합니다.
4. 은행 수수료: 채권자와 채무자는 SWIFT 시스템 내 자동이체 거래와 관련된 수수료가 은행 및 국가에 따라 다를 수 있음을 유의하여야 합니다.

은행 간 SWIFT 메시징에서의 RMA

은행 및 금융 분야에서는 은행 간의 안전하고 효율적인 커뮤니케이션이 필수적입니다. 이 점에서 대부분의 국제 은행 간 메시지를 전달하는 SWIFT(국제은행간통신협회)가 중요한 역할을 수행합니다. 이러한 통신의 보안과 선택성을 보장하는 핵심 요소가 바로 관계 관리 애플리케이션(RMA)입니다.

RMA란 무엇입니까?

관계 관리 애플리케이션(RMA)은 금융기관이 자신에게 SWIFT 메시지를 송신할 수 있는 거래 상대방을 지정하고, SWIFT 네트워크 통신을 인증된 사용자로만 제한할 수 있도록 하는 SWIFT 소프트웨어 애플리케이션입니다. RMA는 무단 메시지를 걸러내고 사기 위험을 줄여 주므로 은행 간 통신 관리에서 핵심적인 보안 계층입니다.

RMA의 중요성

IFB와 같이 국제 금융에 종사하는 은행에 RMA 도구는 필수적입니다. 이 도구는 보안 절차를 강화할 뿐 아니라 글로벌 은행 규제의 준수도 보장합니다. 자행에 메시지를 발송할 수 있는 기관을 관리함으로써 은행은 승인되지 않은 정보 요청과 금융 지시를 차단하고 은행 자신과 고객의 이익을 모두 보호할 수 있습니다.

RMA의 작동 방식

RMA 절차는 다음과 같은 주요 단계로 이루어집니다.

1. RMA 관계 수립: 두 은행이 SWIFT를 통해 정보를 교환하기 시작하기 전에, 상호 간에 RMA를 수립하기로 합의해야 합니다. 이 합의는 디지털 방식의 악수와도 같아서, 상호 신뢰와 통신에 대한 동의를 의미합니다.
2. 키 교환: 각 은행은 RMA 애플리케이션을 통해 RMA 승인을 발송하고, 상대 은행이 이를 수락합니다. RMA는 종전의 양자 간 키 교환(BKE)을 대체하였으며, 메시지 자체는 SWIFTNet PKI(공개키 기반구조)를 통해 인증됩니다.
3. RMA 설정 구성: 각 은행은 RMA 도구를 사용하여 권한을 구성하고 상대 은행으로부터 수신을 허용할 메시지 유형을 지정합니다. 이는 포괄적인 범주로 설정하거나, 특정 메시지 유형과 하위 클래스를 포함하도록 세밀하게 조정할 수 있습니다.
4. 활성화 및 모니터링: RMA 설정이 구성되고 활성화되면 은행은 수신 메시지가 설정된 권한에 부합하는지 모니터링할 수 있습니다. 또한 RMA는 업무상 필요나 보안상 우려가 있을 경우 권한을 변경하거나 취소할 수 있는 도구를 제공합니다.

실무 적용 사례

고액자산가 및 기업 고객을 대상으로 투자 및 자산관리를 전문으로 하는 IFB에 RMA는 다음과 같은 이점을 제공합니다.

• 보안 강화: 메시지 트래픽을 통제함으로써 IFB는 고객의 거래와 민감한 정보를 무단 접근으로부터 보호할 수 있습니다.
• 업무 효율성: 신뢰할 수 있는 상대방과의 간소화된 커뮤니케이션을 통해 적법한 메시지를 더 신속하게 처리함으로써 응답 시간과 고객 만족도가 향상됩니다.
• 규제 준수: RMA는 자금세탁 및 사기와 같은 금융범죄를 방지하기 위해 정보 교환에 대한 엄격한 통제를 의무화하는 국제 은행 규제의 준수를 지원합니다.

RMA와 MT799. 은행은 해당 채널이 허용하는 경우 RMA 관계를 요청하거나 조율하기 위해 MT799를 사용할 수 있습니다. RMA 승인 자체는 RMA 시스템에서 부여되며, MT799만으로는 어떠한 권한도 활성화되지 않습니다. MT799에 필요한 RMA 승인이 없는 경우, MT799를 직접 발송하는 방식으로 이를 우회할 수 없습니다. 이 경우 설정은 승인을 교환하기 전에 상대방과 조율하도록 설계된 Swift 관계 관리 포털(Relationship Management Portal)의 RMA 커뮤니케이션 기능 또는 허용된 다른 채널을 통해 합의합니다. 따라서 'MT799를 통한 RMA'는 이에 수반되는 은행 간 서신을 의미할 수 있으며, 기술적인 RMA 승인은 별개의 단계입니다.

요약

IFB에게 RMA의 효과적인 이행은 단순한 기술적 요건이 아니라 글로벌 업무 운영에서의 전략적 자산입니다. 이는 보안과 규제 준수에 대한 은행의 의지를 강화하는 동시에 통신망의 효율성을 높입니다. 국제 금융 환경이 계속 변화함에 따라 RMA와 같은 도구는 최고 수준의 운영 건전성과 고객 서비스를 유지하고자 하는 은행에 여전히 필수적인 수단입니다.

RMA는 안전하고 선별적인 은행 간 커뮤니케이션의 근간을 이루며, SWIFT 네트워크를 통해 교환되는 모든 메시지가 최고 수준의 보안 기준을 충족하고 완전히 인증되도록 보장합니다. IFB와 같은 은행에게 RMA를 이해하고 관리하는 일은 업무를 안전하게 보호하고 글로벌 파트너와의 신뢰를 구축하는 데 필수적입니다.

Swift 디지털 블록체인 금융 지시

Swift는 2025년 9월, 30개 이상의 금융기관과 함께 공유 디지털 원장의 설계 및 개발에 착수하였다고 발표하였습니다. 2026년 7월 9일, Swift는 해당 원장이 초기 사용 준비를 마쳤음을 공표하였으며, 17개 은행이 토큰화 예금 실거래 시범 운영을 준비하고 있습니다. 참여 은행은 ANZ, BNP Paribas, BNY, Citi, DBS, First Abu Dhabi Bank, FirstRand, HSBC, Itaú Unibanco, Lloyds, Mashreq, MUFG, OCBC, Standard Chartered, UBS, UOB 및 Wells Fargo입니다. 최초의 적용 분야는 은행 간 실시간 연중무휴(24/7) 국경 간 지시를 가능하게 하는 데 중점을 둘 예정이며, 이는 국제 거래 처리 체계에 있어 핵심적인 개선입니다.

최초의 개념 검증용 프로토타입은 Consensys와 함께 구축되었습니다. 이 원장은 금융기관 간 금융 지시를 위한 안전하고 변경 불가능한 실시간 등록부로 설계되었습니다. 이 원장은 거래 메시지를 기록, 정렬 및 검증하는 한편, 스마트 컨트랙트를 통해 운영 및 컴플라이언스 규칙을 이행할 예정입니다. 상호운용성은 핵심 원칙으로, 이 원장은 기존 인프라 및 신규 인프라와 모두 연동되면서도 Swift 특유의 복원력, 신뢰성 및 규제 준수를 유지할 예정입니다.

Swift의 최고경영자 하비에르 페레스-타소(Javier Pérez-Tasso)는 다음과 같이 설명했습니다.
“공유 원장을 Swift의 기존 메시징, API 및 ISO 20022와 결합하면 더욱 강력한 구조가 만들어집니다. 이 구조는 거래 흐름의 처음부터 리스크, 통제 및 컴플라이언스 요건을 내재화하는 동시에, Swift가 지닌 신뢰성, 보안, 복원력, 확장성 및 운영 우수성을 그대로 유지하면서 24시간 연중무휴 실시간 은행 간 국경 간 지시를 가능하게 합니다. 이는 책임 있는 혁신이라는 우리의 일관된 접근 방식에 부합합니다.”

인프라 확장

공유 원장은 Swift의 기존 네트워크를 보완하는 것이며 이를 대체하지 않습니다. 이는 오케스트레이션과 상호운용성을 확장하여, 금융기관이 지시를 더 빠르고 예측 가능하게, 그리고 진정한 글로벌 규모로 교환할 수 있도록 설계되었습니다.

Pérez-Tasso는 Sibos에서 이러한 이중 트랙 접근 방식을 강조했습니다.
“금융 인프라는 운영 우수성, 규제 준수, 거버넌스라는 기본 원칙에 끊임없이 집중해야 합니다. 동시에 미래에 대비해야 합니다. Swift의 접근 방식은 두 개의 병행 트랙에서 혁신을 추진하는 것입니다.”

업계 전반에 걸친 협력

16개국의 금융기관이 공유 원장의 설계, 거버넌스 및 발전 방향을 수립하는 데 처음부터 참여하였습니다. 이러한 공동의 노력은 은행 간 지시를 위한 글로벌 인프라를 발전시키려면 규모와 협력이 필요하다는 공통된 인식을 보여줍니다.

향후 전망

공유 원장은 Swift의 기존 디지털 자산 시범 사업에서 자연스럽게 이어지는 단계이며, 공공 및 민간 네트워크 전반에 걸친 상호운용성에 대한 폭넓은 노력의 일환입니다. 이를 통해 규제 대상 토큰화 가치와 전통적 금융상품이 시스템 간에 원활하게 이동할 수 있게 됩니다.

페레스-타소는 비전을 다음과 같이 요약했습니다.
“이는 미래를 위한 강력한 플랫폼입니다. 그리고 앞으로는 더욱 혁신적인 변화를 가져올 수 있습니다.”

자주 묻는 질문

Swift 블록체인 기반 공유 원장이란 무엇입니까?
금융기관 간 금융 지시 사항에 대한 실시간 공유 기록을 제공하여 상시적이고 규정을 준수하는 국경 간 처리를 가능하게 하는 블록체인 인프라입니다.

대상 고객
더 신속하고 투명한 거래 지시를 제공해야 하며 디지털 미래에 대비하고 있는 은행 및 금융기관입니다.

어떠한 이점이 있습니까?

• 지시 사항의 실시간 가시성 확보 및 처리 순서 관리
• 스마트 계약을 통한 자동화된 컴플라이언스
• 전통 네트워크와 디지털 네트워크 간의 상호운용성
• 규제 대상 토큰화 가치 흐름의 안전한 처리

SWIFT 플랫폼과는 어떻게 연계됩니까?
SWIFT의 신뢰받는 인프라를 확장하여, 복원력, 보안 및 컴플라이언스를 유지하면서 디지털 지시 기능을 내재화합니다.

첫 번째 활용 사례는 무엇입니까?
실시간 24시간 연중무휴 국경 간 은행 간 거래 지시입니다.

참여 기관
16개국 30개 이상의 금융기관이 설계 수립에 참여하였으며, 17개 은행이 최초의 실거래를 시범 운영하고 있습니다.

언제부터 이용할 수 있습니까?
Swift는 2026년 7월 9일에 원장이 초기 사용 준비를 마쳤다고 발표했습니다. 시범 참여 은행들은 통제된 개시 단계에서 초기 실거래를 진행하며, 최종 결제는 여전히 기존 시스템을 통해 이루어집니다. 기능과 이용 범위는 이후 단계적으로 확대될 예정입니다.

환거래 은행 체계를 통한 자금 이체 방법에 대해 더 알고 싶으시면, 환거래 은행 업무 총괄 책임자 M. Amri Elarisse에게 문의해 주시기 바랍니다.