CN117321619A - 利用分布式结算平台执行电子交易和代币化的系统和方法 - Google Patents

Abstract

本发明公开了通过实时交易系统执行实时电子交易的系统和方法。一种方法包括通过路由系统接收来自用户的电子交易请求。所述路由系统可接收来自数据查询系统的路由配置数据。所述路由系统可根据路由决策模型和路由配置数据，确定用于执行电子交易请求的最佳路径。所述路由系统可经由最佳路径将电子交易请求传输到交易网络。所述路由系统可生成基于最佳路径的交易路由数据。所述路由系统可将交易路由数据传输到交易事件主题流。

Description

利用分布式结算平台执行电子交易和代币化的系统和方法

相关专利申请的交叉引用

本申请要求2021年3月22日提交的第17/207,792号美国申请的权益，所述第17/207,792号美国申请通过本发明的整体引用，成为本发明的一部分。

技术领域

本公开总体上涉及电子交易领域，具体涉及采用单一平台在多个网络上执行实时电子交易的系统和方法。

背景技术

企业、商户、消费者、金融实体和/或政府实体可通过各种支付网络在国内外进行电子资金转账、支付处理(如电子商务支付)、资本管理等。然而，现有的电子支付/资金交易技术在许多方面存在一些固有的缺陷或不足，可能会导致用户体验不佳、增加时间和成本以及在通过各种支付网络进行电子汇款时引起的其他不便。例如，很多遗留支付处理网络涉及处理系统相互拼凑、系统碎片化、安全风险等问题。本公开旨在解决现有电子交易系统和服务的这些和其他弊端。

本发明中提供的背景说明旨在概括介绍本公开的背景情况。除非本发明另有说明，否则本节所述材料并非本申请权利要求的现有技术，也不因列入本节而被承认为现有技术或现有技术的建议。

发明内容

一个实施例提供了一种通过实时交易系统执行实时电子交易的方法，所述方法包括：通过路由系统接收来自用户的电子交易请求；通过路由系统接收来自数据查询系统的路由配置数据；通过路由系统根据路由决策模型和路由配置数据确定用于执行电子交易请求的最佳路径；通过路由系统经由最佳路径将电子交易请求传输到交易网络；通过路由系统生成基于最佳路径的交易路由数据；通过路由系统将交易路由数据传输到交易事件主题流。

一个实施例提供了一种实时交易系统，包括：一个或多个计算机可读介质，存储用于执行实时电子交易的指令；以及一个或多个处理器，可执行指令，以进行包括以下步骤的操作：通过路由系统接收来自用户的电子交易请求；通过路由系统接收来自数据查询系统的路由配置数据；通过路由系统根据路由决策模型和路由配置数据确定用于执行电子交易请求的最佳路径；通过路由系统经由最佳路径将电子交易请求传输到交易网络；通过路由系统生成基于最佳路径的交易路由数据；通过路由系统将交易路由数据传输到交易事件主题流。

一个实施例提供了一种存储用于执行实时电子交易的指令的非暂态计算机可读介质，在通过一个或多个处理器执行时，所述指令可使所述一个或多个处理器进行包括以下步骤的操作：通过路由系统接收来自用户的电子交易请求；通过路由系统接收来自数据查询系统的路由配置数据；通过路由系统根据路由决策模型和路由配置数据确定用于执行电子交易请求的最佳路径；通过路由系统经由最佳路径将电子交易请求传输到交易网络；通过路由系统生成基于最佳路径的交易路由数据；通过路由系统将交易路由数据传输到交易事件主题流。

附图说明

本说明书中包含并形成本说明书一部分的附图说明了本公开的几个实施例，与以下说明一起共同说明本公开的原理。

图1显示了根据本公开一个方面所述的示例性电子交易系统的框图。

图2显示了根据本公开一个方面所述的另一示例性电子交易系统的框图。

图3显示了根据本公开一个方面所述的另一示例性电子交易系统的框图。

图4显示了根据本公开一个方面所述的另一示例性电子交易系统的框图。

图5显示了根据本公开一个方面所述的另一示例性电子交易系统的框图。

图6显示了根据本公开一个方面所述的执行电子交易的示例性方法的流程图。

图7显示了根据本公开一个方面所述的执行电子交易的另一示例性方法的流程图。

图8显示了根据本公开一个方面所述的执行电子交易的另一示例性方法的流程图。

图9显示了一种用于执行本发明所述技术的计算机系统。

具体实施方式

以下实施例介绍了促进电子交易的系统和方法。更具体地，本公开所设想的实施例使商户、顾客、企业、机构等能够利用与交易请求方和交易网络通信的单一交易处理器来促进各种电子交易。

如上所述，在执行国内和/或国际支付交易时，现有的电子支付技术在各个方面存在某些缺陷和不足。例如，复杂的遗留系统和不断发展的解决方案相互拼凑，不同市场和支付方式的合规标准如迷宫般错综复杂，以及任意的交易定价策略，都可能导致交易速度缓慢且不可靠、成本增加和用户体验不佳。

为解决上述问题，本公开介绍了提供统一平台的系统和方法，所述平台能够促进或提供：1)与所有账户对账户支付方法连接的单一应用编程接口(API)；2)管理一致且全球认可的安全和隐私惯例；3)智能支付路由和编排能力；4)跨支付方法和方案的统一对账和报告；5)可提供对整个顾客生命周期进行管理的单一管理门户。例如，包括API系统、安全系统、分析系统、编排系统、连接系统和对账系统的交易处理器可与请求方系统和交易网络通信，以促进和执行本公开的电子交易。

在一个实施例中，本公开的交易处理器可通过API系统接收来自用户(如企业、商户、消费者、金融机构、政府机构等)的电子交易请求(如账户对账户的资金转账、购买付款、报销等)。然后，API系统可将电子交易请求传输到交易处理器的编排器系统。然后，编排器系统可将验证API调用(可基于电子交易请求)传输到交易处理器的账户系统。然后，账户系统可确定交易处理器数据库中是否存在与付款请求系统相关联的账户。此外，编排器系统可将授权API调用(可基于电子交易请求)传输到交易处理器的授权系统。然后，编排器系统可接收来自授权系统的授权响应。此外，编排器系统还可将电子交易请求传输到交易处理器的路由系统、账户分类账系统、审计系统和/或交易系统中的至少一个系统。基于规定性交易系统设置和/或用户偏好或请求，路由系统可对交易请求执行智能路由，以优化交易请求路由。

在一个实施例中，本公开的路由系统可通过编排器系统接收来自用户的电子交易请求。路由系统还可接收来自数据查询系统(例如采用结构化查询语言(SQL)的权限查询服务)的路由配置数据(例如规定性系统设置、用户偏好等)。然后，路由系统可根据路由决策模型和路由配置数据确定用于执行电子交易的最佳路径。路由决策模型可以是一个基于规则的引擎，它至少可以基于用户偏好(例如交易金额、期望的付款日期等)和业务知识(例如路由标准)来求解电子交易的最佳路径。然后，路由系统可经由最佳路径将电子交易请求传输到交易网络。此外，路由系统可生成基于最佳路径的交易路由数据，并将交易路由数据传输到交易事件主题流(如Kafka流)。在一个实施例中，交易路径数据可传输到交易事件主题流的订阅者，以便进一步处理。

