WO2023022551A1 - 계정별로 자산 거래를 지원하기 위한 방법, 시스템 및 비일시성의 컴퓨터 판독 가능 기록 매체 - Google Patents

계정별로 자산 거래를 지원하기 위한 방법, 시스템 및 비일시성의 컴퓨터 판독 가능 기록 매체 Download PDF

Info

Publication number
WO2023022551A1
WO2023022551A1 PCT/KR2022/012384 KR2022012384W WO2023022551A1 WO 2023022551 A1 WO2023022551 A1 WO 2023022551A1 KR 2022012384 W KR2022012384 W KR 2022012384W WO 2023022551 A1 WO2023022551 A1 WO 2023022551A1
Authority
WO
WIPO (PCT)
Prior art keywords
trader node
node
trader
transaction
account
Prior art date
Application number
PCT/KR2022/012384
Other languages
English (en)
French (fr)
Inventor
하재우
Original Assignee
주식회사 트루테크놀로지스
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from KR1020210153841A external-priority patent/KR20230028091A/ko
Application filed by 주식회사 트루테크놀로지스 filed Critical 주식회사 트루테크놀로지스
Publication of WO2023022551A1 publication Critical patent/WO2023022551A1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/06—Asset management; Financial planning or analysis

Definitions

  • the present invention relates to a method, system, and non-transitory computer-readable recording medium for supporting asset transactions on an account-by-account basis.
  • Securities lending & borrowing transaction is the consumption of securities whereby a lender agrees to transfer ownership of securities to a borrower, and the borrower agrees to return securities of the same issue and quantity as the relevant securities. means a contract of exchange.
  • a lending transaction is established, the right to dispose of the securities and the source of income are transferred to the borrower, and in return, the borrower receives the economic benefits that the lender would have received if the lender had not made the lending transaction, such as dividends in the form of cash or stocks, and free stock. , paid stocks, etc. will be compensated.
  • SLB transactions are used to achieve various purposes. Specifically, short selling, arbitrage trading through short selling (arbitrage transaction), and use as collateral (collateral usage) ), use for payment substitution (fail coverage), use for replacing the balance volume requested for collection in an existing loan transaction with a new balance volume (recall coverage), and replacement of the balance volume in the existing loan transaction with a lower commission fee It is being used for refinancing and for replacement of the existing borrowing volume with a more stable borrowing volume.
  • the information possessed by both parties in the SLB transaction may be different. This, for example, when consultations are made by phone or messenger, if there is an error in the information confirmed by both parties, this may cause a serious error such as non-borrowed short selling or payment failure. This is because validation of the details of the agreement between the two parties is not properly performed, and in the current method, such validation is performed according to arbitrary interpretation by humans.
  • the provider of such a platform (for example, Exchange) owns all information, and transactions have been discovered and confirmed according to the algorithms and methods set by them.
  • the platform provider manages all information, so the confidentiality of transaction information of transaction participants is not guaranteed, and it is inevitably vulnerable to external attacks.
  • the discovery and confirmation of a transaction had to depend on a single service provider, the nature of the over-the-counter market, in which one could freely trade with the desired participant according to the desired conditions and method, was inevitably diluted. (or, in the case of the quotation competition method, even after the transaction is finalized), there has been a case where even the counterparty to the transaction is not known.
  • one or more traders may individually discover and confirm transactions with one or more counterparties (e.g., lenders) for multiple transactions without centralized transaction discovery and confirmation.
  • counterparties e.g., lenders
  • the object of the present invention is to solve all the problems of the prior art described above.
  • the present invention discovers and negotiates asset transactions based on a decentralized method (eg, individual-individual, individual-institution, peer to peer (P2P) between institutions and institutions) rather than a centralized method. And the purpose of the confirmation process is to be performed efficiently and quickly.
  • a decentralized method eg, individual-individual, individual-institution, peer to peer (P2P) between institutions and institutions
  • P2P peer to peer
  • an object of the present invention is to assist a transaction participant to make a transaction according to the desired counterparty or desired conditions.
  • an object of the present invention is to ensure confidentiality by segregating and storing information associated with each transaction by participant in each transaction, rather than in a centralized database.
  • an object of the present invention is to prevent errors and erroneous transactions in asset transactions by verifying the validity of asset transactions based on distributed two-way communication information.
  • an object of the present invention is to support discovery and confirmation of transactions for each account when a SLB transaction participant owns a plurality of accounts.
  • a method for supporting asset trading on a per-account basis comprises providing offer information from at least one trader node to a first trader node, and providing offer information to a first trader node of the offer information. Included in at least one account included in the first trader node and a second trader node that provided the offer information to be accepted, based on offer information to be accepted determined by referring to the first transaction condition of the node A method is provided that includes confirming a transaction between at least one account that is
  • a system for supporting asset trading for each account includes an offer information management unit configured to provide offer information from at least one trader node to a first trader node, and the offer information of the first trader node. At least one account included in the first trader node and the second trader node that provided the offer information to be accepted based on the offer information to be accepted determined by referring to the first trade condition of the first trader node. There is provided a system including a transaction confirmation management unit for confirming a transaction between at least one account included in.
  • discovery, consultation and management of asset transactions based on a decentralized method (eg, peer to peer (P2P) between individuals-individuals, individuals-institutions, institutions-institutions, etc.) rather than a centralized method.
  • P2P peer to peer
  • the confirmation process can be carried out efficiently and quickly.
  • the participant himself/herself can trade according to the conditions desired by the other party or the participant himself/herself.
  • confidentiality can be guaranteed by separately storing information associated with each transaction by participant in each transaction rather than in a centralized database.
  • FIG. 1 is a diagram showing a schematic configuration of an entire system supporting asset trading according to an embodiment of the present invention.
  • FIGS. 2 and 5 are diagrams illustratively illustrating a process in which asset trading is supported according to an embodiment of the present invention.
  • 3, 4 and 6 to 8 are diagrams illustrating user interface screens for supporting asset trading according to an embodiment of the present invention by way of example.
  • FIG. 9 is a diagram exemplarily illustrating a process of supporting asset trading for each account according to an embodiment of the present invention relating to asset trading support for each account.
  • 10 to 13 are diagrams exemplarily illustrating user interface screens provided based on an embodiment of asset transaction support for each account of the present invention.
  • Assets as used herein are a concept that collectively refers to financial assets (eg, securities), non-financial assets (eg, real estate), other assets (eg, virtual currency, points, mileage, etc.), It should be understood in the broadest sense that covers all objects with economic value.
  • financial assets eg, securities
  • non-financial assets eg, real estate
  • other assets eg, virtual currency, points, mileage, etc.
  • the securities referred to in this specification refer to a document indicating the right to claim a certain amount of money or valuables such as cargo in advance, that is, a certificate indicating property rights under the commercial law, and the value mentioned in this specification Securities should be understood in the broadest sense, encompassing all types of objects that can be the subject of Securities Lending and Borrowing Transaction, not necessarily limited to securities regulated by the Commercial Act or the Securities and Exchange Act.
  • securities referred to in this specification include listed stocks, unlisted stocks, bonds, beneficiary certificates, warrants, financial products including beneficiary certificates, futures, derivative products including equity swaps, ELS (Equity-Linked Securities), ELW (Equity-Linked Warrant), BW (Bond with Warrant), CB (Convertible Bond), ETF (Exchange Fund, Exchange Traded Funds), ETNs (Exchange Traded Notes), etc. can all be included.
  • the entire system may be configured to include a communication network, a plurality of nodes 100 and the asset trading system (200).
  • a communication network may be configured regardless of communication aspects such as wired communication or wireless communication, and may include a local area network (LAN), a metropolitan area network (MAN), and a wide area network. It may be configured with various communication networks such as a wide area network (WAN).
  • LAN local area network
  • MAN metropolitan area network
  • WAN wide area network
  • the communication network referred to in this specification may be the well-known Internet or the World Wide Web (WWW).
  • WWW World Wide Web
  • the communication network may include, at least in part, a known wired/wireless data communication network, a known telephone network, or a known wire/wireless television communication network without being limited thereto.
  • the communication network is a wireless data communication network, and includes WiFi communication, WiFi-Direct communication, Long Term Evolution (LTE) communication, and Bluetooth communication (e.g., Bluetooth Low Energy (BLE)). It may implement a conventional communication method such as low energy (low energy) communication), infrared communication, ultrasonic communication, and the like, at least in part.
  • WiFi communication WiFi-Direct communication
  • LTE Long Term Evolution
  • Bluetooth communication e.g., Bluetooth Low Energy (BLE)
  • BLE Bluetooth Low Energy
  • It may implement a conventional communication method such as low energy (low energy) communication), infrared communication, ultrasonic communication, and the like, at least in part.
  • a plurality of nodes 100 is a contact point or connection point capable of communicating with other nodes 100 through a communication network, such as a server, computer, laptop, smartphone, tablet PC. (i.e., a digital device equipped with a memory unit and equipped with a microprocessor and capable of computing) or a logical node by an application, program module, virtual machine, etc. (i.e., a virtual node) ) may be a concept including.
  • a transaction support system for supporting asset transaction may be installed or included in the plurality of nodes 100 according to an embodiment of the present invention in the form of a program module such as an application or widget. Also, such a program module may be downloaded from an external application distribution server (not shown) or an external system (not shown). If necessary, the above transaction support system may be operated based on Distributed Ledger Technology (DLT).
  • Distributed ledger here may refer to a method in which information related to asset transactions between the nodes of two parties is encrypted or irreversible and distributed to two parties (or other parties) and managed by being distributed and managed.
  • a predetermined hash function eg, Message-Digest algorithm 5 (MD5)), hash operation, encryption algorithm (cryptography) algorithm), etc., known irreversible conversion or non-repudiation techniques may be used.
  • the plurality of nodes 100 above may include nodes of various types of participants associated with asset trading according to purpose, authority, etc.
  • a plurality of nodes 100 may include a first trader node 110 that initiates asset trading and accepts offer information, and a second trader node 120 that provides offer information and provides acceptance confirmation information for the acceptance information.
  • the plurality of nodes 100 above may further include a transaction verification node, a regulator node, an intermediary node, a broker node, a depository institution node, an asset manager node, and the like.
  • the above trading support system allows offer information to be provided from at least one trader node to the first trader node 110, and the first trader node 110 of the offer information
  • a function of confirming a transaction between the first trader node 110 and the second trader node 120 that provided the offer information to be accepted based on the offer information to be accepted determined by referring to the first transaction condition can be performed.
  • the transaction support system has been described as above, this description is exemplary, and at least some of the functions or components required for the transaction support system are provided by a plurality of nodes 100 (eg, a first Trader node 110, second trader node 120, third trader node 130, etc.) or realized within an external system (not shown) or a plurality of nodes 100 (e.g., first trader node) (110), the second trader node 120, the third trader node 130, etc.) or an external system is apparent to those skilled in the art.
  • nodes 100 eg, a first Trader node 110, second trader node 120, third trader node 130, etc.
  • a user uses an application including at least some of the functions of the transaction support system according to the present invention in his or her node, or at least one of the functions of the transaction support system according to the present invention.
  • asset transactions e.g., lending, borrowing
  • the asset trading system 200 when the asset trading system 200 according to an embodiment of the present invention receives information about asset transactions between a plurality of trader nodes, transfer, lending, borrowing, buying, It can perform a function that allows transactions such as selling to be executed.
  • an asset according to an embodiment of the present invention is securities
  • the above asset trading system 200 may be used in Stock Exchanges, Securities Depository, Clearing Houses, etc. It may be partly similar to the system operated by
  • the transaction support system may include an offer information management unit, a transaction confirmation management unit, and an effectiveness management unit.
  • the offer information management unit, the transaction confirmation management unit, and the validity management unit may be program modules in which at least a part communicates with an external system.
  • These program modules may be included in the transaction support system in the form of an operating system, application program modules, or other program modules, and may be physically stored in various known storage devices. Also, these program modules may be stored in a remote storage device capable of communicating with the transaction support system. Meanwhile, these program modules include routines, subroutines, programs, objects, components, data structures, etc. that perform specific tasks or execute specific abstract data types according to the present invention, but are not limited thereto.
  • the offer information management unit may perform a function of providing offer information from at least one trader node to the first trader node 110 .
  • At least one trader node according to an embodiment of the present invention is a network associated with the first trader node 110 (eg, a network dynamically configured with reference to user information of the first trader node or a first trader node). It may be a node existing in a network specified by a node) or a node existing in an open network without separate restrictions.
  • offer information associated with the first transaction condition is sent from at least one trader node to the first trader node ( 110) can be provided.
  • the type, quantity, amount, commission rate eg, loan commission rate
  • date type and amount of collateral required for the transaction
  • dividend rights relationship liability (corporate action liability)
  • conditions on the subject of the transaction such as recall availability, first-come-first-served basis, total score order, highest profit, available to first taker (for example, the person who confirms the proposed quantity first securing), competitive bidding (for example, when the first trader node 110 is a lender node, the trader node 120 that presented the highest commission rate during a predetermined period among borrower nodes secures the corresponding amount ) (For example, when the second trader node 120 is a lender node, the trader node 110 that presented the highest commission rate during
  • the offer information management unit may provide at least one node with information about the asset transaction start when asset transaction initiation based on the first transaction condition set by the first trader node 110 is requested. .
  • the information on the above asset transaction initiation is provided to a plurality of trader nodes (or nodes that exist in an open network without separate restrictions) existing in the network specified by the first trader node 110, one-to-many It is a one-to-one transaction, and if the information on the start of the asset transaction is provided to one trader node existing in the network specified by the first trader node 110.
  • the offer information management unit determines offer information associated with the first transaction condition above by referring to assets that require rental or borrowing specified in the above first transaction condition and assets that can be rented or borrowed from at least one trader node. can be made That is, the offer information management unit compares the borrowable assets of at least one trader node with the borrowing required quantity specified in the first transaction condition, and determines a predetermined quantity of the lendable assets (eg, 10% of the lendable assets) and 1 The above offer information can be determined based on the smaller amount among the required borrowing quantities specified in the transaction conditions.
  • the offer information management unit sets at least one of the preference, commission rate, quantity, date, asset type, amount, type of collateral required for transaction and amount of collateral required for transaction, recall status, and right relationship set by at least one trader node.
  • Offer information associated with the above first transaction condition may be determined by referring to the condition related to . More specifically, the offer information management unit provides offer information based on the set commission rate or the commission rate specified in the first transaction condition when the commission rate specified in the first transaction condition is higher than the commission rate set by at least one trader node. can be determined.
  • the offer information management unit may selectively provide offer information to trader nodes that match the second trade condition of at least one trader node.
  • the offer information management unit when a plurality of asset transactions are requested from a plurality of trader nodes, a specific transaction condition (ie, a second transaction condition set in at least one trader node) among the plurality of asset transactions is initiated.
  • Offer information can be selectively provided to trader nodes associated with asset transaction initiation that satisfies . That is, offer information may not be provided to all trader nodes, but offer information may be selectively provided only to trader nodes meeting set conditions.
  • the offer information manager may automatically provide offer information when a trader node matching the second trade condition of at least one trader node is specified.
  • the offer information management unit includes asset transaction initiation that satisfies a specific transaction condition (ie, the second transaction condition set in at least one of the above trader nodes) among a plurality of asset transaction initiations requested from a plurality of trader nodes.
  • a specific transaction condition ie, the second transaction condition set in at least one of the above trader nodes
  • offer information may be automatically provided to the specified trader node. That is, when a trader node that satisfies the set conditions appears, offer information can be automatically provided.
  • the offer information management unit may provide offer information from at least one trader node by referring to at least one of priority given to each trader node, weight, and preference for each trade condition (or preference criterion or preference value).
  • the above priority, weight, and preference for each trading condition are preset by each of a plurality of trader nodes or dynamically (eg, updated every predetermined period by analyzing the trader node's trading propensity). may be set.
  • the offer information management unit allows offer information to be provided first to a trader node having the highest priority given to each trader node, and a transaction for the offer information has not been confirmed or a predetermined time has elapsed since the offer information has been provided. In the last case, offer information can be provided to the next trader node.
  • the offer information management unit refers to a weight set by at least one trader node (eg, the weight may be set based on the type, quantity, amount, and commission rate of an asset, respectively).
  • the weight may be set based on the type, quantity, amount, and commission rate of an asset, respectively.
  • Calculate the score for the trading condition provided from the trader node of (for example, this score may also include a boolean form or a numerical value), and determine the trading condition whose score is above a predetermined level (or the highest score). Offer information can be provided to trader nodes that provide it.
  • the offer information management unit may provide offer information by referring to an order in which transaction initiation information based on the first transaction condition is provided from the first trader node to at least one node above.
  • the offer information management unit may refer to the order in which transaction start information is provided from the first trader node to at least one node above so that the offer information is provided to the first trader node that provided the trade start information most quickly. there is.
  • the offer information management unit provides transaction initiation information that has a profit (or highest profit) over a predetermined level among transaction initiation information requested (or provided) based on the first transaction condition from the first trader node 110 Offer information may be provided to the first trader node 110 .
  • Offer information management unit when the offer information management unit is set to the highest profit transaction method (eg, bidding method), the most profitable transaction among the transaction initiation information requested from the first trader node 110 (that is, the profit is maximized) Offer information may be provided to the first trader node 110 that has provided trade initiation information (eg, competitive bidding).
  • the highest profit transaction method eg, bidding method
  • the most profitable transaction among the transaction initiation information requested from the first trader node 110 that is, the profit is maximized
  • Offer information may be provided to the first trader node 110 that has provided trade initiation information (eg, competitive bidding).
  • the offer information management unit may provide offer information by referring to preference information (eg, preference or preference criterion for each trading condition) (or non-preference information) set by at least one trader node.
  • preference information eg, preference or preference criterion for each trading condition
  • non-preference information set by at least one trader node.
  • the offer information management unit may provide offer information to trader nodes matching preference information such as a minimum commission rate and a maximum quantity set by at least one trader node. Meanwhile, the offer information management unit may automatically provide offer information when there is a trader node that matches the preference information, and may not provide offer information when it does not match the preferred information. In addition, the offer information management unit may automatically set a criterion or condition (eg, a specific issue of securities) for providing (or not providing) offer information.
  • a criterion or condition eg, a specific issue of securities
  • the transaction confirmation management unit may perform a function of determining offer information to be accepted by referring to a first transaction condition among offer information provided to the first transaction node 110 .
  • the transaction confirmation management unit may determine offer information to be accepted by referring to the order in which offer information is provided from at least one trader node to the first trader node. More specifically, the transaction confirmation management unit, when the first transaction condition is set as a first-come-first-served transaction method, offers information provided first to the first transaction node 110 among offer information provided to the first transaction node 110. It can be determined as acceptance target offer information.
  • the transaction confirmation management unit has a profit (or the highest profit (eg, the highest fee for the lender and the lowest fee for the borrower) at a predetermined level or higher among the offer information provided to the first trader node 110. ), or profit maximization) may be determined as offer information to be accepted. More specifically, the transaction confirmation management unit determines offer information that is most beneficial to the first trader node 110 (that is, maximizes profits) among offer information provided to the first trader node 110 as offer information to be accepted.
  • the transaction confirmation management unit when the first transaction condition is set to the highest profit transaction method, the weight set by the first trader node 110 (eg, such a weight is the type of asset specified in the offer information, score for offer information provided from at least one trader node with reference to quantity, amount, and fee rate) (eg, this score may also include a boolean form or a numerical value) ) is calculated, and offer information having a score equal to or higher than a predetermined level (or offer information having the highest score) may be determined as offer information to be accepted.
  • the weight set by the first trader node 110 eg, such a weight is the type of asset specified in the offer information, score for offer information provided from at least one trader node with reference to quantity, amount, and fee rate
  • this score may also include a boolean form or a numerical value
  • the transaction confirmation management unit may determine acceptance target offer information by referring to priorities assigned to a plurality of trader nodes (or a plurality of traders). More specifically, the transaction confirmation management unit may determine, as offer information to be accepted, offer information of a trader node corresponding to a higher priority when the first transaction condition is a net transaction method of a higher priority trader.
  • the transaction confirmation management unit lends or borrows requested assets and offer information regarding at least one of the type, quantity, amount, and commission rate of the assets specified by the first transaction condition of the first trader node 110.
  • Acceptable offer information may be determined by comparing and analyzing borrowed or lentable assets related to at least one of the quantity, amount, and commission rate of .
  • the transaction confirmation management unit may determine offer information corresponding to a quantity less than or equal to a predetermined ratio than the quantity specified by the first transaction condition as acceptance target offer information.
  • the transaction confirmation management unit may determine offer information corresponding to a commission rate smaller than the commission rate specified by the first transaction condition as acceptance target offer information.
  • the transaction confirmation management unit determines offer information to be accepted by referring to conditions related to at least one of the type of collateral set by the first transaction condition of the first trader node 110, whether or not to recall, and the right relationship.
  • the transaction confirmation management unit determines the type of collateral set by the first transaction condition of the first trader node 110 (eg, presence or absence of cash or non-cash collateral, type of currency in the case of cash collateral, etc.)
  • offer information corresponding to the set security type may be determined as acceptance target offer information.
  • the transaction confirmation management unit determines offer information to be accepted by referring to preference information (eg, preference or preference criteria for each transaction condition) (or non-preference information) set by the first trader node 110 .
  • preference information eg, preference or preference criteria for each transaction condition
  • non-preference information set by the first trader node 110 .
  • the transaction confirmation management unit may determine offer information corresponding to preference information such as a maximum commission rate and a minimum quantity set by the first trader node 110 as offer information to be accepted.
  • the transaction confirmation management unit performs a function of finalizing a transaction between the first trader node 110 and the second trader node 120 that provided information on the offer to be accepted, based on the acceptance offer information determined above can do.
  • the transaction confirmation management unit when the offer information to be accepted is determined, provides acceptance information to the second trader node 120 that has provided the offer information to be accepted, and accepts the offer from the second trader node 120. Transactions between the first trader node 110 and the second trader node 120 may be confirmed by providing acceptance confirmation information (confirm) for the acceptance information to the first trader node 110 .
  • the transaction confirmation management unit may determine the transaction by referring to at least one of the acceptance information provided to the second transaction node 120 and the transaction conditions of the second transaction node.
  • the transaction confirmation management unit may refer to the order in which the acceptance information is provided to the second trader node 120 above (eg, first-come-first-served basis) so that the transaction is confirmed. More specifically, the transaction confirmation management unit can ensure that the transaction between the second trader node 120 and the trader node that first provided acceptance information among the plurality of acceptance information provided to the second trader node 120 above is confirmed. .
  • the transaction confirmation management unit benefits the second trader node 120 above a predetermined level among the acceptance information provided to the second trader node 120 above (or the highest profit (eg, the highest profit from the lender's point of view)
  • the transaction between the trader node and the second trader node 120 may be confirmed, which may be a fee, and may be the lowest fee from the borrower's point of view) or profit maximization).
  • the transaction confirmation management unit accepts information that is most beneficial (ie, profits are maximized) to the second trader node 120 among a plurality of acceptance information provided to the second trader node 120 (eg, The transaction between the trader node that provided the maximum commission rate, maximum quantity, etc.) and the second trader node 120 may be confirmed.
  • the transaction confirmation management unit may allow transactions to be confirmed based on priorities assigned to a plurality of trader nodes (or a plurality of traders). More specifically, when the transaction condition of the second trader node 120 is the first trader net trade method, the trade confirmation management unit, the trader node corresponding to the higher priority among the trader nodes that provided acceptance information and the second trader node (120) to ensure that the transaction between them is confirmed.
  • the transaction confirmation management unit may refer to conditions related to at least one of the type of collateral set by the transaction conditions of the second trader node 120, whether or not to recall, and the rights relationship so that the transaction is confirmed. More specifically, the transaction confirmation management unit refers to the type of collateral set by the transaction conditions of the second trader node 120 (eg, presence or absence of cash or non-cash collateral, type of currency in the case of cash collateral, etc.) A transaction between the trader node that provided acceptance information corresponding to the set security type and the second trader node 120 may be confirmed.
  • the type of collateral set by the transaction conditions of the second trader node 120 eg, presence or absence of cash or non-cash collateral, type of currency in the case of cash collateral, etc.
  • the transaction confirmation management unit may refer to preference information (eg, preference or preference criteria for each transaction condition) (or non-preference information) set by the second trader node 120 so that the transaction is confirmed. . More specifically, the transaction confirmation management unit confirms the transaction between the second trader node 120 and the trader node that has provided acceptance information corresponding to preference information such as the maximum commission rate and the minimum quantity set by the second trader node 120. can be made
  • the transaction confirmation management unit provides the time when offer information is provided from at least one trader node, the time when offer information to be accepted is determined, the time when acceptance information is provided to the second trader node 120, and acceptance confirmation information are sent to the first trader. Whether or not to confirm the transaction may be determined by referring to at least one of the times provided to the node 110 .
  • the transaction confirmation management unit provides the time at which offer information is provided from at least one trader node, the time at which offer information to be accepted is determined, the time at which acceptance information is provided to the second trader node 120, and acceptance confirmation information. 1 Based on at least one of the times provided to the trader node 110, it may be determined that the transaction is confirmed only when a time equal to or less than a predetermined level has passed, and when the time exceeds the predetermined level, it is determined that the transaction is not confirmed. can
  • a plurality of offers existing within a predetermined reference time according to the preference of the trader node.
  • At least one of the offer information, a plurality of acceptance target offer information, and a plurality of acceptance information can be determined.
  • the reference time may include a time when offer information is provided from at least one trader node, a time when offer information to be accepted is determined, a time when acceptance information is provided to the second trader node 120, and acceptance confirmation information It may be specified based on at least one of the times provided to the first trader node 110.
  • the transaction confirmation management unit may hold an asset associated with the offer information to be accepted by the second trader node 120 that provided the offer information to be accepted.
  • the transaction confirmation management unit offers an offer to be accepted by the second trader node 120 (ie, a trader node that has provided the offer to be accepted to the first trader node 110) according to the request of the first trader node 110.
  • Assets associated with information can be frozen so that transactions with other trader nodes are not made for a certain period of time.
  • transaction confirmation management unit may request the third trader node 130 related to the previously held asset of the second trader node 120 to request Fill Or Kill (FOK) for the previously held asset. there is.
  • FOK Fill Or Kill
  • the transaction confirmation management unit when the third trader node 130 has already held a predetermined asset of the second trader node 120, gives the third trader node 130 the previously held asset. It is possible to prompt the third trader node 130 whether to confirm the transaction by requesting the full amount satisfaction condition for . That is, a request to the third trader node 130 to confirm the transaction because the hold may be canceled if all or a predetermined number of transactions are not made within a predetermined period for the previously held assets of the second trader node 120. this can be provided.
  • the validity management unit refers to the communication information between the first trader node 110 and the second trader node 120, and the first trader node 110 and the second trader node ( 120) can perform a function of verifying the validity of transactions between Communication information according to an embodiment of the present invention includes transaction initiation between the first trader node 110 and the second trader node 120, offer information, acceptance information, and acceptance confirmation, etc. ) may be a concept including at least one transmission/reception information.
  • the validity management unit determines that the quantity specified in the information about the transaction initiation requested from the first trader node 110 from the communication information between the first trader node 110 and the second trader node 120 is second. Whether greater than or equal to the quantity specified in the offer information of the trader node 120, whether the quantity specified in the offer to be accepted is greater than or equal to the quantity specified in the acceptance information, and whether the quantity specified in the acceptance information is acceptance confirmation information It is possible to verify whether it is greater than or equal to the quantity specified in , and the validity of the transaction confirmed between the first trader node 110 and the second trader node 120 can be verified by referring to the verification result. .
  • the validity management unit determines the type of asset specified in the communication information between the first trader node 110 and the second trader node 120, and the information about the transaction initiation requested from the first trader node 110. Is the same as the type of asset specified in the offer information of the second trader node 120, whether the type of asset specified in the offer information to be accepted is the same as the type of asset specified in the acceptance information, specific in the acceptance information It is possible to verify whether or not the type of asset to be specified is the same as the type of asset specified in the acceptance confirmation information, and refer to the verification result to determine between the first trader node 110 and the second trader node 120 The validity of the transaction can be verified.
  • the validity management unit from the communication information between the first trader node 110 and the second trader node 120, information is normally delivered to each node (110, 120) without data corruption (corruption). whether or not the information related to the transaction is encrypted, whether the information before the encryption and the information after the decryption match, if the information related to the transaction is confirmed by the first trader node 110 and the second It can be verified whether or not it is normally delivered to the trader node 120, and the validity of the transaction confirmed between the first trader node 110 and the second trader node 120 can be verified by referring to the verification result. .
  • the validity management unit determines the first trader node 110 and the second trader node (110) and the second trader node ( 120) whether the type, quantity and amount of the assets traded between them are the same, and the time associated with the transaction between the first trader node 110 and the second trader node 120 (eg, time stamp) is included normally, identification information (eg, personal information, IP address, Unique identifier (UID)) about the first trader node 110 and the second trader node 120, etc.
  • time associated with the transaction between the first trader node 110 and the second trader node 120 eg, time stamp
  • identification information eg, personal information, IP address, Unique identifier (UID)
  • the validity management unit may provide information on the problem to the associated trader node.
  • the validity management unit sends a warning message including the type, form, and content of problems occurring with respect to the validity of the transaction to be confirmed to each trader node (eg, the first trader node 110 and the second trader node ( 120)) (for example, provided through a message on a user interface (UI) or provided through an application program programming interface (API) message).
  • UI user interface
  • API application program programming interface
  • FIG. 2 is a diagram exemplarily illustrating a process in which asset trading is supported according to an embodiment of the present invention.
  • first trader node 110 may be a borrower of securities
  • second trader node 120 may be a lender of securities
  • initiation of asset trading based on a first trading condition may be requested from the first trader node 110 according to an embodiment of the present invention (210).
  • the above first transaction condition is directly input by the first trader node 110 or is information in the form of a text file or an extensible markup language (XML) file. It can be provided through various programming interfaces and protocols such as API (Application Programming Interface), FTP (File Transfer Protocol), FIX (Financial Information eXchange).
  • API Application Programming Interface
  • FTP File Transfer Protocol
  • FIX Financial Information eXchange
  • At least one trader node may provide an automatic offer user interface screen for quickly setting or providing offer information in response to a first trading condition. More specifically, when a predetermined criterion is satisfied by comparing conditions such as the quantity 310 and commission rate 320 set in at least one trader node with the above first transaction condition, based on the predetermined quantity or predetermined commission rate Specific offer information may be automatically provided to the first trader node 110 .
  • Offer information to be accepted may be determined by comparing the specified quantity and commission rate with each other).
  • an automatic acceptance user interface screen may be provided to support quick acceptance of an offer subject to acceptance among offer information. More specifically, offer information that satisfies conditions such as quantity 410 and fee rate 420 set in the first trader node 110 may be automatically determined as offer information to be accepted.
  • validation according to an embodiment of the present invention is not necessarily limited to the last step, and is performed during the asset transaction initiation step, offer information providing step, acceptance information providing step, acceptance confirmation information providing step, and transaction confirmation step. Note that validation may occur in at least one step.
  • offer information associated with the third trading condition may be provided from at least one trader node to the first trader node 110 (260).
  • acceptance information may be provided to the third trader node 130 that has provided the above acceptance target offer information (270).
  • the above offer information provision process the above acceptance information provision process
  • the above acceptance confirmation information provision process the above transaction confirmation process.
  • the validity of each transaction process can be verified by referring to the communication information of
  • asset transaction start, offer information, details of acceptance of offer information, or details of providing acceptance confirmation information may be provided in real time or at predetermined time intervals through the user interface screen of the first trader node 110. .
  • confirmed transaction details between the first trader node 110 and the second trader node 120 may be provided in real time or at predetermined times through the user interface screen of each trader node 110, 120 there is.
  • the offer information management unit may perform a function of providing offer information from at least one trader node to the first trader node 110 .
  • the offer information management unit determines the offer information associated with the above first transaction condition, the offer information is transmitted from at least one trader node to the first trader node 110. can be made available.
  • the offer information management unit refers to the borrowable assets specified in the above first transaction condition and the lendable assets for each account of at least one trader node included in the offer information, so that the total of the lendable assets for each account is In the case of more than the required borrowing asset, the offer information may be determined as offer information associated with the above first transaction condition.
  • the offer information management unit when the request for asset transaction start based on the above first transaction condition and the offer information associated with the above first transaction condition are specified, respectively, the offer information automatically may be provided to the first trader node 110 from at least one trader node.
  • automatically providing offer information may be set in a trader node that lends an asset.
  • the offer information management unit may provide offer information automatically as described above, but may also provide offer information manually.
  • the offer information management unit may provide offer information automatically as described above, but may also provide offer information manually.
  • the trader node lending the asset trades the asset
  • transaction conditions for each account may be manually input (or set), and offer information may be provided based on the input information.
  • the transaction confirmation management unit based on the offer information to be accepted determined by referring to the first transaction condition among the offer information provided to the first transaction node 110, the first transaction It may perform a function of confirming a transaction between at least one account included in the node 110 and at least one account included in the second trader node 120 providing the above acceptance target offer information.
  • the acceptance target offer information determined by the transaction confirmation management unit may include information associated with at least one account included in the second trader node 120 .
  • the acceptance target offer information is information associated with at least one account included in the second trader node 120, and is related to a lendable asset held by at least one account included in the second trader node 120. At least one of information and information about the priority of at least one account included in the second trader node 120 may be included.
  • the transaction confirmation management unit refers to information associated with at least one account included in the second trader node 120 above, and at least one transaction included in the first trader node 110 An account (or an account for which asset trading is requested by the first trader node 110 ) and at least one account included in the second trader node 120 may be matched.
  • matching of at least one account included in the first trader node 110 and at least one account included in the second trader node 120 automatically provides offer information. It may be made when is provided from the second trader node 120 to the first trader node 110 and the offer information is determined as offer information to be accepted.
  • the transaction confirmation management unit according to an embodiment of the present invention, the ratio of the asset to be rented to the asset to be rented or the quantity of the asset to be rented (these The ratio of assets loaned to assets that can be rented for each account or the number of assets loaned for each account may be arbitrarily set by the second trader node 120), included in the first trader node 110 At least one account may be matched with at least one account included in the second trader node 120 .
  • the transaction confirmation management unit based on the priority of at least one account included in the second trader node 120, at least one included in the first trader node 110 One account and at least one account included in the second trader node 120 may be matched. More specifically, the transaction confirmation management unit according to an embodiment of the present invention, based on the priority of at least one account included in the second trader node 120, so that the asset is rented from an account with a higher rank, the first trader At least one account included in the node 110 and at least one account included in the second trader node 120 may be matched.
  • the transaction confirmation management unit provides acceptance information (accept) to the second trader node 120 that provided the offer information to be accepted, and the second At least one account included in the first trader node 110 and the second trader node ( 120), it is possible to confirm a transaction between at least one account.
  • the transaction confirmation management unit refers to information associated with at least one account included in the first trader node 110, and offers to be accepted between the different accounts above. You can decide the order of acceptance of information.
  • the transaction confirmation management unit when a request for starting an asset transaction is requested multiple times based on different accounts of the first trader node 110, the first trader node 110 As information associated with at least one account included in ), the order of acceptance of offer information to be accepted between the different accounts may be determined by referring to the order of request for asset transaction initiation of the different accounts. More specifically, asset transaction initiation is requested for each account A and B included in the first trader node 110, and asset transaction initiation is first requested for account A prior to account B, account A and account B is 500 shares and 1000 shares, respectively, and the total lendable assets of at least one account included in the second trader node 120 is 1000 shares (at least one account included in the second trader node 120).
  • the transaction confirmation management unit when a request for starting an asset transaction is requested multiple times based on different accounts of the first transaction node 110, the first transaction node ( As information associated with at least one account included in 110), the order of acceptance of offer information to be accepted among the different accounts may be determined by referring to the priorities of the different accounts. More specifically, asset transaction initiation is requested for each account A and B included in the first trader node 110, and asset transaction initiation is first requested for account A prior to account B, account A and account B
  • the borrowing required assets are 500 shares and 1000 shares, respectively, and the total lendable assets of at least one account included in the second trader node 120 are 1000 shares (at least one included in the second trader node 120).
  • the first trader node 110 selects account A 211 from account A 211, account B 212, account C 213, and account D 214. And by setting the first transaction condition for the A account (211), it is possible to request asset transaction start (210).
  • the first trader node 110 when offer information provided from the second trader node 120 is determined as offer information to be accepted, the first trader node 110 provides the above offer information to be accepted Acceptance information may be provided to the second trader node 120 (230).
  • offer information corresponding to offer information to be accepted is automatically provided, E account 221, F account 222, G account 223, and H account 224 included in the second trader node 120 ) included in at least one account included in the first trader node 110 (that is, account A 211) and the second trader node 120 so that the ratio of the loaned asset to the lendable asset is equal to each other. At least one account may be matched.
  • E account 221, F account 222, G account 223, and H account 224 included in the second trader node 120 At least one account included in the first trader node 110 (ie, account A 211) and included in the second trader node 120 so that assets are borrowed from accounts with a higher ranking based on the priority of ). At least one account may be matched.
  • Acceptance confirmation information may then be provided from the second trader node 120 to the first trader node 110 according to one embodiment of the present invention (240).
  • At least one account (ie, account A 211) included in the first trader node 110 and at least one included in the second trader node 120 Transactions between one account may be confirmed.
  • at least one account (ie, account A 211) included in the first trader node 110 and at least one included in the second trader node 120 Transaction confirmation between accounts can be made based on smart contracts supported by the distributed ledger network.
  • a user interface screen for managing an account may be provided according to an embodiment of the present invention.
  • at least one account can be registered by inputting account information on the above user interface screen and clicking the "ADD" button.
  • the account information required for account registration includes the account name (List Name), balance account number (Account Code), fund code, deposited asset classification code (Custody Asset Type), intermediary, transaction Classification (TX Type), compulsory redemption at maturity (Callable), collateral classification (Coll Type), cash collateral base currency (Coll CCY), dividend ratio (Div), etc.
  • a registered account may be deleted using the "Delete” button.
  • the lendable asset held by the account may be deleted together.
  • a user interface screen for setting an automatic offer may be provided according to an embodiment of the present invention. More specifically, according to an embodiment of the present invention, offer information can be set to be automatically provided in the “Auto Offer” tab, and at least one item included in the first trader node 110 in the “Match Preference” tab.
  • a criterion for matching the account of and at least one account included in the second trader node 120 may be set. For example, if "Equal %" is selected in the "Preferred Criterion" tab, which is a sub-tab of the "Match Preference” tab, the asset to be rented versus the lendable asset between at least one account included in the second trader node 120. The ratio of may be equal to each other.
  • the confirmed transaction details between at least one account included in the first trader node 110 and at least one account included in the second trader node 120 may be provided.
  • the transaction details provided through the above user interface screen may include a transaction counterparty, a unique transaction ID, transaction item information, transaction quantity, transaction rate, transaction execution date and the like.
  • the transaction details provided through the above user interface screen may include account information of each trader node with which the transaction has been concluded.
  • the account information of each trader node where the transaction was concluded includes My List Name, My Account Code, My SLB Number, and My Fund Code.
  • My Custody Asset Type My Custody Asset Type, the other party's account code (CPTY Account Code), the other party's balance account number (CPTY SLB Number), the other party's fund code (CPTY Fund Code), the other party's deposited asset classification code (CPTY Custody Asset Type), etc. may be included.
  • CPTY Account Code the other party's account code
  • CPTY SLB Number the other party's balance account number
  • CPTY Fund Code the other party's fund code
  • CPTY Custody Asset Type the other party's deposited asset classification code
  • Embodiments according to the present invention described above may be implemented in the form of program instructions that can be executed through various computer components and recorded on a computer-readable recording medium.
  • the computer readable recording medium may include program instructions, data files, data structures, etc. alone or in combination.
  • Program instructions recorded on the computer-readable recording medium may be specially designed and configured for the present invention, or may be known and usable to those skilled in the art of computer software.
  • Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks and magnetic tapes, optical recording media such as CD-ROMs and DVDs, and magneto-optical media such as floptical disks. medium), and hardware devices specially configured to store and execute program instructions, such as ROM, RAM, flash memory, and the like.
  • Examples of program instructions include high-level language codes that can be executed by a computer using an interpreter or the like as well as machine language codes generated by a compiler.
  • a hardware device may be modified with one or more software modules to perform processing according to the present invention and vice vers

