Automated system and method for transaction management

Abstract

The present invention relates to IT in the financial industry, particularly to an automation system, device, and method for transaction management, which can be used for automated transaction management and control. The automation system for transaction management includes a centralized management device 1, at least two user management devices each having a user interface, and a service provider device 4. Each user management device is connected to the centralized management device 1 via a communication channel via at least one service provider device 4. The present invention can reduce the load on the automation system for transaction management, improve reliability during transactions, and speed up information processing.

Description

Detailed Description of the Invention

[0001] [Technical Field] The present invention relates to IT in the financial industry, in particular to automated systems, apparatus and methods for trade management, which can be used for the automated management and control of trades as well as the arrangement of sales of goods and services. [Background technology]

[0002] Financial technology, especially that related to cashless payments, is rapidly developing, and overlay services are one example of this. Overlay services are software and hardware services developed to improve various consumer payment services (for individuals and businesses), increase security, and simplify and facilitate transactions. In the financial industry, overlay services may precede, follow, or be used independently of payment. One type of overlay service is the transaction support service described herein.

[0003] A known invention in the art describes a method and computer system for conducting a commercial transaction between a consumer and a transactor: Patent RU2702085C2 (see G06Q20 / 00, 18.01.2016). The known method includes initiating a transaction with a transactor by a consumer computer system, which then requests an authority dynamic value from a central platform; receiving a payment account selection request from the central platform by the consumer computer system from two or more consumer payment accounts; and receiving a selection by the consumer computer system of a payment account from the two or more consumer payment accounts. The consumer computer system then receives the authority dynamic value from the central platform, the authority dynamic value corresponding to the primary account number (PAN) of the selected payment account. The commercial transaction is completed by the transactor computer system using the authority dynamic value received. The computer system for conducting a commercial transaction between a consumer and a transactor is configured to implement the above-described method.

[0004] The drawbacks of this method and computer system are that it does not have the ability to control the number of user requests for documents related to a transaction, and it is not possible to perform preliminary checks and prepare payments before funds are transferred, resulting in overloading the computer system, increasing transaction times, and increasing the likelihood of errors.

[0005] The most similar solution to the claimed automated system, device, and method for transaction management is the system, device, and method described in Patent RU2581784 (see G06Q20 / 00, 2011.02.11). The known automated system includes a centralized management device, at least two user management devices using a communication channel that ensures access of the user management devices to the centralized management device via at least one service provider device, and a user interface module configured to provide access to the centralized management device to any user. The known centralized management device (platform) has a centralized database configured to store information about user registrations, credentials, and preferences, and means for automating transaction management. The known automated method includes providing access to the centralized management device to at least two users via a communication channel via at least one service provider device, registering the users, and storing each user's access credentials in the centralized database.

[0006] The drawbacks of this invention include the fact that the bill provision service can only be accessed via one service provider, which severely limits the functionality of the service and makes it impossible to control the number of user requests for transaction-related documents. This results in overloading the automated system and lengthening transaction times. Another drawback is that it is technically impossible to use the system and method to perform pre-checks and prepare payments before funds are transferred. This can lead to errors during transactions. Description of the Invention

[0007] The present invention aims to improve the reliability, quality and speed of electronic document management in conducting various transactions, including but not limited to commercial transactions, by conducting traceable transactions and registering the fulfillment of obligations by the parties.

[0008] The technical result of the claimed invention is a reduced load, increased reliability and faster information processing during transactions on automated systems and devices for managing transactions.

[0009] Improving the reliability of information processing shall be understood to mean providing information security when exchanging messages in automated systems, enabling safe transactions, reducing the likelihood of errors during transactions, registering transactions, and verifying outgoing and incoming transaction-related information.

[0010] By managing the number of transaction-related document requests, supporting information exchange within the system via service providers, and executing information exchange synchronously or asynchronously, the load on automated systems and devices for transaction management is reduced. Furthermore, reducing the load on automated systems for transaction management speeds up information processing during transactions.

[0011] This technical result is achieved due to the fact that the automated system for transaction management comprises a centralized management device configured to perform transaction support services and at least two user management devices equipped with user interfaces, and uses a communication channel to ensure access of the user management devices to the centralized management device via at least one service provider device. The centralized management device is configured as a hardware and software system for automating transaction management, and includes a synchronization processing area, a compatibility area, and an application processing area for processing information about transactions from users and for logical control. The central control device includes control means designed to limit the number of user requests for transaction related information transmitted to the central control device over the communication channel to a set number. In a particular embodiment, the system includes at least one user bank manager configured to act as a service provider and connected to a central manager via a communication channel. The user's bank control device is connected to the central control device using a communication channel via at least one service provider device. The user's means of communicating with the user interface provided to indirectly access the centralized control device (through the service provider) is used as the user's control device. The system includes at least one intermediary bank manager configured to act as a service provider and connected to a central manager via a communication channel. The intermediary bank manager is connected to the central manager using a communication channel via at least one service provider device. The system includes at least one supervisory authority control device configured to act as a service provider and connected to a central control device via a communication channel. The supervisory authority control device is connected to the central control device using a communication channel via at least one service provider device.

[0012] A system for transaction management includes at least one bank payment agent manager configured to act as a service provider and connected to a centralized management device via a communication channel. The bank payment agent manager is connected to the central control unit using a communication channel via at least one service provider unit. The system includes an operational clearing center management device connected to at least one user bank management device and an intermediary bank management device via a communication channel. The central control device is configured to manage user profiles.

[0013] The at least one service provider device is configured to provide the user with an interface for registration, checking identification parameters and user authentication, as well as an interface for data storage by creating a new user account.

[0014] The hint generation module and document provision module that check the number of hint usages are used as control means designed to limit the number of user requests for transaction-related information sent to the centralized control device over the communication channel to a set number.

[0015] For processing and logical control of transaction-related information from users, the synchronous processing area is configured to generate rapid responses to user requests and their submission to the users, the compatibility area of ​​the centralized control device is configured to queue transaction-related requests, and the application processing area of ​​the centralized control device is configured to perform synchronous and asynchronous processing.

[0016] The centralized control device has a centralized database configured to store information regarding user registrations, credentials, and preferences, as well as means for automating transaction management. wherein the means for automating transaction management comprises: means for receiving and submitting to the user at least one transaction-related document; A means of issuing at least one transaction-related document; A means of classifying at least one transaction-related document; A means for generating at least one trading scenario. In certain embodiments, the document receiving and submitting means comprises a document management module, a document serving module, a notification and download link delivery assurance module (store and forward module), a hint generation module, and a queue manager module.

[0017] The transaction-related document issuing means includes a user profile module and a service subscription module. The transaction scenario generator includes a contract module, a remittance and acceptance certificate module, an invoice module, a payer bank debit statement module, a payee bank credit statement module, a template module, an approval module, a redirection module, a billing module, and a report generation module.

[0018] The transaction classifier includes a document matching module. All modules included in the transaction related document issuing means, the transaction scenario generating means and the transaction classifying means include filters configured to match documents related to transactions and included in the queue manager module with each other. The centralized database is made up of the databases of all modules of the centralized control device, which form a single network via communication channels. The document management module is configured to perform analysis and validation.

[0019] The transaction related document publisher is configured to publish complete information about a transaction for the first time in the automated system and share links to previously published information. The transaction related document issuing means is configured to receive and provide information about the transaction at the request of the user by using the unique hint. The transaction-related document issuing means is configured to create a report on the transaction and provide it to the user. The centralized database includes a unique identifier associated with each user and at least one of the user's service providers.