应理解，这里特别考虑的是与企业、商户和/或消费者有关的支付交易。尽管这里提到了与企业、商户和消费者有关的支付交易，但某些公开的系统和方法可同样适用于其他各种电子商务和电子交易。实际上，在通过网络传输信贷、货币、加密货币、担保基金、智能合约和/或代币化基金的任何情况下，都可以采用本发明中公开的系统和方法。此外，虽然本发明中将寻求发起电子交易和/或提供第三方服务的一方称为企业、商户或消费者，但寻求发起电子交易的一方不一定是企业、商户或消费者，也可以是金融机构、政府机构、服务提供商、用户或寻求执行电子交易的任何一方。

下面将参照附图对本公开的主题进行更全面的说明，附图构成了本公开的一部分，并通过图示的方式展示了具体的示例性实施例。本发明所述的“示例性”实施例或实施方式不能理解为相对于其他实施例或实施方式而言优选或有利；相反，其旨在反映或表明该实施例是“示例性”实施例。可以以各种不同的形式体现主题，因此，所涵盖或要求保护的主题旨在解释为不限于本发明所述的任何示例性实施例；提供示例性实施例仅用于说明目的。同样，要求保护或涵盖的主题也应具有合理的宽泛范围。例如，除其他方面以外，主题可体现为方法、设备、组件或系统。相应地，实施例可采取硬件、软件、固件或其任何组合的形式。因此，以下详细描述并不具有限制意义。

在整个说明书和权利要求中，除了明示的含义外，术语在上下文中还可能暗示或隐含一些微妙的含义。同样，本发明中使用的短语“在一个实施例中”或“在一些实施例中”并不一定是指相同的实施例，而本发明中使用的短语“在另一实施例中”并不一定是指不同的实施例。其意图在于要求保护的主题包括全部或部分示例性实施例的组合。

尽管下文中使用的术语与本公开中某些具体示例的具体实施方式结合使用，但是可以对这些术语做出最广义的合理解释。事实上，某些术语甚至可以在下文中加以强调；然而，本具体实施方式部分将对任何旨在以任何受限制方式进行解释的术语做出公开而具体的界定。

现在请参考附图，图1显示了一个示例性系统100，包括一个请求方系统110、一个交易处理器120和一个交易网络140。请求方系统110、交易处理器120和交易网络140可直接、间接和/或通过网络150(例如互联网和/或一个或多个云网络)相互通信。请求方系统110、交易处理器120和交易网络140也可直接通过直接通信线路、物理、技术和/或业务关系组合相互通信。请求方系统110可包括一个或多个实体，例如但不限于国库、商户、消费者、企业、金融机构、政府机构等。例如，请求方系统110可将电子资金传输请求传输到一个或多个接收方。

在一个实施例中，请求方系统110可为请求向消费者传输电子资金的企业提供便利。在本实施例中，电子资金可包括法律纠纷赔偿金、保险索赔、股东分红、会员积分、贷款、投资支付、顾客退款支付等。在另一实施例中，请求方系统110可为请求向另一企业传输电子资金的企业提供便利。在本实施例中，电子资金可包括应收账款/应付账款(AR/AP)、租金支付、商业贷款支付、工资、银行对银行跨境支付、供应商支付、自由职业者支付、供应链财务支付、商业医疗福利支付、联盟营销计划支付等。在另一实施例中，请求方系统110可为请求向企业(或商户)传输电子资金的消费者提供便利。在本实施例中，电子支付可包括销售点终端支付、电子商务结账处支付、在线市场支付、在线数字内容支付、电信账单支付、水电费支付、租金支付、投资支付等。在另一实施例中，请求方系统110可为请求向另一用户传输电子资金的用户(例如任何个人或消费者)提供便利。在本实施例中，电子资金可包括众筹支付、移动钱包支付、礼品支付、个人对个人支付、账户对账户转账等。在另一实施例中，请求方系统110可为请求向消费者传输电子资金的政府实体提供便利。在本实施例中，电子资金可包括政府福利支付、学生补助支付、学费支付、学费报销支付等。在另一实施例中，请求方系统110可为请求向政府实体传输电子支付的用户或消费者提供便利。在本实施例中，电子资金可包括交通支付、停车支付、税款支付、许可证支付、工资支付等。

在一个实施例中，请求方系统110可利用交易处理器120提供的集成门户(或平台)和/或集成服务进行用户体验和/或用户界面(例如AR/AP、企业资源规划(ERP)系统、网站、应用程序等)集成，以便与交易处理器120进行交互。在某些实施例中，请求方系统110可以通过采用集成工具包/服务和/或自己动手(DIY)模型(此模型采用交易处理器120的API系统122)与交易处理器120集成。

仍参照图1，交易处理器120可包括一个应用编程接口(API)系统122(例如API网关)、一个安全系统124、一个分析系统126、一个编排系统128、一个连接系统130和一个对账系统134。连接系统130可在国内和/或国外与各种市场(如市场1-N 132a-132n)进行通信。交易处理器120可促进请求方系统110与交易网络140之间的电子交易和通信。例如，API系统122可通过交易处理器120的API(例如表现层状态转换(RESTful)实时API或基于文件的批处理API)接收来自请求方系统110的一个或多个电子转账(或支付)请求。可通过一个或多个公共超文本传输协议安全(HTTPS)端点访问RESTful API(或API)。可通过一个或多个公共安全文件传输协议(SFTP)端点访问批处理API(或API)。API可包括在交易处理器120中创建顾客身份、将银行账户与顾客身份相关联以及在多个账户之间进行支付的能力。API系统122可与安全系统124、分析系统126和编排系统128通信，以执行本公开的电子交易。例如，API系统122可将电子资金转账(或支付)请求传输到编排系统128。然后，编排系统128可通过连接系统130将电子支付请求传输到交易网络140中的适当网络或方案。(下文将进一步详述。)此外，对账系统134可接收来自交易网络140的通知、消息和/或确认，并可将与电子资金转账请求相关的适当消息、告警和/或信号实时地传输到请求方系统110。

交易处理器120可以是在国内和/或国外使用单一API的单一处理器。也就是说，交易处理器120可通过建立一个以客户为中心的平台，在国内和/或国外统一、编排和执行电子交易，从而促进账户对账户的实时电子交易(例如电子支付、资金转账、货币兑换、报销、资产管理等)。此外，交易处理器120可在单一平台内执行电子资金转账、货币兑换交易、代币化和/或电子交易授权。此外，交易处理器120可按照全球公认的安全和隐私惯例持续运行。此外，交易处理器120可根据用户(例如请求方系统110)的偏好通过编排系统128实时地进行智能支付路由。在某些实施例中，用户可实时地更改交易路由偏好(例如完成支付交易的时间和成本)。除其他方面以外，本公开的交易处理器120可提供单一合作伙伴问责制、降低成本、改进现金流、提高支付安全性、改进支付访问，并可更好地了解支付/资金情况并对其进行问责。因此，交易处理器120可以是执行支付交易的一站式服务点。

