System for jointly managing risk of commercial transaction

Abstract

The present invention relates to a system for integrally and jointly managing the risk of a commercial transaction and, more specifically, to a system for jointly managing the risk of a commercial transaction, in which a plurality of companies (e.g., installment companies, rental companies, etc.) are implemented to, under an agreement, jointly cross-verify the status of a commercial transaction contract managed by each company in an encrypted manner so as to analyze the risk of a commercial transaction, and then provide a risk analysis result to a company that has requested a commercial transaction risk analysis without exposing detailed commercial transaction information including customer personal information, target company information, and the like, thereby enabling detection of the risk of the commercial transaction, which may be caused by a target customer, and provision of same to the requesting company in a timely manner.

Description

Joint Commercial Risk Management System

[0001] The present invention relates to a system for comprehensively and jointly managing transaction risks, and more particularly, to a transaction risk joint management system in which a plurality of companies (e.g., installment companies, rental companies, etc.) jointly, through agreement, cross-verify the status of transaction contracts managed by each company in an encrypted manner to analyze transaction risks, and then provide the risk analysis results to a company that has requested a transaction risk analysis without exposing detailed transaction information including customer personal information and target company information, thereby detecting transaction risks that may occur by target customers and providing the results to the requesting company in a timely manner.

[0002] The term "commerce" as used herein refers to commerce excluding financial transactions, i.e., commerce for the purpose of trading goods, including transactions related to the purchase or rental of physical goods. It primarily includes transactions where a customer pays for a product in installments or enters into a rental contract, and a company agrees to deliver and / or install the product ordered by the customer. In the past, commerce primarily took place in offline stores such as department stores or rental shops. However, recently, commerce has become predominantly conducted through online commerce platforms such as TV home shopping, Naver Store, Gmarket, and 11st. The well-established network of nationwide courier companies such as Daehan Transportation, Logen Express, and Korea Post, as well as small and medium-sized logistics centers, is also a driving force behind the vibrancy of these online commerce platforms.

[0003] Meanwhile, when customers cannot afford to purchase expensive products in full, they often want to purchase or rent them through installments or rentals, often referred to as deferred payment. To meet these needs, companies are offering various installment and rental models. For example, when signing up for a mutual aid association, the cost of the product is included in the monthly installment, allowing both the mutual aid service and the product to be sold in installments simultaneously. When a bank card is issued, a portion of the product installment is refunded if the card is used over a certain amount each month. Furthermore, a rental model allows customers to pay installments, use the product, and then transfer ownership of the product at the end of the contract period. These models vary widely.

[0004] However, as these various post-payment transactions become more prevalent, fraud cases in which payment is not made after receiving the product intentionally occur, and recently, even fraud cases (so-called rental gangs) in which a specific customer intensively creates a large number of contracts with different companies over a short period of time have been occurring.

[0005] For example, as shown in Figure 11, there are cases of fraud where a customer uses a location other than his / her actual residence, such as a sports field, prison, or parking lot, or a rented officetel or studio apartment, as the delivery address for products while engaging in postpaid transactions with multiple companies within a short period of time. When discovered, the customer changes the delivery address to another and resumes postpaid transactions with other companies.

[0006] In particular, in cases of intentional and organized fraud, the contract holders are often homeless, have lost their cell phones, or have had their personal information stolen during the account opening process. This has become a social problem in which fraudulent organizations obtain personal information from the poor and have a large number of illegal transactions.

[0007] In addition, in order to secure the cost required for manufacturing a product, there are cases where a company (e.g., Company C) transfers the installment receivable for the purchase of a product to a financial institution and enters into a contract for assignment of receivables to receive the receivable transfer price. Therefore, if a situation like the above occurs after the assignment of receivables, the loss is passed on to not only the company but also the financial institution that received the installment receivable.

