一种电子保函开具方法、云服务器及电子保函系统

摘要

本申请公开一种电子保函开具方法、云服务器及电子保函系统，该方法包括：根据订单数据和选择项目请求推送项目列表；接收选择的项目并基于其属性对金融机构初筛获得初审金融机构列表；基于选择项目的标的额与交易中心系统交互获取金融机构的担保余责和担保上限；对初审金融机构列表进行二次筛选；在金融机构的担保余责超过担保上限且存在联合担保时，或在金融机构担保余责未超过担保上限时，保留金融机构；基于保留的金融机构生成终审金融机构列表并反馈；接收选择的金融机构，生成保函订单发送给选定金融机构系统。为企业提供了更多的具备出函资格的金融机构以供选择，为担保公司扩大市场业务，扩大金融产业链，保险公司获得连带业务。

说明书

技术领域

本发明涉及区块链技术领域，具体是一种电子保函开具方法、链服务装置及系统。

背景技术

在公共资源交易招投标等业务中，企业作为投标人需要在投标截止前递交保证金或电子保函，企业作为交易主体用户可以从公共资源平台上选择其预投资的项目，并申请电子保函提交保函订单，电子保函系统接收该订单后根据其选择的项目向具有担保资格的金融机构（包括担保公司）下发订单。

目前电子保函系统对于担保公司作为承保机构为企业开具电子保函的的审核要求：首先担保公司具有开具电子保函的资质；其次担保公司具有一定的赔付能力；最后担保公司当前在保保函的累积保额(担保余责)未超过自身赔付能力上限。

按照现有规则，具有资质的担保公司，如果其在保保函的累积保额(担保余责)已达到自身赔付能力上限，或出现一笔保额非常大的项目保函订单导致超过赔付能力上限，则系统不允许担保公司接单。由此引发以下问题：企业无法选择该担保公司进行出函，且担保公司因为风控流失业务订单，减少企业的选择，如果多家担保公司存在上述状况，将会不利于电子保函业务的正常流转，进而影响市场交易秩序。

发明内容

本申请提供一种电子保函开具方法、云服务器及电子保函系统，用于克服现有技术中对担保余责风控审核单一阻碍电子保函市场交易的缺陷。

为实现上述目的，第一方面，本申请提供一种电子保函开具方法，包括：

根据接收的订单数据和选择项目请求推送项目列表；

接收在项目列表中选择的项目并基于选定项目属性对金融机构进行初步筛选获得初审金融机构列表；

基于选择项目的标的额与交易中心系统交互获取初审金融机构列表中金融机构的担保余责和担保上限；对所述初审金融机构列表进行二次筛选；

在金融机构的担保余责超过担保上限且存在联合担保时，或在金融机构的担保余责未超过所述担保上限时，保留所述金融机构；

基于保留的金融机构生成终审金融机构列表并反馈；

接收在终审金融机构列表中选择的金融机构，生成保函订单发送给选定金融机构系统。

通过采用上述的技术方案，如果其在保保函的累积保额(担保余责)已达到自身赔付能力上限，或出现一笔保额非常大的项目保函订单导致超过赔付能力上限时，允许担保公司以再保险的模式与保险公司合作，使得作为担保公司的金融机构可通过与保险公司以联合担保的模式以提升其自身的担保上限，进而获得担保公司接单允许，企业可以选择该担保公司继续出函，降低担保公司因为风控而流失的业务订单量，促进投标企业与担保公司之间的业务往来，刺激市场交易。需要担保公司与合作保险公司均经中电子保函系统认证后才可以开展再保险业务，有认证权威性。再保险模式要求同一担保机构仅可与一家保险公司进行再保险业务签约，具有签约独占性。担保余责/担保余额管理采用特殊规则计算，区块链存证加以程序逻辑实时监控，是行业内的首次应用。

优选的，所述项目属性包括：项目所属区域、项目类型和项目标的额；

获取选定项目属性的步骤包括：

基于选定项目从本地数据提取所述选定项目属性；或

基于选定项目与区块链节点交互获得选定项目的项目所属区域、项目类型和项目标的额。

