安全电子交易协议具体条款

⑴ 电子商务中的安全协议是什么意思

安全协议是以密码学为基础的消息交换协议，其目的是在网络环境中提供各种安全服务。密码学是网络安全的基础，但网络安全不能单纯依靠安全的密码算法。安全协议是网络安全的一个重要组成部分，我们需要通过安全协议进行实体之间的认证、在实体之间安全地分配密钥或其它各种秘密、确认发送和接收的消息的非否认性等。

安全协议是建立在密码体制基础上的一种交互通信协议，它运用密码算法和协议逻辑来实现认证和密钥分配等目标。

安全协议可用于保障计算机网络信息系统中秘密信息的安全传递与处理，确保网络用户能够安全、方便、透明地使用系统中的密码资源。安全协议在金融系统、商务系统、政务系统、军事系统和社会生活中的应用日益普遍，而安全协议的安全性分析验证仍是一个悬而未决的问题。在实际社会中，有许多不安全的协议曾经被人们作为正确的协议长期使用，如果用于军事领域的密码装备中，则会直接危害到军事机密的安全性，会造成无可估量的损失。这就需要对安全协议进行充分的分析、验证，判断其是否达到预期的安全目标。

网络安全是实现电子商务的基础，而一个通用性强，安全可靠的网络协议则是实现电子商务安全交易的关键技术之一，它也会对电子商务的整体性能产生很大的影响。由美国Netscape公司开发和倡导的SSL协议（Secure Sockets Layer，安全套接层），它是目前安全电子商务交易中使用最多的协议之一，内容主要包括协议简介、记录协议、握手协议、协议安全性分析以及应用等。本文在简单介绍SSL协议特点和流程的基础上，详细介绍了SSL协议的应用和配置过程。

1 、SSL协议简介

SSL作为目前保护Web安全和基于HTTP的电子商务交易安全的事实上的，被许多世界知名厂商的Intranet和Internet网络产品所支持，其中包括Netscape、Microsoft、IBM 、Open Market等公司提供的支持SSL的客户机和服务器产品，如IE和Netscape浏览器，IIS、Domino Go WebServer、Netscape Enterprise Server和Appache等Web Server等。

SSL采用对称密码技术和公开密码技术相结合，提供了如下三种基本的安全服务：秘密性。SSL客户机和服务器之间通过密码算法和密钥的协商，建立起一个安全通道。以后在安全通道中传输的所有信息都经过了加密处理，网络中的非法窃听者所获取的信息都将是无意义的密文信息。

完整性。SSL利用密码算法和hash函数，通过对传输信息特征值的提取来保证信息的完整性，确保要传输的信息全部到达目的地，可以避免服务器和客户机之间的信息内容受到破坏。

认证性。利用证书技术和可信的第三方CA，可以让客户机和服务器相互识别的对方的身份。为了验证证书持有者是其合法用户(而不是冒名用户)，SSL要求证书持有者在握手时相互交换数字证书，通过验证来保证对方身份的合法性。

SSL协议的实现属于SOCKET层，处于应用层和传输层之间，由SSL记录协议（SSL RECORD PROTOCOL）和SSL握手协议（SSL HAND-SHAKE PROTOCOL）组成的，其结构如图1所示：

SSL可分为两层，一是握手层，二是记录层。SSL握手协议描述建立安全连接的过程，在客户和服务器传送应用层数据之前，完成诸如加密算法和会话密钥的确定，通信双方的身份验证等功能；SSL记录协议则定义了数据传送的格式，上层数据包括SSL握手协议建立安全连接时所需传送的数据都通过SSL记录协议再往下层传送。这样，应用层通过SSL协议把数据传给传输层时，已是被加密后的数据，此时TCP/IP协议只需负责将其可靠地传送到目的地，弥补了 TCP/IP协议安全性较差的弱点。

Netscape公司已经向公众推出了SSL的参考实现（称为SSLref）。另一免费的SSL实现叫做SSLeay。SSLref和SSLeay均可给任何TCP/IP应用提供SSL功能，并且提供部分或全部源代码。Internet号码分配当局（IANA）已经为具备SSL功能的应用分配了固定端口号，例如，带SSL的HTTP（https）被分配以端口号443，带SSL的SMTP（ssmtp）被分配以端口号465，带SSL的NNTP （snntp）被分配以端口号563。