[0008] In order to prevent such illegal commercial transactions, it would be an effective alternative for companies such as installment companies and rental companies to mutually agree to cross-check the status of each company's commercial transaction contracts to analyze the commercial transaction risk, and then use the analysis results to check the commercial transaction risk with customers in advance, and allow the commercial transaction contract to be canceled before product delivery depending on the risk level, thereby preventing unexpected damage to companies in advance.

[0009] However, in the process of cross-checking the transaction contract status of each company, there may be secondary problems that may arise where corporate information or transaction details held by each company are excessively exposed to other companies, and there is also the problem of violating the Personal Information Protection Act by exposing customers' personal information without their consent. Therefore, the need to devise a method to resolve this is being raised.

[0010] The present invention aims to solve the above problem by providing the results of a transaction risk analysis for each customer without exposing detailed transaction information including customer personal information and target company information.

[0011] In addition, the present invention aims to provide a quantified transaction risk figure for each customer's transaction risk so that the transaction risk of each customer can be intuitively identified and compared.

[0012] In addition, the present invention aims to very quickly derive the results of a transaction risk analysis for each customer, so as to notify the customer of any significant changes in the transaction risk level before the completion of payment, such as delivery of goods, after the conclusion of a transaction contract.

[0013] In order to achieve the above object, the transaction risk joint management system according to the present invention is a transaction risk joint management system including corporate servers of corporate entities that have joined a joint management alliance and a joint management solution server that is connected thereto and provides transaction risk information, wherein the corporate server transmits a transaction risk analysis request message including encrypted data of a customer to be queried to the joint management solution server, the joint management solution server transmits a transaction status information request message including the encrypted data to a plurality of corporate servers that have joined the joint management alliance, and the plurality of corporate servers each generate corporate response data and transmits the data to the joint management solution server.

[0014] In addition, the joint management solution server is characterized in that it collects the corporate response data from the plurality of corporate servers to generate transaction risk information, and provides the generated transaction risk information to the corporate server that sent the transaction risk analysis request message.

[0015] In addition, each of the plurality of corporate servers applies one-way encryption technology to generate encrypted data for certain key information among the detailed transaction information of its own customers, and stores the generated encrypted data in its own database.

[0016] In addition, the plurality of corporate servers are characterized in that they compare the encrypted data included in the transaction status information request message with the encrypted data stored in their own database to generate the corporate response data including the number of contracts with the customer to be queried and whether or not they are in arrears.

[0017] In addition, the transaction risk information generated by the joint management solution server is characterized in that it is implemented as numerical data quantifying the number of contracts and delinquency included in the corporate response data from each corporate server.

[0018] In addition, the corporate server transmits an inquiry notification service application message including encrypted data for a specific customer and a predetermined inquiry period to the joint management solution server, and in response thereto, the joint management solution server determines whether a transaction risk analysis request message including the encrypted data as the subject of inquiry is received from the other corporate server during the inquiry, and upon detecting receipt, transmits an inquiry notification message for the specific customer to the corporate server.

[0019] In addition, the above-mentioned key information is characterized in that it includes at least one of one-way encrypted pseudonym data, pseudonym number data, and pseudonym delivery address data.

[0020] In addition, the above-mentioned transaction risk information is characterized by reflecting an additional value according to the estimated number of contracts held based on the encrypted data of the customer subject to inquiry included in the corporate response data from each of the above-mentioned companies in the above-mentioned numerical data.

[0021] In addition, the numerical data is characterized in that it is calculated by collecting all of the corporate response data from the plurality of corporate servers, distinguishing between normal contracts and overdue contracts for contracts within a recent predetermined period among the commercial contracts of the customer to be queried included in each corporate response data, normal contracts and overdue contracts for contracts outside the aforementioned period, and assigning different values ​​to each contract, and adding up the values ​​assigned to each contract.

