GB2078410A

GB2078410A - Card transaction verification

Info

Publication number: GB2078410A
Application number: GB8020131A
Authority: GB
Original assignee: RACAL TRANSCOM Ltd
Current assignee: RACAL TRANSCOM Ltd
Priority date: 1980-06-19
Filing date: 1980-06-19
Publication date: 1982-01-06

Abstract

In off-line verification of transactions involving banking or credit cards, the terminal processes the account number and expiry date, from the card, together with manually-entered PID (personel ident number), in accordance with a function f1 (itself dependent on the expiry date) and compares the result with check digits from the card, to determine whether the transaction is valid. The terminal records whether the transaction is valid and disables itself if more than a predetermined number of transactions within a series of transactions are invalid. The terminal records (e.g. on magnetic tape) all the transaction information together with a checksum obtained according to a function f2 from the transaction information, serial number and validity and the tape identity, so the card issuer can subsequently detect fraudulent alteration of the tape by processing in accordance with function f2 and comparing with the checksum. The functions f1 and f2 are produced by the same algorithm controlled by respective different key information. <IMAGE>

Description

SPECIFICATION Data handling systems and methods The invention relates the data handling systems and methods, and more specifically to systems and methods for verifying encoded data. In one example of the invention to be more specifically described, it is applied to the off-line verification of information at least some of which is read off a magnetically recorded banking or credit card.

Various novel features of the invention will be apparent from the following description, given by way of example only, of a data handling system embodying the invention, for off-line verification of data involved in a transaction utilizing a magnetically encoded banking or credit card, reference being made to the accompanying drawing which is a block diagram of the system.

From one aspect of the invention, there will be more specifically described below a data processing system for processing data relating to a transaction involving the use of a user token (e.g.a banking or credit card) in which each transaction involves the reading of data stored on the user token in machine-readable form and the separate entry of identification data and of other data relating to the particular transaction, a particular part of the data stored on the token including check data for checking the separately entered identification data and related to the correct idenfitication data corresponding to that token in accordance with a first predetermined function, including data processing means responsive to the check data read from the token and the identification data and operative in accordance with a predetermined algorithm, means operative to set the algorithm to process the data in accordance with the said first predetermined function so as to verify whether or not the identification data corresponds to that token, means operative to set the algorithm to produce further check data in accordance with a second predetermined function and dependent on the data read from the token and the separately entered data relating to the particular transaction, and means for storing at least some of the data read from the token, the separately entered data, and the said further check data all for subsequent processing, whereby unauthorised alteration of the stored data read from the token or the stored separately entered data becomes detectable with high probability by comparing it with the stored further check data.

From another aspect, there will be more specifically disclosed below, a data processing system for processing data relating to a transaction involving the use of a user token, in which each transaction involves the reading of data stored on the user token in machinereadable form and the separate entry of other data relating to the particular transaction, including means responsive to the data read from the token and the separately entered data to produce check data generated according to a predetermined function, and means for storing the data read from the token, the separately entered data, and the check data all for subsequent processing, whereby unauthorised alteration of the stored data read from the token or the stored separately entered data becomes detectable with high probability by comparing it with the stored check data.

Advantageously, the separately entered data includes identification data corresponding to each user token. In such a case, the system may advantageously include means for checking whether a transaction is valid or not by comparing the separately entered identification data with data stored in machine-readable form on the user token, and in which the means for generating the check data is responsive to whether the transaction is determined as being valid or invalid.

Advantageously, the means for generating the check data includes means responsive to the serial number of the transaction within a plurality of transactions.

In addition, the means for generating the check data may generate the check data as a function of the identity of the particular storage medium.

From a further aspect, there will be disclosed a data checking system for verifying a transaction involving the use of a user token and separately entered identification data, comprising means for comparing the separately entered identification data with check data stored on the token itself in machinereadable form, and in which the stored check data is represented on the token according to a predetermined function and is dependent not only on the value of the identification data corresponding to that token but also on other data which is separately stored on the token in machine-readable form and is dependent on the identity of that token, and the predetermined function is dependent on the value of at least some of the data stored on the token.

