GB2503909A

GB2503909A - Electronic account access security system based on trusted proxy and communication using an account identifier to control at least account status

Info

Publication number: GB2503909A
Application number: GB1212347.7A
Authority: GB
Inventors: Peter Elsom Green
Original assignee: Individual
Current assignee: Individual
Priority date: 2012-07-11
Filing date: 2012-07-11
Publication date: 2014-01-15
Also published as: GB201212347D0; WO2014009734A1

Abstract

A security system for electronic account access, e.g. online banking, comprising a user account managed by a service provider wherein access to said user account over a network is provided by a host such that a plurality of communications devices, typically including a smart phone or other mobile device, can control aspects of the account over the network by supplying a first set of account identification data to the host, the user account having an active status in which new interactions with the user account by the communication devices are permitted and an inactive status wherein new interactions are inhibited by the host, e.g. a bank account or credit card is locked or frozen. The system also comprising a data store having the first sets of account identification data stored thereon and an identifier for each of the user accounts such that transmission of the identifier by a user communication device can switch the associated user account at the host between the active and inactive states.

Description

Title -Improvements in relation to electronic security This invention relates to improvements in electronic security, and in particular, the security of data which is regularly accessed by an authorised user.

In industries such as banking, there exists a need to keep user account data secure but also allow the account to be accessible to an authorised user. This has been addressed conventionally by requiring the user to provide a predetermined set of information in order to access an account, such that a service provider can check the information provided against the information held for that account.

However, there exist a number of techniques, e.g. phishing, skimming and computer hacking, which enable unauthorised users to discover, for example a password, along with any other details necessary to access the account. For example, if an unauthorised user obtains a person's debit card, and also discovers that user's PIN number, the unauthorised user has all the necessary information to access and withdraw money from the person's bank account.

There therefore exists a need to improve the security of the account data from unauthorised users, while allowing authorised users to access the data. One service provided by banks to address this problem involves the watching of an account to determine when irregular account activity occurs. The bank then contacts the customer to determine whether the irregular activity is authorised.

However such a service requires manual intervention and is ineffective if the bank is unable to contact the user. Furthermore the user may not wish to be troubled in the event that all the transactions had already been authorised.

In further examples of account security, particularly for online banking services, an end user is provided with a dedicated device in order to retrieve a time limited code before accessing the account via a web site/portal. Whilst such a system inhibits full access to an account by a user who does not have the dedicated device in their possession, it does not inhibit transaction requests from other sources by unauthorised parties. Furthermore the need to keep safe a further dedicated device is an inconvenience to the user.

Accordingly it is an aim of the present invention to provide a system which improves security for a user account. It may be considered to be an additional or alternative aim to provide a system which provides the user greater control over account security.

There has now been developed a new communications device which overcomes or substantially mitigates some or all of the above-mentioned and/or other

disadvantages of the prior art.

According to a first aspect of the invention there is provided a security system for electronic account access comprising a user account managed by a service provider wherein access to said user account over a network is provided by an account host such that a plurality of communications devices can instruct an interaction with said user account over the network by supplying a first set of account identification data to said account host, characterised in that the user account has an active status in which new interactions with the user account by the communication devices are permitted and an inactive status wherein new interactions are inhibited by the account host, the system further comprising a data store having the first set of account identification data stored thereon and an identifier for each of the said user accounts such that transmission of said identifier by a user communication device can switch the associated user account at the account host between the active and inactive states.

This is advantageous as, if the user wishes to perform or instruct an interaction with the user account, he may use the user communication device to switch the user account to an active state. He is then able to perform or instruct an interaction with the user account via the account host. Once the interaction is complete, he may use the user communication device to switch the user account to an inactive state. An unauthorised user would then not be able to perform a new interaction with the account, even if the unauthorised user supplies the first set of account identification data to the account host.

A new interaction or transaction shall be taken to mean an interaction or transaction which has not been authorised previously. Previously authorised interactions, such as regularly repeated transactions, may be honoured even when the account is in the inactive status. For example, direct debits and standing orders are not new transactions as they have been authorised previously.

In one embodiment, a default status of the account may be the inactive status.

In preferred embodiments an intermediate host is provided for communication with a user communication device. The intermediate host may comprise a server.

The intermediate host may comprise the data store. The intermediate host may be located remotely from the account host. The intermediate host may be provided and/or operated by a further service provider. The intermediate host may have an account side and a user side, wherein the intermediate host receives requests from the user and processes the requests prior to transmitting a corresponding request to the account host.