[0022] In addition, the encrypted data includes at least one of one-way encrypted pseudonym data, pseudonym number data, and pseudonym delivery address data, and the numerical data is characterized in that the value is assigned by giving a weight to a commercial transaction contract of the customer to be searched that overlaps two or more of the pseudonym data, the pseudonym number data, and the pseudonym delivery address data.

[0023] Through the above-described solution, the joint transaction risk management system according to the present invention provides the following effects.

[0024] According to the present invention, it is possible to provide the results of a transaction risk analysis for each customer without exposing detailed transaction information including customer personal information and target company information.

[0025] In addition, according to the present invention, it is possible to provide a quantified transaction risk value for each customer so that the transaction risk of each customer can be intuitively identified and compared.

[0026] In addition, according to the present invention, the results of the transaction risk analysis for each customer can be derived very quickly, so that if there is a significant change in the transaction risk value of the customer before the delivery of goods or other payments are completed after the conclusion of the transaction contract, the customer can be notified.

[0027] Figure 1 is a schematic diagram of a joint transaction risk management system according to one embodiment of the present invention.

[0028] FIG. 2 is an example diagram of encrypted data used in a transaction risk joint management system according to one embodiment of the present invention.

[0029] Figure 3 is a flowchart of a method for jointly managing transaction risks according to one embodiment of the present invention.

[0030] Figures 4 to 6 are examples of response data of a joint transaction risk management system according to one embodiment of the present invention.

[0031] FIG. 7 is an example diagram of a transaction risk calculation rule of a transaction risk joint management system according to one embodiment of the present invention.

[0032] Figure 8 is an example diagram of an estimated number of holding contracts addition rule of a joint transaction risk management system according to one embodiment of the present invention.

[0033] Figure 9 is an example diagram of a transaction risk calculation case of a transaction risk joint management system according to one embodiment of the present invention.

[0034] FIG. 10 is an example diagram of a transaction risk inquiry notification service of a transaction risk joint management system according to one embodiment of the present invention.

[0035] Figure 11 is an example diagram illustrating a typical commercial risk case.

[0036] The advantages and features of the invention, and the methods for achieving them, will become clearer with reference to the embodiments described in detail below together with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below and may be implemented in various different forms. These embodiments are provided only to ensure that the disclosure of the present invention is complete and to fully inform those skilled in the art of the scope of the invention, and the present invention is defined only by the scope of the claims. Like reference numerals designate like elements throughout the specification.

[0037] The terminology used herein is merely used to describe specific embodiments and is not intended to limit the present invention. The singular expressions include plural expressions unless the context clearly indicates otherwise. In this specification, it should be understood that the terms "comprises" or "has" indicate the presence of a feature, number, step, operation, component, part, or combination thereof described in this specification, but do not preclude the possibility of the presence or addition of one or more other features, numbers, steps, operations, components, parts, or combinations thereof.

[0038] In this specification, terms such as "part" or "device" are intended to refer to a combination of hardware and software driven by the hardware. For example, the hardware may be a data processing device including a CPU or other processor. Furthermore, the software driven by the hardware may refer to a running process, object, executable, thread of execution, program, etc.

[0039] Hereinafter, the configuration and operation of a joint risk management system according to one embodiment of the present invention will be described with reference to the attached drawings.

[0040] Figure 1 is a schematic diagram of a joint transaction risk management system according to one embodiment of the present invention.

[0041] Referring to FIG. 1, the transaction risk joint management system includes corporate servers (110, 120, 130) of corporations that have joined a predetermined alliance for joint management of transaction risks (wherein the corporate server is a concept including a database (DB)) and a joint management solution server (400) that provides transaction risk information for corporations through API communication.

[0042] An API (Application Programming Interface) is an interface that allows applications to control the functions provided by an operating system or programming language. An API is a method for exchanging data between applications. In the present invention, it is implemented as a private API that provides information only to authorized users. API communication uses HTTPS to send request messages and defines the structure of response messages. These response messages can be in the form of XML or JSON files, for example.