仍参照图1，交易网络140可包括一个或多个网络或方案142a、142b-142n。一个或多个方案(或网络)142a-142n可包括自动清算所(ACH)网络(例如ACH、Same Day ACH等)、银行卡网络(例如美国运通卡、发现卡、万事达卡、维萨卡等)、实时支付(RTP)网络(例如清算所等)、区块链网络、电汇网络、快速支付网络、银行家自动清算系统(Bacs)支付方案、清算所自动支付系统(CHAPS)网络、单一欧元支付区(SEPA)网络、SEPA即时信用转账(SCT Inst)网络和/或其他金融平台网络(例如Dwolla、PayPal、西联汇款、Currencycloud、TransferMate等)。交易网络140可根据一个或多个方案142a、142b-142n的既定政策和/或规则，在对电子资金转账请求进行验证和/或授权后，完成或拒绝电子资金转账请求。

图2显示了一个包括交易处理器120的示例性系统200。具体而言，图2中显示的部分代表了对交易处理器120更详细的示例说明，但不应将其理解为对交易处理器120的限制。交易处理器120可包括API系统122、安全系统124、分析系统126、编排系统128、管理门户系统218、审计系统220、通知系统222和代币化系统224中的一种或多种。API系统122可促进与请求方系统110、交易网络140以及图2所示交易处理器120的一个或多个系统(或微服务)之间的通信。例如，API系统122可以利用API(例如内部或外部API)、批处理API和/或通知API，以促进本公开电子交易的执行。在一个实施例中，可通过一个或多个公共超文本传输协议安全(HTTPS)端点访问API系统122的RESTful API。API系统122可利用POST、GET和PUT方法执行和促进本公开的电子交易。在另一实施例中，可通过一个或多个公共安全文件传输协议(SFTP)端点访问API系统的批处理API。

仍参照图2，安全系统124可促进用户(或顾客)访问控制、用户限流和/或用户识别。在一个实施例中，安全系统124可确保交易处理器120符合一项或多项数据保护标准。可以监控交易处理器120的一个或多个数据元素，以满足交易处理器120制定的一项或多项加密标准。例如，可由安全系统124对数据元素(如个人身份信息(PII)、支付卡数据(PCI数据)、验证凭证、其他敏感数据、公司机密数据等)进行监控。

在一个实施例中，安全系统124可促进并管理与本公开的电子交易相关的数据和/或密钥的加密。例如，安全系统124可包括密钥管理服务(KMS)，所述服务可为加密密钥的使用期限设定一个时限。可从交易处理器120对KMS进行内部或外部(例如，亚马逊网络服务密钥管理服务(AWS KMS))管理。在一个实施例中，一旦加密密钥超过其使用期限，就可从交易处理器120的加密密钥缓存中删除所述加密密钥。然后，可将所述加密密钥替换成KMS新生成的密钥。通过设置数据密钥轮换政策限制范围内的缓存过期时间，此功能可确保符合交易处理器120制定的数据密钥轮换政策。此外，对KMS中密钥的访问可受到安全系统124访问控制的限制，并可在最小权限下进行分配。

在一个实施例中，安全系统124可以仅允许用户使用指定的服务和/或用户身份对KMS顾客主密钥(CMK)进行调用操作。安全系统124还可对主密钥的使用和访问进行审计。此外，安全系统124还可将安全散列函数(如安全散列算法-256(SHA-256))用于加密但必须搜索的数据元素。由于可在所有租户中检索散列数据元素(例如发件人姓名、发件人账号、发件人路由号、收件人姓名、收件人账号、收件人路由号等)，因此散列数据元素可具有全局盐值。在一个实施例中，采用高级加密标准(AES)-256即可将静态敏感数据元素存储在交易处理器120中。此外，通过执行最低传输层安全协议(TLS)1.2，即可对运动中的任何消息数据进行保护。

仍参照图2，分析系统126可包括一个数据存储(如数据湖)和一个用于执行分析的数据平台。例如，审计系统220和管理门户系统218可与分析系统126通信，以便对本公开的电子交易进行分析和审计。审计系统220可订阅交易事件主题，并将事件主题传输到数据湖进行分析。管理门户系统218可为交易处理器120用户的入职、配置和认证提供便利。管理门户系统218可为交易处理器120的用户提供自助服务功能，并为交易处理器120的内部支持团队提供行政管理功能。

仍参照图2，编排系统128可包括编排器系统210、门户系统212、路由系统214和交易系统216。编排器系统210可以对处理本公开一个或多个实时电子交易请求或一个或多个实时交易查询所需的步骤进行编排。例如，编排器系统210可验证交易请求方(如请求方系统110)是否具有请求交易和/或查询的权限。例如，编排器系统210可向交易处理器120的授权系统发出内部API调用。

在一个实施例中，编排器系统210可为电子资金转账请求(或支付请求)的执行提供便利。例如，编排器系统210可向交易处理器120的账户验证查询系统发出内部API调用，以验证源账户是否存在。账户验证查询系统可以验证源账户和目标账户的格式化。此外，编排器系统210可向交易处理器120的授权系统发出内部API调用，以验证用户是否具有使用指定源账户进行支付的权限。在一个实施例中，编排器系统210可以发布对事件主题流(如Kafka)交易的支付请求。编排器系统210可向外部API调用方做出回应，告知支付请求已经被受理。

在一个实施例中，编排器系统210可实时地处理交易查询。例如，编排器系统210可向交易查询系统发出内部API调用，以进行交易查找。此外，编排器系统210可向授权系统发出内部API调用，以验证用户是否具有查看交易和相关账户的权限。此外，编排器系统210可通过API系统122对外部API调用做出回应，并提供查询响应。

仍参照图2，门户系统212可促进用户(或顾客)或开发人员的订阅管理、层级和功能配置、顾客管理、资金来源管理等。门户系统212可允许请求方系统110的开发人员或用户实时地发起交易或付款请求、传输交易状态、接收通知等。门户系统212可促进或提供集成门户，集成门户可包括统一开发人员门户(如沙盒界面)，开发人员可利用此门户将请求方系统110与交易处理器120集成。集成门户可以使开发人员配置请求系统110，以访问交易处理器120、与交易处理器120进行通信以及使用交易处理器120的功能。在某些实施例中，集成门户可包括交易处理器120的互动营销平台。例如，营销平台可提供关于支付如何发生、交易处理器后台发生什么的演示部分，以及访问交易处理器120、与交易处理器120通信和利用交易处理器120功能的各种用例。因此，集成门户可通过营销门户和集成门户实现请求方系统110与交易处理器120的无缝集成。在一个实施例中，集成门户可包括与交易处理器120API的实时连接、用于与交易处理器120通信的代码片段以及用于认证与交易处理器120通信的API的认证界面。可以不同的语言实时提供代码片段。例如，通过在实时沙盒环境中编辑片段，即可实现将RTP方案更改为不同的方案。此外，集成门户还可向开发人员提供统一资源定位器(URL)链接，以便按照所提供的链接，使用通用API，轻松直观地与交易处理器120集成，而无需存储任何单独的URL。此外，还可通过集成门户实时更新交易。例如，可根据到期日、取消付款的能力等更改支付渠道。此外，集成门户可提供关于交易的通知，用户无需发送电子邮件或拨打电话即可访问和查看通知。