Any references to "the host" below may be references to either the account host or intermediate host.

The host may be adapted to receive the transmitted identifier. The identifier is typically not comprised in the first set of account identification data. The identifier may comprise a string. The identifier may comprise a user identifier and a communication device identifier. The identifier may comprise any or any combination of a serial number, PIN, IP address and/or password. Any or any combination of such data may comprise component parts of the identifier.

This is advantageous as the first set of account identification data is not transmitted and therefore if the identifier is intercepted by an unauthorised user, that unauthorised user would not obtain the first set of account identification data.

This improves the security of the system. The identifier may comprise a predetermined format such that alternative data formats may be rejected by the host. The system may be adapted such that the identifier, including the component parts thereof, can be sent in a single data packet. Preferably the host is adapted to accept data packets containing only the identifier and an instruction. Thus an unauthorised user attempting to interact with the user account would have to send a data packet having this format in order for the host to accept the interaction.

Preferably the data store is located at the host. The host may compare a received identifier with the stored identifier. The host may be adapted to compare the communication device identifier (e.g. serial number) and the user identifier (e.g. PIN) received from the user communication device to a list or array of user and device identifier pairs in the data store and in order to determine the account identification data associated with a particular user communication device.

The host may be a server, such as a database server, a file server, an email server and/or a web server. In preferred embodiments, the user account is a bank account. If the user account is a bank account, the identifier preferably does not contain the number of the bank account. Therefore, if the identifier is intercepted, the bank account number cannot be obtained.

The host may be adapted to send data to the user communications device. This may be, for example, a confirmation that instructions have been performed. For example, if the user account is a bank account and an instruction to prevent withdrawal of funds is sent to the bank server from the communications device, the bank server is adapted to send data to the communications which indicates that the bank has taken measures to prevent such transactions occurring.

In some embodiments, the host is adapted to receive further instructions from the user communication device. The further instructions may be limited to a plurality of pre-determined instructions which are acceptable to the host. This may allow the host to perform other tasks beyond switching the user account between active and inactive states. The plurality of pre-determined instructions which are acceptable to the host may include an instruction to send information relating to the user account to the communications device. In the case that the user account is a bank account, such information may be, for example, the account balance or an indication that a threshold limit, such as the overdraft limit, on the account has been reached. The plurality of pre-determined instructions may include only interactions which do not involve funds leaving the user account. This is beneficial as, if an unauthorised user were to hack into the system, the unauthorised user would not be able to send an instruction to the bank server which involved funds leaving the account. However, in one embodiment an instruction could comprise a request for a pie-determined fund transfer to an existing payee, for example a payee or transfer that has previously been registered or authorised, e.g. via online banking services. This would have a pre-determined upper daily limit as registered via online banking services.

If the instruction comprises a request for information in relation to the user account, the data sent by the host to the user communications device may be a response to that request. For example, if the instruction was a request for the account balance, the host may send data relating to the bank balance.

Alternatively, the host may be adapted to receive standing instructions to send a response to the user communications device. In the event that, for example, the account becomes overdrawn, the host may be adapted to send data to the user communications device indicating that the account is overdrawn.

The host may be configured to send automatically a message to the user communication device in response to an event wherein an unauthorised user has attempted to interact with the account, or wherein a cheque or other transaction instrument has been presented which instructs the removal of funds from the bank account. In this case the host may be adapted to request authorisation to allow the transaction to proceed, for example within a predetermined or standard time period.

The data sent by the host to the communications device may contain a label which is usable by the user communications device to identify a user. The label may comprise the identifier (e.g. the serial number and FIN).

The instruction may be to prevent any user from accessing the secure information.

In preferred embodiments, the host is a bank server and the user account is a bank account. In other embodiments, the host is an email server and the user account is an email account. Alternatively, the host may be a store loyalty card server and the secure information may be a store loyalty card account.

In the case of an email account, the instruction may prevent third parties from viewing emails contained in the account.

According to a second aspect of the invention there is provided an intermediate host for managing electronic access to a user account managed by a service provider wherein access to said user account over a network is provided by an account host such that a plurality of communications devices can instruct an interaction with said user account over the network by supplying a first set of account identification data to said account host, characterised in that the user account has an active status in which new interactions with the user account by the communication devices are permitted and an inactive status wherein new interactions are inhibited by the account host, the intermediate host comprising a data store having one or more elements of the first set of account identification data stored thereon and an identifier for each of the said user accounts such that upon transmission of said identifier by a user communication device the intermediate host forwards a corresponding instruction to the account host to switch the associated user account between the active and inactive states.

