Abnormal transaction-based consentor priority control system and method thereof

Abstract

An abnormal transaction-based consenter priority control system according to the present invention may include: a payment executor terminal that generates a transaction request from a user and transmits the transaction request to a payment approval agency management server; a vendor terminal that generates payment destination information based on the transaction request and provides it to the payment approval agency management server; a consenter terminal that receives a consent request message and transmits an approval or rejection response to the payment approval agency management server; and a payment approval agency management server that receives the transaction request, evaluates the possibility of an abnormal transaction of the transaction, determines an approval strategy corresponding to the possibility of an abnormal transaction, calculates priority scores for a plurality of consenters, automatically selects the consenter with the highest score to perform an approval request, and controls the approval flow by automatically switching the approval request to the next-ranked consenter if a response is not received or an approval failure occurs.

Description

Technology Field

[0001] The present invention relates to an abnormal transaction-based consenter priority control system and a method for implementing the same. More specifically, it relates to an abnormal transaction-based consenter priority control system and a method for implementing the same that can intelligently control the approval flow according to the transaction risk level and minimize unnecessary approval delays by automatically optimizing the targets for approval requests by combining abnormal transaction detection results and the real-time response performance of consenters. Background Technology

[0003] Due to the recent proliferation of mobile financial services and the increase in non-face-to-face payment environments, the importance of technology that can rapidly determine the legitimacy of a transaction at the time of a payment request and perform appropriate approval procedures accordingly is growing.

[0004] In particular, for services requiring third-party approval procedures, such as those involving minors, the elderly, people with disabilities, and users requiring protection, the process of transmitting an approval request to the consenting party and receiving a response upon a transaction request is essential, and any delay or failure in this process directly affects the stability and reliability of payment processing.

[0005] However, most existing payment approval structures rely on methods that permanently send approval requests to specific consenters or remain at the level of simply verifying approval, making it difficult to proactively respond to the various situations that arise in actual service environments.

[0006] For example, the efficiency of approval requests is reduced because dynamic characteristics such as the consenter's response speed, approval success rate, and approval failure history are not considered, and there is a problem in that it is difficult to immediately determine which consenter is the most suitable approver for a given transaction in an environment where multiple consenters are registered.

[0007] Furthermore, there is a lack of functionality to quantitatively evaluate transaction data for abnormal transactions and incorporate this into the approval process. While a more robust approval strategy is required in situations where abnormal transactions are suspected, existing technologies do not provide features to adjust approval methods (such as selector groups, response waiting times, and approval request switching methods) based on transaction risk. Consequently, rapid response to high-risk transactions is difficult, leading to compromised security, while frequent unnecessary approval delays in legitimate transactions result in a deteriorated user experience.

[0008] In particular, there were issues where the approval flow was interrupted or payments were delayed for a long time due to the insufficient functionality to automatically transfer approval requests to the next-priority consenter when a request failed or the consenter did not respond. Additionally, there was a limitation in that it was difficult to select effective approvers because there was a lack of functionality to calculate consenter priorities in real-time based on response history, role level, and authority scope.

[0009] Korean Public Patent No. 10-2025-0117910 describes a financial institution system that determines financial activities performed by a child using money charged to a prepaid card based on a user terminal using validity information of verifiable credentials stored in a distributed data repository, wherein the server computer constructs a pattern from information on payments made by the child using the prepaid card and transmits an abnormal transaction detection message to the user terminal when it receives payment information different from the constructed pattern, but does not disclose a solution to the above problem. Prior art literature

[0011] Korean Patent Publication No. 10-2025-0117910 The problem to be solved

[0012] The present invention aims to provide an abnormal transaction-based consenter priority control system and a method for implementing the same, which can intelligently control the approval flow according to the transaction risk level and minimize unnecessary approval delays by automatically optimizing the targets for approval requests by combining abnormal transaction detection results and the real-time response performance of consenters.

[0013] In addition, the present invention aims to provide an abnormal transaction-based consenter priority control system and a method for implementing the same, wherein the consenter invitation and registration procedures are integrated and performed within the system, thereby clarifying approval authority management and blocking unauthorized access to approval, which can significantly enhance security.

[0014] In addition, the present invention aims to provide an abnormal transaction-based consenter priority control system and a method for implementing the same, which can significantly reduce the possibility of fraudulent transactions that may occur in an existing single authentication-based payment structure by performing an approval procedure by combining approval conditions set by a user with the result of an abnormal transaction judgment.

[0015] In addition, the present invention aims to provide an abnormal transaction-based consenter priority control system and a method for implementing the same, which can increase the flexibility of system usage by simultaneously supporting priority approval methods and parallel approval methods, thereby allowing various approval scenarios to be applied according to user requirements.

[0016] In addition, the present invention aims to provide an abnormal transaction-based consenter priority control system and a method for implementing the same, which can eliminate the possibility of manipulating approval responses and enhance the integrity of the approval process by verifying the electronic signature of a consenter terminal based on a public key.

[0017] In addition, the present invention aims to provide an abnormal transaction-based consenter priority control system and a method for implementing the same, which enables payment history management with very high legal and technical reliability by recording the entire approval process on a blockchain so that approval results and approval history cannot be deleted or altered.

[0018] In addition, the present invention aims to provide an abnormal transaction-based consenter priority control system and a method for implementing the same, which can simultaneously secure AI-based security and user-customized protection functions by automatically selecting high-risk transactions through an abnormal transaction detection function and strengthening the approval process. means of solving the problem

[0020] An abnormal transaction-based consenter priority control system for achieving this purpose may include: a payment executor terminal that generates a user's transaction request and transmits said transaction request to a payment approval agency management server; a vendor terminal that generates payment destination information based on said transaction request and provides it to said payment approval agency management server; a consenter terminal that receives a consent request message and transmits an approval or rejection response to said payment approval agency management server; and a payment approval agency management server that receives said transaction request, evaluates the possibility of an abnormal transaction of said transaction, determines an approval strategy corresponding to said possibility of an abnormal transaction, calculates priority scores for multiple consenters, automatically selects the consenter with the highest score to perform an approval request, and controls the approval flow by automatically switching the approval request to the next-ranked consenter if a response is not received or approval fails.

[0021] In one embodiment, the payment approval agency management server classifies transactions into normal, borderline, or high-risk grades based on an integrated risk score, and can set the approval request target group, response waiting time, and approval request conversion method differently in response to the risk grade.

[0022] In one embodiment, the payment approval agency management server calculates a consenter priority score by weighting multiple factors including the consenter's role grade, approval authority scope, response speed, approval success rate, approval failure history, and abnormal transaction response history, sorts consenters in descending order according to the calculated score, performs an approval request preferentially to the consenter with the highest score, and can automatically switch the approval request to the next-ranked consenter in the event of a response failure.

[0023] In addition, a method for controlling consenter priority based on abnormal transactions executed on a payment approval agency management server to achieve this purpose includes: a step of evaluating the possibility of an abnormal transaction in the transaction request upon receiving a transaction request from a user; a step of determining an approval strategy corresponding to the possibility of an abnormal transaction; a step of calculating priority scores for a plurality of consenters and then automatically selecting the consenter with the highest score according to the priority scores to perform an approval request; and a step of automatically transferring the approval request to the next-ranked consenter if an approval response is not received or an approval failure occurs.

[0024] In one embodiment, the abnormal transaction-based consenter priority control method may further include the step of the payment approval agency management server classifying a transaction into a normal, borderline, or high-risk grade based on an integrated risk score; and the step of the payment approval agency management server setting a different approval request target group, response waiting time, and approval request switching method in response to the risk grade.

[0025] In one embodiment, the abnormal transaction-based consenter priority control method may include: a step in which the payment approval agency management server calculates a consenter priority score by weighting and evaluating a plurality of factors including the consenter's role grade, approval authority scope, response speed, approval success rate, approval failure history, and abnormal transaction response history; a step of sorting consenters in descending order according to the calculated score and performing an approval request preferentially to the consenter with the highest score; and a step of automatically switching the approval request to the next-ranked consenter if the response fails as a result of the execution. Effects of the invention

[0027] According to the present invention as described above, by combining abnormal transaction detection results and the real-time response performance of consenters to automatically optimize the targets for approval requests, there is an advantage of intelligently controlling the approval flow according to the transaction risk level and minimizing unnecessary approval delays.

[0028] In addition, according to the present invention, since the consenter invitation and registration procedures are integrated and performed within the system, there is an advantage that approval authority management becomes clear and unauthorized access is blocked, thereby significantly enhancing security.

[0029] In addition, according to the present invention, by performing an approval procedure by combining approval conditions set by a user with abnormal transaction judgment results, there is an advantage of significantly reducing the possibility of fraudulent transactions that may occur in existing single authentication-based payment structures.

[0030] In addition, according to the present invention, since it simultaneously supports a priority approval method and a parallel approval method, various approval scenarios can be applied according to the user's requirements, which has the advantage of increasing the flexibility of system usage.

[0031] In addition, according to the present invention, there is an advantage in that the possibility of manipulating the approval response can be eliminated and the integrity of the approval procedure can be enhanced by verifying the electronic signature of the consenting terminal based on a public key.

[0032] In addition, according to the present invention, since the entire approval process is recorded on a blockchain, the approval results and approval history cannot be deleted or altered, which has the advantage of enabling payment history management with very high legal and technical reliability.

[0033] In addition, according to the present invention, since high-risk transactions are automatically selected through an abnormal transaction detection function to strengthen the approval process, there is an advantage of simultaneously securing AI-based security and user-customized protection functions. Brief explanation of the drawing

[0035] FIG. 1 is a network configuration diagram for explaining an abnormal transaction-based consenter priority control system according to one embodiment of the present invention. FIG. 2 is a block diagram illustrating the internal structure of a payment approval agency management server according to one embodiment of the present invention. FIG. 3 is a flowchart illustrating an embodiment of a method for controlling consenter priority based on abnormal transactions according to the present invention. FIG. 4 is a diagram illustrating an example for explaining the configuration of a consenter registration and approval condition setting screen in an abnormal transaction-based consenter priority control system according to the present invention. FIG. 5 is an example screen diagram illustrating the AI-based asset protection setting procedure performed by the payment approval agency management server according to the present invention. Specific details for implementing the invention

[0036] The aforementioned objectives, signatures, and advantages are described in detail below with reference to the attached drawings, thereby enabling those skilled in the art to easily implement the technical concept of the present invention. In describing the present invention, detailed descriptions of known technologies related to the present invention are omitted if it is determined that such descriptions would unnecessarily obscure the essence of the invention. Hereinafter, preferred embodiments according to the present invention will be described in detail with reference to the attached drawings. In the drawings, the same reference numerals are used to indicate the same or similar components.

[0038] FIG. 1 is a network configuration diagram for explaining an abnormal transaction-based consenter priority control system according to one embodiment of the present invention.