[0043] The corporate servers (110, 120, 130) store information regarding commercial transactions entered into between each company and its customers. Each company is a similar company that handles commercial transactions, such as installment or rental contracts, or at least possesses similar commercial transaction information. These companies have mutually agreed to use the shared management solution server.

[0044] The corporate servers (110, 120, 130) do not directly exchange or share detailed transaction information with each other, and only grant the joint management solution server (400) the authority to partially use the transaction information. The corporate servers (110, 120, 130) provide the transaction information provided to the joint management solution server (400) in the form of encrypted data by one-way encrypting it.

[0045] FIG. 2 is an example diagram of encrypted data used in a transaction risk joint management system according to one embodiment of the present invention.

[0046] When a customer enters into a deferred payment transaction agreement with a company (e.g., rental, installment, or bundled product purchase) and purchases a product, the company stores the details of the transaction agreement as detailed transaction information in a database on its corporate server (110, 120, 130). This detailed transaction information may include the customer's name, date of birth, gender, delivery address, mobile phone number, order number, order date, contract date, transaction status, transaction amount, and delivery status.

[0047] Each corporate server (110, 120, 130) generates encrypted data by one-way encrypting only the information to be provided to the joint management solution server (400) among the detailed transaction information. The encrypted data mainly includes pseudonymized data that encrypts the customer's name (and in some cases, further including the date of birth and / or gender), pseudonymized delivery address data that encrypts the delivery address, and pseudonymized number data that encrypts the mobile phone number.

[0048] The corporate server stores encrypted data, such as pseudonymized data, pseudonymized shipping address data, and pseudonymized number data, generated using one-way encryption in specific data fields of the detailed transaction information database. Depending on the embodiment, other types of information may also be included in the encrypted data.

[0049] One-way encryption is an undecipherable encryption method. It uses a function, such as a hash function, to convert data of arbitrary length into data of fixed length to generate encrypted data. Accordingly, even if the length of the input value varies, the output value always has a fixed length. In the case of Fig. 2, the lengths of the original data, such as the customer's name / date of birth / name, delivery address data, and mobile phone number data, are all different, but the length of the encrypted data is the same, for example, A001, B001, and C001.

[0050] Since encrypted data cannot be decrypted, the original transaction information cannot be found out or guessed by only knowing the encrypted data, and thus detailed transaction information including customer personal information and corporate information is not exposed externally. In addition, since it uses fixed-length data with small capacity, it is easy to find duplicate records in large files, which can accelerate database search speed. In addition, since the same result value is always output when the same value is input, it can also be used to check for data tampering by an intermediary.

[0051] Figure 3 is a flowchart of a method for jointly managing transaction risks according to one embodiment of the present invention.

[0052] In FIG. 3, the joint management solution server (400) transmits and receives only encrypted data with each corporate server (110, 120, 130).

[0053] When a corporate server (110) transmits a transaction risk analysis request message containing encrypted data of a customer who wishes to inquire to a joint management solution server (400) (step 1), the joint management solution server (400) transmits a transaction status information request message containing the encrypted data of the customer to the servers (110, 120, 130) of each company that has joined the joint management alliance (steps 2-1, 2-2, 2-3).

[0054] Each corporate server (110, 120, 130) compares the encrypted data with the encrypted data stored in the detailed transaction information database to determine whether there is a match, and uses the matched data to generate corporate response data and transmits a response message to the joint management solution server (400) (steps 3-1, 3-2, 3-3).

[0055] The joint management solution server (400) quantitatively calculates the customer's transaction risk information based on the corporate response data included in the response message from each corporate server (110, 120, 130) and transmits it to the corporate server (110) of corporate A that requested the inquiry.

[0056] Afterwards, the A company server (110) performs follow-up actions such as concluding or rejecting a commercial transaction contract with the customer based on the customer's commercial transaction risk information.

