CN111582868A

CN111582868A - Transaction request processing method, device and equipment

Info

Publication number: CN111582868A
Application number: CN202010454445.2A
Authority: CN
Inventors: 姚军伟; 刘丁峰
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2020-05-26
Filing date: 2020-05-26
Publication date: 2020-08-25
Anticipated expiration: 2040-05-26
Also published as: CN116934340A; CN111582868B

Abstract

The embodiment of the specification discloses a processing mode, a device and equipment of a transaction request, and the scheme comprises the following steps: acquiring a transaction request sent by a first terminal; determining a first position corresponding to the position identifier; sending information to be positioned, which at least comprises a mobile phone number corresponding to the user identification, to a communication operator server; receiving a first positioning result returned by the communication operator server; judging whether the first position is consistent with the second position or not based on the first positioning result; if the two are consistent, starting a primary verification process; if not, starting a secondary verification process.

Description

Transaction request processing method, device and equipment

Technical Field

The present application relates to the field of computer technologies, and in particular, to a method, an apparatus, and a device for processing a transaction request.

Background

With the development of computer technology, people can handle more and more tasks in mobile terminals. In recent years, users who perform task processing through a mobile banking or mobile payment application terminal are in a rapid growth trend, and meanwhile, because the users need a network as a carrier when handling tasks through a mobile terminal, some security risk problems are inevitably generated in the task processing process, for example, a fraudster forges user information to perform improper task processing, and may bring certain resource loss to the users.

Therefore, how to more comprehensively and accurately identify risks in task processing and reduce user resource loss is a technical problem to be solved in the field.

Disclosure of Invention

The embodiment of the specification provides a method, a device and equipment for processing a transaction request, which can more comprehensively and accurately identify risks in transactions.

In order to solve the above technical problem, the embodiments of the present specification are implemented as follows:

the method for processing the transaction request provided by the embodiment of the specification comprises the following steps:

the server acquires a transaction request sent by a first terminal; the transaction request carries a user identifier and a position identifier of the first terminal;

determining a first position corresponding to the position identification;

sending information to be positioned, which at least comprises a mobile phone number corresponding to the user identification, to a communication operator server, wherein the information to be positioned is used for determining a second position of the terminal using the user identification card corresponding to the mobile phone number;

receiving a first positioning result returned by the communication operator server;

judging whether the first position is consistent with the second position or not based on the first positioning result;

if the two are consistent, starting a primary verification process;

if not, starting a secondary verification process; the security level of the secondary verification process is higher than that of the primary verification process.

An embodiment of this specification provides a processing apparatus for a transaction request, including:

the transaction request acquisition module is used for acquiring a transaction request sent by a first terminal; the transaction request carries a user identifier and a position identifier of the first terminal;

the first position determining module is used for determining a first position corresponding to the position identifier;

the to-be-positioned information sending module is used for sending to-be-positioned information at least containing a mobile phone number corresponding to the user identification to a communication operator server, and the to-be-positioned information is used for determining a second position of a terminal using a user identification card corresponding to the mobile phone number;

a positioning result receiving module, configured to receive a first positioning result returned by the communication operator server; the first positioning result is a result indicating whether the first position and the second position are consistent;

the position judging module is used for judging whether the first position is consistent with the second position or not based on the first positioning result;

the first-level verification starting module is used for starting a first-level verification process if the first position is consistent with the second position;

the second-stage verification starting module is used for starting a second-stage verification process if the first position is inconsistent with the second position; the security level of the secondary verification process is higher than that of the primary verification process.

An embodiment of the present specification provides a processing device of a transaction request, including:

at least one processor; and the number of the first and second groups,

a memory communicatively coupled to the at least one processor; wherein the content of the first and second substances,

the memory stores instructions executable by the at least one processor to enable the at least one processor to:

acquiring a transaction request sent by a first terminal; the transaction request carries a user identifier and a position identifier of the first terminal;

determining a first position corresponding to the position identification;

if the two are consistent, starting a primary verification process;

Embodiments of the present specification provide a computer-readable medium, on which computer-readable instructions are stored, where the computer-readable instructions are executable by a processor to implement the above processing method for transaction requests.

One embodiment of the present description achieves the following advantageous effects:

in the embodiment of the description, the position of the terminal is positioned by the mobile phone number and the communication operator according to the corresponding position information in the transaction request, so that the user sending the transaction request can be covered comprehensively, the transaction request is verified through the position information of the user, and the comprehensiveness of the transaction request verification is ensured. In addition, in the embodiment of the specification, transaction requests can be processed by adopting different levels of verification processes according to different positioning results, high-level security verification can be performed on transaction requests with abnormal positions, verification of the same standard is not required for all users, the cost can be reduced, and the user experience is improved.

Drawings

In order to more clearly illustrate the embodiments of the present disclosure or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments described in the present application, and for those skilled in the art, other drawings can be obtained according to the drawings without any creative effort.

Fig. 1 is an overall architecture diagram of a transaction request processing method provided in an embodiment of the present disclosure in a practical application scenario;

fig. 2 is a flowchart illustrating a processing method of a transaction request according to an embodiment of the present disclosure;

fig. 3 is a flowchart illustrating a processing method of a transaction request according to an embodiment of the present disclosure;

fig. 4 is a schematic structural diagram of a processing device corresponding to a transaction request of fig. 2, provided in an embodiment of the present disclosure;

fig. 5 is a schematic structural diagram of a transaction information processing device corresponding to fig. 2 provided in an embodiment of the present specification.

Detailed Description

To make the objects, technical solutions and advantages of one or more embodiments of the present disclosure more apparent, the technical solutions of one or more embodiments of the present disclosure will be described in detail and completely with reference to the specific embodiments of the present disclosure and the accompanying drawings. It is to be understood that the embodiments described are only a few embodiments of the present specification, and not all embodiments. All other embodiments that can be derived by a person skilled in the art from the embodiments given herein without making any creative effort fall within the scope of protection of one or more embodiments of the present specification.

The technical solutions provided by the embodiments of the present description are described in detail below with reference to the accompanying drawings.

In recent years, retail banking tasks gradually become important engines for bank revenue generation, commercial banks perform retail transformation at a dispute, the retail tasks are vigorously developed, and mobile interconnection deeply changes the living and consumption habits of people, so that mobile banking becomes one of customer service main channels of the retail banks, and the transaction scale and the number of customers of domestic commercial banks are rapidly increased in recent years.

