AU2013101298A4 - Payment authorisation method and system - Google Patents

Abstract

Abstract A system including a user interface (300, 302, 304, 306) associated with an account access device is provided. The user interface includes a means for receiving a user unlock input (312) associated with the account access device. The user unlock input includes a specified 5 expiry time and at least one specified transaction type. The user interface is in data communication with a means for storing information (111) associated with the access device. The information associated with the account access device includes at least one transaction-type lock status for a transaction type. The transaction-type lock status is one of locked and unlocked. The transaction-type lock status information is configured to be used in a transaction 10 authorisation system (450). The transaction authorisation system is configured to receive a transaction authorisation request (201) for the transaction-type associated with the account access device and to generate a negative authorisation output if the transaction-type lock status is locked (51) and to generate a positive authorisation output if the transaction-type lock status is unlocked (52). The means for storing information is configured to receive a user direction to 15 unlock the account access device for a specified time limit and specified transaction type from the user interface and to update the transaction-type lock status of the account access device to unlock and record a time limit for the transaction-type lock status. LO r C cC ) 0 a .g M~1 a, E - ' Z3 LL 0) 'AA, -- - - - - - -- -- - -- 00 ± a)v c E 0,42 Coc Q )a) I 0000 c cu~ E~o- - ZU) 0 60 0l~ El El w< 0 w ElE Els n EL0 ) < I0 < Io .0 0,-0 -J 00q v; a)~ ooc -0

Description

1 Payment authorisation method and system Field of the invention The invention relates to real time authorization of transactions using non-cash payment. In particular, this invention relates to transactions which are performed over an electronic 5 payment network. Background of the invention Financial institutions and other organisations (issuers) typically issue customers with an account that has one or more access devices associated with it. Access devices can be credit cards, debit cards, digital wallets, smartphone applications, internet banking portals, mobile 10 banking portals etc. The authorised user uses the access device to make purchases, withdraw money and/or transfer funds to other people or businesses. For example, a user may present the physical account access device (in a 'card present' transaction) by presenting a credit card or debit card at a bricks and mortar store to make a purchase, or by using a credit card or debit card at an 15 automatic teller machine (ATM) to withdraw money. The customer may also make 'card not present' transactions for example by using credit card or digital wallet details to purchase goods over the internet or by logging into an internet banking portal or smart phone application to transfer money to a friend or pay a bill. Fraudulent use of account access devices is a major problem for consumers, merchants 20 and issuers. To commit fraud, unauthorised users first gain information about the access device (e.g. the account number, customer number, password, CVV number, verification information etc). Access device information may be obtained, for example, from a user inadvertently passing their card through a skimming device. The skimmed information is then used to make a counterfeit card. Another method used to obtain information is by emailing a user posing as a 25 trustworthy entity. The fraudster gains information when the user unknowingly passes account information to the fraudsters. The fraudulent user then uses these details to charge the user's account. Fraud results in losses for the issuer, customer and/or merchant store. Fraudulent use of access devices also results in reduced consumer and merchant confidence in the payment system.

