System of long-term blockchain-based financial transactions management using machine-learning

Abstract

A system of blockchain-based tracking of a financial transaction, comprising a processing circuitry (PC) configured to: receive text of a financial transaction agreement (FTA); utilize a large language model (LLM) in conjunction with the received text to generate data indicative of a transaction map (TM), where the TM comprises: two or more blockchain addresses associated with respective parties of the financial transaction, and one or more required transaction events; deploy, utilizing a first blockchain address, a smart contract to the blockchain, the smart contract being configured to: obtain the TM, and write data based on the TM to the blockchain, thereby creating a permanent record of the TM, and the smart contract being further configured to, responsive to an invocation by the first blockchain address, the invocation being associated with data of a transaction event: write, to the blockchain, data at least partially derivative of the transaction event.

Description

[0001] SYSTEM OF LONG-TERM BLOCKCHAIN-BASED FINANCIAL

[0002] TRANSACTIONS MANAGEMENT USING MACHINE-LEARNING

[0003] TECHNICAL FIELD

[0004] The presently disclosed subject matter relates to financial transactions based on blockchain technology, and in particular to a system using machine- learning and managed wallets to conduct and monitor these transactions.

[0005] BACKGROUND

[0006] Problems of implementation in systems of utilizing blockchains in real-world financial transactions have recognized in the conventional art and various techniques have been developed to provide solutions.

[0007] GENERAL DESCRIPTION

[0008] According to one aspect of the presently disclosed subject matter there is provided a system of blockchain- based tracking of a financial transaction, the system comprising a processing circuitry (PC) configured to: a) receive text of a financial transaction agreement (FTA); b) utilizing at least one large language model (LLM) in conjunction with the received text, generate data indicative of a transaction map (TM), the TM comprising, at least: a. data indicative of two or more blockchain addresses, wherein each blockchain address is associated with a respective party of the financial transaction, and b. data indicative of one or more required transaction events; c) deploy, utilizing a first blockchain address, at least one smart contract to the blockchain, the at least one smart contract being configured to: obtain the TM, and write data based on the TM to the blockchain, thereby creating a permanent record of the TM, and

[0009] 03048725\35-01 the at least one smart contract being further configured to, responsive to an invocation by the first blockchain address, the invocation being associated with data of a transaction event: write, to the blockchain, data at least partially derivative of the transaction event.

[0010] In addition to the above features, the system according to this aspect of the presently disclosed subject matter can comprise one or more of features (i) to (xii) listed below, in any desired combination or permutation which is technically possible:

[0011] (i) the at least one smart contract is further configured to, subsequent to the invocation by the first blockchain address: verify compliance of the data of the transaction event with a current transaction state, wherein the current transaction state comprises: required transaction events comprised in the TM, and past transaction events verified by the one or more smart contracts as compliant, and and wherein the writing to the blockchain is responsive to a success of the verifying of compliance.

[0012] (ii) the one or more smart contracts is configured to perform the writing data based on the TM by: creating, on the blockchain, a transaction token (TT), the TT comprising a transaction identifier, and comprising metadata indicative of data comprised in the TM.

[0013] (iii) the TT is one of: an ERC-20 token, or an ERC-721 token.

[0014] 03048725\35-01 (iv) the one or more smart contracts is further configured to, subsequent to the creating the TT: for one or more parties of the transaction: a) create a copy of the TT; and b) assign the created copy of the TT to a blockchain address associated with the respective party.

[0015] (v) the at least one smart contract is further configured to, responsive to a first invocation, by a blockchain address that is not the first blockchain address, the first invocation being associated with data of a transaction event: responsive to a second invocation, by the first blockchain address, the second invocation being associated with data signaling of acceptance of the data of the transaction event: write, to the blockchain, data at least partially derivative of the transaction event.

[0016] (vi) the one or more smart contracts is configured to perform the writing the data at least partially derivative of the transaction event by: creating, on the blockchain, a current transaction state TT comprising a transaction identifier, and metadata indicative of, at least: i) the TM, ii) past transaction events verified by the one or more smart contracts as compliant, and iii) the transaction event.

[0017] (vii) the one or more smart contracts is further configured to, subsequent to the creating the current transaction state TT: for one or more parties of the transaction:

[0018] 03048725\35-01 a) create a copy of the current transaction state TT; and b) assign the created copy of the current transaction state TT to the respective party.

