RU2814033C1 - Automated system and method for implementing information exchange in service to support transactions between its users - Google Patents

Abstract

FIELD: information technologies.

SUBSTANCE: group of inventions relates to information technologies in the financial industry, and can be used for automated management and control of transactions. The system contains a centralized control device for implementing information exchange to support transactions between users and at least two user control devices, while the centralized control device is made in the form of a software and hardware complex for automating the management of transactions, divided into a synchronous processing zone, a zone compatibility and application processing area, and contains a control device that limits the number of user requests for information about transactions received via communication channels to the centralized control device for implementing information exchange to support transactions between users, a specified number of times.

EFFECT: reducing the load on the automated system and device for managing transactions, as well as increasing the reliability and speed of information processing when conducting transactions.

33 cl, 8 dwg

Description

Field of technology

The invention relates to information technologies in the financial industry, namely to automated systems, devices and methods for managing transactions, and can be used for automated management and control of transactions, as well as for organizing the sale of goods and services.

State of the art.

Currently, technologies in the financial sector are actively developing, in particular in the field of non-cash payments, one of the areas of development is overlay services.

Overlay services are software and hardware developed to optimize the operation of various payment services aimed directly at consumers (individuals and legal entities), helping to increase security, simplify and improve their convenience. Overlay services in the financial industry can precede, follow, or be used independently of payments. One of the overlay services is the transaction support service presented in the present invention.

From the prior art there is known a method and a computer system for conducting a business transaction between a consumer and a merchant, described in the invention patent RU 2702085 C2 (cl. G06Q 20/00, 01/18/2016). The known method comprises the steps of initiating a consumer's computer system to conduct a business transaction with a merchant, wherein the consumer's computer system then requests a dynamic value representing the authorization from a central platform; receiving, by the consumer's computer system, a request to select a payment account from two or more consumer payment accounts from the central platform; and then receiving the consumer's computer system to select a payment account from two or more consumer payment accounts. The consumer's computer system then receives a dynamic value representing the authority from the central platform corresponding to the primary account number (PAN) of the selected payment account. In this case, the business transaction is completed using the authorization-granting dynamic value received by the merchant's computer system. A computer system for conducting a business transaction between a consumer and a merchant is configured to carry out the steps of the method.

The disadvantages of the known method and computer system are the lack of technical ability to manage the number of user requests for documents relating to business transactions (transactions), as well as the ability to perform preliminary checks and prepare for payment before transferring funds, which greatly increases the load on the computer system and the time of transactions , and also increases the likelihood of errors.

The closest analogue of the claimed automated system, device and method for managing transactions is the system, device and method described in the invention patent RU 2581784 (cl. G06Q 20/00, 02/11/2011). The known automated system contains a centralized control device, and at least two user control devices using communication channels to provide access for the user control device to the centralized control device through at least one service provider device, a user interface module made with the ability to provide any user with access to the centralized control device. The known centralized control device (platform) contains a centralized data storage base capable of storing registration data, credentials and preferences corresponding to each user, as well as tools for automating the management of transactions. A known automated control method includes providing at least two users with communication access to a centralized control device through at least one service provider device; user registration, storage in a centralized database of login registration data corresponding to each user.

The disadvantages of the known invention include the provision of access to the service for submitting invoices only through one service provider, which significantly limits the functionality of the service, as well as the inability to manage the number of user requests for documents relating to transactions, which greatly increases the load on the automated system and increases the time of operations. Another disadvantage is that the known system and method do not provide for the technical ability to perform preliminary checks and prepare for payment before transferring funds, which means there is a possibility of errors occurring during transactions.

Disclosure of the essence of the claimed invention.

The tasks to be solved by the presented invention are to ensure reliability, improve the quality and speed of electronic document management when conducting transactions in various areas by conducting a fully monitored transaction and recording the facts of the fulfillment of the obligations of the parties, including, but not limited to, transactions with monetary means.

The technical result of the claimed invention is to reduce the load on the automated system and device for managing transactions between users, increasing the reliability and speed of information processing when conducting transactions.

Increasing the reliability of information processing implies ensuring information security when transmitting messages within an automated system, conducting secure transactions secured in the form of a guarantee payment, reducing the likelihood of errors when making transactions, registering facts of transactions between users and reconciling outgoing and incoming information about transactions between users .

Reducing the load on the automated system and device for managing transactions is achieved by managing the number of requests for documents related to transactions, ensuring information exchange in the system through service providers and synchronous/asynchronous options for implementing information exchange. It should also be noted that reducing the load on the automated system for managing transactions ensures an increase in the speed of information processing when conducting transactions.

The technical result is achieved due to the fact that the automated system for managing the execution of transactions between its users contains a centralized control device configured to provide a transaction support service, and at least two user control devices with a user interface installed on them, using communication channels for providing access to the user control device to the centralized control device through at least one service provider device, characterized in that

the centralized control device is made in the form of a software and hardware complex for automating the management of transactions and is divided into a synchronous processing zone, a compatibility zone and an applied processing zone to ensure the processing and logical control of information about transactions coming from users,

in this case, the centralized control device contains a control device that limits the number of user requests for information about transactions received via communication channels to the centralized control device, a specified number of times.

In particular implementation cases, the system contains at least one user bank control device, configured to implement the functions of a service provider and connected via communication channels with the centralized control device.

The user's bank control device is connected via communication channels to the centralized control device through at least one service provider device.

As a user control device, user communication tools with a user interface installed on them are used for indirect, through a service provider, access to the centralized control device.

The system contains at least one control device of the intermediary bank, configured to implement the functions of a service provider and connected via communication channels with the centralized control device.

The control device of the intermediary bank is connected via communication channels with the central control device through at least one device of the service provider.

The system contains at least one control device of the controlling body, configured to implement the functions of a service provider and connected via communication channels with the centralized control device.

The control device of the controlling body is connected via communication channels with the centralized control device through at least one device of the service provider.

The system for managing transactions contains at least one control device for a bank payment agent, configured to implement the functions of a service provider and connected via communication channels with a centralized control device.

The bank payment agent control device is connected via communication channels to the centralized control device through at least one service provider device.

The system contains a control device of an operational clearing center, connected via communication channels with at least one control device of the user's bank and a control device of the intermediary bank.

The centralized control device is configured to manage the user profile.

The at least one service provider device is configured to provide a user with an interface for registering, checking identification parameters and authenticating the user, and storing data by creating a new user account.

As a means of control that limits the number of requests for information about transactions received via communication channels to the centralized control device to a specified number of times, a module for generating a hint identifier and a module for providing documents is used, which checks the number of uses of the hint identifier.

The synchronous processing zone is made with the ability to generate a quick response to user requests and send it to the user, the compatibility zone of the centralized control device is made with the ability to queue requests for transactions, and the application processing zone of the centralized control device is made with the possibility of synchronous and asynchronous processing to ensure processing and logical control of information about transactions received from users.

The centralized control device contains a centralized data storage base configured to store registration data, credentials and preferences corresponding to each user, as well as tools for automating the management of transactions,

characterized in that they use, as a means for automating the management of transactions,

at least one means for receiving and delivering documents relating to transactions to a user;

at least one means for publishing documents relating to transactions;

at least one means for classifying documents relating to transactions;

at least one means of generating a transaction scenario.

In particular implementation cases, the means for receiving and delivering documents contains a document management module, a document provisioning module, a module for guaranteed delivery of notifications and download links, a hint identifier generation module, and a queue manager module.

The tool for publishing documents related to transactions contains a user profile module and a service subscription module.

The tool for generating a transaction scenario contains a contract module, a transfer and acceptance certificate module, an invoice module for payment, a module for a statement from the payer's bank about debiting funds, a module for a statement from the recipient's bank about crediting funds, a template module, a verdict module, a redirection module, a claims module and reporting module.

The transaction classification tool contains a document reconciliation module.

All modules that are part of the tool for publishing documents related to transactions, the tool for generating a transaction scenario, and the tool for classifying transactions contain filters that make it possible to compare documents related to transactions and those located in the queue manager module.

The centralized data storage database consists of databases of all modules of the centralized control device, united by communication channels into a single network.

The document management module is designed with the ability to perform parsing and validation.

The means for publishing documents relating to transactions is configured to publish in an automated system complete information about the completion of a transaction created for the first time, and publish a link to already published information.

The tool for publishing documents relating to transactions is designed to retrieve and provide information about transactions at the request of users when the latter uses a unique hint identifier.

The tool for publishing documents relating to transactions is designed to generate and provide reports to users on transactions.

The centralized data storage database includes unique identifiers corresponding to each user and at least one user service provider.

An automated method for managing transactions, including providing at least two users with access via communication channels to a centralized control device through at least one service provider device; user registration, storage in a centralized database of login registration data corresponding to each user,

characterized in that

create a user account;

grant each user the right to access one or at least two service providers simultaneously;

through the user's service provider, they authenticate the user, publish a document relating to the transaction in the network of the automated system for managing the execution of transactions;

generating a user request to complete a transaction on the user's control device;

classify incoming information in the centralized management device using a transaction classification tool,

form a transaction in a centralized management device, in the centralized data storage database of which templates of transaction scenarios are stored for approval, confirmation and execution of transactions of various types;

register, compare and monitor the status of agreements relating to transactions;

Using a hint identifier, they regulate the number of requests for documents related to transactions received through communication channels, as well as access of the user’s device to information about the transaction.

In particular cases, implementations publish the user's account and transaction information to the centralized management device after the user's service provider device verifies its authorization.

Data about user preferences are stored in the centralized data storage database of the centralized control device.

A unique identifier is generated for each transaction and for each document in the centralized management device.

Provide access to information about transactions upon user request.

Provides the user with the means to change the account in the centralized management device.

Documents relating to transactions and located in the queue manager module are compared using filters included in the modules of tools for publishing documents, tools for generating a transaction scenario, and tools for classifying transactions.

They make transactions with security through confirmation by the control device of the supervisory authority of the fulfillment of the terms of the transaction between users.

Terms used.

Transaction support service (automated system) is an overlay service used to issue invoices to users and support their payment by electronic means, which is aimed at standardizing and accelerating document flow, ensuring electronic delivery of invoices (acceptance payment requests) from the recipient to the payer, payment preparation for execution, as well as a mechanism for digitalization of document flow that arises between users (economic entities). Documents confirming the completion of transactions between users may include, in particular, contracts, acts of acceptance, work or services, invoices for payment containing the amount payable (cash sales receipts or reporting forms), statements from the payer’s bank account regarding debits funds from the payer's bank, statements from the recipient's bank account about the transfer of funds, verdicts from regulatory authorities, statements from the collateral bank, invoices (documents that the supplier issues to the buyer when shipping goods). This list is not exhaustive and is provided as an example.

As a transaction in the context of the presented invention, we understand the actions of users, in particular, individuals and legal entities, as well as government bodies, aimed at establishing, changing or terminating civil rights and obligations. A transaction between users is registered in the transaction support service (automated system) to manage it electronically.

Information about completing a transaction is information about completing a transaction, including a user request to complete a transaction and notifications about the stages of its completion (notifications about publication of a transaction support service on the network, notifications about confirmation of completed payments, etc.).

The user (individual, legal entity or government body) is the subject of information exchange in the transaction support service, which interacts through its control device with the device of the user's service provider and with the user's bank. The user can be the initiator or recipient of the transaction process, as well as the payer or recipient of payment in the context of processes related to invoices and their payment.

The user's bank is the subject of information exchange in the transaction support service, a financial organization that provides electronic access to the user's bank accounts and execution of payments, in particular, in interaction with the operational processing clearing center (OPCC).

A user control device (payer or recipient) is a means of personal communication used when performing operations in an automated system to manage transactions between its users, both within the framework of information exchange and when making a payment. The payer's control device and the recipient's control device can be devices with a user interface that provide the ability to perform transactions with transactions, as well as to exchange data and receive information about the results of a transaction (information flow) and/or payment operation. User communication devices with a user interface installed on them, in particular such as a mobile phone, tablet, personal computer, terminal or ATM, can be used as a user control device. What these devices have in common is the need for the user to be pre-authenticated by their bank in the user's device interface.

The payer is a subject of information exchange in the transaction support service, which, through its control device, directly interacts with the service provider’s device and the control device of its bank, configured to implement the functions of the service provider, to request and receive documents in electronic format, for example, contracts, acts, invoices, making decisions on documents received by the payer, as well as initiating payments on invoices in favor of recipients. Payers can be individuals, legal entities and government bodies.

If the user is a payer, the bank through which he makes the payment will be called the payer's bank, and the service provider of such a user will be called the payer's service provider.

The recipient is a subject of information exchange in the transaction support service, which, using its control device, initiates the issuance of invoices (acceptance payment requests) in electronic form through the services of the recipient's service provider and expects the receipt of funds from the recipient's bank to the recipient's bank account based on the issued invoices. Recipients can be any individuals or legal entities, as well as any organizations, including government ones.

In particular, but not limited to the following, consumers of goods, works or services, individual entrepreneurs, individuals and the self-employed can act as individuals.

Legal entities may include, in particular, but not limited to the following, trading enterprises, telecommunications companies, utilities, homeowners' associations, gardening non-profit partnerships, dacha construction consumer cooperatives, etc.

If the user is a recipient, the bank through which he receives payment will be called the recipient's bank, and the service provider of such a user will be called the recipient's service provider.

Any transaction between users, including the purchase of goods or payment for services, is not always formalized as a written agreement, but is an agreement in essence. The user, in particular, the payer and the recipient (initiator and addressee), make a decision: one - to sell something for a certain amount of money or provide a service, and the other - to pay for a service or purchase a product for a certain amount of money. Moreover, one process is always accompanied by the execution of only one accompanying document, for example, a fiscal receipt.

Payer bank control device - at least one computing device of a credit institution serving the payer as defined by the standards, from whose correspondent account funds must be debited when transferring funds by order of the payer.

Recipient's bank control device - at least one computing device of a credit institution serving the recipient as defined by the standards, to whose correspondent account funds must be credited when transferring funds in favor of the recipient of funds.

The user's service provider device is a software and hardware complex consisting of at least one server that provides information exchange between users in the transaction support service, as well as access to the electronic services of the above service, in particular, a personal account, activity reporting in the network of the service to support transactions, tools for creating, editing, publishing and delivering documents relating to transactions, subscribing to them and providing user details to the participants of the subscription (the one for whom the subscription was made), initiating payments, user notifications. Each user service provider device is configured to provide the user with an interface for registration, verification of identification parameters and user authentication, as well as storage of data by creating a new user account, which reduces the load on the automated system and device for managing transactions.

The software and hardware complex of each bank (user bank, intermediary bank, bank payment agent) and the controlling body of the automated system for managing transactions between its users, when additionally equipped with equipment and specialized software, can additionally perform the functions of a service provider. Thus, to summarize the above, the control devices of the user's bank, in particular, the control device of the payer's bank and the control device of the recipient's bank, the control device of the intermediary bank, the control device of the bank paying agent and the supervisory authority are configured to implement the functions of a service provider.

Centralized control device (CCU) is a hardware and software complex consisting of servers that ensure the operation of system and application software of the transaction support service. Each of the servers is designed as a computer system that includes tools for automating the management of transactions and their component modules.

A module is a specific functional area (component) of software. At the same time, the entire set of modules completely determines the operation of the hardware and software complex of the control center. The number of modules of the same type is determined by the load capacity of the control center: the higher the requirements for the load capacity of the control center, the more modules of the same type operating simultaneously may be required. The number of different types of modules is determined by the range of those functional areas (for example, purchase and sale agreements, service agreements, joint activity agreements, custody agreements, insurance agreements, etc.) of transactions covered by the UCC.

The set of all software and hardware systems, including user control devices, user bank control devices, service provider devices, centralized control device, intermediary bank control device, control device of the supervisory authority, control device of the bank payment agent and control device of the operational clearing center represent an automated system for managing transactions between its users.

A process is a sequence of creating and changing documents relating to a transaction (agreements, acts, invoices, statements, etc.) in an automated system for managing transactions carried out as a result of information flows.

An information flow is a certain sequence of messages circulating between users in an automated system for managing transactions, as a result of the processing of which the establishment, change or termination of legal relations between legal entities, individuals or public authorities occurs (the creation or change in the state of one very specific document, or the receipt information about it).

Messages are elementary components of information flows that convey the contents of documents (payload) related to transactions. Between control devices of individuals, legal entities and government agencies, electronic messages are exchanged, constituting one logical whole in order to obtain data about the transaction, including data about the user (in particular, the payer, the payer's bank, the recipient, the recipient's bank, the payment system, the intermediary bank , the transfer amount and commissions that will be charged by system users in case of a money transfer).

If all messages that make up an information flow are sent exclusively between the user and his service provider, then this information flow is local, i.e. no centralized control device is involved in its implementation. This information flow occurs outside the automated system for managing transactions.

Data elements are the elementary components of messages nested within messages in a building block.

A building block is a fragment of a document relating to a transaction consisting of a set of data elements, which is created (in its entirety) within one process, as an integral part of the document and can be used as a reference to it within one or more subsequent processes, during which other documents are created. At least two building blocks are grouped into data blocks.

A scenario is a specific sequence of planned services (deliveries) and/or processes (documents) related to transactions. The entire scenario or contract can be planned in advance, before the contract or contracts are signed, i.e. You can include a template for an existing script in contracts executed under it or use the template for the entire contract. In general, a scenario does not belong to one contract. You can create a script that will be distributed between different contracts or will be included in one contract.

Process triggers are parameters used by the central control center that influence which specific information flows will be used in a specific process that generates documents accompanying transactions.

The framework of an automated system for managing transactions shows the relationships between the key concepts of the system: processes, transaction documents, users and information flows. The framework sets the rules for applying information flows depending on the processes.

The protocol of an automated system for managing transactions between its users is a set of rules and technical procedures that allow several users (from two to the required number) to exchange information messages with each other through their control devices when networking an automated system for managing transactions. The concept of a protocol covers all ongoing interactions that take place within an automated system:

- processes and corresponding documents relating to transactions;

- information flows that make up each process;

- triggers that define the rules for applying information flows in a certain process;

- a framework that links user control devices, processes, transaction documents, and information flows;

- messages that make up information flows;

- building blocks that make up messages;

- data elements - elementary components of building blocks.

User profile in the UCC (profile) is a set of data identifying the user and his preferences. The user profile management process refers to the creation, updating or deletion of a user profile, in particular adding, changing or deleting bank details.

The controlling body is a user (organization) confirming the fulfillment of the terms of the transaction (announcing a verdict) between users both in the roles of payer and recipient of money, and compliance with the terms of the legislation securing the contract, in order to provide guarantees to the customer to receive the goods or services specified in the contract, and to the supplier to receive in in accordance with the terms of the contract, funds for goods supplied or services provided. The collateral bank acts as the executor of the terms of financial security. In secure transactions, the supervisory authority informs (via a verdict) through an automated system for managing the execution of transactions, the collateral bank that the transaction by the recipient of the money (the supplier of the goods or service) has been executed, and it is time to transfer the payer's money to him.

Verdict - the conclusion of the regulatory authority regarding the terms of the transaction.

Both government bodies and legal entities authorized by the parties carrying out the transaction (users) and legal entities registered (accredited) by the centralized management device (private organizations) can act as a supervisory authority.

State bodies may include the Federal Service for State Registration, Cadastre and Cartography (Rosreestr), the State Road Safety Inspectorate (STSI), the Federal Tax Service (FTS), the Federal Service for Financial Monitoring (Rosfinmonitoring), and Russian Post. This list is not exhaustive and is provided as an example.

Legal entities (authorized organizations) can be, for example, commercial postal operators or commercial quality controllers.

Comptroller Control Unit (CCU) - at least one supervisory computing device configured to confirm the fulfillment of transaction terms by users in the payer and payee roles.

A bank payment agent (BPA) is a subject of information exchange in an automated system for managing transactions (transaction support service), in particular, a legal entity that ensures the collection of funds from payers in favor of recipients. BPA in the context of processes related to invoices and their payment may be:

- enterprises engaged in trade;

- enterprises providing services.

The control device of a bank payment agent (UBPA) is a control device of an organization that ensures the collection of funds from payers in favor of recipients.

An intermediary bank (IB) is a subject of information exchange in an automated system for managing transactions, which is an intermediate link in settlements, which accumulates funds received from payers for some time, and after receiving the corresponding order (from the IA or as a result of a verdict supervisory authority) transfers funds to the recipient's account (in particular, after the execution of a secure transaction, about which the system notifies the supervisory authority) or to the recipients' accounts (after receiving a register for the transfer of money from an automated system for managing transactions based on data from the payment agent) .

An intermediary bank can act as:

- collateral bank - in secure transactions with the participation of the regulatory authority;

- BPA bank - when paying bills through BPA.

An intermediary bank control device (ICD) is a hardware-software management complex for an organization that accumulates funds received from payers for some time and, after receiving the appropriate order, transfers funds to the recipient’s account. UPBP, when additionally equipped with equipment and specialized software, can perform the functions of a service provider for an intermediary bank.

The control device of the operations and clearing center is at least one computing device configured to support the execution of transactions for the transfer of funds between control devices of user banks and the processing of orders for the transfer of funds to the settlement system, as well as receiving authorization requests from the devices management of payment transactions banks and their routing for authorization to payer banks, receiving responses and their return to payment transactions banks, receiving payment requests, their processing in clearing, generating net positions and sending them to the settlement system, as well as sending reports to user banks and payment transactions banks .

Hint identifier (hint) is an identifier generated in the UCC hint identifier generation module, and is a sequence of letters and numbers presented by the user's service provider in a request to the UCC to control the number of his requests to the UCC for a document received via communication channels.

The number of queries allowed by a hint ID is determined by the category the user belongs to. To determine a user's category, a set of user categorization parameters is used.

The logical division of users in the DCU is carried out on the basis of the categorization parameters specified for the recipient, stored in a centralized database in the form of configuration profiles of recipients. Recipient configuration profiles are a means of categorizing users. Addressees (users) have the right to request from the UCC the parameters they require (possibly on a commercial basis), according to which users are divided into categories. For each user category, the number of requests allowed by means of a hint identifier is also specified in the configuration profiles of recipients in the UCC. In this way, at least two categories of users are determined, and then this data is transmitted to the hint identifier generation module.

Brief description of the drawings.

The present invention is illustrated by the following graphics.

In fig. Figure 1 shows a conceptual diagram of an automated system for managing transactions between users.

In fig. Figure 2 shows a block diagram of an automated system for managing transactions between users.

In fig. Figure 3 shows a block diagram of a centralized control device (CCD).

In fig. Figure 4 shows a block diagram of the applied processing zone of the control center.

In fig. Figure 5 shows a flow diagram of a process consisting of information flows flowing in an automated system for managing transactions between users.

In fig. Figure 6 shows an example of a transaction between users (payers and recipients) with the participation of an operational and payment clearing center (OPCC).

In fig. Figure 7 shows an example of a script template for one contract.

In fig. Figure 8 shows an example script template for multiple related contracts.

An automated system for managing transactions between users (Fig. 1) is a distributed or “cloud computing system” for managing transactions between users.

An automated system for managing transactions between its users contains a control center 1, at least two user control devices (payer control device 2 and recipient control device 3), with a user interface installed on them, and service provider devices 4. Each control device the user is connected to the DCU 1 through communication channels through at least one device of the service provider 4. The DCU 1 and the devices of the service providers 4 form a network of an automated system for managing transactions 5, within which all interactions between the devices of the service providers 4 occur exclusively through UCU 1, as through a single central counterparty. UCU 1 provides management of the identification of service providers and the interaction through it of all service providers 4 in all transaction processes (scenarios, information flows). Identity management in the UCC means, in particular, the registration and issuance of unique identifiers to service providers of user banks, intermediary banks, bank payment agents and regulatory authorities and the storage of these identifiers in a centralized database, as well as the publication on the network of an automated system for managing transactions .

User communication devices with a user interface installed on them to access the service provider device can be used as a user control device. As a means of communication for users, a smartphone, tablet, smart watch, computer (including portable), TV set-top box can be used, the technical characteristics of which allow you to install a user interface (application) to access the control center and have access to the Internet for the purpose of application of payment services to personal accounts in the bank (for online services). This list is not exhaustive.

An automated system for managing transactions, depending on the scenario of the transaction, may also include: at least one control device of the user's bank (control device of the recipient's bank 6 or control device of the payer's bank 7), control device of the intermediary bank 8 (UBP), control device supervisory authority 9 (UUKO) and control device of the bank payment agent 10 (UBPA).

The control center is a key architectural component of an automated system for managing transactions, which can have from two to any number of user control devices, depending on the technical characteristics of the automated system for managing transactions. In this case, the control center is configured with the ability to manage the user profile, which means creating, updating or deleting a user profile, in particular, adding, changing or deleting bank details.

In fig. Figure 2 shows a block diagram of an automated system for managing transactions, which reflects its main users and the interactions occurring within it.

All interactions occurring within it are regulated by the protocol, in particular:

- processes and corresponding documents relating to transactions, their users (payers and recipients, initiators and addressees);

- information flows that make up each process;

- triggers that define the rules for applying information flows in a certain process;

- a framework that connects users (participants), processes, documents related to transactions, triggers and information flows;

- messages that make up information flows;

- building blocks that make up messages;

- data elements - elementary components of building blocks.

Users, in addition to the protocol of the automated system for managing transactions, use other protocols or communication languages to interact with each other, which include (Fig. 1):

-payment protocol,

-API service providers,

-proprietary API protocols,

-PIS/AIS APIs protocols.

API (application programming interface) - interface (language) for the interaction of programs with each other.

The payment protocol covers the interaction of users of transactions, in particular, banks and payment services (for example, such as the Mir payment system, the Bank of Russia service, the Fast Payment System service, classic payment orders processed by the Bank of Russia RCC), to perform the actual transfer of funds between users and their banks. This list is not exhaustive.

The user directly interacts through his control device with at least:

- with its service provider, for example, through the service provider's APIs to initiate information flows, as a result of which a specific document relating to the transaction arises;

- with the control device of the user’s bank, for example, using a proprietary protocol (through the channels of the bank itself).

Service Provider APIs (SP APIs) depicted in FIG. 2 cover the interaction of service providers with users to initiate transactions, in particular, payments and obtain information about the status of transactions, in particular, accounts.

PIS/AIS APIs (payment initiation service/ account information service) - services for initiating payments or providing account information, are used to initiate payments and to inform about a bank account if the roles of the user's service provider and the user's bank are divided between different organizations. Otherwise, the service provider and the bank are one organization; such interactions are implemented locally within one organization and do not require the use of PIS/AIS APIs.

To make any changes within the network of the transaction support service, all users interact exclusively with the devices of the user service providers through SP APIs (Fig. 2).

The user acting as a payer initiates the process of completing a transaction by launching a request for the need to complete a transaction to other users (in particular, the recipient/user's bank/controlling authority/bank payment agent/intermediary bank). This list is not exhaustive and may include other devices that perform the functions of the above-mentioned users.

Based on the legal status of the user and the corresponding legal regulation of the automated system as recipients and payers (initiators and addressees) () when concluding transactions with the subsequent initiation of invoices (accruals) and execution of payments corresponding to the invoices (accruals), transactions can be classified as:

- Business to Business (B2B - Business to Business);

- Individual - Business (C2B - Consumer to Business);

- Individual - To an individual (P2P - Person to Person, C2C - Consumer to Consumer);

- Business to Government (B2G - Business to Government);

- Individual - to the State (C2G - Consumer to Government). The centralized control device (Fig. 3) is made in the form of a hardware and software complex containing a centralized data storage base for storing registration information, credentials and preferences corresponding to each user; means for receiving and delivering documents, means for publishing documents relating to transactions; means of classifying transactions and means of generating a scenario for the passage of a transaction.

In this case, the control center consists of zones: synchronous processing zone 11, compatibility zone 12 and applied processing zone 13. The processes carried out in these zones (11-13) make it possible to ensure the processing and logical control of information about transactions coming from service providers.

The proposed DCU architecture ensures operation not only within the framework of the “subscribe-delivery” asynchronous messaging pattern, but also within the framework of the “request-response” synchronous messaging pattern.

The synchronous processing zone 11 contains a control device that limits the number of user requests for information about transactions, made in the form of a module for generating a hint identifier (hint) 30 and a module for providing documents 15 corresponding to servers operating synchronously, for example, but not limited to the above, web- servers. In the synchronous processing zone, requests/messages are received, checked and processed in real time: parsing, authorization, authentication of service providers, validation, logging, conversion to internal representation and transmission to the compatibility zone, verification of the hint identifier provided by the service provider, generating a quick response and sending it to the sender.

Synchronous processing zone 11 contains means for receiving and delivering documents containing:

- document management module 14 - a module responsible for receiving a message, extracting information from it, checking the validity of the sender and transferring it for processing (office),

- document provision module 15 - a module responsible for providing the requested information in response to a request containing a hint identifier (hint), after first checking the said hint identifier;

- module for guaranteed delivery of notifications and download links 16 - module for notifications from the UCC that the document is prepared and ready to be sent to the recipient,

- module for generating hint identifier 30.

The document management module 14, the document provision module 15, the guaranteed delivery module of notifications and download links 16, the hint identifier generation module 30 and the queue manager module 31 of the compatibility zone 12 are the means for receiving and delivering documents.

Compatibility zone 12 corresponds to the server operating as a message queue manager (queue manager module 31), providing a two-way exchange channel between synchronous processing zone 11 and application processing zone 13. Compatibility zone 12 (two-way message exchange channel) serves as a kind of buffer that implements the asynchronous communication pattern between the zones of synchronous and applied processing. In the compatibility zone, messages converted to internal representation are received, placed in a queue, from which they will be retrieved for application processing by software modules of application processing zone 13. Software modules of this zone will perform the following principles for its delivery in relation to each message (these principles are usually are called politicians):

Durability policies - the duration of delivery of messages to their application processing modules;

Security policies - defining specific modules that have access to certain messages in the queue;

Message clearing policies - defining criteria for removing messages from the queue;

Delivery policies - setting guaranteed delivery of messages to their application processing modules;

Routing policies - determining the location of application processing modules to deliver messages there from the queue;

Batch processing policies - determining the possibility of transmitting several messages at once for processing to their application processing module.

Queue Policies - Determine when to queue.

Receipt notification policies - ensuring the delivery of notifications to the document management module 14 about the transfer of a message for processing to the module of its application processing zone 13.

Application processing zone 13 (synchronous/asynchronous) processing includes processing user requests for transactions both at the time of their receipt (synchronously) and offline (batch) mode (asynchronously), which determines the nature of its architecture and distribution of functions.

The DCU application processing area (FIG. 3 and FIG. 4) consists of at least one means for publishing documents relating to transactions; at least one means of classifying transactions and at least one means of generating a scenario for the transaction.

A means for publishing documents (Fig. 4) relating to transactions contains:

- user profile module 17 - module responsible for registering and maintaining up-to-date information about each user of the automated system;

- service subscription module 18 - a module responsible for registering subscriptions to notifications of payer users for documents from certain users-recipients of money and notifying the latter about this.

Thus, the means for publishing documents relating to transactions is configured to:

- registering and maintaining up-to-date information about each user of the automated system;

- publication in an automated system for managing the execution of transactions complete information about the execution of a transaction created for the first time, and publication of a link to already published information about the transaction;

- retrieving and providing information on transactions at the request of users of the automated system;

- generating and providing reports to users on transactions.

Tools for generating a transaction scenario combine different documents within the framework of one transaction and contain modules for processing documents and corresponding databases associated with transactions, in particular, for example, but not limited to the following:

- contracts module 19 - a module configured for registering and comparing contracts, checking whether the contract fits into a certain scenario;

- module of acceptance and transfer acts 20 - a module that registers the act of acceptance and transfer and compares it with the agreement into which it may be included;

- invoice module 21 - a module that registers an invoice for payment and compares it with the agreement into which it may be included;

- module for statements from the payer’s bank about debiting funds 22 module, which registers statements from the payer’s bank about debiting funds and compares them with the account, generates notifications for recipients and prepares them for sending to recipients;

- module of statements from the recipient's bank about the transfer of funds 23 module, which registers statements from the recipient's bank about the transfer of funds and compares them with the previous account;

- template module 24 - a module that registers published templates;

- verdict module 25 - a module that receives, remembers and compares it with the issued invoice and the corresponding statements about debiting and crediting funds;

-redirection module 26 - a module that receives an application for redirection of accounts and registers it;

- claims module 27 - a module that registers a claim and compares it with the agreement or act to which it is addressed,

-report generation module 29 - a module that generates reports on transactions.

All modules inform the queue manager module 31 about the work performed for subsequent transmission of this data to the guaranteed notification delivery module 16 and the document provision module 15.

Transaction classification tools consist of modules:

- document reconciliation (comparison) module 28, which provides information about incoming and outgoing business (commercial) activity of users, as well as modules that process other types of documents that are, in the scope of their use, organizational, administrative, financial, accounting and reporting and statistical documents (not shown in Fig. 4).

Reconciliation mechanism - tracking the status of the account and its changes based on the processing of debit statements (credit statements) received in the system from the status “not paid” / “fully or partially paid” to the state “payment made” / “payment received” and further to technical verification processes. The reconciliation mechanism is carried out through the reconciliation module of documents relating to the transaction 28, and is intended to monitor the status of payment and, therefore, increase the reliability of transactions.

Each of the above modules 15-31 has its own database. The centralized data storage base consists of databases of all modules 15-31 of the control center, united by communication channels into a single network.

All modules of the application processing area 13 included in the tools for publishing documents relating to transactions; The transaction script generation tools and the transaction classification tools contain filters that compare the type of document located in the queue manager module 31 from the compatibility zone 12 with the document type set in the filter, and retrieves only those messages whose document type matches the setting of its filter .

At the same time, the centralized data storage database includes unique identifiers corresponding to each user and his service provider. In particular, users mean payers, recipients, user bank (payer bank, recipient bank), regulatory authority, bank payment agent, intermediary bank, etc.

The synchronous version of the operation of the DCU 1 is used if the DCU 1 can complete the processing process in a relatively short time, during which it is advisable to maintain the communication connection.

The asynchronous implementation option is used if the DCU 1 cannot complete the processing process in a relatively short time, during which it is advisable to hold the communication connection.

The above implementation of an automated system for managing transactions and centralized control devices make it possible to reduce the load on the automated system, increase the speed of information processing and reduce the likelihood of failures during transactions. In particular, increasing the speed of processing and sending notifications when document flow is transferred completely to electronic form is achieved through:

- subscriptions of users (addressees or recipients) to documents from certain users (initiators or payers),

- notifications to users (addressees or recipients) about the availability of documents for them from other users (initiators or payers),

- managing the number of requests for documents through the use of a hint identifier,

- use of a network of providers, as well as

- use of synchronous/asynchronous options for implementing information exchange in an automated system.

An automated system for managing transactions between users works as follows (Fig. 1).

In order to become a user of the system, the user (payer or initiator) needs to create an account and generate a request to complete a transaction on his control device 2. To do this, the user must install and launch the corresponding application provided to him by his service provider 4 or go to his website, as a result of which he is presented with an interface for choosing authorization or registration. Each user is granted the right to access several service providers simultaneously.

If the user chooses registration, then the service provider 4 provides the user with an interface for registration, which presents all the fields required to be filled in (initials or name of the organization, telephone number, email address, Taxpayer Identification Number, location or registration address, bank name, account number in a bank, etc.). After this, the service provider 4 checks whether the user is already registered in the automated system for managing transactions. To do this, it checks all the basic identification parameters of the user (payer), such as phone number, email address, Taxpayer Identification Number, etc. for uniqueness in its system.

If all basic identification parameters are unique, the service provider’s device checks whether they really belong to the user (user authentication is carried out). For this, an SMS notification by phone number, push notifications or notifications in instant messengers, a call, a letter with an authentication link to email, etc. can be used. To confirm the user's authenticity, his service provider can also contact the user's bank for this. The service provider's device is configured to perform other additional checks at the user's discretion. After successful registration and authentication, the service provider stores the data by creating a new user account.

The user can use various means to change his account in the UCC, including various functionality of the application or website of the service provider device, including he can edit and delete his account, and can also receive data directly from the Unified Identification System and authentication of the Russian Federation or other similar systems for transmission to the service provider. In particular, the user can add new or change existing bank accounts, new phone numbers or email addresses, and edit any other information at the discretion of the service provider device.

If the user wants to change the parameters of his account, then the device of his service provider 4 provides a user interface for making changes to the account parameters and confirms the changes. The service provider device 4 is configured to check whether these changes are actually made by the user. After verification, user 4's service provider device stores the new data by updating the user account. The user (payer), through his control device 2, is notified that the account editing was successful and is redirected to the main page of the application or website of the device of his service provider 4.

After providing the user (payer) with access to the control center 1 through the device of his service provider 4, the user (payer) generates a request to complete a transaction on his control device 2, which is sent to the control center 1 through communication channels. After this, in order to track information about the transaction , a document relating to the transaction is published in the network of the automated system for managing the execution of transactions 5. The device of the service provider of the user 4, through module 15, receives a notification about the publication of information about the transaction.

A published document relating to a transaction is present on the network 5 until it has some final status (eg, "paid in full" status for an invoice) or the transaction has expired and its current status is not final (eg , “finally delivered”).

Next, we will consider the processes occurring inside the control center (Fig. 3). In the document management module 14 of the synchronous processing zone 11 of the central control center, a request to complete a transaction is received and information about the transaction is extracted from it, the validity of the user (payer) is checked, and requests to complete a transaction (messages) are processed. For example, information about a transaction may include: parties to the transaction, subject, conditions, specifications, delivery schedule. For each transaction and for each document, a unique identifier (URL) is generated in the UCC, with the help of which users can access information about the transaction or document upon request.

In compatibility zone 12, incoming requests to complete a transaction are converted, including placing them in a queue using the queue manager module 31. From the above queue, requests to complete a transaction will be retrieved for application processing by software modules of the application processing zone 13.

Next, in the application processing zone 13 (Fig. 4), incoming information is classified using a document reconciliation (comparison) module 28, which provides information about the incoming and outgoing business (commercial) activity of users. In contract module 19, contracts are registered and compared, and each contract related to a transaction is checked for inclusion in a specific scenario. In the module of acceptance and transfer acts 20, the acceptance and transfer acts are registered and compared with the agreement into which it may be included. In the invoices module 21, invoices for payment are registered and compared with the agreement into which it may be included. In the module of statements from the payer's bank on debiting funds 22, statements from the payer's bank on debiting funds are registered and compared with the account, after which notifications are generated for users (recipients) and prepared for sending to them. In the module of statements from the recipient's bank on the transfer of funds 23, statements from the recipient's bank on the transfer of funds are registered and compared with the previous account. The template module 24 registers published templates.

A template script or contract relating to a transaction may be stored on the network of an automated system for managing the execution of transactions and may be made available upon request by users. Any user service provider device can publish a transaction document template to the DCU. Any user service provider can request from the DCU both a collection of transaction document templates and a specific template.

In the verdict module 25, the verdict, the invoice and the corresponding statements of debiting and crediting funds are saved and compared. In the redirection module 26, an application for redirection of invoices is received and registers it. In the event of a claim by the user, both the payer and the recipient, the claim is registered in the claims module 27 and compared with the agreement relating to the transaction or the act to which it is addressed. All modules send the status of completed work via communication channels to the queue manager module 31 for subsequent transmission of this data to the module 16 for guaranteed delivery of notifications and the module 15 for providing documents.

The notification delivery guarantee module 16 receives from the hint identifier generating module 30 its value for inclusion in the notification. Through the module for guaranteed delivery of notifications 16, the user (payer) is informed through the user control device that documents (in particular, invoices, statements, etc.) are prepared and ready to be sent and provide a hint identifier.

Using the tool for generating a transaction scenario, different documents and transactions are combined within the framework of one transaction. The centralized data storage database of the Central Control Center stores information about templates for transaction scenarios and corresponding agreements accompanying transactions, planned in advance before the transactions are carried out.

Users (payers) receive invoices (payment requests, charges) to pay for purchases, services (commercial and government) and other payments in electronic format, and also initiate payment of received invoices. Electronic bill payment completes the process, allowing the payer to make a payment remotely, eliminating the need to manually enter account details to generate payment orders, and also eliminates the need for a physical invoice carrier - on paper.

Let's consider the processes occurring in the automated system for managing transactions (Fig. 5).

In the service network of the automated system for managing the execution of transactions, it is carried out using the information flow “Publishing a document in the central control center” 32, after which the information flow “Delivery of notification of the publication of a transaction” 33 is applied, containing a hint identifier, and which is delivered to the recipient’s service provider device (addressee). Using the link received by the recipient as part of the information flow “Delivery of transaction contents to the addressee” 34, the user (recipient) can obtain information about the transaction stored in the DCU by presenting the previously received hint identifier. The recipient makes a decision to agree or refuse the transaction, which is accompanied by the information flow “Delivery of the addressee’s response to the UCC” 35. Next, the response is delivered to the recipient’s service provider through the information flow “Delivery of the addressee’s response to the service provider” 36, and also to the payer’s service provider through the information flow “Delivery of the current state of the transaction from the UCC to the initiator’s service provider” 37.

The process of concluding an agreement relating to a transaction is only necessary if the parties to the transaction have decided to enter into a contract. If the user in the payee role immediately issues an invoice to the payer for payment, without first entering into a contract, a non-contract process is applied.

Transactions carried out in the declared automated system can be classified into “unsecured transactions” and “secured transactions” (secure), which require confirmation of the conditions for their execution by a supervisory authority.

In the processes occurring in the automated system for managing transactions, the user in the role of payer, through his control device, can:

- appoint/accept recipients of funds (that is, suppliers of goods, works or services), in particular, subscribe to the delivery of invoices to your address from recipients identified by him;

- receive, accept or reject documents related to transactions published for him (for example, contracts, acceptance certificates, invoices, statements of funds credited from the recipient’s bank, as well as in the future, refunds, reconciliation reports, etc.);

- request a deferment and/or installment plan;

- formalize consent for direct debit of the bank account according to the received invoice for payment with the payer’s bank;

- accept the invoice for subsequent payment;

- accept an invoice for instant payment with payment initiation;

-request reconciliation reports.

Using the control device, the user in the role of payer interacts:

- with the payer’s service provider device (directly via the SP APIs protocol);

- with the control device of the payer’s bank (directly or through the device of the payer’s service provider);

- with the recipient’s control device (either outside the network perimeter of the automated system for managing transactions, or indirectly through the payer’s service provider device connected to the network).

Using the control device, the user in the recipient role can:

- request your activation/subscription by payers;

- receive details of payers who have signed documents from him,

- publish documents (agreements, acts, invoices, statements on the transfer of funds) for payers who have subscribed to it;

- issue invoices to specific payers or to “bearer” (without specifying specific payers);

- agree on the terms of the deferment at the request of the payer;

- agree on installment plans at the payer’s request;

- request the status of issued invoices according to specified conditions;

- request reports and reconciliations on your accounts according to specified conditions.

Using the control device, the user in the role of recipient interacts:

- with the recipient’s service provider device;

- with the control device of the recipient's bank (directly or through the device of the recipient's service provider);

- with the payer’s control device (either outside the network perimeter of the automated system for managing transactions, or indirectly through the recipient’s service provider connected to the network).

For the user in the role of payer, the payer bank, through its control device, provides:

- electronic remote access to the payer’s bank accounts for non-cash payment methods for invoices issued to him (payment requests);

- execution of payments initiated by the payer through its control device, either directly or through its service provider;

- strict authentication of the payer;

- authorization of payer subscriptions;

- execution of payments on behalf of the payer initiated through his service provider;

- execution of payments based on payment requests initiated by the payer's service provider, (direct debit) from the payer's accounts, based on the payer's authorized subscriptions;

- informing the payer’s service provider about executed payments.

Using the control device, the payer's bank interacts:

- with the payer’s control device (directly or through the payer’s service provider using SP APIs);

- with the payer’s service provider device (via PIS/AIS APIs);

- with payment systems or services outside the perimeter of the proposed automated system for managing transactions.

For the user in the role of beneficiary, the beneficiary bank, through its control device, provides:

- acceptance and crediting to the recipient’s bank account of payments on invoices issued by the recipient;

- verification (validation) of the recipient's accounts;

- generation of statements, confirmations, as well as other reports and notifications for the recipient;

- verification of the recipient by sending a request to regulatory authorities and receiving a response to the request.

Using the control device, the recipient's bank interacts:

- with the recipient's control device (directly or through the recipient's service provider device using SP APIs);

- with the recipient’s service provider device (via PIS/AIS APIs);

- with payment systems/services (outside the perimeter of the proposed system) for implementation.

The user, in the role of a regulator, interacts using a control device:

- with the service provider’s device (directly);

- from the central control center (indirectly through the device of a service provider connected to the network of an automated system for managing transactions);

- with the control device of the collateral bank (indirectly through the device of the service provider connected to the network of the automated system for managing transactions);

- with the recipient’s control device (either outside the network of the automated system for managing transactions, or indirectly through the device of the service provider connected to the network of the automated system);

- with the payer’s control device (either outside the perimeter of the network of the automated system for managing transactions, or indirectly through the device of the service provider connected to the network).

The Bank Payment Agent (BPA), through its control device, provides:

- requesting and receiving invoices for payment from your service provider;

- inclusion of invoices for payment in the preliminary check, both together with other user purchases, and in a separately generated preliminary check;

- provision of a fiscal receipt for payment to users in the role of payers;

- informing the user's service provider about payment of an invoice for payment by a certain payer immediately after its completion by the user in the role of payer (it does not matter whether the payment was made in cash or by bank transfer);

- transfer of funds received as a result of the transaction to the final recipients through the BPA bank within the terms and conditions determined jointly with the recipients on the basis of agreements.

- preparation and transfer of a detailed register (one account is recorded in the register for each individual transaction of transferring the payer’s money to the banker’s account), which is a decoding for the transfer of aggregated amounts of funds to both the banker and the recipients through their service provider.

Using the control device, the UUV interacts with:

- by the payer (directly or via the Internet using the payer’s control device in accordance with the requirements of the SP API protocol);

- by the device of the UPA service provider (via the SP API);

- payer bank control device (via API or PIS/AIS APIs);

- with the control device of the recipient's bank (according to payment protocols);

- with the control device of the bank PPA (via API or SP API).

The user, in the role of a collateral bank, through his control device, credits funds to bank accounts opened for users as guarantees of fulfillment of the terms of the contract, as well as transfers collateral funds to the user upon receipt of confirmation of the fulfillment of the terms of the contract (verdict) from the regulatory body.

The security bank performs through its control device:

- as a result of the start of a secure transaction - receipt of the payer’s funds from the payer’s bank and their storage;

- informing the network of the automated system for managing the execution of transactions about the crediting of these funds to your account;

- storage of funds received as a result of the start of safe transactions, from the moment of crediting the payer’s funds received to secure settlements under a safe transaction, until the moment when, by order of the network of an automated system for managing transactions based on the verdict of the supervisory authority on the fulfillment of the terms of the transaction, funds placed to secure settlements were transferred to the recipient's bank account in the recipient's bank;

- sending to the recipient’s bank previously placed funds received as part of a secure transaction to ensure future settlements, according to an order received from the network of an automated system for managing transactions, received as a result of a verdict of a supervisory authority on the fulfillment of the terms of a secure transaction by the recipient;

- subsequent informing of the automated system network for managing transactions regarding the debiting of funds from the payer’s account and their transfer to the recipient’s bank from the payer’s bank account.

The BPA bank, through its control device, performs:

- as a result of collection by the banker or transfer of money to the banker’s account - receipt of the payer’s funds from the payer’s bank and their storage,

- informing the network of the automated system for managing the execution of transactions about the crediting of these funds to the bank account account;

- storage of funds in the account of the payment agent, received as a result of the mentioned actions on the part of the payment agent;

- sending funds received earlier, by order of the payment partner, to the recipient’s account in the recipient’s bank;

- subsequent informing of the network of the automated system for managing the execution of transactions on debiting funds from the bank account and sending them to the recipient's bank to the recipient's bank account.

Using the control device, the collateral bank interacts with:

- user service provider (via SP API);

- with the control device of the supervisory authority (only indirectly through the network of an automated system for managing transactions).

Using its control device, the UUV interacts with:

- user service provider (via SP API);

- with a cash register control device (directly via proprietary protocols and indirectly through the network of an automated system for managing transactions).

The Operations and Clearing Center (OPCC) through its control device performs:

- receiving orders to transfer funds from Payer Banks, their processing and routing to Recipient Banks, as well as orders to transfer funds to the settlement system;

- receiving requests for authorization from BPA Banks and their routing for authorization to payer banks, receiving responses and returning them to BPA Banks;

- receiving payment requests, processing them in clearing, generating net positions and sending them to the settlement system, as well as sending reports to user banks.

Summarizing the above, it should be noted that the process of concluding an agreement relating to a transaction is aimed at publishing it in the UCC of an automated system for managing transactions and ensuring agreement on its terms by all parties. The agreement is concluded between users (parties to the agreement), and the minimum number of parties to the agreement is two, and the maximum number is not limited. Moreover, any agreement defines an exhaustive set of agreements between the parties to the agreement. For example, one party, as part of a contract, undertakes to supply some goods, and the other - to pay for it.

The above technical means for implementing the claimed invention make it possible to increase the reliability and speed of information processing when conducting transactions, as well as improve the quality of user service by eliminating non-payments due to “lack of information” or “non-delivery of invoices”, reduce the likelihood of errors in payment, increase the speed of information processing, and, as a result, document flow. The above technical solution also makes it possible to increase the reliability of transactions by improving the quality of reconciliations, as well as providing users with reports on the fulfillment of obligations under transactions. By reducing the load on the automated system for managing transactions, the speed of processing transactions in the said system increases.

The above benefits are confirmed by the following examples.

Examples of implementation.

Example 1: Registration and Authentication

The user's control device receives a notification that registration has been completed successfully, after which the user is redirected to the main page of the application or the website of the device of the service provider 4. Next, the user, through the device of his service provider 4, sends a request to the selected bank in order to he authenticated. Through its control device 7, the user's bank authorizes the user in any way convenient for him. If service provider 4 is not able to independently authorize the user, then he provides him with a choice of authorization channel. After confirmation by the user through the selected data bank, the user bank returns the authorization token to the user control device (2 or 3) for subsequent access to the control center 1.