[0039] Referring to FIG. 1, the abnormal transaction-based consenter priority control system includes a payment executor terminal (100), a sales outlet terminal (200), a consenter terminal (300), a payment approval agency management server (400), and a blockchain server (500). At this time, the blockchain server (500) is an optional module for strengthening the integrity of the payment approval process and may be included or excluded depending on the embodiment, and the basic payment approval function of the present invention can be implemented regardless of whether the blockchain server is included. In addition, the approval history recording function performed by the blockchain server (500) may be replaced by a central server-based log storage method, distributed ledger technology, or other integrity assurance storage means depending on the embodiment.

[0040] The payment executor terminal (100) is a component that generates the first payment request for a user to perform a financial transaction, and performs functions such as generating and standardizing transaction data, transmitting it to a vendor terminal (200), displaying the approval status, and verifying the result. The operation process of the payment executor terminal (100) according to the present invention is described through the following embodiments.

[0041] In one embodiment, a payment executor terminal (100) detects the occurrence of a transaction when a user executes a transaction function such as remittance, cash withdrawal, online purchase, or offline payment. The payment executor terminal (100) generates a transaction request event based on the detected transaction information, and the event includes data such as a transaction amount, a vendor identifier, a transaction type, item information, an executor identifier, and a time of transaction occurrence. Additionally, the payment executor terminal (100) normalizes the generated transaction request event according to a predefined data structure to construct transaction request data including a transaction amount, a vendor code, terminal information, location information, and metadata for risk analysis.

[0042] In another embodiment, the payment executor terminal (100) transmits the normalized transaction request data to the vendor terminal (200). The transmission process is configured to maintain the integrity and security of the data by performing the transmission using an encrypted communication method. Since the vendor terminal (200) determines whether the transaction requires consenter approval through linkage with the payment approval agency management server (400), the payment executor terminal (100) includes a function to receive an approval waiting status returned from the vendor terminal (200) after transmission.

[0043] In another embodiment, when the payment approval agency management server (400) analyzes the transaction conditions and determines that the transaction requires consenter approval, the vendor terminal (200) transmits a status signal to the payment executor terminal (100) indicating that the approval request procedure is in progress. The payment executor terminal (100) receives this and displays a status such as "waiting for approval" or "guardian approval requested," thereby allowing the user to recognize the current transaction progress. Additionally, when a status change occurs at the consenter terminal (300), such as approval, rejection, or timeout, the payment executor terminal (100) receives this through the vendor terminal (200) and displays the transaction progress status in real time, such as "approving," "approval completed," "approval rejected," or "approval timeout exceeded."

[0044] In another embodiment, when all necessary approval signatures are collected from the consenting terminal (300) and the payment approval agency management server (400) determines that payment is possible, the vendor terminal (200) transmits a payment approval completion signal to the payment executor terminal (100). The payment executor terminal (100) receives this and displays a completion screen indicating that the payment has been processed successfully. Conversely, if approval is rejected during the consenting terminal approval process or if the designated approval time is exceeded, the payment executor terminal (100) displays the reason for blocking transmitted through the vendor terminal (200) on the user screen to clearly inform the user that the transaction has been terminated.

[0045] In another embodiment, the payment executor terminal (100) generates a transaction log based on information generated throughout the entire process from the creation of a transaction to approval or blocking processing. The transaction log includes transaction request information, the time of the approval request, whether approval is completed, the reason for approval failure, whether the transaction is blocked, etc., and the payment executor terminal (100) securely stores the log by linking it with the terminal's internal storage or an external server. This transaction log can be used as a basis for user lookup, financial accident response, dispute resolution, and record verification in the future, and if necessary, can be combined with the approval history stored in the blockchain server (500) to verify the integrity of the transaction.

[0046] As described above, the payment executor terminal (100) is a core component responsible for the initial stage and final result verification stage of the abnormal transaction-based consenter priority control system according to the present invention by performing functions such as generating a transaction request, normalizing transaction data, transmitting to a sales outlet terminal (200), displaying a waiting state for approval, receiving approval results, and generating a transaction log.

[0047] The vendor terminal (200) is a component that receives transaction request data from the payment executor terminal (100), links with the payment approval agency management server (400), determines whether approval is required, and performs payment processing or payment blocking according to the approval result. The operation process of the vendor terminal (200) is explained through the following embodiments.

[0048] In one embodiment, a vendor terminal (200) receives transaction request data generated and transmitted by a payment executor terminal (100). The transaction request data includes a transaction amount, vendor identifier, transaction type, item information, executor identifier, time of transaction occurrence, etc., and the vendor terminal (200) converts this into structured data that can be processed in an internal process. Additionally, the vendor terminal (200) prepares for reliable data transmission to a payment approval agency management server (400) by performing data format verification, encryption verification, and checking for missing fields to verify the integrity of the received data.

[0049] In another embodiment, the vendor terminal (200) transmits the normalized transaction information to the payment approval agency management server (400) to inquire whether the transaction requires consenter approval. The payment approval agency management server (400) determines whether approval is required based on predefined conditions such as the transaction amount, vendor type, and risk level, and the vendor terminal (200) receives the result of the determination. At this time, the vendor terminal (200) receives an approval determination result including data such as a flag indicating whether approval is required, risk level information, and the number of required consenters.

[0050] In another embodiment, when the payment approval agency management server (400) determines that the transaction requires consenter approval, the sales terminal (200) transmits a signal to the payment executor terminal (100) indicating a waiting state for approval. The sales terminal (200) acts as a relay between the payment executor terminal (100) and the payment approval agency management server (400) during the approval process, and transmits the result to the payment executor terminal (100) in real time when approval or rejection occurs at the consenter terminal (300). Additionally, if the approval request process continues for a long time, the sales terminal (200) performs a timeout management function to automatically set a payment blocking state for transactions that exceed the approval processing time limit.

[0051] In another embodiment, the vendor terminal (200) receives a payment approval completion signal when one or more approval signatures are collected from the consenting terminal (300) and the payment approval agency management server (400) determines that the payment is possible. Based on the signal, the vendor terminal (200) executes its own payment processing module to complete the payment approval and transmits the approval completion result to the payment executor terminal (100). Conversely, if the payment approval agency management server (400) determines that the payment is blocked because the approval is rejected by the consenting terminal (300) or the approval time has expired, the vendor terminal (200) transmits a signal to the payment executor terminal (100) indicating the payment is blocked.

[0052] In another embodiment, the vendor terminal (200) generates a payment processing log based on the result of payment approval or payment blocking. The log includes transaction request information, whether approval is required, the status of consenter approval progress, whether approval is completed, the reason for rejection of approval, whether a timeout has occurred, etc., and the vendor terminal (200) securely stores this in an internal storage or an external server. This log is linked with the payment approval agency management server (400), the financial institution system, the transaction verification module of the terminal itself, etc., and is utilized for ensuring the integrity of transaction records and for post-verification procedures.

[0053] In this way, the sales terminal (200) functions as a core component that mediates and controls the payment flow in the abnormal transaction-based consenter priority control system according to the present invention by performing functions such as receiving a transaction request, checking whether approval is required, relaying the approval procedure, processing the result of approval or blocking, and generating a transaction log.

[0054] The consenting terminal (300) is a component that receives a consent request message transmitted from a payment approval agency management server (400) and performs identity verification, input approval or rejection, generates an electronic signature, and transmits the approval result; it is the core entity performing the abnormal transaction-based consenting priority control system according to the present invention. The operation process of the consenting terminal (300) is explained through the following embodiments.

[0055] In one embodiment, the consenting terminal (300) receives a consent request message when the payment approval agency management server (400) transmits an approval request. The consent request message may include the transaction amount, vendor information, transaction type, executor identification information, time of transaction occurrence, etc., and the consenting terminal (300) provides this to the user through a screen or notification interface. The consenting terminal (300) displays a notification immediately upon receiving the approval request to notify the user that the payment approval process is in progress.

[0056] In another embodiment, the consenting terminal (300) performs an identity verification procedure after receiving a consent request message. The identity verification procedure may be configured in a manner such as password input, biometric authentication, or terminal unique authentication, and upon successful authentication, the device switches to an approval input screen. The consenting terminal (300) transmits the identity verification result to a payment approval agency management server (400) to perform the function of confirming that the consenting party is a legitimate user.

[0057] In another embodiment, the consenting terminal (300) provides a user input means to select whether to approve payment after identity verification is completed. The consenting user may choose either approval or rejection, and the selected input is transmitted to the payment approval agency management server (400). At this time, the consenting terminal (300) may display detailed information such as the transaction amount, vendor, and transaction type to help understand the transaction details. Additionally, by providing a function to input the reason for rejection when approval is rejected, the payment approval agency management server (400) can provide appropriate guidance to the payment executor terminal (100) based on the reason.

[0058] In another embodiment, the consenting terminal (300) generates an electronic signature corresponding to the transaction request when the consenting intention is confirmed. During the electronic signature generation process, the consenting terminal (300) generates a hash value of the transaction data and signs it using a private key-based signature algorithm within the terminal. The generated electronic signature can be used as an indicator to verify the integrity of the transaction and the fact of approval, and the consenting terminal (300) transmits the electronic signature to a payment approval agency management server (400) or a blockchain server (500).

[0059] In another embodiment, the consenting terminal (300) receives an approval processing result from the payment approval agency management server (400) after inputting approval or rejection. The payment approval agency management server (400) transmits a payment approval completion result to the consenting terminal (300) if the required number of consenting terminals is met, and a payment blocking result if approval rejection or a timeout occurs. The consenting terminal (300) visually provides this to the user so that the user can clearly recognize that the approval process has been completed.

[0060] Additionally, the consenting terminal (300) can record all procedures that occurred during the approval or rejection process as a log. The log may include the time of receipt of the approval request, whether identity verification was successful, the selection of approval or rejection, whether an electronic signature was generated, and the result of the approval processing, and if necessary, it is stored in conjunction with a payment approval agency management server (400) or a blockchain server (500). These logs can be utilized for various subsequent procedures, such as transaction verification, financial accident analysis, and approval history management.

[0061] As described above, the consenting terminal (300) performs functions such as receiving an approval request, authenticating the identity, deciding whether to approve or reject, generating an electronic signature, and verifying the approval result, thereby serving as a core component that directly handles the final approval judgment of a transaction in the abnormal transaction-based consenting priority control system according to the present invention.

[0062] The payment approval agency management server (400) is a central control unit of the abnormal transaction-based consenter priority control system according to the present invention, and manages the entire consenter registration procedure, consenter-specific approval condition storage procedure, transaction approval procedure, and approval history management procedure. The operation process of the payment approval agency management server (400) is described through the following embodiments.

[0063] In one embodiment, a payment authorization agency management server (400) receives a consenter invitation request from a payment executor terminal (100). The invitation request includes identification information of a candidate to be registered as a consenter, and the payment authorization agency management server (400) verifies this and sends a registration invitation message to the candidate. The invitation message may be provided via an application notification, a messenger notification, or a phone-based authentication method, and the payment authorization agency management server (400) stores the result of sending the invitation as an internal record.