通过采用上述的技术方案，在投标企业通过交易中心系统注册的用户接收服务器侧发送的项目列表后从中选择，通过底层就选定项目与服务器交互，在一实施例中服务器基于交互获得的选定项目并从本地数据库提取该选定项目的属性，在另一实施例中服务器基于交互获得的选定项目再次与区块链节点交互，接收区块链节点的反馈获得选定项目的属性，包括选定项目的所属区域、项目类型及项目标的额等，服务器可基于选定项目的所属区域进行初步审查，将所属区域内的有担保资质的金融机构筛选出来形成初审金融机构列表，而这些金融机构均是通过严格筛选后符合担保资质要求的，项目类型包括基础设施、建筑物、水利水电等，不同类型的项目担保标的额的担保比例不同，以方便服务器为基于用户选择的项目的类型配置担保比例。例如有些项目的担保比例为标的额的30%，50%，80%或100%，而有些项目的担保比例为标的额的50%，80%或100%。

优选的，所述接收在项目列表中选择的项目并基于选定项目属性对金融机构进行初步筛选获得初审金融机构列表的步骤包括：

基于所述项目所属区域调用区域与金融机构的第一映射关系表；

所述第一映射关系表中每个区域与若干具有担保资格的金融机构之间具有映射关系；

在第一映射关系表中查找与项目所属区域具有映射关系的金融机构，获得当前区域具备担保资格的金融机构列表；

基于所述项目类型调用类型与金融机构的第二映射关系表；

所述第二映射关系表中每个项目类型与若干具有担保资格的金融机构之间具有映射关系；

在第二映射关系表中查找与项目类型具有映射关系的金融机构，获得与项目类型匹配的金融机构列表；

基于当前区域具备担保资格的金融机构列表和与项目类型匹配的金融机构列表中共同的金融机构，形成初审金融机构列表。

通过采用上述的技术方案，上述两种类型的映射关系表均预存在服务器中，当接收到用户的金融机构选择请求时，调取该请求所选择的项目，基于项目信息确定其所属区域，然后再基于所属区域遍历第一映射关系表中的区域索引，找到一致的区域后再基于映射关系获得该区域的所有具备担保资格的金融机构形成第一粗筛列表；同样，当接收到用户的金融机构选择请求时，调取该请求所选择的项目，基于项目信息确定其类型，然后再基于项目类型遍历第二映射关系表中的项目类型索引，找到一致的项目类型后再基于映射关系获得该项目类型的所对应的金融机构形成第二粗筛列表；取第一粗筛列表与第二粗筛列表中重复的金融机构形成初审金融机构列表；反馈给交易中心系统，以供投标企业用户选择。

优选的，所述基于选择项目的标的额与交易中心系统交互获取初审金融机构列表中金融机构的担保余责和担保上限的步骤包括；

从本地数据库获取所述初审金融机构列表中任一金融机构的担保上限；

与交易中心系统交互获取所述选定金融机构的累积担保额；

基于选定项目的标的额配置保证金金额；

根据所述金融机构的累积担保额与保证金金额之和获得所述金融机构的担保余责；

遍历所述初审金融机构列表中所有金融机构，获得所有金融机构的担保余责和担保上限；

所述基于选定项目的标的额配置保证金金额的步骤包括：

预存有项目类型与担保比例的映射关系表；所述映射关系表中每个项目属性与若干担保比例之间具有映射关系；

基于所述项目类型以及映射关系获得所述项目的若干担保比例并反馈；

基于选定项目的标的额和接收的担保比例获得保证金金额；

判断金融机构的担保余责是否超过担保上限的步骤包括：

比较金融机构的担保余责和担保上限；

在所述担保余责小于或等于担保上限时，确认所述金融机构的担保余责没有超过担保上限；

在所述担保余责大于所述金融机构的担保上限时，确认所述金融机构的担保余责超过了担保上限。

通过采用上述的技术方案，金融机构的担保上限可存储在本地数据库，在获取初审金融机构后可从数据库中调取任一金融机构的担保上限，投标企业在选择金融机构时能够从本地或区块链节点获得所选项目的标的额，并且在选择该项目后向下一流程节点发送该项目标的额，因此该项目标的额在向服务器发送金融机构选择请求时可以携带所选项目标的额信息，基于企业用户选择的担保比例将两者相乘能获得保证金金额，基于企业用户选择的某一金融机构与交易中心系统交互获取该金融机构的累积保证金金额及其担保上限；并判断其能否具备担保能力。

优选的，所述生成终审金融机构列表的步骤包括：

在金融机构的担保余责未超过所述担保上限时，在所述初审金融机构列表中保留所述金融机构；

