Automated system and method for transaction management

Through centralized management equipment, the number of requests for transaction-related information is limited and synchronous and asynchronous information exchange is adopted, the problems of overload and increase transaction time of the existing transaction management system are solved, and efficient and reliable transaction processing is achieved.

CN120266147APending Publication Date: 2025-07-04AKCIONERNOE OBSCHESTVO NACIONALNAYA SISTEMA PLATEZHNYKH KART
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202380081308.0
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Priority Date
2023-02-06
Filing Date
2023-11-28
Publication Date
2025-07-04

AI Technical Summary

Technical Problem

The existing transaction management system lacks control over the number of requests for user transaction-related file before fund transfer, resulting in system overload, increased transaction time and possibility of errors, and is unable to achieve preliminary inspections and payment preparation, which limits service functions.

Method used

The centralized management equipment limits the number of requests for transaction-related information by users, adopts synchronous and asynchronous information exchange, and combines the synchronous processing area, compatible area and application processing area to achieve rapid processing and logical control of transaction-related information, including document reception, submission, classification and scene generation, and use the prompt generation module to control the number of requests.

Benefits of technology

It reduces the load on the automation system, improves the reliability and speed of information processing during transactions, reduces the possibility of transaction failure, and improves the reliability of transactions and user service quality.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure HDA0005417217270000011
    Figure HDA0005417217270000011
  • Figure HDA0005417217270000021
    Figure HDA0005417217270000021
  • Figure HDA0005417217270000031
    Figure HDA0005417217270000031
Patent Text Reader

Abstract

The invention relates to information technology in the financial industry, in particular to automated systems, devices and methods for transaction management, and can be used for automated management and monitoring of transactions. An automated system for managing transactions between users of the system comprises a centralized management device (1), at least two user management devices equipped with user interfaces, and a service provider device (4). Each user management device is connected to the centralized management device (1) via a communication channel by at least one service provider device (4). The present invention allows for reducing the load of an automation system for managing transactions between users, as well as improving reliability and accelerating information processing at the time of transactions.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to IT in the financial industry, in particular to automated systems, devices and methods for transaction management, and can be used for automated management and control of transactions, as well as for arranging the sale of goods and services. Background Art

[0002] Financial technologies are developing rapidly, especially those related to cashless payments; overlay services are one of them.

[0003] Overlay services are developed software and hardware services to improve various consumer-friendly payment services (for individuals and legal entities), as well as to improve security, simplify transactions and make them proceed smoothly. In the financial industry, overlay services can be used before payment, after payment, and independently of any payment. One of the overlay services is the transaction support service described herein.

[0004] The known invention in the art describes a method and a computer system for conducting a commercial transaction between a consumer and a merchant: Patent RU2702085C2 (Classification G06Q20 / 00, 18.01.2016). The known method includes initiating a transaction with a merchant by a consumer computer system, where the consumer computer system then requests an authoritative dynamic value on a central platform, receiving, by the consumer computer system from the central platform, a payment account selection request from two or more consumer payment accounts, and receiving a selection of a payment account by the consumer through the computer system from two or more consumer payment accounts. Wherein, the consumer computer system then receives an authoritative dynamic value from the central platform, wherein the authoritative dynamic value corresponds to the primary account number (PAN) of the selected payment account. Wherein, the commercial transaction is terminated using the authoritative dynamic value received by the merchant computer system. The computer system for conducting a commercial transaction between a consumer and a merchant is configured to implement the described method.

[0005] The disadvantages of the described method and computer system are the lack of a function for controlling the number of requests by a user for documents related to a commercial transaction (transaction), and the inability to perform preliminary checks and prepare for payment before a funds transfer, which results in overloading of the computer system, an increase in transaction time, and a possibility of errors.

[0006] The closest analogue solutions to the required automated systems, devices and methods for transaction management are the systems, devices and methods described in patent RU2581784 (IPC G06Q20 / 00, 11.02.2011). The known automated system includes a centralized management device and management devices for at least two users, uses communication channels to ensure that the management devices of the users access the centralized management device via at least one service provider device, and a user interface module configured to provide any user with access to the centralized management device. The known centralized management device (platform) has a centralized database configured to store information about user registration, credentials and preferences, and means for automating transaction management. The known automated method includes providing at least two users with access to the centralized management device via at least one service provider device via a communication channel; registering users and storing access credentials for each user in the centralized database.

[0007] The disadvantages of this invention include providing access to the invoice provision service only via one service provider, which significantly limits the service functionality, and the inability to control the number of requests from users for transaction-related documents, which leads to overloading of the automated system and an increase in transaction time. Another disadvantage is that it is technically infeasible to perform preliminary checks and prepare for payment before transferring funds using the said system and method, which may lead to errors during transactions. Summary of the Invention

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

[0009] The technical result of the claimed invention is to reduce the load on the automated system and devices for transaction management, and to improve the reliability and speed of information processing when conducting transactions.

[0010] Improving the reliability of information processing should be understood to mean providing information security when exchanging information in an automated system, conducting secured transactions, reducing the likelihood of errors during transactions, registering transactions, and reconciling information related to incoming and outgoing transactions.

[0011] By managing the number of requests for transaction-related documents, enabling information exchange in the service provider support system, and implementing synchronous / asynchronous information exchange, the load on the automated system and devices for transaction management is reduced. It is worth noting that reducing the load on the automated system for transaction management also accelerates information processing when conducting transactions.

[0012] This technical achievement is realized by an automated system for transaction management. The automated system for transaction management includes a centralized management device configured to implement centralized management of transaction support services and management devices of at least two users equipped with user interfaces, using a communication channel to ensure that the management devices of the users access the centralized management device via at least one service provider device, where

[0013] The centralized management device is a hardware and software system configured for automation of transaction management, and includes a synchronous processing area, a compatibility area, and an application processing area for processing and logical control of information about transactions from users.

[0014] Among them, the centralized management device includes a control device designed to limit the number of requests from users for information related to transactions sent to the centralized management device via the communication channel to a set number of times.

[0015] As a specific embodiment, the system includes a bank management device of at least one user configured to act as a service provider and connected to the centralized management device via a communication channel.

[0016] The bank management device of the user uses the communication channel to connect to the centralized management device via at least one service provider device.

[0017] The communication device of the user equipped with a user interface for indirect access to the centralized management device (via a service provider) is used as the management device of the user.

[0018] The system includes at least one intermediary bank management device configured to act as a service provider and connected to the centralized management device via a communication channel.

[0019] The intermediary bank management device uses the communication channel to connect to the centralized management device via at least one service provider device.

[0020] The system includes at least one control agency management device configured to act as a service provider and connected to the centralized management device via a communication channel.

[0021] The control agency management device uses the communication channel to connect to the centralized management device via at least one service provider device.

[0022] The system for transaction management includes at least one bank payment agent management device configured to act as a service provider and connected to the centralized management device via a communication channel.

[0023] The bank payment agent management device uses the communication channel to connect to the centralized management device via at least one service provider device.

[0024] The system includes an operation and settlement center management device that is connected to a bank management device and an intermediary bank management device of at least one user via a communication channel.

[0025] The centralized management device is configured to manage user profiles.

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

[0027] The usage prompt generation module and the document providing module for checking the number of prompt usages are used as control means designed to limit the number of requests from users for transaction-related information sent via the communication channel to a set number of times.

[0028] For processing and logical control of transaction-related information from users, the synchronous processing area is configured to generate a quick response to user requests and submit it to the user, the compatible area of the centralized management device is configured to queue transaction-related requests, and the application processing area of the centralized management device is configured to perform synchronous and asynchronous processing.

[0029] The centralized management device has a centralized database configured to store information about user registration, credentials, and preferences, as well as devices for automating transaction management.

[0030] Among them, the devices for automating transaction management include:

[0031] Devices for receiving at least transaction-related documents and submitting them to users;

[0032] At least transaction-related document publishing devices;

[0033] At least transaction-related document classification devices;

[0034] At least transaction scenario generation devices.

[0035] As a specific embodiment, the document receiving and submitting device includes a document management module, a document providing module, a module for delivering assurance notices and download links (storage and forwarding module), a prompt generation module, and a queue manager module.

[0036] The transaction-related document publishing device includes a user profile module and a service subscription module.

[0037] The transaction scenario generation device includes a protocol module, a transmission and acceptance certificate module, an invoice module, a bank debit statement module of the payer, a bank credit statement module of the payee, a template module, a ruling module, a redirect module, a claim module, and a report generation module.

[0038] The device for transaction classification includes a document reconciliation module.

[0039] All modules included in the document publishing device related to transactions, the transaction scenario generation device, and the transaction classification device include filters configured to match documents related to transactions included in the queue manager module with each other.

[0040] The centralized database consists of the databases of all modules of the centralized management device and forms a single network via a communication channel.

[0041] The document management module is configured to perform parsing and verification.

[0042] The document publishing device related to transactions is configured to first publish complete information about a transaction in an automated system and share a link to the previously published information.

[0043] The document publishing device related to transactions is configured to receive and provide information about a transaction according to a user request by using a unique prompt.

[0044] The document publishing device related to transactions is configured to generate a report about a transaction and provide it to the user.

[0045] The centralized database includes unique identifiers related to each user and the service provider of at least one user.

[0046] An automated method for transaction management includes providing access to a centralized management device for at least two users via at least one service provider device via a communication channel; registering users and storing access credentials of each user in the centralized database.

[0047] The method includes:

[0048] Creating user accounts;

[0049] Providing access to one or at least two service providers for each user simultaneously;

[0050] Performing user authentication via the user's service provider and publishing documents related to transactions on the network of the automated system for transaction management;

[0051] Generating a user request for conducting a transaction on the user's management device;

[0052] Classifying incoming information on the centralized management device via the transaction classification device;

[0053] Generating a transaction on the centralized management device, and the centralized database of the centralized management device stores transaction scenario templates for approving, confirming, and conducting various transactions;

[0054] Registering, comparing, and tracking protocols related to transactions;

[0055] Via prompts, control the number of requests for transaction-related documents received via a communication channel and the access of the user's device to transaction-related information.

[0056] In a particular embodiment, after performing an authentication check of the user via the user's service provider device, publish the user account and transaction-related information on a centralized management device.

[0057] Store data regarding user preferences in a centralized database of the centralized management device.

[0058] Generate unique identifiers for each transaction and each document in the centralized management device.

[0059] Provide access to transaction-related information according to user requests.

[0060] Provide an account editing device for the user in the centralized management device.

[0061] Using filters of the modules included in the transaction-related document publishing device, transaction scenario generation device, and transaction classification device, match the documents included in the transaction-related queue manager module with each other.

[0062] Perform a guaranteed transaction after the control agency management device confirms compliance with the transaction conditions.

[0063] The term

[0064] Transaction support service (automation system) is an overarching service for issuing invoices and making electronic payments for such invoices, aiming at standardizing and accelerating the workflow, providing electronic delivery of invoices from the payee to the payer (with an accepted payment order), and preparing for payment; it is also a mechanism for digitizing the workflow between users (economic entities). In particular, agreements, acceptance certificates, invoices with the amount due (sales receipts or report documents), bank debit reconciliations of the payer, bank credit reconciliations of the payee, rulings of the control agency, statements of the guarantee bank, delivery notes (documents provided by the supplier to the buyer when delivering goods) can be used as documents for confirming user transactions. This list is not restrictive and is provided only as an example.

[0065] The transactions used herein are the actions of users, particularly individuals, legal entities, and government agencies, aiming to establish, change, or terminate civil rights and obligations. Transactions between users are registered in the transaction support service (automation system) for electronic management.

[0066] Information regarding the conduct of a transaction is information about the transaction, including the user requests for conducting the transaction and notifications regarding all its stages (notifications published on the network of the transaction support service, confirmed payment notices, etc.).

[0067] A user (an individual, legal entity or government agency) is a subject of information exchange in the transaction support service. They use their management device to interact with the user's service provider device and the user's bank. A user can be the initiator or recipient of the transaction process, or the payer or payee of invoices and payments.

[0068] The user's bank is a subject of information exchange in the transaction support service. It is a financial institution that provides electronic access to the user's bank account and supports payments, especially during the interaction with the Operational and Payment Clearing Center (OPCC).

[0069] The management device of the user (payer or payee) is a personal communication device used to manage transactions in the automation system for the purpose of information exchange and payment. A device with a user interface that can implement transaction management, as well as data exchange and receive information about the progress of the transaction (workflow) and / or payment transactions, can be used as the management device of the payer or the payee. The user's communication device installed with a user interface, especially a mobile phone, tablet computer, personal computer, terminal or ATM, can be used as the user's management device. The common point of these devices is that the user needs to be initially authenticated by their bank in the interface of such devices.

[0070] The payer is a subject of information exchange in the transaction support service. They use their management device to directly interact with the service provider device and the management device of their bank, and are configured to provide services for the purpose of requesting and receiving soft copy files, such as agreements, certificates, invoices, file resolutions sent to the payer, and initiating payments in favor of the payee. Individuals, legal entities and government agencies can all be payers.

[0071] If the user is a payer, the bank used for payment is called the payer's bank, and the user's service provider in this case is called the payer's service provider.

[0072] The payee is a subject of information exchange in the transaction support service. They use their management device to initiate electronic invoicing (issue a payment order with acceptance) via the payee's service provider and wait for the funds to be credited to the payee's bank account in the payee's bank according to the issued invoice. Any individual and legal entity, as well as any organization including government agencies, can become a payee.

[0073] An individual can be understood to mean including but not limited to: purchasers of goods, works or services, sole proprietors, private and self - employed individuals.

[0074] A legal entity can be understood to mean, including but not limited to: trading companies, telecommunications companies, utility service providers, apartment associations, non-commercial partnerships of gardeners, consumer cooperatives for mansion construction, etc.

[0075] If the user is the payee, the bank used for payment receipt is called the payee's bank, and the service provider of such user is called the payee's service provider.

[0076] Any transaction between users, including the purchase or payment for services, does not require an agreement to be signed each time, but is still essentially an agreement. The users, especially the payer and the payee (initiator and recipient), make decisions: one party decides to sell something or provide a service at a specific price, while the other party decides to pay for the service or buy something at a specific price. A process means only preparing one accompanying document, such as a financial sales receipt.

[0077] The payer's bank management device is at least one computing device of a credit institution serving the payer, as defined by the standard, from whose current account funds must be debited when transferring funds according to the payer's instructions.

[0078] The payee's bank management device is at least one computing device of a credit organization serving the payee, as defined by the standard, into whose current account funds must be credited when transferring funds with the payee as the beneficiary.

[0079] The user's service provider device is a software and hardware system, including at least one server, for user information exchange in transaction support services and providing access to electronic services of said services, in particular: access to accounts, reporting activities in transaction support services, creating, editing, publishing and delivering transaction-related documents and devices for subscribing to such documents, providing the user's profile data to subscription participants (those who have subscribed), payment initiation, user notification. Each user's service provider device is configured to provide an interface for the user to register, authenticate identity parameters and authenticate the user, and store data by creating a new user account, which results in reducing the load on the automated system and devices for transaction management.

[0080] If additionally supplemented with customized devices and specially configured software, the software and hardware systems of each bank (user bank, intermediary bank, bank payment agent) and the control bodies of automated systems for transaction management can additionally act as service providers. As a result of the above, the user's bank management devices, especially the payer's bank management device and the payee's bank management device, intermediary bank management device, bank payment agent management device and control body management device are configured to act as service providers.

[0081] The Centralized Management Device (CMD) is a software and hardware system that includes servers ensuring the system's operation and application software for transaction support services. Each server is designed as a computing system that includes automated devices and their modules for transaction management.

[0082] A module is a specific software component. A group of modules defines the operation of the CMD hardware and software system. The number of modules of the same type depends on the CMD's load capacity: the higher the requirement for the CMD load, the more modules of the same type may need to run simultaneously. The number of different types of modules depends on the diversity of the purposes for using the CMD to sign agreements (such as purchase and sale agreements, service agreements, joint venture agreements, escrow agreements, insurance agreements, etc.).

[0083] The combination of software and hardware systems of the management device of the user, the bank management device of the user, the service provider device, the centralized management device, the intermediate bank management device, the control agency management device, the bank payment agent management device, and the operation and clearing center management device is an automated system for transaction management.

[0084] A process is a series of actions aimed at creating and editing transaction-related documents (agreements, certificates, invoices, statements, etc.) in an automated system for managing transactions (which are the result of information flows).

[0085] An information flow is a specific sequence of messages exchanged by users in an automated system for transaction management, the processing of which leads to the establishment, modification, or termination of legal relationships of legal entities, individuals, or government agencies (creating or modifying a specific document or receiving information about such a document).

[0086] A message is the basic unit of an information flow that transmits the content of a transaction-related document (payload). The management devices of individuals, legal entities, and government agencies exchange electronic information to form a logical unit for receiving data about transactions, including information about users (especially the payer, the payer's bank, the payee, the payee's bank, the payment system, the intermediate bank, the transaction amount, and the fees charged by system users in the case of fund transfers).

[0087] If all the messages forming an information flow are exchanged exclusively between a user and their service provider, then such an information flow is considered local, i.e., the centralized management device does not participate in it. Such an information flow is formed outside the automated system for transaction management.

[0088] A data element is the basic unit of a message and forms a block within the message.

[0089] A block is a fragment of a transaction-related document, consisting of a set of data elements that are (entirely) created in one process as an integral part of the document and can be used as a reference to that fragment during one or more subsequent processes of creating other documents. At least two blocks are grouped in a data block.

[0090] A scenario is a specific sequence of planned service (deliveries) and / or transaction-related processes (documents). A scenario or protocol can be initially planned before signing one or more agreements; that is, a template of the scenario can be included in the agreement executed using such a scenario, or a template of the entire agreement can be used. Generally, a scenario does not belong to one agreement. Scenarios can be created for different agreements or included in one agreement.

[0091] A process trigger is a CMD parameter that affects the selection of a specific information flow for a specific process that forms the documents accompanying a transaction.

[0092] The framework of the automated system for transaction management shows all the links between the key system components: processes, transaction-related documents, users, and information flows. The framework sets the rules for the use of information flows according to the processes.

[0093] The protocol of the automated system for transaction management is a set of rules and technical procedures that enable several users (from two to the required number) to exchange messages using their management devices connected to the network of the automated system for transaction management. The protocol covers all interactions that occur in the automated system:

[0094] - processes and related transaction-related documents;

[0095] - information flows that form each process;

[0096] - triggers that define the rules for information flows for specific processes;

[0097] - the framework that links the management devices of users, processes, transaction-related documents, and information flows;

[0098] - messages that form the information flows;

[0099] - blocks that form the messages;

[0100] - data elements, the basic units of blocks.

[0101] The user profile in CMD is a set of data that identifies the user and their preferences. Managing the user profile process means creating, updating, or removing the user profile, especially adding, changing, or deleting bank details.

[0102] The control agency is a user (organization) that verifies that the payer and payee meet the transaction conditions (makes a ruling) and complies with the law, to ensure that the payer receives the goods or services specified in the agreement and the payee receives the funds in accordance with the agreement for the delivery of the goods or services. The guarantee bank acts as the enforcer of the financial guarantee conditions. For a guaranteed transaction, the control agency uses an automated system for transaction management to (via a ruling) notify the guarantee bank that the payee (supplier or service provider) has met the transaction conditions and the payer's money can be transferred to it.

[0103] A ruling is the conclusion of the control agency regarding the transaction conditions.

[0104] Both government agencies and legal entities (private organizations) authenticated by the parties (users) conducting the transaction and registered (recognized) by the centralized management device can act as control agencies.

[0105] The following agencies can act as government agencies: Federal Service for State Registration, Cadastre and Cartography (Rosreestr), State Inspectorate for Traffic Security (GIBDD), Federal Tax Service (FTS), Federal Financial Monitoring Service (Rosfinmonitoring), and Russian Post. This list is not restrictive and is provided only as an example.

[0106] Legal entities (certified organizations) can include, for example, commercial postal operators or commercial quality control parties.

[0107] The Control Agency Management Device (CAMD) is at least one computing device of the control agency, configured to verify that users (payer and payee) meet the transaction conditions.

[0108] The Bank Payment Agent (BPA) is a subject of information exchange in an automated system for transaction management (transaction support service), in particular a legal entity that ensures the transfer of funds from the payer to the payee. The following enterprises can act as BPAs in relation to invoices and their payment:

[0109] - Trading enterprises;

[0110] - Service enterprises.

[0111] A Bank Payment Agent Management Device (BPAD) is a management device of an organization that ensures the transfer of funds from a payer to a payee.

[0112] An Intermediary Bank (IB) is an information exchange entity in an automated system for transaction management, acting as an intermediary in settlement, accumulating funds received from the payer within a specific time period, and transferring the funds to the payee's account (especially after executing a guaranteed transaction, the system notifies the control agency) or multiple accounts of the payee (after receiving a fund transfer registration form based on data from the BPA from the automated system for transaction management) upon receiving a relevant instruction (from the BPA or as a result of a ruling by the control agency).

[0113] The Intermediary Bank can act as:

[0114] - A Guarantee Bank – for secure transactions involving the control agency;

[0115] - A BPA Bank – when paying an invoice via the BPA.

[0116] An Intermediary Bank Management Device (IBMD) is a hardware and software management system of an organization that accumulates funds received from the payer within a specific time period and transfers the funds to the payee's account upon receiving a relevant order. If additionally supplemented with customized devices and specially configured software, the IBMD can act as an intermediary bank service provider.

[0117] An Operating Clearing Center Management Device is at least one computing device configured to support fund transfers between the management devices of users' banks, process instructions for transfer to the settlement system, receive authentication requests from the management device of the BPA Bank, route such authentication requests to the payer's bank for authentication, receive responses and return such responses to the BPA Bank, receive payment instructions and send such instructions for clearing, form a net position and send such net position to the settlement system, and send reports to the users' banks and the BPA Bank.

[0118] A Prompt is an identifier generated in the CMD Prompt Generation Module, which is a sequence of letters and numbers submitted by the user's service provider in a request to the CMD to control the number of requests for documents sent by the user to the CMD via the communication channel.

[0119] The number of requests allowed by the Prompt is determined by the category to which the user belongs. A set of user classification parameters is used to determine the user category.

[0120] The logical classification of users in the CMD is performed based on classification parameters specified for the recipients, which are stored in a centralized database in the form of configurable profiles of the recipients. The configurable profile of the recipient is the way of classifying users. The recipient (user) has the right to request parameters (possibly business-based) from the CMD, and the user is classified according to these parameters. The number of allowed requests is also specified in the configurable profile of the recipient for each user category in the CMD. Therefore, at least two user categories are determined, and then the data is transmitted to the prompt generation module. Brief Description of the Drawings

[0121] The present invention is illustrated by the following drawings.

[0122] Figure 1 Depicts the framework of an automated system for transaction management.

[0123] Figure 2 Depicts the flowchart of an automated system for transaction management.

[0124] Figure 3 Depicts the schematic structure of the centralized management device (CMD)

[0125] Figure 4 Depicts the structural diagram of the CMD application processing area.

[0126] Figure 5 Depicts the flowchart of the process consisting of the information flow in the automated system for transaction management.

[0127] Figure 6 Depicts an example of a transaction between users (payers and payees) involving the operational payment and clearing center (OPCC).

[0128] Figure 7 Depicts an example of a scenario template for a protocol.

[0129] Figure 8 Depicts an example of a scenario template for a group of related protocols. Detailed Description of the Invention

[0130] The automated system for transaction management ( Figure 1 ) is a distributed or "cloud computing system" for managing transactions.

[0131] An automated system for transaction management includes CMD 1, management devices of at least two users with user interfaces installed (management device 2 of the payer and management device of the payee), and device 4 of the service provider. The management device of each user is connected to CMD 1 via at least one service provider device 4 through a communication channel. CMD 1 and the device 4 of the service provider form network 5 of the automated system for transaction management, in which the devices 4 among all service providers only interact with each other via CMD 1 as the sole central counterparty. CMD 1 manages the identity of the service provider and the interaction of all service providers 4 in all transaction processes (scenarios, information flows). The identity management of CMD means, in particular, registering and issuing unique identifiers to the service providers of the user's bank, intermediary bank, bank payment agent, and control institution, storing these identifiers in a centralized database, and publishing these identifiers on the network of the automated system for transaction management.

[0132] The communication device of the user with a user interface installed for accessing the service provider device can be used as the management device of the user. Smartphones, tablets, smartwatches, computers (including laptops), and TV set-top boxes, whose technical characteristics allow the installation of a user interface (application) to access CMD and access the Internet to use payment services, as well as access personal accounts in the bank (for online services), can be used as the communication device of the user. The above list is not restrictive.

[0133] Depending on the transaction scenario, the automated system for transaction management may also include: management devices of at least one user's bank (management device 6 of the payee's bank or management device 7 of the payer's bank), intermediary bank management device (IBMD) 8, control institution management device (CAMD) 9, and bank payment agent management device (BPAD) 10.

[0134] CMD is a key architectural component of the automated system for transaction management. According to the technical characteristics of the automated system for transaction management, there can be management devices of two to any number of users. At the same time, CMD is configured to manage user profiles, which means creating, updating, or deleting user profiles, in particular, adding, changing, or deleting bank details.

[0135] Figure 2 A flowchart depicting the automated system for transaction management and its main users and interactions is shown.

[0136] All interactions occurring in this system are subject to protocols, in particular:

[0137] - Processes and related transaction-related documents and their users (payer and payee, initiator and recipient);

[0138] - Form the information flow for each process;

[0139] - Define the triggers for the rules of the information flow for a specific process;

[0140] - A framework that links users (participants), processes, transaction-related documents, triggers, and information flows;

[0141] - Messages that form the information flow;

[0142] - Blocks that form the messages;

[0143] - Data elements, which are the basic units of the blocks.

[0144] In addition to the protocols of the automated systems for transaction management, users also use other protocols or communication languages to interact with each other, including ( Figure 1 ):

[0145] - Payment protocols,

[0146] - Service provider APIs,

[0147] - Proprietary API protocols,

[0148] - PIS / AIS API protocols.

[0149] An API (Application Programming Interface) is an interface (language) for programs to interact with each other.

[0150] Payment protocols cover the interactions of users, especially for banks and payment services (e.g., Mir payment system, Russian bank services, fast payment system services, standard payment orders processed by the CSC of the Russian bank), for the actual transfer of funds between users and their banks. The above list is not restrictive.

[0151] Users directly interact with at least the following via their management devices:

[0152] - Their service providers, e.g., via the service provider's API to initiate an information flow, thereby generating specific transaction-related documents;

[0153] - The user's bank management device, e.g., via a proprietary protocol (through the bank's channels).

[0154] Figure 2 The API of the service provider shown (SP API) covers the interactions between the service provider and the user to initiate transactions, especially requests for payments and information on the transaction status (especially the account status).

[0155] The PIS / AIS API (Payment Initiation Service / Account Information Service) is a service used to initiate payments or provide account information, for initiating payments and providing information about bank accounts in cases where the user's service provider and the user's bank roles belong to different entities. Otherwise, if the service provider and the bank are the same entity and such interactions are locally implemented within one entity, the PIS / AIS API is not required.

[0156] To make any changes to the network of the transaction support service, all users can only interact with the user's service provider device via the SP API ( Figure 2 ).

[0157] The user acting as the payer starts the transaction process by sending a transaction request to other users (especially the payee / user bank / control institution / bank payment agent / intermediary bank).

[0158] The above list is not restrictive and may include other devices that perform the functions of the above users.

[0159] According to the legal status of the user and the relevant legal provisions of the automated system, as the payee and payer (initiator and recipient), when processing the subsequent issuance of invoices (fees) and fulfilling the payments corresponding to the issued invoices (charges), transactions can be classified as:

[0160] - B2B – Business to Business;

[0161] - C2B – Consumer to Business;

[0162] - P2P – Person to Person, C2C – Consumer to Consumer;

[0163] - B2G – Business to Government;

[0164] - C2G – Consumer to Government.

[0165] The centralized management device ( Figure 3 ) is configured as a software and hardware system, including a centralized database for storing information about user registration, credentials, and preferences; a document receiving and submitting device; a transaction-related document publishing device; a transaction classification device, and a transaction scenario generating device.

[0166] The CMD has the following areas: a synchronous processing area 11, a compatibility area 12, and an application processing area 13. The processes executed in the specified areas (11 - 13) allow for the processing and logical control of information about transactions received from the service provider.

[0167] The proposed CMD architecture ensures the operation of the system by using "subscribe - deliver" asynchronous message exchange templates and "request - response" synchronous message exchange templates.

[0168] The synchronous processing area 11 contains control devices, which are designed to limit the number of requests from users for transaction - related information, and is configured with a prompt generation module 30 and a document providing module 15 corresponding to a server for synchronous operations (such as but not limited to a web server). In the synchronous processing area, requests / messages are received, checked, and processed in real - time: the system performs parsing, authentication, authentication of the service provider, verification, recording, conversion to an internal representation, and transmission to the compatible area, checks the prompts provided by the service provider, generates a quick response, and sends it to the sender.

[0169] The synchronous processing area 11 contains document receiving and submitting devices, including:

[0170] - Document management module 14 – A module configured to receive messages, extract information from them, verify the sender, and transmit it for processing (registration).

[0171] - Document providing module 15 – A module configured to provide the requested information in response to a request containing a prompt, first checking the said prompt;

[0172] - Module for ensuring the delivery of the guarantee notice and download link (store - and - forward module) 16 – A module configured to notify the CMD that the document is ready and prepared for sending to the recipient.

[0173] - Prompt generation module 30.

[0174] The document management module 14, the document providing module 15, the module for ensuring the delivery of the guarantee notice and download link (store - and - forward module) 16, the prompt generation module 30, and the queue manager module 31 of the compatible area 12 form the document receiving and submitting devices.

[0175] The compatible area 12 corresponds to a server operating as a message queue manager (queue manager module 31) and provides a two - way communication channel between the synchronous processing area 11 and the application processing area 13. The compatible area 12 (two - way communication channel) is a buffer that implements an asynchronous communication mode between the synchronous processing area and the application processing area. In the compatible area, messages converted to an internal representation are received and then placed in a queue, and these messages are extracted from the queue for application processing by the software modules in the application processing area 13. For each message, the software modules in this area will implement the following delivery principles (these principles are usually called policies):

[0176] Persistence policy – The time when the message is delivered to the processing module;

[0177] Security Policy – Set the specified module for the specified message in the access queue;

[0178] Message Deletion Policy – Set the criteria for deleting messages from the queue;

[0179] Delivery Policy – Ensure the guaranteed delivery of messages to the processing module;

[0180] Routing Policy – Set the location of the processing module to deliver messages from the queue to these modules;

[0181] Batch Processing Policy – Set the possibility of transmitting several messages to the processing module for processing at one time.

[0182] Queuing Policy – Set the queuing time.

[0183] Receiving Notification Policy – Ensure that the notification of the message delivery to the processing module 13 is delivered to the document management module 14.

[0184] The application processing area 13 (synchronous / asynchronous) processes include processing the user's request for a transaction (synchronous) when receiving the user's request for a transaction and (asynchronous) in an offline (batch) mode, which determines the area architecture and function allocation.

[0185] The application processing area of the CMD ( Figure 3 and Figure 4 ) includes at least a transaction-related document publishing device; at least a transaction classification device and at least a transaction scenario generating device.

[0186] The transaction-related document publishing device ( Figure 4 ) includes:

[0187] - User Profile Module 17 – A module configured to register each user of the automation system and keep the user information up-to-date;

[0188] - Service Subscription Module 18 – A module configured to register the subscription of the user payee to the notification of the document of the specific user payee and notify the latter.

[0189] Therefore, the transaction-related document publishing device is configured to:

[0190] - Register and keep the latest information about each user of the automation system;

[0191] - First publish the complete information about the transaction in the automation system for transaction management and share the link to the previously published information.

[0192] - Extract and provide the information about the transaction according to the user's request;

[0193] - Generate a report about the transaction and provide it to the user.

[0194] The transaction scenario generation device combines different documents within a transaction and includes modules for processing transaction-related documents and associated databases, specifically but not limited to the following:

[0195] - Protocol module 19 – configured to register and compare protocols and check whether the protocol is included in the specified scenario;

[0196] - Transmission and acceptance certificate module 20 – a module that registers acceptance certificates and matches them with the protocols that may be included therein;

[0197] - Invoice module 21 – a module that registers invoices and matches them with the protocols that may be included therein;

[0198] - Payer's bank debit statement module 22 – this module registers the funds debit statement from the payer's bank, matches it with the invoice, generates a notice for the recipient, and prepares to send it to the recipient;

[0199] - Payee's bank credit statement module 23 – this module registers the funds credit statement from the payee's bank and matches it with the previous invoice;

[0200] - Template module 24 – a module that registers the published templates;

[0201] - Ruling module 25 – a module that receives, stores, and matches the ruling with the issued invoice and the related funds debit and credit statements;

[0202] - Redirect module 26 – a module that receives an invoice redirect request and registers it;

[0203] - Claim module 27 – a module that registers claims and matches them with the related protocols or certificates,

[0204] - Report generation module 29 – a module that generates reports on transactions.

[0205] All modules notify the queue manager module 31 of their execution status for subsequent transmission of this data to the delivery assurance module (store-and-forward module) 16 and the document provision module 15.

[0206] The transaction classification device consists of the following modules:

[0207] - Document reconciliation module 28, which provides information on the user's business (commercial) activities and modules for processing other types of documents such as organizational and administrative, financial, accounting, and reporting, and statistical documents ( Figure 4 not shown).

[0208] The reconciliation mechanism means the processing based on the debit statement (credit statement) received by the system, tracking the account status and its changes, from the status "unpaid" / "paid in full or in part" to the status "payment completed" / "payment received" and further performing technical reconciliation processing. The reconciliation mechanism is implemented by the reconciliation module 28 for transaction-related documents and is designed to control the payment status and, thus, improve the reliability of transactions.

[0209] Each of the above modules 15 - 31 has its own database. The centralized database consists of the databases of all modules 15 - 31 of the CMD that form a single network via the communication channel.

[0210] All modules of the application processing area 13 included in the transaction-related document issuing device; the transaction scenario generation device and the transaction classification device contain filters that match the type of documents located in the queue manager module 31 from the compatible area 12 with the type of documents set in the filters and extract only those messages whose document type matches the filter settings.

[0211] The centralized database includes unique identifiers corresponding to each user and their service provider. In particular, users are understood as payers, payees, the user's bank (payer's bank, payee's bank), control institutions, bank payment agents, intermediary banks, etc.

[0212] The CMD 1 synchronous operation is used for cases where CMD 1 can complete the processing in a relatively short time, during which it is recommended to maintain communication.

[0213] The CMD 1 asynchronous operation is used for cases where CMD 1 cannot complete the processing in a relatively short time, during which it is recommended to maintain communication.

[0214] The above implementation of the automated system for transaction management and the centralized management device allows reducing the load on the automated system, accelerating information processing, and reducing the likelihood of transaction failures. In particular, the acceleration of processing and sending notifications can be achieved in the presence of an electronic workflow for the following reasons:

[0215] - Subscription by the user (recipient or payee) to documents from a specific user (initiator or payer),

[0216] - Notification to the user (recipient or payee) about documents provided for them by other users (initiators or payers),

[0217] - Management of the number of requests for documents by using prompts,

[0218] - Provision of the provider's network, and

[0219] - Use of synchronous / asynchronous information exchange implementation in an automated system.

[0220] The following operation of an automated system for transaction management ( Figure 1 ).

[0221] To become a system user, a user (payer or initiator) needs to create an account and generate a transaction request using their management device 2. For this purpose, the user must install and start the relevant application provided by their service provider 4, or access the service provider's website; as a result, the user sees an interface prompting for authentication or registration. Each user has the right to access several service providers simultaneously.

[0222] If the user chooses to register, the service provider 4 shows the user an interface for registration, which has all the fields to be filled in (abbreviation or full name of the organization, phone number, email, TIN, location or registration address, bank name, account number, etc.). Thereafter, the service provider 4 checks whether the user has already registered in the automated system for transaction management. For this purpose, it checks all the basic identity parameters of the user (payer), such as phone number, email, TIN, etc., to ensure uniqueness in its system.

[0223] If all the basic identity parameters are unique, the service provider device checks whether they actually belong to the user (the user is authenticated). For this purpose, SMS, push messages or notifications in instant messaging, calls, emails with authentication links, etc. can be used. To confirm the authenticity of the user, their service provider can also contact the user's bank. The service provider device is configured to perform other additional user checks at the discretion of the service provider. After successful registration and authentication, the service provider stores the data by creating a new user account.

[0224] The user can change their account in the CMD using various methods, including various functions of the service provider device's application or website; the user can edit and delete their account and can also directly receive data from the Unified Identification and Authentication System of the Russian Federation or other similar systems to transfer the account to the service provider. In particular, the user can add a new or change an existing bank account, a new phone number or email, and edit any other information at the discretion of the service provider device.

[0225] If a user wants to change account parameters, the service provider device 4 presents a user interface for changing the account parameters and confirming the changes. The service provider device 4 is configured to check whether these changes are actually made by the user. After verification, the user's service provider device 4 stores the new data by updating the user account. Through the user's management device 2, the user (payer) is notified that the account has been successfully updated and is redirected to the main page of the application or website of its service provider 4's device.

[0226] After providing the user (payer) with access to CMD 1 through the service provider device 4, the user (payer) generates a transaction request on its management device 2, which is sent to CMD 1 via the communication channel. After that, for the purpose of transaction-related data tracking, transaction-related documents are published on the network 5 of the automated system for transaction management. Through module 15, the user's service provider device 4 receives a notification of the publication of transaction-related data.

[0227] The published documents related to the transaction remain on the network 5 until a final state is set (e.g., the "fully paid" state of an invoice), or the transaction has expired and its current state is not the final state (e.g., "final delivery").

[0228] Next, we will consider the processes that occur in CMD ( Figure 3 ). The document management module 14 in the synchronization processing area 11 of CMD receives the transaction request, extracts transaction-related information from the request, verifies the user (payer), and processes the transaction request. For example, the transaction-related information may include: the parties to the transaction, the subject matter, the conditions, the specifications, the delivery schedule. For each transaction and each document, CMD generates a unique identifier (URL), with the help of which the user can access transaction-related information or documents upon request.

[0229] In the compatibility area 12, the queue manager module 31 transforms the incoming request for the transaction and queues it. The transaction request will be retrieved from the above queue for application processing by the software modules in the application processing area 13.

[0230] After that, in the application processing area 13 ( Figure 4)Among them, the document reconciliation module 28 that provides information on the user's business (commercial) activities classifies the incoming information. The protocol module 19 registers and compares protocols, and checks the inclusion of protocols related to each transaction in specific scenarios. The transfer and acceptance certificate module 20 registers acceptance certificates and matches them with the protocols in which they may be included. The invoice module 21 registers invoices and matches them with the protocols in which they may be included. The payer's bank debit statement module 22 registers the fund debit statement from the payer's bank and matches it with the invoice, then generates a notice for the user (payee) and prepares to send it to the user. The payee's bank credit statement module 23 registers the fund credit statement from the payee's bank and matches it with the previous invoice. The template module 24 registers the published templates.

[0231] Transaction-related templates for scenarios or protocols can be stored on the network of the automated system for transaction management and can be provided according to the user's request. The service provider device of any user can publish transaction-related document templates in the CMD. The service provider of any user can request a set of transaction-related document templates and specified templates from the CMD.

[0232] The adjudication module 25 stores the adjudication and matches the adjudication with the issued invoices and related fund debit and credit statements. The redirection module 26 receives and registers the invoice redirection request. In the case of claims from users (payer and payee), the claims module 27 registers the claims and matches them with the transaction-related protocols or certificates related to them. All modules send the processing status to the queue manager module 31 via the communication channel for subsequent transmission of this data to the module (store and forward module) 16 that ensures the delivery of notifications and the document providing module 15.

[0233] The module (store and forward module) 16 that ensures the delivery of notifications receives the values to be added to the notification from the prompt generation module 30. The module (store and forward module) 16 that ensures the delivery of notifications notifies the user (payer) via the user's management device that the documents (especially invoices, statements, etc.) are ready and prepared to be sent and provides a prompt.

[0234] The transaction scenario generation device combines different documents and transactions within a transaction framework. The CMD centralized database stores information on templates for transaction scenarios and related preliminary prepared transaction-related protocols.

[0235] The user (payer) receives invoices (payment orders, charges) for purchases, services (commercial and government), and other electronic payments and initiates the payment of the received invoices. The electronic payment of the invoice completes this process, allowing the payer to pay remotely, eliminating the need to manually enter account details to generate a payment bill and the need for physical media (paper).

[0236] The following are the processes that occur in an automated system for transaction management ( Figure 5 ).

[0237] "Document release in CMD" 32 occurs through the information flow on the network of the automated system for transaction management; afterwards, the information flow "Delivery of notice of transaction release" 33 containing prompts is used, and the notice is delivered to the service provider device of the payee (recipient). Using the link received by the payee as part of the information flow "Transaction content passed to the recipient" 34, the user (payee) can obtain transaction-related information stored in CMD using the previously received prompts. The payee decides to agree or reject the transaction within the information flow "Response passed by the payee to CMD" 35. Next, the response is passed to the payee's service provider within the information flow "Response passed from the recipient to the service provider" 36 and to the payer's service provider within the information flow "Current transaction status passed from CMD to the initiator's service provider" 37.

[0238] The process of signing a transaction-related agreement is required only when all parties to the transaction decide to sign the agreement. If the user, as the payee, immediately issues a payment invoice to the payer without first signing an agreement, the process that does not require signing an agreement applies.

[0239] Transactions conducted in the automated system can be classified as "unsecured transactions" and "secured transactions" (secure), which require compliance confirmation by the control agency.

[0240] In the processes that occur in the automated system for transaction management, the user, as the payer, can use their management device to:

[0241] - Conclude / accept the payee (i.e., the supplier of goods, works, or services), especially subscribe to the delivery of invoices from the payee specified by the payer;

[0242] - Receive, accept, or reject transaction-related documents issued for such users (such as agreements, acceptance certificates, invoices, the payee's bank credit statements, and potential refunds, reconciliation reports, etc.);

[0243] - Request an extension and / or installment payment;

[0244] - Clearly permit direct debit of the payer's bank account based on the received invoice;

[0245] - Accept invoices for subsequent payment;

[0246] - Accept invoices for immediate payment at the time of payment initiation;

[0247] - Request a reconciliation report.

[0248] Using the management device, the user as the payer interacts with the following:

[0249] - The payer's service provider device (directly via the SP API protocol);

[0250] - The payer's bank management device (directly or via the payer's service provider device);

[0251] - The payee's management device (outside the network of the automated system for transaction management or indirectly via the payer's service provider device connected to the network).

[0252] Using the management device, the user as the payee can:

[0253] - Request the payer to activate / subscribe;

[0254] - Receive their profile data (proxy) from the subscribed payer,

[0255] - Publish documents (agreements, certificates, invoices, debit statements) for the subscribed payer;

[0256] - Issue invoices to the specified payer or "to the bearer" (without specifying the payer);

[0257] - Agree to the terms of an extension as required by the payer;

[0258] - Agree to installment payments as required by the payer;

[0259] - Request the status of the issued invoice based on specified conditions;

[0260] - Request a report and reconciliation for its invoices based on specified conditions.

[0261] Using the management device, the user acting as the payee interacts with the following:

[0262] - The payee's service provider device;

[0263] - The payee's bank management device (directly or via the payee's service provider device);

[0264] - The management device of the payer (outside the network of the automated system for transaction management or indirectly via the payer's service provider connected to the network).

[0265] For a user acting as a payer, the payer's bank provides via its management device:

[0266] - Remote access to the payer's bank account for cashless payment of invoices (payment orders) issued to it;

[0267] - Execute payments initiated by the payer directly or via its service provider through its management device;

[0268] - Strict authentication of the payer;

[0269] - Verify the payer's subscription;

[0270] - Execute the payment of an order initiated by the payer via its service provider;

[0271] - Based on the payer's authenticated subscription, execute the payment (direct debit) from the payer's account for a payment order initiated by the payer's service provider;

[0272] - Notify the payer's service provider of the completed payment.

[0273] Using the management device, the payer's bank interacts with the following:

[0274] - The management device of the payer (directly or via the payer's service provider using the SP API);

[0275] - The payer's service provider device (via the PIS / AIS API);

[0276] - A payment system or service external to the proposed automated system for transaction management.

[0277] For a user acting as a payee, the payee's bank provides via its management device:

[0278] - Accept funds paid according to the invoice issued by the payee and credit them to the payee's bank account;

[0279] - Verification (confirmation) of the payee's account;

[0280] - Generate statements, confirmations and other reports and notifications for the payee;

[0281] - Verify the payee by sending a request to the control agency and receiving a response to the request.

[0282] Using the management device, the payee's bank interacts with the following:

[0283] - The management device of the payee (directly or via the service provider device of the payee using the SP API);

[0284] - The service provider device of the payee (via the PIS / AIS API);

[0285] - The payment system / service (external to the proposed system).

[0286] As a control agency, the user interacts with the following via the management device:

[0287] - The device of the service provider (directly);

[0288] - The CMD (indirectly via the service provider device connected to the network for transaction management);

[0289] - The management device of the guarantee bank (indirectly via the device of the service provider connected to the network for transaction management);

[0290] - The management device of the payee (outside the network for transaction management or indirectly via the service provider device connected to the automation system network);

[0291] - The management device of the payer (outside the network for transaction management or indirectly via the service provider device connected to the network).

[0292] The bank payment agent (BPA) provides via its management device:

[0293] - Request and receive invoices from its service provider;

[0294] - Incorporate the invoice together with other user purchases into a preliminary receipt and into a separately generated preliminary receipt;

[0295] - Provide the final financial receipt to the user acting as the payer;

[0296] - Immediately notify the service provider of the user acting as the payer of the invoice payment status of a specific payer after the user acting as the payer completes the payment (whether the payment is in cash or by wire transfer);

[0297] - Transfer the funds received in the transaction to the final payee via the BPA bank based on the terms and conditions jointly determined with the payee according to the agreement.

[0298] - Prepare and transmit a detailed registration form (an account is recorded in the registration form each time the funds of the payer are transferred to the account of the BPA), as a detailed breakdown of the transfer of the aggregated amount to the BPA bank and the payee via the service provider.

[0299] Using the management device, the BPA interacts with the following:

[0300] - The payer (directly or via the Internet using the payer's management device as required by the SP API protocol);

[0301] - The BPA service provider device (via the SP API);

[0302] - The payer's bank management device (via the API or PIS / AIS API);

[0303] - The payee's bank management device (via the payment protocol);

[0304] - The BPA bank management device (via the API or SP API).

[0305] The user, acting as a guarantee bank, credits funds as a performance bond to a bank account opened for the user via its management device and transfers the guaranteed funds to the user after receiving confirmation from the control agency of compliance with the agreement terms (ruling).

[0306] Using its management device, the guarantee bank:

[0307] - As a result of the initiation of the guarantee transaction – receives the payer's funds from the payer's bank and stores them;

[0308] - Notifies the network of the automated system for transaction management to credit these funds to its account;

[0309] - Stores the funds received as a result of the initiation of the guarantee transaction, from the moment the received payer's funds are credited to the secure settlement in the guarantee transaction until, based on the ruling of the control agency on compliance with the agreement terms, the funds for the secure settlement are transferred to the payee's bank account of the payee's bank through the instruction of the network of the automated system for transaction management;

[0310] - Sends, through the instruction of the network of the automated system for transaction management, the funds received previously as part of the guarantee transaction and intended for future settlement to the payee's bank, which are received as a result of the ruling of the control agency on the payee's fulfillment of the guarantee transaction terms;

[0311] - Subsequently notifies the network of the automated system for transaction management to debit the amount from the payer's account and transfer it from the payer's bank account to the payee's bank.

[0312] Using its management device, the BPA bank:

[0313] - As a result of collecting payments from BPA or transferring funds to BPA's account – receive the payer's funds from the payer's bank and store them,

[0314] - Notify the network of the automated system for transaction management to credit these funds to BPA's account;

[0315] - Store the funds received as a result of the actions described by BPA in BPA's account;

[0316] - Upon BPA's instruction, send the previously received funds to the payee's account at the payee's bank;

[0317] - Subsequently notify the network of the automated system for transaction management to debit from BPA's account and transfer it to the payee's bank at the payee's bank account.

[0318] Using the management device, the guarantee bank interacts with the following:

[0319] - The user service provider (via the SP API);

[0320] - The management device of the control agency (only indirectly via the network of the automated system for transaction management).

[0321] Using its management device, BPA interacts with the following:

[0322] - The user service provider (via the SP API);

[0323] - The BPA management device (directly via a proprietary protocol and indirectly via the network of the automated system for transaction management).

[0324] Using its management device, the operations and clearing center (OPCC):

[0325] - Receive transfer instructions from the payer's bank, process and route them to the payee's bank, and process and send funds transfer instructions to the settlement system;

[0326] - Receive authentication requests from BPA's bank and route them to the payer's bank for authentication, receive the response and return it to BPA's bank;

[0327] - Receive payment instructions, process them in clearing, generate net positions and send them to the settlement system, and send reports to the user's bank.

[0328] Therefore, in view of the above, it should be noted that the process of signing an agreement related to a transaction is aimed at publishing it in the CMD of an automated system for transaction management and ensuring that the parties approve its terms. The agreement is signed between users (the parties to the agreement), and the minimum number of parties to the agreement is two, and the maximum number is not restricted. In addition, any agreement defines a comprehensive arrangement between the parties to the agreement. For example, one party to the agreement undertakes to supply some goods, while the other party undertakes to pay for them.

[0329] The above technical means for implementing the claimed invention can improve the reliability during transactions and accelerate information processing, as well as improve the quality of user services by eliminating non-payments due to "missing information" or "invoice not delivered", reduce the likelihood of payment errors, accelerate information processing and document flow. The above technical solution can also improve the reliability of transactions by improving the reconciliation quality and providing users with a report on the compliance of the agreement terms (reconciliation report). By reducing the load on the automated system for transaction management, the transaction processing speed in the system is increased.

[0330] The above benefits are confirmed by the following embodiments.

[0331] Embodiments of the present invention.

[0332] Embodiment 1. Registration and authentication

[0333] The management device of the user receives a notification of successful registration, and then the user is redirected to the home page of the application or the website of the service provider device 4. Next, the user uses their service provider's device 4 to send a request to the selected bank to perform authentication. The user's bank uses its management device 7 to authenticate the user in any convenient way. If the service provider 4 cannot independently authenticate the user, the service provider allows the user to select an authentication channel. Once the user has confirmed their data via the selected bank, the user bank returns an authentication token to the management device of the user (2 or 3) for subsequent access to CMD 1.

[0334] The authentication using the token occurs as follows. The user (payer) uses their management device 2 or 3 to request access to the server or protected resource (service provider device 4 or the management device 7 of the payer's bank) by providing the token. Access is granted or, conversely, denied based on the issued token. After that, the service provider 4 sends a request to CMD1 to release the user's (payer's) account. All data about the user and their preferences are stored in the centralized database of CMD, and each user is assigned a unique identifier.

[0335] Embodiment 2. Transactions between legal entities (B2B transactions):

[0336] 1. The supplier supplies products to supermarkets, restaurants, and cafes.

[0337] 2. Supply computer equipment to companies specializing in computer assembly.

[0338] 3. Supply raw materials for production to factories and power plants.

[0339] 4. Deliver cars to car dealerships.

[0340] 5. Supply cosmetics, household chemicals, clothing, shoes, etc. to specialty stores.

[0341] 6. Make payments for construction, cleaning, security, maintenance, and goods transportation services.

[0342] 7. Pay insurance premiums.

[0343] Using the B2B transaction invoice service will make it easier for all parties to issue and pay invoices, and the reliability of B2B will also be improved by implementing a reconciliation mechanism in the automated system for transaction management.

[0344] Example 3. Transactions between legal entities and individuals (C2B transactions).

[0345] All parties interact online using the interface (mobile application, website) provided by the payee.

[0346] 1. Online shopping

[0347] Deliver food, groceries, and purchase clothing, household appliances, shoes, furniture, cosmetics, flowers, tools, jewelry, equipment, auto parts, home supplies, books.

[0348] 2. Make payments for the services of cleaning companies, lawyers, tutors, stevedores, and goods transportation.

[0349] Transactions of immediate delivery of goods between legal entities and individuals:

[0350] 1. Purchase tickets for concerts, theaters, cinemas, sports events, and plane tickets.

[0351] 2. Hotel reservations.

[0352] 3. Purchase travel packages.

[0353] 4. Purchase software.

[0354] 5. Purchase insurance.

[0355] 6. Pay taxes, duties, and fines.

[0356] A convenient mechanism for regular invoicing of subscription-related transactions:

[0357] 1. Recharge the personal account with the service operator.

[0358] 2. Toll road.

[0359] 3. Payment for subscribed music and video services.

[0360] 4. Payment for regular grocery delivery, such as weekly meal box delivery.

[0361] 5. Payment for parking fees.

[0362] 6. Payment for rent.

[0363] 7. Payment for gym, swimming pool, fitness club memberships.

[0364] Gift (one party provides a donation to another party for free), for example, charitable donation.

[0365] Tracking charitable donations is an extremely difficult task for the government. Transaction support services simplify this task by providing an invoice tracking mechanism and a convenient donation method, involving the provision of a QR code or account link by the charitable organization to the donor. The donor scans the QR code or clicks the link to make a donation. There is no form to fill out.

[0366] Invoice for offline transactions:

[0367] 1. Purchase food in the cafeteria, café, restaurant, fast food restaurant.

[0368] 1. Buy groceries in the supermarket.

[0369] 3. Purchase jewelry, household items, fishing supplies, medicines, flowers, construction supplies, furniture, plumbing equipment, household appliances in the store.

[0370] During such transactions, the interaction occurs offline, for example, in the store. Currently, if the evidence of the transaction (cash receipt) is lost, there is a problem of filing a claim with the goods or service provider. Although the law stipulates that a refund can be made if the receipt is lost, in practice, the buyer faces many difficulties. Using the invoice mechanism and transaction support services will simplify the claim against the seller because the buyer will have an electronic document confirming the payment.

[0371] Payment for housing and utility services.

[0372] The existing payment mechanism for housing and utility services is inconvenient for both property management companies and service consumers. A large number of property management companies issue invoices, making the situation more chaotic. Transaction support services provide a convenient invoice payment and receipt mechanism for the payer, including batch payment (all invoices from the property management company can be paid with one click), and also provide a convenient invoice delivery and reconciliation mechanism for the providers of housing and utility services.

[0373] Example 4. Transactions between individuals (P2P payments).

[0374] This type of transaction provides interaction between individuals. These transactions are confidential to the government; it cannot monitor them nor provide legal protection for the parties. Transaction support services will help eliminate these disadvantages, and, while strengthening the government's control over P2P transactions, will also provide a convenient payment and invoicing mechanism in a timely manner.

[0375] Examples of such transactions may include:

[0376] 1. Buying second-hand goods via an online advertising service, for example.

[0377] 2. Paying for the services of private tutors, builders, movers, plumbers, computer repairmen.

[0378] 3. Paying rent.

[0379] 4. Paying off debts between individuals.

[0380] Example 5. Transactions between users with the participation of the OPCC ( Figure 6 ).

[0381] The originator of the funds transfer can be a user acting as the payer or payee.

[0382] The Operational and Payment Clearing Center (OPCC), via its management equipment:

[0383] - Receives a funds transfer request from the bank management equipment of at least one user and processes it;

[0384] - Identifies the payees and sends requests to them;

[0385] - Receives the response to the request and matches it with the original request;

[0386] - Receives a direct payment order (claim) and sends it for settlement;

[0387] - Performs settlement on payment orders (claims) not accepted over the counter;

[0388] - Based on the settlement results, generates a net position registration form for direct transfers between banks and a reconciliation report for users, which contains the basic components of each net position;

[0389] - Sends the net position registration form to the settlement bank of the payment system or an instruction for a funds transfer for a separate transaction;

[0390] - Sends a reconciliation report or a notice of completed settlement to the banks of the users participating in the funds transfer.

[0391] Example 6 of the template scenario of a protocol in the form of a direct cycle diagram is as Figure 7 shown. It can be seen that starting from state (1) "Protocol", according to the template, the scenario can transition to state (3) "Invoice" or (6) "Delivery". This scenario example stipulates that from state (6) "Delivery", it can only transition to the next state (2) "Acceptance Certificate", and from state (2), it can only transition to state (3) "Invoice". According to this scenario, there are two paths:

[0392] Through the consecutive states (4) "Debit Statement" and (5) "Credit Statement", the process will enter state (6) "Delivery", from where it will transition to state (2) "Acceptance Certificate" and then to state (3) "Invoice", after which the process will enter state (4) "Debit Statement" again. And this will be repeated as needed multiple times (the number of cycles will depend on the number of deliveries);

[0393] Or through the consecutive states (4) "Debit Statement" and (5) "Credit Statement", the process will enter state (3) "Invoice", after which the process will enter state (4) "Debit Statement" again. And this will be repeated as needed multiple times (depending on the number of payments made for an acceptance certificate of a delivery; this is an example of installment payments based on the acceptance certificate)

[0394] Example 7 of the scenario template of a set of related protocols in the form of a direct cycle diagram is as Figure 8 shown.

[0395] Differing from Figure 7 is that in this direct cycle diagram, there is an edge connecting state (5) "Debit Statement" and state (1) "Protocol", which means that the transition from one protocol to the next is provided by a complex scenario (composed of many protocols).

[0396] Example 8 includes calculating the number of requests of permitted payers using a prompt identifier.

[0397] A set of parameters for user classification set by the CMD is used to determine the category of the user.

[0398] The parameters stored in the centralized database in the CMD are used to set the parameters according to which the user is classified.

[0399] Specifically, these parameters include the following, but are not limited to the following:

[0400] - Whether the user is an individual or a legal entity;

[0401] - The type and quantity of activities performed by users (e.g., the number of requests from individuals registered as self-employed will exceed the number of requests provided to individuals but will be less than the number of requests provided to legal entities such as property management companies);

[0402] - The status of the legal entity assigned at registration (either only the payee or the VIP payee);

[0403] - Additionally, it includes commercial classification terms (e.g., an increased fee for the number of requests for a specific type of document for one prompt identifier).

[0404] Determine at least two categories of users; then, this data is sent to the prompt generation module. For each user category in the CMD, the number of allowed requests is set through prompts.

[0405] For service providers of individuals acting as payers, the system can set a limit on the number of free requests (e.g., from 1 to 3); if this limit is exceeded, the user's service provider will be charged at the rate established by the CMD. The number of requests for service providers of legal entities acting as payees is set in the same way (e.g., from 1 to 3). For service providers of VIP payees, the number of free requests can be increased, e.g., up to 5.

[0406] This limitation is caused by the following situation: The CMD should notify any service provider of any release or any modification of any document at any time. The rules of the system established by the CMD require service providers to independently remember and provide information about the document to any type of user upon request without contacting the CMD because they are the owners of the up-to-date information. If any update occurs on the CMD side, then, as established, the CMD will notify the service provider again, and the service provider will update the information in its system by contacting the CMD, after which it will again have the up-to-date information to provide to users without direct interaction with the CMD. The methods and practices described in this article are internationally known as "caching"; the service provider acts as a "cache" here, i.e., an intermediate information buffer for quick access upon user request.

Claims

1. An automated system for information exchange in transaction support services, comprising a centralized management device for information exchange in transaction support services configured to provide support during transactions and management devices of at least two users equipped with user interfaces, using a communication channel to ensure access of the users' management devices to the centralized management device for the purpose of information exchange in transaction support services via at least one service provider device, wherein the centralized management device for information exchange in transaction support services is a hardware and software system configured for automated transaction management and includes a synchronous processing area configured to generate a quick response to user requests and submit the response to the user, a compatibility area configured to queue transaction-related requests, and an application processing area configured to perform synchronous and asynchronous processing of user requests and logical control of information about transactions from users. Among them, The centralized management device for information exchange in transaction support services contains control means configured to limit the number of requests from users for transaction-related information sent via the communication channel to the centralized management device for information exchange in transaction support services to a set number of times.

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

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

4. The system for transaction management according to claim 1, wherein, The communication device of the user equipped with a user interface for indirect access (via a service provider) to the centralized management device is used as the management device of the user.

5. The system for transaction management according to claim 1, comprising at least one intermediate bank management device configured to act as a service provider and connected to the centralized management device via a communication channel.

6. The system for transaction management according to claim 5, wherein, The intermediate bank management device is connected to the centralized management device via at least one service provider device using a communication channel.

7. The system for transaction management according to claim 1, comprising at least one control agency management device configured to act as a service provider and connected to the centralized management device via a communication channel.

8. The transaction management system according to claim 7, wherein, The control agency management device is connected to the centralized management device via at least one service provider device using a communication channel.

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

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

11. The system for transaction management according to claim 1, comprising at least one operational clearing center management device connected via a communication channel to the bank management device and the intermediate bank management device of at least one user.

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

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

14. The system for transaction management according to claim 1, wherein, Use a prompt generation module and a document providing module for checking the number of prompt usages as control means designed to limit the number of requests by users for transaction-related information sent via a communication channel to a set number of times.

15. A centralized management device for information exchange in a transaction support service, comprising a centralized database configured to store information about user registration, credentials, and preferences, and a transaction management automation device. Among them, The transaction management automation device includes: At least a device for receiving and submitting transaction-related documents to users, including a document management module, a document providing module, a module for delivering assurance notifications and download links (storage and forwarding module), a prompt generation module, and a queue manager module, where the prompt generation module and the document providing module form control means designed to limit the number of requests by users for transaction-related information, and the queue manager module queues transaction-related requests during asynchronous request processing; At least a device for publishing transaction-related documents, at least a device for classifying transaction-related documents, and at least a device for generating transaction scenarios, where the specified devices are for synchronous and asynchronous processing of user requests for transactions.

16. The centralized management device according to claim 15, wherein, The device for publishing transaction-related documents includes a user profile module and a service subscription module.

17. The centralized management device according to claim 15, wherein, The device for generating transaction scenarios includes a protocol module, a transmission and acceptance certificate module, an invoice module, a bank debit statement module for the payer, a bank credit statement module for the payee, a template module, an adjudication module, a redirection module, a claim module, and a report generation module.

18. The centralized management device according to claim 15, wherein, The device for classifying transactions includes a document reconciliation module.

19. The centralized management device according to any one of claims 16-18, wherein, All modules included in the device for publishing transaction-related documents, the device for generating transaction scenarios, and the device for classifying transactions include filters configured to match documents related to transactions and included in the queue manager module with each other.

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

21. The centralized management device according to claim 15, wherein, The document management module is configured to perform parsing and verification.

22. The centralized management device according to claim 16, wherein, The device for publishing transaction-related documents is configured to first publish complete information about a transaction in the automation system according to claim 1 and share a link to the previously published information.

23. The centralized management device according to claim 16, wherein, The device for publishing transaction-related documents is configured to receive and provide information about a transaction requested by a user by using a unique prompt.

24. The centralized management device according to claim 16, wherein, The device for publishing transaction-related documents is configured to generate and provide a report about a transaction to a user.

25. The centralized management device according to claim 1, wherein, The centralized database includes unique identifiers related to each user and the service provider of at least one user.

26. An automated method for information exchange in a transaction support service, including providing access to a centralized management device for at least two users via at least one service provider device over a communication channel; Register users and store the access credentials of each user in the centralized database. The method includes: Creating a user account; Providing access to one or at least two service providers for each user simultaneously; Authenticating the user via the user's service provider; Publishing transaction-related documents on the network of the automation system for transaction management. Generate a user request for conducting a transaction on the user's management device; Classify the incoming information on the centralized management device via a transaction classification device; Generate a transaction on the centralized management device, and the centralized database of the centralized management device stores transaction scenario templates for approving, confirming, and conducting various transactions; Register, compare, and track the protocols related to the transaction; Control the number of requests for transaction-related documents received via the communication channel and the access of the user's device to transaction-related information via prompts.

27. The automated method for transaction management according to claim 26, including publishing the user account and transaction-related information on the centralized management device after the user is authenticated by the user's service provider device.

28. The automated method for transaction management according to claim 26, including storing data on user preferences in the centralized database of the centralized management device.

29. The automated method for transaction management according to claim 26, including generating unique identifiers for each transaction and each document in the centralized management device.

30. The automated method for transaction management according to claim 26, including providing access to transaction-related information according to the user request.

31. The automated method for transaction management according to claim 26, including providing an account editing device for the user in the centralized management device.

32. The automated method for transaction management according to claim 26, including using a filter of the modules included in the transaction-related document publishing device, transaction scenario generating device, and transaction classification device according to any one of claims 15-17 to match the documents related to the transaction and included in the queue manager module with each other.

33. The automated method for transaction management according to claim 26, including conducting a guaranteed transaction after the control agency management device confirms that the user meets the transaction conditions.