According to a third aspect of the invention there is provided an account host for use in the system of the first aspect.

Any of the preferable features described in relation to the first aspect may be applied to the second or further aspects wherever practicable.

Preferred embodiments of the invention will now be described in further detail with reference to the accompanying figures, which are for illustration only, and in which: Figure 1 is a general schematic view of the system according to the invention; Figure 2 is a schematic view of the system according to the invention showing the content of the data packets which can be sent between the components of the invention; Figure 3 is a schematic view of the user interface of a mobile radio telephone for use in the invention.

Figure 1 shows a system according to the invention and is generally designated 1.

The system includes a host which is a bank server 2, an intermediate server 3 and user communications device 4, which may be a smartphone, PDA or other suitable portable, wireless communication device. The user communications device has a display and user interaction means or controls, preferably in the form of a touchscreen 15. The user communications device has one or more processors and conventional transmitter/receiver circuitry for data transmission in accordance with conventional protocols and standards. Data transmission between the user device 4 and one or more servers 2, 3 typically occurs using standard networks, such as the internet 6 and/or one or more mobile telecommunications networks 7.

It will be appreciated that the desired portability of the user device calls for the use of wireless data transmission but the transmission of any one or more individual signal within the system could be performed using a wired connection if desired.

The user of the device 4 has a bank account with a particular bank. The bank server 2 is associated with that bank. Using the system 1, the user is able to send instructions relating to his bank account to the bank from the device 4 via the intermediate server 3. The user is also able to receive, at his device, information relating to his bank account from the bank.

The system of the present invention operates within a conventional banking context, wherein a bank account holder can authorise a transaction with his bank account using predetermined bank account information. For example, within a retail premises a bank account holder would typically use a bank card (e.g. a chip-and-PIN card) to authorise a transaction at the point of sale. A communication device at the retailer sends the authorised transaction request to the bank server 2 and, upon receipt, the bank can accept or decline the transaction based on conventional criteria. Similarly a bank account holder can provide the required bank account details in order to authorise a transaction by a third party over the telephone or internet, such that a third-party communication device can transmit the authorised transaction request to the bank using the bank account details provided by the user.

In the context of this invention, as noted above, a user may use the present system 1 to send an instruction, relating to his bank account, to the bank using a different identifier instead of the conventional bank account details required for instructing a transaction. The bank server 2 will typically only accept a single predetermined instruction of this kind or else a small number of instructions chosen from a predetermined list of instructions. The user interface of the mobile device gives the user a choice of instructions each of which is on the predetermined list. One of these instructions is an instruction to switch the user account between an active and inactive state. Switching the user account from an inactive to an active state will be referred to here as turning a shield off. Switching the user account from an active to an inactive state will be referred to here as turning a shield on. If the shield is turned on, the bank will reject any request to remove funds from the bank account unless the request corresponds to a pre-existing arrangement, such as a standing order or a direct debit. In other words, a shield prevents new transactions which involve funds leaving the account. An attempt by any party (including the account holder) to remove funds will be unsuccessful, even if the attempt involves account and PIN information. If the account holder wishes to withdraw funds he may instruct the bank to turn the shield off. This means that new transactions which remove funds are permitted.

The shielded status of the account may thus be considered a partial block on the account in respect of new debit instructions. This may be distinguished from a conventional blocked account in which further restrictions on the account may be applied.

The shield (i.e. the inactive account status) preferably only applies to account debits such that the account can be credited by third parties or the account holder regardless of the account/shield status.

The way that the system is initialised will now be described. In order to initialise the system 1, the bank generates a serial number 17 and PIN 19 which correspond to the user's bank account. This serial number 17 and PIN 19 are sent to the user who inputs them into the device 4. Such details may be sent using conventional secure channels, for example by recorded-delivery mail and/or secure electronic mail. The bank also provides the same serial number 17 and PIN 19 to the intermediate server 3, and this information is saved on the intermediate server 3 or, more typically, on a storage device within a local area network at the intermediate server system.

The next step is to register the device 4 with the intermediate server 3. In order for the device 4 to communicate with the intermediate server 3, the device 4 is program med with the necessary communications software/firmware.

The software for controlling the user communication device in accordance with a system according to an embodiment of the invention is typically a mobile telephone application (or "app") and generates a user interface 15 on the device display. The user interface 15 provides a number of fields into which the user can input the serial number 17 and PIN 19 provided by the bank. Fields are also provided for a password which is used to access the app, and for a confirmation of that password.