[0019] (viii) the PC is further configured to provide, to a user associated with a given blockchain address, the blockchain address having been assigned a created copy of the current transaction state TT: a software-as-a-service (SaaS) interface including a visual representation of one or more of: a. whether a financial transaction has completed, based on the current transaction state TT; b. on or more required transaction events, based on the current transaction state TT; c. historical payments signaled by a payment originator, based on the current transaction state TT; or d. historical payments initiated by an intermediary, based on the current transaction state TT.

[0020] (ix) the PC is further configured to, responsive to a user specification, in the SaaS interface, initiating a transaction event: invoking the one or more smart contracts, the invocation being associated with the user-specified transaction event data.

[0021] (x) the one or more smart contracts is configured to obtain the TM from data associated with an invocation by the first blockchain address.

[0022] (xi) the blockchain is permissioned.

[0023] 03048725\35-01 (xii) the blockchain conforms to an Ethereum protocol.

[0024] According to another aspect of the presently disclosed subject matter there is provided a processing circuitry-based method of blockchain-based tracking of a financial transaction, the method comprising: a) receiving text of a financial transaction agreement (FTA); b) utilizing at least one large language model (LLM) in conjunction with the received text to generate data indicative of a transaction map (TM), the TM comprising, at least: a. data indicative of two or more blockchain addresses, wherein each blockchain address is associated with a respective party of the financial transaction, and b. data indicative of one or more required transaction events; c) deploying, utilizing a first blockchain address, at least one smart contract to the blockchain, the at least one smart contract being configured to: obtain the TM, and write data based on the TM to the blockchain, thereby creating a permanent record of the TM, and the at least one smart contract being further configured to, responsive to an invocation by the first blockchain address, the invocation being associated with data of a transaction event: write, to the blockchain, data at least partially derivative of the transaction event.

[0025] This aspect of the disclosed subject matter can further optionally comprise one or more of features (i) to (xii) listed above with respect to the system, mutatis mutandis, in any desired combination or permutation which is technically possible.

[0026] 03048725\35-01 According to another aspect of the presently disclosed subject matter there is provided a computer program product comprising a computer readable non-transitory storage medium containing program instructions, which program instructions when read by a processor, cause the processing circuitry to perform a method of blockchain- based tracking of a financial transaction, the method comprising: a) receiving text of a financial transaction agreement (FTA); b) utilizing at least one large language model (LLM) in conjunction with the received text to generate data indicative of a transaction map (TM), the TM comprising, at least: a. data indicative of two or more blockchain addresses, wherein each blockchain address is associated with a respective party of the financial transaction, and b. data indicative of one or more required transaction events; c) deploying, utilizing a first blockchain address, at least one smart contract to the blockchain, the at least one smart contract being configured to: obtain the TM, and write data based on the TM to the blockchain, thereby creating a permanent record of the TM, and the at least one smart contract being further configured to, responsive to an invocation by the first blockchain address, the invocation being associated with data of a transaction event: write, to the blockchain, data at least partially derivative of the transaction event.

[0027] This aspect of the disclosed subject matter can further optionally comprise one or more of features (i) to (xii) listed above with respect to the system, mutatis mutandis, in any desired combination or permutation which is technically possible.

[0028] BRIEF DESCRIPTION OF THE DRAWINGS

[0029] 03048725\35-01 In order to understand the invention and to see how it can be carried out in practice, embodiments will be described, by way of non-limiting examples, with reference to the accompanying drawings, in which:

[0030] Fig. 1A illustrates a logical block diagram of a deployment of an example transaction monitoring platform, in accordance with some embodiments of the presently disclosed subject matter;

[0031] Fig. IB illustrates an alternative logical block diagram of a deployment of an example transaction monitoring platform, in accordance with some embodiments of the presently disclosed subject matter;

[0032] Fig- 2 is a logical block diagram of an example transaction monitoring platform, in combination with logical components that a transaction monitoring platform can initiate on a blockchain, in accordance with some embodiments of the presently disclosed subject matter;

[0033] Fig. 3 is a flow diagram of an example method of onboarding a user to a blockchain-oriented transaction monitoring platform, in accordance with some embodiments of the presently disclosed subject matter;

[0034] Fig. 4 is a flow diagram of an example method of initiating blockchain-based tracking of a financial transaction, in accordance with some embodiments of the presently disclosed subject matter; and

[0035] Fig. 5 is a flow diagram of an example method of tracking an event of a blockchain-monitored financial transaction, in accordance with some embodiments of the presently disclosed subject matter.

[0036] DETAILED DESCRIPTION

[0037] In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the invention. However, it will be understood by those skilled in the art that the presently disclosed subject matter may be practiced without

