DE10017235C2 - Method, computer program, device and system for the automatic recording and settlement of a securities transaction - Google Patents

Description

The present invention relates to a method, a computer program, a pre direction and a system for the automatic recording and processing of a value pa piergeschäfts.

It is known to offer platforms on the Internet on which a Wertpa pier business can be concluded. So offer z. B. Direct investment banks at Stock exchange listed shares for purchase. Here, however, the problem arises that single A small number of shares can be offered, which are officially listed on the stock exchange are noted. In addition, the specific form of offer requires a corresponding de Full license of the offering institute. Platforms are still known which are also offered non-listed securities. These platforms suffer from the fact that no effective control of the settlement ge is guaranteed so that, for. B. Quotes of individual securities offered by means of a bill purchases or bogus transactions can be artificially driven up.  

The document 1) (WO 00/11587 A1) discloses a method and a system for Share trading in real time after the market closes. Here are sales and Purchase offers from different investors matched.

The document 2) (WO 97/30407 A1) discloses a system for the electronic Trading in so-called "contracts".

It is therefore an object of the present invention to automatically detect and Propose to process a securities transaction that is automated Control of actual business transactions guaranteed.

This object is achieved by a method for automatic He form and settle a securities transaction according to claim 1, a computer Program according to claim 22, an apparatus according to claim 23 and a system solved according to claim 28. Preferred embodiments of the invention are Ge subject of the dependent claims.  

The invention provides a method for the automatic recording and settlement of a securities transaction, in particular a transaction of listed and / or unlisted shares, which comprises the following steps:
Detecting a (buy and / or sell) offer from a first user or user for a securities transaction;
Detecting an acceptance of a second user of the detected offer;
Checking an (internal or external) intermediate account, whether a cash flow or transfer corresponding to the offer and the acceptance was preferred; and
Settlement of the securities business by transferring or reconciling the securities corresponding to the offer between a securities account of the first user and a securities account of the second user if a corresponding countervalue was recorded in the intermediate account in the verification step.

Checking the intermediate account ensures that a countervalue, in particular, money was actually flowed or transferred, so that a Settlement of the securities transaction is then only carried out can, if the second user is at least partially from the assumption itself resulting obligations. Accordingly, it can also be prevented that pseudo-transactions are carried out to artificially drive up the share values the.  

Furthermore, the Securities from the corresponding securities transaction are blocked until settlement and are at least temporarily not accessible to any other securities business.

It is thus advantageously avoided that the same security is the subject of several Securities transactions.

Furthermore, the method according to the invention has a step of checking, whether the number of existing accounts in a first user's securities account Securities is greater than the number of securities in the securities business.  

According to a preferred embodiment of the invention, the method has white then a step of including the recorded offer in a security data bank and / or the display of the recorded offer on a display device.

By appropriately adding the offer to the securities database or by displaying the offer, the second user is enabled to to accept the offer. Therefore, the first user can go without a specific exchange sennotierung offer his security advantageous to another user.  

In the offer display step, preference is given to the corresponding security, an equivalent value corresponding to the security, an equivalent value corresponding to the offer Number of securities, a recently offered equivalent and / or a partial amount business information is displayed.

This different information offers the second user more advantageous wise a concrete basis for its adoption.

The step of recording the acceptance preferably further comprises the following steps:
Selection of the corresponding offer within the securities database by the second user and
Capture a confirmation of acceptance from the second user.

Entering the additional confirmation of acceptance can result in an incorrect entry of the second user can be avoided at least partially because he is more advantageous wisely asked to confirm his acceptance again.

Furthermore, the first user preferably orders in the offer entry step to the offer a partial transaction or denomination information, from which goes about whether and preferably how the recorded offer may be divided in order to an acceptance of only part of the securities business by the second Be allow users. The denomination information is preferably in the value pa pier database saved.

Most preferably, the acceptance detection step involves entering the number of the securities, insofar as partial transaction information is assigned to the offer.

According to a further preferred embodiment of the invention, the Offer registration step and / or an identification in the acceptance registration step adornment of the first or second user by collecting user data and a comparison of the recorded user data with stored in a user database saved user data.  

Accordingly, in particular by querying a login ID or a passport words ensures that no unauthorized participation in the procedure or no unauthorized access to the securities trading platform is possible. Farther is advantageously assigned to egg by identifying the user possible in a securities account or custody account.