[0057] Meanwhile, unlike in FIG. 3, the joint management solution server (400) may not send a transaction status information request message to the A company server (110) that requested the inquiry, but may request transaction status information only from other company servers (120, 130), and may collect the corresponding response messages to calculate transaction risk information for the corresponding customer and transmit it to the A company server (110). Alternatively, the A company server (110) may consider both the transaction risk information from the joint management solution server (400) and the data stored in its own detailed transaction information database to generate separate transaction risk information on its own and use it for transactions.

[0058] Figures 4 to 6 are examples of response data of a joint transaction risk management system according to one embodiment of the present invention.

[0059] As described in Figure 2, each corporate server stores encrypted data such as pseudonymized data, pseudonymized shipping address data, and pseudonymized number data created using one-way encryption in specific data fields of the detailed transaction information database.

[0060] Referring to FIG. 4, when a transaction status information request message including encrypted data (e.g., A002 / B002 / X003) for a specific customer is sent from the joint management solution server (400) to Company A, Company A compares the encrypted data stored in the detailed transaction information database and extracts the matching encrypted data (i.e., A002, B002).

[0061] A corporate server (110) derives data on the number of contracts and delinquency by distinguishing one pseudonym data (A002) and one pseudonym number data matching in its own detailed transaction database into related full contracts and recent contracts (or, depending on the embodiment, general contracts from 3 months ago and recent contracts within 3 months), and using this, generates response data on the number of contracts and delinquency by dividing them into individual items and combined items combining multiple individual items as shown in FIG. 4, and transmits this to the joint management solution server (400).

[0062] In response to a transaction status information request message received from the joint management solution server (400), the B company server (120) searches its own transaction information database for the same encrypted data (i.e., A002 / B002 / X003), extracts the matching encrypted data (i.e., A002, B002), and accordingly generates response data as shown in FIG. 5 and transmits it to the joint management solution server (400).

[0063] The C company server (130) also generates response data as shown in FIG. 6 in response to the same transaction status information request message and transmits it to the joint management solution server (400).

[0064] Depending on the embodiment, response data may be generated that includes items other than the number of contracts and whether or not they are overdue, or response data may be generated that sets a different criteria time period for distinguishing the number of contracts.

[0065] FIG. 7 is an example diagram of a transaction risk calculation rule of a transaction risk joint management system according to one embodiment of the present invention.

[0066] The production rules in Figure 7 are generated based on the exemplary criteria score table below.

[0067] Encrypted data combination formula: Normal, unpaid, overdue, overdue, general, recent, general, recent, general, recent, pseudonym AND pseudonym number AND pseudonym delivery address 12241729144576 pseudonym AND pseudonym number 918142381324 pseudonym 510101525100 pseudonym number 489131664 pseudonym delivery address 36811936

[0068] In the example illustrated in FIG. 7, 'general' is assumed to be a contract from 3 months ago from the current date, for example, and 'recent' is assumed to be a contract from within 3 months ago from the current date. First, let's explain with a focus on 'general' contracts that are normal cases (i.e., commercial contracts with no overdue or late payments, etc., as of the time of inquiry). If the 'pseudonym' data matches, a standard score of, for example, 5 points is given. If the 'pseudonym number' data matches, a standard score of, for example, 4 points is given, which is 1 point less than the standard score. If the 'pseudonym delivery address' data matches, a standard score of, for example, 2 points is given, which is 3 points. If both the 'pseudonym' and the 'pseudonym number' data match, the scores given to the 'pseudonym' and the 'pseudonym number' are combined to give 9 points. If the 'pseudonym', 'pseudonym number', and 'pseudonym delivery address' data all match, the scores given to each are combined to give 12 points.

[0069] Additionally, the score of a "recent" contract in a normal case is, for example, double the score of a "normal" contract. This is because the more recent the contract, the higher the transaction risk.

