SWIFT

SWIFT转账及MT与MX报文通信

SWIFT(环球银行金融电信协会)是一个安全的报文网络,使银行等金融机构能够收发有关金融交易的标准化报文,例如付款指令和确认。SWIFT 不持有账户,也不转移资金,仅提供一个安全可靠的信息交换平台。

常规SWIFT转账使用一系列标准化的报文类型,即MT(Message Type,报文类型)报文。这些报文具有预先定义的格式和字段,确保金融机构能够轻松理解并处理其中所含信息。

MX(ISO 20022)报文是基于XML(可扩展标记语言)的较新金融报文标准。其格式更丰富、结构更严谨,可实现更充分的数据交换,并改善直通式处理。MX报文正逐步取代SWIFT网络中的MT报文,旨在提供更好的互操作性和数据处理能力。

传统的SWIFT转账数十年来一直是国际支付的支柱，但也存在一些局限，包括透明度有限、处理速度较慢以及数据非结构化。

Swift 103+ STP(直通式处理)

Swift 103+ STP 是针对直通式处理(STP)优化的传统 MT 格式;并行期结束后,其职能由 pacs.008 STP 使用指引取代。STP 使整个支付流程从发起到最终结算均可通过电子方式完成,无需人工干预。

其他特点:

1. 标准化格式:要求严格遵循标准化格式,以减少差错和延误。
2. 自动化处理:交易自动处理,确保处理更快捷、更高效。
3. 减少人工干预:将人工录入与核验降至最低,降低出错和延误的风险。
4. 更快结算:与传统方式相比,交易结算速度更快。

直通式处理(STP)的考量因素:

1. 数据录入准确:数据必须准确录入,以避免延误或被退回。
2. 符合格式要求:银行必须确保严格遵循103+ STP的格式要求。
3. 软件与系统:银行需要配备适当的软件和系统,以有效处理直通式处理(STP)

必须区分报文传递与资金结算。SWIFT在机构之间传送结构化金融报文,但其本身不划转资金,也不持有余额。SWIFT确认(包括pacs.008报文)仅在其对应于参与机构银行系统内实际处理并完成对账的交易时方为有效。

任何未经机构核实而单独出示的SWIFT文件、截图或消息,均不应被视为已完成结算的证据。

SWIFT gpi 转账。

SWIFT gpi(全球支付创新):

SWIFT gpi于2017年推出,旨在解决传统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时生成UETR,但对非gpi机构而言传递该编号属可选)。具体要求可能因司法管辖区、币种及双边协议而异,但核心参数源自CBPR+(跨境支付与报告增强版)指引及ISO 20022标准。自2025年11月22日共存期结束后,跨境支付指令以ISO 20022格式交换;下文提及的传统MT字段仅供参考。
1. 当事方识别(付款人与收款人详情)
这些信息用于识别发起人和受益人,以确保符合FATF第16号建议中的“旅行规则”要求。

• 债务人/汇款人:全名、结构化地址(街道、城市、邮政编码、国家)及账户标识(如IBAN或账号)。在原有的MT103/MT202 COV中,对应字段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. 代理行及路由信息
列明资金链中所涉及的金融机构。

• 付款方代理行:发送行的BIC(银行识别码)或其他标识符。对应原MT103中的52a栏;在pacs.008/pacs.009中为<DbtrAgt>。
• 收款人代理行:收款银行的BIC。对应原MT 103/MT 202 COV中的第57a栏;在pacs.008/pacs.009中对应<CdtrAgt>。
• 中间代理行(如已知):任何代理行的BIC(最多三级)。对应原MT报文中的字段56a;在pacs.008/pacs.009中为<IntrmyAgt1-3>。
• 指示方/被指示方代理行:链条中直接发送方/接收方的BIC。为可选项,有助于采用串行方式或头寸覆盖(cover)方式。
• 前序指示代理行(如适用):对于多跳链路,最多列明3家前序代理行。

必要性:确保中间机构路由正确;在pacs.009 COV中,为求精确,应使用BICFI而非名称。

3. 交易详情
用于结算的核心财务要素。

