本页面为方便阅读而提供的译文,以英文版本为准。阅读英文版

其他转账方式

IP/IP 及 IPZip 转账

在IFB开通IPIP、IPZip服务

IPIP融资安排将在客户账户处于良好状态时,经客户申请后启用:

其维持最低余额,
具有持续稳健的财务业绩记录,并且
与合法商业活动相符。

此外,该账户还必须具有

无未决合规问题,并且
所有交易均须遵守国际金融法规。

最终激活须经我行合规及风险管理团队的内部审查和批准。

报文不是资金

90秒讲清:为何没有结算,任何SWIFT报文、电传或服务器都无法划转资金。

使用VL1验证文件 →

收到付款报文、凭条或确认函?在依赖之前,请先进行核验。

我们的IPIP及IPZip服务

我们向经甄选的高净值个人客户及信誉良好的公司客户提供IPIP及IPZip服务,尤其注重审慎、保密和机构诚信。

所有 IPIP 及 IPZip 交易仅在已全面接入国际银行体系的银行之间进行,不仅确保经认证的 IPIP 报文得以安全交换,也确保资金得到有效、及时的结算。未接入该体系的交易对手方或许能够发送报文,但在本质上无法完成资金结算。

根据经验，向我们提交的IPIP交易中，超过86%来自非银行实体，或来自不具备资金发送能力的银行。

相比之下,本行可不受金额限制开展交易,唯须对发起机构及其切实具备的结算能力进行严格核实。

验证实体及参与方无关联银行

IP对IP(IPIP)

IP 对 IP 转账是指利用互联网协议(IP)地址,在不同金融机构或系统之间转移货币、资产、负债和权益(来自代理行账户或数据)的流程中的一个环节。在金融交易中,IP 地址是分配给每台联网设备的唯一数字标识,用于在不同系统之间路由信息。银行业中的 IP 对 IP 转账是指两个系统通过各自的 IP 地址直接通信,以完成金融交易。此外还采用专门的认证与授权方法,以保障信息的完整性和安全性。

但需要指出的是,IP对IP转账在银行业中并不常见,也不被推荐,原因多种多样,包括安全性、可靠性和合规方面的顾虑。以下几点对这些顾虑作出说明:

安全性:与SWIFT或ACH等成熟的银行网络相比,IP到IP转账的安全性可能较低,后者实施多层安全、加密和身份验证措施。两个IP地址之间的直接通信可能使敏感信息面临潜在的安全威胁,包括黑客攻击、网络钓鱼或中间人攻击。
可靠性:使用IP对IP转账无法保证交易的可靠性,因为银行业内尚无普遍认可的、适用于基于IP的转账的标准或协议。这可能导致交易处理、跟踪和对账方面的潜在问题。
合规:银行和金融机构须遵守众多法规和要求,包括反洗钱(AML)和了解你的客户(KYC)政策。IP到IP的转账可能不符合这些监管要求,从而可能使相关各方面临法律和财务风险。

银行和金融机构更倾向于使用成熟的网络,如SWIFT、RTGS或ACH/即时支付,以及ISO 20022等报文标准,以促进不同机构之间安全、可靠且合规的资金转账,而非采用IP到IP的转账方式。

IP to IP 货币转账结构

实际资金划转:这些协议擅长传输交易详情,例如报文和指令,但并不负责资金的实际转移。要实现资金的实际划转,代理行业务、实时全额结算(RTGS)和实时支付(RTP)等系统不可或缺。

在代理行业务中,资金在不同银行的账户之间划转。
在实时全额结算(RTGS)系统中,资金在各银行于中央银行开立的结算账户之间划转。
同样,在RTP系统中,资金在清算账户之间划转。

这些系统对于货币资产的实际划转至关重要。因此,发送银行不仅须具备IP对IP的连接能力,还须与银行系统实现全面集成。

两个不同的层级:

指令层面及实际资金划转层面

IPIP协议