For example, where the token is a token used for initiating a financial transaction, the said other data may be data representing the account number and the expiry date of the token. In such a case, the data stored on the token and on whose value the predetermined function is dependent may advantageously be the data representing the expiry date.

Also to be described below is a data checking system for verifying transactions involving the use of user tokens in which a record is made whether each transaction is valid or invalid and the system determines when the proportion of invalid transactions in a predetermined number of consecutive transactions exceeds a pre-set minimum.

In response to such determination, the system may disable itself.

Advantageously, each transaction also involves the use of separately entered identification data which is predetermined for each token, and the system includes means for determining, and recording, whether or not any particular transaction is valid by comparing the separately entered identification data with data stored on the token itself in machine-readable form and representing the correct identification data for that token.

Preferably, the said data stored on the token is represented thereon in accordance with a predetermined function and is dependent not only on the identification data but also on other information also stored on the token itself in machine-readable form and which is particular to that token.

In a more specific sense, there will be disclosed a data checking system for off-liine verification of the validity of a transaction involving the use of a banking or credit card carrying machine-readable data identifying the card and also involving data which is separately entered at the time of the transaction and which includes identification data, in which the machine-readable data includes check data dependent on the correct identification data for that card and on the other data on the card all represented according to a first predetermined function which itself is dependent on a predetermined part of the data on the card, and including an off-line terminal comprising means for reading data from the card, means for receiving the separately entered data, data processing means operative in accordance with a predetermined algorithm, means responsive to the said predetermined part of the data on the card to set the data processing means to operate in accordance with the first predetermined function to process the separately entered identification data with the said other data from the card to generate output data, means for comparing this output data with the check data to determine whether the separately entered identification data corresponds to that card and thereby to determine whether the transaction is valid or not valid, storage means for storing, for each of a predetermined plurality of consecutive transactions, data indicating whether or not the transaction is valid, means operative to indicate when the stored data shows that more than a predetermined number of the plurality of transactions are invalid, means for storing on a storage medium sufficient of the said data to enable the transaction to be subsequently completed, means operative to set the data processing means to operate in accordance with a second predetermined function to process the data which is stored on the storage medium, in conjunction with a serial number for the transaction, so as to generate check data according to the second predetermined function, and means for storing this check data on the storage medium to enable the associated data stored thereon to be checked.

Corresponding methods are also disclosed.

The foregoing are exemplary of and not exhaustive of the novel features of the system described below.

The system now to be desribed, by way of example, is applied to a terminal used in connection with transactions involving a magnetically encoded banking or credit card, and more specifically is applied to a terminal which verifies each transaction at the time of -.

the transaction and records the details for subsequent processing by the card issuer, that is, the system is an off-line system. It contrasts wih manual systems where the transaction is verified by means of a visual comparison between the card user's signature, which is usually carried on the card itself, and the signature which he writes at the time of the transaction. With such manual systems, each transaction involves the production of paper work which has to be subsequently processed by the card issuer.In the system now to be described, the transaction is not verified by visual signature comparison, but in a manner to be described below, and data specifying all the details of the transaction is automatically recorded in a manner which is compatible with the requirement of the card issuer so that it can be directly processed automatically by the card issuer, instead of having to be first transferred from a paper docket or the like.

The system involves the use by each card holder of Personal Identification Data (PID). At the time of the transaction, therefore, and in a manner to be described in more detail below, the card holder presents his card to the transaction terminal and also enters his PID by suitable means (depending on the nature of the PID) at the terminal. The terminal then verifies the transaction by checking that the entered PID is that which corresponds to that particular card. Full details of the transaction are then encoded and recorded for later trans mission to the card issuer.