The financial service is more convenient and faster due to the existence of the mobile banking, the cost is lower and lower, but the mobile banking task has stronger internet compared with the traditional bank task, and meanwhile, various commercial banks continuously pursue task innovation and extreme user experience, so that various security holes and task holes are inevitably generated in the process. On the other hand, although the country is greatly stricken in internet fraud, the fraud industry tends to specialize and group under the drive of benefits, which brings great challenges to the security of mobile banking tasks.

The inventor researches and discovers that a remarkable characteristic of internet fraud is allopatricity, namely that a larger probability of a cheater is different from that of a cheated user in a city, so that how to accurately identify the position information of each dynamic account transaction of a mobile phone bank is effectively applied to a wind control system is an important part of wind control of the mobile phone bank.

The IP address is an abbreviation of internet protocol (internet protocol), and is a digital label assigned to an internet protocol device used by a user to access internet, and is generally composed of four segments, for example, 192.168.0.1. The IP positioning refers to identifying the user position information through a digital label distributed when the user accesses the Internet.

GPS Positioning is known as Global Positioning System (Global Positioning System), which is a Positioning System for high-precision radio navigation based on air satellites.

And (3) operator location authentication: the authentication service is provided by a communication operator, and is positioned in real time by a mobile phone number, wherein the mobile phone number and the city information are generally input, and the output is consistent or inconsistent or the result is null. The communication operator can determine the position of the terminal using the mobile phone number according to the mobile phone number, and when the input city information is consistent with the position determined by the mobile phone number, the information indicating the consistent position can be output; when the input city information is inconsistent with the position determined by the mobile phone number, the information indicating the position inconsistency can be output; and when the terminal using the mobile phone number is in a power-off or flight mode, outputting a null result.

The communication operator carries out positioning according to the mobile phone number by adopting base station positioning. Because each base station has its unique base station number, when a Subscriber Identity Module (SIM) card is inserted into the terminal, the current network type and network state of the terminal, the mobile phone hardware parameters and their providers, the mobile phone application details, the battery usage, and the information of recovering the factory settings of the mobile phone are stored in a specific area of the host memory of the terminal every time the terminal is powered on and accesses the network. Through the positioning of the base station, some parameters such as the base station number corresponding to the terminal can be obtained through a specific program, and the base station number corresponds to the area where the base station is located, so that the aim of positioning the mobile base station is finally fulfilled.

Accessing in a roaming place: roaming access is one of the access modes of a communication operator when a user accesses a mobile network, namely, the mobile user accesses the internet through the mobile network at the current location when using the operator network. Generally speaking, when the mobile user uses the mobile network in province A, the IP address assigned is the IP of province A, and when the mobile user uses the mobile network in province B, the IP address assigned is the IP of province B.

Home access: the home access is one of the access modes of the communication operator when the user accesses the mobile network, that is, no matter where the user uses the mobile network to access the internet, the operator allocates the mobile network resource of the city when the user accesses the internet for the user to access. Generally speaking, when a mobile subscriber with a network access place of a uses a mobile network in province B, the assigned IP address is the IP to which province a belongs, and when the mobile subscriber uses the mobile network in province C, the assigned IP address is still the IP to which province a belongs.

In order to more comprehensively and accurately identify risks in transactions, the scheme provides the following embodiments:

fig. 1 is a schematic overall architecture diagram of a transaction request processing method provided in an embodiment of the present disclosure in a practical application scenario.

As shown in fig. 1, the overall architecture mainly includes a user 1, a terminal 2, a server 3, and a communication operator server 4. The user 1 initiates a transaction through a certain transaction APP (application) in the terminal 2, the server 3 obtains a transaction request sent by the user terminal, and can determine the operation position of the terminal 2 according to a terminal position identifier carried in the transaction request, and the operation position can be understood as the position of initiating the transaction request, the server 3 can also determine a mobile phone number corresponding to a registration account number used by the user according to the user identifier carried in the transaction request, the registration account number can be an account number registered by the user into the APP user before the user uses the APP transaction, the server 3 can send the determined mobile phone number and the operation position to the communication operator server 4, the communication operator server 4 can determine the current position of the terminal using the mobile phone number according to the mobile phone number, and compare the current position with the operation position, and feed back a result whether the current position is consistent with the operation position to the server 3, when receiving the feedback information indicating that the current position is consistent with the operation position, the server 3 may start a primary authentication process, for example, prompt the user to input a transaction password; when receiving the feedback information indicating that the current position is inconsistent with the operation position, the server 3 may start a secondary authentication process with a security level higher than that of the primary authentication, for example, prompt the user to perform face recognition, thereby performing a hierarchical processing on the transaction request.

Next, a transaction request processing method provided in an embodiment of the specification will be specifically described with reference to the accompanying drawings:

fig. 2 is a flowchart illustrating a processing method of a transaction request according to an embodiment of the present disclosure. From the viewpoint of a program, the execution subject of the flow may be a program installed in an application server or an application client.

As shown in fig. 2, the process may include the following steps:

step 202: the server acquires a transaction request sent by a first terminal; the transaction request carries a user identifier and a location identifier of the first terminal.

In the embodiment of the present specification, a user may initiate a transaction request through an application installed in a terminal, and a server may obtain the transaction request and may also analyze various information carried in the transaction request. Among them, the terminal may include but is not limited to the following devices: cell-phone, panel computer, intelligent wrist-watch, car machine, personal computer etc..

In general, when a user initiates a transaction request through an application program, the user needs to register the user of the application program first, and the transaction request received by the server may carry an identifier of the registered user, for example, the user performs a transaction through a mobile banking APP, and needs to register the user of the mobile banking APP in a manner of a mobile phone number or a mailbox, and the transaction request acquired by the server may carry the user identifier of the registered user when initiating a transaction. . In practical applications, the user identifier may be an identifier generated by the server according to the registration information of the user and used for distinguishing other registered users, and the server may also determine information associated with the registered user according to the user identifier, such as a registered account number, user information, login information, transaction information, and the like.

Because the request initiated by the user through the terminal is a transaction performed through the network, the transaction request may also carry a location identifier for identifying the location of the terminal, for example, an IP address, GPS information, and the like carried in the transaction request.

Step 204: and determining a first position corresponding to the position identification.

The server can determine a first position corresponding to the position identification according to the position identification carried in the transaction request. For example, the server may determine a location corresponding to the IP address by analyzing the IP address carried in the transaction request; for another example, the server may also determine the GPS-located location from GPS information.

Step 206: and sending information to be positioned, which at least comprises the mobile phone number corresponding to the user identification, to a communication operator server, wherein the information to be positioned is used for determining a second position of the terminal using the user identification card corresponding to the mobile phone number.