[0064] In another embodiment, when a consenting candidate accesses the registration screen via an invitation message and performs an identity verification procedure, the payment approval agency management server (400) receives the verification result and verifies the identity of the candidate. If identity verification is successful, the payment approval agency management server (400) receives profile information from the consenting terminal (300) and stores information such as name, contact method, notification channel, and participation in approval to complete the consenting candidate registration.

[0065] In another embodiment, the payment approval agency management server (400) receives approval condition setting data per consenter from the payment executor terminal (100). The approval condition setting data may include criteria for a notification amount or minimum amount, approval conditions by financial transaction type, minimum account balance conditions, conditions for purchasing high-value items or specific categories, and conditions for a monthly cumulative consumption limit. The payment approval agency management server (400) stores the received approval conditions per consenter and applies approval judgment criteria based on the corresponding conditions in a future transaction approval process.

[0066] In another embodiment thereafter, when the payment approval agency management server (400) receives transaction request data from the payment executor terminal (100) or the sales terminal, it analyzes whether the transaction is valid. The payment approval agency management server (400) calculates deviations such as the transaction amount, transaction time zone, payment location type, location information, and terminal information by comparing them with a normal pattern model built from past normal transaction history, and converts them into a normalized deviation distance to calculate an integrated risk score. The calculated risk score is expressed as a value between 0 and 1, and the higher the value, the higher the probability of an abnormal transaction.

[0067] The payment approval agency management server (400) selects an approval strategy to be applied to the transaction through the approval strategy determination unit (455) based on the above risk score. The approval strategy determination unit (455) sets multiple grades of normal, borderline, and high-risk according to the risk score and applies the scope of approvers, response timeout, and approval request switching method differentially. For example, the approval strategy determines that for normal transactions, approval requests are made to a group of general approvers; for borderline transactions, a group of highly trusted approvers is selected first; and for high-risk transactions, approval requests are made to approvers with high authority, such as guardians or custodians.

[0068] After determining the approval strategy, the payment approval agency management server (400) calculates the ranking of the consenters subject to the approval request. The payment approval agency management server (400) calculates a final priority score for each consenter by combining static elements such as role grade, approval scope, and registration time with dynamic elements such as response speed, approval success rate, approval failure history, and abnormal transaction response history. The payment approval agency management server (400) sorts the scores in descending order and automatically selects the consenter with the highest score as the primary approval request target.

[0069] In this way, the payment approval agency management server (400) continuously performs the functions of analyzing transaction risks, determining approval strategies, and calculating consenter priorities, thereby implementing an intelligent approval flow that comprehensively considers the risk of the transaction and the reliability of the consenters. Furthermore, the server improves the efficiency and stability of the approval process through a control structure that transmits approval requests according to the calculated priority and automatically switches to the next-ranked consenter if a response is not received or approval fails.

[0070] In another embodiment, when a consenting terminal (300) transmits an approval or rejection response and an electronic signature, the payment approval agency management server (400) receives the response and performs an electronic signature verification procedure. If the signature is valid, the approval status is recorded, and it is determined whether the number of approvals specified according to the approval structure has been satisfied. If one consenting party transmits a rejection response or the approval timeout is exceeded, the payment approval agency management server (400) may block the payment.

[0071] In another embodiment, the payment approval agency management server (400) transmits the final approval or blocking result to the vendor terminal (200) to perform payment processing or payment suspension. Additionally, the electronic signature, response time, approval status, and approval structure information generated during the consenter approval process are linked with the blockchain server (500) and stored in the form of a transaction. The blockchain storage history can be utilized for future transaction verification, dispute resolution, and analysis of compliance with approval policies.

[0072] Additionally, the payment approval agency management server (400) stores all events that occurred throughout the consenter registration and approval processes in the form of logs. The logs include invitation request information, identity verification results, details of approval condition settings, records of sending approval requests, response status by consenter, electronic signature verification results, final approval or blocking results, etc. By analyzing the logs, the payment approval agency management server (400) can utilize them to optimize approval policies, improve abnormal transaction detection models, and enhance service stability.

[0073] As described above, the payment approval agency management server (400) performs the central function of the abnormal transaction-based consenter priority control system according to the present invention by overseeing both the preliminary preparation stage, which includes consenter registration and approval condition setting, and the real-time processing stage, which includes transaction approval judgment and approval procedure.

[0074] The blockchain server (500) functions as a distributed ledger storage device for storing and verifying data such as consenter registration history, approval condition setting history, transaction approval or rejection results, and electronic signature values ​​without falsification in the abnormal transaction-based consenter priority control system according to the present invention. The operation process of the blockchain server (500) is described through the following embodiments.

[0075] In one embodiment, the blockchain server (500) receives record data related to consenter registration from the payment approval agency management server (400). The record data may include consenter identification information, whether identity verification is complete, profile information, priority information, approval structure setting information, etc., and the blockchain server (500) converts this into transaction data and participates in the block creation procedure.

[0076] After the transaction is created, the blockchain server (500) verifies the validity of the transaction according to the consensus algorithm and includes the verified transaction in a new block to connect it to the chain. Through this, the consenter registration information is stored in a form that cannot be tampered with.

[0077] In another embodiment, the blockchain server (500) receives approval condition setting data per consenter from the payment approval agency management server (400) and records it. The approval conditions may include specific amount criteria, financial transaction type conditions, balance conditions, product purchase conditions, monthly cumulative expenditure conditions, etc., and the blockchain server (500) converts the above conditions into approval policy transactions and stores them on the blockchain. This record can subsequently be used as a basis for tracking whether the approval policy has been changed or for verifying whether the policy has been tampered with.

[0078] In another embodiment, the blockchain server (500) receives electronic signature data of each consenter from the payment approval agency management server (400) while performing the transaction approval procedure. The electronic signature data may include a transaction identifier, transaction summary information, consenter identification information, a signature value, a signature creation time, etc.

[0079] The blockchain server (500) records the above electronic signature as an individual transaction to maintain the integrity of the approval process and permanently stores the approval or rejection history for each consenter. This can fundamentally prevent the possibility of manipulation of the approval process.

[0080] Additionally, when the transaction approval or blocking is finally decided, the blockchain server (500) receives approval result record data from the payment approval agency management server (400). The approval result record data may include a list of approval participants, approval status, the time of response of each consenter, the method of response, and whether the electronic signature was verified, and the blockchain server (500) stores this as an approval result transaction.

[0081] As a result, the entire approval process for a single transaction is stored in the form of a linked log on the blockchain, and can subsequently be used for resolving transaction disputes, investigating fraudulent transactions, and third-party verification.

[0082] Additionally, the blockchain server (500) maintains the integrity and consistency of the data by executing a consensus algorithm during the block creation and storage process. The consensus algorithm may use a proof-of-work method, a proof-of-stake method, or other permissioned blockchain-based consensus methods, and the blockchain server (500) repeatedly verifies the validity of transactions through communication with verification nodes. In this process, the blockchain server (500) is configured to automatically detect and block attempts at malicious alteration or data forgery.

[0083] In another embodiment, the blockchain server (500) provides a verification function that can query stored transaction and block data. The payment approval agency management server (400), payment executor terminal (100), sales outlet terminal (200), etc., can send a query request to the blockchain server (500) when necessary to check approval history, registration history, and signature verification data, and the blockchain server (500) responds by extracting the relevant block or transaction. Through this, each component can secure the reliability of the transaction.

[0084] In addition, the blockchain server (500) stores all approval-related data generated during the entire operation of the system for a long period, and maintains the stability of the chain by performing data consistency checks and block orphan prevention procedures.

[0085] The blockchain server (500) can be used to automatically detect whether the approval policy has been tampered with based on the stored approval records or to detect abnormal signs during the operation of the system.

[0086] As described above, the blockchain server (500) functions as a core storage device that ensures the reliability and integrity of the abnormal transaction-based consenter priority control system according to the present invention, including functions for storing consenter registration records, storing approval conditions, storing electronic signature records, storing approval results, verifying consensus, and querying data.

[0088] FIG. 2 is a block diagram illustrating the internal structure of a payment approval agency management server according to one embodiment of the present invention.

[0089] Referring to FIG. 2, the payment approval agency management server (400) includes a consenter authentication management unit (405), a consenter profile management unit (410), an approval condition storage unit (415), a transaction request analysis unit (420), an abnormal transaction detection linkage unit (425), an approval judgment unit (430), an approval request control unit (435), a signature verification unit (440), a payment approval unit (445), a transaction pattern analysis unit (450), an approval strategy determination unit (455), and a consenter priority score calculation unit (460).

[0090] The consenter authentication management unit (405) is an internal component of the payment approval agency management server (400) and performs a core function to verify the identity of the consenter and ensure the integrity of the registration request during the consenter registration process. The operation process of the consenter authentication management unit (405) is described through the following embodiments.

[0091] In one embodiment, when the payment approval agency management server (400) receives a consenter invitation request transmitted from a payment executor terminal (100), the consenter authentication management unit (405) analyzes the contact information, user identifier, or terminal information included in the invitation request to verify the validity of the invitation target. During the verification process, procedures such as format checking of input information, checking for matching with a registered user database, and checking whether the account is inactive or blocked may be performed. The consenter authentication management unit (405) generates and transmits a data packet to send an invitation message to the invitation target whose validity has been verified.

[0092] In another embodiment, the consenter authentication management unit (405) initiates an identity authentication procedure when a consenter candidate who has received an invitation message accesses the consenter registration screen. The identity authentication procedure may be configured in a manner such as password input, one-time authentication code-based authentication, biometric authentication, or terminal unique authentication, and the consenter authentication management unit (405) includes a modularized authentication structure to support various authentication methods. When a consenter candidate inputs authentication information, the consenter authentication management unit (405) determines whether the authentication is successful by linking the authentication information with an authentication verification module within the server.

[0093] In another embodiment, the consenting member authentication management unit (405) verifies the consistency between the authentication information entered during the identity authentication process and the user information stored in the server's internal database.

[0094] In the authentication verification process, not only is a simple string comparison made, but the expiration status of the authentication code, the consistency of the biometric authentication value, and the consistency of the terminal information are also comprehensively determined. When authentication is successfully completed, the consenter authentication management unit (405) generates an authentication completion signal and transmits it to the consenter profile management unit (410), thereby enabling the subsequent procedures for creating the consenter profile and saving approval conditions to proceed.

[0095] Conversely, if authentication failure or a forgery attempt is detected, an authentication failure signal is generated to halt the registration process, and a security alert log is recorded if necessary.

[0096] In another embodiment, the consenter authentication management unit (405) may perform an encryption key exchange procedure to secure a secure communication path along with identity authentication. In this case, the consenter authentication management unit (405) performs an initial handshake using a public-private key pair to establish an encrypted session between the consenter terminal (300) and the server, and protects the data communicated during the subsequent profile input and approval condition setting steps from being forged or stolen by external attacks.

