其他转账方式
API及JSON转账
在IFB激活API及JSON服务
待客户账户处于良好状态后,经客户申请,将开通API服务:
- 其维持最低余额,
- 具有持续稳健的财务业绩记录,并且
- 与合法商业活动相符。
此外,该账户还必须具有
- 无未决合规问题,并且
- 所有交易均须遵守国际金融法规。
最终激活须经我行合规及风险管理团队的内部审查和批准。
我们的API服务
在API转账中,连接严格限于本行的外部服务器,或在特定情形下限于为特殊客户交互而指定的核心服务器。然而,这些系统绝不会与保存实际财务记录的本行账簿服务器直接相连。这种隔离确保账簿服务器完全独立,从而保护本行资产,并在银行体系的安全框架内维护所有金融业务的完整性。
如需查看我们的API服务对接指南,请向下滚动至本页末尾(金融机构密钥交换流程)。
我们的API(及JSON)服务
我们向经甄选的高净值个人客户及信誉卓著的公司客户提供API服务,尤其注重审慎、保密与机构诚信。
所有API交易仅在已完全接入国际银行体系的银行之间进行,不仅确保经认证的API报文的安全交换,还确保资金得到有效、及时的结算。未接入该体系的交易对手或许能够发送报文,但本质上无法完成资金结算。
在 API 转账中,资金无法从银行的账务服务器“下载”,因为这些系统始终与外部访问完全隔离。与存储在云端或任何普通服务器或计算机上的数字文件不同,资金必须始终通过全球银行体系安全且受监管的框架进行传输,以确保其完整性以及每笔交易的合规。
从实证来看，提交给我们的API交易中，超过77%来自非银行实体，或来自不具备资金发送能力的银行。
相比之下,本行可不受金额限制开展交易,唯须对发起机构及其切实具备的结算能力进行严格核实。
API(应用程序编程接口)
与一种普遍看法相反,API本身并不转移资金。它是一种精密的通信渠道和接口,连接银行各软件系统之间,或连接客户与银行后台服务器(该服务器不与银行核心系统相连)。其作用是通过软件接口向银行的数字基础设施发出请求或指令。
- 请求/指令发出与信息检索:银行业中的API本质上并不直接执行金融交易,而是充当信使,将外部应用程序的请求传递至银行的互联网边缘系统。例如,当通过API发送发起交易的指令时,API仅将该请求转送至银行的交易处理系统。资金的实际划转随后由银行内部机制统筹完成,以严格的安全与合规规程为支撑,并与代理行、RTGS或RTP保持通信。
- 安全通信的促成者:银行API的首要功能是确保外部应用程序与银行内部系统之间安全、高效地通信,包括提交交易请求和获取账户相关信息。通过采用先进的加密与认证措施,API保证这些通信既安全,又仅限获授权的主体访问。这一角色可比作一项高度安全且高效的邮政服务,确保双方之间的信息准确、保密地送达。
- 提升银行服务：资金的直接划转虽不属于API的职能范围，但API在提升银行服务的可获得性和功能性方面发挥着关键作用。通过促进指令与信息的交换，API使第三方应用能够提供各类与银行相关的服务，包括实时查询账户余额和交易记录，以及发起交易，再由银行自身系统处理。
- 监管合规与数据完整性:银行API在履行职能时,遵循旨在保护消费者数据并确保金融交易完整性的严格监管标准。其运作处于法律及监管框架的范围之内,例如欧洲的PSD2,该指令要求以安全、标准化的方式共享金融数据。由此,API在数字银行生态系统中并非资金划转的直接促成者,而是发起交易和获取金融信息的安全通道。
- 增强可扩展性: API 使银行和金融科技公司能够通过与外部服务和系统集成,轻松扩展业务。
- 改善客户体验:借助API,金融机构可提供更加个性化、顺畅的银行服务体验,满足精通数字技术的客户不断变化的期望。
- 运营效率:API有助于实现日常任务自动化,从而减少人工差错,提高银行运营效率
- 创新与协作: API的开放性促进银行、金融科技初创企业及其他金融服务提供商之间的协作,从而推动创新。
在银行业领域,API的本质并非直接转移资金,而是作为一种精密的软件中介,传递请求并获取信息。正是通过这种安全且结构化的通信,API丰富了数字银行环境,在确保遵循最高安全与监管合规标准的同时,实现了种类繁多的服务。
外部API
出于金融机构固有的严格安全要求,银行环境中的外部API与核心系统保持一定距离,与银行账务系统之间的距离则更远。采取这种间接连接方式有若干充分理由,均关乎保护敏感信息及银行核心职能的运营完整性:
1. 敏感数据隔离
核心系统包含银行客户及业务流程中最敏感、最关键的数据,例如客户记录和财务明细;总账系统则包含全部账户余额和交易记录。若通过API将核心或总账银行系统直接暴露于外部系统,将显著增加数据泄露及数据与记录被篡改的风险。通过将API交互限定于中间层或外围系统,银行可以控制并审查数据访问,防止无意或未经授权的数据泄露。
2. 最大限度减少攻击面
若允许外部API直接连接核心系统或账本系统,将增加一个额外的接入入口,扩大可能被恶意行为人利用的攻击面。直接通往账本的连接点越多,攻击者突破系统的风险就越大。间接连接通常通过中间件层或API网关实现,可起到保护性缓冲作用,对访问请求进行筛查和过滤,并以受控、受监测的方式予以处理。
3. 强化访问控制
通过中间层路由外部API传输,银行可实施额外的访问控制机制,包括限速、身份验证和授权检查。该中间系统在将经审查的数据或指令转发至内部银行系统中的核心系统之前,会验证每项请求的真实性与合法性。它执行严格的访问策略,确保仅经审核的请求才会从核心系统转发至账本系统。
4. 数据完整性保障
外部API直接访问可能危及数据完整性。如果外部系统直接与账簿交互,即便是微小的错误或意外交互,也可能破坏数据的一致性和准确性。中间层系统负责校验,转换API请求并在其到达账簿之前确认其准确且适当。这种受控的交互对于维护财务记录的稳定性和可信度至关重要。
5. 监管合规与审计
银行在严格的监管框架下运营,尤其在数据访问和处理方面须采取严密的安全措施。由间接、受控的系统处理外部API请求,可在账簿与外部系统之间划定清晰的边界,从而简化合规工作。这使得每一笔交易都能被详细记录和审计,确保任何外部交互均可完全追溯、可问责,同时不会暴露敏感的账簿数据。
6. 降低系统性风险
若外部API直接连接至账务系统,这些API内的任何漏洞或被利用的缺陷都可能直接影响机构的核心财务记录。间接接入有助于遏制和缓解风险,使账务系统在外部API发生安全事件或系统故障时得以隔离。通过间接连接的方式构建架构,银行可确保即使外部系统出现问题,关键系统仍能保持安全、运行和韧性。
简言之
采用中间件或API网关的间接连接模式,可确保本行账簿免受外部连接可能带来的威胁,同时仍允许与经授权的第三方进行安全、受控的数据交换。这种分层安全架构保障了数据的保密性、完整性和可用性,符合网络安全最佳实践及监管标准。
进一步了解银行API
银行 API 充当中介,使第三方开发者和企业能够以安全、可控的方式访问银行的功能和数据。这种访问对于开发可直接与银行系统交互的应用程序至关重要,从而无需重复造轮子,即可实现丰富多样的金融服务。
银行API类型一览
银行API大致可分为四种主要类型,各自服务于不同目的,满足不同的金融需求:
- 核心银行API:此类API侧重于存款、贷款及中小企业跨境交易等基本银行业务。通过提供对这些基础服务的访问,核心银行API使金融科技应用能够顺畅地整合传统银行功能。
- 即插即用 API:这些 API 专为交易和会计流程等金融业务而设计,并包含通过 OAuth 实现的身份验证服务。其设计便于集成到现有系统中,有助于快速采用和实施。
- 卡片、钱包及转账API:此类别涵盖发卡、钱包、多币种业务和欺诈监测,通常配有软件开发工具包(SDK)。它们对于涉及支付、货币兑换和交易安全保障的应用至关重要。
- 收单API:此类API专注于支付收单,支持移动支付、近场通信(NFC)解决方案、线上银行卡收单等业务,对拓展企业收款渠道发挥着重要作用。
REST与SOAP:银行API的架构风格
在银行API中,主要存在两种通信范式:
- REST(表述性状态转移)是一种架构风格:通过HTTP发送无状态的请求与响应,通常承载JSON数据。该方式轻量且易于扩展,在现代开放银行接口中占据主导地位。
- 相比之下,SOAP(简单对象访问协议)是一种基于XML的正式协议,内置安全(WS-Security)和错误处理标准,在较早期的核心银行系统集成中仍然常见。
两种范式各具优势,选择何者取决于所实施银行服务的具体要求。
银行应用程序接口(API)处于金融业数字化转型的前沿,为传统银行服务与创新金融科技解决方案之间搭建了桥梁。借助这些技术进步,银行不仅能够提升运营效率和客户服务水平,还能在日益数字化的世界中保持竞争力。随着金融业持续演进,对银行 API 的战略性运用必将在塑造其未来方面发挥关键作用。
基于API的通信可实现系统之间的结构化交互,从而提升银行业务运作效率。然而,API并不构成独立的支付机制。通过API传输的数据,包括JSON格式的请求与响应,体现的是交易指令或系统通信,而非结算。
通过API发起的任何转账,其执行仍取决于获授权的金融机构和公认的支付基础设施。API响应或结构化数据输出的出现,本身并不能证明资金已经划转。
基于 API 的银行环境中的 JSON
在现代银行基础设施中,JSON是API通信层所采用的标准化数据格式。其作用纯属技术性质:在各系统之间构建并传输信息。它不执行交易,不持有价值,也不能替代机构流程。
在基于API的银行业务中,JSON通常用于对支付指令、账户数据、交易元数据及系统响应进行编码,其格式既可被机器读取,又可跨平台互操作。这使外部应用程序、客户界面和内部银行系统能够在受控环境中高效通信。
通过API发起付款时,指令可能以JSON格式传输。然而,资金的实际划转由银行另行通过SWIFT、SEPA、RTGS或其他公认的结算系统等既有支付渠道执行。JSON仅用于传达指令,并不执行转账。
在API交易中的功能角色
在实际应用中,JSON充当客户端应用程序与银行基础设施之间的接口层。一次典型的API请求可包含结构化字段,例如发送方标识、收款人详情、账号、币种、金额及交易参考编号。接收系统对这些数据进行验证和处理,进而判定该笔交易能否继续进行。
指令经验证后即进入本行内部处理环境,在此接受合规检查、风险控制和授权程序。只有完成这些步骤后,交易才会进入相应的结算渠道。
因此,JSON 只是更广泛的交易生命周期中的一个组成部分,并不能取代:
- 机构授权
- 合规核查
- 账户级别验证
- 清算与结算流程
数据与结算相分离
一个反复出现的误解,是将数据传输与资金划转混为一谈。JSON作为一种数据格式,可以详尽地描述一笔交易,但无法创设或结算该笔交易。无论JSON报文内容看似多么完整,其存在本身并不构成资金已被划转的证明。
这一区别在操作和风险层面均至关重要。有效的转让必须体现在:
- 发送机构的账簿
- 接收机构的账簿
- 中间结算系统(如适用)
缺少上述要素,则无论数据如何呈现,均未发生转让。
与银行API的集成
在受监管的环境中，JSON 通常嵌入安全的 API 框架之中。这些框架强制执行身份验证、加密和访问控制，确保只有获得授权的主体才能发起或获取金融数据。
典型使用情形包括:
- 通过客户界面发起付款
- 调取交易历史记录
- 余额查询
- 受益人管理
- 实时状态更新
这些功能提升了效率和互操作性,但仍依赖于底层的银行基础设施。
风险考量
由于JSON易于阅读且便于复制,在受控环境之外呈现时容易被滥用。JSON文档可以毫不费力地被构造、修改或伪造,因此不能作为已完成交易的独立证据。
在专业银行实务中,核验始终以机构记录和公认的支付系统为依据,而非以孤立的数据陈述为依据。
有关转账相关风险的更全面论述,请参阅:转账风险与欺诈防范
机构层面的解读
在IFB的运营框架内，JSON被视为API通信中使用的技术标准，而不被视为支付机制或结算方式。
所有交易,无论以何种方式发起,最终均须通过受监管的金融基础设施执行。JSON可便利信息沟通,但并不改变银行业务的基本运作机制。
概要头寸
JSON通过实现结构化数据交换,提升了数字银行界面的效率。其作用在于信息传递,而非交易执行。货币转账仍属银行机构、受监管系统及结算流程的职能。JSON是该架构内的信息通道,而非其替代品。
与替代性或传统转账方式相关的术语,应结合银行基础设施的背景加以理解。此类术语可能描述通信渠道、内部处理方式或历史惯例,但并不取代对受监管机构、公认支付系统及正式结算程序的要求。
任何转移,无论其名称如何,最终都必须在既有金融体系内进行处理、清算和对账。
密钥交换
如果您希望进一步了解如何向您在本行的账户转入资金或资产，请联系Marie Mayer。