The offer acquisition step preferably has a step of assigning or Setting or capturing a time information on the offer, the time in formation corresponds to a period of time during which the recorded offer is valid, preferably in the offer display step an offer whose duration expires is not displayed and / or wherein the acceptance detection step is a Step of checking the duration of the accepted offer shows whether the The duration of the accepted offer has not been exceeded.

Furthermore, the acceptance step preferably has a step of awarding a Transaction number for the corresponding securities transaction. Accordingly spreader A securities transaction can advantageously have a unique identifier or a unique means of identification are automatically assigned, through which or which the business can be identified.

According to a further preferred embodiment of the invention, the intermediate account checking step receiving a transfer file from a Financial institution on which transfer file of a successful transfer or money movement of the equivalent value or money corresponding to the securities business amount corresponds.

Accordingly, a movement on the intermediate account can be advantageous are automatically checked so that a transfer or money movement on the intermediate account can be easily recorded. Accordingly, the Settlement of the securities business is advantageously fully automated and effective control of the settlement is carried out.  

The transfer file preferably contains the transaction number or has one information corresponding to this transaction number.

Containing the transaction number can benefit from the transfer file is unequivocally based on the securities transaction carried out following settlement can be closed. Therefore, an easy assignment is a Movement on the interim account to a specific security transaction a large number of securities transactions advantageously possible. He continues The transaction number advantageously also allows multiple values to be recorded paper transactions via one and the same intermediate account.

It is also preferred to transfer the security (s) after they have been recorded the transfer file, preferably after receiving and comparing the transaction number mer, made.

Most preferably, the intermediate account verification step comprises a step of Reconciliation or comparison of a transaction recorded in the intermediate account corresponding transaction record with one in the acceptance entry step generated acceptance data record. The acceptance data record is preferably used for Instruction of a movement or transfer to the intermediate account used.

It is therefore advantageously an easy comparison between the on the Zwi movements and a value generated in the process paper business possible.

The acceptance detection step preferably has a step of generating a  Data record on, which preferably automatically (possibly with a time delay) on Credit institution is transferred, with the record preferring the transaction number mer contains or this at least partially corresponds.

This can advantageously ensure that an acceptance by the second User is automatically processed to correspond to the securities business to generate appropriate movement on the intermediate account and thus the settlement to enable.

Furthermore, the offer entry step prefers a step of checking on whether the offered number of securities is available, through Ver equal to a number of offer securities with one in the securities account of the first user stored inventory number of securities, if, if the Ange number of securities exceeds the number of existing securities, this automatically Offer is preferably rejected and an error message is generated.

It can thus advantageously be avoided automatically that the first user offers more securities to buy than on the assigned security account are included.

Most preferably, the offer entry step includes an entry step sens of a purchase offer to buy one or more securities and / or a step of entering a sales offer to sell one or of several securities.

According to a further preferred embodiment of the invention, the development development step a step of updating user data, in particular in the User database, the user data preferably a number of success richly executed securities transactions and / or a volume of successful carried out securities transactions, the user data of the first user preferably the second user, most preferably on request can. Therefore, the number of successful deals can be beneficial used as an indication of business acceptance to provide an indication of  to maintain the "seriousness" of the relevant user.

According to the invention, a computer program for automatic Capture and settlement of a securities transaction provided, which Pro Has parts of the gram for performing a method according to the invention.

According to the invention, a device for automatically recording and processing a securities transaction is also provided, in particular for carrying out the method according to the invention, which has the following features:
a first input device for entering or capturing an offer of a first user for a securities transaction;
a second input device for inputting or detecting an acceptance of a second user of the detected offer;
an internal or external intermediate account on which the equivalent or monetary value is to be recorded or paid;
a checking device for the intermediate account to check whether the equivalent value recorded or moved in the intermediate account corresponds to the acceptance by the second user;
a user database with storage areas for security accounts assigned to the respective users; and
a settlement facility, which settles the securities transaction by switching or matching the securities corresponding to the offer between the securities account of the first user and the securities account of the second user, if the verification facility determines an equivalent value to the acceptance in the intermediate account and the settlement device transmits a corresponding signal or command.

Furthermore, the device according to the invention comprises a Check facility for the number of securities to check whether the Number of existing accounts in a first user's securities account Securities is greater than the number of securities in the securities business, and a blocking device for blocking the securities of the corresponding Securities transaction until the settlement of the securities transaction, so that the Securities at least temporarily not accessible to any other securities business are.  

According to a preferred embodiment of the invention, the device continue to a securities database in which the offer and / or the To accept and prefer further information about the offer or the acceptance, like a countervalue corresponding to the security, one corresponding to the offer number of securities, partial business information, are stored.  

The device preferably also has a first data generation device which generates a first data record or a file, which or which corresponds to the acceptance by the second user.

Furthermore, a second data generation device preferably generates two ten data record or a file, which or which of the detection of a movement corresponds to the intermediate account.

Most preferably, the checking device has a matching device, which compares the first and second data record or file and corresponds to one generated the command of the handler.

It is therefore advantageously an automatic comparison or checking of the actual settlement of the securities business and efficient control of the Processing possible within the device.

According to the invention, a system for automatic detection and Settlement of a securities transaction provided which comprises: ei ne inventive system device for automatic detection and Wwic a security deal; a first input unit for input or Er summarize the offer of the first user for a securities transaction; a second Input unit for entering or recording the acceptance of the second user the recorded offer; wherein the first and second input units with the first or second input device via a bi-directional or multi-directional network in particular who are connected via the Internet.

It is therefore advantageously possible to conduct securities transactions between users lead, which only in the Internet via the system according to the invention in Connect.

According to a preferred embodiment of the invention, the external intermediate gift account and the verification facility via a bi- or multidirectional Network connected in particular via the Internet.  

Accordingly, the intermediate account can also be localized at a financial institution be, which means that the system does not require bank approval. Furthermore, this can advantageously a reliable, actual settlement of the amount of securities business, d. H. the corresponding transfer of the corresponding amount of money can be guaranteed via the intermediate account at a financial institution.

Other objects, features and advantages of the present invention will become apparent from the following exemplary description of preferred embodiments with Reference to the drawing can be seen in which:

Fig. 1 is a schematic diagram of a basic flow of a method according to the invention for the automatic detection and settlement of a securities transaction;

Fig. 2 shows a so-called "screenshot", which is an image representation of an open order book according to a preferred embodiment of the invention;

. 3 a flow of the method is a diagrammatic schematic diagram according to a preferred embodiment of the invention;

Fig. 4 is an example of an overviews of registered users or user and trading history in accordance shows a preferred embodiment of the invention;

Fig. 5 is a flowchart showing a procedure of the method according to a preferred embodiment of the invention;

. FIGS. 6A through 6Q so-called are "screenshots" which a preferred embodiment of the invention showing screen images of a practical execution of the method of, with respect to the quotation and responding to orders on a trading platform according to an embodiment of the invention; and

FIGS. 7A-7I so-called. "Screenshots" are that a preferred embodiment of the invention showing screen images of a practical execution of the method according, with respect of creating an offer for sale and to respond to an offer to purchase.

A preferred embodiment of the method according to the invention is described below with reference to FIGS . 1 and 2.

The method according to the invention for the automatic recording and settlement of a securities transaction is shown in the schematic schematic diagram from FIG. 1. A first user can place an offer via the Internet for a purchase and / or sale of securities. This offer is presented on a platform (so-called "open order book") to which other users have preferential free access.

If a second user is interested in an offer, click to place it corresponding buttons or links or references his acceptance of the offer.

Then a corresponding movement is observed in an intermediate account or recorded or monitored. As soon as the second user accepts a Be has caused or caused movement on the intermediate account, e.g. B. by transfer an amount corresponding to a share purchase plus, if applicable accruing commissions, this amount is the corresponding security is automatically assigned and checked for correctness, e.g. B. whether he is actually the corresponds to the correct amount. If the check is positive, it will Securities transactions are processed automatically, d. H. the securities or shares booked and a corresponding transfer to the first user is initiated.

For the access of all users to the authorized area with the associated trading opportunity on the platform, the standards usual in online banking are preferred. These include the following:

• - Identification of personal data  
• - Check the ID card number
• - Identification of bank details
• - Self-disclosure and acceptance of the terms and conditions
• - Sending password, PIN and TAN's, which is also used to verify the Address information and access to the specified e-mail account.

Verification of personal data based on the copy of your ID card Activation of the user and inclusion of user-specific data in one User Database

Only users registered according to the above procedure can make a buy or sell offer in the open order book (which can be viewed by everyone). An example of an open order book is shown in Fig. 2.

The submission of an offer preferably proceeds as follows:
If a user or trader wants to B. not respond to an existing offer, he can create a new offer. A new offer is generated by clicking the B1 or B2 button for order entry.

Subsequently, the user must log into the system with a user ID and password gene.

The master data is filled automatically (WKN, date of the offer creation Etc.). There is a query as to whether there are any open offers for this company messengers exist, if so there is a hint. There is a distinction between and sales offers necessary.

A period of time is automatically generated during which the offer is valid. The period of validity of the offer is set to one by default Month set, but you can also choose an individual date. The Be user supplements the order with order information such as the number of shares and the  Share price. The corresponding order information is in the Wertpa pier database and / or stored in the user database.

The user can make any number of buy and sell offers, at Ver However, purchase offers are preferably checked to see if they include the number of value actually has stocks or shares. This is preferably done by Comparison of the number offered (number of offer securities) with that on one number of securities assigned to the respective user Securities (number of existing securities). Exceeds the number of offer securities the number of existing securities, the offer is rejected and one corresponds The corresponding error message is generated automatically.

When or after the offer has been created, they are already put up for sale offered shares in the securities database and marked by existing inventory that can be offered for sale is reduced.

In addition, the user enters whether a partial trade is possible. B. in egg nem "pulldown menu" (yes / no), a default is set to yes.

In the following, the complete order will be shown to the entering user again for confirmation, preferably with the indication that this offer is binding. For the confirmation of the offer entry (offer confirmation) the user must e.g. B. Enter a valid TAN and the corresponding PIN. The data entered are compared with a data set or data stored in a user database. If the data match, the order is entered in the trading system and appears in the open order book ( Fig. 2).

The procedure for acceptance, i. H. if a user at best want to enter or accept the existing order in the order book.

Is a registered user or trader on one of the in the open order book interested in offers, he can respond to them by referring to the existing offer clicks.  

Subsequently, the user must be in the system, for. B. with UserID and password log in.

If a partial trade is possible with the corresponding offer, the Interests sent only the number of shares he wants to buy / sell. When selling it is checked whether he holds the shares by comparing them with his value pa pierkonto. In the basic setting, the total or still available number of shares.

After successfully entering an acceptance, the prospect receives the entire Transaction displayed (e.g. with the number of shares, the price per share and the total amount of the securities transaction). In addition, the outbound is preferred indicates the legal validity of this assumption.

When confirming the entries, they must have a valid TAN and PIN to verify.

Below, the shares are settled with each transaction until complete settlement lung locked, d. H. there can be neither buyers nor sellers over the traded Shares dispose of as long as the cash flow in the intermediate account for that match de securities transaction did not take place. In addition, the entry disappears from the open order book and appears in the trading history and evaluations. Here, these preliminary entries / data are preferred in a different color be marked until processing has taken place.

In the overviews of the seller and buyer, the transaction is visible, however also marked z. B. in a different color or a blocking notice features.

After the acceptance has been carried out correctly, both users, i.e. H. the one User who placed the offer and the user who placed the offer has accepted, preferably sent an email about the purchase contract automatically.  In addition, the person who posted (acted) the offer and gets on the response to the offer is waiting, preferably a notification, z. B. in the form of an SMS (if desired and mobile phone number in the user data record is included) or an email.

A monitoring device monitors possible movements on the Zwi rule account. As soon as movement is detected, e.g. B. an incoming payment on the Zwi check account has been carried out, a check is made as to whether the amount is sufficient and if so, an automatic comparison with the trading system takes place. Here is a Data exchange with the bank regarding the transfer information e.g. B. via data carrier exchange (DTA). The transfer information contains be prefers a transaction number of the order or of the securities business. This transaction number is entered into the trading system read and released for forwarding after an examination.

After the transaction or securities transaction has been released, the securities pa dealt with, d. H. the blocked shares in the securities account of the Sellers are deleted and transferred to the buyer's securities account.

For the transfer / transfer of the amount of money to the seller is before generates a data record, which is also transferred to the bank (e.g. via DME) becomes. After reading the data record at the bank, the transfer is made to the seller.

FIG. 3 describes a method for automatically recording and processing a securities transaction according to an embodiment of the invention.

In step 1 , a first user K and a second user V agree on the trading platform and conclude a securities or share transaction.

In step 2 , the intermediate account is checked for incoming funds (including the transaction fees).

In step 3 , the shares in the share register are blocked for V and cannot be traded until the end of the settlement. The shares are also not accessible to K until the transaction is completed.

In step 4 , K transfers the purchase price to the intermediate account.

In step 5 , the shares are transferred to K on receipt of the purchase price on the intermediate account.

In step 6 , the purchase price minus the transaction fees is forwarded to the seller (e.g. via a DME connection with the bank).

Thus, processing via the intermediate account enables everyone to be monitored transactions made on the trading platform. Generally, this is advantageous made sure that no "virtual" transactions are made and the according to the course manipulation is not easily possible. Would settlement do not go through an intermediate account and the contractual partners would have to do the transaction on and only confirm the cash flow, Transaction could be carried out and confirmed without actually doing business keln and pay.

By checking the transactions via the intermediate account that the value pa following transactions have actually been concluded Automated implementation in the system advantageous.

The buyer's overview (Trader's Account) is increased by the shares purchased. The seller's overview (Trader's Account) is adjusted by the shares sold Ringert. The trading history (including the identifier derived from the transaction pay like B. Average values, volatilities and the associated graphs representations) are updated automatically.

In Fig. 4 an example of an overview of registered users or users and the trading history can be seen, as z. B. be displayed on the Internet.

When processing the securities transaction, the overviews of the traders who have made the deal (buyers and sellers) to the made Securities business adjusted. The buy history is with the buyer and with the seller expanded the sales history by one store.

With the current price of the shares traded, the overviews of all traders, who hold the stocks at the last price closed and then the absolute and relative difference to the starting price and the reali The realized and unrealized profit or loss is determined, saved and / or displayed. The corresponding data is also stored in the securities database chert.

The trading history for the traded value is also extended by a transaction, with the adjustment of all associated key figures (which are provided in the open order book for information about the existing orders), in particular the following graphics or data records changed, saved and / or displayed:

• - Last traded price
• - Last volume traded
• - Average values of the last 3, 10, 30 transactions and the last 3, 10, 30 trading days
• - Absolute and relative change from the previous transaction
• - Update of the best "bid" (buy) and "ask" (sell offer)
• - Update volatility

In Fig. 5 is a flowchart of a preferred embodiment of the invention is illustrated by way of example, in which a first user Buyer placed ( "User 1") a locking and a second user ( "User 2") responds to the offer for sale and accepts it.

In step S1, the first user accesses a so-called "open order book" over the Internet,  preferred for everyone, d. H. without registration. In the In step S2 and S3, this order book is filled with data or data records ("orders") a WDB securities database. This is in particular for securities offers and related information such as countervalue or shares Price, number of securities offered, business information, time permanent information, etc.

If the first user wants to respond to an order, he can match one Press the button, e.g. B. by clicking a button and / or link. so then it is checked in step S4 whether the first user is properly registered is. This check happens z. B. by entering a user ID and one Passwords with user information stored in the BDB user database be compared. If there is no proper registration (no in Step S4), the process returns to Step S2. However, there is an order appropriate registration (yes in step S4), an order is created in step S5 solution. Here, the first user must provide details of his offer give, such as type of offer (sale / purchase), security, number, equivalent, part business information, duration, etc. The order entry is preferred by entering an offer confirmation, e.g. B. by querying and entering user zerID, PIN, TAN, confirmed.

In step S6 it is then checked whether there is a sell order. If the offer is a sales offer (yes in step S6), a check is carried out in step S7 to determine whether the number of securities or orders (number of existing securities) in a securities account of the first user and / or absolutely in the entire securities portfolio is sufficient, ie whether this number of existing securities is greater than the number of securities or orders in the offer (number of offer securities). If the number of existing securities is too small (no in step S7), the order entry process returns in step 7 . If, on the other hand, the number of existing securities is sufficiently large (yes in step S7), then in step S8 the order is recorded in the securities database WDB and / or in the user database BWD and / or the order of the first user is set in the order book.

With step S8 the setting of a new order or an offer of the first user completed.

A second user ("User 2 ") can view the order book in step S10, similar to steps S1 and S2. If he is interested in an offer, he can by pressing an appropriate field, z. B. by clicking a button and / or link to the offer. For this purpose, a check is then carried out in step S11, similar to or identical to step S4, to determine whether the second user is properly registered. If it is not properly registered, the process returns to step S10 (not shown). If, on the other hand, the second user is properly registered, an order entry is carried out in step S12, in a manner similar to step S5. It is then checked in step S13 (similar to step S6) whether the submitted order is a sell order. If this is the case, it is checked in step S14 (similar to step S7) whether the number of existing securities is sufficient. If this is not the case, the method returns to step S12 (not shown). On the other hand, if the order is not a sell order but a buy order (no in step S13), or if the number of existing securities is sufficient (yes in step S14), the method proceeds to step S15.

In step S15, a blocking of those corresponding to the securities transaction Securities. For this, the corresponding securities or Order in the WDB securities database and the corresponding entries in the Be user accounts automatically identified in the BDB user database, e.g. B. by setting a blocking flag. Furthermore, the blocked securities in the Order book e.g. B. by changing their color and / or by a blocking notice mar kiert.

Successors will continue to automatically generate an acceptance file in step S16, which contains data or data records that the expected and to be executed Contains bank orders. This acceptance file can preferably be a DME file and / or have an ASCII text file which is used to carry out a Securities transaction corresponds to transfer UE1. Preferably points the acceptance file contains a transaction information or number which is unique  for the respective securities business and is assigned to it. This The acceptance file is preferably stored and / or a checking device made available

Subsequently, an intermediate account ZK is checked in step S20 the checking device performed whether a movement or a transfer is noted on the intermediate account ZK. The review will by periodically or continuously retrieving information from the intermediate account ZK. As an alternative or in addition, it is also possible for the intermediate account to a change automatically a corresponding information to the review tion device transmitted.

The intermediate account is preferably kept at a bank (external), so that the did neuter settlement of the securities business, d. H. the corresponding payments, be done by this bank.

The second user now transfers an amount to the intermediate in step UE1 ZK account, so the information of the transfer to the verification direction, in particular in the form of a DTA file UE1-DTA. The review The processing file then checks whether the transfer made actually corresponds to the value pa pier business corresponds, by checking the amount deposited, wel correspond to the equivalent value of the securities transaction plus a commission got to. It can also be checked whether the transfer information is further In contains formations such as B. the transaction information. A is also possible Sending through the intermediate account ZK a file UE1-DTA and a receipt this file UE1-DTA through a bi- or multidirectional network, e.g. B. on the Inter net, whereby the file contains all payment and outputs on the intermediate account (e.g. in Standard S.W.I.F.T. MT 940) contains.

Corresponds to the movement on the interim account ZK by the security stock expected movement, especially the paid or transferred Amount sufficient, a transfer of the equivalent value of the Securities business to the first user, preferably by generating  a DTA file UE2-DTA, so that the incoming payments on the intermediate account are at least partially forwarded to the first user. In other wor the amount corresponding to the securities transaction is calculated via the intermediate account forwarded to the account of the first user when the amount of it Waiting for payment.

Furthermore, the securities transaction is processed in step S21, namely through Adjust the corresponding data in the user database BDB and the value WDB paper database adapted (User's Profile, Last Price, etc.). The correspond de securities accounts in the user database BDB of the two users in particular decremented accordingly. In the settlement step the corresponding blocking of the securities of step S15 is also lifted.

In FIG. 5, the transfers were explained using an example in which the first user places a sales offer, and assumes the second user Ver this purchase offer. If, on the other hand, the first user places a purchase offer and the second user accepts this purchase offer, the transfers are carried out accordingly in reverse.

In FIGS. 6A through 6M "screenshots" are known. Shown which settings the Bildschirmdarstel of a practical execution of the method according approximate shape of a preferred exporting the invention exhibit, with respect to the quotation and responding to orders on a trading platform according to an embodiment of the Invention.

Can be used in the screen of FIG. 6A, a list of companies is shown (in the example, only the company "ISSP AG"), the Ge on the corresponding platform is to be. With a click on the reference or pointer or link "act!" one arrives at the so-called "open order book" from FIG. 6B (cf. step S2). By clicking on the "Create purchase offer!" you can create a purchase offer (see step S5). This triggers a registration check (cf. step S4), which is carried out using the page shown in FIG. 6C. To do this, you must first identify yourself as a registered user. A confirmation of the user data is requested on the screen area of FIG. 6D. By clicking the button "Confirm!" one arrives at the screen shown in Fig. 6E, in which one can submit the actual offer (in the example setting a purchase offer of 5 shares for EURO 10), according to an order creation or entry (see step S5). The offer is confirmed in FIGS. 6F and 6G by entering the PIN and TAN (offer confirmation). At the same time, the conditions for the securities business are also displayed. The tender submitted is confirmed by the trader edition shown in Fig. 6H. The order thus correctly entered now appears in the order book, as can be seen in FIG. 6I (cf. step S8).

If a second user now wants to respond to the offer created, the second user can first obtain information about the first user in order to get an idea of its seriousness. The second user can thus first view the activity of the first user, specifically by clicking on the header symbol, the user profile with the number of securities transactions successfully completed on the platform can be viewed (in this case 20 ), see FIG. 6L.

If the second user wishes to respond to the offer by clicking on the "Create purchase offer!" Button, his / her personal data is checked (cf. step S11), cf. Figure 6M. Then the second user arrives by clicking the "Confirm!" Buttons to the actual page of Fig. 6N for order entry (see step S12). In this example, he places an order "Buy a share at EUR 100.15". By clicking the "Confirm!" Buttons ge he gets to a confirmation page according to FIGS. 6O and 6P, where he has to enter his PIN and TAN for confirmation.

The number of successfully executed trades is only adjusted when the business has been settled, ie when the corresponding amount of money has been received on the interim account ZK, see Fig. 6Q.

More so-called. "Screenshots" are shown in Fig. 7A to 7I which the on-screen representations of a practical execution of the method according to a prior ferred embodiment of the invention exhibit, with respect of creating an offer for sale and to respond to an offer to purchase.

In both cases, the intention of the user to sell shares is. The process follows the same principle, with the difference that here the Da Bank query is interposed, causing a sale of shares that are not in stock (short sale) is prevented and a corresponding Error message is triggered automatically.

In the following the process is carried out up to the step leading to the termination leads because there are not enough shares in the portfolio.

In Figs. 7A to 7D a sales offer is created (cf. Step S5), however, a security number is offered, which exceeds that of the own securities account. Accordingly, an insufficient number of securities is determined in the checking step S7, by comparison with the data stored in the user database BDB. Accordingly, the entered order (sales offer) is rejected and a corresponding error message from FIG. 7E is generated automatically.

In a similar manner, a user in Figs. 7F through 7H would like to respond to a purchase offer without having a sufficient number of securities available (either because the total number is too small or because some of the existing securities are blocked are, see step S15). Here, too, the order is automatically rejected and a corresponding error message is generated, cf. Fig. 7I.

Claims (29)

1. A method for the automatic recording and settlement of a securities transaction, which comprises the following steps:
Detecting (S5) an offer of a first user for a securities transaction;
Detecting (S11) an acceptance of a second user of the detected offer;
Checking (S20) an intermediate account (ZK) whether an equivalent value corresponding to the offer and the acceptance has been recorded; and
Settlement (S21) of the securities transaction by transferring or matching the securities corresponding to the offer between a securities account of the first user and a securities account of the second user, if in the verification step (S20), a corresponding countervalue on the intermediate account (ZK) was recorded, and
Checking (S14) whether the number of securities in a securities account of the first user is greater than the number of securities in the securities transaction,
whereby the securities of the corresponding securities transaction are blocked (S15) until settlement (S21) and at least temporarily no further securities transaction is accessible. 2. The method of claim 1, further comprising a step of recording (S8) the recorded offer in a securities database (WDB) and / or the An show (S3; S10) of the detected offer on a display device. 3. The method according to claim 2, wherein in the offer display step (S3; S10)  the corresponding security, an equivalent value corresponding to the security, a number of securities corresponding to the offer, one last offered Countervalue and / or partial business information is displayed. 4. The method according to any one of the preceding claims, wherein the step of detecting the acceptance (S12) comprises the following steps:
Selection of the corresponding offer within the securities database by the second user and
Capture a confirmation of acceptance from the second user. 5. The method according to any one of the preceding claims, wherein the first user zer in the offer entry step (S5) the offer a partial business or Assigns denomination information, which shows whether and preferably how recorded offer may be divided into an acceptance of only a part of the securities transaction by the second user. 6. The method of claim 5, wherein the acceptance detection step is an input ben the number of securities, insofar as the offer includes partial transaction information on is assigned. 7. The method according to any one of the preceding claims, wherein in the Ange bot detection step (S5) and / or in the acceptance detection step (S12) Identification (S4; S11) of the first or second user by recording Be user data and a comparison of the recorded user data with in a user zerdatenbank (BDB) stored user data takes place. 8. The method according to any one of the preceding claims, wherein the Ange bot detection step (S5) a step of assigning time information to the Offer, wherein the time information corresponds to a period of time during de The entered offer is valid. 9. The method according to claim 8, wherein in the offer display step (S3; S10) an offer that has expired is not displayed.   10. The method according to claim 8 or 9, wherein the acceptance detection step (S5) has a step of checking the duration of the accepted offer whether the duration of the accepted offer has not been exceeded. 11. The method according to any one of the preceding claims, the assumption step of assigning a transaction number for the corresponding one Securities business. 12. The method according to any one of the preceding claims, wherein the intermediate account checking step (S20) receiving a transfer file (UE1-DTA) from a financial institution, which transfer file (UE1-DTA) a success transfer (UE1) of the equivalent value for the securities transaction equivalent. 13. The method according to claim 11 and 12, wherein the transfer file (UE1- DTA) contains the transaction number. 14. The method according to claim 12 or 13, wherein the transfer (S21) of the or of the securities after recording the transfer file, preferably after receipt and Comparison of the transaction number is made. 15. The method according to any one of the preceding claims, wherein the intermediate account checking step (S20) a step of a comparison or comparison of a a transaction corresponding to a transaction recorded in the intermediate account (ZK) onsdatsatzes (UE1-DTA) with one in the acceptance detection step (S12) er witnessed acceptance data record (S16), the acceptance data record (S16) preferably to instruct a movement or transfer (UE1) on the Zwi schenkonto (ZK) is used.   16. The method according to any one of the preceding claims, wherein the Annah sea acquisition step (S12) a step of generating a data record (S16) has, which is preferably automatically transferred to a bank, the Record preferably contains the transaction number. 17. The method according to any one of the preceding claims, wherein the Ange bot detection step (S5) has a step of checking (S7) whether the requested offered number of securities is available by comparing an offer Bid securities number with one on the first user's securities account number of stored securities. 18. The method according to claim 17, wherein if the number of offer securities exceeds the number of existing securities, the offer is automatically rejected and an error indicator ( FIG. 7E) is generated. 19. The method according to any one of the preceding claims, wherein the Ange bot detection step (S5) a step of detecting a purchase offer and / or has a step of capturing a sales offer. 20. The method according to any one of the preceding claims, wherein the Abwick step (S21) comprises a step of updating user data where in the case of the user data, a number of value pairs successfully carried out is preferred transactions and / or a volume of the securities transaction successfully carried out shafts. 21. The method according to claim 20, wherein the user data of the first user can be displayed to the second user, preferably on request ( FIG. 6L). 22. Computer program for the automatic recording and processing of a value paper business, which program parts to carry out a procedure according to one of the preceding claims.   23. Device for the automatic recording and settlement of a securities transaction, which has the following features:
a first input device for entering or capturing an offer of a first user for a securities transaction;
a second input device for inputting or detecting an acceptance of a second user of the detected offer;
an internal or external intermediate account (ZK), on which the countervalue is to be recorded or paid;
a checking device for the intermediate account (ZK) to check whether the equivalent value recorded in the intermediate account corresponds to the acceptance by the second user;
a user database (BDB) with storage areas for the respective user-assigned securities accounts;
a settlement facility that processes the securities transaction by switching or matching the securities corresponding to the offer between the securities account of the first user and the securities account of the second user if the verification facility determines an equivalent value on the intermediate account (CC) that corresponds to the acceptance and the settlement device transmits a corresponding signal or command, and
a number-of-securities checker to verify that the number of securities in a first user's securities account is greater than the number of securities in the securities business,
a blocking device for blocking the securities of the corresponding securities transaction until the securities transaction is processed, so that the securities are at least temporarily not accessible to any other securities transaction. 24. The apparatus of claim 23, further comprising a securities database (WDB) in which the offer and / or the acceptance and preferably knows more information about the offer or acceptance, such as a security corresponding countervalue, a number of securities corresponding to the offer,  partial business information is stored. 25. The apparatus of claim 23 or 24, further comprising a first da ten generation device, which has a first data set or a file generated which corresponds to the acceptance by the second user. 26. The apparatus of claim 23, 24 or 25, wherein a second data generating device generates a second data record or a file, which or which corresponds to the entry of a movement in the intermediate account. 27. The apparatus of claim 25 and 26, wherein the checking device has a matching device, the first and second data set or file compares and generates a corresponding command of the processing device. 28. A system for the automatic recording and settlement of a securities transaction, which comprises:
a device according to any one of claims 23 to 27;
a first input unit for inputting or capturing the offer of the first user for a securities transaction;
a second input unit for inputting or detecting the acceptance of the second user of the detected offer;
wherein the first and second input units are connected to the first and second input devices via a bi-directional or multi-directional network, in particular via the Internet. 29. The system of claim 28, wherein the external intermediate account and the over testing facility via a bi-directional or multi-directional network, in particular via the Internet connected.