Authorization using a token occurs as follows. The user (payer), through his control device 2 or 3, requests access to the server or protected resource (service provider device 4 or payer bank control device 7, providing a token. Access is granted or, conversely, denied based on the issued token. After this, the service provider 4 sends a request to UCC 1 to publish a user (payer) account.All data about users and their preferences are stored in the centralized data storage database of the UCC, and each user is assigned a unique identifier.

Example 2. Transactions between legal entities (B2B payment):

1. Supply of products to supermarkets, restaurants, cafes from suppliers.

2. Supply of computer equipment to companies specializing in computer assembly.

3. Supply of raw materials for production to factories and factories.

4. Delivery of cars to car dealerships.

5. Supply of cosmetics, household chemicals, clothing, shoes, etc. to specialized stores.

6. Payment for the services of construction, cleaning, security, repair companies, cargo transportation.

7. Payment for insurance.

Using a B2B invoicing service will make it easier for parties to issue and pay invoices, and will also increase their reliability by implementing a reconciliation mechanism in an automated system to manage transactions.

Example 3. Transactions between legal entities and individuals (C2B payment).

The interaction between the parties takes place online, using the interface provided by the recipient (mobile application, website).

1. Online shopping

Delivery of food, groceries, purchase of clothing, household appliances, shoes, furniture, cosmetics, flowers, tools, jewelry, equipment, auto parts, household goods, books.

2. Payment for the services of cleaning companies, lawyers, tutors, loaders, cargo transportation.

Transactions between legal entities and individuals with instant delivery of goods:

1. Buying tickets to concerts, theaters, cinemas, sports matches, air tickets.

2. Hotel reservations.

3. Purchase of tourist tours.

4. Purchase of software.

5. Purchasing insurance.

6. Payment of taxes, duties, fines.

Convenient mechanism for periodic invoicing in subscriber transactions:

1. Topping up personal accounts with service operators.

2. Toll roads.

3. Payment for subscriptions to music and video services.

4. Payment for periodic food deliveries, for example, delivery of meal kits every week.

5. Payment for parking.

6. Payment of rent.

7. Payment for a subscription to a gym, swimming pool, fitness club.

Gift transactions (in this form of transactions, one of the parties provides a donation to the other party free of charge), for example, charitable donations.

Tracking charitable payments is an extremely difficult task for the government. The transaction support service will correct these problems by providing an invoice tracking mechanism and a convenient way to make donations, which consists of the charity delivering a QR code or link to the invoice to the donor. After this, the donor scans the QR code or follows the link and makes a donation. There are no forms to fill out.

Accounts for offline transactions:

1. Purchasing food in canteens, cafes, restaurants, fast food establishments.

2. Buying groceries at the supermarket.

3. Purchase of jewelry, household goods, fishing goods, medicines, flowers, construction goods, furniture, plumbing, household appliances, medicines in the store.

In these transactions, the interaction takes place offline, for example, in a store. Currently, there is a problem of filing claims against the supplier of goods or services in the event of loss of proof of the transaction (cash receipt). Although the law provides for a refund if the receipt is lost, in reality the buyer will face a number of inconveniences. The use of an invoicing mechanism and a transaction support service will simplify the filing of claims against the seller, because the document confirming payment is in electronic form with the buyer.

Payment of bills for housing and communal services (HCS).

The existing mechanism for paying housing and communal services bills is inconvenient and unprofitable for both management companies and consumers of services. Additional inconvenience is created by the presence of a large number of management companies (MCs), each of which issues invoices. The transaction support service provides payers with a convenient mechanism for paying and receiving invoices, including batch payments (all invoices from management companies can be paid with one click), and providers of housing and communal services with a convenient mechanism for delivery and reconciliation.

Example 4. Transactions between individuals (P2P payment).

In this type of transaction, interaction occurs between individuals. Such transactions are hidden from the state; it cannot monitor them and provide legal protection to the parties. The introduction of a transaction support service will help eliminate these shortcomings, and also, with possible strengthening of state control over P2P transactions, will provide a convenient payment and invoicing mechanism in a timely manner.

Examples of such transactions may be:

1. Purchasing used goods, for example, from online classifieds services.

2. Payment for private services of tutors, builders, movers, plumbers, computer technicians.

3. Payment of rent.

4. Payment of debts between individuals.

Example 5. Making a transaction between users with the participation of OPCC (Fig. 6).

The initiator of a funds transfer can be the user as a payer or recipient of funds.

The Operational Payment Clearing Center (OPCC) through its control device:

- receives requests from at least one control device of the user bank for the transfer of funds and processes them;

- identifies recipients and sends requests to them;

- receives responses to requests and compares them with original requests;

- receives direct payment requests and sends them for clearing;

- performs clearing of counter unaccepted payment requests;

- based on the results of clearing, generates a register of net positions for direct transfer of funds between banks, clearing reconciliation reports for users containing the elementary components of each net position;

- sends either a register of net positions or an order to transfer funds for a separate transaction to the settlement bank of the payment system;

- sends a reconciliation report or notification of completed settlements to user banks participating in the funds transfer.

Example 6 of a script template for one contract in the form of a directed cyclic process graph is presented in FIG. 7. As you can see, from the state (1) “contract”, according to the template, the scenario can go to the state either (3) “invoice” or (6) “delivery”. In turn, this example scenario provides for a transition from state (6) “delivery” only to the only next state (2) “acceptance act”, from which only a single transition to state (3) “invoice” is also provided. Following this, events, according to this scenario, can unfold in two ways:

or through the successive states (4) “statement of write-off” and (5) “statement of enrollment” return to state (6) “delivery”, from where there will be a transition to state (2) “Acceptance certificate” and to state (3) “ Account”, after which the transition will again be to state (4) “statement of write-off”. And this will be repeated as many times as required (how many deliveries - there will be as many such repetitions of the cycle)

or through the successive states (4) “statement of write-off” and (5) “statement of crediting” the transition to state (3) “Account”, after which there will again be a transition to state (4) “statement of write-off”. And this will be repeated as many times as necessary (how many payments are provided for one delivery certificate; this is an example of payment for an acceptance certificate in installments)

An example 7 of a script template for multiple related contracts in the form of a directed cyclic process graph is presented in FIG. 8.

The difference from figure 7 is that in this cyclic directed graph there is an edge connecting state (5) “Statement of enrollment” with state (1) “Contract”, which means the transition from one contract to the next, provided for by complex (consisting of many contracts) scenario.

Example 8 of calculating the number of requests allowed to the payer user using a hint identifier.

To determine a user's category, a set of parameters for user categorization, specified by the DCU, is used.

Based on the parameters stored in the centralized database at the UCC, parameters are set according to which users are divided into categories.

Such parameters include, in particular, but not limited to the following:

- whether the user is an individual or legal entity;

- the type and volume of activity carried out by the user (for example, the number of requests for an individual registered as self-employed will exceed the number of requests provided to an individual, but will be less than for a legal entity, for example, for a management company);

- status of a legal entity assigned upon registration (simply recipient or VIP Recipient)

- additional, including commercial, categorization conditions (for example, a tariff for an increased number of requests for one hint identifier for obtaining documents of certain types).

At least two categories of users are determined, and then this data is transmitted to the hint identifier generation module. For each user category in the UCC, the number of requests allowed by means of a hint identifier is specified.

At the same time, for service providers of individuals acting as payers, you can set a limit on the number of free requests (for example, from 1 to 3), if exceeded, the user’s service provider will be charged at the rate established by the UCC. The number of requests for service providers of legal entities acting as recipients is set similarly (for example, from 1 to 3). For service providers of VIP recipients, the number of free requests can be slightly increased, for example, up to 5.

Such restrictions are due to the following circumstance: UCU will notify any service provider at any time of any publication or any modification of any document. And the rules of the system, determined by the UCC, provide for a requirement for service providers to remember and provide users of any type with information about documents upon their requests independently without contacting the UCC, since they are the owners of up-to-date information. If any update occurs on the DCU side, then, as stated, the DCU will again notify the service provider, who will update the information in its system by contacting the DCU, after which it will again have up-to-date information to provide it to users without direct contact with the UCU. The methodology and practice described here has received an internationally recognized name - caching, and the service provider acts here as such a “cache”, that is, an intermediate buffer of information with quick access to it based on user requests.

Claims (51)

1. An automated system for implementing information exchange in a service to support transactions between its users, containing a centralized control device for implementing information exchange to support transactions between users, configured to provide a service to support transactions, and, at least two user control devices, with a user interface installed on them, using communication channels to provide access to the user control device to the centralized control device to implement information exchange to support transactions between users through at least one service provider device, characterized in that a centralized control device for implementing information exchange to support transactions between users is made in the form of a software and hardware complex of means for automating the management of transactions and is divided into a synchronous processing zone intended for generating a quick response to user requests and sending it to the user, a compatibility zone intended for setting in the queue of requests for transactions, and an application processing zone designed to ensure synchronous and asynchronous processing of user requests and logical control of information about transactions received from users, wherein the centralized control device for implementing information exchange to support transactions between users contains a control device that limits the number of user requests for information about transactions received via communication channels to the centralized control device for implementing information exchange to support transactions between users, a specified number of times. 2. The system according to claim 1, characterized in that it contains at least one user bank control device, configured to implement the functions of a service provider and connected via communication channels with the centralized control device. 3. The system according to claim 2, characterized in that the control device of the user's bank is connected via communication channels with the centralized control device through at least one device of the service provider. 4. The system according to claim 1, characterized in that user communication tools with a user interface installed on them are used as a user control device for indirect, through a service provider, access to the centralized control device. 5. The system according to claim 1, characterized in that it contains at least one control device of the intermediary bank, configured to implement the functions of a service provider and connected via communication channels with the centralized control device. 6. The system according to claim 5, characterized in that the control device of the intermediary bank is connected via communication channels with the centralized control device through at least one device of the service provider. 7. The system according to claim 1, characterized in that it contains at least one control device of a supervisory authority, configured to implement the functions of a service provider and connected via communication channels with a centralized control device. 8. The system according to claim 7, characterized in that the control device of the controlling body is connected via communication channels with the centralized control device through at least one device of the service provider. 9. The system according to claim 1, characterized in that it contains at least one control device of a bank payment agent, configured to implement the functions of a service provider and connected via communication channels with a centralized control device. 10. The system according to claim 9, characterized in that the control device of the bank payment agent is connected via communication channels with the centralized control device through at least one device of the service provider, 11. The system according to claim 1, characterized in that it contains a control device of the operational clearing center, connected via communication channels with at least one control device of the user's bank and a control device of the intermediary bank. 12. The system according to claim 1, characterized in that the centralized control device is configured to manage the user profile. 13. The system according to claim 1, characterized in that the device of at least one service provider is configured to provide the user with an interface for registering, checking identification parameters and authenticating the user, as well as storing data by creating a new user account. 14. The system according to claim 1, characterized in that, as a means of control that limits the number of user requests for information about transactions received via communication channels to the centralized control device, a specified number of times, a hint identifier generation module and a document provision module are used , which checks the number of uses of the hint identifier. 15. A centralized control device for implementing information exchange to support transactions between users, containing a centralized data storage database configured to store registration data, credentials and preferences corresponding to each user, as well as tools for automating the management of transactions, characterized in that they use, as a means for automating the management of transactions, at least one means for receiving and delivering to the user documents relating to transactions, containing a document management module, a document provision module, a module for guaranteed delivery of notifications and download links, a hint identifier generation module and a queue manager module, wherein the identifier generation module is hints and a module for providing documents form a control tool that limits the number of user requests for information about transactions, and the queue manager module ensures that requests for transactions are queued when processing requests asynchronously, at least one means for publishing documents relating to transactions, at least one means of classifying documents relating to transactions, at least one means of generating a transaction scenario, wherein these means are intended for synchronous and asynchronous processing of user requests for transactions. 16. The centralized control device according to claim 15, characterized in that the means for publishing documents relating to transactions contains a user profile module and a service subscription module. 17. The centralized control device according to claim 15, characterized in that the means for generating a transaction scenario contains a contract module, a transfer and acceptance certificate module, an invoice module for payment, a module for a statement from the payer’s bank about debiting funds, a module for a statement from the recipient’s bank about crediting funds, template module, verdict module, redirection module, claims module and reporting module. 18. The centralized control device according to claim 15, characterized in that the transaction classification tool contains a document reconciliation module. 19. Centralized control device according to paragraphs. 16-18, characterized in that all modules included in the tool for publishing documents relating to transactions, the means for generating a transaction scenario and the means for classifying transactions contain filters made with the ability to compare documents relating to transactions and located in the queue manager module. 20. Centralized control device according to paragraphs. 16-18, characterized in that the centralized data storage base consists of databases of all modules of the centralized control device, united by communication channels into a single network. 21. The centralized control device according to claim 15, characterized in that the document management module is configured to perform parsing and validation. 22. The centralized control device according to claim 16, characterized in that the means for publishing documents relating to transactions is configured to publish in the automated system according to claim 1 complete information about the completion of a transaction created for the first time, and publish a link to already published information. 23. The centralized control device according to claim 16, characterized in that the means for publishing documents relating to transactions is designed to retrieve and provide information about transactions at the request of users when the latter uses a unique identifier. 24. The centralized control device according to claim 16, characterized in that the means for publishing documents relating to transactions is designed to generate and provide reports to users on transactions. 25. The centralized control device according to claim 15, characterized in that the centralized data storage base includes unique identifiers corresponding to each user and at least one service provider of the user. 26. An automated method for implementing information exchange in a service to support transactions between its users, including providing at least two users with access via communication channels to a centralized control device through at least one service provider device; user registration, storage in a centralized database of login registration data corresponding to each user, characterized in that create a user account; grant each user the right to access one or at least two service providers simultaneously; the user is authenticated through the user's service provider, publish a document relating to the transaction in the network of an automated system for managing the execution of transactions; generating a user request to complete a transaction on the user's control device; classify incoming information in the centralized management device using a transaction classification tool, form a transaction in the centralized management device, in the centralized data storage database of which templates of transaction scenarios are stored for approval, confirmation and execution of transactions of various types; register, compare and monitor the status of agreements relating to transactions; using a hint identifier, they regulate the number of requests for documents related to transactions received through communication channels, as well as access of the user’s device to information about the transaction. 27. The method according to claim 26, characterized in that the user's account and transaction information are published in the centralized management device after the user's service provider device verifies his authorization. 28. The method according to claim 27, characterized in that data about user preferences is stored in the centralized data storage database of the centralized control device. 29. The method according to claim 27, characterized in that a unique identifier is formed for each transaction and for each document in the centralized control device. 30. The method according to claim 27, characterized in that they provide access to information about transactions at the user’s request. 31. The method according to claim 27, characterized in that it provides the user with the means to change the account in the centralized management device. 32. The method according to claim 27, characterized in that documents relating to transactions and located in the queue manager module are compared using filters included in the modules of tools for publishing documents, tools for generating a transaction scenario and means for classifying transactions according to paragraphs. 16-18. 33. The method according to claim 27, characterized in that transactions are carried out with security through confirmation by the control device of the supervisory authority of the fulfillment of the terms of the transaction between users.