仍参照图2，路由系统214可促进路由决定、最快路由、最低成本路由、市场方案配置、市场路由配置、多地理位置路由等。路由系统214可通过同时查看顾客配置和方案能力来执行交易路由。可以利用顾客和方案中与价格、速度和能力相关的数据，根据特定顾客的配置，以及顾客是否对速度和成本处理有偏好，确定电子交易的最佳可能路由。路由系统214可利用开源业务规则管理系统(BRMS)(如Drools)来实现路由决策模型。路由系统214可促进和编排路由和执行支付请求所需的步骤。路由系统214可订阅交易事件主题，并可根据支付发起的事件采取行动，发起路由请求。在一个实施例中，路由系统214可向权限查询系统发出内部API调用，以检索可能影响支付请求路由的顾客特定配置详细信息。路由系统214可通过路由模型处理交易请求(包括顾客权限详细信息)，以确定适当的支付方案适配器(下文将进一步详述)。路由系统214可向一个或多个支付方案适配器发出内部API调用，然后再调用市场特定支付方案实施。此外，路由系统214还可将选定的路由事件发布到交易事件主题数据流中。

仍参照图2，交易系统216可促进电子资金转账请求、电子资金转账信息请求、电子资金转账通知书、电子资金转账授权、确认、撤销、修改和退款等。交易系统216可与通知或消息系统222进行通信。通知系统222可接收来自支付方案(例如方案142a-142n)的通知，以便在交易的整个生命周期中提供状态更新。通过API系统122，即可接收来自支付方案的通知，以及相关方案详细信息。通知系统222可通过确认对通知做出响应。然后，通知系统222可将收到支付通知事件发布到支付通知主题中。在一个实施例中，通知系统222可包括一个支付通知处理程序，所述处理程序订阅支付通知主题，并等待收到支付通知消息。也就是说，在处理事件时，支付通知处理程序可首先向交易查询系统发出内部API调用，以检索与支付通知相关的交易的其他详细信息。然后，支付通知处理程序可向支付通知主题发布支付确认消息。

连接系统130可包括一个或多个用于与交易网络140通信的适配器。例如，市场1132a的连接适配器可包括TCH RTP适配器、ACH适配器、账户对银行卡适配器、电汇适配器、支付适配器、账户对钱包适配器、清算/结算适配器等。此外或可替代地，市场N 132n的连接适配器同样可包括ACH适配器、电汇适配器、方案适配器、电汇适配器、转账通适配器、账户对钱包适配器、清算/结算适配器等。

在一个实施例中，交易系统216可接收与本公开的电子交易相关的信息，并促进电子交易的执行。交易系统216可将交易信息传输到代币化系统224。然后，代币化系统224可生成代币，将替代值用于请求方系统110所请求的支付交易中使用的敏感账户详细信息。代币可以是低值代币，也可以是高值代币。此外，代币还可以是一个随机生成的数字。在其他实施例中，代币可以是伪随机数、加密信息或其他字符序列。

可在多个地区和可用区的服务器和数据中心部署交易处理器120。交易处理器120可以是采用容器化微服务的云原生和云无关性处理器，并可在开源容器编排系统(如Kubernetes)上的弹性基础设施中进行部署。在一个实施例中，可完全在云中部署和构建交易处理器120。因此，可通过基于云的微服务设计(如AWS云基础设施)从头开始构建，从而控制交易处理器120的复杂性。本公开基于云的微服务设计可允许快速增强和弹性扩展交易处理器120，而不会对顾客产生影响或造成停机。例如，小型开发人员团队可快速添加增强功能和新方案支持。此外，还可以控制故障，并可防止对其他功能造成附带损害。

图3显示了一个用于促进本公开的电子交易请求(如支付请求)的示例性系统300。系统300可包括请求方系统110、交易处理器120、交易网络140和接收方系统310。在本实施例中，除图3所述系统以外，交易处理器120还可包括一个或多个系统或微服务。例如，交易处理器120可包括一个授权系统302、一个账户验证系统304、一个账户分类账系统306和一个审计系统220，这些系统可与编排器系统210进行通信。在本实施例中，连接系统130可包括一个或多个方案或网络适配器。例如，连接系统130可包括RTP适配器312a、ACH适配器312b、电汇适配器312n等。此外，连接系统130还可包括连接器314a-n，连接器314a-n可促进与交易网络140的通信。

仍参照图3，授权系统302可暴露某个内部API，交易处理器120中的其他系统或微服务可以调用该API，以验证用户是否具有执行操作和查看数据的权限。账户验证系统304可暴露某个内部API，交易处理器120中的其他系统或微服务可调用该API，以便对存储在交易处理器数据库(图中未显示)中的账户详细信息进行查询。账户分类账系统306可暴露某个内部API，交易处理器120中的其他系统或微服务可调用该API，以便对存储在交易处理器120数据库中的账户分类账详细信息进行查询。账户分类账系统306可根据本公开订阅由编排器系统210传输的Kafka流的交易事件主题。此外，账户分类账系统306还可以观察完整状态，并利用这些事件更新分类账数据库。在一个实施例中，审计系统220可订阅由编排器系统210传输的Kafka流的交易事件主题。审计系统220可将这些事件传输到数据湖进行分析。

仍参照图3，交易系统216可暴露某个内部API，交易处理器120中的其他系统或微服务可调用该API，以针对存储在交易处理器120所提供的不仅仅结构化查询语言(NoSQL)数据库中的账户详细信息进行查询。如图2所述，路由系统214可负责编排路由和执行支付请求所需的步骤。路由系统214可订阅编排器系统210传输的Kafka流的交易事件主题，并可根据支付发起的事件采取行动，发起路由请求。路由系统214可向权限查询服务发出内部API调用，以检索可能影响路由的顾客特定配置详细信息。路由系统214可通过路由模型处理请求(包括顾客权限详细信息)，以确定适当的支付方案适配器。

仍参照图3，RTP适配器312a可暴露某个用于处理跨RTP方案或渠道支付的内部API。RTP方案适配器312a可调用内部/外部市场特定API RTP渠道实现。ACH适配器可暴露某个用于处理跨ACH渠道支付的内部API。ACH适配器312b可调用内部/外部市场特定API ACH渠道实现。电汇适配器312n可暴露某个用于处理跨电汇渠道支付的内部API。电汇适配器312n可调用内部/外部市场特定API电汇渠道实现。

在一个实施例中，可由API系统122管理来自请求方系统110用户(例如支付发送方)的传入支付请求(例如支付请求API)。API系统122可通过与交易处理器120的身份提供程序(IdP)通信，对用户身份进行验证检查(例如通过开放授权2.0(OAuth2))。然后，API系统122可将支付请求转发给支付编排器系统210。然后，编排器系统210可向授权系统302发起授权检查。一旦授权系统302确认请求方系统110拥有进行交易的权限，编排器系统210就可与账户验证系统304通信，以检查交易处理器120的数据库中是否存在请求方系统110中的用户。然后，编排器系统210可将账户分类账系统306、审计系统220、交易系统216和路由系统214接收到的Kafka消息进行流式处理。

仍参照图3，路由系统214可将支付请求转发给连接系统130中的最佳方案(或渠道)适配器。然后，连接系统130可将支付请求传输到交易网络140中的适当方案(例如方案142a-142n)。在一个实施例中，第三方服务提供商可直接实现连接系统130所提供的一个或多个适配器。因此，交易处理器120可能不需要与第三方服务提供商API集成。