Abstract

본 발명의 일 태양에 따르면, 계정별로 자산 거래를 지원하기 위한 방법으로서, 오퍼(offer) 정보가 적어도 하나의 거래자 노드로부터 제1 거래자 노드에게 제공되도록 하는 단계, 및 상기 오퍼 정보 중 상기 제1 거래자 노드의 제1 거래 조건을 참조하여 결정되는 수락(accept) 대상 오퍼 정보를 기준으로 하여, 상기 제1 거래자 노드에 포함되는 적어도 하나의 계정 및 상기 수락 대상 오퍼 정보를 제공한 제2 거래자 노드에 포함되는 적어도 하나의 계정 사이의 거래를 확정하는 단계를 포함하는 방법이 제공된다.

Description

계정별로 자산 거래를 지원하기 위한 방법, 시스템 및 비일시성의 컴퓨터 판독 가능 기록 매체
본 발명은 계정별로 자산 거래를 지원하기 위한 방법, 시스템 및 비일시성의 컴퓨터 판독 가능 기록 매체에 관한 것이다.
유가 증권 대차 거래(securities lending & borrowing transaction)란, 대여자가 유가 증권의 소유권을 차입자에게 이전할 것을 약정하고 차입자는 해당 유가 증권과 동일한 종목과 수량의 유가 증권을 반환할 것을 약정함으로써 성립되는 증권 소비 대차 거래 계약을 의미한다. 이러한 대차 거래가 성립되면, 해당 유가 증권의 처분권과 수익원이 차입자에게 이전되며, 이에 대한 반대 급부로서 차입자는 대여자가 대차 거래를 하지 않았으면 받을 수 있었던 경제적 이익, 예컨대, 현금이나 주식 형태의 배당금, 무상주, 유상주 등을 보상하게 된다.
대차 거래는 다양한 목적을 달성하기 위해서 활용되고 있는데, 구체적으로 살펴보면, 공매도를 위한 용도(short selling), 공매도를 통하여 차익 거래를 수행하기 위한 용도(arbitrage transaction), 담보로서 이용하기 위한 용도(collateral usage), 결제 대용을 위한 용도(fail coverage), 기존 대차 거래에서 회수 요청이 들어온 대차 물량을 새로운 대차 물량으로 대체하기 위한 용도(recall coverage), 기존 대차 거래의 대차 물량을 보다 낮은 수수료의 대차 물량으로 대체하기 위한 용도(refinancing), 기존 대차 거래의 대차 물량을 보다 안정적인 대차 물량으로 대체하기 위한 용도(replacement) 등으로 활용되고 있다.
지난 수년 간 대차 거래의 횟수와 금액은 급증하였으나, 장외에서 이루어지는 대차 거래의 계약을 확정함에 있어서 대차 거래 참가자들이 자신이 원하는 거래 상대방과 조건에 맞는 다수의 거래를 빠르고 효율적인 방식으로 발견, 협상, 및 확정할 수 있도록 지원하고(이하, "거래의 발견 및 확정"), 이러한 거래에 대한 유효성(validation) 검증을 할 수 있는 기술은 존재하지 않았다. 이러한 기술의 부재로 인해 대차 거래 참가자들은 대차 거래를 위한 협의를 하기 위하여 전화, 메신저, 블룸버그 터미널(Bloomberg Terminal), 이메일 등에 의존해 오고 있는 실정이다.
차입자가 주식을 공매도하기 위해서는 차입자 자신이 공매도 주문 이전에 차입 주식을 소유하고 있어야 하는데, 일반적으로 차입 주식을 소유하고 있는 것으로 인정되는 시점은 해당 주식의 차입이 완료되거나 해당 주식에 대한 대차 거래 계약이 확정된 시점이다. 이에 따라, 글로벌 투자자들은 일반적으로 대차 거래 계약이 확정되는 즉시 공매도에 대한 매도 호가 주문을 내고 있는데, 현재의 방식으로는 주식 대차 물량 발견(discovery) 또는 탐색(searching), 협상(negotiation), 계약 확정(confirmation) 및 검증까지 상당한 시간이 소요되고 있다.
위의 사항과 관련하여 구체적으로, 다음과 같은 문제점이 지적되어 왔다.
첫째로, 대차 거래 참가자가 서로 다른 통신 수단(예를 들어, 앞서 언급된 채팅, 이메일 등)으로 개별적으로 의사 소통을 해야 했기 때문에, 대차 거래 계약을 체결함에 있어서 많은 시간과 노력이 소모되어 왔다. 특히 분과 초를 다투는 금융시장에서 짧은 시간 동안 다수의 증권에 대한 계약의 확정이 요구되는데, 현실적으로는 다수의 거래를 발견 및 확정을 도와주는 관련 기술의 부재로 인하여 매우 비효율적이고 느린 방식으로 이루어지고 있다.
둘째로, 대차 거래 참가자 쌍방이 갖고 있는 정보가 달라질 수 있다. 이는, 예를 들어, 전화 또는 메신저로 협의가 이뤄질 경우, 쌍방이 확정하는 정보에 오류가 있다면 이는 무차입 공매도 또는 결제 불이행이라는 중대한 오류를 초래할 수 있다. 이는 쌍방 간에 이루어지는 협의 내역에 대한 유효성 검증이 제대로 이루어지지 않기 때문인데, 현재의 방식에서는 이러한 유효성 검증을 사람이 자의적인 해석에 따라 하고 있는 실정이다.
셋째로, 입력 과정에 오류가 생길 수 있다. 확정된 내역을 수기로 각자의 시스템에 입력을 하다 보면 이는 착오 또는 실수 입력(fat-finger error)의 경우가 발생하게 된다. 이러한 착오 또는 실수 입력은 무차입 공매도 및 결제 지연이라는 심각한 문제를 초래하게 되며 실제로 골드만삭스가 입력 과정의 오류로 한국에서 무차입 공매도를 한 사례가 있으며, 이로 인해 상당한 금액의 과징금이 부과된 사례가 있다.
넷째로, 거래의 발견 및 확정과 관련된 기술은 중앙 집중화된 구조에서 거래소가 참가자들의 거래를 매칭해주는 형태(예를 들어, 호가 또는 게시판의 형태)로 이루어지기에 이러한 플랫폼의 제공자(예를 들어, 거래소)가 모든 정보를 소유하고 그들이 정하는 알고리즘과 방식에 따라 거래의 발견 및 확정이 이루어져왔다. 이러한 중앙 집중화(centralized)된 구조에서는 플랫폼 제공자가 모든 정보를 관리하게 되어, 거래 참가자들의 거래 정보에 대한 기밀성이 보장되지 않으며, 외부 공격에도 취약할 수밖에 없다. 또한, 거래의 발견 및 확정을 하나의 서비스 제공자에 의존해야 하기에 자신이 원하는 참가자와 자신이 원하는 조건과 방식에 따라 자유롭게 거래할 수 있는 장외 시장의 성격이 희석될 수밖에 없었으며, 거래가 확정되기 전까지는(또는, 호가 경쟁 방식의 경우에는 거래가 확정된 이후에도), 거래 상대방조차 알 수 없는 경우가 존재해왔다.
다섯째로, 대차 거래 참가자가 복수의 계정(또는 펀드)을 소유하고 있는 경우에 계정별로 거래의 발견 및 확정이 이루어질 수 있도록 하는 기술이 존재하지 않았다. 전술한 바와 같이 금융 시장에서는 짧은 시간 동안 다수의 거래를 확정 및 발견할 것이 요구되는데, 다수의 계정을 기반으로 거래할 시에는 위와 같이 계정별로 거래의 발견 및 확정이 이루어질 수 있도록 하는 기술이 존재하지 않았으므로, 자산 거래가 더욱 비효율적이고 느린 방식으로 이루어질 수밖에 없었다.
따라서, 하나 또는 다수의 거래자(예를 들어, 차입자)가 하나 또는 다수의 거래 상대방(예를 들어, 대여자)과 다수의 거래에 대해서 중앙 집중화된 거래의 발견 및 확정없이 개별적으로 거래의 발견 및 확정을 수행하고, 그 거래에 대한 유효성 검증을 수행할 수 있도록 하여 유효하지 않는 거래를 사전에 차단할 수 있게 하며, 계정별로 거래의 발견 및 확정이 이루어질 수 있도록 하는 기술의 필요성이 대두되었다.
나아가, 장내 또는 장외 시장에서 이루어지는 유가 증권 대차 거래 외에도 장내 시장 또는 장외 시장에서 이루어지는 모든 금융(예를 들어, Total Return Swap, Interest Rate Swap 등), 비금융(예를 들어, 인터넷 광고 비딩(bidding), 호텔 또는 비행기의 예약, 부동산, 데이터 등), 기타 자산(예를 들어, 가상 화폐, 포인트, 마일리지 등) 등에 관한 거래를 포함하는 모든 자산 거래를 대상으로도 앞서 살펴본 기술의 필요성이 대두되고 있다.
본 발명은 전술한 종래 기술의 문제점을 모두 해결하는 것을 그 목적으로 한다.
또한, 본 발명은, 중앙 집중화된 방식이 아닌 분산화된 방식(예를 들어, 개인-개인, 개인-기관, 기관-기관 사이의 P2P(peer to peer) 등)을 기반으로 자산 거래의 발견, 협의 및 확정 과정이 효율적이고 신속하게 이루어지는 것을 그 목적으로 한다.
또한, 본 발명은, 거래 참가자가 거래를 희망하는 상대방 또는 희망하는 조건에 따라 거래가 이루어질 수 있도록 지원하는 것을 그 목적으로 한다.
또한, 본 발명은, 각 거래와 연관되는 정보를 중앙 집중화된 데이터베이스가 아닌 해당 거래마다 참가자별로 분리(segregate)하여 저장되도록 함으로써 기밀성을 보장하는 것을 그 목적으로 한다.
또한, 본 발명은, 분산화된 양방향 커뮤니케이션 정보를 기반으로 자산 거래의 유효성을 검증하여 자산 거래의 오류 및 착오 거래를 방지하는 것을 그 목적으로 한다.
또한, 본 발명은, 대차 거래 참가자가 복수의 계정을 소유하고 있는 경우에 계정별로 거래의 발견 및 확정이 이루어질 수 있도록 지원하는 것을 그 목적으로 한다.
상기 목적을 달성하기 위한 본 발명의 대표적인 구성은 다음과 같다.
본 발명의 일 태양에 따르면, 계정별로 자산 거래를 지원하기 위한 방법으로서, 오퍼(offer) 정보가 적어도 하나의 거래자 노드로부터 제1 거래자 노드에게 제공되도록 하는 단계, 및 상기 오퍼 정보 중 상기 제1 거래자 노드의 제1 거래 조건을 참조하여 결정되는 수락(accept) 대상 오퍼 정보를 기준으로 하여, 상기 제1 거래자 노드에 포함되는 적어도 하나의 계정 및 상기 수락 대상 오퍼 정보를 제공한 제2 거래자 노드에 포함되는 적어도 하나의 계정 사이의 거래를 확정하는 단계를 포함하는 방법이 제공된다.
본 발명의 다른 태양에 따르면, 계정별로 자산 거래를 지원하기 위한 시스템으로서, 오퍼(offer) 정보가 적어도 하나의 거래자 노드로부터 제1 거래자 노드에게 제공되도록 하는 오퍼 정보 관리부, 및 상기 오퍼 정보 중 상기 제1 거래자 노드의 제1 거래 조건을 참조하여 결정되는 수락(accept) 대상 오퍼 정보를 기준으로 하여, 상기 제1 거래자 노드에 포함되는 적어도 하나의 계정 및 상기 수락 대상 오퍼 정보를 제공한 제2 거래자 노드에 포함되는 적어도 하나의 계정 사이의 거래를 확정하는 거래 확정 관리부를 포함하는 시스템이 제공된다.
이 외에도, 본 발명을 구현하기 위한 다른 방법, 다른 시스템 및 상기 방법을 실행하기 위한 컴퓨터 프로그램을 기록하는 비일시성의 컴퓨터 판독 가능한 기록 매체가 더 제공된다.
본 발명에 의하면, 중앙 집중화된 방식이 아닌 분산화된 방식(예를 들어, 개인-개인, 개인-기관, 기관-기관 사이의 P2P(peer to peer) 등)을 기반으로 자산 거래의 발견, 협의 및 확정 과정이 효율적이고 신속하게 이루어질 수 있게 된다.
또한, 본 발명에 의하면, 참가자가 거래를 희망하는 상대방 또는 참가자가 희망하는 조건에 따라 거래가 이루어질 수 있도록 지원할 수 있게 된다.
또한, 본 발명에 의하면, 개인간 양방향 커뮤니케이션 방식을 기반으로 참가자 자신이 거래를 희망하는 상대방 또는 참가자 자신이 희망하는 조건에 따라 거래할 수 있게 된다.
또한, 본 발명에 의하면, 각 거래와 연관되는 정보를 중앙 집중화된 데이터베이스가 아닌 해당 거래마다의 참가자별로 분리하여 저장되도록 함으로써 기밀성을 보장할 수 있게 된다.
또한, 본 발명에 의하면, 분산화된 양방향 커뮤니케이션 정보를 기반으로 자산 거래의 유효성을 검증하여 자산 거래의 오류 및 착오 거래를 방지할 수 있게 된다.
또한, 본 발명에 의하면, 대차 거래 참가자가 복수의 계정을 소유하고 있는 경우에 계정별로 거래의 발견 및 확정이 이루어질 수 있도록 지원할 수 있게 된다.
도 1은 본 발명의 일 실시예에 따라 자산 거래를 지원하는 전체 시스템의 개략적인 구성을 나타내는 도면이다.
도 2 및 도 5는 본 발명의 일 실시예에 따라 자산 거래가 지원되는 과정을 예시적으로 나타내는 도면이다.
도 3, 도 4 및 도 6 내지 도 8은 본 발명의 일 실시예에 따른 자산 거래를 지원하기 위한 사용자 인터페이스 화면을 예시적으로 나타내는 도면이다.
도 9는 본 발명의 계정별 자산 거래 지원에 관한 실시예에 따라 계정별로 자산 거래가 지원되는 과정을 예시적으로 나타내는 도면이다.
도 10 내지 도 13은 본 발명의 계정별 자산 거래 지원에 관한 실시예에 기초하여 제공되는 사용자 인터페이스 화면을 예시적으로 나타내는 도면이다.
<부호의 설명>
100: 복수의 노드
110: 제1 거래자 노드
120: 제2 거래자 노드
200: 자산 거래 시스템
후술하는 본 발명에 대한 상세한 설명은, 본 발명이 실시될 수 있는 특정 실시예를 예시로서 도시하는 첨부 도면을 참조한다. 이러한 실시예는 당업자가 본 발명을 실시할 수 있기에 충분하도록 상세히 설명된다. 본 발명의 다양한 실시예는 서로 다르지만 상호 배타적일 필요는 없음이 이해되어야 한다. 예를 들어, 본 명세서에 기재되어 있는 특정 형상, 구조 및 특성은 본 발명의 정신과 범위를 벗어나지 않으면서 일 실시예로부터 다른 실시예로 변경되어 구현될 수 있다. 또한, 각각의 실시예 내의 개별 구성요소의 위치 또는 배치도 본 발명의 정신과 범위를 벗어나지 않으면서 변경될 수 있음이 이해되어야 한다. 따라서, 후술하는 상세한 설명은 한정적인 의미로서 행하여지는 것이 아니며, 본 발명의 범위는 특허청구범위의 청구항들이 청구하는 범위 및 그와 균등한 모든 범위를 포괄하는 것으로 받아들여져야 한다. 도면에서 유사한 참조부호는 여러 측면에 걸쳐서 동일하거나 유사한 구성요소를 나타낸다.
본 명세서에서 말하는 자산이란, 금융 자산(예를 들어, 유가 증권), 비금융 자산(예를 들어, 부동산), 기타 자산(예를 들어, 가상 화폐, 포인트, 마일리지 등) 등을 총칭하는 개념으로서, 경제적 가치가 있는 모든 대상을 포괄하는 최광의의 의미로 이해되어야 한다.
또한, 본 명세서에서 말하는 유가증권이란, 사전적으로는 일정한 금전이나 화물 등의 유가물에 대해 청구할 수 있는 권리가 표시된 증서, 즉, 상법상의 재산권을 표시하는 증서를 가리키는 것으로서, 본 명세서에서 언급되는 유가증권은 반드시 상법이나 증권거래법에서 규정하고 있는 유가증권에 한정되는 것이 아니라 대차 거래(Securities Lending and Borrowing Transaction)의 대상이 될 수 있는 모든 유형의 객체를 포괄하는 최광의의 의미로 이해되어야 한다. 예를 들면, 본 명세서에서 언급되는 유가증권에는, 상장 주식, 비상장 주식, 채권, 수익 증권, 신주 인수권, 수익 증권을 포함하는 금융 상품, 선물, 주식 스왑(Equity Swap)을 포함하는 파생 상품, ELS(주가연계증권, Equity-Linked Securities), ELW(주식워런트증권, Equity-Linked Warrant), BW(신주인수권부사채, Bond with Warrant), CB(전환사채, Convertible Bond), ETF(상장지수펀드, Exchange Traded Funds), ETN(상장지수증권, Exchange Traded Notes) 등이 모두 포함될 수 있다.
이하에서는, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자가 본 발명을 용이하게 실시할 수 있도록 하기 위하여, 본 발명의 여러 바람직한 실시예에 관하여 첨부된 도면을 참조하여 상세히 설명하기로 한다.
도 1은 본 발명의 일 실시예에 따라 자산 거래를 지원하는 전체 시스템의 개략적인 구성을 나타내는 도면이다.
도 1에 도시된 바와 같이, 본 발명의 일 실시예에 따른 전체 시스템은 통신망, 복수의 노드(100) 및 자산 거래 시스템(200)을 포함하여 구성될 수 있다.
먼저, 본 발명의 일 실시예에 따른 통신망은 유선 통신이나 무선 통신과 같은 통신 양태를 가리지 않고 구성될 수 있으며, 근거리 통신망(LAN; Local Area Network), 도시권 통신망(MAN; Metropolitan Area Network), 광역 통신망(WAN; Wide Area Network) 등 다양한 통신망으로 구성될 수 있다. 바람직하게는, 본 명세서에서 말하는 통신망은 공지의 인터넷 또는 월드와이드웹(WWW; World Wide Web)일 수 있다. 그러나, 통신망은, 굳이 이에 국한될 필요 없이, 공지의 유무선 데이터 통신망, 공지의 전화망 또는 공지의 유무선 텔레비전 통신망을 그 적어도 일부에 있어서 포함할 수도 있다.
예를 들면, 통신망은 무선 데이터 통신망으로서, 와이파이(WiFi) 통신, 와이파이 다이렉트(WiFi-Direct) 통신, 롱텀 에볼루션(LTE; Long Term Evolution) 통신, 블루투스 통신(예를 들면, 저전력 블루투스(BLE; Bluetooth Low Energy) 통신), 적외선 통신, 초음파 통신 등과 같은 종래의 통신 방식을 적어도 그 일부분에 있어서 구현하는 것일 수 있다.
다음으로, 본 발명의 일 실시예에 따른 복수의 노드(100)(node)는 통신망을 통하여 다른 노드(100)와 통신할 수 있는 접점 또는 접속점으로서, 서버, 컴퓨터, 노트북, 스마트폰, 태블릿 PC 등(즉, 메모리 수단을 구비하고 마이크로 프로세서를 탑재하여 연산 능력을 갖춘 디지털 기기)의 물리적 노드(physical node) 또는 애플리케이션, 프로그램 모듈, 가상 머신 등(즉, 가상 노드)에 의한 논리적 노드(logical node)를 포함하는 개념일 수 있다.
한편, 본 발명의 일 실시예에 따른 복수의 노드(100)에는 본 발명에 따른 자산 거래를 지원하기 위한 거래 지원 시스템이 애플리케이션, 위젯 등의 프로그램 모듈의 형태로 설치 또는 포함되어 있을 수 있다. 또한, 이와 같은 프로그램 모듈은 외부의 애플리케이션 배포 서버(미도시됨) 또는 외부 시스템(미도시됨) 등으로부터 다운로드된 것일 수 있다. 필요에 따라, 위의 거래 지원 시스템은 분산원장 기술(DLT; Distributed Ledger Technology)을 기반으로 동작될 수 있다. 여기서의 분산원장은 두 당사자 노드 사이에서 일어나는 자산 거래와 연관되는 정보가 암호화 또는 비가역화되어 두 당사자(또는 그 외의 다른 당사자)에게 분산 기록되어 관리되는 방식을 의미할 수 있고, 두 당사자 사이의 합의에 따라 결정되는 정보가 그 두 당사자의 노드에서 블록체인의 형태로 관리되는 일종의 프라이빗(private) 형태의 블록체인을 포함하는 개념일 수 있다. 한편, 위의 암호화 또는 비가역화를 위하여, 소정의 해시 함수(hash function)(예를 들어, 메시지 다이제스트 산출 알고리즘(MD5; Message-Digest algorithm 5)), 해시 연산(hash operation), 암호화 알고리즘(cryptography algorithm) 등 공지의 비가역 변환 또는 부인 방지에 관한 기술이 이용될 수 있다.
또한, 본 발명의 일 실시예에 따라 위의 복수의 노드(100)에는, 용도, 권한 등에 따라 자산 거래와 연관되는 다양한 참가자 유형의 노드가 포함될 수 있으며, 예를 들어, 복수의 노드(100)에는 자산 거래를 개시하고 오퍼 정보를 수락하는 제1 거래자 노드(110) 및 오퍼 정보를 제공하고 수락 정보에 대한 수락 확인 정보를 제공하는 제2 거래자 노드(120)가 포함될 수 있다. 한편, 필요에 따라, 위의 복수의 노드(100)에는 거래 검증 노드, 규제자 노드, 중개자 노드, 브로커 노드, 예탁기관 노드, 자산 관리인 노드 등이 더 포함될 수도 있다.
본 발명의 일 실시예에 따른 위의 거래 지원 시스템은, 오퍼(offer) 정보가 적어도 하나의 거래자 노드로부터 제1 거래자 노드(110)에게 제공되도록 하고, 오퍼 정보 중 제1 거래자 노드(110)의 제1 거래 조건을 참조하여 결정되는 수락(accept) 대상 오퍼 정보를 기준으로 하여, 제1 거래자 노드(110) 및 수락 대상 오퍼 정보를 제공한 제2 거래자 노드(120) 사이의 거래를 확정하는 기능을 수행할 수 있다.
본 발명에 따른 거래 지원 시스템의 구성과 기능에 관하여는 이하의 상세한 설명을 통하여 자세하게 알아보기로 한다. 한편, 거래 지원 시스템에 관하여 위와 같이 설명되었으나, 이러한 설명은 예시적인 것이고, 거래 지원 시스템에 대하여 요구되는 기능이나 구성요소의 적어도 일부가 필요에 따라 복수의 노드(100)(예를 들면, 제1 거래자 노드(110), 제2 거래자 노드(120), 제3 거래자 노드(130) 등) 또는 외부 시스템(미도시됨) 내에서 실현되거나 복수의 노드(100)(예를 들면, 제1 거래자 노드(110), 제2 거래자 노드(120), 제3 거래자 노드(130) 등) 또는 외부 시스템에 포함될 수도 있음은 당업자에게 자명하다. 예를 들면, 본 발명의 일 실시예에 따른 사용자는, 자신의 노드에서 본 발명에 따른 거래 지원 시스템의 기능 중 적어도 일부를 포함하는 애플리케이션을 이용하거나, 본 발명에 따른 거래 지원 시스템의 기능 중 적어도 일부를 제공하는 웹사이트에 접속함으로써, 본 발명에 따른 자산 거래(예를 들어, 대여, 차입) 등을 행할 수 있다.
다음으로, 본 발명의 일 실시예에 따른 자산 거래 시스템(200)은 복수의 거래자 노드 간의 자산 거래에 관한 정보를 제공받으면, 그 거래에 관한 정보에 대응하는 자산의 이동, 대여, 차입, 매수, 매도 등의 거래가 실행되도록 하는 기능을 수행할 수 있다. 예를 들면, 본 발명의 일 실시예에 따른 자산이 유가 증권인 경우에는, 위의 자산 거래 시스템(200)은 증권 거래소(Stock Exchanges), 예탁 기관(Securities Depository), 청산 기관(Clearing Houses) 등에 의하여 운영되는 시스템과 일부 유사할 수 있다.
거래 지원 시스템의 구성
이하에서는, 본 발명의 구현을 위하여 중요한 기능을 수행하는 거래 지원 시스템 각 구성요소의 기능에 대하여 살펴보기로 한다.
본 발명의 일 실시예에 따라 거래 지원 시스템은 오퍼 정보 관리부, 거래 확정 관리부 및 유효성 관리부를 포함하여 구성될 수 있다. 본 발명의 일 실시예에 따르면, 오퍼 정보 관리부, 거래 확정 관리부 및 유효성 관리부는 그 중 적어도 일부가 외부의 시스템과 통신하는 프로그램 모듈일 수 있다. 이러한 프로그램 모듈은 운영 시스템, 응용 프로그램 모듈 또는 기타 프로그램 모듈의 형태로 거래 지원 시스템에 포함될 수 있고, 물리적으로는 여러 가지 공지의 기억 장치에 저장될 수 있다. 또한, 이러한 프로그램 모듈은 거래 지원 시스템과 통신 가능한 원격 기억 장치에 저장될 수도 있다. 한편, 이러한 프로그램 모듈은 본 발명에 따라 후술할 특정 업무를 수행하거나 특정 추상 데이터 유형을 실행하는 루틴, 서브루틴, 프로그램, 오브젝트, 컴포넌트, 데이터 구조 등을 포괄하지만, 이에 제한되지는 않는다.
먼저, 본 발명의 일 실시예에 따른 오퍼 정보 관리부는 오퍼 정보가 적어도 하나의 거래자 노드로부터 제1 거래자 노드(110)에게 제공되도록 하는 기능을 수행할 수 있다. 본 발명의 일 실시예에 따른 적어도 하나의 거래자 노드는, 제1 거래자 노드(110)와 연관되는 네트워크(예를 들어, 제1 거래자 노드의 사용자 정보를 참조하여 동적으로 구성되는 네트워크 또는 제1 거래자 노드에 의해 특정되는 네트워크)에 존재하는 노드이거나 별도의 제약 없는 개방형 네트워크에 존재하는 노드일 수도 있다.
예를 들어, 오퍼 정보 관리부는 제1 거래자 노드(110)로부터 제1 거래 조건에 기초한 자산 거래 개시가 요청되면, 제1 거래 조건과 연관되는 오퍼 정보가 적어도 하나의 거래자 노드로부터 제1 거래자 노드(110)로 제공되도록 할 수 있다. 본 발명의 일 실시예에 따른 거래 조건에는, 자산의 종류, 수량, 금액, 수수료율(예를 들어, 대차 수수료율), 날짜, 거래에 필요한 담보의 종류 및 금액, 배당, 권리 관계 책임(corporate action liability), 리콜(recall) 가능 여부와 같은 거래 대상에 관한 조건과 선착 순, 총점 순, 최고 이익, 우선 확정 경쟁(available to first taker)(예를 들어, 제시한 물량을 먼저 확정하는 사람이 해당 물량을 확보), 경쟁 입찰(bidding)(예를 들어, 제1 거래자 노드(110)가 대여자 노드인 경우에, 차입자 노드 중 소정 기간 동안 가장 높은 수수료율을 제시한 거래자 노드(120)가 해당 물량을 확보)(다른 예를 들어, 제2 거래자 노드(120)가 대여자 노드인 경우에, 차입자 노드 중 소정 기간 동안 가장 높은 수수료율을 제시한 거래자 노드(110)가 해당 물량을 확보)과 같은 거래 방식에 관한 조건이 포함될 수 있다.
보다 구체적으로, 오퍼 정보 관리부는 제1 거래자 노드(110)에 의해 설정되는 제1 거래 조건에 기초한 자산 거래 개시가 요청되면, 그 자산 거래 개시에 관한 정보가 적어도 하나의 노드에게 제공되도록 할 수 있다. 이 경우에, 위의 자산 거래 개시에 관한 정보가 제1 거래자 노드(110)에 의해 특정되는 네트워크에 존재하는 복수의 거래자 노드(또는 별도의 제약 없는 개방형 네트워크에 존재하는 노드)로 제공되면 일대다 방식의 거래이고, 위의 자산 거래 개시에 관한 정보가 제1 거래자 노드(110)에 의해 특정되는 네트워크에 존재하는 하나의 거래자 노드로 제공되면 일대일의 거래일 수 있게 된다. 그 다음에, 위의 적어도 하나의 거래자 노드로부터 위의 제1 거래 조건과 연관되는 오퍼 정보가 결정되면, 그 오퍼 정보가 적어도 하나의 거래자 노드로부터 제1 거래자 노드(110)에게 제공되도록 할 수 있다. 예를 들어, 오퍼 정보 관리부는 위의 제1 거래 조건에서 특정되는 대여 또는 차입 요구 자산과 적어도 하나의 거래자 노드의 대여 또는 차입 가능 자산을 참조하여 위의 제1 거래 조건과 연관되는 오퍼 정보가 결정되도록 할 수 있다. 즉, 오퍼 정보 관리부는 적어도 하나의 거래자 노드의 대여 가능 자산과 제1 거래 조건에서 특정되는 차입 요구 수량을 비교하여, 대여 가능 자산의 소정 수량(예를 들어, 대여 가능 자산의 10%) 및 제1 거래 조건에서 특정되는 차입 요구 수량 중 적은 수량을 기준으로 위의 오퍼 정보를 결정할 수 있다. 또한, 오퍼 정보 관리부는 적어도 하나의 거래자 노드에 의해 설정되는 선호도, 수수료율, 수량, 날짜, 자산 종류, 금액, 거래에 필요한 담보의 종류 및 거래에 필요한 담보의 금액, 리콜 여부 및 권리 관계 중 적어도 하나에 관한 조건을 참조하여 위의 제1 거래 조건과 연관되는 오퍼 정보를 결정할 수 있다. 보다 구체적으로, 오퍼 정보 관리부는 적어도 하나의 거래자 노드에 의해 설정되는 수수료율보다 제1 거래 조건에서 특정되는 수수료율이 높은 경우에, 그 설정되는 수수료율 또는 제1 거래 조건에서 특정되는 수수료율을 기준으로 오퍼 정보가 결정되도록 할 수 있다.
또한, 오퍼 정보 관리부는 적어도 하나의 거래자 노드의 제2 거래 조건에 매칭되는 거래자 노드를 대상으로 선별적으로 오퍼 정보가 제공되도록 할 수 있다.
예를 들어, 오퍼 정보 관리부는, 복수의 거래자 노드로부터 복수의 자산 거래 개시가 요청되면, 복수의 자산 거래 개시 중 특정 거래 조건(즉, 위의 적어도 하나의 거래자 노드에서 설정되는 제2 거래 조건)을 만족시키는 자산 거래 개시와 연관되는 거래자 노드를 대상으로 선별적으로 오퍼 정보가 제공되도록 할 수 있다. 즉, 모든 거래자 노드로 오퍼 정보가 제공되지 않고 설정된 조건이 맞는 거래자 노드로만 오퍼 정보가 선별적으로 제공될 수 있다.
또한, 오퍼 정보 관리부는 적어도 하나의 거래자 노드의 제2 거래 조건에 매칭되는 거래자 노드가 특정되는 경우에 자동적으로 오퍼 정보가 제공되도록 할 수 있다.
예를 들어, 오퍼 정보 관리부는, 복수의 거래자 노드로부터 요청되는 복수의 자산 거래 개시 중 특정 거래 조건(즉, 위의 적어도 하나의 거래자 노드에서 설정되는 제2 거래 조건)을 만족시키는 자산 거래 개시와 연관되는 거래자 노드가 특정되면, 그 특정되는 거래자 노드에게 자동적으로 오퍼 정보가 제공되도록 할 수 있다. 즉, 설정된 조건이 맞는 거래자 노드가 나타나게 되면 오퍼 정보가 자동적으로 제공될 수 있게 된다.
또한, 오퍼 정보 관리부는 거래자 노드별로 부여되는 우선 순위, 가중치 및 거래 조건별 선호도(또는 선호 기준, 선호 수치) 중 적어도 하나를 참조하여 적어도 하나의 거래자 노드로부터 오퍼 정보가 제공되도록 할 수 있다. 본 발명의 일 실시예에 따른 위와 같은 우선 순위, 가중치 및 거래 조건별 선호도는 복수의 거래자 노드 각각에 의해 기설정되거나 동적(예를 들어, 거래자 노드의 거래 성향을 분석하여 소정 기간마다 업데이트)으로 설정되는 것일 수 있다.
예를 들어, 오퍼 정보 관리부는 거래자 노드별로 부여되는 우선 순위가 가장 높은 거래자 노드에게 오퍼 정보가 먼저 제공되도록 하고, 해당 오퍼 정보에 대한 거래 확정이 이루어지지 않았거나 해당 오퍼 정보가 제공된 이후 소정 시간이 지난 경우에 차순위에 해당되는 거래자 노드에게 오퍼 정보가 제공되도록 할 수 있다.
다른 예를 들어, 오퍼 정보 관리부는 적어도 하나의 거래자 노드에 의해 설정되는 가중치(예를 들어, 이러한 가중치는 자산의 종류, 수량, 금액 및 수수료율 각각을 기준으로 설정되는 것일 수 있음)를 참조하여 복수의 거래자 노드로부터 제공되는 거래 조건에 대한 스코어(예를 들어, 이러한 스코어에는 불리언(boolean) 형태 또는 수치도 포함될 수 있음)를 산출하고, 그 스코어가 소정 수준 이상(또는 최고 스코어)인 거래 조건을 제공하는 거래자 노드를 대상으로 오퍼 정보가 제공되도록 할 수 있다.
또한, 오퍼 정보 관리부는 제1 거래자 노드로부터 제1 거래 조건에 기초한 거래 개시 정보가 위의 적어도 하나의 노드로 제공되는 순서를 참조하여 오퍼 정보가 제공되도록 할 수 있다.
예를 들어, 오퍼 정보 관리부는 제1 거래자 노드로부터 거래 개시 정보가 위의 적어도 하나의 노드로 제공되는 순서를 참조하여 가장 빠르게 거래 개시 정보를 제공한 제1 거래자 노드에게 오퍼 정보가 제공되도록 할 수 있다.
또한, 오퍼 정보 관리부는 제1 거래자 노드(110)로부터 제1 거래 조건에 기초하여 요청(또는 제공)되는 거래 개시 정보 중 소정 수준 이상으로 이익(또는, 최고 이익)이 되는 거래 개시 정보를 제공한 제1 거래자 노드(110)에게 오퍼 정보가 제공되도록 할 수 있다.
예를 들어, 오퍼 정보 관리부는 최고 이익 거래 방식(예를 들어, 입찰 방식)으로 설정되는 경우에, 제1 거래자 노드(110)로부터 요청되는 거래 개시 정보 중 가장 이익이 되는(즉, 이익이 최대화되는) 거래 개시 정보(예를 들어, 경쟁 입찰)를 제공한 제1 거래자 노드(110)에게 오퍼 정보가 제공되도록 할 수 있다.
또한, 오퍼 정보 관리부는 적어도 하나의 거래자 노드에 의해 설정되는 선호 정보(예를 들어, 거래 조건별 선호도 또는 선호 기준)(또는 비선호 정보)를 참조하여 오퍼 정보가 제공되도록 할 수 있다.
예를 들어, 오퍼 정보 관리부는 적어도 하나의 거래자 노드에 의해 설정되는 최소 수수료율, 최대 수량과 같은 선호 정보에 부합되는 거래자 노드에게 오퍼 정보가 제공되도록 할 수 있다. 한편, 오퍼 정보 관리부는 선호 정보에 부합되는 거래자 노드가 존재하는 경우에는 자동으로 오퍼 정보가 제공되도록 하고 그에 부합되지 않으면 오퍼 정보가 제공되지 않도록 할 수도 있다. 또한, 오퍼 정보 관리부는 자동으로 오퍼 정보가 제공되는(또는 제공되지 않는) 기준 또는 조건(예를 들어, 유가증권의 특정 종목)이 설정되도록 할 수도 있다.
다음으로, 본 발명의 일 실시예에 따른 거래 확정 관리부는 제1 거래자 노드(110)로 제공되는 오퍼 정보 중 제1 거래 조건을 참조하여 수락 대상 오퍼 정보를 결정하는 기능을 수행할 수 있다.
예를 들어, 거래 확정 관리부는 적어도 하나의 거래자 노드로부터 오퍼 정보가 제1 거래자 노드로 제공되는 순서를 참조하여 수락 대상 오퍼 정보를 결정할 수 있다. 보다 구체적으로, 거래 확정 관리부는 제1 거래 조건이 선착순 거래 방식으로 설정되는 경우에, 제1 거래자 노드(110)로 제공되는 오퍼 정보 중 제1 거래자 노드(110)로 가장 먼저 제공되는 오퍼 정보를 수락 대상 오퍼 정보로서 결정할 수 있다.
다른 예를 들어, 거래 확정 관리부는 제1 거래자 노드(110)로 제공되는 오퍼 정보 중 소정 수준 이상으로 이익(또는 최고 이익(예를 들어, 대여자 입장에서는 최고 수수료일 수 있고, 차입자 입장에서는 최저 수수료일 수 있음), 이익 최대화)이 되는 오퍼 정보를 수락 대상 오퍼 정보로서 결정할 수 있다. 보다 구체적으로, 거래 확정 관리부는 제1 거래자 노드(110)로 제공되는 오퍼 정보 중 제1 거래자 노드(110)에게 가장 이익이 되는(즉, 이익이 최대화되는) 오퍼 정보를 수락 대상 오퍼 정보로서 결정할 수 있다. 또한, 거래 확정 관리부는 제1 거래 조건이 최고 이익 거래 방식으로 설정되는 경우에, 제1 거래자 노드(110)에 의해 설정되는 가중치(예를 들어, 이러한 가중치는 오퍼 정보에서 특정되는 자산의 종류, 수량, 금액 및 수수료율 각각을 기준으로 설정되는 것일 수 있음)를 참조하여 적어도 하나의 거래자 노드로부터 제공되는 오퍼 정보에 대한 스코어(예를 들어, 이러한 스코어에는 불리언(boolean) 형태 또는 수치도 포함될 수 있음)를 산출하고, 그 스코어가 소정 수준 이상인 오퍼 정보(또는 최고 스코어인 오퍼 정보)를 수락 대상 오퍼 정보로서 결정할 수 있다.
또 다른 예를 들어, 거래 확정 관리부는 복수의 거래자 노드(또는 복수의 거래자)에 대하여 부여되는 우선 순위를 참조하여 수락 대상 오퍼 정보를 결정할 수 있다. 보다 구체적으로, 거래 확정 관리부는 제1 거래 조건이 우선 순위 거래자 순 거래 방식인 경우에, 상위 우선 순위자에 해당되는 거래자 노드의 오퍼 정보를 수락 대상 오퍼 정보로서 결정할 수 있다.
또 다른 예를 들어, 거래 확정 관리부는 제1 거래자 노드(110)의 제1 거래 조건에 의해 특정되는 자산의 종류, 수량, 금액 및 수수료율 중 적어도 하나에 관한 대여 또는 차입 요구 자산과 오퍼 정보의 자산의 수량, 금액 및 수수료율 중 적어도 하나에 관한 차입 또는 대여 가능 자산을 비교하여 분석함으로써, 수락 대상 오퍼 정보를 결정할 수 있다. 보다 구체적으로, 거래 확정 관리부는 제1 거래 조건이 특정 수량 거래인 경우에, 제1 거래 조건에 의해 특정되는 수량보다 소정 비율 이하의 수량에 해당되는 오퍼 정보를 수락 대상 오퍼 정보로서 결정할 수 있다. 또한, 거래 확정 관리부는 제1 거래 조건이 특정 수수료율 기준인 경우에, 제1 거래 조건에 의해 특정되는 수수료율보다 작은 수수료율에 해당되는 오퍼 정보를 수락 대상 오퍼 정보로서 결정할 수 있다.
또 다른 예를 들어, 거래 확정 관리부는 제1 거래자 노드(110)의 제1 거래 조건에 의해 설정되는 담보의 종류, 리콜 여부 및 권리 관계 중 적어도 하나에 관한 조건을 참조하여 수락 대상 오퍼 정보를 결정할 수 있다. 보다 구체적으로, 거래 확정 관리부는 제1 거래자 노드(110)의 제1 거래 조건에 의해 설정되는 담보의 종류(예를 들어, 현금 또는 비현금 담보 유무, 현금 담보일 경우에는 통화의 종류 등)를 참조하여 그 설정된 담보의 종류에 부합되는 오퍼 정보를 수락 대상 오퍼 정보로서 결정할 수 있다.
또 다른 예를 들어, 거래 확정 관리부는 제1 거래자 노드(110)에 의해 설정되는 선호 정보(예를 들어, 거래 조건별 선호도 또는 선호 기준)(또는 비선호 정보)를 참조하여 수락 대상 오퍼 정보를 결정할 수 있다. 보다 구체적으로, 거래 확정 관리부는 제1 거래자 노드(110)에 의해 설정되는 최대 수수료율, 최소 수량과 같은 선호 정보에 부합되는 오퍼 정보를 수락 대상 오퍼 정보로서 결정할 수 있다.
또한, 거래 확정 관리부는, 위의 결정되는 수락 오퍼 정보를 기준으로 하여, 제1 거래자 노드(110) 및 수락 대상 오퍼 정보를 제공한 제2 거래자 노드(120) 사이의 거래를 확정하는 기능을 수행할 수 있다.
예를 들어, 거래 확정 관리부는 수락 대상 오퍼 정보가 결정되면, 그 수락 대상 오퍼 정보를 제공한 제2 거래자 노드(120)에게 수락 정보(accept)를 제공하고, 제2 거래자 노드(120)로부터 그 수락 정보에 대한 수락 확인 정보(confirm)가 제1 거래자 노드(110)로 제공되도록 함으로써, 제1 거래자 노드(110) 및 제2 거래자 노드(120) 사이의 거래를 확정할 수 있다.
보다 구체적으로, 거래 확정 관리부는 제1 거래자 노드(110) 및 제2 거래자 노드(120)(즉, 제1 거래자 노드(110)에게 수락 대상 오퍼 정보를 제공한 거래자 노드) 사이에서 수락 정보 및 수락 확인 정보가 상호간에 주고받게 되면, 블록체인 기반의 스마트 계약(smart contract) 기술을 이용하여 제1 거래자 노드(110) 및 제2 거래자 노드(120) 사이의 거래 계약이 체결되도록 할 수 있다.
한편, 거래 확정 관리부는 위의 제2 거래자 노드(120)로 제공되는 수락 정보 및 제2 거래자 노드의 거래 조건 중 적어도 하나를 참조하여 거래가 확정되도록 할 수 있다.
예를 들어, 거래 확정 관리부는 수락 정보가 위의 제2 거래자 노드(120)로 제공되는 순서를 참조(예를 들어, 선착순)하여 거래가 확정되도록 할 수 있다. 보다 구체적으로, 거래 확정 관리부는 위의 제2 거래자 노드(120)로 제공되는 복수의 수락 정보 중 가장 먼저 수락 정보를 제공한 거래자 노드와 제2 거래자 노드(120) 사이의 거래가 확정되도록 할 수 있다.
다른 예를 들어, 거래 확정 관리부는 위의 제2 거래자 노드(120)로 제공되는 수락 정보 중 제2 거래자 노드(120)에게 소정 수준 이상으로 이익(또는 최고 이익(예를 들어, 대여자 입장에서는 최고 수수료일 수 있고, 차입자 입장에서는 최저 수수료일 수 있음), 이익 최대화)이 되는 수락 정보를 제공한 거래자 노드와 제2 거래자 노드(120) 사이의 거래가 확정되도록 할 수 있다. 보다 구체적으로, 거래 확정 관리부는 제2 거래자 노드(120)로 제공되는 복수의 수락 정보 중 제2 거래자 노드(120)에게 가장 이익이 되는(즉, 이익이 최대화되는) 수락 정보(예를 들어, 최대 수수료율, 최대 수량 등)를 제공한 거래자 노드와 제2 거래자 노드(120) 사이의 거래가 확정되도록 할 수 있다.
또 다른 예를 들어, 거래 확정 관리부는 복수의 거래자 노드(또는 복수의 거래자)에 대하여 부여되는 우선 순위에 기초하여 거래가 확정되도록 할 수 있다. 보다 구체적으로, 거래 확정 관리부는 제2 거래자 노드(120)의 거래 조건이 우선 순위 거래자 순 거래 방식인 경우에, 수락 정보를 제공한 거래자 노드 중 상위 우선 순위자에 해당되는 거래자 노드와 제2 거래자 노드(120) 사이의 거래가 확정되도록 할 수 있다.
또 다른 예를 들어, 거래 확정 관리부는 제2 거래자 노드(120)의 거래 조건에 의해 특정되는 자산의 종류, 수량, 금액 및 수수료율 중 적어도 하나에 관한 대여 또는 차입 요구 자산과 복수의 수락 정보의 자산의 수량, 금액 및 수수료율 중 적어도 하나에 관한 차입 또는 대여 가능 자산을 비교하여 분석함으로써, 수락 정보를 제공한 거래자 노드 중 거래를 확정할 거래자 노드를 결정할 수 있고, 그 거래자 노드와 제2 거래자 노드(120) 사이의 거래가 확정되도록 할 수 있다.
또 다른 예를 들어, 거래 확정 관리부는 제2 거래자 노드(120)의 거래 조건에 의해 설정되는 담보의 종류, 리콜 여부 및 권리 관계 중 적어도 하나에 관한 조건을 참조하여 거래가 확정되도록 할 수 있다. 보다 구체적으로, 거래 확정 관리부는 제2 거래자 노드(120)의 거래 조건에 의해 설정되는 담보의 종류(예를 들어, 현금 또는 비현금 담보 유무, 현금 담보일 경우에는 통화의 종류 등)를 참조하여 그 설정된 담보의 종류에 부합되는 수락 정보를 제공한 거래자 노드와 제2 거래자 노드(120) 사이의 거래가 확정되도록 할 수 있다.
또 다른 예를 들어, 거래 확정 관리부는 제2 거래자 노드(120)에 의해 설정되는 선호 정보(예를 들어, 거래 조건별 선호도 또는 선호 기준)(또는 비선호 정보)를 참조하여 거래가 확정되도록 할 수 있다. 보다 구체적으로, 거래 확정 관리부는 제2 거래자 노드(120)에 의해 설정되는 최대 수수료율, 최소 수량과 같은 선호 정보에 부합되는 수락 정보를 제공한 거래자 노드와 제2 거래자 노드(120) 사이의 거래가 확정되도록 할 수 있다.
한편, 거래 확정 관리부는 적어도 하나의 거래자 노드로부터 오퍼 정보가 제공되는 시각, 수락 대상 오퍼 정보가 결정되는 시각, 수락 정보가 제2 거래자 노드(120)로 제공되는 시각 및 수락 확인 정보가 제1 거래자 노드(110)로 제공되는 시각 중 적어도 하나를 참조하여 거래의 확정 여부를 결정할 수도 있다.
예를 들어, 거래 확정 관리부는 적어도 하나의 거래자 노드로부터 오퍼 정보가 제공되는 시각, 수락 대상 오퍼 정보가 결정되는 시각, 수락 정보가 제2 거래자 노드(120)로 제공되는 시각 및 수락 확인 정보가 제1 거래자 노드(110)로 제공되는 시각 중 적어도 하나를 기준으로 하여 소정 수준 이하의 시간이 지난 경우에만 거래가 확정되도록 결정할 수 있고, 위의 소정 수준 이상으로 시간이 지난 경우에는 거래가 확정되지 않은 것으로 결정할 수 있다.
한편, 본 발명의 일 실시예에 따라 동일한 조건의 복수의 오퍼 정보, 복수의 수락 대상 오퍼 정보 또는 복수의 수락 정보가 존재하는 경우에는, 거래자 노드의 선호도에 따라 소정의 기준 시간 내에 존재하는 복수의 오퍼 정보, 복수의 수락 대상 오퍼 정보 및 복수의 수락 정보 중 적어도 하나가 결정될 수 있게 된다. 예를 들어, 이러한 기준 시간은, 적어도 하나의 거래자 노드로부터 오퍼 정보가 제공되는 시각, 수락 대상 오퍼 정보가 결정되는 시각, 수락 정보가 제2 거래자 노드(120)로 제공되는 시각 및 수락 확인 정보가 제1 거래자 노드(110)로 제공되는 시각 중 적어도 하나를 기준으로 하여 특정될 수 있다.
한편, 거래 확정 관리부는 수락 대상 오퍼 정보를 제공한 제2 거래자 노드(120)의 해당 수락 대상 오퍼 정보와 연관되는 자산이 홀드(hold)되도록 할 수 있다.
예를 들어, 거래 확정 관리부는 제1 거래자 노드(110)의 요청에 따라 제2 거래자 노드(120)(즉, 제1 거래자 노드(110)에게 수락 대상 오퍼를 제공한 거래자 노드)의 수락 대상 오퍼 정보와 연관되는 자산에 대하여 소정 기간 동안 다른 거래자 노드와의 거래가 이루어지지 않도록 동결시킬 수 있다.
또한, 거래 확정 관리부는 제2 거래자 노드(120)의 기홀드된 자산과 연관되는 제3 거래자 노드(130)에게 기홀드된 자산에 대한 전량충족조건(Fill Or Kill; FOK)이 요청되도록 할 수 있다.
예를 들어, 거래 확정 관리부는 제3 거래자 노드(130)에 의해 제2 거래자 노드(120)의 소정 자산에 대하여 이미 홀드가 이루어진 경우에, 그 제3 거래자 노드(130)에게 해당 기홀드된 자산에 대한 전량충족조건이 요청되도록 함으로써, 제3 거래자 노드(130)의 거래 확정 여부를 촉구할 수 있다. 즉, 제3 거래자 노드(130)에게 제2 거래자 노드(120)의 기홀드된 자산에 대하여 소정 기간 내에 전량 또는 소정 수량의 거래가 이루어지지 않으면, 해당 홀드가 취소될 수 있으니 거래를 확정시켜 달라는 요청이 제공될 수 있다.
다음으로, 본 발명의 일 실시예에 따른 유효성 관리부는 제1 거래자 노드(110) 및 제2 거래자 노드(120) 사이의 커뮤니케이션 정보를 참조하여 상기 제1 거래자 노드(110) 및 제2 거래자 노드(120) 사이의 거래의 유효성을 검증하는 기능을 수행할 수 있다. 본 발명의 일 실시예에 따른 커뮤니케이션 정보는 제1 거래자 노드(110) 및 제2 거래자 노드(120) 사이의 거래 개시, 오퍼 정보, 수락 정보 및 수락 확인 등 거래 시작에서부터 거래 확정(또는 실제 거래 체결)까지의 적어도 하나의 송수신 정보를 포함하는 개념일 수 있다.
예를 들어, 유효성 관리부는 제1 거래자 노드(110) 및 제2 거래자 노드(120) 사이의 커뮤니케이션 정보로부터, 제1 거래자 노드(110)로부터 요청되는 거래 개시에 관한 정보에서 특정되는 수량이 제2 거래자 노드(120)의 오퍼 정보에서 특정되는 수량보다 크거나 같은 지 여부, 수락 대상 오퍼에서 특정되는 수량이 수락 정보에서 특정되는 수량보다 크거나 같은 지 여부, 수락 정보에서 특정되는 수량이 수락 확인 정보에서 특정되는 수량보다 크거나 같은 지 여부 등을 검증할 수 있고, 그 검증 결과를 참조하여 제1 거래자 노드(110) 및 제2 거래자 노드(120) 사이에서 확정되는 거래의 유효성을 검증할 수 있다.
다른 예를 들어, 유효성 관리부는 제1 거래자 노드(110) 및 제2 거래자 노드(120) 사이의 커뮤니케이션 정보로부터, 제1 거래자 노드(110)로부터 요청되는 거래 개시에 관한 정보에서 특정되는 자산의 종류가 제2 거래자 노드(120)의 오퍼 정보에서 특정되는 자산의 종류와 같은 지 여부, 수락 대상 오퍼 정보에서 특정되는 자산의 종류가 수락 정보에서 특정되는 자산의 종류와 같은 지 여부, 수락 정보에서 특정되는 자산의 종류가 수락 확인 정보에서 특정되는 자산의 종류와 같은 지 여부 등을 검증할 수 있고, 그 검증 결과를 참조하여 제1 거래자 노드(110) 및 제2 거래자 노드(120) 사이에서 확정되는 거래의 유효성을 검증할 수 있다.
또 다른 예를 들어, 유효성 관리부는, 제1 거래자 노드(110) 및 제2 거래자 노드(120) 사이의 커뮤니케이션 정보로부터, 데이터의 손상(corruption) 없이 각 노드(110, 120)로 정보 전달이 정상적으로 이루어지는지 여부, 거래와 연관되는 정보가 암호화(encrypted)될 경우 암호화 이전 정보와 복호화(decrypted)된 이후의 정보가 일치하는지 여부, 확정되는 거래에 관한 정보가 제1 거래자 노드(110) 및 제2 거래자 노드(120)에게 정상적으로 전달되는지 여부 등을 검증할 수 있고, 그 검증 결과를 참조하여 제1 거래자 노드(110) 및 제2 거래자(120) 노드 사이에서 확정되는 거래의 유효성을 검증할 수 있다.
또 다른 예를 들어, 유효성 관리부는 제1 거래자 노드(110) 및 제2 거래자 노드(120) 사이에 확정되는 거래에 관한 정보를 기준으로 하여, 제1 거래자 노드(110) 및 제2 거래자 노드(120) 사이에 거래된 자산의 종류, 수량 및 금액이 동일하게 포함되어 있는지 여부, 제1 거래자 노드(110) 및 제2 거래자 노드(120) 사이의 거래와 연관된 시각(예를 들어, 타임 스탬프)이 정상적으로 포함되어 있는지 여부, 제1 거래자 노드(110) 및 제2 거래자 노드(120)에 관한 식별 정보(예를 들어, 인적사항, IP 주소, Unique identifier(UID) 등 거래자 노드를 다른 거래자 노드와 구분 가능한 정보)가 정상적으로 포함되어 있는지 여부, 개별 자산에 대한 가격 정보가 정확히 반영이 되어 거래가 확정된 총 금액에 대한 정보가 오류 없이 정확하게 기재되어 있는지 여부, 확정되는 거래 내역이 해당 거래의 실행을 담당하는 중개 기관(intermediary) 또는 수탁 은행(custodian)에게 제공되는 데이터에 정확하게 기재되어 있는지 여부 등을 검증할 수 있고, 그 검증 결과를 참조하여 제1 거래자 노드(110) 및 제2 거래자 노드(120) 사이에서 확정되는 거래의 유효성을 검증할 수 있다.
한편, 유효성 관리부는 확정되는 거래의 유효성에 문제가 있는 것으로 판단되는 경우에, 해당 문제에 관한 정보를 연관된 거래자 노드로 제공할 수 있다.
예를 들어, 유효성 관리부는 확정되는 거래의 유효성에 대하여 발생되는 문제의 종류, 형식 및 내용을 포함하는 경고 메시지를 각 거래자 노드(예를 들어, 제1 거래자 노드(110) 및 제2 거래자 노드(120))에게 제공(예를 들어, 사용자 인터페이스(UI)상에서 메시지를 통해 제공 또는 응용 프로그램 프로그래밍 인터페이스(API) 메시지를 통해 제공)할 수 있다.
도 2는 본 발명의 일 실시예에 따라 자산 거래가 지원되는 과정을 예시적으로 나타내는 도면이다.
도 2를 참조하면, 본 발명의 일 실시예에 따라 제1 거래자 노드(110) 및 제2 거래자 노드(120) 사이에서 유가증권 대차 거래가 지원되는 상황을 가정해 볼 수 있다. 여기서 제1 거래자 노드(110)는 유가 증권의 차입자일 수 있고, 제2 거래자 노드(120)는 유가 증권의 대여자일 수 있다.
먼저, 본 발명의 일 실시예에 따라 제1 거래자 노드(110)로부터 제1 거래 조건에 기초한 자산 거래 개시가 요청될 수 있다(210).
예를 들어, 위의 제1 거래 조건은, 제1 거래자 노드(110)에 의해 직접 입력되거나, 텍스트(Text) 파일, 확장 가능 마크 업 언어(eXtensible Markup Language; XML) 파일 등의 형식의 정보로 API(Application Programming Interface), FTP(File Transfer Protocol), FIX(Financial Information eXchange) 등의 다양한 프로그래밍 인터페이스 및 프로토콜을 통해 제공될 수 있다.
그 다음에, 본 발명의 일 실시예에 따라 제1 거래 조건과 연관되는 오퍼 정보가 적어도 하나의 거래자 노드로부터 제1 거래자 노드(110)에게 제공될 수 있다(220).
예를 들어, 도 3을 참조하면, 적어도 하나의 거래자 노드에서는 제1 거래 조건에 대응하여 오퍼 정보가 빠르게 설정 또는 제공될 수 있도록 지원하기 위한 자동 오퍼 사용자 인터페이스 화면이 제공될 수 있다. 보다 구체적으로, 적어도 하나의 거래자 노드에서 설정되는 수량(310), 수수료율(320) 등의 조건과 위의 제1 거래 조건을 비교하여 소정 기준이 만족되는 경우에, 소정 수량 또는 소정 수수료율을 기준으로 특정되는 오퍼 정보가 제1 거래자 노드(110)로 자동으로 제공될 수 있다.
그 다음에, 본 발명의 일 실시예에 따라 위의 적어도 하나의 거래자 노드에서 제공되는 오퍼 정보 중 제1 거래 조건을 참조(예를 들어, 오퍼 정보로부터 특정되는 수량 및 수수료율과 제1 거래 조건으로부터 특정되는 수량 및 수수료율을 서로 비교)하여 수락(accept) 대상 오퍼 정보가 결정될 수 있다.
예를 들어, 도 4를 참조하면, 오퍼 정보 중 수락 대상 오퍼가 빠르게 수락될 수 있도록 지원하기 위한 자동 수락 사용자 인터페이스 화면이 제공될 수 있다. 보다 구체적으로, 제1 거래자 노드(110)에서 설정되는 수량(410), 수수료율(420) 등의 조건을 만족하는 오퍼 정보가 수락 대상 오퍼 정보로서 자동 결정될 수 있다.
그 다음에, 본 발명의 일 실시예에 따라 제1 거래자 노드(110)로부터 위의 수락 대상 오퍼 정보를 제공한 제2 거래자 노드(120)에게 수락 정보가 제공될 수 있다(230).
그 다음에, 본 발명의 일 실시예에 따라 제2 거래자 노드(120)로부터 제1 거래자 노드(110)에게 수락 확인 정보가 제공될 수 있다(240).
그 다음에, 위의 수락 대상 오퍼 정보를 기준으로 하여, 제1 거래자 노드(110) 및 제2 거래자 노드(120) 사이의 거래가 확정될 수 있다. 예를 들어, 본 발명의 일 실시예에 따르면, 제1 거래자 노드(110) 및 제2 거래자 노드(120) 사이의 거래 확정은 분산원장 네트워크에서 지원되는 스마트 계약(smart contract)을 기반으로 이루어질 수 있다.
그 다음에, 제1 거래자 노드(110) 및 제2 거래자 노드(120) 사이의 커뮤니케이션 정보를 참조하여 위의 확정되는 거래의 유효성이 검증될 수 있다.
한편, 본 발명의 일 실시예에 따른 유효성 검증은, 반드시 마지막 단계에서 이루어지는 것에만 한정되지 않고, 자산 거래 개시 단계, 오퍼 정보 제공 단계, 수락 정보 제공 단계, 수락 확인 정보 제공 단계 및 거래 확정 단계 중 적어도 하나의 단계에서 유효성 검증이 이루어질 수도 있음을 밝혀 둔다.
그 다음에, 제1 거래자 노드(110) 및 제2 거래자 노드(120)에게 거래된 내역 정보(예를 들어, 거래 내역서)가 제공될 수 있다.
도 5는 본 발명의 일 실시예에 따라 제1 거래자 노드(110)와의 자산 거래가 지원되는 과정을 예시적으로 나타내는 도면이다.
도 2 및 도 5를 참조하면, 본 발명의 일 실시예에 따라 앞서 살펴본 제1 거래자 노드(110) 및 제2 거래자 노드(120) 사이에서 유가증권 대차 거래가 지원된 이후에 제1 거래자 노드(110)에게 부족한 수량에 대하여 제1 거래자 노드(110) 및 제3 거래자 노드(130) 사이에서 유가증권 대차 거래가 추가 지원되는 상황을 가정해 볼 수 있다. 여기서 제1 거래자 노드(110)는 유가 증권의 차입자일 수 있고, 제2 거래자 노드(120) 및 제3 거래자 노드(130)는 유가 증권의 대여자일 수 있다.
먼저, 본 발명의 일 실시예에 따라 제1 거래자 노드(110)로부터 제3 거래 조건에 기초한 자산 거래 개시가 요청될 수 있다(250). 위의 제3 거래 조건은 앞서 살펴본 제2 거래자 노드(120)의 수락 대상 오퍼 정보에 의해 특정되는 수량과 제1 거래 조건에 의해 특정되는 수량 사이의 차이를 기준으로 설정되는 것일 수 있다.
그 다음에, 본 발명의 일 실시예에 따라 제3 거래 조건과 연관되는 오퍼 정보가 적어도 하나의 거래자 노드로부터 제1 거래자 노드(110)에게 제공될 수 있다(260).
그 다음에, 본 발명의 일 실시예에 따라 위의 적어도 하나의 거래자 노드에서 제공되는 오퍼 정보 중 제3 거래 조건을 참조하여 수락 대상 오퍼 정보가 결정될 수 있다.
그 다음에, 본 발명의 일 실시예에 따라 위의 수락 대상 오퍼 정보를 제공한 제3 거래자 노드(130)에게 수락 정보가 제공될 수 있다(270).
그 다음에, 본 발명의 일 실시예에 따라 제3 거래자 노드(130)로부터 제1 거래자 노드(110)에게 수락 확인 정보가 제공될 수 있다(280).
그 다음에, 위의 수락 대상 오퍼 정보를 기준으로 하여, 제1 거래자 노드(110) 및 제3 거래자 노드(130) 사이의 거래가 확정될 수 있다.
한편, 위의 거래 개시 과정, 위의 오퍼 정보 제공 과정, 위의 수락 정보 제공 과정, 위의 수락 확인 정보 제공 과정 및 거래 확정 과정에서 제1 거래자 노드(110) 및 제3 거래자 노드(130) 사이의 커뮤니케이션 정보를 참조하여 각 거래 과정에서의 유효성이 검증될 수 있다.
도 6 내지 도 8은 제1 거래자 노드(110) 및 제2 거래자 노드(120)(또는 제3 거래자 노드(130))에게 제공되는 사용자 인터페이스 화면을 예시적으로 나타내는 도면이다.
도 6을 참조하면, 자산 거래 개시, 오퍼 정보, 오퍼 정보가 수락되는 내역 또는 수락 확인 정보가 제공되는 내역이 제1 거래자 노드(110)의 사용자 인터페이스 화면을 통해 실시간 또는 소정 시간마다 제공될 수 있다.
도 7을 참조하면, 자산 거래 개시, 오퍼 정보, 오퍼 정보가 수락되는 내역 또는 수락 확인 정보가 제공되는 내역이 제2 거래자 노드(120)의 사용자 인터페이스 화면을 통해 실시간 또는 소정 시간마다 제공될 수 있다.
도 8을 참조하면, 제1 거래자 노드(110) 및 제2 거래자 노드(120) 사이의 확정된 거래 내역이 각 거래자 노드(110, 120)의 사용자 인터페이스 화면을 통해 실시간 또는 소정 시간마다 제공될 수 있다.
계정별 자산 거래 지원에 관한 실시예
이하에서는 복수의 노드(200) 각각에 포함되는 적어도 하나의 계정(또는 펀드)에 기초하여 자산 거래가 이루어지는 실시예에 대하여 살펴본다. 한편, 전술한 내용(또는 실시예)들이 본 실시예에도 마찬가지로 적용될 수 있음은 당연하며, 내용이 중복되는 범위 내에서 일부 내용이 생략될 수도 있음을 밝혀 둔다.
먼저, 본 발명의 일 실시예에 따른 오퍼 정보 관리부는, 오퍼 정보가 적어도 하나의 거래자 노드로부터 제1 거래자 노드(110)에게 제공되도록 하는 기능을 수행할 수 있다.
구체적으로, 본 발명의 일 실시예에 따른 오퍼 정보 관리부는, 제1 거래자 노드(110)로부터 제1 거래 조건에 기초한 자산 거래 개시가 요청되면, 제1 거래 조건과 연관되는 오퍼 정보가 적어도 하나의 거래자 노드로부터 제1 거래자 노드(110)로 제공되도록 할 수 있다.
여기서, 본 발명의 일 실시예에 따르면, 위의 제1 거래 조건에 기초한 자산 거래 개시의 요청은, 제1 거래자 노드(110)에 포함되는 적어도 하나의 계정 중에서 제1 거래자 노드(110)에 의하여 선택되는 계정에 기초하여 요청될 수 있다. 예를 들어, 제1 거래자 노드(110)에 A 계정, B 계정, C 계정 및 D 계정이 포함되는 경우, 제1 거래자 노드(110)는 그 중 하나의 계정을 선택(예를 들어, A 계정을 선택)하고 그 계정에 관하여 제1 거래 조건을 설정함으로써 자산 거래 개시를 요청할 수 있다.
그 다음에, 본 발명의 일 실시예에 따른 오퍼 정보 관리부는, 위의 제1 거래 조건과 연관되는 오퍼 정보가 결정되면, 그 오퍼 정보가 적어도 하나의 거래자 노드로부터 제1 거래자 노드(110)에게 제공되도록 할 수 있다. 예를 들어, 오퍼 정보 관리부는 위의 제1 거래 조건에서 특정되는 차입 요구 자산과 오퍼 정보에 포함되는 적어도 하나의 거래자 노드의 계정별 대여 가능 자산을 참조하여, 그 계정별 대여 가능 자산의 총합이 차입 요구 자산 이상에 해당하는 경우에, 그 오퍼 정보를 위의 제1 거래 조건과 연관되는 오퍼 정보로서 결정할 수 있다.
한편, 본 발명의 일 실시예에 따른 오퍼 정보 관리부는, 위의 제1 거래 조건에 기초한 자산 거래 개시의 요청과 위의 제1 거래 조건과 연관되는 오퍼 정보가 각각 특정되면, 자동적으로 그 오퍼 정보가 적어도 하나의 거래자 노드로부터 제1 거래자 노드(110)에게 제공되도록 할 수 있다. 여기서, 본 발명의 일 실시예에 따르면, 자동적으로 오퍼 정보를 제공하는 것은 자산을 대여하는 거래자 노드에서 설정되는 것일 수 있다.
한편, 본 발명의 일 실시예에 따른 오퍼 정보 관리부는, 위와 같이 자동적으로 오퍼 정보를 제공할 수도 있지만, 수동적으로 오퍼 정보를 제공할 수도 있다. 예를 들어, 본 발명의 일 실시예에 따르면, 자산을 대여하는 거래자 노드에 포함되는 적어도 하나의 계정이 제1 거래 조건에서 특정되는 차입 요구 자산에 대응하는 대여 가능 자산을 보유하고 있지 않은 경우, 제1 거래 조건이 자산을 대여하는 거래자 노드의 대여 조건과 일치하지 않는 경우, 자산을 대여하는 거래자 노드가 자동적으로 오퍼 정보를 제공하는 것을 설정하지 않은 경우 등에서, 자산을 대여하는 거래자 노드가 자산 거래 개시 요청에 기초하여 계정별 거래 조건을 수동적으로 입력(또는 설정)하고 그 입력 정보에 기초하여 오퍼 정보가 제공될 수 있다.
다음으로, 본 발명의 일 실시예에 따른 거래 확정 관리부는, 제1 거래자 노드(110)로 제공되는 오퍼 정보 중 제1 거래 조건을 참조하여 결정되는 수락 대상 오퍼 정보를 기준으로 하여, 제1 거래자 노드(110)에 포함되는 적어도 하나의 계정 및 위의 수락 대상 오퍼 정보를 제공한 제2 거래자 노드(120)에 포함되는 적어도 하나의 계정 사이의 거래를 확정하는 기능을 수행할 수 있다.
여기서, 본 발명의 일 실시예에 따르면, 거래 확정 관리부에 의하여 결정되는 수락 대상 오퍼 정보에는 제2 거래자 노드(120)에 포함되는 적어도 하나의 계정과 연관되는 정보가 포함될 수 있다. 예를 들어, 수락 대상 오퍼 정보에는 제2 거래자 노드(120)에 포함되는 적어도 하나의 계정과 연관되는 정보로서, 제2 거래자 노드(120)에 포함되는 적어도 하나의 계정이 보유한 대여 가능 자산에 관한 정보 및 제2 거래자 노드(120)에 포함되는 적어도 하나의 계정의 우선 순위에 관한 정보 중 적어도 하나가 포함될 수 있다.
본 발명의 일 실시예에 따르면, 거래 확정 관리부는 위의 제2 거래자 노드(120)에 포함되는 적어도 하나의 계정과 연관되는 정보를 참조하여, 제1 거래자 노드(110)에 포함되는 적어도 하나의 계정(또는 제1 거래자 노드(110)에 의하여 자산 거래 개시가 요청된 계정)과 제2 거래자 노드(120)에 포함되는 적어도 하나의 계정이 매칭되도록 할 수 있다. 여기서, 본 발명의 일 실시예에 따르면, 위의 제1 거래자 노드(110)에 포함되는 적어도 하나의 계정과 제2 거래자 노드(120)에 포함되는 적어도 하나의 계정의 매칭은, 자동적으로 오퍼 정보가 제2 거래자 노드(120)로부터 제1 거래자 노드(110)에게 제공되고 그 오퍼 정보가 수락 대상 오퍼 정보로서 결정된 경우에 이루어지는 것일 수 있다.
예를 들어, 본 발명의 일 실시예에 따른 거래 확정 관리부는, 제2 거래자 노드(120)에 포함되는 적어도 하나의 계정이 보유한 대여 가능 자산에 기초하여, 제1 거래자 노드(110)에 포함되는 적어도 하나의 계정과 제2 거래자 노드(120)에 포함되는 적어도 하나의 계정이 매칭되도록 할 수 있다. 보다 구체적으로, 본 발명의 일 실시예에 따른 거래 확정 관리부는, 제2 거래자 노드(120)에 포함되는 적어도 하나의 계정 사이에서 대여 가능 자산 대비 대여되는 자산의 비율이 서로 동일하도록, 제1 거래자 노드(110)에 포함되는 적어도 하나의 계정과 제2 거래자 노드(120)에 포함되는 적어도 하나의 계정을 매칭할 수 있다. 즉, 제1 거래자 노드(110)에 의하여 자산 거래 개시가 요청된 A 계정의 차입 요구 자산이 1000주이고, 제2 거래자 노드(120)에 포함되는 E 계정 및 F 계정이 보유한 대여 가능 자산이 각각 1200주 및 2000주라고 가정할 경우, 거래 확정 관리부는 E 계정에서 대여되는 자산을 375주(여기서, E 계정에서 대여되는 자산은 다음과 같이 계산됨; 1200/(1200+2000)*1000=375), F 계정에서 대여되는 자산을 625주(여기서, F 계정에서 대여되는 자산은 다음과 같이 계산됨; 2000/(1200+2000)*1000=625)로 설정함으로써, E 계정 및 F 계정 사이에서 대여 가능 자산 대비 대여되는 자산의 비율이 서로 동일하도록(즉, E 계정의 대여 가능 자산(즉, 1200주) 대비 대여되는 자산(즉, 375주)의 비율: 375/1200*100=31.25[%], F 계정의 대여 가능 자산(즉, 2000주) 대비 대여되는 자산(즉, 625주)의 비율: 625/2000*100=31.25[%]), 제1 거래자 노드(110)의 계정에 해당하는 A 계정과 제2 거래자 노드(120)의 계정에 해당하는 E 계정 및 F 계정을 매칭할 수 있다. 한편, 본 발명의 일 실시예에 따른 거래 확정 관리부는, 제2 거래자 노드(120)에 포함되는 적어도 하나의 계정마다 각각 설정되는 대여 가능 자산 대비 대여되는 자산의 비율 또는 대여되는 자산의 수량(이러한 계정별 대여 가능 자산 대비 대여되는 자산의 비율 또는 계정별 대여되는 자산의 수량은 제2 거래자 노드(120)에 의하여 임의로 설정될 수 있다.)을 참조하여, 제1 거래자 노드(110)에 포함되는 적어도 하나의 계정과 제2 거래자 노드(120)에 포함되는 적어도 하나의 계정을 매칭할 수도 있다.
다른 예를 들어, 본 발명의 일 실시예에 따른 거래 확정 관리부는, 제2 거래자 노드(120)에 포함되는 적어도 하나의 계정의 우선 순위에 기초하여, 제1 거래자 노드(110)에 포함되는 적어도 하나의 계정과 제2 거래자 노드(120)에 포함되는 적어도 하나의 계정이 매칭되도록 할 수 있다. 보다 구체적으로, 본 발명의 일 실시예에 따른 거래 확정 관리부는, 제2 거래자 노드(120)에 포함되는 적어도 하나의 계정의 우선 순위에 기초하여 순위가 높은 계정부터 자산이 대여되도록, 제1 거래자 노드(110)에 포함되는 적어도 하나의 계정과 제2 거래자 노드(120)에 포함되는 적어도 하나의 계정을 매칭할 수 있다. 즉, 제1 거래자 노드(110)에 의하여 자산 거래 개시가 요청된 A 계정의 차입 요구 자산이 2500주이고, 제2 거래자 노드(120)에 포함되는 E 계정 및 F 계정이 보유한 대여 가능 자산이 각각 1000주 및 2000주이며, 제2 거래자 노드(120)로부터 설정된 E 계정 및 F 계정의 우선 순위가 각각 2 순위 및 1 순위라고 가정할 경우, 거래 확정 관리부는, 1 순위에 해당하는 F 계정에서 먼저 2000주가 대여되고 그 다음에 2 순위에 해당하는 E 계정에서 500주가 대여되도록, E 계정에서 대여되는 자산을 500주, F 계정에서 대여되는 자산을 2000주로 설정함으로써, 제1 거래자 노드(110)의 계정에 해당하는 A 계정과 제2 거래자 노드(120)의 계정에 해당하는 E 계정 및 F 계정을 매칭할 수 있다.
계속해서, 본 발명의 일 실시예에 따른 거래 확정 관리부는, 수락 대상 오퍼 정보가 결정되면 그 수락 대상 오퍼 정보를 제공한 제2 거래자 노드(120)에게 수락 정보(accept)를 제공하고, 제2 거래자 노드(120)로부터 그 수락 정보에 대한 수락 확인 정보(confirm)가 제1 거래자 노드(110)로 제공되도록 함으로써, 제1 거래자 노드(110)에 포함되는 적어도 하나의 계정 및 제2 거래자 노드(120)에 포함되는 적어도 하나의 계정 사이의 거래를 확정할 수 있다.
한편, 본 발명의 일 실시예에 따르면, 자산 거래 개시의 요청이 제1 거래자 노드(110)의 서로 다른 계정에 기초하여 복수 회 요청되는 경우에, 위와 같이 자산 거래 개시가 요청된 제1 거래자 노드(110)의 서로 다른 계정에 동일한 수락 대상 오퍼 정보가 제공될 수도 있다. 본 발명의 일 실시예에 따른 거래 확정 관리부는, 위와 같은 경우에, 제1 거래자 노드(110)에 포함되는 적어도 하나의 계정과 연관되는 정보를 참조하여, 위의 서로 다른 계정 사이에서 수락 대상 오퍼 정보에 대한 수락 순서를 결정할 수 있다.
예를 들어, 본 발명의 일 실시예에 따른 거래 확정 관리부는, 자산 거래 개시의 요청이 제1 거래자 노드(110)의 서로 다른 계정에 기초하여 복수 회 요청되는 경우에, 제1 거래자 노드(110)에 포함되는 적어도 하나의 계정과 연관되는 정보로서 위의 서로 다른 계정의 자산 거래 개시의 요청 순서를 참조하여, 위의 서로 다른 계정 사이에서의 수락 대상 오퍼 정보에 대한 수락 순서를 결정할 수 있다. 보다 구체적으로, 제1 거래자 노드(110)에 포함되는 A 계정 및 B 계정에 대하여 각각 자산 거래 개시가 요청되고, B 계정에 앞서 A 계정에 대하여 먼저 자산 거래 개시가 요청되며, A 계정 및 B 계정의 차입 요구 자산이 각각 500주 및 1000주이고, 제2 거래자 노드(120)에 포함되는 적어도 하나의 계정의 총 대여 가능 자산이 1000주(이러한 제2 거래자 노드(120)에 포함되는 적어도 하나의 계정의 총 대여 가능 자산에 관한 정보는 수락 대상 오퍼 정보에 포함될 수 있다.)라고 가정할 경우에, 거래 확정 관리부는, A 계정 및 B 계정의 자산 거래 개시의 요청 순서를 참조하여 A 계정, B 계정의 순서로 수락 대상 오퍼 정보에 대한 수락 순서를 결정할 수 있다. 즉, 제2 거래자 노드(120)에 의하여 제1 거래자 노드(110)에 포함되는 적어도 하나의 계정 및 제2 거래자 노드(120)에 포함되는 적어도 하나의 계정 사이의 거래가 최종적으로 확정될 경우, A 계정에 먼저 500주가 대여되고, 그 다음에 B 계정에 500주가 대여될 수 있다.
다른 예를 들어, 본 발명의 일 실시예에 따른 거래 확정 관리부는, 자산 거래 개시의 요청이 제1 거래자 노드(110)의 서로 다른 계정에 기초하여 복수 회 요청되는 경우에, 제1 거래자 노드(110)에 포함되는 적어도 하나의 계정과 연관되는 정보로서 위의 서로 다른 계정의 우선 순위를 참조하여, 위의 서로 다른 계정 사이에서의 수락 대상 오퍼 정보에 대한 수락 순서를 결정할 수 있다. 보다 구체적으로, 제1 거래자 노드(110)에 포함되는 A 계정 및 B 계정에 대하여 각각 자산 거래 개시가 요청되고, B 계정에 앞서 A 계정에 대하여 먼저 자산 거래 개시가 요청되며, A 계정 및 B 계정의 차입 요구 자산이 각각 500주 및 1000주이고, 제2 거래자 노드(120)에 포함되는 적어도 하나의 계정의 총 대여 가능 자산이 1000주이며(이러한 제2 거래자 노드(120)에 포함되는 적어도 하나의 계정의 총 대여 가능 자산에 관한 정보는 수락 대상 오퍼 정보에 포함될 수 있다.), 제1 거래자 노드(110)로부터 설정된 A 계정 및 B 계정의 우선 순위가 각각 2 순위 및 1 순위라고 가정할 경우에, 거래 확정 관리부는, A 계정 및 B 계정의 우선 순위를 참조하여 B 계정, A 계정의 순서로 수락 대상 오퍼 정보에 대한 수락 순서를 결정할 수 있다. 즉, 제2 거래자 노드(120)에 의하여 제1 거래자 노드(110)에 포함되는 적어도 하나의 계정 및 제2 거래자 노드(120)에 포함되는 적어도 하나의 계정 사이의 거래가 최종적으로 확정될 경우, B 계정에 1000주가 대여될 수 있다.
도 9는 본 발명의 계정별 자산 거래 지원에 관한 실시예에 따라 계정별로 자산 거래가 지원되는 과정을 예시적으로 나타내는 도면이다.
도 9를 참조하면, 본 발명의 일 실시예에 따라 제1 거래자 노드(110)에 포함되는 적어도 하나의 계정(즉, A 계정(211), B 계정(212), C 계정(213) 및 D 계정(214)) 및 제2 거래자 노드(120)에 포함되는 적어도 하나의 계정(즉, E 계정(221), F 계정(222), G 계정(223) 및 H 계정(224)) 사이에서 유가증권 대차 거래가 지원되는 상황을 가정해 볼 수 있다. 여기서, 제1 거래자 노드(110)는 유가 증권의 차입자일 수 있고, 제2 거래자 노드(120)는 유가 증권의 대여자일 수 있다.
먼저, 본 발명의 일 실시예에 따르면, 제1 거래자 노드(110)는 A 계정(211), B 계정(212), C 계정(213) 및 D 계정(214) 중 A 계정(211)을 선택하고 그 A 계정(211)에 관하여 제1 거래 조건을 설정함으로써 자산 거래 개시를 요청할 수 있다(210).
그 다음에, 본 발명의 일 실시예에 따라 제1 거래자 노드(110)의 A 계정(211)에 관하여 설정된 제1 거래 조건과 연관되는 오퍼 정보가 제2 거래자 노드(120)로부터 제1 거래자 노드(110)에게 제공될 수 있다(220).
그 다음에, 본 발명의 일 실시예에 따라 제2 거래자 노드(120)에서 제공되는 오퍼 정보가 수락 대상 오퍼 정보로서 결정되면, 제1 거래자 노드(110)로부터 위의 수락 대상 오퍼 정보를 제공한 제2 거래자 노드(120)에게 수락 정보가 제공될 수 있다(230). 여기서, 수락 대상 오퍼 정보에 해당하는 오퍼 정보가 자동적으로 제공되는 경우, 제2 거래자 노드(120)에 포함되는 E 계정(221), F 계정(222), G 계정(223) 및 H 계정(224) 사이에서 대여 가능 자산 대비 대여되는 자산의 비율이 서로 동일하도록, 제1 거래자 노드(110)에 포함되는 적어도 하나의 계정(즉, A 계정(211))과 제2 거래자 노드(120)에 포함되는 적어도 하나의 계정이 매칭될 수 있다. 또는, 수락 대상 오퍼 정보에 해당하는 오퍼 정보가 자동적으로 제공되는 경우, 제2 거래자 노드(120)에 포함되는 E 계정(221), F 계정(222), G 계정(223) 및 H 계정(224)의 우선 순위에 기초하여 순위가 높은 계정부터 자산이 대여되도록, 제1 거래자 노드(110)에 포함되는 적어도 하나의 계정(즉, A 계정(211))과 제2 거래자 노드(120)에 포함되는 적어도 하나의 계정이 매칭될 수 있다.
그 다음에, 본 발명의 일 실시예에 따라 제2 거래자 노드(120)로부터 제1 거래자 노드(110)에게 수락 확인 정보가 제공될 수 있다(240).
그 다음에, 위의 수락 대상 오퍼 정보를 기준으로 하여, 제1 거래자 노드(110)에 포함되는 적어도 하나의 계정(즉, A 계정(211)) 및 제2 거래자 노드(120)에 포함되는 적어도 하나의 계정 사이의 거래가 확정될 수 있다. 예를 들어, 본 발명의 일 실시예에 따르면, 제1 거래자 노드(110)에 포함되는 적어도 하나의 계정(즉, A 계정(211)) 및 제2 거래자 노드(120)에 포함되는 적어도 하나의 계정 사이의 거래 확정은 분산원장 네트워크에서 지원되는 스마트 계약(smart contract)을 기반으로 이루어질 수 있다.
그 다음에, 제1 거래자 노드(110) 및 제2 거래자 노드(120) 사이의 커뮤니케이션 정보를 참조하여 위의 확정되는 거래의 유효성이 검증될 수 있다. 한편, 본 발명의 일 실시예에 따른 유효성 검증은, 반드시 마지막 단계에서 이루어지는 것에만 한정되지 않고, 자산 거래 개시 단계, 오퍼 정보 제공 단계, 수락 정보 제공 단계, 수락 확인 정보 제공 단계 및 거래 확정 단계 중 적어도 하나의 단계에서 유효성 검증이 이루어질 수도 있음을 밝혀 둔다.
그 다음에, 제1 거래자 노드(110) 및 제2 거래자 노드(120)에게 거래된 내역 정보(예를 들어, 거래 내역서)가 제공될 수 있다.
도 10 내지 도 13은 본 발명의 계정별 자산 거래 지원에 관한 실시예에 기초하여 제공되는 사용자 인터페이스 화면을 예시적으로 나타내는 도면이다.
도 10을 참조하면, 본 발명의 일 실시예에 따라 계정을 관리하기 위한 사용자 인터페이스 화면이 제공될 수 있다. 본 발명의 일 실시예에 따르면, 위의 사용자 인터페이스 화면에서 계정 정보를 입력하고 "ADD" 버튼을 클릭함으로써 적어도 하나의 계정을 등록할 수 있다. 여기서, 계정 등록 시 요구되는 계정 정보에는, 계정 이름(List Name), 대차 계정 번호(Account Code), 펀드 코드(Fund Code), 예탁 자산 구분 코드(Custody Asset Type), 중개 기관(Intermediary), 거래 구분(TX Type), 만기 시 강제 상환 여부(Callable), 담보 구분(Coll Type), 현금 담보 기준 통화(Coll CCY), 배당금 비율(Div) 등이 포함될 수 있다. 한편, 본 발명의 일 실시예에 따르면, "Delete" 버튼을 이용하여 등록된 계정을 삭제할 수도 있다. 여기서, 대여 가능 자산을 보유하고 있는 계정을 삭제하는 경우 해당 계정이 보유한 대여 가능 자산이 함께 삭제될 수 있다.
도 11을 참조하면, 본 발명의 일 실시예에 따라 자동 오퍼를 설정하기 위한 사용자 인터페이스 화면이 제공될 수 있다. 보다 구체적으로, 본 발명의 일 실시예에 따르면, "Auto Offer" 탭에서 오퍼 정보가 자동적으로 제공될 수 있도록 설정할 수 있고, "Match Preference" 탭에서 제1 거래자 노드(110)에 포함되는 적어도 하나의 계정과 제2 거래자 노드(120)에 포함되는 적어도 하나의 계정을 매칭시키기 위한 기준을 설정할 수 있다. 예를 들어, "Match Preference" 탭의 하위 탭인 "Preferred Criterion" 탭에서 "Equal %"를 선택하는 경우, 제2 거래자 노드(120)에 포함되는 적어도 하나의 계정 사이에서 대여 가능 자산 대비 대여되는 자산의 비율이 서로 동일해질 수 있다. 또 다른 예를 들어, "Match Preference" 탭의 하위 탭인 "Preferred Criterion" 탭에서 "List Order"를 선택하는 경우, 제2 거래자 노드(120)에 포함되는 적어도 하나의 계정의 우선 순위에 기초하여 순위가 높은 계정부터 자산이 대여될 수 있다. 한편, "Match Preference" 탭의 하위 탭인 "List Order" 탭에서는, "Preferred Criterion" 탭에서 "List Order"를 선택 시 제2 거래자 노드(120)에 포함되는 적어도 하나의 계정의 우선 순위를 설정할 수 있다.
도 12를 참조하면, 본 발명의 일 실시예에 따라 제1 거래자 노드(110)에 포함되는 적어도 하나의 계정 및 제2 거래자 노드(120)에 포함되는 적어도 하나의 계정 사이의 확정된 거래 내역을 제공하기 위한 사용자 인터페이스 화면이 제공될 수 있다. 여기서, 위의 사용자 인터페이스 화면을 통해 제공되는 거래 내역에는, 거래 상대방, 고유 거래 아이디, 거래 종목 정보, 거래 수량, 거래 요율, 거래 체결 일시 등이 포함될 수 있다. 또한, 위의 사용자 인터페이스 화면을 통해 제공되는 거래 내역에는, 거래가 체결된 각 거래자 노드의 계정 정보가 포함될 수 있다. 예를 들어, 거래가 체결된 각 거래자 노드의 계정 정보에는 나의 계정 이름(My List Name), 나의 계좌 코드(My Account Code), 나의 대차 계정 번호(My SLB Number), 나의 펀드 코드(My Fund Code), 나의 예탁 자산 구분 코드(My Custody Asset Type), 상대방의 계좌 코드(CPTY Account Code), 상대방의 대차 계정 번호(CPTY SLB Number), 상대방의 펀드 코드(CPTY Fund Code), 상대방의 예탁 자산 구분 코드(CPTY Custody Asset Type) 등이 포함될 수 있다.
도 13을 참조하면, 본 발명의 일 실시예에 따라 수동 오퍼에 따른 거래 조건을 설정하기 위한 사용자 인터페이스 화면이 제공될 수 있다. 보다 구체적으로, 자산을 대여하는 거래자 노드는, 위의 사용자 인터페이스 화면의 "Negotiations" 탭에서, 자산 거래 개시 요청을 확인할 수 있고, 그 자산 거래 개시 요청에 기초하여 계정별 거래 조건을 설정할 수 있는 행(row)을 "+" 버튼을 클릭하여 생성할 수 있으며, 그 생성된 행에서 계정별 거래 조건을 설정한 후 "Submit All" 버튼을 클릭함으로써 수동적으로 오퍼 정보가 제공되도록 할 수 있다.
이상 설명된 본 발명에 따른 실시예는 다양한 컴퓨터 구성요소를 통하여 실행될 수 있는 프로그램 명령어의 형태로 구현되어 컴퓨터 판독 가능한 기록 매체에 기록될 수 있다. 상기 컴퓨터 판독 가능한 기록 매체는 프로그램 명령어, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다. 상기 컴퓨터 판독 가능한 기록 매체에 기록되는 프로그램 명령어는 본 발명을 위하여 특별히 설계되고 구성된 것이거나 컴퓨터 소프트웨어 분야의 당업자에게 공지되어 사용 가능한 것일 수 있다. 컴퓨터 판독 가능한 기록 매체의 예에는, 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체, CD-ROM 및 DVD와 같은 광기록 매체, 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체(magneto-optical medium), 및 ROM, RAM, 플래시 메모리 등과 같은, 프로그램 명령어를 저장하고 실행하도록 특별히 구성된 하드웨어 장치가 포함된다. 프로그램 명령어의 예에는, 컴파일러에 의하여 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용하여 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드도 포함된다. 하드웨어 장치는 본 발명에 따른 처리를 수행하기 위하여 하나 이상의 소프트웨어 모듈로 변경될 수 있으며, 그 역도 마찬가지이다.
이상에서 본 발명이 구체적인 구성요소 등과 같은 특정 사항과 한정된 실시예 및 도면에 의하여 설명되었으나, 이는 본 발명의 보다 전반적인 이해를 돕기 위하여 제공된 것일 뿐, 본 발명이 상기 실시예에 한정되는 것은 아니며, 본 발명이 속하는 기술분야에서 통상적인 지식을 가진 자라면 이러한 기재로부터 다양한 수정과 변경을 꾀할 수 있다.
따라서, 본 발명의 사상은 상기 설명된 실시예에 국한되어 정해져서는 아니 되며, 후술하는 특허청구범위뿐만 아니라 이 특허청구범위와 균등한 또는 이로부터 등가적으로 변경된 모든 범위는 본 발명의 사상의 범주에 속한다고 할 것이다.