The PID may take any suitable form. For example, it may be data in the form of numbers or letters, or a combination of numbers and letters, which the card holder enters by means of a keyboard or the like. instead, however, the PID may be of a different form relating for example to a characteristic of the card holder such as a finger print or his signature. In such cases, an appropriate means would be provided at the terminal by means of which the card holder could enter the finger print or signature or other characteristic as the case may be and which would produce corresponding electronic data by means of which the terminal would check whether the data corresponds to the particular card, thereby to verify the transaction.

As the system is operating off-line, and as it is normally impossible for each transaction terminal in a practical system to pre-store the PID corresponding to each card which is active at any time, it follows that, in order for a transaction terminal to be able to check the veracity of the PID, the PID corresponding to each card must be recorded on the card itself.

Clearly, the PID needs to be recorded on the card in a manner which minimises the possibility of an unauthorised card user ascertaining the PID from the card itself-and thus subsequently being able to validate fraudulent transactions.

Therefore, the card carries check digits which are a processed version, to a function f1, of the PID corresponding to that card. The check digits are dependent not only on the PID but also on the other data on the card, that is, the account number and the expiry date, and the function f1 is itself dependent on data on the card. In this way, therefore, the check digits are not solely dependent on the PID, and it is therefore not possible for an unauthorised user to compile a list of PID and the corresponding check digits.

For practical reasons, the PID must consist of a relatively small number of digits. For example, if the PID is a number it must be a number which is easily remembered by the card holder and in practice would be a four, or possibly six, digit number. A number with more digits than this would be difficult to remember. If the PID is a characteristic of the card holder such as a finger print or his signature, the same general limitation applies because practical considerations limit the number of digits which can be used to represent this characteristic. Therefore, there is a relatively low number of possible PID combinations for PID's of practical length.In view of this, the system is arranged to minimise the possibility of a fraudulent card user discovering the PID appropriate to a particular card by causing the terminal to carry out a large number of transactions, each with a different PID, until the correct PID for that card is obtained, as would of course be indicated by a validation of the corresponding transaction by the terminal.

The terminal will now be described with reference to the Figure.

As shown, the terminal includes a card reader 10 into which the card user inserts his card and which reads the magnetically (or otherwise) recorded data on the card. In this example, it is assumed that the data recorded on the card user's card is recorded according to ISO 3554, but it may be recorded in any suitable machine-readable manner. The card reader 10 can be of any suitable form, many examples of which are known. The data recorded on the card is in this example considered to be data representing the account number (19 digits) and the expiry date (four digits representing the month and year), together with check digits (10 digits). The data read off is fed to a switch S1 which is settable under control of a sequence controller 1 2 so as to feed the data to any of the three registers 14, 16 and 18.

Registers 1 4 and 1 6 can store sixteen BCD digits and register 1 8 can store ten BCD digits.

This example of the terminal also includes a customer key pad 20 by means of which the customer can enter his PID, which in this example is assumed to consist of a number of four digits. The data representing these four digits is fed into stages 16C of register 16.

The terminal also includes a retailer's keyboard 22 by means of which the retailer can enter details of the transaction, including digits representing the charge. This data is fed into the stages 24A of a further register 24 which can store up to sixteen BCD digits.

Instead of the keyboard 22, however, the data could be entered automatically by means, for example, of a till, a data reader reading transaction data direct from the product being purchased or apparatus (e.g. a petrol pump) dispensing the product.

The construction of the remainder of the terminal will become apparent from the following operational description.

The operation takes place mainly in three stages, a data input stage, a validation stage and a transaction recording stage.

The data input stage is the stage during which data is entered by the retailer and the card holder and from the card itself.

The validation stage is the stage during which the terminal checks whether the card holder has entered the correct PID and thus whether the transaction is valid or not.

During the transaction recording stage, the terminal records the details of the transaction, even if invalid, on a storage medium (e.g.

magnetic tape) by means of a data storage device 26.

The data input stage comprises the entering of the data of the transaction into the terminal by means of the card reader 10, the customer keypad 20 and the retailer keyboard 22.

