一种申请信息的处理方法及装置

本申请涉及数据处理领域，尤其涉及一种申请信息的处理方法及装置。

随着人们生活水平的日益提高，贷款交易已经成为一种常见的交易方式。当人们在日常生活中遇到资金周转困难或者是需要大额资金进行交易时，通常会选择向银行等金融机构进行贷款业务的办理。

贷款业务的办理一般需要申请人提供一些信息，金融机构根据这些信息确定申请人的贷款需求，并且根据申请人提供的信息判断申请人的信用和还款的能力。现有的贷款业务大多数是通过人工办理的，线上可以办理的贷款业务一般较为简单，均是申请人自主支付的用款方法。这是由于自主支付是将申请人申请的贷款直接发放到申请人在所申请的金融机构开设的账户中，交易系统获取用户的用户标识和该用户的收款账号，完成核验后向收款账号放款。交易系统并不能将款项发放到其他用户的账号上，如果收款账号的用户与申请用户并不对应，认为申请信息有误。因此不能实现将贷款发放到申请人以外的相关人员的账户上，不能处理申请用户和收款用户不一致的申请信息，不能实现多种用款方式的业务的办理。

为了解决现有技术存在的上述技术问题，本申请提供了一种申请信息的处理方法及装置，通过获取用户的用款信息，判断收款用户与用户标识的对应关系是否与用款信息中所预设的对应关系是否一致，完成申请信息的处理。可以解决现有技术中，交易系统不能处理申请用户和收款用户不一致的申请的问题。

本申请实施例公开了如下技术方案：

第一方面，本申请实施例提供了一种申请信息的处理方法，包括：

获取用户的申请信息；其中，所述申请信息中具有用户标识、目标收款账户和用款信息；根据所述目标收款账户获取目标收款用户；根据所述用款信息确定用款方式；

若所述用款方式为自主支付，判断所述目标收款用户是否与所述用户标识相对应；若是，则根据所述用款信息和所述目标收款账户发放用款，完成对所述申请信息的处理；

若所述用款方式为受托支付，判断所述目标收款用户是否与所述用户标识相对应；若否，则根据所述用款信息和所述目标收款账户发放用款，完成对所述申请信息的处理。

可选的，当所述目标收款账户具有所属的目标交易系统时，所述根据所述目标收款账户获取目标收款用户，包括：

根据所述目标收款账户，从所述目标交易系统中获取目标收款账户。

可选的，当所述目标交易系统与获取用户的申请信息的交易系统不同时，所述根据所述目标收款账户，从所述目标交易系统中获取目标收款账户，包括：

根据所述目标收款账户向交易系统联合平台发送请求信息，获取所述交易系统联合平台的反馈信息，从所述反馈信息中获取由所述目标交易系统提供的目标收款账户信息；

所述根据所述用款信息和所述目标收款账户发放用款，包括：

根据所述用款信息和所述目标收款账户，通过跨系统交易系统向所述目标收款账户发放用款。

可选的，所述获取所述交易系统联合平台的反馈信息，包括：

若在预设时间内未获取到由所述交易系统联合平台发送的反馈信息，则主动从所述交易系统联合平台中获取所述反馈信息。

可选的，在所述根据所述用款信息和所述目标收款账户发放用款之前，所述方法还包括：

根据所述用户标识获取用户信息，根据所述用户信息确定所述用户满足预设的申请条件；

所述根据所述用户信息确定所述用户满足预设的申请条件，具体包括：

根据所述用户信息中的信用信息确定所述用户信用符合预设信用阈值，和/或根据所述用户信息中的资金情况信息确定所述用户符合预设的用款阈值。

可选的，所述根据所述用款信息和所述目标收款账户发放用款，具体包括：

根据所述用款信息中的用款数值和所述目标收款账户，向所述目标收款账户发放与所述用款数值相对应的用款。

可选的，所述方法还包括：

当所述用款方式为自主支付，所述目标收款用户与所述用户标识不对应时，或当所述用款方式为受托支付，所述目标收款用户与所述用户标识相对应时，向所述用户发送处理失败信息。

第二方面，本申请实施例提供了一种申请信息的处理装置，所述装置包括：