在金融机构的担保余责超过担保上限时，查询所述金融机构是否存在联合担保；

在所述金融机构存在联合担保时，切换为联合担保模式；

在所述金融机构不存在联合担保时，在初审金融列表中删除所述金融机构；

所述切换联合担保的步骤包括：

提取联合担保的担保额；

在所述联合担保的担保额大于或等于选定项目的保证金金额时，允许联合担保，并在所述初审金融机构列表中保留所述金融机构；；

在所述联合担保的担保额小于所选项目的保证金金额时，不允许联合担保并在所述初审金融机构列表中删除所述金融机构。

通过采用上述的技术方案，在初审金融机构列表中的金融机构的担保余责未超过担保上限时，允许该金融机构独立承保；在初审金融机构列表中金融机构的担保余责超过担保上限不能独立承保时才需要判断是否存在联合担保，若存在联合担保则切换至联合担保模式判断是否具备承保能力，若具备则保留在列表中；若不存在联合担保时则直接从列表中删除不许该金融机构承保，通过上述判断并对初审金融机构列表重新调整后形成终审金融机构列表；推送给用户的终审金融机构列表中每一个金融机构均允许承保，用户可以在其中任意选择，而不会产生选择的金融机构不能承保的可能，提高了保单生成的效率。

优选的，上述方法中所述接收在终审金融机构列表中选择的金融机构，生成保函订单发送给选定金融机构系统的步骤包括：

在接收到的选定金融机构的担保余责未超过担保上限时，允许独立承保并生成独立保函订单给所述金融机构系统；

在接收到的选定金融机构的担保余责超过担保上限且存在联合担保时时，允许联合担保并生成联合保函订单给所述金融机构系统。

通过采用上述的技术方案，基于金融机构与合作的保险公司签订的合同，提取保险公司的保证金金额即联合担保的保证金金额，基于两者的关系生成保函订单给交易中心系统；若某一金融机构的担保余责超过担保上限且不存在联合担保则直接在初审金融机构列表中删除，不会在终审金融机构列表中出现，也不会被用户选到；所有从终审金融机构列表中选定的金融机构必然允许承保，从而保证一旦被选中就能生产保函订单。上述联合担保的保证金金额基于金融机构与合作保险公司的业务合同确定，并且再保险模式下要求同一担保机构仅可与一家保险公司进行再保险业务签约，具有签约独占性，有利于减少纠纷，确保招标人的利益；担保余责担保余额管理采用特殊规则计算，区块链存证加以程序逻辑实时监控，程序安全可控，具有可操作性。

优选的，上述方法中在生成保函订单之前还包括：

获取企业信息并反馈给交易中心系统核实；

接收交易中心系统基于所述企业信息与存储信息比较结果的反馈，发送项目信息校验请求；

接收交易中心系统基于项目信息校验请求并反馈的项目信息校验结果；

在校验结果成功时生成保函订单并发送给选定金融机构系统；

在校验结果失败时结束流程。

通过采用上述的技术方案，在生成保函订单之前的流程为订单预提交，获取企业用户的企业信息并向交易中心系统发送进行核实，为提高项目保密性该预提交订单通过调用区块链节点存证的项目信息加密后一起发送给交易中心以校验其身份是否合法，在校验正确时再向选定的金融机构系统发送保函订单，以提高交易的安全性。

优选的，上述方法中在将保函订单发送给选定金融机构系统后还包括：

基于选定金融机构反馈的通过信息发送支付链接；

在接收到选定金融机构基于支付成功而反馈的出函信息时，推送出函成功的信息并结束流程。

通过采用上述的技术方案，金融机构接收保函订单后，通过内部风控审核后反馈通过信息，并将支付链接推送给企业用户，企业用户接收支付链接并支付成功后，金融机构系统出函经服务器推送给交易中心系统出函成功的信息并结束流程。

为实现上述目的，第二方面，本申请还提供一种云服务器，包括处理器和存储器，所述存储器存储有电子保函开具程序；所述处理器在运行所述电子保函开具程序时执行上述方法的步骤；处理器一端用于与申报项目的交易中心系统通讯连接，另一端用于与与金融机构系统通讯连接。

通过采用上述的技术方案，将上述电子保函开具方法以计算机可读代码的形式呈现并存储于存储器内，在安装上述计算机程序后，处理器在系统内运行存储器内的计算机可读代码时，执行上述方法的步骤获得促进市场交易的技术效果。