2 Various systems have been put in place to attempt to control the misuse. One such system uses a dynamic two-factor authorisation. This monitors for transaction parameters that indicate that the use of the access device requires additional authorisation when the transaction is conducted. For example "card not present" transactions for an online purchase may require 5 additional authorisation. If the transaction fits the parameters, the customer will be notified that additional steps will be required to complete the online transaction. The bank will send a unique code also known as 'one time password' by short message service (SMS) text message or by email to the authorised user. The user must enter this code to verify the transaction before the transaction is approved. If the transaction is a fraud attempt, the transaction will not be able to be 10 completed by the fraudster as the unique code will be accessible only to the genuine user through their personalised device such as SMS/email. This system has disadvantages. The authorised user may choose not to complete the purchase because the system is too onerous or may suspect the process as another attempt to gain personal information known as "phishing". This makes the payment system less desirable for the 15 merchant and, in fact, many merchants have chosen not to opt in for the two-factor authorisation fraud protection method provided under 'Verified by Visa' and 'MasterCard SecureCode'. Where merchants choose not to opt into the protection system, the system does not provide secure shopping coverage. Also, the verification system is expensive to implement and can be inaccurate. For 20 example, if a transaction is made by the authorised user and the authorised user is not in an area with mobile reception, they are unable to complete the transaction. Many cardholders turn their mobile phones off when travelling internationally to avoid the cost of receiving calls and text messages through the roaming services. If they perform purchase transactions while travelling, they cannot be sent the SMS code to complete the transaction. Also, in some instances the 25 fraudulent user has arranged to have the access code redirected to their own phone or email address by a fraudulent process known as "mobile porting", enabling them to complete a fraudulent transaction by entering the code. There are also problems with fraudulent payments made by stolen account access devices. To address this, issuers typically set up a hotline which a user can call when they lose 30 their credit card. Issuers offer to cancel the lost credit card and reissue the customer with a new credit card. This is an expensive exercise, and causes inconvenience if the user later finds the lost 3 credit card, because the customer cannot use the cancelled card and instead must wait for a new card to be delivered. Also, a new card may have a new account number and the user will need to rearrange recurring payments that can no longer be made by the cancelled card. There is a need for a method or system which addresses one or more of the disadvantages 5 of the current payment systems and methods. Alternatively, there is also a need to provide the public with a useful alternative to current payment systems and methods. Reference to any prior art in the specification is not, and should not be taken as, an acknowledgment or any form of suggestion that this prior art forms part of the common general knowledge in Australia or any other jurisdiction or that this prior art could reasonably be 10 expected to be ascertained, understood and regarded as relevant by a person skilled in the art. Summary of the invention According to one aspect of the invention, there is provided a method for controlling an account access device including: a) storing information associated with an account access device, the information associated 15 with the account access device including at least one transaction-type lock status for a transaction type, the transaction-type lock status selected from locked and unlocked, wherein the transaction-type lock status information is configured to be used in a transaction authorisation system, and wherein the transaction authorisation system is configured to receive a transaction authorisation request for the transaction-type associated with an account access 20 device, and to generate a negative authorisation output if the transaction-type lock status is locked and to generate a positive authorisation output if the transaction-type lock status is unlocked; and b) upon receiving a user direction to change the transaction-type lock status to unlocked for a specified time limit, updating the transaction-type lock status of the account access device to 25 unlocked and registering the time limit for the transaction-type lock status; wherein the transaction-type lock status includes at least one of: an internet transaction lock status, an ATM lock status, an electronic bill lock status, 30 a telephone order lock status, 4 a point of sale lock status; a transfer out to third party lock status; an international money transfer lock status; a cash advance transaction lock status; 5 an international in store transaction lock status; and an international internet transaction lock status and wherein the specified time limit is less than a lifetime of the account access device. The method may further include starting a timer to monitor the specified time limit for the transaction-type lock status, and upon the timer registering a specified threshold for the 10 transaction-type lock status, updating the transaction-type lock status of the account access device to locked. The method may further include monitoring the time limit of the transaction-type lock status and updating the transaction-type lock status of the account access device if the time is greater than the expiry time of the transaction-type lock status. 15 The method may be further configured to compare the time of the transaction authorisation request with the time limit of the transaction-type lock status and to generate a negative authorisation output if the time of the transaction authorisation request is after the time of the time limit of the transaction-type lock status. The method may be further configured to apply at least one issuer authorisation rule. 20 The maximum specified time limit may be less than 24 hours. Alternatively, the maximum specified time limit may be two weeks or less, one week or less, 12 hours or less, 6 hours or less, 1 hour or less, 0.5 hours or less, or 5 minutes or less. Upon updating the transaction-type lock status of the account access device to unlocked, the transaction authorisation system may be configured to send a confirmation message to the 25 user. The account access device may be one of: a credit card; a debit card; a digital wallet; 5 a payment application; internet banking portal; mobile banking portal; assisted customer contact/call centre. 5 After generating a positive authorisation output if the transaction-type lock status of the account access device is unlocked, the transaction authorisation system may be further configured to apply further authorisation rules to determine whether to authorise the transaction. At least one transaction-type lock status may have a default lock status of locked. Recording the specified time limit may be selected from one of a duration and an end 10 time. Upon registering the time limit for the transaction-type lock status, the transaction authorisation system may be configured to notify the user that the account access device is locked. The method of any one of the preceding claims, wherein a first transaction-type lock 15 status is default locked for a first transaction type and wherein a second transaction-type lock status is default unlocked for a second transaction type. In another aspect of the invention, there is provided a system including: means for storing information associated with an account access device, the information associated with the account access device including at least one transaction-type lock status for a 20 transaction type; wherein the transaction-type lock status is one of locked and unlocked, a transaction authorisation system in data communication with the stored information, the transaction authorisation system configured to receive a transaction authorisation request for the transaction type associated with the account access device and to generate a negative authorisation output if the transaction-type lock status of the account access device is locked and 25 to generate a positive authorisation output if the transaction-type lock status of the account access device is unlocked; means for updating the transaction-type lock status of the account access device to unlocked, in response to receiving a user direction to unlock the account access device for a specified time limit; and 6 means for updating the transaction-type lock status of the account access device to locked upon expiration of the specified time limit, wherein the transaction-type lock status includes at least one of: an internet transaction lock status, 5 an ATM lock status, an electronic bill lock status, a telephone order lock status, a point of sale lock status; a transfer out to third party lock status; 10 an international money transfer lock status; a cash advance transaction lock status; an international in store transaction lock status; and an international internet transaction lock status and wherein the specified time limit is less than a lifetime of the account access device. 15 In a further aspect of the invention, there is provided a system including a user interface associated with an account access device; the user interface including a means for receiving a user unlock input associated with the account access device. The user unlock input includes specified expiry time and at least one specified transaction type. The user interface is in data communication with a means for storing information associated with the access device. The 20 information associated with the account access device including at least one transaction-type lock status for a transaction type. The transaction-type lock status is one of locked and unlocked. The transaction-type lock status information is configured to be used in a transaction authorisation system and the means for storing information is in data communication with a transaction authorization system. The transaction authorisation system is configured to receive a 25 transaction authorisation request for the transaction type associated with the account access device and to generate a negative authorisation output if the transaction-type lock status is locked and to generate a positive authorisation output if the transaction-type lock status is unlocked. The means for storing information is configured to receive a user direction to unlock the account access device for a specified time limit and specified transaction type from the user interface and 30 to update the transaction-type lock status of the account access device to unlock and record an time limit for the transaction-type lock status, wherein the transaction-type lock status includes at least one of: 7 an internet transaction lock status, an ATM lock status, an electronic bill lock status, a telephone order lock status, 5 a point of sale lock status; a transfer out to third party lock status; an international money transfer lock status; a cash advance transaction lock status; an international in store transaction lock status; and 10 an international internet transaction lock status and wherein the specified time limit is less than a lifetime of the account access device. As used herein, except where the context requires otherwise, the term "comprise" and variations of the term, such as "comprising", "comprises" and "comprised", are not intended to exclude further components, integers or steps. 15 Further aspects of the present invention and further embodiments of the aspects described in the preceding paragraphs will become apparent from the following description, given by way of example and with reference to the accompanying drawings. Brief description of the drawings Figure 1 is a flow chart of a process for updating the lock status of an account access 20 device. Figure 2 shows an example of a user interface of a settings modifications illustrated in a series of screen shots. Figure 3 shows a high level diagram of a transaction system in accordance with an embodiment of the invention. 25 Figure 4 shows a schematic diagram of a transaction system in accordance with an embodiment of the invention. Figure 5 shows a method of processing a transaction request in accordance with an embodiment of the invention.