In practical application, when a user registers as a user of an APP, the user usually registers a mobile phone number, or the mobile phone number of the user exists in user data in the APP, and the server may determine the mobile phone number corresponding to the user identifier according to the user identifier, where the user identifier may also be the mobile phone number of the user. The server can include the determined mobile phone number in the information to be positioned and send the information to the communication operator server, and the communication operator server can determine the position of a user identification card, such as a terminal of an SIM card, using the mobile phone number according to the mobile phone number.

When a user registers as a user of an APP, the user generally signs a user agreement with the APP platform, the agreement may contain content that allows the APP platform to perform operator location authentication, and the server may perform operator location authentication on the user using the APP.

The communication carrier may refer to a provider providing network communication services, such as three communication carriers in the country: china Mobile, China Unicom, China telecom. The communication operator server may be a server corresponding to a communication operator and providing a network communication service.

Step 208: and receiving a first positioning result returned by the communication operator server.

In practical application, a communication operator can determine the position of a terminal using a mobile phone number according to the mobile phone number provided by a server, and feed back a positioning result to the server.

Step 210: and judging whether the first position is consistent with the second position or not based on the first positioning result.

The server may receive a positioning result fed back by the communication carrier server, wherein the positioning result may represent a result of whether the first location and the second location are consistent. In the implementation application, the server can send the first position and the user mobile phone number to the communication operator server, and ask the communication operator server to confirm whether the current position of the user mobile phone number is consistent with the first position. The communication operator server can determine a second position of the terminal using the mobile phone number through base station positioning according to the mobile phone number of the user, and when the first position is consistent with the second position, information indicating the consistency of the positions can be fed back to the server, and if the first position is consistent with the second position, the information is fed back to the server; when the first location is inconsistent with the second location, information indicating the position inconsistency may be fed back to the server, such as feeding back "inconsistency" to the server.

It should be noted that, in the embodiment of the present disclosure, the position coincidence may mean that the first position and the second position belong to the same preset range. For example, the first position is province a, and the second position is city B belonging to province a, and the first position and the second position may be considered to coincide.

Step 212: if the two are consistent, a first-level verification process is started.

Step 214: if not, starting a secondary verification process; the security level of the secondary verification process is higher than that of the primary verification process.

The server can start verification processes of different levels according to different feedback results, when the feedback positioning result shows that the first position is consistent with the second position, the transaction can be considered to be safe, and a first-level verification process with a lower safety level can be started, for example, if a transaction verification mode set by the user is password verification, when the feedback positioning result shows that the first position is consistent with the second position, a process for prompting the user to input password verification can be started; when the fed-back positioning result indicates that the first position is inconsistent with the second position, it can be considered that the transaction has a risk, and a secondary verification process with a higher security level needs to be started, for example, a process for prompting a user to perform face recognition verification is started, so that the security of the transaction can be ensured, and considering that the secondary verification requires a verification mode that the operation of the user is more complicated or a transaction platform needs to provide higher cost, the hierarchical verification mode in the embodiment of the description can also reduce the cost and improve the user experience.

In the embodiment of the description, the position of the terminal is positioned by the mobile phone number and the communication operator according to the corresponding position information in the transaction request, so that the user sending the transaction request can be covered comprehensively, the transaction request is verified through the position information of the user, and the comprehensiveness of the transaction request verification is ensured.

In addition, in the embodiment of the present specification, transaction requests can be processed by adopting different levels of verification processes according to different positioning results, high-level security verification can be performed on transaction requests with abnormal positions, verification of the same standard is not required for all users, and considering that the secondary verification requires a verification mode that the operation of the user is complicated or a transaction platform needs to provide high cost, the hierarchical verification mode in the embodiment of the present specification can also reduce cost and improve user experience.

It should be understood that the order of some steps in the method described in one or more embodiments of the present disclosure may be interchanged according to actual needs, or some steps may be omitted or deleted.

Based on the above, in the method for processing a transaction request in this embodiment of the present description, before sending information to be located, which at least includes a mobile phone number corresponding to the user identifier, to a communication operator server, the method may further include:

obtaining a trusted position corresponding to the user identifier; the credible position is used for representing a common position of the user terminal carrying the user identification;

judging whether the first position is consistent with the credible position or not to obtain a second positioning result;

the sending of the information to be positioned, which at least includes the mobile phone number corresponding to the user identifier, to the communication operator server specifically includes:

and if the second positioning result shows that the first position is inconsistent with the credible position, sending information to be positioned, which at least comprises the mobile phone number corresponding to the user identification, to a communication operator server.

In practical applications, before the location authentication is performed by using the communication carrier, the server may further determine whether the transaction based on the first location is risky according to a trusted location determined according to a preset condition. The trusted location is used to represent a common location of the user terminal carrying the user identifier, and may also be understood as a common location where the user uses a registered account to perform a transaction.

Usually, the server may obtain the position where the transaction occurs according to the transaction information of the user, for example, by using the IP address information carried in the transaction information, the address corresponding to the IP address is determined as the transaction address; for another example, when the user authorizes the transaction platform to use the GPS positioning function, the address obtained through the GPS positioning function may be determined as the transaction address; for another example, when a user logs in an APP to perform an offline transaction, the transaction address of the user may be determined by obtaining the location of the counterparty, and so on.

Since the trusted location may be a common address for user transactions, it may be an indication that the transaction is at risk when the first location of the transaction request is not consistent with the trusted location. In practical application, a user may leave a common position of a transaction for some reasons, for example, a place where the user works and lives in daily life is a city a, and the user needs to go out to a city B because of work, when the user initiates a transaction request in the city B, the server learns that a first position of the transaction request is different from a trusted position of the user by acquiring address information carried in the transaction request, and in order to further determine whether the transaction is normally initiated by the user, position determination can be performed by means of a communication operator. When the result fed back by the communication operator shows that the first position is consistent with the second position corresponding to the mobile phone number, starting a primary verification process; and when the first position is inconsistent with the second position corresponding to the mobile phone number, starting a secondary verification process. Therefore, disturbance to the user due to normal position movement of the user can be avoided, and the user experience can be improved while the transaction safety is ensured.

In addition, in practical application, the location authentication service provided by the communication operator is usually a charging service, and before the location authentication is performed by the communication operator, the first location is compared with the trusted location, and when the first location is inconsistent with the trusted location, the information to be located, which at least includes the mobile phone number corresponding to the user identifier, is sent to the communication operator server, so that the cost can be reduced.