为实现上述目的，第三方面，本申请还提供一种电子保函系统，包括云服务器、交易中心系统及若干金融机构系统；云服务器为上述的云服务器；交易中心系统与所述云服务器的处理器通讯连接；若干金融机构系统均与所述云服务器的处理器通讯连接。

通过采用上述的技术方案，为再保险模式在电子保函产业链的安全可靠运行提供了硬件环境。

本申请提供的传输方法、采集卡及数据传输系统具有如下综合技术效果：

优化营商环境，为企业提供了更多的具备出函资格的金融机构以供选择。

优化市场环境，为担保公司提供扩大市场业务的方式。

扩大金融产业链，保险公司获得连带业务。安全可靠，保证保函真实无篡改，避免了金融机构为了业务铤而走险采用不合规的方式拓展市场。

保函再保险的新模式，在保障招标人(受益人)权益的原则下，企业可以有更多选择，担保公司可以获取更多业务订单，连带保险公司增加收益，多方共赢。

系统中有严格的规则配置，并增加实时统计功能监控担保公司担保余额额度，做到实时监控，精准切换，无缝链接，对记录进行加密存储，区块链存证，确保准确无篡改，责任清晰。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单的介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图示出的结构获得其他的附图。

图1为本申请实施例电子保函开具方法的硬件运行环境框架图；

图2为本申请一实施例电子保函开具方法的流程图；

图3为本申请另一实施例电子保函开具方法中对金融机构进行筛选的流程图；

图4为本申请又一实施例中电子保函开具方法中金融机构列表形成的流程图；

图5为图4中金融机构列表的多级筛选流程图；

图6为本申请又一实施例电子保函开具方法的层构建示意图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

需要说明，本发明实施例中所有方向性指示（诸如上、下、左、右、前、后……）仅用于解释在某一特定姿态（如附图所示）下各部件之间的相对位置关系、运动情况等，如果该特定姿态发生改变时，则该方向性指示也相应地随之改变。

另外，在本发明中如涉及“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本发明的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。

在本发明中，除非另有明确的规定和限定，术语“连接”、“固定”等应做广义理解，例如，“固定”可以是固定连接，也可以是可拆卸连接，或成一体；可以是机械连接，也可以是电连接，还可以是物理连接或无线通信连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通或两个元件的相互作用关系，除非另有明确的限定。对于本领域的普通技术人员而言，可以根据具体情况理解上述术语在本发明中的具体含义。

另外，本发明各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本发明要求的保护范围之内。

实施例一

如图1所示，提供一种交易网络系统1000，包括多个交易节点100，每个交易节点100包括：区块链节点110、云服务器120及交易中心系统130，多个区块链节点110构成联盟区块链200。

联盟区块链200的构建可以是基于例如Hyperledger Fabric区块链网络。该网络串联各个交易中心系统130，并将每一个交易中心系统130单独设置成一个组织。每一个交易中心系统130可以配置一个Peer节点和和一套链服务装置。为了保证组织内部的服务冗余和高可靠性，也可以配置两个以上的Peer节点和配套的链服务装置。所有组织的Peer节点都处于同一个通道。通道指的是实现区块链节点之间数据存储和利用的私有空间。

在交易网络系统1000应用的过程中，通常涉及的应用主体除了交易中心系统130外，包括若干金融机构系统300和云服务器120。其中，投标企业可以通过共享应用工具即公共资源在云服务器120前台和交易中心系统130分别注册用户。联盟区块链200存储招标项目信息、加密的电子保函。交易中心系统130通过云服务器120访问区块链节点110，上传招标项目信息并自动同步至链上全部节点。云服务器120包括前台和后台，前台供不特定的终端通过互联网登陆并选择项目、选择金融机构及提交电子保函申请；后台通过与区块链节点、交易中心系统以及若干金融机构系统交互。

投标企业可以分别在云服务器120的前台及交易中心系统130注册用户，通过云服务器120与金融机构系统300通信，实现电子保函申请资料的提交。

实施例二

在实施例一的基础上，参见图2、图3，下面结合交易网络系统对电子保函开具方法进行详细说明，基于云服务器120侧提供的方法包括：

S100，根据接收的订单数据和选择项目请求推送项目列表；

企业用户首先需要在交易中心系统130填写企业信息并注册用户，登陆用户后通过交易中心系统130生成申请电子保函的订单数据，与云服务120交互并向云服务器120的后台发送。该订单数据中包含企业设置的密令、企业名称、信用代码等信息。