8 Figure 6 is a schematic representation of a system suitable for use with an embodiment of the invention. Detailed description of the embodiments Overview 5 Embodiments of the present invention provide a method and a system whereby a customer can unlock an account access device for a specified time limit. When the user access device is unlocked, transactions performed over an electronic payment network using the account access device may be approved. When the account access device is locked, transactions performed over an electronic payment network are declined. 10 Account access device Typically a customer applies to an issuer for an account access device. The issuer may be a financial institution such as a bank or another issuing organisation. The account access device is, for example, a credit card, a debit card, digital wallet or a payment application for use with a smartphone (e.g. a banking application which can be used to transfer funds), a mobile banking 15 portal or an internet banking portal. The issuer issues the customer with the account access device so that the user can make purchases and conduct authorised transactions at remote locations e.g. at a point of sale (POS), at an ATM, and through a network site such as an internet website etc. The account access device can be used to debit or credit the account that the customer keeps with the issuer. 20 Examples of transaction types include: * Point of Sale transactions (for example merchant, online, NFC/contactless) * ATM transactions (for example cash withdrawal / cash advance) * Electronic bill payments via a Scheme - (for example BPAYTMusing a credit card) 25 * Internet purchases (for example: PayPal, credit card, debit card) * Banking teller transactions (for example cash withdrawals) 9 * Mail order / telephone order (MOTO) transactions * Peer to peer transfer methods, e.g. digital wallet, Bump TM * Recurring direct credit/debits where the transaction can be identified as recurring. Updating the lock status of an account access device 5 Figure 1 is a flow chart of a process for updating the lock status of an account access device. In step 10, the customer logs in to a settings modification facility. To gain admission, the customer provides account information and security information. For example, the customer may be required to submit a customer number, account number, personal identification number (PIN), 10 password, answer to a security question, enter a code sent to the authorised user from the issuer via SMS, push notification or email and/or fulfil other security measures to used identify the authorised user. In Figure 1, the customer can use a mobile phone/tablet application 12 to gain entry to the settings modification facility. In this example, the mobile phone or tablet application has been 15 previously downloaded to the mobile phone or tablet from the issuer. To enter the settings modification facility, the user enters a secret PIN. The customer can also be admitted to the settings modification facility via a browser based login screen 14. The browser login screen requires the customer to enter a client number and a password to log in to the settings modification facility. 20 In Figure 1, the settings modification facility is operated by the issuer, the Commonwealth Bank of Australia. In alternative embodiments, the secure facility may be operated by a different issuer, a network provider (e.g. Mastercard, Visa, American express etc), a third party service provider or a combination of these parties. In a further embodiment, the customer is able to access the settings modification facility 25 in other ways. The customer may access the settings modification facility by another self-service system e.g. via an ATM or using an SMS or interactive voice response (IVR) system. The customer may access the setting modification facility via an assisted customer service platform, e.g. by telephoning a customer service staff member or by visiting a bank teller.