[0020] 1. An automated method for transaction management, comprising: providing access to a centralized control device to at least two users via a communication channel through at least one service provider device; registering the users; and storing access credentials for each user in a centralized database; Creating a user account; Providing each user with access to one or at least two service providers simultaneously; Authenticating users and publishing transaction-related documents on a network of automated systems for transaction management, via the users' service providers; generating a user request to conduct a transaction on the user's management device; classifying the received information at the centralized control device via the information classification means; generating transactions on a centralized device to a centralized database storing transaction scenario templates for authorizing, verifying, and conducting various transactions; Registering, comparing and tracking contracts related to transactions; Controlling, via hints, the number of requests for transaction-related documents received over the communication channel and user device access to transaction-related information. In certain embodiments, the user's account and transaction related information is posted to a centralized control device after the user's service provider device has checked the user's authorization. Storing data regarding user preferences in a centralized database on a central control device. Generating a unique identifier for each transaction and document at the centralized control device. Providing users with access to transaction-related information upon request. Providing users with a means to edit accounts in the centralized management device. Matching transaction-related documents included in the queue manager module with each other using filters of modules included in the transaction-related document issuing means, transaction scenario generating means, and transaction classification means. To carry out secured transactions after the supervisory authority has confirmed compliance with the terms of the transaction. conditions.

[0021] Transaction support services (automated systems) are overlay services used for issuing invoices and their electronic settlement, with the aim of standardizing and accelerating workflows, electronically delivering invoices (payment orders with inspection) from payers to recipients, and providing payment preparation. They are also a mechanism for digitizing workflows between users (economic entities). In particular, documents that can be used to confirm a user's transaction include contracts, acceptance certificates, invoices (sales receipts and reports) with payment amounts, payer's bank debit statements, payee's bank debit statements, regulatory approvals, statements from secured banks, and delivery notes (documents submitted by merchants to buyers when delivering goods). This list is not exhaustive and is provided by way of example only.

[0022] As used herein, "transaction" refers to any action of users, in particular natural persons, legal entities or government authorities, aimed at establishing, modifying or terminating civil rights and obligations. Transactions between users are registered in the transaction support service (automated system) for electronic management.

[0023] The transaction information is information about the transaction, including the user's transaction request and notifications about all stages of the transaction (such as notifications of issuance on the transaction support service network and confirmed payment notifications).

[0024] The user (individual, corporate or government authority) is the subject of information exchange in the transaction support service and uses a user management device to interact with the user's service provider device and the user bank. The user can be the initiator or recipient of the transaction creation process as well as the payer or payee with respect to invoices and payments. User banks are financial institutions that are the primary exchange of information for transaction support services, provide electronic access to users' bank accounts and facilitate settlements, particularly in relation to the Operations and Payments Clearing Centre (OPCC).

[0025] A user (payer or payee) management device is a personal communication device used to manage transactions within an automated system for both information exchange and payment purposes. Any device with a user interface that allows transaction management and data exchange and reception of information related to the transaction (workflow) and / or payment transaction can be used as a payer or payee management device. In particular, communication means with a user interface, such as a mobile phone, tablet, personal computer, terminal, ATM, etc., can be used as a user management device. What these devices have in common is that the interface of such devices requires the user to be pre-authenticated by the bank.

[0026] The payer is the subject of the information exchange in the transaction support service and uses its management device to directly interact with the service provider device and its bank's management device. These devices are configured to act as a service provider for the purposes of requesting and receiving soft copy documents and initiating payments to payees. For example, soft copy documents include document agreements, certificates, invoices, and resolutions sent to the payer, and the payer can be an individual, a legal entity, or a government authority.

[0027] When a user is a payer, the bank used for payment is called the payer bank and the service provider of such user is called the payer service provider. The payee is the subject of information exchange in the transaction support service, and uses the payee management device to initiate electronic invoice issuance (issuance of payment order with acceptance) via the payee service provider, and waits for the issued invoice to be deposited into the payee's bank account at the payee's bank. Any organization, including individuals, corporations, and government agencies, can be a payee.

[0028] Individuals may be understood to mean, but are not limited to, purchasers of goods, deliverables or services, sole proprietors, private individuals and self-employed persons. Legal entities include, but are not limited to, trading companies, telecommunications companies, public utility companies, apartment associations, non-commercial partnerships of gardeners, and consumer cooperatives for building dachas.

[0029] If the user is a payee, the bank used to receive the payment is called the payee bank, and the service provider of such user is called the payee service provider. Any transaction between users, including the purchase or payment of a service, is still essentially a contract, even though it does not require a signed contract each time. Users, specifically the payer and payee (initiator and receiver), make a decision: one decides to sell something or provide a service at a certain price, and the other decides to pay for a service or purchase something at a certain price. A process generates only one accompanying document, such as a sales receipt.

[0030] The payer bank control device, as defined by the standard, is at least one computing device of a credit institution that provides services to the payer, the corresponding account of which must be debited when funds are transferred at the payer's command. The recipient bank control device, as defined by the standard, is at least one computing device of a credit institution that provides services to the recipient, the corresponding account of which must receive the funds when transferring funds for the recipient.

[0031] The user service provider device is a software and hardware system including at least one server for exchanging user information in a transaction support service and providing access to the electronic services of said service, in particular providing access to accounts, activity reporting in the transaction support service, the means for creating, editing, publishing and distributing transaction-related documents, subscribing to said documents, providing user profile data to subscribers (those who have applied for subscriptions), initiating payments, and user notifications. Each user service provider device is configured to provide users with an interface for user registration, verification of identification parameters, user authentication, and also allows data storage upon creation of new user accounts. This reduces the load on automated systems and devices for transaction management.

[0032] The software and hardware systems of each bank (user bank, intermediary bank, bank paying agent) and supervisory authority of the automated system for transaction management can additionally function as service providers if additionally supplemented with custom equipment and specially configured software. Thus, as a result of the above, the user's bank management devices, in particular the payer bank management device and the payee bank management device, the intermediary bank management device, the bank paying agent management device, and the supervisory authority management device are configured to function as service providers.

[0033] The Central Management Device (CMD) is a software and hardware system that includes servers that ensure the operation of the transaction support service system and application software. Each server is designed as a computing system that includes transaction management automation means and its modules.

[0034] A module is a specific software component. The set of modules defines the behavior of the CMD hardware and software system. The number of modules of the same type depends on the load capacity of the CMD; the higher the load demands on the CMD, the more modules of the same type may be required to operate simultaneously. The number of modules of different types depends on the variety of purposes for which contracts are concluded using the CMD (e.g., sales contracts, service contracts, joint operating contracts, storage contracts, insurance contracts, etc.).

[0035] A combination of software and hardware systems including a user management device, a user bank management device, a service provider device, a central management device, an intermediary bank management device, a supervisory authority management device, a bank paying agent management device, and an operational clearing center management device is an automated system for transaction management.

[0036] A process is a set of actions aimed at creating and editing transaction-related documents (contracts, certificates, invoices, statements, etc.) in an automated system for transaction management that results from an information flow.

[0037] An information flow is a sequence of messages exchanged by users in an automated system for managing transactions, the processing of which results in the establishment, modification or termination of legal relationships between legal entities, individuals or governmental authorities (the creation or modification of a particular document or the receipt of information about that document).

[0038] A message is the basic unit of information flow that transfers the contents (payload) of transaction-related documents. Control devices of individuals, legal entities, and government authorities exchange electronic messages that form one logical unit and receive data about transactions, including information about users (in particular, the payer, the payer's bank, the payee, the payee's bank, the payment system, the intermediary bank, the transaction amount, and the fees collected by the system user in case of funds transfer).

[0039] An information flow is considered local if all messages forming the information flow are exchanged only between the user and its service provider, i.e., no centralized control device participates in it. This information flow is formed outside the automated system for transaction management.

[0040] Data elements are the basic units of a message and form the blocks within the message. A block is a fragment of a transaction-related document, consisting of a set of data elements. It can be created (completely) in one process as an integral part of the document and can be used as a reference to such a fragment in one or more subsequent processes where other documents are created. At least two blocks are combined into one data block.