Based on the foregoing, determining whether the first location is consistent with the trusted location, obtaining a second positioning result, where after the obtaining of the second positioning result, the method may further include:

and if the second positioning result shows that the first position is consistent with the credible position, starting the primary verification process.

In this embodiment of the present description, when the server determines that the first location is consistent with the trusted location, it may be considered that the risk of the transaction is low, and may start a primary verification process, or perform location without using a communication carrier. Therefore, the disturbance to normal users can be reduced, and the cost of risk control can also be reduced.

In practical applications, communication carriers provide users with different network access modes, such as home access, roaming access, and the like. When the network mode provided by the communication operator is home access, the IP address acquired by the server is the access address of the user, and the position corresponding to the mobile phone number located by the communication operator through the base station is usually the actual position of the user, at this time, the position determined by the server may be different from the position determined by the communication operator. In this specification, the trusted address may be a common address determined by the server according to the IP address of the user, and when the IP address of the user is the IP address of the home location, a first location acquired by the server may be different from a second location located by the communications carrier through the mobile phone number, but the first location is a common transaction location of the user.

When a user uses the APP to conduct transaction, the user of the APP generally needs to be registered first, after the user is registered or in the process of registering the user, the server can inquire whether the user authorizes the server to use the GPS positioning function, and after the user agrees to authorization, the server can acquire GPS positioning information of the user when the user uses the APP.

In this embodiment of the present description, the location identifier may include an identifier indicating GPS positioning information, where the first location may specifically be a GPS positioning location determined by the GPS positioning information of the first terminal, and the determining a first location corresponding to the location identifier may specifically include:

acquiring authority information of the first terminal;

judging whether the server has the authority to use the GPS positioning function of the first terminal or not based on the authority information;

and if the server has the authority of using the GPS positioning function of the first terminal, determining the GPS positioning position of the first terminal according to the GPS positioning information of the first terminal.

In the embodiment of the description, the GPS location position of the user may be compared with the trusted position, and whether the transaction position is abnormal or not is determined to start different verification processes, so that the security of the transaction may be improved.

In this embodiment of the present description, the location identifier may further include an identifier indicating IP address information, where the first location may specifically be an IP location corresponding to the IP address information of the first terminal, and after determining whether the server has a right to use a GPS positioning function of the first terminal, the method may further include:

and if the server does not have the authority of using the GPS positioning function of the first terminal, determining the IP position of the first terminal according to the identification of the IP address information.

Because of the user is more sensitive to positional information among the practical application, probably there is the user who does not agree to APP start user terminal GPS locate function, leads to the proportion that APP's server can successfully gather GPS information lower, and then produces great influence to the wind accuse effect of transaction. In the embodiment of the specification, when the user does not authorize to use the GPS function of the terminal, the server can also determine the transaction position according to the IP address information carried in the transaction request, and the abnormal judgment of the transaction position is carried out, so that more users can be covered, and the safety of the user is improved.

In the embodiment of the specification, the IP position can be compared with the credible position, the false IP can be identified to a certain extent, the transaction risk is effectively identified, and the transaction safety is improved.

In order to further effectively identify risks in a transaction and improve security of the transaction, in an embodiment of this specification, before the starting of the primary verification process, the method may further include:

if the first position is consistent with the second position, acquiring equipment information and transaction counter-party information related to the transaction request;

judging whether the transaction corresponding to the transaction request hits a weak wind control strategy or not according to the equipment information and the information of the counter party of the transaction to obtain a first judgment result;

if the first judgment result is negative, starting the primary verification process;

and if the first judgment result is yes, starting the secondary verification process.

In the embodiment of the present specification, the primary authentication flow may be an authentication mode with a simple processing procedure and a low security level, or may be an authentication mode that the server itself can complete without using other third-party services, such as password authentication, and the like. For example, a user uses a certain mobile banking APP to perform a transaction, a server of the mobile banking APP may provide a password verification mode for the user, and the password may be a password set by the user. After the user sets the password, the server can store the corresponding relation between the password and the user, and when the user conducts transaction, the user can be verified by whether the stored password is consistent with the password input by the user during the transaction.

The secondary verification process may be a verification mode with a complex processing process and a high security level, or a verification mode which can be completed by the server only with the help of other third-party services, such as fingerprint identification, face identification, iris identification, short message dynamic verification code, and the like. For example, a user uses a certain mobile banking APP to perform a transaction, and when the user performs face recognition, the user needs higher technical support due to a complex face recognition process, and the mobile banking APP considering the factors such as technology or cost does not have a face recognition function, and can recognize the face only by means of technical service provided by a third party.

In practical application, the secondary verification process can also be a new verification mode added on the basis of the processing mode of the primary verification process. For example, the first-level verification process may be performed by password verification, and the second-level verification process may be performed by password verification and then dynamic code verification. The specific manner of the first-level verification and the second-level verification in this specification is not particularly limited, as long as the actual requirements are met.

The weak wind control strategy can be used for judging whether the transaction has risks under certain conditions so as to set risk judgment rules.

In order to identify transaction risks more accurately and ensure the security of transactions, in the embodiment of the present specification, when the first location is consistent with the second location, whether a risk exists in a transaction may be further determined according to device information and transaction opponent information included in a transaction request, and when it is determined that a device initiating the transaction request or a transaction opponent is risky, a secondary verification process with a higher security level may be started; when it is determined that neither the device initiating the transaction request nor the counterparty has a risk, the risk of the transaction is considered to be low, and a primary verification process with a low security level can be started.

The determining whether the transaction corresponding to the transaction request hits the weak wind control policy may specifically include:

judging whether the equipment information hits equipment information wind control conditions or whether the information of the transaction counter-party hits information wind control conditions of the transaction counter-party;

the device information wind control condition may specifically include: the first terminal is any one of new equipment, unbound equipment and non-used equipment;

the trade-counter-party information wind control condition may specifically include: the transaction counter-party of the transaction is any one of a non-trusted transaction counter-party and a non-historical transaction counter-party.

In this embodiment of the present specification, it may be determined whether a risk exists in a transaction corresponding to the transaction request from the device information and the information of the transaction counter-party.

Wherein the new device may be a terminal in which no transaction related to the user identity has occurred; for example, when a user logs in a user account in a terminal for the first time, the terminal is a new device for the user account.

The non-binding device may be a device that has no binding relation with an account corresponding to the user identifier. In practical applications, after a user registers as a user of an APP, a binding device may be set in the APP, or a default device for performing operations may be set as the binding device, the user may also set a device that frequently logs in using the account as the binding device, and the server may store information of the binding device, such as a device name, a model number, an IMEI (International Mobile equipment identity), and the like.