[0070] Meanwhile, the scores for "Normal" and "Recent" contracts for unpaid transactions (i.e., commercial transactions for which installments, etc. have not been paid at least once as of the time of inquiry) are given by adding, for example, 5 points to the scores for "Normal" and "Recent" contracts for normal transactions. Unpaid transactions mean that one or more payments have not been made, and this unpaid contract status indicates a higher commercial transaction risk for the customer than a normal contract status.

[0071] Lastly, the scores for 'normal' and 'recent' contracts for overdue transactions (i.e., commercial contracts with overdue payments of three or more installments as of the time of inquiry) are given as the square of the scores for 'normal' contracts and 'recent' contracts for normal transactions. Overdue transactions mean that payments have not been made three or more times, and the scores intuitively show that this overdue contract status carries a much higher commercial risk than a normal contract status. Overdue transactions are not simply added to the score, but are set to increase the score exponentially. For this reason, compared to the combined scores for cases where overdue transactions occur based on the data for 'pseudonym', 'pseudonym number', and 'pseudonym delivery address', the score for overdue transactions when two or all three pieces of information match is calculated to be much higher.

[0072] Figure 8 is an example diagram of an estimated number of contracts held by a joint management system for transaction risk according to one embodiment of the present invention.

[0073] As the number of commercial contracts entered into by the same customer with multiple companies increases, the commercial risk tends to increase. Therefore, in order to reflect the additional risk caused by customers entering into multiple commercial contracts within a certain period of time, for example, as shown in Figure 8, the number of contracts presumed to be from the same person, that is, the estimated number of contracts held, can be calculated separately based on the ‘pseudonymous’ data, and the risk can be adjusted by assigning a bonus rate (or weight) to each number of contracts.

[0074] For example, the estimated number of contracts held can be calculated based on "pseudonym" data. A higher premium rate is assigned as the total number of contracts increases. The premium rate can be implemented to increase rapidly when the number of contracts exceeds a critical number (5 in Figure 8). For even more stable risk management, the premium rate can be increased rapidly based on a lower number of contracts.

[0075] In the example in Figure 8, the score was calculated by multiplying the number of estimated holding contracts by the baseline score of 12, multiplying by 2 if there were recent contracts (within 3 months), and then multiplying by (1 + number of estimated holding contracts / 10). If the number of estimated holding contracts was 5 or more, the score was then multiplied by (5 + number of estimated holding contracts / 10). Furthermore, in the example in Figure 8, the final score for each case was rounded to the nearest whole number for convenience of calculation.

[0076] Figure 9 is an example diagram of a transaction risk calculation case of a transaction risk joint management system according to one embodiment of the present invention.

[0077] Figure 9 illustrates an example of calculating a transaction risk level in a joint management solution server (400) by receiving response data from companies A, B, and C illustrated in Figures 4 to 6. The response data from companies A, B, and C are transmitted to the joint management solution server (400) with information such as the company names deleted, and are stored with the information of the companies deleted, as in response data 1, 2, and 3.

[0078] The joint management solution server (400) calculates a transaction risk score by integrating the transaction response data of all companies belonging to the joint management alliance by applying, for example, the transaction risk calculation rule described in FIG. 7 (however, the unpaid portion is omitted for convenience of calculation) and the estimated number of contracts added rule described in FIG. 8, and, if necessary, calculates a final transaction risk score by applying the estimated number of contracts added rule.

[0079] For example, 100 points are awarded for one recent overdue transaction with matching 'pseudonym' data, 10 points for one recent normal transaction with matching 'pseudonym' data, and 5 points for one normal transaction out of two transactions with matching 'pseudonym' data, excluding the most recent one. In addition, 64 points are awarded for one recent overdue transaction with matching 'pseudonym number' data, and 8 points are awarded for one recent normal transaction with matching 'pseudonym number' data. In addition, 12 points are awarded for two recent normal transactions with matching 'pseudonym delivery address' data. In addition, 324 points are awarded for one recent overdue transaction with matching 'pseudonym' and 'pseudonym number' data, and 18 points are awarded for one recent normal transaction with matching 'pseudonym' and 'pseudonym number' data. The total score calculated in this way is 541 points.

[0080] If there is one recent overdue transaction where the 'pseudonym', 'pseudonym number', and 'pseudonym delivery address' all match, 100 points will be awarded for the 'pseudonym' section, 64 points for the 'pseudonym number' section, and 36 points for the 'pseudonym delivery address' section. Then, an additional 324 points will be awarded for the matching 'pseudonym' and 'pseudonym number', and finally, an additional 576 points will be awarded for the matching 'pseudonym', 'pseudonym number', and 'pseudonym delivery address', resulting in a total of 1,100 points for just one risky transaction.

[0081] In Fig. 9, no additional points were awarded for the combination of 'pseudonym' and 'pseudonym delivery address' data, or the combination of 'pseudonym number' and 'pseudonym delivery address' data, as they were deemed to have a relatively low impact on risk. However, additional points may be awarded depending on the application case.

[0082] The key here is to structure the score so that more than one data item matches and the more duplicates there are, the more rapidly the score increases, which optimally reflects the reality that transaction risk increases sharply in such cases.

[0083] When applying the addition rule according to the estimated holding contract in Fig. 9, as in the example of Fig. 8, the number of estimated holding contracts (3) is multiplied by the reference score of 12, and since there is a recent contract (within 3 months), it is multiplied by 2, and then (1 + number of estimated holding contracts (3) / 10)) is multiplied to obtain 93.6, which is then rounded up to obtain the addition score of 94.

[0084] Through the above process, the management solution server (400) returns the calculated total transaction risk index (e.g., 635 points in the case of FIG. 9) to the A company server (110) that requested the inquiry. At this time, the joint management solution server (400) may divide the score into multiple sections and return the score in combination with indicators such as 'serious / alert / caution / concern / normal' and / or colors such as 'red / vermilion / orange / yellow / green'.

[0085] FIG. 10 is an example diagram of a transaction risk inquiry notification service of a transaction risk joint management system according to one embodiment of the present invention.

[0086] Company A can proceed with a contract with the customer by referring to the transaction risk index of Figure 9, and can apply for an inquiry notification service to the joint management solution server (400) to check in real time whether an inquiry on the transaction risk of another company for the same customer occurs during the progress of the contract with the customer (e.g., after contract conclusion and before product delivery is completed).