[0097] In another embodiment, the consenter authentication management unit (405) may store the authentication history of the registered consenter after authentication is completed by linking it with the blockchain server (500). At this time, the authentication history may include the authentication time, authentication method, whether authentication was successful, and information of the authentication terminal, and the authentication record stored in the blockchain may be used as a basis for identity verification in the approval procedure after consenter registration. Through this, the integrity and transparency of the consenter registration process are enhanced.

[0098] In another embodiment, the consenter authentication management unit (405) can perform the consenter identity verification function not only during the consenter registration process but also during the approval process. For example, if a specific high-risk transaction or a high-value transaction occurs, the consenter authentication management unit (405) may request a consenter re-authentication procedure through the consenter authentication management unit (405), and the consenter authentication management unit (405) transmits the re-authentication request to the consenter terminal (300) and re-verifies whether the authentication is successful. This prevents risks such as the use of a stolen terminal or the generation of forged responses.

[0099] As described above, the consenter authentication management unit (405) functions as a core component that ensures the reliability of the consenter registration and approval process by verifying the validity of the consenter invitation, performing an identity authentication procedure, verifying authentication data, setting up an encrypted session, storing authentication history, and performing a re-authentication procedure when necessary.

[0100] The consenter profile management unit (410) is a component that stores and manages the consenter's basic information, approval structure information, and approval participation settings, and performs the role of maintaining core data necessary for performing approval policies and approval procedures after consenter registration. The operation process of the consenter profile management unit (410) is explained through the following embodiments.

[0101] In one embodiment, when the consenter profile management unit (410) receives a signal indicating that consenter identity verification is complete from the consenter authentication management unit (405), it prepares to receive profile input data transmitted from the consenter terminal (300). The consenter terminal (300) provides a screen for entering basic profile information, such as name, contact method, notification reception method, and approval participation status, and the consenter profile management unit (410) receives the data and converts it into a form suitable for an internal data structure. During the conversion process, checks for missing required fields, data format checks, and valid value verification may be performed.

[0102] In another embodiment, the consenter profile management unit (410) stores consenter-specific approval attributes by reflecting the approval structure settings between the consenter and the payment executor. The approval attributes may include priority values, whether parallel approval is required, whether alternative approval is possible, etc. The consenter profile management unit (410) stores these attributes in a state associated with the consenter identifier, thereby supporting the approval judgment unit (430) to accurately evaluate whether approval is required for each consenter when a transaction occurs.

[0103] In another embodiment, the consenter profile management unit (410) manages notification channel settings for each consenter. Notification channels may include application push, messaging service, phone notification, email, etc., and the consenter profile management unit (410) stores the channels available to each consenter and supports the approval request control unit (435) in selecting appropriate means. Additionally, the consenter profile management unit (410) can store the priority of the notification channels so that the fastest and most reliable channel is selected in a specific environment.

[0104] In another embodiment, the consenter profile management unit (410) may perform the function of specifying the type of transaction or the scope of approval for which the consenter's approval is required. For example, a specific consenter may be restricted to performing only financial transaction approvals, and another consenter may be set to participate only in the product purchase approval process. The consenter profile management unit (410) stores this approval scope information for each consenter so that it can be utilized in the step of determining whether approval is required.

[0105] In another embodiment, the consenter profile management unit (410) may store registered profile data and approval structure information in conjunction with other components of the payment approval agency management server (400), or transmit it to the blockchain server (500) to permanently store the registration history. The blockchain storage may include the profile registration time, approval structure settings, approval scope settings, etc., and may be used as supporting data for identity verification or policy change verification during the subsequent approval process.

[0106] Additionally, the consenter profile management unit (410) updates the relevant information when changes to consenter information or policies occur. Changeable information includes contact information, notification channels, approval scope, priority, etc. After verifying the change request, the consenter profile management unit (410) records the change history and provides a real-time update function so that the approval judgment unit (430) can apply the latest policy.

[0107] Additionally, the consenter profile management unit (410) can manage the consenter status even while the approval process is being performed after the consenter registration is completed. For example, if a consenter who is temporarily unable to participate in the approval, a suspended consenter, or a substitute consenter is assigned, the status information regarding this is recorded and reflected in the approval judgment step.

[0108] As described above, the consenter profile management unit (410) stores and manages the consenter's basic information, approval structure, approval scope, notification channel, and status information, and plays a key data management role so that the approval judgment and approval procedure control functions within the payment approval agency management server (400) can be performed accurately.

[0109] The approval condition storage unit (415) is a component that receives approval condition setting data provided by the payment executor terminal (100) and the consenter terminal (300), stores approval policies for each consenter, and manages policy information so that the approval judgment unit (430) can determine whether approval is required based on this. The operation process of the approval condition storage unit (415) is described through the following embodiments.

[0110] In one embodiment, when the approval condition storage unit (415) receives an approval condition setting request from the payment executor terminal (100), it verifies the format and validity of the setting data included in the request. The approval condition setting data may include criteria for a notification amount or minimum amount, specific transaction type conditions, specific sales outlet or industry conditions, etc., and the approval condition storage unit (415) determines whether the data is in a form that can be reflected in a policy table. Verification of whether required fields are missing, suitability of the value range, and whether there are setting conflicts may be verified.

[0111] In another embodiment, the approval condition storage unit (415) may receive different approval conditions for multiple consenters from the consenter terminal (300). For example, a specific consenter may be set to be approved only for remittances and ATM withdrawals, while another consenter may be set to be approved only for the purchase of goods. The approval condition storage unit (415) stores these detailed conditions for each consenter as individual policy entries so that the approval judgment unit (430) can accurately identify the role of the consenter when a specific transaction occurs.

[0112] In another embodiment, the approval condition storage unit (415) stores various conditions related to the transaction amount. The payment executor may set whether approval is required for transactions exceeding a specific amount, and conditions such as a minimum amount or higher, a specific range condition, or an excess condition may be set. The approval condition storage unit (415) stores the condition values ​​for each consenter and uses them to determine whether approval is required by comparing them with the transaction amount calculated by the transaction request analysis unit (420).

[0113] In another embodiment, the approval condition storage unit (415) stores conditions related to financial transaction types. The conditions may include various financial transaction types such as remittance, account transfer, automatic transfer, and cash withdrawal, and the approval condition storage unit (415) stores a mapping of whether the consenter approves for each transaction type. This allows the approval request to be delivered only to consenters who meet the corresponding conditions when a financial transaction occurs.

[0114] In another embodiment, the approval condition storage unit (415) stores a balance-based approval condition. The payment executor may be configured to activate the consenter approval procedure when the account balance falls below a specific amount, and the approval condition storage unit (415) stores the threshold value and utilizes it in the approval judgment step. This condition can be used as a core policy for protecting user assets.

[0115] In another embodiment, the approval condition storage unit (415) stores policies related to product purchase conditions. For example, it can be configured to require an approval procedure when purchasing high-value electronic products, precious metals, specific risk category products, etc., and the approval condition storage unit (415) stores information such as product category code, risk level, and minimum purchase amount in a policy table. Through this, the approval judgment unit (430) can perform an appropriate consenter approval procedure based on the transaction item information provided by the sales terminal (200).

[0116] In another embodiment, the approval condition storage unit (415) stores approval conditions based on the monthly cumulative consumption amount. The payment executor may set the approval process to be activated when the monthly cumulative consumption amount exceeds a specific amount, and the approval condition storage unit (415) stores the cumulative amount criteria. The approval judgment unit (430) may evaluate whether the conditions are met based on the monthly cumulative transaction amount information provided by the transaction request analysis unit (420).

[0117] In another embodiment, the approval condition storage unit (415) performs policy consistency verification to ensure that the set policies do not conflict with each other. For example, if conflicting conditions are set for the same transaction type, or if a conflict occurs between a priority rule and a parallel approval rule, the approval condition storage unit (415) may generate a warning or reject the setting. This ensures the stability of the approval policy and operational reliability.

[0118] In another embodiment, the approval condition storage unit (415) can prevent tampering by recording the stored approval conditions on the blockchain server (500). The stored data may include consenter identification information, approval condition type, condition value, setting time, setting change history, etc., and the data stored on the blockchain can be used as supporting data to verify whether a policy has been changed when performing the approval procedure.

[0119] Additionally, the approval condition storage unit (415) automatically transmits the changes to the approval judgment unit (430) when a policy change or a consenter profile change occurs, so that the latest policy is applied in real time. Through this, the approval condition storage unit (415) functions as a core data management component that maintains the accuracy of the approval judgment function within the payment approval agency management server (400).

[0120] As described above, the approval condition storage unit (415) stores approval conditions for each consenter, verifies policy conflicts, and performs the function of providing approval policy information so that the approval judgment unit (430) can make a correct judgment, thereby serving as a core data storage unit of the abnormal transaction-based consenter priority control system according to the present invention.

[0121] The transaction request analysis unit (420) is a component that structures transaction request data received from the sales terminal (200), performs transaction characteristic analysis, risk calculation, and judgment of matching with approval conditions, and plays a key role in generating basic data for the approval judgment unit (430). The operation process of the transaction request analysis unit (420) is explained through the following embodiments.

[0122] In one embodiment, when the transaction request analysis unit (420) receives transaction request data from the seller terminal (200), it first verifies the integrity and format suitability of the transaction request data. The transaction request data may include a transaction amount, seller identifier, item information, transaction time zone, executor terminal information, etc., and the transaction request analysis unit (420) determines whether required fields are missing, checks the range of values, and whether data has been tampered with, and transmits only valid transaction requests to subsequent steps.

[0123] In another embodiment, the transaction request analysis unit (420) classifies transaction types for transaction data that has been verified as valid. The transaction type classification may be divided into financial transactions, cash withdrawals, product purchases, subscription payments, etc., and the transaction request analysis unit (420) automatically determines the transaction type based on a vendor industry code, a transaction item code, or a transaction identification rule. Such transaction type information is utilized by the approval judgment unit (430) in the process of comparing it with approval conditions for each consenter.

[0124] In another embodiment, the transaction request analysis unit (420) calculates the basic risk level of a transaction based on the transaction amount, transaction time zone, and type of sales outlet. For example, the basic risk level may increase for transactions during nighttime hours, high-value transactions, or transactions occurring at sales outlets classified as high-risk industries, and the transaction request analysis unit (420) calculates the risk level by applying a pre-set weight-based risk score calculation algorithm. Here, the calculation of the basic risk level can be represented by the following [Equation 1].

[0126] [Mathematical Formula 1]

[0127]

[0129] R base : Basic risk level

[0130] A: The transaction amount

[0131] A max : Predefined maximum risk detection threshold amount

[0132] T risk Risk index for trading hours

[0133] M risk Risk index based on sales channel industry

[0134] w a , w t , w m : Weight of each item