获取单元，用于获取用户的申请信息；其中，所述申请信息中具有用户标识、目标收款账户和用款信息；根据所述目标收款账户获取目标收款用户；根据所述用款信息确定用款方式；

处理单元，用于若所述用款方式为自主支付，判断所述目标收款用户是否与所述用户标识相对应；若是，则根据所述用款信息和所述目标收款账户发放用款，完成对所述申请信息的处理；若所述用款方式为受托支付，判断所述目标收款用户是否与所述用户标识相对应；若否，则根据所述用款信息和所述目标收款账户发放用款，完成对所述申请信息的处理。

可选的，所述装置还包括：

审核单元，用于在所述根据所述用款信息和所述目标收款账户发放用款之前，根据所述用户标识获取用户信息，根据所述用户信息确定所述用户满足预设的申请条件；

所述根据所述用户信息确定所述用户满足预设的申请条件，具体包括：

根据所述用户信息中的信用信息确定所述用户信用符合预设信用阈值，和/或根据所述用户信息中的资金情况信息确定所述用户符合预设的用款阈值。

可选的，所述装置还包括：

处理失败单元，用于当所述用款方式为自主支付，所述目标收款用户与所述用户标识不对应时，或当所述用款方式为受托支付，所述目标收款用户与所述用户标识相对应时，向所述用户发送处理失败信息。

相较于现有技术，本申请具有以下有益效果：

在本申请实施例提供的方法中，获取用户的申请信息，根据申请信息中的目标收款账户获取目标收款用户，根据申请信息中的用款信息确定用款方式，判断目标收款用户与所述用户标识的对应关系是否与用款方式中预设的对应关系一致，如果一致，完成对所述申请信息的处理。由此可知，本申请实施例提供的方法通过判断申请信息中用户和收款用户的对应关系是否和用款方式一致，来对申请信息进行处理。由此可以通过选择不同的用款方式来对不同情况的申请信息进行处理，解决了现有技术中不能处理申请用户和收款用户不一致的申请信息，可以通过选择不同的用款方式来实现多种用款方式的业务的办理。

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

图1为本申请实施例提供的一种申请信息的处理方法的流程图；

图2为本申请实施例提供的另一种申请信息的处理方法的流程图；

图3为本申请实施例提供的一种申请信息的处理装置的结构示意图。

正如前文所述，贷款交易具有多种类型，申请人可以根据自己的实际需要向银行等金融机构提出申请，当金融机构审核完成后认为该用户具有申请贷款的资格后，会将款项发放到申请人提供的账户中。随着移动支付的快速发展，部分小额贷款业务可以在移动设备上的金融机构的客户端实现，用户在线上提交申请信息，可以快速实现审批，得到放款款项。

发明人发现，现有的线上贷款均是采用自主支付的用款方式，也就是说，申请用户的贷款款项只能发放到自己的账户中，不能直接发放到其他用户的账户中，而其他种类的用款方式只能通过线下人工办理。这是由于在现有技术中，线上贷款只能处理申请用户和收款用户一致的申请信息，申请用户不能提交申请用户和收款用户不一致的申请信息，或者不一致的申请信息会认为是错误信息，所以申请用户在线上申请贷款只能选用自己的账户，现有技术中不能实现对多种申请信息的处理。

发明人经过研究发现，在获取用户的申请信息时，可以向用户提供用款方式的选择，在获得用户的申请信息之后，可以根据申请信息中的用款信息确定用款方式，判断目标收款用户与所述用户标识的对应关系是否与用款方式中预设的对应关系一致，如果一致，就可以认为用户提供的申请信息是正确的，可以完成对所述申请信息的处理。通过进行一次判断可以实现对于不同种类的用款方式的申请信息的处理。

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

第一实施例

参见图1，该图为本申请实施例提供的一种申请信息的处理方法的流程图。

在本实施例中，所述方法例如可以通过如下步骤S101-S103实现。

S101：获取用户的申请信息；其中，所述申请信息中具有用户标识、目标收款账户和用款信息；根据所述目标收款账户获取目标收款用户；根据所述用款信息确定用款方式。

可以理解的是，本申请实施例中的申请信息是用户提供的，本申请实施例中不限定获取申请信息的具体方式，在一种可能的实现方式中，可以通过获取申请请求，根据申请请求获取申请信息。