10 Once the customer has provided the account and security information, the customer's access is authenticated and the customer is provided with access to the settings modification facility (step 20). In Figure 1, the customer is connected to a secure electronic settings modification facility via the internet. The information sent and received may be security 5 encrypted. In another embodiment, the customer is assisted by a staff member, and the staff member's access to the user interface is authenticated using the information provided by the customer. In step 30, the user uses the settings modification facility to provide a user direction to unlock the account access device. In an alternative embodiment, the customer can additionally 10 use the setting modification facility to enquire about the current account access device settings. In yet a further embodiment, the settings modification facility is also configured to allow the user to change other settings e.g. transaction amount limits, passwords etc. The user provides a user direction to unlock the account access device by using the interfaces (32, 34, 36) to enter a user unlock input. The interfaces may be displayed on the user's 15 mobile phone or tablet application 12 or on the browser 14. The interfaces are configured to receive user unlock inputs to unlock the account access device for specific transaction types, for specific transaction geographical locations and until a specific time limit. In user interface 32, the user can select the type of transaction to be unlocked by clicking on a check box next to each option. The interface allows the user to make multiple unlock selections or a single unlock 20 selection by clicking on one or more check boxes. In another embodiment, the user interface includes different input features for receiving a user direction to unlock the account. For example, the user may be able add an unlock selection to a list e.g. by dragging and dropping a unlock selection to a list or for example by double clicking on an icon associated with an unlock selection etc. In user interface 34, the user is able to select the geographical locations of 25 transactions to be unlocked. In user interface 36, the user is able to select the time limit for which the transactions will be unlocked. The settings modification facility is configured to communicate a user unlock input delivered via user interfaces (32, 34, 36) to a customer rules engine 111 (see Figure 3). The customer rules engine stores the lock status information and is configured to apply the lock status 30 information to electronic transaction authorisation requests. In alternative embodiments, the user need not provide a user unlock input into an interface directly. For example, the user may issue a 11 user direction to unlock the account access device verbally to a bank teller or issuer representative. The bank teller or telephone attendant then enters the user unlock direction via a staff member interface to record the new settings in the customer rules engine 111. User interface 32 provides the options of unlocking the device for particular transaction 5 types. The options provided in this example are 'all transactions', 'cash withdrawals', 'internet purchases', 'in-store purchases' and 'direct debits'. If the 'cash withdrawals' option is selected, transactions to withdraw cash (e.g. cash withdrawals at an ATM, at a bank teller, funds transfers, etc) would be unlocked. If 'internet purchases' is selected, transactions where the account access device is used to pay for purchases 10 over the internet (for example where a user enters the credit card details and verification numbers at merchant website) would be unlocked. If 'in-store purchases' is selected, card present transactions, for example, where the account access device is used at a bricks and mortar store to acquire goods/services, would be unlocked. If 'Direct debits' is selected, pre-authorised transactions where the account access device is used to transfer funds from the user's account to 15 another bank account at the request of the payee would be unlocked. If 'All transactions' is selected, all types of transactions using the account access device would be unlocked. In another embodiment, more transaction options are provided to the user (e.g. Bpay, telephone order transactions, debit purchase transactions, purchase with cash out transactions, cash advance transactions, international money transfer transactions, transfer out/withdrawal 20 transactions, for example, internet banking transfers out to a third party account etc). In a further embodiment, the user is also be able to specify that only transactions with particular merchant category are unlocked, e.g. grocery store transactions, book store transactions, gambling transactions, alcohol purchase transactions etc. In a further embodiment, the user is able to specify the source of the transaction for example by selecting transactions initiated at a particular 25 branch of a bank, from a particular banking agency (e.g. Australia Post - Bank@Post etc) and/or via assisted channels e.g. telephone banking). In an alternative embodiment, the user is not able to specify the type of transaction to be unlocked. The user is only able to change the lock status for all transaction types. User interface 34 provides the options of 'all locations', 'transactions in Australia only' 30 or 'transactions outside Australia only'. 'All location' unlocks card present transactions from 12 anywhere in the world, while 'transactions in Australia' unlocks card present transactions initiated in Australia. 'Transactions outside Australia'; unlocks card present transactions initiated outside of Australia. In other embodiments, the user is presented with the option to unlock card present transactions made in other countries or regions (for example, options to unlock 5 transactions initiated in Mexico, European Union, China etc). In an alternative embodiment, the user is not provided with any options to unlock transactions in specific geographical locations. User interface 36 provides the options of different unlock time limits: '5 minutes', '1 hour', 'customised time' and 'no time limit'. This allows the user to unlock the account access device for the next 5 minutes, next 1 hour, another time limit chosen by the customer or to 10 unlock the account access device for an unlimited time. Where the unlock is selected for an unlimited time, the selected transaction types have a default unlocked status. This means that a customer may freely use the account access device for the transaction types for the life of the account access device or until the customer locks the device again at a different time. If the user selects 'customised time', the user is provided with a editable text field entry box where the user 15 can type in the amount of time they would like to unlock the account access device for. For example the user can type '2.5 hours', '0.5 hours', '0.30 hours', '10 minutes' etc. In an alternative embodiment, the user enters an unlock time limit for which the transactions will be unlocked by using a different input mechanism e.g. by entering the time limit on an editable clock and/or by using a scrollable time limit selector etc. 20 In one embodiment, the time limit specified by the user must be less than the lifetime of the account access device. Many account access devices (e.g. credit cards and debit cards) have an expiry date marking the end of the account access devices' lifetime. By specifying a time limit that is less that the lifetime of the account access device, the user can ensure that the lock status of reverts to locked during the lifetime of the account access device. 25 In some embodiments, the interface does not provide the option of 'no time limit'. In such arrangements, the default status of the account access device is locked. The customer may only unlock the account access device until the specified time limit. After the time limit passes the account access device reverts to the locked status. In this embodiment, the user must select an unlock time limit. Similarly, for certain transaction types, and/or transaction from specific 30 locations (e.g. particular countries or regions), the interface may not provide the option of 'no time limit'. In such arrangements, the default lock status of those transaction types is locked.