微软推出了SSL版本2的改进版本，叫做PCT（私人通信技术）。SSL和PCT非常类似。它们的主要差别是它们在版本号字段的最显著位（The Most Significant Bit）上的取值有所不同：SSL该位取0，PCT该位取1。这样区分之后，就可以对这两个协议都给予支持。

1996年4月，IETF授权一个传输层安全（TLS）工作组着手制订一个传输层安全协议（TLSP），以便作为标准提案向IESG正式提交。TLSP将会在许多地方酷似SSL。

2 、SSL安全性

目前，几乎所有操作平台上的WEB浏览器（IE、Netscatp）以及流行的Web服务器（IIS、Netscape Enterprise Server等）都支持SSL协议。因此使得使用该协议便宜且开发成本小。但应用SSL协议存在着不容忽视的缺点：

1. 系统不符合国务院最新颁布的《商用密码管理条例》中对商用密码产品不得使用国外密码算法的规定，要通过国家密码管理委员会的审批会遇到相当困难。

2. 系统安全性差。SSL协议的数据安全性其实就是建立在RSA等算法的安全性上，因此从本质上来讲，攻破RSA等算法就等同于攻破此协议。由于美国政府的出口限制，使得进入我国的实现了SSL的产品（Web浏览器和服务器）均只能提供512比特RSA公钥、40比特对称密钥的加密。目前已有攻破此协议的例子：1995年8月，一个法国学生用上百台工作站和二台小型机攻破了Netscape对外出口版本；另外美国加州两个大学生找到了一个“陷门”，只用了一台工作站几分钟就攻破了Netscape对外出口版本。

但是，一个安全协议除了基于其所采用的加密算法安全性以外，更为关键的是其逻辑严密性、完整性、正确性，这也是研究协议安全性的一个重要方面，如果一个安全协议在逻辑上有问题，那么它的安全性其实是比它所采用的加密算法的安全性低，很容易被攻破。从目前来看，SSL比较好地解决了这一问题。不过SSL协议的逻辑体现在SSL握手协议上，SSL握手协议本身是一个很复杂的过程，情况也比较多，因此我们并不能保证SSL握手协议在所有的情况下逻辑上都是正确的，所以研究SSL协议的逻辑正确性是一个很有价值的问题。

另外，SSL协议在“重传攻击”上，有它独到的解决办法。SSL协议为每一次安全连接产生了一个128位长的随机数——“连接序号”。理论上，攻击者提前无法预测此连接序号，因此不能对服务器的请求做出正确的应答。但是计算机产生的随机数是伪随机数，它的实际周期要远比2128小，更为危险的是有规律性，所以说SSL协议并没有从根本上解决“信息重传”这种攻击方法，有效的解决方法是采用“时间戳”。但是这需要解决网络上所有节点的时间同步问题。

总的来讲，SSL协议的安全性能是好的，而且随着SSL协议的不断改进，更多的安全性能、好的加密算法被采用，逻辑上的缺陷被弥补，SSL协议的安全性能会不断加强。

3、 windows 2000中SSL的配置与应用SSL的典型应用主要有两个方面，一是客户端，如浏览器等；另外一个就是服务器端，如Web服务器和应用服务器等。目前，一些主流浏览器（如IE和 Netscape等）和IIS、Domino Go WebServer、Netscape Enterprise Server、Appache等Web服务器都提供了对SSL的支持。要实现浏览器（或其他客户端应用）和Web服务器（或其他服务器）之间的安全SSL 信息传输，必须在Web服务器端安装支持SSL的Web服务器证书，在浏览器端安装支持SSL的客户端证书（可选），然后把URL中的“http://” 更换。

⑵ 安全电子交易协议英文

SET= Secure Electronic Transaction

⑶ 安全电子交易协议的简介

People today pay for online purchases by sending their credit card details to the merchant. A protocol such as SSL or TLS keeps the card details safe from eavesdroppers, but does nothing to protect merchants from dishonest customers or vice-versa. SET addresses this situation by requiring cardholders and merchants to register before they may engage in transactions. A cardholder registers by contacting a certificate authority, supplying security details and the public half of his proposed signature key. Registration allows the authorities to vet an applicant, who if approved receives a certificate confirming that his signature key is valid. All orders and confirmations bear digital signatures, which provide authentication and could potentially help to resolve disputes.
A SET purchase involves three parties: the cardholder, the merchant, and the payment gateway (essentially a bank). The cardholder shares the order information with the merchant but not with the payment gateway. He shares the payment information with the bank but not with the merchant. A set al signature accomplishes this partial sharing of information while allowing all parties to confirm that they are handling the same transaction. The method is simple: each party receives the hash of the withheld information. The cardholder signs the hashes of both the order information and the payment information. Each party can confirm that the hashes in their possession agrees with the hash signed by the cardholder. In addition, the cardholder and merchant compute equivalent hashes for the payment gateway to compare. He confirms their agreement on the details withheld from him.
All parties are protected. Merchants do not normally have access to credit card numbers. Moreover, the mere possession of credit card details does not enable a criminal to make a SET purchase; he needs the cardholder’s signature key and a secret number that the cardholder receives upon registration. The criminal would have better luck with traditional frauds, such as ordering by telephone. It is a pity that other features of SET (presumably demanded by merchants) weaken these properties. A merchant can be authorized to receive credit card numbers and has the option of accepting payments given a credit card number alone.
SET is a family of protocols. The five main ones are cardholder registration, merchant registration, purchase request, payment authorization, and payment capture. There are many minor protocols, for example to handle errors. SET is enormously more complicated than SSL, which merely negotiates session keys between the cardholder’s and merchant’s Internet service providers. Because of this complexity, much of which is unnecessary, the protocol is hardly used. However, SET contains many features of interest:
The model is unusual. In the registration protocols, the initiator possesses no digital proof of identity. Instead, he authenticates himself by filing a registration form whose format is not specified. Authentication takes place outside the protocol, when the cardholder’s bank examines the completed form.
The al signature is a novel construction. The partial sharing of information among three peers leads to unusual protocol goals.
SET uses several types of digital envelope. A digital envelope consists of two parts: one, encrypted using a public key, contains a fresh symmetric key K and identifying information; the other, encrypted using K, conveys the full message text. Digital envelopes keep public-key encryption to a minimum, but the many symmetric keys complicate the reasoning. Most verified protocols distribute just one or two secrets.

⑷ 支付宝使用哪些安全协议

支付宝采用SET协议保证安全性。
安全电子交易协议 (Secure Electronic Transaction,简称SET协议)，是基于信用卡在线支付的电于商务安全协议，它是由VISA和MasterCard两大信用卡公司于1997年5月联合推出的规范。SET主要是为了解决用户、商家和银行之间通过信用卡支付的交易而设计的，以保证支付命令的机密、支付过程的完整、商户及持卡人的合法身份，以及可操作性。SET通过制定标准和采用各种密码技术手段，解决了当时困扰电子商务发展的安全问题。
SET是在开放网络环境中的卡支付安全协议，它采用公钥密码体制(PKI)和X.509电子证书标准，通过相应软件、电子证书、数字签名和加密技术能在电子交易环节上提供更大的信任度、更完整的交易信息、更高的安全性和更少受欺诈的可能性。SET协议用以支持B-C这种类型的电子商务模式，即消费者持卡在网上购物与交易的模式。
SET协议的功能
SET协议是信用卡在因特网上进行支付的一种开放式安全协议和格式。解决持卡人、商家和银行之间通过信用卡来进行网上支付的交易，旨在保证支付命令的机密性、支付过程的完整性、商家以及持卡人身份的合法性以及可操作性。
SET协议采用的加密和认证技术
SET使用多种密钥技术来达到安全交易的要求，其中对称密钥技术、公钥加密技术和Hash算法是其核心。综合应用以上三种技术产生了数字签名、数字信封、数字证书等加密与认证技术。
SET标准的应用与局限性
SET 1.0版自1997年推出以来推广应用较慢，没有达到预期的效果。最大的挑战在于定期进行网上购物的消费者极少，原因主要是SET协议为了保证安全性而牺牲了简便性、操作过于复杂、成本较高、具有较大竞争力的SSL协议的广泛应用以及部分经济发达国家的法律规定了持卡人承担较低的信用卡风险等。SET协议提供了多层次安全保障，复杂程度显著增加；这些安全环节在一定程度上增加了交易的复杂性。
另外，SET协议目前只局限于银行卡的网上支付，对其他方式的支付没有给出很好的解决方案。SET协议只支持B2C模式的电子商务，而不支持目前最具有前途和影响力的B2B电子商务交易。
SET由于其高度的安全性和规范性，使其逐步发展成为目前安全电子支付的国际标准。由于SSL协议的成本低、速度快、使用简单，对现有网络系统不需进行大的修改，因而目前取得了广泛的应用。但随着电子商务规模的扩大，网络欺诈的风险性也在提高，在未来的电子商务中SET协议将会逐步占据主导地位。

⑸ 目前功能较强的安全电子交易协议是什么

(secure Electronic Transaction简称SET) 由威士(VISA)国际组织、万事达(MasterCard)国际组织创建，结合IBM、Microsoft、Netscope、GTE等公司制定的电子商务中安全电子交易的一个国际标准。其主要目的是解决信用卡电子付款的安全保障性问题，这包括：保证信息的机密性，保证信息安全传输，不能被窃听，只有收件人才能得到和解密信息；保证支付信息的完整性，保证传输数据完整接收，在中途不被篡改；认证商家和客户，验证公共网络上进行交易活动包括会计机构的设置、会计人员的配备及其职责权利的履行和会计法规、制度的制定与实施等内容。合理、有效地组织会计I作，意义重大，它有助于提高会计信息质量，执行国家财经纪律和有关规定；有助于提高经济效益，优化资源配置。会计工作的组织必须合法合规。讲求效益，必须建立完善的内部控制制度，必须有强有力的组织保证。

⑹ 安全电子交易协议的SET系统的组成

SET支付系统主要由持卡人（CardHolder）、商家（Merchant）、发卡行（Issuing Bank）、收单行（Acquiring Bank）、支付网关（Payment Gateway）、认证中心（Certificate Authority）等六个部分组成。对应地，基于SET协议的网上购物系统至少包括电子钱包软件、商家软件、支付网关软件和签发证书软件。

⑺ 安全电子支付的法律法规

第一条为规范和引导电子支付的健康发展，保障当事人的合法权益，防范支付风险，确保银行和客户资金的安全，制定本指引。
第二条电子支付是指单位、个人（以下简称客户）直接或授权他人通过电子终端发出支付指令，实现货币支付与资金转移的行为。
电子支付的类型按电子支付指令发起方式分为网上支付、电话支付、移动支付、销售点终端交易、自动柜员机交易和其他电子支付。
境内银行业金融机构（以下简称银行）开展电子支付业务，适用本指引。
第三条银行开展电子支付业务应当遵守国家有关法律、行政法规的规定，不得损害客户和社会公共利益。
银行与其他机构合作开展电子支付业务的，其合作机构的资质要求应符合有关法规制度的规定，银行要根据公平交易的原则，签订书面协议并建立相应的监督机制。 第四条客户办理电子支付业务应在银行开立银行结算账户（以下简称账户），账户的开立和使用应符合《人民币银行结算账户管理办法》、《境内外汇账户管理规定》等规定。 第五条电子支付指令与纸质支付凭证可以相互转换，二者具有同等效力。
第六条本指引下列用语的含义为：
（一）“发起行”，是指接受客户委托发出电子支付指令的银行。
（二）“接收行”，是指电子支付指令接收人的开户银行；接收人未在银行开立账户的，指电子支付指令确定的资金汇入银行。
（三）“电子终端”，是指客户可用以发起电子支付指令的计算机、电话、销售点终端、自动柜员机、移动通讯工具或其他电子设备。
第二章电子支付业务的申请
第七条银行应根据审慎性原则，确定办理电子支付业务客户的条件。
第八条办理电子支付业务的银行应公开披露以下信息：
（一）银行名称、营业地址及联系方式；
（二）客户办理电子支付业务的条件；
（三）所提供的电子支付业务品种、操作程序和收费标准等；
（四）电子支付交易品种可能存在的全部风险，包括该品种的操作风险、未采取的安全措施、无法采取安全措施的安全漏洞等；
（五）客户使用电子支付交易品种可能产生的风险；
（六）提醒客户妥善保管、使用或授权他人使用电子支付交易存取工具（如卡、密码、密钥、电子签名制作数据等）的警示性信息；
（七）争议及差错处理方式。
第九条银行应认真审核客户申请办理电子支付业务的基本资料，并以书面或电子方式与客户签订协议。
银行应按会计档案的管理要求妥善保存客户的申请资料，保存期限至该客户撤销电子支付业务后5年。
第十条银行为客户办理电子支付业务，应根据客户性质、电子支付类型、支付金额等，与客户约定适当的认证方式，如密码、密钥、数字证书、电子签名等。 认证方式的约定和使用应遵循《中华人民共和国电子签名法》等法律法规的规定。
第十一条银行要求客户提供有关资料信息时，应告知客户所提供信息的使用目的和范围、安全保护措施、以及客户未提供或未真实提供相关资料信息的后果。 第十二条客户可以在其已开立的银行结算账户中指定办理电子支付业务的账户。该账户也可用于办理其他支付结算业务。
客户未指定的银行结算账户不得办理电子支付业务。
第十三条客户与银行签订的电子支付协议应包括以下内容：
（一）客户指定办理电子支付业务的账户名称和账号；
（二）客户应保证办理电子支付业务账户的支付能力；
（三）双方约定的电子支付类型、交易规则、认证方式等；
（四）银行对客户提供的申请资料和其他信息的保密义务；
（五）银行根据客户要求提供交易记录的时间和方式；
（六）争议、差错处理和损害赔偿责任。
第十四条有以下情形之一的，客户应及时向银行提出电子或书面申请：
（一）终止电子支付协议的；
（二）客户基本资料发生变更的；
（三）约定的认证方式需要变更的；
（四）有关电子支付业务资料、存取工具被盗或遗失的；
（五）客户与银行约定的其他情形。
第十五条客户利用电子支付方式从事违反国家法律法规活动的，银行应按照有权部门的要求停止为其办理电子支付业务。
第三章电子支付指令的发起和接收
第十六条客户应按照其与发起行的协议规定，发起电子支付指令。
第十七条电子支付指令的发起行应建立必要的安全程序，对客户身份和电子支付指令进行确认，并形成日志文件等记录，保存至交易后5年。
第十八条发起行应采取有效措施，在客户发出电子支付指令前，提示客户对指令的准确性和完整性进行确认。
第十九条发起行应确保正确执行客户的电子支付指令，对电子支付指令进行确认后，应能够向客户提供纸质或电子交易回单。
发起行执行通过安全程序的电子支付指令后，客户不得要求变更或撤销电子支付指令。
第二十条发起行、接收行应确保电子支付指令传递的可跟踪稽核和不可篡改。
第二十一条发起行、接收行之间应按照协议规定及时发送、接收和执行电子支付指令，并回复确认。
第二十二条电子支付指令需转换为纸质支付凭证的，其纸质支付凭证必须记载以下事项(具体格式由银行确定)：
（一）付款人开户行名称和签章；
（二）付款人名称、账号；
（三）接收行名称；
（四）收款人名称、账号；
（五）大写金额和小写金额；
（六）发起日期和交易序列号。
第四章安全控制
第二十三条银行开展电子支付业务采用的信息安全标准、技术标准、业务标准等应当符合有关规定。
第二十四条银行应针对与电子支付业务活动相关的风险，建立有效的管理制度。
第二十五条银行应根据审慎性原则并针对不同客户，在电子支付类型、单笔支付金额和每日累计支付金额等方面做出合理限制。
银行通过互联网为个人客户办理电子支付业务，除采用数字证书、电子签名等安全认证方式外，单笔金额不应超过1000元人民币，每日累计金额不应超过5000元人民币。 银行为客户办理电子支付业务，单位客户从其银行结算账户支付给个人银行结算账户的款项，其单笔金额不得超过5万元人民币，但银行与客户通过协议约定，能够事先提供有效付款依据的除外。 银行应在客户的信用卡授信额度内，设定用于网上支付交易的额度供客户选择，但该额度不得超过信用卡的预借现金额度。
第二十六条银行应确保电子支付业务处理系统的安全性，保证重要交易数据的不可抵赖性、数据存储的完整性、客户身份的真实性，并妥善管理在电子支付业务处理系统中使用的密码、密钥等认证数据。 第二十七条银行使用客户资料、交易记录等，不得超出法律法规许可和客户授权的范围。
银行应依法对客户的资料信息、交易记录等保密。除国家法律、行政法规另有规定外，银行应当拒绝除客户本人以外的任何单位或个人的查询。
第二十八条银行应与客户约定，及时或定期向客户提供交易记录、资金余额和账户状态等信息。
第二十九条银行应采取必要措施保护电子支付交易数据的完整性和可靠性：
（一）制定相应的风险控制策略，防止电子支付业务处理系统发生有意或无意的危害数据完整性和可靠性的变化，并具备有效的业务容量、业务连续性计划和应急计划; （二）保证电子支付交易与数据记录程序的设计发生擅自变更时能被有效侦测；
（三）有效防止电子支付交易数据在传送、处理、存储、使用和修改过程中被篡改，任何对电子支付交易数据的篡改能通过交易处理、监测和数据记录功能被侦测； （四）按照会计档案管理的要求，对电子支付交易数据，以纸介质或磁性介质的方式进行妥善保存，保存期限为5年，并方便调阅。
第三十条银行应采取必要措施为电子支付交易数据保密：
（一）对电子支付交易数据的访问须经合理授权和确认；
（二）电子支付交易数据须以安全方式保存，并防止其在公共、私人或内部网络上传输时被擅自查看或非法截取；
（三）第三方获取电子支付交易数据必须符合有关法律法规的规定以及银行关于数据使用和保护的标准与控制制度；
（四）对电子支付交易数据的访问均须登记，并确保该登记不被篡改。
第三十一条银行应确保对电子支付业务处理系统的操作人员、管理人员以及系统服务商有合理的授权控制：
（一）确保进入电子支付业务账户或敏感系统所需的认证数据免遭篡改和破坏。对此类篡改都应是可侦测的，而且审计监督应能恰当地反映出这些篡改的企图。 （二）对认证数据进行的任何查询、添加、删除或更改都应得到必要授权，并具有不可篡改的日志记录。
第三十二条银行应采取有效措施保证电子支付业务处理系统中的职责分离：
（一）对电子支付业务处理系统进行测试，确保职责分离；
（二）开发和管理经营电子支付业务处理系统的人员维持分离状态；
（三）交易程序和内控制度的设计确保任何单个的雇员和外部服务供应商都无法独立完成一项交易。
第三十三条银行可以根据有关规定将其部分电子支付业务外包给合法的专业化服务机构，但银行对客户的义务及相应责任不因外包关系的确立而转移。
银行应与开展电子支付业务相关的专业化服务机构签订协议，并确立一套综合性、持续性的程序，以管理其外包关系。
第三十四条银行采用数字证书或电子签名方式进行客户身份认证和交易授权的，提倡由合法的第三方认证机构提供认证服务。如客户因依据该认证服务进行交易遭受损失，认证服务机构不能证明自己无过错，应依法承担相应责任。 第三十五条境内发生的人民币电子支付交易信息处理及资金清算应在境内完成。
第三十六条银行的电子支付业务处理系统应保证对电子支付交易信息进行完整的记录和按有关法律法规进行披露。
第三十七条银行应建立电子支付业务运作重大事项报告制度，及时向监管部门报告电子支付业务经营过程中发生的危及安全的事项。
第五章差错处理
第三十八条电子支付业务的差错处理应遵守据实、准确和及时的原则。
第三十九条银行应指定相应部门和业务人员负责电子支付业务的差错处理工作，并明确权限和职责。
第四十条银行应妥善保管电子支付业务的交易记录，对电子支付业务的差错应详细备案登记，记录内容应包括差错时间、差错内容与处理部门及人员姓名、客户资料、差错影响或损失、差错原因、处理结果等。 第四十一条由于银行保管、使用不当，导致客户资料信息被泄露或篡改的，银行应采取有效措施防止因此造成客户损失，并及时通知和协助客户补救。
第四十二条因银行自身系统、内控制度或为其提供服务的第三方服务机构的原因，造成电子支付指令无法按约定时间传递、传递不完整或被篡改，并造成客户损失的，银行应按约定予以赔偿。 因第三方服务机构的原因造成客户损失的，银行应予赔偿，再根据与第三方服务机构的协议进行追偿。
第四十三条接收行由于自身系统或内控制度等原因对电子支付指令未执行、未适当执行或迟延执行致使客户款项未准确入账的，应及时纠正。
第四十四条客户应妥善保管、使用电子支付交易存取工具。有关电子支付业务资料、存取工具被盗或遗失，应按约定方式和程序及时通知银行。
第四十五条非资金所有人盗取他人存取工具发出电子支付指令，并且其身份认证和交易授权通过发起行的安全程序的，发起行应积极配合客户查找原因，尽量减少客户损失。 第四十六条客户发现自身未按规定操作，或由于自身其他原因造成电子支付指令未执行、未适当执行、延迟执行的，应在协议约定的时间内，按照约定程序和方式通知银行。银行应积极调查并告知客户调查结果。 银行发现因客户原因造成电子支付指令未执行、未适当执行、延迟执行的，应主动通知客户改正或配合客户采取补救措施。
第四十七条因不可抗力造成电子支付指令未执行、未适当执行、延迟执行的，银行应当采取积极措施防止损失扩大。
第六章附则
第四十八条本指引由中国人民银行负责解释和修改。
第四十九条本指引自发布之日起施行。希望能帮助到楼主