During the data input stage, the sequence controller 1 2 operates the switch S1 to steer the data from the card reader 10 into the appropriate sections of the registers 14, 1 6 and 18, as follows:- Account No: The switch S1 is set to Position 1 to feed the most significant digits of the account number into the most significant stages 1 4A of register 14, and the eight least significant digits of the account number are then fed into the eight most significant stages 1 6A of register 16 by setting switch S1 in Position 2.

Expiry Date: The switch S1 is set to Position 2, and the four digits representing the expiry date are fed into the stages 1 6B of register 16.

Check digits: Switch S1 is set to Position 3 and feeds the check digits into register 1 8.

The customer then enters his PID by means of the keypad 20, and the four digits of this are fed into the stages 1 6C of register 16.

Unused stages of any of the registers 14 to 1 8 are set to a fixed predetermined pattern.

During the validation stage, the data in registers 14 and 1 6 is read out via switches S2 and S3 which are controlled by the sequence controller 1 2. During this stage, they have the positions shown in the Figure. The bits of the data in the two registers are read out non-destructively and are combined bit-bybit using modulo-2 addition in an adder 28, therefore producing a 64 bit data block.

This data block is applied to the input of the block cipher unit 30 which operates in accordance with the United States National Bureau of Standards Data Encryption Standard, (see Federal Information Processing Standards Publication 46). The particular key used by the block cipher unit 30 is obtained from a store 32 via a switch S4 which is controlled by the sequence controller 1 2 and during the validation stage is set in the position illustrated in the Figure. This process represents the particular function f, and is defined by the key selected from the store 32 in dependence on the expiry date stored in register stages 16B, via a line 54.

The resultant 64 bits from the block cipher unit 30 are then fed to a combination register 34 where, by modulo-2 addition of pairs of bits, they are reduced to eight hexadecimal characters, and the resultant word is then fed into a base 1 6/base 10 converter 36 which converts the word to ten decimal digits and feeds this to one input of a comparator 38.

The second input of the comparator is fed from the register 1 8 which contains the check digits read from the card, and the comparator 38 produces a binary output indicating whether or not equality is detected. The comparison process carried out in comparator 38 therefrom checks to ensure that the PID which the card holder has entered, when processed according to the function f1, is in accord with the version stored on the card by the check digits, and thus the binary output indicates whether or not the transaction is valid (that is, whether the card holder has fed in the correct PID). This binary output from comparator 33 is fed into stage 24B of register 24.Register 24 also has a set of stages 24C in which is recorded a serial number representing the number of transactions (valid or invalid) which have taken place since the magnetic tape was last replaced, and this number is incremented each time the comparator 38 produces a binary output. In addition, the output from the comparator 38 is fed into an accumulator 40 which stores data representing the validity of the last 64 transactions. Finally, the output from the comparator 38 can operate an indicator 46 to indicate to the terminal users whether the transaction is valid.

Each time the accumulator 40 is updated, it updates data representing the total number of invalid transactions which it is storing and outputs a signal representing this number. A threshold detector 42 compares this output with a pre-set threshold to determine whether more than a predetermined number of the last 64 transactions are invalid. If more than this predetermined number are invalid, then the threshold detector 42 produces an output which clears the key store 32 and thus disables the terminal. However, instead of, or inv addition to, disabling the terminal, it could take other suitable warning action.

The accumulator 40 and the threshold detector 42 therefore prevent an unauthorised user with access to a terminal from attempting to ascertain the correct PID for that card by performing repeated fictitious transactions.

That concludes the validation stage.

During the transaction stage, the switches S1 to S5 are initially set in the following positions by the sequence controller 1 2:- Switch S2-Position 1 Switch 53 Position 2 Switch S Position 2 Switch S5 Position 2 The contents of register 24 are therefore transferred via switch S2, a line 50 and switch S5 to the storage device 26.

In addition, the contents of this register are fed into one input of the modulo-2 adder 28 whose other input receives a key from the key store 32 on a line 52.