The non-common device may be a device in which the number of times of logging in the account corresponding to the user identifier within a preset time period is less than a predetermined number of times, or may be a device in which the accumulated time of logging in the account corresponding to the user identifier within the preset time period is less than a predetermined time. In practical application, the server may record login conditions of a user account, and may determine a device that frequently logs in the user account within a recent period of time as a frequently-used device, and determine a device that is different from the frequently-used device as an unusual device. Wherein, the server can distinguish the equipment by the IMEI code of the equipment.

The exception device may be a device that has been exception-handled or rejected, such as a swiped device, a jail device, an older model device, a device with a lower version of the operating system, and so forth.

The non-trusted counterparty may be a user who has not transacted with the account corresponding to the user identifier within a preset time period, or may be a counterparty to which the user has joined the list. A non-historical transaction opponent can be an account number for which a transaction has not occurred with an account number that does not correspond to the user identification. In practical application, the server may record historical transaction information that a user account has performed, wherein the historical transaction information may include account information of a transaction counter-party, and the server may determine whether the transaction counter-party corresponding to the transaction request is at risk.

In practical application, whether the weak wind control strategy is hit in the transaction can be judged according to the preset priority sequence, the higher risk of the transaction request can be determined as long as any risk factor in the weak wind control strategy is hit, a secondary verification process with higher security level needs to be started, the judgment of the risk factor can be stopped, the risk determination speed can be increased, the transaction request processing speed can be increased, and server resources can be saved. The following table 1 shows priorities and judgment results corresponding to risk factors in the weak wind control strategy.

Priority level	Risk factors	The judgment result
			1	New equipment	The equipment is at risk
2	Equipment not in use	The equipment is at risk
			3	Non-binding device	The equipment is at risk
4	Untrusted counterparty	Risk to counterparty
			5	Non-historical transaction counter-parties	Risk to counterparty

TABLE 1

Supposing that a user logs in a certain mobile banking APP in a terminal to initiate a transaction request, a server can acquire a terminal identification code carried in the transaction request, firstly, whether the terminal is new equipment is judged through the identification code, when the terminal is judged to be the new equipment, a result that the equipment has risk can be obtained, the fact that the user needs to perform secondary verification with higher security level is shown, and judgment of the risk factor can be finished; when the terminal is judged not to be the new device, whether the terminal is the non-use binding device or not can be continuously judged, when the terminal is judged not to be the non-use binding device or not, whether the transaction counter-party is the non-credible transaction counter-party or not can be continuously judged through the transaction counter-party information carried in the transaction request, when the transaction counter-party is the non-credible transaction counter-party, secondary verification with higher security level is required to be carried out by the user, and judgment of the risk factor can be finished. When no risk factor exists in the transaction request, the risk of the transaction can be determined to be low, and a primary verification process can be started; when any risk factor exists, the judgment of the risk factor can be stopped, the risk of the transaction can be determined to be higher, and a primary verification process can be started.

In order to improve the user experience, in this embodiment of the present specification, before starting the secondary verification process, the method may further include:

if the first position is inconsistent with the second position, acquiring equipment information, transaction counter-party information, transaction time information and transaction amount information related to the transaction request;

judging whether the transaction corresponding to the transaction request hits a strong wind control strategy or not according to the equipment information, the information of the counter party of the transaction, the information of the transaction time and the information of the transaction amount to obtain a second judgment result;

if the second judgment result is negative, starting the primary verification process;

and if the second judgment result is yes, starting the secondary verification process.

In this embodiment of the present specification, the strong wind control policy may be a risk determination rule set for determining whether a risk exists in a transaction under a certain condition, where the risk determination rule corresponding to the strong wind control policy may have more determination conditions than the risk determination rule corresponding to the weak wind control policy, and the related determination range is wider, and accuracy and comprehensiveness of risk determination are improved by determining a plurality of determination conditions.

Judging whether the transaction corresponding to the transaction request hits a strong wind control strategy specifically includes:

judging whether the equipment information hits equipment information wind control conditions or the information of the counter party hits the information wind control conditions of the counter party or the information of the transaction time hits the information wind control conditions of the transaction time or the information of the transaction amount hits the information wind control conditions of the transaction amount;

wherein the device information wind control conditions specifically include: the first terminal is any one of new equipment, unbound equipment and non-used equipment;

the trade counterparty information wind control condition specifically comprises the following steps: the transaction counter-party of the transaction is any one of a non-credible transaction counter-party and a non-historical transaction counter-party;

the transaction time information wind control conditions specifically include: the transaction time of the transaction is high-risk transaction time;

the transaction amount information wind control condition specifically comprises the following steps: whether the transaction amount of the transaction is a transaction amount outside a preset safe transaction amount form or not. In the embodiment of the present specification, whether a risk exists in a transaction corresponding to a transaction request may be determined from the aspects of device information, transaction counter-party information, transaction time information, transaction amount information, and the like.

In practical application, after the first position is determined to be inconsistent with the second position, whether the transaction hits the strong wind control strategy or not can be judged according to the preset priority sequence, the risk existing in the transaction request can be determined to be high as long as any risk factor in the strong wind control strategy is hit, a secondary verification process with a high security level needs to be started, the judgment of the risk factor can be stopped, the risk determination speed can be increased, the transaction request processing speed can be increased, and server resources can be saved. The following table 2 shows the priorities corresponding to the risk factors and the judgment results.

Priority level	Risk factors	The judgment result
			1	New equipment	The equipment is at risk
2	Equipment not in use	The equipment is at risk
			3	Non-binding device	The equipment is at risk
4	Untrusted counterparty	Risk to counterparty
			5	Non-historical transaction counter-parties	Risk to counterparty
6	High risk transaction time	Time of transaction is at risk
			7	Amount of abnormal transaction	The transaction amount is at risk

TABLE 2

In practical application, when the first position is inconsistent with the second position, in order to determine whether a high risk really exists in the transaction request, the risk condition in the transaction request can be judged according to the multidimensional risk factors. The risk judgment rules shown in table 2 can be obtained by adding risk judgment factors such as high-risk transaction time, abnormal transaction amount and the like on the basis of table 1. Through the risk judgment of multiple dimensions, whether high risk exists in the transaction request can be accurately judged, whether a secondary verification process is started is judged, the safety is ensured, meanwhile, the disturbance to the user can be reduced as much as possible, and the user experience is improved.