The app then initiates a connection via the internet 6 to the intermediate server 3 and presents the bank-allocated serial number 17 and bank-allocated FIN 19 input by the user to the intermediate server 3. If they match the serial number and PIN stored on the intermediate server 3 then the app passes the mobile device's hardware ID and SIM serial number to the intermediate server 3. At this point, the device and the intermediate server 3 have been successfully paired and full communication is possible between the device and the intermediate server 3.

In any embodiment of the invention, the intermediate server thus serves to validate the instruction from the user communication device for transmission to the bank.

For example, the intermediate server may validate the device ID (such as serial number or IP address) as well as the user identification data before forwarding a corresponding instruction to the bank.

The process for sending an instruction to the bank server 2 will now be described and is best seen in Fig 2. The user interface of the app provides the user with predetermined list of possible instructions. The user selects a particular instruction, for example to turn a shield on. The app sends that instruction, along with the bank-allocated serial number 17 and PIN 19, in a data packet 9 to the intermediate server 3. No information relating to the identity of the user, the device 4 or the bank account is sent with the instruction. Upon receiving this information, the intermediate server 3 sends a data packet 18 containing the bank-allocated serial number 17 and PIN 19, and the instruction l6to the bank server.

The bank server 2 is programmed to only accept data packets 18 from the intermediate server 3 which have these three pieces of information. Possible instructions include an instruction to turn the shield on or off, or to inform the user of the account balance.

However in further embodiments, the intermediate server may supply additional data 27 to the bank server to supplement the information sent by the user communication device, such as the account number or other conventional bank account identification means. This helps to ensure the connection with the user device need not require any bank account data to be stored on the device itself.

When the bank server 2 receives the data packet 18, it reads the received serial number 17 and PIN 19 and attempts to match them to a list of serial numbers 17 and PINs 19 stored on the bank server 2, or, more typically, on a storage device within a local area network at the intermediate server system. Once a match is found, the bank server 2 can identify the bank account which corresponds to the matched serial number 17 and FIN 19. Once this has been done the bank performs the instruction in relation to the account. In the event of receiving and matching a "shield on" or "shield off" request, the bank server instructs the update of the bank account status accordingly.

If, for example, a user wishes to instruct the bank server 2 to turn on the shield, this instruction is selected at the user interface 15. The user interface 15 may presents a plurality of on screen user-actuable icons for this purpose, such as three shield-shaped icons as shown in Fig 3. The icons are coloured red 20, white 21 and green 22. Touching the green icon 22 causes a data packet containing (i) the serial number 17, (ii) the PIN and (Di) an instruction 16 to establish the shield to be sent to the intermediate server 3. The intermediate server 3 sends a data packet 18 containing this same information to the bank server 2 which establishes the shield. From this point on, new transactions which remove funds from the account are not permitted.

It is a benefit that, once the device 4 has been set up, the present invention does not require the user to remember or enter a PIN or password in order to send the desired instruction to the bank. Instead the user merely is required to be in possession of the device 4. Thus it is the identity of the device (typically in conjunction with the prescribed PIN and/or serial number) that is used to verify the instruction to the bank. By limiting the set of instructions that can be provided using the present invention any security threat to the user's account is minimised.

That is to say, if the user device 4 is lost or stolen, any unauthorised user of the device would be unable to perform any action in relation to the account other than the turning of the account shield on or off. Furthermore, the unauthorised user would not know to which account the instruction to turn the shield on or off related.

It may be desirable for the bank server 2 to send information to the user, for example, an indication that a user's instruction has been carried out or an indication of the current status of the shield (i.e. whether the shield is on or off).

The user interface may present a message or other indication to the user of the received status of the account. For example, the icon could change appearance to indicate that the desired instruction has been carried out. That icon may be disabled from user interaction such that only icons that instruct a change to the current account status are actuable by the user.

Other information provided to the user device 4 could include a response to a specific request, e.g. for the account balance, or to a standing request, e.g. an indication that the account is overdrawn/overdraft limit exceeded/interest rates have changed etc. To send information to the user the bank server 2 sends to the intermediate server 3, a data packet containing i) the serial number 17, ii) the FIN 19 and iH) the required information 24 (see Fig 2). The intermediate server 3 is programmed to only accept data packets 25 from the bank server 2 which have these three pieces of information. When the information is received at the intermediate server 3 it is forwarded to the device 4 in a data packet 26. If the information relates to the shield status, the appropriate shield-shaped icon is highlighted. In particular, if the shield is on the red icon 20 is highlighted and if the shield is off the green icon 22 is highlighted. If the mobile device has not been registered the white icon 21 is highlighted.