图4显示了一个用于促进本公开交易对账和通知的示例性系统400。系统400可包括请求方系统110、交易处理器120、交易网络140和接收方系统310。在本实施例中，除图3和4所述系统以外，交易处理器120还可包括一个身份验证系统401、一个文件传输系统402、一个方案通知系统404、一个支付通知处理程序406和一个交易查询系统408。在一个实施例中，身份验证系统401可利用OAuth2协议针对交易处理器120的身份提供程序(IdP)对API进行身份验证。此外，身份验证系统401可以对访问门户系统212的用户名和密码进行身份验证。在一个实施例中，方案通知系统404可以将方案特定通知翻译成通用的非方案特定格式。文件传输系统402可将从方案142a-142n接收到的通知汇总到一个文件中，并根据已配置的偏好发送到接收方系统310。交易查询系统408可暴露某个内部API，该API可由交易处理器120的其他系统或微服务调用，以便针对NoSQL数据库中存储的账户详细信息进行查询。此外，交易查询系统408可从交易处理器120的Kafka流订阅交易事件主题，并可利用这些事件更新NoSQL数据库。在一个实施例中，支付通知处理程序406可订阅支付通知主题，并等待收到支付通知消息。也就是说，在处理事件时，支付通知处理程序406可首先向交易查询系统408发出内部API调用，以检索与支付通知相关的交易的其他详细信息。然后，支付通知处理程序406可向支付通知主题发布支付确认消息。

在一个实施例中，在对交易进行处理时，交易网络140中的方案142a-142n可向交易处理器120提供交易更新。更新可由API系统122接收，或作为由文件传输系统402处理的批处理文件(安全文件传输协议(SFTP)推送或拉取)。还可由身份验证系统401对更新进行身份验证，以验证更新的发送方。验证成功后，可将更新发送到方案通知系统404。方案通知系统404可以将方案特定通知翻译成通用的非方案特定格式。通用消息可推送到Kafka消息队列，并由支付通知处理程序406接收。支付通知处理程序406可调用交易查询系统408，从交易处理器120的数据库中检索交易详细信息。然后，支付通知处理程序406可将Kafka消息传输到账户分类账系统306、审计系统220和交易系统216和/或文件传输系统402。文件传输系统402可将通知汇总到一个文件中。然后，基于已配置的偏好(例如，向已配置的HTTP端点发送Webhook、向已配置的SFTP端点发送SFTP推送和/或从接收方系统310向交易处理器的SFTP服务器发送SFTP拉取)，将通知文件发送到接收方系统310。因此，本公开的对账和通知方面可以向请求方系统110提供实时支付状态，让交易请求方始终了解支付的进展情况。

图5显示了一个用于促进与本公开实施例一致的电子交易的交易路由的示例性系统500。系统500可包括路由系统214、欺诈监控系统530和机器学习系统532。在本实施例中，路由系统214可包括一个或多个路由决策模型502。在一个实施例中，路由系统214可基于顾客配置和方案能力中的一项或两项进行交易路由。也就是说，路由系统214可考虑顾客和方案(例如方案142a-142n)中的价格、速度和能力变量，并为交易确定最佳可能路由(例如最快、最便宜、最能获得回报、最受欢迎等)。可根据顾客的配置或偏好(如速度与成本处理偏好)确定交易路由。在一个实施例中，路由决策模型502可利用至少以下数据来确定执行本公开电子交易(如支付请求)的最佳路径：当前日期504、交易金额506、期望的交易日期508、方案执行日期510、方案决策512、方案假期520、方案处理时间522、方案成本524、方案金额限制526和顾客偏好528。例如，执行支付请求的最佳路径可基于用户(或客户)期望的偏好。在一个实施例中，可基于两个关键输入(例如：交易金额506和期望的交易日期508)来执行路由决策模型502。也就是说，路由决策模型502可考虑到顾客偏好和业务知识，从而做出关于交易方案142a-142n和方案执行日期510的决策。

在一个实施例中，路由决策模型502可考虑一个或多个路由标准，以确定最佳交易路由。例如，在地理位置方面，可以考虑以下问题：1)这是否是美国国内交易？2)这是否是英国国内交易？3)这是否属于跨境交易？等等。每个选项都可能影响或改变可用的路由，并影响路由决策模型502的决策过程。关于方案假期520和交易处理时间522，与RTP方案不同，其他方案或渠道可能需要数天时间来处理交易。为了确保交易得到及时处理，可以计算并追溯处理时间，以确保不忽略任何非处理窗口，如周末或银行假期。关于方案(或渠道)成本524，不同渠道的成本可能有所不同。因此，根据顾客偏好，可通过最便宜的路由进行交易。关于方案金额限制526，交易可超过特定渠道的最大允许阈值。在这种情况下，路由决策模型502可能不会考虑该特定路由选项，或者有可能在多个支付渠道之间拆分交易。

在一个实施例中，可在不同层级上配置路由决策模型502建立的规则，例如：全系统范围的规则；支付方案的特定规则；以及客户定制的特定规则。基于路由决策模型502规则的不同层级，可以为用户提供用于确定交易请求路由的各种选项。在一个实施例中，可以多种方式定义客户定制的特定规则。例如，路由系统214可基于规定的用户偏好确定交易请求的路由。也就是说，用户可以决定(例如用户定义的支付方式)交易请求的路径(例如特定的支付方案、支付路由、支付时间等)。此外或可替代地，路由系统214还可以通过用户界面(例如图形化用户控制面板)向用户提供可用的路由选项。例如，路由系统214可基于路由决策模型502提供用户可选择用于完成交易请求的不同持续时间和成本选项的列表。然后，路由系统214可基于用户选择的选项发送交易请求。此外或可替代地，用户还可以通过用户界面向路由系统214提供一个或多个用户偏好(如交易金额、交易到期日等)。然后，路由系统214可利用路由决策模型502，基于用户提供的偏好，为用户确定和决定最佳路由。

除了基于规则的路由输入以外，路由系统214还可以接收来自欺诈监控系统530的实时反馈。也就是说，根据欺诈监控系统530进行的欺诈特征剖析，交易可能会被路由到不同的渠道。例如，如果信贷方案允许扣款撤销，则风险交易可从RTP方案转移到信贷方案。另外，机器学习系统532的输入可提供带外、非实时的机器学习反馈，以便在发现微妙趋势时调整支付路由。

图6显示了一个执行本公开电子交易的示例性方法600的流程图。下文将描述根据上述系统100、200和300执行的方法600的示例性过程流程。

在步骤610中，API系统122可接收来自用户(例如请求方系统110)的支付请求。在步骤612中，API系统122可与身份验证系统302通信，以验证用户身份。身份验证系统302可与交易处理器120的身份供应程序(IdP)通信，以验证用户身份的真实性。在步骤614中，API系统122可将支付请求传输到编排器系统210。在步骤616中，编排器系统210可向交易处理器的授权系统601发出内部API调用。授权系统601可验证用户是否具有执行支付请求的权限。然后，授权系统601可将授权响应传输到编排器系统210。在步骤618中，编排器系统210可向账户验证系统602发出内部API调用，以验证交易处理器120中是否存在与支付请求相关的参考银行账户。在步骤620中，账户验证系统602可与交易处理器120的账户查询系统604通信，以确认交易处理器120之外是否存在与支付请求相关的银行账户。在步骤622中，账户验证系统602可将验证响应消息传输到编排器系统210。在步骤624中，编排器系统210可向授权系统601发出内部API调用，以验证用户是否有权限针对发送方账户进行交易。然后，授权系统601可将授权响应传输到编排器系统210。在步骤626中，编排器系统210可通过事件主题流(例如Kafka流)向账户分类账系统306、审计系统220和交易系统216发布支付请求消息。编排器系统210还可向用户做出回应，告知支付请求已经被受理。此外，还可将支付请求消息发送给订阅者进行处理。例如，路由系统214可接收支付请求事件，并可开始处理支付。交易查询系统可接收支付请求事件，并更新其NoSQL数据库。账户分类账系统306可接收支付请求事件，但由于支付尚未完成，因此账户分类账系统306可忽略此事件。在步骤628中，审计系统220可将支付请求事件传输到数据库系统604进行分析。