Claims (19)

  1. 계정별로 자산 거래를 지원하기 위한 방법으로서,
    오퍼(offer) 정보가 적어도 하나의 거래자 노드로부터 제1 거래자 노드에게 제공되도록 하는 단계, 및
    상기 오퍼 정보 중 상기 제1 거래자 노드의 제1 거래 조건을 참조하여 결정되는 수락(accept) 대상 오퍼 정보를 기준으로 하여, 상기 제1 거래자 노드에 포함되는 적어도 하나의 계정 및 상기 수락 대상 오퍼 정보를 제공한 제2 거래자 노드에 포함되는 적어도 하나의 계정 사이의 거래를 확정하는 단계를 포함하는
    방법.
  2. 제1항에 있어서,
    상기 수락 대상 오퍼 정보에는, 상기 제2 거래자 노드에 포함되는 적어도 하나의 계정과 연관되는 정보가 포함되는
    방법.
  3. 제2항에 있어서,
    상기 제2 거래자 노드에 포함되는 적어도 하나의 계정과 연관되는 정보에는, 상기 제2 거래자 노드에 포함되는 적어도 하나의 계정이 보유한 대여 가능 자산에 관한 정보 및 상기 제2 거래자 노드에 포함되는 적어도 하나의 계정의 우선 순위에 관한 정보 중 적어도 하나가 포함되는
    방법.
  4. 제3항에 있어서,
    상기 거래 확정 단계에서, 상기 제2 거래자 노드에 포함되는 적어도 하나의 계정이 보유한 대여 가능 자산에 기초하여, 상기 제1 거래자 노드에 포함되는 적어도 하나의 계정과 상기 제2 거래자 노드에 포함되는 적어도 하나의 계정이 매칭되도록 하는
    방법.
  5. 제4항에 있어서,
    상기 제1 거래자 노드에 포함되는 적어도 하나의 계정과 상기 제2 거래자 노드에 포함되는 적어도 하나의 계정의 매칭은, 상기 제2 거래자 노드에 포함되는 적어도 하나의 계정마다 각각 설정되는 대여 가능 자산 대비 대여되는 자산의 비율 또는 대여되는 자산의 수량을 참조하여 매칭되는
    방법.
  6. 제3항에 있어서,
    상기 거래 확정 단계에서, 상기 제2 거래자 노드에 포함되는 적어도 하나의 계정의 우선 순위에 기초하여, 상기 제1 거래자 노드에 포함되는 적어도 하나의 계정과 상기 제2 거래자 노드에 포함되는 적어도 하나의 계정이 매칭되도록 하는
    방법.
  7. 제1항에 있어서,
    상기 제1 거래 조건에 기초한 자산 거래 개시의 요청은, 상기 제1 거래자 노드에 포함되는 적어도 하나의 계정 중에서 상기 제1 거래자 노드에 의하여 선택되는 계정에 기초하여 요청되는
    방법.
  8. 제7항에 있어서,
    상기 자산 거래 개시의 요청이 상기 제1 거래자 노드의 서로 다른 계정에 기초하여 복수 회 요청되는 경우, 상기 수락 대상 오퍼 정보에 대한 수락 순서는 상기 자산 거래 개시의 요청 순서를 참조하여 결정되는
    방법.
  9. 제7항에 있어서,
    상기 자산 거래 개시의 요청이 상기 제1 거래자 노드의 서로 다른 계정에 기초하여 복수 회 요청되는 경우, 상기 수락 대상 오퍼 정보에 대한 수락 순서는 상기 서로 다른 계정의 우선 순위를 참조하여 결정되는
    방법.
  10. 제1항에 따른 방법을 실행하기 위한 컴퓨터 프로그램을 기록하는 비일시성의 컴퓨터 판독 가능 기록 매체.
  11. 계정별로 자산 거래를 지원하기 위한 시스템으로서,
    오퍼(offer) 정보가 적어도 하나의 거래자 노드로부터 제1 거래자 노드에게 제공되도록 하는 오퍼 정보 관리부, 및
    상기 오퍼 정보 중 상기 제1 거래자 노드의 제1 거래 조건을 참조하여 결정되는 수락(accept) 대상 오퍼 정보를 기준으로 하여, 상기 제1 거래자 노드에 포함되는 적어도 하나의 계정 및 상기 수락 대상 오퍼 정보를 제공한 제2 거래자 노드에 포함되는 적어도 하나의 계정 사이의 거래를 확정하는 거래 확정 관리부를 포함하는
    시스템.
  12. 제11항에 있어서,
    상기 수락 대상 오퍼 정보에는, 상기 제2 거래자 노드에 포함되는 적어도 하나의 계정과 연관되는 정보가 포함되는
    시스템.
  13. 제12항에 있어서,
    상기 제2 거래자 노드에 포함되는 적어도 하나의 계정과 연관되는 정보에는, 상기 제2 거래자 노드에 포함되는 적어도 하나의 계정이 보유한 대여 가능 자산에 관한 정보 및 상기 제2 거래자 노드에 포함되는 적어도 하나의 계정의 우선 순위에 관한 정보 중 적어도 하나가 포함되는
    시스템.
  14. 제13항에 있어서,
    상기 거래 확정 관리부는, 상기 제2 거래자 노드에 포함되는 적어도 하나의 계정이 보유한 대여 가능 자산에 기초하여, 상기 제1 거래자 노드에 포함되는 적어도 하나의 계정과 상기 제2 거래자 노드에 포함되는 적어도 하나의 계정이 매칭되도록 하는
    시스템.
  15. 제14항에 있어서,
    상기 제1 거래자 노드에 포함되는 적어도 하나의 계정과 상기 제2 거래자 노드에 포함되는 적어도 하나의 계정의 매칭은, 상기 제2 거래자 노드에 포함되는 적어도 하나의 계정마다 각각 설정되는 대여 가능 자산 대비 대여되는 자산의 비율 또는 대여되는 자산의 수량을 참조하여 매칭되는
    시스템.
  16. 제13항에 있어서,
    상기 거래 확정 관리부는, 상기 제2 거래자 노드에 포함되는 적어도 하나의 계정의 우선 순위에 기초하여, 상기 제1 거래자 노드에 포함되는 적어도 하나의 계정과 상기 제2 거래자 노드에 포함되는 적어도 하나의 계정이 매칭되도록 하는
    시스템.
  17. 제11항에 있어서,
    상기 제1 거래 조건에 기초한 자산 거래 개시의 요청은, 상기 제1 거래자 노드에 포함되는 적어도 하나의 계정 중에서 상기 제1 거래자 노드에 의하여 선택되는 계정에 기초하여 요청되는
    시스템.
  18. 제17항에 있어서,
    상기 자산 거래 개시의 요청이 상기 제1 거래자 노드의 서로 다른 계정에 기초하여 복수 회 요청되는 경우, 상기 수락 대상 오퍼 정보에 대한 수락 순서는 상기 자산 거래 개시의 요청 순서를 참조하여 결정되는
    시스템.
  19. 제17항에 있어서,
    상기 자산 거래 개시의 요청이 상기 제1 거래자 노드의 서로 다른 계정에 기초하여 복수 회 요청되는 경우, 상기 수락 대상 오퍼 정보에 대한 수락 순서는 상기 서로 다른 계정의 우선 순위를 참조하여 결정되는
    시스템.