Some contents in table 2 can be referred to the description of table 1 above, and the description is not repeated here. The high-risk transaction time in table 2 may be a transaction time outside a preset time, for example, the user often performs transactions in the daytime, and the time of a certain transaction request is 3 am, and the transaction time of the transaction request may be considered as the high-risk transaction time; the abnormal transaction amount may be a transaction amount outside a preset amount rule, for example, in a normal case, the user rarely performs a transaction amount close to an integer, like 999.99, and when the transaction amount indicated in the transaction request is an amount close to an integer, the transaction time of the transaction request may be considered as the abnormal transaction amount.

In the embodiment of the specification, when any risk factor exists in the transaction request, it can be determined that the transaction request has higher risk and secondary verification with higher security level is required; when any risk factor does not exist in the transaction request, the transaction request can be determined to have lower risk, and primary verification with lower security level can be carried out.

It should be noted that the contents in table 1 and table 2 are only examples for clearly illustrating the contents in the embodiments of the present specification, and the risk judgment rule may be set according to actual needs, and is not limited herein.

Based on the above, the processing method of the transaction request provided in this specification can also be represented as the flowchart shown in fig. 3, and fig. 3 is a flowchart illustrating a processing method of the transaction request provided in an embodiment of this specification. As shown in fig. 3, in practical applications, the method in the embodiment of the present specification may include:

step 301, firstly, a user logs in an APP and initiates a transaction request; the user can log in the APP in the form of inputting an account number and a password, and after login is successful, the information inquiring whether the user authorizes to use the GPS positioning function can be displayed in the APP for the user to select whether the APP is authorized to use the GPS positioning function of the terminal.

Step 302: after the user logs in the APP or initiates a transaction request, the server can judge whether the user has the authority of using the GPS positioning function of the user terminal.

Step 303: after the user authorizes the APP to use the GPS positioning permission, the server can acquire the GPS position for sending the transaction request.

Step 304: the server may also determine the trusted location at the time the transaction request was received based on the user's historical information.

Step 305: based on the trusted location, the server may determine whether the acquired GPS location is consistent with the trusted location.

If the GPS location is consistent with the trusted location, it indicates that the transaction has a low risk probability, and further, as shown in step 308, it is determined whether the transaction corresponding to the transaction request hits the weak wind control policy.

When the transaction corresponding to the transaction request does not hit the weak wind control policy, it indicates that the probability of risk existing in the transaction is low, and in step 310, the server may start a primary verification process to prompt the user to perform primary verification with a low security level.

When the transaction hit weak wind control policy corresponding to the transaction request indicates that the probability of risk existing in the transaction is high, in step 311, the server may start a secondary verification process to prompt the user to perform secondary verification with a high security level.

Step 306: if the GPS position is inconsistent with the credible position, the GPS position and the mobile phone number corresponding to the user account can be sent to a communication operator;

step 307: the communication carrier can determine the second position of the terminal using the mobile phone number according to the mobile phone number, and can feed back the result whether the GPS position is consistent with the second position to the server.

If the server receives a feedback result indicating that the GPS location is consistent with the second location, in step 308, it is further determined whether the transaction corresponding to the transaction request hits the weak wind control policy.

If the feedback result received by the server indicates that the GPS location is inconsistent with the second location, as shown in step 309, it is further determined whether the transaction corresponding to the transaction request hits the strong wind control policy.

If the transaction corresponding to the transaction request does not hit the strong wind control policy, which indicates that the probability of risk existing in the transaction is low, the step 310 may be executed; if the transaction hit strong wind control strategy corresponding to the transaction request indicates that the probability of risk of the transaction is high, step 311 may be performed.

The above contents are mainly the processing process of the transaction request initiated by the user when the user is authorized to use the GPS positioning authority, the method in the embodiment of the specification can also be applied to the scene that the user is not authorized to use the GPS positioning authority,

when the user does not authorize the APP to use the GPS positioning function of the terminal, in step 312, the server may determine the IP location corresponding to the transaction request according to the IP address information carried in the transaction request.

The server may obtain a trusted location, as in step 304 above.

Step 313: based on the trusted location, the server may determine whether the obtained IP location is consistent with the trusted location.

If the IP location is consistent with the trusted location, indicating that the transaction is at risk with a low probability, the step shown in step 308 may be performed, and further, the step 310 or step 311 may be performed.

Step 314: if the IP position is inconsistent with the credible position, the IP position and the mobile phone number corresponding to the user account can be sent to a communication operator;

step 315: the communication carrier can determine the second position of the terminal using the mobile phone number according to the mobile phone number, and can feed back the result whether the IP position is consistent with the second position to the server.

If the server receives a feedback result indicating that the IP location is consistent with the second location, indicating that the transaction has a low risk probability, the step shown in the step 308 may be performed, and further, the step 310 or the step 311 may be performed.

If the server receives a feedback result indicating that the IP location is inconsistent with the second location, indicating that the transaction has a high risk probability, the step shown in step 309 may be performed, and further, the step 310 or step 311 may be performed.

In an embodiment of this specification, the obtaining of the trusted location corresponding to the user identifier may specifically include:

determining historical record information corresponding to the user identification based on the user identification;

obtaining an estimated credible position set based on the historical record information; the estimated credible position set comprises at least one estimated credible position;

determining the credibility of each estimated credible position based on the historical record information;

and determining the predicted credible position with the highest credibility as the credible position.

In practical application, a user logs in a certain APP for transaction, the server can record the login information, the transaction information and other contents of the user, and when the user does not perform transaction, the server can also record the time and duration of the account logging in the APP, the browsing information in the APP and the like.

The credibility can be understood as credibility and can be expressed into a specific numerical value form according to a preset mapping relation; the estimated trusted location set may be understood as a set of all locations appearing in the history information corresponding to the user identifier. The server can determine the reliability of each position according to a preset mapping relation, and determines the position with the highest reliability as a reliable position.

In this embodiment of the present specification, the history information may include history login information; the determining the reliability of each pre-estimated trusted location based on the history information may specifically include:

based on the historical login information, counting the historical login times of each estimated credible position;

and determining the credibility of each estimated credible position according to the historical login times.

In practical application, the server may count the historical login times corresponding to each estimated trusted location, and may determine the reliability of each estimated trusted location according to a relationship between the preset historical login times and the reliability. The historical login times may be historical times of successfully logging in the user account. Assuming that a user successfully logs in a certain mobile phone bank APP for 5 times at an address A, and the same user successfully logs in the mobile phone bank APP for 3 times at an address B, the reliability of the address A can be determined to be 5, and the reliability of the address B can be determined to be 3.

The history information may further include history login information, and the determining the reliability of each estimated trusted location based on the history information may specifically include:

counting the accumulated historical login time length of each estimated credible position based on the historical login information;

and determining the reliability of each estimated credible position according to the accumulated historical login time length.

In practical application, the server may count the cumulative historical login time length corresponding to each predicted trusted location, and may determine the reliability of each predicted trusted location according to a relationship between the preset cumulative historical login time length and the reliability. Assuming that the accumulated historical login time length of the user at the first address is 4 days, and the accumulated historical login time length of the user at the second address is 2, the reliability of the first address can be determined to be 4, and the reliability of the second address can be determined to be 2.

Wherein the historical record information may further include historical transaction information; the determining the reliability of each pre-estimated trusted location based on the history information specifically includes: based on the historical transaction information, counting the historical successful transaction times of each estimated credible position; and determining the credibility of each estimated credible position according to the historical successful transaction times.

In practical application, the server can also count the historical successful transaction times corresponding to each estimated credible position, and can determine the credibility of each estimated credible position according to the relationship between the preset historical successful transaction times and the credibility. Assuming that the historical successful transaction times of the user at the address A is 5 days, and the cumulative historical login time length at the address B is 2, the reliability of the address A can be determined to be 10, and the reliability of the address B can be determined to be 4.

Based on the above method for determining the credibility, in the embodiment of the present specification, the credibility of each estimated credible location may also be determined by comprehensively considering the historical login times, the accumulated historical login time length, and the historical successful transaction times in the historical record information. For example, the reliability of the estimated credible location is obtained by adding the reliability corresponding to the historical login times, the accumulated historical login time length and the historical successful transaction times. The method for determining the reliability may be set according to the requirement, and is not particularly limited herein.

In practical applications, the server may not have or have insufficient user history information, for example, when a newly registered user first logs in the APP to initiate a transaction, the server may only have the location information of the user logged in this time, and insufficient history information may not determine the trusted location of the user. In order to guarantee the user security more comprehensively, in this embodiment of the present specification, the acquiring a trusted location corresponding to the user identifier specifically includes:

when the history record information corresponding to the user identification does not exist;

acquiring registration information of the user based on the user identification; the registration information is information generated when the user registers in an application program corresponding to the server; the user identification is an identification which is distributed to the user of the application program by the server based on the registration information;

determining bank card information bound by the user in the application program based on the registration information;

determining a card issuing bank position based on the bank card information;

determining the issuer location as the trusted location.

In the implementation application, when a user registers as a user of an application program to perform a transaction, a bank card is generally bound first, the transaction is performed by means of a bank card account, and in order to effectively identify the transaction risk of a newly registered user, the position of an issuer can be determined as a trusted position. Wherein, the card issuer may be an issuer and may refer to an organization that issues bank cards.

In an embodiment of this specification, the obtaining a trusted location corresponding to the user identifier may specifically further include:

acquiring registration information of the user based on the user identification; the registration information is information generated when the user registers in an application program corresponding to the server; the user identification is a specific identification distributed to the server for the user of the application program based on the registration information;

determining information of a user residence provided by the user based on the bank card information;

determining the user residence as the trusted location.

In practical application, a user can fill in residence information when applying for a bank card, and when the user uses the bank card to initiate a transaction request on a certain transaction platform, the server can acquire the residence information filled in by the user according to a relevant protocol and determine the residence as a credible position.

In this embodiment, when the first location is not consistent with the trusted location, information indicating the first location may be sent to a communications carrier server, and location authentication may be performed by the communications carrier. To improve the accuracy of the risk determination, the trusted location may also be sent to the communications operator server for the communications operator server to determine whether the trusted location is consistent with the second location. For example, the determined card issuer location and/or user residence may be sent to the communications carrier server, and the communications carrier server may feed back to the server the result of whether the card issuer location and/or user residence is consistent with the second location. When the card issuing bank position is consistent with the second position, the card issuing bank position can be determined to be a credible position, and the credibility of the card issuing bank position can be correspondingly increased; when the place of residence coincides with the second location, the place of residence may be determined to be a trusted location, and the confidence of the place of residence may be increased accordingly.

In practical applications, when the issuer location and the residence belong to the same county or downtown, the issuer location and the residence may be considered to be the same, and either location may be sent to the communication carrier server for location authentication.

Based on the same idea, the embodiment of the present specification further provides a device corresponding to the above method. Fig. 4 is a schematic structural diagram of a processing device corresponding to a transaction request of fig. 2 according to an embodiment of the present disclosure. As shown in fig. 4, the apparatus may include:

a transaction request obtaining module 402, configured to obtain a transaction request sent by a first terminal; the transaction request carries a user identifier and a position identifier of the first terminal;

a first location determining module 404, configured to determine a first location corresponding to the location identifier;

a to-be-positioned information sending module 406, configured to send to-be-positioned information including at least a mobile phone number corresponding to the user identifier to a communication operator server, where the to-be-positioned information is used to determine a second location of a terminal that uses a user identification card corresponding to the mobile phone number;

a positioning result receiving module 408, configured to receive a first positioning result returned by the communication operator server;

a position determining module 410, configured to determine whether the first position is consistent with the second position based on the first positioning result;

a primary verification starting module 412, configured to start a primary verification process if the first location is consistent with the second location;

a secondary verification starting module 414, configured to start a secondary verification process if the first location is inconsistent with the second location; the security level of the secondary verification process is higher than that of the primary verification process.

The apparatus in this specification may further include:

the trusted position acquisition module is used for acquiring a trusted position corresponding to the user identifier; the credible position is used for representing a common position of the user terminal carrying the user identification;

the position judging module is used for judging whether the first position is consistent with the credible position or not to obtain a second positioning result;

the information sending module to be positioned is specifically configured to send information to be positioned, which at least includes the mobile phone number corresponding to the user identifier, to a communication operator server if the second positioning result indicates that the first position is inconsistent with the trusted position.

The primary verification starting module 412 may be further configured to:

The location identifier may include an identifier indicating GPS positioning information, the first location may specifically be a GPS positioning location determined by the GPS positioning information of the first terminal, and the first location determining module 404 may specifically be configured to:

acquiring authority information of the first terminal;

In this embodiment of the present description, the location identifier may further include an identifier indicating IP address information, where the first location may specifically be an IP location corresponding to the IP address information of the first terminal, and the first location determining module 404 may be further configured to:

The apparatus in this embodiment of the present specification may further include a first risk determination module, configured to:

The apparatus in this embodiment of the present specification may further include a second risk determination module, configured to:

The trusted location obtaining module may be specifically configured to:

and determining the predicted credible position with the highest credibility as the credible position. .

Based on the same idea, the embodiment of the present specification further provides a device corresponding to the above method.

Fig. 5 is a schematic structural diagram of a transaction information processing device corresponding to fig. 2 provided in an embodiment of the present specification. As shown in fig. 5, the apparatus 500 may include:

at least one processor 510; and the number of the first and second groups,

a memory 530 communicatively coupled to the at least one processor; wherein the content of the first and second substances,

the memory 530 stores instructions 520 executable by the at least one processor 510 to enable the at least one processor 510 to:

determining a first position corresponding to the position identification;

if the two are consistent, starting a primary verification process;

Based on the same idea, the embodiment of the present specification further provides a computer-readable medium corresponding to the above method. The computer readable medium has computer readable instructions stored thereon that are executable by a processor to implement the method of:

determining a first position corresponding to the position identification;

if the two are consistent, starting a primary verification process;

The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. For example, as for the processing device of the transaction request shown in fig. 4, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant points can be referred to the partial description of the method embodiment.

In the 90 s of the 20 th century, improvements in a technology could clearly distinguish between improvements in hardware (e.g., improvements in circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements in process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by a user. A digital character system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate a dedicated integrated circuit chip. Furthermore, nowadays, instead of manually making an integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development and writing, but the original code before compiling is also written by a specific Programming Language, which is called Hardware Description Language (HDL), and HDL is not only one but many, such as abel (advanced Boolean Expression Language), ahdl (alternate Language Description Language), traffic, pl (core unified Programming Language), HDCal, JHDL (Java Hardware Description Language), langue, Lola, HDL, laspam, hardsradware (Hardware Description Language), vhjhd (Hardware Description Language), and vhigh-Language, which are currently used in most common. It will also be apparent to those skilled in the art that hardware circuitry that implements the logical method flows can be readily obtained by merely slightly programming the method flows into an integrated circuit using the hardware description languages described above.

The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, and an embedded microcontroller, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic for the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller as pure computer readable program code, the same functionality can be implemented by logically programming method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Such a controller may thus be considered a hardware component, and the means included therein for performing the various functions may also be considered as a structure within the hardware component. Or even means for performing the functions may be regarded as being both a software module for performing the method and a structure within a hardware component.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

For convenience of description, the above devices are described as being divided into various units by function, and are described separately. Of course, the functionality of the units may be implemented in one or more software and/or hardware when implementing the present application.

As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Disks (DVD) or other optical storage, magnetic cassettes, magnetic tape disk storage or other magnetic storage devices, or any other non-transmission medium which can be used to store information which can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The application may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The application may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

The above description is only an example of the present application and is not intended to limit the present application. Various modifications and changes may occur to those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

Claims

1. A method of processing a transaction request, comprising:

determining a first position corresponding to the position identification;

if the two are consistent, starting a primary verification process;

2. The method of claim 1, before sending the information to be located, which includes at least the mobile phone number corresponding to the user identifier, to a communication operator server, further comprising:

3. The method of claim 2, after obtaining the second positioning result, further comprising:

4. The method according to claim 1, wherein the location identifier includes an identifier indicating GPS positioning information, the first location is specifically a GPS positioning location determined by the GPS positioning information of the first terminal, and the determining the first location corresponding to the location identifier specifically includes:

acquiring authority information of the first terminal;

5. The method according to claim 4, wherein the location identifier includes an identifier indicating IP address information, the first location is specifically an IP location corresponding to the IP address information of the first terminal, and after determining whether the server has a right to use a GPS positioning function of the first terminal, the method further includes:

6. The method of claim 1, before initiating the primary authentication procedure, further comprising:

7. The method according to claim 6, wherein the determining whether the transaction corresponding to the transaction request hits the weak wind control policy specifically includes:

the trade counterparty information wind control condition specifically comprises the following steps: the transaction counter-party of the transaction is any one of a non-trusted transaction counter-party and a non-historical transaction counter-party.

8. The method of claim 1, before initiating the secondary authentication procedure, further comprising:

9. The method according to claim 8, wherein the step of determining whether the transaction corresponding to the transaction request hits a strong wind control policy specifically comprises:

the transaction amount information wind control condition specifically comprises the following steps: whether the transaction amount of the transaction is a transaction amount outside a preset safe transaction amount form or not.

10. The method according to claim 2, wherein the obtaining of the trusted location corresponding to the user identifier specifically includes:

11. The method of claim 10, wherein the history information comprises historical login information; the determining the reliability of each pre-estimated trusted location based on the history information specifically includes:

12. The method of claim 10, wherein the historical information includes historical login information, and the determining the confidence level of each of the predicted trusted locations based on the historical information specifically includes:

13. The method of claim 10, wherein the historical information comprises historical transaction information; the determining the reliability of each pre-estimated trusted location based on the history information specifically includes:

based on the historical transaction information, counting the historical successful transaction times of each estimated credible position; and determining the credibility of each estimated credible position according to the historical successful transaction times.

14. The method according to claim 2, wherein the obtaining of the trusted location corresponding to the user identifier specifically includes:

determining a card issuing bank position based on the bank card information;

determining the issuer location as the trusted location.

15. The method according to claim 2, wherein the obtaining of the trusted location corresponding to the user identifier specifically includes:

determining the user residence as the trusted location.

16. A transaction request processing apparatus comprising:

a positioning result receiving module, configured to receive a first positioning result returned by the communication operator server;

17. The apparatus of claim 16, further comprising:

18. The apparatus of claim 17, the primary authentication initiation module further configured to:

19. The apparatus of claim 16, wherein the location identifier comprises an identifier indicating GPS positioning information, the first location is specifically a GPS positioning location determined by the GPS positioning information of the first terminal, and the first location determining module is specifically configured to:

acquiring authority information of the first terminal;

20. The apparatus of claim 19, wherein the location identifier includes an identifier indicating IP address information, the first location is specifically an IP location corresponding to the IP address information of the first terminal, and the first location determining module is further configured to:

21. The apparatus of claim 16, further comprising a first risk assessment module configured to:

22. The apparatus of claim 16, further comprising a second risk assessment module configured to:

23. The apparatus of claim 17, wherein the trusted location acquisition module is specifically configured to:

24. A transaction request processing device, comprising:

at least one processor; and the number of the first and second groups,

determining a first position corresponding to the position identification;

if the two are consistent, starting a primary verification process;