图7显示了一个执行本公开电子交易路由的示例性方法700的流程图。下文将描述根据上述系统100、200、300和500执行的方法700的示例性过程流程。

在步骤710中，路由系统214可通过事件主题流702(例如Kafka流)接收来自编排器系统601的支付请求事件。在步骤712中，路由系统214可通过API调用向权限查询系统704发送查询请求，以检索可能影响路由路径和/或支付请求事件定时的顾客配置。例如，权限查询系统704可利用结构化查询语言(SQL)与数据库进行通信，该数据库可存储顾客配置数据。在步骤714中，权限查询系统704可将已请求的顾客配置数据传输到路由系统214。路由系统214可通过路由决策模型502运行支付请求和顾客配置数据，以确定发送支付请求的最佳路由。在步骤716中，路由系统214可向事件主题流702发布最佳路由(例如所选路由)信息。然后，事件主题流702的任何订阅者均可利用所选路由信息进行进一步处理。在步骤718中，路由系统704可根据顾客配置数据生成信息性消息，并将信息性消息传输到顾客。在一个实施例中，信息性消息可包括关于交易执行前所选交易(或支付)路由的信息。因此，顾客可以在交易执行前检验并确认所选的交易路由。此外或可替代地，路由系统214可立即或在未来某个时间，根据最佳路由，通过API调用，安排支付请求并传输到连接系统130中的适当网络/方案适配器(例如312a-312n)。在步骤720中，所选联网/方案适配器可通过API调用在交易网络140中传输市场特定支付方案实现，以便执行和完成支付请求。

图8显示了根据本公开所述的请求电子交易的另一示例性方法800的流程图。下文将介绍根据上述系统100、200、300、500和700执行方法800的示例性过程流程。

在步骤802中，路由系统(例如路由系统214)可接收来自用户的电子交易请求(例如支付请求)。在步骤804中，路由系统可接收来自数据查询系统(例如权限查询系统704)的路由配置数据。路由配置数据可包括用户偏好，用户偏好可至少包括交易金额或期望的交易完成日期。在一个实施例中，路由系统可通过交易事件主题流接收来自用户的电子请求。

在步骤806中，路由系统可根据路由决策模型和路由配置数据，确定用于执行电子交易的最佳路径。路由决策模型可包括路由标准。此外，所述路由标准至少包括地理信息、交易处理时间、银行假期、交易网络方案成本、交易方案金额限制或交易路由的货币汇率。在一个实施例中，路由系统可配置至少基于全系统规则、支付方案规则或定制用户特定规则的路由决策模型。此外，路由系统可将交易数据传输到机器学习系统(例如机器学习系统532)，并接收来自机器学习系统的调整后的路由规则。此外，路由系统可接收来自欺诈特征剖析系统(例如欺诈监控系统530)的实时反馈。此外，路由系统214可接收在路由决策中需要考虑的不同路由的货币兑换率信息。

在步骤808中，路由系统可经由最佳路径将电子交易请求传输到交易网络。在步骤810中，路由系统可生成基于最佳路径的交易路由数据。在一个实施例中，路由系统可将应用编程接口(API)调用传输到数据查询系统，以请求路由配置数据。在步骤812中，路由系统可将交易路由数据传输到交易事件主题流。

除了标准台式机或服务器以外，以下情况也完全属于本公开的范围，即任何能够满足所需存储和处理需求的计算机系统都将适用于实施本公开的实施例。其中可包括平板设备、智能手机、密码输入器和任何其他计算机设备，无论是移动设备还是分布在网络上的设备(即基于云的设备)。

除非另有特别说明，从下面讨论中可以明显看出，在整个说明书的讨论中，应理解，术语“处理”、“运算”、“计算”、“确定”、“分析”或类似术语指的是计算机或计算系统或类似电子计算设备的操作和/或过程，这些操作和/或过程将以物理量(如电子量)表示的数据操作和/或转换成同样以物理量表示的其他数据。

同样，术语“处理器”可指处理电子数据的任何设备或设备的一部分，例如，从寄存器和/或内存中处理电子数据，将电子数据转换成可存储在寄存器和/或内存中的其他电子数据。“计算机”、“计算机器”、“计算平台”、“计算设备”或“服务器”可包括一个或多个处理器。

图9显示了指定编号为900的计算机系统。计算机系统900可包括一组指令，执行这些指令可使计算机系统900执行本发明中公开的任何一种或多种方法或基于计算机的功能。计算机系统900可作为独立的设备运行，也可利用网络等方式与其他计算机系统或外围设备连接。

在网络部署中，计算机系统900可以服务器的身份运行，或在服务器-客户端用户网络环境中作为客户端用户计算机运行，或在点对点(或分布式)网络环境中作为对等计算机系统运行。计算机系统900还可作为各种设备实现，或者集成到各种设备中，例如个人计算机(PC)、平板电脑、机顶盒(STB)、个人数字助理(PDA)、移动设备、掌上电脑、笔记本电脑、台式计算机、通信设备、无线电话、固定电话、控制系统、相机、扫描仪、传真机、打印机、寻呼机、个人可信设备、环球网设备、网络路由器、交换机或网桥，或任何其他能够执行一组指令(顺序指令或其他指令)的机器。在一个特定实施方式中，可利用提供语音、视频或数据通信的电子设备来实现计算机系统900。此外，虽然图中显示的是单个计算机系统900，但是“系统”一词也应视为包括任何系统或子系统的集合，这些系统或子系统可单独或共同执行一组或多组指令，以执行一项或多项计算机功能。

如图9所示，计算机系统900可包括一个处理器902，例如中央处理器(CPU)、图形处理器(GPU)或两者兼有。处理器902可以是各个系统中的一个组件。例如，处理器902可以是标准个人电脑或工作站的一部分。处理器902可以是一个或多个通用处理器、数字信号处理器、专用集成电路、现场可编程门阵列、服务器、网络、数字电路、模拟电路及其组合或其他现在已知或后来开发的数据分析处理设备。处理器902可以执行软件程序，如手动生成(即编程)的代码。

计算机系统900可包括一个可通过总线908进行通信的存储器904。存储器904可以是主存储器、静态存储器或动态存储器。存储器904可包括但不限于计算机可读存储介质，如各种类型的易失性和非易失性存储介质，包括但不限于随机存取存储器、只读存储器、可编程只读存储器、电可编程只读存储器、电可擦除只读存储器、闪存、磁带或磁盘、光学介质等。在一个实施方式中，存储器904包括一个用于处理器902的高速缓存或随机存取存储器。在可替代实施方式中，存储器904与处理器902分离，例如处理器的缓存存储器、系统存储器或其他存储器。存储器904可以是用于存储数据的外部存储设备或数据库。示例包括硬盘驱动器、光盘(“CD”)、数字视频光盘(“DVD”)、存储卡、记忆棒、软盘、通用串行总线(“USB”)存储设备或任何其他可用于存储数据的设备。存储器904可用于存储处理器902可执行的指令。图中所示或本发明所述的功能、行为或任务可由执行存储在存储器904中的指令的编程处理器902执行。这些功能、行为或任务与特定类型的指令集、存储介质、处理器或处理策略无关，并可由软件、硬件、集成电路、固件、微代码等单独或联合执行。同样，处理策略可包括多处理、多任务、并行支付等。