企业用户通过云服务器120前台向后台发送选择项目请求，云服务器120的后台接收上述订单数据以及选择项目请求后向前台反馈项目列表，在本申请一实施例中，云服务器120通过访问区块链节点110，实现招标项目信息下载并向前台的用户推送。例如，用户可以通过扫描交易节点100提供的二维码从区块链节点110获取招标项目信息，选择其中一项招标项目后，向后台传递。S200，接收在项目列表中选择的项目并基于选定项目属性对金融机构进行初步筛选获得初审金融机构列表；

后台接收用户基于前台选择的项目（即选定项目）后，获取该选定项目的项目属性信息，在本申请一实施例中，项目属性信息存储于本地数据库中，后台可直接调用，简洁高效；在本申请另一实施例中，项目属性信息存储与区块链节点中，后台与区块链节点交互获得，该方式安全性较高；其中项目属性信息可以包括项目所属区域、项目类型和项目标的额等重要信息；后台基于这些信息部分或全部能够对适用的金融机构进行初步筛选，获得初审金融机构列表。

需要说明的是，后台本体数据库预先存储有若干金融机构的信息，例如可基于选择的项目查询该项目的所属区域具备担保资格的金融机构；

在本申请一实施例中，云服务器120基于用户选择的项目，例如海口某项目能够基于项目名称信息提取到该项目所属的行政区域海口，然后将海口所有具备担保资质的金融机构筛选出来。

在本申请另一实施例中，基于企业用户选择的项目以统一的数据结构存储在区块链节点110，云服务器120基于选择的项目代号，与从区块链节点110交互获得该项目的所属区域、项目属性和项目标的额等信息。

在本申请的又一实施例中，基于选择的项目的所属区域、项目属性和项目标的额等信息均以加密的形式附加在该选择项目请求中，云服务器120后台解密后可直接获得。

参见图4、图5，S200具体包括：

S201，基于所述项目所属区域调用区域与金融机构的第一映射关系表；

云服务器后台或系统本地数据库预存有区域与金融机构的第一映射关系表，所述第一映射关系表中每个区域与若干具有担保资格的金融机构之间具有映射关系；

区块链节点110、云服务器120或交易中心系统130中预存有项目所属行政区域与金融机构的映射关系表，行政区域和/或具体的金融机构均可采用编号或代号等形式存储在目录索引中，以提升遍历比对的速度。

S202，所述第一映射关系表中每个区域与若干具有担保资格的金融机构之间具有映射关系；

基于所述项目所属区域以及映射关系表获得当前区域具备担保资格的若干金融机构；

例如：海口的编号为30，对应位于海口的具有担保资格的金融机构包括若干，代号分别为301、302、303……。云服务器120基于编号30在映射关系表索引目录中遍历区域编号，能够查询到金融机构301、302、303……。

S203，在第一映射关系表中查找与项目所属区域具有映射关系的金融机构，获得当前区域具备担保资格的金融机构列表；

将若干金融机构反馈给基于互联网获取投标企业以供选择；

云服务器120将金融机构301、302、303……筛选出来形成当前区域具备担保资格的金融机构列表。

S204，基于所述项目类型调用类型与金融机构的第二映射关系表；

S205，所述第二映射关系表中每个项目类型与若干具有担保资格的金融机构之间具有映射关系；

S206，在第二映射关系表中查找与项目类型具有映射关系的金融机构，获得与项目类型匹配的金融机构列表；

这里的项目类型可以按照项目是基础设施（包括路、桥、轨道等交通设施，也包括通信基站等信息网络设施，还包括电网等电力输送设施等等）、建筑（包括居民住宅、工业建筑、公共建筑等）、绿化（包括公园、人工湖等）等；每一类型的项目匹配了不同的金融机构，例如：大型建筑只允许银行等金融机构作为担保机构，而不允许一般的金融机构担保，而一些小型的项目则匹配普通的金融机构；这种分类有利于构建良性的交易秩序并促进金融机构的高效运作。

需要说明的是，上述步骤S201-203作为一个整体，步骤S204-206作为一个整体，两个整体的顺序可以调换，例如向执行S204-206，再执行S201-203；整体不影响初审金融机构列表的形成。

S207，基于当前区域具备担保资格的金融机构列表和与项目类型匹配的金融机构列表中共同的金融机构，形成初审金融机构列表。