[0038] 03048725\35-01 these specific details. In other instances, well-known methods, procedures, components and circuits have not been described in detail so as not to obscure the presently disclosed subject matter.

[0039] Unless specifically stated otherwise, as apparent from the following discussions, it is appreciated that throughout the specification discussions utilizing terms such as "processing", "computing", "comparing", "encrypting", “decrypting”, "determining", "calculating", “receiving”, “providing”, “obtaining”, “emulating” or the like, refer to the action(s) and / or process(es) of a computer that manipulate and / or transform data into other data, said data represented as physical, such as electronic, quantities and / or said data representing the physical objects. The term “computer” should be expansively construed to cover any kind of hardware-based electronic device with data processing capabilities including, by way of non-limiting example, the processor, mitigation unit, and inspection unit therein disclosed in the present application.

[0040] The terms "non-transitory memory" and “non-transitory storage medium” used herein should be expansively construed to cover any volatile or non-volatile computer memory suitable to the presently disclosed subject matter.

[0041] The operations in accordance with the teachings herein may be performed by a computer specially constructed for the desired purposes or by a general-purpose computer specially configured for the desired purpose by a computer program stored in a non- transitory computer-readable storage medium.

[0042] Embodiments of the presently disclosed subject matter are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the presently disclosed subject matter as described herein.

[0043] Some embodiments of the presently disclosed subject matter are directed to a computer system facilitating blockchain-based monitoring of a multistage financial transaction.

[0044] 03048725\35-01 By way of non-limiting example: a real estate transaction based on payment stages or a loan or mortgage etc. can involve a number of parties e.g. buyer, seller, bank and / or other intermediaries.

[0045] Some embodiments of the presently disclosed subject matter provide a computerized system (e.g. a software-as-a-service (SaaS) platform) which interfaces to a blockchain, and provides functions including:

[0046] Enabling a project owner to immutably store the conditions / stipulations of the financial transaction

[0047] Providing interfaces to enable participating transaction parties to submit events to modify the transaction status. In some examples, a submitted event can be a signal to a transaction party to perform an offchain action (e.g. transferring money).

[0048] Enabling participating transaction parties to monitor the transaction status and entire transaction history

[0049] Ensuring that events submitted by participating transaction parties are in conformance with the conditions / stipulations of the financial transaction and / or the platform itself.

[0050] Attention is directed to Fig. 1A, which illustrates a logical block diagram of a deployment of an example transaction monitoring platform, in accordance with some embodiments of the presently disclosed subject matter.

[0051] Transaction monitoring platform (SaaS) 120 can be a processing circuitry-based system as described below, with reference to Fig. 2.

[0052] Transaction monitoring platform (SaaS) 120 can be operably connected to blockchain 125 (for example: via a wired or wireless internet connection).

[0053] 03048725\35-01 Blockchain 125 can be e.g. a private, permissioned blockchain. Blockchain 125 can be a blockchain supporting smart contracts. For example, blockchain 125 can be based on Ethereum or a similar platform.

[0054] Transaction monitoring platform (SaaS) 120 can be operably connected to offchain storage 135. Offchain storage 135 can be an online storage system configured for utilization in conjunction with blockchain-based resources. For example, offchain storage 135 can be a service such as Arweave or Interplanetary File System (IPFS).