如图所示，计算机系统900可进一步包括一个显示单元910，如液晶显示器(LCD)、有机发光二极管(OLED)、平板显示器、固态显示器、阴极射线管(CRT)、投影仪、打印机或其他现在已知或后来开发的用于输出已确定信息的显示设备。显示器910可作为用户查看处理器902运行情况的界面，或具体作为与存储在存储器904或驱动单元906中的软件的界面。

此外或可替代地，计算机系统900还可包括一个输入设备912，输入设备912允许用户与系统900的任何组件进行交互。输入设备912可以是数字键盘、键盘或光标控制设备，如鼠标、操纵杆、触摸屏显示器、遥控器或任何其他与计算机系统900交互的设备。

计算机系统900还可(或可替代地)包括一个磁盘驱动器单元或光驱单元906。磁盘驱动器单元906可包括一个计算机可读介质922，其中可嵌入一组或多组指令924，例如软件。此外，指令924可以体现本发明所述的一种或多种方法或逻辑。在由计算机系统900执行期间，指令924可完全或部分位于存储器904和/或处理器902中。如上所述，存储器904和处理器902还可包括计算机可读介质。

在一些系统中，计算机可读介质922包括指令924，或接收并执行响应传播信号的指令924，使得连接到网络970的设备能够通过网络970传达语音、视频、音频、图像或任何其他数据。此外，可通过通信端口或接口920和/或利用总线908在网络970上传输或接收指令924。通信端口或接口920可以是处理器902的一部分，也可以是单独组件。可在软件中创建通信端口920，也可以是硬件中的物理连接。通信端口920可与网络970、外部介质、显示器910或系统900中的任何其他组件或其组合连接。与网络970的连接可以是物理连接，例如有线以太网连接，也可以通过无线方式建立连接，如下文所述。同样，与系统900其他组件的附加连接可以是物理连接，也可以通过无线方式建立连接。网络970可替代地与总线908直接连接。

虽然计算机可读介质922显示为单一介质，但“计算机可读介质”一词可包括单一介质或多种介质，例如集中式或分布式数据库，和/或存储一组或多组指令的相关缓存和服务器。术语“计算机可读介质”还可包括能够存储、编码或携带一组指令的任何介质，这些指令可由处理器执行，或使计算机系统执行本发明中公开的任何一种或多种方法或操作。计算机可读介质922可以是非暂态计算机可读介质，也可以是有形计算机可读介质。

计算机可读介质922可包括固态存储器，如存储卡或其他包，其中包含一个或多个非易失性只读存储器。计算机可读介质922可以是随机存取存储器或其他易失性可重写存储器。此外或可替代地，计算机可读介质922可包括磁光介质或光学介质，如磁盘、磁带或其他存储设备，用于捕捉载波信号，如通过传输介质传达的信号。电子邮件或其他独立信息档案或档案集的数字文件附件可视为分发介质，即有形存储介质。相应地，本公开可视为包括可用于存储数据或指令的计算机可读介质或分发介质及其他相当介质和后继介质中的任何一种或多种。

在替代实施方式中，可以构建专用硬件实施方式，如专用集成电路、可编程逻辑阵列和其他硬件设备，以实现本发明所述的一种或多种方法。可包括各种实施方式的装置和系统的应用可广泛包括各种电子和计算机系统。本发明所述的一种或多种实施方式可利用两个或多个特定的互连硬件模块或设备来实现功能，这些硬件模块或设备采用相关的控制和数据信号，可在模块之间或通过模块传达，或作为专用集成电路的部分。相应地，本系统包括软件、固件和硬件实施方式。

计算机系统900可连接到一个或多个网络970。网络970可以定义一个或多个网络，包括有线或无线网络。无线网络可以是蜂窝电话网络、802.11、802.16、802.20或WiMAX网络。此外，此类网络还可包括公共网络(如互联网)、私有网络(如内联网)或其组合，并且可以利用现有或后来开发的各种网络协议，包括但不限于基于TCP/IP的网络协议。网络870可包括广域网(WAN)(如互联网)、局域网(LAN)、校园网、城域网、直接连接(如通过通用串行总线(USB)端口)或任何其他可进行数据通信的网络。网络870可将一台计算设备与另一台计算设备耦合，以实现设备间数据通信。网络870一般可以采用任何形式的机器可读介质，用于将信息从一个设备传达到另一个设备。网络870可包括在计算设备之间传输信息的通信方法。网络870可分为多个子网络。子网络可允许访问与其连接的所有其他组件，或限制组件之间的访问。网络870可视为公共或私有网络连接，并且可包括虚拟私有网络或在公共互联网上使用的加密或其他安全机制等。

根据本公开的各种实施方式，可通过计算机系统可执行的软件程序实现本公开所述的方法。此外，在一个示例性、非限制性实施方式中，实施方式可包括分布式处理、组件/对象分布式处理和并行支付。可替代地，可以构建虚拟计算机系统处理，以实现本发明所述的一种或多种方法或功能。

尽管本说明书描述了可以参照特定标准和协议在特定实施方式中实现的组件和功能，但是所述公开并不局限于此类标准和协议。例如，互联网及其他分组交换网络传输标准(例如TCP/IP、UDP/IP、HTML、HTTP等)代表技术现状的示例。此类标准会定期被功能基本相同、速度更快或效率更高的等同标准所取代。相应地，与本发明中公开的标准和协议具有相同或相似功能的替代标准和协议可视为其等同标准和协议。

应理解，在一个实施例中，由处理(即计算机)系统的一个适当的处理器(或多个处理器)通过执行存储在存储器中的指令(计算机可读代码)来执行所述方法的步骤。还应理解，所公开的实施例并不局限于任何特定的实施方式或编程技术，利用任何适当的技术即可实现所公开的实施例，从而实现本发明所述的功能。所公开的实施例并不局限于任何特定的编程语言或操作系统。

应理解，在上述对示例性实施例的描述中，为了简化公开并帮助理解一个或多个不同的发明方面，有时会将实施例的各种特征集中在一个实施例、附图或说明中。然而，不应将这种公开方法解读为反映一种意图，即要求保护的实施例所需的特征多于每项权利要求中明确阐述的特征。相反，正如以下权利要求所反映的那样，本发明的创造性在于不完全包含前述单一公开实施例的所有特征。因此，具体实施方式之后的权利要求特此明确纳入本具体实施方式，每项权利要求作为一个单独的实施例独立存在。

此外，本领域技术人员可以理解，虽然本发明所述的一些实施例包括一些特征，但不包括其他实施例中包含的其他特征，但是不同实施例的特征组合均属于本公开范围内的内容，并形成不同的实施例。例如，在以下权利要求中，可以在任意组合中使用任何要求保护的实施例。