FIX(Financial Information eXchange,金融信息交换协议):证券交易的消息传递标准:用于经纪商、交易所与投资者之间的订单、成交和分配。它传递的是交易数据,而非支付信息。
EBICS(电子银行互联网通信标准):公司客户与其银行之间安全交换文件的标准,主要用于德国、法国、瑞士和奥地利,传输支付文件和对账单。
全银(Zengin):全银系统是日本国内银行间资金划拨网络,全银文件格式用于国内转账和直接扣款。
AS2(适用性声明2):一种通过互联网对商业文件(EDI、XML)进行安全签名传输的协议,并以回执确认送达。
SNMPv3(简单网络管理协议第3版):一种用于监控和管理网络设备的协议,具备认证和加密功能。它用于管理基础设施,不承载交易。
Kerberos:一种网络认证协议,使用由受信任服务器签发的票据,使客户端与服务能够相互证明身份。
OAuth 2.0: 一种委托授权的开放标准:应用程序获取受限的访问令牌,而无需使用用户密码。大多数开放银行API均以此为基础。
基于TLS的LDAP:对目录服务的安全访问,目录服务中存储用户身份和访问权限。
基于SSH的SFTP和SCP:服务器之间的加密文件传输和复制,广泛用于支付和对账单文件。

上述每一项协议均用于保护数据交换或系统访问。在涉及货币、银行资产、负债及权益划转的IPIP交易中,上述协议虽属必要,但尚不足以完成金融交易:

向本行进行IPIP资金划转

如果 pacs.008 是通过 IPIP 而非 SWIFT 发送给我们的,为缓解部分合规方面的顾虑,可考虑请贵方汇出行在代理行与代理行之间资金传送所使用的 pacs.009 COV 中(在格式允许的情况下)加入以下补充信息:

汇款人信息：提供汇款人的详细信息，与MT103中的第50域类似，可包括姓名、地址和账号。
受益人信息:包含受益人的详细信息,对应MT103中的第59栏。应包括受益人名称、地址和账号
付款目的:明确说明交易原因,这有助于缓解部分反洗钱(AML)方面的关注。
监管报告信息:如您所在司法管辖区有要求,请填写用于监管报告的代码或标识符。
引用IPIP pacs.008:明确说明该pacs.009 COV与某笔IPIP pacs.008相关联,可为中间行提供背景信息。
联系信息:请提供负责该笔付款的合规部门或交易经理的具体联系方式,以便收款银行需要立即澄清时使用。
特别处理指示:向收款银行提供的、有助于识别并妥善处理所转移资金的任何额外指示。
收费信息:在没有SWIFT pacs.008的情况下,最好明确由谁承担与交易相关的费用,以避免产生误解。
附加标识符:包含可将pacs.009 COV与IPIP pacs.008相关联的任何附加交易标识符,例如发票编号或内部交易ID。

合规说明

在pacs.009 COV中加入额外信息,未必能完全化解合规风险,尤其是通常通过SWIFT pacs.008报文处理的AML与CFT(反恐融资)核查;同时务必确保修改后的pacs.009 COV仍符合适用标准及银行间协议。

银行中通信服务器与分类账/账户服务器的主要区别

在银行技术领域,服务器对于确保金融交易和记录保存的顺畅运行起着决定性作用。银行依赖的两类主要服务器是通信服务器和分类账/账户服务器。二者虽然都至关重要,但用途不同,处理的数据类型也各异。

通信服务器

通信服务器是银行与金融机构之间安全数据交换的支柱。通信服务器的主要功能和特点如下:

安全数据交换:这些服务器促进安全的数据交换,确保敏感金融信息能够在机构之间传输而不受损害。
协议与标准:其采用SWIFT、Sepa或ACH等标准化协议进行银行间通信,确保不同平台之间的一致性与可靠性。
加密与认证:为保障安全,通信服务器采用先进的加密方法和严格的认证协议,确保数据在传输过程中的安全。
交易处理:其主要职能是处理交易请求、报文和指令,作为中介传递交易所需的信息。
不涉及资金划转:重要的是,这些服务器不直接划转资金或更新账户余额;它们仅为上述操作所需的通信提供支持。

账簿/账户服务器

另一方面,账簿/账户服务器是银行财务记录的保管者。其主要特点如下:

财务记录维护:这些服务器存储并维护本行的核心财务记录,确保每一笔交易均被准确记录。
交易记录:负责记录所有交易(包括借方和贷方分录),并负责更新和保存当前账户余额。
总分类账管理:账务服务器管理银行的总分类账及各客户账户,从而提供财务状况的完整视图。
数据完整性：确保数据的一致性和完整性至关重要，因为这些记录对于准确的财务报告和合规必不可少。
严格的安全措施:鉴于数据的敏感性,账本服务器通常采用更为严格的安全措施,包括额外的加密层级和严密的访问控制。

通信服务器发起并促成交易,而账簿服务器则在验证后最终将这些交易记录并反映在银行账簿中。

在当代银行体系中,这些功能往往相互整合,安全的行内通信协议与分类账管理系统协同运作。这种整合确保整个银行金融体系内的实时更新与一致性,既提高效率,又增强安全性。许多银行综合使用本地部署与云端服务器,以兼顾安全、合规和可扩展性要求。

银行与银行之间可以转移哪些内容?

银行资产:

现金及现金等价物:指可立即或几乎立即动用的资金,包括实物现金、存放于其他银行的存款,以及国库券等高流动性证券。
投资/证券:这些是银行为获取回报而投资的金融工具,例如政府债券和公司债券、股票及其他证券。
贷款及垫款:这是银行向客户发放的资金,可产生利息收入,包括个人贷款、抵押贷款、商业贷款、信用卡余额及透支。
固定资产:指银行拥有的有形财产,如建筑物、土地、设备和家具。
无形资产:包括软件、专利、商标和商誉等非实物资产。
其他资产：可包括应收应计利息、递延所得税资产和衍生金融工具等。

银行负债:

存款:指个人和企业存放于银行的资金,包括活期账户、储蓄账户和定期存款。存款属于负债,因为银行有义务在存款人要求时或在特定到期日向其返还这些资金。
借入资金:指银行向其他金融机构、中央银行借入的资金,或通过发行债务证券筹集的资金。
债务证券:指本行为筹集资金而发行的债券或其他形式的债务工具。本行有义务向债券持有人偿还本金并支付利息。
其他负债:包括应计费用、应付账款、递延所得税负债、贷款损失准备以及衍生金融工具等项目。
次级负债:此类债务在银行破产时,须在所有其他债务清偿之后方予偿付。

银行自有权益:

普通股:这是银行所有者持有的股权。普通股股东享有表决权,并可获得股息。
优先股:此类股权对收益和资产的求偿权高于普通股,但通常不附带表决权。
留存收益:指银行历年累积的净利润,银行选择将其再投资于业务而非以股息形式分配。
库存股:指本行从市场回购的自身股份。
其他综合收益：尚未计入损益的利得和损失，例如某些投资及对冲工具的重估。
非控制性权益(少数股东权益):指子公司净资产中归属于非由母公司直接或通过子公司间接持有的权益的部分。

资产、负债及权益的实际转移:证券的转移由中央证券存管机构(CSD)登记,其保存所有权的法律记录;贷款、固定资产及其他头寸则依据适用法律,通过转让或转移协议完成转移。这两类转移均不在通信协议的范围之内。资产和权益的转移还会影响银行的财务报表,改变负债、资产及权益余额。向相关监管机构进行的此类财务报告以及必要的合规事项,超出了协议的数据传输能力,需要另行履行财务和监管程序。

总之,尽管各项协议对于在IPIP交易中安全、高效地交换信息至关重要,但完整的流程还涉及其他系统,用于实际的货币、资产、负债及权益的划转、结算、法律登记和财务报告,以确保整个交易符合银行监管标准。

IP ZIP 转账

机构付款指令的安全文件传输

IP ZIP 转账可理解为一种安全的、基于文件的方式,通过互联网协议网络,在经认证的机构系统之间直接传输结构化的支付指令及相关交易数据。

术语的使用须格外精确。

IP ZIP传输并非清算系统、结算系统、支付通道,亦非独立的货币价值转移机制。ZIP压缩包只是传输容器,IP连接只是通信渠道,压缩包内所含信息构成指令、数据集或交易报文。

因此:

IP ZIP传输支付信息和指令,其本身并不结算资金。

从概念上讲,这与适用于ISO 20022 pacs.008(金融机构间客户信用转账)报文的区分相类似。pacs.008可以承载高度结构化的银行间信用转账指令,但该报文本身不得与中央银行货币、商业银行货币或代理账户余额的最终划转和结算相混淆。