PCT/KR2022/012384 2021-08-19 2022-08-19 계정별로 자산 거래를 지원하기 위한 방법, 시스템 및 비일시성의 컴퓨터 판독 가능 기록 매체 WO2023022551A1 (ko)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
KR10-2021-0109782 2021-08-19
KR20210109782 2021-08-19
KR10-2021-0153841 2021-11-10
KR1020210153841A KR20230028091A (ko) 2021-08-19 2021-11-10 계정별로 자산 거래를 지원하기 위한 방법, 시스템 및 비일시성의 컴퓨터 판독 가능 기록 매체

Publications (1)

Publication Number Publication Date
WO2023022551A1 true WO2023022551A1 (ko) 2023-02-23

Family

ID=85240872

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2022/012384 WO2023022551A1 (ko) 2021-08-19 2022-08-19 계정별로 자산 거래를 지원하기 위한 방법, 시스템 및 비일시성의 컴퓨터 판독 가능 기록 매체

Country Status (1)

Country Link
WO (1) WO2023022551A1 (ko)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20100022139A (ko) * 2008-08-19 2010-03-02 동양종합금융증권 (주) 주식 대차 거래 방법
KR101377156B1 (ko) * 2013-11-21 2014-03-25 한국투자증권 주식회사 대차 거래 시스템 및 대차 거래 방법
KR101629893B1 (ko) * 2014-07-11 2016-06-13 키움증권 주식회사 대차거래 관리 시스템 및 수량 우선 순차 대여 배정 방법
KR20160116323A (ko) * 2016-09-27 2016-10-07 삼성증권주식회사 위탁 운용자산의 대차거래 시스템 및 그 방법
JP2019023925A (ja) * 2013-03-15 2019-02-14 シーエフピーエイチ， エル．エル．シー． ドル預託証券、電子的会員取引、及びレポ取引

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20100022139A (ko) * 2008-08-19 2010-03-02 동양종합금융증권 (주) 주식 대차 거래 방법
JP2019023925A (ja) * 2013-03-15 2019-02-14 シーエフピーエイチ， エル．エル．シー． ドル預託証券、電子的会員取引、及びレポ取引
KR101377156B1 (ko) * 2013-11-21 2014-03-25 한국투자증권 주식회사 대차 거래 시스템 및 대차 거래 방법
KR101629893B1 (ko) * 2014-07-11 2016-06-13 키움증권 주식회사 대차거래 관리 시스템 및 수량 우선 순차 대여 배정 방법
KR20160116323A (ko) * 2016-09-27 2016-10-07 삼성증권주식회사 위탁 운용자산의 대차거래 시스템 및 그 방법