13 Again, this means that the customer may only unlock the transactions types for a specific time limit and after that time limit has expired the lock status for that transaction type reverts to locked. In a further embodiment, the time limit options are limited so that the user must select an unlock time limit of less than 48 hours, or alternatively less than 24 hours, or alternatively less 5 than 23.5 hours or alternatively less than 12 hours or alternatively less than 4 hours or alternatively less than 1 hour. In a further embodiment, the interface is configured to allow a user to specify an unlock time limit by entering the expiry time of the unlock time limit. For example a user may select an expiry time of 11:30 am which unlocks the account access device until 11:30 am. Optionally, the 10 user may select an expiry time and expiry date, e.g. 14 September 2013; 8.50 pm allowing the user to unlock the user access device until 14 September 2013; 8:50 pm. In yet a further embodiment, the user interface restricts entry of an expiry time, so the customer can only specify an expiry time of less than 48 hours time, less than 24 hours time, or alternatively less than 23.5 hours time or alternatively less than 12 hours time or alternatively less than 4 hours time or 15 alternatively less than 1 hours time. In yet another embodiment, the user may set a lock status for a future time period, for example 13 September 2013 from 3pm-5pm. In yet a further embodiment, the user is provided with the option of setting recurring time periods. For example the user may choose to unlock the device on certain days of the week for example on Monday to Friday at 3pm-3:30pm, or every 20 second Thursday at 3:30pm-9pm. The user may choose a recurring unlock period to unlock the device on a particular day of each month, e.g. on the 14th day of each month 9am- 11:30am or on the 2nd last day of the month for the entire day. In another embodiment, the user interface is designed to allow a user to select a time zone which they wish to use. For example, if a user is accessing the user interface from Hawaii, the 25 user could select a time zone (e.g. Hawaii (GMT -10:00)) and then select an expiry time or time period(s) according to that time zone e.g. 2:45 pm or 25 March 2013; 13:35-14:25. In a further embodiment, if the user has more than one account access device associated with their account, the user is provided with an option selecting which of the devices to unlock. For example, the user may be provided with an option to unlock a debit card while keeping their 30 credit card locked. In yet another embodiment, the user is provided with the options of selecting 14 between the primary and supplementary credit (or debit) cards attached to one account. For example the customer may select to unlock a primary credit card while keeping all supplementary credit cards locked or may select one or more supplementary cards to be unlocked. Different permutations are possible according to the user's needs. 5 In yet a further embodiment, the user is additionally able to limit the maximum transaction amount of each unlock transaction or alternatively set a maximum total amount for the transactions made before the specified unlock time limit expires or made during the unlock time interval. In yet a further embodiment, the user is additionally able to select to unlock the account 10 access device for a particular recurring transaction. As the time of the direct debit, BPay and mail order transactions cannot be predicted with precision, in one embodiment these transactions are excluded from the process. In another embodiment, rather than specifying an expiry time, the user can specify an expiry event. For example, the user can select to unlock a particular transaction type (e.g. for 15 online transactions) and select the expiry event (e.g. immediately following the next transaction, immediately following the next two transaction etc). In this embodiment, the transaction-type lock status for online transactions will revert to locked after the specified expiry event. In a further embodiment, the user interface provides an option to lock all transactions for a particular access device. This option is useful in the circumstances where a user notices that the 20 account access device is lost, but does not know if the device has been stolen or has simply been misplaced. Upon selection of this option, a user direction to lock the device is sent to a customer rules engine and the lock status of the device is changed to locked or confirmed as locked. This setting overrides any previously unlock directions and prevents any transactions from being approved until the user chooses to unlock the device again. This enables users to ensure that no 25 fraudulent transactions are processed while they are searching for the device. If the lost device is later found, the user can immediately unlock the device to re-commence transactions. If the device is not found, the user can contact the issuer to cancel the account access device and be reissued with a new one. In one embodiment, the user interface allows the user to choose between different account access devices available on a joint account or on a corporate account 30 with multiple account access devices. For example, enabling the user to lock one or more 15 supplementary cards while not affecting the primary card or vice versa. If it is a corporate account with multiple account access devices, any combination of account access devices may be selected to be locked. Referring to Figure 2, an alternative user interface of the settings modifications facility is 5 illustrated by a series of screen shots 300, 302, 304, 306 from a mobile phone display. In this embodiment, the user interface allows the user to alter the settings of an account access device (in this instance a credit card) where only particular transactions types have a locked status. As shown in the user interface 300, the unlock settings allow the user to select from different locked transaction types. In particular, the locked transaction types are 'international in-store 10 transactions' which relates to transactions made outside of the originating country of the account access device where the account access device is physically presented; 'international online' which relates to internet transactions where the account access device is not physically present and the transaction is processed outside of the originating country of the account access device; and 'cash advance' which relates to cash withdrawals from an ATM or over the counter using 15 the credit card. To find out about the particular transaction type, the user can touch the title 308 of the transaction type, causing transaction type information 310 to be displayed as shown in 302. To unlock the transaction type, the user slides the slider bar 312 next to the transaction type which they want to unlock. As shown in 304, the user then specifies a time limit by touching one of the button selections (in this instance, the options provided are '1 hour', 'indefinitely' or 20 'choose when to lock again'), the selected transaction type is unlocked for the specified time. As shown in 306, the image of slider bar 314 shows an unlocked image indicating that the particular transaction-type lock status is unlocked so that the customer is aware that that those types of transaction will proceed. An embodiment where only particular transaction types are locked is advantageous. 25 Some transaction types are have a higher risk than others. For example, transactions which do not require the account access device to be physically present (e.g. internet transactions) are considered to have a higher risk of fraud than transactions where the account access device must be physically presented. Also, some types of transactions are less frequently used by consumers (e.g. international transactions and ATM cash advance transactions). This embodiment allows 30 high risk or less commonly used types of transactions to be restricted to particular time periods by reverting the lock status to locked after the specified time. Lower risk transactions or more 16 common transactions, can have a transaction-type lock status of default unlocked so they may be freely accessed without having to unlock the account access device. The issuer may provide the account access device which when activated has a transaction-type lock status of locked for high risk and/or less frequently used transaction types 5 and a transaction-type lock status of unlocked for commonly used and/or low risk transaction types. The customer can vary the transaction-type lock status according to their preferences (e.g. by changing the transaction-type lock status for particular transactions to default unlocked). The customer's transaction-type lock status preferences may be transported from one account access device to other account device or to any new or replacement account access devices on expiry of 10 the account access device. Alternatively, the transaction-type lock status for high risk transaction types may be set as default locked by the issuer so that the customer cannot set elect to change the transaction-type lock status to default unlock. This would maintain a high level of security on the default locked transaction types. Referring again to Figure 1, in step 40, the user unlock input entered in the user interface 15 is communicated to and stored in a customer rules engine. The customer rules engine assesses transaction authorisation requests in real time. In one embodiment, once the customer rules engine has stored the lock status information, it is configured to send confirmation to the settings modification facility. The settings modification facility conveys this confirmation to the user via the user interface. This confirmation step is advantageous because the user then knows that the 20 user unlock direction has been received and that the account access device can be used. In one embodiment, when the specified unlock time limit is reached, the customer rules engine is configured to notify the user that the device is locked. The customer rules engine may do this by sending the information to the settings modification facility (which conveys this information to the user via the user interface), or other notification means for example sms, push 25 notification etc). This allows the user to know that the account access device can no longer be used. One embodiment of the transaction system is described in more detail below. In step 50, the user uses the account access device to make a purchase during the time interval they have specified. As the settings in the customer rules engine have been updated, the transaction authorisation system will process the transaction authorisation request in accordance 30 with the lock status of the account access device 51. If the account access device is used after the 17 specified time limit has passed, for example by a fraudulent user, the transaction will be declined by the transaction authorisation system 52. In an embodiment where the user is able to unlock the account access device by inputting a specified time limit, the account access device automatically reverts the lock status to locked 5 after the expiration of the time limit without the need for a user to manually access and change the settings. This process provides advantages over processes where the user can change settings before the transaction and then modify settings after the transaction because the user may forget to change the settings back after the transaction leaving their account vulnerable to fraud after their authorised transaction is made. 10 A default locked status of the account access device means that fraudulent use will be blocked unless the fraudulent user happens to process the transaction during the brief time period unlocked by the user. The transaction system Figure 3 shows a high level diagram of a transaction system in accordance with an 15 embodiment of the invention. This system can be used to perform the method of Figure 1. Figure 3 shows two processes. The upper process shows the customer enquiring and modifying the lock status of an account access device and the lower process shows the interaction of the customer and the systems involved in a transaction event. In the enquiry and modification of the account settings process, the customer 101 20 accesses a settings modification facility 105 to ask for the customer's current account access device settings. The request is sent to and information is received from customer rules engine 111. The customer rules engine 111 stores customer settings information associated with an account access device for use by the settings modification facility 105 and applies the rules to 25 transaction authorisation requests in a real time transaction authorisation system. Customer settings information associated with a particular account access device includes information about settings which are able to be modified by the customer. For example, customer setting information may include the: the lock status, the transaction type limitations, the geographical limitations, the merchant category limitations, the maximum transaction limitation etc.