The resultant modulo-2 addition is then enciphered in the block cipher unit 30 using another key from the key store 32, this key being different from that used in the validation stage. This key and the key on line 52 together define a particular function f2 discussed below. These keys (or parts of them) are arranged to be changed automatically each time a fresh tape is placed in the storage device 26.

The sequence controller 12 then sets switch S2 to Position 2 and switch S3 to Position 3 and clears the PID data from register stages 1 6C of the register 16.

The contents of register 14 are transferred to the storage medium 26 via switch S2 and line 50. In addition, they are modulo-2 added, by the adder 28, to the output of the block cipher unit 30 which carries the result of the previous step during which register 24 was enciphered; the resultant output of adder 28 is then enciphered in the block cipher unit 30 using the function f2 key.

Switch S2 is then set to Position 3, and the contents of stages 1 6A and 1 6B of register 1 6 are fed via the switch and line 50 to the storage device 26.

In addition, they are modulo-2 added by the adder 28 to the output of the block cipher unit 30, which carries the result of the previous step during which register 14 was enciphered; again, the same key is used.

At the end of this step, the output of the block cipher unit 30 will therefore carry a 64 bit word which is generated according to the function f2 and represents all the bits from registers 14, 1 6 and 24 (except the PID data from register stages 16C). This output is fed into the combination register 34 which performs a modulo-2 addition of four groups of four bits so as to produce each of four hexadecimal characters. Switch 55 is set into Position 1 and feeds these characters to the storage device 26 for storage as a check sum on the tape.

The terminal is now ready to carry out the next transaction.

The purpose of the check sum is to prevent a fraudulent operator from interfering with the storage medium so as to record additional fictitious transactions or to modify or delete recorded transactions.

It will be apparent that the check sum is a function of:- the transaction serial number; the transaction charge; the customer's account number; the expiry date of the card; whether or not the transaction was determined to be valid; and the tape-identity.

The card issuer is therefore able to check the validity of each transaction recorded on the storage tape by encoding the transaction information according to the function f2 and comparing it with the recorded check sum. In this way, a fraudulent user could only alter recorded transaction information if he could also make a corresponding alteration to the recorded check sum (using the function f2).

The dependence of the check sum on the serial number of the transaction prevents a fraudulent user inserting a fictitious transaction into, or deleting a transaction from, the tape.

The key produced by the key store 32 on the line 52 could be omitted but its use increases the security provided by the function f2. The dependence of f2 on the identity of the particular tape in the storage device 26 means that two transactions recorded on different tapes would have different check sums even if they were identical in every other way (even having the same transaction number). This prevents a fraudulent user attempting to transfer transaction data from one tape to another.

The function f2 is arranged to have the following properties: (a) the function is impossible to deduce from an inspection of many transaction records and their corresponding check sums; (b) a small change in any of the recorded transaction information results in a large and unpredictable change in the check sum; (c) the tape-identifying relationship cannot be deduced from an examination of many transaction records made using the same keys.

The terminal may also be arranged to check that the value of the transaction (recorded in register stages 24) is within predetermined limits. Thus, the value can be checked to ensure that it is not above a predetermined limit, which may be a fixed limit or may be a limit stored on the card. Secondly, the terminal may check that the value of the transaction is not less than a predetermined minimum. This check is to prevent a fraudulent user attempting to elicit the correct PID corresponding to a fraudulently obtained card by carrying out a mixture of fictitious transactions of low value using a genuine card and PID and fraudulent ones using the fraudulently obtained card.

It will be observed that the terminal makes use of the same algorithm to generate both the function f1 and the function f2, the algorithm being acted on by different keys to generate the two functions. In this example, function f, is shown as being determined by the expiry date on the card, but it could instead be determined by other data on the card.

Claims