[0087] Referring to FIG. 10, the A company server (110) may generate encrypted data through one-way encryption for a customer named 'Hong Gil-dong' (or extract the customer's encrypted data stored in the detailed transaction database), and then set a retention period (or inquiry period) to transmit an inquiry notification service request message to the joint management solution server (400) to request an inquiry notification service to determine whether a transaction risk analysis request message from another company for the customer is received. In response, the joint solution management server (400) may determine whether a transaction risk analysis request message from another company that includes encrypted data that is the subject of the inquiry is received during the set retention period or inquiry period, and may transmit an inquiry notification message to the A company server (110) when an inquiry is detected (and / or transmit an inquiry notification text message to a person in charge of A company).

[0088] For rental or installment transactions, it may take several days for the product to be delivered even after the contract is signed. Therefore, if each company receives an inquiry notification before delivery, it can stop the delivery process and re-examine the commercial contract with the customer in question.

[0089] According to this embodiment, in addition to assessing the transaction risk at the time of transaction, if the transaction risk increases during the contract performance process after concluding a transaction contract and up to the point of completion of delivery, the change in the transaction risk can be provided to the company.

[0090] Although the present invention has been described above with specific details such as specific components and limited examples and drawings, these are provided only to help a more general understanding of the present invention, and the present invention is not limited to the above examples, and those with ordinary knowledge in the technical field to which the present invention pertains can attempt various modifications and variations from this description.

[0091] For example, when heterogeneous companies such as home appliance rental companies and car finance companies join a joint management alliance and collaborate to cross-verify encrypted contract information; when online shopping malls and logistics companies collaborate to encrypt and cross-verify customer order history to detect order fraud or abnormally large orders; when insurance companies and hospitals collaborate to encrypt and cross-verify customer medical records to detect duplicate or fraudulent claims; when heterogeneous financial institutions such as banks and credit card companies encrypt and cross-verify customer contract information; and when car sharing service platforms and accommodation sharing service platforms encrypt and cross-verify customer transaction information. These can be expanded and utilized in various ways.

[0092] Therefore, the idea of ​​the present invention is not limited to the embodiments described above, and the scope of patent rights for the present invention should be considered to extend to the invention described in the patent claims and inventions that are equally or equivalently modified therefrom.

Claims

1. A transaction risk joint management system including a corporate server of companies that have joined a joint management association and a joint management solution server that provides transaction risk information connected thereto. The corporate server transmits a transaction risk analysis request message containing the encrypted data of the customer to be queried to the joint management solution server, The above joint management solution server transmits a transaction status information request message including the encrypted data to multiple corporate servers that have joined the joint management association, The above multiple corporate servers each generate corporate response data and transmit it to the joint management solution server. Joint risk management system for commercial transactions.

2. In claim 1, The above joint management solution server collects the corporate response data from the multiple corporate servers to generate transaction risk information, and provides the generated transaction risk information to the corporate server that sent the transaction risk analysis request message. Joint risk management system for commercial transactions.

3. In claim 2, Each of the above multiple corporate servers applies one-way encryption technology to create encrypted data for certain key information among the detailed transaction information of its own customers, and stores the created encrypted data in its own database. Joint risk management system for commercial transactions.

4. In claim 3, The above multiple corporate servers compare the encrypted data included in the transaction status information request message with the encrypted data stored in their own database to generate the corporate response data including the number of contracts with the customer to be queried and whether or not they are overdue. Joint risk management system for commercial transactions.

5. In claim 4, The above transaction risk information generated by the above joint management solution server is implemented as numerical data quantifying the number of contracts and delinquency included in the corporate response data from each corporate server. Joint risk management system for commercial transactions.

6. In claim 5, The corporate server transmits an inquiry notification service application message including encrypted data for a specific customer and a predetermined inquiry period to the joint management solution server, and in response thereto, the joint management solution server determines whether a transaction risk analysis request message including the encrypted data that is the subject of inquiry is received from the other corporate server during the inquiry, and upon detecting receipt, transmits an inquiry notification message for the specific customer to the corporate server. Joint risk management system for commercial transactions.

7. In claim 3, The above-mentioned key information includes at least one of one-way encrypted pseudonym data, pseudonym number data, and pseudonym delivery address data. Joint risk management system for commercial transactions.

8. In claim 5, The above transaction risk information is reflected in the numerical data by adding an additional value according to the estimated number of contracts held based on the encrypted data of the customer subject to the inquiry included in the corporate response data from each of the above companies. Joint risk management system for commercial transactions.

9. In claim 5, The above numerical data is calculated by collecting all of the corporate response data from the multiple corporate servers, assigning different values ​​to normal contracts and overdue contracts for contracts within a recent specified period among the transaction contracts of the customer subject to inquiry included in each corporate response data, and normal contracts and overdue contracts for contracts outside the specified period, and adding up the values ​​assigned to each contract. Joint risk management system for commercial transactions.

10. In claim 9, The encrypted data includes at least one of one-way encrypted pseudonym data, pseudonym number data, and pseudonym delivery address data, and the numerical data assigns the value by giving a weight to the commercial transaction contract of the customer to be searched that overlaps two or more of the pseudonym data, the pseudonym number data, and the pseudonym delivery address data. Joint risk management system for commercial transactions.

Images