18 In the modification of settings process, the customer 101 issues a user direction to unlock the account until a specified time limit using a settings modification facility 105. The user direction is communicated to the customer rules engine 111 which updates the lock status for the account access device including recording expiry time of the time limit. A confirmation message 5 is sent from the customer rules engine 111 to the settings modification facility 105 to let the customer 101 know that the settings have been updated. The customer rules engine 111 also sends the details of the changed settings to a audit storage facility 121. The audit storage facility 121 keeps a record of all changes made to settings for audit purposes and dispute handling purposes. The audit storage facility 121 may also be 10 configured to store information about the account including what settings/controls have been put in place, who put them in place (customer or staff), by which channel (banking application, assisted customer service platform etc) and at what time. The policing of the expiry time of a specified time limit can be performed in a variety of different ways. 15 In one embodiment, the customer rules engine 111 updates the lock status of a particular account access device to unlock, and a timer is started to monitor the expiry time of the lock status. Upon the timer registering the expiry time for the lock status, the customer rules engine 111 is updated so the lock status of the account is locked. The timer can be set to count down to the specified expiry time or monitor for a particular time for updating the lock status. The timer 20 may be part of the customer rules engine 111 or another sub-system attached to the customer rules engine 111. In another embodiment, the customer rules engine 111 records the lock status and the expiry time. The customer rules engine 111 is monitored by a polling engine which searches for expiry times and updates the lock status when the expiry time is reached. 25 In another embodiment, the customer rules engine 111 records the lock status and the expiry time. When a transaction authorisation request is processed by the customer rules engine 111 or the settings modification facility 105 requests information associated with the account access device, the customer authorisation system 111 compares the expiry time with the current time (or alternatively the time of the request). If the current time or the transaction authorisation 30 request or settings query is before the expiry time the lock status of unlocked is applied. If the 19 current time or the time of the request is greater than the expiry time, the lock status of unlocked is not applied. The above embodiments ensure that when the transaction authorisation request is processed by the customer rules engine 111 or the settings modification facility 105 requests 5 information from the customer rules engine 111, the information regarding the lock status is current. Real time transaction event A customer 101 initiates a transaction using the account access device. In this step 130, account access device information and transaction information is acquired by an 10 acquirer/gateway 131 which uses the information to generate a transaction authorisation request. The transaction authorisation request includes account access device information such as the account number and a security feature such as a CVC number. The transaction authorisation request also includes transaction information, for example, the amount of the transaction and the account number to which funds are being transferred. The transaction authorisation request may 15 include information about where the request is generated, the country of acquirer, the currency, the timestamp, the merchant category code, the transaction channel (e.g. Paypass, Card swiped, EMV chip, PIN authorised, or signature authorised transaction) etc. The details of this acquisition step 130 differ for different payment methods. In a bricks and mortar store, a customer can pay for their purchase using their account access device at a 20 Point of Sale (POS), e.g. using a credit card, a debit card or a smartphone application equipped with near field communication (for example using an application and an iCarte case). Details of the account access device are transferred electronically to the acquirer via e.g. the merchant's card reader. The card reader receives account identification information for example by reading the magnetic strip or the security chip embedded in the card or by communicating with a 25 contactless feature on the account access device e.g. by near field communication. If the customer is making an ATM transaction (e.g. a cash withdrawal or cash advance), the customer inserts his or her credit or debit card into the ATM card reader and enters the details of the transaction.