同一原则同样适用于IP ZIP传输。

1. 技术架构

一笔结构完善的IP ZIP交易可如左图所示。

因此,关键区别在于传输层、指令层与结算层之间的划分。

这些层面不得混为一谈。

2. ZIP文件作为安全交易容器

ZIP组件主要用作容器化及打包机制。

发起机构可将相关文件汇集为单一受控数据包,而无需分别传送各个交易组成部分。

根据双方约定的具体规格,此类文件包可包含:

结构化支付指令;
XML支付报文;
兼容ISO 20022的数据集;
JSON 交易对象;
CSV或固定格式的交易记录;
专有格式的银行间支付文件;
债务人及债权人信息;
付款方及收款方账户信息;
交易标识符;
币种及金额信息;
要求的执行日期和起息日;
代理行指令;
中间行信息;
汇款附言信息;
结算路由信息;
合规文件;
KYC或KYB参考资料;
资金来源信息；
交易清单；
数字签名;
加密哈希值;
证书;
时间戳;
对账文件;以及
控制总额。

因此,存档可能既包含主要支付指令,也包含对该指令进行认证、验证、处理和对账所需的附属信息。

压缩在技术上属于附带环节,主要目的在于受控打包与传输。

因此,ZIP压缩包绝不应被视为其中所列资金存在、可用、无权利负担或已结算的证据。

3. 结构化支付指令

如设计得当,IP ZIP 数据包中所含的付款指令可发挥类似于传统结构化金融报文的功能。

例如,机构可传送一条XML指令,其中包含与ISO 20022 pacs.008报文中通常所载信息相对应的字段,包括:

报文标识；
创建日期和时间;
交易笔数;
结算信息;
指令代理行;
被指示代理行;
债务人;
付款人账户;
债务人代理行;
债权人代理行;
债权人;
收款人账户;
指示金额;
货币;
费用承担方;
付款识别;
端到端标识;以及
汇款附言信息。

关键区别在于:数据结构并不决定结算机制。

一项技术上有效的支付指令可能已被接收系统接收、认证并接受,而相应的资金结算仍未完成。

因此:

收到指令 ≠ 收到资金

指令经验证 ≠ 资金已结算

文件成功导入 ≠ 收款人已收到最终资金

服务器确认 ≠ 结算确认

这一区分是IFB处理替代性转账方式的根本依据。

4. 传输协议

机构IP ZIP传输应仅通过受控且经过认证的通信环境进行。

视双边技术安排而定,传输可采用下列技术:

SFTP

基于SSH的安全文件传输协议提供加密传输、服务器认证及受控的用户认证。

对于机构间的系统连接,一般应优先采用公钥认证,而非仅凭密码的认证方式。

FTPS

在传统基础设施有此需要的情况下,FTP可通过TLS加以保护,前提是实施适当的证书验证、加密标准和访问控制。

HTTPS / REST API

该文件包可通过经认证的HTTPS端点或API架构传输,并采用TLS及适当的应用层认证。

双向TLS

对于更高保障等级的机构连接,双向TLS(mTLS)允许两端通过数字证书相互验证身份。

相比仅采用单向服务器认证,这为防范未经授权的终端提供了实质性更强的保护。

VPN

在应用层传输发生之前,可通过站点到站点的IPSec或同等VPN在参与机构之间建立加密的专用隧道。

专属私有连接

若交易量、安全要求或机构风险状况有此需要,可采用专用或私有网络连接,以补充或取代通过公共互联网的传输。

在业务启用之前,必须经双方商定确切的协议。

5. 终端认证

接收机构必须确认该传输确实来自其所称代表的机构。

相关控制措施可包括:

机构数字证书;
SSH公钥/私钥对;
双向TLS证书;
API凭证;
IP白名单;
VPN身份验证;
硬件安全模块;
在适当情况下采用证书绑定;
多因素管理员身份验证;
受控服务账户;
基于角色的访问控制;以及
生产环境与测试环境相互隔离。

仅凭IP地址不足以证明机构身份。