The shield icons can also be used to show the list of instructions which can be sent. The selectable list 23 of instructions 16 appears if the user makes a long press on the green icon 22, see Fig 3. Any conventional additional on-screen or other user input may be used to bring up a menu or list in this regard.

A further example of a notification which can be sent to the user is information in relation to acts in relation to the account. These could include attempts to login to internet banking or attempts to withdraw funds from the account by ATM withdrawal or the use of a credit or debit card. These types of notifications (see 1 5a in Fig. 1) could include, for example, the time and location of any such attempt (example: ATM ATTEMPT 23:19-02/02/2012 HIGH STREET LONDON). They are useful as they give the user the opportunity to take action quickly if he suspects that the attempt was unauthorised. These types of notifications may be sent irrespective of whether or not a shield is established. The user can also be notified if a third party attempts to bank a cheque which removes funds from his account. In this situation, the app provides the user with the option to allow or to prevent the cheque payment. The user selects the appropriate option and a corresponding instruction is sent to the bank in the manner described above.

In one example, the notification may allow a time window in which the user can send a shield off" instruction in order to allow the transaction to proceed. Thus a user who forgets to actively switch the shield off before making a transaction can still react to an automated message without requiring human intervention.

If the shield has been removed, new transactions may be performed which involve the movement of funds out of the account. The user may perform such a transaction e.g. he may make a cash withdrawal from an ATM or pay for goods using a debit card. When the transactions are complete, the user may wish to instruct the bank to re-establish the shield. If the user selects that option, the app sends an instruction to re-establish the shield, along with the bank-allocated serial number and PIN to the intermediate server. The intermediate server, in turn, sends the same information to the bank server in the manner previously described. The bank server receives the instruction and re-establishes the shield.

From this point on, unless an instruction to remove the shield is received by the bank server, further new transactions which involve the withdrawal of funds from the account are not permitted. The bank server sends a confirmation to the device that the shield is on. This causes the colour of the shield icon on the display of the device to change from green to red.

The app may thus provide a toggle or switch allowing the user to turn the shield on and off at will, for example using an input via a single icon.

In any of the above embodiments the time of the transmission of an instruction according to the present invention sent from the user communication device may be logged by the host 2 or intermediate host 3. This may form part of the instruction itself or else may be logged by the relevant host as the time of receipt of the instruction. Similarly, the time of authorisation or request by the user of any transactions may also be logged such that any delays in the transmission or receipt of the relevant instructions/authorisations need not inhibit the smooth running of the system. That is to say, the time of a past transaction authorisation or request can be compared to the timing of earlier "shield on" or "shield off" requests in order to check whether the transaction can later be allowed by the bank.

In any embodiment of the invention, the transmission of a "shield off" instruction to the bank may remove the shield either indefinitely (i.e. until the user sends a "shield on" instruction) or else for a predetermined period of time. The predetermined period of time may be sufficient to allow one or more transactions to take place, such as for example five or ten minutes. Additionally or alternatively, the user may select a predetermined time, such as a number of hours or a day, for example in the event that they envisage making a number of transaction within the ensuing time period.

In any embodiment, the user bank account may have a default "shield on" condition and may be reset to the default state under preset conditions. Such conditions may comprise a predetermined duration of time after a shield off instruction is received and/or a predetermined duration of time after the last transaction has been made and/or a predetermined time of day or night. The predetermined duration may be one or more hours and/or the predetermined time may be midnight or else some other time which is generally associated with low levels of account activity. Such conditions may be automatic or else may be set or selected by a user upon initial setup of the service.

There are a number of other possible types of information which can be sent from the device to the bank using this system, for example, information relating to the location of the device. This could be used to detect unauthorised use of the device. Also pre-arranged money transfers are possible. For example, an account may have a pre-arranged facility for transferring a limited amount to a particular recipient. The user could use this system to instruct the bank to transfer a particular amount to the recipient.

The system could also be used to confirm the identity of a user to a bank during a phone call. The app provides a field into which the user can input a verification code given to him over the telephone by the bank clerk. The verification code is sent to the bank via the intermediate server as described above such that the bank receives a data packet containing the bank-allocated serial no and PIN and the verification code. This demonstrates to the bank clerk that the caller is authorised in relation to the bank account to which the received serial number and PIN relate.