[0055] In the example of Fig. 1A, three distinct parties (i.e. buyer, seller, and financial intermediary) utilize computer systems (i.e. buyer’s system 105, seller's system 115, and financial intermediary system 110 respectively) to access transaction monitoring platform (SaaS) 120 (e.g. via a wired or wireless internet link).

[0056] In the example of Fig. 1A, transaction monitoring platform (SaaS) 120 maintains blockchain wallets on behalf of the parties of a transaction. Specifically, in the example of Fig. 1A, transaction monitoring platform (SaaS) 120 maintains buyer wallet 130A, seller wallet 130B, and intermediary wallet 130C.

[0057] In some other examples, one or more of the parties can maintain their own blockchain client or wallet, and can access the blockchain independently. In the example of Fig. IB, financial intermediary system 110 includes intermediary wallet 130C.

[0058] Fig- 2 is a logical block diagram of an example transaction monitoring platform, in combination with logical components that a transaction monitoring platform can initiate on a blockchain, in accordance with some embodiments of the presently disclosed subject matter.

[0059] Transaction monitoring platform (processing circuitry) 200 can include processor 205 and memory 210.

[0060] Processor 205 can be a suitable hardware-based electronic device with data processing capabilities, such as, for example, a general purpose processor, digital signal processor (DSP), a specialized Application Specific Integrated Circuit (ASIC), one or

[0061] 03048725\35-01 more cores in a multicore processor, etc. Processor 205 can also consist, for example, of multiple processors, multiple ASICs, virtual processors, combinations thereof etc.

[0062] Memory 210 can be, for example, a suitable kind of volatile and / or non-volatile storage, and can include, for example, a single physical memory component or a plurality of physical memory components. Memory 210 can also include virtual memory. Memory 210 can be configured to, for example, store various data used in computation.

[0063] Transaction monitoring platform (processing circuitry) 200 can be configured to execute several functional modules in accordance with computer-readable instructions implemented on a non-transitory computer-readable storage medium. Such functional modules are referred to hereinafter as comprised in the processing circuitry. These modules can include, for example, contract verification and payment map generation module 225, generative Al models 230, smart data wallets unit 215, buyer wallet 235A, seller wallet 235B, and intermediary wallet 235C.

[0064] Contract verification and payment map generation module 225 can receive and process a financial transaction governing document (FTGD). The FTGD can be a legal document (e.g. contract) governing a transaction (e.g. mortgage, auto loan etc.). The FTGD can be in a conventional human language e.g. English, Chinese etc. The FTGD can potentially be in any suitable text format e.g. Microsoft™-Word, Hypertext Transfer Protocol (HTML), American Standard Code for Information Interchange (ASCII) or unicode text etc. In some examples, the FTGD can be written in or include machine- readable formats / languages such as extensible markup language (XML), Javascript object notation (JSON) etc.

[0065] Contract verification and payment map generation module 225 can receive the FTGD - for example - from an upload of a user. In some examples, transaction monitoring platform (processing circuitry) 200 associates “roles” with users. In such examples, transaction monitoring platform (processing circuitry) 200 can e.g. permit upload of a new FTGD to a user with role of “seller” or “payment recipient”, thereby creating a new financial transaction for tracking.

[0066] Contract verification and payment map generation module 225 can process FTGD, and utilize it to generate data indicative of a “transaction map”.

[0067] 03048725\35-01 A “transaction map” as used herein includes a specification of data pertaining to a financial transaction to be performed. The transaction map can include, for example:

[0068] Financial institution account details of transacting parties and intermediaries Blockchain addresses of transacting parties and intermediaries

[0069] Total amount of transaction (e.g. in fiat currency)

[0070] Transaction events: events (e.g. payments) which are scheduled or required to occur in the process of the financial transaction. Specifications of transaction events can include various data such as: o Payment dates (e.g. fixed dates, date ranges etc.) o associated payment amounts (fixed amounts, fixed amounts with late penalties, amounts varying e.g. according to prevailing interest rates etc.).

[0071] The transaction map can be in any format e.g. text file, JSON etc.

[0072] The transaction map can specify transaction events using “low-level” descriptions (e.g. JSON specifications of each individual required event) or using “high-level” descriptions (e.g. specifications of total number of payments, range of allowable payment dates, range of allowable payment amounts).

[0073] It is noted that the transaction map can permit missed events (e.g. missed payments), absent events (e.g. prepayments) etc.

[0074] Contract verification and payment map generation module 225 can include generative artificial intelligence (Al) models 230. Generative Al models 230 can be - for example - one or more large language models (LLMs). Generative Al models 230 can be suitably trained to receive an FTGD to generate a transaction payment map (or data indicative of a transaction payment map).

[0075] Transaction monitoring platform (processing circuitry) 200 can include smart data wallets unit 215.

[0076] 03048725\35-01 Smart data wallets unit 215 can implement blockchain wallet and smart contract deployment functionality for one or more users (e.g. SaaS users). In the example of Fig. 2, smart data wallets unit 215 include buyer wallet 235A, seller wallet 235B, intermediary wallet 235C, for use by buyer (i.e. payment originator), seller (i.e. payment recipient) and banking intermediary.

[0077] Each of the smart data wallets 235A 235B 235C can be associated with a distinct blockchain address, which is in turn associated with the respective SaaS user. Thus smart data wallets 235A 235B 235C can hold coins and tokens. In some examples, smart data wallets 235A 235B 235C can also deploy (and communicate with) smart contracts.

[0078] Transaction monitoring platform (processing circuitry) 200 (e.g. seller wallet 235B) can deploy various smart contracts to the blockchain. For example: transaction monitoring platform (processing circuitry) 200 can deploy vouching smart contract 245. In some examples, transaction monitoring platform (processing circuitry) 200 can deploy additional smart contracts which perform specific functionality e.g. per-party wallet admin smart contract 255, and payment data management smart contract 250. In some other examples, functionality described here for vouching smart contract 245 can performed by one or more smart contracts in a different configuration.

[0079] In some examples, the wallet associated with the user who provided an FTGD deploys the one or more smart contracts.

[0080] Vouching smart contract 245 can perform - for example - functions including: receiving transaction map data and creating derivative blockchain records enabling parties to read the current transaction status updating transaction status in the blockchain (e.g. in response to an invocation by the wallet of the owner of the project) receive notifications of events or requests to update transaction status (e.g. in response to an invocation by a wallet of a transaction party other than the

[0081] 03048725\35-01 owner of the project). Vouching smart contract 245 can provide these requests to the wallet of the project owner, who can then instruct vouching smart contract 245 to update the transaction status enforcing policies of the transaction monitoring platform (processing circuitry) 200 and of the transaction payment map. For example, vouching smart contract 245 can reject requests to change status if these do not conform to platform rules or the transaction map

[0082] More specifically: in some embodiments, vouching smart contract 245 can, responsive to an invocation by the blockchain address associated with the deployer, and accompanied by data of a transaction event: i) verify compliance of the data of the transaction event with a current transaction state. It is noted that the current transaction state can be represented by required transaction events contained in the TM in combination with past transaction events (for example: transaction events that were verified by vouching smart contract 245 as compliant and then written to the blockchain). ii) responsive to successful verification of compliance, write, to the blockchain: data derivative of the transaction event. For example: vouching smart contract 245 can write all the data of the transaction (e.g. payment details). Alternatively vouching smart contract 245 can write some updated some data that is at least partially derivative of the transaction event (e.g. an outstanding balance which has been updated based on the transaction amount).