1. A data processing system for processing data relating to a transaction involving the use of a user token in which each transaction involves the reading of data stored on the user token in machine-readable form and the separate entry of identification data and of other data relating to the particular transaction, a particular part of the data stored on the token including check data for checking the separately entered identification data and related to the correct identification data corresponding to that token in accordance with a first predetermined function, the system comprising data processing means responsive to the check data read from the token and the identification data and operative in accordance with a predetermined algorithm, means operative to set the algorithm to process the data in accordance with the said first predetermined function so as to verify whether or not the identification data corresponds to that token, means operative to set the algorithm to produce further check data in accordance with a second predetermined function and dependent on the data read from the token and the separately entered data relating to the particular transaction, and means for storing at least some of the data read from the token, the separately entered data, and the said further check data all for subsequent processing, whereby unauthorised alteration of the stored data read from the token or the stored separately entered data becomes detectable with high probability by comparing it with the stored further check data.

2. A data processing system for processing data relating to a transaction involving the use of a user token, in which each transaction involves the reading of data stored on the user token in machine-readable form and the separate entry of other data relating to the particular transaction, the system comprising means responsive to the data read from the token and the separately entered data to produce check data generated according to a predetermined function, and means for storing the data read from the token, the separately entered data, and the check data all for subsequent processing, whereby unauthorised alteration of the stored data read from the token or the stored separately entered data becomes detectable with high probability by comparing it with the stored check data.

3. A system according to claim 2, in which the separately entered data includes identification data corresponding to each user token.

4. A system according to claim 3, including means for checking whether a transaction is valid or not by comparing the separately entered identification data with data stored in machine-readable form on the user token, and in which the means for generating the check data is responsive to whether the transaction is determined as being valid or invalid.

5. A system according to any one of claims 2 to 4, in which the means for generating the check data includes means responsive to the serial number of the transaction within a plurality of transactions.

6. A system according to claim 5, in which the means for generating the check data generates the check data as a function of the identity of the particular storage medium.

7. A data checking system for verifying a transaction involving the use of a user token and separate entered identification data, comprising means for comparing the separately entered identification data with check data stored on the token itself in machine-readable form, and in which the stored check data is represented on the token according to a predetermined function and is dependent not only on the value of the identification data corresponding to that token but also on other data which is separately stored on the token in machine-readable form and is dependent on the identify of that token, and the predetermined function is dependent on the value of at least some of the data stored on the token.

8. A system according to claim 7 for use where the token is a token used for initiating a financial transaction, in which the said other data is data representing the account number and the expiry date of the token.

9. A system according to claim 8, in which the data stored on the token and on whose value the predetermined function is dependent is the data representing the expiry date.

1 0. A data checking system for verifying transactions involving the use of user tokens, in which a record is made whether each transaction is valid or invalid and the system determines when the proportion of invalid transactions in a predetermined number of consecutive transactions exceeds a pre-set minimum.

11. A system according to claim 10, including means responsive to such determination to disable the system.

1 2. A system according to claim 10 or 11, in which each transaction also involves the use of separately entered identification data which is predetermined for each token, and including means for determining, and recording, whether or not any particular transaction is valid by comparing the separately entered identification data with data stored on the token itself in machine-readable form and representing the correct identification data for that token.

1 3. A system according to claim 12, in which the said data stored on the token is represented thereon in accordance with a predetermined function and is dependent not only on the identification data but also on other information also stored on the token itself in machine-readable form and which is particular to that token.

14. A data checking system for off-line verification of the validity of a transaction involving the use of a banking or credit card carrying machine-readable data identifying the card and also involving data which is separately entered at the time of the transaction and which includes identification data, in which the machine-readable data includes check data dependent on the correct identification data for that card and on the other data on the card all represented according to a first predetermined function which itself is dependent on a predetermined part of the data on the card, the system comprising an off-line terminal including means for reading data from the card, means for receiving the separately entered data, data processing means operative in accordance with a predetermined algorithm, means responsive to the said predetermined part of the data on the card to set the data processing means to operate in accordance with the first predetermined function to process the separately entered identification data with the said other data from the card to generate output data, means for comparing this output data with the check data to determine whether the separately entered identification data corresponds to that card and thereby to determine whether the transaction is valid or not valid, storage means for storing, for each of a predetermined plurality of consecutive transactions, data indicating whether or not the transaction is valid, means operative to indicate when the stored data shows that more than a predetermined number of the plurality of transactions are invalid, means for storing on a storage medium sufficient of the said data to enable the transaction to be subsequently completed, means operative to set the data processing means to operate in accordance with a second predetermined function to process the data which is stored on the storage medium, in conjunction with a serial number for the transaction, so as to generate check data according to the second predetermined function, and means for storing this check data on the storage medium to enable the associated data stored thereon to be checked.