• 金额与币种:银行间结算金额及ISO 4217币种代码(例如USD、EUR)。对应原MT103/MT202 COV中的32A域;在pacs.008/pacs.009中为<IntrBkSttlmAmt>。
• 指示金额(如有不同):扣除费用前的原始金额。
• 银行间结算日:结算的起息日。对应MT报文中字段32A的一部分;在pacs.008/pacs.009中对应<IntrBkSttlmDt>。
• 结算方式:注明是通过RTGS(CLRG)、头寸偿付(COVE)还是代理行(INDA/INGA)。无直接对应的MT报文,但可隐含体现。

必填原因:界定价值转移;所有格式均为必填项。

4. 参考编号与追踪标识
用于确保可追溯性,尤其适用于gpi。

• 端到端标识:贯穿整个业务链的参考编号(例如发票或交易编号)。即pacs.008/pacs.009中的<EndToEndId>。
• 指令标识:发送方参考号(在MT中限16个字符)。对应原MT报文的第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服务(例如G001表示gpi客户贷记转账);非gpi银行除非另有约定,不应包含gpi专用代码。对应MT报文中的第23E栏;pacs.008/pacs.009中的<SvcLvl>。
• 本地工具代码:适用于特定业务方案(例如集团内部转账)。

必要性:确保合规及处理优先级;在ISO标准迁移之后,这一要求正日益成为强制性规定。

6. 汇款及附加指示

• 汇款附言:非结构化(最多140个字符)或结构化(如发票详情)。对应原MT 103中的第70栏;在pacs.008/pacs.009中对应<RmtInf>。
• 代理行指示:例如/REC/表示致接收行的指示,/ACC/表示账户,或电话指示(PHOB)。对应原MT报文中的第72栏;在pacs.008/pacs.009中对应<InstrForNxtAgt>/<InstrForCdtrAgt>。
• 结算时间指示:所要求的时间(例如CLS时间的CLSTm)。

必要性说明:提供背景信息和处理指示;对pacs.009 COV中的头寸偿付(cover)方式至关重要。

7. 监管与合规数据

• 监管报告:代码或详细信息(如税务识别号、CRED/DEB等报告标识)。对应MT报文中的第77B域;对应pacs.008/pacs.009中的<RgltryRptg>。
• 退回原因代码(如适用于退回):例如,AC04表示账户已关闭,在pacs.004中与原始报文相关联。

必要性：满足AML/KYC及报告义务；在受监管的汇路中属强制性要求。

作为最佳实践,非gpi参与行应当合理设置数据结构,以避免在MT至MX转换过程中出现数据截断,并就具体需求咨询gpi成员银行。如付款涉及头寸偿付(cover)方式,则各报文中的基础客户信息必须保持一致(例如由pacs.008至pacs.009 COV)。

SWIFT gpi中的支付报文

在SWIFT gpi(全球支付创新)框架下,原始支付报文(例如用于客户汇款的pacs.008或用于覆盖汇款的pacs.009 COV)一经发出即被视为不可更改。收款银行无法直接更改这些报文的内容,因为SWIFT报文的设计旨在整个支付链条中保持完整性和可审计性。任何变更、更正或撤销均通过单独的后续报文、经由gpi Tracker的状态更新,或gSRP(gpi止付与召回)等专门服务办理。这样可借助唯一端到端交易参考号(UETR)确保端到端可追溯。

不过,接收银行(通常作为债权人代理行或中间机构)可以回应发送方的变更请求,或采取行动,从而实际改变付款结果(例如退汇或暂停处理)。在特定条件下,接收银行亦可要求发送方予以澄清或修改。这些流程受SWIFT规则手册、市场惯例指引(例如支付市场惯例工作组PMPG的指引)及监管要求约束,并以自动化、透明度和欺诈防范为优先。

收款银行请求或协助变更的条件
当原始付款无法按指示处理时,收款银行可请求变更(如更正详细信息),或采取表明需要变更的行动。此类操作通常通过查询报文(如MT 195/199)或对发送方发起的请求作出答复来完成。主要条件包括:

• 付款详情有误:如存在不准确之处,例如收款账户有误(如账户已关闭——代码AC04)、币种错误(代码CURR)、代理行路由有误(代码AGNT)或技术问题(代码TECH),收款银行可暂扣该笔付款,并要求付款方提供更正后的信息或重新发送付款。这既可避免直接拒绝,又为问题的解决留出空间。
• 无法入账:根据代码CUTA(Cancel Upon Unable to Apply,无法入账时取消),若因不匹配(如户名/账号不符或信息不足)导致款项无法入账,收款银行可要求汇款行提供取消或修改的详细信息,以便予以纠正。
• 涉嫌欺诈或未经授权的交易:对于欺诈(代码FRAD),收款银行可自行发现问题,并在无需汇款方事先请求的情况下启动资金退回。对于汇款方的召回请求,若资金已入账,收款银行亦可先行冻结资金并要求提供赔偿保证(代码INDM),以便在退款前缓释风险。
• 重复或不当付款:DUPL(重复付款)或UPAY(不当付款)等代码使收款银行能够在交易有误或缺乏正当依据时予以标记并要求撤销。
• 监管或合规问题:如该笔付款违反当地法律、制裁规定或AML要求(代码LEGL),收款行可拒绝或暂扣该笔付款,并要求付款方补充提供文件或作出修改。
• 客户或收款人的决定:如收款人拒收款项(代码CUST或NOAS——收款人无回应),收款行可予以退回并通知付款方,并可能要求其确认相关变更。
• 待决事项:对于待处理事项(代码PDCR),例如等待借记授权(RQDA)或下一代理行答复(PTNA),收款银行可暂缓该笔付款,并要求进一步指示或修改,以便继续处理。

在所有情形下,请求均须按自动化要求构建(例如包含UETR、原始参考号如第20/32A/50/59字段,以及报文第79字段中的特定代码),以支持直通式处理。如资金已入账,可能需要双方签订赔偿协议;收款银行无义务接受相关请求,但须优先处理紧急请求(如与欺诈有关的请求)。

涉及的流程

• 对发送方发起的召回的回应:发送方(付款人代理行)通常通过gSRP服务以MT 192/292(或ISO 20022的对应报文,如camt.056)发起召回,沿付款链逐级发送或直接发送至接收银行。接收银行须立即确认,并使用MT 196/296(或结构化时使用MT 199/299)作出回应,采用CNCL(已取消)、RJCR(附理由拒绝)或PDCR(待处理)等代码。如获接受,资金将通过pacs.004(付款退回)返还。
• 收款银行的自主行动:如在内部发现欺诈,收款银行可使用带有结构化详细信息的pacs.004退回资金,并通过Tracker通知,以便实时更新状态。
• 修改/澄清请求:收款银行使用查询类报文(例如MT 195/295)请求更改,例如补充详细信息。这在被搁置的付款中较为常见。
• 跟踪器集成:所有操作均实时更新gpi Tracker,可通过API或图形界面访问,确保各方可见。gpi成员必须遵守gCCT(客户贷记转账)、gCOV(覆盖付款)和gSRP的强制性规则手册。
• 局限与成功要素:变更并无保证,能否成功取决于支付所处阶段(入账前更易办理)、受益人的配合以及司法管辖区。如已入账,退回须经受益人同意或提供赔偿保证。法规始终优先于指引。

这些做法主要适用于 gpi 成员行,但非 gpi 银行可通过网关参与。如需最新详情,请查阅 SWIFT 的官方规则手册,因为相关流程在不断演进(例如随 ISO 20022 迁移而变化)。

SWIFT gpi中的报文传送与结算分离

SWIFT gpi 主要通过报文处理支付指令并提供追踪(例如用于客户汇款的 pacs.008、用于金融机构间转账的 pacs.009 等 ISO 20022 格式,或传统的 MT103/MT202),但资金的实际划转在结算层面另行进行。结算通常通过代理行关系(往来账户(Nostro)/来账账户(Vostro))、双边轧差或清算与结算机制(CSM)完成,例如实时全额结算(RTGS)系统(如欧洲的 T2(原 TARGET2)、美国的 Fedwire 或英国的 CHAPS)。gpi Tracker 可实时显示报文状态,但资金转移依赖于上述底层系统。

跨境支付指令的共存期已于2025年11月22日结束:MT 103和MT 202等支付指令已由pacs.008和pacs.009等ISO 20022(MX)报文取代,其他MT类别则将于后续日期陆续停用。以下说明退回及冻结解除在账户、清算和结算层面如何发生。

账户/清算/结算层面的资金退回方式
退回在召回请求成功(通过gSRP——gpi止付与召回服务)或经独立发现(如欺诈、差错)后启动。gSRP使用发送方发出的camt.056(付款撤销请求),并以camt.029(调查结果答复)作出回应。一经接受,资金退回即通过一笔新的付款指令执行,该指令使资金流向反转,借记收款行账户,并沿原链路贷记退回。这并非对原始报文的更改,而是一笔独立的交易。

主要结算方式与退回流程
结算方式决定退回的发生方式:

• CLRG(通过市场基础设施清算):通过RTGS或CSM(例如经由中央银行)进行结算。退回款项使用pacs.004指示市场基础设施借记接收代理行的账户并贷记前一代理行的账户,通常为实时或当日完成。
• INGA(指示代理行先行结算):发送方在发送报文前先行结算资金。通过pacs.004办理的退回在结算后借记被指示代理行的账户。
• INDA(受指示代理行于收到时结算):接收方在收到报文时结算。若未结算,则通过pacs.002拒绝(无资金划转);若已结算,则通过pacs.004退回。
• COVE(覆盖法):用于附带覆盖款划转(pacs.009 COV)的大额付款。退汇沿反向链路进行:由受益人代理行经各中间行逐级回传pacs.004,并相应借记/贷记代理行账户。

结算层面的退回流程(分步说明)

1. 发起与接受:发送方提出召回请求(例如通过附带UETR的camt.056报文)。接收方作出答复(camt.029),如资金可用或尚未记入收款人账户(入账前更易办理),则予以接受。如资金已入账,可能需要获得收款人同意或出具赔偿保证。

2. 资金退回指令:收款方发出pacs.004(支付退回)或带有退回代码(如RETN)的传统MT 103/MT 202报文。该报文包括:

• 原始参考编号(UETR、端到端标识、指令标识)。
• 角色互换:原债权人变为债务人;原债务人代理行变为债权人。
• 结算详情:原始银行间结算金额/日期、汇率(如涉及外汇)、费用(如已扣除)。
• 退回原因代码(例如:AC04 表示账户已关闭,FRAD 表示欺诈)。
• 结算账户字段(如原始报文中包含),用于指明贷记账户。

3. 结算执行:

• pacs.004触发从接收银行的往来账户(Nostro)/来账账户(Vostro)(于前手代理行或MI处开立)中扣款。
• 资金沿链路逐跳回记,采用相同的结算方式(例如CLRG中的RTGS划转)。
• 如为部分退回,请在“附加信息”中注明“PART”及按比例计算的金额。
• 跟踪系统实时更新状态(例如“已退回”),可通过API或图形界面查看。

4. 最终入账:原始发送方账户获得入账,通常已扣除费用。如通过CSM办理,则为原子结算;在双边安排下,可能涉及日终轧差。

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年报告称,近50%的gpi支付在30分钟内入账,几乎100%在24小时内入账。资本管制或银行离线时段等因素可能延长资金占压时间,但gpi强调通过自动化尽量缩短这一时间。

SwiftNet Instant

SwiftNet Instant。这是一个实时、低延迟的报文平台,全天候可用,支持清算与结算机制(CSM)及其参与者之间即时支付流的安全交换。

客户可通过其现有的Swift连接及安全基础设施(包括VPN设备、专线和硬件安全模块)接入SwiftNet Instant。与银行IT环境的集成通过Alliance Gateway Instant(AGI)实现。

即时支付链条上的所有参与方均可使用AGI和SwiftNet Instant报文服务。应用场景包括:通过叠加服务发起支付、间接成员与其担保成员之间的通信,或企业收到付款确认。

SWIFT Instant 与各国国内即时支付系统相连,依托 ISO 20022 标准,实现境内及跨境交易的实时处理。这些系统体现了金融业持续推进支付流程现代化与简化的努力。

SWIFT 直接借记

SWIFT体系中的直接借记是一种支付方式,使企业和个人能够从多个国家的付款人银行账户中以多种货币收款。与专为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?