[0083] In some examples, a per-party wallet admin smart contract 255 is deployed and provides the vouching smart contract 245 with information related to user-specific platform policies.

[0084] 03048725\35-01 In some examples, payment data management smart contract 250 is deployed and provides the vouching smart contract 245 with services related to reading and / or writing of on-chain data. In some examples, payment data management smart contract 250 writes data to tokens owned by the project owner, as described below.

[0085] It is noted that the teachings of the presently disclosed subject matter are not bound by the system described with reference to Figs. 1A-1B, and Fig. 2. Equivalent and / or modified functionality can be consolidated or divided in another manner and can be implemented in any appropriate combination of software with firmware and / or hardware and executed on a suitable device. The system can be a standalone entity, or integrated, fully or partly, with other entities.

[0086] Attention is directed to Fig. 3, which is a flow diagram of an example method of onboarding a user to a blockchain- oriented transaction monitoring platform, in accordance with some embodiments of the presently disclosed subject matter.

[0087] A user can register 305 with the transaction monitoring platform (processing circuitry) 200. In so doing, the user can supply e.g. his / her identity and banking details, as well as what role the user will assume in monitored financial transactions. The role can be, for example: buyer (payment originator), seller (payment recipient), or intermediary.

[0088] Transaction monitoring platform (processing circuitry) 200 can then accordingly assign a policy pertaining to which blockchain and / or smart contract operations the user (and his / her wallet) is entitled to execute. For example: a project owner (e.g. seller) might be entitled to create new vouching smart contracts, and to supply these transaction payment maps, whereas other users / wallets can lack this entitlement. Similarly, a buyer can be entitled to request initiation of payment, and an intermediary can be entitled to receive and confirm the request to initiate payment.

[0089] These roles and entitlements can - in some embodiments - be enforced by vouching smart contract 245, as described hereinbelow.

[0090] 03048725\35-01 Atention is directed to Fig. 4, which is a flow diagram of an example method of initiating blockchain-based tracking of a financial transaction, in accordance with some embodiments of the presently disclosed subject mater.

[0091] Transaction monitoring platform (processing circuitry) 200 (for example: contract verification and payment map generation unit 225) can receive 405 text of a contractual document (i.e. FTGD). The FTGD can be a legal document (e.g. contract) governing a transaction (e.g. mortgage, auto loan etc.) in accordance with the description of the FTGD hereinabove with reference to Fig. 2. In this context, “text” is interpreted to include illustrations, diagrams, etc.

[0092] In some examples, transaction monitoring platform (processing circuitry) 200 (for example: contract verification and payment map generation unit 225) receives the FTGD via upload of one of the parties of the transaction (e.g. the seller / payment recipient).

