MXPA97008581A - Transaction recovery in a valo transfer system - Google Patents

Abstract

A system of transfer of securities to transfer the value in the transactions between electronic funds as electronic cash and has a procedure of recovery of transaction failure whereby a pending record stores the transaction messages after they are sent. During the detection of an error, an interface device (IFD) can issue a payment resume command to resend the last transaction message and resume transaction.

Description

"RECOVERY OF TRANSACTION IN A SYSTEM OF TRANSFER OF SECURITIES" The invention relates to a system for transferring securities for transactions exempt from cash and in particular for the recovery of failed transactions. The value transfer systems have been proposed to allow the exchange of money values between "electronic funds". These systems are described, for example, in International Patent Publications Nos. WO 91/16691 and WO 93/08545. Unauthorized tamper-proof carriers such as integrated circuit cards (ICC), otherwise known as "smart cards", are incorporated into microprocessors and electronic memories if they carry electronic funds. Strictly speaking, electronic funds are computer "applications" that consist of programs and associated data and smart cards are an example of an application bearer device (ACD). In order to exchange the value between the electronic funds the cards (ACD) carrying the respective funds are put into communication through one or more of the interface devices (IFD). For example, in the charge value, or "electronic cash" in your bank's fund, a customer will enter their card into an automatic paying machine (ATM) associated with the bank. The ATM is an interface device that is coupled with the ACD that carries the bank's electronic fund. The interface device (IFD) exchanges information between the fund and the electronic cash required to transfer from the bank's fund to the client's fund. This is an online transaction as it relates to the bank. Another form of interface device is a point-of-sale (POS) terminal at an outlet of the retail merchant. Here the customer can enter their card in the terminal, thus connecting their electronic fund with that of the retail merchant. Goods can be purchased by transferring electronic cash from the customer's fund to the merchant's fund. This is an off-line transaction as it relates to the bank. Remote transactions are also possible, where two background carrier cards are introduced into the respective interface devices that communicate with one another through odems and a communication network. In this way, the value can be exchanged in transactions over the telephone or on the Internet, for example.

A transaction, typically for exchange of values, consists of the exchange of a number of messages between the funds in accordance with a predetermined protocol. It is possible that the message sequence is interrupted due to a number of reasons. There may be equipment failure, power loss or message corruption, due to electrical noise or difficulty of synchronization, for example. Most network systems have error correction facilities at the modem level. Even so, there is a potential for a transaction to fail due to the interruption of the message sequence of the transaction. The present invention investigates to provide a system having facilities for recovery so that interrupted transactions are completed. In accordance with the invention, a value transfer system comprising a plurality of electronic funds is provided; a plurality of application carrying devices (ACD) to carry the electronic funds; and a plurality of interface devices (IFD) for coupling together pairs of the ACDs to enable the transfer of securities transactions between pairs of electronic funds, wherein a transaction between a pair of electronic funds in the ACD is carried out. by means of an IFD it comprises an exchange of transaction messages in a sequence of compliance with a predetermined protocol, each transaction message is sent from an electronic fund of a pair of IFD and from the IFD to another electronic fund of the pair, storage means are provided for storing the transaction messages after they are sent, and the IFD is effective for invoking a recovery procedure if the predetermined sequence of transaction messages fails, the recovery procedure comprises the step of deriving the storage medium the last sent transaction message and sending it again to resume the sequence. Preferably, each electronic fund includes a pending record that retains the details of the present or last transaction, the pending records of said pair of funds constituting the storage means. In addition, it is preferable that each electronic fund has a section record that is a storage of the details of the transactions that have failed, the contents of the pending record being copied into a record in the exception record during the failure, to retrieve a transaction what has failed. The recovery procedure may include a trial method, with the IFD being effective when following this method to: (a) interrogate a first electronic fund of the pair to derive its pending record from the last transaction message sent; (b) send that transaction message to the other electronic fund of the pair, to resume the transaction; and if this results in an error; (c) interrogating the other electronic fund of the pair to derive from its pending record the last transaction message that was sent; and (d) sending that transaction message to the first electronic fund of the pair to resume the transaction. The scoring method can result in the sending of superfine messages and in some situations it may be better to use a more structured predetermined recovery method. In this, the IFD is effective to: (a) interrogate both electronic funds of the pair to determine from their pending records which electronic fund has advanced the most in the transaction that has failed; (b) interrogating the electronic fund that has further advanced in the transaction that has failed to derive the last transaction message it sent from its pending record; and (c) sending that transaction message to the other electronic fund of the pair to resume the transaction.

Instead of, or in addition to storing the transaction messages in the pending records in the electronic funds, the message can be stored after being sent in a buffer in the IFD. Then the IFD does not need to recover the last message sent from the electronic funds. Many of the transaction failures will be transient and preferably then the IFD is effective to invoke the automatic recovery procedure and immediately in a transparent manner to the users. Sometimes, however, a transaction can be interrupted more significantly, for example by removing a card from an IFD, for example. Then, a procedure for the delayed recovery of transactions is necessary and a preferred provision is that the IFD must interrogate the electronic funds at the beginning of a proposed transaction in order to determine if there is a transaction that has failed pending among those funds, which it may be able to resume so that a delayed recovery procedure can be initiated. The invention will be further described with reference to the accompanying drawings, of which: Figure 1 is a schematic diagram of a value transfer system according to the invention; Figure 2 is a schematic diagram of an arrangement of the point of sale terminal of the system of Figure 1; Figure 3 is a diagram illustrating remote communication between electronic funds; Figure 4 is a diagram showing the records in the electronic background of the system of Figure 1; Figure 5 is a diagram illustrating the flow of command messages and response transaction in a typical value transfer transaction at a point of sale terminal in the value transfer system; Figures 6 to 8 are diagrams showing the flow of response command and transaction messages in three respective examples of immediate automatic implementation of the transaction recovery procedure in the securities transfer system; Figure 9 is a digram showing the flow of response command and transaction messages in the implementation of a predetermined and delayed recovery procedure in the value transfer system; and Figure 10 is a diagram showing the flow of command and response transaction messages in the implementation of a predetermined and delayed recovery procedure in the value transfer system. Referring to Figures 1 and 2, the value transfer system according to the invention is an electronic cash money system of the kind described in International Patent Publications Nos. WO 91/16691 and WO 93/08545. Each of a number of smart cards 1 is an application bearer device (ACD) having a microprocessor, a RAM or a ROM that is of the electrically erasable programmable type (EEPROM). Electronic funds are applications in the ACD that hold programs and data including valuable data that is electronic cash. The electronic cash is transfered from bottom to bottom by coupling the respective ACDs electrically together through one or two interface devices (IFD) and exchanging messages of the transaction. The messages take the fof commands issued by the IFD and the responses provided by the funds. The responses include a message of transfer of values whereby a register of values in the electronic payer fund is decreased by an amount and that in the electronic fund of the beneficiary is increased by the same amount. As described in the international patent publications mentioned above, electronic funds and transaction messages are secured by a cryptographic public / secret-code system. One fof DFI is a personal "portfolio" that has two slots to accept the respective DTAs and controls the transfer of funds between the electronic funds in it. Figure 2 shows a portfolio IFD 5 that has two lc smart cards, Id inserted. The IFD has a screen 6 and a keyboard 7. Internally, the IFD has a microprocessor 8, a RAM 9 and an EEPROM 10. Within RAM 9 there are two buffers 11, 12. Each buffer is a portion of the memory which retains the transaction messages after they are sent from the IFD respectively to the ACDs lc and Id. An alternative arrangement is to provide a single buffer retaining the last sent message, independently from which of the ACDs. The memory or buffers can be in the EEPROM instead of in the RAM. Figure 2 also shows the ACDs comprising microprocessors 13c, 13d; RAM 14c, 14d; and EEPROM 15c, 15d. An example of a securities transfer transaction is the charging of electronic cash in an electronic fund of the customer from a bank such as bank 16 in Figure 1. Here, the IFD that couples the customer's ACD with the bank's ACD it is an automatic payment machine 17. Now the customer can buy merchandise or items from a retail merchant by presenting his ACD to a POS point of sale terminal with which the retail merchant's ACD is also attached. A transaction to transfer the value of electronic cash can be initiated. This is an offline transaction as it relates to the bank. Retail merchants can deposit the accumulated electronic cash in their own banks through additional transactions, either in a type of automatic payment machine type or by telephone as illustrated schematically in Figure 3. Here, the ACD of the merchant retail is coupled with an IFD 18 which is a combined card and modem reader. This is connected via telephone with an IFD 19 at the retail merchant bank which is again a combined modem and card reader that is coupled with the bank's ACD Ib.

Figure 4 schematically illustrates part of the EEPROM 4 of an ACD that retains the electronic fund data keeping three records of a payment: The details of the current or last payment are retained in a pending register 20. When the payment has reached a critical point but is still not completed, the payment is eligible for recovery. While the details remain in the pending record, most of the recent payment protocol message that was sent through the fund during this payment (if any) may be recovered again. This critical point occurs during the successful processing of either a command for the Beneficiary to Begin Payment (in the beneficiary's fund). A command for Payment Request (at the bottom of the payer). A payment retained at this stage may be eligible for recovery. There is only one pending record. An exception record 21 stores the details of the payments that failed to complete successfully but can no longer be recovered. Entries in this record are never overwritten, but can be cleared by a back-end provider (eg, a bank). Payments can not be made when the exception record is full.

A payment record 22 maintains the details of the last satisfactory payments. If it is a circular record: when it is complete, the oldest entry is overwritten with details of the new payment. As soon as you change the balance in a fund, a payment record is created. This happens during the handling of the Payment Request (in the payer's fund) or a Payment Value (in the beneficiary's fund). In the case of the payer fund, in this stage, the payment record is marked as incomplete. (In the beneficiary's fund, the payment has now been completed effectively, since no additional messages are expected). Each transaction between the electronic funds consists of a set of command transaction messages generated by the IFD and corresponding to the response transaction messages generated by the respective electronic funds. The electronic fund and the IFD programs follow a predetermined sequence of command and response. If the sequence is disturbed by a fault or interference of a certain kind, then the transaction will be stopped with an "out of sequence message" error. A normal command and response sequence will now be described. The commands are described in three games: pre-payment, payment initiation and payment protocol controls. The technique in general is that the pre-payment and initiation of payment commands are issued which are prepared for payment, and these are followed by a flow of minimum payment protocol messages that normally must be completed without failure that only occurs when all the pre-testing has been carried out. Pre-Payment Controls Fund Registration and Registration Orders These are issued by an IFD to obtain the different items of information from the bottom. The information includes the lengths of the variable length data elements. The Background Registration command provides the length of the Register command response and a memory write flag. The response to the Registration command provides: Configuration Information about the Fund Application, such as how many bags the fund contains, the capacity of the payment and the exception records, and the allowed number of personal code tests. The current status information, indicating the number of exception records not used, the current count of the number of consecutive incorrect personal code tests made, and the degree to which the internal memory is downloaded (expressed as a percentage).

A character game code, indicating the character set used for the narrative background. The Registry command also indicates whether there is a previously attempted payment that has failed to complete that is eligible for recovery. This will be discussed later. Payment Registration Command This provides information that will be supplied to the counterpart fund in the Payment Initiation command. The information can also be used by the DFIs. Payment Initiation Controls There are two variants: Payment Initiation Payroll and Payment Initiation Beneficiary. The controls are similar, but only the Payment Initiation Beneficiary returns the information in its response. Payer of Payment Starter This is directed to the payer fund. Provide the fund with details of the payment to be made (address, value and currency) and the counterpart fund. The fund then checks (not necessarily in this order) that: There is a bag for this currency, which contains sufficient funds for payment; There is a free element in the exception record to retain the details of the payment, if a failure occurs; The two funds have different background identifiers. (This should always be the case); The beneficiary's fund class is in this fund class list; The background is not blocked or unlocked. If these checks are successful, and there is a previously incomplete payment in the pending record, it moves to the exception record. If the exception record is now complete, the payment can not continue. The command results in a response of the current state. If all the checks are successful, the details provided are stored and the subsequent payment protocol controls must be based on the same information. The currency of failure for the fund is now the one announced for this payment. The payer fund is now waiting for a Payment Request command. Beneficiary of Initiation of Payment Regarding the Payment Initiation Payer, this command provides the fund with details of the payment to be made (address, value and currency) and the counterpart's fund.

The fund then checks (again, not necessarily in this order) that: The fund can handle a payment in the indicated currency (if it is a supported currency, and if there is a bag that can be used for the currency); Payment will not cause the value limit of the currency to be exceeded; There is a free element in the exception record to retain payment details if a failure occurs; The two funds have different background identifiers. (This must always be the case); The background is not unlocked. If these checks are successful, and there is an incomplete payment previously in the pending record, it moves to the exception record. If the exception record is complete, the payment can not continue. If all the checks are successful, the details provided are stored, and the subsequent payment controls must be based on the same information. If an appropriate bag is assigned to the specific currency, this becomes a currency of failure for the fund. The data in the response is a Payment Request signature that is used as the data for a Payment Request command at the bottom of the payer. Payment Protocol Controls The payment protocol controls include the three commands that transfer the value from one fund to the other: Request for Payment, where the beneficiary's fund requests the value; The Payment Value, where the payer's fund sends the value; Payment Acknowledgment, where the beneficiary's fund recognizes the payment. The sequence is implemented in a more complicated way, because the funds do not communicate directly with one another through an IFD (or multiple IFDs). It works as follows: The data for Payment Request is obtained in response to a command from the Beneficiary of Payment Initiation sent to the beneficiary's fund. It is changed in a command, and sent as a command of Payment Request at the bottom of the payment; The payer fund responds to the Payment Request message with a Payment Value message. This is sent as a Payment Value command to the beneficiary's fund; The beneficiary's fund responds to the command of Payment Value with a Payment Acknowledgment message.

This is sent as a Payment Acknowledgment command at the bottom of the payer. The payer fund responds with the current status information. The normal sequence of commands and responses in a payment transaction is shown in Figure 5. In this Figure, the text in the boxes represents commands and the arrows indicate responses (data flow). It is possible that a technical failure manifests itself during a transaction. For example, a transaction message may be corrupted, the power supply may be broken or interrupted, or an ACD may be removed from an IFD. Some of the faults can be transient and others more considerable. The present invention provides ways to recover interrupted transactions. The recovery can be either immediate (as soon as a failure is detected) or delayed (when the funds are resubmitted to the DFIs after the payment has failed). Within these types of recovery, there are two other possible ways for DFIs to work to obtain a recovery: The test method or based on direct knowledge of the exact status of the payment is in: the DFIs then continue with the payment (the method of trial and error is applied and the Failure occurs when a message has been sent to a fund if a response is not received The IFD will not know if the fund has received and processed the message, if so, trying to resend the message may result in an error message In some cases, recovery may not be appropriate - payment may have already been completed successfully); Default: when the DFIs investigate securities returned from funds and can then determine which fund should send a Payment Remand command in order to recover the payment. When both funds are local to an IFD, the tentative recovery may be more appropriate since the total expense of issuing the wrong command initially has no chance of being important. In cases where two remote IFDs are involved, it may not be ideal to a tentative approach since it can be a waste of messages through the communication link. Instead of using the trial method, the DFIs can use the default recovery method. Note that the default recovery mechanism can be used in any circumstances (not just for remote recovery). There is also a need for users to be informed that a previous failure has occurred so that they can invoke recovery if appropriate.

The following illustrations are based on the immediate recovery of payments when both funds are local to the IFD. Figure 6 shows a sequence in which: A. The IFD fails to receive a response to the Payment Request command sent to the Payer's Fund. B. The IFD sends the Payment Request to the Payer's Fund again. C. On the second attempt, the IFD receives a Payment Value message from the Payer's Fund. (In this case, the Payment Request has not been previously processed by the Beneficiary's Fund). In this example it will be noted that the IFD retains the transaction messages in the buffers after they are sent. The buffers are illustrated in Figure 2. Figure 7 shows a sequence in which: A. The DFI stops receiving a response to the Payment Request command sent to the Payer's Fund. B. In this case, you have not retained the message of Request for Payment, and therefore send an Extract of Payment to the Beneficiary Fund to recover the Payment Request. C. When sending the Request for Payment to the Payer's Fund for the second time, the Payer's Fund satisfactorily returns the Payment Value. (As with Figure 6, it is successful because the Payer Fund has not received and processed the Payment Request on the first attempt). Figure 8 shows a sequence in which: A. The DFI stops receiving a response to a Payment Request command sent to the Payer's Fund. B. Send the Payment Extract to the Beneficiary Fund to retrieve the Payment Request message. C. When sending the Payment Request to the Payer a second time, the Payer's Fund responds with an "out of sequence message" because it has previously processed the Payment Request. D. The IFD then issues an Extract of Payment to Payer Fund to obtain the Payment Value message that you have not received the first time. An additional example, not shown, is when there is a recurring error in the interface between the IFD and a background. For example, the IFD sends a Payment Value message to the Beneficiary Fund and does not receive a valid response. Retrieves the Payment Value from the Payer's Fund, repeats the sequence for a predetermined number of times but without success and then stops, warning the user of the failure.

Pre-determined recovery Before describing how DFIs can recover a payment in a predetermined way (instead of using the method of trial and error), it is necessary to explain how a fund indicates to DFIs the stage it has reached in the payment. The following fields of recovery management data are used to indicate this: a. Flag of failure of payment, in the response of the Registry. This can adopt the values of: no failure fails the beneficiary's fund (note that this does not necessarily indicate that a failure has occurred in the beneficiary's fund) failure of the payer fund. b. Flag of outstanding exception, in the response of the Registry. This can adopt the values of: no outstanding exception pending exception present. c. Payment stage failed, in the response of the Payment Register that Failed.

The values of this field depend on the implementation. However, DFIs can use this field to determine which fund has advanced the most in a payment: the higher the value, the more progress the fund has made. There are four logical values, to which reference is made in the present, VI, V2, V3 and V4, where 0 < = VI < V2 < V3 < V4 < - 255. Under some circumstances, the fund will not return to any of these securities, but will respond to a Payment Registration command that has Failed with the error "unable to resume payment". Depending on these values, the IFD can predict if the payment resumption will work but can not necessarily predict which Payment message will be made Regress because you do not know the actual values associated with VI, V2, V3 and V4. The following fields are also necessary in order to verify that this is the same pair of funds that was involved in the failed payment: d. The Fund ID of the counterpart of the payment record response that has failed. and. The sequence number of the counterpart of the answer of the Payment Record that has Failed. Figure 9 shows the sequence of commands and responses in a predefined recovery procedure. The steps are: A. Send a Registration command to each fund, and inspect the flag of payment failure in the response message. If one fund returns the failure of the payer fund and the other returns the failure of the beneficiary fund, then recovery may be possible. B. I sent a Payment Registration command that has Failed to each fund. If each answer contains the PID of the other background, and if the sequence numbers match, then recovery is possible. C. I sent the Renew Payment to any fund that reports the highest value of the failed payment stage. D. I sent the response of the Payment Resumption in one command to the other fund and then continued with the payment. It should be understood that the default recovery can be initiated during a transaction that has failed automatically during the detection of a failure. Likewise, the checks and resumption of the transaction, if appropriate, can be part of the normal transaction protocol. Therefore, at the beginning of each transaction, the funds are checked and, if possible, a pending transaction is completed before the next transaction is made. A special protocol is required when transactions are carried out remotely between electronic funds each having its own IFD, as illustrated in Figure 3, for example. Here, there is the IFD-IFD message flow and a so-called Virtual ACD Protocol is used. This protocol allows an IFD to send commands to a remote or remote ACD through a remote IFD. Any IFD can do this. The IFD that receives this command can either: pass the command through the ACD without inspecting it, or pass it to the ACD if it is acceptable, and interpret the message and any response, or return an error ("the message can not be processed") ), or - re-interpret the command, and handle it as if it were an IFD-IFD message. The IFD that issues the command is known as the "master", and the IFD that receives the command is called here as the "subsidiary". During the transfer of the value, as will be discussed below, there is an agreement that a transfer of the value involving two DFIs is initiated by an IFD-IFD Initiative Value Transfer command, and that after this command there is an understanding about which IFD is the "teacher" and which is the "subsidiary". However, an IFD may have to handle the case where a virtual ACD payment command is received outside of this scheme. (In theory, due to the full duplex link between the DFIs, there could be an attempt to intersperse two transfers of values in opposite directions, so that each DFI is at the same time the master for one payment and the subsidiary for the other. be permissible if different funds are involved). When transferring remote securities, both DFIs must be able to determine the current status of the payment transaction justly carried out. It is easy for the teacher to do so as long as he knows what is happening through the transfer of values. All DFIs always supervise and prevent the issuing of Paid Initiation Payers from a remote IFD. For the subsidiary IFD there are three options: (1) Examine all messages before they are passed on to the ACD, and all the responses so that at the end of payment can be reported exactly what has happened, or (2) monitor the Payroll Beneficiary commands: to reject all but the first of these commands that follow an Initiation Value Transfer command: and to read and compare all the values of the fund's stock before and after payment, so that payment details can be made known; or (3) To supervise the Payroll Beneficiary's controls; to allow each payment to continue; and to read and compare all the values of the fund stock before and after each payment (such as for option (2)) so that the details of the payment can be reported. In options (2) and (3), the command data of the Beneficiary of Initiation of Payment can be interpreted to determine the details of the payment, instead of to compare the values of the stock exchange. It is not considered appropriate for the beneficiary's IFD to compare the values of the stock market before and after a payment and then look at the last record of the underlying transaction to determine what has happened, since without identifying the controls of the Beneficiary of Initiation of Payment The IFD can not reliably then determine the number of transactions that have occurred. Supervision of all controls (the first option) can be said to protect the card holder to the maximum extent. For example, you can provide the option to reject a payment that is not compatible with the previous command of Transfer of Initiation Value; or it can be used to prevent an unauthorized attempt to unlock a remote fund. However, the options that do not depend on the interpretation command headers or the data in the Payroll Beneficiary's commands, provide the best proof of future against changes in the system. (The subsidiary IFD does not need to be at the same level of system software release as the teacher, but the DFIs can still interwork). Figure 10 shows a typical message sequence involved in the delayed retrieval of a payment where the two funds that were involved in the original are now distant one from the other. The steps are the following: a. The users (payer and beneficiary) agree to carry out the recovery, and ensure that the appropriate games are available to their respective DFIs. b. One of the users (in this example, the beneficiary) asks your IFD to start the recovery. c. The beneficiary's IFD issues appropriate local controls to its fund, including the Register and the Payment Record that has Failed. If the Register's flag of payment failure is "no failure", or if the Payment Record that has Failed indicates "unable to resume payment", informs the beneficiary that recovery is impossible. d. If all is well, the data of the failed payment and the Fund ID send in an Initiation Recovery command to the other IFD. and. The payer's IFD selects an appropriate fund according to the fund ID of the specified counterparty of the payment data that has failed from the Initiation Recovery command. Having found this, it issues appropriate local controls to its fund, including the Register and the Payment Record that has Failed. If any of: the flag of failed payment returned from the Register indicates "no failure", or - Payment Record that has Failed indicates "Unable to resume payment", or The Fund's Ids and sequence numbers do not match, informs the payer that recovery is impossible and returns an error response to the beneficiary's IFD. F. If all is well, return the payment data that has failed to the payer fund in the Initiation Recovery response. g. The beneficiary's IFD is now the master in the virtual ACD protocol. Compare the values of the Payment Stage that has Failed as it is returned from the two funds, and send a Payment Resume command to any fund that discovers the highest value of the payment stage that has failed. (In this example, it is the payer fund, and therefore the Payment Resume is sent to a virtual ACD command). h. The beneficiary's IFD receives a response from the Payment Resumption, in this example a Payment Value message. Send this to a Payment Value command that sends it to the beneficiary's fund. The payment then continues normally. The use of the Initiation Recovery command could theoretically initiation IFD could carry out the recovery simply by using the Virtual ACD commands. However: The subsidiary IFD could not report its intention to recover, or the result of the recovery, its user, since he would not know what is happening. - If the subsidiary IFD had more than one fund, the teacher could not in any way inform the fund which to use.

Claims (8)

CLAIMS:

1. A system of transfer of values comprising a plurality of electronic funds; a plurality of application carrying devices (ACD) to carry the electronic funds; and a plurality of interface devices (IFD) for coupling together pairs of the ACDs to allow for the transfer of securities transactions between pairs of electronic funds, where a transaction between a pair of electronic funds in the ACDs is carried out. coupled by an IFD comprises an exchange of transaction messages in a sequence according to a predetermined protocol, each transaction message is sent from an electronic fund of one pair of the IFD and the IFD to the other electronic fund of the pair, means are provided storage to store the transaction messages after they send, and the IFD is effective to invoke the recovery procedure if the predetermined sequence of transaction messages fails, the recovery procedure comprising the step of deriving the storage medium from the last message of sent transaction and re-send the same to resume the sequence.

2. A value transfer system according to claim 1, wherein each electronic fund includes a pending record that retains the details of the current or last transaction, the pending records of the pair of funds constituting the storage means.

3. A system for transferring securities according to claim 2, wherein the recovery procedure includes a trial and error method, the IFD being effective when it follows this method to: (a) interrogate a first electronic fund of the pair that derives from your pending record the last transaction message from which you sent; (b) sending that transaction message to the other electronic fund of the pair to resume the transaction; and if this results in an error; (c) interrogating the other electronic fund of the pair to derive the last transaction message it sent from its pending record; and (d) sending the transaction message to the first electronic peer fund to resume the transaction.

4. A value transfer system according to claim 2 or claim 3, wherein the recovery procedure includes a predetermined method, the IFD being effective when it follows this method to: (a) interrogate both electronic funds of the pair to determine from your pending records which electronic fund has advanced the most in the transaction that has failed; (b) interrogating the electronic fund that has advanced the most in the transaction that has failed to derive the last transaction message it sent from its pending record; (c) sending that transaction message to the other electronic fund of the pair to resume the transaction.

5. A value transfer system according to claim 1, wherein the storage means is included in the IFD.

6. A securities transfer system according to any of the preceding claims, wherein the IFD is effective to invoke the automatic recovery procedure and immediately during a transaction during the detection of a failure in the predetermined sequence of the transaction message .

7. A securities transfer system according to any of claims 1 to 4, wherein the IFD is effective to interrogate the electronic funds at the beginning of a proposed transaction to determine if there is a transaction that has failed pending between those funds You may be able to resume so that a delayed recovery procedure can be started.

8. A securities transfer system according to claim 2, wherein each electronic fund has an exception record that is a storage of the details of the transactions that have failed, the content of the pending record being copied into a record in the exception record during the failure, in order to recover a transaction that has failed.