RU2794054C2 - Automated system for independent confirmation of transactions - Google Patents

Abstract

FIELD: means of identification.

SUBSTANCE: invention in particular relates to methods, systems and devices for multi-factor independent confirmation of transactions. The required technical result, which consists in reducing vulnerability and increasing the reliability and security of using remote banking systems by corporations, is achieved in a system containing a conversion and verification unit, a client treasury operations management unit, the first and second transaction confirmation units, a data update unit between databases, a bank operations control unit and a unit for the formation and sending of customer payments.

EFFECT: reducing vulnerability and increasing the reliability and security of using remote banking systems by corporations.

1 cl, 8 dwg

Description

The invention relates to means of identification, in particular to methods, systems and devices for multi-factor independent confirmation of transactions, made in the form of specialized computing devices.

The proposed automated system for independent confirmation of transactions (hereinafter referred to as "ISPT") is used as a separate service and is designed to confirm that the document was (1) sent to the bank and / or (2) was accepted by the bank exactly in the form in which it was generated in automated information system for enterprise resource planning, which provides management of treasury operations, payment process and exchange with banks (hereinafter referred to as the "ERP system"), and sent by the client to the bank or generated in the automated banking system (hereinafter referred to as the "ABS") of the bank and sent to the client. SNPT is able to confirm any electronic documents - statements, payment orders, currency control documents, letters from the bank, etc.

A method and device for confirming transactions are known [RU 2417444, C1, G06Q 20/00, 04/27/2011], according to which the control device sends request messages containing transaction data to the mobile device, which can send the control device a confirmation message containing a confirmation code, moreover , the control device and/or the mobile device comprise one or more digital storage devices in which a security application is stored for encrypting and digitally signing the request message and/or the confirmation message, respectively, before sending them.

The disadvantage of this technical solution is a relatively narrow scope, determined by mobile devices for conducting transactions, and a relatively high vulnerability.

There is also a method for performing a secure electronic transaction [RU 2397540, C1, G06F 21/20, 20.08.2010], in which the user authenticates himself to a portable data carrier, moreover, the portable data carrier sends an authentication confirmation to the terminal, and then during electronic transaction generates and transmits to the terminal a message guaranteeing the user's authenticity, wherein the portable storage medium generates authentication quality information indicating the authentication method used to authenticate the user, when one type of authentication quality information indicates a biometric authentication method, and the other type of information about as authentication indicates an authentication method based on knowledge of certain information, the specified authentication quality information is added to a message guaranteeing the user's authenticity and taken into account when making an electronic transaction.

From the same technical solution, a system for performing a secure electronic transaction is known, containing a portable data carrier for performing a security and information protection operation in the course of a secure electronic transaction, when the user authenticates himself in front of the portable data carrier, moreover, the portable data carrier transmits to the terminal a user authentication confirmation , and then, in the course of an electronic transaction, generates and transmits to the terminal a message guaranteeing the user's authenticity, while it is configured to generate authentication quality information indicating the authentication method used to authenticate the user, and add this information to the message guaranteeing the user's authenticity, and , one type of authentication quality information indicates a biometric authentication method, and another type of authentication quality information indicates an authentication method based on knowledge of certain information.

The disadvantage of this technical solution is also a relatively high vulnerability.

The closest in technical essence and functions to the proposed one is an automatic system for checking the consent of the party with the authority to make a transaction, to make a transaction by the party initiating the transaction [RU 2388053, C1, G06Q 20/00, 27.04.2010], including the first base data that has the ability to accumulate information about the transaction, including the identifier of the party initiating the transaction, the data store, which includes the first database and at least one second database and placed in it predefined interconnected identifier of the party initiating transaction, and the subscriber address of the subscriber device of the party authorized to make the transaction, at least one subscriber device of the automatically switched telephone network, having the ability to establish a connection with the subscriber device of the party authorized to make the transaction, transmit the subscriber number of the calling subscriber and receive the signal hang up and answer, moreover, said subscriber number corresponds to the subscriber device of the side verifying the transaction, and the subscriber device of the party having the authority to complete the transaction has a means of reporting information about the caller and sending a clear signal and a response signal, at least one reader transaction initiating party identifier and a digital transaction processing means connected to the transaction initiating party identifier reading device and including said data store and said subscriber unit of an automatically switched telephone network, wherein said digital transaction processing means is able, by means of said data store to accumulate information about the transaction in the mentioned first database and determine the subscriber address of the party having the authority to commit the transaction by the identifier of the party initiating the transaction, and the ability, using the mentioned subscriber device of the automatic switched telephone network, to initiate a connection with the subscriber device of the party having transaction authority, transmit the subscriber address of the caller, and receive the clear signal and answer tone, and the user device of the party authorized to make the transaction includes a caller information reporting means and has the ability to send the clear signal and the answer signal.

The disadvantage of the closest technical solution is a relatively high vulnerability, predetermined by the following factors:

- hacking the client's ERP system can lead to the substitution of bank details (the influence of the factor is limited by the capabilities of the particular type of ERP system used);

- access to the system is carried out by employees of the treasury (who, as a rule, do not have the right to sign in a bank card, but who, in fact, put down the signatures of authorized persons in the client-bank), who have the opportunity to upload not an agreed file with payments, but their own , and can also make any changes to the test or xm1 file with data that was uploaded from the ERP system;

- often in corporations, data is not loaded into the client-bank directly from the ERP system that contains the agreed payments, but from another system (for example, an accounting system), or transmitted through files that can be changed, or entered manually by the user into the client- bank, which does not allow performing any automated checks and eliminating the risk of a technical error of a teller or accountant;

- the client is responsible for all information that is uploaded to the client-bank;

- systems accessed via the Internet can be attacked by hackers using a number of technologies specially developed for this purpose;

- the process of transferring (uploading and downloading) payments from the ERP system to the client-bank is carried out through a file located on the client's server or network drive, which creates the possibility of its substitution or modification, and often the file name has a standard name;

- if the exchange between the ERP-system in the client-bank is carried out using a file, there is a risk that a conversion can be carried out that distorts the content of the document;

- the log of uploading and downloading data between the ERP system in the client-bank is not saved;

- encryption of the data transmission channel between the ERP-system in the client-bank is not provided.

- documents are sometimes transferred to the system on the client side in an unsigned form, which creates a risk of data spoofing after they are uploaded from the client's ERP system due to an internal human factor;

- sometimes, it is required to convert documents into the format of an electronic document management system, during which a conversion can be carried out that distorts the content of the document;

- the process of transferring (uploading and downloading) payments from the ERP system to the electronic document management system is carried out through a file located on the client's server or network drive, which creates the possibility of its substitution or modification;

- as a rule, the system is not responsible for the possible loss or distortion of information that is transmitted over the exchange channel;

- Encryption of the data transmission channel between the ERP system and the electronic document management system is not provided.

- hacking the client's ERP system can lead to the substitution of bank details (the influence of the factor is limited by the capabilities of the particular type of ERP system used);

- the bank is not responsible for the possible risks of modifying or replacing the file from the documents after it is uploaded from the client's ERP system and before it is received by the bank;

- the process of transferring (uploading and downloading) payments from the ERP system to an individual host-to-host gateway is carried out through a file located on the client's server or network drive, which creates the possibility of its substitution or modification;

- as a rule, the system is not responsible for the possible loss or distortion of information that is transmitted over the exchange channel;

- as a rule, encryption of the data transmission channel from the ERP system to the individual host-to-host gateway is not provided.

The problem that is solved in the invention is the creation of an automated system for independent confirmation of transactions, which has a lower vulnerability and thus provides a higher level of reliability and security when using remote banking systems by corporations.

The required technical result is to reduce the vulnerability and increase the reliability and security of the use of remote banking systems by corporations.

The task is solved, and the required technical result is achieved in a system containing a conversion and verification unit, a control unit for the client's treasury operations, the first and second inputs-outputs of which are connected to the first and second inputs-outputs of the conversion and verification unit, respectively, the first transaction confirmation unit , the first, second, third and fourth inputs-outputs of which are connected to the third, fourth, fifth and sixth inputs-outputs of the client's treasury operations control unit, respectively, the corporate banking control unit, the first and second inputs-outputs of which are connected to the seventh and eighth inputs-outputs of the client's treasury operations control block, respectively, and the third and fourth inputs-outputs of which are connected to the fifth and sixth inputs-outputs of the first transaction confirmation block, respectively, the block for updating data between databases, the first and second inputs-outputs of which are connected to the seventh and the eighth inputs-outputs of the first transaction confirmation block, respectively, the bank operations control block, the first and second inputs-outputs of which are connected to the fifth and sixth inputs-outputs of the corporation's banking operations control block, respectively, the block for generating and sending client payments, the first input - the output of which is connected to the ninth input-output of the client's treasury operations control unit, and the second input-output is connected to the third input-output of the bank's operations control unit, as well as the second transaction confirmation unit, the first and second inputs-outputs of which are connected to the third and fourth inputs - outputs of the data update unit between the bases, and the third, fourth, fifth, sixth and seventh inputs-outputs of which are connected to the fourth, fifth, sixth, seventh and eighth inputs-outputs of the bank operations control unit, respectively.

The drawing shows:

in fig. 1 is a functional diagram of an automated system for independent confirmation of transactions;

in fig. 2 - functional diagram of the conversion and verification unit;

in fig. 3 - functional diagram of the client's treasury operations control unit;

in fig. 4 is a functional diagram of the first transaction confirmation block;

in fig. 5 is a functional diagram of a corporate bank management unit;

in fig. 6 is a functional diagram of a block for managing bank operations;

in fig. 7 - functional diagram of the block for generating and sending customer payments;

in fig. 8 is a functional diagram of the second transaction confirmation block.

The automated system for independent confirmation of transactions (Fig. 1) contains a conversion and verification unit 1, a client treasury operations control unit 2, the first and second inputs and outputs of which are connected to the first and second inputs and outputs of the conversion and verification unit 1, respectively, the first block 3 confirmation of transactions, the first, second, third and fourth inputs-outputs of which are connected to the third, fourth, fifth and sixth inputs-outputs of the client's treasury operations control unit 2, respectively, the corporate banking control unit 4, the first and second inputs-outputs of which are connected with the seventh and eighth inputs-outputs of the block 2 managing the treasury operations of the client, respectively, and the third and fourth inputs-outputs of which are connected to the fifth and sixth inputs-outputs of the first block 3 transaction confirmation, respectively.

The automated system for independent confirmation of transactions (Fig. 1) also contains a block 5 for updating data between databases, the first and second inputs-outputs of which are connected to the seventh and eighth inputs-outputs of the first block 3 of transaction confirmation, respectively, the block 6 for managing bank operations, the first and the second inputs-outputs of which are connected to the fifth and sixth inputs-outputs of the block 4 for managing the banking operations of the corporation, respectively, the block 7 for generating and sending payments to the client, the first input-output of which is connected to the ninth input-output of the block 2 for managing the client's treasury operations, and the second the input-output is connected to the third input-output of the bank operations control block 6, as well as the second transaction confirmation block 8, the first and second inputs-outputs of which are connected to the third and fourth inputs-outputs of the data update block 5 between databases, and the third, fourth, the fifth, sixth and seventh inputs-outputs of which are connected to the fourth, fifth, sixth, seventh and eighth inputs-outputs of the block 6 control bank operations, respectively.

The conversion and verification block 1 (Fig. 2) contains a block 9 of requests for converting data from ERP to a third-party application, a block 10 for converting payment documents into a bank format into a third-party application, a block 11 for storing files with a payment document in a bank format, a block for loading into ERP payment documents in the format of the bank in the converted format, a block for verifying the filling in of the document fields.

Block 2 for managing the client's treasury operations (Fig. 3) contains a block 14 for transferring payment documents for payment, a block 15 for transferring payment documents for converting to a bank format, a block 16 for converting payment documents into a bank format in the ERP system itself, a block 17 for uploading payments for verification compliance, block 18 for confirming the readiness of the document for payment, block 19 for signing a payment document, block 20 for storing files with payment documents in bank format, block 21 for uploading a bank statement to the ERP system, block 22 for uploading payments to the client-bank.

The first transaction confirmation block 3 (Fig. 4) contains a block 23 for accenting or rejecting a document from the bank, a block 24 for checking the hash in the database with the one calculated from the payment document, a block 25 for calculating the hash for confirming and checking with the database data, and a block 26 for assigning a document digest ID (DD), block 27 for calculating a hash based on DD and transaction ID, block 28 for recording transactions in SNTP, block 29 for SNTP (blockchain), block 30 for returning ID DD to ERP for acceptance in a bank, block 31 for checking the conformity of converted documents uploaded earlier from ERP, block 32 of sending the conformity status of documents.

The block 4 for managing banking operations of the corporation (Fig. 5) contains a block 33 SNTP (blockchain), a block 34 for additional verification of documents before sending, a block 35 for sending a document to the bank, a block 36 for transmitting a document digest and ID DD to the SNTP, a block 37 for transmitting a payment document through the gateway (host-to-host), block 38 download bank statement with ID DD.

The block 6 for managing bank operations (Fig. 6) contains a block 39 for loading a payment document to a bank, a block 40 for verifying the correctness of a signature on a payment document, a block 41 for checking a payment document for filling in fields, a block 42 for requesting payment acceptance in SNTP, a block 43 for transmitting a payment document through the client-bank, block 44 for transmitting the payment digest and ID DD to the SNTP, block 45 for learning the answer about the possibility of executing the payment acceptance-refusal, block 46 for refusing to execute the document, block 47 for accepting the bank's payment document, block 48 for generating and sending the processing status to the client payment document, block 49 for generating an extract, block 50 for sending an extract to customers with ID DD.

Block 7 of the formation and sending of payments to the client (Fig. 7) contains a block 51 of loading payment orders to the client-bank, a block 52 of signing and sending payments.

The second transaction confirmation block 8 (Fig. 8) contains the SNTP database 53, the hash calculation block 54 for confirming and verifying the database data, the document acceptance or rejection block 55, the hash verification block 56 in the database with that calculated from the payment document, the ID assignment block 57 document digest, hash calculation block 58 based on document DD and transaction ID, transaction record block 59 in SNTP, block 60 for returning DD ID to the bank's ABS for customer acceptance.

An automated system for independent confirmation of transactions is used as follows.

All elements of blocks 1-8 perform the functions reflected in their names.

The database (DB) of the system is decentralized and available to all authorized participants in the system, both clients and banks. A participant in the system must have a complete copy of the database with all transactions made in the system for the entire time of the system's existence. Transactions themselves do not carry any confidential information. According to the data contained in the transaction, it will be impossible for a third party to determine either the type of document, or the composition of the document fields, or the values of these fields. In the simplest form of implementation, transactions can contain only the transaction identifier, the hash of the document digest (DD) itself, and the electronic digital signature (EDS) of the system participant.

Connection to the system should not be free and regulated in order to exclude the presence of third-party participants. It is assumed that the system will require mandatory authorization of participants both to receive data, i.e. synchronization of the database, and for sending new data to the system, i.e. creating new transaction records. Authorization in the system can be performed, for example, using certificates issued to system participants by a single Certification Authority that will work within the system.

It is desirable that the role of the Certification Authority be performed by a third-party organization with a high level of trust, for example, the Central Bank of the Russian Federation.

Access to the system can be limited at the level of communication channels. For greater reliability, the system can operate in a closed communication loop created by channel equipment certified in the Russian Federation. Thus, connecting to the system, receiving data from it and writing new data to it by unauthorized participants will become impossible.

Also, at the design stage, general security requirements should be agreed with authorized participants - traffic encryption, encryption of a local copy of the database, the need to sign EDS transactions, and the choice of a hashing algorithm.

Sending a document from the ERP system.

The ERP system or the user can directly send documents using any available communication channel. Immediately before sending the document, the ERP system sends the DD to the SNPT. The DD of each of the documents supported by the system is known to all participants in the SNPT system. The SNPT creates a transaction ID, a hash based on the DD, and writes to the blockchain data block. If all operations were successful, then the SNPT returns the ID of the saved transaction to the ERP system. Next, the ERP system or the user directly sends the document to the bank via the desired communication channel, together with the SNPT system identifier of this document.

Receipt of the document by the bank.

The bank can use the SNPT as an additional service to confirm that the document received by it was accepted exactly in the form in which it was sent by the client.

To do this, after the document is registered in the bank's ABS, at one of the verification stages, the ABS refers to the SNPT, passing it the document identifier and DD.

Similarly, the process of checking by the client of a document sent by the bank, for example, an extract, is organized. Provided that the bank, at the time of sending the document, did the necessary actions in the SNPT on its side. Only instead of the ABS, the client's ERP system will work.

Document digest and generating a hash of the document digest.

In order to confirm the integrity of the document and at the same time not transmit confidential information, it is supposed to use hashes of the document digest in the SNPT. Hashing allows you to convert an input string of arbitrary length into a fixed-length output string in such a way that, using certain algorithms, the output string will be unique and unchanged for each input data set. Consider an example of sending a payment order (an arbitrary DD is used in the example.

The ERP system sends DD:

<PmtRub>

<PmtInfNm>Client 1 </PmtInfNm>

<PmtInfOrgId>7724792919</PmtInfOrgId>

<PmtInfDbtrAcct>407028118222110700814</PmtInfDbtrAcct>

<PmtInfFinInstnId>044525593</PmtInfFinInstnId>

<PmtInfFinInstnIdNm>Bank</PmtInfFinInstnIdNm>

<PmtInfInstdAmt>88000.0000</PmtInflnstdAmt>

<PmtInfRltdDt>06/09/2018</PmtInfRltdDt>

</PmtRub>

SNPT generates a transaction ID (an arbitrary transaction ID is used in the example:

77da712a8a0c4f3d9211673931646d7d

Further, based on the data from the DD and the transaction ID, the SNPT creates a hash (in the example, the md5 hashing algorithm is used:

md5("Client17724792919407028118222110700814044525593Bank88000.0000

06/09/201877da712a8a0c4f3d9211673931646d7d")

We get the hash:

03939f856260535c2f9986bfc90fbeab

In order for any of the parties to be able to check the correctness and integrity of the received document, it sends the digest of the document and its identifier to the SNPT. Next, the SNPT searches for and finds the required document, and based on the hashing algorithm, the hash is calculated and verified with the hash stored in the SNPT. If the hash values are identical, then the document is received exactly in the form in which it was transmitted by the system by the source. If the hashes differ, then the document was modified during transmission.

The basis for the development of digests.

For each type of document, a special digest was used, which contains all the details of the document, which are listed in the "Regulations on the rules for the transfer of funds" (approved by the Bank of Russia on June 19, 2012 N 383-P) or other regulatory acts.

Thus, thanks to the improvement of the known device, the required technical result is achieved, which consists in reducing vulnerability and increasing the reliability and security of using remote banking systems by corporations.

Claims (1)

An automated system for independent transaction confirmation, comprising a conversion and verification unit, a client treasury operations control unit, the first and second inputs/outputs of which are connected to the first and second inputs/outputs of the conversion and verification unit, respectively, the first transaction confirmation unit, the first, second, third and the fourth input-output of which is connected to the third, fourth, fifth and sixth input-output of the client's treasury operations control unit, respectively; respectively, and the third and fourth inputs-outputs of which are connected to the fifth and sixth inputs-outputs of the first transaction confirmation block, respectively, the data update block between the bases, the first and second inputs-outputs of which are connected to the seventh and eighth inputs-outputs of the first transaction confirmation block, respectively , bank operations control unit, the first and second inputs-outputs of which are connected to the fifth and sixth inputs-outputs of the corporate banking operations control unit, respectively, the client payment generation and sending unit, the first input-output of which is connected to the ninth input-output of the treasury operations control unit client, and the second input-output is connected to the third input-output of the bank operations control block, as well as the second transaction confirmation block, the first and second inputs-outputs of which are connected to the third and fourth inputs-outputs of the data update block between databases, and the third, fourth , the fifth, sixth and seventh inputs-outputs of which are connected to the fourth, fifth, sixth, seventh and eighth inputs-outputs of the bank operations control unit, respectively.

Images