此外，在本发明中，一些实施例被描述成一种方法或一种方法的要素组合，这种方法或组合可通过计算机系统处理器或其他执行该功能的手段来实现。因此，采用执行这种方法或方法要素的必要指令的处理器就构成了执行该方法或方法要素的手段。此外，装置实施例所述的一个要素是功能执行手段的一个示例，所述功能由所述要素执行，以实现所述功能。

本发明提供的说明书中阐述了许多具体细节。然而，应理解，在没有这些具体细节的情况下，也可以实施本公开的实施例。在其他情况下，为了不影响对于本说明书的理解，尚未详细展示众所周知的方法、结构和技术。

同样，需要注意，权利要求书中使用的术语“耦合”不应解读为仅限于直接连接。可以使用“耦合”、“连接”及其派生词。应理解，这些术语并不互为同义词。因此，“设备A与设备B耦合”这一表述的范围不应局限于设备A的输出端与设备B的输入端直接相连的设备或系统。这意味着在A的输出端和B的输入端之间存在一条路径，这条路径可能包括其他设备或装置。“耦合”可能是指两个或多个元件发生直接物理或电气接触，也可能是指两个或多个元件相互之间未直接接触，但仍能相互配合或相互作用。

因此，虽然本发明已经对被视为本公开优选实施例的实施例进行了说明，但本领域技术人员将会认识到，在不脱离本公开精神的前提下，还可以对本公开进行其他和进一步的修改，并且所有这些变更和修改均应纳入本公开的范围内。例如，上面给出的任何公式仅代表可以使用的程序。可在框图中添加或删除功能，功能块之间也可进行操作互换。在本公开的范围内，可以添加或删除所述方法的步骤。

上述公开主题可视为说明性主题，而非限制性主题，所附权利要求旨在涵盖属于本公开真正精神和范围内的所有此类修改、增强及其他实施方式。因此，在法律允许的最大范围内，本公开的范围需根据以下权利要求及其等同权利要求的最宽泛解释进行确定，而不应受到上述具体实施方式的约束或限制。虽然已经对本公开的各种实施方式进行了说明，但是对于本领域普通技术人员而言显而易见的是，在本公开的范围内，还可以有更多的实施方式。相应地，除所附权利要求及其等同权利要求外，本公开不受任何约束。

Claims (20)

1.一种通过实时交易系统执行实时电子交易的方法，所述方法包括：

通过路由系统接收来自用户的电子交易请求；

通过路由系统接收来自数据查询系统的路由配置数据；

通过路由系统根据路由决策模型和路由配置数据确定用于执行电子交易请求的最佳路径；

通过路由系统经由最佳路径将电子交易请求传输到交易网络；

通过路由系统生成基于最佳路径的交易路由数据；

通过路由系统将交易路由数据传输到交易事件主题流。

2.根据权利要求1所述的方法，其中，所述路由配置数据包括用户偏好，所述用户偏好至少包括交易金额或所需的交易完成日期。

3.根据权利要求1所述的方法，其中，所述路由决策模型包括路由标准，所述路由标准至少包括地理信息、交易处理时间、银行假期、交易网络方案成本或交易方案金额限制或交易路由的货币汇率。

4.根据权利要求1所述的方法，其中，经由最佳路径将电子交易请求传输到交易网络安排在未来某个时间。

5.根据权利要求1所述的方法，进一步包括：

通过路由系统配置至少基于全系统规则、支付方案规则或定制用户特定规则的路由决策模型。

6.根据权利要求1所述的方法，进一步包括：

通过路由系统接收来自欺诈特征剖析系统的实时反馈。

7.根据权利要求1所述的方法，进一步包括：

通过路由系统将交易数据传输到机器学习系统；

通过路由系统接收来自机器学习系统的调整后的路由规则。

8.根据权利要求1所述的方法，进一步包括：

通过路由系统经由交易事件主题流接收来自用户的电子交易请求。

9.根据权利要求1所述的方法，进一步包括：

通过路由系统将应用编程接口(API)调用传输到数据查询系统，以请求路由配置数据。

10.一种实时交易系统，包括：

一个或多个计算机可读介质，存储用于执行实时电子交易的指令；

一个或多个处理器，可执行指令，以进行包括以下步骤的操作：

通过路由系统接收来自用户的电子交易请求；

通过路由系统接收来自数据查询系统的路由配置数据；

通过路由系统根据路由决策模型和路由配置数据确定用于执行电子交易请求的最佳路径；

通过路由系统经由最佳路径将电子交易请求传输到交易网络；

通过路由系统生成基于最佳路径的交易路由数据；

通过路由系统将交易路由数据传输到交易事件主题流。

11.根据权利要求9所述的系统，其中，所述路由配置数据包括用户偏好，所述用户偏好至少包括交易金额或所需的交易完成日期。

12.根据权利要求9所述的系统，其中，所述路由决策模型包括路由标准，所述路由标准至少包括地理信息、交易处理时间、银行假期、交易网络方案成本、交易方案金额限制或交易路由的货币汇率。

13.根据权利要求9所述的系统，其中，所述操作进一步包括：

通过路由系统配置至少基于全系统规则、支付方案规则或定制用户特定规则的路由决策模型。

14.根据权利要求9所述的系统，其中，所述操作进一步包括：

通过路由系统接收来自欺诈特征剖析系统的实时反馈。

15.根据权利要求9所述的系统，其中，所述操作进一步包括：

通过路由系统将交易数据传输到机器学习系统；

通过路由系统接收来自机器学习系统的调整后的路由规则。

16.根据权利要求9所述的系统，其中，所述操作进一步包括：

通过路由系统经由交易事件主题流接收来自用户的电子交易请求；

通过路由系统将应用编程接口(API)调用传输到数据查询系统，以请求路由配置数据。

17.一种存储用于执行实时电子交易的指令的非暂态计算机可读介质，在通过一个或多个处理器执行时，所述指令可使所述一个或多个处理器进行包括以下步骤的操作：

通过路由系统接收来自用户的电子交易请求；

通过路由系统接收来自数据查询系统的路由配置数据；

通过路由系统根据路由决策模型和路由配置数据，确定用于执行电子交易请求的最佳路径；

通过路由系统经由最佳路径将电子交易请求传输到交易网络；

通过路由系统生成基于最佳路径的交易路由数据；

通过路由系统将交易路由数据传输到交易事件主题流。

18.根据权利要求17所述的非暂态计算机可读介质，其中，所述路由配置数据包括用户偏好，所述用户偏好至少包括交易金额或所需的交易完成日期；

其中，所述路由决策模型包括路由标准，所述路由标准至少包括地理信息、交易处理时间、银行假期、交易网络方案成本、交易方案金额限制或交易路由的货币汇率。

19.根据权利要求17所述的非暂态计算机可读介质，其中，所述操作进一步包括：

通过路由系统配置至少基于全系统规则、支付方案规则或定制用户特定规则的路由决策模型；

通过路由系统接收来自欺诈特征剖析系统的实时反馈；

通过路由系统将交易数据传输到机器学习系统；

通过路由系统接收来自机器学习系统的调整后的路由规则。

20.根据权利要求17所述的非暂态计算机可读介质，其中，所述操作进一步包括：

通过路由系统经由交易事件主题流接收来自用户的电子交易请求；

通过路由系统将应用编程接口(API)调用传输到数据查询系统，以请求路由配置数据。