将S203获得的列表和步骤S206获得的列表取交集（共同的金融机构）形成初审金融机构列表。

S300，基于选择项目的标的额与交易中心系统交互获取初审金融机构列表中金融机构的担保余责和担保上限；对所述初审金融机构列表进行二次筛选；

选择项目的标的额可以从项目属性信息中获得，金融机构的担保余责和担保上限可以从本地数据库获得，也可以直接或间接存储在交易中心系统130中或存储在区块链节点110中，直接存储时，可通过与存储的设备交互直接获取；间接存储时需要对交互获得的数据进行二次加工和计算。

S300具体包括：

S301，从本地数据库获取所述初审金融机构列表中任一金融机构的担保上限；

S302，与交易中心系统交互获取所述金融机构的累积担保额；

交易中心系统记录有初审金融机构列表中每个金融机构的单次担保数据，将一金融机构的所有单次担保数据中的金额累计后获得累计担保额；

S303，基于选定项目的标的额配置保证金金额；

这里的配置可以是后台直接配置，也可以是基于用户通过前台的选择进行配置，保证金金额与担保比例有关，若担保比例不可选择时则采用前者；若担保可以选择时则采用后者。

基于选择的项目配置保证金金额并反馈给该前台；

由于招投标项目性质的不同，需要投标企业提供不同额度的担保，为了方便用户通过云服务器120能够快速匹配到金融机构出具保函，基于获取的项目属性配置符合规定的担保比例，需要说明的是，之所以反馈给前台，是在一些项目中担保比例唯一，而在另一些项目中担保比例不是唯一的，有多个梯度供客户端选择。这里的担保比例指的是项目标的额的担保比例，基于担保法的规定可以是30%、50%、80%或100%等多个担保梯度；投标企业可以基于自身的资产实力选择。

S304，根据所述金融机构的累积担保额与保证金金额之和获得所述金融机构的担保余责；

S305，遍历所述初审金融机构列表中所有金融机构，获得所有金融机构的担保余责和担保上限；

基于用户选择的金融机构和保证金金额确认所述金融机构的担保余责是否超过担保上限；云服务器120可基于交易中心系统130交互获得该金融机构的担保余责和备案的担保上限，并基于两者之间的差值计算是否满足本次保证金金额。为了防止金融机构的交易记录或担保余额被篡改，可将所述记录存储在区块链节点200以存证或进行加密存储。

所述S303基于选定项目的标的额配置保证金金额的步骤具体包括：

S31，预存有项目类型与担保比例的映射关系表；所述映射关系表中每个项目类型与若干担保比例之间具有映射关系；

后台本地预存有项目类型与担保比例的映射关系表；所述映射关系表中每个项目属性与若干担保比例之间具有映射关系；

例如项目类型为A级，标的额担保比例对应为50%以上，项目属性为B级，标的额担保比例对应为70%以上。

S32，基于所述项目类型以及映射关系获得所述项目的若干担保比例并反馈；

在选择的项目属性为A级时， 云服务器120在映射关系表目录索引中遍历项目属性并查找对应项A，能获得与A对应的担保比例，例如50%以上的整数百分比，可以按照每10个百分点设置一个梯度，则对应50%、60%、70%、80%、90%、100%，也可按照每5个百分点设置一个梯度，则对应50%、55%、60%、65%、70%、75%、80%、85%、90%、95%、100%。

S33，基于选定项目的标的额和接收的担保比例获得保证金金额；

在选择的项目类型为A级时，云服务器120将50%以上的整数百分比反馈给前台，按照每10个百分点设置一个梯度，则反馈50%、60%、70%、80%、90%、100%，按照每5个百分点设置一个梯度，则反馈50%、55%、60%、65%、70%、75%、80%、85%、90%、95%、100%。

S400，在金融机构的担保余责超过担保上限且存在联合担保时，或在金融机构的担保余责未超过所述担保上限时，保留所述金融机构；

判断金融机构的担保余责是否超过担保上限的步骤A包括：

S401，比较金融机构的担保余责和担保上限；

S402，在所述担保余责小于或等于担保上限时，确认所述金融机构的担保余责没有超过担保上限；

S403，在所述担保余责大于所述金融机构的担保上限时，确认所述金融机构的担保余责超过了担保上限。