Alternative embodiments include additional layers of security. For example, the bank-allocated serial no and PIN may be associated with a bank-allocated code which is associated with a particular bank account no. The bank informs the intermediate server of the code and which serial no and PIN the code corresponds to. When the intermediate server receives a data packet form the device, it reads the serial no and PIN as described above. However, the intermediate server sends only the code and the instruction to the bank server. It does not send the serial no and FIN. The bank server receives the code and uses it to identify the relevant bank account in relation to which the instruction is to be performed. The bank server then performs the instruction and sends the user the necessary notification as described above.

This system could apply to entities other than bank accounts. For example, the system can be used to apply a shield to an email account which prevents all external communication in order to prevent unauthorised access. The shield could be pre-programmed to be periodically turned off in order to allow email to be received by the account. The shield could also apply to any other types of online account, eg share dealing accounts, ISAs and other savings/investment accounts, store card accounts and loyalty card accounts.

A number of preferable features of the app used to implement embodiments of the invention on the user's communication device will now be described. Despite the security of the device and the app being of reduced significance for the reasons described above in relation to the present invention, the app may offer a number of security features. For example, the user may set a PIN or password or any other conventional security measure, such as an on-screen visual code or interaction sequence, or else a biometric security measure (thumb-print, finger-print or retina scan), or voice activation, to access the app.

In one example, the app is customisable by the user such that the app name and/or icon used to access the app can be amended or configured by the user.

The user may be provided a number of icon options and/or may enter a new name to disguise the function of the app to an unauthorised user. This may be applied also to icons and other elements of the user interface during use of the app. For example the shield icon may be replaced with an alternative icon which is understood by the user as denoting the shield on or off status. To this end, the user may be presented by the app with a number of icon and interface options from which they can select a preferred option for use.

Also a number of different accounts held by the user may be set up such that each account is assigned its own on-screen controls, such as icons. The provision of an intermediate server 3 allows the system to be applied to a number of banks and/or other service providers such that a user can manage a number of accounts using a single app or device.

The invention allows a user smartphone or other device to be severed from a user bank account, in that no bank account information need be held on the device, whilst still allowing the device to be used to increase the security of a bank account.

Claims

Claims 1. A security system for electronic account access comprising a user account managed by a service provider wherein access to said user account over a network is provided by an account host such that a plurality of communications devices can instruct an interaction with said user account over the network by supplying a first set of account identification data to said account host, characterised in that the user account has an active status in which new interactions with the user account by the communication devices are permitted and an inactive status wherein new interactions are inhibited by the account host, the system further comprising a data store having the first sets of account identification data stored thereon and an identifier for each of the said user accounts such that transmission of said identifier by a user communication device can switch the associated user account at the account host between the active and inactive states.
2. A security system as claimed in Claim 1, wherein an intermediate host is provided for communication with the user communication device.
3. A security system as claimed in Claim 2, wherein the intermediate host receives the identifier from the user communication device and validates the identifier prior to transmission of a corresponding instruction to the account host.
4. A security system as claimed in Claim 2 or 3, wherein the intermediate host comprises the data store.
5. A security system as claimed in any one of Claims 2 to 4, wherein the intermediate host has a user side receiver and a account host side transmitter.
6. A security system as claimed in any preceding claim, wherein the identifier comprises a user identifier and a communication device identifier
7. A security system according to any preceding claim wherein the identifier comprises a predetermined data format which is transmittable as a single data packet.
8. A security system according to any preceding claim wherein the identifier comprises a serial number and PIN.
9. A security system according to any preceding claim wherein the identifier does not comprise any of the first set of account data or any further account information.
1O.A security system as claimed in any preceding claim, wherein the account host or intermediate host comprises a server.
11.A security system as claimed in any preceding claim, wherein the host is adapted to receive further instructions from the user communication device
1 2.A security system as claimed in Claim 11, wherein the further instructions are selectable list of pre-determiried instructions which are acceptable to the host.
13.A security system as claimed in any preceding claim, wherein the account host is adapled to receive slanding insiruclions to send a response 10 Ihe user communications device.
14.A security system as claimed in any preceding claim, wherein the account host comprises a bank and the user account is a bank account.
15.A security system as claimed in Claim 14, wherein, new interactions include only transactions which involve funds leaving the bank account, other than pre-arranged such transactions.