同样，持有端点、服务器登录凭证、API凭证或ZIP压缩包密码，并不能证明对相关资金拥有所有权。

6. 加密

保密通常应在多个层面上予以确立。

传输加密

通信渠道应采用经适当配置的现行协议(如TLS或SSH)进行加密。

这可保护传输过程中的信息。

载荷加密

如有需要,交易文件包本身亦可另行加密。

这种做法使金融信息的保护独立于传输通道,在文件被临时存储、经由中间基础设施路由、归档或异步处理的环节,可显著降低风险敞口。

静态加密

待处理文件应存放于受控的存储环境中,并设置适当的访问限制及静态加密。

然而,加密只能确立保密性,并不能确立交易在财务上的有效性。

7. 密码学完整性

接收机构还必须有能力判断所传输的文件包在生成之后是否被篡改。

因此,可为数据包或其所含文件生成加密哈希值。

例如:

原始交易数据包
→ 生成加密哈希值
→ 传输数据包
→ 接收系统独立计算哈希值
→ 将计算所得哈希值与传输或签署的哈希值进行比对

不一致表明所收到的文件包与最初经认证的文件包在密码学上并不相同。

可视实施情况采用现代加密哈希算法(如SHA-2或SHA-3系列算法)进行完整性校验。

8. 数字签名

数字签名所发挥的功能与加密有本质区别。

加密保护保密性。

哈希有助于确立完整性。

正确实施的数字签名有助于确立:

真实性 - 该数据包已使用相应私钥签署;
完整性 - 已签署的数据其后未被更改;以及
可追责性——在适用的PKI及治理框架下,该签名可与相应的机构凭证相关联。

接收机构应在交易指令进入支付处理流程之前，对照相应的可信证书或公钥验证签名。

私有签名密钥应得到妥善保护,宜通过机构级密钥管理基础设施,并在必要时使用硬件安全模块(Hardware Security Module)。

9. 重放与重复防护

金融文件传输需要设置控制措施,防止同一有效指令被重复提交。

因此,设计合理的架构应纳入唯一交易标识符及适当的控制措施,例如:

唯一的报文ID;
唯一的交易编号;
时间戳;
序列号;
文件标识符;
重复报文检测;
幂等性控制;
处理状态登记册;以及
与此前已处理的指令进行核对。

接收机构应根据约定的操作程序,拒绝、隔离或调查重复的指令。

10. 文件验证

成功接收文件后应启动验证流程,而非自动结算。

安全的处理环境可能对该包裹依次实施多项检查:

第1阶段 – 传输验证

确认包裹已通过授权渠道送达。

第2阶段——端点认证

确认发送系统及机构身份凭证。

第3阶段——恶意软件与文件安全控制

在归档文件及其组成文件导入支付基础设施之前,对其进行检查。

第4阶段 – 密码验证

对哈希值、签名及证书的验证。

第5阶段——结构验证

确认文件符合约定的数据结构、命名规范、字符编码和数据规格。

第6阶段——语义验证

确认必填付款字段均已提供且内部一致。

第7阶段——交易验证

对币种、金额、账户、路由信息、交易参考编号及结算指令进行验证。

第8阶段 – 合规验证

AML、制裁、KYC/KYB、交易监测及其他适用控制措施。

第9阶段——结算验证

确认存在可用于结算相应金融价值的实际机制。

仅在上述控制程序全部完成后,指令方可依照接收机构适用的程序进入执行阶段。

11. 确认不等于结算

IP ZIP环境可能产生多条技术确认信息。

例如:

ACK——文件已收到

这仅能证明接收端已获取该文件包。

ACK – 文件已验证

这表明身份验证控制已成功完成。

ACK – 文件已验证

这表明该文件包符合适用的结构性或技术性验证要求。

ACK – 指令已接受

这可能表明该支付指令已进入接收机构的处理流程。

上述情形均不必然意味着:

已结算

结算须通过单独的资金环节完成。

这一区别类似于传统金融报文业务:支付报文的成功送达与接受,必须与基础货币债务的最终结算加以区分。

12. 基础交易的结算

IP ZIP付款指令一经认证、验证、接受和授权,其所涉货币价值须通过适当的金融基础设施完成结算。

视所涉及的货币、机构和司法管辖区而定,结算可通过以下方式进行:

代理行业务;
往来账户(Nostro)/来账账户(Vostro);
中央银行账户;
RTGS基础设施;
认可的清算系统;
国内支付系统;
即时支付基础设施;
代理结算银行;或
另一种在法律及运营上获得认可的结算安排。

因此,简化的交易流程可如图所示。

因此,金融价值是通过结算基础设施转移的,而非通过ZIP压缩文件转移。

13. 与 ISO 20022 pacs.008 的比较
二者的区别可概念性地说明如下:

此项比较着眼于功能层面,而非规范层面。pacs.008是依据ISO 20022正式定义的金融报文。"IP ZIP"并非与之对等的国际标准化报文类型。

因此,IP ZIP架构必须通过双边约定,明确其报文模式、安全架构、认证规则、确认逻辑、异常处理、对账流程以及结算关系。

14. 安全原则

IFB对所有替代性转账方式均适用一项根本性区分:

安全传输只能证明数据可以被安全地传送,并不能证明资金可以完成结算。

加密并不能证明资金的存在。
数字签名并不能证明资金的存在。
服务器上的余额并不能证明资金存在。
交易文件并不能证明资金的存在。
文件成功导入并不能证明资金存在。
技术确认并不证明已完成结算。

决定性的财务问题仍然在于,发起机构是否已核实流动性及可运作的结算路径,并能够通过公认的银行基础设施交付相应的货币价值。

15. IFB受理框架

IFB仅会考虑为获批的机构交易对手及已获接纳的客户办理IP ZIP传输,且须事先通过令人满意的技术、法律及合规审查。

在建立生产环境连接之前,IFB可能要求核验以下事项:

发起机构;
传送该笔交易的机构授权;
受益所有权及交易各方;
资金来源及合法性;
底层经济目的;
发送与接收基础设施;
终端所有权;
IP与网络架构;
认证方法;
证书及加密凭证;
加密标准;
文件格式及架构;
支付报文结构;
交易识别方法;
确认协议;
重复及重放控制;
异常处理;
对账程序;
代理行关系;
结算账户;
流动性安排;以及
最终结算路径。

仅有技术上的互操作性是不够的。

IFB不会将IP ZIP数据包的成功传输视为资金到账。仅当相应款项已通过约定的银行或结算基础设施成功结算,且该结算可被独立核对时,交易在财务上方告完成。

基本原则

IP ZIP是指令的安全传输。结算则是相应金融价值的转移。

这两个流程可能属于同一交易工作流程的组成部分,但并非同一事件。

按机构银行业务术语:

报文传输 → 身份验证 → 校验 → 接受 → 执行 → 结算 → 对账

仅当适用的结算流程完成后,方可确认交易的资金环节已经完成。

IP Direct

IP Direct机制涉及银行间业务范围内的一套专门交易流程。具体说明如下:

往来账户(Nostro)-来账账户(Vostro)关系:本笔交易的基础在于两家银行机构之间建立“往来账户(Nostro)-来账账户(Vostro)”关系。在此情形下,“汇出行”在International Finance Bank(IFB)开立往来账户(Nostro)(Nostro为意大利语“ours”之意:“我方在贵行开立的账户”),而IFB则相应为汇出行保有来账账户(Vostro)(Vostro为“yours”之意:“贵方在我行开立的账户”)。这一双边账户安排对于IP Direct交易的顺利办理至关重要。

IP Direct机制:采用IP Direct方式时,汇出行发起的交易通过两家银行的集成支付系统直接处理。此流程绕开了SWIFT(环球银行金融电信协会)等国际支付系统较为传统且往往更为复杂的路径。IP Direct的主要优势在于,由于银行之间建立了直接的通信渠道,交易执行可能更为迅速,交易成本也可能更低。

交易流程:在IP Direct交易中,委托银行依托已建立的往来账户(Nostro)与来账账户(Vostro)关系,直接向IFB发出付款指令。IFB收到该指令后,将按所收到的指示相应记入或扣减各账户。这一流程通常较为简化,效率可高于标准做法,尤其适用于交易量大或需要加急处理的银行。

有效运作的条件:要使IP Direct发挥最佳效能,须满足若干条件: