CH717898A1 - Server for processing financial transactions. - Google Patents

Abstract

A transaction processing server (101) is adapted for connection to a computer network storing a distributed ledger (150) comprising a plurality of data blocks which are replicated, shared and synchronized between multiple computers of the computer network. The server (101) includes a linking module (102) that is set up to receive a public key from a certification authority (200) and to generate and store fingerprint data representing the public key in one of the data blocks of the distributed ledger (150). The server (101) further comprises an authorization module (103) which is set up to store access authorizations linked to identity certificates issued by the certification authority (200) in one of the data blocks of the distributed ledger (150). It further comprises an input module (104) which is set up to receive a transaction request from a requesting body (10), the request being signed with the private key of the requesting body (10), which is signed with a public key from one of the certification bodies ( 200) issued identity certificate of the requesting body (10) is linked. The server (10) further comprises a verification module (105) that is set up to verify an identity of the requesting body (10), based on the request of the requesting body (10), the stored fingerprint data and the stored access authorizations, and a recording module ( 106) that is set up to record a transaction that corresponds to the transaction request in a data block of the distributed ledger (150), provided that the identity has been successfully verified by the verification module (105).

Description

technical field

The invention relates to a server for processing transactions, the server being designed for connection to a computer network which stores a distributed ledger which comprises a plurality of data blocks which are replicated, shared and synchronized between a number of computers in the computer network. The invention further relates to a corresponding computer-aided system and a method for processing transactions.

State of the art

Traditionally, securities transactions such. B. those related to bills of exchange based on physical documents settled. However, this is very cumbersome, especially in international traffic or in short-term transactions. Accordingly, there is a need to carry out such transactions purely electronically. In doing so, strict financial regulations must be observed - in addition, in such transactions it is often crucial that the parties involved reliably identify themselves to each other.

[0003] Numerous methods for the electronic processing of financial transactions are known. They can usually be divided into two groups: Procedures in the first group use a service provider (trusted third party) who is classified as trustworthy by all parties involved and who handles the transaction on behalf of the parties. Methods from the second group are based on what is known as distributed ledger technology (DLT), in which the data is stored in a computer network, specifically in a plurality of data blocks which are replicated, shared and synchronized between a number of computers in the computer network. The data blocks are linked to each other in such a way that new transactions within the network are always tracked and, in the case of divergent data content, a consensus is reached as to which data is to be regarded as correct. Security is also created through the use of cryptographic processes and electronic signatures. Blockchain technology is an example of DLT.

DLT applications typically have i.a. with the aim of making the use of a TTP unnecessary. DLT applications are also very well suited for processing anonymous transactions. However, it is often not easy to meet identification requirements within this framework.

Presentation of the invention

The object of the invention is to create a server belonging to the technical field mentioned at the outset, which enables transactions to be processed efficiently with reliable identification of the transaction partners.

The solution to the problem is defined by the features of claim 1. According to the invention, the server for processing transactions comprises the following: a) a linking module that is set up to receive a public key from a certification authority and to generate and store fingerprint data that represent the public key in one of the data blocks of the distributed ledger; b) an authorization module configured to store access authorizations associated with identity certificates issued by the certification authority in one of the data blocks of the distributed ledger; c) an ingress module configured to receive a transaction request from a requesting authority, the request being signed with the requesting authority's private key linked to a public key of an identity certificate of the requesting authority issued by the certification authority; d) a verification module configured to verify an identity of the requesting entity based on the requesting entity's request, the stored fingerprint data and the stored access authorizations; e) a recording module that is set up to record a transaction that corresponds to the transaction request in a data block of the distributed ledger, provided that the identity has been successfully verified by the verification module.

A computer-assisted system according to the invention for processing transactions accordingly comprises: a) a certification authority for issuing identity certificates, the identity certificates comprising a public key and an identity and being signed by the certification authority; b) a computer network storing a distributed ledger comprising a plurality of data blocks replicated, shared and synchronized between multiple computers of the computer network; c) a server according to the invention for processing transactions as described above.

An inventive method for processing transactions also includes the following steps: a) storage of fingerprint data representing the public key of a certification authority in one of a plurality of data blocks of a distributed ledger, the plurality of data blocks between multiple computers replicated, shared and synchronized over a computer network; b) storing access credentials associated with identity certificates issued by the certification authority in one of the plurality of data blocks of the distributed ledger; c) receiving a transaction request from a requester, the request being signed with the requester's private key linked to a public key of a requester's identity certificate issued by the certification authority; d) verification of an identity of the requesting body, based on the request of the requesting body, the stored fingerprint data and the stored access authorizations; e) Recording a transaction corresponding to the transaction request in a data block of the distributed ledger, provided that the identity has been successfully verified by the verification module.

In the context of the present application, “server” is to be understood broadly. These are computing resources that can receive, process and output data. A server within the meaning of the present application can be formed by a single computer or multiple computers and can be fully or partially virtualized.

[0010] The distributed ledger is in particular a private blockchain. The certificate authority is a trusted third party (TTP).

The fingerprint data can be the public key itself or a processing result (digest) that is obtained from the public key or the certificate. Accordingly, in addition to the public key, the fingerprint data can include further information or can be obtained from further information.

The identity certificates are generated in particular based on the X.509 standard. The access authorizations are linked to the identity certificates in particular using a unique identifier (serial number) of the respective certificates. The transaction requirements are linked to a public key of an identity certificate in particular by using a qualified electronic signature (QES). Corresponding certificates each comprise at least two linked certificates, namely the user certificate and one or more publisher certificates. The appropriate certificate chain can be used to verify that the QES identity certificate comes from the appropriate issuer, namely the appropriate Certificate Authority (TTP).

The transaction request is generated independently of the distributed ledger (“off-chain”) by the requesting body (or on behalf of the requesting body) and already includes the information necessary to verify the identity of the requesting body. The verification itself is then carried out using data stored in the distributed ledger (“on-chain”).

The recording of the transaction may be subject to additional conditions, e.g. B. in relation to the possibility or validity of the transaction itself.

The server according to the invention and the method according to the invention are characterized in that certificates issued by TTP are linked with distributed ledger technology (DLT). Transaction data can thus be stored reliably and securely in a distributed ledger, which e.g. B. also enables the use of smart contracts. At the same time, requirements can be met that require identification of the parties involved. Such requirements arise e.g. B. from legal provisions on the regulation of financial transactions, but the identifiability can of course also be desired by the parties involved.

The DLT (for processing the actual transactions) is thus linked to the use of a TTP or multiple TTPs (to ensure identification) in a new way in order to combine the advantages of both approaches.

[0017] The transaction request can relate in particular to the issue, transfer or offsetting of financial instruments, in particular bills of exchange (promissory notes). The system according to the invention thus serves to manage digital security certificates. In this context, it is essential for the parties involved to have certainty about the identity of the transaction partner. Identification is also often mandatory due to regulatory requirements.

The invention can also be used in connection with other transactions, e.g. B. in the financial and real estate sector, especially where secure identification is required by the parties and/or due to legal regulations.

Advantageously, the authorization module is set up to store assignments to administrators' identity certificates, the input module is set up to receive transaction requests that include an access certificate with an administrator's signature, and the verification module is set up to check whether the administrator's signature linked to one of the identity certificates of the stored access permissions.

Thus, within the scope of the method according to the invention, identity certificates from administrators are assigned to the access authorizations, the transaction request from the requesting body includes an access certificate with an administrator's signature, and a successful verification of the identity presupposes that the administrator's signature corresponds to one of the identity certificates of the stored access permissions.

[0021] The assignment to the identity certificates takes place in particular with the aid of a unique identifier (serial number) of the certificates. In addition, the publisher (certification authority) is noted with advantage, so that identity certificates from different publishers can be used without further ado if necessary, provided that the corresponding fingerprint data of these publishers are stored in the distributed ledger as explained above.