[0041] A scenario is a fixed sequence of planned services (deliveries) and / or transaction-related processes (documents). A scenario or contract can be planned in advance, before the contract is signed; that is, a template of a scenario can be included in a contract that is executed using such a scenario, or a template for the entire contract can be used. In general, a scenario does not belong to one contract; it is possible to create scenarios to be used for different contracts or to include them in one contract.

[0042] Process triggers are CMD parameters that influence the selection of the particular information flow used for a particular process that forms the documents associated with a transaction. The framework for an automated system for transaction management shows all the connections between the main system components: processes, transaction-related documents, users, and information flows. The framework sets rules for using information flows according to the processes.

[0043] The protocol of an automated system for transaction management is a set of rules and technical procedures that allow several users (from two to as many as needed) to exchange messages using management devices participating in the network of an automated system for transaction management. The protocol covers all interactions that take place in the automated system: - Process and related transaction documentation; - Information flow that forms each process - Triggers that define the rules for the information flow used in a process; - A framework that connects users' management devices, processes, transaction documents and information flows; - messages that form information flows; - blocks that form the message; - Data component, the basic unit of a block. A CMD user profile (profile) is a collection of data that identifies a user and their preferences. The user profile management process involves creating, updating and deleting a user profile, in particular adding, changing and deleting bank details.

[0044] The supervisory authority is the user (institution) that verifies compliance with the transaction terms (issuance of authorization) and the law by the payer and the payee, ensuring that the payer receives the goods or services specified in the contract and that the payee receives the funds in accordance with the contract for the delivered goods or services. The collateral bank acts as the enforcer of the financial collateral terms. In the case of secured transactions, the supervisory authority uses an automated system for transaction management and notifies the collateral bank (via authorization) that the payee (merchant or service provider) has met the transaction terms and can transfer the payer's funds to the collateral bank.

[0045] Approval is the supervisory authority's conclusion regarding the terms of the transaction. The supervisory authority can be either a government authority or a legal entity (private organization) authorized by the transacting parties (users) and registered (certified) by a central control device.

[0046] The following bodies may act as government authorities: Federal State Registration, Cadist and Mapping Service (Rosreestr), State Transport Security Inspection Service (GIBDD), Federal Tax Service (FTS), Federal Financial Supervision Service (Rosfinmonitoring), and Russian Post. This list is by way of example and not of limitation. Legal entities (authorized organizations) include, for example, commercial postal operators or commercial quality controllers. The Competent Authority Management Device (CAMD) is at least one computing device of a Competent Authority that is configured to verify that users (payers and payees) comply with the terms of the transaction.

[0047] A Bank Paying Agent (BPA) is an entity that is an information exchange entity in an automated system for transaction management (transaction support services), and in particular ensures the transfer of funds from payer to payee. With regard to invoices and their payments, the following companies can act as BPAs: - trading enterprises; - Service companies. A Bank Paying Agent Control Device (BPAD) is an organizational control device that secures the transfer of funds from the payer to the payee.

[0048] An intermediary bank (IB) is an information exchange entity in the automated system for transaction management and acts as an intermediary in settlements. The IB accumulates funds received from the payer for a certain period of time and transfers them to the payee's account after receiving the relevant instructions (from the BPA or as a result of the supervisory authority's approval), in particular after the execution of a secured transaction that the system has notified to the supervisory authority, or after receiving a registration for funds transfer from the automated system for transaction management based on the BPA's data.

[0049] An intermediary bank can function as follows: - In secured transactions involving the collateral bank-supervisory authority; - BPA Bank - If you pay your bill via BPA. An Intermediary Banking Device (IBMD) is an organization's hardware and software management system that accumulates funds received from payers for a certain period of time and transfers the funds to payee accounts after receiving relevant instructions. When complemented with custom equipment and specially configured software, an IBMD can function as an intermediary banking service provider.

[0050] The operational clearing center management device is at least one computing device configured to support fund transfers between the management devices of the user's bank and process fund transfer instructions to the settlement system, and configured to receive authorization requests from the management device of the BPA bank, forward such authorization requests to the payer's bank, receive responses, return such responses to the BPA bank, receive payment instructions, submit such instructions for settlement, form a net position, submit such net position to the settlement system, and further submit reports to the user's bank and the BPA bank.

[0051] A hint is an identifier generated in the CMD hint generation module and is a sequence of letters and numbers that a user's service provider submits in a request to CMD to control the number of user requests for documents sent to CMD over a communication channel.

[0052] The number of requests allowed by the hint is determined by the category the user is in. A set of user categorization parameters is used to determine the user category.

[0053] The logical categorization of users in CMD is performed based on categorization parameters specified for the recipient and stored in a centralized database in the form of a recipient configurable profile. The recipient configurable profile is a means of user categorization. The recipient (user) has the right (possibly on a commercial basis) to request from CMD the parameters under which the user is categorized. The number of requests allowed by hints is also specified for each user category in the recipient configurable profile of CMD. In this way, at least two user categories are determined and this data is transferred to the hint generation module.

[0054] [Brief description of the drawing] The invention is illustrated by the following figures: [Figure 1] Figure 1 shows the framework of an automated system for transaction management. [Figure 2] Figure 2 shows a flowchart of an automated system for transaction management. [Figure 3] Figure 3 shows a structural diagram of a centralized management device (CMD). [Figure 4] Figure 4 shows a structural diagram of the CMD application processing area. [Figure 5] Figure 5 shows a process flowchart of information flow in an automated system for transaction management. [Figure 6] Figure 6 shows an example of a transaction between users (payer and payee) involving an OPCC (Operational Payment Clearing Center). [Figure 7] Figure 7 shows an example of a scenario template for a contract. [Figure 8] Figure 8 shows an example of a scenario template for a set of related contracts.

[0055] The automated system for trade management (Figure 1) is a distributed or "cloud computing system" for managing trades. The automated system for transaction management comprises a CMD 1, at least two user management devices (a payer management device 2 and a payee management device) with installed user interfaces, and a service provider device 4. Each user management device is connected to the CMD 1 via a communication channel via at least one service provider device 4. The CMD 1 and the service provider devices 4 form a network of the automated system for transaction management 5, in which all service provider devices 4 interact only through the CMD 1, which is the only central counterparty. The CMD 1 manages the identities of the service providers and the interactions of all service providers 4 via the CMD in all transaction processes (scenarios, information flows). Identification management by the CMD means, in particular, registering and issuing unique identifiers to service providers of user banks, intermediary banks, bank clearing agents, and supervisory authorities, storing these identifiers in a centralized database, and publishing these identifiers across the network of the automated system for transaction management.

[0056] The user's means of communication with the installed user interface for accessing the service provider device can be used as the user's management device. Smartphones, tablets, smart watches, computers (including mobile devices), television set-top boxes, etc., which have technical characteristics that allow the user interface (application) for accessing the CMD to be installed, access to the Internet for payment services, and access to personal bank accounts (for online services) can be used as the user's communication means. The above list is not exhaustive.

[0057] Depending on the transaction scenario, the automated system for transaction management comprises at least one user bank manager (recipient bank manager 6 or payer bank manager 7), an intermediary bank manager (IBMD) 8, a supervisory authority manager (CAMD) 9 and a bank settlement agent manager (BPAD) 10.

[0058] The CMD is a key architectural component of the automated system for transaction management, which may have from two to any number of user management devices depending on the technical characteristics of the automated system for transaction management. At the same time, the CMD is configured to manage user profiles, which means creating, updating or deleting user profiles, in particular adding, changing or deleting bank details.

[0059] Figure 2 shows a flowchart of an automated system for trade management, along with its main users and interactions. All interactions that occur in this system are regulated by protocols, particularly with regard to: - The process and associated transaction documents and their users (payer and payee, transaction initiator and recipient); - the information flows that form each process; - Triggers that define the rules for the information flow used in a process; - A framework that connects users (participants), processes, transaction documents, triggers, and information flows; - messages that form information flows; - blocks that form the message; - Data element, the basic unit of a block. In addition to the protocol of the automated system for managing transactions, users communicate using other protocols and communication languages ​​(Figure 1): - payment protocols, - Service Provider APIs, - Proprietary API protocol, - PIS / AIS API protocol. An API (Application Programming Interface) is an interface (language) that allows programs to communicate with each other.

[0060] The payment protocol covers user interactions, particularly with banking and payment services (e.g., Mir Payment System, Bank of Russia services, Faster Payments System services, standard payment orders processed by CSC of the Bank of Russia, etc.), to perform the actual transfer of funds between the user and their bank. The above list is not exhaustive.

[0061] The user interacts directly with at least the following via the management device: - Initiating an information flow with a service provider, for example through the service provider's API, leading to specific transaction-related documents; - Interacting with the user's bank manager, for example via a proprietary protocol (through the bank's channel).

[0062] The Service Provider API (SP API) shown in Figure 2 covers the interaction between the service provider and the user to initiate transactions, particularly payments, and requests for information about transaction status, particularly account status.

[0063] PIS / AISAPI (Payment Initiation Service / Account Information Service) is a service for initiating payments or providing account information, and is used to initiate payments or provide information about bank accounts when the roles of the user's service provider and the user's bank belong to different entities. Otherwise, the service provider and the bank are the same entity and such interactions are performed locally within one entity, without the need to use PIS / AIS API.

[0064] To make changes to the network of transaction support services, all users interact exclusively with their service provider equipment via the SP API (Figure 2). A user acting as a payer initiates the transaction process by sending a request for a transaction to another user (in particular a payee / user bank / regulatory authority / bank paying agent / intermediary bank).

[0065] The above list is not limiting and other devices may be included that perform the above user functions. Based on the legal status of the user and the relevant legislation of the automated system, as the payee and payer (initiator and receiver) when carrying out a transaction that initiates the issuance of an invoice (fee) and the execution of a payment corresponding to the issued invoice (fee), the transaction is classified as follows: - B2B - Business to Business; - C2B - Consumer to Business; - P2P - person to person, C2C - consumer to consumer; - B2G - Business to Government; - C2G - Consumer to Government. The centralized management device (Figure 3) is configured as a software and hardware system that includes user registration, qualification certificates, preference information 2022-563211, document receiving and submission means, transaction-related document issuing means, transaction classification means, and transaction scenario generation means.

[0066] The CMD has a synchronization processing area 11, a compatibility area 12 and an application processing area 13. The processing performed in the designated areas (11-13) allows the processing and logical control of information relating to transactions received from service providers. The proposed CMD architecture ensures system operation by using both the "subscription-delivery" asynchronous message exchange template and the "request-response" synchronous message exchange template.

[0067] The synchronous processing area 11 includes control means designed to limit the number of times a user needs to access transaction-related information, and may be configured as a hint generation module 30 and a document serving module 15 corresponding to a synchronously operating server, such as, but not limited to, a web server. In the synchronous processing area, requests / messages are received, checked, and processed in real time. The system performs parsing, authentication, service provider authentication, validation, logging, conversion to an internal representation and forwarding to a compatibility area, checking hints provided by the service provider, generating a quick response, and sending it to the sender.

[0068] The synchronization processing area 11 includes document receiving and submitting means, which include: - document management module 14 - a module configured to receive messages, extract information from them, verify the sender and forward them for processing (registry), - document providing module 15 - a module configured to respond to a request containing a hint, first check the hint and then provide the requested information; - Notification and Download Link Delivery Guarantee Module (Store and Forward Module) 16 - a module configured to notify the CMD that a document has been prepared and is ready to be sent to the recipient, and - Hint generation module 30.

[0069] The compatibility area 12's document management module 14, document provision module 15, notification and download link delivery assurance module (store and forward module) 16, hint generation module 30 and queue manager module 31 form the means for receiving and submitting documents.

[0070] The compatibility domain 12 corresponds to a server that acts as a message queue manager (queue manager module 31) and provides a bidirectional communication channel between the synchronous processing domain 11 and the application processing domain 13. The compatibility domain 12 (bidirectional communication channel) is a type of buffer that realizes an asynchronous communication pattern between the synchronous processing domain and the application processing domain. In the compatibility domain, messages converted into an internal representation are received and queued, from which they are extracted for application processing by software modules in the application processing domain 13. For each message, the software modules in this domain enforce the following delivery principles (these principles are usually called policies):

[0071] Durability policy - time of message delivery to the processing module; Security policies - setting which specific modules can access certain messages in the queue; Message Removal Policy - sets the criteria for removing messages from the queue; Delivery policy - guarantees guaranteed delivery of messages to processing modules; Routing policy - sets the location of processing modules for delivering messages from queues to such modules; Batching policy - sets the possibility to forward multiple messages to a processing module for processing at once. Queuing policy - Sets the queuing time. Acknowledgment Policy - Ensures that notification of message delivery to the processing module 13 is delivered to the document management module 14.

[0072] Application Processing 13 (Synchronous / Asynchronous) The processing domain includes processing of user transaction requests both on receipt (synchronous) and in offline (batch) mode (asynchronous), and determines the domain architecture and allocation of functions.

[0073] The CMD area of ​​the application process (FIGS. 3 and 4) includes at least a transaction-related document issuing means, at least a transaction classification means, and at least a transaction scenario generating means. The transaction document issuing means (Figure 4) includes: - User Profile Module 17 - a module configured to register each automated system user and keep user information up to date; - Service Subscription Module 18 - A module configured to register notifications to a user (payer) for documents from a specific user (payee) and notify the user (payee).

[0074] Thus, the transaction-related document issuing means is configured as follows: - Register and keep up to date information about each user of the automated system; - Publish complete transaction information for the first time in the automated transaction management system and share links to previously published information. - Extract and provide transaction information upon request from users; - Generate and provide reports on transactions to users.

[0075] The transaction scenario generator includes modules for combining different documents within a transaction and processing transaction-related documents and related databases, including, but not limited to: - Contracts module 19 - a module configured to register contracts, compare them and check whether they are included in a particular scenario; - Remittance and Acceptance Certificate Module 20 - a module that registers acceptance certificates and matches them with the contracts in which they may be included; - Invoice module 21 - a module that registers invoices and matches them with the contracts they may be included in; - module 22 for payer bank debit details - a module that registers the fund debit details from the payer bank, matches them with the invoice, creates the payee notice and prepares it for sending to the payee; - Module 23 for recipient bank credit details - a module that registers credit details from the recipient bank and matches them with previous invoices; -Template module 24 - a module for registering issued templates; - Approval module 25 - a module that receives, stores and reconciles approvals with issued invoices and associated fund debit and credit statements; -Redirection module 26 - a module that receives and registers requests for invoice redirection; - Invoicing module 27 - a module that registers invoices and checks them against the relevant contracts or certificates, -Report Generation Module 29 - A module that generates reports on transactions.

[0076] All modules inform the queue manager module 31 about the performance of the subsequent forwarding of this data to the guaranteed delivery module of notifications (store and forward module) 16 and the document serving module 15 .

[0077] The transaction classification tool consists of the following modules: - a document matching module 28 that provides information about the inflow and outflow of the user's business (commercial) activities, and modules that process other types of documents, such as organizational and management, financial, accounting and reporting, and statistical documents (not shown in Figure 4). The reconciliation mechanism tracks the account status and its changes based on the processing of debit (credit) statements received by the system, from the "unpaid" / "fully or partially paid" status to the "paid" / "payment received" status and further technical reconciliation processes. The reconciliation mechanism is performed by the transaction document reconciliation module 28 and aims to manage the payment status and thus improve the reliability of the transaction.

[0078] Each of the modules 15 to 31 has its own database. The centralized database is made up of the databases of all the modules 15 to 31 of the CMD that form a single network via communication channels. All modules in the application processing area 13, including the transaction-related document issuing means, transaction scenario generating means, and transaction classification means, include a filter that compares the document type placed in the queue manager module 31 from the compatibility area 12 with the document type set in the filter and extracts only messages of document types that match the filter settings.

[0079] The centralized database contains a unique identifier corresponding to each user and its service provider. In particular, a user is understood to be a payer, a payee, a user's bank (payer's bank, payee's bank), a supervisory authority, a bank paying agent, an intermediary bank, etc. The synchronous operation of CMD1 is used when CMD1 can complete a process in a relatively short time where it is desirable to maintain communication. The asynchronous operation of CMD1 is used when CMD1 cannot complete processing in a relatively short time, where maintaining communication is desirable.

[0080] By implementing the above-described automated system for transaction management and centralized management device, it is possible to reduce the load on the automated system for transaction management, speed up information processing, and reduce the possibility of transaction failure. In particular, the speedup of processing and notification transmission when using e-workflow is achieved for the following reasons: - subscription of a user (recipient or payee) to documents from a particular user (initiator or payer); - a User (recipient or payee) to be notified of documents addressed to him by other Users (initiators or payers); - Use hints to manage document requests, - Use the provider's network. - Use of synchronous / asynchronous information exchange execution in automation systems.

[0081] The automated transaction management system works as follows (Figure 1). To become a system user, a user (payer or initiator) must create an account and generate a transaction request using the management device 2. This requires installing and launching a relevant application provided by the service provider 4 or accessing the service provider's website. As a result, the user is presented with an interface offering authorization or registration. Each user is given the right to access several service providers simultaneously.

[0082] If the user chooses to register, the service provider 4 presents the user with an interface for registration with all the fields to be filled in (abbreviated or full name of the organization, phone number, email, TIN, location or registered address, bank name, account number, etc.). After this, the service provider 4 checks whether the user is already registered in the automated system for transaction management. To do so, it checks all the basic identification parameters of the user (payer), such as phone number, email, TIN, etc., and ensures that they are unique within the system.

[0083] If all basic identification parameters are unique, the service provider device checks whether they really belong to the user (whether the user is authenticated). For this purpose, a text message, push message, or instant messenger notification, a phone call, an email with an authentication link, etc. can be used. To verify the user's authenticity, the service provider can also contact the user's bank. The service provider device is configured to perform other additional user checks at the service provider's discretion. After successful registration and authentication, the service provider creates a new user account and stores the data.

[0084] Users may use various means to modify their CMD accounts, including various features of the service provider device's application or website. Users may edit and delete accounts, and may also receive data directly from the Unified Identification and Authentication System of the Russian Federation or other similar systems for account transfer to the service provider. In particular, users may add new bank accounts or modify existing bank accounts, add new phone numbers or email addresses, and edit other information at the service provider device's discretion.

[0085] If the user wants to change the account parameters, the service provider device 4 displays a user interface for making changes to the account parameters and confirms the changes. The service provider device 4 is configured to verify whether these changes have actually been made by the user. After verification, the user's service provider device 4 saves the new data by updating the user account. Through the user's management device 2, the user (payer) is notified that the account has been successfully updated and is redirected to the main page of the application or website of the user's service provider device 4.

[0086] After providing the user (payer) with access to the CMD1 via the service provider device 4, the user (payer) generates a request for the transaction in his management device 2. This request is sent to the CMD1 via a communication channel. A transaction-related document is then published on the network of the automated system for transaction management 5 for the purpose of tracking transaction-related data. Through module 15, the user's service provider device 4 receives notification of the publication of transaction-related data.

[0087] Issued documents related to a transaction remain on Network 5 until a final state is set (e.g., an invoice in "paid in full" state) or the transaction expires and its current state is no longer a final state (e.g., "finally delivered").

[0088] Next, consider the processing that occurs in the CMD (Figure 3). The document management module 14 in the synchronous processing area 11 of the CMD receives a transaction request, extracts transaction-related information from the request, verifies the user (payer), and processes the transaction request. For example, the transaction-related information includes the parties, subject, conditions, details, and delivery date of the transaction. For each transaction and each document, the CMD generates a unique identifier (URL) that allows users to access the transaction-related information and document upon request.

[0089] In the compatibility domain 12, a queue manager module 31 translates incoming requests for transactions and places them in a queue from which they are dequeued for application processing by software modules in the application processing domain 13.

[0090] Subsequently, in the application processing area 13 (Fig. 4), the document matching module 28, which provides information about the user's incoming and outgoing business (commercial) activities, classifies the received information. The contract module 19 registers and compares contracts and checks whether a scenario contains each transaction-related contract. The remittance and acceptance certificate module 20 registers acceptance certificates and matches them with the contracts they may be included in. The invoice module 21 registers invoices and matches them with the contracts they may be included in. The payer bank debit statement module 22 registers debit statements from the payer bank, matches them with the invoice, and then creates a notice for the user (payer) and prepares it for sending to the user. The payee bank statement module 23 registers credit statements from the payee bank and matches them with previous invoices. The template module 24 registers issued templates.

[0091] Transaction-related templates for scenarios or contracts may be stored on the network of the automated system for transaction management and provided upon user request. Any user's service provider device can issue transaction-related document templates to the CMD. A user's service provider can request both a set of transaction-related document templates and a specific template from the CMD.

[0092] The Approval Module 25 stores verdicts and checks them against issued invoices and associated debit and credit statements. The Redirection Module 26 receives and registers invoice redirection requests. In case of claims from users (both payers and payees), the Claims Module 27 registers the claim and checks it against the relevant transaction-related contracts or certificates. All modules send progress status via communication channels to the Queue Manager Module 31, which forwards this data to the Notification Delivery Guarantee Module (Store and Forward Module) 16 and the Document Provisioning Module 15.

[0093] The notification delivery assurance module (save and forward module) 16 receives the value to be added to the notification from the hint generation module 30. The notification delivery assurance module (save and forward module) 16 notifies the user (payer) via the user's management device that a document (in particular an invoice, statement, etc.) has been created and is ready to be sent, and provides the hint.

[0094] The transaction scenario generator combines different documents and transactions within the framework of one transaction. CMD's centralized database stores transaction scenario templates and information on associated pre-prepared transaction-related contracts.

[0095] Users (payers) receive and initiate payments of invoices (payment orders, fees) for purchases, services (commercial and government), and other electronic payments. Electronic payment of invoices completes the process, allowing payers to make payments remotely and eliminating the need to manually enter account details to generate payment orders, as well as the need for physical paper.

[0096] Below is the process that occurs in an automated system for trade management (Figure 5).

[0097] The "Document issuance to CMD" 32 is carried out through an information flow on the network of the automated system for transaction management, and then the information flow "Transaction issuance notification distribution" 33 containing the hint is used to distribute the notification to the payee's (recipient's) service provider device. Using the link the payee received as part of the information flow "Transaction details distribution to recipient" 34, the user (payee) can retrieve the transaction-related information stored in the CMD using the previously received hint. The payee decides to accept or reject the transaction in the information flow "Payee's response distribution to CMD" 35. The response is then distributed to the payee's service provider in the information flow "Response distribution to payee's service provider" 36, and also to the payer's service provider in the information flow "CMD distribution of current transaction status to initiator's service provider" 37.

[0098] The process of entering into a contract for a transaction is only required when the parties to the transaction decide to enter into a contract. If the user, as a payer, immediately issues an invoice to the payer for payment without entering into a contract, the process not requiring a contract is applied.

[0099] The transactions made through the automated system can be classified as "unsecured" and "secured" transactions, which require compliance verification by regulatory authorities.

[0100] In the process occurring in an automated system for transaction management, the payer user can use the management device to: - designating / accepting the payee (i.e. the supplier of goods, products or services) and, in particular, accepting delivery of the invoice from the payee identified by the payer; - Receipt, acceptance or rejection of transaction-related documents issued to the User (e.g. contracts, acceptance certificates, invoices, recipient's bank statements and possible refunds, reconciliation reports, etc.); - Request deferred payment and / or installment payments; - expressly consent to direct debit of the payer's bank account for the invoices received; - Receive invoices and apply them to subsequent payments; - Accept invoices for immediate payment as soon as payment is initiated; - Request a reconciliation report. Using the management device, the payer user interacts with: - Payer service provider devices (directly via SP API protocol); - Payer bank's administrative equipment (directly or via the payer's service provider equipment); - The payee's administrative equipment (either outside the network of the automated system for transaction management or indirectly through the payee's service provider's equipment connected to the network). Using the management device, recipient users can: - Require activation / subscription by payer; - receive profile data (proxy) of payers who have agreed to the document; - Issuing documents (contracts, certificates, invoices, credit statements) for payers who have agreed to them; - Issue invoices to a specific payer or "anonymously" (without specifying a payer); - Agree to deferred payment terms at the request of the payer; - Agree to installment payments at the request of the payer; - Request the status of invoices issued according to the specified conditions; - Request reports and reconciliations for invoices according to specified conditions. Using the management device, the user as recipient interacts with: - Recipient's service provider device; - The recipient's bank control device (directly or via the recipient's service provider device); - Payer administrative devices (either outside the network of an automated system for transaction management or indirectly through a networked payer service provider). The payer user is provided with the following by the payer's bank through a management device: - Remote access to the payer's bank account and cashless payment of bills (payment orders) issued to the payer; - The payer initiates the payment through the management device, either directly or via a service provider; - Strict authentication of payers; - Confirmation of payer consent; - Execution of payments ordered by the payer initiated via the service provider; - Execution of payments by payment order (direct debit) from the payer's account, initiated by the payer's service provider, based on the payer's authorized consent; - Notify the payer's service provider that a payment has been made. Using the management device, the payer's bank interacts with: - Payer administration devices (directly or via the payer service provider using SP APIs); - Payer service provider devices (via PIS / AIS API); - Payment systems or services other than automated systems for the management of proposed transactions.

[0101] For users acting as payees, the payee bank, through its management device, provides: - Receive funds paid against invoices issued by the recipient and deposit them into the recipient's bank account; - Validation of the recipient's account; - Preparing statements, confirmations, and other reports and notices to payees; - Validation of the recipient by sending a request to a supervisory authority and receiving a response to this request. Using the control device, the recipient's bank will communicate the following: - Recipient's management device (directly or via the recipient's service provider device using the SP API); - Recipient's service provider device (via PIS / AIS API); - Payment systems / services (other than the proposed system). As a supervisory authority, the user interacts through the management device with: - Service provider's device (directly); - CMD (indirectly through service provider equipment connected to the network of an automated system for transaction management); - the management equipment of the collateral bank (indirectly through the equipment of the service provider connected to the network of the automated system for transaction management); - the receiver's management equipment (outside the network of the automated system for transaction management or indirectly through a service provider's equipment connected to the network of the automated system); - The payer's administrative device (either outside the network of its automated system for transaction management or indirectly through a service provider device connected to the network). The Bank Paying Agent (BPA) provides, through its management device: - Request and receive invoices from service providers; - Include invoices in backup receipts, both together with other users' purchases or on backup receipts created separately; - Providing a final accounting receipt to the user who is the payer; - notify the User's service provider of the payment of an invoice by a particular payer immediately after the User as the payer has completed the payment (regardless of whether the payment is made in cash or by wire transfer); - Transfer the funds received as a result of the transaction to the final recipient via BPA Bank within the terms and conditions jointly determined with the recipient under the contract. - Creation and transfer of a detailed register (one account will be recorded in the register for each individual transfer of the payer's money to the BPA account) that is a detailed breakdown of the transfer of the combined amount via the service provider to both the BPA bank and the payee. Using the management device, the BPA interacts with: - Payers (directly or over the internet using the payer's administrative device in accordance with SP API protocol requirements); - BPA Service Provider Devices (via SP API); - Payer bank management device (via API or PIS / AIS API); - Recipient's bank control device (via payment protocol); - BPA bank management device (via API or SP API). The user who will act as the collateral bank deposits funds as a performance guarantee into a bank account opened for the user via the management device, and transfers the collateral funds to the user once the supervisory authority confirms (approves) compliance with the terms of the contract. Using its management device, the collateral bank: - Receive and hold the payer's funds from the payer's bank as a result of the initiation of a secured transaction; - notifying the network of automated systems for managing transactions of the deposit of these funds into the account; - storing the funds received as a result of the opening of a secured transaction from the time the payer credits the received funds for settlement within the secured transaction until the moment the funds for payment are transferred to the recipient's bank account by order of the network of automated systems for managing transactions based on the supervisory authority's approval of compliance with the terms of the contract; - Transfer, on the orders of the network of automated systems for transaction management, to the recipient's bank funds previously received as part of a secured transaction to secure future settlements, received as a result of the supervisory authority's approval of the recipient's fulfillment of the terms of the secured transaction; - A network of automated systems for managing transactions is then notified of the debit of funds from the payer's bank account and the transfer of funds from the payer's bank account to the recipient's bank. Using the BPA Bank, a management device: - Receive and hold the payer's funds from the payer's bank as a result of collection by BPA or transfer to BPA's account; - Notifying the network of automated systems for transaction management that these funds will be deposited into BPA's account; - depositing in the account of the BPA any funds received as a result of the above actions by the BPA; - Transfer previously received funds to the recipient's bank account as ordered by the BPA; - A network of automated systems for managing transactions is then notified that the funds will be debited from BPA's account and transferred from the recipient's bank account to the recipient's bank. Using the control device, the collateral bank interacts with: - User Service Provider (via SP API); - with the control apparatus of the supervisory authority (only indirectly through a network of automated systems for transaction control); Using the management device, the BPA interacts with: - User Service Provider (via SP API); - Communicate with BPA management devices (directly via a proprietary protocol, indirectly via a network of automated systems for transaction management). Using its management device, the Operational Clearing Center (OPCC): - Receive funds transfer orders from the payer's bank, process them and forward them to the payee's bank; - Receive authorization requests from BPA Bank, forward authorization requests to the payer bank, receive responses and return them to BPA Bank; - Receive payment orders, process clearing, generate net positions and send them to the settlement system, while reporting to the user's bank and processing and transferring funds to the settlement system.

[0102] Therefore, as a result of the above, it should be noted that the process of entering into a trade-related contract is aimed at submitting it to the CMD, an automated system for managing transactions, and ensuring the approval of its terms by all parties. Contracts are concluded between users (contracting parties), with a minimum of two parties and no maximum limit. Furthermore, any contract defines the overall agreement between the contracting parties. For example, one party to a contract promises to supply certain goods, and the other party promises to pay for them.

[0103] The above technical means for implementing the claimed inventions enable increased reliability in transactions and faster information processing, eliminating non-payments due to "insufficient information" or "non-delivery of invoices," reducing the possibility of payment errors, and improving the quality of user service by accelerating information processing and document flow. The above technical solutions also improve the reliability of transactions by improving the quality of reconciliation and providing users with reports on compliance with contract terms (reconciliation reports). Reducing the load on automated systems for transaction management improves the speed of transaction processing in those systems. The above advantages are confirmed by the following embodiments. [Embodiments of the Invention] Embodiment 1. Registration and authentication The user's management device receives a notification that the registration was successful, after which the user is redirected to the application's main page or the service provider device 4's website. Then, using the service provider 4's device, the user sends a request to the selected bank, which performs the authentication. Using its management device 7, the user's bank authorizes the user in a way convenient for the bank. If the service provider 4 cannot authenticate the user on its own, the service provider lets the user choose an authentication channel. As soon as the user has verified the data via the selected bank, the user's bank returns an authentication token to the user's management device (2 or 3) for access to CMD1.

[0104] Authentication using a token works as follows: a user (payer) requests access to a server or protected resource (service provider device 4 or payer bank manager 7) by providing a token using the manager 2 or 3. Based on the issued token, access is granted or denied. The service provider 4 then sends a request to the CMD 1 to issue a user (payer) account. All data about users and their preferences is stored in a centralized database in the CMD, and each user is assigned a unique identifier. Embodiment 2. Transactions between corporations (B2B transactions): 1. Supply of goods from suppliers to supermarkets, restaurants and cafes. 2. Supply of computer equipment to companies specializing in computer assembly. 3. Supply of raw materials for production to factories and plants. 4. Delivery to the car dealer 5. Supply to specialty stores of cosmetics, household chemicals, clothing, shoes, etc. 6. Payments for construction, cleaning, security, repair and freight transportation services. 7. Payment of Insurance Claims Using an invoicing service for B2B transactions not only makes it easier to issue and pay invoices, but also increases the reliability of B2B transactions by introducing a reconciliation mechanism into an automated system for transaction management. Embodiment 3. Transactions between corporations and individuals (C2B transactions). The parties interact online using an interface (mobile application, website) provided by the recipient. 1. Online Shopping Buy food, grocery delivery, clothing, appliances, shoes, furniture, cosmetics, flowers, tools, jewelry, fixtures, auto parts, household items, and books. 2. Payments for the services of cleaning companies, lawyers, tutors, loaders and freight forwarders. Transactions involving immediate delivery of goods between a company and an individual: 1. Concerts, theaters, cinemas, watching sports, purchasing airline tickets. 2. Hotel reservations 3. Purchasing sightseeing tours. 4. Software Purchase 5. Join the insurance 6. Payment of taxes, duties and fines A convenient way to generate recurring invoices for subscription-related transactions: 1. Deposit into the service operator's personal account. 2. Toll roads. 3. Paying for subscriptions to music and video services. 4. Paying for regular grocery deliveries, such as weekly meal kit deliveries. 5. Paying parking fees. 6. Payment of rent. 7. Paying for gym, pool, or health club memberships. Gifts (where one party provides a gratuitous contribution to the other party), such as charitable donations.

[0105] Tracking charitable donations is an extremely difficult task for governments. Transaction support services simplify this task by providing an invoice tracking mechanism and a convenient way for charities to make donations, which involves providing donors with a QR code or a link to an account. Donors simply scan the QR code or follow the link to make their donation; no forms need to be filled out. Invoices for offline transactions 1. Purchasing food at cafeterias, cafes, restaurants, and fast food outlets. 2. Shopping at the supermarket. 3. Shop in-store for jewelry, household goods, fishing supplies, medicine, flowers, building supplies, furniture, plumbing fixtures and appliances.

[0106] Such transactions take place offline, for example in a store. Currently, there is the problem of making claims against the supplier of goods or services if the proof of transaction (cash receipt) is lost. Although the law provides for refunds in case of lost receipts, in practice buyers face many difficulties. Invoicing mechanisms and transaction support services simplify claims against sellers, as buyers have an electronic document confirming payment.

[0107] Payments for housing and public services The existing mechanism for paying for housing and utility services is inconvenient for both property management companies and service users. The situation is further confused by the sheer number of property management companies issuing invoices. The transaction support service provides payers with a convenient mechanism for paying and receiving invoices, including bulk payments (paying all invoices from property management companies with one click), and housing and utility service providers with a convenient mechanism for issuing and reconciling invoices.

[0108] Embodiment 4. Transactions between individuals (P2P payments). This type of transaction provides interaction between individuals. Because such transactions are hidden from the government, the government cannot monitor the transactions or provide legal protection to the parties involved. Transaction support services address these disadvantages and also provide a convenient and timely payment and billing mechanism, while strengthening government control over P2P transactions. Examples of such transactions include: 1. Purchasing second-hand goods through online advertising services, etc. 2. Payments for the services of tutors, builders, movers, plumbers, and computer repairmen. 3. Paying rent. 4. Payment of debts between individuals. Embodiment 5. Transactions between users involving OPCC (FIG. 6). The initiator of a funds transfer is a user, either the payer or the recipient. The OPCC (Operations and Payment Clearing Center) is: - receiving and processing requests for fund transfers from at least one user's bank control device; - Identify the recipient and send the request; - Receive responses to requests and match them with the original request; - Receive direct payment orders (claims) and send them for settlement; - Settlement of unaccepted payment orders (invoices); - Based on the settlement results, create a net position register for direct interbank transfers and prepare a settlement reconciliation report for users containing the main components of each net position; - Sending to the clearing bank of the payment system either a net position registration or an order to transfer funds for another transaction; - Sending reconciliation reports or settlement completion notices to the banks of users participating in the funds transfer.

[0109] A template scenario for one contract in embodiment 6 is shown in Figure 7 in a direct circular format. As can be seen in Figure 7, according to the template, from the (1) "Contract" state, the scenario can transition to either the (3) "Invoice" state or the (6) "Delivery" state. From the (6) "Delivery" state, only the next transition to the (2) "Acceptance Certificate" state is possible, and from the (2) "Acceptance Certificate" state, only the (3) "Invoice" state is possible. According to this scenario, there are two paths: (4) "Debit Statement", (5) "Credit Statement", then the process moves to the (6) "Delivery" state, from which it moves to the (2) "Acceptance Certificate" state, (3) "Invoice" state, after which the process moves back to the (4) "Debit Statement" state, and so on, as many times as necessary (the number of cycles depends on the number of deliveries); Or, it may go through (4) "Debit Statement" and (5) "Credit Statement" to become (3) "Invoice" and then again to (4) "Debit Statement." This process may be repeated as many times as necessary (depending on the number of payments made against one delivery acceptance certificate, for example, payments made against an installment payment acceptance certificate).

[0110] A seventh embodiment of a scenario template for a set of related contracts in the form of a direct circular graph is shown in FIG. The difference with Figure 7 is that this directed circular graph has an edge connecting the (5) "Credit Statement" state with the (1) "Contract" state, which represents the transition from one contract to the next, provided by a complex scenario (consisting of many contracts).

[0111] An eighth embodiment includes using the hint identifier to calculate the number of requests allowed to the payer. A set of parameters for user classification set by the CMD is used to determine the user's category. The parameters stored in CMD's centralized database are used to set the parameters for classifying users. Such parameters include, but are not limited to: -Whether the User is an individual or a legal entity; - the type and volume of activities carried out by the user (for example, the number of requests made by individuals registered as self-employed exceeds the number of requests made to individuals, but is lower than the number of requests made to legal entities, for example, in the case of property management companies); - Legal entity status granted upon registration (simple beneficiary or VIP beneficiary); - Additional classification conditions, including commercial ones (e.g., fees for increasing the number of requests for one hint identifier to obtain documents of a particular type).

[0112] At least two categories of users are determined, and then this data is sent to the hint generation module. For each user category in the CMD, the number of requests allowed by the hint is set.

[0113] For individual service providers acting as recipients, the system may set a limit on the number of free requests (e.g., from 1 to 3). Any excess of such limit will be charged to the user's service provider at the rate set by the CMD. The number of requests for corporate service providers acting as recipients is set similarly (e.g., from 1 to 3). For VIP recipient service providers, the number of free requests can be increased to 5.

[0114] This limitation is due to the following: the CMD must notify the service provider of any document publication or modification at any time. Furthermore, the system rules established by the CMD require the service provider, as the owner of the latest information, to store information about any type of document and provide it to the user upon request without contacting the CMD. When any updates are made on the CMD side, as established, the CMD again notifies the service provider. The service provider updates the information in the system by contacting the CMD, and then again provides the user with the latest information without direct interaction with the CMD. The method and practice described in this specification is internationally known as "caching," and the service provider functions as a "cache" here, i.e., as an intermediate information buffer that can be quickly accessed upon user request. [Brief explanation of the drawings]

[0115] The invention is illustrated by the following figures: [Figure 1] Figure 1 shows the framework of an automated system for trade management. [Figure 2] Figure 2 shows a flow chart of an automated system for transaction management. [Figure 3] Figure 3 shows the structure diagram of the central management device (CMD). [Figure 4] Figure 4 shows the structural diagram of the CMD application processing area. [Figure 5] FIG. 5 shows a process flow diagram of information flow in an automated system for transaction management. [Figure 6] Figure 6 shows an example of a transaction between users (payer and payee) involving an OPCC (Operational Payment Clearing Center). [Figure 7] Figure 7 shows an example of a scenario template for a contract. [Figure 8] Figure 8 shows an example scenario template for a set of related contracts.

Claims

1. 1. An automated system for information exchange in a transaction support service, comprising: a centralized control device for information exchange in a transaction support service configured to provide support in conducting a transaction; and at least two user management devices each having a user interface, the automated system using a communication channel that ensures access of the user management devices to the centralized control device for information exchange in the transaction support service via at least one service provider device, The centralized control device for information exchange in the transaction support service is configured as a hardware and software system for automating transaction management, and comprises a synchronous processing area configured to generate rapid responses to user requests and submissions to the users, a compatibility area configured to queue transaction-related requests, and an application processing area configured to perform synchronous and asynchronous processing of user requests and logical control of information related to transactions from users; An automated system for information exchange in transaction support services, wherein the centralized control device for information exchange in transaction support services includes a control means configured to limit the number of user requests for transaction-related information sent via a communication channel to the centralized control device for information exchange in transaction support services to a set number.

2. 10. The transaction management system of claim 1, comprising at least one user bank management device configured to act as a service provider and connected to said centralized management device via a communication channel.

3. 3. The transaction management system according to claim 2, wherein the user bank management device is connected to the central management device using a communication channel via at least one service provider device.

4. 2. A transaction management system according to claim 1, characterized in that a user's communication means provided with a user interface for indirectly accessing the centralized management device (via a service provider) is used as the user management device.

5. 10. The transaction management system of claim 1, comprising at least one intermediary bank management device configured to act as a service provider and connected to said centralized management device via a communication channel.

6. The transaction management system of claim 5, wherein the intermediary bank management device is connected to the central management device using a communication channel via at least one service provider device.

7. 10. The transaction management system of claim 1, comprising at least one supervisory authority control device configured to act as a service provider and connected to said central control device via a communication channel.

8. 8. The system of claim 7, wherein the supervisory authority control device is connected to the central control device using a communication channel via at least one service provider device.

9. The transaction management system of claim 1 , comprising at least one bank payment agent manager configured to act as a service provider and connected to said centralized management device via a communication channel.

10. 10. The transaction management system of claim 9, wherein the bank payment agent management device is connected to the centralized management device using a communication channel via at least one service provider device.

11. 2. The system for transaction management of claim 1, including at least one operational clearing center management device connected to at least one user bank management device and an intermediary bank management device via a communication channel.

12. The transaction management system of claim 1, wherein the centralized management device is configured to manage user profiles.

13. 2. The transaction management system of claim 1, wherein the at least one service provider device is configured to provide users with an interface for registration, identification parameter checking and user authentication by creating a new user account, and for data storage.

14. 2. The transaction management system of claim 1, wherein a hint generation module and a document provision module for checking the number of hint usages are used as control means designed to limit the number of user requests for transaction-related information sent to the centralized management device via a communication channel to a set number.

15. 1. A centralized management device for information exchange in transaction support services, comprising a centralized database configured to store information regarding user registrations, credentials, and preferences, and means for automating transaction management, the centralized management device comprising: the means for automating transaction management comprises means for receiving and submitting to a user at least one transaction-related document; The means for receiving and submitting the at least one transaction-related document to a user includes: a document management module, a document serving module, a notification and download link delivery assurance module (store and forward module), a hint generation module, and a queue manager module, wherein said hint generation module and said document serving module form control means designed to limit the number of user requests for transaction-related information, and said queue manager module queues transaction-related requests during asynchronous request processing; A centralized management device characterized in that the means for automating transaction management further comprises at least one transaction-related document issuing means, at least one transaction-related document classification means, and at least one transaction scenario generation means, the identified means intended for synchronous and asynchronous processing of user transaction requests.

16. 16. The central control device of claim 15, wherein the transaction-related document issuing means comprises a user profile module and a service subscription module.

17. 16. The centralized control device of claim 15, wherein the transaction scenario generation means comprises a contract module, a remittance and acceptance certificate module, an invoice module, a payor bank debit statement module, a recipient bank credit statement module, a template module, an approval module, a redirection module, a billing module and a report generation module.

18. 16. The central control unit of claim 15, wherein the transaction classifier comprises a document matching module.

19. The centralized control device according to claims 16 to 18, characterized in that all modules included in the transaction-related document issuing means, the transaction scenario generating means, and the transaction classifying means include filters configured to match documents related to transactions and included in the queue manager module with each other.

20. The centralized control device according to any one of claims 15 to 18, wherein the centralized database is made up of databases of all modules of the centralized control device, and forms a single network via a communication channel.

21. The central control device of claim 15 , wherein the document management module is configured to perform analysis and validation.

22. 17. The centralized control device of claim 16, wherein the transaction-related document issuing means is configured to issue complete information about a transaction in the automated system of claim 1 for the first time and to share links to previously published information.

23. 17. The central control device according to claim 16, wherein the transaction-related document issuing means is configured to receive and provide information about a transaction at the request of a user by using a unique hint.

24. 17. The central control device according to claim 16, wherein the transaction-related document issuing means is configured to generate a report on the transaction and provide it to the user.

25. The central control device of claim 1 , wherein the centralized database includes a unique identifier associated with each user and at least one of the user's service providers.

26. 1. An automated method for information exchange in a transaction support service, comprising: providing access to a centralized control device for at least two users via a communication channel through at least one service provider device; registering the users; and storing access credentials for each user in a centralized database, the method comprising: The method is as follows: Creating a user account; Providing each user with access to one or at least two service providers simultaneously; authenticating the user via the user's service provider; issuing transaction documents on a network of automated systems for transaction management; generating a user request to conduct a transaction on a user management device; classifying, at said centralized control device, the received information via a transaction classification means; generating transactions on said centralized management device having a centralized database storing transaction scenario templates for authorizing, verifying, and conducting various transactions; Registering, comparing and tracking contracts related to transactions; and A method comprising controlling, via hints, a number of requests for transaction-related documents received over a communication channel and user device access to said transaction-related information.

27. 27. The method of automating transaction management of claim 26, including posting user account and transaction related information to said centralized management device after user authorization checks by the user's service provider device.

28. 27. The method of automating transaction management of claim 26, including storing data regarding user preferences in a centralized database at the central control device.

29. 27. The method of automating transaction management of claim 26, including generating a unique identifier for each transaction and each document within the centralized management device.

30. 27. A method for managing automated transactions as set forth in claim 26, including providing access to transaction-related information upon request of a user.

31. 27. The method for automating transaction management according to claim 26, further comprising providing a user with an account editing means in the centralized management device.

32. A transaction management automation method as described in claim 26, which includes matching documents related to transactions and included in the queue manager module using filters of modules included in the transaction-related document issuing means, transaction scenario generating means, and transaction classification means as described in claims 15 to 17.

33. 27. The method for automating transaction management according to claim 26, wherein the supervisory authority management device executes a secured transaction after verifying that the user complies with the terms of the transaction.

Images