需要说明的是，用户标识可以为区别其他用户所使用的标识，可以为用户的姓名，也可以为用户在交易系统注册过的相关的独一无二的信息。目标收款账户可以为账户账号，用款信息中可以包括用款所使用到的相关信息，可以包括用款金额、用款方式、用款时间，还款时间等。

需要说明的是，本申请实施例中不限定根据所述目标收款账户获取目标收款用户的获取方式，在一种可能的实现方式中，可以通过相关的信息库中检索得到，也可以根据目标收款账户具有的标识查目标收款用户。

需要说明的是，本申请实施例中的用款方式中具有自主支付和受托支付两种，其中自主支付是指用户和目标收款用户是同一人，受托支付是指用户和目标收款用户不是同一人。可以理解的是，用款方式是用户在申请信息中所提供的，在一种可能的实现方式中，当用款方式是受托支付时，可以判断目标收款账户是否是用户相关的账户，若是，可以向用户反馈申请信息错误。

S102：若所述用款方式为自主支付，判断所述目标收款用户是否与所述用户标识相对应；若是，则根据所述用款信息和所述目标收款账户发放用款，完成对所述申请信息的处理。

本申请实施例中不限定判断方式，在一种可能的实现方式中，可以判断目标收款用户的用户标识是否与申请信息中的用户标识一致，也可以判断与申请信息中的用户标识相对应的用户是否和目标收款用户一致。

本申请实施例中不限定申请信息处理完成的具体步骤，在一种可能的实现方式中，可以在发放用款时同步向用户发送处理完成的信息，也可以异步向用户发送信息。

S103：若所述用款方式为受托支付，判断所述目标收款用户是否与所述用户标识相对应；若否，则根据所述用款信息和所述目标收款账户发放用款，完成对所述申请信息的处理。

由上可知，本申请实施例提供的申请信息的处理方法，通过获取申请信息中具有的用款方式和目标收款用户，判断目标收款用户与所述用户标识的对应关系是否与用款方式中预设的对应关系一致，由此可以通过选择不同的用款方式来对不同情况的申请信息进行处理。

第二实施例

在上述第一实施例中，仅对不同的用款方式的申请信息进行了处理，但是在实际情况中，有可能收款账户所属的交易系统可能与申请的交易系统并不是同一个系统，对于属于不同的交易系统之间的交互需要通过其他联合系统平台才可以实现。

针对上述情况，本申请提供了另一种申请信息的处理方法，图2为本申请实施例提供的另一种申请信息的处理方法的流程图。

下面对该实施例进行详细的说明，在本实施例中，所述方法例如可以通过如下步骤S201-S204实现。

S201：获取用户的申请信息；其中，所述申请信息中具有用户标识、目标收款账户和用款信息；当所述目标收款账户具有所属的目标交易系统时，根据所述目标收款账户，从所述目标交易系统中获取目标收款账户；根据所述用款信息确定用款方式。

可以理解的是，本申请实施例中的交易系统可以为各个商业银行的系统。目标交易系统可以与获取申请信息的交易系统并不一致。当所述目标交易系统与获取用户的申请信息的交易系统不同时，可以根据所述目标收款账户向交易系统联合平台发送请求信息，获取所述交易系统联合平台的反馈信息，从所述反馈信息中获取由所述目标交易系统提供的目标收款账户信息。可以理解的是，交易系统联合平台可以是相关的银联的系统。

需要说明的是，若在预设时间内未获取到由所述交易系统联合平台发送的反馈信息，则主动从所述交易系统联合平台中获取所述反馈信息。本申请实施例中不限定预设时间，可以为正常信息交互所需要的时间。

S202：根据所述用户标识获取用户信息，根据所述用户信息确定所述用户满足预设的申请条件。