Based on their identity certificates, administrators can now authorize other people to request transactions by providing them with an access certificate. This is essentially a piece of data signed by the administrator, specifically with a QES. In this way, such authorizations are granted outside of the distributed ledger (off-chain). Authorization is checked using the administrator's access authorization stored on-chain, the access certificate, i.e. the data portion with the administrator's signature, and the identity certificate of the requesting authority.

[0023] In addition, of course, all identity certificates involved are checked for their validity, as explained above, again with the aid of data that are stored on-chain (fingerprint data).

[0024] The access certificate preferably comprises a unique identifier for the requesting authority (e.g. a unique identifier for the identity certificate) and an association with an entity. This ensures that the access certificate can only be used by a designated, clearly identified person to request transactions, i.e. it cannot be transferred to other persons. In addition, several administrators and/or authorized requesting bodies can be assigned to a common entity. The administrators and authorized bodies are in particular natural persons (for whom identity certificates can usually be issued), the entity is in particular a legal person, e.g. B. a company. The assignment to the entity takes place, for example, via standardized, state-administered numbers (e.g. company numbers or codes, supplemented with information on the respective jurisdiction).

Within the scope of the invention, large and complexly organized companies can also be mapped in a simple manner by ultimately only having to manage the administrators in the distributed ledger, while the management of the specific authorizations takes place within the company by issuing the access certificates.

The data portion of the access certificate may include other information, e.g. B. in relation to the signing rights of the authorized person. So e.g. B. it can be noted that the person can only validly sign together with another (specified or unspecified) authorized person of the entity.

The access certificates advantageously have a limited period of validity, so that authorizations have to be checked regularly.

In a simpler, alternative embodiment of the invention, the access authorizations of the authorized users are stored directly on-chain. It is also possible to enable both variants in the same system, i. H. both directly authorized and delegated authorized bodies can make transaction requests.

Advantageously, verifying the identity of the requesting entity includes verifying that the requesting entity is not listed in a revocation list stored in a data block of the distributed ledger.

This can ensure that no longer authorized bodies can no longer make valid transaction requests, because users with a valid identity certificate can continue to sign data in a qualified manner and on-chain it is not known which bodies are authorized by the listed administrators by issuing corresponding access certificates became.

The following elements are preferably stored on-chain: the transaction data (possibly including the financial instruments in virtual form); data to identify the authenticity of the certificates of approved certification services; the authorized administrators with assignment to the respective legal entity; the revocation list.

The access certificates, on the other hand, are advantageously stored off-chain in that they are issued by the administrators by means of certificates and are transmitted in transactions as part of the transaction request. The identity certificates are also issued off-chain, in particular by a certification authority that is independent of the system.

The transaction can be encrypted before recording using symmetric encryption, so transactions can be discarded by deleting an encryption/decryption key.

After receipt and successful verification of a transaction request, the content of the transaction is thus encrypted using the symmetric encryption method (z. B. AES 256 bit) and stored in the distributed ledger. If the encryption/decryption key is deleted, the corresponding information can no longer be accessed. The transaction is therefore no longer visible and therefore no longer effective.

Advantageously, transaction requests can be signed by multiple (two or more) parties. A corresponding transaction request is thus signed by additional parties involved in the transaction to be recorded, and the identity of the additional parties is verified on the basis of the respective stored fingerprint data and stored access authorizations.

Such transactions include, for example, the transfer or settlement of a bill of exchange where the old and new holders or the issuer and the (current) holder must sign for the transaction to be valid.

In applications where the identity of the parties involved has to be verified by a separate process, e.g. B. in the context of "Know Your Customer" requirements in the financial sector, the storage of access authorizations in a data block can also be made dependent on an identity check that is independent of the identity certificate.

[0038] Such an examination includes, for example, a real or virtual interview, the examination of identity documents, etc.

Further advantageous embodiments and combinations of features of the invention result from the following detailed description and the entirety of the patent claims.

Brief description of the drawings

The drawings used to explain the exemplary embodiment show: FIG. 1 a block diagram of those involved in transactions according to the system according to the invention; and FIG. 2 shows a flow chart of a method according to the invention for processing transactions.

In principle, the same elements are provided with the same reference symbols in the figures.

Ways to carry out the invention

The exemplary embodiment described here relates to transactions in connection with bills of exchange or promissory notes (promissory notes), namely transactions between companies (legal entities). In such a bill of exchange, one party (the issuer) promises to pay another party (the drawee) a specified sum to that other party or a third party (payee) at a time due.

Within the framework of the system described, each of the parties (legal entities) involved are associated with certain users (natural persons) who can act on behalf of the parties, i.e. H. can provide binding (virtual) signatures in the context of the transactions.

FIG. 1 shows a block diagram in which the participants in such transactions are shown in a simplified manner. A user company 10 is shown with a natural person as administrator 11 and several natural persons as users 15.1, 15.2, 15.3.

The user company 10 is for example only. Transactions usually involve several such user companies, each of which can also assume different roles. All user companies are integrated into the system in the same way.

Also shown is the computer-aided system 100 of the service provider, which includes a server 101 with communication interfaces and computing resources and a private blockchain 150, which is managed by the service provider itself or by another service provider on behalf of the service provider. In the blockchain, data is stored in data blocks in a manner known per se, with the data blocks being replicated, shared and synchronized between a number of computers in a computer network.

The server 101 comprises a linking module 102, an authorization module 103, an inbound module 104, a verification module 105 and a recording module 106.

A certification authority 200 for issuing identity certificates is also involved. In the example shown, these are certificates for qualified electronic signatures (QES). Each of the certificates comprises two or more certificates that are chained together, namely the user certificate of the respective natural person whose identity is to be confirmed and one or more publisher certificates chained to it. Several certification authorities can be provided, whose certificates are accepted by the service provider.

The user company 10 or the administrator 11 and the users 15.1...3 interact with the certification authority 200 to obtain identity certificates that are associated with the administrator 11 or the users 15.1...3. The service provider's server 101 also interacts with the certification authority 200, e.g. B. to obtain publisher certificates.

A simplified flow chart of a method according to the invention for processing transactions is shown in FIG. First, the linking module 102 of the server 101 receives an issuer's certificate from the certification authority 200 and stores a fingerprint derived from its public key in the blockchain 150 (step 301).

The fingerprint is obtained from the data of the certificate, which is in pem format, for example. It is obtained, for example, by applying a SHA-256 hash function to this data. The public key of the certificate, for example, is suitable for obtaining the fingerprint. Other elements can be used.

[0052] Fingerprints of identity certificates from administrators 11 linked to information about the user company 10 (e.g. with a unique company identifier or company number) are stored in the blockchain 150 by the authorization module 103 of the server 101 (step 302). The administrator 11 recorded in this way can then authorize users 15.1..3 to act on behalf of the user company 10 vis-à-vis the service provider. To do this, he signs a data portion that includes the unique identifier of the user to be authorized (serial number of the corresponding identity certificate) and the specification of the legal entity for which the administrator and the user (should) act. He leaves the authorization certificate generated in this way to the respective user 15.1 . . . 3 for use (step 303).

The authorized users 15.1 . . . 3 can then interact with the service provider's server 101 as part of transactions. To do this, they transmit a corresponding transaction request to the server 101 via the input module 104 of the server 101, which includes, among other things, data portions signed by the user and the authorization certificate received from the administrator 11 (step 304).

In all transactions, the verification module 105 of the server 101, in addition to the signatures of the signing users, using the stored fingerprint of the issuer's certificate, also checks whether they have authorization for the legal entity concerned (step 305). After a successful check, data about the transactions or the changes affected by them are also stored in the blockchain 150 by the recording module 106 (step 306).

User signatures are represented by a signature structure with the following elements: 1. The signature of the user signing the bill of exchange. This consists of a hash of the following elements signed by the user: – the hash of the bill of exchange, – the designation of the user’s legal entity and – a hash of any conditions that may exist (discounts or other information that is not visible in the bill of exchange, but is visible during the signing process should nevertheless be verifiable); 2. A signature of an administrator of the legal entity. This consists of a hash signed by the administrator of the following elements: - the unique sequence number of the user and - the designation of the legal entity of the administrator and the user; 3. the name of the legal entity.

A bill of exchange (Promissory Note PN) is represented in the framework of the described system by a structure with the following elements: 1. A main structure that remains unchanged during the lifetime of the bill of exchange, comprising the following elements: - the indication of the nominal value; – indication of the currency; – indication of the due date; – the indication of possible transfer recipients (legal entities) (optional); – a nonce (to prevent replay attacks); – an indication of the legal entity of the issuer; – an indication of the legal entity of the guarantor (optional); – fixed metadata; 2. an identifier; 3. an issue date; 4. a signature structure (see below) with the current signatures; 5. History of the PN (updated when the PN is completed, deleted or transferred); 6. a status (open, due, done, deleted, possibly others); 7. the indication of the legal entity of the owner and 8. variable metadata, including single and multiple variable data.

The signature structure of the bill of exchange includes several signature structures and other elements as follows: issuer signature hash (PN), jur. Person (LE), Hash (Conditions) Conditions of Issuance String Hash (Conditions of Issuance) Conditions of Guarantee String Hash (Conditions of Guarantee) Conditions of Transfer String Hash (Conditions of Transfer) Guarantor Signature Hash (PN), Hash (Conditions) Holder (Publice ) Signature hash (PN), LE holder, LE new holder (optional), hash (conditions) new holder Signature hash (PN), LE holder, LE new holder, hash (conditions)

To issue a new bill of exchange, the issuer and the (initial) holder agree on the hash of the information according to the main structure (item 1 above) and the legal entity of the holder. In addition, there is at most a hash of data relating to the conditions agreed between the parties. These two or three portions of data are then signed by users who are authorized to sign for both parties.

In a combined issuance and transmission, the issuer must sign the same data as in the issuance. In the case of the original and new owner, the legal entity of the new owner and any conditions for the transfer are added to the data to be signed. As part of the processing of the transfer, the promissory note structure is used to check whether the transfer of the bill of exchange is restricted and, if so, whether the intended transfer is permissible within the framework of the restrictions.

A bill of exchange can be dealt with at the request of the (current) owner, particularly after the issuer has paid the agreed amount. To do this, the owner signs a piece of data with the identification number of the bill of exchange, the note that the bill of exchange has been completed and the legal entity of the owner. No further signatures are required for completion.

In the context of the system described, a signature is valid if the corresponding certificate is valid, the authorization of the signatory has not been revoked (see below) and the signing user is linked to the acting legal entity via valid access authorization. In addition, stored signing authorizations (e.g. regarding collective signing authorization) can be checked. Accordingly, the validity of signatures within the framework of the described system is checked according to the following steps, each applied to each signature of a PN: 1. The corresponding certificate data are obtained, both for the signing user and for the assigned administrator. 2. The list of recorded administrators of the legal entity associated with the signature is retrieved. 3. It is checked whether the user's certificate comes from a registered publisher (certification authority). To do this, a fingerprint is generated using the issuer's certificate, which is chained to the user's identity certificate. This is then compared with the fingerprints stored in the blockchain. 4. It is checked whether the user is not included in a list with revoked access rights. Such lists are stored in the blockchain and are kept separately for each legal entity, because a specific user (natural person) can have access permissions for several legal entities and because these should be managed independently of each other. 5. It is checked whether the user's certificate contains an access authorization from one of the registered administrators of the legal entity and whether this access authorization was validly signed by the corresponding administrator.

Other tests are possible, e.g. For example, whether all signatures associated with a party to a transaction belong to the same legal entity, whether the number of signatures is sufficient, etc.

The promissory notes stored in the blockchain are encrypted with a symmetric key, for example using AES encryption. The key (and possibly also an initialization vector) is generated and stored off-chain. It is required to access the Promissory Note; if it is deleted, the information in the corresponding Promissory Note can no longer be read or written to. Accordingly, the Promissory Note loses all effect and, despite the storage of the corresponding data in the blockchain, it is no longer clear what its content was.

The invention is not limited to the illustrated embodiment. Thus, specific aspects of the described system and method may be implemented differently. In addition, the invention can be used not only for processing transactions in connection with bills of exchange or other financial instruments, but also for other transactions.

In summary, it can be stated that the invention creates a server, a system and a method that enable transactions to be processed efficiently with reliable identification of the transaction partners.

Claims (12)

A server for processing transactions, the server being adapted for connection to a computer network storing a distributed ledger comprising a plurality of data blocks which are replicated, shared and synchronized between a plurality of computers on the computer network, and the server includes: a) a linking module that is set up to receive a public key of a certification authority and to generate and store fingerprint data representing the public key in one of the data blocks of the distributed ledger; b) an authorization module configured to store access authorizations associated with identity certificates issued by the certification authority in one of the data blocks of the distributed ledger; c) an ingress module configured to receive a transaction request from a requesting authority, the request being signed with the requesting authority's private key linked to a public key of an identity certificate of the requesting authority issued by the certification authority; d) a verification module configured to verify an identity of the requesting entity based on the requesting entity's request, the stored fingerprint data and the stored access authorizations; e) a recording module that is set up to record a transaction that corresponds to the transaction request in a data block of the distributed ledger, provided that the identity has been successfully verified by the verification module. 2. Server for processing transactions according to claim 1, characterized in that the authorization module is set up for storing assignments to identity certificates from administrators, that the input module is set up for receiving transaction requests that include an access certificate with an administrator's signature, and that the verification module is set up to verify that the administrator's signature is linked to one of the identity certificates of the stored access permissions. 3. Server for processing transactions according to claim 2, characterized in that the access certificate includes a unique identifier of the requesting body and an assignment to an entity. 4. Computerized transaction processing system comprising: a) a certification authority for issuing identity certificates, the identity certificates comprising a public key and an identity and being signed by the certification authority; b) a computer network storing a distributed ledger comprising a plurality of data blocks replicated, shared and synchronized between multiple computers of the computer network; c) a server for processing transactions according to one of claims 1 to 3. 5. Procedure for processing transactions, comprising the following steps: a) storing fingerprint data representing the public key of a certification authority in one of a plurality of data blocks of a distributed ledger, the plurality of data blocks being replicated, shared and synchronized between a plurality of computers in a computer network; b) storing access credentials associated with identity certificates issued by the certification authority in one of the plurality of data blocks of the distributed ledger; c) receiving a transaction request from a requester, the request being signed with the requester's private key linked to a public key of a requester's identity certificate issued by the certification authority; d) verification of an identity of the requesting body, based on the request of the requesting body, the stored fingerprint data and the stored access authorizations; e) Recording a transaction corresponding to the transaction request in a data block of the distributed ledger, provided that the identity has been successfully verified by the verification module. 6. The method according to claim 5, characterized in that identity certificates of administrators are assigned to the access permissions, the requestor's transaction request includes an access certificate signed by an administrator, and that successful verification of identity requires that the administrator's signature is linked to one of the identity certificates of the stored access permissions. 7. The method according to claim 6, characterized in that the access certificate includes a unique identifier of the requesting body and an assignment to an entity. 8. The method according to any one of claims 5 to 7, characterized in that the verification of the identity of the requesting body comprises a check whether the requesting body is not listed in a revocation list that is stored in a data block of the distributed ledger. 9. The method according to any one of claims 5 to 8, characterized in that the transaction is encrypted before recording using a symmetrical encryption and that transactions can be discarded by deleting an encryption / decryption key. 10. The method according to any one of claims 5 to 9, characterized in that the transaction request is signed by additional parties involved in the transaction to be recorded, and that the identity of the additional parties is verified on the basis of the respective stored fingerprint data and stored access authorizations . 11. The method as claimed in one of claims 5 to 10, characterized in that the storage of the access authorizations in a data block is dependent on an identity check which is independent of the identity certificate. 12. The method according to any one of claims 5 to 11, characterized in that the transaction request relates to the issuance, transfer or settlement of financial instruments, in particular bills of exchange.