[0136] In another embodiment, the transaction request analysis unit (420) calculates an abnormal transaction indicator by comparing it with the transaction executor's past transaction patterns. For example, the abnormal indicator rises when a sudden large transaction occurs compared to the typical transaction amount at the same vendor, and also rises when there is a transaction that occurred during a past period of no transactions. The transaction request analysis unit (420) generates a risk correction value based on such abnormal indicators. This process can be represented by the following [Equation 2].

[0138] [Mathematical Formula 2]

[0139]

[0140] R adj : Final adjusted risk

[0141] A: Current transaction amount

[0142] : Historical average transaction amount

[0143] △T past : Heterogeneity indicator with past trading time zones

[0144] α,β: Correction weights

[0145] ∈: Infinitesimal value to prevent division by zero

[0147] In another embodiment, the transaction request analysis unit (420) generates a list of candidate consenters by comparing the consenter-specific approval conditions stored by the approval condition storage unit (415) with the transaction data. For example, if the transaction amount exceeds the approval condition of consenter A, the transaction type corresponds to the approval condition of consenter B, and the monthly cumulative usage condition exceeds the standard of consenter C, it is determined that an approval request is required for each consenter. The transaction request analysis unit (420) transmits these condition matching results to the approval judgment unit (430).

[0148] In another embodiment, the transaction request analysis unit (420) analyzes the vendor information and item information included in the transaction request to calculate the item risk level. For example, transactions involving high-priced electronic products, precious metals, medical devices, and currency exchange may be classified as high risk, and the transaction request analysis unit (420) calculates the risk level by looking up an item code-based risk mapping table.

[0149] In another embodiment, the transaction request analysis unit (420) synthesizes the calculated risk level, transaction type, and whether approval conditions are met, and generates analysis data necessary for the approval judgment unit (430) to determine whether to initiate the transaction approval procedure. The transaction request analysis unit (420) records the analysis results for each transaction and maintains the state until the approval procedure is completed.

[0150] As described above, the transaction request analysis unit (420) performs transaction data structuring, transaction type classification, basic risk calculation, user pattern-based correction, approval condition matching, and item risk calculation, and functions as a core component that supports the approval judgment unit (430) in accurately determining whether to perform the consenter approval procedure based on the analysis results.

[0151] The abnormal transaction detection linkage unit (425) determines whether a transaction is abnormal based on transaction data provided by the transaction request analysis unit (420), user past transaction history, and vendor characteristic information, and performs the function of correcting the risk level by linking with an internal or external artificial intelligence-based risk assessment module. The operation process of the abnormal transaction detection linkage unit (425) is explained through the following embodiments.

[0152] In one embodiment, the abnormal transaction detection linkage unit (425) receives the transaction amount, transaction time zone, sales outlet type, item information, etc. provided by the transaction request analysis unit (420) as input values, and detects basic abnormal signs by querying reference information such as the average transaction amount per user, recent transaction interval, normal category by transaction type, and list of preferred sales outlets. The abnormal score increases if a transaction occurs in a time zone that does not generally occur, or if a transaction occurs that is significantly higher than the average transaction amount per user.

[0153] In another embodiment, the abnormal transaction detection linkage unit (425) determines whether there is an abnormality by analyzing transaction occurrence area information or characteristics of the transaction occurrence terminal. An abnormal signal may be detected if a high-value transaction occurs in an area that the user does not usually use, or if a transaction occurs from an unregistered terminal. Additionally, the discrepancy from normal user behavior is analyzed by comparing the distance difference between the location information of the payment executor terminal (100) and the location information of the seller terminal (200), changes in the connection IP, communication delay time, etc.

[0154] In another embodiment, the abnormal transaction detection linkage unit (425) calculates a risk level by linking with an artificial intelligence-based abnormal transaction detection model. The model uses multiple feature values ​​as input, such as user past transaction patterns, vendor reliability, and changes in transaction time and amount. The abnormal transaction detection linkage unit (425) generates a comprehensive risk level by combining the risk score calculated by the model with the existing policy-based risk level. In this process, the model may be updated in real-time or periodically, and the abnormal transaction detection linkage unit (425) automatically reflects the latest risk level assessment results.

[0155] In another embodiment, the abnormal transaction detection linkage unit (425) links with the sales terminal (200) or the industry-specific risk database to correct the risk level of a transaction that occurred at a specific sales location. The risk level increases for high-value payments that are repeated in a short period at the same sales location or for transactions that occur at a sales location with a history of past fraudulent transactions, and the abnormal transaction detection linkage unit (425) reflects this in the transaction risk judgment process.

[0156] In another embodiment, the abnormal transaction detection linkage unit (425) analyzes the heterogeneity of transaction patterns by comparing them with the user activity history. By analyzing the difference between recent transactions and past transaction characteristics, for example, if a sudden high-value transaction occurs even though there were no specific transaction types for the past 30 days, or if a user who usually only uses the service during daytime hours attempts to make a transaction during the early morning hours, it is reflected as an abnormality.

[0157] In another embodiment, the abnormal transaction detection linkage unit (425) transmits the abnormal judgment result to the approval judgment unit (430). If the risk level exceeds a threshold, the approval judgment unit (430) may be configured to initiate a consenter approval procedure, and if the risk level is very high, it may be configured to block the transaction without an approval procedure. Conversely, for transactions with a low risk level, the approval procedure may be omitted to allow for automatic approval.

[0158] In another embodiment, the abnormal transaction detection integration unit (425) stores the abnormal score and analysis feature value in an internal log or blockchain server (500). The stored data includes a transaction identifier, an abnormal score, a feature value used in the analysis, a model version, etc., which can be used as supporting data for future dispute resolution, model improvement, and authentication procedure verification.

[0159] As described above, the abnormal transaction detection linkage unit (425) functions as a component that supports the approval judgment unit (430) in making accurate and intelligent approval decisions by performing transaction characteristic analysis, user pattern-based abnormal detection, artificial intelligence-based risk calculation, sales outlet-based risk correction, and providing abnormal judgment results.

[0160] The approval determination unit (430) is a component that determines whether the transaction requires consenter approval based on the analysis results provided by the transaction request analysis unit (420) and the abnormal transaction detection linkage unit (425), and determines the approval structure to be performed by the approval request control unit (435). The operation process of the approval determination unit (430) is explained through the following embodiments.

[0161] In one embodiment, the approval determination unit (430) determines whether approval is required by comparing the transaction amount, transaction type, sales outlet information calculated by the transaction request analysis unit (420), and the approval conditions for each consenter stored in the approval condition storage unit (415). If the transaction amount exceeds the minimum approval criteria for a specific consenter, or if the transaction type falls within the approval range of the consenter, the approval determination unit (430) designates the consenter as an approval candidate.

[0162] In another embodiment, the approval judgment unit (430) determines whether approval is required by additionally reflecting the risk score calculated by the abnormal transaction detection linkage unit (425). If the risk score is above a threshold, the approval judgment unit (430) may be configured to require consenter approval even if the transaction volume is small; conversely, if the risk score is low, it may determine to automatically approve the transaction without an approval procedure by relaxing some of the approval conditions. Through this, the approval judgment unit (430) implements a composite approval structure that combines policy-based judgment and AI-based judgment.

[0163] In another embodiment, the approval determination unit (430) retrieves approval structure information of the consenter from the approval condition storage unit (415). The approval structure may include a priority approval method, a parallel approval method, and whether the consenter is a mandatory consenter. The approval determination unit (430) prioritizes including mandatory consenters in the list of candidate consenters and determines the order in which the approval request control unit (435) transmits approval requests according to the parallel or sequential approval method.

[0164] In another embodiment, the approval judgment unit (430) may dynamically change the approval structure according to the nature of the transaction. For example, if repeated high-value payments occur within a short period at the same vendor, the structure that previously required only a single consenter approval may be expanded to a multiple consenter parallel approval structure. The approval judgment unit (430) transmits this structural change to the approval request control unit (435) to perform a more enhanced protection procedure.

[0165] In another embodiment, the approval judgment unit (430) may analyze the transaction environment to strengthen or weaken the need for approval. For example, if the distance between a normal user location and a sales location is very large, or if a transaction occurs in an unregistered network environment, the approval judgment unit (430) may require an approval procedure. Conversely, if a low-value transaction occurs at a sales location frequently used by the user, the approval judgment unit (430) may automatically approve the transaction without an approval procedure.

[0166] In another embodiment, the approval determination unit (430) determines not only whether approval is required but also auxiliary policies to be applied in the event of an approval request failure or a response delay. For example, an automatic blocking policy may be applied if the response time is excessively delayed, and if a substitute consenter is registered, the approval request may be set to be automatically transferred to the substitute consenter. The approval determination unit (430) transmits this to the approval request control unit (435) to enable the handling of exceptional situations during the approval process.

[0167] In another embodiment, the approval determination unit (430) determines the list of consenting parties subject to approval and the approval structure, and then transmits the information to the approval request control unit (435). The approval determination unit (430) provides an approval policy in a structured form so that the approval request control unit (435) can accurately execute the required number of approvals, approval order, approval deadline, etc. In addition, the approval determination unit (430) can update the approval determination record by receiving approval response information from the approval request control unit (435) to monitor the progress of the approval.

[0168] As described above, the approval judgment unit (430) determines whether to perform the approval procedure by comprehensively considering the transaction risk, approval conditions, consenter profile, and approval structure, and functions as a key component for setting an approval policy so that the approval request control unit (435) can perform an appropriate approval request.

[0169] The approval request control unit (435) is a component that generates a consent request message according to the consenting party and approval structure determined by the approval judgment unit (430), transmits it to the consenting party terminal (300), and controls the collection, retransmission, and timeout processing of the approval response. The operation process of the approval request control unit (435) is explained through the following embodiments.

[0170] In one embodiment, when the approval request control unit (435) receives a list of consenting parties subject to approval and an approval structure from the approval judgment unit (430), it generates a consent request message including a transaction amount, transaction type, sales location information, approval deadline, etc. Based on the notification settings of the consenting party terminal (300), the generated consent request message is transmitted by selecting an appropriate communication channel, such as an application push, message service, or voice notification.

[0171] In another embodiment, when the approval structure is a priority approval method, the approval request control unit (435) first sends an approval request to the consenter with the highest priority and waits for a response from that consenter for a specified time. If no response arrives, the approval request control unit (435) may perform a retransmission or automatically forward the approval request to the next priority consenter. In the priority approval method, the approval process may be terminated when one consenter approves.

[0172] In another embodiment, when the approval structure is a parallel approval method, the approval request control unit (435) simultaneously transmits an approval request to all consenting parties subject to approval. The approval request control unit (435) generates an independent response timer for each consenting party to monitor the response status, and transmits it to the approval judgment unit (430) whenever an approval status arrives. In the parallel approval method, approval is determined to be complete only when all consenting parties approve, and if even one rejection response occurs, the approval process is terminated immediately.