[0093] Transaction monitoring platform (processing circuitry) 200 (for example: contract verification and payment map generation unit 225) can utilize machine learning (e.g. at least one large language model, such as generative Al models 330 described above) to generate 410 a transaction map (TM) from the FTGD.

[0094] The TM can include some or all data to be used for completing and managing stages of the financial transaction. TM can include, for example: data indicative of two or more blockchain addresses associated with a respective party of the financial transaction data indicative of one or more required transaction events; e.g. fixed payment dates, fixed payment amounts etc. as described above

[0095] The TM can additionally include, for example:

[0096] Identification, physical address details, and bank details of payment originator and payment recipient, and banking intermediary

[0097] Identification and physical address details of banking intermediary

[0098] 03048725\35-01 Details and / or permitted variations or alterations of required transaction events: fixed or varying penalties for late payments, minimum payments in addition to maximum payments, additional intermediaries etc.

[0099] It is noted that transaction monitoring platform (processing circuitry) 200 (for example: contract verification and payment map generation unit 225) can determine that the FTGD is inadequate to create a TM, or that the generated TM does not meet predefined requirements of the TM (e.g. if the TM generation failed to identify a name or bank details in the FTGD. In such cases, that transaction monitoring platform (processing circuitry) 200 (for example: contract verification and payment map generation unit 225) can halt processing.

[0100] Transaction monitoring platform (processing circuitry) 200 (for example: seller wallet 130B) can next deploy 415 a vouching smart contract (VSC) 245 to the blockchain. As described in detail above with reference to Fig. 2, the VSC 245 (possibly in coordination with other entities or other smart contracts 250 255) can be configured to enforce platform rules regarding roles and permissions of the different transaction parties, enforce TM rules regarding conduct of transactions, and manage recording of the transaction activities on the blockchain 125 / offchain storage 135.

[0101] Transaction monitoring platform (processing circuitry) 200 (for example: seller wallet 130B) can next invoke 420 the VSC 245, and in so doing provide the generated TM to the VSC 245. Transaction monitoring platform (processing circuitry) 200 (for example: seller wallet 130B) can provide the TM via - for example - an application binary interface (ABI) of the VSC 245, or via a different mechanism.

[0102] VSC 245 can execute on blockchain 125, as known in the art. VSC 245 can then obtain the TM (for example via an ABI, or via a different mechanism.

[0103] VSC 245 can immutably record the TM data on blockchain 125. To do this, in some embodiments, VSC 245 creates 425 a transaction token (TT) based on the TM. The term “token” is herein interpreted to include a digital asset (e.g. incorporating metadata) that is assigned to a particular blockchain address. The metadata of the token can be

[0104] 03048725\35-01 stored on-chain or off-chain, as described in detail hereinabove. In some embodiments, the token can be a Ethereum ERC-20 fungible token or ERC-721 non-fungible token (NFT).

[0105] By way of non-limiting example: VSC 245 can e.g. create metadata based on the TM, store the metadata to offchain storage 135, and VSC 245 can then mint a new NFT, including a link to the metadata in the NFT. The newly-minted NFT can have a particular token identifier.

[0106] It is noted that some data of the TM can be secret. According, some of the NFT metadata can be stored in an encrypted format.

[0107] VSC 245 can assign the newly-minted NFT to the wallet of the party which provided the TM (in this example: seller wallet 235B).

[0108] VSC 245 can then (optionally) mint 430 additional NFTs containing the TM data (e.g. partially or fully encrypted for decryption by one of the transaction participants), and can respectively assign these NFTs to the wallets of other transaction participants 235 A 235C. In this manner, transaction participants can determine a current state of the transaction by invoking the VSC to read (and if necessary decrypt) the TM data from the NFT stored in their respective smart data wallets.

[0109] Attention is directed to Fig. 5, which is a flow diagram of an example method of tracking an event of a blockchain-monitored financial transaction, in accordance with some embodiments of the presently disclosed subject matter.

[0110] A user (e.g. payment originator) can access 505 e.g. a SaaS -based platform transaction monitoring platform (processing circuitry) 200.

[0111] The user can then receive 510 e.g. an indication from SaaS-based platform transaction monitoring platform (processing circuitry) 200, that a payment of the transaction is due or will soon be due. Platform transaction monitoring platform (processing circuitry) 200 can determine whether a payment is due from a particular user by e.g. scanning for NFTs assigned to the user, and by utilizing the VSC to read the metadata of the NFTs. In some other examples, platform transaction monitoring platform

[0112] 03048725\35-01 (processing circuitry) 200 can determine whether a payment from a particular user is due in a different fashion (e.g. by accessing other blockchain records).

[0113] The user can then signal 515 to platform transaction monitoring platform (processing circuitry) 200 (e.g. via a graphical user interface) to proceed with a payment of a transaction. In some examples, the user can specify various payment details e.g. payment amount, day and time for a payment to be executed etc. In some examples, transaction monitoring platform (processing circuitry) 200 (e.g. via a graphical user interface) can ensure that the user only specifies payment details which are in accordance with the transaction payment map data recorded in the NFT.

[0114] The user’s smart data wallet (e.g. buyer wallet 235A) can next invoke 520 VSC 245, providing the payment request and (when applicable) payment details to VSC 245.

[0115] VSC 245 can validate the user’s request e.g. a) ensure that the user is entitled by platform policy to initiate payment requests and b) ensure that the payment request is compliant with the transaction requirements of the current transaction state. For example: VSC 245 can determine whether the requested payment is due, whether it is of the correct amount, whether it was already paid etc. In some examples, platform transaction monitoring platform (processing circuitry) 200 can signal the wallet that deployed VSC 245 (e.g. intermediary wallet 235 C), that an event request (i.e. payment request) is pending.