关系管理应用(Relationship Management Application,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。在通道允许的情况下,银行可使用MT799请求或协调RMA关系。RMA授权本身在RMA系统中授予;仅凭MT799不能激活任何权限。如缺少MT799所需的RMA授权,则不能通过直接发送MT799来绕过。此时应通过Swift关系管理门户的RMA通信功能(该功能专为在交换授权之前与对手方协调而设计)或其他获许可的渠道商定相关设置。因此,“通过MT799办理RMA”可用于描述随附的银行往来函电;技术层面的RMA授权是单独的一个步骤。

简言之

对IFB而言,有效实施RMA不仅是一项技术要求,更是其全球运营中的战略资产。它强化了本行对安全与监管合规的承诺,同时提升了通信网络的效率。随着国际金融环境持续演变,RMA等工具对于致力于维持最高运营诚信与客户服务标准的银行而言,依然不可或缺。

RMA是安全且具选择性的银行间通信的基础,确保通过SWIFT网络交换的每一条报文均符合最高安全标准并经过完整认证。对于IFB等银行而言,了解并管理RMA对于保障自身运营安全、建立与全球合作伙伴的信任至关重要。

Swift 数字区块链金融指令

2025年9月,Swift宣布已联合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。首个应用将侧重于实现银行之间实时、全天候的跨境指令传递,这是对国际交易处理体系的一项关键提升。

首个概念原型与Consensys合作构建。该账本被设计为机构间金融指令的安全、不可篡改的实时登记簿,将记录、排序并验证交易报文,同时通过智能合约执行运营与合规规则。互操作性是核心原则:该账本将同时连接现有及新兴基础设施,并保持Swift一贯的韧性、可信度与监管合规性。

正如Swift首席执行官Javier Pérez-Tasso所言:
“将共享账本与Swift现有的报文、API及ISO 20022相结合,可构建出更为强大的架构——自一开始便将风险、控制和合规要求嵌入交易流程,同时实现全天候24/7的实时跨境银行间指令传递,并保持Swift一贯享有盛誉的信任、安全、韧性、可扩展性和卓越运营。这一切均符合我们始终秉持的负责任创新方针。”

基础设施的延伸

共享账本是对 Swift 现有支付通道的补充,而非取而代之。其设计旨在扩展业务编排与互操作能力,使金融机构能够以更快的速度、更高的可预期性,在真正的全球范围内交换指令。

在Sibos大会上,Pérez-Tasso强调了这一双轨并行的路径:
“金融基础设施需要始终专注于卓越运营、监管合规与治理这些根本要素。与此同时,它们还需要为未来做好准备。而在Swift,我们的做法是沿着两条并行的轨道进行创新。”

全行业协作

来自16个国家的金融机构自始即参与共享账本的设计、治理及发展路径的制定。这一集体努力彰显了一项共同认识:推进银行间指令的全球基础设施建设,需要规模与协作。

展望未来

共享账本是Swift早期数字资产试验的自然延伸,也是其致力于公有与私有网络之间互操作性这一更广泛承诺的一部分。这将使受监管的代币化价值与传统工具能够在各系统之间顺畅流转。

佩雷斯-塔索(Pérez-Tasso)概括了这一愿景:
“这是面向未来的强大平台。未来,它还将带来更具变革性的影响。”

常见问题

什么是Swift基于区块链的共享账本?
这是一种区块链基础设施,可在机构之间提供金融指令的共享实时记录,支持持续、合规的跨境处理。

适用对象
须提供更快速、更透明的交易指令并为数字化未来做好准备的银行及金融机构。

有哪些益处?

• 指令的实时可视化与排序
• 通过智能合约实现自动化合规
• 传统网络与数字网络之间的互操作性
• 对受监管的代币化价值流进行安全处理

它如何与SWIFT平台契合?
它拓展了SWIFT值得信赖的基础设施,在保持稳健性、安全性与合规性的同时,嵌入数字化指令功能。

首个应用场景是什么?
实时、全天候的跨境银行间交易指令。

有哪些机构参与?
来自16个国家的30多家金融机构参与了方案设计;17家银行正在试点首批实际交易。

何时可用?
Swift已宣布该账本于2026年7月9日可供初步使用。试点银行将在受控的上线阶段开展首批实际交易;最终结算仍通过现有系统进行。其功能和可用范围将在此后逐步扩展。

如欲进一步了解如何通过代理行体系划转资金,请联系本行代理行业务负责人 M. Amri Elarisse。