[0173] In another embodiment, the approval request control unit (435) detects communication failures, terminal disconnection, network delays, etc., that may occur during the approval request transmission process. If an approval request failure is detected, the approval request control unit (435) applies a pre-set retransmission policy or, if an alternative consenter is designated, automatically transfers the approval request to the alternative consenter. This exception handling function contributes to increasing the stability and reliability of the approval process.

[0174] In another embodiment, the approval request control unit (435) receives various types of responses, such as approval, rejection, no response, or authentication failure, from the consenting terminal (300) after transmitting an approval request. The approval request control unit (435) distinguishes each response and transmits response data so that the approval judgment unit (430) can make an appropriate approval judgment. If the response does not arrive within a specified time, the approval request control unit (435) applies a timeout policy and processes it as an approval failure.

[0175] In another embodiment, the approval request control unit (435) records the transmission history and response history of the consent request message in an internal log or blockchain server (500). The information recorded includes the time of sending the approval request, the communication channel, the time of arrival of the response, the type of response, the number of retransmissions, and whether there is an error. These records can be used as supporting data for verifying the integrity of the approval process, resolving disputes, and improving policies.

[0176] In another embodiment, the approval request control unit (435) provides the approval request progress status to the payment executor terminal (100) or the sales outlet terminal (200) to inform the user that the approval request is being processed normally. The status information provided may include whether the approval request has been transmitted, a list of pending consenters, and the result of approval or rejection.

[0177] The approval request control unit (435) performs the function of automatically selecting the consenter with the highest score based on the priority score for each consenter provided by the consenter priority score calculation unit (460), sending an approval request to the consenter, waiting until a response is received, and then automatically switching the approval request to the next-ranked consenter if the response fails or there is no response.

[0178] First, the approval request control unit (435) sorts the list of consenting priority scores in descending order and designates the consenting person with the highest score among them as the primary approval target. In this process, the approval request control unit (435) automatically applies the most suitable request method by considering the approval method, response timeout value, request path, etc. set by the approval strategy decision unit (455).

[0179] The approval request control unit (435) generates a consent request message for the consenting party determined as the primary approval recipient and transmits it to the corresponding terminal. The consent request message includes the transaction amount, transaction time, payment location information, risk level, transaction identifier, etc., and the approval request control unit (435) monitors the transmission status in conjunction with a communication module so that this message can be safely transmitted. When the approval request is successfully transmitted, the approval request control unit (435) waits for the consenting party's approval response for a set timeout.

[0180] During the waiting period, the approval request control unit (435) monitors the consenter's approval or rejection response in real time, and if no response is received by the timeout elapses, the consenter is determined to be non-respondent or approval failed. When this determination is made, the approval request control unit (435) immediately automatically converts the next-ranked consenter to the second approval target. The next-ranked consenter is determined to be the consenter with the second highest score in the initial priority score list, and the approval request control unit (435) repeats the same approval request procedure to send a new consent request message to the consenter.

[0181] If the second approval recipient also does not respond within the timeout or approval fails, the approval request control unit (435) continuously performs approval requests in the same manner to the next-ranked consenter. This automatic switching process continues until the group-specific approval range or maximum number of approval attempts specified by the approval strategy decision unit (455) is reached, and if rejection, failure, or non-response occurs from all approval recipients, the approval request control unit (435) marks the transaction as unapprovable and the entire approval process is terminated.

[0182] In this way, the approval request control unit (435) implements an efficient and intelligent approval request flow that reflects the transaction risk level and the real-time response performance of the consenter by performing a series of procedures including automatic selection based on priority score, transmission of approval request, waiting for response, and automatic switching to the next priority. Through this, the present invention can maximize the reliability and stability of payment approval processing even in abnormal transaction situations.

[0183] The signature verification unit (440) is a component for verifying the authenticity of an electronic signature received from a consenting terminal (300) and ensuring that the response to an approval request is normal and untampered data. The signature verification unit (440) performs the role of ensuring the reliability of the approval procedure by working in conjunction with the approval judgment unit (430) and the approval request control unit (435). The operation process of the signature verification unit (440) is explained through the following embodiments.

[0184] In one embodiment, when the signature verification unit (440) receives an approval or rejection response from the consenting terminal (300), it first separates data such as the electronic signature, transaction identifier, consenting identifier, and signature time included in the response message and converts it into a verifiable structure. During the conversion process, data format inspection, verification of missing fields, and preparation for decryption of encrypted data may be performed.

[0185] In another embodiment, the signature verification unit (440) performs a public key-based verification procedure to verify the electronic signature generated by the consenting terminal (300). The payment approval agency management server (400) stores the public key of the consenting terminal (300) during the consenting registration stage, and the signature verification unit (440) uses the said public key to check whether the electronic signature matches the hash value of the corresponding transaction data. If the signature value is successfully decrypted through the public key verification procedure, it is determined to be a valid electronic signature.

[0186] In another embodiment, the signature verification unit (440) verifies the freshness of the signature data by analyzing the difference between the time of electronic signature generation and the server reference time. For example, if the time of signature generation is excessively old compared to the server reference time, or if time manipulation is suspected, the signature verification unit (440) may determine that the response is a forged response. This is effective in preventing replay attacks or forgery of repeated approval requests.

[0187] In another embodiment, the signature verification unit (440) verifies the consistency between the transaction identifier and the signature data. If the transaction identifier included in the signature data does not match the transaction identifier transmitted by the approval request control unit (435), or if the signature content contains data for a different transaction, the signature verification unit (440) determines the response as invalid and transmits an error status to the approval judgment unit (430).

[0188] In another embodiment, the signature verification unit (440) can evaluate data integrity by generating a hash value for the entire approval response data. It confirms that the response data has not been tampered with during transmission by comparing the received response message with the internally generated hash value, and if a hash mismatch occurs, it determines that the response data is corrupted and excludes it from the approval process.

[0189] In another embodiment, the signature verification unit (440) transmits the signature verification result to the approval judgment unit (430) or the approval request control unit (435). If the signature is successfully verified, the approval or rejection response of the consenting party is processed to be reflected in the approval structure evaluation of the approval judgment unit (430); if the signature verification fails, the approval judgment unit (430) may stop the approval procedure or transfer the approval request to an alternative consenting party according to an error handling policy.

[0190] In another embodiment, the signature verification unit (440) records verified signature data on a blockchain server (500) or an internal log storage unit to ensure the integrity of the approval process. The information recorded may include an electronic signature value, a signature verification result, a time of signature, consenter identification information, etc., and may be used as evidence for future dispute resolution or audit trails.

[0191] As described above, the signature verification unit (440) functions as a key component that ensures the reliability of the approval process by performing verification of the authenticity of the electronic signature, verification of data integrity, visual verification, evaluation of transaction consistency, and recording of verification results.

[0192] The payment approval unit (445) is a component that makes a final decision to approve or block a transaction based on the approval judgment result and electronic signature verification information provided by the approval judgment unit (430) and the signature verification unit (440), and transmits the result to the sales terminal (200) and the payment executor terminal (100). In addition, the payment approval unit (445) records the approval result in a blockchain server (500) or an internal storage unit to ensure the integrity of the approval process. The operation process of the payment approval unit (445) is explained through the following embodiments.

[0193] In one embodiment, the payment approval unit (445) receives from the approval judgment unit (430) whether the approval conditions are satisfied, and evaluates whether final approval is possible by integrating the approval responses by consenter and the electronic signature verification results collected through the approval request control unit (435) and the signature verification unit (440). If the approval structure is a priority method, it can be determined that the approval conditions are satisfied when the consenter with the highest priority approves, and if it is a parallel approval method, the approval conditions are satisfied only when all consenters subject to approval approve.

[0194] In another embodiment, the payment approval unit (445) stops the approval process and decides to block payment if the electronic signature verification result provided by the signature verification unit (440) is invalid, even if the approval conditions are met. Since failure in electronic signature verification implies suspicious situations such as falsification of response data, retransmission attacks, or signature manipulation, the payment approval unit (445) safely blocks this. This ensures the security and integrity of the approval process.

[0195] In another embodiment, when payment approval conditions are met, the payment approval unit (445) generates a payment approval signal and transmits it to the sales terminal (200). The approval signal includes the approval time, a list of consenting parties participating in the approval, approval structure information, etc., and the sales terminal (200) completes the payment processing according to this signal. At the same time, the payment approval unit (445) transmits the approval completion status to the payment executor terminal (100) to indicate that the approval process has been successfully completed.

[0196] In another embodiment, if the approval conditions are not met or if any of the consenters transmit a rejection response, the payment approval unit (445) generates a payment blocking signal. The payment blocking signal is transmitted to the vendor terminal (200) to stop the transaction, and provides guidance information including the reason for the blocking to the payment executor terminal (100). The guidance information may include detailed reasons such as the occurrence of a rejection response, a timeout due to a response delay, or a failure in signature verification.

[0197] In another embodiment, the payment approval unit (445) records data generated during the approval process in the blockchain server (500) after an approval or blocking decision is made. The recorded data includes the approval result, a list of participating consenters, the signature verification result, the time of approval, and the transaction identifier, and the blockchain server (500) stores this in the form of a transaction to prevent tampering. This can be used for purposes such as resolving transaction disputes, detecting fraudulent activities, and verifying approval policies.

[0198] In another embodiment, the payment approval unit (445) stores all events that occurred during the approval process in an internal log. The stored log includes the time of the approval request, the time of the response arrival, the flow of the application of the approval structure, error information, communication status, etc., and this information is used as base data for improving approval policies, analyzing errors, and ensuring system operation stability.

[0199] In another embodiment, the payment approval unit (445) applies a response policy when an exception occurs during the approval process. For example, if the approval request control unit (435) reports a state of non-arrival of response, the approval process may be automatically terminated or the approval request may be switched to an alternative consenter; and if the connection of the vendor terminal (200) or the payment executor terminal (100) is disconnected during approval, the approval process may be suspended or automatically blocked. As described above, the payment approval unit (445) functions as a core component responsible for the final stage of the abnormal transaction-based consenter priority control system according to the present invention by performing functions such as integrated evaluation of approval status, final approval or blocking decision, result delivery, blockchain recording of approval data, and exception handling.

[0200] The transaction pattern analysis unit (450) performs the function of analyzing normal transaction patterns by user and payment location based on transaction request data collected from payment executor terminals and sales location terminals, and quantifying how much a new transaction deviates from the normal pattern to calculate an integrated risk score. First, the transaction pattern analysis unit (450) collects transaction characteristic data including transaction time, day of the week, location, payment location type, transaction amount, transaction method, terminal information, network information, etc., and converts the data into a normalized transaction characteristic vector.