需要说明的是，根据所述用户信息确定所述用户满足预设的申请条件，具体可以包括：根据所述用户信息中的信用信息确定所述用户信用符合预设信用阈值，和/或根据所述用户信息中的资金情况信息确定所述用户符合预设的用款阈值。可以理解的是本申请实施例中不限定确定用户满足申请条件的顺序，在一种可能的实施方式中，可以为获取用户的申请信息后进行确定，也可以在根据所述用款信息和所述目标收款账户发放用款之前进行。需要说明的是，本申请实施例中不限定判断用户信用符合预设信用阈值以及用户信息中的资金情况信息确定所述用户符合预设的用款阈值的具体方式。可以获取用户信用值，判断是否到达预设信用值。可以获取用户用款金额数值，判断是否超过用款阈值，也可以获取用户未还清用款的数值，判断是否超过欠款阈值。预设信用阈值和预设的用款阈值可以根据实际需要进行设置。

可以理解的是，用户信息中的资金情况信息可以从交易系统中的相关的信用卡系统中获取。

可以理解的是，当用户不满足预设的申请条件时，可以通知用户申请信息处理失败或者是向用户提供其他申请的途径，例如人工服务等。

S203：若所述用款方式为自主支付，判断所述目标收款用户是否与所述用户标识相对应；若是，则根据所述用款信息中的用款数值和所述目标收款账户，向所述目标收款账户发放与所述用款数值相对应的用款，完成对所述申请信息的处理。

需要说明的是，当目标交易系统和获取申请信息的交易系统不同时，可以根据所述用款信息和所述目标收款账户，通过跨系统交易系统向所述目标收款账户发放用款。可以理解的是，跨系统交易系统可以为人民银行大小额交易系统。

可以理解的是，当目标收款用户与所述用户标识不对应时，可以向用户发送处理失败信息。

S204：若所述用款方式为受托支付，判断所述目标收款用户是否与所述用户标识相对应；若否，则根据所述用款信息中的用款数值和所述目标收款账户，向所述目标收款账户发放与所述用款数值相对应的用款，完成对所述申请信息的处理。

可以理解的是，当目标收款用户与所述用户标识相对应时，可以向用户发送处理失败信息。

本申请实施例通过获取目标收款账户所属的目标交易系统，当目标交易系统和获取申请信息的交易系统不一致时，通过其他相关的系统实现信息交互和放款，可以实现向不同交易系统中的账户发放用款，解决了现有技术中对于此类申请信息只能向申请用户名下的同交易系统的账户发放用款的问题。

第三实施例

图3为本申请实施例提供的一种申请信息的处理装置的结构示意图。

例如具体可以包括：

获取单元301，可以用于获取用户的申请信息；其中，所述申请信息中具有用户标识、目标收款账户和用款信息；根据所述目标收款账户获取目标收款用户；根据所述用款信息确定用款方式；

处理单元302，可以用于若所述用款方式为自主支付，判断所述目标收款用户是否与所述用户标识相对应；若是，则根据所述用款信息和所述目标收款账户发放用款，完成对所述申请信息的处理；若所述用款方式为受托支付，判断所述目标收款用户是否与所述用户标识相对应；若否，则根据所述用款信息和所述目标收款账户发放用款，完成对所述申请信息的处理。

可以理解的是，所述装置还可以包括：

审核单元，用于在所述根据所述用款信息和所述目标收款账户发放用款之前，根据所述用户标识获取用户信息，根据所述用户信息确定所述用户满足预设的申请条件；

所述根据所述用户信息确定所述用户满足预设的申请条件，具体包括：

根据所述用户信息中的信用信息确定所述用户信用符合预设信用阈值，和/或根据所述用户信息中的资金情况信息确定所述用户符合预设的用款阈值。

可以理解的是，所述装置还可以包括：

处理失败单元，可以用于当所述用款方式为自主支付，所述目标收款用户与所述用户标识不对应时，或当所述用款方式为受托支付，所述目标收款用户与所述用户标识相对应时，向所述用户发送处理失败信息。

应当理解，在本申请中，“至少一个(项)”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，用于描述关联对象的关联关系，表示可以存在三种关系，例如，“A和/或B”可以表示：只存在A，只存在B以及同时存在A和B三种情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b或c中的至少一项(个)，可以表示：a，b，c，“a和b”，“a和c”，“b和c”，或“a和b和c”，其中a，b，c可以是单个，也可以是多个。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元及模块可以是或者也可以不是物理上分开的。另外，还可以根据实际的需要选择其中的部分或者全部单元和模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述仅是本申请的具体实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。