20 If the customer is making an online purchase, the customer can pay for their purchase by entering the credit card details and verification numbers at a merchant website. If the customer is making an assisted bank transaction, they present their credit or debit card to a bank teller. The bank teller passes the card through a card reader. 5 In a telephone order transaction, the customer telephones or mails an organisation credit card and security information. If the customer is using a payment application on a smartphone, the customer may log into the payment application and enter transaction details. The customer may also use one of these method to sign up for a recurring credit/debit by 10 giving a merchant the customer's credit card or debit card details. It should be understood that the acquirer may be the issuer or it may be another institution (e.g. the merchant's bank, the ATM's bank, etc). Real time authorisation Once the acquirer/gateway 131 has acquired the transaction details and the account 15 access device information, and generated an electronic transaction authorisation request, the request is communicated to and processed by a transaction authorisation system. For some transactions, the acquirer/gateway 131 is a system which includes several intermediate parties and several systems. This will be described in more detail below with reference to Figure 4. As shown in Figure 3, the transaction authorisation request is first sent from the acquirer 20 to the issuer authorisation engine 110 for processing (step 139) and then to the customer rules engine 111 for processing (step 149). The issuer authorisation engine 110 processes the transaction request using issuer authorisation rules. The customer rules engine 111 processes the transaction request using customer authorisation rules including checking the lock status of the user access device. The authorisation method is described in more detail below with reference to 25 Figure 5. The customer rules engine 111 communicates the approval or decline of the transaction to the audit storage facility 121 (step 161) so that the transaction attempt can be recorded. If the transaction is suspicious, the customer rules engine 111 is able to communicate with a Fraud 21 monitoring system 151 to place the transaction in a fraud investigation list to be investigated (step 163). The customer rules engine 111 is also able to direct a notification events engine 141 (step 165). Upon receiving direction from the customer rules engine 111, the notification events engine 141 then notifies the customer 101 (e.g. by SMS, push notification or by email) (step 5 167). The customer rules engine 111 communicates the approval or decline of the transaction authorisation request to the issuer authorisation engine 110 (step 168). The issuer authorisation engine 110 then communicates an approval or decline of the transaction authorisation request to the acquirer 131. The acquirer 131 notifies the customer whether the transaction has been approved (step 171). 10 In an alternative embodiment, the steps 161, 163 and 165 may be performed by the issuer authorisation engine 110 or by another part of the transaction authorisation system. In one embodiment, the issuer authorisation engine processes the transaction upon receiving the transaction authorisation request from the acquirer. In another embodiment, the issuer authorisation engine 110 processes the transaction authorisation request in accordance with the 15 issuer authorisation rules upon receiving the approval or decline response from the customer rules engine 111. In yet a further embodiment the issuer authorisation engine processes some of the issuer authorisation rules before sending the transaction authorisation request to the customer rules engine and the rest of the rules after receiving an transaction approval message from the customer rules engine 111. In Figure 3, the customer rules engine is a separate rules engine from 20 the issuer authorisation engine. In an alternative embodiment, the customer and issuer rules are incorporated into a single rules engine. Figure 4 shows a more detailed diagram of the acquirer/gateway system 131 and the transaction authorisation system 450 of Figure 3. For some transaction types, the transaction authorisation request is sent between more 25 than one entity including another financial institutions (OFI). For example, if the customer commences a transaction using another financial institution's POS 401 or an internet merchant 402, the transaction request is transferred to a payment network (e.g. schemes 406 such as Cirrus, Maestro, Mastercard, Visa, American Express, etc.) before being sent to the transaction authorisation system 450. If the customer commences a transaction using another financial 30 institution's ATM internationally, the transaction authorisation request will be communicated via a scheme 406 to a common transaction system 452 which then communicates the request to the 22 transaction authorisation system 450. If the customer commences a transaction using another financial institution's ATM domestically, the transaction authorisation request will be communicated via a bilateral agreement 408 to a common transaction system 452 which then communicates the request to the transaction authorisation system 450. 5 For some transactions, the transaction is not sent to other entities, but is transferred between different issuer systems. For example, if the transaction commences at an issuer ATM 410, the transaction authorisation request is then sent via an issuer ATM system (e.g connex 414) before being communicated to a common transaction system 452 and then to the transaction authorisation system 450. If a transaction is commenced at an issuer POS, the transaction 10 authorisation request is sent to the common transaction system 452 and then to the transaction authorisation system 450. As described above, the transaction authorisation system processes the transaction authorisation request using the issuer authorisation engine 110 and the customer rules engine 111 and the approval or decline is then communicated back through the various acquirer systems 131 15 to the customer. Authorisation method Figure 5 shows a method of processing a transaction authorisation request in accordance with an embodiment of the invention. At step 201, the transaction authorisation system receives a transaction authorisation request including account access device information and transaction 20 information. At step 203, the transaction authorisation system checks whether the lock status is locked. As described above, in one embodiment, the lock status includes an expiry time and the customer rules engine 111 checks the current time against the expiry time to determine the lock status. In one embodiment, the lock status is an account access device lock status, this lock status applies 25 to all transactions made by the account access device, the customer rules engine 111 applies the test to all transactions made with the account access device. In other embodiments, the lock status is specific to a particular transaction type, country or region where the request was initiated, merchant category etc. In which case, the customer rules engine 111 first determines from the transaction authorisation request whether the transaction falls within the specific 23 category and then checks the lock status for that particular category of transaction and applies the lock status for the particular transaction. If the status is unlocked, at step 209, other transaction checks are performed including applying other customer modifiable rules (for example checking whether the transaction limit 5 exceed the maximum transaction amount specified by the customer, etc.) and applying issuer authorisation rules (for example checking that there are sufficient funds in the account to complete the transaction, whether the transaction amount exceeds the account access device limit, whether the security information is correct, etc). If the transaction passes these additional transaction checks, the transaction is approved (step 211) and an approval message is sent and 10 the transaction details are recorded for audit purposes. If the lock status is locked or if the transaction does not pass the additional transaction checks, the transaction authorisation system proceeds to step 213. In this step, the transaction authorisation system sends a decline response to the acquirer. The transaction authorisation system then checks whether the customer has elected to receive alerts when the transaction is 15 declined (step 215). If the customer has elected to receive alerts, in step 216, the customer is notified of the declined transaction. At step 217, the transaction authorisation system then performs a further check of the transaction to determine whether the transaction is suspicious e.g. by applying predictive rules to identify possible fraudulent transactions or for example because transactions have been commenced when the account access device is locked. If there are 20 suspicious circumstances, (step 218) the transaction will be recorded in fraud monitoring system. At step 219, the details of the transaction (including the reasons for the decline) are recorded for audit purposes. In a further embodiment, step 209 is performed before step 203. Hardware overview 25 The present invention is implemented over electronic network systems. Such systems may include a variety of computer hardware running different computer programs. Figure 6 illustrates an example embodiment that includes a computer server 100 and a computer host 210, both of which can be any type of computing device including, but not limited to a personal computer (PC) using an operating system such as Microsoft Windows, Unix or Linux, or a 30 Macintosh computer, mainframe computer, or a combination of such devices, for example being 24 connected via a communication network. The computer server 100 includes a processor 112 that can be a single processor or a plurality of processors, memory 120 that can include a plurality of combinations of volatile and/or non-volatile memory, the processor and memory coupled to a system bus 150, and a network interface 140 that enables the computer server to access a 5 communication network 200. It will be understood by a person skilled in the art that a typical computer system will usually include at least a processor and memory coupled by a bus, but that the invention can be implemented with other computer system configurations or in a distributed computing environment. At least one software program 139 is executed on the computer server and contains 10 data relevant to transactions performed with this system. One or more computer servers are used to run the customer rules engine 110, the issuer authorisation engine 111, the notifications events engine 141, the fraud monitoring system 151 and the audit storage facility 121 in the present invention. The communication network 200 can be any type of network including, but not limited 15 to, a local area network (LAN), a wide area network (WAN) such as the Internet, a wireless network or a mobile network. The communication network facilitates bidirectional communication between the computer server 100 and the computer host 210. The computer host includes a processor 230 that can be a single processor or a plurality of processors, memory 240 that can include a plurality of combinations of volatile and/or non 20 volatile memory, and a network interface 220 that enables the computer server to access a communication network 200. The components of the computer host are also coupled to a system bus 260 which also coupled to a input output devices 250 which may include, for example, displays, touch screens, mouses, keyboards, keypads, card readers etc. The user interface enables a user of the computer host to access information provided by the system and hosted by the 25 computer server, and to enter information relevant to settings modification and/or a transaction, the information then being transmitted to the computer server 100 via the communication network 200. Examples of host computers described above include POS devices, ATMs, user computers, tablets and mobiles.