[0201] Next, the transaction pattern analysis unit (450) selects only past normal transactions over a certain period and models the usage frequency distribution by time of day and day of the week, the average amount and variance by payment location type, the frequency of appearance by region and country, terminal usage patterns, time intervals between consecutive transactions, and patterns of change in amount in a multidimensional feature space. In this process, a clustering algorithm or density estimation technique may be applied, thereby expressing the normal transaction area for each user as a structure of multiple cluster centers and covariances, and enabling the calculation of relative distances for new transactions.

[0202] Subsequently, when a new transaction occurs, the transaction pattern analysis unit (450) calculates a feature-specific deviation distance value indicating how much each feature value of the transaction deviates from the past normal pattern. The feature-specific deviation distance includes amount deviation, time zone deviation, location deviation, terminal deviation, and consecutive transaction pattern deviation, and each deviation is expressed as a normalized non-negative distance value, such as the Mahalanobis distance to the cluster center or the log-likelihood difference from the probability density function of the normal pattern. The transaction pattern analysis unit (450) integrates the multiple deviation distances calculated above to generate a single risk score, at which time the risk score can be calculated through the non-linear transformation formula of [Equation 3].

[0204] [Mathematical Formula 3]

[0205]

[0206] R t : Integrated risk score of transactions that occurred at time t

[0207] d k (t): Normalized deviation distance value for the k-th feature

[0208] w k : Weights reflecting the extent to which the corresponding feature contributes to identifying abnormal transactions

[0209] exp(): exponential function

[0211] In addition, the transaction pattern analysis unit (450) enables adaptive risk analysis that reflects the characteristics of individual users and payment destinations by automatically adjusting weights based on feedback data regarding past abnormal transaction judgment results and actual fraud.

[0212] Finally, the transaction pattern analysis unit (450) stores the calculated integrated risk score and deviation distance values ​​for each feature together with the transaction log, and transmits the information to the approval strategy decision unit (455) so that it can be used in subsequent steps for determining the risk grade, calculating the priority of consenters, and determining the approval strategy. In this way, the transaction pattern analysis unit (450) calculates risk through the non-linear integration of multidimensional feature deviations rather than simple threshold-based judgment, thereby enabling more precise and adaptive abnormal transaction detection compared to existing technology.

[0213] The approval strategy determination unit (455) performs the function of automatically selecting an approval strategy suitable for each transaction based on the integrated risk score and transaction characteristic data provided by the transaction pattern analysis unit (450). The approval strategy determination unit (455) classifies the risk score into multiple grades of normal, warning, and high risk, and dynamically switches the approval request method corresponding to each grade, thereby enabling a quick and accurate response in the event of an abnormal transaction.

[0214] First, the approval strategy decision unit (455) determines the risk grade by comparing the integrated risk score transmitted from the transaction pattern analysis unit (450) with a preset reference value. For example, if the risk score is 0.0 or higher and less than 0.6, it is classified as a normal transaction; if it is 0.6 or higher and less than 0.8, it is classified as a borderline transaction; and if it is 0.8 or higher, it is classified as a high-risk transaction. Based on this risk grade, the approval strategy decision unit (455) sets the method of approval request, target group, and response requirement conditions differently.

[0215] When classified as a normal transaction, the approval strategy decision unit (455) designates an approver among the registered general approvers who has a fast recent response speed or a stable approval history as a priority target, and performs the payment approval procedure using a single approval request method. At this time, the approval strategy decision unit (455) sets the response timeout relatively long and processes it in the same way as a normal transaction flow.

[0216] When classified as a boundary transaction, the approval strategy decision unit (455) re-selects approval candidates based on the top group of highly reliable approvers and sets the response timeout shorter than that of a normal transaction to ensure rapid payment verification. Additionally, if necessary, a sequential approval method can be applied in which the approval request is immediately transferred to the next-ranked approver within the same group in the event of a first approval failure.

[0217] In the case of a transaction classified as high-risk, the approval strategy decision unit (455) does not determine whether to settle based solely on the approval result of a general approver, but requests approval from a group of approvers with high authority, such as a guardian, a guardian, or a legal representative. At this stage, the approval strategy decision unit (455) sets a very short response timeout to quickly determine whether to grant urgent approval, and also reviews an immediate blocking policy or an approval hold policy for high-risk transactions to determine the final approval strategy.

[0218] Additionally, the approval strategy determination unit (455) combines information such as each approver's score, approval accuracy, approval failure history, and response speed provided by the consenter priority score calculation unit (480) to automatically select the most suitable approver within the same risk class. Through this, the approval strategy determination unit (455) can generate an optimal approval strategy in real time that comprehensively considers the transaction risk level and the approver's reliability.

[0219] The approval strategy determination unit (455) transmits the finally determined approval strategy information to the approval request control unit (435), and the approval request control unit (435) transmits an approval request signal to the approver according to the strategy and receives a response to determine whether to approve the payment. Through the operational structure of the approval strategy determination unit (455) as described above, the present invention implements an intelligent approval strategy that dynamically reflects the risks of the transaction and the characteristics of the approver, thereby enabling stable and efficient payment approval even in abnormal transaction situations.

[0220] The consenter priority score calculation unit (460) performs the function of quantitatively calculating the priority for each consenter by reflecting the approval method and the risk grade of the transaction determined by the approval strategy decision unit (455). The consenter priority score calculation unit (460) calculates a comprehensive score for each consenter by evaluating not only static elements such as role grade, approval authority scope, and registration order, but also dynamic elements such as response speed, approval accuracy, approval failure history, and abnormal transaction response history. This comprehensive score is used as a key indicator in the step of automatically selecting consenters subject to approval requests.

[0221] First, the consenter priority score calculation unit (460) calculates static elements that are fixed in advance for each consenter. Static elements include, for example, a role grade score assigned based on legal and relative influence such as whether the consenter is a legal representative or family relationships, an approval range score reflecting the range of approval allowed by the consenter, and a priority registration score based on the time of registration. These static elements are set at the time of initial registration for each user and have the characteristic of not changing significantly over time.

[0222] Next, the consenter priority score calculation unit (460) calculates dynamic factors using the consenter's real-time behavior data and past approval history. The dynamic factors include the average response speed to approval requests, the recent approval success rate, the reliability of response in abnormal transaction situations, and the frequency of approval failures. In particular, since the response speed is directly related to the efficiency of processing approval requests, a high weight can be assigned to it among the dynamic factors. Additionally, consenters who repeatedly fail to approve have lower reliability, so this is reflected as a deduction factor.

[0223] The consenting priority score calculation unit (460) combines all of the above static and dynamic elements and then calculates the final priority score of each consenting person using the following [Equation 4].

[0225] [Mathematical Formula 4]

[0226]

[0228] P i : Final priority score of the i-th agreeer

[0229] S i : Weighted sum of static factors such as role grade, approval scope, and registration order

[0230] D i : Weighted sum of dynamic factors such as response speed, approval accuracy, and abnormal transaction response history

[0231] F i : Penalty factors reflecting frequency of approval failures, etc.

[0232] α, β, γ: Non-negative weights that adjust the contributions of the static, dynamic, and penalty factors, respectively.

[0233] σ(): A non-linear activation function that normalizes scores to a range between 0 and 1.

[0235] By using such a non-linear transformation, it is possible to control the total score so that it does not stably exceed the threshold even if a specific feature value increases rapidly, thereby allowing for more precise priority calculation. The consenting priority score calculation unit (460) automatically selects the highest priority approval target by sorting the list of consenting persons in descending order based on the final priority score calculated by [Equation 4].

[0236] In addition, the final priority score is immediately recalculated based on the consenter's real-time response data or changes in the approval strategy, thereby enabling the continuous selection of the optimal consenter even in transaction situations where the approval request flow changes dynamically. The final calculated priority score is transmitted to the approval request control unit (435) and used to determine the actual consenter subject to the approval request. Through this structure, the present invention realizes an intelligent priority calculation function that quantitatively reflects the reliability, response performance, and approval history among consenters.

[0238] FIG. 3 is a flowchart illustrating an embodiment of a method for controlling consenter priority based on abnormal transactions according to the present invention.

[0239] Referring to FIG. 3, when the payment approval agency management server (400) receives a transaction request from a user, it evaluates the possibility of an abnormal transaction in the transaction request (step S310).

[0240] The payment approval agency management server (400) determines an approval strategy corresponding to the possibility of an abnormal transaction (step S320).

[0241] The payment approval agency management server (400) calculates priority scores for multiple consenters and then automatically selects the consenter with the highest score according to the priority scores to perform an approval request (step S330).

[0242] The payment approval agency management server (400) automatically transfers the approval request to the next-ranked consenter if the approval response is not received or if approval fails (step S340).

[0243] The payment approval agency management server (400) controls the recording of the approval result to the blockchain server (step S350).

[0245] FIG. 4 is a diagram illustrating an example for explaining the configuration of a consenter registration and approval condition setting screen in an abnormal transaction-based consenter priority control system according to the present invention.

[0246] Referring to FIG. 4, the payment approval agency management server (400) is a component that consistently controls the entire process from the user's service sign-up stage to inviting consenters, registering consenters and setting approval conditions, saving approval policies, and managing consenter approval history. The screen procedure illustrated in FIG. 4(a) to FIG. 4(e) is an example for understanding the operation process performed by the payment approval agency management server (400).

[0247] In one embodiment, the payment authorization agency management server (400) receives a service subscription request from a new user through the service subscription screen of FIG. 4(a). The payment authorization agency management server (400) performs user identification information generation, account registration, initial state initialization, etc., and configures an initial environment for consenting user registration.

[0248] In another embodiment, the payment authorization agency management server (400) controls the display of the invitation screen of FIG. 4(b-1) when the user executes the consenter invitation function. The payment authorization agency management server (400) receives the KakaoTalk identifier or phone number information entered in the consenter message sending button and the consenter input field to verify the validity of the invitation target. It also controls the screen configuration to notify that personal information is not stored through an information non-storage notice area.

[0249] In another embodiment, when the consenter invitation procedure is in progress, the payment approval agency management server (400) controls the detailed invitation screen of FIG. 4(b-2) to receive information entered through the consenter name input field, phone number input field, and message sending button. The payment approval agency management server (400) generates an invitation message based on the entered consenter information and sends it to the consenter terminal (300), and enables the consenter authentication procedure to be performed through the consenter authentication management unit (405).

[0250] In another embodiment, the payment approval agency management server (400) configures the consenter list screen (40) of FIG. 4(c) after consenter registration is completed and provides it to the payment executor terminal (100). The registered consenter list items are configured based on information stored by the consenter profile management unit (410) of the server, and the user can move to the consenter setting step through the list.

[0251] In another embodiment, the payment approval agency management server (400) controls the setting screen of FIG. 4(d) when the user sets the consenter approval conditions.

[0252] The payment approval agency management server (400) provides a priority setting area, a minimum approval amount setting area, a minimum amount input field, a detailed approval condition setting area, etc., and each area includes financial transaction conditions, cash withdrawal conditions, goods purchase conditions, purchase amount standard conditions, etc. The payment approval agency management server (400) stores the approval condition data entered by the user in the approval condition storage unit (415) and configures the application policy and approval structure for each consenter.