[0116] The financial intermediary’s smart data wallet (e.g. intermediary wallet 235A) can receive 530 and inspect the the payment request (e.g. by invoking VSC 245). The user’s smart data wallet (e.g. intermediary wallet 235A) can then itself invoke VSC 245 to signal acceptance or rejection of the payment request.

[0117] Upon acceptance of the payment, the financial intermediary should - for example - perform the payment as requested (e.g. through an offchain transfer of fiat currency).

[0118] Upon invocation by the financial intermediary’s smart data wallet (e.g. intermediary wallet 235A) (and responsive to the financial intermediary’s acceptance of the payment request), VSC 245 can mint 535 a new token according to the updated transaction state (i.e. the accepted payment), and assign this token to the financial

[0119] 03048725\35-01 intermediary’s smart data wallet (e.g. intermediary wallet 235A). VSC 245 can then also mint additional token reflecting the updated transaction state, and assign them to the respective smart data wallets of other parties (e.g. buyer and seller).

[0120] It is noted that the teachings of the presently disclosed subject matter are not bound by the flow diagrams illustrated in Figs. 3-5, the illustrated operations can occur substantially concurrently, or out of the illustrated order. It is also noted that whilst the flow chart is described with reference to elements of the system Figs. 1A-1B, and Fig. 2, this is by no means binding, and the operations can be performed by elements other than those described herein.

[0121] It is to be understood that the invention is not limited in its application to the details set forth in the description contained herein or illustrated in the drawings. The invention is capable of other embodiments and of being practiced and carried out in various ways. Hence, it is to be understood that the phraseology and terminology employed herein are for the purpose of description and should not be regarded as limiting. As such, those skilled in the art will appreciate that the conception upon which this disclosure is based may readily be utilized as a basis for designing other structures, methods, and systems for carrying out the several purposes of the presently disclosed subject matter.

[0122] It will also be understood that the system according to the invention may be, at least partly, implemented on a suitably programmed computer. Likewise, the invention contemplates a computer program being readable by a computer for executing the method of the invention. The invention further contemplates a non-transitory computer-readable memory tangibly embodying a program of instructions executable by the computer for executing the method of the invention.

[0123] Those skilled in the art will readily appreciate that various modifications and changes can be applied to the embodiments of the invention as hereinbefore described without departing from its scope, defined in and by the appended claims.

[0124] 03048725\35-01

Claims

CLAIMS1. A system of blockchain-based tracking of a financial transaction, the system comprising a processing circuitry (PC) configured to: a) receive text of a financial transaction agreement (FTA); b) utilizing at least one large language model (LLM) in conjunction with the received text, generate data indicative of a transaction map (TM), the TM comprising, at least: a. data indicative of two or more blockchain addresses, wherein each blockchain address is associated with a respective party of the financial transaction, and b. data indicative of one or more required transaction events; c) deploy, utilizing a first blockchain address, at least one smart contract to the blockchain, the at least one smart contract being configured to: obtain the TM, and write data based on the TM to the blockchain, thereby creating a permanent record of the TM, and the at least one smart contract being further configured to, responsive to an invocation by the first blockchain address, the invocation being associated with data of a transaction event: write, to the blockchain, data at least partially derivative of the transaction event.