1 5. A method of processing data relating to a transaction involving the use of a user token in which each transaction involves the reading of data stored on the user token in machine-readable form and the separate entry of identification data and of other data relating to the particular transaction, a particular part of the data stored on the token including check data for checking the separately entered identification data and related to the correct identification data corresponding to that token in accordance with a first predetermined function, the method including the steps of processing the check data read from the token and the identification data in accordance with a predetermined algorithm, setting the algorithm to process the data in accordance with the said first predetermined function so as to verify whether or not the identification data corresponds to that token, setting the algorithm to produce further check data in accordance with a second predetermined function and dependent on the data read from the token and the separately entered data relating to the particular transaction, and storing at least some of the data read from the token, the separately entered data, and the said further check data for all subsequent processing, whereby unauthorised alteration of the stored data read from the token or the stored separately entered data becomes detectable with high probability by comparing it with the stored further check data.

1 6. A method of processing data relating to a transaction involving the use of a user token, in which each transaction involves the reading of data stored on the user token in machine-readable form and the separate entry of other data relating to the particular transaction, the method including the steps of responding to the data read from the token and the separately entered data to produce check data generated according to a predetermined function, and storing the data read from the token, the separately entered data, and the check data all for subsequent processing, whereby unauthorised alteration of the stored data read from the token or the stored separately entered data becomes detectable with high probability by comparing it with the stored check data.

1 7. A method according to claim 16, in which the separately entered data includes identification data corresponding to each user token.

18. A method according to claim 17, including the steps of checking whether a transaction is valid or not by comparing the separately entered identification data with data stored in machine-readable form on the user token, and in which the step of generating the check data depends on whether the transaction is determined as being valid or invalid.

1 9. A method according to claim 18, in which the step of generating the check data includes the step of comparing the serial number of the transaction within a plurality of transactions.

20. A method according to claim 1 8 or 19, in which the step of generating the check data includes the step of generating the check data as a function of the identity of the particular storage medium.

21. A data checking method for verifying a transaction involving the use of a user token and separately entered identification data.

comprising the steps of comparing the separately entered identification data with check data stored on the token itself in machinereadable form, and in which the stored check data is represented on the token according to a predetermined function and is dependent not only on the value of the identification data corresponding to that token but also on other data which is separately stored on the token in machine-readable form and is dependent on the identity of that token, and the predetermined function is dependent on the value of at least some of the data stored on the token.

22. A data checking method for verifying transactions involving the use of user tokens, in which a record is made whether each transaction is valid or invalid and including the step of determining when the proportion of invalid transactions in a predetermined number of consecutive transactions exceeds a pre-set minimum.

23. A method according to claim 22, including the step of responding to such determination by ceasing further verification of transactions.

24. A method according to claim 21 or 22, in which each transaction also involves the use of separately entered identification data which is predetermined for each token, and including the step of determining, and recording, whether or not any particular transaction is valid by comparing the separately entered identification data with data stored on the token itself in machine-readable form and representing the correct identification data for that token.

25. A method according to any one of claims 22 to 24, in which the said data stored on the token is represented thereon in accordance with a predetermined function and is dependent not only on the identification data but also on other information also stored on the token itself in machine-readable form and which is particular to that token.

26. A data processing method, substantially as described with reference to the accompanying drawing.

26. A data processing system, substantially as described with reference to the accompanying drawing.