[0253] In another embodiment, the payment approval agency management server (400) determines in real time whether the transaction requires consenter approval by linking with the approval judgment unit (430) and the transaction request analysis unit (420) when a transaction occurs after the approval conditions are stored. In the determination process, the conditions of FIG. 4(d) are reflected in the consenter-specific policy table, and whether the conditions are satisfied is evaluated for each transaction.

[0254] In another embodiment, when the payment approval agency management server (400) receives a request to look up the consenter approval history, it controls the approval history screen of FIG. 4(e) to display the approval time, approval type, and details buttons. This screen is configured by looking up the stored approval history and the approval transaction data stored in the blockchain server (500).

[0255] In another embodiment, the payment approval agency management server (400) automatically reflects the changes to the approval judgment unit (430) and the approval request control unit (435) when the approval conditions or consenter structure selected by the user are changed. This configures the policy evaluation to be affected in real time by changes in consenter priority, adjustment of the approval condition range, or adjustment of the minimum approval amount.

[0256] In another embodiment, the payment approval agency management server (400) prevents tampering by storing consenter registration events, approval condition setting events, approval requests, and approval result data occurring throughout the operation process of the present invention in a log format or recording them on the blockchain server (500). The approval history information illustrated in FIG. 4(e) is displayed based on this recorded data.

[0257] In this way, the payment approval agency management server (400) functions as a core component that manages the overall operation of the abnormal transaction-based consenter priority control system according to the present invention by controlling the entire process starting from the service subscription stage (Fig. 4(a)), to the invitation of consenters (Fig. 4(b-1), Fig. 4(b-2)), the registration and list lookup of consenters (Fig. 4(c)), the setting of approval conditions (Fig. 4(d)), and the management of approval history (Fig. 4(e)).

[0259] FIG. 5 is an example screen diagram illustrating the AI-based asset protection setting procedure performed by the payment approval agency management server according to the present invention.

[0260] Referring to FIG. 5, FIG. 5(a) is a screen for explaining the initial subscription procedure of an AI asset protection service provided by a payment approval agency management server (400) according to the present invention through a user terminal. The screen of FIG. 5(a) includes a subscription selection area for activating the My Asset Protection function, and when the payment approval agency management server (400) receives a request to subscribe to the AI ​​asset protection service from a user, it registers the user as an active user of the asset protection service. After confirming the subscription, the server performs control to call the next step setting screen so that the user can set approval conditions.

[0261] FIG. 5(b) is a screen displaying approval condition items that can be set by a user in the AI ​​asset protection service according to the present invention. The screen of FIG. 5(b) includes a notification amount minimum amount setting area and a protection detailed setting area. The notification amount minimum amount setting area provides a function to set a threshold so that an approval procedure or an AI-based risk assessment procedure is performed when the transaction amount exceeds a specific standard. When the user sets an amount in the corresponding input field, the payment approval agency management server (400) records it in the approval condition storage unit (415).

[0262] In addition, the detailed settings area of ​​the screen in Fig. 5(b) is configured to allow individual settings for financial transaction conditions, minimum balance conditions, product purchase conditions, and monthly cumulative purchase amount conditions. Financial transaction conditions are conditions for activating a pre-approval procedure for specific types of financial transactions, and minimum balance conditions are conditions requiring a guardian approval procedure when the account balance falls below a certain threshold. Product purchase conditions and monthly cumulative purchase amount conditions define conditions for determining whether approval is required based on the cumulative expenditure amount by consumption category or over a certain period.

[0263] When the payment approval agency management server (400) receives each condition value set in FIG. 5(b), it stores it in the approval condition storage unit (415) and determines whether approval is required for subsequent transaction requests based on the stored conditions. The payment approval agency management server (400) evaluates information such as transaction type, amount, and vendor through the transaction request analysis unit (420) and the abnormal transaction detection linkage unit (425), and determines whether to perform the consenter approval procedure by comparing it with the condition value set by the user in FIG. 5(b).

[0264] In addition, the payment approval agency management server (400) updates the operation policy of the approval judgment unit (430) by reflecting the approval conditions set by the user in real time according to the screen configuration shown in FIG. 5(a) and FIG. 5(b), and when the approval policy per transaction changes, it transmits the policy change to the approval request control unit (435) so that the approval request processing procedure is applied accurately.

[0265] As described above, FIGS. 5(a) and FIGS. 5(b) illustrate an exemplary control flow performed by the payment approval agency management server (400) according to the present invention during the AI ​​asset protection service subscription and approval condition setting step, and the server implements an intelligent asset protection function by receiving user subscription information, storing approval conditions, reflecting approval policies, and performing evaluations for each transaction.

[0267] Although the present invention has been described by the embodiments and drawings described above, the present invention is not limited to the above embodiments, and various modifications and variations are possible from this description by those skilled in the art to which the present invention pertains. Accordingly, the concept of the present invention should be understood only by the claims set forth below, and all equivalent or analogous variations thereof shall be considered to fall within the scope of the concept of the present invention. Explanation of the symbols

[0269] 100: Payment executor terminal 200: Sales outlet terminal 300: Consent terminal 400: Payment authorization management server 405: Consent Authentication Management Department 410: Consent Profile Management Department 415: Approval Condition Storage 420: Transaction Request Analysis Department 425: Anomaly Detection Integration 430: Approval Judgment Department 435: Approval Request Control Unit 440: Signature Verification Department 445: Payment Approval Department 450: Trading Pattern Analysis Department 455: Approval Strategy Decision Department 460: Consent Priority Score Calculation Unit 500: Blockchain Server

Claims

Claim 1 An abnormal transaction-based consenter priority control system comprising a payment executor terminal, a vendor terminal, a consenter terminal, and a payment approval agency management server, wherein the payment approval agency management server comprises: a transaction request receiving unit that receives transaction request data from a user terminal; an abnormal transaction analysis unit that calculates a risk score by analyzing the possibility of an abnormal transaction based on the transaction amount, transaction location, transaction time, user transaction history, and terminal information included in the transaction request data; an approval strategy determination unit that determines an approval strategy based on the risk score; a consenter priority calculation unit that calculates a priority score per consenter based on authority information, response speed information, approval success rate information, and abnormal transaction response history for multiple consenters; an approval request control unit that selects the consenter with the highest priority based on the consenter priority score and transmits an approval request; and an approval flow control unit that automatically switches the approval request to the next-ranked consenter if an approval response is not received from the selected consenter or if an approval rejection response is received, wherein the abnormal transaction analysis unit calculates the risk score according to [Equation 3] below, and the consenter priority calculation unit calculates the consenter priority score according to [Equation 4] below, and [Equation 3] R t represents the integrated risk score of transactions that occurred at time t, and d k (t) represents the normalized deviation distance value for the k-th feature, and w k represents a weight reflecting the extent to which a feature contributes to the detection of abnormal transactions, exp() represents an exponential function, and [Equation 4] P i represents the final priority score of the i-th agreeer, and S i represents the weighted sum of static factors such as role grade, approval scope, and registration order, and D i represents the weighted sum of dynamic factors such as response speed, approval accuracy, and abnormal transaction response history, and F i An abnormal transaction-based consenter priority control system characterized by the fact that represents a penalty element reflecting the frequency of approval failure, etc., α, β, and γ represent non-negative weights that adjust the contribution of a static element, a dynamic element, and a penalty element, respectively, and σ() represents a non-linear activation function that normalizes the score to a range of 0 or more and 1 or less. Claim 2 An abnormal transaction-based consenter priority control system according to claim 1, wherein the payment approval agency management server classifies transactions into normal, borderline, or high-risk grades based on an integrated risk score and sets the approval request target group, response waiting time, and approval request switching method differently in correspondence with the risk grade. Claim 3 An abnormal transaction-based consenter priority control system according to claim 1, wherein the payment approval agency management server calculates a consenter priority score by weighting multiple factors including the consenter's role grade, approval authority scope, response speed, approval success rate, approval failure history, and abnormal transaction response history, sorts consenters in descending order according to the calculated score, performs an approval request preferentially to the consenter with the highest score, and automatically switches the approval request to the next-ranked consenter in the event of a response failure. Claim 4 A method for controlling consenter priority based on abnormal transactions performed by a payment approval agency management server, comprising: a step in which the payment approval agency management server receives transaction request data from a payment executor terminal or a vendor terminal; a step in which the payment approval agency management server analyzes the possibility of abnormal transactions and calculates a risk score based on transaction amount, transaction location, transaction time, user transaction history, and terminal information included in the transaction request data; a step in which the payment approval agency management server determines an approval strategy based on the risk score; a step in which the payment approval agency management server calculates a priority score for each consenter based on authorization information, response speed information, approval success rate information, and abnormal transaction response history for a plurality of consenters; and a step in which the payment approval agency management server selects the consenter with the highest priority based on the consenter priority score and transmits an approval request. and the above payment approval agency management server includes a step of automatically transferring the approval request to the next-ranked consenter if an approval response is not received from the selected consenter or if an approval rejection response is received, and the step of calculating the risk score calculates the integrated risk score according to [Equation 3] below, and the step of calculating the consenter-specific priority score calculates the consenter priority score according to [Equation 4] below, [Equation 3] R t represents the integrated risk score of transactions that occurred at time t, and d k (t) represents the normalized deviation distance value for the k-th feature, and w k represents a weight reflecting the extent to which a feature contributes to the detection of abnormal transactions, exp() represents an exponential function, and [Equation 4] P i represents the final priority score of the i-th agreeer, and S i represents the weighted sum of static factors such as role grade, approval scope, and registration order, and D i represents the weighted sum of dynamic factors such as response speed, approval accuracy, and abnormal transaction response history, and F i An abnormal transaction-based consenter priority control method characterized by the fact that represents a penalty element reflecting the frequency of approval failure, etc., α, β, and γ represent non-negative weights that adjust the contribution of a static element, a dynamic element, and a penalty element, respectively, and σ() represents a non-linear activation function that normalizes the score to a range of 0 or more and 1 or less. Claim 5 A method for controlling consenter priority based on abnormal transactions, characterized in that, in claim 4, the payment approval agency management server further comprises the step of classifying a transaction into a normal, borderline, or high-risk grade based on an integrated risk score; and the payment approval agency management server differently sets the approval request target group, response waiting time, and approval request switching method in response to the risk grade. Claim 6 A method for controlling consenter priority based on abnormal transactions according to claim 4, characterized in that the payment approval agency management server calculates a consenter priority score by weighting and evaluating a plurality of factors including the consenter's role grade, approval authority scope, response speed, approval success rate, approval failure history, and abnormal transaction response history; sorts consenters in descending order according to the calculated score and performs an approval request preferentially to the consenter with the highest score; and automatically switches the approval request to the next-ranked consenter if the response fails as a result of the above execution.

Images