2. The system of claim 1, wherein the at least one smart contract is further configured to, subsequent to the invocation by the first blockchain address: verify compliance of the data of the transaction event with a current transaction state, wherein the current transaction state comprises: required transaction events comprised in the TM, and03048725\35-01past transaction events verified by the one or more smart contracts as compliant, and and wherein the writing to the blockchain is responsive to a success of the verifying of compliance.

3. The system of claim 1, wherein the one or more smart contracts is configured to perform the writing data based on the TM by: creating, on the blockchain, a transaction token (TT), the TT comprising a transaction identifier, and comprising metadata indicative of data comprised in the TM.

4. The system of claim 3, wherein the TT is one of: an ERC-20 token, or an ERC- 721 token.

5. The system of claim 3, wherein the one or more smart contracts is further configured to, subsequent to the creating the TT: for one or more parties of the transaction: a) create a copy of the TT; and b) assign the created copy of the TT to a blockchain address associated with the respective party.

6. The system of claim 1, wherein the at least one smart contract is further configured to, responsive to a first invocation, by a blockchain address that is not the first blockchain address, the first invocation being associated with data of a transaction event: responsive to a second invocation, by the first blockchain address, the second invocation being associated with data signaling of acceptance of the data of the transaction event:03048725\35-01write, to the blockchain, data at least partially derivative of the transaction event.

7. The system of claim 6, wherein the one or more smart contracts is configured to perform the writing the data at least partially derivative of the transaction event by: creating, on the blockchain, a current transaction state TT comprising a transaction identifier, and metadata indicative of, at least: i) the TM, ii) past transaction events verified by the one or more smart contracts as compliant, and iii) the transaction event.

8. The system of claim 7, wherein the one or more smart contracts is further configured to, subsequent to the creating the current transaction state TT: for one or more parties of the transaction: a) create a copy of the current transaction state TT; and b) assign the created copy of the current transaction state TT to the respective party.

9. The system of claim 8, wherein the PC is further configured to provide, to a user associated with a given blockchain address, the blockchain address having been assigned a created copy of the current transaction state TT: a software-as-a-service (SaaS) interface including a visual representation of one or more of: a. whether a financial transaction has completed, based on the current transaction state TT; b. on or more required transaction events, based on the current transaction state TT;03048725\35-01c. historical payments signaled by a payment originator, based on the current transaction state TT; or d. historical payments initiated by an intermediary, based on the current transaction state TT.

10. The system of claim 9, wherein the PC is further configured to, responsive to a user specification, in the SaaS interface, initiating a transaction event: invoking the one or more smart contracts, the invocation being associated with the user-specified transaction event data.

11. The system of claim 1, wherein the one or more smart contracts is configured to obtain the TM from data associated with an invocation by the first blockchain address.

12. The system of claim 1 , wherein the blockchain is permissioned.

13. The system of claim 1, wherein the blockchain conforms to an Ethereum protocol.

14. A processing circuitry-based method of blockchain- based tracking of a financial transaction, the method comprising: a) receiving text of a financial transaction agreement (FTA); b) utilizing at least one large language model (LLM) in conjunction with the received text to generate data indicative of a transaction map (TM), the TM comprising, at least: a. data indicative of two or more blockchain addresses, wherein each blockchain address is associated with a respective party of the financial transaction, and b. data indicative of one or more required transaction events;03048725\35-01c) deploying, utilizing a first blockchain address, at least one smart contract to the blockchain, the at least one smart contract being configured to: obtain the TM, and write data based on the TM to the blockchain, thereby creating a permanent record of the TM, and the at least one smart contract being further configured to, responsive to an invocation by the first blockchain address, the invocation being associated with data of a transaction event: write, to the blockchain, data at least partially derivative of the transaction event.

15. A computer program product comprising a computer readable non-transitory storage medium containing program instructions, which program instructions when read by a processor, cause the processing circuitry to perform a method of blockchain-based tracking of a financial transaction, the method comprising: a) receiving text of a financial transaction agreement (FTA); b) utilizing at least one large language model (LLM) in conjunction with the received text to generate data indicative of a transaction map (TM), the TM comprising, at least: a. data indicative of two or more blockchain addresses, wherein each blockchain address is associated with a respective party of the financial transaction, and b. data indicative of one or more required transaction events; c) deploying, utilizing a first blockchain address, at least one smart contract to the blockchain, the at least one smart contract being configured to: obtain the TM, and write data based on the TM to the blockchain, thereby creating a permanent record of the TM, and03048725\35-01the at least one smart contract being further configured to, responsive to an invocation by the first blockchain address, the invocation being associated with data of a transaction event: write, to the blockchain, data at least partially derivative of the transaction event.03048725\35-01

Images