在某一金融机构的累积担保额与本次所选项目的保证金金额之和（即担保余责）小于或等于该金融机构的担保上限时，系统确认该金融机构可以独立承保，通过上述筛选程序能够将初审金融机构列表中所有具备单独承保资格的金融机构筛选出来并保留。

判断在金融机构的担保余责超过担保上限且存在联合担保的步骤B包括：

S404，在金融机构的担保余责超过担保上限时，查询所述金融机构是否存在联合担保；

S405，在所述金融机构存在联合担保时，切换为联合担保模式；

S406，在所述金融机构不存在联合担保时，在初审金融列表中删除所述金融机构；

所述切换联合担保的步骤S405包括：

S41，提取联合担保的担保额；

S42，在所述联合担保的担保额大于或等于选定项目的保证金金额时，允许联合担保，并在所述初审金融机构列表中保留所述金融机构；

S43，在所述联合担保的担保额小于所选项目的保证金金额时，不允许联合担保并在所述初审金融机构列表中删除所述金融机构。

步骤A和步骤B整体获得的两部分之和形成最终的终审金融机构列表。

S500，基于保留的金融机构生成终审金融机构列表并反馈；

后台将终审金融机构列表向前台反馈，以供企业用户选择，在用户选择一金融机构后，并在前台录入联系人信息，并提取企业信息与交易中心系统130交互对企业信息进行核实，这里核实的为云服务器侧订单数据中的企业信息与企业用户在交易中心系统注册时提交的信息是否一致，具体参见步骤S61-63，防止非企业用户通过云服务器提交虚假保函。

S600，接收在终审金融机构列表中选择的金融机构，生成保函订单发送给选定金融机构系统。

在所述金融机构的担保余责超过担保上限，且存在联合担保时，切换联合担保并基于允许联合担保的信息生成保函订单发送给交易中心系统。

金融机构与合作的保险公司签订合同时，该保险公司和金融机构均需要经过审核和认证后方可开展再保险业务，且保险合同需要审核备案；通过云服务器120的认证可提高服务的安全性。此外，再保险模式要求同一担保机构仅可与一家保险公司进行再保险业务签约，具有签约独占性，以保证受益人利益。

S600包括以下步骤：

S61，在接收到的选定金融机构的担保余责未超过担保上限时，允许独立承保并生成独立保函订单给所述金融机构系统；

S62，在接收到的选定金融机构的担保余责超过担保上限且存在联合担保时时，允许联合担保并生成联合保函订单给所述金融机构系统。

判断是否允许担保的步骤包括：

S601，提取联合担保的保证金金额；

基于所选的金融机构与保险公司签订的保险合同，提取联合担保的保证金金额。

S602，在所述联合担保的保证金金额之和大于或等于所选项目的保证金金额时，允许联合担保并生成联合保函订单发送给交易中心系统。

为提高保函的安全性，需要通过加密和解密以确认身份，在生成保函订单之前还包括：

S061获取企业信息并反馈给交易中心系统核实；

S062接收交易中心系统基于所述企业信息与存储信息比较结果的反馈，发送项目信息校验请求；

S063接收交易中心系统基于项目信息校验请求并反馈的项目信息校验结果；

S064在校验结果成功时生成保函订单并发送给选定金融机构系统；

S065在校验结果失败时结束流程。

在将保函订单发送给交易中心系统后还包括：

S610，基于选定金融机构反馈的通过信息发送支付链接；

金融机构在接收到订单后内部进行风控审核，若评估没有风险，则向云服务器后台反馈通过的信息，并发送支付链接，云服务器后台将该支付链接推送至前台供用户支付，在用户支付成功后，金融机构箱云服务器后台发送出函成功的信息；反之，若金融机构内部没有通过风险审核，则向云服务器后台反馈出函失败的信息。

S620，在接收到选定金融机构基于支付成功而反馈的出函信息时，推送出函成功的信息并结束流程。

云服务器后台接收到出函成功的信息时向交易中心系统发送，交易中心系统结束流程；云服务器后台接收到出函失败的信息时，向交易中心系统发送，交易中心系统结束流程。

参见图6，区块链系统的分层设计中，用户层布置在云服务器前台，服务层及跨层功能布置在云服务器后台，核心层布置在交易中心系统，基础层布置在区块链节点。

以上所述仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是在本发明的构思下，利用本发明说明书及附图内容所作的等效结构变换，或直接/间接运用在其他相关的技术领域均包括在本发明的专利保护范围内。