25 It will be understood that the invention disclosed and defined in this specification extends to all alternative combinations of two or more of the individual features mentioned or evident from the text or drawings. All of these different combinations constitute various alternative aspects of the invention.

Claims (5)

1. A method for controlling an account access device including: a) storing information associated with an account access device, the information associated with the account access device including at least one transaction-type lock status for a 5 transaction type, the transaction-type lock status selected from locked and unlocked, wherein the transaction-type lock status information is configured to be used in a transaction authorisation system, and wherein the transaction authorisation system is configured to receive a transaction authorisation request for the transaction type associated with an account access device, and to generate a negative authorisation output if the transaction-type lock status is 10 locked and to generate a positive authorisation output if the transaction-type lock status is unlocked; and b) upon receiving a user direction to change the transaction-type lock status to unlocked for a specified time limit, updating the transaction-type lock status of the account access device to unlocked and registering the time limit for the transaction-type lock status; 15 wherein the transaction-type lock status includes at least one of: an internet transaction lock status, an ATM lock status, an electronic bill lock status, a telephone order lock status, 20 a point of sale lock status; a transfer out to third party lock status; an international money transfer lock status; a cash advance transaction lock status; an international in store transaction lock status; and 25 an international internet transaction lock status and wherein the specified time limit is less than a lifetime of the account access device, and wherein the transaction authorisation system is configured to generate a negative authorisation output for the transaction type after the specified time limit has expired.

2. The method of claim 1, wherein the maximum specified time limit is one of the group 30 consisting of: two weeks or less; 27 one week or less; 24 hours or less; 12 hours or less; 6 hours or less; 5 1 hour or less; 0.5 hours or less; and 5 minutes or less.

3. The method of any one of the preceding claims, wherein a first transaction-type lock status is default locked for a first transaction type. 10

4. The method of claim 3, wherein a second transaction-type lock status is default unlocked for a second transaction type.

5. A system including: a user interface associated with an account access device; the user interface including a means for receiving a user unlock input associated with the account access device; the user 15 unlock input including a specified expiry time and at least one specified transaction type, wherein the user interface is in data communication with a means for storing information associated with the access device, the information associated with the account access device including at least one transaction-type lock status for a transaction type; wherein the transaction type lock status is one of locked and unlocked, 20 wherein the transaction-type lock status information is configured to be used in a transaction authorisation system and wherein the means for storing information is in data communication with a transaction authorization system, the transaction authorisation system transaction authorisation system configured to receive a transaction authorisation request for the transaction type associated with the account access device and to generate a negative authorisation output if 25 the transaction-type lock status is locked and to generate a positive authorisation output if the transaction-type lock status is unlocked and wherein the means for storing information is configured to receive a user direction to unlock the account access device for a specified time limit and specified transaction type from the user interface and to update the transaction-type lock status of the account access device to unlock and record an time limit for the transaction 30 type lock status wherein the transaction-type lock status includes at least one of: 28 an internet transaction lock status, an ATM lock status, an electronic bill lock status, a telephone order lock status, 5 a point of sale lock status; a transfer out to third party lock status; an international money transfer lock status; a cash advance transaction lock status; an international in store transaction lock status; and 10 an international internet transaction lock status and wherein the specified time limit is less than a lifetime of the account access device, and wherein the transaction authorisation system is configured to generate a negative authorisation output after the specified time limit has expired.