Similar Documents

Publication Publication Date Title
WO2021230443A1 (ko) 자산 거래를 지원하기 위한 방법, 시스템 및 비일시성의 컴퓨터 판독 가능 기록 매체
CN110992028B (zh) 基于区块链网络的换汇平台的数据处理方法及装置
KR100917036B1 (ko) 부동산 전자거래 시스템 및 그 시스템을 이용한 부동산전자거래 방법
US20030004859A1 (en) Method and system for facilitating secure transactions
KR100979504B1 (ko) 부동산 중개 정보 서비스를 이용한 부동산 계약 체결서비스 장치 및 방법
JP2003533793A (ja) デリバティブ取引を電子的に実行するシステムとその方法
JP2003511759A (ja) 匿名の交渉と興味の指標をサポートする電子取引システム
KR102439399B1 (ko) 맞춤검색이 가능한 부동산 거래 플랫폼 서버 및 그 부동산 거래방법
KR102439401B1 (ko) 신뢰성 및 검색의 편리성이 향상된 부동산 거래 플랫폼 서버 및 그 부동산 거래 중개방법
CN111784128A (zh) 一种基于区块链的资产信息处理方法及系统
WO2018212580A1 (ko) 에스크로 서비스 보증 시스템 및 방법
KR20190119906A (ko) 블록체인 기반 중개 시스템
JP2003085371A (ja) 賃貸契約保険システム
WO2023022551A1 (ko) 계정별로 자산 거래를 지원하기 위한 방법, 시스템 및 비일시성의 컴퓨터 판독 가능 기록 매체
KR20090089745A (ko) 진성 확인된 중개사의 부동산 거래 정보를 제공하기 위한 방법, 시스템 및 컴퓨터 판독 가능한 기록 매체
US20030225680A1 (en) Escrow management system
JP2002373255A (ja) 決済情報ネットワークシステム及び情報処理装置，決済情報配信方法，プログラム並びに記憶媒体
KR20220041804A (ko) 온라인 주식 거래 관리 방법 및 시스템
US20220156842A1 (en) Data processing system, data processing method, and program
KR20180003778A (ko) 부동산 경매 펀딩 시스템 및 방법
KR20200104792A (ko) 비상장주식 거래 지원 장치 및 방법
KR20230028091A (ko) 계정별로 자산 거래를 지원하기 위한 방법, 시스템 및 비일시성의 컴퓨터 판독 가능 기록 매체
KR20230143587A (ko) 자산 거래를 지원하기 위한 방법, 시스템 및 비일시성의 컴퓨터 판독 가능 기록 매체
KR102218548B1 (ko) 부동산 p2p 중개 시스템 및 그 방법
JP5586971B2 (ja) Ｖｗａｐ取引市場システムおよびｖｗａｐ取引方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22858788

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE